De MorfeoWiki

Tabla de contenidos 1 Entregables 2 D.5.2.1 Definición del escenario 2.1 Planteamiento 2.2 Introducción 2.3 Definición del escenario 2.3.1 Identificación de aplicaciones relevantes 2.3.2 Análisis de la interconectividad modular 2.3.3 Selección de prototipos operacionales para la evalucación de la plataforma 3 D.5.2.2 Diseño de la Arquitectura del Sistema Operacional y de Negocio en grandes empresas 4 D.5.2.3 Implementación del Sistema de soporte Operacional y de Negocio en grandes empresas 4.1 Elección de las tecnologías 4.1.1 MyYahoo 4.1.2 NetVibes 4.1.3 POSH de Portaneo 4.2 Implementación 4.2.1 Plataforma NetVibes 4.2.1.1 Gadget "Búsqueda de artículos" 4.2.1.2 Gadget "Gestión de artículos" 4.2.2 Plataforma IGoogle 4.2.2.1 Gadget "Login" (Cliente) 4.2.2.2 Gadget "Alta de Usuarios" (Cliente) 4.2.2.3 Gadget "Supermercados" (Cliente) 4.2.2.4 Gadget "Mapa" (Cliente) 4.2.2.5 Gadget "Publicidad" (Cliente) 4.2.2.6 Gadget "Datos" (Cliente) 4.2.2.7 Gadget "Login Empleados" (Empleado) 4.2.2.8 Gadget "Alta de Empleados" (Empleado) 4.2.2.9 Gadget "Lista de Artículos" (Empleado) 4.2.2.10 Gadget "Inventario" (Empleado) 4.2.2.11 Gadget "Ventas" (Empleado) 4.3 Instrucciones de uso 4.3.1 Plataforma NetVibes 4.3.1.1 Gadget "Búsqueda de artículos" 4.3.1.2 Gadget "Gestión de artículos" 4.3.2 Plataforma IGoogle 4.3.2.1 Gadget "Login" (Cliente) 4.3.2.2 Gadget "Alta de Usuarios" (Cliente) 4.3.2.3 Gadget "Supermercados" (Cliente) 4.3.2.4 Gadget "Mapa" (Cliente) 4.3.2.5 Gadget "Publicidad" (Cliente) 4.3.2.6 Gadget "Datos" (Cliente) 4.3.2.7 Gadget "Login Empleados" (Empleado) 4.3.2.8 Gadget "Alta de Empleados" (Empleado) 4.3.2.9 Gadget "Lista de Artículos" (Empleado) 4.3.2.10 Gadget "Inventario" (Empleado) 4.3.2.11 Gadget "Ventas" (Empleado) 5 D.5.2.4 Evaluación del Sistema de soporte Operacional y de Negocio en grandes empresas 5.1 Conclusiones 5.1.1 Comparación de plataformas 5.1.2 Implementación de gadgets utilizando la plataforma mashups de Netvibes 5.1.3 Inconvenientes encontrados en el uso de la plataforma Netvibes: 5.2 Líneas futuras

Entregables

• D.5.2.1 Definición del escenario

• D.5.2.2 Diseño de la Arquitectura del Sistema Operacional y de Negocio en grandes empresas

• D.5.2.3 Implementación del Sistema de soporte Operacional y de Negocio en grandes empresas

• D.5.2.4 Evaluación del Sistema de soporte Operacional y de Negocio en grandes empresas

D.5.2.1 Definición del escenario

Planteamiento

• Se trata de estudiar el Marketplace de soluciones que soporta la operativa de negocio de las grandes cuentas.
• Este estudio se centra principalmente en los elementos operacionales, característicos y diferenciadores de este tipo de sociedades, a los cuales les infieren unas necesidades computacionales distintas de las de las PYMEs y microempresas.
• Se reutilizarán y ampliarán los Gadgets desarrolladores en el WP5.1, añadiendo nuevos módulos específicos y habituales en grandes empresas, pero que cada vez son más demandados por las PYMES a medida que aumentan sus necesidades y su negocio va creciendo.
• Este planteamiento proporciona la suficiente moduladidad para que cada empresa construya y utilice la plataforma según la complejidad de su sector de mercado.

Introducción

Actualmente los ERP pueden ser vistos como soluciones de tecnologías de la información que permiten integrar los procesos de la empresa.

Estos productos son modulares y ofrecen capacidades para logísticas integradas, ventas, procesos de órdenes, producción y control de los recursos materiales.

Las organizaciones pueden escoger implementar uno o varios módulos dejando otros para implementaciones futuras en función de sus necesidades y su crecimiento.

Un sistema para la gestión de los recursos de la empresa comprende la integración de todos los paquetes de software que gestionan la información que fluye a través de la compañía: financiera, contable, recursos humanos, la cadena de proveedores y la información del cliente.

El éxito del ERP está determinado por los beneficios operacionales y estratégicos que aportan ciertas consideraciones en la implementacion:

• Entrada de la información al sistema solo una vez.
• Customización.
• Proporcionar funcionalidad para interactuar con otros módulos.
• Proporcionar herramientas para consultas complejas.

Definición del escenario

Identificación de aplicaciones relevantes

El operativo de una gran empresa necesita integrar la información que se encuentra almacenada en los diferentes sistemas disponibles, pasando a formar parte de un único Sistema integrado de Gestión (ERP).

Los requisitos generales que debería soportar este operativo son:

Desde el punto de vista funcional

Requerimientos del área Económico Financiera

• Registros de facturas (o IVA, de compra, de venta).
• Contabilidad según Plan General Contable (Diario, Sumas y Saldos periódicos, Balances de Situación y Explotación).
• Gestión de cobros y pagos.
• Resúmenes sobre impuestos: IVA, retenciones, etc.
• Permitir obtener cuentas de resultado analíticas por unidad de negocio, línea de negocio, línea de producto y por proyecto y/o producto.
• Creación de un Cuadro de Mando para la Dirección.
• Informes de actividad, facturación, ingresos, costes y evolución comparando con distintos períodos, desglosando en Unidades de Negocio, Línea de Negocio, Línea de Producto y Proyecto.
• Posibilidad de crear balance y cuenta de pérdidas y ganancias a nivel global de toda la compañía, por unidades de negocio y por líneas de negocio.
• Gestionar , de manera eficiente, las necesidades ámbito legal, presupuestario y fiscal.
• Ofrecer información sobre datos de actividad.

Requerimientos del proceso de facturación

