Scr Position Paper For Chi 04 Workshop


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Scr Position Paper For Chi 04 Workshop

  1. 1. User-Centered Design and Agile Software Development Processes Beatrice Hwong David Laurance Xiping Song Arnold Rudorfer Siemens Corporate Siemens Corporate Siemens Corporate Siemens Corporate Research Research Research (SCR) Research 755 College Road 755 College Road 755 College Road 755 College Road East East East Eastbeatrice.hwong@sc david.laurance@scr Arnold.rudorfer@scr. siemens.comABSTRACT software development teams must find a way toThe time and budget to create software products is communicate successfully with their clients, both toshrinking; successful enterprises will economize both capture client needs and to show how the product willby combining processes and exploiting synergies be implemented to meet those needs. Most softwarebetween SE and UCD practices. By intelligently development methodologies now rely on use cases orcombining the strengths of SE and UCD processes “user stories” to capture client needs; however, forand by using one development artifact, e.g. many systems, these approaches are limited in theirstoryboard, it is possible, more quickly than before, to ability to convey useful information to the client; this isfocus on client requirements, to design and implement often not completed until the end of an iteration, whenthe user interface, and to shorten test iteration cycles. running code is implemented.With use of a single artifact, time compression for theproject life cycle is achieved. This position paper In a growing number of software systems, the userpresents an experience report on how we have interface accounts for approximately half of the totalsuccessfully combined SE and UCD practices. lines of code [1]. Among our clients, this is often recognized late in the development cycle, typicallyAuthor Keywords after much of the code for the system has beenProcess integration, optimization, agile and iterative written. In our development experience, UCDdevelopment, storyboard, requirements and design expertise is sometimes engaged at this time, but it ismodels. often too late in development for UCD-related changes to be introduced. Significant UI defects oftenINTRODUCTION remain unaddressed in the released product.What is the current market situation for user-centered At Siemens Corporate Research, we have seen bothdesign (UCD) and software engineering (SE) software of these problems repeated in our consultingproviders? Scarce resources force providers to experience. We believe that we have addressed bothachieve more with much less and, at a minimum, to of them by introducing UCD techniques directly intomaintain the status quo of quality. the software development process. Our requirementsManagers and decision makers in the software team includes UCD expertise as well as traditionalindustry are increasingly demanding quick turn-around requirements engineering expertise; in addition, wein software development and related tasks. In this create a storyboard for each client scenario, and usecontext, both schedule and feature content are often that storyboard to capture overall client requirements.dictated by market window, without regard for quality While the storyboard may be translated oror feasibility. Software Engineers have responded decomposed into individual scenarios or story cards, itwith a shift from traditional, plan-driven approaches to provides a graphical narrative that communicatesmore “agile” methods, relying on short development directly with the client. It can be reviewed by bothcycles and requiring frequent client interaction to client and requirements teams during softwarecreate a climate where developers and clients can development, and can be used to verify correctagree on the combination of features and quality that function of the software within the development cycle.can best meet the market needs. In effect, by We have thus adapted a combination of UCD and SEengaging the client repeatedly in a series of interim methods and practices into the overall productreviews, we can facilitate and speed the development development process. This can be seen as merelyprocess while continually aligning our project with user “common sense”: to tailor one’s design andand market needs. In order to do this successfully, 1
  2. 2. development process to the needs of a specific quality, rely on a minimum development overheadproject. However, without a clear understanding and (e.g. minimum specifications), and have the capabilityexperience of both worlds, it is difficult to see the links to adapt continually to short-term changes.and similarities. Projects cannot effectively capitalize A traditional waterfall development model cannoton the right methods to be used in UCD and SE. deliver the code within a time frame of 6 weeks pairedRecently, more examples of intelligently combining with the other challenging constraints. It takes tooUCD and SE can be found be found. For example, much time to elicit the requirements, transform theExtreme Programming and agile software requirements model into a design model, do the UIdevelopment [2] were presented in one of the principal specification as well as the define the test engineering conferences ICSE’03 [4,6,7]. This leads us to adopt an iterative approach, and toThere are 2 main streams identified by the research consider various agile methods. But even with agileliterature. One is the integration of UCD techniques methods, we have experienced limitations in gatheringinto the software engineering process [7]. The other is feedback quickly enough to keep our severelythe active coordination and communication of the shortened development cycle on track.UCD and SE processes running in parallel, and joined To overcome these limitations, we propose aligningby well-defined process interfaces [4]. UCD and SE processes as shown conceptually inThis position paper is an experience report of how figure 2. Each discipline (UCD + SE) is interconnectedUCD and SE practices can synergistically deliver with each other like in a “puzzle” process chain. UCDclient-centric and advanced software features. and SE people work either quasi parallel with each other (independently) via clearly defined interfaces or First, we will outline the overall process jointly (integrated). Both approaches have its unique applied in the development of hospital advantages and challenges. administration demo software system used for sales and marketing purposes. . To build a set of feature using a UCD-SE process and fit into a tight time window, the development team Second, we present a thorough discussion of needs to rely on software artifact(s) that can serve how the process is accepted by all multiple purposes, (e.g., from a requirements model stakeholders. to a design and test case model). Our experience Third, we highlight the potential for future exploring the overlap of UCD and SE processes led to work. the use of a single software artifact for design and development of advanced product prototype demosAN INTEGRATED DEVELOPMENT PROCESS [3].Over the past 3 years within SCR, the User Interface Overall, the optimized UCD-SE process consists of 3Design Center and the Software Engineering major activities (see figure 3): (i) Requirements, (ii)Department have worked closely to streamline the Design and Implementation, and (iii) Validation. Theproduct development process. Software engineers key to this process is to use the storyboard as aand user-centered design specialists work together to single, unifying artifact across major activities.deliver an advanced product prototype showcasinghospital administration features RequirementsA project where we typically try to capitalize on A small upfront effort identifies stakeholders in theadvantageous UCD or SE methodologies could start project scope (e.g. domain expert, useras follows: A potential client requests that we assist representatives) and enumerates scenarios. Thethem in developing a new feature set to be shown to development team then carries out a 2-hour clientcustomers at an up-coming conference. The client workshop with domain experts and composes thetypically has no feature requirements specified and basic story in terms of screen prints or sketches, taskoften does not know what should be built. The flow (sequence of screens), and data requirements.timeframe can be as little as 6 weeks. Of course, ourdevelopment team needs to deliver superior code 2
  3. 3. 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 newFigure 1: Sample Storyboard Used for requirements.Requirements Specification, UI Specification and Finally, the code is validated with a full regression testTest Case for Regression using the storyboard as the test case specification.The initial output of the client workshop is thestoryboard. We have been using MS PowerPoint as Retrospectivethe tool to produce the storyboard. People can make In order to check the development process, the teamannotations on the screens such as data changes, carries out an improvement workshop at the end ofscenario steps, or an elaborated user interaction. The each development interval. This is an informal sessionPowerPoint “Notes” section contains both a detailed where the entire team reflects on the previous intervaldescription of the user interaction and a data section. and documents what went well and what could be improved. The output is an action plan thatThe storyboard enables the following lines of activities formulates gradual improvements in the process suchin parallel: a) the development team is able to provide as a groupware tool for the development team and thea good development estimate since the overall flow of client (LiveLink) and the adoption of coding standards.the story is well defined, b) it can be used to evaluatethe complexity of the interaction to be developed, c) The overall development of the features in thethe user-centered design specialist can evaluate the example project took 3 ½ staff-weeks. If a traditionallevel of usability using the wizard of Oz method (or waterfall approach were taken, we estimate it wouldpaper prototype usability testing), d) the client can have taken 8 to 12 with other domain experts to validate thefunctional requirements e.g. defining a new advanced GAINING STAKEHOLDER ACCEPTANCEfeature set for a product e) Marketing people (clients)can produce the demo script using the storyboard. We chose to start requirements capture through aIn our project, we have succeeded in eliciting workshop in response to our clients’ requirement forconcrete, buildable requirements from our clients an extremely short development schedule. In that(marketing and sales staff) using a storyboard. This context, the choice of storyboard seemed a naturalway, the risk of late requirements changes can be way to document the workshop and provide rapid andminimized as the story is visually present. The last high-quality feedback to our clients.step in the “Requirements” phase is the storyboard Our clients have generally been quite happy with bothreview in a read-out session to user representatives the workshop approach and the storyboard artifact.where the whole development team attends and can They understood the storyboard without training, andask very specific questions on user interactions and they are comfortable using it. They have been able tocan clarify ambiguous domain details. In the 6-weeks propose and review changes in storyboards, and overproject, the requirements phase took 2 staff-weeks to time have learned to expect that we can capture andcreate 1 simple, 2 medium and 1 high complexity implement their requirements efficiently andstoryboards. effectively.Design and Implementation Initially, our storyboards were informal andNext, the development team reviews the storyboard incomplete, capturing just enough for ourand decides how to decompose the screens and development team to get started. Duringfeatures into manageable coding activities. Activities development, we found that it was difficult to maintainmay support specific aspects of the storyboard, or communication with our clients at a sufficient level todevelopers may create additional “story card” sustain the required development pace. Because ofequivalents that can be built up to support the this, we have over time begun to capture morestoryboard. Individuals or pairs of developers take complete information in the storyboards themselves, 3
  4. 4. so that each became a single record of customer • What is the common design language thatneeds. UCD and SE specialists understand?Another key item was how UCD and SE people • What UCD and SE processes/ methodologies/collected, analyzed and validated the requirements, tools work in which situation and context?achieving quasi-parallel threads of work for eachdiscipline in the project. In order to support • How can the business impact of the processcommunication between team members with different optimization be measured in terms of(UCD and SE) backgrounds, we needed a common economic added value?language. The storyboard provided the means to • What are the best practices in the industry?develop that language; moreover, since it uses ametaphor the client is already comfortable with, itpromotes better communication all around. ACKNOWLEDGMENTSConclusions The authors are very grateful to the SiemensCarrying out a retrospective analysis of a series of Corporate Research Soarian Financial Vision Demoprojects conducted over the last 3 years, we have development team (including Herb Foster, Juniuscome up with the following learnings regarding UCD Gunaratne, Steve Masticola, Gilberto Matos,and SE process optimization. Christopher Nelson, and Raj Tanikella). The members apply the depicted process on a daily basis and have • Provide a clear rationale for the optimization contributed many ideas to further shape and refine of UCD and SE processes (for instance, in this work. terms of economic value or increased quality) REFERENCES • Every UCD and SE process optimization needs to consider the type of project that is 1. Meyers B., Rosson M. B. Survey on User Interface being carried out as well as which domain it Programming, CHI ’92, Conference Proceedings, will contain. For example, storyboards make Monterrey, CA, 195-202 sense for advanced product prototype 2. Beck K., Extreme Programming Explained: development in the healthcare sector, but may Embrace Change, 2000 not make sense for other project types or in 3. Siemens Medical Systems, Siemens Corporate other domains. Research (invention disclosure from Arnold • Rudorfer, Beatrice Hwong, Robin Kavanagh): Agile Software Development Process Enables Rapid • Collaboration of UCD & SE people builds an Application Development of Advanced Demo understanding of each other’s processes. Prototype by Means of Multiple Use of Storyboard, Therefore, the increased understanding can 12/03 avoid unhealthy competition within or across projects. 4. Pardha S., Pyla, Manuel A. Quinones: Towards a Model-based Framework for Integrating Usability • The choice of storyboard is separate from the and Software Engineering Lifecycles, ICSE’03 decision to use a single artifact. The 5. Laurance, D., Rudorfer, A.: Optimizing Use of storyboard seems to suit the problem domain Software Engineering & User-Centered Design (healthcare information systems) well, but Practices in Demo Development, SAIG 8 Control there may be other, more appropriate artifacts Systems Software Architecture Improvement in other sectors. At the same time, the use of Group, October, 2003, Nuremberg a single artifact appears to be motivated by development schedule and problem size. 6. Paech B., Kohler K. Usability Engineering Integrated with Requirements Engineering. inFUTURE WORK Proceedings of ICSE’03 (International ConferenceFrom the experience gathered so far, we are planning for Software Engineering – Portland, Oregon)to diversify the UCD and SE process optimization idea 7. Ferre, X.: Integration of Usability Techniques intoto other types of projects and also to different domains Software Development Process, in Proceedings of(e.g. Power Generation, Automation and Control). ICSE’03 (International Conference for SoftwareSpecifically, we are further investigating the following Engineering – Portland, Oregon)questions: 8. Cronin, D. RUP & Goal Directed Design. Toward a • Can a general process model be built? New Development Process, July 2003, /2003_07/RUP_&_GDD.asp 4
  5. 5. 5
  6. 6. Figure 2: Integrated UCD-SE Development Process Requirements Design and Implementation ValidationFigure 3: Compressing the Integrated UCD-SE Development Process into 3 Major Blocks of Activities 6