Jeff Winter
email: jeff.winter@bth.se

Kari Rönkkö
email: kari.ronkko@bth.se

Mårten Ahlberg
email: marten.ahlberg@uiq.com

Jo Hotchkiss
email: jo.hotchkiss@sonyericsson.com

Meeting Organisational Needs and Quality Assurance through Balancing Agile and Formal Usability Testing Results

Keywords: agility, formalism, usability, product quality, methods & tools

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Osterweil et al [START_REF] Osterweil | Strategic directions in software quality[END_REF] state that product quality is becoming the dominant success criterion in the software industry, and believe that the challenge for research is to provide the industry with the means to deploy quality software, allowing companies to compete effectively. Quality is multi-dimensional, and impossible to show through one simple measure, and they state that research should focus on identifying various dimensions of quality and measures appropriate for it and that a more effective collaboration between practitioners and researchers would be of great value. Quality is also important owing to the criticality of software systems (a view supported by Harrold in her roadmap for testing [START_REF] Harrold | Testing: A Roadmap[END_REF]) and even to changes in legislation that make executives responsible for damages caused by faulty software.

One traditional approach to quality has been to rely on complete, testable and consistent requirements, traceability to design, code and test cases, and heavyweight documentation. However, the demand for continuous and rapid results in a world of continuously changing business decisions often makes this approach impractical or impossible, pointing to a need for agility. At a keynote speech at the 5th Workshop on Software Quality, held at ICSE 2007 [START_REF] Wosq | Fifth Workshop on Software Quality[END_REF], Boehm stated that both agility and quality are becoming more and more important. Many areas of technology exhibit a tremendous pace of change, due to changes in technology and related infrastructures, the dynamics of the marketplace and competition, and organisational change. This is particularly obvious in mobile phone development, where their pace of development and penetration into the market has exploded over the last 5 years. This kind of situation demands an agile approach [START_REF] Boehm | Keynote address, 5th Workshop on Software Quality[END_REF].

This paper deals with a case study of a usability test package called UIQ Technology Usability Metrics (UTUM) [START_REF]UIQ Technology Usability Metrics[END_REF], the result of a long research cooperation between the research group "Use-Oriented Design and Development" (U-ODD) [START_REF]Use-Oriented Design and Development[END_REF] at Blekinge Institute of Technology (BTH), and UIQ Technology (UIQ) [7]. With the help of Martin et al.'s study [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF] and our own case study, it presents an approach to achieving quality, related to an organizational need for agile and formal usability test results. We use concepts such as "agility understood as good organizational reasons" and "plan driven processes as the formal side in testing", to identify and exemplify a practical solution to assuring quality through an agile approach.

The original aim of the study at hand was to examine how a distributed usability test could be performed, and the effect that the geographical separation of the test leaders had on the collection, analysis and presentation of the data. As often happens in case studies, another research question arose during the execution of the study: How can we balance demands for agile results with demands for formal results when performing usability testing for quality assurance?

Here, we use the term "formal" as a contrast to the term "agile", not because we see agile processes as being informal or unstructured, but since "formal" in this case is more representative than "plan driven" to characterise the results of testing and how they are presented to certain stakeholders. We examine how the results of the UTUM test are suitable for use in an agile process. Even though eXtreme Programming (XP) is used as an illustrative example in this article, note that there is no strong connection to any particular agile methodology; rather, there is a philosophical connection between the test and the ideas behind the agile movement. We examine how the test satisfies requirements for formal statements of usability and quality. As a result of the investigation regarding the agile and the formal, we also identify parties interested in the different elements of the test data.

Our study is in reference to Martin et al's work [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF]. Our work deals with quality and the necessary balance between agility and formality from the viewpoint of "day to day organizational needs". Improving formal aspects is important, and software engineering research in general has successfully emphasized this focus. However, improving formal aspects may not help to design the testing that most efficiently satisfies organisational needs and minimises the testing effort. The main reason for not adopting "best practice" in testing is to orient testing to meet organisational needs, based on the dynamics of customer relationships, using limited effort in the most effective way, and the timing of software releases to the needs of customers as to which features to release (as is demonstrated in [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF]). Both perspectives are needed!

The structure of the article is as follows. An overview of two different testing paradigms is provided. A description of the test method comes next, followed by a presentation of the study method and an analysis of the material from the case study, examining the balance between agility and formalism, the relationship between these and quality, and the need for research/industry cooperation. The article ends with a discussion of the work, and conclusions.

Testing -Prevailing Models vs. Agile Testing

This section presents a brief overview of testing as seen from the viewpoints of the software engineering community and the agile community. As quality becomes a dominant success factor for software, the practitioner's use of processes to support software quality will become increasingly important. Testing is one such process, performed to support quality assurance, and provide confidence in the quality of software, and an emphasis on software quality requires improved testing methodologies that can be used by practitioners to test their software [START_REF] Harrold | Testing: A Roadmap[END_REF]. This section therefore briefly discusses the field of testing, in connection with the fact that the test framework can be seen as an agile testing methodology.

