Dina Salah

Richard Paige
email: richard.paige@york.ac.uk

Paul Cairns
email: paul.cairns@york.ac.uk

Integrating Agile Development Processes and User Centred Design-A Place for Usability Maturity Models?

Keywords: Agile Software Development Processes, User Centred Design, Agile User Centred Design Integration, Usability Maturity Models, Maturity Models 2 Agile Development Processes and User Centred Design Integration

The aim of this paper is to explore and evaluate the role that can be played by Usability Maturity Models (UMMs) in integrating agile processes and User Centred Design (UCD). UMMs can be utilised in Agile projects as a diagnostic tool to assess the extent to which UCD is systematically and consistently implemented and the extent of effective implementation of UCD in development projects. This paper investigated the suitability of Nielsen Corporate Usability Maturity Model for utilisation in the Agile domain in order to assess the organisation's UCD capability. It reported on applying Nielsen Model in five case studies that performed Agile and User Centred Design Integration (AUCDI) and utilising the model in assessing their usability maturity level. The results revealed the existence of a correlation between the success of AUCDI attempts and the AUCDI case study's usability maturity level. These results can have positive implications on AUCDI practice since practitioners who aim to achieve the integration can utilise Nielsen model to identify their strengths and weaknesses in regards to UCD related aspects and accordingly plan for improvement.

Introduction

Agile methods are lightweight software development methods that tackle perceived limitations of plan-driven methods via a compromise between absence of a process and excessive process [START_REF] Fowler | The New Methodology[END_REF]. Agile processes aim to deal with volatile requirements via discarding upfront, precisely defined plans. They are iterative and are used to develop software incrementally. Different Agile processes implement these ideas in different ways. All Agile processes share common values and principles, defined in the Agile Manifesto [START_REF] Beck | Manifesto for Agile Software Developement[END_REF].

User Centred Design (UCD) is a set of techniques, methods, procedures and processes as well as a philosophy that places the user at the centre of the development process in a meaningful, appropriate and rigourous ways [START_REF] Gould | Designing for Usability: Key Principles and What Designers Think[END_REF][START_REF] Detweiler | Managing UCD within Agile Projects[END_REF]. The goal of applying UCD is to attempt to satisfy users via producing usable and understandable products that meet their needs and interests [START_REF] Detweiler | Managing UCD within Agile Projects[END_REF] in addition to their goals, context of use, abilities and limitations [START_REF] Blomkvist | Towards a Model for Bridging Agile Development and User-Centered Design[END_REF]. The usability of a product is the consequence of systematic UCD work that occurs throughout the development process and continues even after product release in order to enhance subsequent versions [START_REF] Detweiler | Managing UCD within Agile Projects[END_REF].

Maturity Models are normative [START_REF] Iversen | Situated Assessment of Problems in Software Development[END_REF] reference models that embrace the assumption of predictable evolution and change patterns. The main purpose of maturity models is to assess the current situation in order to evaluate the strengths and weaknesses and then prioritize and plan for improvement [START_REF] Iversen | Situated Assessment of Problems in Software Development[END_REF]. This is achieved via evolutionary successive stages or levels that signify step by step patterns of evolution and change designating the desirable or current organisational capabilities against a specific class of entities [START_REF] Rosemann | Towards a Business Process Management Maturity Model[END_REF][START_REF] Gottschalk | Maturity Levels for Interoperability in Digital Government[END_REF][START_REF] Mettler | Maturity Assessment Models: A Design Science Research Approach[END_REF].

Improving the effectiveness of user-centred design in software development is a considerable challenge in many organisations. Usability Maturity Models (UMMs) were proposed to conduct a status-quo analysis of UCD. UMMs aim to assist organisations in conducting a systematic analysis that evaluates the strengths and weaknesses of the organisation in regards to UCD related aspects [START_REF] Jokela | Usability Assessment of an Extreme Programming Project: Close Co-operation with the Customer Does Not Equal to Good Usability[END_REF] and accordingly plan for improvement actions [START_REF] Jokela | Modelling Usability Capability -Introducing the Dimensions[END_REF]. Usability Capabiliy is defined as A characteristic of a development organisation that determines its ability to consistently develop products with high and competitive level of usability [START_REF] Jokela | Modelling Usability Capability -Introducing the Dimensions[END_REF].

This paper provides details of an exploratory study for the role that could be played by usability maturity models in the domain of integrating agile development processes and user centred design. The rest of this paper is structured as follows: section 2 provides a background on agile and user centred design integration. Section 3 discusses the research approach. Section 4 provides details of the utilisation of Nielsen Corporate Usability Maturity Model in five AUCDI Case Studies. Section 5 discusses the results and section 6 discusses the conclusion and future work. thus leading to improved usability and user satisfaction. Second, none of the major Agile processes explicitly have guidance for how to develop usable software [START_REF] Lee | Examining the Foundations of Agile Usability with eXtreme Scenario-Based Design[END_REF]. In addition, the interaction design role, usability, and user interface design in an Agile team is unclear and largely overlooked [START_REF] Constantine | Process Agility and Software Usability: Towards Lightweight Usage Centred Design[END_REF][START_REF] Beyer | An Agile Customer-Centered Method: Rapid Contextual Design[END_REF]. Furthermore, principles and practices for understanding and eliciting usability and user requirements and evaluating Agile systems for usability and UX are generally considerably deficient [START_REF] Lee | Examining the Foundations of Agile Usability with eXtreme Scenario-Based Design[END_REF][START_REF] Kane | Finding a Place for Discount Usability Engineering in Agile Development: Throwing Down the Gauntlet[END_REF]. Third, there appear to be philosophical and principled differences between Agile methods and UCD in focus, evaluation method, culture and documentation that suggest that their integration will be fundamentally challenging.

Although Agile and User Centred Design Integration (AUCDI) research is growing, it has not yet exploited the potential of UMMs, which is strongly relevant to AUCDI practice. A systematic literature review [?] was conducted that included 71 papers on AUCDI that classified AUCDI studies according to the integration approach revealed eight different categories, non of which focused on utilization of UMMs. UMMs can be utilised in the Agile development projects as a diagnostic tool. They can assist in assessing the status quo to evaluate the extent to which UCD is systematically and consistently implemented as well as the extent of effective implementation of UCD in development projects. The results can help organisations identify their strengths and weaknesses in regards to UCD related aspects and accordingly plan for improvement actions.

Thus this study has two aims: first, to investigate the suitability of UMMs for utilisation in the context of Agile projects in order to assess the organisation's UCD capability and/or performance. Second, to investigate the relationship between the success of AUCDI attempts and usability maturity level.

Research Approach

This section provides details on the research approach that was used to achieve the research aims.

Comparative Study of Usability Maturity Models

The first step of this research involved conducting a comparative study of UMMs in order to choose one of those UMMs for utilisation in assessing the usability maturity level of case studies that integrated Agile development processes and UCD. To the best of our knowledge there exists eleven usability maturity models for which an overview will be provided below. The features, perspective of usability integration, maturity approaches, scope, and documentation of these models are diverse. An example of difference in scope is shown in the fact that some models focus on assessing the user centredness of the organisation whereas others focus on measuring the user centredness of projects. Moreover, the existing UMM literature is focused on presenting the structure of the models and the methods for performing the assessment rather than presenting empirical evaluation of these models [START_REF] Iivari | Evaluating a Usability Capability Assessment[END_REF][START_REF] Jokela | A Survey of Usability Capability Maturity Models: Implications for Practice and Research[END_REF]. [START_REF] Flanagan | Usability Management Maturity, Part 1: Self Assessment: How Do You Stack Up[END_REF][START_REF] Rauch | Usability Management Maturity, Part 2: Usability Techniques -What Can You Do[END_REF] was developed by IBM in the early 1990s as a means of benchmarking and improving the status of usability in software development projects. It examines organisations from three different aspects: organisation, skills, and processes. The model documentation that is available in the public domain is very limited and only two papers are available [START_REF] Flanagan | Usability Management Maturity, Part 1: Self Assessment: How Do You Stack Up[END_REF][START_REF] Rauch | Usability Management Maturity, Part 2: Usability Techniques -What Can You Do[END_REF]. 5. Humanware Process Improvement (HPI): Humanware Process Improvement was developed by Philips [START_REF] Gupta | Humanware Process Improvement Framework: Interfacing User Centred Design and the Product Creation Process at Philips. Position paper delivered at Human Centred Process Improvement Group (HCPIG) meeting[END_REF][START_REF] Mcclelland | Humanware Process Improvement -Institutionalising the Principles of User Centred Design[END_REF]. HPI includes 10 Key Process Areas (KPAs) which identify UI design practices and suggest how these can be incorporated in the product creation process [START_REF] Gupta | Humanware Process Improvement Framework: Interfacing User Centred Design and the Product Creation Process at Philips. Position paper delivered at Human Centred Process Improvement Group (HCPIG) meeting[END_REF]. HPI is based on the "Plan-Do-Check-Act" cycle and covers software and hardware aspects of products [START_REF] Mcclelland | Humanware Process Improvement -Institutionalising the Principles of User Centred Design[END_REF]. HPI provides a questionnaire as an assessment tool for self and full assessments [START_REF] Gupta | Humanware Process Improvement Framework: Interfacing User Centred Design and the Product Creation Process at Philips. Position paper delivered at Human Centred Process Improvement Group (HCPIG) meeting[END_REF]. 6. User Centred Design Maturity (UCDM): User Centred Design Maturity (UCDM) [START_REF] Eason | User Centred Design Maturity[END_REF] was developed at the University of Loughborough in the UK, initially as a tool for benchmarking information systems capability in the UK public sector. It has five capability areas, for example, "systems design", "project structure and goals" and maturity stages, and 15 foci of assessment [START_REF] Jokela | A Survey of Usability Capability Maturity Models: Implications for Practice and Research[END_REF]. 7. Usability Maturity Model-Processes (UMM-P): UMM-P [START_REF] Earthy | Usability Maturity Model: Processes Version 2.3. Technical report[END_REF] was developed in the European INUSE project. It is intended to be used in the assessment and improvement of the human centred processes in system development. The model describes seven processes each defined by a set of base practices and associated work products. Examples of UMM-P processes are "Plan and manage the human-centred design process", and "Specify the user and organisational requirements". An assessment recording form is supplied and its use is described.

