Universidad Tecnológica Nacional Facultad Regional Buenos Aires

Transcripción

1 Universidad Tecnológica Nacional Facultad Regional Buenos Aires Dirección de Educación de Posgrado Sistema Inteligente para la selección de un Administrador de Contenidos a través de la Web Tesis de Maestría en Ingeniería en Sistemas de Información Corsi, Diego Pablo Director: Dr. Ing. Raimundo O. D Aquila 2008

2 - ii -

3 A Adriana - iii -

4 - iv -

5 RESUMEN En esta tesis se presenta el sistema inteligente CMS-SOM, el cual, al ser consultado a través de la Web, puede ayudar a seleccionar - de entre un grupo predeterminado de Administradores de Contenidos o CMS (Content Management Systems) - aquel que mejor cumpla con una serie de requerimientos ingresados. El desarrollo de CMS-SOM fue motivado por la dificultad de aplicar las metodologías convencionales para la selección del CMS que esté más acorde a las necesidades de una organización, ya que los productos disponibles en el mercado son demasiado numerosos y diversos. Durante la realización de este trabajo se analizaron distintas técnicas del campo de los sistemas inteligentes, a fin de determinar cuál sería la más adecuada para resolver el problema planteado, y se optó finalmente por emplear un tipo de sistema neuronal: los mapas autoorganizativos de Kohonen (SOM). Los resultados experimentales confirmaron la validez de CMS-SOM. Después de recibir del usuario los requerimientos previstos para las pruebas, el sistema mostró mapas donde se podían identificar con facilidad los CMS que más se aproximaban a las características requeridas, y a partir de estos conjuntos reducidos de CMS, la finalización del proceso de selección aplicando métodos convencionales de evaluación ya no presentaría ninguna dificultad. Palabras clave: Sistemas Inteligentes, Redes Neuronales, Mapas Autoorganizativos de Kohonen, Administradores de Contenidos, Aplicaciones basadas en la Web - v -

6 - vi -

7 ABSTRACT This thesis presents the web-based intelligent system CMS-SOM, which can help to select - from among a predetermined group of CMSes (Content Management Systems) - the one that best fulfills a series of given requirements. The development of CMS-SOM was motivated by the difficulty of applying conventional methods for the selection of the CMS that best matches the needs of an organization, since the products available on the market are too numerous and diverse. During the realization of this work different techniques of the intelligent systems field were analyzed, in order to determine which of them would be the most appropriate to solve the mentioned problem, and a type of neuronal system was finally chosen: Kohonen's Self Organizing Maps (SOM). The experimental results confirmed the validity of CMS-SOM. After receiving from the user the requirements that were foreseen for the tests, the system displayed maps where the CMSes that closest matched the required features could be easily identified, and continuing from these narrowed sets of CMSes, the completion of the selection process by applying conventional evaluation methods would no longer offer any difficulty. Keywords: Intelligent Systems, Neural Networks, Kohonen's Self Organizing Maps, Content Management Systems, Web-based Applications - vii -

8 - viii -

9 AGRADECIMIENTOS Quisiera a través de estas líneas expresar mi agradecimiento a las personas que con su dedicación, apoyo y orientación me acompañaron durante el proceso de elaboración de esta tesis. Al Dr. Ing. Raimundo O. D Aquila por comprometerse con la dirección de este trabajo, aportando su inestimable asesoramiento y dedicándole su tiempo. A mi esposa Adriana, quien me alentó y me ayudó durante todo el proceso. A mi hermano Martín, por haberme ayudado con el ingreso de los datos. A mis compañeros de curso en la maestría, por haber compartido conmigo sus hallazgos, en especial a José Luis Octavio Rodríguez y Elisa Bianchi. A todos los expertos en Administradores de Contenidos que me proporcionaron los datos sobre sus sistemas (las identidades de aquellos que respondieron solamente mi cuestionario online lamentablemente me son desconocidas), y en particular a los siguientes, a quienes contacté directamente o me respondieron por correo electrónico en forma espontánea, para hacerme sugerencias o demostrarme su interés en este trabajo: De Alemania: Alexander Stuckenholz (jefe de desarrollo de Calimero.CMS) y Oliver Georgi (responsable del CMS phpwcms) De Argentina: Luis Argerich (autor del CMS TikiWiki) De Australia: Scott Davey (director de la empresa Datalink que desarrolla el CMS Freestyler) y Andrew Eddie (director de proyecto del CMS Joomla!) De Bélgica: Dries Buytaert (fundador y director de proyecto del CMS Drupal) De Estados Unidos: Dave B. Johnson (de Oracle Corporation, y experto en el sistema Universal Content Management) De Suiza: Ivan Schmid (de Comvation AG, los desarrolladores del CMS Contrexx) y Tristan Renaud (de Jahia Ltd, responsables por la línea de CMS Jahia) - ix -

10 - x -

11 PALABRAS DEL DIRECTOR Conozco a Diego desde hace mucho tiempo. Aproximadamente 10 años. Primeramente, trabajamos en un Laboratorio de Investigación y Desarrollo de la EST (Escuela Superior Técnica, Universidad del Ejército), donde Diego tuvo la oportunidad de trabajar con las técnicas de Inteligencia Computacional: clásica y de Soft Computing. Luego, lo invité a trabajar en el Laboratorio de Inteligencia Artificial del I.T.B.A. (Instituto Tecnológico de Buenos Aires). Más tarde pasó a ser uno de mis Adjuntos en la materia Sistemas Inteligentes, perteneciente a la carrera de Ingeniería Informática de dicho Instituto. En todos estos trabajos, Diego demostró su alta capacidad, su deseo de aprender y su gran responsabilidad, destacándose mucho en todas las tareas que realizó. Por todo lo expresado arriba, fue una satisfacción muy grande para mí cuando me ofreció ser el Director de esta Tesis. En mi entender, Diego ha realizado un trabajo digno de lo que se espera de una persona de sus altos valores, donde mi principal tarea se limitó a orientarlo en los formalismos y la estructura del trabajo. Auguro para Diego un futuro más promisorio aún, donde esta Tesis será un eslabón más en su brillante carrera. Le pedí a Diego que me permitiera expresar estas palabras, dado el conocimiento y la gran estima que tengo de él, por sus altos valores académicos y profesionales y, más aún, por sus altos valores personales y morales. Raimundo O. D Aquila - xi -

12 - xii -

13 ÍNDICE 1. INTRODUCCIÓN Estructura de la tesis ESTADO DEL ARTE Administración de contenidos Proyecto para la adopción de un CMS Métodos para la evaluación y selección de un CMS Suma y ponderación numéricas (NWS) Suma y ponderación cualitativas (QWS) Maximax (MM) Eliminación por aspectos (EBA) Ordenamiento lexicográfico (LO) Agregación lógica de preferencias (LSP) Selección de CMS a través de la Web CMS-Search Produktfinder Content Management Overview CMS-Matrix PLANTEO DEL PROBLEMA SOLUCIÓN PROPUESTA Los mapas autoorganizativos de Kohonen (SOM) Arquitectura Funcionamiento Aprendizaje Un ejemplo clásico Desarrollo de un sistema SOM genérico Requisitos para el sistema SOM genérico Diseño del sistema SOM genérico Implementación del sistema SOM genérico Prueba del sistema SOM genérico Una nueva lista de características descriptivas de los CMS Elección de los CMS iniciales para CMS-SOM xiii -

14 4.5. Obtención de los datos de los CMS iniciales de CMS-SOM Solicitud de datos a los fabricantes Búsqueda de datos en la Web Implementación de CMS-SOM RESULTADOS EXPERIMENTALES Mapas SOM considerando todas las características posibles PHP-Nuke 8.0, PostNuke y Xaraya Mambo y Joomla! Drupal 4.7 y Typo3 - Version Mapas SOM considerando sólo características requeridas Búsqueda de CMS basados en LAMP Búsqueda de CMS basados en J2EE Búsqueda de CMS basados en.net Búsqueda de CMS basados en Perl Búsqueda de CMS basados en Zope Búsqueda de CMS con las características del CMS Jahia CONCLUSIONES Aportes del presente trabajo Futuras líneas de investigación REFERENCIAS BIBLIOGRAFÍA ANEXOS A1. Lista de CMS de CMS-Search A2. Lista de CMS de Produktfinder A3. Lista de CMS del Content Management Overview A4. Lista de CMS de CMS-Matrix A5. Lista de CMS de CMS-SOM A6. CMS-Search: Lista de características descriptivas de CMS A7. Produktfinder: Lista de características descriptivas de CMS A8. CM-Overview: Lista de características descriptivas de CMS A9. CMS-Matrix: Lista de características descriptivas de CMS A10. CMS-SOM: Lista de características descriptivas de CMS xiv -

15 LISTA DE FIGURAS Figura 1. Dificultades al adoptar un CMS... 9 Figura 2. Descripción General de la Gestión de las Adquisiciones Figura 3. Diagrama de Flujo de la Gestión de las Adquisiciones Figura 4. Algunos de los datos que deben ingresarse como texto en CMS-Search Figura 5. Características no seleccionables en CMS-Search Figura 6. Búsqueda de un CMS gratuito basado en LAMP en CMS-Search Figura 7. CMS gratuitos basados en LAMP mostrados por CMS-Search Figura 8. Página de inicio de Produktfinder (en alemán) Figura 9. Página de inicio del portal contentmanager.net Figura 10. Página de inicio de Product finder (en inglés) Figura 11. Selección de la categoría CMS en Produktfinder Figura 12. Selección del criterio Soporte de XML en Produktfinder Figura 13. Selección de los subcriterios Importación y Exportación en Produktfinder Figura 14. Obtención de un listado de productos en Produktfinder Figura 15. Búsqueda de un CMS gratuito basado en LAMP en Produktfinder Figura 16. CMS gratuitos basados en LAMP mostrados por Produktfinder Figura 17. Despliegue de controles en Content Management Overview Figura 18. Explicación contextual en Content Management Overview Figura 19. Búsqueda de un CMS gratuito basado en LAMP en CM-Overview Figura 20. Explicación contextual emergente en CMS-Matrix Figura 21. Búsqueda de un CMS gratuito basado en LAMP en CMS-Matrix Figura 22. A: un conjunto de n CMS Figura 23. R: una lista de requerimientos (c características como máximo) Figura 24. Perceptrón multicapa en funcionamiento Figura 25. Red ART1 en funcionamiento Figura 26. Arquitectura de la red neuronal SOM Figura 27. Vecindad topológica Figura 28. SOM mostrando los 16 animales Figura 29. Diagrama de clases del sistema SOM genérico Figura 30. Diagrama de secuencia del sistema SOM genérico Figura 31. Representación de un registro en XML Figura 32. Otra representación de un registro en XML Figura 33. Estructura del fichero de datos del sistema SOM genérico Figura 34. Vista general de MyJavaServer Figura 35. Ficheros del sistema SOM genérico alojados en MyJavaServer Figura 36. El fichero animales.xml Figura 37. Página de inicio del Sistema Inteligente para la selección de un animal Figura 38. Fragmento del código HTML de animales.html Figura 39. Una estrategia para la prueba del software Figura 40. Validación automática del fichero animales.xml xv -

16 - xvi - Figura 41. Validación automática del fichero animales.html Figura 42. Validación automática del fichero estilo.css Figura 43. Formulario de entrada de datos (cerrado) Figura 44. Formulario de entrada de datos (abierto) Figura 45. Ingreso de las características de un águila (eagle) Figura 46. Mapa SOM obtenido al ingresar las características de un águila (eagle) Figura 47. Tabla obtenida al ingresar las características de un águila (eagle) Figura 48. Ingreso de la característica Mediano Obl. SÍ y el resto Indistinto Figura 49. Mapas SOM obtenidos al ingresar Mediano Obl. SÍ y el resto Indistinto Figura 50. Tablas obtenidas al ingresar Mediano Obl. SÍ y el resto Indistinto Figura 51. Explicaciones contextuales ofrecidas por el sistema SOM genérico Figura 52. El ciclo de vida del contenido según Robertson Figura 53. El ciclo de vida del contenido según Röwekamp Figura 54. El ciclo de vida del contenido según Bechtolsheim y Oberbauer Figura 55. Cantidad de CMS comparados en CMS-SOM (por país de origen) Figura 56. Países de origen de los CMS comparados en CMS-SOM Figura 57. Formulario online para solicitar datos de CMS Figura 58. Ficheros de CMS-SOM alojados en MyJavaServer Figura 59. Página de inicio de CMS-SOM Figura 60. Fragmento del código HTML de la página de inicio index.html Figura 61. Ficheros de la página de inicio de CMS-SOM alojada en AwardSpace Figura 62. Acceso a CMS-SOM desde Figura 63. Primer mapa SOM obtenido al considerar las 400 características posibles Figura 64. Segundo mapa SOM obtenido al considerar las 400 características posibles Figura 65. Tercer mapa SOM obtenido al considerar las 400 características posibles Figura 66. Cuarto mapa SOM obtenido al considerar las 400 características posibles Figura 67. Preguntas más frecuentes sobre PostNuke en Dev-Postnuke.com Figura 68 Documentación sobre la compatibilidad de Xaraya con PostNuke Figura 69. Joomla! reconocido como bifurcación de Mambo Figura 70. Resultado de buscar Drupal Typo3 en Google Figura 71. Resultado de buscar Typo3 Drupal en Google Figura 72. Ingreso de los requerimientos para la primera prueba de CMS-SOM Figura 73. Mapa SOM obtenido en la primera prueba de CMS-SOM Figura 74. Ingreso de los requerimientos para la segunda prueba de CMS-SOM Figura 75. Mapa SOM (vista parcial) obtenido en la segunda prueba de CMS-SOM Figura 76. Tabla (vista parcial) obtenida en la segunda prueba de CMS-SOM Figura 77. Ingreso de los requerimientos para la tercera prueba de CMS-SOM Figura 78. Mapa SOM obtenido en la tercera prueba de CMS-SOM Figura 79. Ingreso de los requerimientos para la cuarta prueba de CMS-SOM Figura 80. Mapa SOM (vista parcial) obtenido en la cuarta prueba de CMS-SOM Figura 81. Tabla (vista parcial) obtenida en la cuarta prueba de CMS-SOM Figura 82. Ingreso de los requerimientos para la quinta prueba de CMS-SOM Figura 83. Mapa SOM obtenido en la quinta prueba de CMS-SOM Figura 84. Tabla (vista parcial) obtenida en la quinta prueba de CMS-SOM Figura 85. Requerimientos para la sexta prueba de CMS-SOM Figura 86. Mapa SOM obtenido en la sexta prueba de CMS-SOM Figura 87. Mapa SOM (vista parcial) obtenido en la sexta prueba de CMS-SOM Figura 88. Tabla (vista parcial) obtenida en la sexta prueba de CMS-SOM

17 LISTA DE TABLAS Tabla 1. Características de los 16 animales a mostrar en un SOM Tabla 2. Descripción del fichero de datos del sistema SOM genérico Tabla 3. Prueba de integración: Respuestas esperadas vs. respuestas obtenidas Tabla 4. Resultados de la prueba de validación del sistema SOM genérico Tabla 5. Rubros en que algunos sistemas clasifican las características de los CMS Tabla 6. Rubros en que CMS-SOM clasifica las características de los CMS Tabla 7. Sistemas donde son mencionados los CMS iniciales de CMS-SOM Tabla 8. CMS basados en LAMP Tabla 9. CMS basados en J2EE Tabla 10. CMS basados en.net Tabla 11. CMS basados en Perl Tabla 12. Grupos de CMS surgidos en la quinta prueba de CMS-SOM Tabla 13. CMS basados en Zope xvii -

18 - xviii -

19 CAPÍTULO 1 INTRODUCCIÓN 1 Antes de la invención de la World Wide Web, el término información solía utilizarse "para incluir tanto los datos estructurados procesados mediante las aplicaciones de administración de datos (data management applications), como los textos no estructurados de las aplicaciones de administración de documentos (document management applications)" [Gilbane, 2000, p. 2]. Sin embargo, debido a la naturaleza multimedial de la Web "se hizo necesario reemplazar el término información por otro que abarcara, además, lo que tienen en común el audio, el video en tiempo real, el código ejecutable, la información transaccional, etc. y el término 'contenido' parece servir razonablemente bien para ello" [ibidem, p. 3]. Ejemplos de contenido son "las informaciones de la empresa, las descripciones de los productos, los catálogos, los manuales de operación, etc. que constituyen un componente fijo del lanzamiento y la ejecución de los negocios" [Bechtolsheim y Oberbauer, 2001, p. 7] En cuanto a la administración de los contenidos, este término es lo suficientemente vago como para que se haya llegado a afirmar que "siempre hay alguien dispuesto a considerar que hacerle cualquier cosa a un documento, excepto quizá leerlo, es administrarlo" [Gilbane, 2000, p. 3]. Por eso, la mayoría de las definiciones de administración de contenidos simplemente enumeran los pasos recorridos durante el procesamiento del contenido: La filosofía, metodología y práctica conocida como "administración de contenidos" [...] puede ser definida más precisamente en términos de actividad [...] En su forma más simple, se reduce a la gestión de activos (asset management), o sea, organizar unidades de contenido, su transformación y su publicación [Suh et al., 2002]. "Content management" es una variedad de herramientas y métodos empleados para recolectar, procesar y distribuir contenido de diversos tipos [McIntosh, 2000, p. 17]. Existen muchas cosas que se pueden hacer con el contenido y que podrían ser, y de hecho lo son, consideradas "administración": creación (authoring), adquisición, publicación, generación dinámica de páginas, integración, ensamblado (assembling), control de versiones (versioning), configuración, enlace (linking), distribución, almacenamiento temporal (caching), análisis, compartimiento (sharing), búsqueda (searching), categorización, transformación, reutilización, sindicación (syndicating), archivamiento, etc. [Gilbane, 2000, p. 3] Los sistemas específicos utilizados para llevar a cabo la administración de contenidos se denominan administradores de contenidos o CMS (Content Management Systems)

20 Cuando en una organización se inicia un proyecto para llevar a cabo la adopción de un CMS, uno de los objetivos que deben cumplirse es la adquisición del sistema. En esta tesis se propone resolver un problema específico con el cual se encuentran los responsables del proyecto: identificar a los vendedores de los CMS que más se aproximan a las características requeridas por la organización. Esta no es una tarea trivial, debido principalmente a la confluencia de los dos factores siguientes: Cantidad de CMS existentes en el mercado: Para seleccionar un sistema que cubra satisfactoriamente las necesidades de la organización, actualmente hay que comparar un gran número de sistemas, ya que "más de 1000 productos de software tienen como objetivo administrar contenidos en la Web" [Byrne, 2005]. Propiedades que caracterizan a cada CMS: Para poder evaluar la aptitud de un CMS, es necesario comparar sus características con las necesidades de la organización. Pueden existir cientos de ellas, como prueba el Content Management Requirements Toolkit, un listado que "contiene 133 requerimientos totalmente desarrollados, listos para copiar y pegar en su solicitud de propuestas" [STD, 2004] Una vez que se dispone de un conjunto reducido de vendedores de CMS, la finalización del proceso de selección del sistema que mejor se adapta a las necesidades de la organización se puede realizar aplicando métodos convencionales de evaluación. La importancia de este trabajo radica en que, para resolver el problema mencionado, no sólo se propuso una solución, sino que, además, ésta se implementó y está actualmente en funcionamiento. Se trata de CMS-SOM, un sistema inteligente que, al ser consultado a través de la Web, genera y muestra mapas donde se puede identificar con facilidad, de entre un grupo predeterminado de 160 vendedores de CMS, cuáles son los que más se aproximan a los requerimientos efectuados. CMS-SOM puede ayudar a reducir los costos que actualmente acarrea la selección de un administrador de contenidos. Bob Doyle [2004a] menciona que (en los EE.UU.): Los expertos de la industria como Bob Boiko, Tony Byrne, Jo Ann Hackos, Gerry McGovern, James Robertson y Ann Rockley pueden ser contratados como consultores neutrales por unos pocos miles de dólares para dictarle seminarios de un día de duración al personal clave que será el equipo de administración de contenidos de la organización [...] Los informes de los analistas de la industria, donde se evalúa a las empresas que producen CMS y se reportan las tendencias tecnológicas en la administración de contenidos y las herramientas que las implementan, oscilan entre unos pocos cientos de dólares y USD 1000 o más [...] Entre los documentos para el análisis de las necesidades, para las especificaciones y para las solicitudes de propuestas se encuentran el CMS Planner (USD 300) de Boiko y el Requirements Toolkit (USD 550) de James Robertson, que ofrecen plantillas para utilizar durante el proceso de selección

21 Las características más relevantes de CMS-SOM son las siguientes: El sistema emplea mapas autoorganizativos de Kohonen (SOM) y, por lo tanto, entra dentro de la categoría de los Sistemas Inteligentes. El sistema es de fácil uso: el usuario ingresa sus requerimientos y recibe un mapa donde se encuentran distribuidos, en un panal de celdas hexagonales, los nombres de los CMS y una leyenda representando los requerimientos ingresados. Cuanto más cerca de la leyenda aparezca un CMS, mayor será la aptitud de éste. El sistema es accesible a través de la Web mediante un navegador (browser). El sistema mantiene sus datos en el servidor, almacenados en un fichero en XML (Extensible Markup Language), lo que facilita su procesamiento (lectura, edición, etc.) El sistema está formado por Java servlets, que generan dinámicamente las páginas vistas en el navegador, a partir de los requerimientos ingresados por el usuario, de los datos de los CMS leídos desde el fichero en XML y de los cálculos que se realizan. El sistema emplea hojas de estilo CSS (Cascade Style Sheets) para definir el formato de los distintos elementos de las páginas web. El sistema cumple con los estándares Web del Consorcio World Wide Web (W3C). El sistema sólo permite que sea el administrador quien modifique los datos de los CMS, lo que puede ayudar a garantizar la veracidad de los mismos. El sistema le ofrece al usuario una gran flexibilidad para que ingrese sus requerimientos, los cuales pueden estar formados por hasta 400 características (agrupadas en 66 categorías, y éstas a su vez en 10 rubros) que definen a los CMS. Constituyen características originales de CMS-SOM: El sistema ofrece una tabla completa con los datos de los CMS, para su comparación. Los sistemas presentados en el capítulo 2 no indican todos los datos con que trabajan. El sistema permite especificar requerimientos de 5 tipos: "obligatoriamente NO", "preferentemente NO", "indistinto", "preferentemente SÍ" y "obligatoriamente SÍ". Los sistemas presentados en el capítulo 2 sólo permiten establecer un tipo de requerimientos (aquellos que obligatoriamente deben cumplirse). El sistema utiliza solamente botones de exclusión mutua (radio buttons), por lo que nunca es necesario ingresar textos. Los sistemas presentados en el capítulo 2 utilizan métodos menos eficaces para el ingreso de los requerimientos. El sistema muestra explicaciones contextuales de todos los requerimientos efectuables, para que el usuario siempre esté informado del significado de las distintas opciones. Los sistemas presentados en el capítulo 2 requieren profundos conocimientos sobre administración de contenidos para poder ser operados