Within software engineering, there are many types of testing, in many process models, (e.g. the Waterfall model [START_REF] Royce | Managing the development of large software systems: concepts and techniques in 9th international conference on Software Engineering[END_REF], Boehm's Spiral model [START_REF] Boehm | A spiral model of software development and enhancement[END_REF]). Testing has been seen as phase based, and the typical stages of testing (see e.g. [11], [START_REF] Pfleeger | Software Engineering[END_REF]) when developing large systems are Unit testing, Integration testing, Function testing, Performance testing, Acceptance testing, and Installation testing. The stages from Function testing and onwards are characterised as System Testing, where the system is tested as a whole rather than as individual pieces [START_REF] Pfleeger | Software Engineering[END_REF].

Unit testing, which should be performed in a controlled environment, verifies that a component functions properly with the expected types of input. Integration testing ensures that system components work together as described in the specifications. After this testing, the system has been merged into a working system, and system testing can begin. System testing begins with Function testing, where the system is tested to ensure that it has the desired functionality, and evaluates whether the integrated system performs the functions described in the requirements specification. A performance test compares the system with the rest of the software and hardware requirements, and after the performance test, the system is regarded as being a validated system. In an acceptance test, the system is tested together with the customer, in order to check it against the customer's requirements description, to ensure that it works in accordance with customer expectations. When Acceptance testing is completed, the accepted system is installed in its proper environment, and in order to ensure that it functions as it should, an installation test is run [START_REF] Pfleeger | Software Engineering[END_REF]. Usability testing (otherwise named Human Factors Testing), which we are concerned with here, has been characterised as investigating requirements dealing with the user interface, and has been regarded as a part of Performance testing [START_REF] Pfleeger | Software Engineering[END_REF]. This is an example of the prevailing approach to testing, reliant on formal aspects and best practice.

Agile software development radically changes how software development organisations work, especially regarding testing [START_REF] Talby | Agile Software Testing in a Large-Scale Project[END_REF]. In agile development, exemplified here by XP [START_REF] Beck | Extreme Programming Explained[END_REF], one of the key tenets is that testing is performed continuously by developers. In XP, the tests should be isolated, i.e. should not interact with the other tests that are written, and should preferably be automatic, although a recent study of testing practice in a small organisation has shown that not all companies applying XP automate all tests [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF]. Tests come from two sources, from programmers and customers, who both create tests that serve, through continuous testing, to increase their confidence in the operation of the program. Customers write, or specify, functional tests to show that the system works in the way they expect it to, and developers write unit tests to ensure that the programs work the way they think that they work. Unit and functional tests are the main testing methods in XP, but can be complemented by other types of tests when necessary. Some XP teams may have dedicated testers, who help customers translate their test needs into tests, who can help customers create tools to write run and maintain their own tests, and who translate the customer's testing ideas into automatic, isolated tests [START_REF] Beck | Extreme Programming Explained[END_REF].

The role of the tester is a matter of debate. In both of the above paradigms it is primarily developers who design and perform testing, albeit occasionally at the request of the customer. However, within industry, there are seen to be fundamental differences between the people who are "good" testers and those who are good developers. The role of the tester as described above assumes that the tester is also a developer, even when teams use dedicated testers. Within industry, however, it is common that the roles are clearly separated, and that testers are generalists with the kind of knowledge that users have, who complement the perspectives and skills of the testers. A good tester can have traits that are in direct contrast with the traits that good developers need (see e.g. Pettichord [START_REF] Pettichord | Testers and Developers Think Differently[END_REF] for a discussion regarding this). Pettichord claims that good testers think empirically in terms of observed behaviour, and must be encouraged to understand customers' needs. As can be seen in the above, although there are similarities, there are substantial differences in the testing paradigms, how they treat testing, and the role of the tester and test designer. In our testing, the test leaders are specialists in the area of usability and testing, and generalists in the area of the product and process as a whole.

There is a body of knowledge concerning usability testing, much of it in the field of Human Computer Interaction, but we have chosen not to look more closely at this. In this paper we concentrate on the studied company's organizational needs and the philosophical connection between the test and the ideas behind the agile movement.

The UTUM Test Package

UTUM is a usability test package for mass market mobile devices, and is a tool for quality assurance, measuring usability empirically on the basis of metrics for satisfaction, efficiency and effectiveness, complemented by a test leader's observations. Its primary aim is to measure usability, based on the definition in ISO 9241-11, where usability is defined as "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use" [START_REF]Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs) -Part 11: Guidance on Usability[END_REF]. This is similar to the definition of quality in use defined in ISO 9126-1, where usability is instead defined as understandability, learnability and operability [17]. The intention of the test is also to measure "The User Experience" (UX), which is seen as more encompassing than the view of usability that is contained in e.g. the ISO standards [START_REF]UIQ Technology Usability Metrics[END_REF], although it is still uncertain how UX differs from the traditional usability perspective [START_REF] Uxem | User eXpreience Evaluation Methods in product development (UXEM)[END_REF] and exactly how UX should be defined (for some definitions, see e.g. ( [START_REF] Hassenzahl | User Experience -Towards a unified view[END_REF][START_REF] Hassenzahl | User experience -a research agenda[END_REF][START_REF] Uxnet | UXNet: the User Experience network[END_REF]).

In UTUM testing, one or more test leaders carry out the test according to predefined requirements and procedure. The test itself takes place in a neutral environment rather than a lab, in order to put the test participant at ease. The test is led by a test leader, and it is performed together with one tester at a time. The test leader welcomes the tester, and the process begins with the collection of some data regarding the tester and his or her current phone and typical phone use. Whilst the test leader is then preparing the test, the tester has the opportunity to get acquainted with the device to be tested, and after a few minutes is asked to fill in a hardware evaluation, a questionnaire regarding attitudes to the look and feel of the device.

The next step is to perform a number of use cases on the device, based on the tester's normal phone use or organisational testing needs. Whilst this is taking place, the test leader observes what happens during the use case performance, and records these observations, the time taken to complete the use cases, and answers to follow-up questions that arise. After the use case is complete, the tester is asked to answer questions about how well the telephone lets the user accomplish the use case.

The final step in the test, when all of the use cases are completed, is a questionnaire about the user's subjective impressions of how easy the interface is to use. This is based on the System Usability Scale (SUS) [START_REF] Brooke | System Usability Scale (SUS): A Quick-and-Dirty Method of System Evaluation User Information[END_REF], and it expresses the tester's opinion of the phone as a whole. The tester is finally thanked for their participation in the test, and is usually given a small gift, such as a cinema ticket, to thank them for their help.

After testing, the data obtained are transferred to spreadsheets. These contain both quantitative data, such as use case completion times and attitude assessments, and qualitative data, like comments made by testers and information about problems that arose. The data is used to calculate metrics for performance, efficiency, effectiveness and satisfaction, and the relationships between them, leading to a view of usability for the device as a whole. The test leader is an important source of data and information in this process, as he or she has detailed knowledge of what happened during testing. The results of the testing are thereby a combination of metrics and knowledge, where the different types of data confirm one another. The metrics based material is presented in the form of diagrams, graphs and charts, showing comparisons, relations and tendencies. This can be corroborated by the knowledge possessed by the test leader, who has interacted with the testers and is the person who knows most about the process and context of the testing. Knowledge material is often presented verbally, but can if necessary be supported and confirmed by visual presentations of the data.

UTUM has been found to be a customer driven tool that is quick and efficient, easily transferable to new environments, and that handles complexity [START_REF] Winter | Developing Quality through Measuring Usability -The UTUM Test Package[END_REF]. For more detailed information on the contents and performance of the UTUM test and the principles behind it, see ( [START_REF]UIQ Technology Usability Metrics[END_REF], [START_REF] Winter | Developing Quality through Measuring Usability -The UTUM Test Package[END_REF]). A brief video presentation of the whole test process (6 minutes) can be found on YouTube [START_REF] Bth | Usability test[END_REF].

This work has been performed as part of a long-term cooperation between U-ODD and UIQ, which has centred on the development and evaluation of a usability test (for more information, see [START_REF] Winter | Developing Quality through Measuring Usability -The UTUM Test Package[END_REF]25]). The prime area of interest has been on creating and studying a test method for quality assurance, on developing metrics to measure usability and on the combination of qualitative and quantitative results. This case study in this phase of the research cooperation concerned tests performed by UIQ in Ronneby, and by Sony Ericsson Mobile Development in Manchester.

