We report the results of a study comparing two concurrent think-aloud approaches for usability testing: the classic think-aloud (CTA) and an interactive think-aloud (ITA). The think-alouds were compared in respect of task performance and usability problem data. We also analyse the utility of the interventions used within the ITA in eliciting useful participant utterances. The most useful interventions were those focused on seeking explanations and opinions; these generated more utterances about user difficulties. Requests for clarifications, particularly about actions, resulted in fewer useful utterances: participants responded with simple procedural descriptions. In comparing the CTA and ITA, we found no differences in the number of successfully completed tasks, but the ITA did elongate the test session. The ITA led to the detection of more usability problems overall, and a greater number of causal explanations. However, the ITA produced more low-severity problems than the CTA.

Technology probes were used to investigate what adolescents would find persuasive in digital devices supporting opportunistic (unstructured/unplanned) exercise. The probes comprised pedometers, handheld consoles with an exercise game and a customised social website with an exercise focus. Three groups of six adolescents participated in the field study. To contextualise the study their attitudes to exercise, and exercise behaviours, were collected at the start and end of the study. The participants logged their daily exercise and noted any barriers that they encountered over six weeks. They reflected on these experiences and took part in innovation activities to identify requirements for motivational exercise technology. Analysis of the results revealed that they desired individual customisation of devices that can capture a wide range of physical activity data. Moreover, social interaction is expected within digital media and positive messages reinforcing goal attainments are valued, whereas negative feedback demotivates. These findings support those reported in other studies of both children and adults. More specific to this age group was their openness to sharing information beyond their friendship groups, although this was counterbalanced by their lack of autonomy in the physical world. This highlights issues that could constrain the effective design of technology for this age group.

The instructions used in think-aloud studies can range from a simple request to think-aloud, to an explicit instruction to include certain types of content. The present study compared two think-aloud instructions: the classic neutral think-aloud instruction and an explicit instruction requesting explanations and content that is relevant to the user experience. Data from task performance, mental workload, think-aloud protocols and usability problems were collected from 16 participants, equally distributed between the two think-aloud instruction conditions. No differences were found in task performance, however, participants in the explicit instruction condition reported higher mental workload and a focus on finding interface problems. The explicit instruction condition also yielded more utterances about the user experience, expectations and explanations of behaviour than the neutral condition. An analysis of the resultant usability problems revealed that the explicit instruction led to a larger number of dialogue, navigation, layout and functionality problems, but that the problems which were unique to this condition were, in the main, at a low level of severity.

Verbal protocols are the primary tool for understanding users' task-solving behaviors during usability testing. A qualitative study that examined the utility of combining a concurrent and retrospective think-aloud within the same usability test is described. The results indicate that although there was significant overlap between the types of utterances produced during each think-aloud, the retrospective phase produced more verbalizations that were relevant to usability analysis, for example, helpful self-assessments of performance, yielding insights into the impact of encountered difficulties. However, a small number of less desirable utterance types emerged: hypothesising, rationalizing, and forgetting. When used together, both methods contributed to an understanding of usability issues; the concurrent phase yielded more usability issues overall, and the retrospective data improved the understanding of these by (a) reinforcement: users highlighted the impact of an issue on their experience, (b) elaboration: users would provide causal explanations of encountered difficulties, and (c) context: users provided information about the product's context of use.

By undertaking projects that have a real-world dimension students are highly likely to gain the skills and abilities which industry requires. An outline is presented of the range of taught masters level programmes at the University of Sunderland highlighting the requirement for each student to undertake a capstone project. Details are presented of an approach, involving empowerment and control, that has enabled hundreds of successful projects to be undertaken with industry ever year. Finally reflections are presented along with details of developments.

Effective links between industry and academia are of greatest importance if real-world industrial practices are to be communicated to students. The challenges that exist with regard to ensuring that Software Engineering curricula address important industry-related aspect are addressed. A literature survey is presented and details are given of an ongoing project concerned with industry/academic links. Findings are presented and finally suggestions are made with regard to areas that need urgent attention.