22 1.1. Estructura de la tesis Esta tesis está dividida en seis capítulos: Capítulo 1. Introducción: Aquí se presentan el tema general de la tesis, el problema abordado y la solución propuesta. Además, se describe la estructura del trabajo. Capítulo 2. Estado del Arte: En este capítulo se explica la adopción de un CMS y se realiza una presentación crítica de los principales métodos utilizados actualmente para evaluar y seleccionar administradores de contenidos. Capítulo 3. Planteo del Problema: Aquí se define el problema que se propone resolver: la identificación de un grupo de posibles vendedores de CMS para poder, posteriormente, llevar a cabo la selección del CMS que mejor cumpla con los requerimientos de la organización. Capítulo 4. Solución Propuesta: En este capítulo se presenta la solución propuesta para el problema planteado en el capítulo anterior: CMS-SOM, un sistema inteligente que, al ser consultado a través de la Web, genera y muestra mapas donde se puede identificar con facilidad, de entre un grupo predeterminado de vendedores de CMS, cuáles son los que más se aproximan a los requerimientos efectuados. Debido a que este capítulo constituye la parte más extensa del trabajo, se lo dividió en las siguientes secciones: 4.1. Los mapas autoorganizativos de Kohonen (SOM) 4.2. El desarrollo de un sistema SOM genérico 4.3. Una nueva lista de características descriptivas de los CMS 4.4. Elección de los CMS iniciales para CMS-SOM 4.5. Obtención de los datos de los CMS iniciales de CMS-SOM 4.6. Implementación de CMS-SOM Capítulo 5. Resultados Experimentales: Aquí se presentan y discuten los resultados experimentales utilizados para probar la validez de la solución propuesta. Capítulo 6. Conclusiones: En este capítulo se presentan los aportes del trabajo y las futuras líneas de investigación. Al final de la tesis se incluyen las referencias bibliográficas y los anexos

23 CAPÍTULO 2 ESTADO DEL ARTE Administración de contenidos Hasta hace poco tiempo atrás, administrar los contenidos de una organización era una actividad con un alto porcentaje de trabajo artesanal. En el caso de los contenidos para la Web, por ejemplo, el ciclo de publicación típico consistía en transmitirle contenidos al responsable del mantenimiento del sitio web para que realizara con ellos una página web nueva, por lo general en el lenguaje HTML (HyperText Markup Language), y luego la publicara, usualmente mediante el protocolo FTP (File Transfer Protocol). Todas las páginas antiguas que requirieran enlaces hacia la página nueva tenían que modificarse manualmente. Entre las debilidades del modelo anterior se destacan [Suh et al., 2002]: Cuellos de botella: a medida que crece el sitio web, al responsable de su mantenimiento se le va haciendo cada vez más difícil cumplir con los plazos establecidos para la publicación de los contenidos. Desactualización de los contenidos: muchas veces, la información que es válida por cierto tiempo permanece en línea incluso después de su vencimiento, haciendo que el sitio web contenga información contradictoria y pierda confiabilidad. Inconsistencias en el código subyacente: si las páginas web son realizadas por más de un responsable, es posible que - debido a sus hábitos de programación personales - aparezcan inconsistencias en la codificación en HTML del sitio. Degradación cualitativa: a medida que pasa el tiempo, los sitios web pueden ir perdiendo calidad, por ejemplo cuando hay enlaces externos 1 que dejan de funcionar, lo que resulta sumamente frustrante para los visitantes del sitio. Además, dado que redefinir la apariencia de un sitio web estático es sumamente costoso, la apariencia del sitio por lo general no se modifica nunca y consecuentemente se vuelve anticuada. Hoy en día, para la mayoría de las organizaciones, estas debilidades son inaceptables, y es por ello que se observa, desde mediados de la década de 1990, un continuo aumento en la adopción de administradores de contenidos o CMS (Content Management Systems). 1 Los enlaces externos apuntan hacia páginas ubicadas fuera del sitio y que usualmente dependen de terceros - 5 -

24 En general, los diferentes tipos de contenido pueden ser administrados siguiendo dos enfoques opuestos: "mediante sistemas que son vendidos por separado, y cuya interoperabilidad no es fácil de lograr, o mediante los llamados enterprise content management systems (ECMS), que combinan un CMS central con otras herramientas administrativas dirigidas a todo el espectro de contenidos que existen en la organización" [Robertson, 2003b, p. 3] Es oportuno destacar aquí que existe una gran confusión en el uso del término sistemas de administración de contenidos empresariales o ECMS, debido a que "los vendedores de sistemas de administración de imágenes (imaging), flujo de trabajo (workflow) o documentos, sistemas de administración de cambios, sistemas de administración del conocimiento (knowledge management), registros o portales, y sistemas para publicación en la Web, todos ellos utilizan la etiqueta ECMS, y lo hacen porque la ECM (administración de contenidos empresariales) está de moda" [Howard, 2003]. Generalmente, la denominación administrador de contenidos o CMS se aplica a los sistemas cuyo fin principal es la publicación de contenidos en la Web, ya que "administrar contenidos para la Web es el uso más común de los CMS" [Robertson, 2003b, p. 1]. Por ello, un administrador de contenidos o CMS se puede definir como: Un sistema que cubre la totalidad del ciclo de vida de las páginas de un sitio web, desde la provisión de herramientas para crear su contenido, abarcando su publicación y finalizando con su almacenamiento. Posee también la capacidad de administrar la estructura del sitio web, la apariencia de las páginas publicadas y la navegación proporcionada a los visitantes [idem]. Sin embargo, "en ciertos ámbitos, a estos sistemas se prefiere llamarlos sistemas de administración web (web management systems o WMS)" [idem]. Desde el punto de vista de los usuarios no técnicos (que son la mayoría), el funcionamiento de un CMS es algo relativamente simple: El CMS proporciona una manera no técnica y simple de actualizar los contenidos de un sitio web. Esto se realiza típicamente (pero no siempre) a través de una interfaz web que funciona de forma similar a Word. Basta apuntar y hacer clic, ingresar las palabras nuevas, y presionar "Guardar". El sitio web se actualiza instantáneamente. Igualmente fácil es agregar nuevas páginas, borrar páginas antiguas, o reestructurar el sitio web para ajustarlo a un nuevo modelo de negocio. El CMS también automatiza otras tareas, como aplicar el mismo diseño de página y apariencia a todo el sitio. También se generan automáticamente menús y otros elementos de navegación. Combinado con otras herramientas administrativas, le permite al usuario concentrarse en las palabras, y no en la tecnología [Robertson, 2003a]

25 Esto último es posible debido a que "en un CMS moderno se mantiene la estricta separación de los tres componentes básicos de la información: el contenido, la estructura y el diseño (layout)" [Röwekamp, 2001, p. 13]. El contenido se almacena, junto con sus metadatos (fecha de creación, de publicación, de expiración, autor, etc.), en un repositorio que "puede tener varias formas: una base de datos, un sistema de archivos, o una combinación de ambos. También puede ser un repositorio virtual: una interfaz a varias fuentes de datos" [Suh et al., 2002]. Para administrar la estructura de un sitio web, es decir, los enlaces (links) internos y la navegación entre las páginas, "el CMS mantiene un glosario interno de códigos únicos de identificación de contenidos (IDs) o simplemente la jerarquía de archivos y carpetas del sitio (que puede ser una jerarquía lógica o física)" [idem]. El diseño, en cambio, está almacenado en "una colección de plantillas (templates) que contienen lugares reservados para llenar con el contenido proveniente del repositorio o, en algunos esquemas más potentes, código en línea para ser interpretado" [idem]. Con los tres componentes mencionados, el CMS genera entonces el documento para su publicación, generalmente en HTML, aunque "algunos CMS ofrecen mucho más, permitiendo publicar en diferentes formatos, incluyendo formatos para impresiones (PDF, Word, etc.), para portátiles wireless/hand-held (WAP, etc.) o XML" [Robertson, 2003b, p. 3]. La generación de los documentos puede realizarse en el momento en que éstos son solicitados o por anticipado. El primer enfoque se denomina Just-in-Time Publishing y es llevado a cabo por un Live Server. Debido al número relativamente elevado de recursos que requiere, "desde el punto de vista del desempeño y la escalabilidad de un sitio web, en poquísimos casos excepcionales representa una solución óptima" [Röwekamp, 2001, p. 14]. Ejemplos en los que este tipo de publicación es aplicable son las páginas web que muestran datos bursátiles o deportivos en tiempo real. En cambio, la generación de documentos por anticipado, denominada Pregeneration Publishing y realizada por un Staging Server cada cierto tiempo predeterminado, "ofrece un mejor desempeño, aunque por lo general la regeneración de un sitio web demora bastante y no permite entregarle al usuario final datos realmente actuales" [idem]. A causa de esta última limitación, "en la práctica usualmente se utilizan modelos híbridos: los contenidos que no varían en el tiempo se generan por anticipado, y al momento de ser solicitados se combinan con los contenidos que requieren gran actualidad y que son obtenidos mediante generación Just-in-Time" [idem]

26 Adoptar un CMS para administrar los contenidos del sitio web de una organización trae muchos beneficios, entre los cuales pueden mencionarse: Reducción de costos: "Las empresas se han dado cuenta de que implementando un sistema de gestión de contenido web, pueden [...] asignar las tareas de publicación a los expertos en contenido [usuarios de negocio no técnicos], liberando al personal técnico para construir nuevas aplicaciones" [MS, 2004] Mejora cualitativa del sitio web: "La responsabilidad del contenido [...] en manos del usuario de negocio asegura que el contenido esté actualizado, mientras que [...] el control centralizado del diseño asegura que el mensaje sea consistente con los valores y el branding de la compañía, y hace que se trasmita una imagen profesional" [idem]. Automatización del flujo de trabajo: Dado que se puede definir por anticipado el momento en que se actualizará automáticamente el sitio web, "los cambios se pueden realizar tan pronto como se los necesite, de día o de noche" [Robertson, 2003a, p. 1] Trabajo colaborativo: "Varias personas pueden actualizar el sitio web, en lugar de restringir esta actividad a una sola persona (el webmaster). El CMS controla quién está haciendo qué, y evita potenciales confusiones" [idem] Reutilización del contenido: "Una página web (o incluso un único párrafo) puede aparecer en diferentes contextos, y el CMS administra automáticamente su publicación en las diferentes plataformas (por ejemplo: intranet e Internet) a partir de una única fuente de contenido (lo que se conoce como single-sourcing)" [Robertson, 2002, p. 2] Interoperabilidad: "Al estar basados en estándares de la industria, los CMS se integran fácilmente a los sistemas de negocio existentes" [ibidem, p. 3]. Escalabilidad: "Es cada vez más difícil encontrar personal que comprenda la tecnología y las particularidades de un sitio web en particular" [Suh et al., 2002]. Mediante la separación de contenido, estructura y diseño, los CMS permiten administrar eficientemente sitios web de gran tamaño. Control de versiones: "Un CMS lleva un registro de las versiones de cada página web, para controlar quién cambió qué y cuándo lo hizo" [Robertson, 2003b, p. 2] Además de los beneficios mencionados, "el mayor beneficio que un CMS puede proporcionar es soportar las metas y estrategias del negocio. Por ejemplo, el CMS puede ayudar a mejorar las ventas, incrementar la satisfacción de los usuarios, o asistir en la comunicación con el público" [ibidem, p. 1]

27 Por otro lado, el Information Architecture Institute (organización sin fines de lucro con miembros en más de 40 países) llevó a cabo en 2003 una encuesta para determinar los problemas que presenta la adopción de un CMS, cuyos resultados se muestran a continuación: Softw are comercial demasiado caro Necesidad de demasiada customización Migración de contenidos antiguos Proceso pobre para migrar contenidos antiguos Entrenamiento de autores y editores Insuficiente flexibilidad para el diseño existente Dificultad en la evaluación de los fabricantes Determinación de los requerimientos Estructuración de los metadatos Dificultad de integración con otros sistemas Demasiado tiempo para implementar el SW comercial Insuficiente customización Elevada complejidad del proyecto Elevada complejidad en su conjunto Diseño de un flujo de trabajo Flujo de trabajo no acorde a las necesidades Proceso pobre para edición de contenido Proceso pobre para publicación de contenido Funcionamiento distinto del promocionado Proceso pobre para administración de contenido Proceso pobre para creación de contenido Demasiado tiempo para implementar el SW propio Dificultad de enmarcado de texto Creación de un diseño basado en plantillas Mantenimiento del sistema Combinación de componentes en la páginas Mantenimiento del contenido Dificultad para agregar archivos de multimedia Falta de soporte de un requerimiento importante Falta de soporte de una tecnología importante Elevado costo del softw are hecho en casa Búsqueda de programadores capacitados Falta de soporte por el fabricante Diseño de componentes de contenido Búsqueda de diseñadores capacitados Requerimientos de softw are Creación de nuevos contenidos Creación de un cronograma de publicación Requerimientos de hardw are 0% 10% 20% 30% 40% 50% 60% Figura 1. Dificultades al adoptar un CMS [IAI, 2003] - 9 -

28 2.2. Proyecto para la adopción de un CMS La adopción de un CMS requiere de un proyecto que tenga como uno de sus objetivos principales la adquisición del sistema. Un proyecto se puede definir como "un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único" [PMI, 2004, p. 5]. Además, los proyectos "son realizados por personas, están restringidos por la limitación de los recursos, y son planificados, ejecutados y controlados" [ibidem, p. 6]. El Project Management Institute define la dirección de proyectos como: la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de inicio, planificación, ejecución, seguimiento y control, y cierre [ibidem, p. 8]. Los siguientes procesos de dirección constituyen un área de conocimiento llamada gestión de las adquisiciones del proyecto, y se requieren "para comprar o adquirir productos, servicios o resultados, así como para contratar procesos de dirección" [ibidem, p. 10]: Planificar las Compras y Adquisiciones: determinar qué comprar o adquirir, y cuándo y cómo hacerlo. Planificar la Contratación: documentar los requisitos de los productos, servicios y resultados, e identificar a los posibles vendedores. Solicitar Respuestas de Vendedores: obtener información, presupuestos, licitaciones, ofertas o propuestas, según corresponda. Selección de Vendedores: revisar ofertas, elegir entre posibles vendedores, y negociar un contrato por escrito con cada vendedor. Administración del Contrato: gestionar el contrato y la relación entre el comprador y el vendedor, revisar y documentar cuál es o fue el rendimiento de un vendedor a fin de establecer las acciones correctivas necesarias y proporcionar una base para relaciones futuras con el vendedor, gestionar cambios relacionados con el contrato y, cuando corresponda, gestionar la relación contractual con el comprador externo del proyecto. Cierre del Contrato: completar y aprobar cada contrato, incluida la resolución de cualquier tema abierto, y cerrar cada contrato aplicable al proyecto. [ibidem, p. 269]

29 Las entradas, las herramientas y técnicas, y las salidas de los procesos de la gestión de adquisiciones del proyecto se muestran en la figura siguiente: Figura 2. Descripción General de la Gestión de las Adquisiciones [PMI, 2004, p. 272]

30 Según el Project Management Institute, los procesos de la gestión de adquisiciones del proyecto siguen el diagrama de flujo que se muestra a continuación: Figura 3. Diagrama de Flujo de la Gestión de las Adquisiciones [PMI, 2004, p. 273]

31 Suh et al. [2002] destacan que "el proceso para analizar y comprar un CMS dependerá de la escala de las necesidades de la organización, así como el rango de productos que se evaluarán dependerá del presupuesto asignado para la administración de contenidos [...] Para una adquisición grande, los dueños del proceso serán las gerencias de IT o de marketing, [...] mientras que para un presupuesto reducido o requerimientos más simples, el dueño del proceso será el profesional web". Sin embargo, debido a que los procesos propuestos por el Project Management Institute son genéricos y aplicables a la adquisición de cualquier producto o servicio, la mayoría de la bibliografía sobre administración de contenidos propone gestionar la adquisición de un CMS a través de esos procesos u otros similares. Bob Boiko [2001] coincide con ello al afirmar que "el proceso de selección de un proveedor de CMS no es tan diferente de cualquier otro proceso de selección de proveedores, como para que requiera de métodos propios. La mayoría de lo que propongo es sentido común para quien tiene mucha experiencia con la selección de productos". Los ocho pasos que propone seguir son los siguientes: 1. Crear una breve descripción con los puntos principales del proyecto, que pueda incluirse en la correspondencia inicial con los proveedores y que sirva para orientar al comité de selección. 2. Sondear el mercado buscando los CMS que corresponden al perfil buscado. Debería obtenerse una lista con más de 10 y menos de 20 productos. 3. Realizar el primer corte de la lista de candidatos, seleccionando aquellos que merezcan consideración. No es necesario realizar un análisis demasiado exhaustivo. Utilizar una lista de entre 10 y 20 criterios con reglas de puntuación simples (rangos de puntaje cortos). La lista de candidatos luego del primer corte debería tener entre 5 y 10 CMS. 4. Establecer una lista completa de criterios de selección y un mecanismo de puntuación, darles forma de solicitud de propuesta y enviárselas a los proveedores que pasaron el primer corte. 5. Seleccionar un número pequeño de finalistas (entre 2 y 5), calificando para ello las respuestas a las solicitudes de propuesta. 6. Llevar a cabo encuentros con los finalistas y verificar sus referencias. 7. Pedirles a los finalistas que realicen una presentación o demostración de sus CMS. 8. Tomar la decisión final combinando los puntajes de las solicitudes de propuesta con los de las referencias y la presentación

32 Para evitar que el ganador del proceso de selección sea descartado "por cualquier razón", es necesario que, antes de comenzar, "todos estén de acuerdo con el proceso y con que gane el que resulte ganador" [Boiko, 2001]. Por ello, los mecanismos de puntuación deben definirse por anticipado, a fin de realizar una evaluación justa e imparcial. James Robertson [2002] sugiere una metodología formada por cinco pasos: 1. Identificar las metas de negocio que se alcanzarán al implementar el CMS, para lograr el consenso de los stakeholders (grupos de IT, unidades de negocio y usuarios finales) acerca de la necesidad del CMS. 2. Identificar los requerimientos de administración de contenidos de la organización, involucrando para ello a los stakeholders y utilizando métodos de investigación estructurados, para garantizar la obtención de una lista que sea manejable y suficiente. 3. Estructurar los requerimientos en categorías para facilitar su comprensión. 4. Obtener información sobre la (potencialmente) larga lista de CMS candidatos. Dos enfoques pueden ser útiles: enviarles a los proveedores solicitudes de propuesta, en base a las cuales ellos deberán ofrecer información detallada sobre cómo sus sistemas cumplirán con cada uno de los requerimientos, o enviarles escenarios con tareas importantes que se llevarán a cabo con el CMS, en base a los cuales los proveedores realizarán demostraciones. 5. Calificar los sistemas mediante un sistema de puntajes establecido antes de contactar a los proveedores (lo cual evita potenciales acusaciones de corrupción) y elegir el ganador. Esta metodología se diferencia de la anterior principalmente por ser menos detallada y por utilizar las solicitudes de propuesta y las demostraciones como pasos alternativos en lugar de consecutivos. La necesidad de obtener el consenso de los stakeholders y de garantizar la imparcialidad del proceso mediante la creación de los mecanismos de puntuación antes de contactar a los proveedores, es un concepto común a ambas metodologías. Bob Doyle [2004a] menciona 15 pasos para seleccionar un CMS, aunque aclara que "algunos son demasiado caros para ciertos presupuestos, pero al menos es interesante saber cuáles son los gastos que uno no puede afrontar; y otros requieren más tiempo de estudio del que se dispone, pero al menos es interesante saber qué es lo que uno se está salteando". Los 15 pasos propuestos son los siguientes: 1. Organizar el contenido. 2. Buscar información en la Web

33 3. Leer libros y artículos sobre el tema. 4. Contratar consultores neutrales. 5. Detectar las compañías que realizan publicidad en las revistas especializadas. 6. Leer reportes de los analistas de la industria. 7. Visitar demostraciones comerciales. 8. Contactar a los proveedores. 9. Contratar consultores específicos de los productos. 10. Identificar los requerimientos de administración de contenidos de la organización y enviar solicitudes de propuesta. 11. Utilizar demos para conocer los sistemas. 12. Realizar el primer corte para obtener una lista de dos a cinco productos como máximo. 13. Pedirles a los finalistas un prototipo de parte del sitio web realizado con sus CMS. 14. Pedirles a los finalistas una estimación del cronograma para la migración al CMS. 15. Seleccionar el CMS que será adquirido. A pesar del gran número de pasos, esta metodología no difiere sustancialmente de las anteriores, ya que los ocho pasos del 2 al 9 podrían englobarse bajo el título "Sondear el mercado en busca de CMS". En cuanto a las solicitudes de propuesta y las demostraciones (aquí denominadas "prototipos"), según esta metodología se trata de pasos consecutivos. Es interesante que no se mencione la utilización de ningún método de puntajes para evaluar los sistemas y seleccionar un ganador Métodos para la evaluación y selección de un CMS Al responder a las solicitudes de propuesta que contienen los requerimientos de administración de contenidos de la organización, los proveedores ofrecen información detallada sobre cómo sus CMS cumplirán con cada uno de los requerimientos. En base a esta información, es posible evaluar los CMS y compararlos entre sí, a fin de seleccionar el sistema ganador. A continuación, se describen algunos de los métodos utilizados más frecuentemente para realizar la evaluación y/o selección de software, y que, por lo tanto, se aplican también en el caso particular de los CMS