The process of research cooperation is Action research according to the researchand method development methodology called Cooperative Method Development (CMD), see [START_REF] Dittrich | Co-operative Method Development: Combining qualitative empirical research with method, technique and process improvement[END_REF] [27], [START_REF] Dittrich | Co-Operative Method Development revisited[END_REF] and ( [START_REF] Rönkkö | Making Methods Work in Software Engineering: Method Deployment as a Social achievement[END_REF], chapter 8) for further details. Action research is "research that involves practical problem solving which has theoretical relevance" ( [START_REF] Mumford | Advice for an action researcher[END_REF] p. 12). It involves gaining an understanding of a problem, generating and spreading practical improvement ideas, applying the ideas in a real world situation and spreading the theoretical conclusions within academia [START_REF] Mumford | Advice for an action researcher[END_REF]. Improvement and involvement are central to action research, and its purpose is to influence or change some aspect of whatever the research has as its focus ([31] CMD is built upon a number of guidelines including the use of ethnomethodological and ethnographically inspired empirical research, combined with other methods if suitable. Ethnography is a research strategy taken from sociology, and that has its foundations in anthropology [START_REF] Rönkkö | Ethnography in Encyclopedia of Software Engineering[END_REF]. It is a method that relies upon the first-hand experience of a field worker who is directly involved in the setting that is under investigation [START_REF] Rönkkö | Ethnography in Encyclopedia of Software Engineering[END_REF]. CMD focuses on shop floor development practices, taking the practitioners' perspective when evaluating the empirical research and deliberating improvements, and involving the practitioners in the improvements. This approach is inspired by a Participatory Design (PD) perspective. PD is an approach towards system design in which those who are expected to use the system are actively involved and play a critical role in designing it. It is a paradigm where stakeholders are included in the design process, and it demands shared responsibility, active participation, and a partnership between users and implementers [START_REF] Schuler | Participatory Design -Principles and Practices[END_REF].

This study has been performed as a case study, defined by Yin as "an empirical enquiry that investigates a contemporary phenomenon within its real-life context, especially when the boundaries between phenomenon and context are not clearly evident" ( [START_REF] Yin | Case Study Research -Design and Methods[END_REF], s. 13). The data for the study has been obtained through observation, through a series of unstructured and semi-structured interviews [START_REF] Robson | Real World Research[END_REF], both face-to-face and via telephone, through participation in meetings between different stakeholders in the process, and from project documents and working material, such as a research protocol that ensures that the individual tests take place in a consistent manner, spreadsheets for storing and analysing qualitative and quantitative data, and material used for presenting results to different stakeholders. The interviews have been performed with test leaders, and with staff on management level within the two companies. Interviews have been audiotaped, and transcribed, and all material has been collected in a research diary. The diary is also the case study database, which collects all of the information in the study, allowing for traceability and transparency of the material, and reliability [START_REF] Yin | Case Study Research -Design and Methods[END_REF]. The mix of data and collection methods has given a triangulation of data that serves to validate the results that have been reached.

The transcriptions of the interview material, and other case material in the research diary, have been analysed to find emerging themes, in an editing approach that is also consistent with Grounded Theory (see Robson [START_REF] Robson | Real World Research[END_REF] s. 458). The analysis process has affected the further rounds of questioning, narrowing down the focus, and shifting the main area of interest, opening up for the inclusion of new respondents who shed light on new aspects of the study. During the case study, as often happens in case studies [START_REF] Yin | Case Study Research -Design and Methods[END_REF], the research question changed. The first focus of the study was the fact that testing was distributed, and the effect this had on the testing and the analysis of the results. Gradually, another area of interest became the elements of agility in the test, and the balance between the formal and informal parts of the testing.

We have tried to counter threats to validity and reliability in the study. One of these is bias introduced by the researchers most closely involved in the study. This is addressed by cross checking results with participants in the study, and discussing the results of the case study with research colleagues. One more threat is that most of the data in the case study comes from UIQ. Due to close proximity to UIQ, the interaction there has been frequent and informal, and everyday contacts and discussions on many topics have influenced the interviews and their analysis. Interaction with Sony Ericsson has been limited to interviews and discussions, but data from Sony Ericsson confirms what was found at UIQ. Another threat is that most of the data in the case study comes from informants who work within the usability/testing area, but once again, they come from two different organisations and corroborate one another, have been complemented by information from other stakeholders, and thus present a picture of industrial reality.

In the case in question, test leaders from two organisations in two countries performed testing in parallel. Testing was performed in a situation with complex relationships between customers, clients, and end-users, and complexities of how and where results were used. Reasons for performing the tests were to validate the UTUM test itself as a tool for quality assurance, and to obtain a greater number of tests, creating a baseline for validation of products, to identify and measure differences or similarities between countries, and to identify issues with common use-cases. Normally, there is no need for a large number of testers or data points. However, although this can be seen as a large test from the point of view of the participating organisations, compared to their normal testing, with more than 10 000 data points, it was found to be an agile process, where results were produced quickly and efficiently.

In the following, we present the results of the study, and discuss in which way the results are agile or plan-driven/formal, who is interested in the different types of results, and which of the organisational stakeholders needs agile or formal results.

The case study was grounded in thoughts concerning the importance of quality and agility in software processes, as specified previously. We have always seen the importance of the framework as a tool for quality, and verifying this was one purpose of the testing that this case study was based on. Given the need for agility mentioned above, the intention of this case study became to see how the test is related to agile processes and whether the items in the agile manifesto can be identified in the results from the test framework. The following is the result of having studied the material from the case study from the perspective of the spectrum of different items that are taken up in the agile manifesto.

The agile movement is based on core values, described in the agile manifesto [START_REF] Robinson | The Agile Manifesto[END_REF], and explicated in the agile principles [START_REF]Principles of Agile Software[END_REF]. The agile manifesto states that: "We are uncovering better ways of developing software by doing it and by helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, and Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more". Cockburn [START_REF] Cockburn | Agile Software Development[END_REF] stresses that the intention is not to demolish the house of software development, represented here by the items on the right (e.g. working software over comprehensive documentation), but claims that those who embrace the items on the left rather than those on the right are more likely to succeed in the long run. Even in the agile community there is some disagreement about the choices, but it is accepted that discussions can lead to constructive criticism. Our analysis showed that all these elements could be identified in the test and its results.

In our research we have always been conscious of a division of roles within the company, often expressed as "shop floor" and "management", and working with a participatory design perspective we have worked very much from the shop floor point of view. During the study, this viewpoint of separate groups emerged and crystallised, and two disparate groups became apparent. We called these groups Designers, represented by e.g. interaction designers and system and interaction architects, representing the shop floor perspective, and Product Owners, including management, product planning, and marketing, representing the management perspective.

When regarding this in light of the Agile manifesto, and its connection to our test, we began to see how different groups may have an interest in different factors of the framework and the results that it can produce, and it became a point of interest in the case study to see how these factors related to the manifesto and which of the groups, Designers (D) or Product Owners (PO), is mainly interested in each particular item in the manifesto. The case study material was analysed on the basis of these emerging thoughts. Where the groups were found to fit on the scale is marked at the end of the paragraphs that follow. We have changed one of the items from "Working software" to "Working information" as we see the information resulting from the testing process as a metaphor for the software that is produced in software development.

• Individuals and interactions -The testing process is dependent on the individuals who decide the format of the test, who lead the test, and who actually perform the tests on the devices. The central figure here is the test leader, who functions as a pivot point in the whole process, interacting with the testers, observing and registering the data, and presenting the results. This is obviously important in the long run from a PO perspective, but it is D who has the greatest and immediate benefit of the interaction, showing how users reacted to design decisions, that is a central part of the testing. D • Processes and tools -The test is based upon a well-defined process that can be repeated to collect similar data that can be compared over a period of time. This is of interest to the designers, but in the short term they are more concerned with the everyday activities of design and development that they are involved in. Therefore we see this as being of greatest interest to PO, who can get a long-term view of the product, its development, and e.g. comparisons with competitors, based on a stable and standardised method. PO • Working information -The test produces working information quickly. Directly after the short period of testing that is the subject of this case study, the test leaders met and discussed and agreed upon their findings. This took place before the data was collated in the spreadsheets. They were able to present the most important qualitative findings to system and interaction architects within the two organisations 14 days after the testing began, and changes in the implementation were requested soon after that. An advantage of doing the testing in-house is having access to the tester leaders, who can explain and clarify what has happened and the implications of it. This is obviously of primary interest to D • Comprehensive documentation -The comprehensive documentation consists of spreadsheets containing metrics and qualitative data. The increased use of metrics, which is the formal element in the testing, is seen in both organizations in this study as a complement to the testing methods already in use. Metrics back up the qualitative findings that have always been the result of testing, and open up new ways to present test results in ways that are easy to understand without having to include contextual information. They make test results accessible for new groups.

The quantitative data gives statistical confirmation of the early qualitative findings, but are regarded as most useful for PO, who want figures of the findings that have been reached. There is less pressure of time to get these results compiled, as the most important work has been done, and the critical findings are already being implemented. In this case study, the metrics consisted of 10 000 data points collected from 48 users, a mixture of quantitative measurements and attitudinal metrics. The metrics can be subject to stringent analysis to show comparisons and correlations between different factors. In both organisations there is beginning to be a demand for Key Performance Indicators for usability, and although it is still unsure what these may consist of, it is still an indication of a trend that comes from PO level. PO • Customer collaboration -in the testing procedure it is important for the testers to have easy access to individuals, to gain information about customer needs, end user patterns, etc. The whole idea of the test is to collect the information that is needed at the current time regarding the product and its development. How this is done in practice is obviously of concern to PO in the long run, but in the immediate day to day operation it is primarily of interest to D • Contract negotiation -On a high level it is up to PO to decide what sort of cooperation should take place between different organisations and customers, and this is not something that D is involved in, so this is seen as PO • Respond to change -The test is easily adapted to changes, and is not particularly resource-intensive. If there is a need to change the format of a test, or a new test requirement turns up suddenly, it is easy to change the test without having expended extensive resources on the testing. It is also easy to do a "Light" version of a test to check a particular feature that arises in the everyday work of design, and this has happened several times at UIQ. This is the sort of thing that is a characteristic of the day to day work with interaction design, and is nothing that is of immediate concern for PO, so this is seen as D • Following a plan -From a short-term perspective, this is important for D, but since they work in a rapidly changing situation, it is more important for them to be able to respond to change. This is however important for PO who are responsible for well functioning strategies and long-term operations in the company.

On opposite sides of the spectrum

In this analysis, we found that "Designers", as in the agile manifesto, are interested in the items on the left, rather than the items on the right (see figure 3). We see this as being "A Designer's Manifesto". "Product Owners" are more interested in the items on the right. Boehm characterised the items on the right side as being "An Auditor Manifesto" [START_REF] Boehm | Keynote address, 5th Workshop on Software Quality[END_REF]. We see it as being "A Product Owner's Manifesto". This is of course a sliding scale; some of the groups may be closer to the middle of the scale. Neither of the two groups is uninterested in what is happening at the opposite end of the spectrum, but as in the agile manifesto, while there is value in the items on one side, they value the items on the other side more. We are conscious of the fact that these two groups are very coarsely drawn, and that some groups and roles will lie between Product Owner = PO D = Designers these extremes. We are unsure exactly which roles in the development process belong to which group, but are interested in looking at these extremes to see their information requirements in regard to the results of usability testing. On closer inspection it may be found that none of the groups is on the far side of the spectrum for all of the points in the manifesto; more work must be done to examine this distribution and division.

Discussion

Here, we discuss our results in relation to academic discourses, to answer the research question: How can we balance demands for agile results with demands for formal results when performing usability testing for quality assurance? We also comment upon two related discourses from the introductory chapter, i.e. the relation between quality and a need for cooperation between industry and research, and the relationship between quality and agility. Since we work in a mass-market situation, and the system that we are looking at is too large and complex for a single customer to specify, the testing process must be flexible enough to accommodate the needs of many different stakeholders. The product must appeal to the broadest possible group, so it is difficult for customers to operate in dedicated mode with development team, with sufficient knowledge to span the whole range of the application, which is what an agile approach requires to work best [START_REF] Boehm | Get Ready for Agile Methods, with Care[END_REF]. In this case, test leaders work as proxies for the user in the mass market. We had a dedicated specialist test leader who brought in the knowledge that users have, in accordance with Pettichord [START_REF] Pettichord | Testers and Developers Think Differently[END_REF]. Evidence suggests that drawing and learning from experience may be as important as taking a rational approach to testing [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF]. The fact that the test leaders involved in the testing are usability experts working in the field in their everyday work activities means that they have considerable experience of their products and their field. They have specialist knowledge, gained over a period of time through interaction with end-users, customers, developers, and other parties that have an interest in the testing process and results. This is in line with the idea that agile methods get much of their agility from a reliance on tacit knowledge embodied in a team, rather than from knowledge written down in plans [START_REF] Boehm | Get Ready for Agile Methods, with Care[END_REF].

It would be difficult to gain acceptance of the test results within the whole organisation without the element of formalism. In sectors with large customer bases, companies require both rapid value and high assurance. This cannot be met by pure agility or plan-driven discipline; only a mix of these is sufficient, and organisations must evolve towards the mix that suits them best [START_REF] Boehm | Get Ready for Agile Methods, with Care[END_REF]. In our case this evolution has taken place during the whole period of the research cooperation, and has reached a phase where it has become apparent that this mix is desirable and even necessary.

In relation to the above, Osterweil et al [START_REF] Osterweil | Strategic directions in software quality[END_REF] state that there is a body of knowledge that could do much to improve quality, but that there is "a yawning chasm separating practice from research that blocks needed improvements in both communities", thereby hindering quality. Practice is not as effective as it must be, and research suffers from a lack of validation of good ideas and redirection that result from serious use in the real world. This case study is part of a successful cooperation between research and industry, where the results enrich the work of both parts. Osterweil et al [START_REF] Osterweil | Strategic directions in software quality[END_REF] also request the identification of dimensions of quality and measures appropriate for it. The particular understanding of agility discussed in our case study can be an answer to this request. The agility of the test process is in accordance with the "good organisational reasons" for "bad testing" that are argued by Martin et al [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF]. These authors state that testing research has concentrated mainly on improving the formal aspects of testing, such as measuring test coverage and designing tools to support testing. However, despite advances in formal and automated fault discovery and their adoption in industry, the principal approach for validation and verification appears to be demonstrating that the software is "good enough". Hence, improving formal aspects does not necessarily help to design the testing that most efficiently satisfies organisational needs and minimises the effort needed to perform testing. In the results of the present paper, the main reason for not adopting "best practice" is precisely to orient testing to meet organisational needs. Our case is a confirmation of [START_REF] Martin | Good' Organisational Reasons for 'Bad' Software Testing: An Ethnographic Study of Testing in a Small Software Company in ICSE '07[END_REF]. Here, it is based on the dynamics of customer relationships, using limited effort in the most effective way, and the timing of software releases to the needs of customers as to which features to release. The present paper illustrates how this happens in industry, since the agile type of testing studied here is not according to "best practice" but is a complement that meets organisational needs for a mass-market product in a rapidly changing marketplace, with many different customers and end-users.

Conclusion and Further Work

In the UTUM test package, we have managed to implement a sufficient balance between agility and plan driven formalism to satisfy practitioners in many roles. The industrial reality that has driven the development of this test package confirms the fact that quality and agility are vital for a company that is working in a rapidly changing environment, attempting to develop a product for a mass market. There is also an obvious need for formal data that can support the quick and agile results. Real-world complex situations are not either on or off. The UTUM test package demonstrates one way to balance demands for agile results with demands for formal results when performing usability testing for quality assurance. The test package conforms to both the Designer's manifesto, and the Product Owner's manifesto, and ensures that there is a mix of agility and formalism in the process.

The case in the present paper confirms the argumentation emphasizing 'good organizational reasons', since this type of testing is not according to "best practice" but is a complement that meets organisational needs for a mass-market product in a rapidly changing marketplace, with many different customers and end-users. This is partly an illustration of the chasm between industry and research, and partly an illustration of how agile approaches are taken to adjust to industrial reality. In relation to the former this case study is a successful cooperation between research and industry. It has been ongoing since 2001, and the work has an impact in industry, and results enrich the work of both parts. The inclusion of Sony Ericsson in this case study gives an even greater possibility to spread the benefits of the cooperative research. More and more hybrid methods are emerging, where agile and plan driven methods are combined, and success stories are beginning to emerge. We see the results of this case study and the UTUM test as being one of these success stories. How do we know that the test is successful? By seeing that it is in successful use in everyday practice in an industrial environment. We have found a successful balance between agility and formalism that works in industry and that exhibits qualities that can be of interest to both the agile and the software engineering community.

As a follow up to this case study, work has been performed to collect more information regarding the attitudes of Product Owners and Designers towards the information they require from testing and their preferred presentation formats. This will help define the groups and their needs, and allow us to place them on the map of the manifesto, and tailor the testing and presentation methods to fulfil these needs, and thereby improve the test package even further.

Fig. 1 .Figure 1

 11 Fig. 1. Contents of the UTUM testing, a mix of metrics and mental data

Fig. 2 .

 2 Fig. 2. Qualitative results in spreadsheets (product information removed).

  p. 215). A central aspect of action research is collaboration between researchers and those who are the focus of the research. The terms participatory research and participatory action research are sometimes used as synonyms for action research ([31] p. 216).