• Emitir facturas por proyecto y/o producto y/o cliente (configuradas y formato libre).
• Emitir abonos por proyecto y/o producto y/o cliente (configuradas y formato libre).
• Mantenimiento de facturas, posibilitando modificar o borrar.
• Posibilidad de realizar diferentes series de facturación.
• Emitir facturas y abonos con diferentes tipos de IVA (tipo de IVA abierto).
• Posibilidad de asignar los proyectos y/o productos y/o clientes a Líneas de Producto.
• Posibilidad de asignar los proyectos y/o productos a Líneas de Negocio.
• Posibilidad de asignar los proyectos y/o producto y/o clientes a Unidades de Negocio.
• El sistema debe permitir emitir facturas de un proyecto y/o producto y/o cliente con cargo a diversas Líneas de Negocio o Unidades de Negocio.
• Emitir facturas parciales o totales del proyecto y/o Producto y/o cliente.
• Posibilitar facturar por hitos del proyecto y/o servicio o en función de niveles de avance del mismo.
• Posibilidad de facturar de forma global o por partidas.
• Permitir el registro y aplicación de datos de actividad para aplicarlos a facturaciones de proyectos y/o productos (a precio de coste o aplicando el margen).
• Permitir el registro y aplicación de gastos derivados y/o adquisiciones asociadas a un proyecto susceptibles de facturación a ese proyecto y/o un cliente. El gasto debe facturarse a coste o con margen (profesionales independientes, comisiones de servicio…).
• Posibilidad de guardar los datos maestros de los clientes, así como de los pedidos que se les ha hecho anteriormente.
• Permitir dar de alta proyectos por parte de la unidad de negocio interesada como paso previo a la facturación de un proyecto y/o producto. El proyecto contendrá información sobre cliente, proponente, descripción de las tareas a realizar, finalidad del proyecto, recursos técnicos y humanos necesarios (presupuesto de gastos), estimación de los ingresos que generará etc....
• Asignar una codificación de proyecto
• Crear distintos status por los que debe pasar una oportunidad o proyecto.
• Workflow para que el Responsable de Negocio correspondiente o el Director General en su caso, si es un proyecto deficitario o requiere nuevo personal, aprueben la ficha de proyecto mediante firma electrónica o proceso similar.
• Workflow para que el Responsable del Área Económica firme la propuesta de facturación y la factura emitida (firma electrónica o proceso similar).
• Informe de relación de proyectos (Unidad de Negocio, Línea de producto, ingresos, costes , actividad, codificación..etc..)
• Relacionar el proyecto con un contrato, acuerdo, convenio, pliego, encomienda,…Ambos documentos deberán poder relacionarse en el sistema entre sí y con la facturación posterior que se realice.
• El sistema debe posibilitar que para llevar a cabo una facturación, se deba cumplimentar un formato de propuesta de facturación (codificado en el sistema) que indicará los datos necesarios para llevar a cabo la facturación. Este formato deberá permitir una ruta de aprobación (firma electrónica o similar).
• Permitir que la contabilización de las facturas se realice de forma automática, paso previo de chequeo de la información por parte del responsable del área económica.
• Posibilidad de que cada uno de los proyectos y/o productos y/o clientes lleve asociada sus cuentas de ingresos y de gasto y/o coste con el fin de generar automáticamente la contabilidad.
• Permitir que los proyectos que se facturen íntegramente al final del contrato puedan periodificarse en función del nivel de alcance del mismo, o según el criterio que se establezca.
• Informe de facturas emitidas por proyecto
• Informe de facturas emitidas por cliente
• Informe de proyectos facturados por cliente
• Informe de facturas de proyectos por línea de producto
• Informe de facturas de proyectos por líneas de negocio
• Informe de facturas de proyectos por Unidad de negocio
• Informe de actividad facturada y planificada por proyecto y/o producto, por cliente, por línea de producto, por línea de negocio, por Unidad de Negocio.
• Permitir obtener un catálogo de los proyectos y/o productos existentes, con todas sus características.
• Permitir obtener la planificación económica de la ficha del proyecto y su comparación con reales.
• Posibilidad de exportar a las herramientas de alta implantación en el mercado cualquier información para elaborar diferentes informes.
• Posibilidad de que existan otros centros de coste, donde se imputará costes indirectos que se repartirán aplicando diferentes criterios de reparto (nº de empleados, consumos, actividad, ingresos…).
• Posibilidad que los centros de apoyo puedan repercutir un precio a las Unidades de Negocio. Este precio podrá determinarse a partir de un coste o algoritmo, pudiendo tener la posibilidad de añadir un margen.
• Permitir que se puedan introducir datos de actividad de los trabajadores (horas, meses….), de instalaciones, consumos, número de personas, etc.…, lo que permitirá que a partir de estos datos, se puedan crear relaciones con criterios de imputación de costes.
• El sistema debe posibilitar realizar simulaciones de diferentes escenarios de distribución de ingresos y gastos.

Requerimientos generales de Contabilidad

• Consolidar estados financieros.
• Periodificaciones y desperiodificaciones automáticas de un gasto, previo chequeo del apunte contable si la mercancía o el servicio ha sido recepcionado.
• Posibilidad de amortizar determinados elementos del inmovilizado por horas de actividad del elemento.
• Realizar previsiones de tesorería.
• Realizar conciliaciones bancarias de forma automática.
• Registrar diferentes tipos de operaciones con los activos: adquisición, amortización, apreciación, depreciación, provisión, venta y baja contable.
• Definir un número ilimitado de libros de amortización para cada activo, que permitirá satisfacer las necesidades contables internas, los criterios fiscales y las normas contables internacionales.
• Ubicar los activos en las localizaciones que se establezcan (unidades, áreas, etc.) y asignar a éstas el coste de amortización.
• Bajas, cesiones o ventas parciales de activos.
• Realizar diversos escenarios de presupuestos, ofreciendo la posibilidad de comparar los presupuestos reales con los diferentes modelos de presupuestos que se establezcan y obtener las correspondientes desviaciones.
• Posibilidad de realizar presupuestos por unidades de negocio, por líneas, por proyecto y en conjunto de la Sociedad.
• Trabajar con múltiples presupuestos.
• Debe considerar las Normas Internacionales de Contabilidad (NIC).
• Informes de IVA e IGIC detallado por compras y por inversiones.
• Informe de IVA Intracomunitario, con documento equivalente.
• Declaración de IVA e IGIC.
• Declaración del Impuesto de Sociedades.

Gestión de Cobros

• Generar alertas en el caso de vencimiento de avales.
• Extraer listados de las facturas de profesionales independientes introducidas en el sistema, con datos fiscales del profesional, base sobre la que se aplica la retención, tipo de retención y cuota.
• El sistema no podrá permitir la introducción de ninguna factura de profesionales independientes, una vez que el Departamento de Recursos Humanos haya realizado el cierre de IRPF.
• Enviar alertas de que existen facturas de clientes ya vencidas, carta automática de reclamación del cobro.
• Generar una carta automática de reclamación de un cobro vencido.
• Informe de morosos.
• Informe para realizar verificación de facturas con el fin de relacionar éstas con los cobros recibidos.