34 Suma y ponderación numéricas (NWS) Este método, que posee diferentes denominaciones como NWS (Numerical Weight and Sum) o LWA (Linear Weighted Attribute), "mide la calidad de un producto de software como la suma ponderada de sus atributos" [Anderson, 1990]. Es decir, Q i (la calidad del producto i) se define como: i n Q = W A j= 1 j ij donde W j es el peso del atributo j y A ij es el puntaje del atributo j para el producto i. Una vez obtenido el valor de Q de todos los productos, es posible ordenarlos para formar un ranking y seleccionar al ganador. Dujmovic [1996, p. 2] menciona tres limitaciones importantes de este método: 1. No es posible modelar requerimientos obligatorios. Aunque un atributo obligatorio A i valga cero, el valor de Q i no será cero. 2. La contribución del atributo A i al puntaje global está limitada a W i. La única consecuencia de la ausencia total del atributo A i (expresada como A i = 0) es la reducción del puntaje global en W i, lo que la mayoría de las veces no es significativo. 3. Cuando algunos atributos son más significativos que el resto (y esto se expresa mediante sus pesos), los atributos menos significativos puede tener una contribución al puntaje global uno o dos órdenes de magnitud menor que los atributos más significativos. Este hecho prácticamente limita el valor de n (la cantidad de atributos) Suma y ponderación cualitativas (QWS) Este método, cuya sigla proviene de la denominación en inglés "Qualitative Weight and Sum" [Scriven, 1991], utiliza símbolos como pesos, por ejemplo: E = esencial, * = extremadamente valioso, # = muy valioso, + = valioso, = marginalmente valioso y 0 = sin valor. La evaluación se realiza en tres pasos: 1. Construcción de la lista de atributos: Se establece una lista de atributos para los productos a evaluar. Luego se le otorga a cada uno de los atributos un peso de referencia máximo (en forma de símbolo). Se eliminan los atributos que obtienen el peso 0, pues se los considera irrelevantes. 2. Calificación de los atributos de cada producto: Se les asigna a los atributos de cada producto un símbolo que no puede exceder el peso de referencia máximo

35 correspondiente. Por ejemplo, si el peso de un atributo es #, se lo puede calificar como #, +, o 0, pero no *. Si un producto obtiene una calificación menor que E en algún atributo cuyo peso de referencia es E, el producto se elimina. Si todos los productos obtienen la misma calificación en algún atributo, el atributo se elimina. 3. Construcción del ranking: Para cada producto, se cuenta cuántos símbolos de cada tipo obtuvo, y según esos totales se ordenan los productos. A veces hace falta comparar más detalladamente algún par de productos. Por ejemplo: 3*, 4#, 2+ y 1 es sin duda mejor que 2*, 5#, 2+ y 1, pero no está claro, a priori, si es mejor que 2* y 8# Maximax (MM) Maximax [Anderson, 1990] es un modelo simple que no utiliza ponderación de atributos. Tiene complejidad de cómputo baja y emplea una cantidad de información pequeña, pero no proporciona un ranking único de los productos. Primero se identifica para cada producto el puntaje máximo obtenido (no importa en cuál de los atributos se obtuvo). Luego se ordenan los productos de acuerdo con los puntajes máximos encontrados en el primer paso. Este modelo es útil cuando es baja la variación entre los puntajes de los atributos para cada producto, ya que un bajo desempeño en un solo atributo no afectará la elección Eliminación por aspectos (EBA) En el caso de EBA (Elimination by aspects) [idem], el proceso comienza con el ordenamiento decreciente de los atributos según su importancia. Después, se establece un puntaje mínimo para cada atributo. A continuación, se eliminan los productos que no alcancen el puntaje mínimo para el primer atributo. Este paso se repite sucesivamente con los atributos siguientes. El proceso de eliminación termina cuando solamente quede un producto o cuando se hayan considerado todos los atributos. EBA tiene dos limitaciones importantes. Primero, varios productos pueden alcanzar los puntajes mínimos en todos los atributos (con distintos valores), pero el método no indica qué hacer en tales casos. En segundo lugar, debido a que la selección de un producto puede ocurrir antes de haber considerado todos los atributos, el producto elegido puede tener un puntaje menor que el mínimo aceptable en un atributo no considerado todavía

36 Ordenamiento lexicográfico (LO) El modelo de ordenamiento lexicográfico (Lexicographic Ordering) [Anderson, 1990] puede ser utilizado cuando uno o dos atributos son importantes, y los demás tienen poca o ninguna relevancia. El proceso comienza ordenando los atributos del más importante al menos importante. Después, los productos se ordenan en base al puntaje que cada uno obtuvo en el atributo más importante. Si un único producto tiene el mayor valor, se lo selecciona. Si dos o más productos tienen el mayor valor, se los ordena en base al atributo que sigue en importancia. El proceso continúa hasta que no haya más empates o se han considerado todos los atributos Agregación lógica de preferencias (LSP) LSP (Logic Scoring of Preferences) es "un modelo cuantitativo de decisión para la evaluación, comparación y selección de sistemas de hardware y software complejos, cuyo fundamento matemático es una lógica de preferencias continua" [Dujmovic, 1996, p. 1]. El funcionamiento de este modelo puede resumirse de la siguiente manera: 1. A partir del árbol de requerimientos, a cada atributo A i se le asocia una variable X i que deberá ser medida para cada producto a evaluar. 2. Luego, a cada variable X i se le aplica una función de criterio elemental G i, que producirá una preferencia elemental E i. Las preferencias elementales están normalizadas e indican el grado de satisfacción de los requerimientos del comprador, por ejemplo: E i = 0 % denota un requerimiento no satisfecho en absoluto, E i = 100 % denota la satisfacción total del requerimiento, y los valores intermedios denotan una satisfacción parcial. 3. Por medio de un proceso de agregación preparado previamente por los evaluadores, el cual estructura las preferencias elementales mediante operadores lógicos que permiten expresar simultaneidad, reemplazabilidad, etc., se calcula un valor numérico global para cada producto a evaluar, denominado "preferencia de calidad global del producto", que representa el grado de satisfacción de todos los requisitos involucrados y en base al cual es posible construir un ranking. Es interesante mencionar la existencia de "software estándar para automatizar los procesos del modelo LSP" [ibidem, p. 10]

37 2.4. Selección de CMS a través de la Web Varias organizaciones han colocado sistemas en la Web con el fin específico de facilitar la selección de un CMS. A continuación, se describen cuatro de estos sistemas CMS-Search La asociación internacional para la administración de contenidos de código abierto OSCOM, el sitio web CMS Review, la consultora holandesa Hartman Communicatie, la organización de profesionales de administración de contenidos CM Pros y el laboratorio de evaluación de CMS de la Universidad de Washington ischool lanzaron en 2003 un proyecto conjunto denominado CMSML (CMS Markup Language) orientado a proporcionar una lista abierta y gratuita de CMS, sus características y sus funciones principales. Bob Doyle, el editor del proyecto CMSML, reconoce que "algún programador podría tomar la información disponible e intentar generar un sistema de puntuación para varios CMS basándose en ella" [Gilbane, 2003, p. 7], pero recomienda, sin embargo, "que los usuarios serios sólo usen la información disponible como punto de partida para su propio proceso de evaluación y selección, y que trabajen con una consultora especializada en CMS o con el personal de IT de la propia empresa [...], ya que las herramientas de ese tipo no pueden elegir automáticamente el CMS ideal" [idem] Actualmente, ya es posible realizar una búsqueda en la base de datos del proyecto CMSML a través del sistema CMS Search 3. Sin embargo, este sistema es de dudosa utilidad, ya que presenta varios puntos débiles: Solamente dispone de una base de 73 CMS (ver Anexo A1) Muchas de las características deseadas en el CMS a encontrar se deben ingresar como texto, por lo que es difícil saber qué ingresar y con qué formato hacerlo (Fig. 4). No proporciona una explicación contextual de los términos que emplea. Lo único que ofrece es la posibilidad de consultar un glosario que se abre desde otra página (CMS Features). Su implementación está incompleta. Aunque las características referidas a la creación, administración y publicación del contenido aparecen entre los requerimientos posibles (Fig. 5), no hay manera de seleccionarlas. 2 Los sistemas descritos fueron analizados en enero de Actualmente, sus características pueden diferir de las expuestas aquí

38 Figura 4. Algunos de los datos que deben ingresarse como texto en CMS-Search

39 Figura 5. Características no seleccionables en CMS-Search

40 Por otro lado, CMS-Search se destaca porque su funcionamiento es muy sencillo. A modo de ejemplo, se muestra la selección de las características de un CMS gratuito basado en LAMP 4 (Fig. 6) y cómo, al hacer clic en Search, se obtiene una lista de 4 CMS (Fig. 7) Figura 6. Búsqueda de un CMS gratuito basado en LAMP en CMS-Search 4 LAMP es el acrónimo de Linux, Apache, MySQL y PHP

41 Figura 7. CMS gratuitos basados en LAMP mostrados por CMS-Search

42 Produktfinder La agencia alemana de publicidad FEiG & Partner, especializada desde hace más de una década en el rubro Internet / Proyectos Web, lanzó en 1999 el portal contentmanager.de, desde el cual es posible acceder a su sistema Produktfinder 5. El sistema es visualmente muy atractivo, pero al analizarlo cuidadosamente se le detectaron las siguientes debilidades: La única página que ofrece explicaciones contextuales es la página de inicio (Fig. 8) A través del enlace ENGLISH, que debería conducir hasta la versión en inglés de Produktfinder, se accede a la página de inicio del portal contentmanager.net (Fig. 9), lanzado en 2003 por FEiG & Partner. Desde allí, es necesario navegar hasta Product finder (Fig. 10), la versión en inglés de Produktfinder. El sistema Produktfinder original (en alemán) contiene información sobre un número mayor de CMS (ver Anexo A2) que el sistema Product finder. Por ese motivo, en esta tesis se analiza únicamente el sistema en alemán. Figura 8. Página de inicio de Produktfinder (en alemán)

43 Figura 9. Página de inicio del portal contentmanager.net Figura 10. Página de inicio de Product finder (en inglés)

44 El funcionamiento de Produktfinder es bastante simple. Existen 11 criterios de búsqueda. Los criterios de búsqueda se eligen mediante casillas de verificación (checkbox), y para algunos subcriterios la opción son los botones de exclusión mutua (radio buttons). En la página de inicio se afirma que "en base a los criterios de búsqueda que Ud. seleccione, Produktfinder le mostrará soluciones adecuadas para Ud.", pero, lamentablemente, a veces los criterios de búsqueda seleccionados provocan que Produktfinder no funcione de forma correcta, mostrando resultados que pueden llegar a inspirar cierta desconfianza, como lo demuestra el siguiente ejemplo: 1. Se selecciona la categoría CMS, que comprende 101 productos (Fig. 11) 2. Se selecciona el criterio Soporte de XML (Fig. 12) 3. Se seleccionan los subcriterios Importación y Exportación (Fig. 13) 4. Se obtiene un listado con 266 productos (Fig. 14) Lo sorprendente en este caso es que la cantidad de productos del listado obtenido (266) representa mucho más que el doble del número de productos comprendidos en la categoría seleccionada (101). Figura 11. Selección de la categoría CMS en Produktfinder

45 Figura 12. Selección del criterio Soporte de XML en Produktfinder

46 Figura 13. Selección de los subcriterios Importación y Exportación en Produktfinder Figura 14. Obtención de un listado de productos en Produktfinder

47 Evidentemente, al usar Produktfinder no es posible confiar en que las soluciones mostradas serán las más adecuadas según los requerimientos efectuados. A pesar de ello, para poder comparar este sistema con los demás, se muestra a continuación su comportamiento al realizar la búsqueda de un CMS gratuito basado en LAMP. El primer paso consiste en seleccionar la categoría CMS, luego el criterio Informaciones Básicas, y finalmente los subcriterios correspondientes al CMS buscado (Fig. 15). En el listado resultante aparecen 35 CMS (Fig. 16) Figura 15. Búsqueda de un CMS gratuito basado en LAMP en Produktfinder

48 Figura 16. CMS gratuitos basados en LAMP mostrados por Produktfinder

49 Content Management Overview Content Management Overview 6 es un desarrollo de Hartman Communicatie BV, una consultora neerlandesa independiente (no tiene relación con ningún vendedor de CMS). La seriedad de esta consultora se puede observar en la siguiente advertencia - hecha en el sitio web del sistema - sobre la utilidad del mismo: 'Content Management Overview' no es un reemplazo para la definición de los requerimientos de funcionalidad antes de la selección de una herramienta. La definición de lo que necesita una organización, cuáles son las prioridades y para qué se utilizará la herramienta sigue siendo una tarea importante que no puede ser reemplazada por el uso de este sistema. La administración de la información digitalizada es principalmente un proyecto de cambio organizacional que no puede ser logrado solamente con el uso de 'Content Management Overview'. No obstante, este sistema puede ser útil para la definición de una lista corta de sistemas según sus características. El sentido común al utilizar la información de 'Content Management Overview' siempre será una responsabilidad del usuario de esta información. En conjunto, los 174 productos descritos en este sistema (ver Anexo A3) corresponden a la denominada administración de contenidos empresariales (Enterprise Content Management), ya que sus funciones abarcan la administración de contenidos web, la administración de documentos, la administración de registros, la administración de flujos de trabajo, la edición y la administración del correo electrónico. El sistema de búsqueda avanzada de Content Management Overview es realmente muy sofisticado. Inicialmente, los 13 criterios aparecen sin seleccionar, y recién cuando éstos son seleccionados, se despliegan los controles que permiten elegir los subcriterios correspondientes (Fig. 17). Los controles disponibles en Content Management Overview son de tres tipos: Botones de exclusión mutua (radio buttons) para seleccionar los criterios y desplegar los subcriterios. Casillas de verificación (checkboxes) para seleccionar un subcriterio Menús desplegables (pull-down menus) para mostrar un grupo de subcriterios y seleccionar uno de ellos. El diseño utilizando menús desplegables es uno de los puntos débiles de este sistema, ya que impide la búsqueda de un CMS con dos características que estén presentes en un mismo menú (por ejemplo, un sistema que pueda trabajar con PHP y Perl sería imposible de buscar en Content Management Overview)

50 Figura 17. Despliegue de controles en Content Management Overview Otro punto débil de Content Management Overview es la incorrecta ubicación de las explicaciones contextuales, ya que éstas sólo están disponibles en las vistas de los productos, o sea que recién pueden consultarse después de haber efectuado una búsqueda (Fig. 18) Figura 18. Explicación contextual en Content Management Overview

51 Para ilustrar el funcionamiento de este sistema, se muestran a continuación la búsqueda de un CMS gratuito basado en LAMP y los 10 CMS encontrados (Fig. 19) Figura 19. Búsqueda de un CMS gratuito basado en LAMP en CM-Overview

52 CMS-Matrix Al contrario de otros sistemas similares, CMS-Matrix - The Content Management Comparison Tool 7 no es el desarrollo de un grupo independiente, sino del fabricante de uno de los CMS que son comparados por esta herramienta. En efecto, CMS-Matrix es un servicio de la empresa estadounidense Plain Black Corporation, los creadores de WebGUI. Considerando el número de CMS que puede comparar, CMS-Matrix es una fuente muy rica en información, ya que contiene las características de 873 CMS. Estas características están agrupadas en los siguientes 10 criterios: Requerimientos de sistema Seguridad Soporte Interoperabilidad Facilidad de uso Flexibilidad Administración Desempeño Aplicaciones integradas Comercio CMS-Matrix ofrece explicaciones contextuales emergentes (Fig. 20) para cada una de las características que pueden seleccionarse. Figura 20. Explicación contextual emergente en CMS-Matrix

53 La mayoría de las características se elige mediante casillas de verificación (checkboxes), aunque, desafortunadamente, algunas deben ingresarse como texto y el sistema no da indicaciones de cuáles son los valores posibles. Esta debilidad del sistema provoca que, por ejemplo, al realizar la búsqueda de un CMS gratuito basado en LAMP (Fig. 21), muchos CMS que cumplen con los criterios no sean encontrados. Figura 21. Búsqueda de un CMS gratuito basado en LAMP en CMS-Matrix

54 Otro inconveniente que se presenta en CMS-Matrix es que, si la búsqueda devuelve más de 10 resultados, el sistema no permite realizar la comparación entre ellos y, por lo tanto, no es posible acceder simultáneamente a los datos de los CMS. En el ejemplo anterior, la búsqueda arrojó como resultado los nombres de 55 CMS (en la figura sólo se ven los primeros cuatro)

55 CAPÍTULO 3 PLANTEO DEL PROBLEMA 3 Como se vio en el capítulo anterior (sección 2.2), en cualquier proyecto dirigido a la adopción de un CMS existen procesos de dirección pertenecientes al área de conocimiento que el Project Management Institute denomina gestión de las adquisiciones del proyecto, y que se requieren para llevar a cabo la compra o adquisición del CMS. Uno de estos procesos es la Planificación de la Contratación, entre cuyos subprocesos se encuentra la identificación de los posibles vendedores para solicitarles información detallada sobre sus productos (a través del proceso denominado Solicitar Respuestas de Vendedores) que sirva de base, posteriormente, para realizar la selección del CMS que mejor cumple con los requerimientos de la organización (mediante el proceso denominado Selección de Vendedores). En la práctica, la identificación de los posibles vendedores se reduce a obtener una lista que contenga los nombres de 10 a 20 posibles vendedores como recomienda Boiko [2001] o de 2 a 5 posibles vendedores como sugiere Doyle [2004a]. Los responsables de llevar a cabo la identificación de los posibles vendedores encuentran dos serias dificultades: Deben llegar a un número relativamente pequeño de sistemas partiendo de un conjunto inicial formado por los CMS existentes en el mercado. El número de CMS que aparecen en los principales directorios de la Web varía enormemente, pero "después de copiar y pegar los listados, y de filtrarlos para eliminar la redundancia, es posible obtener los nombres de cerca de 1800 CMS" [Doyle, 2005]. La cantidad de propiedades que caracterizan a un CMS es problemática, ya que su número también es elevado. Por ejemplo, los responsables del proyecto CMSML (ya presentado en la sección del Estado del Arte) afirman que su listado posee 125 características

56 Considerando el objetivo y los factores mencionados, el problema que se propone resolver en esta tesis puede ser enunciado de la siguiente manera: Dados: A: un conjunto de n CMS (Administradores de Contenidos), cada uno representado por sus c características presentes o ausentes (Fig. 22) Figura 22. A: un conjunto de n CMS R: una lista de requerimientos representada por (como máximo) c características, como se muestra en la figura 23. Figura 23. R: una lista de requerimientos (c características como máximo) Se desea ordenar los n CMS pertenecientes al conjunto A de forma tal que sea posible identificar fácilmente aquellos que, por tener una mayor afinidad con los requerimientos de R, serían los más apropiados para participar de un proceso de selección posterior

57 Los siguientes métodos, ya descritos en el capítulo anterior, podrían aplicarse para obtener una lista ordenada de vendedores (y al tope de la misma, consecuentemente, los CMS que mejor cumplen con los requerimientos): Suma y ponderación numéricas (NWS) Suma y ponderación cualitativas (QWS) Maximax (MM) Eliminación por aspectos (EBA) Ordenamiento lexicográfico (LO) Agregación lógica de preferencias (LSP) Sin embargo, debido a que en el caso de los CMS los atributos a ponderar son tan numerosos, estos métodos no funcionarán correctamente por las limitaciones ya mencionadas en la sección 2.3 del Estado del Arte. Tampoco los sistemas que varias organizaciones han colocado en la Web con el fin específico de facilitar la selección de un CMS, y que ya han sido descritos en el capítulo anterior, permiten resolver satisfactoriamente el problema. Algunas de las dificultades que se presentan son: Fallas en el diseño de la interfaz: los requerimientos deben ingresarse como texto, por lo que es difícil saber qué ingresar y con qué formato hacerlo, o se utilizan controles inadecuados (por ejemplo, menús desplegables que impiden elegir dos de las opciones mostradas) Ingreso y edición de datos sin moderador: Si los visitantes de la página web de un sistema pueden ingresar y/o modificar los datos de los CMS, la información pierde confiabilidad. Esto explica por qué los sistemas no moderados contienen los datos de más de 800 CMS, mientras que los sistemas con moderador sólo contienen los datos de menos de 200 CMS. Especificación estricta de requerimientos: Los controles que sólo permiten elegir entre dos estados (sí/no), provocan que sean descartados los CMS que no cumplen todos los requerimientos, con lo cual, a veces, la búsqueda no arroja resultados. En tales casos, podría ser mejor para los usuarios obtener los resultados que más se acerquen a sus requerimientos, aunque no los cumplan completamente. Imposibilidad de comparar los resultados: En algunos sistemas, no es posible comparar las características de los CMS que cumplen con los requerimientos de los usuarios, lo que dificulta la posterior selección

58 Por lo tanto, la solución buscada sólo se puede obtener mediante un enfoque diferente de los convencionales. En el próximo capítulo se presenta un Sistema Inteligente que resuelve satisfactoriamente el problema planteado