Figure 3 .

 3 Figure 3. Groups and their diverging interests

Acknowledgements

This work was partly funded by The Knowledge Foundation in Sweden under a research grant for the software development project "Blekinge -Engineering Software Qualities", www.bth.se/besq. Thanks to my colleagues in the U-ODD research group for their help in data analysis and structuring my writing. Thanks also to Gary Denman for permission to use the extract from the Structured Data Summary.


Łukasz Olek
email: lukasz.olek@cs.put.poznan.pl

Jerzy Nawrocki

Miroslaw Ochodek
email: miroslaw.ochodek@cs.put.poznan.pl

Mirosław Ochodek

Enhancing Use Cases with Screen Designs

Keywords: Use cases, GUI Design, Prototyping, ScreenSpec

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Use cases are the most popular way of specifying functional requirements. A survey published in IEEE Software in 2003 [START_REF] Neill | Requirements Engineering: The State of the Practice[END_REF] shows that over 50% of software projects elicit requirements as use cases. Use case is a good way of describing interaction between a user and a system at a high level, so maybe now the number can be even higher. At the same time many practitioners (in about 40% of projects [START_REF] Neill | Requirements Engineering: The State of the Practice[END_REF]) draw user interfaces to visualise better how the future system will behave. This is wise, since showing user interface designs (e.g. prototypes [START_REF] Pressman | Software Engineering -A practitioners Approach[END_REF][START_REF] Snyder | Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces[END_REF][START_REF] Constantine | Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design[END_REF][START_REF] Sommerville | Requirements Engineering. A Good Practice Guide[END_REF], storyboards [START_REF] Landay | Sketching storyboards to illustrate interface behaviors[END_REF]) together with use cases helps to detect more problems with requirements ([13] 1 ). Unfortunately, user interface details would clutter use-case description and should be kept apart from the steps ( [START_REF] Adolph | Patterns for Effective Use Cases[END_REF][START_REF] Cockburn | Writing Effective Use Cases[END_REF]), but they can be attached to use cases as adornments [START_REF] Adolph | Patterns for Effective Use Cases[END_REF].