Gestión de Pagos

• El sistema deberá proporcionar la funcionalidad básica necesaria para generar un Plan Contable y registrar en diarios contables requeridos legalmente: plan de cuentas, diarios generales, IVA, diarios periódicos y códigos de origen, retenciones y declaración del volumen de operaciones anuales con terceros.
• Informes contables base para la empresa.
• El sistema debe ser capaz de realizar apuntes contables predeterminados (plantillas).
• Posibilidad que el sistema automatice los apuntes contables que se realizan mensualmente, previo chequeo de los mismos por parte del departamento económico-financiero.
• Se debe considerar cualquier forma de pago.
• Realizar pagos por los bancos con soportes magnéticos normalizados.
• Posibilidad de casar los anticipos (clientes o proveedores/acreedores) con la factura cuando llegue.
• Pago automático de facturas cuando estén domiciliadas.
• Workflow de aprobaciones de órdenes de pago con varios niveles.
• Contabilizar las facturas en base a los datos aportados, imputando a gasto o inversión.
• Posibilidad de que el sistema envíe alertas de fecha de vencimiento de las facturas.

Gestión de Compras

• Registros de presupuestos y relación con el proceso de contratación administrativo.
• Creación de Registro de proveedores.
• Control de licitadores en relación a los correspondientes Pliegos.
• Relacionar el presupuesto con el pliego correspondiente. Ambos documentos deberán poder relacionarse con en el sistema entre sí , con la facturación posterior que se realice, y con el proceso jurídico de contratación.
• Recepción y registro de ofertas.
• Sistema de recepción y respuesta ágil de dudas sobre pliegos.
• Procesos de respuesta a adjudicatarios y no adjudicatarios, relación con área jurídica.
• Integración total con la Contabilidad General, a través de las cuentas de mayor asociadas. Será necesario especificar para cada proveedor la cuenta de mayor en la que se reflejará su saldo, a nivel de Contabilidad General.
• Registro de contratos. Seguimiento y control en relación al área técnica correspondiente.
• Realización y seguimiento de los pedidos.
• Demoras en las entregas
• Reclamaciones de entregas.
• Al registrarse cada entrada se actualizará el stock del almacén.
• Al producirse la contabilización de una factura, el sistema debe actualizar automáticamente el saldo de la cuenta del proveedor o acreedor manteniendo el vínculo con las partidas del documento que se ha contabilizado. Esto permite ver el estado de la cuenta del proveedor o acreedor visualizando su saldo contable y desglosándolo en las partidas que lo componen, hasta llegar al documento contable.
• La verificación y conformación de las facturas se realizará a partir de la información del circuito de compras a partir del albarán de recepción de material. Caso de no existir el circuito logístico será de introducción directa de la factura para su registro, creación de asiento automático así como del efecto de pendiente de pago.
• Introducir en los documentos tanto artículos con stock físico como artículos ficticios o servicios.
• Realización de consultas relacionadas con los distintos documentos (pedido, albarán,…).
• Trazabilidad documental.
• Control de la subcontratación de servicios y fabricación de artículos.

Gestión de Almacén

• Relación de albarán con factura.
• Gestión de stock (precio medio, ponderado y precio real).
• El sistema debe permitir la impresión de albaranes de entrada y salida de materiales/productos.
• Identificar los materiales/productos a través de su "part number".
• Asignar a ciertos materiales/productos un stock de seguridad.
• Utilizar números de serie para identificar unívocamente productos concretos.
• Posibilidad de conocer el historial de los productos.
• Posibilidad de realizar solicitudes de compra.
• Informes para poder comparar (en función del precio, plazo de entrega, etc.) la respuesta de los distintos proveedores/acreedores a las solicitudes de compra y de intercambio.
• Workflow de aprobaciones con unos o varios niveles, según el coste, para aprobar un gasto asociado a una orden de pedido.
• El sistema debe facilitar la creación de solicitudes de oferta a proveedores/acreedores.
• Guardar los datos maestros de los proveedores/acreedores, así como de los pedidos que se les ha hecho anteriormente.
• Posibilidad de consultar el ciclo de vida del producto (compra/venta).

Desde el punto de vista de la Seguridad

El sistema de Gestión (ERP) deberá contar con sistemas de auditoria, protección de información, log de registros de todos los movimientos, acceso seguro etc...

Debe disponer de una metodología, política y demás detalles referidas a las prácticas de backup y recuperación de la información.

Análisis de la interconectividad modular

La globalización actual hace que las organizaciones sean operadas en una escala global, con múltiples sitios de fabricación, distribución y socios situados alrededor del mundo.

• Las aplicaciones ERP deben gestionar y optimizar el concepto de cadena de suministros.

• Deben posibilitar la integración de diferentes topologías de tecnologías de información (TI) y protocolos de transmisión electrónica de datos (EDI), a través de las empresas.

• El potencial de este tipo de sistemas reside en la capacidad de organizar las diferentes unidades de negocio que utilizan diferentes procesos operacionales y de producción, usando además diferentes lenguajes y monedas.

• El sistema ERP debe ser fácilmente configurable y adaptable a la estructura particular de cada organización, soportando operaciones multi-sitio, centralizadas o descentralizadas, ayudando a la organización a integrar toda la información a través de sus módulos, interrelacionandolos entre sí.

El ERP es una forma de modelar el flujo de información en los negocios, ya que este beneficia el intercambio de información entre sus divisiones. Constituye una red de todos los sistemas de la organización, incluyendo las herramientas administrativas, producción, etc.

Los principales motivos para instalar un software ERP son dos: la necesidad de contar con datos más precisos y actualizados, e información íntegra y fiable, además de la necesidad de simplificar y unificar los procedimientos de los diferentes departamentos.

Estos sistemas de administración corporativa de recursos cuentan con funciones que integran la información del negocio y los procesos de gestión:

• Mejorando la comunicación con los inversores.
• Colaborando con clientes y proveedores en las actividades de pago y liquidación.
• Reducciendo los costos de transacción y aumento de la eficiencia operativa.
• Integrando la información entre diferentes áreas.
• Disponibilidad de información de forma inmediata para la toma de decisiones.
• Incremento en la productividad.
• Mejora de los tiempos de respuesta.
• Rápida adaptación a los cambios.
• Escalabilidad del sistema.
• Integridad de los datos.
• Seguridad definida por el usuario para el manejo de información.

La herramienta ERP es una reorganización de la empresa en sus procesos y en la forma de manejar la información dentro de la organización.

Selección de prototipos operacionales para la evalucación de la plataforma

Se trata de desarrollar aplicaciones totalmente accesibles para el usuario final, siendo además adaptables y fácilmente manejables.

Se tendrá en cuenta su uso por parte de personas sin experiencia en tecnologías de la información.