59 CAPÍTULO 4 SOLUCIÓN PROPUESTA 4 La identificación de los posibles vendedores, uno de los primeros pasos en un proyecto orientado a la adopción de un CMS, no es un problema trivial. Como los métodos convencionales - debido al gran número de características que definen a los CMS - son difíciles de llevar a la práctica y no entregan resultados confiables (en particular, los sistemas de ponderación no funcionan correctamente cuando los atributos a ponderar son tan numerosos, y los sistemas accesibles a través de la Web que fueron estudiados presentan serias restricciones), en esta tesis se propone resolver el problema planteado mediante un Sistema Inteligente cuyo núcleo esté constituido por una red neuronal. Las redes neuronales son un modelo computacional basado en unas "unidades de procesamiento sorprendentemente simples" [Dayhoff, 1990, p. 1] denominadas neuronas artificiales, interconectadas y funcionando en paralelo. Antes de llegar a la solución definitiva para el problema planteado en el capítulo anterior, se estudiaron y descartaron dos modelos neuronales. Primero, se intentó resolver el problema mediante un perceptrón multicapa (MLP o Multi-Layer Perceptron). Este tipo de red neuronal está compuesto de neuronas con conexiones hacia adelante (feedforward) entre capas vecinas, formando una capa de entrada, una o más capas ocultas y una capa de salida. Mediante un algoritmo conocido como back-error propagation (propagación del error hacia atrás), es posible ajustar los pesos de las conexiones para que la red aprenda la asociación que existe entre un patrón presentado a la entrada y otro patrón esperado a la salida, usando aprendizaje supervisado. Los detalles de este modelo pueden encontrarse en [Dayhoff, 1990], [Hilera, J. y Martínez, V., 1995], [Welstead, 1994] o en los demás libros sobre el tema mencionados en la bibliografía. La red tendría c neuronas de entrada y n neuronas de salida, es decir, cada neurona de entrada representaría una característica, y cada neurona de salida representaría un CMS. Se entrenaría la red para asociar el conjunto de c características de cada CMS con un patrón de salida compuesto por un 1 en la neurona del CMS correspondiente y 0 en todas las demás. En la figura 24 puede verse un ejemplo donde la red ya entrenada, cuando recibe en la capa de entrada las características del CMS Nº 3, responde a la salida con un valor cercano a 1 en la neurona Nº 3 y con valores cercanos a 0 en todas las demás

60 Figura 24. Perceptrón multicapa en funcionamiento Este primer intento estuvo guiado por la hipótesis (que no se llegó a demostrar) de que los valores en la capa de salida indicarían el grado de afinidad que las características presentadas en la capa de entrada tendrían con cada uno de los CMS. Por lo tanto, si se le presentara a la red una lista de características diferente de las características de los CMS con que fue entrenada, los valores que surgieran en la capa de salida podrían ordenarse en forma descendente y los CMS que quedaran al tope de la lista serían aquellos cuyas características fueran más parecidas a las características ingresadas. El modelo mencionado se descartó porque fue imposible, tras varias horas de entrenamiento, que la red aprendiera a asociar las características de cada uno de los CMS con las salidas correspondientes (eran 400 características por cada uno de los 160 CMS). El segundo intento estaría basado en una red ART1. Esta red compara los patrones que se le presentan con los prototipos que tiene almacenados. Si no hay suficiente similitud, crea un nuevo prototipo, de lo contrario, ajusta el prototipo para que mantenga la similitud con los patrones de la misma clase. En la figura 25 se muestra cómo luego de crear prototipos para el 2, el 3 y el 8, ante la llegada de un 8 distorsionado que es reconocido como 8, el prototipo se ajusta para parecerse a ambos (al 8 y al 8 distorsionado). Los detalles de este modelo pueden encontrarse en [Hilera, J. y Martínez, V., 1995] o en los otros libros de la bibliografía. Al sistema se le presentarían primero los requerimientos del usuario y luego sucesivamente las características de cada uno de los CMS considerados. Para los CMS cuyas características no fueran parecidas a los requerimientos, la red crearía nuevos prototipos, pero los que sí fueran parecidos serían reconocidos y quedarían asociados al primer prototipo. Este modelo fue descartado porque durante su estudio se encontró un paper [Mogharreban, 2006] donde se utilizan las redes ART con un objetivo similar al de esta tesis

61 Figura 25. Red ART1 en funcionamiento [Hilera, J. y Martínez, V., 1995, p.245] Finalmente, se desarrolló CMS-SOM, un sistema con las siguientes características: Es un Sistema Inteligente (utiliza mapas autoorganizativos de Kohonen) Es accesible a través de la Web mediante un navegador (browser) Trabaja con datos de CMS guardados en un fichero escrito en XML. Está formado por Java servlets, que generan dinámicamente las páginas que se ven en el navegador (browser), a partir de los datos ingresados por el usuario, de los datos del fichero en XML y de los cálculos que se realizan. Es de fácil uso: el usuario ingresa sus requerimientos y recibe un mapa donde se encuentran distribuidos, en un panal de celdas hexagonales, los CMS y una leyenda representando los requerimientos ingresados. Cuanto más cerca de un CMS aparezca la leyenda, mayor será la aptitud de éste. Ofrece una tabla completa de las características de los CMS, para su comparación. Muestra explicaciones contextuales de todos los requerimientos efectuables. Sólo permite que sea el administrador quien modifique los datos de los CMS. Utiliza solamente botones de exclusión mutua (radio buttons), por lo que nunca es necesario ingresar textos. Permite especificar requerimientos de 5 tipos: "obligatoriamente NO", "preferentemente NO", "indistinto", "preferentemente SÍ" y "obligatoriamente SÍ"

62 4.1. Los mapas autoorganizativos de Kohonen (SOM) La aplicación web CMS-SOM se encuadra dentro de los Sistemas Inteligentes porque utiliza mapas autoorganizativos de Kohonen (SOM 9 ), que son un tipo de red neuronal. Los mapas autoorganizativos, desarrollados por Teuvo Kohonen durante la década de 1980 en la Universidad Tecnológica de Helsinki, se destacan porque "de entre todos los modelos de red neuronal, probablemente sea el que mejor modela lo que ocurre realmente en el cerebro" [Welstead, 1994, p. 344]. Sin embargo, hoy en día las redes neuronales artificiales solamente tienen una importancia marginal como modelo de funcionamiento del cerebro humano, ya que son "consideradas estrictamente como interesantes y útiles dispositivos de ingeniería" [Nilsson, 1998, p. 37]. Una aplicación práctica de los mapas autoorganizativos de Kohonen es "encontrar categorías (clusters) en la información de entrada y que luego un vector de datos desconocido sea identificado con una de las categorías" [Kohonen et al., 1996, p. 3]. Eso es precisamente lo que hace la aplicación web CMS-SOM Arquitectura En comparación con otros tipos de redes neuronales, la arquitectura de SOM es extremadamente sencilla. En este modelo, la red neuronal está formada solamente por dos capas (Fig. 26): Capa de entrada: Es la capa en la que se le presenta a la red la información de entrada contenida en un vector x = [ξ 1, ξ 2,...,ξ n ] R n. Capa de salida: Es la capa donde la red neuronal muestra su respuesta ante la presentación de cierta entrada. Las neuronas de esta capa forman un arreglo de forma "rectangular, hexagonal, o incluso irregular, siendo el formato hexagonal el visualmente más efectivo" [Kohonen, 2001, p. 110]. Cada neurona i de esta capa tiene asociado un vector modelo mi = [µ i1, µ i2,.., µ in ] R n (gráficamente, el valor µ se representaría una conexión entre una neurona e de entrada y una neurona s de salida). 9 SOM es el acrónimo de Self-Organizing Map

63 Figura 26. Arquitectura de la red neuronal SOM [Hilera, J. y Martínez, V., 1995, p.256] Funcionamiento El objetivo de la red neuronal SOM es que, al recibir un vector con la información de entrada, éste sea procesado y, como respuesta, se obtenga cuál es la neurona de salida que corresponde al vector ingresado. Según Kohonen [2001, p. 110], "la magnitud exacta de la respuesta no precisa ser calculada: la entrada simplemente es mapeada en esa ubicación". El procesamiento que ocurre con el vector de entrada x para determinar cuál es c, la neurona con la que se lo debe mapear como respuesta, "es una tarea trivial si la red neuronal es simulada mediante un programa de computadora" [idem]. Lo que se realiza es la comparación del vector de entrada x con los vectores modelo mi de todas neuronas de salida i, mediante alguna métrica, y c es la neurona i que mejor resulta en la comparación. Usualmente, la métrica que se utiliza para comparar el vector de entrada x con los vectores modelo mi es el valor mínimo de las distancias euclídeas x - mi, por lo que la neurona c es la que satisface la siguiente igualdad [idem]: x mc = min i { x m } La fórmula de la distancia euclídea es la que se muestra a continuación, aunque también "suele utilizarse la expresión eliminando la raíz cuadrada" [Hilera, J. y Martínez, V., 1995, p. 260]: x m i = ( x m ) j j i 2 ij

64 Aprendizaje En las redes SOM, la etapa de funcionamiento, que es cuando se le presenta a la red neuronal un vector de entrada x para que lo mapee a una neurona de salida c, ocurre luego de haber finalizado la etapa de aprendizaje, que es cuando se ajustan los valores de los vectores modelo mi. Por ello, "el aprendizaje en el modelo de Kohonen es de tipo OFF LINE" [Hilera, J. y Martínez, V., 1995, p. 258]. Otra característica de este modelo es que utiliza un aprendizaje no supervisado. A la red neuronal SOM "sólo se le proveen valores de entrada, y se le requiere que les dé sentido según su propio criterio" [Welstead, 1994, p. 344]. El algoritmo de aprendizaje de SOM es "computacionalmente muy liviano" [Kohonen, 2001, p. 112], y consta de los siguientes pasos [Hilera, J. y Martínez, V., 1995, p ]: 1. Se inicializan los vectores modelo mi con valores aleatorios (por ejemplo, con valores reales entre -1 y 1), y se fijan los valores de los tres parámetros de aprendizaje: Número de iteraciones para los pasos Factor de aprendizaje α 11 Radio de la zona de vecindad. La zona de vecindad N c abarca la neurona c y las neuronas de salida ubicadas alrededor de ella. El radio debe ir disminuyendo a medida que avanza el aprendizaje (Fig. 27). Figura 27. Vecindad topológica [Kohonen, 2001, p. 111] 10 Los pasos se deben repetir "un número razonablemente grande de veces [...] Típicamente, se han usado iteraciones en nuestras simulaciones, pero para un aprendizaje rápido [...] iteraciones o menos pueden ser suficientes" [Kohonen, 2001, p. 112] 11 "Por aproximadamente 1000 iteraciones, α debe tener valores razonablemente altos (cercanos a la unidad) [...] luego del periodo inicial de ordenamiento, debería mantenerse en valores pequeños (del orden de 0.02 o menores) [idem]

65 2. A continuación se presenta a la red una información de entrada (la que debe aprender) en forma de vector x = [ξ 1, ξ 2,...,ξ n ] R n. 3. Puesto que se trata de un aprendizaje competitivo, se determina c, la neurona vencedora de la capa de salida. 4. Una vez localizada c, la neurona vencedora, se actualizan los vectores modelo mi aplicando la siguiente fórmula, donde t = 0, 1, 2,... es un entero, el número de la iteración: m i ( t + ) = m ( t) + α( t) [ x( t) m ( t) ] 1 para i N c (t) i i Los ajustes realizados en el último paso "hacen que la neurona ganadora y sus vecinas se vuelvan más parecidas al vector de entrada x. De esta forma, la neurona ganadora tendrá más probabilidades de ganar la próxima vez que se presente el mismo vector de entrada u otro similar" [Dayhoff, 1990, p. 167] Un ejemplo clásico En el siguiente ejemplo (Tabla 1), los vectores binarios con las descripciones de 16 animales, basadas en la presencia (= 1) o ausencia (= 0) de los 13 atributos de la izquierda, se mapean en las neuronas de un mapa autoorganizativo (SOM) de 6 filas y 7 columnas (Fig. 28). es tiene le gusta d o v e h e n d u c k g o o s e o w l h a w k e a g l e pequeño mediano grande patas patas pelo pezuñas melena plumas cazar correr volar nadar f o x d o g w o l f c a t t i g e r l i o n h o r s e z e b r a c o w Tabla 1. Características de los 16 animales a mostrar en un SOM [Kohonen, 2001, p. 164]

66 Figura 28. SOM mostrando los 16 animales 12 [Kaski, Nikkilä y Kohonen, 1998, p. 2] Kohonen [2001, p ] señala que "el orden espacial de las respuestas ha capturado las 'relaciones de familia' entre los animales". En efecto, las neuronas correspondientes a las aves ocupan la parte izquierda del mapa, los cazadores como el tigre, el león y el gato aparecen en el centro, mientras que las especies más pacíficas como la cebra, el caballo y la vaca se sitúan arriba a la derecha Desarrollo de un sistema SOM genérico Para desarrollar un sistema SOM genérico que luego sirva de base para CMS-SOM, fue necesario elegir el paradigma de la ingeniería del software que se seguiría. Un paradigma de la ingeniería del software (también conocido como modelo de procesos de software) se puede definir como "una estrategia de desarrollo que abarca procesos, métodos y herramientas, y se elige de acuerdo a la naturaleza del proyecto y la aplicación, los métodos y herramientas a utilizar, y los controles y entregables requeridos" [Pressman, 2001, p. 26]. En un primer momento, porque son muy conocidos y existe abundante bibliografía sobre ellos, pareció prudente que la elección recayera sobre alguno de los siguientes paradigmas descritos por Carlos Fontela [2003, p ]: 12 dove=paloma / hen=gallina / duck=pato / goose=ganso / owl=lechuza / hawk=halcón /eagle=águila fox=zorro / dog=perro / wolf=lobo / cat=gato / tiger=tigre / lion=león / horse=caballo / zebra=cebra / cow=vaca

67 Desarrollo en cascada (Ciclo de vida tradicional del software) Desarrollo en espiral Desarrollo con prototipos completos El Proceso Unificado de Desarrollo del Software XP (Extreme Programming) Sin embargo, la gran difusión que tienen estos paradigmas no es un argumento suficientemente fuerte como para justificar su adopción. James Senn [1992, p. 47] incluso llegó a afirmar: No existe 'el método correcto' para desarrollar un sistema de información, pero sí existen diferentes formas para producir 'el sistema correcto' para una aplicación. En la comunidad empresarial existen muchas variaciones de los métodos expuestos anteriormente. Algunos métodos tienen más éxito que otros y esto depende de cuándo se emplean, cómo se aplican y de los participantes en el proceso de desarrollo. En ciertas ocasiones el único método adecuado será un enfoque paso a paso, comparable con el ciclo de vida de desarrollo de un sistema. En otros casos, el desarrollo de prototipos es el único método que tiene sentido. En otras situaciones se combinan los métodos [...] El indicador definitivo del éxito de un método de desarrollo es aquel que se refiere a los resultados obtenidos y no a la "precisión" teórica del método. Entonces, por ser un término medio entre comenzar a programar directamente sin ninguna planificación previa 13 y los complejos procesos de análisis y diseño que incluyen cientos de páginas de documentación, para el desarrollo de un sistema SOM genérico se eligió seguir la metodología de desarrollo orientado a objetos para proyectos pequeños propuesta por Carlos Fontela [2003, p ], la cual consta de las siguientes etapas: a. Describir el proyecto en una o dos oraciones. b. Determinar los requerimientos del usuario y chequearlos con el mismo. Esto es mejor si se hace en sesiones de 'brainstorming' informales. También se debe determinar si es posible realizar el sistema, cuánto va a llevar en tiempo y dinero, quién lo va a usar, qué van a hacer los usuarios con el sistema, cómo lo van a hacer, etc. En este nivel, debe evitarse entrar en detalles demasiado precisos. c. Hacer un diseño que describa las clases que se van a utilizar y sus interacciones, con sus responsabilidades y colaboraciones con otras. Se pueden usar tarjetas CRC para esto. La clase típica debe entenderse muy fácilmente: si no es así, habría que plantearse si no se puede refactorizar en más de una clase. Siempre hay que considerar las opciones y elegir la más simple. d. Construir el núcleo ejecutable de la aplicación, con una funcionalidad mínima, como un marco alrededor del cual se va a armar el conjunto. 13 Es lo que propone el modelo code-and-fix (codificar y corregir), que "es un modelo poco útil pero bastante común" [McConnell, 1996, p. 140]

68 e. Trabajar con el cliente, e implementar antes los casos de uso que éste priorice. f. Agregar, en múltiple iteraciones, pequeños proyectos que incorporen un caso de uso por vez. Cada iteración se dividirá en tareas pequeñas que serán responsabilidad de un programador o una pareja, que deberá hacer el diseño detallado, programación, prueba unitaria e integración. Las pruebas se escribirán antes que el código probado y servirán como comunicación del equipo de trabajo. g. Guardar el código de todas las pruebas, unitarias y funcionales, asegurando que siempre se ejecutan sin problemas. h. Refactorizar a menudo, manteniendo la simplicidad al máximo. i. Una vez que se termina el desarrollo, evolucionar el sistema de uno que funciona bien a uno mejor aún. Recién en este momento conviene agregar optimizaciones de código, capacidades multiplataforma, etc. De todos modos, debido a la naturaleza del proyecto (el equipo de trabajo estuvo formado por una única persona, que actuó simultáneamente como cliente y como desarrollador) algunas características de esta metodología no fueron aprovechadas (por ejemplo, la utilización de las pruebas para la comunicación del equipo de trabajo). A continuación, se describen las etapas que fueron llevadas a cabo Requisitos para el sistema SOM genérico La captura de requisitos "es el proceso de averiguar, normalmente en circunstancias difíciles, lo que se debe construir. De hecho, es tan difícil que todavía no es poco común para los equipos de proyecto el comenzar a escribir código (lo cual es bastante fácil) antes de que hayan firmado simplemente lo que se supone que debe hacer el código (lo cual es difícil de determinar)" [Jacobson, Booch y Rumbaugh, 2000, p ] Como requisitos funcionales 14, se estableció que el sistema SOM genérico: 1. Debería permitirle al usuario elegir sin dificultad las características que considera deseables en el elemento buscado, mostrando explicaciones contextuales de todas las características que se pueden elegir, para que el usuario estuviera informado del significado de las distintas opciones. 2. Debería analizar los datos de todos los elementos considerados, y mostrarlos dispuestos en un mapa SOM, para poder visualizar cuáles son los más adecuados según sus características, las cuales, a su vez, también deberían poder compararse. 14 Requisito que especifica una acción que debe ser capaz de realizar el sistema, sin considerar restricciones físicas; requisito que especifica comportamiento de entrada/salida de un sistema. [ibidem, p. 432]

69 Entre los requisitos no funcionales 15 para el sistema SOM genérico, se estableció que: 3. Debería ser accesible a través de la Web mediante un navegador (browser). 4. Debería trabajar con datos guardados en un fichero escrito en XML (Extensible Markup Language), lo que facilitaría su procesamiento (lectura, edición, etc.) y permitiría además que, al cambiar el fichero, el sistema SOM genérico se pudiera orientar a la selección de cualquier tipo de elementos (no específicamente CMS). 5. Debería estar formado por Java servlets 16, para generar dinámicamente las páginas que se ven en el navegador (browser), a partir de los datos ingresados por el usuario, de los datos del fichero en XML y de los cálculos realizados. 6. Debería emplear HTML de acuerdo con los estándares del Consorcio World Wide Web (W3C). 7. Debería emplear hojas de estilo CSS (Cascade Style Sheets) para definir el formato de los distintos elementos de las páginas web. 8. Debería permitir que sólo el administrador modificara los datos de los elementos Diseño del sistema SOM genérico El objetivo del diseño es "modelar el sistema y encontrar su forma (incluida la arquitectura) para que soporte todos los requisitos - incluyendo los requisitos no funcionales y otras restricciones - que se le suponen" [Jacobson, Booch y Rumbaugh, 2000, p. 205] El diseño "captura los requisitos o subsistemas individuales, interfaces y clases, creando una entrada apropiada y un punto de partida para actividades de implementación subsiguientes" [idem]. El sistema SOM genérico está formado por una página de inicio (una página web estática que utiliza una hoja de estilo CSS y diversas imágenes), un fichero XML (los datos del sistema) y las cinco clases que se muestran en el diagrama de clases de la figura Requisito que especifica propiedades del sistema, como restricciones del entorno o de implementación, rendimiento, dependencias de la plataforma, mantenibilidad, extensibilidad o fiabilidad [Jacobson, Booch y Rumbaugh, 2000, p. 432] 16 Un Java servlet es un objeto que corre en un contenedor de servlets. (por ejemplo: Tomcat). La función básica de un servlet es recibir solicitudes y generar respuestas en base a esas solicitudes. Para ello, el contenedor de servlets crea objetos del tipo HttpServletRequest y HttpServletResponse (los cuales contienen la información de la página que invocó al servlet) y se los pasa como argumentos a ciertos métodos del servlet (doget, dopost, etc)

70 Figura 29. Diagrama de clases del sistema SOM genérico El diagrama de secuencia que se ve a continuación muestra como interactúan los objetos de diseño, desde que el usuario solicita la página de inicio, hasta que obtiene las tablas con las características procesadas durante el funcionamiento del sistema (Fig. 30):

71 Figura 30. Diagrama de secuencia del sistema SOM genérico

72 El diagrama de secuencia mostrado podría describirse así: 1. El usuario, a través de un navegador (browser) solicita la página de inicio del sistema, y el servidor web se la entrega. 2. El usuario, luego de leer la página de inicio del sistema, solicita el formulario de entrada de datos (a ser generado por FormularioServlet). En la solicitud se incluye, como un parámetro oculto, el nombre del fichero XML que contiene la información sobre los elementos a comparar FormularioServlet le solicita a XMLTable los datos del fichero XML, y XMLTable se los entrega. FormularioServlet genera una página web con el formulario y se la entrega al usuario. 3. El usuario llena el formulario y solicita su procesamiento (a ser realizado por RedNeuronalServlet) RedNeuronalServlet le solicita a XMLTable los datos del fichero XML, y XMLTable se los entrega RedNeuronalServlet le solicita a Kohonen un mapa SOM basado en los datos ingresados por el usuario y los datos obtenidos del fichero XML, y Kohonen lo construye y se lo entrega 18. RedNeuronalServlet genera una página web con el mapa SOM y se la entrega al usuario. 4. El usuario solicita las tablas con los datos utilizados para construir el SOM (a ser generadas por TablasServlet) TablasServlet le solicita a XMLTable los datos del fichero XML, y XMLTable se los entrega. TablasServlet genera una página web con las tablas de los datos utilizados para construir el mapa SOM y se la entrega al usuario. 17 De esta forma, reemplazando la página de inicio original por otra que incluya como parámetro oculto el nombre de un fichero XML diferente, el sistema se podría configurar para que permita comparar otro tipo de elementos, o quizá disponibilizarlo en otro idioma. 18 En realidad, si el usuario no selecciona todas las características posibles, RedNeuronalServlet le solicitará a Kohonen dos mapas SOM: uno considerando todas las características posibles y otro considerando sólo las características requeridas por el usuario