The areas of student projects and work experience in undergraduate and taught postgraduate programmes provide a focus for this open event. The key objectives set for the activities are (i) to gain information on specific instances of: project-based classes, capstone course(s), and student work, (ii) to gain an understanding of: beneficiaries and benefits, constraints, risks and challenges, and resources that are needed and those actually provided, (iii) to undertake evaluations - both pros and cons.

University/Industry interactions are examined in this fourth of a series of open events that are providing inputs to an international project funded through the United Kingdom's Teaching Fellowship Scheme. These inputs will support the part of the project which is concerned with gaining knowledge of industrial Software Engineering practices and the development of a framework that can be used in the classification and evaluation of such practices.

A fifteen week module on software engineering management exposed graduate students to practical aspects of the management of software development: emphasizing the recording and analysis of factual data during a group project. Data generated within the six projects are analyzed to reveal the extent to which the students demonstrated the required management and monitoring competencies. These results showed the student groups on a spectrum from full competence to no evidence of competence. The most interesting results were for the three groups in the "partially competent" range: and it is these that are discussed in most detail. The group work was retrospectively evaluated against SWEBOK knowledge areas to analyze the extent to which they were covered. Finally the issues that need to be considered in an explicit use of SWEBOK, and the need for support from automated data collection and analysis are discussed.

The workshop will provide the initial inputs to a project that is being funded under the UK National Teaching Fellowship Scheme (NTFS) which is concerned with enhancing the education that supports IT professionals. The project involves:

Innovative University/Industry interactions are examined in this open event with the aim of providing inputs to an international project that is being funded through the United Kingdom's Teaching Fellowship Scheme. These inputs will support the first stage of the project which is concerned with gaining knowledge of industrial Software Engineering practices and the development of a framework that can be used in the classification and evaluation of such practices.

There are currently insufficient skilled software engineers to meet the needs of industry across the world. Intensive taught Masters level programmes represent one solution to this shortfall. One such programme is the MSc in Software Engineering offered by the University of Sunderland in the UK. This was developed to satisfy student needs both within and outside the European Union.. The constraints and challenges that needed to be addressed in the development of the programme are outlined. The programme and the various pathways through it are described. Student feedback on the programme is reported. The programme is evaluated and some of the lessons learned since its inception in 1999 are reviewed.

Work is currently being undertaken under the auspices of the Association for Computing Machinery (ACM) and the Institute for Electrical and Electronic Engineers Computer Society (IEEE-CS) to produce the Software Engineering volume for the project known as Computing Curriculum 2001 (CC2001). The work undertaken to date is considered and details are presented of the approach that is being taken. Summaries are given of three major events that have been used to assist in the development and appraisal of the work: a workshop at the Fifteenth Conference on Software Engineering Education and Training (CSEE&T 2002), an International Summit on Software Engineering Education (SSEE) which was colocated with the 24th IEEE-CS/ACM International Conference on Software Engineering (ICSE2002), and a workshop held in Chicago in May 2002. Finally an appraisal regarding progress and what still needs to be addressed is given in terms of the principles defined for the project.

There is a clear need to develop Software Engineering courses to meet local, national and international needs. Recently a joint task force of the IEEE Computer Society and the ACM have been engaged in producing undergraduate curricula and associated documentation known as Computing Curriculum 2001 (CC 2001). For this to be accepted there needs to be involvement by the wider community and evaluation should be undertaken to determine the usefulness of the parts of CC 2001 that is relate to Software Engineering. In this workshop the prime aim will be to evaluate the use of CC 2001 in the development of Software Engineering courses. A final outcome of the workshop will be the production of a report detailing the major recommendations relevant to the aim and the topics considered. This will be circulated to participants and a paper based on it will submitted for journal publication.

