User-Centered Design and Agile Software Development Processes

Beatrice Hwong Siemens Corporate

Research 755 College Road

East beatrice.hwong@sc

r.siemens.com

David Laurance Siemens Corporate

Research 755 College Road

East david.laurance@scr

.siemens.com

Xiping Song Siemens Corporate

Research (SCR) 755 College Road

East xiping.song@scr.sie

mens.com

Arnold Rudorfer Siemens Corporate

Research 755 College Road

East Arnold.rudorfer@scr.

siemens.com

ABSTRACT The time and budget to create software products is shrinking; successful enterprises will economize both by combining processes and exploiting synergies between SE and UCD practices. By intelligently combining the strengths of SE and UCD processes and by using one development artifact, e.g. storyboard, it is possible, more quickly than before, to focus on client requirements, to design and implement the user interface, and to shorten test iteration cycles. With use of a single artifact, time compression for the project life cycle is achieved. This position paper presents an experience report on how we have successfully combined SE and UCD practices.

Author Keywords Process integration, optimization, agile and iterative development, storyboard, requirements and design models.

INTRODUCTION What is the current market situation for user-centered design (UCD) and software engineering (SE) software providers? Scarce resources force providers to achieve more with much less and, at a minimum, to maintain the status quo of quality.

Managers and decision makers in the software industry are increasingly demanding quick turn-around in software development and related tasks. In this context, both schedule and feature content are often dictated by market window, without regard for quality or feasibility. Software Engineers have responded with a shift from traditional, plan-driven approaches to more “agile” methods, relying on short development cycles and requiring frequent client interaction to create a climate where developers and clients can agree on the combination of features and quality that can best meet the market needs. In effect, by engaging the client repeatedly in a series of interim reviews, we can facilitate and speed the development process while continually aligning our project with user and market needs. In order to do this successfully,

software development teams must find a way to communicate successfully with their clients, both to capture client needs and to show how the product will be implemented to meet those needs. Most software development methodologies now rely on use cases or “user stories” to capture client needs; however, for many systems, these approaches are limited in their ability to convey useful information to the client; this is often not completed until the end of an iteration, when running code is implemented.

In a growing number of software systems, the user interface accounts for approximately half of the total lines of code [1]. Among our clients, this is often recognized late in the development cycle, typically after much of the code for the system has been written. In our development experience, UCD expertise is sometimes engaged at this time, but it is often too late in development for UCD-related changes to be introduced. Significant UI defects often remain unaddressed in the released product.

At Siemens Corporate Research, we have seen both of these problems repeated in our consulting experience. We believe that we have addressed both of them by introducing UCD techniques directly into the software development process. Our requirements team includes UCD expertise as well as traditional requirements engineering expertise; in addition, we create a storyboard for each client scenario, and use that storyboard to capture overall client requirements. While the storyboard may be translated or decomposed into individual scenarios or story cards, it provides a graphical narrative that communicates directly with the client. It can be reviewed by both client and requirements teams during software development, and can be used to verify correct function of the software within the development cycle.

We have thus adapted a combination of UCD and SE methods and practices into the overall product development process. This can be seen as merely “common sense”: to tailor one’s design and

1

development process to the needs of a specific project. However, without a clear understanding and experience of both worlds, it is difficult to see the links and similarities. Projects cannot effectively capitalize on the right methods to be used in UCD and SE.

Recently, more examples of intelligently combining UCD and SE can be found be found. For example, Extreme Programming and agile software development [2] were presented in one of the principal software engineering conferences ICSE’03 [4,6,7]. There are 2 main streams identified by the research literature. One is the integration of UCD techniques into the software engineering process [7]. The other is the active coordination and communication of the UCD and SE processes running in parallel, and joined by well-defined process interfaces [4].

This position paper is an experience report of how UCD and SE practices can synergistically deliver client-centric and advanced software features.

First, we will outline the overall process applied in the development of hospital administration demo software system used for sales and marketing purposes. .

Second, we present a thorough discussion of how the process is accepted by all stakeholders.

Third, we highlight the potential for future work.

AN INTEGRATED DEVELOPMENT PROCESS Over the past 3 years within SCR, the User Interface Design Center and the Software Engineering Department have worked closely to streamline the product development process. Software engineers and user-centered design specialists work together to deliver an advanced product prototype showcasing hospital administration features