73 Además de las clases mencionadas anteriormente, se diseñó la estructura del fichero de datos del sistema. Para ello se utilizó XML, ya que actualmente es "el lenguaje estándar de intercambio de información más popular" [Fontela, 2003, p. 201] Fontela [idem] menciona dos formas distintas de utilizar XML, ejemplificadas mediante los dos casos siguientes en que el propósito es guardar el número de legajo, apellido, nombre y fecha de nacimiento de un empleado: <Empleado legajo="54811" apellido="fernández" nombre="juan"> </Empleado> <fecha_nacimiento dia="22" mes="12" anio="1973" /> Figura 31. Representación de un registro en XML <Empleado> <legajo> </legajo> <apellido> Fernández </apellido> <nombre> Juan </nombre> <fecha_nacimiento> <dia> 22 </dia> <mes> 12 </mes> <anio> 1973 </anio> </fecha_nacimiento> </Empleado> Figura 32. Otra representación de un registro en XML En la primera forma de representación (Fig. 31), se utilizan varias características del lenguaje XML: Empleado es un elemento con contenido (el elemento fecha_nacimiento). fecha_nacimiento es un elemento sin contenido (el cierre se hace al final de la misma etiqueta). Los datos propiamente dichos sólo aparecen como atributos de los elementos. En la segunda variante (Fig. 32), todos los elementos tienen contenido (otros elementos o los datos propiamente dichos), y ningún elemento tiene atributos. Para el sistema SOM genérico, se utilizó la segunda forma de representación. El diseño de su fichero de datos en XML se muestra en la figura 33:

74 <?xml version="1.0" encoding="iso "?> <lista> <configuraciones> <csimayu> 1 </csimayu> <csiminu> 2 </csiminu> <cnomayu> 3 </cnomayu> <cnominu> 4 </cnominu> <spuntaje> 5 </spuntaje> <sestilo> 6 </sestilo> <stitle> 7 </stitle> <sencabezado> 8 </sencabezado> <soblno> 9 </soblno> <sprefno> 10 </sprefno> <sindistinto> 11 </sindistinto> <sprefsi> 12 </sprefsi> <soblsi> 13 </soblsi> <svolver> 14 </svolver> <sprocesar> 15 </sprocesar> <susrequerimientos> 16 </susrequerimientos> <sarchivoimg> 17 </sarchivoimg> <sencabezado1a> 18 </sencabezado1a> <sencabezado1b> 19 </sencabezado1b> <sencabezado1c> 20 </sencabezado1c> <sbuscado> 21 </sbuscado> <snocalifica> 22 </snocalifica> <srequerimientos> 23 </srequerimientos> <stablas> 24 </stablas> <sencabezado2> 25 </sencabezado2> </configuraciones> <explicaciones_fijas> < 26 > 27 </ 26 >.. (Aquí siguen más descripciones de rubros). </explicaciones_fijas> <explicaciones_popup> < 28 > 29 </ 28 >.. (Aquí siguen más descripciones de categorías). </explicaciones_popup> <item> <Nombre> 30 </Nombre> <WWW> 31 </WWW> < 26 > < 28 > < 32 > 33 </ 32 >.. (Aquí siguen más características). </ 28 >.. (Aquí siguen más categorías). </ 26 >.. (Aquí siguen más rubros). </item>.. (Aquí siguen más items). </lista> Figura 33. Estructura del fichero de datos del sistema SOM genérico

75 El prólogo del documento XML está compuesto por una única línea con la declaración <?xml version="1.0" encoding="iso "?>. No es necesario que los nombres de los elementos sean los vistos en la figura anterior, ya que el sistema SOM genérico se orientará en base a la posición que ocupan los elementos dentro del documento XML, no en base a sus nombres. De este modo, el documento podría traducirse completamente a otro idioma sin afectar el funcionamiento del sistema. El cuerpo posee un único elemento raíz (lista), el cual contiene tres elementos referidos a la interfaz del sistema (configuraciones, explicaciones_fijas y explicaciones_popup) y luego siguen los elementos (item) cuyo contenido son los demás datos utilizados para la construcción del formulario de entrada, del mapa SOM y de las tablas de características. En algunos casos, además del contenido de un elemento, también se utiliza el propio nombre del mismo. La tabla 2 muestra una descripción detallada del fichero de datos del sistema SOM genérico. Nº Descripción Ejemplos 1 Carácter en mayúscula con que se afirma la posesión de una característica S 2 Carácter en minúscula con que se afirma la posesión de una característica s 3 Carácter en mayúscula con que se niega la posesión de una característica N 4 Carácter en minúscula con que se niega la posesión de una característica n 5 Cadena con que se encabeza en la tabla de resultados la columna que contiene la cantidad de coincidencias entre las características buscadas y las características Coincidencias poseídas 6 Cadena que representa la ruta y el nombre del fichero que contiene la hoja de estilo en cascada (CSS) común a todas las páginas web del sistema 7 Cadena que aparece en la barra de título Sistema Inteligente para la selección de un CMS 8 Cadena que aparece inmediatamente debajo de la Indique los requerimientos barra de título en la página web del formulario para el CMS que Ud. busca: Cadena con que se encabeza en el formulario de 9 entrada la columna de botones usados para elegir la Obl. NO opción "Obligatoriamente NO" Cadena con que se encabeza en el formulario de 10 entrada la columna de botones usados para elegir la Pref. NO opción "Preferentemente NO"../~dcorsi/css/estilo.css Tabla 2. Descripción del fichero de datos del sistema SOM genérico

76 Nº Descripción Ejemplos 11 Cadena con que se encabeza en el formulario de entrada la columna de botones usados para elegir la Indistinto opción "Indistinto" 12 Cadena con que se encabeza en el formulario de entrada la columna de botones usados para elegir la Pref. SÍ opción "Preferentemente SÍ" 13 Cadena con que se encabeza en el formulario de entrada la columna de botones usados para elegir la Obl. SÍ opción "Obligatoriamente SÏ" 14 Cadena correspondiente al texto del botón usado para volver a la página web anterior Volver 15 Cadena correspondiente al texto del botón usado para enviar los datos del formulario Procesar 16 Cadena con que se identifica en el mapa SOM la celda correspondiente a los requerimientos efectuados Requerimientos efectuados 17 Cadena que representa la ruta y el nombre del fichero que contiene la imagen utilizada como borde entre las../~dcorsi/img/hexa.gif celdas del mapa SOM 18 Cadena que aparece inmediatamente debajo de la barra de título en la página web del mapa SOM y que es seguida del número de características consideradas Mapa autoorganizativo de Kohonen (Características consideradas: 19 Cadena que separa el número de características consideradas del número de características posibles de 20 Cadena que sucede al número de características posibles posibles) 21 Cadena con que se encabeza en la tabla de resultados la columna correspondiente a los items CMS 22 Cadena con que se indica en la tabla de resultados que un item no cumple un requerimiento obligatorio No califica 23 Cadena con que se encabeza en la tabla de resultados la fila que contiene los requerimientos del usuario Requerimientos 24 Cadena correspondiente al texto del botón usado para solicitar las tablas de resultados Tablas 25 Cadena que aparece inmediatamente debajo de la barra de título en la página web de las tablas de resultados Características de los CMS 26 Etiqueta que especifica el nombre de un rubro Fabricante 27 Cadena correspondiente a la descripción del rubro Aquí Ud. podrá establecer los (para que aparezca como explicación fija) siguientes requerimientos Etiqueta que especifica el nombre de una categoría Origen 29 Cadena correspondiente a la descripción de la categoría El CMS es producido en la (para que aparezca como explicación emergente) República Argentina? 30 Cadena correspondiente al nombre de un item 360 Web Manager Cadena correspondiente a la dirección de la página web del item 32 Etiqueta que especifica el nombre de una característica República_Argentina 33 Carácter que afirma, niega, etc. la posesión de la característica S Tabla 2 (cont.). Descripción del fichero de datos del sistema SOM genérico

77 Implementación del sistema SOM genérico En la implementación se construye el sistema "en términos de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables y similares" [Jacobson, Booch y Rumbaugh, 2000, p. 255]. Para implementar el sistema SOM genérico, se abrió una cuenta (dcorsi) en MyJavaServer (Fig. 34). Este servicio es gratuito y permite compilar y correr servlets. Figura 34. Vista general de MyJavaServer

78 La implementación comenzó con la creación de los ficheros de código fuente de las cinco clases que componen el sistema SOM genérico (Fig. 29): FormularioServlet.java TablasServlet.java Kohonen.java 19 RedNeuronalServlet.java XMLTable.java Estos ficheros se subieron por FTP a la carpeta del usuario dcorsi en el servidor de MyJavaServer (Fig. 35), y se compilaron allí mismo con la herramienta que ofrecen en el sitio (utilities/java compiler desde el menú principal), obteniéndose de esa forma los siguientes cinco ficheros con el Java bytecode 20 : FormularioServlet.class TablasServlet.class Kohonen.class RedNeuronalServlet.class XMLTable.class Figura 35. Ficheros del sistema SOM genérico alojados en MyJavaServer Como se puede ver en la figura anterior, para la implementación del sistema SOM genérico también se crearon diversos ficheros guardados en las carpetas css (donde se encuentra el fichero estilo.css, que define la apariencia de las páginas web del sistema) e img (donde están alojados los ficheros de imagen utilizados por las páginas web del sistema). 19 Kohonen se implementó de forma tal que su funcionamiento pudiera modificarse mediante el uso de parámetros. Sin embargo, no se requiere que el usuario haga uso de ello, ya que RedNeuronalServlet siempre utiliza los mismos valores: primero solicita que se realice un aprendizaje grueso (300 iteraciones partiendo de α = 0.5 y r = altura del mapa) y luego un aprendizaje fino (1000 iteraciones partiendo de α = 0.2 y r = 3) 20 El Java bytecode es un código intermedio entre el código fuente y el código máquina que entiende el dispositivo de destino. El Java bytecode es interpretado y ejecutado en la máquina virtual de Java (JVM), un programa escrito en código nativo de la plataforma de destino

79 Para poder probar el sistema SOM genérico, con los datos de la tabla 1 y respetando 21 la estructura vista en la figura 33, se creó el fichero animales.xml (Fig. 36). <?xml version="1.0" encoding="iso "?> <lista_de_items_animal> <configuraciones> <csimayu>s</csimayu> <csiminu>s</csiminu> <cnomayu>n</cnomayu> <cnominu>n</cnominu> <spuntaje>coincidencias</spuntaje> <sestilo>../~dcorsi/css/estilo.css</sestilo> <stitle>sistema Inteligente para la selección de un animal</stitle> <sencabezado>indique los requerimientos para el animal que Ud. busca:</sencabezado> <soblno>obl. NO</sOblNo> <sprefno>pref. NO</sPrefNo> <sindistinto>indistinto</sindistinto> <sprefsi>pref. SÍ</sPrefSi> <soblsi>obl. SÍ</sOblSi> <svolver>volver</svolver> <sprocesar>procesar</sprocesar> <susrequerimientos>requerimientos efectuados</susrequerimientos> <sarchivoimg>../~dcorsi/img/hexa.gif</sarchivoimg> <sencabezado1a>mapa SOM de Kohonen (Características consideradas: </sencabezado1a> <sencabezado1b> de </sencabezado1b> <sencabezado1c> posibles)</sencabezado1c> <sbuscado>animal</sbuscado> <snocalifica>no califica</snocalifica> <srequerimientos>requerimientos</srequerimientos> <stablas>tablas</stablas> <sencabezado2>características de los animales</sencabezado2> </configuraciones> <explicaciones_fijas> <Tamaño>En este menú Ud. podrá hacer requerimientos sobre el tamaño del animal</tamaño> <Cuerpo>En este menú Ud. podrá hacer requerimientos sobre el cuerpo del animal</cuerpo> <Hábitos>En este menú Ud. podrá hacer requerimientos sobre los hábitos del animal</hábitos> </explicaciones_fijas> <explicaciones_popup> <Es>Cómo es el animal?{ul}{li}pequeño{li}mediano{li}grande{/ul}</es> <Tiene>Tiene{ul}{li}2 patas{li}4 patas{li}pelo{li}pezuñas{li}melena{li}plumas?{/ul}</tiene> <Le_gusta>Le gusta{ul}{li}cazar{li}correr{li}volar{li}nadar?{/ul}</le_gusta> </explicaciones_popup> <item_animal> <Nombre>Dove</Nombre> <WWW> <Tamaño><Es> <Pequeño>S</Pequeño> <Mediano>N</Mediano> <Grande>N</Grande> </Es></Tamaño> <Cuerpo><Tiene> <_2_patas>S</_2_patas> <_4_patas>N</_4_patas> <Pelo>N</Pelo> <Pezuñas>N</Pezuñas> <Melena>N</Melena> <Plumas>S</Plumas> </Tiene></Cuerpo> <Hábitos><Le_gusta> <Cazar>N</Cazar> <Correr>N</Correr> <Volar>S</Volar> <Nadar>N</Nadar> </Le_gusta></Hábitos> </item_animal>.. (Aquí siguen más items). </lista_de_items_animal> Figura 36. El fichero animales.xml 21 Si el contenido de un elemento XML contiene una etiqueta HTML, ésta se escribe con llaves, p. ej: {ul}

80 Además del fichero animales.xml, se creó también animales.html (Fig. 37) Así, el sistema SOM implementado dejó de ser genérico, pues con estos dos ficheros se convirtió en un sistema inteligente para la selección de un animal. Figura 37. Página de inicio del Sistema Inteligente para la selección de un animal El siguiente fragmento del código HTML de la página de inicio animales.html (Fig. 38) muestra que, al hacer clic en el botón Comenzar (líneas 14-16), se invoca el servlet FormularioServlet (líneas 01-03), al cual se le pasa, como parámetro oculto, el nombre del fichero XML del sistema (líneas 05-07). 01: <FORM ACTION=" 02: METHOD="post" 03: ENCTYPE="application/x-www-form-urlencoded"> 04: <P> 05: <INPUT TYPE="hidden" 06: NAME="archivo" 07: VALUE="/users/dcorsi/animales.xml"> 08: <INPUT TYPE="hidden" 09: NAME="segundoServlet" 10: VALUE="/servlet/dcorsi.RedNeuronalServlet"> 11: <INPUT TYPE="hidden" 12: NAME="tercerServlet" 13: VALUE="/servlet/dcorsi.TablasServlet"> 14: <INPUT TYPE="SUBMIT" 15: CLASS="botonazul" 16: VALUE="Comenzar"> 17: </P> 18: </FORM> Figura 38. Fragmento del código HTML de animales.html

81 Prueba del sistema SOM genérico Como se adelantó en la sección anterior, el sistema SOM genérico se probó implementando con él un sistema inteligente para la selección de un animal, en base a los datos de la tabla 1. Se decidió utilizar este sistema porque, debido a la gran familiaridad de cualquier usuario con estos datos, un funcionamiento incorrecto del sistema se podría detectar con facilidad, prácticamente en forma intuitiva. Roger Pressman [2001, p. 478] sugiere que "una estrategia de prueba del software debe incluir tests de bajo nivel necesarios para verificar que el código fuente ha sido implementado correctamente, así como también tests de alto nivel para validar las funciones del sistema en base a los requisitos del cliente", y representa la estrategia completa con la espiral que se muestra en la figura 39 [ibidem, p. 481] Figura 39. Una estrategia para la prueba del software 22 La prueba de unidad (Unit testing) "se concentra en cada unidad (componente) del software y en cómo fue implementado su código fuente" [idem]. La prueba de integración (Integration testing) "se enfoca en el diseño y en la construcción de la arquitectura del software" [idem] La prueba de validación (Validation testing) "consiste en contrastar los requerimientos de software establecidos durante el análisis con el software que ha sido construido" [idem] Finalmente, la prueba de sistema (System testing) "evalúa el software y los otros elementos del sistema como un todo" [idem]. Esta prueba "cae fuera del ámbito de la ingeniería del software, ya que exige la verificación del desempeño de otros elementos (hardware, gente, bases de datos) además del software" [ibidem, p. 482] 22 De adentro hacia afuera: Prueba de unidad Código; Prueba de integración Diseño; Prueba de validación Requerimientos; Prueba de sistema Ingeniería del sistema

82 Para la prueba de unidad del sistema SOM genérico se emplearon diversas técnicas. El fichero animales.xml se validó accediendo a (Fig. 40) Figura 40. Validación automática del fichero animales.xml

83 También index.html se validó en (Fig. 41) Figura 41. Validación automática del fichero animales.html El fichero estilo.css se validó en Figura 42. Validación automática del fichero estilo.css

84 Steve McConnell [1996, p. 74] explica que "code reading 23 es un proceso formal de revisión en el cual el autor del código les entrega a dos o más revisores los listados del código fuente. Los revisores leen el código y le reportan cualquier error al autor de código". Este autor menciona, además, que "en un estudio del Laboratorio de Ingeniería del Software de la NASA, code reading detectó el doble de defectos por hora que las pruebas" [idem]. Lo que McConnell sugiere, como conclusión, es que "en un proyecto de desarrollo rápido, llevar a cabo alguna combinación de code reading y pruebas sería más efectivo que realizar sólo pruebas" [idem]. En sintonía con estas ideas, para el sistema SOM genérico se decidió revisar mediante la técnica de code reading el código fuente de los tres servlets FormularioServlet.java, RedNeuronalServlet.java y XMLTable.java, así como también el de las clases TablasServlet.java y Kohonen.java. Para verificar que los componentes mencionados funcionan correctamente juntos, se realizó la prueba de integración. Obsérvese que, a diferencia de la prueba de unidad, que revisó la estructura interna del sistema (es decir, su código fuente), la prueba de integración es "una prueba del sistema como 'caja negra', es decir, una prueba del comportamiento observable externamente del sistema" [Jacobson, Booch y Rumbaugh, 2000, p. 284]. En otras palabras, "las pruebas de caja negra se utilizan para demostrar que las funciones del software operan bien, que las entradas son aceptadas de forma apropiada, que las salidas son producidas correctamente, y que se mantiene la integridad de la información externa (por ejemplo, de una base de datos)" [Pressman, 2001, p ] Como "la mayoría de los casos de prueba de integración pueden ser derivados de las realizaciones de casos de uso-diseño, ya que las realizaciones de casos de uso describen cómo interaccionan las clases y los objetos, y por lo tanto cómo interaccionan los componentes" [Jacobson, Booch y Rumbaugh, 2000, p. 293], para la prueba de integración del sistema SOM genérico se partió de su diagrama de secuencia (Fig. 30). La página de inicio animales.html se solicitó y se mostró correctamente, como ya se informó al explicar su implementación (Fig. 37). 23 Literalmentee: Lectura de código

85 Al hacer clic en el botón Comenzar, se solicitó el formulario de entrada de datos (a ser generado por FormularioServlet). La solicitud incluyó, como un parámetro oculto, el nombre del fichero XML (animales.xml). El funcionamiento de FormularioServlet y XMLTable fue correcto, ya que, en base al contenido del fichero animales.xml se mostró el siguiente formulario de entrada de datos (Fig. 43): Figura 43. Formulario de entrada de datos (cerrado) En el formulario se ven inicialmente los tres rubros Tamaño, Cuerpo y Hábitos, con sus correspondientes descripciones. Cada rubro dispone de una opción abrir, mediante la cual la descripción es reemplazada por los controles que el usuario puede usar para ingresar sus requerimientos acerca de cada característica (Fig. 44). En el sistema inteligente para la selección de un animal, existen 13 características, correspondientes a tres categorías (Es, Tiene y Le gusta), una en cada uno de los tres rubros mencionados. Los controles disponibles están formados por botones de exclusión mutua (radio buttons), a razón de cinco de ellos por cada característica, e identificados con los títulos Obl. NO, Pref. NO, Indistinto, Pref. SÍ y Obl. SÍ

86 Figura 44. Formulario de entrada de datos (abierto) Hasta aquí, la prueba de integración siguió un recorrido lineal, ya que el usuario solamente tuvo como opción hacer clic en el botón Comenzar, con lo cual se solicita y obtiene siempre el mismo formulario basado en animales.xml. En cambio, como es posible elegir entre cinco valores para cada una de las 13 características, lo que el usuario le envía a RedNeuronalServlet al hacer clic en el botón Procesar es apenas una de las 5 13 (es decir, ) combinaciones que existen

87 Roger Pressman [2001, p. 440] afirma que "no es posible hacer una prueba exhaustiva. Incluso para un programa de tamaño moderado, el número de permutaciones de caminos es excepcionalmente grande. Por ello, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Sin embargo, es posible cubrir adecuadamente la lógica del programa y asegurar que se han cumplido todas las condiciones en el diseño de los componentes". Para probar que RedNeuronalServlet funciona correctamente en conjunto con XMLTable y Kohonen, es necesario "buscar combinaciones de entrada, salida y estado inicial de sistema que den lugar a escenarios interesantes que empleen estas clases" [Jacobson, Booch y Rumbaugh, 2000, p. 293]. Por ello, el resto de la prueba de integración (Tabla 3) consistió en verificar la salida de RedNeuronalServlet y TablasServlet cuando la entrada correspondía a: Las características de los mismos animales de la tabla 1 ingresadas como preferencia (casos 1-13) Las características de los mismos animales de la tabla 1. ingresadas como exigencia (casos 14-26) Todas las características ingresadas de a una por vez como preferencia y dejando el resto como Indistinto (casos para "Preferentemente SÍ" y para "Preferentemente NO"). Todas las características ingresadas de a una por vez como exigencia y dejando el resto como Indistinto (casos para "Obligatoriamente SÍ" y para "Obligatoriamente NO") Todas las características ingresadas simultáneamente con la misma preferencia (casos 79 para "Preferentemente SÍ" y 80 para "Preferentemente NO") Todas las características ingresadas simultáneamente con el valor Indistinto (caso 81) La codificación empleada en la tabla 3 es la siguiente: 1: Obligatoriamente SÍ 1: Preferentemente SÍ?: Indistinto 0: Preferentemente NO 0: Obligatoriamente NO