Deploying IT systems has always presented a combination of challenges and risks to decision-makers. Many IT projects have failed to accomplish their cost, schedule, or technical performance objectives. However, the factors that are encountered in deploying IT/IS projects in developing countries differ from those encountered in developed countries due to cultural and organisational reasons. Oman is one developing country that has started, slowly, exploring the use of computer systems to help in improving their business. The case is made that Oman needs to have a coherent IT strategic vision at the national level. Implementing this vision into detailed strategies depends on the high awareness of the positive role IT can play in the economy, counterbalanced by the ability to manage the associated risks. The factors that are associated with implementing IT/IS in Omani government organisations are: human resource deficiency, organisational inefficiencies, and the immaturity of the IT business culture. The risk factors that arise in the context of the Omani culture are contrasted with those that have been reported in the literature.

The prime aim of the workshop is to provide a forum to consider the global dimensions. of a Software Engineering Profession and determinethe relevance and usefulness of IFIP's initiative concerning harmonization. In achieving this aim our objectives are to examine: The current situation with regard to certification of licensing in different countries; The drivers and constraints regarding Software Engineering Professionalism; and to determine: The extent to which world-wide Software Engineering Professionalism is achievable (particularly in the light of IFIP's proposals) Possible strategy(ies) that would assist in achieving such world-wide Software Engineering Professionalism.

There is extensive literature highlighting the difficulty in evaluating the success of software applications, and even in defining the meaning of the term "success". Two complementary studies are presented that have focused on this from different perspectives (in the context of small-medium organisations (SMOs)) in terms of: (i) return on investment and (ii) user satisfaction. The former has adopted case study analysis, the latter longitudinal surveys as the instruments used: illustrative results are provided for both approaches. Results indicate that within the first case study company there is a strong link between the identified company strategy typology and the attitude to the type of investment undertaken. The preliminary results from the second case indicate that, contrary to received wisdom, user satisfaction with systems can exist despite a lack of liaison between developers and users in the requirements phase. Other factors that have influenced this satisfaction are outlined.

In this workshop the prime aim will be to determine a set of guidelines that can be used in the development of graduate and postgraduate Software Engineering courses. In achieving this aim the our objectives are to examine: Curricula: soft and hard optionsCore and non core subjects and the place for optionalityRelationship with research specialismsDelivery modes and teaching and learning mechanismsAssessmentMeeting the needs of industry: with regard to existing and new staffThe role of professional bodies and aspects relating to accreditation and licensing.

S.665-668

Within the UK, as for the rest of the world, there is an acknowledged shortage of highly skilled software engineers. In UK academia, there is a chronic shortage of able candidates to fill posts at all levels, from research students (through research fellows and lecturers) to professors. It is clear from salaries being offered in industry that it is a "seller's market". However, since thousands of students graduate each year in the UK with computing degrees, questions must be asked about the extent to which software engineering is addressed within these courses. It is impossible to consider software engineering curricula without giving acknowledgement to the impact of human factors, organisational issues and cultural norms. Therefore, in looking at software engineering education, I believe we need to devise syllabuses that not only address technical issues (such as the object-oriented paradigm, metrics or metaCASE technology) but also the "sociotechnical" concerns (such as the usability of systems and the requirement to engineer systems to situationally specific work practices). Identifying what should be taught is only part of the problem; the other part is how. Experience has demonstrated the need to consider unconventional study patterns if we are to attract students to our courses, particularly those in industry who wish to re-skill or extend their professional development.

Within small organisations, where software and IT are often seen as simply technology to support the business (rather than as a central component of it), the issues associated with legacy systems are rarely assessed. What constitutes a legacy system and how such systems should be viewed are considered. From case study material four distinct acquisition policies used by small organisations are identified: in-house professional software development, third party bespoke software development, specific commercial off-the-shelf packages and general commercial off-the-shelf packages. In addition, from the collected data it has been possible to classify the different strategies that are adopted in integrating these varied software artefacts into a company software portfolio. The areas of concern that affect the success of such strategies are highlighted. Details are then presented of the RAMESES method which has been developed to ensure that when changes are proposed they are evaluated within the context of the organisation: its culture, working practices, expectations, expertise, and experience. Current work and future extensions related to the method are outlined and overall conclusions are presented.

