Applying lean principles in craft brewing to improve quality and reduce costs : two KwaZulu-Natal case studies.

Master of Commerce. University of KwaZulu-Natal, Pietermaritzburg, 2018.A significant number of companies around the world have implemented lean methodologies in order to remain competitive. Although these were initially developed for large manufacturing companies, the principles that serve as a foundation for these methodologies are, arguably, also applicable to small companies. The proposed research will focus on small craft breweries in the KwaZulu-Natal province of South Africa to determine if they too can benefit from implementing practices that are based on lean principles. The world’s craft brewing industry is well-established and growing rapidly. Most of the beer brewed in South Africa is mass-produced at comparatively low cost. Craft beer brewed by smaller scale breweries is relatively more expensive to produce and consumers have to accept trade-offs between the perceived better quality and higher cost of craft beer. In order to gain and maintain market share, craft brewers need to produce quality beer whilst reducing production costs. The objectives of this study were threefold. Firstly, it sought to identify appropriate assessment tools that may be used to measure waste in craft breweries. Secondly, to identify and measure any sources of waste that may occur in craft breweries. Lastly, to determine if and how craft brewers can introduce lean methodologies based on lean principles in their production processes in order to improve quality and reduce costs. The study was guided by lean theory. The principles derived from this directed the deployment of lean tools and practices to implement lean production methodologies. Lean theory argues that lean methodologies, if implemented correctly, will yield positive results for all firms in all industries. A multi-case study approach was used, supported by five data collection instruments; direct observations, participant observations, documents & records and semi-structured interviews. A convergent, parallel, mixed methods design was used as this allowed both qualitative and quantitative data to be gathered, analysed and then merged to interpret the findings and results. The data was analysed using content analysis with NVivo software. The main findings of this study indicate that: 1. Lean tools, like the Lean Assessment Tool, which consists of several lean improvement programmes and tools (e.g. setup time reduction, visual controls) may be used to assess waste in craft breweries. 2. The sources of wastes and inefficiencies which were identified from the case studies relate to inventory, overproduction, waiting time, unnecessary transporting, processing waste, inefficient work methods, product defects and underutilised human resources. 3. Identifying lean tools and programmes that the company can implement under its current production capabilities is a key success factor in becoming a lean organisation. 4. Having a step by step implementation model which is clear to follow will help companies to implement lean production. 5. To produce good quality beer, the ingredients used must be of good quality. Also, close monitoring of the brewing processes, times and temperatures is essential. 6. The current challenges in the craft beer industry include high levels of competition from the mainstream beer producing giants, distribution problems, maintaining consistent quality and developing effective marketing plans in a highly contested market. The study was concluded by discussing the implications of these findings for theory and literature, as well as for practitioners. Recommendations, specific for these case studies were provided and areas for future research suggested

From Sensor to Observation Web with Environmental Enablers in the Future Internet

This paper outlines the grand challenges in global sustainability research and the objectives of the FP7 Future Internet PPP program within the Digital Agenda for Europe. Large user communities are generating significant amounts of valuable environmental observations at local and regional scales using the devices and services of the Future Internet. These communities’ environmental observations represent a wealth of information which is currently hardly used or used only in isolation and therefore in need of integration with other information sources. Indeed, this very integration will lead to a paradigm shift from a mere Sensor Web to an Observation Web with semantically enriched content emanating from sensors, environmental simulations and citizens. The paper also describes the research challenges to realize the Observation Web and the associated environmental enablers for the Future Internet. Such an environmental enabler could for instance be an electronic sensing device, a web-service application, or even a social networking group affording or facilitating the capability of the Future Internet applications to consume, produce, and use environmental observations in cross-domain applications. The term ?envirofied? Future Internet is coined to describe this overall target that forms a cornerstone of work in the Environmental Usage Area within the Future Internet PPP program. Relevant trends described in the paper are the usage of ubiquitous sensors (anywhere), the provision and generation of information by citizens, and the convergence of real and virtual realities to convey understanding of environmental observations. The paper addresses the technical challenges in the Environmental Usage Area and the need for designing multi-style service oriented architecture. Key topics are the mapping of requirements to capabilities, providing scalability and robustness with implementing context aware information retrieval. Another essential research topic is handling data fusion and model based computation, and the related propagation of information uncertainty. Approaches to security, standardization and harmonization, all essential for sustainable solutions, are summarized from the perspective of the Environmental Usage Area. The paper concludes with an overview of emerging, high impact applications in the environmental areas concerning land ecosystems (biodiversity), air quality (atmospheric conditions) and water ecosystems (marine asset management)