A project where we typically try to capitalize on advantageous UCD or SE methodologies could start as follows: A potential client requests that we assist them in developing a new feature set to be shown to customers at an up-coming conference. The client typically has no feature requirements specified and often does not know what should be built. The timeframe can be as little as 6 weeks. Of course, our development team needs to deliver superior code

quality, rely on a minimum development overhead (e.g. minimum specifications), and have the capability to adapt continually to short-term changes.

A traditional waterfall development model cannot deliver the code within a time frame of 6 weeks paired with the other challenging constraints. It takes too much time to elicit the requirements, transform the requirements model into a design model, do the UI specification as well as the define the test cases. This leads us to adopt an iterative approach, and to consider various agile methods. But even with agile methods, we have experienced limitations in gathering feedback quickly enough to keep our severely shortened development cycle on track.

To overcome these limitations, we propose aligning UCD and SE processes as shown conceptually in figure 2. Each discipline (UCD + SE) is interconnected with each other like in a “puzzle” process chain. UCD and SE people work either quasi parallel with each other (independently) via clearly defined interfaces or jointly (integrated). Both approaches have its unique advantages and challenges.

To build a set of feature using a UCD-SE process and fit into a tight time window, the development team needs to rely on software artifact(s) that can serve multiple purposes, (e.g., from a requirements model to a design and test case model). Our experience exploring the overlap of UCD and SE processes led to the use of a single software artifact for design and development of advanced product prototype demos [3].

Overall, the optimized UCD-SE process consists of 3 major activities (see figure 3): (i) Requirements, (ii) Design and Implementation, and (iii) Validation. The key to this process is to use the storyboard as a single, unifying artifact across major activities.

Requirements A small upfront effort identifies stakeholders in the project scope (e.g. domain expert, user representatives) and enumerates scenarios. The development team then carries out a 2-hour client workshop with domain experts and composes the basic story in terms of screen prints or sketches, task flow (sequence of screens), and data requirements.

2

Figure 1: Sample Storyboard Used for Requirements Specification, UI Specification and Test Case for Regression

The initial output of the client workshop is the storyboard. We have been using MS PowerPoint as the tool to produce the storyboard. People can make annotations on the screens such as data changes, scenario steps, or an elaborated user interaction. The PowerPoint “Notes” section contains both a detailed description of the user interaction and a data section.

The storyboard enables the following lines of activities in parallel: a) the development team is able to provide a good development estimate since the overall flow of the story is well defined, b) it can be used to evaluate the complexity of the interaction to be developed, c) the user-centered design specialist can evaluate the level of usability using the wizard of Oz method (or paper prototype usability testing), d) the client can work with other domain experts to validate the functional requirements e.g. defining a new advanced feature set for a product e) Marketing people (clients) can produce the demo script using the storyboard.

In our project, we have succeeded in eliciting concrete, buildable requirements from our clients (marketing and sales staff) using a storyboard. This way, the risk of late requirements changes can be minimized as the story is visually present. The last step in the “Requirements” phase is the storyboard review in a read-out session to user representatives where the whole development team attends and can ask very specific questions on user interactions and can clarify ambiguous domain details. In the 6-weeks project, the requirements phase took 2 staff-weeks to create 1 simple, 2 medium and 1 high complexity storyboards.

Design and Implementation Next, the development team reviews the storyboard and decides how to decompose the screens and features into manageable coding activities. Activities may support specific aspects of the storyboard, or developers may create additional “story card” equivalents that can be built up to support the storyboard. Individuals or pairs of developers take

responsibility for these story cards, developing both code and unit tests.

Validation At regular intervals, we hold a “round-trip review” with the client. All functionality is reviewed interactively, and the client provides feedback on the implementation of the storyboard. The storyboard is updated during the review if possible. Client change requests are often minor, but frequently, the review process helps the client to understand new requirements.

Finally, the code is validated with a full regression test using the storyboard as the test case specification.

Retrospective In order to check the development process, the team carries out an improvement workshop at the end of each development interval. This is an informal session where the entire team reflects on the previous interval and documents what went well and what could be improved. The output is an action plan that formulates gradual improvements in the process such as a groupware tool for the development team and the client (LiveLink) and the adoption of coding standards.

The overall development of the features in the example project took 3 ½ staff-weeks. If a traditional waterfall approach were taken, we estimate it would have taken 8 to 12 weeks.

GAINING STAKEHOLDER ACCEPTANCE

We chose to start requirements capture through a workshop in response to our clients’ requirement for an extremely short development schedule. In that context, the choice of storyboard seemed a natural way to document the workshop and provide rapid and high-quality feedback to our clients.