8. KESSU: KESSU [START_REF] Jokela | An Assessment Approach for User-Centred Design Processes[END_REF] is an assessment model that was developed in a national research project at Oulu University in Finland. The main selling point of KESUU is that it examines the performance rather than the management aspects of user centred processes. KESSU includes seven processes of UCD including: identify user, context of use, determine user requirements, produce user task designs, produce interaction designs, usability feedback and usability verification [START_REF] Jokela | A Survey of Usability Capability Maturity Models: Implications for Practice and Research[END_REF] [START_REF] Raza | An Open Source Usability Maturity Model (OS-UMM)[END_REF].

Table 1 provides a comparison for the maturity levels of the different UMMs. It indicates that the different UMMs vary in the number of maturity levels between eight (Nielsen Model) and three (DATech-UEPA).

Criteria for Comparing Usability Maturity Models

The following criteria were found relevant for the purposes of this work in order to compare the main characteristics of the different UMMs that are available in the public domain.

Lightweight: Since the chosen UMM will be utilized to assess the usability maturity level of each project, the model should be lightweight; it should require low overhead so as not to disrupt any Agile project schedule and low cost so as not to consume considerable time to perform the assessment or require additional personnel to conduct the assessment.

Detailed English Documentation: The model should provide detailed documentation that provides practitioners with detailed maturity model definition and detailed descriptions of the assessment process. This detailed documentation will provide explicit guidance to practitioners to conduct self assessment,

- - Optimizing- - - - Integrated user- centred design - - - - - - - - User- driven corpora- tion - - - - - - - -
Table 1. Maturity Levels of Usability Maturity Models i.e., conduct the assessment on their own without the need for the presence of the model author. Moreover, since the available usability maturity/assessment models were developed in various countries, one of the criteria for choosing the usability maturity/assessment model is to be documented in English. Domain Independent: Some UMMs are domain specific; i.e., they were created for specific domains like telecommunication or manufacturing. This implies that they focus on domain specific practices and cannot be utilized in other domains. Thus the model chosen should be domain independent; i.e., it should be suitable for utilisation in all organisations regardless of their domain of business.

Empirically Evaluated: The model should have been evaluated in empirical studies and iterated according to the results of these empirical evaluations.

The UMMs were examined using the criteria identified above and table 2 presents a summary of the results of the comparison between the different usability models according to the comparison criteria proposed earlier.

The UMM pursued is documented in English, has a detailed documentation, can be used irrespective of the organisation's domain (generic), is lightweight, and has been empirically evaluated.

These criteria led to the exclusion of a number of UMMs.

The language criteria led to the exclusion of DATech-UEPA, HCD-PCM Design and HCD-PCM Visioning since they were not documented in English. The detailed documentation criteria led to the exclusion of ULMM, HPI, UCDM, KESSU, and OS-UMM since they do not provide sufficient documentation to conduct the assessment in a self assessment form. However, this does not imply that they did not have extensive documentation, for example, KESSU is published in numerous papers, however, all these papers and documentation provided a rather high level detail on the dimensions and processes rather than on the how to conduct the assessment. The domain criteria led to the exclusion of Trillium since it is domain specific as it is focused on the telecommunication industry. The lightweight criteria led to the exclusion of UMM-P since the model is not lightweight and requires considerable time to be conducted which may disrupt any Agile project schedule and impose considerable cost as a result of consuming considerable time to perform the assessment.

In case of the lack of enough documentation or the lack of English documentation, it was hard to judge whether the model is lightweight or not. As a result "Not Applicable (N/A)" was used as an indication that it was not applicable to make an evaluation. This left us with only two UMMs: Nielsen Corporate Usability Maturity Model and Usability Maturity Model-Human Centrdness Scale. Although Nielsen model was not empirically evaluated, yet it was decided to utilise both models in five AUCDI case studies in order to provide richer comparative analysis via two UMMs.

Choosing Five AUCDI Case Studies

The second step of the research approach involved choosing five case studies that integrated Agile development processes and user centred design and represented successful and unsuccessful AUCDI attempts A candidate list of five academic researchers and industrial practitioners were selected. This list included authors who developed new AUCDI approaches and whose work on AUCDI was well received and highly referenced. The chosen case studies also reflect a "two tail" design [START_REF] Yin | Case Study Research: Design and Methods[END_REF] in which cases from both extremes (success and failure) are selected.

Interviewees were contacted via an email. All of the interviewees were professional usability practitioners whose job roles were: usability product manager, usability analyst, usability engineer, lead user experience designer, and team manager for user experience design. One interview was conducted per participant in which questions regarding Nielsen model were posed. At the beginning of the interview the interviewees were asked for their permission to record the interview and then the informed consent form was read and their consent on its terms was recorded. All interviewees agreed to record the interview. All interviews were transcribed in English. Each case study works in a different sort of software, however, all case studies implement Scrum. Four case studies represent successful integration attempts whereas one case study represent a failure integration attempt. The imbalance between the number of successful and unsuccessful case studies is attributed to the existence of publication bias since more positive results are published than negative results in the AUCDI domain as indicated by the results of a systematic literature review that was conducted on agile and user centred design integration [?].

For the sake of protecting the anonymity of participants, company names and some details on the projects will be withheld.

Case Study 1: The product developed in the first case study was a Software as a Service where high quality UX was crucial. The product developed an integration with a new ecommerce platform in order to allow sellers to sell their inventory to multiple ecommerce sites. The interviewee worked as a usability product manager, and was responsible for managing all the UX aspects of the project and designing the user interfaces. This project represented successful AUCDI attempt as declared by the author. This success occurred through utilising a variant of the Scrum methodology. The project had two peer product owners, one focused on usability and user experience and the other on the more conventional functions. The usability product owner took the lead in establishing a UX vision for the product along with a number of personas. The vision was realised in high level user goals, high level description of the UX with the product and a high level navigation model for the entire product.

Case Study 2: The second case study occurred at a leader company in the enterprise customer relationship management marketplace. The product developed was a second version of an approval process editor, the first version had very poor UX and users could not use the product as expected and there was poor adoption. Four years later it was subject to redesign. The interviewee worked as a usability analyst which involves being a dedicated UX researcher. This project represented successful AUCDI attempt as declared by the author. This occurred via first, introducing a new resource plan that reduced workload on UX team members and dedicated two hours per week by UX practitioners to assist Scrum teams that did not have assigned UX resources. Second, they introduced design transformations via moving to parallel development and design, working a release ahead, utilising interactive prototypes for usability testing, communication of designs to developers, and design studios. Third, using Rapid Iterative Test and Evaluation (RITE) for usability testing in all Agile projects.

Case Study 3: The third case study occurred at a home shopping network company. The product developed was a new system that facilitates show planning for a home shopping network. Show planners used the software in order to schedule shows, products to shows and hosts to shows. The interviewee worked as a lead UX running a team with three designers. This case study represented successful AUCDI attempt as declared by the author. This success occurred through the use of a rapid process that allows designers, developers, and stakeholders to collaborate and explore design alternatives. This occurred via some common guidelines where participants produce several rough sketch designs, then attended a collaborative workshop to discuss each other's work. This was followed by merging ideas to one design concept with which to move forward. This process reportedly had several advantages, for example, facilitating role sharing and knowledge transfer, allowing rapid exploration of design alternatives, and fostering shared understanding of design vision.

Case Study 4: The fourth case study occurred at a leading software and services company in the asset performance management domain. The product developed was a touch screen kiosk system for mechanics in order to receive work orders and record the results of the repair. The interviewee worked as a usability engineer. This case study represented successful AUCDI attempt as declared by the author. This success occurred through the use of a development approach that draws from extreme programming and scenario based design. This approach has two separate and synchronized usability and development tracks and the usability engineer works one iteration ahead of the developers. The key design is represented in a set of mock-ups, scenarios, claims, and design goals that were used to support synchronization activities and help the usability engineer plan and run usability evaluations.

Case Study 5: The fifth case study occurred at an Internet infrastructure services company that enable and protect interactions across the world's voice, video, and data networks. In addition to domain name registration and resolution. This company is a leading provider of security related products, for example, SSL certificates, identity and authentication services and enterprise security management. The product developed was a redesign of an existing web site for a product that allowed customers to purchase and manage services on-line. The goal of the project was to increase sales and customer retention, and reduce the number of support calls by providing an improved UX during the purchase and product renewal processes. The interviewee worked as a manager of UX design team which was a central team serving the whole company. This case study represented unsuccessful AUCDI attempt as stated by the author. At the end of the release the project went into the beta phase and a major problem was discovered since the users were unable to complete their purchase successfully.