The aim of the MEA (Method Engineering Activity) framework is to support the process of creating situation and project-specific methods for information systems development. In order to contextualise the work and to assist in understanding why we believe this approach is necessary, the article provides an overview of the issues that have driven the development of the framework. Structured methods are created and have evolved to support the process of systems development, yet we are in a situation where only a relatively small proportion of developers use them. In addition, of those who do use methods, the majority feel the need to adapt them to suit individual projects. The first problem is to find one or more methods that are relevant to your organisational needs that can be used as the starting point for the development of individual projects. Assuming that that can be achieved, and this is far from straightforward, many developers rely on their development experience to create project-specific methods from these base methods. The second problem is that there are very few widely known approaches that provide support for this engineering of situation-specific methods and there is always the risk of losing what strengths exist in methods through their unsupported modification. The third problem is that individuals want different things from the methods they use and methods do not always provide what is required in a way that fulfils expectations.

The forces that operate within the software industry are outlined and the case is made for postgraduate software engineering education that is flexible in terms of attendance patterns and responsive to the market in terms of curricula. The developments within a postgraduate "conversion" course at the University of Sunderland over a nine year period with regard to both patterns of delivery/attendance and curricula are then described (including the origins of the course and the development of five different delivery mode). The 1992 modularisation and the 1995 review of the course are described. The structures of the pre- and post-review versions of the course are outlined, and particular details are given of the approaches adopted towards the treatment of software engineering (SE) in the two versions of the course. The reasons behind the changes that were introduced are given and information is provided on the innovative teaching and learning approaches adopted within the revised course. Finally a critical appraisal is presented with regard to the changes introduced in the course and questions are identified that educationalists and industrialists need to address with regard to such courses.

Software development methods can only be used effectively where there is a close match between the method being used and the situational application. There are two key features that need to be considered by those concerned with formalising the development of situational methods: (i) the stakeholder input and (ii) the method engineering process. The method presented, MEWSIC (Method Engineering With Stakeholder Input and Collaboration), formalises the development of situational methods so that links to quality assurance processes is retained. MEWSIC accounts for the number of stakeholders who have a legitimate interest in the success of the project but distinguishes between those who provide input that informs the method engineering process and those who carry out this process. A description of MEWSIC is given bringing out the collaborative nature of the approach. The authors then discuss MEWSIC's place within software engineering (particularly in relation to method engineering approaches and quality assurance mechanisms).

There is a close association between many current CASE tools and structured methods. Both technologies offer benefits to developers, but unfortunately they are not as widely used as they might be. Possible reasons for this are reported which have been deduced from an analysis of replies to two surveys carried out in the 1990's of computer users in the UK. A possible resolution to the situation is suggested through the use of metaCASE tools; however, existing paradigms do not go far enough to resolve the problem. It is argued that it is possible to take advantage of existing models to provide a more holistic approach to the engineering of methods.

The reverse engineering into CASE technology method (RECAST) takes the source code for an existing COBOL system and derives a no-loss representation of the system documented in a structured systems analysis and design method (SSADM) format. One key element of the method is the abstraction of logical processing that affects the individual entities of the system. For each entity this processing is extracted from the physical implementation of the system using a program slicing technique and is then transformed into a logical representation (as an entity life history) using a set of translation and transformation rules. How the abstraction is achieved is described, and an example derived from an existing operational system that has been used as a case study for the method is given.>

The authors outline the problems associated with software production and details how the STePS method can alleviate them. They provide an overview of STePS as a method for developing systems beyond the logical design stage into detailed program design and implementation. This method operates on the products of a systems design method to identify the programs in a system. It then uses well-established design techniques to develop the specification for the software components that will comprise these programs. The need for comprehensive program specifications to facilitate the design/implementation interface is explained and the contents of the different forms of STePS specifications are outlined. The beneficial effects which the use of STePS can have in the areas of quality assurance, control, project management, and configuration management are presented.>