Our clients have generally been quite happy with both the workshop approach and the storyboard artifact. They understood the storyboard without training, and they are comfortable using it. They have been able to propose and review changes in storyboards, and over time have learned to expect that we can capture and implement their requirements efficiently and effectively.

Initially, our storyboards were informal and incomplete, capturing just enough for our development team to get started. During development, we found that it was difficult to maintain communication with our clients at a sufficient level to sustain the required development pace. Because of this, we have over time begun to capture more complete information in the storyboards themselves,

3

so that each became a single record of customer needs.

Another key item was how UCD and SE people collected, analyzed and validated the requirements, achieving quasi-parallel threads of work for each discipline in the project. In order to support communication between team members with different (UCD and SE) backgrounds, we needed a common language. The storyboard provided the means to develop that language; moreover, since it uses a metaphor the client is already comfortable with, it promotes better communication all around.

Conclusions Carrying out a retrospective analysis of a series of projects conducted over the last 3 years, we have come up with the following learnings regarding UCD and SE process optimization.

• Provide a clear rationale for the optimization of UCD and SE processes (for instance, in terms of economic value or increased quality)

• Every UCD and SE process optimization needs to consider the type of project that is being carried out as well as which domain it will contain. For example, storyboards make sense for advanced product prototype development in the healthcare sector, but may not make sense for other project types or in other domains.

• • Collaboration of UCD & SE people builds an

understanding of each other’s processes. Therefore, the increased understanding can avoid unhealthy competition within or across projects.

• The choice of storyboard is separate from the decision to use a single artifact. The storyboard seems to suit the problem domain (healthcare information systems) well, but there may be other, more appropriate artifacts in other sectors. At the same time, the use of a single artifact appears to be motivated by development schedule and problem size.

FUTURE WORK From the experience gathered so far, we are planning to diversify the UCD and SE process optimization idea to other types of projects and also to different domains (e.g. Power Generation, Automation and Control). Specifically, we are further investigating the following questions:

• Can a general process model be built?

• What is the common design language that UCD and SE specialists understand?

• What UCD and SE processes/ methodologies/ tools work in which situation and context?

• How can the business impact of the process optimization be measured in terms of economic added value?

• What are the best practices in the industry?

ACKNOWLEDGMENTS The authors are very grateful to the Siemens Corporate Research Soarian Financial Vision Demo development team (including Herb Foster, Junius Gunaratne, Steve Masticola, Gilberto Matos, Christopher Nelson, and Raj Tanikella). The members apply the depicted process on a daily basis and have contributed many ideas to further shape and refine this work.

REFERENCES 1. Meyers B., Rosson M. B. Survey on User Interface

Programming, CHI ’92, Conference Proceedings, Monterrey, CA, 195-202

2. Beck K., Extreme Programming Explained: Embrace Change, 2000

3. Siemens Medical Systems, Siemens Corporate Research (invention disclosure from Arnold Rudorfer, Beatrice Hwong, Robin Kavanagh): Agile Software Development Process Enables Rapid Application Development of Advanced Demo Prototype by Means of Multiple Use of Storyboard, 12/03

4. Pardha S., Pyla, Manuel A. Quinones: Towards a Model-based Framework for Integrating Usability and Software Engineering Lifecycles, ICSE’03

5. Laurance, D., Rudorfer, A.: Optimizing Use of Software Engineering & User-Centered Design Practices in Demo Development, SAIG 8 Control Systems Software Architecture Improvement Group, October, 2003, Nuremberg

6. Paech B., Kohler K. Usability Engineering Integrated with Requirements Engineering. in Proceedings of ICSE’03 (International Conference for Software Engineering – Portland, Oregon)

7. Ferre, X.: Integration of Usability Techniques into Software Development Process, in Proceedings of ICSE’03 (International Conference for Software Engineering – Portland, Oregon)

8. Cronin, D. RUP & Goal Directed Design. Toward a New Development Process, July 2003, http://www.cooper.com/content/insights/newsletters/2003_07/RUP_&_GDD.asp

4

5

Figu

re 2

: Int

egra

ted

UC

D-S

E D

evel

opm

ent P

roce

ss

Requ

irem

ents

De

sign

and

Impl

emen

tatio

n Va

lidat

ion

Figu

re 3

: Com

pres

sing

the

Inte

grat

ed U

CD

-SE

Dev

elop

men

t Pro

cess

into

3 M

ajor

Blo

cks

of A

ctiv

ities

6