Resulta indispensable considerar la elevada velocidad requerida en las aplicaciones y en el acceso a los datos.

En cuanto a su usabilidad, destacará la ausencia del uso de periféricos ajenos al teclado para ejecutar todas las funcionalidades.

Serán, además, aplicaciones síncronas y perfectamente comunicadas entre ellas.

Asimismo, se tienen en cuenta, de forma exhaustiva, todos los requisitos establecidos en el documento D 1.1.1.

• Reutilización de los gadgets especificados en el “WP 5.1: PYMES”

• Alta de usuarios

Aplicación que permite dar de alta nuevos usuarios, otorgando privilegios de acceso a recursos y funcionalidades. Se complementará el registro con parámetros adicionales propios del usuario (tipo de usuario, fecha de alta en la aplicación, ...).

• Identificación y gestión de empleados

Identificación del empleado mediante la introducción de usuario y clave. A partir del registro realizado quedan registradas las características del usuario (hora de registro, localización, hora de desconexión...). Una vez registrado un usuario, se permite el acceso o restricción a una serie de recursos (en función de sus características y privilegios registrados con anterioridad). Por ejemplo, mientras que una cajera puede acceder solamente a sus estadísticas personales, un gerente de la empresa podría acceder a las estadíticas de todas las cajeras.

• Fidelización de clientes

El empleado introduce un código de identificación del cliente (DNI, PIN,...). Una vez que el cliente está identificado, el gadget pemite modificar automáticamente la información perteneciente al mismo (puntos obtenidos,...) en función de la acción realizada (compra, solicitud de entrega a domicilio,...). Este gadget alimenta al de ticketing, identificando los usos y costumbres del cliente, permitiendo explotar estos datos para un gadget de estadísticas de cliente y para un gagdet de propuesta de “Carro de compra”.

• Estadísticas de clientes

Visualiza los totales de venta por cliente. Estadísticas realizadas a partir de una característica propia del cliente frente al tiempo (Ejemplo: número de elementos comprados el último mes, puntos de cliente en la última quincena...). Las características se pueden obtener a partir de los elementos que forman los tickets asociados al cliente (elementos que se han comprado en cada ticket, fecha de la compra, gasto total por ticket...) y las características propias del usuario creadas por otros gadgets. Permite explotar distintos niveles de detalle y agrupación. Permite generar una selección de tickets para ser utilizados por otros gadgets (Gestión de Tickets, Impresion de Tickets).

• Propuesta de “Carro de compra”

Recibe un código de cliente, por teclado o salida de otro gadget, y nos facilita la lista de los últimos tickets del cliente. La selección de uno o varios de estos tickets generará una propuesta de artículos a adquirir. Este gadget puede ser utilizado en un terminal independiente del TPV, donde el cliente pueda acceder a esta información. El TPV también puede utilizarlo, para indicar al cliente los artículos que habitualmente adquiere y no están en el ticket actual.

• Inventario

Después de la introducción del código interno de uno o varios artículos (mediante teclado o salida del gadget de búsqueda de artículos) se nos solicita la cantidad actual del producto en el establecimiento.

• Stock

Nos muestra el stock actual (teórico) de los artículos seleccionados, calculado a partir del dato del último inventario y teniendo en cuenta las entradas y salidas de mercancías (venta). Indica los días que cubre este stock, en función del promedio de ventas del artículo, así como del periodo de aprovisionamiento del producto y la cantidad del producto óptima de pedido.

• Pedido

Permite introducir la cantidad solicitada del producto, apoyándonos en los gadgets de búsqueda de artículos y stock.

D.5.2.2 Diseño de la Arquitectura del Sistema Operacional y de Negocio en grandes empresas

• Alta de usuarios

• Identificación y gestión de empleados

• Fidelización de clientes

• Estadísticas de clientes

• Propuesta de “Carro de compra”

• Inventario

• Stock

• Pedido

D.5.2.3 Implementación del Sistema de soporte Operacional y de Negocio en grandes empresas

Elección de las tecnologías

Un requisito indispensable para realizar una implementación de un marketplace de resoluciones ERP para Gran Empresa es un exhaustivo análisis de las plataformas mashup existentes en la actualidad. Puntos claves en la evaluación de las mismas serán: la capacidad de utilización de gadgets creados en otras plataformas, representación conjunta de gadgets, catalogación, comunicación entre gadgets y mecanismos de seguridad existentes. A continuación se describen distintas plataformas evaluadas:

MyYahoo

Se trata de una plataforma mashup de tipo presentacional con un funcionamiento a través de 'Módulos' (tipo GoogleIG). Permite el uso de módulos de tipo sindicación (feeds RSS) y de módulos de servicios ligeramente más avanzados creados por Yahoo. Permite la personalización de la página principal mediante la colocación de los diferentes módulos. Entre sus características principales se puede distinguir:

Características

• Funcionamiento a través de Módulos
  • Tipos de Módulos
    • Feed RSS para sindicación de contenidos
    • Módulos con otro tipo de servicios creados por Yahoo (horóscopo, tiempo, etc)
  • Características técnicas
    • Agregación de feeds RSS
• Presentación de gadgets en pantalla
  • Necesario uso de navegador Web
  • Distribución en pestañas
  • Recolocación en pantalla en rejilla con número configurable de columnas
• Funcionalidades de búsqueda y catalogado de Módulos
  • Catalogado de Módulos
    • Búsqueda
    • Distribución en categorías (fijas, establecidas por Yahoo)
    • Posibilidad de agregación de feeds RSS externos

Valoración

Teniendo en cuenta las características descritas para la plataforma My Yahoo se puede concluir lo siguiente: La plataforma MyYahoo sólo permite el uso de servicios desarrollados por la propia Yahoo y la agregación y sindicación de feeds RSS propios. Carece de la posibilidad de integrar módulos propios con funcionalidades más allá de la sindicación de contenidos, con lo que no cumple los requisitos mínimos para el desarrollo de un TPV sobre la plataforma. Dentro de la plataforma Yahoo existen también tecnologías de gadgets pero orientadas a su uso en escritorio y no a su utilización mediante mashup Web.

NetVibes

Se trata de una plataforma mashup de tipo presentacional, con un funcionamiento a través de 'Gadgets' (tipo GoogleIG). Permite el uso de gadgets de tipo sindicación (feeds RSS), calendario y podcast, así como la creación de gadgets propios utilizando una API dispuesta para ello. Los gadgets pueden ser recolocados y dispuestos en pestañas. Adicionalmente se permite su búsqueda y catalogación. Entre sus características principales se puede distinguir:

Características