The product did not satisfy its requirements of increasing sales and improving customer retention. This resulted in pulling the software back in order to fix it. The cause of this failure was attributed to a lack of communication among the cross functional team members due to geographical separation and unwillingness by the engineering team to collaborate with non engineering teams and as a result the product manager and the UX team were prevented from participating in the sprint planning and Scrums. This led the engineering team to interpret and implement the designs incorrectly. There was also a lack of iterative refinement of designs.

Utilising The Chosen UMM(s) in five AUCDI Case Studies

The fourth step of research approach involved utilising the chosen UMM(s)(Nielsen Model) in assessing the usability maturity level of five case studies that integrated Agile development processes and user centred design and represented successful and unsuccessful AUCDI attempts. This occurred via conducting a set of one to one, Skype interviews. A set of open ended questions were formulated and posed to interviewees to evaluate the achievement of different practices. The questions were formulated in a manner that is precise, unambiguous, and understandable to respondents.

Answers to interview questions were used in evaluating the usability maturity level of each case study and the results of each case study were compared with the achieved practices in the different usability maturity levels in order to determine the closest usability maturity level. Those results are reported in section 5 in table 4.

Synthesizing The Results Of Utilisation of UMMs

The fifth step of the research approach involved synthesizing the results of utilisation of Nielsen Model in order to investigate the following: the existence of a relationship between the success of AUCDI attempts and usability maturity level and the suitability of UMMs for utilisation in assessing usability maturity in the context of Agile projects.

Utilising Nielsen Corporate Usability Maturity Model in AUCDI Case Studies

This section discusses the steps that were used in order to utilise Nielsen model in assessing the usability maturity level of the five AUCDI case studies introduced in section 3.2. Maturity models as a design product can take various forms including: pure textual description, functioning of the maturity model, or instantiation as a software assessment tool [START_REF] Mettler | Maturity Assessment Models: A Design Science Research Approach[END_REF]. The Nielsen model is a textual model that is composed of 8 maturity levels but is written primarily as a textual narrative and this form cannot be easily deployed for measuring usability maturity of an organisation. Accordingly, the model was carefully examined in order to transform its narrative form into a set of measurable dimensions and practices. Each dimension is composed of a number of practices. This examination resulted in a model that is composed of five dimensions and 24 practices as shown in table 3. These dimensions included: developers' attitude towards usability, management attitude towards usability, usability practitioners' role, usability methods and techniques, and strategic usability. Nielsen model describes each usability maturity level as a set of achieved practices. Thus 1 was used to signify an achieved practice and 0 was used to signify a non achieved practice in each usability maturity level. An identifier were given to each practice in order to assist with referring to it.

Table 3 reflects the dimensions, practices, and maturity levels involved in Nielsen model.

Results

This section reports on applying Nielsen Corporate Usability Maturity Model in the five AUCDI case studies that were discussed in section 3.2 and utilising the model in assessing their usability maturity level.

Interviewees from case study 1, 2, 3, 4, 5 are referred to as PT1, PT2, PT3, PT4, and PT5 respectively. In order to protect the anonymity of participants, the word "he" will be used to refer to all of them. Relevant interviewee quotes are included to illustrate the evaluations given to some of the assessed practices and these quotes are identified by the participant who said them. Case study 1, 2, 3, 4 and 5 will be referred to as CS1, CS2, CS3, CS4, and CS5 respectively. Allocating funds for usability activities B1. Usability data is employed to determine individual projects to be built

E1.5 1 1 1 1 1
Concept of total user experience extend to other forms of customer interaction with the company

E1.6 0 1 0 1 0
User research data is employed to determine overall direction and priorities E1.7 0 1 1 1 0

Table 4. Case Study

Corporate Usability Maturity Model in five AUCDI case studies.

Maturity Level Evaluation of Case Studies Via Nielsen Model

Table 4 reflects the results of maturity level evaluation of Nielsen model for CS1, CS2, CS3, CS4, and CS5. Table 4, column CS1, CS2, CS3, and CS4 shows that the closest maturity level that describe CS1, CS2, CS3, and CS4 is maturity levels 7, 8, 7-8,and 8 respectively. However, column CS5 shows that CS5 differed significantly from all maturity levels. Thus it was given a maturity level of "Unknown". The exploratory study that was conducted via Nielsen capability maturity model aimed to investigate the existence of a relationship between the success of AUCDI attempts and usability maturity level and the suitability of Nielsen Corporate Usability Maturity Model for utilisation in assessing usability maturity in the context of Agile projects.

Aim 1: Investigating the existence of a relationship between the success of AUCDI attempts and usability maturity level

This study revealed the existence of a correlation between the success of AUCDI attempts and AUCDI case study's usability maturity level. Successful AUCDI case studies all scored a usability maturity level that ranged from 7-8.

This result can have positive implications on AUCDI practice since practitioners who aim to achieve the integration can utilise Nielsen model the start of their projects to assess their maturity level. In case of achieving a low maturity level then the different practices included in Nielsen model can be used as a checklist for areas that need to be improved.

It was not possible to determine the maturity level of CS5, an example of a failed AUCDI attempt as discussed in section 5.1. This was due to the wide difference between its achieved practices and any available maturity level. This difficulty of determining the maturity level of CS5 was due to the fact that it had low maturity for all practices related to developers' attitude dimension towards usability including: practice A1.1-"Recognition of usability importance", practice A1.2-"Recognition of importance of understanding user needs" and A1.3-"Developers acting on behalf of users". However, it had high maturity for all practices related to the dimensions related to management attitude towards usability, usability practitioners role, usability methods and some practices related to strategic usability. Nevertheless, due to developers' attitude towards usability all the management awareness, allocated funds, usability practitioners and strategic usability practices were not effectively utilised. Moreover, the lack of cooperation of the development team led to discarding a number of practices including: practices-D1.1 "Performing usability testing", D1.6-"Performing iterative design", D1.7-"Quantitative usability metrics can be used to track quality", D1.8-"Projects has defined usability goals". The lack of communication among the cross functional team members due to geographical separation and unwillingness by the engineering team to collaborate with non engineering teams resulted in preventing the product manager and the user experience team from participating in the sprint planning and scrums. This led the engineering team to interpret and implement the designs incorrectly and resulted in lack of iterative refinement of designs.

This implies that the existence of management acknowledgment of usability importance and providing necessary infrastructure for usability activities , i.e., dedicated usability labs, usability professionals, usability funds, usability tools, etc are all less important to project success than developers' attitude towards usability how they communicate with usability practitioners.

Aim 2: Investigating whether Nielsen Corporate Usability Maturity Model is suitable for utilisation in assessing usability maturity in the context of Agile projects Nielsen model was not initially developed for Agile software development processes, however, a number of criteria were set in order to investigate the suitability of Nielsen model for utilisation in assessing usability maturity in the context of Agile projects. These criteria involves the following:

CR1: The usability maturity model should not conflict with Agile values and principles

This criteria was set in order to maintain the agility of the development process in case of utilising Nielsen model. However, practice E1.1-"Presence of a tracking process for user experience quality throughout design projects and across releases" could pose a conflict with the Agile value of "Individuals and interactions over processes and tools". However, this practice also works in support of another Agile principle "Continuous attention to technical excellence and good design enhances agility" since the aim of practice E1.1 is to improve the quality of user experience across all products.

Thus it can be concluded that CR1 is satisfied by Nielsen model since the model does not conflict with Agile values and principles.

CR2: The usability maturity model should integrate UCD activities into the overall project plan and throughout the Agile development life cycle

The reason behind setting this criteria is that none of the major Agile processes explicitly include guidance for how to develop usable software [START_REF] Lee | Examining the Foundations of Agile Usability with eXtreme Scenario-Based Design[END_REF]. In addition, the interaction design role, usability, and user interface design in an Agile team is unclear and largely overlooked [START_REF] Constantine | Process Agility and Software Usability: Towards Lightweight Usage Centred Design[END_REF][START_REF] Beyer | An Agile Customer-Centered Method: Rapid Contextual Design[END_REF]. Furthermore, principles and practices for understanding and eliciting usability and user requirements and evaluating Agile systems for usability and user experience are generally considerably deficient [START_REF] Lee | Examining the Foundations of Agile Usability with eXtreme Scenario-Based Design[END_REF][START_REF] Kane | Finding a Place for Discount Usability Engineering in Agile Development: Throwing Down the Gauntlet[END_REF]. In general, it is not yet clear how to incorporate UCD into Agile processes without sacrificing the acknowledged benefits of each of these individual processes.

As a result, criteria CR2 was considered as a significant factor for judging the suitability of Nielsen model for utilisation in assessing usability maturity in the context of Agile projects since the main problem that faces the Agile domain regarding the integration is when to perform the different UCD activities and how to make them more lightweight in order to accommodate the Agile processes iterative and incremental nature. However, Nielsen model lacks details on the timing of applying practices D1.1, D1.2, D1.5, and D1.6. Although the model includes practice D1.2 that is focused on planning for usability, however no details were given on what this entails. Practice D1.2 does not clarify what is meant by planning for usability and whether it includes preparation for user research, usability testing or planning to integrate UCD activities into the software development life cycle or all of these issues collectively. Practice D1.4 is focused on utilising a usability reports archive to compile past usability findings, however, the practice does not discuss the form of this usability reports archive to clarify whether it is a lightweight or heavyweight form. Moreover, practice D1.4 focuses only on archiving (documenting) past usability findings without mentioning other aspects that are necessary for AUCDI and that need to be archived including: design rationale, source of requirements, results of user research, designs, expected delivery date of designs, etc that are all necessary in the context of Agile projects. Practice D1.5 is focused on performing early user research, however, it uses a generic term to refer to the timing of conducting user research (early), this can imply iteration 0 or sprint 0 in the Agile domain. Moreover, the practice is generic since it does not identify the activities that are involved in performing early user research including: identification of user groups, context of use, task analysis, etc. Practice D1.8 is focused on setting defined usability goals for projects yet the problem facing Agile teams is not to set usability goals but rather how to translate these goals into user stories or features in the product back log that can gain priority for execution in the tight Agile time lines and avoid marginalization.