Much have been said about writing use cases [START_REF] Adolph | Patterns for Effective Use Cases[END_REF][START_REF] Cockburn | Writing Effective Use Cases[END_REF][START_REF] Schneider | Applying Use Cases: A Practical Guide[END_REF][START_REF] Leffingwell | Managing Software Requirements: A Use Case Approach[END_REF][START_REF] Jacobson | Object-Oriented Software Engineering: A Use Case Driven Approach[END_REF]] (e.g. how to divide them into main scenario and extensions, what type of language to use), however it is not clear how to specify UI details as adornments. Practitioners seem to either draw screens in graphical editors and attach graphical files to use cases, or just describe it using a natural language. Both approaches have advantages and disadvantages. The graphical approach is easier to analyse by humans, however more difficult to prepare and maintain. On the other hand, the textual approach is much easier to prepare, but not so easy to perceive.

The goal of this paper is to propose a simple formalism called ScreenSpec to specify user interface details. It has both advantages of the approaches mentioned earlier: it is inexpensive to prepare and maintain, and can be automatically converted to a graphical form (attached to use cases as adornments can stimulate readers visually). Currently the language is limited to describe user interfaces of web applications.

It is easy to propose a new formalism, but it is much more difficult to prove that it is useful. ScreenSpec has been successfully used in 8 real projects. An investigation was carried out to find out how much effort is needed to use Screen-Spec, and how much time does it take to learn how to use it.

The plan of this paper is following. Section 2. describes some approaches to UI specification that are popular in software engineering. Section 3. describes the ScreenSpec language. Section 4. describes case studies that were conducted to check whether ScreenSpec is complete enough and flexible to specify real applications and how much effort does it take to specify screens at requirements elicitation phase. Section 5. describes a way to generate graphical files representing particular screens from ScreenSpec. Section 6. presents how the visual representation of screens can be embedded in requirements documents: as adornments, or as a mockup. The whole paper is concluded in Section 7.

Related Work

There are many outstanding technologies and formalisms used to describe user interface. One of them is XUL[2] (XML User Interface Language) from the Mozilla Foundation. This is an interesting language used to describe platformindependent user interface. It has many interesting features, e.g. separation of presentation from application logic, easy customisation, localisation or branding. However this language seems to be too much implementation-oriented, to be used at requirements elicitation phase. There are two important impediments to use XUL for this purpose. Firstly, one has to know component type before it can be specified (e.g. <textbox id="username"/>).Therefore it is not possible to start from specifying the structure of information connected with particular screen, and then add details about control types (see Section 3.3). Secondly, labels for components have to be defined explicitly. This means that for each component two declarations are required: one for a label, and second one for a control. However it would be interesting to generate (or round-trip-generate) XUL from ScreenSpec. Produced XUL could be easily used for implementation.

There are other technologies that are getting more and more popular nowadays, like for instance, MDSD (Model Driven Software Development) approaches, that provide an ability to generate a whole application from a set of models (e.g. WebML [START_REF]The Web Modeling Language Home Page[END_REF], UWE/ArgoUWE [START_REF]UWE -UML-based Web Engineering Home Page[END_REF]). Unfortunately this approach still seems to require too much effort, to be successfully used at the requirements elicitation phase. There are companies using such approach, that Poznań University of Technology cooperates with. According to their experience it takes at least several hours to describe a single use case with MDSD models. It is definitely to long to be used at requirements elicitation phase, so they use generic text editors to specify use cases and screens.

ScreenSpec -Language for Screen Specification

The goal of the ScreenSpec language is to allow analyst to specify the structure of user interface very efficiently. Since this approach is supposed to be used at early stages of requirements elicitation phase, it would be wise to focus on the structure of screens and information exchanged between a user and a system, rather then on such attributes like colours, fonts, layout of components. This is called a lo-fidelity approach( [START_REF] Walker | High-Fidelity or Low-Fidelity, Paper or Computer? Choosing Attributes When Testing Web Applications[END_REF][START_REF] Rudd | Low vs. high-fidelity prototyping debate[END_REF]) and is used in ScreenSpec.

It is best to explain how ScreenSpec specification looks like on a simple example. Let us imagine an Internet shop with a view of all categories (see Fig. 1). It contains a list of categories (each of them is represented by a link with its name) and lists of subcategories. There are also some links to other shoppingviews (by brand, by store, etc).

Language Definition

Screens Each screen is specified with a set of lines that describe its structure. The definition starts with keyword SCREEN followed by screen's identifier (each screen must have an unique ID). The following lines are indented and describe components, that belong to the screen:

SCREEN Screen_ID: Component_definition_1 Component_definition_2 ...
Where Component_definition_n is a definition of a basic component or a group.

Basic components Basic components are mainly simple widgets taken from the HTML language. They are specified using the following syntax:

Component_ID[(CONTROL_TYPE)]
where:

-Component_ID is a string that identifies the component, e.g. Login_name, Password, Author. It has to be unique in the scope of the screen or parent group.

-CONTROL_TYPE is one of: BUTTON, LINK, IMAGE, STATIC_TEXT,DYNAMIC_TEXT, EDIT_BOX, COMBO_BOX, RADIO_BUTTON, LIST_BOX, CHECK_BOX, CUSTOM. This parameter is optional (EDIT_BOX by default) and can be defined by an analyst later (see Section 3.3).

Three controls do not come from a standard set of HTML controls, thus require additional comment: (1)STATIC_TEXT is used to display a text that will be the same on each screen instance (e.g. a comment or instructions) (2)DYNAMIC_TEXT is a block of text generated dynamically by the system (e.g. a total value of an invoice) and ( 3)CUSTOM is used to represent non-standard components (e.g. date picker).

Groups Groups of components are containers for widgets, usually providing additional features. They are defined using the following syntax:

Group_ID[(GROUP_TYPE)]: Component_definition_1 Component_definition_2 ...
where:

-Group_ID is a string that identifies the group.

-Component_definition_n -is a definition of a basic component or another group of components -GROUP_TYPE -determines the type of the group:

• SIMPLE or omitted -such group is just used to introduce structure to the screen, but it does not provide any additional semantics to its components • LIST -its components are repeated in a list, all child components form a single list item • TABLE -its components are repeated in rows, as a table (similar to LIST, but different layout) • TREE -similar to list, but its items can also contain another lists of the same structure (e.g. used to create tree of categories, or site map tree).

ScreenSpec Advanced Elements

Static values are used to specify, that the component will have the same values on each screen. For example, when we have a combo box that allows to choose sex of user, it would always have two values: "Male" and "Female". We can express such case in ScreenSpec using the following structure:

Component_ID(...):Value_1|Value_2|...

e.g. Sex(COMBO_BOX):Male|Female

Template mechanism can be used to build more complex screens. Two elements are needed to do this: a template definition and a reference to the template in the particular screen. This can be done using the following structure (shown in the example): ...

Each template is defined with keyword TEMPLATE followed by a template name.

The structure of template is the same as the structure of a screen. The main difference is that it requires putting the additional component Contents(CUSTOM) -which is a placeholder for the specific screen which will use the template. When screen is supposed to use a particular template, we need to mention the name of the template in parenthesis, e.g. SCREEN All_Categories(Main).

Include common screen elements When there are the same controls (functional blocks) used in more screens it would be wise to declare them once and then make references. We can do this by using INCLUDE keyword:

SCREEN Search_box: ...

SCREEN Search_results: INCLUDE Search_box

Results(LIST): ...

Select clause

It is common that a screen has different variants depending on situation. For example, a screen can display a list of all accepted papers or a message that no papers are accepted yet. When one of several variants can be used, it is specified by a select clause:

SELECT: Component_definition_1 Component_definition_2
This means that either Component_definition_1 or Component_definition_2 will be displayed on a real screen. More than two variants are possible (additional lines should be added within the SELECT clause). Components, that are specified here can be both simple components, or groups.

Iterative Approach to Screen Specification

ScreenSpec is designed to be used by an analyst at requirements elicitation phase. This phase is exploratory, which means that change-involving decisions are made frequently. It would be important to provide incremental approach to the screen specification process. It would be great if analyst could just roughly describe screen at the beginning (only the structure of information), and add more details later (when a customer confirms it is correct). Therefore ScreenSpec has 3 levels of details:

L1 Component names -need to be specified at the beginning. L2 Types of controls and groups -specifies types of information connected with each screen. L3 Static values and templates.

These levels can be mixed throughout the specification process: some fragments of screens can be written at one level of details, whereas other ones at another level.

Experience with ScreenSpec

Specifying Screens for the Real Projects -Case Studies

Analysts usually use word processors and sheets of papers to author requirements. Keeping it in mind, it seems that introducing formalised requirements models can be risky. It may happen that some of the developed-system features might be too difficult to describe.

To make sure that the ScreenSpec formalism is complete and flexible enough to be used for describing real systems, eight case studies were conducted. They included a large variety of projects. Some of them were internally-complex (large number of sub-function2 requirements), with a small amount of interaction with a user (e.g. Project A, Project C). Others were interaction-oriented, with a great number of use cases and screens (e.g. Project D, Project G). First 6 projects were selected from the Software Development Studio course at Poznań University of Technology. These projects were developed for external customers by students of the Master of Science in Software Engineering. Students were successfully using ScreenSpec approach to specify screens. They also raised some minor suggestions for ScreenSpec language, and small simplifications were introduced afterwords. Then screens for two commercial projects were also written using ScreenSpec language. In both cases all screens were successfully specified.

It seems that number of lines of code (LOC) per screen may differ depending on the screen complexity. In analysed projects average LOC per Screen varies from 3.0 to 14.5 (see table 1).

ScreenSpec Efficiency Analysis

Although an average amount of code required to specify a screen with ScreenSpec seems to be rather small, two important questions arise:

-Q1: how much effort is required to specify3 a screen? -Q2: how much time is required to learn how to use ScreenSpec?

The second question is also important because practitioners tend to choose solutions, which provide business value and are inexpensive to introduce. If an extensive training is required in order to use ScreenSpec efficiently, there might be a serious threat, that the language will not be attractive to the potential users.

In order to answer these questions, a controlled case study was conducted 4 . Eight participants were asked to specify sequence of 12 screens coming from the real application (provided as the series of application screenshots). The time required for coding each of the screens was precisely measured (up to the seconds). The code was written manually on sheets of paper. Participants were also asked to copy a sample screen specification, in order to examine their writing speed. Before they started to specify screens, they had been also introduced to the ScreenSpec during the 15-minute lecture, and each of them was also provided with a page containing the ScreenSpec specification in a nutshell. All materials provided to participants are published at [1].

Descriptive analysis and data clearing. During the completion of each task (single screen specification) two values were measured:

time required to finish the task lines of code developed to specify the screen Screens specifications, developed by participants, differed in respect to their size, because they were specified only on the basis of the screenshots, which were be perceived slightly differently by different people. What is more, some of the ScreenSpec structures might be used optionally. The detailed results of the case study is presented in table 2. Before proceeding to the further analysis

Lines of code -LOC

Participant Sample Screen

Mean results for all tasks were carefully analysed in order to find potential outliers. The task was marked as a suspicious if the variability in lines of code provided by participants was high (or there were outlying observations). According to the box plots presented in figure 2 tasks 1, 4, 5, 7, 8, 9, 10, 11, 12 were chosen for further investigation in order to find out the reasons for the LOC variability. It turned out that tasks 4 and 8 were ambiguous, because in both cases there were two possible interpretations of the screens semantic. What is more, the amount of code required to specify each of two versions differed significantly. Therefore those tasks were excluded from the further analysis. Productivity analysis. Based on the effort and code size measured for each task performed by each participant, a productivity factor can be derived. It will be defined here as a time required to produce a single line of code. It might be calculated using equation 1.

P ROD = Ef f ort Size (1)
Where:

-P ROD -is a productivity factor understood as a number of minutes required to develop a single line of code -Ef f ort -is an effort required to complete the task (measured in minutes) -Size -is the size of code developed to specify the screen (measured in LOC)

Effort measured during the case study consists of two components: (1)time required for thinking and (2)writing down the screen. It would be difficult to precisely measure both of them, however knowing the writing speed of each participant (see equation 2) it is possible to calculate the approximate effort spent only on thinking. It can be further used to estimate cognitive productivity factor (see equation 3), which can be understood as a productivity of thinking while coding the screen. It is independent from the tool (effort needed mentally produce the screen-specification code).

V writing = Size sample Ef f ort sample (2)
Where:

-V writing -is a writing speed (measured in LOC per minutes) -Ef f ort sample -is an effort required to copy the code for the sample screen (measured in minutes) -Size sample -is the size of the code for the sample screen -8 LOC

P ROD cognitive = Ef f ort -(Size/V writing ) Size (3)
Where:

-P ROD cognitive -is an estimation of cognitive productivity factor understood as a number of minutes spend on thinking in order to produce a single line of code -Ef f ort -is an effort required to complete the task (measured in minutes) -Size -is the size of code to specify the screen (measured in LOC) -V writing -is a writing speed (measured in LOC per minutes)

Cognitive and standard productivity factors were calculated for each task performed by participants. The chart presenting mean values for each task is presented in figure 3. Q1: how much effort is required to specify a screen? If the mean productivities from the first and the last task are compared, it would mean that average beginner produces around 2.81 LOC / minute while person with some experience 4.7 LOC / minute (this of course may very depending on the screen complexity). That means that total effort of specifying all of the screens for the largest project included in the case studies -Project G (92 screens with total of 917 LOC of screen specifications) would vary from 3.2 to 5.4 hours depending on analyst skill. What is more, an average screen size is around 8 LOC (average from table 1), which could be specified in less then 2 minutes (for experienced analyst, and less then 3 minutes for beginner). Therefore it seems that the Spec-Screen notation might be used directly during the meetings with customer. It is also worth to mention that if there was an efficient editor available (with high usability), the productivity factor for potential user, would be closer to the cognitive one. This means that a 8 LOC screen would be specified in about 30 seconds.

Q2: how much time is required to learn how to use ScreenSpec? By looking at the productivity chart presented in figure 3, the learning process can be investigated. The ratio between productivity factors calculated for the ending and beginning task is 1.69. In addition it seems that after completing 8-10 tasks, learning process saturates. Therefore it seems that participating in a single training session which includes a short lecture and ten practical tasks (about an hour), should be enough to start using ScreenSpec effectively.

An interesting observation is regarding the task number 5, because the productivity factor suddenly increased at this point (more time required to produce one line of code). This issue was further investigated, and the finding was that the screen for that task contained interactive controls, which appeared for the first time in the training cycle (edit boxes, check boxes etc.). Thus an important suggestion for a preparation of the training course would be to cover all of the components available in the ScreenSpec language.

Visual Representation of Screens

ScreenSpec can be authored using a dedicated tool. This is a simple editor, that detects each change, and automatically regenerates graphics files (PNG) that can be attached to requirements documents. The generator uses simple rules to transform ScreenSpec to visual representation: 1. For each component:

-EDIT_BOX, COMBO_BOX, LIST_BOX, CUSTOM -a label (equal Component ID) is displayed on the left side of the control, the control's value is taken from the defined static value, or it is left empty. CUSTOM component is displayed as the EDIT_BOX. -BUTTON, LINK -displays a control with a caption equal to the defined static value, or component ID.