• Funcionamiento a través de Gadgets
  • Tipos de gadget:
    • Feed RSS para sindicación de contenidos.
    • iCal para compartición de calendarios.
    • Podcast para sindicación de audio y vídeo.
    • Creación de gadgets propios.
  • Características técnicas:
    • Creación mediante el uso de XHTML + CSS + JavaScript
    • Utilización del API UWA que permite compatibilidad con Google IG, Apple Dashboard y Opera Widgets.
      • Funcionalidades para comunicación con orígenes de datos Web vía asíncrona (AJAX)
        • Obtención directa de feeds RSS
        • Obtención de datos en texto plano
        • Obtención de datos en formato XML
        • Obtención de datos en formato JSON
      • Permite la ejecución de los gadgets en solitario (sin necesidad de plataforma NetVibes) a efectos de pruebas.
      • Utilización de Javascript limitada.
      • Permite la especificación de preferencias para cada gadget
      • Necesario el uso de navegador web salvo en el caso de Apple Dashboard
• Presentación de gadgets en pantalla
  • Necesario uso de navegador Web
  • Distribución en pestañas
  • Recolocación en pantalla en rejilla con número configurable de columnas
  • Permite el uso de atajos de teclado
• Funcionalidades de búsqueda y catalogado de gadgets
  • Catalogado de gadgets mediante 'ecosistemas'
    • Búsqueda de gadgets
    • Distribución en categorías (fijas, establecidas por NetVibes)
    • Agrupación de gadgets tipo feed RSS con información común en 'Universos'.

Valoración

Teniendo en cuenta las características descritas para la plataforma NetVibes se puede concluir lo siguiente:

La plataforma NetVibes permite la creación de gadgets mediante una infraestructura propia basada en el API UWA, permitiendo la reutilización de dichos gadgets en otras plataformas. El API ofrece una forma estructurada de crear gadgets que funcionan individualmente. La plataforma provee de la capacidad de representación conjunta de los gadgets, colocación y catalogación.

Sin embargo las capacidades de uso de JavaScript están reducidas y no se permite la comunicación entre gadgets. Además no se ofrece ningún tipo de información o implementación que sirva de referencia de los servicios de back-end con los que se comunicarían los gadgets. Esto implica que en el caso particular de la creación de gadgets con el propósito de la creación de un TPV haya que diseñar cómo serán los servicios que se consuman, requiriendo un esfuerzo adicional y limitando la posible reutilización.

Las limitaciones anteriormente mencionadas hacen necesario que toda la lógica de comunicación y estado deba de ser almacenada en servidores web propios, de forma que dicha información pueda ser accedida mediante los gadgets. Además, la plataforma no ofrece mecanismos de seguridad ni de aislamiento del entorno de ejecución (el navegador), que permitan cumplir algunos de los requisitos del caso de uso descrito para Gran Empresa.

Por lo tanto, la plataforma NetVibes proporciona al menos unas funcionalidades mínimas que pueden ser aprovechadas para la creación de los gadgets en el caso de uso de Gran Empresa, si bien existirán algunas limitaciones que deberían de ser cubiertas por la plataforma final. La implementación inicial de los gadgets servirá además para pulir el conjunto de requisitos que deberá soportar la plataforma EzWeb.

POSH de Portaneo

La plataforma POSH es un portal personalizable al estili de Netvibes e IGoogle, creado mediante HTML, AJAX y MySQL. Permite el uso de módulos (gadgets) previamente creados, o bien, crear nuestros propios gadgets mediante su correspondiente API. Se pueden distribuir los gadgets por pestañas y ubicar éstos dentro de la página de forma libre. Otra funcionalidad es la capacidad de añadir funcionalidades al sistema mediante addons, como por ejemplo un reproductor mp3 en flash. Es un software libre distribuido bajo la licencia GNU General Public License Entre sus características principales se puede distinguir:

Características

• Funcionamiento a través de Módulos
  • Tipos de módulos:
    • Sindicación RSS.
    • Creación de módulos propios.
  • Características técnicas
    • Uso de Javascrip + XHTML + CSS para los módulos.
    • Uso de PHP, AJAX y MySQL para el portal.

• Presentación de gadgets en pantalla
  • Necesidad de un navegador web.
  • Uso de pestañas.
  • Distribución flexible por la pantalla.
  • Posibilidad de configurar el número de columnas

• Funcionalidades de catalogado y búsqueda de módulos
  • Los módulos están ordenados por categorías.
  • Se permite la realización de búsquedas

Valoración

Aunque la plataforma está en una fase de desarrollo preliminar a las anteriormente comentadas, con distintos detalles por mejorar (por ejemplo una mejor documentación sobre como crear módulos y un mejor sistema de clasificación de los mismos), resulta muy interesante el hecho de poder disponer del código. La plataforma está creada con PHP, AJAX y MySQL. El código está disponible en la siguiente URL: http://www.portaneo.com/solutions/en/opensource_development.php

El único requisito necesario para instalarlo es disponer de un servidor MySQL y un servidor web debidamente configurado.

Implementación

Plataforma NetVibes

Para la plataforma NetVibes se han desarrollado los gadgets de ‘Búsqueda de Artículos’ y ‘Gestión de artículos’ especificados en el apartado D.5.1.2 intentando cumplir al máximo los requisitos establecidos con las posibilidades que aporta esta plataforma. El contenido de los gadgets de NetVibes se encuentra en ficheros HTML. Se ha utilizado PHP en el servidor para el manejo de la base de datos

Gadget "Búsqueda de artículos"

La funcionalidad del gadget está desarrollada en: http://ezweb.treelogic.com/widgets/buscaProd.html

• Se proporciona una lista de artículos basándose en el criterio de búsqueda.
• El mismo criterio se utiliza para buscar en todos los campos más representativos del artículo.
• La modificación del criterio de búsqueda genera una búsqueda instantánea.
• La búsqueda se realiza sin ser necesario pulsar ninguna tecla ni botón.
• El criterio de búsqueda esta formado por la conjunción copulativa de todas las palabras introducidas.
• Al realizar una búsqueda de artículos se permite exportar los datos de cada artículo a un fichero XML.

Inconvenientes: El tiempo de respuesta depende de la ubicación del servidor con la BBDD. Además la API UWA de NetVibes sólo proporciona funciones asíncronas, por lo que los tiempos de respuesta al mostrar los resultados pueden variar.

Gadget "Gestión de artículos"

La funcionalidad del gadget está desarrollada en: http://ezweb.treelogic.com/widgets/gestionArticulos.html

Alta de artículo

• Para realizar un alta deberemos pulsar en la pestaña “Alta”.
• El identificador del artículo a dar de alta puede ser creado de forma manual, siempre y cuando no esté ocupado ya, o automática. En este último caso bastará con dejar en blanco el campo “Producto” del formulario.
• Todos los campos del formulario deberán ser rellenados, excepto el identificador de producto, para que el alta sea correcto.
• Se podrá dar de alta un artículo que anteriormente haya sido dado de baja.

Baja de artículo