Nielsen model is a generic model, i.e., it is not developed for a particular software development life cycle. As a result the model focus is on declaring the important practices for usability maturity rather than clarifying the timing, method or frequency for conducting these practices along the project plan or the phases of the product development life cycle. This is of specific importance in case of Agile development processes since significant part of the integration challenges are related to the iterative, incremental, tight time line nature of Agile development processes.

Thus it can be concluded that criteria CR1 is satisfied by Nielsen model since it does not conflict with Agile values and principle. However, criteria CR2 is not satisfied by Nielsen model since the model does not state clear timings and milestones along the Agile development life cycle for the inclusion of UCD activities into the overall project plan and all phases in the software development life cycle.

Conclusion and Future Work

This paper investigated the suitability of Nielsen Corporate Usability Maturity Model for utilisation in the Agile domain in order to assess the organisation's UCD capability. It reported on applying Nielsen Model in five case studies that integrated Agile development processes and user centred design and utilising the model in assessing their usability maturity level.

The investigation of the existence of a relationship between the success of AUCDI attempts and usability maturity level revealed the existence of a correlation between the success of AUCDI attempts and the AUCDI case study's usability maturity level since successful AUCDI case studies all scored a usability maturity level that ranged from 7-8. Whereas, with the failed AUCDI attempt, it was not possible to determine its maturity level and as a result it was given a maturity level of "Unknown".

Moreover, the investigation of the suitability of UMMs for utilisation in assessing usability maturity in the context of Agile projects gave an indication that the model does not conflict with Agile values and principles. However, although the model includes a variety of UCD activities, yet, it lacks details on the timing of applying the different practices along the Agile development life cycle iterations or sprints. This is of specific importance in case of Agile development processes as significant part of the integration challenges that faces Agile projects is related to the timing of performing the different UCD activities in order to accommodate the Agile processes' iterative and incremental nature.

Although the existence of a correlation between the success of AUCDI attempts and the AUCDI case study's usability maturity level result can have positive implications on AUCDI practice since practitioners who aim to achieve the integration can utilise Nielsen model before the start of their projects to assess their maturity level. In case of achieving a low maturity level then the different practices included in Nielsen model can be used as a checklist for areas that need to be improved. However, two issues are of concern: first, Nielsen model is a descriptive maturity model, thus it is limited to acting as a diagnostic tool rather than an improvement tool, so the model can assess the performance and pinpoint weak areas but the procedures of improvement of these areas are left to practitioners and are not tackled by the model. Second, the lack of timing for the different UCD activities can hinder the usefulness of the model since organisations can use it as a checklist of the UCD activities that need to be performed, however, when they initiate their software development process they will be more concerned with the timing and the lightweight method through which they can achieve the recommended UCD activities by Nielsen model.

Moreover, an open issue is the further AUCDI challenges that are specific to the Agile domain and that are not tackled in Nielsen model. These issues need to be taken into consideration by any researcher who considers developing a UMM in the context of Agile projects. AUCDI challenges that are not approached by Nielsen model are: practices regarding the communication, coordination and collaboration between UCD practitioners and Agile developers in order to synchronize and complete their work, practices related to design modularization and chunking, UCD practitioner workload, and maintaining communication between the customer and the development team [?]. Moreover, another issue that needs to be approached by the developers of UMMs for Agile development processes is the features and activities that should be played by some team roles including XP coach, and scrum master whose role can impact the integration process.

Future work will involve applying UMM-HCS model in the same five case studies that integrated Agile development processes and UCD and utilising the model in assessing their usability maturity level.

  Nielsen model includes a variety of UCD activities embodied in the following practices -D1.1-Performing usability testing. -D1.2-Planning for usability. -D1.4-Utilising a usability reports archive to compile past usability findings. -D1.5-Performing early user research. -D1.6-Performing iterative design. -D1.8-Projects has defined usability goals.

  Usability Maturity Models 1. Nielsen Corporate Usability Maturity Model: Nielsen Corporate Usability Maturity Model [26] was developed in 2006 by Jackob Nielsen. It is composed of 8 stages or maturity levels. It declares that as organisations' usability matures they typically progress through the same sequence of stages from initial hostility to widespread reliance on user research [26]. 2. Usability Maturity Model-Human Centredness Scale (UMM-HCS): UMM-HCS [8] was developed in 1998 by the European INUSE project that focused on the assurance of interactive systems or web sites usability. UMM-HCS was derived from all significant existing UMMs. It embodies usability maturity via 6 maturity levels of a combination of attitude, technology, and management activities. UMM-HCS documentation includes an assessment recording form and its use is described [8]. 3. Trillium: Trillium [4] is a process assessment approach for development of telecommunication products, developed in 1991 by Bell Canada. Trillium Model is based on (CMM) version 1.1. Although the model is extensively documented and published in the public domain, yet, it does not include methods on how to perform the assessment. 4. Usability Leadership Maturity Model (ULMM): Usability Leadership Maturity Model (ULMM)

Table 2 .

 2 Criteria for Choosing a Usability Maturity Model

	UMM Model	Language Detailed	Domain	Lightweight Empirical
			Documenta-			Evaluation
			tion
	Nielsen	English	Yes	Generic	Yes	No
	UMM-HCS	English	Yes	Generic	Yes	Yes
	Trillium	English	Yes	Telecommunication No	Not published
	ULMM	English	No	Generic	N/A	Not Published
	HPI	English	No	Consumer Product	N/A	Not Published
				Development
	UCDM	English	No	Information System	N/A	Not Published
				Capability in UK
				Public Sector
	UMM-P	English	Yes	Generic	No	Yes
	KESSU	English	No	Generic	N/A	Yes
	DATech-UEPA	German	N/A	Manufacturing	N/A	N/A
	HCD-PCM Design	Japanese N/A	Generic	N/A	N/A
	HCD-PCM Visioning Japanese N/A	Generic	N/A	N/A
	OS-UMM	English	No	Open Source Projects N/A	N/A

Table 3 .

 3 Nielsen Corporate Usability Maturity Model Levels

  Table 4 reflects the results of applying Nielsen model on CS1, CS2, CS3, CS4, and CS5. The following section discusses the findings from applying Nielsen

	Dimension	Practices	ID	CS1 CS2 CS3 CS4 CS5
		Recognition of usability importance	A1.1 1	1	1	1	0
	Developers Attitude Towards Usability	Recognition of importance of under-	A1.2 1	1	1	1	0
		standing user needs
		Developers not acting behalf of users A1.3 1	1	1	1	0
		Recognition of usability importance	B1.1 1	1	1	1	1
	Management Attitude Towards Usability	ity activities Willingness to allocate funds for usabil-	B1.2 1	1	1	1	1


Mirko Fetter

Tom Gross

LILOLE-A Framework for Lifelong Learning from Sensor Data Streams for Predictive User Modelling

Keywords: Lifelong Learning, User Modelling, Framework

Adaptation in context-aware ubiquitous environments and adaptive systems is becoming more and more complex. Adaptations need to take into account information from a plethora of heterogeneous sensors, while the adaptation decisions often imply personalised aspects and individual preferences, which are likely to change over time. We present a novel concept for lifelong learning from sensor data streams for predictive user modelling that is applicable in scenarios where simpler mechanisms that rely on pre-trained general models fall short. With the LILOLE-Framework, we pursue an approach that allows ubiquitous systems to continuously learn from their users and adapt the system at the same time through stream-based active learning. This Framework can guide the development of context-aware or adaptive systems in form of an overall architecture.

Introduction

Context-aware and adaptive systems promise to support users by allowing them to offload tasks to the system. For example context-aware ubiquitous environments automatically execute tasks for the users, by sensing properties about the current situation and inferring the users' needs based on learned models or specified rules. For simple forms of adaptation, such rules can be specified manually with the help of tools [START_REF] Salber | The Context Toolkit: Aiding the Development of Context-Enabled Applications[END_REF][START_REF] Schirmer | CollaborationBus Aqua: Easy Cooperative Editing of Ubiquitous Environments[END_REF]. For example the task of automatically muting the phone when arriving at a specific location such as a meeting room can be relatively easily described by a rule. More complex forms of adaptations often already require the application of machine learning algorithms, as a manual specification of rules would be too complex. For example, smartphones are able to distinguish different simple activities like walking, running, or bicycling through activity recognition based on accelerometer data [START_REF] Biao | Activity Recognition from User-annotated Acceleration Data[END_REF] and thus they are able to adapt their user interface to the current activity of the user. In order to enable such devices to recognise specific activities, usually machine-learning classifiers are trained with labelled data collected from a number of users. However, even with these relatively simple machine-learning problems, the generalisability of the learned models to new users who are not part of the group that provided training data, is already a challenge. For example Biao and Intille [START_REF] Biao | Activity Recognition from User-annotated Acceleration Data[END_REF] found that while some of the activities in their work could be identified well with "subject-independent training data" some of the activities could be detected better with "subject-specific training data". In order to optimise general activity recognition models for individual users, a number of different approaches have been developed, which try to optimise general models to specific users [START_REF] Reiss | Personalized Mobile Physical Activity Recognition[END_REF][START_REF] Zhao | Cross-People Mobile-Phone Based Activity Recognition[END_REF]. The reason for relying on general models, even if they perform worse, is that the final users are not bothered with the effort for training a system before using it.