-STATIC_TEXT, DYNAMIC_TEXT -displays a piece of text equal the static value or component ID. -RADIO_BUTTON, CHECK_BOX -displays a control followed by a label (label's value equals the static value or component ID) -IMAGE -displays a label on the left (equal to component ID) and an empty image frame on the right. 2. For each group:

-SIMPLE -a header and a frame is created, all children components are placed inside this frame. -LIST -a header and a frame is created. In the frame 3 rows are displayed (this visualises that a list can have more elements): two rows having the child components, and the third one containing "..." -TABLE -is similar to a LIST, however a new table column is created for each child component. Its label is displayed in the table header rather then on the left (near its control). -TREE -is similar to a LIST, but for each row a nested and smaller list is displayed.

Following example (figure 4) shows a visual representation of a simple screen specified in ScreenSpec.

ScreenSpec Meets Use Cases

Visual screens generated from ScreenSpec can be directly inserted into requirements specification in adornments section of particular use cases. Having up-todate graphic files allows to update the specification very easily, because many modern text editors allow to link with external files, and update them each time the document is opened (e.g. Microsoft Word, OpenOffice).

Mockup

Mockup is an interesting artefact created by connecting screens to particular steps of use cases. It is rendered as a simple web application that can display both: use cases and screens at the same time. Use case (displayed on the left side) shows the interaction between an actor and a system (see figure 5). After selecting particular step, an according screen is displayed (on the right side). This artefact seems to be useful in practice, initial feedback from commercial projects using mockups is very positive.

It is difficult to connect screens to use case steps in generic text editor, so a dedicated tool called UC Workbench [START_REF]UC Workbench project homepage[END_REF] was developed at Poznan University of Technology.

Conclusions

User interface designs are often attached to use cases as adornments, because it helps to understand the requirements by IT laymen. However, it is not clear how to specify UI details. This paper proposes a language called ScreenSpec, that can be used for this purpose. ScreenSpec is a formalism that was thoroughly validated. It was used to describe UI in eight real software projects. ScreenSpec allows to work incrementally on screen designs, starting with the general structure of information at particular screen, and then adding more details about widgets. It is very efficient, it takes on average about 2 minutes per screen. ScreenSpec is also easy to learn, it takes about an hour, for a person that has never seen ScreenSpec, to become proficient in using it.

Although it is interesting to use ScreenSpec at requirements elicitation stage, it could be even more interesting to use it at later stages. One can think about generating skeleton user interface code (in XUL, SWT, Swing or other technologies), that could be refined during implementation. Appropriate research will be conducted as a future work.

Fig. 1 .

 1 Fig. 1. A screen showing a list of categories (screenshot taken from shopping.yahoo.com), and its corresponding specification in ScreenSpec.

Fig. 2 .

 2 Fig. 2. Effort and size of code (LOC) variability for each task, a) box plot presents effort variability for each task, b) box plot presents lines of code variability for each task

Fig. 3 .

 3 Fig. 3. Mean (cognitive and standard) productivity factors for each task (screen)

Fig. 4 .

 4 Fig. 4. An example of visual representation for a LIST group component.

  to the system Main Scenario:1. Customer chooses login action .2. Customer fills in login form .

3 .

 3 System checks if data is correct and authorizes Customer .

Extensions: 3 .Fig. 5 .

 35 Fig. 5. An screenshot of Mockup -showing use case with corresponding screens at the same time.

Table 1 .

 1 Eight projects selected for the case study

		Number of Use Cases		ScreenSpec Screens
	Project Project A Project B Project C Project D Project E Project F Project G Project H	Business 0 3 0 0 0 1 0 2	4 13 5 16 4 3 44 12 User	2 2 0 0 0 2 39 0 Sub-functional	4 5 4 27 7 3 92 7 Screens	14.5 9.4 3 4.7 3.9 13 9.5 5.1 Average LOC/Screen	58 47 12 128 27 39 917 36 Total LOC

Table 2 .

 2 Effort and lines of code for each participant and task (sample screen refers to the task measuring participants writing speed )

	Participant P1 P2 P3 P4 P5 P6 P7 P8 SD Mean	0.9 Sample Screen 1.6 1.2 1.3 1.0 1.0 1.0 1.6 1.2 0.3	Time [min] 5 6 4.3 2.0 2.0 6.2 2.3 4.7 7.7 3.3 5.5 6.3 1 2 3 7 8 9 11 12 2.8 2.0 3.6 3.6 1.2 2.0 4.1 3.1 3.1 4.2 1.8 2.0 3.0 4.6 1.5 2.4 6.2 4.8 3.9 4.4 1.7 1.4 5.7 2.5 1.8 1.9 3.3 3.5 4.7 3.9 2.4 2.2 1.0 2.5 1.4 1.8 3.6 4.3 3.0 4.2 2.5 1.6 1.5 3.7 1.3 1.4 4.1 3.0 3.3 3.8 1.9 1.5 1.6 2.0 1.1 1.3 2.3 1.8 3.2 3.5 5.4 4.2 3.2 5.8 3.7 2.5 4.7 5.6 4.0 6.7 2.9 2.1 2.7 3.9 1.8 2.3 4.5 3.7 3.8 4.6 1.3 0.9 1.5 1.6 0.9 1.1 1.7 1.2 0.9 1.2
			1	2	3	5	6	7	8	9	11	12
	P1 P2 P3 P4 P5 P6 P7 P8 SD	8 8 8 8 8 8 8 8 8.0 0.0	14 9 8 7 11 9 10 5 9.1 6.8 8.4 11.1 6.3 9.0 19.6 16.3 18.4 22.5 6 8 17 7 20 35 20 25 32 7 9 12 6 8 21 16 18 19 6 9 10 6 7 22 16 18 25 6 9 10 6 7 15 17 20 19 8 8 11 6 8 16 16 15 23 7 8 9 7 8 17 14 17 23 7 9 10 6 7 17 15 21 21 7 7 10 6 7 14 16 13 18 2.7 0.7 0.7 2.5 0.5 4.5 6.8 1.8 3.7 4.5

After Cockburn[START_REF] Cockburn | Writing Effective Use Cases[END_REF]: a sub-function requirement is a requirement that is below the main level of interest to the user, i.e. "logging in", "locate a device in a DB".

The term "specifying" is understood here as the process of transcribing the vision of the screen into the ScreenSpec code.

The case study is labeled here as a controlled, because the methodology was similar to that used in case of controlled experiments, however the nature of questions being investigated refers rather to the "common sense", then to some obtainable values (e.g. compare average learning time, to the one which is acceptable for the industry).

Acknowledgements

Authors would like to thank companies which cooperate with Poznań University of Technology: Polsoft and Komputronik. They found time and courage to try our ideas in practice and provided us with a substantial feedback. This research has been financially supported by the Polish Ministry of Science and Higher Education under grant N516 001 31/0269.

This research has been financially supported by the Polish Ministry of Science and Higher Education grant N516 001 31/0269. 1 See experiment conclusions in section: "Mockup helps to unveil usability problems".


Issa Sangare

Anne Jolivet

Antoine Adenis

Leila Adriouch #

Mathieu Levy-Loeb #

Sabine Dimanche #

Vincent Vantilcke

Christian Marty ¶#

Pierre Couppié #

Mathieu Nacher

Paid HIV rapid testing in general medicine private practice in French Guiana: a pilot project

Keywords: HIV rapid testing, private practice, diagnostic delay, French Guiana, Public Health

French Guiana is the French territory with the highest HIV prevalence. A pilot study implemented rapid HIV testing in private practitioner's clinics with funding of the tests and compensation for the time spent for the test. Communication informed the population about this opportunity. Overall 90% of private practitioners participated over a period of 23 months, diagnosing 41 new patients for 4868 tests performed. This intervention seemed successful, and the health authorities have now transformed it into policy.

Introduction

French Guiana has long been the French territory most affected by HIV Ministry of Health, 2010). Persons unaware of their HIV infection have a preponderant role in the infection of new sexual partners [START_REF] Marks | Estimating sexual transmission of HIV from persons aware and unaware that they are infected with the virus in the USA[END_REF]. Too often, HIV-infected persons unaware of their infections repeatedly come in contact with physicians without being proposed to do an HIV test (Champenois et al., 2013). In French Guiana, private practitioners perform 70% of all HIV tests and diagnose 45% of new HIV patients (INVS, 2012). Following the national recommendations to do an HIV test each year for every one having sexual relations in French Guiana [START_REF] Has | Depistage de l'Infection par le VIH/Sida en France: Stratégies et Dispositif de dépistage[END_REF]Ministry of Health, 2010), a pilot project using rapid HIV tests in the private practice was developed by the Réseau Kikiwi, a network of health professionals involved in HIV care and testing. The objective here is to present this experience and its evaluation.