88 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s N a d a r Respuesta esperada Respuesta obtenida SOM dove dove Tablas 13: dove 12: hen, duck, goose, owl, hawk... O K SÍ hen hen 13: hen 12: dove... SÍ duck, goose duck, goose 13: duck, goose 12: dove... SÍ owl, hawk owl, hawk 13: owl, hawk 12: dove... SÍ eagle eagle 13: eagle 11: owl, hawk... SÍ fox fox 13: fox 11: dog, wolf, cat... SÍ dog dog, wolf 13: dog 11: fox, wolf... SÍ wolf dog, wolf 13: wolf 11: fox, dog, lion... SÍ cat cat 13: cat 11: fox... SÍ tiger tiger 13: tiger 12: lion... SÍ Tabla 3. Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

89 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s N a d a r Respuesta esperada Respuesta obtenida SOM Tablas O K lion tiger, lion 13: lion 12: tiger... SÍ horse, zebra horse, zebra 13: horse, zebra 11:lion, cow... SÍ cow cow 13: cow 11: horse, zebra... SÍ dove dove 13: dove SÍ hen hen 13: hen SÍ duck, goose duck, goose 13: duck, goose SÍ owl, hawk owl, hawk 13: owl, hawk SÍ eagle eagle 13: eagle SÍ fox fox 13: fox SÍ dog dog, wolf 13: dog SÍ Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

90 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s N a d a r Respuesta esperada Respuesta obtenida SOM Tablas O K wolf wolf, dog 13: wolf SÍ cat cat 13: cat SÍ tiger tiger 13: tiger SÍ lion tiger, lion 13: lion SÍ horse, zebra horse, zebra 13: horse, zebra SÍ cow cow 13: cow SÍ 27 1???????????? dove, hen, duck, goose, owl, hawk, cat dove, hen, duck, goose, owl, hawk, cat 13: dove, hen, duck, goose, owl, hawk, cat... SÍ 28? 1??????????? eagle, fox, dog, wolf eagle, fox, dog, wolf 13: eagle, fox, dog, wolf... SÍ 29?? 1?????????? tiger, lion, horse, zebra, cow tiger, lion, horse, zebra, cow 13: tiger, lion, horse, zebra, cow... SÍ 30??? 1????????? dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle 13: dove, hen, duck, goose, owl, hawk, eagle... SÍ Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

91 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s 31???? 1???????? 32????? 1??????? 33?????? 1?????? 34??????? 1????? 35???????? 1???? 36????????? 1??? 37?????????? 1?? 38??????????? 1? N a d a r Respuesta esperada fox, dog, wolf, cat, tiger, lion, horse, zebra, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow horse, zebra, cow wolf, lion, horse, zebra dove, hen, duck, goose, owl, hawk, eagle owl, hawk, eagle, fox, wolf, cat, tiger, lion dog, wolf, tiger, lion, horse, zebra dove, duck, goose, owl, hawk, eagle Respuesta obtenida SOM fox, dog, wolf, cat, tiger, lion, horse, zebra, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow horse, zebra, cow wolf, lion, horse, zebra dove, hen, duck, goose, owl, hawk, eagle owl, hawk, eagle, fox, wolf, cat, tiger, lion dog, wolf, tiger, lion, horse, zebra dove, duck, goose, owl, hawk, eagle 39???????????? 1 duck, goose duck, goose 40 0???????????? eagle, fox, dog, wolf, tiger, lion, horse, zebra, cow eagle, fox, dog, wolf, tiger, lion, horse, zebra, cow Tablas 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow... 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow... 13: horse, zebra, cow... 13: wolf, lion, horse, zebra... 13: dove, hen, duck, goose, owl, hawk, eagle... 13: owl, hawk, eagle, fox, wolf, cat, tiger, lion... 13: dog, wolf, tiger, lion, horse, zebra... 13: dove, duck, goose, owl, hawk, eagle... 13: duck, goose... 13: eagle, fox, dog, wolf, tiger, lion, horse, zebra, cow... Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas O K SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ

92 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V N r P e l o d p p z a o a a e l u r i a a u z l d n l e m r a t t ñ a a a d o n a e n a a a r r r e a s r o s s s 41? 0??????????? 42?? 0?????????? 43??? 0????????? 44???? 0???????? 45????? 0??????? 46?????? 0?????? 47??????? 0????? 48???????? 0???? Respuesta esperada dove, hen, duck, goose, owl, hawk, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion dove, hen, duck, goose, owl, hawk, eagle, fox, dog, cat, tiger, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow Respuesta obtenida SOM dove, hen, duck, goose, owl, hawk, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion dove, hen, duck, goose, owl, hawk, eagle, fox, dog, cat, tiger, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow Tablas 13: dove, hen, duck, goose, owl, hawk, cat, tiger, lion, horse, zebra, cow... 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat... 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow... 13: dove, hen, duck, goose, owl, hawk, eagle... 13: dove, hen, duck, goose, owl, hawk, eagle... 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion... 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, cat, tiger, cow... 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow... O K SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

93 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s 49????????? 0??? 50?????????? 0?? 51??????????? 0? 52???????????? ???????????? N a d a r Respuesta esperada dove, hen, duck, goose, dog, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle, fox, cat, cow hen, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, cat Respuesta obtenida SOM dove, hen, duck, goose, dog, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle, fox, cat, cow hen, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, cat Tablas 13: dove, hen, duck, goose, dog, horse, zebra, cow... 13: dove, hen, duck, goose, owl, hawk, eagle, fox, cat, cow... 13: hen, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow... 13: dove, hen, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow... 13: dove, hen, duck, goose, owl, hawk, cat O K SÍ SÍ SÍ SÍ SÍ 54? 1??????????? eagle, fox, dog, wolf eagle, fox, dog, wolf 13: eagle, fox, dog, wolf SÍ 55?? 1?????????? tiger, lion, horse, zebra, cow tiger, lion, horse, zebra, cow 13: tiger, lion, horse, zebra, cow SÍ 56??? 1????????? 57???? 1???????? dove, hen, duck, goose, owl, hawk, eagle fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: dove, hen, duck, goose, owl, hawk, eagle 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow SÍ SÍ Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

94 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s 58????? 1??????? N a d a r Respuesta esperada fox, dog, wolf, cat, tiger, lion, horse, zebra, cow Respuesta obtenida SOM fox, dog, wolf, cat, tiger, lion, horse, zebra, cow Tablas 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow O K SÍ 59?????? 1?????? horse, zebra, cow horse, zebra, cow 13: horse, zebra, cow SÍ 60??????? 1????? wolf, lion, horse, zebra wolf, lion, horse, zebra 13: wolf, lion, horse, zebra SÍ 61???????? 1???? dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle 13: dove, hen, duck, goose, owl, hawk, eagle SÍ 62????????? 1??? owl, hawk, eagle, fox, wolf, cat, tiger, lion owl, hawk, eagle, fox, wolf, cat, tiger, lion 13: owl, hawk, eagle, fox, wolf, cat, tiger, lion SÍ 63?????????? 1?? dog, wolf, tiger, lion, horse, zebra dog, wolf, tiger, lion, horse, zebra 13: dog, wolf, tiger, lion, horse, zebra SÍ 64??????????? 1? dove, duck, goose, owl, hawk, eagle dove, duck, goose, owl, hawk, eagle 13: dove, duck, goose, owl, hawk, eagle SÍ 65???????????? 1 duck, goose duck, goose 13: duck, goose SÍ 66 0???????????? 67? 0??????????? eagle, fox, dog, wolf, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, cat, tiger, lion, horse, zebra, cow eagle, fox, dog, wolf, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, cat, tiger, lion, horse, zebra, cow 13: eagle, fox, dog, wolf, tiger, lion, horse, zebra, cow 13: dove, hen, duck, goose, owl, hawk, cat, tiger, lion, horse, zebra, cow Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas SÍ SÍ

95 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s 68?? 0?????????? N a d a r Respuesta esperada dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat Respuesta obtenida SOM dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat Tablas 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat O K SÍ 69??? 0????????? fox, dog, wolf, cat, tiger, lion, horse, zebra, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow SÍ 70???? 0???????? dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle 13: dove, hen, duck, goose, owl, hawk, eagle SÍ 71????? 0??????? dove, hen, duck, goose, owl, hawk, eagle dove, hen, duck, goose, owl, hawk, eagle 13: dove, hen, duck, goose, owl, hawk, eagle SÍ 72?????? 0?????? 73??????? 0????? dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion dove, hen, duck, goose, owl, hawk, eagle, fox, dog, cat, tiger, cow dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion dove, hen, duck, goose, owl, hawk, eagle, fox, dog, cat, tiger, cow 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, cat, tiger, cow SÍ SÍ 74???????? 0???? fox, dog, wolf, cat, tiger, lion, horse, zebra, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow SÍ Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

96 Nº P e q u e ñ o Valores ingresados Es Tiene Le gusta M 2 4 P G M P C e e C V r P e l o d p p z a o a e l u r i a a u z l n l e m r a t t ñ a a d o n a e n a a a r r e a s r o s s s 75????????? 0??? N a d a r Respuesta esperada dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat Respuesta obtenida SOM dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat Tablas 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat O K SÍ 76?????????? 0?? fox, dog, wolf, cat, tiger, lion, horse, zebra, cow fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: fox, dog, wolf, cat, tiger, lion, horse, zebra, cow SÍ 77??????????? 0? 78???????????? 0 hen, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow hen, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: hen, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: dove, hen, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow SÍ SÍ : wolf, lion, horse, zebra 5: duck, goose, owl, hawk, eagle, tiger... SÍ : hen 9: dove, fox, dog, cat cow... SÍ 81????????????? dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow 13: dove, hen, duck, goose, owl, hawk, eagle, fox, dog, wolf, cat, tiger, lion, horse, zebra, cow SÍ Tabla 3 (cont.). Prueba de integración: Respuestas esperadas vs. respuestas obtenidas

97 Si bien todas las pruebas arrojaron resultados satisfactorios, es necesario realizar algunas aclaraciones sobre lo que se muestra en la tabla 3. La respuesta obtenida está formada tanto por el mapa SOM (que es la salida de RedNeuronalServlet) como por las tablas que muestra TablasServlet. En la columna SOM se indica el valor contenido en la celda correspondiente a los requerimientos ingresados, aunque en realidad todo el mapa SOM es la salida del sistema. Esto es crítico en los casos 79 y 80, donde los requerimientos contradictorios llevan a un mapa SOM donde no hay valores en la celda correspondiente a los requerimientos ingresados, pero sí los hay en las celdas adyacentes. En la columna Tablas se muestran los animales ordenados según el número de coincidencias entre sus características y los requerimientos ingresados. Los puntos suspensivos indican que la lista continúa, ya que, cuando todos los requerimientos son preferencias, TablasServlet muestra todos los animales. Si, en cambio, algún requerimiento es obligatorio, se listan sólo los animales que lo cumplen, por lo que, en este caso, no se utilizan los puntos suspensivos. Resultan interesantes los casos 7, 8, 11, 20, 21 y 24, porque en ellos la celda del mapa SOM correspondiente a los requerimientos ingresados contiene la respuesta esperada acompañada de otro valor 24. Las tablas mostradas por TablasServlet permitirían, en estos casos, separar los valores según el número de coincidencias entre sus características y los requerimientos ingresados. En estas tablas se indica, además de ese número, cuáles son las características que no coinciden. En cuanto a lo que acaba de mencionarse, también es necesario recordar que los mapas SOM se generan a partir de vectores cuyos valores iniciales son números aleatorios, por lo cual, ante la misma entrada, es posible que se produzcan como salidas mapas SOM distintos de los obtenidos para completar la tabla 3. Por ello, si se repiten las pruebas para los casos mencionados, frecuentemente las respuestas esperadas aparecerán en sus celdas sin la compañía de otros valores. A continuación, se muestran dos de las pruebas del sistema que dieron lugar a los resultados de la tabla En los casos 7 y 20, se esperaba dog pero la celda contiene dog y wolf; en los casos 8 y 21, se esperaba wolf pero la celda contiene dog y wolf; y en los casos 11 y 24, se esperaba lion pero la celda contiene tiger y lion

98 En la figura 45 se muestra el ingreso de los datos del caso 5. Como ninguna característica fue ingresada como Indistinto, se consideraron para la construcción del mapa SOM todas ellas (13 en total), tal como puede observarse en la figura 46. Además, como tampoco hubo características ingresadas como exigencias, la tabla obtenida muestra todos los animales con sus correspondientes números de coincidencias (Fig. 47). Figura 45. Ingreso de las características de un águila (eagle)

99 Figura 46. Mapa SOM obtenido al ingresar las características de un águila (eagle) Figura 47. Tabla obtenida al ingresar las características de un águila (eagle)

100 En la figura 48 se muestra el ingreso de los datos del caso 54. Como hubo características ingresadas como Indistinto, se construyeron dos mapas SOM, uno considerando todas las características posibles (13 en total) y otro considerando solamente la característica exigida (tamaño obligatoriamente mediano), tal como puede observarse en la figura 49. Al haber por lo menos una característica ingresada como exigencia, la tabla obtenida no muestra el número de coincidencias de los animales que no califican (Fig. 50). Figura 48. Ingreso de la característica Mediano Obl. SÍ y el resto Indistinto

101 Figura 49. Mapas SOM obtenidos al ingresar Mediano Obl. SÍ y el resto Indistinto

102 Figura 50. Tablas obtenidas al ingresar Mediano Obl. SÍ y el resto Indistinto La última prueba que se realizó sobre el sistema SOM genérico fue su prueba de validación. La misma se llevó a cabo en tres de los navegadores más populares (Internet Explorer, Mozilla Firefox y Safari) utilizando tres de las resoluciones de pantalla más comunes: SVGA (800x600), XGA (1024x768) y SXGA (1280x1024). En todos los casos mencionados, el funcionamiento del sistema SOM genérico fue completamente satisfactorio. La prueba consistió en verificar que el sistema cumpliera con los requisitos planteados en la sección 4.2.1, y sus resultados se muestran a continuación (Tabla 4)

103 Tipo de requerimientos Funcionales No funcionales Requerimiento Comentario OK El sistema debe permitirle al usuario elegir sin dificultad las características que considere deseables en el elemento buscado, mostrando explicaciones contextuales de todas las características que se pueden elegir, para que el usuario esté informado del significado de las distintas opciones El sistema debe analizar los datos de todos los elementos considerados, y mostrarlos dispuestos en un mapa SOM, para poder visualizar cuáles son los más adecuados según sus características, las cuales, a su vez, también deberían poder compararse El sistema debe ser accesible a través de la Web mediante un navegador (browser) El sistema debe trabajar con datos guardados en un fichero escrito en XML (Extensible Markup Language) El sistema debe estar formado por Java servlets, para generar dinámicamente las páginas que se ven en el navegador (browser), a partir de los datos ingresados por el usuario, de los datos del fichero XML y de los cálculos realizados El sistema debe emplear HTML de acuerdo con los estándares del Consorcio World Wide Web (W3C) El sistema debe emplear hojas de estilo CSS (Cascade Style Sheets) para definir el formato de los distintos elementos de las páginas web El sistema debe permitir que sólo el administrador modifique los datos de los elementos Mediante controles formados por botones de exclusión mutua (radio buttons), el sistema le permite al usuario elegir las características que considera deseables en el elemento buscado. El sistema permite incorporar descripciones de los diferentes rubros y es capaz, además, de mostrar explicaciones contextuales (Fig. 51) Si ninguna característica es ingresada como Indistinto, se consideran para la construcción del mapa SOM todas ellas. De lo contrario, se generan dos mapas SOM (uno con todas las características y otro sólo con las características no ingresadas como Indistinto). Para poder comparar las características de los elementos, se muestran tablas ordenadas según el número de coincidencias entre las características de los elementos y las características deseadas El sistema es accesible con los navegadores más populares (p. ej. Internet Explorer, Mozilla Firefox y Safari) El sistema lee los datos desde un fichero XML. Cambiándolo, el sistema se puede orientar a la selección de cualquier tipo de elementos El sistema está formado por Java servlets, que generan dinámicamente las páginas que se ven en el navegador (browser), a partir de los datos ingresados por el usuario, de los datos del fichero XML y de los cálculos realizados El sistema emplea HTML de acuerdo con los estándares del Consorcio World Wide Web (Fig. 41) El sistema emplea hojas de estilo CSS (Cascade Style Sheets) para definir el formato de los distintos elementos de las páginas web Los datos de los elementos se encuentran en el fichero XML, el cual no puede ser modificado por los usuarios SÍ SÍ SÍ SÍ SÍ SÍ SÍ SÍ Tabla 4. Resultados de la prueba de validación del sistema SOM genérico

104 Figura 51. Explicaciones contextuales ofrecidas por el sistema SOM genérico Al pasar las pruebas de unidad, de integración y de validación, fue completado el desarrollo del sistema SOM genérico. Al mismo tiempo, también finalizó gran parte del desarrollo de CMS-SOM, ya que éste no es más que una aplicación específica del sistema SOM genérico. En las próximas secciones se describen los procesos que fue necesario llevar a cabo para implementar el sistema CMS-SOM: establecer una nueva lista de características descriptivas de los CMS, determinar cuáles serían los CMS iniciales para CMS-SOM, obtener los datos de esos CMS y, finalmente, generar los ficheros del sistema y ponerlos en la Web

105 4.3. Una nueva lista de características descriptivas de los CMS Los sistemas que varias organizaciones han colocado en la Web con el fin de facilitar la selección de un CMS utilizan diferentes listas de características descriptivas de los CMS. Los rubros en que se agrupan estas características se muestran a continuación (Tabla 5) Sistema Nº Rubro CMS-Search (Lista de características completa en Anexo A6) Produktfinder (Lista de características completa en Anexo A7) CM-Overview (Lista de características completa en Anexo A8) CMS-Matrix (Lista de características completa en Anexo A9) 1 Descripción del producto 2 Creación de Contenido 3 Administración de Contenidos propiamente dicha 4 Distribución del contenido 5 Mejoras en el ciclo de vida (Aplican a las tres etapas anteriores) 1 Información básica 2 Gestión de activos 3 Sindicación de contenidos 4 Extensibilidad 5 Importación 6 Performance 7 Personalización 8 Reportes 9 Disponibilidad 10 Flujo de trabajo 11 XML 1 Producto 2 Edición 3 Administración de Contenidos 4 Gestión Documental 5 Gestión de correo electrónico 6 Recuperación de Información 7 Gestión de Registros 8 Gestión del flujo de trabajo 9 Estándares 10 Inversión 11 Tecnología 12 Soporte 13 Componentes 1 Requisitos del sistema 2 Seguridad 3 Soporte 4 Interoperabilidad 5 Facilidad de uso 6 Flexibilidad 7 Administración 8 Performance 9 Aplicaciones integradas 10 Comercio Tabla 5. Rubros en que algunos sistemas clasifican las características de los CMS

106 Algunos de esos rubros corresponden a los pasos recorridos durante el procesamiento del contenido, los cuales constituyen el "ciclo de vida del contenido" (Content Life Cycle). Existen diversos modelos de ciclo de vida del contenido, como se ve a continuación: Figura 52. El ciclo de vida del contenido según Robertson [2003b, p. 2] 25 REDACCIÓN USUARIOS Creación Control Aprobación Publicación Archivamiento Figura 53. El ciclo de vida del contenido según Röwekamp [2001, p. 15] Archivamiento Investigación Publicación Creación Aprobación Control Figura 54. El ciclo de vida del contenido según Bechtolsheim y Oberbauer [2001, p. 11] 25 Creación de contenido Administración de contenido Publicación Presentación $ Contrato & Negocio

107 Los tres modelos anteriores presentan semejanzas y diferencias. Inicialmente, tiene lugar la creación del contenido. Luego, éste debe ser sometido al control de los responsables hasta su aprobación. En el primer modelo, estos dos últimos pasos aparecen agrupados bajo la denominación de "administración del contenido", un enfoque también defendido por Boiko [2003] 26. A continuación, es posible su publicación. La presentación que aparece en el primer modelo hace referencia a la posibilidad de cambiar la apariencia del contenido publicado (por ejemplo, la escala utilizada para mostrar una imagen), algo que en los otros dos modelos no fue contemplado o que se considera como parte del proceso de publicación. Cuando el contenido no es más actual, los dos últimos modelos indican su archivamiento (algo que en el primer modelo no aparece). Finalmente, el último modelo - que es el más completo de los tres - menciona que los contenidos archivados pueden ser objeto de una investigación que lleve a la creación de nuevos contenidos, con lo que el ciclo comenzaría nuevamente. Para CMS-SOM se diseñó un listado de 10 rubros (Tabla 6) entre los cuales, además de los datos del fabricante y del producto, se incluyen las tres fases principales del ciclo de vida del contenido (creación, administración y publicación). Estos rubros fueron luego divididos en 66 categorías, en las cuales, finalmente, fueron agrupadas las 400 características que definen a los CMS. En base a esta información se definió la estructura del fichero items.xml, que es el fichero leído por el sistema SOM genérico para dar lugar a CMS-SOM. Sistema Nº Rubro 1 Fabricante 2 Generalidades del producto CMS-SOM (Lista de características completa en Anexo A10) 3 Licencia 4 Documentación 5 Soporte 6 Tecnologías 7 Estándares 8 Ciclo de Vida del Contenido: CREACIÓN 9 Ciclo de Vida del Contenido: ADMINISTRACIÓN 10 Ciclo de Vida del Contenido: PUBLICACIÓN Tabla 6. Rubros en que CMS-SOM clasifica las características de los CMS 26 "Muchas compañías describen su producto CMS entero como un sistema de administración. Para mí [...] es más instructivo focalizar el término administración en la parte específica del CMS que trata el contenido que está en el sistema y diferenciarla de sus otras partes que permiten captar contenido o publicarlo"