However, adaptation decisions in ubiquitous environments and adaptive systems are becoming more and more complex, where such simplified approaches based on general models or their optimisation can be hardly applied. They often take a multiplicity of input factors like location, activities, social interactions, etc. that happen simultaneously in physical and electronic space. The input arrives from a plethora of heterogeneous sensors and the adaptation decisions often imply personalised aspects and individual preferences that also can change over time. An illustrative example is the scenario of mediating interruptions by predicting the interruptibility of users [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF][START_REF] Fogarty | Predicting Human Interruptibility with Sensors[END_REF][START_REF] Horvitz | Creating and Fielding Personalized Models of the Cost of Interruption[END_REF], where the data of numerous different sensors is brought together with personal interruptibility reports to predict the availability of a user for communication. In such scenarios, general models do not offer enough accuracy and thus fail to offer adequate adaptation support for various reasons, as reflected on by Fetter et al. [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF]. In order to overcome such challenges the idea of lifelong learning systems for user modelling [START_REF] Kapoor | Principles of Lifelong Learning for Predictive User Modeling[END_REF] was introduced. Thereby the approach is to collect labels for unobservable user states over a prolonged time span to continuously train an adaptive system. The underlying rationale is that the system continuously improves itself, and over time reduces the request for labels, unless novel situations are detected. Hence, lifelong learning aims at improving the prediction quality through learning personalised models while trying to keep the training effort for users low.

In the following we present the LILOLE framework for lifelong learning from sensor data streams for predictive user modelling. The Framework can guide the development of context-aware or adaptive systems in form of an overall architecture. The Framework thereby provides a foundation for the research and development of systems that deliver more human-centred adaptations, by continuously learning from the user, while keeping the effort for the user low. In the remainder of the paper we motivate the LILOLE-Framework based on the analysis of the requirements and a look at existing machine learning approaches and the related work. We give a detailed description of the framework and a reference implementation. Finally, we discuss the results of an experiment, which applied the reference implementation to a real world data set and thus is able to predict the availability of individuals for instant messaging (IM) based on 30 different sensors.

Background and Related Work

In the following we give an introduction to the background of our work, including work that motivated our approach, that is related to our approach, and such that is incorporated in our approach.

A Rationale for Learning Personal Models

While machine learning at first seems an ideal candidate for learning personalised user models, a number of challenges hinder its broad application. As discussed by Webb et al. [START_REF] Webb | Machine Learning for User Modeling[END_REF], the main challenges are the need for a huge amount of labelled data for training and the fact that learned concepts may change over time (i.e., concept drift). In user modelling therefore mainly two approaches can be found [START_REF] Zukerman | Predictive Statistical Models for User Modeling[END_REF]: contentbased, and collaborative learning. In the first approach users' past behaviour is used, to make prediction about their personal future behaviour. In the second approach, the behaviour of a group of similar behaving people is used, to make predictions for an individual user. Yet, both approaches only work if the concept to be learned is not hidden for the learning system, but is available for in-stream supervision [START_REF] Kapoor | Principles of Lifelong Learning for Predictive User Modeling[END_REF]. For example, for a media player the songs played by a user are observable. Accordingly, based on meta-information like artists and genre (content-based learning) or based on the similar musical taste of other users (collaborative learning), the media player is able to recommend new songs to the user on the basis of the kind of songs the user played before. However, in many cases in ubiquitous computing and context-aware systems the concepts to be learned are hidden from the system (e.g., the users' mood, interruptibility, activity), and labels need to be provided manually. Therefore, in most implementations, where data could not be learned from individual users, the data is collected from a smaller number of users and is used to build general models that later need to fit all users (e.g., in activity recognition, gesture recognition). From a humancentred computing perspective, such approaches do not account for the individual differences of users. Accordingly, often users are forced to adapt to the system instead of the systems adapting to them (e.g., perform an activity in such a way, that the system is able to detect it). Further, as recent work has shown, such general models are not feasible in more complex settings. For example, when Fetter et al. [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF] examined the performance of general vs. personal models in the context of predicting Instant Messaging availability of nomadic users based on a number of sensors in mobile settings, they found several aspects that degraded the performance of general models such as: the learned concept (i.e., availability) is highly personalised, and the variation between users was accordingly high; some features that had high predictive power for an individual user had a limited predictive power for other users, and thus were discarded; and some features that worked well in the individual models even had contradictory information for other users when used in general models. Our approach accounts for these challenges.

Lifelong Learning Systems

Only few researchers so far investigated the feasibility of systems that are able to continuously learn personalised models of human situations and adapt the user interface. Kapoor and Horvitz [START_REF] Kapoor | Principles of Lifelong Learning for Predictive User Modeling[END_REF] proposed the notion of lifelong learning, where a user trains a machine learning system over a prolonged period based on selective supervision using the experience sampling method (ESM) [START_REF] Horvitz | Experience Sampling for Building Predictive User Models: A Comparative Study[END_REF]. However, their approach only was applied in strictly controlled settings, where the knowledge about the feature space was clear in the beginning, and each feature was handcrafted upfront by the system designer. Accordingly this approach only partially adapted to new situations. With Subtle, Fogarty et al. [START_REF] Fogarty | Predicting Human Interruptibility with Sensors[END_REF] developed the concept of a toolkit to generate automatic sensor-based statistical models of human situations. The toolkit provided an extensible sensor library, although with a limited number of readily available sensors. It provided support for continuous learning, but only in form of an iterative batch mode, that did not combine the strength of online learning algorithms with selective supervision for choosing best instances to label. Further, it was based on automated feature construction and selection, but did not make use of online feature selection mechanisms, to cope with high dimensional data with a presumably sparse number of features with high predictive power.

While both approaches demonstrated the general feasibility of life-long learning adaptive systems, those ideas have not been further pursued. Though, for a humancentred assessment of these approaches, studies with real-users in real life situations are needed, measuring the users attitude towards such systems. The LILOLE-Framework informs the design of life-long learning systems and promotes implementations, which are robust to deployments in different environments and situations, and thus can be the foundation of further human-centred evaluations.

Data Stream Mining and Active Learning

In the following, the two machine learning approaches that build the foundation of our lifelong learning approach are introduced: data stream mining, and active learning.

The research field of data stream mining is concerned with methods, algorithms, and tools for extracting knowledge from rapid and continuous streams of data. As the development of information and communication technologies make more and more data available (e.g., from sensor networks, network traffic, or human activity data), learning from data streams is an emerging field in the area of machine learning. The aim of the research is to develop new algorithms and approaches that can cope with the special characteristics and requirements of stream-based learning, discussed in the Data Stream Model by Babcock et al. [START_REF] Babcock | Models and Issues in Data Stream Systems[END_REF] as well as in the work of Bifet [START_REF] Bifet | Adaptive Stream Mining -Pattern Learning and Mining from Evolving Data Streams[END_REF], Aggarwal [START_REF] Aggarwal | An Introduction to Data Streams[END_REF]), and Gama [START_REF] Gama | Issues and Challenges in Learning from Data Streams[END_REF]. So, for example, the data needs to be processed in one-pass and only in small chunks as the amount of data is extremely large, arrives continuously and is potentially infinite [START_REF] Aggarwal | An Introduction to Data Streams[END_REF][START_REF] Babcock | Models and Issues in Data Stream Systems[END_REF][START_REF] Bifet | Adaptive Stream Mining -Pattern Learning and Mining from Evolving Data Streams[END_REF][START_REF] Gama | Issues and Challenges in Learning from Data Streams[END_REF]. Further, the speed at which data arrives makes processing the data in real-time a prerequisite [START_REF] Babcock | Models and Issues in Data Stream Systems[END_REF][START_REF] Bifet | Adaptive Stream Mining -Pattern Learning and Mining from Evolving Data Streams[END_REF][START_REF] Gama | Issues and Challenges in Learning from Data Streams[END_REF]. Also, a temporal order of the arriving data is not guaranteed [START_REF] Babcock | Models and Issues in Data Stream Systems[END_REF][START_REF] Bifet | Adaptive Stream Mining -Pattern Learning and Mining from Evolving Data Streams[END_REF]. New algorithms furthermore need to be able to deal with temporal locality [START_REF] Aggarwal | Data Streams: An Overview and Scientific Applications[END_REF] (i.e., concept drift [START_REF] Widmer | Learning in the Presence of Concept Drift and Hidden Contexts[END_REF]), as the concepts underlying the data can change over time and thus make past data irrelevant of even contradictory. Finally, the algorithms need to be able to adapt the changing data structures and evolving feature space when old data sources are removed, new ones are added, previous potential features loose their discriminative power, and new features are becoming continually available [START_REF] Aggarwal | An Introduction to Data Streams[END_REF][START_REF] Babcock | Models and Issues in Data Stream Systems[END_REF][START_REF] Bifet | Adaptive Stream Mining -Pattern Learning and Mining from Evolving Data Streams[END_REF][START_REF] Gama | Issues and Challenges in Learning from Data Streams[END_REF].