• Para realizar una baja deberemos pulsar en la pestaña “Baja”.
• Se podrá dar de baja un artículo sin que sea eliminado del sistema.
• Se podrá eliminar un artículo definitivamente del sistema, una vez haya sido dado de baja.

Modificación de artículo

• Para realizar una modificación en un artículo deberemos pulsar la pestaña “Modificación”.
• En primer lugar habrá de buscar el artículo que se quiera modificar.
• Los datos del artículo a modificar se mostrarán en el formulario pero no se podrán editar.
• Para editar los datos del artículo primero se deberá pulsar en la casilla “Bloquear para modificación” con el fin de bloquear el artículo y que ningún otro usuario pueda modificarlo.
• Una vez realizados los cambios se pulsará el botón “Modificar” que automáticamente desbloqueará el artículo una vez modificado.
• Si no se desease aplicar los cambios realizados, bastará con desmarcar la casilla “Bloquear para modificación” antes de pulsar “Modificar”.

General en todas las pestañas

• Se podrán realizar búsquedas de artículos a partir de su identificador con el fin de comprobar si un artículo existe ya en el sistema. Para ello se deberá pulsar el botón situado a continuación del campo “Producto”.
• Cuando se realiza una búsqueda a partir de un identificador de artículo, si éste existe se rellenarán automáticamente todos los campos del formulario.
• Existe la opción de buscar también un identificador de Familia o Sección, del mismo modo que con un artículo.

Se permite la exportación de los datos de un artículo a un fichero XML simplemente con pulsar el botón “XML”.

Plataforma IGoogle

NOTA - A día 19 de diciembre de 2007 Google ha pasado los gadgets de tipo html-inline a estado deprecated (es decir, los ha marcado como a abandonar) aduciendo dificultad en su mantenimiento a causa de potenciales riesgos en la seguridad. Esto ha provocado que muchos gadgets a nivel mundial dejen de ser operativos. El cambio ha afectado a los gadgets desarrollados dentro de la Actividad 5, que incluyen requisitos de inter-comunicación (tal y como queda explicado dentro de este mismo documento)y que necesitan ser declarados como html-inline para poder funcionar correctamente. La comunicación de este hecho por parte de Google no se ha realizado a través de la información principal para desarrolladores, sino que se ha dado a conocer a través de un post en los foros de Google. Dentro de este entregable se incluyen capturas de pantalla y vídeos que permiten mostrar la funcionalidad que se ha logrado en caso de que el soporte por parte de Google se retire de forma definitiva.

Para la plataforma de IGoogle se han desarrollado una serie de gadgets de intentando seguir el diseño propuesto en el apartado D5.2.2, orientados a las grandes empresas.

Además de los propuestos en el apartado D5.2.2 se han diseñado otros gadgets que se consideraban oportunos. Para ello hemos dividido los gadgets en dos grupos:

• Gadgets orientados a clientes de Alimerka (Cliente)
• Gadgets orientados a empleados de Alimerka (Empleado)

A continuación se presenta una breve descripción de cada uno de ellos reflejando las funcionalidades y el aspecto de cada uno de ellos. Cada gadget está contenido en un fichero XML.

Gadget "Login" (Cliente)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/login.xml.

• Se proporciona un formulario donde se deberá introducir un Login y una Password de un usuario registrado en el sistema.
• Se proporciona un botón de ingreso en el sistema que permitirá la entrada si los datos son correctos.
• Se proporciona un botón que nos lleva al formulario de registro de usuario en caso de que un cliente no esté registrado ya en el sistema.
• En caso de que se introduzca un Login y Password correctos, el gadget “Login” se ocultará.

Gadget "Alta de Usuarios" (Cliente)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/altausuarios.xml.

• Se proporciona un formulario que deberá ser correctamente cumplimentado para que un usuario se de de alta correctamente.
• Se deberá introducir un DNI válido.
• En caso de que los datos introducidos sean correctos, el formulario se borrará y se mostrará un mensaje de confirmación.
• Si algún dato resulta incorrecto se mostrará un mensaje de error
• Se proporciona la posibilidad de ocultar el gadget de “Alta de usuarios”.

Gadget "Supermercados" (Cliente)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/supermercados.xml.

• Este gadget se muestra cuando un usuario ingresa en el sistema desde el gadget de “Login”.
• Proporciona una lista de supermercados y la opción de mostrar la ruta desde la dirección del usuario que acaba de ingresar en el sistema hasta el supermercado seleccionado.
• La ruta seleccionada se mostrará en el gadget “Mapa”.

Gadget "Mapa" (Cliente)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/localizador.xml.

• Este gadget se muestra cuando un usuario ingresa en el sistema desde el gadget de “Login”.
• Una vez mostrado, se obtendrá la dirección del usuario que acaba de ingresar.
• Cuando se seleccione un supermercado en el gadget “Supermercados” se mostrará la ruta desde la dirección del cliente hasta el supermercado seleccionado.

Gadget "Publicidad" (Cliente)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/publicidad.xml.

• Muestra un archivo Flash con publicidad de Alimerka.

Gadget "Datos" (Cliente)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/visorCliente.xml.

• Este gadget se muestra cuando un usuario ingresa en el sistema desde el gadget de “Login”.
• Contiene los datos del cliente que acaba de ingresar en el sistema.
• Proporciona la opción de abandonar el sistema.
• Si se abandona el sistema, se ocultarán todos los gadgets excepto el de “Publicidad”, y se mostrará el de “Login”

Gadget "Login Empleados" (Empleado)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/loginEmp.xml.

• Se proporciona un formulario donde se deberá introducir un Login y una Password de un empleado registrado en el sistema.
• Se proporciona un botón de ingreso en el sistema que permitirá la entrada si los datos son correctos.
• En caso de que se introduzca un Login y Password correctos, el gadget “Login” ocultará el formulario y mostrará la opción de salir del sistema.

Gadget "Alta de Empleados" (Empleado)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/altaEmpleados.xml.

• Se proporciona un formulario que deberá ser correctamente cumplimentado para dar de alta un empleado correctamente.
• En caso de que los datos introducidos sean correctos, el formulario se borrará y se mostrará un mensaje de confirmación.
• Si algún dato resulta incorrecto se mostrará un mensaje de error

Gadget "Lista de Artículos" (Empleado)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/busquedasPizarra.xml.

• Se proporciona una lista de artículos basándose en el criterio de búsqueda.
• El mismo criterio se utiliza para buscar en todos los campos más representativos del artículo.
• La modificación del criterio de búsqueda genera una búsqueda instantánea.
• La búsqueda se realiza sin ser necesario pulsar ninguna tecla ni botón.
• El criterio de búsqueda esta formado por la conjunción copulativa de todas las palabras introducidas.
• Sobre la lista resultado de la búsqueda se podrán seleccionar artículos haciendo “clic” sobre las filas.
• Se proporciona la posibilidad de enviar estos artículos a otros gadgets.