108 4.4. Elección de los CMS iniciales para CMS-SOM Los cuatro sistemas para la selección de CMS a través de la Web descritos en el Estado del Arte de esta tesis contienen los datos de un gran número de productos, como se muestra a continuación 27 : CMS-Search: 73 CMS (ver Anexo A1) Produktfinder: 1419 CMS (ver Anexo A2) Content Management Overview: 174 CMS (ver Anexo A3) CMS-Matrix: 873 CMS (ver Anexo A4) Para elegir cuáles serían los CMS considerados inicialmente en CMS-SOM, se siguió el siguiente procedimiento: 1. Se realizó la unión de los cuatro conjuntos de CMS mencionados.. 2. Se eliminaron los CMS que sólo aparecían en uno de los sistemas de selección. 3. Se revisó la lista de los CMS resultantes, actualizando los nombres de aquellos que cambiaron y eliminando los que ya no están más en el mercado. 4. Finalmente, se agregaron dos CMS más 28, obteniéndose la lista definitiva de 160 CMS que se muestra en la tabla 7. Nº CMS CMS-Search Produktfinder CM-Overview CMS-Matrix Web Manager activeweb contentserver Affino Professional CMS 4 AIOCP - All In One Control Panel Aiyoota!-CMS Apache Lenya Applaud CMS Ariadne AuthorIT Axinom AxCMS.net BASE-10 Content Management Suite beam:ware 4 13 Bitrix Site Manager Bluo CMS Tabla 7. Sistemas donde son mencionados los CMS iniciales de CMS-SOM 27 Los sistemas descritos fueron analizados en enero de Actualmente, sus características pueden diferir de las expuestas aquí. 28 El CMS 360 Web Manager 3.0, a pesar de ser mencionado solamente en CMS-Matrix, fue agregado a la lista porque se consideró interesante incluir un producto argentino en CMS-SOM (también es argentino el autor del CMS TikiWiki, actualmente desarrollado por voluntarios de todo el mundo), y el sistema c-bizz, mencionado solamente en Produktfinder, se agregó por ser el CMS con que habitualmente trabaja el autor de esta tesis

109 Nº CMS CMS-Search Produktfinder CM-Overview CMS-Matrix 15 Bricolage c-bizz C1 18 Calimero.CMS Campsite Changer 21 Clay Tablet Rosetta WCMS 22 Cofax CommonSpot Communiqué 4 25 Composite CMS 26 ConQuest 27 conrad:// 28 Consolo Contelligent Contenido CONTENS Contensis R4 Enterprise Web CMS 33 Contrexx Open Source CMS CS EMMS Suite CuppaWEB Daisy Day Two WCMS Digimaker Digital Workroom Direct News DROW CMS Drupal Dynabase Dynasite CMS Easy Publisher econtent eforia web manager 4 48 EGOTEC Ektron CMS400.net EMC Documentum 5 51 ENID PX EPAM CMS 53 EPiServer EPiX Eprise 56 Estrada Engine EverSuite 3.8 Tabla 7 (cont.). Sistemas donde son mencionados los CMS iniciales de CMS-SOM

110 Nº CMS CMS-Search Produktfinder CM-Overview CMS-Matrix 58 ez Publish FarCry CMS FatWire Content Server FeedStream QDoX FileNet Content Manager 63 formelcms Freestyler CMS Geeklog Gentics Content.Node GERNOVA Interweb GX WebManager Hippo CMS IBM Content Manager icoya OpenContent Imperia 8 73 Infopark CMS Fiona 74 InterRed Interwoven TeamSite inxire ECM Jahia Joomla! K3CMS PRO Kentico CMS 2.0b 81 Kuborgh CMS 82 LATUS 83 Libertas U DO 84 Liferay Portal Livelink ECM 86 Magnolia Mambo MARK 4 89 Mason Mediasurface Morello Metadot Portal Server Microsoft Office SharePoint Server Midgard mijncms 95 Mini-CMS MMBase MySource Matrix NetCMS 99 Noxum Publishing Studio 100 Numotion WebManager Tabla 7 (cont.). Sistemas donde son mencionados los CMS iniciales de CMS-SOM

111 Nº CMS CMS-Search Produktfinder CM-Overview CMS-Matrix 101 Oktopus CMS 102 omeco webcontent OpenACS OpenCms openengine OpenIMS CMS 107 Oracle Universal Content Management 108 Ovidentia Papoo PHP-Nuke phpcms phpcomasy 0.8-RC2 113 phpwcms Plone Poociboo 116 PostNuke Powerslave ECMS QualiSite Redakto WCMS REDAXO RedDot Content Management Server RedFishCMS Rhythmyx Roxen CMS Saurus CMS Savvy Content Manager 127 SCMS flash SELBSTDENKER Frameworks Silva Simplicis Marketing Dashboard Sitecore SiteKreator Smartsite SR2 v step one Solution Server Taggon 137 TERMINALFOUR Site Manager Tikiwiki TIMETOWEB toendacms Tridion R5 142 TYPO3 - Version ubicms Tabla 7 (cont.). Sistemas donde son mencionados los CMS iniciales de CMS-SOM

112 Nº CMS CMS-Search Produktfinder CM-Overview CMS-Matrix 144 Vignette VIO.Matrix Visual Content Constructor 147 Vyre Unify WAXTRAPP Content Manager 149 web4biz Web500 CMS 151 webedition WebGUI WebHare Application Portal 154 WEBSITE-OBJECTS 155 wfdynamic Xaraya XIST4C CMS 158 Xitex WebContent M Xtive CMS Zeta Producer 7 Tabla 7 (cont.). Sistemas donde son mencionados los CMS iniciales de CMS-SOM En el anexo A5 se listan los 160 productos que resultaron seleccionados como CMS iniciales de CMS-SOM, las direcciones de las páginas web de sus fabricantes y sus países de origen. Como puede verse, Alemania, USA y los Países Bajos concentran aproximadamente dos tercios de los CMS resultantes (Fig. 55), lo que se debe a cierta correlación existente entre el origen de los sistemas de selección y el origen de los CMS que éstos comparan: Produktfinder y 52 CMS son de origen alemán, CMS-Matrix, CMS-Search y 34 CMS son estadounidenses, y CM-Overview es neerlandés como 19 de los CMS. El tercio restante está formado por CMS cuyos países de origen están dispersos por casi todo el mundo (Fig. 56) Alemania: 52 USA: 34 Países Bajos: 19 Suiza: 8 Australia, Reino Unido: 6 c/u Dinamarca, Suecia: 4 c/u Canadá, Francia: 3 c/u Argentina, Austria, Bélgica, Irlanda, República Checa, Noruega: 2 c/u Estonia, Finlandia, India, Italia, Japón, Nueva Zelanda, Rumania, Ucrania, Venezuela: 1 c/u Figura 55. Cantidad de CMS comparados en CMS-SOM (por país de origen)

113 Canadá: 3 USA: 34 Alemania: 52 Países Bajos: 19 Bélgica: 2 Reino Unido: 6 Irlanda: 2 Francia: 3 Suiza: 8 Italia: 1 Venezuela: 1 Argentina: 2 Dinamarca: 4 Austria: 2 Noruega: 2 Suecia: 4 Finlandia: 1 Estonia: 1 República Checa: 1 Ucrania: 1 Rumania: 1 India: 1 Australia: 6 Nueva Zelanda: 1 Japón: 1 Figura 56. Países de origen de los CMS comparados en CMS-SOM

114 4.5. Obtención de los datos de los CMS iniciales de CMS-SOM La obtención de los datos de los 160 CMS que resultaron elegidos para formar parte de la lista inicial de CMS-SOM se realizó siguiendo dos metodologías diferentes. En primer lugar, se intentó contactar a los fabricantes para solicitarles que colaboraran con este trabajo, a través del aporte de los datos referidos a sus CMS. Cuando no fue posible conseguir los datos de un CMS de la manera mencionada anteriormente, se emplearon distintas técnicas para buscar los datos de los CMS en la Web Solicitud de datos a los fabricantes A fin de facilitarles a los fabricantes el aporte de los datos referidos a sus CMS, se alojó un formulario online en (Fig. 57). El formulario mencionado tiene las siguientes propiedades: Está en inglés, ya que está dirigido a fabricantes de CMS de casi todo el mundo. Está formado por una única página web. De esta forma, se puede ver su longitud antes de comenzar a responder, evitando una posible frustración del visitante. Permite que los fabricantes informen acerca de las 400 características que definen a los CMS y, como el valor por defecto es NO, muchas respuestas ya están dadas de antemano. Permite que el fabricante se identifique a través de la casilla Code, con lo que se impide que cualquier visitante se haga pasar por el fabricante de un CMS. El botón SEND solicita la ejecución de un script 29 en el servidor, mediante el cual se graban las respuestas en un fichero en el servidor y también se las envía por correo electrónico a la dirección diegocorsi@gmail.com. Para solicitarles a los 160 fabricantes que aportaran los datos referidos a sus CMS, se le envió un mensaje de correo electrónico con un código distinto a cada uno de ellos. Las direcciones de los fabricantes se buscaron en las páginas web de los productos 30. A medida que las características de los CMS enviadas por los fabricantes fueron llegando, se las incorporó al fichero items.xml, el cual tiene la estructura mostrada en la figura Se trata del script answers.cgi, el cual fue programado en Perl, un lenguaje soportado por Netfirms. 30 Algunas veces, el mensaje se envió a través de un formulario de contacto provisto en la página web del producto

115 Figura 57. Formulario online para solicitar datos de CMS

116 Búsqueda de datos en la Web En aquellos casos en que no se obtuvo una respuesta positiva de los fabricantes, fue necesario buscar los datos de los CMS directamente en la Web. Para ello, se utilizaron las siguientes técnicas: Extracción automática de los datos disponibles en otros sistemas. Dos de los sistemas colocados en la Web con el fin específico de facilitar la selección de un CMS (CM-Overview y CMS-Matrix) muestran en forma de tablas las características de los productos seleccionados. El formato en que se encuentran estas tablas es HTML, pero utilizando herramientas adecuadas 31 fue posible extraer los datos y dejarlos expresados en XML. Después de realizar algunas correcciones, los datos pudieron ser incorporados automáticamente al fichero items.xml. Búsqueda manual de los datos disponibles en las páginas web de los productos. En aquellos casos en que los fabricantes no respondieron a la solicitud de datos, y los CMS sólo aparecían en los dos sistemas que no muestran en forma de tablas las características de los productos seleccionados (CMS-Search y Produktfinder), fue necesario buscar manualmente las características de los CMS, tanto en los resultados de las búsquedas realizadas con los sistemas mencionados, como en las páginas web de los propios CMS, para poder agregarlas al fichero items.xml Implementación de CMS-SOM CMS-SOM es el resultado de agregarle los ficheros items.xml (creado en la sección anterior) e index.html (una página de inicio estática) al sistema SOM genérico (Fig. 58). Figura 58. Ficheros de CMS-SOM alojados en MyJavaServer

117 La página de inicio index.html se muestra a continuación (Fig. 59): Figura 59. Página de inicio de CMS-SOM

118 Figura 59 (cont.) Página de inicio de CMS-SOM El siguiente fragmento del código HTML de la página de inicio index.html (Fig. 60) muestra que, al hacer clic en el botón Comenzar (líneas 14-16), se invoca el servlet FormularioServlet (líneas 01-03), al cual se le pasa, como parámetro oculto, el nombre del fichero XML del sistema (líneas 05-07)

119 01: <FORM ACTION=" 02: METHOD="post" 03: ENCTYPE="application/x-www-form-urlencoded"> 04: <P> 05: <INPUT TYPE="hidden" 06: NAME="archivo" 07: VALUE="/users/dcorsi/items.xml"> 08: <INPUT TYPE="hidden" 09: NAME="segundoServlet" 10: VALUE="/servlet/dcorsi.RedNeuronalServlet"> 11: <INPUT TYPE="hidden" 12: NAME="tercerServlet" 13: VALUE="/servlet/dcorsi.TablasServlet"> 14: <INPUT TYPE="SUBMIT" 15: CLASS="botonazul" 16: VALUE="Comenzar"> 17: </P> 18: </FORM> Figura 60. Fragmento del código HTML de la página de inicio index.html Finalmente, para no tener que acceder al sistema mediante la complicada URL 32, se registró en NIC Argentina el dominio diegocorsi.com.ar y se lo delegó a AwardSpace, un proveedor de servicios de Internet donde se alojó una copia de la página de inicio de CMS-SOM (Fig. 61). Figura 61. Ficheros de la página de inicio de CMS-SOM alojada en AwardSpace 32 En realidad, también sería posible acceder ingresando

120 De esta forma, para acceder a CMS-SOM basta con ingresar la URL en cualquier navegador web, como se muestra en la figura 62. Figura 62. Acceso a CMS-SOM desde

121 CAPÍTULO 5 RESULTADOS EXPERIMENTALES 5 En este capítulo se presentan y discuten los resultados experimentales utilizados para probar la validez del sistema CMS-SOM implementado en el capítulo anterior. En realidad, para probar la validez de CMS-SOM no fue necesario realizar tests a fin de verificar que el código fuente haya sido implementado correctamente, ni validar las funciones del sistema en base a los requisitos previos, debido a que CMS-SOM no es más que una aplicación específica del sistema SOM genérico que ya fue validado en la sección Por lo tanto, la experimentación que se presenta aquí fue llevada a cabo con el único objetivo de probar que los resultados que se obtienen mediante CMS-SOM son correctos. Vale recordar que, cuando el usuario ingresa alguna característica como Indistinto, se construyen dos mapas SOM, uno considerando todas las características posibles y otro considerando solamente las características requeridas, como ya se mostró en la figura 49. Por ello, hubo que verificar que ambos tipos de mapas fueran correctos Mapas SOM considerando todas las características posibles La validez de los mapas SOM construidos por CMS-SOM al considerar las 400 características posibles se determinó analizando algunos de ellos y verificando si la distribución de los CMS en cada mapa se puede reconocer como correcta. Para ello, se accedió cuatro veces al sistema CMS-SOM solicitando todas las características como Indistinto, y se obtuvieron los mapas SOM que se muestran en las figuras 63, 64, 65 y 66. En esos mapas SOM se marcó luego la ubicación de los siguientes tres grupos de CMS: Grupo 1: PHP-Nuke 8.0, PostNuke y Xaraya Grupo 2: Mambo y Joomla! Grupo 3: Drupal 4.7 y Typo3 - Version

122 Figura 63. Primer mapa SOM obtenido al considerar las 400 características posibles En esta figura puede verse cómo los CMS PostNuke y Xaraya (grupo 1) aparecen en la misma celda, mientras que PHP-Nuke 8.0 está en una celda cercana aunque no contigua. Los CMS del grupo 2 (Mambo y Joomla! ) aparecen juntos y, no lejos de allí, Drupal 4.7 y Typo3 - Version 4.0 (grupo 3) están ubicados en celdas contiguas

123 Figura 64. Segundo mapa SOM obtenido al considerar las 400 características posibles En la figura 5.2 se ve cómo los CMS del grupo 2 (Mambo y Joomla! ) aparecen juntos y, en la misma celda, también están PostNuke y Xaraya (grupo 1), mientras que PHP-Nuke 8.0 aparece en una celda cercana aunque no contigua. Bastante alejados de allí, Drupal 4.7 y Typo3 - Version 4.0 (grupo 3) aparecen en celdas contiguas

124 Figura 65. Tercer mapa SOM obtenido al considerar las 400 características posibles En esta figura puede verse cómo los CMS PostNuke y Xaraya (grupo 1) aparecen en la misma celda, y que PHP-Nuke 8.0 está en una celda contigua. Mambo y Joomla! (grupo 2), aunque no aparecen juntos, están ubicados en celdas contiguas. Drupal 4.7 y Typo3 - Version 4.0 (grupo 3), lejos de allí, también ocupan celdas contiguas

125 Figura 66. Cuarto mapa SOM obtenido al considerar las 400 características posibles En la figura 5.4 se observa que los CMS del grupo 1 (PHP-Nuke 8.0, PostNuke y Xaraya 1.1.2) aparecen en celdas contiguas, al igual que Mambo y Joomla! (grupo 2). En cambio, Drupal 4.7 y Typo3 - Version 4.0 (grupo 3) esta vez aparecen juntos en la misma celda

126 La distribución de los CMS en los mapas SOM presentados puede considerarse correcta, ya que los CMS de cada uno de los tres grupos permanecieron siempre juntos en las cuatro oportunidades, algunas veces en la misma celda, y otras veces en celdas contiguas o cercanas. Esto se debe a que los CMS de cada grupo poseen similares características, como se verá a continuación PHP-Nuke 8.0, PostNuke y Xaraya El hecho de que PHP-Nuke 8.0 y PostNuke posean similares características y que, por ello, hayan sido ubicados siempre juntos en el mapa por CMS-SOM, se debe probablemente a que PostNuke es un "fork" (es decir, una bifurcación) de PHP-Nuke y, como tal, se originó en el código fuente de éste, por lo cual, a pesar de incorporar numerosas mejoras, inevitablemente mantiene muchas de sus características. En Dev-Postnuke.com, uno de los sitios web oficiales de PostNuke, se puede verificar esta información (Fig. 67) Figura 67. Preguntas más frecuentes sobre PostNuke en Dev-Postnuke.com

127 Xaraya y PostNuke también son sistemas de características similares, por el mismo motivo mencionado en el caso anterior: Xaraya es una bifurcación de PostNuke. En el sitio web oficial de Xaraya hay abundante documentación sobre las cuestiones de compatibilidad surgidas luego de portar los módulos de PostNuke a Xaraya (Fig. 68). Figura 68 Documentación sobre la compatibilidad de Xaraya con PostNuke 33 Por último, puede suponerse que, por transitividad, también debería existir cierta similitud entre PHP-Nuke 8.0 y Xaraya 1.1.2, por ser el primero un ancestro del segundo, aunque, evidentemente, ésta debería ser menor que la existente entre ambos sistemas y PostNuke Mambo y Joomla! Los CMS pertenecientes al segundo grupo identificado en los mapas SOM también poseen características similares, y es por ello que se mantuvieron juntos en las cuatro pruebas realizadas. Se trata de Mambo y Joomla! La causa probable por la cual ambos CMS son similares, es que Joomla! surgió como una bifurcación de Mambo, el 1º de septiembre de 2005, como puede verificarse en la página oficial de Joomla! en castellano (Fig. 69) 33 Documentación: Compatibilidad hacia atrás de Xaraya con PostNuke - Una breve reseña. Autor: Marc Lutolf. Enviado el 14 de junio de Después de pasar algún tiempo portando módulos de PostNuke a Xaraya, pensé en hacer públicas algunas de las cosas con las que me he topado. La compatibilidad con PostNuke.7.1x no es uno de los objetivos primarios del proyecto Xaraya, pero es una meta declarada por la cual luchar, y en los últimos meses ha habido mucho progreso al respecto

128 Figura 69. Joomla! reconocido como bifurcación de Mambo Drupal 4.7 y Typo3 - Version 4.0 Al contrario de los casos anteriores, en los que algunos sistemas surgieron como bifurcación de otros, Drupal 4.7 y Typo3 - Version 4.0 son dos desarrollos independientes. Sin embargo, ambos aparecieron juntos en los cuatro mapas SOM generados. Intentando encontrar una explicación para este hecho, se realizaron dos búsquedas con Google en las cuales puede verse que Drupal y Typo3 realmente presentan una fuerte tendencia a aparecer juntos. Al buscar Drupal Typo3 (Fig. 70), se encontraron aproximadamente páginas web, las más relevantes con títulos como "Drupal versus Typo3", "Se busca desarrollador Drupal/Typo3" o "Typo3 vs. Drupal". La búsqueda de la combinación inversa Typo3 Drupal (Fig. 71) arrojó un resultado de aproximadamente páginas y títulos parecidos: "drupal and typo3 compared" 34, "Typo3 better than Drupal for community websites?" 35 o "They hate Drupal, they love Drupal. We use Drupal and Typo3 on more than a dozen sites" drupal y typo3 comparados 35 Typo3 mejor que Drupal para sitios web comunitarios? 36 Ellos odian a Drupal. Ellos aman a Drupal. Usamos Drupal y Typo3 en más de una docena de sitios

129 Figura 70. Resultado de buscar Drupal Typo3 en Google Figura 71. Resultado de buscar Typo3 Drupal en Google Evidentemente, no fue casual que CMS-SOM colocara a Drupal 4.7 y a Typo3 - Version 4.0 siempre en celdas próximas. Estudiando ambos sistemas en detalle, se encuentran muchas semejanzas: los dos están disponibles con la licencia GNU/GPL, su lenguaje de programación es el PHP, soportan varias bases de datos, entre ellas MySQL, así como los servidores web Apache e IIS

130 5.2. Mapas SOM considerando sólo características requeridas La validez de los mapas SOM construidos por CMS-SOM considerando solamente las características que le son requeridas se determinó analizando algunos de ellos y verificando que la distribución de los CMS en cada mapa fuera compatible con los resultados obtenidos al consultar los cuatro sistemas disponibles en la Web para facilitar la selección de un CMS: CMS-Search, Produktfinder, CM-Overview y CMS-Matrix. Para ello, se accedió al sistema CMS-SOM estableciendo como requerimientos los siguientes grupos de características: Primera prueba: Se solicitaron CMS que obligatoriamente fueran gratuitos y estuvieran basados en la tecnología LAMP (sistema operativo Linux, servidor web Apache, base de datos MySQL y lenguaje PHP). Segunda prueba: El objetivo fue seleccionar CMS con un precio obligatoriamente menor que USD 5 000, basados en la tecnología J2EE, que funcionaran con el servidor de aplicaciones IBM Websphere y que, además, preferentemente permitieran importar ficheros DOC y editar contenidos mediante la técnica WYSIWYG (what you see is what you get). Tercera prueba: La meta fue seleccionar CMS que obligatoriamente costaran entre USD y USD , estuvieran basados en la tecnología.net y usaran bases de datos MS SQL Server, y que preferentemente permitieran la publicación de versiones del contenido accesibles para usuarios con discapacidades. Cuarta prueba: Se solicitaron CMS que preferentemente no costaran más de USD 500, que estuvieran basados únicamente en el lenguaje Perl y fueran obligatoriamente compatibles con los sistemas operativos Linux y Windows Server 2003, que preferentemente ofrecieran una vista previa antes de publicar los contenidos y con los cuales obligatoriamente se pudieran realizar foros y encuestas. Quinta prueba: El objetivo fue seleccionar CMS que obligatoriamente estuvieran basados en la tecnología Zope, y en los cuales la generación de los documentos a publicar fuera realizada preferentemente por un Live Server. Sexta prueba: Se solicitaron exactamente las características del CMS Jahia