Active learning [START_REF] Settles | Active Learning[END_REF] is a recent approach to machine learning. As gathering labelled data mostly is expensive (i.e., causing user effort during the training phase), the idea of active learning is to allow the algorithm to choose the data from which it learns by requesting labels from an oracle (e.g., a human annotator) in form of a query. By using algorithms that only request labels for instances that are close to the decision boundary, the required number of labelled examples is significantly reduced. The main difference between various active learning approaches is the way the algorithms queries for labels. The literature [START_REF] Settles | Active Learning[END_REF] currently distinguishes between membership query synthesis, pool-based sampling, and stream-based selective sampling. While the first approach synthesises artificial examples based on the provided features and their range of values, the second evaluates the entire collection of unlabelled instances upfront to pick the most promising examples for the query. The last approach, stream-based selective sampling [START_REF] Atlas | Training Connectionist Networks with Queries and Selective Sampling[END_REF], sequentially evaluates the unlabelled instances. For each instance-based on a given querying strategy-the algorithms decides if a label provided by an oracle is likely to improve the overall model quality and accordingly presents a query to the oracle or not.

In the next section we discuss, how the two approaches play together, to support the implementation of a lifelong learning system.

A Concept for Lifelong Learning of Personalised User Models

Context-aware systems adapt to the users' preferences based on sensing the current context. Therefore they apply machine learning algorithms to the sensor data in form of previously learned models that were trained in a batch learning approach [START_REF] Gama | Issues and Challenges in Learning from Data Streams[END_REF]. A sensor can be either a software or a hardware component used to capture data from the users' environment in the digital or physical realm. The underlying idea of batch learning is, that a certain amount of labelled data is available upfront and can be used to train a predictive model (e.g., a gesture recogniser). This trained model then can be applied to new data-with the primary assumption that the training and the new data is independent and identically distributed-in order to make inference on this data. However, the assumption that labelled training data is available at a given time and representative for future data may not hold in any case. When learning personalised user models for building adaptive systems, four influencing factors cause a demand a new machine learning approach: • Firstly, preferences for context-aware adaptations are often highly personalised and accordingly labelled data is sparse. For example, privacy-based decisions like revealing the current location to others have been found to be personal decisions are influenced by various factors [START_REF] Consolvo | Location Disclosure to Social Relations: Why, When, & What People Want to Share[END_REF]. • Secondly, the data can often only be labelled by the individual and only in the moment when it is experienced; assigning labels later based on a presentation of collected sensor data to the user is often not feasible. For example, the question how interruptible a person was at a given point in time can hardly be answered retrospectively [START_REF] Kapoor | Principles of Lifelong Learning for Predictive User Modeling[END_REF]. • Thirdly, the sensor data (like the labels) is highly personalised and grounded in the individual users' daily contexts, hence resulting in an individual evolving feature space based on a continuous sensor data stream. For example, if several people share the preference for muting their work phone when at home, the sensor data that allows localising a person as at home, is individually different (e.g., BSSID of the home network) [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF].

• And finally, preferences and contexts can change over time. Accordingly mechanisms are needed, which allow forgetting previously learned concepts, or overwriting them with new concepts, and also allow learning new concepts in new contexts. For example, a changing class schedule after a term break could lead to new preferences for when a phone should be automatically muted. Implementations of systems should take these factors into account, to provide usercentred adaptations in real-life contexts. In doing so, those systems should be clearly designed to reduce the overall effort for the user. That is, such systems should balance the training effort against the effort of manually adapting the system, and provide an optimised behaviour that greatly reduced the amount of work for the user.

Stream-Based Active Learning

Accordingly, to allow for lifelong learning of personalised user models, new machine learning approaches need to be utilised. We found that the characteristics of two machine learning approaches in their combination promise a solution, able to deal with the above constraints: active learning and data stream mining. As outlined before, active learning [START_REF] Settles | Active Learning[END_REF] departs from the premise that obtaining labelled data for supervised learning can sometimes be very expensive. Hence-instead of presenting a training set with labelled data to the algorithm upfront-the rational behind active learning is that an algorithm that is able to actively select the instances for which it requires labelling by an annotator performs equal or better with fewer labels needed. On the other side, data stream mining subsumes the ideas of learning from extremely large (potentially infinite) amounts of data that continuously arrive at great speed [START_REF] Gama | Data Stream Processing[END_REF] with the possibility of variations in the learned concepts as well as in the underlying data structures. A combination of both, as theoretically explored by Zliobaite et al. [START_REF] Zliobaite | Active Learning with Evolving Streaming Data[END_REF], promises a solution to the requirements of learning personalised user models. We therefore developed a concept, which utilises a combination of these approaches to enable stream-based active learning from sensor data streams, for lifelong learning of personalised user models. Fig. 1 illustrates the underlying principle of our concept-forming the basis of LILOLE-Framework.

In a ubiquitous environment, various sensors continuously monitor the users' contexts and activities, capture data from them, and provide this data in form of a sensor data stream. The arriving sensor data is pre-processed and converted to a feature vector that is processable by a machine learning algorithm. Based on this feature vector and a predictive model the system evaluates whether it is certain enough to adapt the system state and does so accordingly, or if it is uncertain continues training the predictive model. In the second case the user is queried by the system and gives feedback in form of a label. This label is used to train a learner to improve and update the predictive model and to directly adapt the system state.

An Application Scenario

For a more illustrative depiction of the principle we use a simplified, stripped-down scenario of a context-aware system that adapts the Instant Messaging availability status on a laptop computer based on the input of two sensors running on the computer: A Wi-Fi-Sensor (WF) and an Application Focus-Sensor (AF). The Wi-Fi-Sensor sends a list of all nearby access-points (SSIDs and BSSIDs) together with the respective signal strength (RSSI) every 30 seconds, allowing conclusions on a user's whereabouts. The Application Focus-Sensor sends the name of the current application every time the user switches to a new application, allowing conclusions about the user's activity. Whenever a new sensor event arrives in the sensor stream, the application transforms this data into a feature vector and evaluates the data with a decision tree (i.e., the predictive model). When the laptop user starts working with a new application at a familiar location, the model might not be confident enough to adapt the IM status automatically. Accordingly the user is asked about the preferred current availability status in a dialog. The status is adapted based on the user's input, and an incremental training algorithm (e.g., Very Fast Decision Trees (VFDT)) is used to update the decision tree. The next time the user switches to this application at the same location, the status is automatically adapted. While this simplified illustration gives a basic idea of the framework, in order to be flexible and robust for various settings and applicable with current implementations of machine learning algorithms, a few extra steps have to be taken. In the following, we provide further details of the LILOLE-Framework, starting with an overview that extends on the before discussed basic principle. We provide further details on the peculiarities when learning from streaming data in ubiquitous environments and how to integrate realtime feedback by end-users in form of active learning. Subsequently, we distil an algorithm for stream-based active learning from sensor events, which is the foundation of our framework. In the course of this paper we continuously refer to this scenario in form of examples for the different steps, algorithms and approaches.

The LILOLE-Framework

In the following overview of the LILOLE-Framework (depicted in Fig. 2) we extend on the previously simplified conceptual model of the principle of stream-based active learning from sensor data streams by providing more details on the necessary steps and by proposing adequate methods for each of those steps. We thereby concentrate on the transformation of the raw sensor data stream into a feature vector as well as the mechanisms of actively querying the user and training a predictive model. Finally, we derive an algorithm formalising the central steps.

Learning from Streaming Sensor Data

In order to learn from the sensor data stream, several steps need to be completed to preprocess the incoming stream of raw data into a feature vector that is processable by a machine learning algorithm. Each of these steps is now consecutively introduced:

Resampling & Segmentation. An incoming sensor data stream consists of a series of repeated measures from multiple sensors that basically can be understood as a multivariate time series (MTS). A MTS represents a series of observations over a time T where each observation at a given point in time t for a specific variables i is denoted. As each sensor can potentially send information at any given point in time, a first step is concerned with resampling the incoming sensor events to discrete timestamps. In our scenario where the WF-sensor was interval-based (i.e., sending an update every 30 seconds) and the AF-sensor is event-driven (i.e., sending an update only when a change occurred), there is a high possibility that for each point in time only data for one sensor is available (cf. Table 1). In order to further process this data, it is necessary to either upsample the data (e.g., through interpolation of the missing values) or downsample the data (e.g., by calculating the average over a sliding window) to a discrete time point resulting in a MTS with a fixed sample rate. The right approaches and parameters for resampling should be chosen based on the application scenario and the data. The second step is to cut the MTS into discrete segments of finite length, as the data stream constantly grows, and the MTS cannot be processed in its whole. Again, different algorithms for segmenting time-series are available [START_REF] Keogh | Segmenting Time Series: A Survey and Novel Approach[END_REF]. The application scenario and the expected data influence the selection of an appropriate algorithm. However, when apriori knowledge about the data is limited, a fixed-size sliding window for segmentation is often a valid first strategy.

Table 1. Example of the sensor data stream from our scenario, showing that data from the interval-based WF-sensor and the event-driven AF-sensor can be available at different time points (x denotes an incoming sensor event at a given time t n ).

t1 (0s) t2 (11s) t3 (30s) t4(60s) t7(83s) WF-sensor

