The Knowledge Management Lab
University of Toronto

Description

New applications related to proactive ubiquitous computing will start to be demanded in the future. Take for instance, smart homes, a complex network of computers sensors and activators that will be embedded in homes. It is natural to think that these kinds of systems will have to be customized according to the people that will be living there. One kind of such customization is aimed at impaired people. For example consider the use of e-mail by survivors of brain injuries. These users would be able to use email more readily if it were adapted to their particular skills and needs.

Most of the software engineering methods do not take customization into account. As a consequence, software usually adopts the one size fits all model, with the inevitable result of being a poor fit for many users. Exceptions of this rule either focus just on human interfaces or take a very coarse grain view (product families), where customization is geared to large target groups and not individuals.

Software engineers do not have robust methods for discovering, modeling and analyzing the criteria with which the variants of full product should be produced. Consequently, instead of delivering software that adapts to the user's needs, the one-size-fits-all approach, that is currently followed, requires the user to adapt to the software's needs.

Moreover, even if the delivered software can be configured to some extend, this cannot usually be done without diving into a chaos of technical terms and low level adjustments, which are out of reach for ordinary users.

In this project we study the process and the necessary infrastructure that will allow fine grained software customization. Such customization will be defined and analyzed from the early definition of the desired artifact, at the requirements level, focusing both on the customization of non-functional aspects, like interfaces, as well as on the customization of functional characteristics of the future artifact.

Furthermore, we consider software variability as a result of two processes. First, software customization leads to the definition of the appropriate variants of the full product. Then, through personalization, each of the intended users will be assigned the variant that best suits to her needs.

Our approach for the problem departs from the extensive experience of the group in working with goal models and their analysis. A first result towards this direction was the goals, skills and preferences framework ([Hui, 2003]). In this work, goal models serve as descriptions of the variability in the requirements level by implying alternative ways for the user goals to be satisfied. Technically, alternatives are solutions of an AND/OR goal decomposition tree. Then, each alternative is characterized in terms of the skills it requires and the generic user preferences it presumes. Skills and preferences describe the users' abilities and desires. At the personalization phase, given a real profile of skills and preferences the most suitable alternative can be selected.

Shown below is a detail of one of the goal models we have been developing for the needs of our case study on a communication system for people with traumatic brain injury. It illustrates a goal and 6 alternatives for satisfying it. In practice, the number of the alternatives of the whole goal system may reach several tens of billions. This is an index of the achieved granularity of the customization analysis.

Our initial results have shown that there are several open questions in the adoption of goal models for software customization. If the natural variability implied by goal decomposition models proved an intuitive and useful way for both describing and analyzing options, the next question is how this model can lead us to the implementation of the actual software system.

Can we derive a fine grain customization product family from the goal models [Leite, 03]? Is it possible to extend the selection criteria beyond skills and preferences? For instance, how can we deal with contextual restrictions and opportunities? And how can we guarantee that the refinement of the models does provide the right configuration as selected at the goal level?