131 Búsqueda de CMS basados en LAMP La figura 72 muestra el ingreso de los requerimientos (el resto se dejó en Indistinto) Figura 72. Ingreso de los requerimientos para la primera prueba de CMS-SOM El mapa SOM obtenido con los requerimientos anteriores puede verse en la figura 73: Figura 73. Mapa SOM obtenido en la primera prueba de CMS-SOM

132 Debido a que los CMS ubicados en la celda correspondiente a los requerimientos efectuados resultaron ser relativamente numerosos (25 CMS), se orientará la atención hacia ellos y no se estudiará lo que ocurrió en las celdas adyacentes o cercanas. La tabla 8 muestra los CMS sugeridos por los cinco sistemas utilizados para la selección. CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM 1024 AJAX CMS 360 Web Manager 360 Web Manager 3.0 Absolut Engine CMS AdaptCMS Lite ARCOMA 2.0 Ariadne Ariadne Artikelwerk Attitude Adjustor Automne AWF b2evolution Back-End CMS beam:ware beam:ware 4 bloofoxcms Drupal ez Publish Managee CMS.R. COM.ON CMS conceptcms Contenido v4.4 Contrexx CMS D++CMS 3.1 Digital Workroom 5.3 E-CoMa ez publish Flux CMS Geeklog Joomla! 1.0 Midgard Campsite Drupal ez Publish Mambo Campsite Ciamos Clever Copy CMScout CSI_Meerkat DEV WMS Direct News Drupal enetwizard Server Esselbach Storyteller ExpressionEngine ezcontents FlexCMS gamecms Lite Geeklog Groupy Habari Joomla! Land Down Under Limeware CMS Mambo MDPro Midgard CMS MindTouch Wiki Tabla 8. CMS basados en LAMP Calimero.CMS 3.3 Campsite Contenido 4.6 Contrexx CMS Digital Workroom 5.3 Drupal 4.7 ez Publish Geeklog Joomla! Mambo Midgard

133 CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM Mini-CMS 0.3 MMS MNPnexus Netautor Pro nococoma v OneCMS openengine OpenPHPNuke OpenRat 0.8 opentimetool Open Publisher Ovidentia 3.4 Ovidentia Ovidentia papaya CMS 4.0 Papoo phpbb phpcms phpcomasy Tiki phpwcms Portalsuite Advanced REDAXO 3.1 smart edit SPIP step one 2007 toendacms v1.6 TYPO3 Poociboo Saurus CMS TYPO3 PHP-Fusion PHP Nuke phpwcms Poseidon PostNuke Psycms snews CMS SyntaxCMS TikiWiki CMS TYPO3 UNITED-NUKE Walnut CMS Wheatblog WikkaWiki wwedit PHP-Nuke 8.0 phpwcms Poociboo PostNuke step one 2006 Tikiwiki TYPO3 - Version 4.0 Xaraya XEDAQ X5 CMS Xoops ZeusCMS 4/73 = 5,4% 35/1419 = 2,4% 10/174 = 5,7% 55/873 = 6,3% 25/160 = 15,6% Tabla 8 (cont.). CMS basados en LAMP Lo primero que se observa es que el 15,6% de los 160 CMS considerados por CMS-SOM son CMS gratuitos basados en LAMP, lo que representa un porcentaje significativamente mayor que el 2,4 ~ 6,3% con que estos CMS están presentes en los resultados de los otros sistemas. Si se determinara, de los CMS existentes, el porcentaje que corresponde a los CMS gratuitos basados en LAMP, probablemente se llegaría a un número más cercano al arrojado por CMS-SOM

134 Los bajos porcentajes observados en los demás sistemas no se deben a que los CMS gratuitos basados en LAMP no figuran en sus registros, sino al hecho de que no son mostrados porque no coinciden con los criterios de búsqueda. Para justificar esta afirmación, vale recordar que 158 de los 160 CMS considerados en CMS-SOM figuran en los registros de dos o más de los otros cuatro sistemas, como se mostró oportunamente en la tabla 7. Sin embargo, entre los 25 CMS sugeridos por CMS-SOM en esta primera prueba hay 9 (Ariadne, beam:ware, Contenido, Contrexx, Digital Workroom, PHP-Nuke, Poociboo, PostNuke y step one) que fueron propuestos por uno solo de los demás sistemas. Al rastrear la causa de esta discordancia en los resultados, se detectó que la falla se originó por el deficiente ingreso de requerimientos ya mencionado con anterioridad en la sección 2.4. Por ejemplo, al solicitar en CMS-Matrix un CMS que corra bajo Linux, no resultan seleccionados los CMS que como valor de su característica "Sistema Operativo" tienen registrado "any" (que en inglés significa "cualquiera"). Además, hubo 4 CMS (Calimero, Mini-CMS, Papoo y Xaraya) que sólo fueron propuestos por CMS-SOM. Accediendo a las páginas web de estos productos, pudo verificarse que son CMS gratuitos basados en LAMP, por lo que fueron correctamente sugeridos por CMS-SOM e incorrectamente ignorados por dos o más de los otros sistemas Búsqueda de CMS basados en J2EE La figura 74 muestra el ingreso de los requerimientos (el resto se dejó en Indistinto) Figura 74. Ingreso de los requerimientos para la segunda prueba de CMS-SOM

135 En la figura 75 puede verse la parte más importante del mapa SOM obtenido a partir de los requerimientos anteriores (la celda de los requerimientos efectuados y sus adyacencias). Figura 75. Mapa SOM (vista parcial) obtenido en la segunda prueba de CMS-SOM Según muestra el mapa SOM, existen 3 CMS ubicados en la misma celda que los requerimientos efectuados (Liferay Portal, Magnolia y MMBase) y 6 CMS más se encuentran en tres de las celdas adyacentes (Oracle Universal CM en la celda de arriba a la izquierda, EPAM CMS y FeedStream QDoX en la celda de la derecha, y CuppaWeb, Simplicis Marketing Dashboard y SR2 en la celda de abajo a la derecha). La figura 76 permite observar que, de los CMS mencionados, apenas 5 califican, aunque solamente Liferay Portal cumple exactamente con los requerimientos efectuados, porque los otros 4 CMS no satisfacen una o más preferencias (o se desconoce si lo hacen). Figura 76. Tabla (vista parcial) obtenida en la segunda prueba de CMS-SOM

136 Comparar los resultados obtenidos mediante CMS-SOM en la segunda prueba con los que surgieron al consultar CMS-Search, Produktfinder, CM-Overview y CMS-Matrix no resultó ser una tarea trivial, ya que estos sistemas no permiten ingresar la totalidad de las características requeridas en esta prueba. En particular, los requerimientos que sólo son preferencias pero no son obligatorios, no deben ingresarse en estos sistemas, ya que siempre son considerados como características obligatorias. Por ejemplo, si en CM-Overview se hubiera ingresado la edición WYSIWYG como un requerimiento, el CMS Simplicis Marketing Dashboard no hubiera aparecido entre las sugerencias de este sistema. La tabla 9 muestra los CMS sugeridos por los cinco sistemas. CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM - Cimi 3.1 WCMS Corinis CCM flexive 2.1 glonz.com RedHat ECMS CuppaWEB Fatwire CS Magnolia MMBase ACM Ariadne Enonic VerticalSite EverSuite 3.9 Green Valley 5 NuContent 5.3 SchoolSitePro CuppaWEB Liferay Portal 4.2 Magnolia 3.01 MMBase Simplicis M Dashboard Simplicis M Dashboard TRIM Context WebGate Ae 0/73 = 0% 6/1419 = 0,4% 6/174 = 3,4% 6/873 = 0,6% 5/160 = 3,1% Tabla 9. CMS basados en J2EE Esta vez, CMS-SOM no posee la mayor relación entre el número de CMS que cumplen los requerimientos efectuados y el número de CMS considerados por el sistema, aunque su porcentaje de 3,1% no es significativamente menor que los 3,4% de CM-Overview que, además, es el único sistema con el que CMS-SOM produjo resultados en gran parte coincidentes (CuppaWEB, Magnolia, MMBase y Simplicis Marketing Dashboard). La falta de resultados de CMS-Search y la coincidencia nula entre las sugerencias de Produktfinder, CMS-Matrix y CMS-SOM podrían explicarse por el tipo de requerimientos efectuados, pero como, en realidad, los CMS sugeridos por CMS-SOM deberían aparecer entre los resultados de por lo menos otros dos sistemas y no lo hacen, vuelve a ponerse en evidencia que la verdadera causa reside en el problemático modo de ingreso de datos provisto por CMS-Search, Produktfinder y CMS-Matrix

137 Búsqueda de CMS basados en.net La figura 77 muestra el ingreso de los requerimientos (el resto se dejó en Indistinto) Figura 77. Ingreso de los requerimientos para la tercera prueba de CMS-SOM El mapa SOM obtenido con los requerimientos anteriores puede verse en la figura 78: Figura 78. Mapa SOM obtenido en la tercera prueba de CMS-SOM En la celda correspondiente a los requerimientos efectuados aparecen 10 CMS: activeweb contentserver 5.5, Applaud CMS 3.5, Clay Tablet Rosetta WCMS, Digimaker 5.2, EPiServer 4.60, Estrada Engine 3.5, Noxum Publishing Studio, Numotion WebManager, SR2 v7.0 y Web500 CMS

138 También en esta prueba, el elevado número de CMS obtenidos en la celda correspondiente a los requerimientos efectuados hace que no sea necesario estudiar los CMS de las celdas adyacentes, y puede considerarse satisfactorio el desempeño de CMS-SOM simplemente comparando la lista de los CMS que éste sugiere con los propuestos por los otros sistemas, como puede observarse en la tabla 10. CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM - <sitekit> CMS 2flex activeweb CS ActiveWeb CMS Acumium CMS activeweb CS 5.5 add.min CM Appix Express Applaud CMS Applaud CMS 3.5 AxCMS.net Beyond CM BeYourOwn.net BigJump Niagara CastManage Clay Tablet WCMS Clay Tablet Rosetta CMS Enterprise cmscribe Community Manager Composite CMS CONNEXUS V.4 ContentM contentxxl CMS DocuPortal.NET Intersim sitevision k-ontext cms KEY-TEC CMS nextshop CMS Noxum Studio EasySite EPiServer Estrada WebTech Idios Immediacy CMS IPROX Librios IMS Cucumber CMS Digimaker Dozing Dogs CMS Dynamicweb EPiServer CMS Feeleen Foxbright CMS Intellogy Kentico CMS 3.1 Microsoft CMS MimswareCMS MoST N2 CMS Digimaker 5.2 EPiServer 4.60 Estrada Engine 3.5 Noxum Studio Numotion Manager Tabla 10. CMS basados en.net

139 CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM - Orchestrate OXX Publisher 3 redcms(c) ECMS seven49.net - wcms SEVIWARE 3.73 Web500 CMS Pro 3.0 WebAuthor Enterprise 3 WideBight Wipcore 3.2 Info System Publish One Pythia Q-Publishing SiteRefresh RBC Contents redcms(c) sscms Synapse CMS Tangora Portal The WMS Web500 SR2 v7.0 Web500 CMS 0/73 = 0% 18/1419 = 1,2% 17/174 = 9,7% 32/873 = 3,6% 10/160 = 6,2% Tabla 10 (cont.). CMS basados en.net Al igual que en la primera prueba, ahora CMS-SOM sugirió algunos CMS que también fueron propuestos por al menos dos de los otros sistemas: activeweb contentserver 5.5, EPiServer 4.60 y Web500 CMS. La mayoría de las sugerencias de CMS-SOM, sin embargo, aparecieron como máximo en uno de los otros sistemas, tal es el caso de Applaud CMS 3.5, Clay Tablet Rosetta WCMS, Digimaker 5.2, Estrada Engine 3.5, Noxum Publishing Studio y SR2 v7.0. Además, un CMS (Numotion WebManager) fue sugerido sólo por CMS-SOM. Esta sugerencia se verificó con los datos disponibles y también resultó ser correcta. Para cada uno de los cinco sistemas, nuevamente se calculó la relación entre el número de CMS que cumplen los requerimientos efectuados y el número de CMS considerados, y esta vez se repitió el orden de la prueba anterior, con CMS-SOM ubicado detrás solamente de CM-Overview. Es interesante destacar que, una vez más, CMS-Search no arrojó ningún resultado, por lo que su relación es de 0%. Esto casi seguro se deba a algún defecto en su sistema de búsqueda, porque es muy poco probable que el resultado de las dos últimas pruebas se deba a la inexistencia de CMS con las características requeridas entre los CMS de su registro. Por la imposibilidad de expresar en CMS-Matrix un precio requerido de entre USD y USD , este sistema sugirió CMS basados en.net y que utilizan MS SQL Server, pero cuyos precios están fuera del rango solicitado (por ejemplo: Composite CMS, Kentico CMS y Microsoft CMS)

140 Búsqueda de CMS basados en Perl La figura 79 muestra el ingreso de los requerimientos (el resto se dejó en Indistinto) Figura 79. Ingreso de los requerimientos para la cuarta prueba de CMS-SOM

141 En la figura 80 puede verse la parte más importante del mapa SOM obtenido a partir de los requerimientos anteriores (la celda de los requerimientos efectuados y sus adyacencias). Figura 80. Mapa SOM (vista parcial) obtenido en la cuarta prueba de CMS-SOM En la celda de los requerimientos efectuados aparecen solamente dos CMS (Metadot Portal Server y WebGUI 7.0). En las celdas adyacentes aparecen otros tres CMS (a la izquierda Liferay Portal 4.2 y arriba a la derecha Hippo CMS y Silva 1.5.9). Como puede observarse en la figura 81, sólo los dos CMS que aparecen en la celda de los requerimientos efectuados los satisfacen, aunque sin una coincidencia total (la vista previa de los contenidos, que fue ingresada como una preferencia no excluyente, no es posible en Metadot Portal Server y se desconoce si es posible en WebGUI 7.0). Figura 81. Tabla (vista parcial) obtenida en la cuarta prueba de CMS-SOM

142 También en la cuarta prueba se encontraron algunos obstáculos al intentar ingresar los requerimientos en CMS-Search, Produktfinder, CM-Overview y CMS-Matrix. En este último sistema, por ejemplo, fue necesario ingresar "mod_perl" en la casilla "Application Server", ya que ingresando "Perl" en la casilla "Programming Language" no se obtuvieron resultados satisfactorios (en el campo correspondiente de los distintos CMS figuran valores con "Perl 5", "Perl 6", etc. y el sistema no es capaz de realizar una equiparación parcial). La tabla 11 muestra los CMS sugeridos por los cinco sistemas. CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM admin.tool Brightsite Drupal E-business Platfom ez Publish FileNet CM Jahia Lenya Managee Red Hat CMS SiteRefresh Tiki FIRMATIC CMS GERNOVA Interweb mycms v2.8 Red Hat ECMS tool1 Metadot Portal Server Gravity FactorCMS Level9 CMS MetaDot MKDoc NuContent nx-engine PHP-Fusion Scoop Metadot Portal Server TRIM Context WebGUI Weblication Classic WebSlave v3.10 WebGUI WebGUI 7.0 9/73 = 12,3% 9/1419 = 0,6% 2/174 = 1,1% 11/873 = 1,2% 2/160 = 1,2% Tabla 11. CMS basados en Perl La relación entre el número de CMS que cumplen los requerimientos efectuados y el número de CMS considerados permite hacer dos observaciones. Por un lado, Produktfinder, CM-Overview, CMS-Matrix y CMS-SOM indicaron que el 0,6 ~ 1,2% de los CMS que constan en sus registros cumplieron con los criterios de búsqueda, por lo podría suponerse que esa es la participación de este tipo de CMS en el mercado. Por otro lado, el alto valor calculado para CMS-Search (12,3%) llevó a que se analizara la lista sugerida, y el resultado fue que la mayoría de esos CMS, a pesar de haber sido propuestos por el sistema, en realidad no cumple con los criterios de búsqueda. En esta prueba, además, por primera vez todos los sistemas sugeridos por CMS-SOM también fueron propuestos por al menos dos de los otros sistemas

143 Búsqueda de CMS basados en Zope La figura 82 muestra el ingreso de los requerimientos (el resto se dejó en Indistinto) Figura 82. Ingreso de los requerimientos para la quinta prueba de CMS-SOM El mapa SOM obtenido con los requerimientos anteriores puede verse en la figura 83: Figura 83. Mapa SOM obtenido en la quinta prueba de CMS-SOM Dado que se ingresaron dos características y son tres los valores posibles de cada una (sí, no y se ignora), los CMS deberían distribuirse en los 9 grupos mostrados en la tabla 12. Marco de trabajo: Zope Generación instantánea CMS en el grupo sí sí Silva sí se ignora CS EMMS Suite 4.3, Easy Publisher 1.8, etc. sí no - se ignora sí - se ignora se ignora AIOCP - All In One Control Panel 1.3.8, etc. se ignora no - no sí Calimero.CMS 3.3, Contenido 4.6, etc. no se ignora 360 Web Manager 3.0, etc. no no C1, CuppaWEB 1.8.8, Digimaker 5.2, etc. Tabla 12. Grupos de CMS surgidos en la quinta prueba de CMS-SOM

144 Sin embargo, como tres de las combinaciones no corresponden a ninguno de los CMS, en el mapa SOM aparecen solamente 6 grupos de CMS. En la celda de los requerimientos efectuados aparece solamente un CMS (Silva 1.5.9), y en la celda adyacente de la derecha aparecen cuatro más (CS EMMS Suite 4.3, Easy Publisher 1.8, icoya OpenContent y Plone 2.5.1). Como puede observarse en la figura 84, apenas esos cinco CMS satisfacen los requerimientos efectuados, aunque sólo Silva lo hace completamente, ya que de los otros cuatro se desconoce si poseen la capacidad de generar en forma instantánea los documentos a publicar. Figura 84. Tabla (vista parcial) obtenida en la quinta prueba de CMS-SOM También como parte de la quinta prueba se realizó la consulta de CMS-Search, Produktfinder, CM-Overview y CMS-Matrix para comparar sus resultados con los de CMS-SOM. La tabla 13 muestra los CMS sugeridos por los cinco sistemas. CMS-Search Produktfinder CM-Overview CMS-Matrix CMS-SOM - Axiom Back-End CMS CPS CS EMMS Suite Easy Publisher 1.6 EZRO CS EMMS Suite 4.3 Easy Publisher 1.8 icoya OpenContent 2.5 Nuxeo Plone Plone and Zope Silva Plone 3.0 Silva 2.1.x Plone Silva WIS Zope zwook /73 = 4,1% 0/1419 = 0% 6/174 = 3,4% 6/873 = 0,6% 5/160 = 3,1% Tabla 13. CMS basados en Zope

145 Antes de analizar los porcentajes mostrados en la tabla 13, es necesario aclarar que Produktfinder no permitió realizar la búsqueda necesaria para esta prueba, debido a la ausencia de Zope entre las opciones de su menú "Technologie/Architektur", y que los valores de CMS-Matrix se obtuvieron ingresando "Zope" en la casilla "Application Server" y adicionalmente "Python" (el lenguaje de programación usado por Zope) en la casilla "Programming Language", ya que, de lo contrario, la lista obtenida contenía demasiados valores incorrectos. Nuevamente, la mayor relación entre el número de CMS que cumplen los requerimientos efectuados y el número de CMS considerados le correspondió a CMS-Search (4,1%). Sin embargo, salta a la vista que este sistema alcanza ese valor mediante la inclusión del propio Zope (que no es un CMS sino un servidor de aplicaciones) entre sus sugerencias. A continuación se ubican CM-Overview y CMS-SOM con 3,4% y 3,1%, respectivamente. La validez de las sugerencias de CMS-SOM queda confirmada al observar que, de los 5 CMS propuestos por este sistema, dos (Plone y Silva 1.5.9) aparecen en al menos dos de los demás sistemas, otros dos (CS EMMS Suite 4.3 y Easy Publisher 1.8) aparecen en al menos uno de los demás sistemas, y el restante (icoya OpenContent 2.5) está basado en Zope según la información que consta en la propia página web de sus fabricantes ( Búsqueda de CMS con las características del CMS Jahia En la sexta y última prueba de CMS-SOM, se ingresaron como preferencias los 400 valores que caracterizan al CMS Jahia. La figura 85 muestra la secuencia formada por estos valores. NNNSNNNSNNSSNSNNSNNNNNNSSNNNNNSNNSSSSSSSNNNNNSNSNN SSSSNSSSSSNNNSSSNNNNNNNSNNNSSNNSSSNNNNNNSSSNNNNNNN SNNNSSSSNNNNNNNNSNNNNNSNNNSNSNNSSNNNNNNNNNSSNNNSNN SSNNNNSSSNNSNNSNNSNNNNSNNNNNNNSNNNNSNSNNNNNNNNNNNN NNNNNNNNSSNNNNNSNNSNNNNNSNNNNNNNSNNNNNSSNNNNNNNSNN NNSSNNSSSSSSSSNNNNNNSNNNSSSSSNNNNNNNSSSSSSSNSSSNNN SSNNSSSSSSSSSSSSSSSSSSSSSNNNSSSSSSSSSSNNSNNNNNNSNS SSNNSSSSNNNSSSSSSSSSSNSSSSSSSNNNNSNNNSNNNNNNNNSNNN Figura 85. Requerimientos para la sexta prueba de CMS-SOM

146 la figura 86: El mapa SOM obtenido con los requerimientos anteriores puede verse por completo en Figura 86. Mapa SOM obtenido en la sexta prueba de CMS-SOM

147 La figura 87 muestra ampliada el área de la celda de los requerimientos efectuados. Figura 87. Mapa SOM (vista parcial) obtenido en la sexta prueba de CMS-SOM Parte de la tabla correspondiente al mapa SOM anterior puede verse en la figura 88. Figura 88. Tabla (vista parcial) obtenida en la sexta prueba de CMS-SOM