x - x x - AF-sensor - x - - x
Feature Extraction. After the data is resampled and segmented, it is ready to be processed by the feature engineering chain. Each incoming segment represents an example (i.e., instance) that is later presented to the predictive model to be classified and to eventually further train the system. Thereby, feature extraction is the first step [START_REF]Feature Extraction, Construction and Selection -A Data Mining Perspective[END_REF]. The aim of the feature extraction process is to transform the raw sensor data into features that can be interpreted by the machine learning algorithms. This includes a transformation of the data into the data types the machine learning algorithms can process (i.e., numeric and nominal types [START_REF] Witten | Data Mining: Practical Machine Learning Tools and Techniques[END_REF]) and a reduction of the dimensionality to simple key-value pairs of attributes (i.e., features) with the aim to reduce the amount of irrelevant information. Coming back to our scenario, the WF-Sensor for each reading delivers a matrix listing the SSID, BSSID and RSSI of each nearby access-points (cf. Table 2). Based on this simple raw data, already a plenitude of features can be composed, as for example the following: The number of nearby access points (WF_Sensor_No=4) could indicate how dense the area around the users location is populated while a low average RSSI (WF_Sensor_Avg_RSSI=61,5) could indicate an outdoor usage. The absence, presence, or signal strength of an access point allows to infer the users whereabouts on different granularity levels. Different extractable features could tell that the user is on the University campus (WF_Sensor_SSID_ eduroam_Bool=true), near a specific lecture room (WF_Sensor_BSSID_001F4597E388_RSSI=62) or not at home (WF_Sensor_SSID_ HomeNet_Bool=false) when the history of sensor values is taken into account for feature extraction. The possible combinations are endless, while clearly not every combination does make sense (e.g., WF_Sensor_BSSID_ 001F4597E388_RSSI ="eduroam") and later can dilute the classification performance. While normally human domain experts guide the feature extraction process, in the case of our framework for lifelong learning, automatic strategies need to be found, as potentially new features are constantly arriving with each new sensor reading. Optimally, different strategies for feature extraction need to be combined here, that allow generating a rich representation of the sensor data. As exemplified above, this can happen through simple functions that calculate mean values from the sensor values, count the number of occurrences, etc. But also more sophisticated approaches such as Principal Component Analysis are conceivable as FeatureExtractionStrategies. If, in the end, not all extracted features meaningfully contribute to the classification result, simple filters or more powerful mechanisms for feature selection can remove those later.

Feature Construction. The next feature engineering step is concerned with creating additional features by discovering missing information about the relationship of individual features [START_REF]Feature Extraction, Construction and Selection -A Data Mining Perspective[END_REF]. While these dependencies of features also can be of multifarious nature and only mechanisms for the automatic feature construction [START_REF] Markovitch | Feature Generation Using General Constructor Functions[END_REF] can be taken into account, one aspect that becomes prevalent when using data streams is taking the factor time into account. So, instead of only using features from the last sensor reading, one promising strategy is to build features that take into account a period of time. Coming back to our scenario, features for the last 2, 5, or 15 minutes could be computed to provide additional information. By calculating the fraction of time a given feature was true they could indicate that somebody just arrived at a location in the last 2 minutes (WF_Sensor_SSID_eduroam_Bool_2m =0.2) or is focused on one application for longer (AF_Sensor_MSWord_Bool_15m =0.95). Other options for FeatureConstructionStrategies are calculating frequencies for Boolean values or the mean, standard deviation, etc. for numeric values.

Online Feature Selection. Feature Selection is the last step in the feature engineering [START_REF]Feature Extraction, Construction and Selection -A Data Mining Perspective[END_REF] process. Hereby the aim is to reduce the dimensionality of the feature vector, as most classifier perform significantly better on data with a low number of features. The reduction of features is especially necessary, as our approach so far continuously increased the number of features through the strategies of feature extraction and feature construction. Normally, feature selection algorithms select the most predictive features and remove irrelevant and redundant features based on an evaluation process where all features are available upfront as well as labelled data as evaluation criteria. As both prerequisites are not given in our setting of stream-based active learning, special algorithms for online feature selection [START_REF] Wang | Online Feature Selection and Its Applications[END_REF][START_REF] Wu | Online Feature Selection with Streaming Features[END_REF][START_REF] Wu | Online Streaming Feature Selection[END_REF] need to be applied. Conclusively, the process of feature selection constantly can suggest different, improved combinations of features. As each new feature vector would require a new model to be trained, a FeatureSelectionStrategy also has to decide, when switching to a new feature vector-and hence to a new model-is beneficial for the overall performance. In the following, more details on how to deal with the resulting multiple models are provided.

Active Learning of User Preferences

Based on the previous steps, the framework is now able to provide the incoming sensor data as single instances with a fixed number of features to the predictive model for evaluation. Based on the update frequency of the sensors, and the chosen parameters for resampling and segmentation a new instance for evaluation is available in a fixed rhythm (e.g., every few seconds). Each time an instance arrives, an ActiveLearningStrategy decides whether it uses the instance for adaptation or whether it queries a label from the user. In order to provide an understanding of what a simple ActiveLearningStrategy looks like, we use the example of the Fixed Uncertainty Strategy [START_REF] Zliobaite | Active Learning with Evolving Streaming Data[END_REF]. The Fixed Uncertainty Strategy provides the instance to the classifier (i.e., predictive model) in order to obtain a prediction. The strategy then compares the confidence value or the posterior probability of the classifier to a fixed threshold defined e.g. by the developer.. If the classifier is confident enough about the classification, the strategy performs the adaptation based on the classification result, otherwise the user is queried for a label. Of course, more sophisticated active learning strategies are needed, to allow building user-centred systems, not overburdening the user with the training effort. One illustrative example is the introduction of a simple upper-limit on the number of queries a strategy is allowed to pose to the user in a given time frame. Other strategies are decision-theoretic approaches as proposed by Kapoor et al. [START_REF] Horvitz | Experience Sampling for Building Predictive User Models: A Comparative Study[END_REF] and also strategies that simply detect novel situations, by applying clustering algorithm on the incoming data, as presented later in our implementation.

The presentation of the query to the user and the feedback by the user (i.e., provisioning of the label) also allows for different approaches. In GUI based systems, an experience sampling based approach [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF][START_REF] Horvitz | Experience Sampling for Building Predictive User Models: A Comparative Study[END_REF] is feasible, as exemplified for our scenario in Fig. 2. Of course depending on the application context, multifarious query and feedback mechanisms are conceivable, e.g., a vibration pattern of a smart watch could query the current interruptibility, allowing the user to simply respond by performing a gesture. Depending on the provision of a label, the final step now is to update the model through training with the instance and corresponding label. As the training data arrives sequentially, only classification algorithms that allow for incremental learning can be applied in our framework. Examples for such algorithms are incremental decision trees like Hoeffding trees or Very Fast Decision Trees (VFDT), online variants of kernel learners like LASVM or more basic algorithms like an updateable Naïve Bayes classifier.

In respect to our setting that requires learning from data streams under the assumption of concept drift and feature evolution, additional steps need to be taken in the model updating process. As noted in an earlier step, foremost the application of a FeatureSelectionStrategy requires flexibility in the model updating process, as most algorithms cannot deal with instances represented by a changing combination of features (i.e., feature evolution). Accordingly, each time the FeatureSelectionStrategy suggests a new set of features also a new model needs to be trained. As this would require starting the learning process from scratch, three mechanisms (cf. Fig. 2) allow a smooth transition and preservation of the previously learned concepts. First, the use of ensemble classifiers [START_REF] Opitz | Popular Ensemble Methods: An Empirical Study[END_REF][START_REF] Rokach | Ensemble-based Classifiers[END_REF][START_REF] Wang | Mining Concept-Drifting Data Streams Using Ensemble Classifiers[END_REF] allows combining several models into one. When a classification is requested, different ensemble strategies (e.g., bagging or boosting) provide a weighted classification result, computed from the individual models. Ensemble approaches have been demonstrated to work well for learning from concept drifting data streams [START_REF] Opitz | Popular Ensemble Methods: An Empirical Study[END_REF][START_REF] Rokach | Ensemble-based Classifiers[END_REF][START_REF] Wang | Mining Concept-Drifting Data Streams Using Ensemble Classifiers[END_REF]. Second, attribute bagging [START_REF] Bryll | Attribute Bagging: Improving Accuracy of Classifier Ensembles by Using Random Feature Subsets[END_REF] (also feature subset ensembles or random subspace method [START_REF] Ho | The Random Subspace Method for Constructing Decision Forests[END_REF]) are specialised ensemble methods for learning from instances with different feature vectors, that can be fitted to tackle the challenges of dealing with an evolving feature space. Third, the application of cotraining [START_REF] Blum | Combining Labeled and Unlabeled Data with Co-training[END_REF] in both cases allows to train new models separately, before they are added to an ensemble. Co-training simply uses the classification output of the current ensemble, to train new models, with new feature subsets, until a certain training criterion is met. This approach would allow training a new model for a specific period, before it is actively used for predictions in the ensemble. In the previous sections we described in detail our concept of the LILOLE-Framework, and provided examples for the implementation including promising strategies and available algorithms. In order to provide a more formalised documentation of our approach, we propose the following algorithm for the streambased active learning from sensor data streams to enable lifelong learning systems. In the next chapter we provide insights in an implementation and provide results of a simulation with real user data.

An Algorithm for Stream-Based Active Learning

Implementation and Evaluation of the Framework

In order to put our approach into practise, we build a first reference implementation of our framework, and evaluated the feasibility of the approach in a simulation with real user data. The main aim was to test the end-to-end feasibility of our approach of stream-based active learning. As a basis for our implementation we used Sens-ation [START_REF] Gross | Sens-ation: A Service-Oriented Platform for Developing Sensor-Based Infrastructures[END_REF], an event-based platform for ubiquitous computing, that allows integrating sensors, inference engines (i.e., parameterisable inferencing mechanisms) and actuators. A visual editor for Sens-ation [START_REF] Schirmer | CollaborationBus Aqua: Easy Cooperative Editing of Ubiquitous Environments[END_REF] allows us to easily connect sensors, inference engines and actuators in order to layout the event flow (cf. Fig. 3.1). We implemented a variety of the proposed strategies in form of parameterisable inference engines (IE) for Sens-ation, which could be configured in the editor (cf. Fig. 3.2). However, for some of the strategies we only provide naïve implementations, as the main focus at this state was on the general feasibility of the framework. For all machine learning algorithms, we used the WEKA toolkit [START_REF] Witten | Data Mining: Practical Machine Learning Tools and Techniques[END_REF].