Gadget "Inventario" (Empleado)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/inventario.xml.

• Se puede modificar el stock de uno o varios artículos.
• Los artículos se añaden a una lista introduciendo su identificador interno o EAN.
• También se añaden a la lista para modificar aquellos artículos enviados desde el gadget “Lista de Artículos”.
• Se proporciona la opción de borrar la lista de artículos a modificar su stock.
• El stock se puede modificar introduciendo un número negativo o positivo. Siendo negativo para reducir el stock y positivo para incrementarlo.

Gadget "Ventas" (Empleado)

Este gadget se encuentra desarrollado en el fichero http://ezweb.treelogic.com/IGoogle/graph.xml.

• Proporciona la posibilidad de mostrar varios tipos de gráficos en función de trimestres, familias de productos.

Instrucciones de uso

Plataforma NetVibes

Gadget "Búsqueda de artículos"

El interfaz de usuario es lo más simple posible y consta de:

• Campo de texto donde se introduce el criterio de búsqueda.
• Parrilla de datos donde se muestran los resultados.

Debido a las limitaciones de esta plataforma no se pueden cumplir todos los requisitos establecidos:

• No es posible definir opciones de teclado para realizar el movimiento por la parrilla y seleccionar registros.

Gadget "Gestión de artículos"

El interfaz de usuario dispone de los siguientes elementos para proporcionar las funcionalidades comentadas en el apartado "Implementación":

• Etiquetas con el nombre de los campos a rellenar
• Campos de texto donde introducir los datos.
• Botones de búsqueda de Productos, Familias y Secciones.
• Distintas pestañas de navegación, una para cada acción sobre los artículos:

• Alta
• Baja
• Modificación

Debido a las limitaciones de esta plataforma no se pueden cumplir todos los requisitos establecidos:

• No es posible definir opciones de teclado para moverse a través de las pestañas y los diferentes campos y botones del formulario.
• No es posible la importación de datos a partir de ficheros dado que Javascript no permite el manejo de los mismos.

Plataforma IGoogle

Gadget "Login" (Cliente)

El interfaz es simple y proporciona:

• Campos de texto donde introducir los datos Login y Password.
• Botones de Ingresar y Registrarse.

Gadget "Alta de Usuarios" (Cliente)

El interfaz está compuesto simplemente de:

• Campos de texto para cada uno de los datos.
• Etiquetas de los campos a rellenar.
• Botones de Alta y Ocultar.

Gadget "Supermercados" (Cliente)

El interfaz nos proporciona lo siguiente:

• Una tabla con las direcciones de los supermercados.
• Un botón en cada fila de la tabla (para cada supermercado) para mostrar la ruta.

Gadget "Mapa" (Cliente)

El interfaz nos muestra un mapa de Google Maps.

Gadget "Publicidad" (Cliente)

El interfaz nos muestra un Flash con publicidad de Alimerka.

Gadget "Datos" (Cliente)

El interfaz consta de:

• Una tabla con los datos del cliente.
• Un botón para salir del sistema.

Gadget "Login Empleados" (Empleado)

El interfaz es simple y proporciona:

• Campos de texto donde introducir los datos Login y Password.
• Botones de Ingresar y Salir.

Gadget "Alta de Empleados" (Empleado)

El interfaz está compuesto simplemente de:

• Campos de texto para cada uno de los datos.
• Etiquetas de los campos a rellenar.
• Boton de Alta.

Gadget "Lista de Artículos" (Empleado)

El interfaz de usuario es lo más simple posible y consta de:

• Campo de texto donde se introduce el criterio de búsqueda.
• Parrilla de datos donde se muestran los resultados.
• Botón para enviar los artículos seleccionados.

Gadget "Inventario" (Empleado)

El interfaz consta de:

• Campo de texto donde se introduce el código de un artículo.
• Parrilla de datos donde se muestran los artículos a modificar.
• Botón para enviar los nuevos stocks introducidos para cada artículo.

Gadget "Ventas" (Empleado)

El interfaz consta únicamente de un gráfico en Flash. Para cambiar el tipo de gráfico habrá que acceder a las preferencias del gadget.

D.5.2.4 Evaluación del Sistema de soporte Operacional y de Negocio en grandes empresas

Conclusiones

Comparación de plataformas

Se han comparado las diferentes plataformas que se encuentran en uso actualmente: Netvibes, PageFlakes, MyYahoo y POSH.

La plataforma MyYahoo no es de utilidad en el ámbito de crear pequeñas aplicaciones configurables, ya que no se pueden crear gadgets propios. Por otro lado, la plataforma PageFlakes fue descartada ya que los gadgets implementados en ella se deben mandar por e-mail, siendo los administradores de la plataforma quienes deciden si han de ser publicados o rechazados.

La plataforma POSH de Portaneo, a pesar de ser código libre y por tanto dar la ventaja de poder acceder a su implementación, ha sido rechazada por su estado muy poco avanzado y por la cantidad de fallos encontrados en la misma.

Por último, destacar que se ha elegido la plataforma Netvibes para comenzar a implementar gadgets por ser la única que tiene un sistema sencillo de crear y subir nuestras propias aplicaciones junto con una buena calidad del portal.

Implementación de gadgets utilizando la plataforma mashups de Netvibes

Para la implementación de los gadgets en la plataforma Netvibes se ha dispuesto de las siguientes tecnologías:

1. XHTML, Javascript y AJAX.
2. El XHTML se usa rtr para definir propiedaddes del gadget y en el formateo de los datos devueltos por los métodos AJAX.
3. Definición de la lógica del gadget mediante javascript incustado en el html.
4. Definición del aspecto mediante hojas de estilo.

En cuanto a las comunicaciones, se han utilizado distintas posibilidades. Por una parte, los gadgets pueden recibir datos usando los métodos AJAX y Javascript adecuados, pudiendo ser en XHTML normal, XHTML en formato JSON, o texto plano. Se ha llegado a la conclusión que no existen métodos específicos para el envío de datos, pudiéndose conseguir de forma rudimentaria mediante formulario en HTML.

La recolección y envío de datos se tiene que llevar a cabo a través de los métodos ofrecidos por la plataforma. El tener que utilizar estos métodos propios de la plataforma plantea problemas, principalmente cuando es necesario enviar información hacia el servidor, ya que los gadgets no están pensados en principio para este uso.

Como se ha comentado anteriormente, actualmente ni se dispone de un sistema de comunicaciones específico entre gadgets, ni tampoco es posible usar variables globales javascript (método permitido en la plataforma iGoogle para la comunicación). El punto de partida para ralizar una comunicación eficiente entre gadgets será el uso de un sistema por ficheros compartidos en el servidor web.

Inconvenientes encontrados en el uso de la plataforma Netvibes:

• No disponibilidad de un método de autenticación seguro.

La plataforma Netvibes ofrece un sistema de envío de claves. Sin embargo, el sistema está pensado para un único usuario por cuenta, por lo que las claves sólo se envían la primera vez y éstas quedan almacenadas en el servidor. Esto no sería problema si cada usuario dispusiese de su propia cuenta, pero, del mismo modo, no es útil si una misma cuenta va a ser usada por diferentes usuarios. Este problema, en conjunción con la imposibilidad de usar sesiones debido al proxy AJAX utilizado por Netvibes, hace que, en el caso de necesitar autenticación, se deba enviar las claves en cada consulta, por lo que se hace necesario establecer algún método de seguridad para evitar el envío de claves en texto plano, lo cual, debido a las limitaciones del lenguaje Javascript, puede ser bastante problemático.

• Recogida de datos asíncrona.

La petición de datos al servidor web se realiza de manera asíncrona, es decir, el código javascript del gadget no se detiene a esperar la respuesta del servidor.Todas las funciones AJAX han de ser llamadas a través de la API de Netvibes, negando todas posibilidades de usar funciones AJAX normales, por lo que no es posible forzar la comunicación síncrona. Esto hace que la implementación de ciertas funcionalidades sea especialmente complicada, y puede incluso llegar a imposibilitar ciertas funciones. Esto que en el funcionamiento usual de un gadget no supone ningún problema para ciertos usos, como por ejemplo esperar una confirmación de un envío de datos, o realizar una validación de un dato, puede provocar conflictos. Este problema, añadido al hecho de que Javascript hace imposible crear una espera inactiva en el lado del cliente, provoca que en muchos casos sea necesario crear un código más complicado y difícil de mantener, siendo posible que en algunos casos no se pueda solucionar de una manera correcta.

• Valoración de las comunicaciones.

Las comunicaciones de los gadgets con el servidor de datos son bastante problemáticas, debido a que éstas, al tener que pasar por los servidores de Netvibes y concretamente a través de su proxy AJAX, sufren unas restricciones bastante fuertes, como es por ejemplo la imposibilidad de hacer uso de sesiones, o de un envío seguro de claves. Estos problemas serían bastante graves si se quisiese hacer un uso empresarial de la plataforma, ya que provocan que la protección de datos se convierta en una tarea muy complicada, pudiendo llegar a ser imposible en algunos casos. Otro problema que implica usar la plataforma Netvibes, el cual es inherente a cualquier plataforma de este tipo alojada en servidores ajenos, es que no se puede controlar a través de donde se va a transmitir nuestra información, convirtiendose en un problema mucho más serio de seguridad. Se puede concluir afirmando que en la plataforma NetVibes no es posible comunicar un widget con otro, por lo que requisitos como por ejemplo la comunicación de un widget de búsqueda con el resto de widgets, para poder exportar los datos de un búsqueda y poder utilizar los mismos para otras funcionalidades, resulta imposible.

• Importar ficheros externos

Netvibes no permite importar ficheros externos como hojas de estilo o archivos javascript (.js), por lo que toda la lógica de presentación y de funcionamiento han de estar en el fichero del widget. Esto hace que si se quiere llevar a cabo un cambio de aspecto, o de una funcionalidad de la que hacen uso todos lo widgets, todos los archivos han de ser modificados.

• Tamaño del widget

No se permite definir ni ancho ni alto de los widgets. El ancho viene definido por el número de columnas que el usuario defina en las preferencias de su cuenta, y el alto viene fijado por el contenido del widget. Mientras que el ancho no es muy problemático, ya que se puede adaptar el contenido de todos los widgets para un número de columnas concreto, el no poder fijar el alto del widget es bastante molesto, porque en los widgets con contenido dinámico, como el de búsqueda, cambian de tamaño continuamente.

Como conclusiones finales del trabajo realizado en las plataformas existentes, es necesario destacar las limitaciones de todas ellas, incurriendo por tanto en un esfuerzo adicional a la hora de crear una lógica de negocio incluida en un servidor web junto con una base de datos

Líneas futuras

A partir del estudio realizado en las plataformas mash-up actuales se deben centrar esfuerzos en las siguientes líneas de investigación:

• Comunicaciones entre widgets: es necesario disponer de un sistema sencillo de comunicación entre widgets. También se ha de disponer de un sistema de gestión de las comunicaciones para así poder crear grupos y lleva a cabo comunicaciones broadcast, multicast e individuales.
• Comunicaciones locales: investigar a cerca de las posibilidades de comunicación local entre gadgets sin comunicación intermedia con un servidor web. Para ello hay que definir el tipo de comunicación a implementar, qué tipos de datos se comparten, datos de salida, datos de entrada, interfaz de comunicación entre dos gadgets, tratamiento de eventos que puedan surgir, etc.
• Autenticación: mediante un envío de claves, inicio de sesiones, etc. El objetivo final de esta línea de investigación comprende tanto todo el proceso de intentar verificar la identidad del remitente de una comunicación, como una petición para conectarse
• Sincronismo: evaluar las posibilidades de mantener una comunicación síncrona entre la petición de datos de un gadget en concreto al servidor web.
• Funcionalidades máximas: definir la carga máxima de funcionalidad de un gadget particular. Evaluar las ventajas e inconvenientes entre implementar gadgets autocontenidos con alta funcionalidad o gadgets básicos con alta capacidad de comunicación y variación de sus prestaciones finales fruto de su unión con otros gadgets del entorno.
• Diseño gráfico: comprende la etapa de diseño e implementación del intefaz gráfico con el usuario. Capacidades de configuración personalizable, habilitación/deshabilitación de características, etc. Para obtener un entorno fácil de usar, más agradable visualmente y mejor integrado, es necesario que los widgets tengan un mayor número de propiedades para definir.
• Sistema seguro de envío de información: habilitar un sistema de forma que el programador pueda fácilmente garantizar que los datos sensibles van a ser enviados de una forma segura.
• Sesiones: implementar algún tipo de sistema de sesiones de forma que las acciones de un usuario siempre estén identificadas desde que entra hasta que sale del sistema
• Interacción con el entorno del usuario: el uso de javascript en las plataformas limita totalmente la interacción con el entorno local del usuario, por lo que resulta imposible el uso de fichero de ámbito local, sería muy útil poder tener acceso a ficheros locales del usuario.
• Navegación específica: Los navegadores web normales disponen de multitud de opciones y de atajos de teclado, de los cuales muchos son contraproducente o totalmente indeseables para el manejo del sistema, por lo que sería interesante disponer de un navegador con las opciones justas y necesarias para interactuar con la aplicación.
• Definición de atajos específicos: Para mejorar la usabilidad del sistema es muy recomendable permitir al usuario definir sus propios atajos de teclado a las distintas funciones que le proporciones su interfaz.