Methods

Context of private practice in French Guiana

French Guiana is the least medicalized French territory. Modelling studies predict that this will get worse in the future [START_REF] Boula | Projection de l'offre et de la demande de soins aux Antilles-Guyane à l'horizon 2030[END_REF]. Private practitioners thus have little time for more than what the patient comes for.

Context of the project initiation

Between July and November 2011, 12 private practitioners volunteered to start using rapid tests. The Health Regional Agency and the Caisse Générale de Sécurité Sociale then agreed to fund the tests and to compensate practitioners for the time taken to test the patient starting in December 2011. Practitioners were trained on the test, on how to break the news of a positive test and on the organisation of HIV care for patient referral; practitioners signed a participant's charter, and kept a simple registry to justify payment. A communication campaign was organized with radio, television campaigns and large posters along major roads; posters were placed in all pharmacies with a message in 5 local languages, and given to private practitioners to place in their waiting rooms in order to inform patients (Figure 1).

Quantitative evaluation

The data from the anonymized rapid test registries between December 2011 and May 2013 were analyzed.

Evaluation of acceptability

Between March and April 2012 face to face interviews were conducted with 32 practitioners working in the Cayenne area using a structured questionnaire. In February 2012, a physician collected the responses of consenting patients waiting for a consultation in a private practice using a questionnaire filled by the patient. When the patient had problems to read and write in French the interview was done face to face by the investigating physician.

Regulatory approval

In accordance with French law the database was declared to the commission nationale informatique et libertés N°1690953.

Results

Quantitative evaluation

In 23 months of this pilot project, 83 private practitioners working in Cayenne Kourou, Saint Georges de l'Oyapock and Saint Laurent du Maroni agreed to participate. There were only 2 specialists and 81 general practitioners. This amounts to 90% of all general medicine private practitioners in French Guiana. A total of 4868 tests were performed, among which 43 were positive, thus a prevalence of 0.8%. Among the positive tests, 2 patients were already aware of their HIV infection, 2 other patients were never seen again by the private practitioner. Overall, 41 new HIV patients were discovered with rapid tests. There were 14 undetermined tests. Among the tested patients 48% were foreigners. The median age was 34 years (IQR= 24-45 years), 65% of tested persons were women. For HIV positive tests, 58% were women. The median age of positive tests was 46,5 years range (25-76), IQR 25-75=36-55. Overall, for all of French Guiana, the purchasing of rapid tests, the payment of practitioners, the communication, training cost 191 000 euros between December 2011 and May 2013. Among the practitioners having agreed to participate, 80% had performed at least one rapid test with an average 3,5 rapid tests per month (range 1-190 tests per month).

Evaluation of acceptability for practitioners

A total of 32 physicians were surveyed: 29/32 declared that using rapid tests was pertinent and feasible. 28/32 declared feeling at ease to propose the test, to discuss the patient's sexual practices and to give the test result. The practitioners declared they proposed the test in similar situations than those where they prescribe an ELISA method (patient request, epidemiologic or clinical indications). Physicians also declared testing persons that had no medical follow up, were reticent to do the test elsewhere. Half of surveyed practitioners declared that no patient refused a rapid test. For those reporting patient refusal, in half of the cases it was because the patient had recently had an HIV test. The surveyed practitioners declared that overall with pre and post test counselling, and the test itself the process took 11 minutes on average when the test was negative and 40 minutes when the test was positive. For 53%, the rapid test could be integrated in a standard consultation. Concerning the technical test realization, 54% thought that the capillary blood collection was difficult or very difficult. Overall, 26/32 practitioners declared that it was difficult for them to propose the test to all patients targeted, mostly because they had too many patients awaiting consultation, and testing them would make them lose time.

Survey of patients

For 62.5% of the 213 patients interrogated, the private practitioner was the first person they would consult to do an HIV test; 85% declared they would accept to do a rapid test if the physician asked them to do it; and 85% of persons found very interesting that private practitioners could propose a rapid test at their practice; 67% of surveyed patients did not know their practitioner could propose a rapid test.

Discussion

The estimated 1 000 persons that are infected with HIV and not aware of it should be the main focus of the testing effort in French Guiana [START_REF] Hamers | Diagnosed and undiagnosed HIV-infected populations in Europe[END_REF]INSEE, 2009;Yazdanpanah et al., 2010). The present pilot study showed the feasibility and acceptability, among patients and practitioners, of rapid HIV testing in the setting of private practice in French Guiana. With 41 new HIV diagnoses in 18 months and 90% of private practitioners having signed up (unheard of in France), the intervention seemed to have some success. Indeed, in Cayenne Hospital's HIV clinic there seemed to be a surge in new HIV patients (figure 2) and the proportion of patients with CD4 counts<200 decreased for the first time when compared with the previous years(COREVIH [START_REF] Guyane | Rapport d'activites 2012 COREVIH GUYANE[END_REF]. These converging elements do not however prove that rapid HIV testing by private practitioners was the only possible cause for improving HIV diagnosis because a number of other interventions were simultaneously implemented (rapid testing by NGOs, voluntary testing at the emergency department, rapid testing in a mobile truck by the Red Cross). However, all other innovations combined did not manage to identify as many patients. In addition, the 41 diagnoses only corresponds to HIV rapid tests but physicians still use standard ELISA testing at the laboratory. The proportion of rapid versus standard ELISA was not known, physicians plausibly substituted ELISA tests for rapid tests in some situations. Although the official message(Ministry of Health, 2010) « In French Guiana one test per person and per year » has been largely relayed, the practitioners, in fact, have a targeted approach to testing relying on epidemiological context or clinical signs. Although a few practitioners managed to do a large number of tests, the realization of rapid tests was however often reported to be difficult. In a context of scarcity of practitioners [START_REF] Boula | Projection de l'offre et de la demande de soins aux Antilles-Guyane à l'horizon 2030[END_REF], they were time consuming. The supply, training, communication required the consistent investment of 2 coordinating physicians. Although the national Plan against HIV AIDS recommends a particular effort on HIV testing, this pilot study has now come to an end and will no longer be funded by the Health authorities. Figure 3 shows that in February 2013, when private practitioners started to learn that they would no longer be compensated for the time spent, they massively withdrew from the initiative. The precision of the data in the last 3 months may be less reliable because some physician then refused to give their registries, but the visible decline was genuine because physicians also refused to take new test kits because they would not use them anymore. It is officially recommended that each sexually active person in French Guiana get an HIV test annually [START_REF] Has | Depistage de l'Infection par le VIH/Sida en France: Stratégies et Dispositif de dépistage[END_REF]Ministry of Health, 2010). This would concern approximately 130 000 persons who, using the normal Elisa method, would each require an initial consultation (27.60 euros per consultation) to prescribe the test, would then need to go to a laboratory (14.58 euros each test) and then consult once more to get the result from the prescribing physician. Overall, for French Guiana, if this only relied on private practitioners and in the unlikely event that all who had an indication willingly consulted the practitioners, this would cost 5.5 million euros per year using the normal ELISA, not counting the cost of the first consultation. This would indeed be an extreme consequence of the official recommendation. In real life, the rapid 4 868 tests were performed in 23 months at a cost of 191 000 euros, performing the same number of tests with the standard ELISA would have cost 205 000 euros, not counting the cost of the first consultation, and it is predictable that a significant proportion would not have bothered with the whole process of going to a lab and then coming back to the practitioner for the result. Yet the pilot project was terminated. Instead the ministry of health is now promoting a one week communication campaign to promote testing, with presumably minimal implication of private practitioners who have expressed strong resentment. Indeed, the financial conjuncture is difficult, but it is perplexing to see the interruption of a concrete and cost effective intervention that led to diagnose 41 new patients (4 % of the estimated undiagnosed HIV population in French Guiana): not a small feat for a sparsely populated region. Media communication should not take priority over practical and effective interventions, it should promote them.

Figure 3 :

 3 Figure 3: Number of HIV rapid tests and number of participating physicians, aggregated by month, between 12/01/2011 and 05/31/2013