For Resampling and Segmentation we implemented two separate IEs, each configurable to use one of various strategies. For resampling, we implemented one simple strategy called LastValueStrategy: each time a new sensor event arrives, the value is stored. Depending on a chosen push method, the stored last values for all sensors are either passed on to the next inference engine, each time a new senor event is incoming, or in a configurable time interval. For segmentation, we implemented a simple FixedWindowStrategy, with a configurable window size. While the IE for feature construction implements several of the mechanisms proposed above, the IE for feature extractions only extracts two simple features, which is the day of the week and the hour of the day. Finally, for the online feature selection (OFS), we implemented a naïve random strategy, that randomly selected a percentage of the features for the feature vector. While we were aware that this decision degrades the machine learning performance, the lack of implementations for OFS algorithms at this time in standard machine learning toolkits and the focus of the end-to-end feasibility did not allow for a different solution.

For the active learning IE we implemented two ActiveLearningStrategies: a FixedUncertaintyStrategy with a configurable minimum and maximum threshold for the confidence value; a strategy based on the COWEB clustering algorithm that queries for labels, when changes in the underlying data are detected (ClusterStrategy). The IE for the model and the learner (i.e., classifier algorithm) provides the most flexibility by accepting WEKA command-line strings, for setting and configuring a classifier. Of course, the IE accepted only incremental classifiers, that is, all WEKA classifiers that implement the Interface UpdateableClassifier. Furthermore, the use of advanced strategies for model updating like ensemble classifiers and attribute bagging were not applicable, as we had no sophisticated mechanism for feature selection. Finally, the adaptation mechanisms as well as the label query were implemented as Sens-ation actuators. For the adaptation we implemented two demonstrators: One was able to control the system volume of a PC, the other was able to adapt the Instant Messaging status. For the querying mechanisms, we implemented a simple, XML-configurable ESM-like dialog (cf. Fig. 2). The feedback of the user was passed back to the Sens-ation in form of a sensor event. For the evaluation we relied on a dataset from previous work that assessed the predictability of availability for IM [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF]. In average an accuracy of 81.35% was reached in this work for this dataset. It needs to be noted that these are the results of an offline, explorative machine learning approach, where step-by-step the best features, algorithms, and parameters where chosen by a human expert based on computational expensive grid search. Accordingly, this accuracy was not considered not as a benchmark but only as a guiding value for our current implementation, relying on naïve implementations and with near real-time constraints.

The data provided a variety of characteristics that deemed it an ordeal for our approach. The dataset, collected by four individuals consisted of several month of sensor data recorded on their laptop computers, together with two estimates of their own availability for IM every hour. 30 different sensors collected data such as nearby Bluetooth and Wi-Fi devices, running applications, connected USB devices, the presence of people, etc., with sampling rates between 30 and 150 seconds and in form of sensor events of varying dimensionality (i.e., sensors that only provide a single value per reading up to sensors that provide a multi-dimensional matrix of values). For the performance evaluation, we implemented a playback application (cf. Fig. 3.3), which read the data from the provided XML-dataset files and send it to Sens-ationpractically simulating events from live sensors. For the evaluation, the temporal information in the datasets was omitted, and the data was played back as fast as it could be read from the files. In Sens-ation, all incoming sensor data was preprocessed. However, of course only that data could be evaluated where a label was available as evaluation criteria. For the evaluation, a specially programmed actuator allowed to write out the data received from the evaluation inference engine. As many existing metrics for measuring the performance of machine learning (e.g., accuracy, precision or recall) are of limited expressiveness for our setting of lifelong learning, we illustrate our results based on a trend chart over time. Fig. 4 exemplary shows the results for the dataset of one user over a period of roughly four months (Oct. to Feb). The algorithm used for classification was an incremental Naïve Bayes implementation. A FixedUncertaintyStrategy was applied as the ActiveLearningStrategy with a minimum threshold of 0.6 for the confidence valuethat is, if the confidence for a prediction falls below the 60% mark, a label is requested. The chart shows the accuracy of the classifier (blue line), quickly goes up and then dithers around 70% until in the last third-the weeks around New Year-it suddenly breaks down to 20% until it goes up again. This effect is likely caused through the occurrence of a concept or feature drift. In this specific case, probably due to a holiday break of the user that provided the data, which led to different circumstances, a different environment or different availability preferences for this period. Also clearly visible is how the number of queries for labels (vertical pink lines) triggered by the ActiveLearningStrategy goes down after an initial intense learning phase. And likewise, how the concept or feature drift around New Year, leads to a more intense training phase at the end of January. While the overall accuracy of the classifier does not reach a performance as demonstrated in [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF]where an average accuracy of 81.35% could be achieved in an offline evaluation with manually crafted feature sets and hand-picked algorithms-it is also true that our implementation does yet not fully exploit the full power of our proposed concept. As in most parts we relied on naïve implementations for the strategies, our main aims was to demonstrate the general feasibility of a lifelong learning system, based on our proposed conceptual framework. The integration of a real feature selection mechanism and the application of more advanced learners like kernel learners or tree ensembles are likely to boost the performance, leading to less queries and a higher accuracy-closer to that of the manual process in [START_REF] Fetter | Predicting Selective Availability for Instant Messaging[END_REF].

Conclusions and Future Work

We presented the LILOLE-Framework, a conceptual framework for lifelong learning from sensor data streams for predictive user modelling. The conceptual framework combines the strength of data stream mining and active learning, and thus allows building complex adaptive systems that learn from individual user over a prolonged period of time. We provided detailed insights in the necessary components and building blocks, as well as the underlying processes and data flow, which can guide the engineering process and architectures of similar systems. An end-to-end implementation, partially based on simple and naïve algorithm implementations, already proves that our system is able to learn form an evolving data stream and to adapt to concept drifts. In future work we will extend the number of implemented algorithm, and add more sophisticated mechanisms to the implementation, as already described in the concept.

Mainly, our implementation will ultimately allow us to assess more human-centred aspects of the approach of life-long learning. While previous work assessed the improvement of personal user models through life-long learning only theoretical through offline accuracy and performance measures, our implementation now allows to get real user feedback on the adaptation in field tests in real settings. This includes aspects like the adaptation quality or the satisfaction with the training effort, and allows researching and revealing further human-centred aspects.

Fig. 1 .

 1 Fig. 1. Illustration of the basic principle of stream-based active learning from sensor data streams for lifelong learning.

Fig. 2 .

 2 Fig. 2. Overview of the LILOLE-Framework.

Fig. 2 .

 2 Fig. 2. Exemplary experience sampling dialog for our IM scenario.

Fig. 3 .

 3 Fig. 3. Overview of our setup for the simulation, including the event flow in the visual editor (1) between sensors (white boxes with scale symbol at the left), inference engines (beige boxes with gear symbol in the centre) and actuators (lime boxes with light bulb symbol at the right); two inspector windows, each showing the parameters for an inference engine (2); and the sensor data player (3).

Fig. 4 .

 4 Fig. 4. Results of the NaïveBayesUpdateable classifier over time for one dataset. Each red and green cross marks the availability of a label in the data set, that was either predicted right (=1.0) or wrong (=0) by the classifier, whereby each vertical pink line shows a query for a label triggered by the ActiveLearningStrategy. The blue line shows the overall accuracy of the classifier over time. (Further: red line = confidence for real class; pink line = confidence for predicted class; green line = normalised absolute difference between real and predicted class).

Table 2 .

 2 Example of one sensor event of the WF-sensor listing nearby access-points.

	SSID	BSSID	RSSI
	UniXXXXXX 00:1F:45:97:E3:81	-54 dBm
	eduroam	00:1F:45:97:E3:80	-51 dBm
	eduroam	00:1F:45:97:E3:88	-62 dBm
	MyNet	00:4F:81:05:0B:8A -79 dBm

Algorithm 1 :

 1 Stream-based Active Learning from Sensor Data Streams Input: strategy parameters, strategies Output: o t as output label for instance I t for each s t -incoming SensorEvent, do resample s t to discrete timestamps t' and add to resampled data stream segment resampled data stream into segments S

	end for
	end for
	build I t' -instance from Features
	if FeatureSelectionStrategy (I t' ,…) = true then
	start a new classifier C n with selected features
	end if
	for each I t' -incoming instance, do
	if ActiveLearningStrategy(I t' ,…) = true then
	query the true label a t' of instance I t' from the user
	train ensemble E with (I t' ; a t' )
	return true label at' as output o t'
	else
	classify I t' with ensemble E and obtain the predicted label p t'
	return classification result p t' as output o t'
	end if
	if C n exists then
	co-train classifier C n with o t'
	if C n is trained then
	add classifier C n to Ensemble E
	end if
	end if
	adapt the system based on o t'
	end for
	end for

t' =[ s t', s t'-1, s t'-2,… s t'-w ] for each FeatureConstructionStrategy(…) do for each FeatureExtractionStrategy(…) do constructFeatures(extractFeatures(S t' ))

Acknowledgments

We thank members of the CML, especially Jonas Pencke and David Wiesner.