Reanimating cultural heritage through digital technologies

Digital technologies are becoming extremely important for web-based cultural heritage applications. This thesis presents novel digital technology solutions to 'access and interact' with digital heritage objects and collections. These innovative solutions utilize service orientation (web services), workflows, and social networking and Web 2.0 mashup technologies to innovate the creation, interpretation and use of collections dispersed in a global museumscape, where community participation is achieved through social networking. These solutions are embedded in a novel concept called Digital Library Services for Playing with Shared Heritage (DISPLAYS). DISPLAYS is concerned with creating tools and services to implement a digital library system, which allows the heritage community and museum professionals alike to create, interpret and use digital heritage content in visualization and interaction environments using web technologies based on social networking. In particular, this thesis presents a specific implementation of DISPLAYS called the Reanimating Cultural Heritage system, which is modelled on the five main functionalities or services defined in the DISPLAYS architecture, content creation, archival, exposition, presentation and interaction, for handling digital heritage objects. The main focus of this thesis is the design of the Reanimating Cultural Heritage system's social networking functionality that provides an innovative solution for integrating community access and interaction with the Sierra Leone digital heritage repository composed of collections from the British Museum, Glasgow Museums and Brighton Museum and Art Gallery. The novel use of Web 2.0 mashups in this digital heritage repository also allows the seamless integration of these museum collections to be merged with user or community generated content, while preserving the quality of museum collections data. Finally, this thesis tests and evaluates the usability of the Reanimating Cultural Heritage social networking system, in particular the suitability of the digital technology solution deployed. Testing is performed with a user group composed of several users, and the results obtained are presented

Opportunities for waste valorisation in the food industry – A case study with four UK food manufacturers

Food manufacturing is comprised of a number of complex processes which generate vast amounts of food waste. Frequently, strategies for dealing with these materials are rudimentary and provide a low economic and environmental value, for instance animal feeding, anaerobic digestion, composting, incineration, landspreading and landfilling. However, food wastes contain numerous chemicals with a wide range of potential commercial applications, which makes these materials suitable feedstocks for valorisation. This paper applies a Waste Flow Modelling methodology to achieve two aims: to provide valuable food manufacturing and waste data in order to better understand current food manufacturing activities, and to analyse existing food waste management practices to lay the foundation for the implementation of alternative food waste valorisation solutions. Four UK industrial companies have been selected and assessed to represent four different food sectors where food waste valorisation could provide an economic and/or environmental advantage: a fruits supplier, a brewery, a potato supplier and a producer of peas. The production line of each of these four businesses is defined and characterised, which allows the identification of food wastes generated. Next, food wastes are categorised and quantified, and their patterns of generation and current waste management practices are described. Sankey diagrams and performance indicators are used to assess the efficiency of processes, combination of processes and the complete production line in terms of food waste generation. Finally, the results are analysed and used to obtain the main conclusions and provide recommendations for an improved food waste management system, with a focus on valorisation opportunities

Enterprise 2.0: Collaboration and Knowledge Emergence as a Business Web Strategy Enabler

The Web is becoming in many respects a powerful tool for supporting business strategy as companies are quickly becoming more and more reliant on new Web-based technologies to capitalize on new business opportunities. However, this introduces additional managerial problems and risks that have to be taken into consideration, if they are not to be left behind. In this chapter we explore the Web’s present and future potential in relation to information sharing, knowledge management, innovation management, and the automation of cross-organizational business transactions. The suggested approach will provide entrepreneurs, managers, and IT leaders with guidance on how to adopt the latest Web 2.0-based technologies in their everyday work with a view to setting up a business Web strategy. Specifically, Enterprise 2.0 is presented as a key enabler for businesses to expand their ecosystems and partnerships. Enterprise 2.0 also acts as a catalyst for improving innovation processes and knowledge work

Variability in remote portlets

130 p.Contexto Los portales corporativos (EIP, acrónimo en inglés de Enterprise Information Portal ) integran información, personas y procesos dentro de los límites de las organizaciones. Una característica importante de los portales corporativos es la descentralización en la creación de los contenidos y la gestión de los mismos, esto ayuda a mantener la información siempre actualizada. Otra característica distintiva es que pueden atender no sólo al personal interno de la organización a la que pertenecen, sino que también son capaces de proveer servicios a personal externo tales como clientes, proveedores y socios comerciales. Los portales permiten a las personas comunicarse y colaborar, proporcionan un punto de acceso uni cado al contenido dinámico generado por las aplicaciones de negocio, fraccionan los silos de contenido y proveen información personalizada de forma e caz. Los portales son también plataformas de integración. Además de ofrecer sus propios servicios, un portal es también un conducto para aplicaciones externas. Estas aplicaciones son técnicamente conocidas como portlets. Un portlet es un componente Web con interfaz de usuario que puede ser ofrecido a través de aplicaciones de terceros (por ejemplo, un portal). Los portlets tienen interfaz de usuario, es decir, en lugar de devolver datos en crudo, los portlets presentan vistas a los usuarios. Además, los portlets son aplicaciones complejas con contexto que pueden soportar ujos de trabajos compuestos de múltiples pasos. La especi cación de portlet [6, 7] ofrece interoperabilidad entre las plataformas de portales y los portlets, estos es, permite a los desarrolladores escribir el portlet una vez, y reutilizarlo en cualquier portal que soporte la especi cación. Esto proporciona la infraestructura para hacer posible un mercado de portlets de manera que, los portales puedan ofrecer portlets provistos por terceros. En 2006 se puso en marcha el proyecto Open Source Portlet Repository Project (un repositorio de portlets de código abierto) para fomentar el libre intercambio de portlets de código abierto. Este repositorio es "una biblioteca de aplicaciones listas para correr que se pueden descargar y desplegar directamente en su portal sin, en la mayoría de los casos, con gura- 1 ciones adicionales" [2]. Otras iniciativas similares son Portlet Swap (jboss.org) y Liferay Marketplace (liferay.com). La especi cación Web Services for Remote Portlets (WSRP) va un paso más allá y permite el renderizado remoto de los portlets. El mantra de esta especi - cación es desplegar una vez, proveer en cualquier lugar . Con WSRP, un portlet puede estar alojado ( producido ) en una infraestructura completamente aislada de los portales que ofrecen ( consumen ) el portlet a sus usuarios. Esto convierte a WSRP en una solución viable para construir portales federados, es decir, una red de portales interconectados donde los recursos alojados en un portal pueden estar disponibles en muchos. Desde esta perspectiva, los portlets juegan en la capa de presentación el mismo papel que los servicios web convencionales juegan en la capa de lógica de negocio: permiten crear sistemas complejos mediante la composición de sistemas reusables más sencillos. Las principales diferencias con los servicios web tradicionales consisten en qué se está reutilizando (que incluye la interfaz de usuario) y dónde se produce la integración (en la capa de presentación). 2 Problema General La variabilidad en software es la capacidad de un sistema o artefacto software para ser modi cado, personalizado o con gurado para su uso en un contexto particular. Pero, ¿cuánta variabilidad debemos considerar? ¿Quién es consciente de la variabilidad requerida? Para responder a estas preguntas vamos a introducir un ejemplo. Considere una compañía aérea (por ejemplo, IBERIA) que ofrece dos servicios en términos de portlets: searchFlight y bookFlight. De esta manera, las agencias de viajes (por ejemplo, HALCON) pueden hacer uso de estos portlets dentro de sus portales. Los usuarios (por ejemplo, los clientes de HALCON) acceden al portal de la agencia de viajes sin ser conscientes de que searchFlight está siendo ofrecido por un tercero (es decir, IBERIA). Por lo tanto, los portlets son explícitamente desarrollados para ser utilizados en múltiples portales, ya sea desplegados localmente o provistos de forma remota. El punto importante a destacar es que los portlets pueden ser reutilizados por diversos contextos y audiencias. Por ejemplo, IBERIA ofrece sus servicios no sólo a HALCON, sino también a otras agencias de viajes (por ejemplo, EROSKI). Esto signi ca que searchFlight también debe atender a las necesidades de integración de EROSKI. Por otro lado, incluso los clientes de un portal dado pueden tener diferentes necesidades. Por ejemplo, el usuario Oscar es muy aprensivo a las condiciones climáticas por lo que siempre consulta el pronóstico del tiempo antes de jar la fecha de un viaje. Esto sólo se aplica a Oscar, y no es contemplado por el portlet ightBooking. Por lo tanto, el Sr. Oscar se ve obligado a moverse fuera del ámbito del portal para satisfacer esta necesidad de datos (por ejemplo, a través de un widget weatherForecast ), y es su responsabilidad pasar los datos necesarios para la consulta del portal al widget. El ejemplo anterior sirve para ilustrar los diferentes contextos en los que la 2 variabilidad puede ser jada y decidida. En concreto, existen tres "reinos de decisión": el proveedor del portlet (por ejemplo, IBERIA). En este caso, el proveedor realiza un análisis profundo del dominio para satisfacer las variaciones del portlet requeridas por todos los usuarios y escenarios donde su portlet puede ser utilizado. el consumidor del portlet (por ejemplo, HALCON). Aquí, el portal del consumidor realiza un análisis de su base de consumidores, y provee los medios al propietario del portal para con gurar el portlet adecuadamente. el usuario nal (por ejemplo, el Sr. Oscar). Ningún diseño puede proporcionar información para cada situación, y ningún diseñador puede incluir información personalizada para cada usuario. Esto es cierto para cualquier aplicación web, y los portlets no son una excepción. Merece la pena mencionar, que estos reinos de decisión no son ortogonales sino complementarios. Todos, el proveedor del portlet, el consumidor del portlet, e incluso, los usuarios nales, deben colaborar para obtener una mejor experiencia en la web. Las secciones siguientes profundizan en cada uno de estos escenarios. 3 Escenario 1: Variabilidad basada en el Provee- dor Este escenario pone la carga de la variabilidad sobre los hombros del proveedor. El proveedor debe realizar un análisis del dominio con el n de comprender los diferentes entornos en los que sus portlets van a ser desplegados. Esto lleva a la noción de Consumer Pro le (o per l del consumidor). El Consumer Pro le incluye no sólo detalles sobre la plataforma del consumidor (por ejemplo, JBoss GateIn, Liferay, eXo Platform), sino también requisitos funcionales planteados por el propietario portal que necesitan ser atendidos por el proveedor del portlet. Mientras que el per l de usuario caracteriza al usuario nal (por ejemplo, edad, nombre, etc.), el Consumer Pro le recoge la idiosincrasia de la organización a través de la cual se está ofreciendo el portlet (por ejemplo, el propietario del portal) en cuanto a la funcionalidad del portlet se re ere. El per l de usuario puede ser dinámico y, por lo tanto, requiere que el portlet pueda ser personalizado en tiempo de ejecución. Por el contrario, el Consumer Pro le se conoce en tiempo de registro, y no siempre es apropiado o posible considerarlo en tiempo de ejecuci ón. En este caso, es mejor personalizar el código en tiempo de desarrollo y producir un portlet especí co para la organización que incluya funcionalidad personalizada. Para este n, se propone el uso de líneas de producto software (SPL) para el desarrollo de portlets. 3 Desarrollo basado en SPL hace referencia a los métodos, herramientas y técnicas para la creación de una colección de sistemas software similares a partir de un conjunto compartido de artefactos software utilizando un medio de producci ón común. En este escenario, ya no tenemos un portlet sino una familia de portlets, y el proveedor de portlet se convierte en la "cadena de montaje" de esta familia. Este trabajo promueve esta visión mediante la introducción de una arquitectura compatible con el estándar WSRP que permite a los consumidores de portlets manejar familias de portlet de la misma manera en la que manejan "portlets tradicionales". Al hacer esto, los portlets están más cerca de convertirse en servicios realmente reutilizables y, por lo tanto, permitir la construcción de Arquitecturas Orientadas a Servicios (SOA) usando portlets. Una arquitectura SOA de de ne como "una estrategia de TI que organiza las funciones discretas contenidas en las aplicaciones empresariales en servicios interoperables estándares que pueden ser combinados y reutilizados de manera ágil para satisfacer las necesidades del negocio" - BEA Systems, Inc. SOA ofrece a las organizaciones una mayor agilidad, ya que pueden desplegar rápidamente nuevos procesos de negocio o modi car los existentes en respuesta a los cambios del mercado. Los portales basados en portlets podrían proporcionar un enfoque ligero a las SOA. La de nición anterior puede reformularse utilizando la terminolog ía de portales como una estrategia de TI que organiza las funciones discretas contenidas en las aplicaciones empresariales [portlets] en servicios interoperables [portlets remotos pueden comunicarse y compartir datos] estándares [WSRP está basado en los estándares de servicios web] que pueden ser combinados [los portales pueden agregar información de múltiples portlets] y reutilizados de manera ágil [WSRP no requiere esfuerzo de programación] para satisfacer las necesidades del negocio . Aunque un número creciente de organizaciones se están moviendo hacia las SOA muchas están teniendo di cultades para identi- car el primer paso en el proceso. Aquellas empresas que buscan bene ciarse de las SOA pueden utilizar los portales basados en portlets como su primer paso en este camino [9]. Este escenario SOA no sólo requiere interoperabilidad (a través de los estándares de portlets) y la difusión de los portlets (a través de los repositorios de portlets), sino también variabilidad. Los portlets tienden a ser componentes de grano grueso, ya que encapsulan tanto la capa de presentación, como la capa de funcional. Estos componentes de granularidad gruesa tienen menos posibilidades de ser reutilizados "tal cual" [5]. Esto puede poner en peligro la visión de los portlets como servicios reutilizables. Esto introduce las siguientes preguntas de investigación: ¿Cómo se puede aplicar el desarrollo basado en SPL a los portlets? ¿Cuáles serían las implicaciones para el estándar WSRP? 4 4 Escenario 2: Variabilidad basada en el Con- sumidor Los proveedores de portlets no siempre pueden prever todas las necesidades de los consumidores, o algunos portlets podrían necesitar extensiones que no pueden ser soportadas utilizando los mecanismos de parametrización habituales. El etiquetado social es un ejemplo de ello. Los portales, en un grado mayor que otras aplicacionesWeb, tienen la noción de comunidad profundamente arraigada en el interior de su naturaleza. Especí camente, los Enterprise Information Portals nacieron para dar soporte a los empleados dentro de una organización. Por lo tanto, es natural integrar funcionalidades presentes en las redes sociales dentro de estos portales. Entre estas funcionalidades, este trabajo se centra en el etiquetado. La motivación para llevar el etiquetado al lugar de trabajo, admite una doble perspectiva. Desde el punto de vista de la empresa, el etiquetado es un medio económico para compartir y retener conocimiento en el contexto de una organización, previniendo la fuga de datos críticos fuera de la empresa [4]. Desde la perspectiva de un empleado, distintos estudios [11, 1, 8] concluyen que las motivaciones individuales para utilizar el etiquetado en el lugar de trabajo, tales como la creación de un repositorio personal o re-encontrar los recursos propios aún son motivaciones importantes. En este escenario, los etiquetadores (es decir, la comunidad del portal) y las etiquetas son activos del portal. Sin embargo, y a diferencia de los sitios de etiquetado tradicionales, los portales podrían no contener la descripción de todos los recursos susceptibles de ser etiquetados. Por ejemplo, la descripción de los libros o de los hoteles que se ofrecen a través del portal la podría proveer de forma remota, por ejemplo, por Amazon y Expedia, respectivamente. Esta externalización de la descripción de los contenidos no implica que no merezca la pena etiquetar los recursos externos. Esto nos lleva a distinguir entre dos actores: el proveedor de recursos, que mantiene el contenido de los recursos etiquetables (por ejemplo, la descripción del libro en el caso de Amazon), y el consumidor de recursos (es decir, el portal), que mantiene la comunidad de etiquetadores y las etiquetas. De la misma manera en que los portlets adaptan su capa de presentación a las directrices estéticas del portal que los aloja, el etiquetado a través de los portlets también debe adaptarse a las peculiaridades del portal del consumidor. Esto introduce las siguientes preguntas de investigación: ¿Cómo pueden los portlets ser conscientes de las especi cidades del portal, en concreto, aquellas referentes al etiquetado? 5 Escenario 3: Variabilidad basada en el Usuario La personalización es el proceso de adaptación de las páginas a las características o preferencias individuales de los usuarios de manera que resulten más e caces para satisfacer sus objetivos. Se basan en la teoría de que cada usuario tiene intereses y necesidades únicas. Desafortunadamente, los usuarios normalmente 5 no tienen in uencia en la elección de qué contenido puede ser personalizado o cómo puede este personalizarse. Además, no siempre es fácil para el diseñador prever los distintos contextos y objetivos desde los que se acceden a su aplicación. "Ningún diseño puede proporcionar información para cada situación, y ningún diseñador puede incluir información personalizada para cada usuario" [10]. No hace mucho tiempo, sólo los desarrolladores podían crear aplicaciones. Los usuarios sólo podían utilizar lo que los desarrolladores habían creado antes. Sin embargo, las cosas han cambiado. Con los mashups, los usuarios pueden evitar el departamento de TI y crear sus propias aplicaciones en respuesta a sus propias necesidades. Un mashup es una aplicación web ligera creada por la combinación de información y capacidades de más de una fuente existente para ofrecer nuevas funciones y conocimiento. Nuevas herramientas están actualmente disponibles (por ejemplo, Software AG Presto, IBM Mashup Center, Kofax Kapow) que requieren poca o ninguna participación del departamento de TI y permiten a los usuarios con experiencia crear el mashup que necesitan, cuando lo necesitan. Habilitando a los usuarios de esta manera, se puede reducir el número de aplicaciones que esperan a la cola del departamento de TI para ser creadas, el tiempo y los costos de desarrollo y se puede reducir el costo de crear información personalizada ya que los usuarios pueden adaptar ellos mismos la información a la forma en que la necesitan [3]. Esto introduce las siguientes preguntas de investigación: ¿Cómo pueden los mashups ser introducidos en los portales basados en portlets? 6 Contribuciones Esta tesis se ha desarrollado en el contexto de la ingeniería, lo que nos empujó a lograr no sólo una contribución académica sino también a mirar la aplicabilidad de estas ideas. Para ello, se proporciona una implementación de las ideas aquí introducidas. En nuestra opinión, esta tesis hace las siguientes aportaciones: 6.0.1 Variabilidad basada en el Proveedor Este trabajo promueve la visión de los portlets como servicios reutilizables mediante la introducción de la noción de Consumer Pro le como una forma de capturar las especi cidades de las diferentes organizaciones, donde el portlet puede ser utilizado. Esto a su vez conduce al uso de un enfoque de desarrollo de portlets basado en SPL y a la introducción de una arquitectura compatible con el estándar WSRP que permite a los consumidores de portlets manejar familias de portlet de la misma manera en la que manejan "portlets tradicionales". La solución se ha apoyado en el proyecto WSRP4Java1. 1http: //portals.apache.org/wsrp4j/ 6 6.0.2 Variabilidad basada en el Consumidor Esta tesis explora aquellos medios que pueden ser más adecuados para dar soporte a las características especí cas del consumidor. El etiquetado se utiliza como un ejemplo. Este trabajo argumenta que el etiquetado debe ser ortogonalmente soportado como una funcionalidad transversal encima de los portlets. El principal reto se basa en la coherencia tanto en el back-end (esto es, el uso de una estructura común de datos, por ejemplo, un conjunto común de etiquetas), y el front-end (esto es, las interacciones con la funcionalidad de etiquetado deben ser soportadas de forma homogénea a lo largo de todo el portal utilizando estilos de presentación similares). El mecanismo de eventos de los portlet y las anotaciones RDFa se utilizan para cumplir con este requisito. Un ejemplo sobre Liferay ilustra la viabilidad del enfoque. 6.0.3 Variabilidad basada en el Usuario El enfoque presentado introduce mashups como un mecanismo de personalizaci ón adicional mediante el cual los usuarios del portal pueden complementar los servicios del portal (es decir, los portlets) con sus propias necesidades de información. El enfoque se implementa sobre Liferay como la plataforma de portales utilizando los portlets como la tecnología para soportar los servicios del portal y XBL como que la tecnología de integración. Para facilitar la adopción del enfoque se ha desarrollado una herramienta visual que oculta los tecnicismos de XBL a los usuarios. 7 Conclusiones El protocolo WSRP describe la conversación entre los proveedores de portlets y los consumidores que actúan en nombre de los usuarios nales: los proveedores son los servicios web con capa de presentación que alojan los portlets y son capaces de procesar las solicitudes de markup y las de interacción del usuario con los portlets, los consumidores utilizan estos servicios web como parte de las vistas que presentan a los usuarios nales y gestionan las interacción de los usuarios nales con la capa de presentación de los portlets, los usuarios nales son los clientes de los consumidores Estos roles constituyen los diferentes contextos en los que la variabilidad de los portlets remotos se puede jar y decidir. el proveedor de portlet. En este caso, el proveedor de portlets lleva a cabo un análisis profundo del dominio y proporciona a los consumidores un conjunto cerrado de variantes entre las que elegir. 7 el consumidor portlet. Los consumidores de portlets también pueden crear y añadir sus propias variantes especí cas del producto, por ejemplo, para tener en cuenta los requisitos que para ser satisfechos requieren el uso de funcionalidad externa. el usuario nal. Hay una tendencia creciente para proporcionar variabilidad a los usuarios nales (por ejemplo, mecanismos a través de plugins). Sin embargo, no podemos esperar que los usuarios nales puedan editar y compilar el código fuente. Esta tesis aborda el reto de soportar variabilidad para cada uno de estos escenarios

Open learning: Advances in the eMadrid excellence network

Proceedings of: 2011 IEEE Global Engineering Education Conference (EDUCON 2011): Learning Environments and Ecosystems in Engineering Education. Amman, Jordan, 4-6 April 2011.This Special Session is going to present some of the activities carried out by the Excellence Network on e-learning that is being funded in the Region of Madrid, called eMadrid. They are related to the application of open source principles in the educational context and in opening up the alternatives to the learner.The eMadrid Excellence Network [24] is being funded by the Madrid Regional Government (Comunidad de Madrid) with grant No. S2009/TIC-165. We wish to acknowledge stimulating discussions with our partners in the context of the networkPublicad