Integrating the Rational Unified Process and Participatory Design for Development of Socio-Technical Systems

Home , Rational Unified Process, Use case

Integrating the rational unified process and participatory design for development of socio- technical systems: A user participative approach

Sofie Pilemalm, Per-Ola Lindell, Niklas Hallberg and Henrik Eriksson

Linköping University Post Print

N.B.: When citing this work, cite the original article.

Original Publication: Sofie Pilemalm, Per-Ola Lindell, Niklas Hallberg and Henrik Eriksson, Integrating the rational unified process and participatory design for development of socio-technical systems: A user participative approach, 2007, Design Studies, (28), 3, 263-288. http://dx.doi.org/10.1016/j.destud.2007.02.009 Copyright: Elsevier http://www.elsevier.com/

Postprint available at: Linköping University Electronic Press http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-40336

ARTICLE IN PRESS JDST455_proof 6 March 2007 1/26

Integrating the Rational Unified Process 1 2 and participatory design for development 3 of socio-technical systems: a user 4 5 participative approach 6 7 Sofie Pilemalm, Per-Ola Lindell, Niklas Hallberg and Henrik Eriksson, 8 Department of Systems Development and IT Security, Division of Command 9 and Control Systems, Swedish Defence Research Agency, FOI, PO Box 1165, 10 SE-581 11 Linko¨ping, Sweden 11 12 This study presents the MOPT-Systems Development Process, aimed at 13 bridging the gap between ideality and reality. The process is based on an 14 approach to systems development involving a formalised process for PROOF 15 developing socio-technical systems. In specific, it integrates a modified 16 Rational Unified Process (RUP) framework with a socio-technical system 17 view and an extended participatory design (PD) perspective using PD 18 techniques and social research methods. It is argued that the integrated 19 approach, by combining the RUP formalisation, modeling tools and coverage 20 of the entire development process, together with the parallel development of 21 methodology, organisation, and personnel, will greatly enhance the chance of 22 solid systems, grounded in the organisation and appreciated by its users. In 23 this respect, the close cooperation with the end-users throughout the 24 development process is supposed to contribute. 25 Ó 2007 Published by Elsevier Ltd. 26 27 Keywords: Rational Unified Process, systems design, user participation, 28 collaborative design 29 30 31 32 n the last few decades, the need for taking a simultaneous view on 33 methodological, organisational, personnel, and technical aspects when 34 Ideveloping information systems, i.e., to develop socio-technical systems, 35 has become increasingly recognised (Avison and Fitzgerald, 1995). Similarly, 36 the necessityNCORRECTED of involving the end-users actively throughout the development 37 process in order to arrive at systems that are actually usable, used and appre- 38 ciatedU is today acknowledged by most system developers, at least in theory and 39 in academia. However, simultaneously to these insights, the software engineer- 40 ing approaches that still dominate industry tend less to put explicit emphasis 41 on the end-users and on the organisational and social aspects of information 42 systems. An example is the Rational Unified Process (RUP) which has, in re- Corresponding author: 43 S. Pilemalm cent years, received much attention as a defined process for development of 44 sofi[email protected] software intensive systems ensuring a high quality product (Kruchten, 45

www.elsevier.com/locate/destud 0142-694X $ - see front matter Design Studies -- (2007) --e-- doi:10.1016/j.destud.2007.02.009 1 Ó 2007 Published by Elsevier Ltd. Printed in Great Britain

Please cite this article in press as: Pilemalm, S et al., Integrating the Rational Uniﬁed Process and participatory design for development of socio-technical systems: a user participative approach, Design Studies (2007), doi:10.1016/ j.destud.2007.02.009 ARTICLE IN PRESS JDST455_proof 6 March 2007 2/26

2004). On the other hand, socio-technical oriented approaches, such as Partic- 46 ipatory Design (PD), are often criticised for being imprecise and lack in defin- 47 ing a fully specified design process (Constantine and Lockwood, 2002) and to 48 put emphasis only on the early systems development phases resulting in that 49 a ready-to-use system is seldom delivered (Tollmar, 2001). In the specific 50 case of PD, the approach is almost exclusively applied to small-scale projects 51 within the academic domain rather than to the design of large, strategic infor- 52 mation systems (Oostveen and van den Besselar, 2004). In conclusion, the need 53 to combine the benefits of a socio-technical perspective and active user partic- 54 ipation with more formalised processes covering entire system life cycles seems 55 urgent, both for academia and industry. This study presents a novel approach 56 to systems development based on such a combination, for the development of 57 information systems that are technologically solid as well as organisationally 58 compatible and grounded in users’ needs. 59 PROOF 60 1 Study objectives 61 The objective of the study is to present an overall approach and a specified pro- 62 cess for developing socio-technical systems. In specific, the study contributes 63 to the field of systems development by the following: 64 65 1. Presenting an overall approach to systems development based on the in- 66 tegration of a modified, extended version of RUP with an extended ver- 67 sion of PD. 68 2. Suggesting the MOPT-Systems Development Process based on the pre- 69 sented approach. The notion of MOPT systems refers to systems that con- 70 sider method, organisation personnel and technology in parallel during the 71 development process. (Figures 1e2) 72 More concretely, the MOPT-Systems Development Process is based on a sub- 73 set of RUP principles, artefacts and notations, in combination with principles 74 of active user participation and social research methods. It is intended to be 75 applied in the development of socio-technical systems, with a particular focus 76 on systems that are large, complex and distributed. 77 78 2 Background 79 This section presents the systems view and development approaches of rele- 80 vance forNCORRECTED the study, including socio-technical systems, the Rational Unified 81 Process, and participatory design. Further, a brief description of the study 82 context is provided. 83 U 84 2.1 Socio-technical systems 85 The socio-technical system view emerged in the 1970s as an opponent to the 86 more down-right technical perspectives that, thus far, had dominated systems 87 development thinking. According to the socio-technical view, systems consist 88 of individuals, social, cultural and organisational components, in addition to 89 mere technology. For systems to work well, they must fit closely with organisa- 90

2 Design Studies Vol -- No. -- Month 2007

91 92 93 94 95 96 97 Figure 1 Example of relations 98 between disciples and phases 99 as described in RUP Version 100 2003.06.00. The different 101 disciples receive different 102 amount of attention depend- 103 ing on the current project 104 phase PROOF 105 106 tional and social factors, and preferably enhance the quality of work life for 107 the users. Examples of the socio-technical system view are the Effective Tech- 108 nical and Human Implementation of Computer based Systems (ETHICS) 109 methodology, the Soft Systems Methodology (SSM) (Avison and Fitzgerald, 110 1995), and PD. The MOPT-Systems Development Process adopts a socio- 111 technical system view which is most visible in that method, organisation, per- 112 sonnel and technology are seen as equally important parts of the system and 113 are developed in parallel throughout the development process. 114 115 Of course a socio-technical perspective can be adopted for developing small as 116 well as large information systems. In contemporary society an ever increasing 117 amount of existing systems is large-scale and distributed, affecting many peo- 118 ple and institutions, as well as being complex, involving many administrative, 119 organisational, legal, political and ideological issues to be considered in the 120 systems development process (Oostveen and van den Besselar, 2004). The pro- 121 posed integrative approach follows in this development, which means that the 122 process in specific targets (but is not limited to) development of socio-technical 123 information systems of reasonably comprehensive size and involving heteroge- 124 neous user groups. This is, for instance, reflected in the extended version of PD 125 and the use of social research methods. 126 NCORRECTED 127 2.2 The Rational Unified Process 128 The RationalU Unified Process (RUP) is a software engineering process aimed 129 at guiding software development organisations in their endeavours to create 130 solid software. According to RUP, a system’s lifetime is described as a finite 131 number of development cycles. Each development cycle is divided into the 132 four project phases Inception, Elaboration, Construction and Transition (0). 133 The phases, in its turn, are divided into a number of iterations, depending 134 on the project’s needs and size. RUP includes nine disciples that are iteratively 135

Integrating the Rational Uniﬁed Process and participatory design 3

RUP Socio-technical systems PD Extended PD for large- 136 scale systems 137 138

Formalized Systems view Work in design/project External data complements 139 development - Method groups project groups’ work process - Organization Users actively participate in Social research methods 140 Disciplines/ - Personnel all workflows Active user participation but not workflows - Technology Participative design full user participation in all 141 UML (MOPT sub-systems) techniques aspects of development work 142 143 MOPT- Systems 144 integrative approach 145 146 Figure 2 The different influences on and specific contributions to the MOPT-Systems Integrative Approach 147 148 executed during the different phases. The disciples are divided into technical 149 and supportive disciples. The technical disciplinesPROOF include Business modeling, 150 Requirements, Analysis and Design, Implementation, Test and Deployment. 151 The supportive disciplines include Project Management, Configuration and 152 Change Management and Environment. Together the latter provide the infra- 153 structure that every project needs for the project work to proceed smoothly 154 (Kruchten, 2004). 155 156 157 RUP has, in the last decade, been increasingly recognised, as an efficient pro- 158 cess for developing software intensive systems. However, while RUP suggests 159 a process for developing the software system, aspects of surrounding organisa- 160 tional issues and active user participation are less well covered (Hesse, 2003; 161 Olsson, 2004). RUP should instead be viewed as a process framework or 162 even ‘‘a collection of good advice’’ that, indeed, acknowledges the potential 163 development of the enterprise and has, in recent versions included business 164 use cases as complementing the original system use cases (Kruchten, 2004), 165 and which also claims to involve system stakeholders in parts of the develop- 166 ment process. But all these aspects receive limited attention and are only 167 loosely connected to the overall RUP process framework, as one possible 168 way of doing things, rather than being fully integrated with concrete develop- 169 ment work. In RUP, a use case is a complete sequence of actions related to the 170 task the user aims to perform, either directly related to the system or to a cer- 171 tain workNCORRECTED task. Use cases can subsequently be integrated into use-case models. 172 As development proceeds, use-case models are transformed to system models, 173 objectU models and so on (Kruchten, 2004). The business use cases are, thus, 174 supposed to be an aid when initially modeling the present enterprise as the set- 175 ting for the system. Change aspects, where they occur, mainly relate to offi- 176 cially acknowledged changes than to in-depth investigations of true end-user 177 needs. RUP thereby, in reality presumes a rather narrowed and manager ori- 178 ented focus on the organisation (Hull et al., 2001). This is much in contrast 179 with the socio-technical system view and with PD approaches which explicitly 180

4 Design Studies Vol -- No. -- Month 2007

embrace change of work routines based on user needs. Further, in RUP user 181 representation is highly selective and users used as consultants, called in as 182 information sources when needed (e.g. as enterprise analysts) but with no 183 real influence over the entire development process (Constantine and Lock- 184 wood, 1999). This is in sharp contrast with the continuous, active and substan- 185 tial involvement of the users as recommended of the socio-technical design 186 approaches including PD (Gulliksen et al., 2003). 187 188 2.3 Participatory design 189 The participatory design (PD) approaches originated in the 1970s and 1980s, 190 when they were used as a means to empower workers at the workplace by let- 191 ting them take part in the design of the technology they were going to use. The 192 intention was to enhance workplace democracy and realise the ‘good work’ 193 objective, i.e., to increase worker autonomy, skill and task variety (Ehn, 194 1993). PD is, thus, a rather loosely connected setPROOF of philosophies, principles 195 and techniques belonging, to the socio-technical system view. The develop- 196 ment of organisations and personnel are seen as equally important to develop- 197 ment of technology and users are to be given direct influence on all aspects of 198 the systems development process, through their participation in design groups. 199 200 PD uses a range of techniques that are supposed to be easy-to-learn and put low 201 demand on the users’ beforehand knowledge. Commonly used are mock-ups, 202 future workshops, prototyping and scenarios (Ehn et al., 1996). Mock-ups 203 are paper based models of the current organisation or systems. Future work- 204 shops involve the users in the systems development process, by letting them 205 (1) reflect on their own work situation (critique phase), (2) identify futuristic 206 and innovative solutions to experienced problems (fantasy phase), and (3) trans- 207 form these solutions to be realistic and possible to implement (implementation 208 phase)(Kensing and Halskov Madsen, 1991). Scenarios are constructed use sit- 209 uations with reference to the users’ work tasks, often in a textual format (Car- 210 roll, 2000). They can be applied in the evaluative parts of a systems development 211 process and for identifying needs and requirements. Prototypes, i.e., models of 212 the system under development, are crucial for iterative systems development 213 and PD (Avison and Fitzgerald, 1995; Ehn et al., 1996). 214 215 Since its origin, PD has been extended and applied also outside the immediate 216 ideologicalNCORRECTED context (Reich et al., 1996). It has been argued that it results in better 217 systems than other approaches, since the systems are designed together with the 218 users insteadU of merely using them as information sources (Bravo, 1993). But 219 PD has also been criticised in several respects, e.g., for lack of formalisation, re- 220 sulting in increased overall complexity of implementation, for extensively deal- 221 ing with the early design phases while putting less emphasis on, the later, more 222 technical stages (Tollmar, 2001), and for having a pro-longed focus on consen- 223 sus reaching and democratic processes, thereby hampering efficiency and a co- 224 herent system architecture (Doll and Deng, 1999; Asaro, 2000). In spite of the 225

Integrating the Rational Uniﬁed Process and participatory design 5

fact that PD now has been on the systems development arena for over 30 years, 226 it still has not expanded to reach industrial development, neither to the develop- 227 ment of large-scale, complex and distributed systems (Tollmar, 2001). An expla- 228 nation for the latter is that the approach is only suited for small user groups in 229 limited parts of organisations, and thus, to the design of small-scale systems. 230 But neither small-scale PD projects have had any impact on industrial systems 231 development. Several scholars have, indeed, critically investigated their own ap- 232 proach and found it, in certain respects to be an academic construction, difficult 233 to put into industrial practice (Kensing, 2000). In conclusion, it is possible to say 234 that while RUP is based on a marked technocratic system view, PD represents 235 the opposite ideological and socio-technical perspective. Both these system 236 views have their advantages and drawbacks; combining them is one way to 237 bridge the gap between what is desired and what is feasible. 238 239 2.4 Study context PROOF 240 The development of the MOPT-Systems Development Process has taken place 241 in the context of developing command and control systems for the Swedish 242 Defense. In Sweden, a major reconstruction of the defence is currently taking 243 place, involving the introduction of a networked, flexible and dynamic struc- 244 ture, built on temporary configurations of the armed forces suited to the 245 particular mission. This, in its turn, has created a need for new and more 246 flexible systems supporting command and control. The systems are seen as 247 socio-technical, involving method (M), organisation (O), personnel (P) and 248 technology (T). The development of the MOPT-Systems Development Process 249 has received input from several projects developing control and command sys- 250 tems for the Swedish military ground forces and for the helicopter battalion. 251 The projects spin over a time from the late 1990s to currently. 252 253 3 Methods and perspective 254 The perspective taken in the study is, first, to present an overall integrative 255 approach for developing large socio-technical systems and, second, to suggest 256 a specific development process; the MOPT-Systems Development Process, us- 257 ing a modified version of the Rational Unified Process together with supporting 258 principles, methods and techniques from extended Participatory Design. In the 259 study context, socio-technical systems are systems where methodology, organi- 260 sation, personnel and technology are seen as closely interrelated and developed 261 in parallel.NCORRECTED The study is thus descriptive and includes a theoretical adjustment of 262 chosen aspects in RUP and PD into the integrative approach and process. 263 U 264 3.1 Theoretical adjustment of RUP and PD 265 The theoretical adjustment of RUP and PD is based on: 266 267 1. The participating researchers’ previous experience from PD and software 268 engineering projects. Of the researchers, two have solid experience from 269 managing PD projects and design groups, both for small-scale and 270

6 Design Studies Vol -- No. -- Month 2007

large-scale systems (Pilemalm, 2002). The third researcher has worked in 271 several industrial software engineering projects. 272 2. Literature studies of RUP and PD. 273 3. The collected experience from previous and current projects developing 274 command and control systems for the Swedish military ground forces 275 and helicopter battalion. In the ground forces projects, active user in- 276 volvement took place in the context of developing a system for geograph- 277 ically distributed command and control. In the helicopter battalion 278 project RUP and PD principles were explicitly combined in developing 279 a command and control system for the entire Swedish helicopter battal- 280 ion. Two of the researchers in the study, one with PD experience and 281 the one with industrial software engineering experience worked in some 282 of the ground forces projects and also accessed documentation from all 283 these projects in retrospect. As for the helicopter battalion project they 284 both acted as systems developers in the projectPROOF design group and initially 285 applied the MOPT-Systems Development Process. In this way, they were 286 able to gather their experience and continuously feed it back to the 287 process. 288 289 3.2 Documentation 290 The overall MOPT-Systems Development Process was constructed based on 291 the experience as described above, and documented in a report. As the 292 MOPT-Systems framework had been initiated before the helicopter battalion 293 project, the impressions of the two researchers participating in this project 294 were discussed after each project meeting, to create a common picture, and 295 used as input to modifying the process. As for this study, this regards, above 296 all, enterprise modeling, needs analysis and requirements engineering (the pro- 297 ject is still in progress). But also the process in its entirety has been continu- 298 ously updated to reflect new findings, thoughts and ideas. 299 300 4 Results 301 In this section, the results of the study are presented. First, the overall 302 approach is described on a theoretical level, displaying its major cornerstones 303 collected from RUP, the socio-technical systems view and PD and comparing 304 it to the others. Second, a more detailed description of the proposed MOPT- 305 Systems Development Process is provided including descriptions of the pro- 306 cess workflows,NCORRECTED the process in practice and some toolbox work tools. 307 308 4.1U Description of the overall MOPT-Systems approach 309 The MOPT-Systems approach is based, first, on modifications of chosen 310 aspects of RUP. This includes, above all, iteration in and between nine work- 311 flows. Further, the RUP Unified Modeling Language (UML) which has a de- 312 fined syntax, including, e.g., objects, relations and diagrams and further 313 includes mechanisms for extending syntax and notations (Cockburn, 2001) 314 is used to support the use case based modeling parts in the process 315

Integrating the Rational Uniﬁed Process and participatory design 7

(Oesterreich, 2002; Kruchten, 2004). In comparison to RUP, activities in the 316 workflows have, however, been extended in the sense that method, organisa- 317 tion, personnel, and technology are developed in parallel throughout the de- 318 velopment process; in order to reflect the socio-technical perspective. Some 319 workflows relate mostly to the system context, some mostly to the overall sys- 320 tem, and some to its MOPT sub-systems. The iteration and traceability be- 321 tween workflows is crucial, in order to facilitate verification, validation and 322 further development of the ensuing system. Further, the approach integrates 323 a subset of existing principles and techniques from PD. The approach taken 324 here is an extended version of PD where traditional techniques for user partic- 325 ipation such as, e.g., future workshops, scenarios and prototyping, have been 326 complemented with social research methods in order to reach a wider user 327 group. This is in line with recent attempts to develop PD to suit development 328 of large-scale systems and large, heterogeneous user groups (Pilemalm, 2002; 329 Oostveen and van den Besselar, 2004). ExamplesPROOF of social research methods 330 applied include, for instance, Critical incident technique questionnaires 331 (CIT) and the Critical decision method (CDM). CIT was originally an inter- 332 view technique used to recruit American Air Force pilots by investigating 333 how they would behave in critical situations (Flanagan, 1954). It has since 334 been used in a number of fields, including systems development (Dean, 335 1998). Here, CIT has been shown effective to capture breakdowns in work ac- 336 tivities and in the next step to identify solutions and remedies to the problems, 337 i.e., to identify user needs and system requirements. The CDM is an off-spring 338 from CIT and is a specific interview technique that aims to identify the process 339 for decision-making in critical, non-routine incidents taking place in dynamic 340 environments characterised by time pressure, high information content and 341 changing conditions (Klein et al., 1989). illustrates the different inputs to the 342 overall MOPT-Systems approach from the other approaches. 343 344 Similarly, Table 1 provides a comparison of the overall approach as related to 345 RUP and PD. It also functions as a summary of the ensuing suggested MOPT- 346 Systems process. 347 348 4.2 The MOPT-Systems Development Process 349 and its workflows 350 Based on the overall approach, a more formalised process is suggested and 351 substantiatedNCORRECTED as the MOPT-Systems Development Process. The process is 352 defined by nine workflows, to a certain extent reflecting the nine disciples in 353 RUP.U However, while RUP divides the disciples into technical and supportive 354 disciples, all the workflows in this case treat the Systems Development Process. 355 The supportive infrastructures that surround every systems development pro- 356 ject are treated separately as part of the practical application of the process. 357 The nine workflows of the MOPT-Systems Development Process are, thus, 358 contextual modeling, needs analysis, system requirements engineering, system 359 analysis and design, sub-system development and implementation, system 360

8 Design Studies Vol -- No. -- Month 2007

Table 1 The MOPT-Systems approach, as compared to the Rational Unified Process and participatory design 361 Rational Unified Process Participatory design MOPT-Systems approach 362 and process 363 364 Scope of systems Covers entire Covers only early phases Covers entire development process development process for in development process development process for 365 software engineering. for socio-technical socio-technical systems. 366 systems. 367 System target group Large software systems Small-scale Large socio-technical 368 in an enterprise. socio-technical systems systems in a wide system in an organization. context also embracing 369 surrounding environment. 370 Systems development Iteration in and between No defined disciplines or Iteration in and between 371 process nine disciplines in each workflows. Process is nine systems development project phase. Division of loose and context workflows in each project 372 technical and supportive dependant. phase. Supportive 373 disciplines. disciplines not included 374 PROOFbut part of the MOPT- Systems practical 375 application. 376 Focus of systems Software system in focus. Socio-technical; end-user Socio-technical; the 377 development process Subsequent focus on the and their real needs, enterprise/context and the 378 system requirements, system, and system to be developed technology and organizational context simultaneously. Models 379 architecture. No explicit in focus. context in which the 380 needs analysis. system will function. 381 Develops methodological, organizational and 382 personnel sub-systems 383 simultaneously to 384 technological sub-system (MOPT). Performs needs 385 analysis. 386 Enterprise/organization/ Relatively unproblematic Conflict view. Emphasizes Emphasizes needs for 387 context view and manager oriented the identification and change aspects; existing 388 view on enterprise. Do not resolving of existing problems and future explicitly emphasize needs conflicts and problems in changes in mind when 389 for organizational change. organization, especially modeling system context. 390 between managers and 391 workers/users. User participation Implicit assumption that End-users participate in End-users work actively in 392 system stakeholders can all aspects of design work, project group throughout 393 participate in parts of including planning and entire development 394 systems development decision-making about process. A trade-off of process; but no explicit work routines. work between users and 395 guidelines as how to Development takes place systems developers where 396 achieve activeNCORRECTEDin design groups. users provide information 397 involvement of users on context, user and 398 in entire process. system functionality needs U while systems developers 399 are responsible for, e.g., 400 project planning, 401 decision-making and documentation 402 and detailed design and 403 implementation. 404 (continued on next page) 405

Integrating the Rational Uniﬁed Process and participatory design 9

Table 1 (continued) 406 Rational Unified Process Participatory design MOPT-Systems approach 407 and process 408 Practical guidelines for Describes the general Has no specified process A suggested and specified 409 development process process framework and but provides a philosophy, systems development 410 include ‘‘how to do it’’ and a set of principles and process complemented 411 practical aspects. tools. with ‘‘how to do it’’ general guidelines. 412 Tools for data collection Provides examples of ways Toolbox existing of a Toolbox existing of a 413 to collect data for range of PD techniques. range of PD techniques 414 modeling the enterprise and social research and identifying methods for 415 requirements but few complementary data 416 explicit user-oriented tools collection from the user 417 and no tools for capturing groups and stakeholders 418 user needs. who are not represented in project group. 419 Tools for structuring Applies the UML Lacks coherent notationsPROOFApplies the UML 420 information notation language for or commonly agreed upon notation language for 421 modeling. modeling tools. modeling. 422 423 424 integration, system verification, deployment and system validation. One or 425 sometimes several project groups consisting of systems developers and user 426 representatives work together through all the workflows. The UML notation 427 is used for all modeling. 428 429 4.2.1 Contextual modeling 430 When developing socio-technical systems, understanding the context and 431 environment in with the system will be operative is crucial. In the MOPT- 432 Systems Development Process, contextual analysis takes place by contextual 433 modeling. The overall activity performed in this workflow is, thus, to develop 434 a model describing the organisational context in which the system will serve. 435 This is achieved by collecting data and using it as input when modeling the 436 context activities as use cases. The active role of the users is crucial in this 437 activity as they possess the domain knowledge. Information should be ex- 438 tracted both from the user representatives in the project group and from users, 439 domain experts and stakeholders external to the group. When modeling the 440 context the perspective is on the present as well as on the future. This implies 441 that also currentNCORRECTED difficulties, problems and needs for change should be explic- 442 itly captured, in-depth analyzed and incorporated into the modeling work. 443 Here,U methods and techniques for capturing change aspects, as for instance 444 Future workshops and the Critical incident technique can be used. 445 446 Workflow input: Data about current organisation, its immediate context and 447 surrounding environment. 448 Workflow output: Contextual model reflecting the future organisational con- 449 text and environment that the system should support. 450

10 Design Studies Vol -- No. -- Month 2007

Degree of active user participation: High. 451 452 4.2.2 Needs analysis 453 While RUP proceeds directly from Business Modeling to Requirements and 454 only briefly treats needs as stakeholder requests (Kruchten, 2004), the 455 MOPT-Systems Development Process, introduces the intermediate workflow 456 of needs analysis. This is done in order to capture the context’s and users’ 457 true needs of the system, and to avoid a too early focus on solutions and fixed 458 requirements. Many of the needs can be identified directly by the system 459 developers using the contextual model. Further, reflecting over the model in 460 a project group can help the users participating in the group to identify new 461 needs. In the latter case, the contextual model becomes an initial prototype 462 wherefrom needs are identified, distilled, refined and concretised. Additional 463 needs are captured using social research methods and PD techniques (see Sec- 464 tion 4.5). The established needs are further analyzed,PROOF structured, prioritised 465 and documented in a database with traceability to their sources and preceding 466 statements (see Section 4.5). 467 468 Workflow input: Contextual model, social research methods and PD 469 techniques. 470 Workflow output: A document specifying the system context and its users’ 471 needs and their priorities; a needs description. 472 Degree of user participation: High. 473 474 4.2.3 System requirements engineering 475 The workflow handles requirements on the ensuing system. The overall activ- 476 ity performed is much similar to the requirements handling in RUP, but with 477 a great amount of requirements extracted directly from the needs specification. 478 Additional requirements are collected in order to complement and fill in miss- 479 ing requirements or those requirements that are not explicitly preceded by 480 a need. The identified requirements are analyzed, structured, prioritised and 481 documented in a database with traceability to needs or statements. The project 482 group and other user representatives play a continuous important role in iden- 483 tifying and prioritising requirements. A low-fi prototype should be developed 484 at this stage and used to support the users in evaluating the requirements. In 485 the requirements documentation, categories and sub-categories of require- 486 ments areNCORRECTED displayed hierarchically in order to facilitate overview and, to see 487 if some category is missing or weakly represented, i.e., whether iteration is 488 needed.U 489 490 Workflow input: Needs specification, organisational governing documents, 491 IT-security and usability expertise. 492 Workflow output: A model specifying the external view of the ensuing system 493 displayed as system use cases, a requirements specification and a prototype. 494 Degree of user participation: High 495

Integrating the Rational Uniﬁed Process and participatory design 11

4.2.4 System analysis and design 496 497 The workflow handles overarching design of the system. The overall activity 498 performed is to determine the system architecture, design principles, and deci- 499 sions. A core activity in this workflow is to determining which requirements 500 are of interest for the sub-systems development, i.e., M, O, P, T. The workflow 501 also re-uses the system use cases to identify a set of objects. The objects are 502 subsequently defined into classes, using UML class diagrams. The project 503 group and user representatives are somewhat less involved in this workflow, 504 since much of the work requires modeling, systems architecture and design 505 skills. Still end-users are, as compared to RUP, much more involved in the de- 506 sign process, mainly by means of iterative prototyping. Prototypes at this stage 507 are often broad with rather low functionality, focusing on and testing different 508 design and architectural solutions. 509 PROOF 510 Workflow input: Requirements specification. 511 Workflow output: A model describing the internal view of the system and its 512 objects and classes, prototypes and an overall design description. 513 Degree of user participation: Medium. 514 4.2.5 Sub-systems development and implementation 515 Because of the socio-technical perspective, a crucial aspect of the MOPT- 516 Systems Development Process is the sub-system development. While RUP 517 has its overall focus on the software system, the current process continues to 518 consider method, organisation and personnel in parallel to technology. The 519 overall activity performed in this workflow is thus to develop and implement 520 the MOPT sub-systems as part of the overall system. Data collection, analysis, 521 design, implementation and verification are subsequently performed for each 522 sub-system. The concrete content of these steps look different depending on 523 what sub-system is being developed. For instance, implementation of technol- 524 ogy implies coding and testing while in the case of method it means to structure 525 and document new methods in a textual format. Also, even though the Figure 3 526 may give the impression of sequential development performed by different in- 527 dividuals; in reality activities are executed in parallel, jumps between activities 528 take place, input from one sub-system may provide input to another, several 529 individuals partake in the development of several sub-systems, several project 530 groups may be formed and so on. A certain degree of parallelism is even 531 a must, inNCORRECTED order to achieve reasonable sub-system coherency. The project 532 group and user representatives play an important part in the M, O, and P 533 sub-systemsU while development of pure technology is more of an issue for 534 system developers and technicians. The outcome of the activity is MOPT 535 sub-systems with specific deliverables for each sub-system: 536 537 Workflow input: Data from previous work (e.g. needs specification, require- 538 ments specification), complementary data from users. 539 Workflow output: A number of deliverables for each sub-system. 540

12 Design Studies Vol -- No. -- Month 2007

Method deliverables: Sub-system use-case model, analysis model, requirements 541 specification, document providing structured work methods and how they are 542 to be deployed in organisation and integrated with system. Activity diagrams. 543 Organisation deliverables: Sub-system use-case model, analysis model, 544 requirements specification, document providing future organisational struc- 545 ture and how it is to be deployed in organisation and integrated with system. 546 Class diagrams. 547 Personnel deliverables: Sub-system use-case model, analysis model, require- 548 ments specification, competence plans, training directives and material. Class 549 diagrams, roles connected to position, description of competences. 550 Technology deliverables: Sub-system use-case model, analysis model, require- 551 ments specification, design description, software, and test reports. Realisation 552 diagrams. 553 User participation: High. 554 PROOF 555 4.2.6 Systems integration 556 The workflow deals with the integration of the MOPT sub-systems. As com- 557 pared to RUP, where integration is seen as part of the implementation workflow 558 and where system components from individual implementers or teams are inte- 559 grated, integration here has its own workflow. The overall activities performed 560 are to successively and incrementally integrate the MOPT sub-systems to an en- 561 tire, functioning socio-technical system, to plan and perform tests. This implies, 562 in practice to solve those problems and conflicts that have not already been 563 solved during sub-system development. For instance, technology may be mod- 564 ified and configured to support new work routines or, the other way round, 565 some methods may be abandoned since they do not fit in with fundamental tech- 566 nological requirements. Prototypes of the system are developed and succes- 567 sively added with more functionality and components before deciding on the 568 final system solution, and hence, users play an important part in evaluating dif- 569 ferent versions of the system. It should be noted that for large-scale systems (as 570 emphasised also in RUP), it is most often better to perform development incre- 571 mentally, i.e., to develop several sub-systems and components that are succes- 572 sively added and integrated, rather than to aim at a total solution from the 573 very beginning. The project group and user representatives are also needed 574 when prioritisation of contradicting sub-system issues must take place. 575 576 WorkflowNCORRECTED input: The MOPT sub-system and possible other sub-systems and 577 components. 578 WorkflowU output: Socio-technical system and test models results. 579 Degree of user participation: Medium. 580 581 4.2.7 System verification 582 The workflow aims at verifying the socio-technical system before it is deployed 583 into the enterprise. While RUP uses the test discipline for covering both veri- 584 fication and validation the MOPT-Systems Development Process 585

Integrating the Rational Uniﬁed Process and participatory design 13

586 587 Environment 588 589 590 591 592 Context Enterprise Needs Deployment System 593 modeling analysis validation 594 595 596 System System Systems System requirements analysis and integration verification Socio-technical engineering design 597 System 598 PROOF 599 Sub-systems 600 Socio-technical Sub- development systems 601 602 603 604 Technology Data collection Analysis Design Implementation Verification 605 606 Organization Data collection Analysis Design Implementation Verification 607 608 609 Personnel Data collection Analysis Design Implementation Verification 610 611

Methods Data collection Analysis Design Implementation Verification 612 613 Figure 3 The nine workflows of the MOPT-Systems Development Process. Iteration takes place as needed in the current project context. Pos- 614 sible iterations are exemplified with a point of departure in plausible decision points 615 616 617 distinguishes between the two in order to reflect the previously made distinc- 618 tion between needs and requirements. The overall activity performed in the 619 verification workflow is to verify that the system fulfils its requirements consid- 620 ering technology as well as organisation, method and personnel. More con- 621 cretely, theNCORRECTED requirements substantiated in the system are compared with 622 those (prioritised) requirements in the requirements specifications. If there 623 are contradictions,U it must be decided whether this is a result of acceptable 624 modifications made during system integration or if the system must be ex- 625 tended or modified. End-users play a less prominent part in the verification 626 workflow but the project group should be provided with feedback. A verifica- 627 tion model and report provides the basis for a decision point, i.e., a decision 628 whether the system is correctly built (fulfils the system requirements) or if 629 more iteration is needed. 630

14 Design Studies Vol -- No. -- Month 2007

Workflow input: Requirements specifications both for entire system and for 631 the MOPT sub-systems. 632 Workflow output: Socio-technical system, a system verification model and 633 report. 634 Degree of user participation: Low. 635 636 637 4.2.8 Deployment 638 The aim of the workflow is to deploy a functioning socio-technical system into 639 the enterprise. The major activity performed is thus to install the system and, if 640 necessary, carry out modifications to make it work. All the MOPT sub-systems 641 have to be deployed; deployment thus implying different things for each sub- 642 system. As for technology, software and hardware are installed, or software 643 integrated with existing hardware. Further, additional tests are performed test- 644 ing the system against pre-defined criteria concerning,PROOF e.g., speed, capability 645 and robustness. As for methodology and organisation, new methods and 646 work routines are anchored in the enterprise, through the personnel responsi- 647 ble to carry out required changes. As for personnel, the end-users are trained in 648 the system and in other needed competences as identified in the current sub- 649 system. This workflow, thus, has the entire ‘‘real-life’’ enterprise end-user 650 group in focus. 651 652 Workflow input: Socio-technical system. 653 Workflow output: Deployment reports including problems, solutions and 654 experience, and the enterprise managed by the new socio-technical system. 655 Degree of user participation: High. 656 657 658 4.2.9 System validation 659 The MOPT-Systems Development Process includes system validation as the 660 last workflow. The activity performed is to validate if the system actually fulfils 661 the needs of the users. The major input to workflow comes from the needs 662 analysis workflow as well as from the actual experience from the system in 663 practice, i.e., the experience of the end-users. The latter is captured by inter- 664 views, observations of how end-users use, interact with and acknowledge the 665 system, and by simply talking to the users. The ‘‘real-life’’ enterprise end- 666 user groupNCORRECTED is thus in focus. During the workflow, new needs may be identified 667 or those previously identified modified to update the system or to be used in 668 a newU release of the system. A validation report provides the basis for a deci- 669 sion point, i.e., a decision of whether the system fulfils the needs of the enter- 670 prise and its users or if more iteration is needed. 671 672 Workflow input: Needs specification and experience of system in real use. 673 Workflow output: Socio-technical system and a validation report. 674 Degree of user participation: High. 675

Integrating the Rational Uniﬁed Process and participatory design 15

Figure 3 visualises the MOPT-Systems Development Process. In the process, 676 context is the immediate system context, most often denoted as organisational 677 context. System is the socio-technical system, in itself embracing those parts of 678 the organisation that are directly affected by the system, with related methods 679 and personnel aspects. Environment is external to the immediate context but 680 may still have an influence on the system through different actors and interests. 681 Further, it should be noted that even though the workflows are described in 682 sequence and may denote a topedown hierarchical process, this is not the 683 case in reality. Iteration is a crucial aspect of the process and several workflows 684 are supposed to be executed in parallel and switched between, providing input 685 to each other and partly involving the same individuals. As an example, new 686 needs and requirements may be established during the evaluation of proto- 687 types, implying that not only the needs analysis and requirements engineering 688 workflows needs to be iterated, but also that the contextual model has to be 689 updated, reflecting new work routines. In line withPROOF iteration and as compared 690 to RUP, no explicit project phases are described in the process. This decision is 691 deliberate, reflecting recent critique on RUP as in reality copying waterfall-like 692 models and having a monolithic view on the development process (Hesse, 693 2003). In the current process, the workflows instead evolve around manage- 694 ment of the different decomposed units and sub-systems that are present in 695 large, complex systems. 696 697 4.3 The MOPT-Systems Development Process in practice 698 In the above descriptions, the roles and participation of the users were briefly 699 described in relation to each workflow. The MOPT-Systems Development 700 Process further suggests a practically oriented framework that provides a num- 701 ber of general, concrete guidelines for how the process can be applied in real 702 systems development projects. The concretisation elaborates on project orga- 703 nisation, including the aspects of how active user participation and the added 704 extended PD aspects work in practice. The framework further includes a tool- 705 box of PD techniques and social research methods to support concrete 706 development work. 707 708 4.4 Project organisation 709 According to RUP, teams of individuals work together during the software 710 engineering process. In the teams individuals acquire certain roles such as, 711 e.g., systemNCORRECTED analysts, business designers and requirements engineers. The asso- 712 ciation between a role and an individual is not fixed; several individuals can 713 acquireU the same role and vice versa. Neither are the teams as such stable as 714 different roles are executed during different phases of the development process 715 (Kruchten, 2004). The role of the user is not explicitly handled in RUP even if 716 it is possible that, for instance, one or several of the context analysts are user 717 representatives from the current enterprise acting as domain experts. PD, on 718 the other hand, assumes that user representatives actively partake in the entire 719 development process and even dominate a design group. In the current 720

16 Design Studies Vol -- No. -- Month 2007

process, a project group is formed, consisting of system developers and user 721 representatives. Several of the roles in RUP are re-used and responsibilities di- 722 vided between them. But the process also adds the explicit role of user repre- 723 sentative, where a project group should involve of at least two to three user 724 representatives for each system developer. The established group then works 725 together through the entire MOPT-Systems Development Process (in an ideal 726 case, pre-cautions to handle eventual participant turnovers must always be 727 taken; Pilemalm, 2002). 728 729 However, designing large-scale systems using a PD perspective involves certain 730 difficulties as to reach the entire user group. It has also been demonstrated that 731 full user participation in all aspects of the development process neither is effi- 732 cient nor in agreement with user satisfaction (Doll and Deng, 1999). In recent 733 attempts to extend the PD approach, parts of the development work has there- 734 fore taken place outside the immediate design groupPROOF with data collection from 735 different user groups applying social research methods (Pilemalm, 2002; 736 Oostveen and van den Besselar, 2004). In the MOPT-Systems Development 737 Process, there is a division of work between development taking place in 738 and external to the project group. The project group is kept permanent to 739 the extent possible. A number of systems developers (depending on project 740 context) manage and coordinate the work of the group throughout the devel- 741 opment process. These persons can, for instance, have the role of context an- 742 alysts or system analysts. 743 744 Work of the user dominated project group includes, e.g., analyzing the con- 745 text, identifying system stakeholders, identifying and prioritising needs and 746 system requirements, performing design practices and evaluation of proto- 747 types, and providing general feedback on all results produced in the systems 748 development process. The work where the project group user representatives 749 are less involved includes data collection from identified important additional 750 user groups and stakeholders using various social research methods. However, 751 the gained results are always fed back to the entire project group. The data col- 752 lected external to the group have two functions; first to verify the findings of 753 the group against a larger data material (e.g. by questionnaires sent to many 754 respondents); and second, to collect the voices of those users and stakeholders 755 that are not directly represented in the project group. Through this combina- 756 tion, entireNCORRECTED organisations can partake in designing large-scale systems while 757 the project group is always present providing feedback. Other activities in 758 the developmentU process which are less of candidates for user participation 759 include e.g., administrative and documentation work in project group (partici- 760 pating system developers responsible), detailed modeling (analysts responsi- 761 ble), detailed needs and requirements engineering including management of 762 requirements in a database (requirements engineers responsible), detailed de- 763 sign (designers responsible) building system architecture (system architects re- 764 sponsible), integration (implementers responsible) and so on. This implies 765

Integrating the Rational Uniﬁed Process and participatory design 17

that, in above all the later phases of the development process, individuals pos- 766 sessing these roles must, besides from performing this work outside the project 767 group, also act as guest players in the group presenting their results (for in- 768 stance a prototype), and receive the necessary feedback from the user represen- 769 tatives. In this way, the project group can be kept reasonable stable while 770 interaction between internal and external development work remains. The 771 users still have the opportunity to influence important issues in the develop- 772 ment process, even though to a different extent in different workflows. Also, 773 in large project contexts, it may be necessary to form several project groups, 774 from the very beginning or as the process grows more complex (but at least 775 one group needs to follow the entire development process), to put a reasonable 776 load of work on the group members and to expand on the direct involvement 777 of end-users. This, of course, involves additional tasks for the systems devel- 778 opers as to coordinate and integrate the results of the different groups. In con- 779 clusion, the MOPT-Systems process thus adheresPROOF to the principle of active user 780 participation throughout the workflows, but not necessarily to full user partic- 781 ipation in ALL aspects of this work. 782 783 4.5 The toolbox 784 The toolbox consists of RUP tools, PD techniques and social research 785 methods. The reason for including social research methods is that the PD pro- 786 ject group, when designing large-scale systems, is too small to adequately rep- 787 resent all user groups and stakeholders. Likewise, the RUP notion of 788 enterprise has a wider connotation here and is to be seen as the entire system 789 context. In the following section, the usage of some toolbox tools, techniques 790 and research methods is exemplified and motivations of why they where cho- 791 sen provided. This, of course, does not elude other methods or techniques. The 792 specific combination is dependent upon the prerequisites for each project. 793 794 4.5.1 RUP tools 795 The RUP tools included in the toolbox are the The Unified Modeling Language 796 notation and the Rational Rose support tool. 797 798 The Unified Modeling Language (UML): In the MOPT-Systems Development 799 Process UML is used in modeling use cases and models. As for the latter, the 800 process applies context models, system models, sub-system use-case models, 801 test modelsNCORRECTED and verification models. The UML was chosen in order to provide 802 notations that support structure of data and process, in order to arrive at a for- 803 malisedU development process. 804 805 Rational Rose: Rational Rose is a commercial software development support 806 tool aimed to sustain RUP (RUP Version 2003.06.00.). It supports the UML 807 modeling and further provides, for instance, automatic document generation 808 and a database (Requisit Pro) where statements, needs and requirements can 809 be stored and traced to each other. The MOPT-Systems Development Process 810

18 Design Studies Vol -- No. -- Month 2007

applies Rational Rose in the above respects, to bring structure and overview to 811 the process. 812 813 814 4.5.2 Social research methods 815 The social research methods included in the toolbox are a number of tradi- 816 tional qualitative data collection methods, for instance questionnaires and 817 interviews. 818 819 In the field of systems development, questionnaires can be used to acquire in- 820 formation on users’ work situation and tasks and thereby pinpointing their 821 needs and system requirements. In the MOPT-Systems Development Process 822 different types of questionnaires are applied for different purposes and some- 823 times in combination with prototyping. In the main, the questionnaires have 824 open-ended questions (Taylor and Bogdan, 1998PROOF) seeking out users current 825 work situations, problems, needs, and experiences from practically working 826 with the system under development. One example is the Critical incident tech- 827 nique (CIT) which is applied in the project group to capture the users’ expe- 828 rienced problems in the context and work situation, and to work out 829 solutions to these problems. Solutions may be of an M, O, P or T nature. Fur- 830 ther, CIT questionnaires are sent to additional user representatives and stake- 831 holders external to the project group. CIT has in previous projects shown to be 832 extremely useful for providing rich descriptions of users’ present situation, 833 needs and requirements, and can also be used to reach a large number of 834 respondents from where general patterns can be extracted. 835 836 In systems development interviews are suitable for reaching the perspective of 837 important individual actors and stakeholders in a system. In the MOPT- 838 Systems Development Process, interviews are applied for collecting organisa- 839 tional knowledge, needs and requirements from users and stakeholders not 840 represented in the project group. For instance, it might be necessary to inter- 841 view those people who are to administrate or finance the system. Interviews are 842 also used for evaluation of the system, often in combination with prototypes. 843 They are, most often, of a semi-structure character where theme questions are 844 formed to guide the seeking for needs and requirements, as well as for identi- 845 fying constraints on and subjective experiences of the system (Taylor and 846 Bogdan, 1998NCORRECTED). In specific, The Critical decision method (CDM) is applied 847 when decision-making and command aspects are crucial. The method has 848 shownU effective when the system is to provide decision-support for non-routine 849 incidents (Klein et al., 1989). 850 851 852 4.5.3 Participatory design techniques 853 Examples of explicit design techniques with a high degree of user participation 854 include Future workshops, prototyping and scenarios. 855

Integrating the Rational Uniﬁed Process and participatory design 19

In the MOPT-Systems Development Process, Future workshops (FW) are 856 applied in the project group, sometimes in combination with the previously 857 established contextual model (which then serves as a trigger for the critique 858 phase). Future workshops are also held with other user groups, both to com- 859 plement and corroborate the findings of the project group. Future workshops 860 have in previous projects been easy for the users to comprehend and successful 861 in starting out with their everyday reality and successively forming needs and 862 requirements. 863 864 RUP only briefly describes prototyping as a way of reducing risks and uncer- 865 tainties regarding the system. It does not clearly integrate their belonging in 866 the development process (Kruchten, 2004). The MOPT-Systems Development 867 Process, on the other hand, makes extensive use of prototyping and includes 868 the construction of prototypes from the needs analysis and system requirement 869 workflows and forward on. Prototypes are evaluatedPROOF both in the project group 870 and by other users and stakeholders, with the aims of finding needs, require- 871 ments and identifying suitable design solutions. Prototypes are included to 872 complement the abstract UML models with concrete hands-on experience. 873 Previous project experience has shown that the possibility to work with con- 874 crete tools, yields not only rich information results but also enhances user sat- 875 isfaction in a group. 876 877 In the MOPT-Systems Development Process, scenarios are constructed using 878 the context model as input. The scenarios are used for condensing and concre- 879 tising the model and thereby triggering the identification of needs and require- 880 ments in the project group. They are also used together with prototypes and 881 for evaluation and validation purposes. The motivation for including scenar- 882 ios in the toolbox is that they are useful triggers for needs and requirements 883 and further support working with the somewhat abstract context model in 884 a more concretised manner, more graspable for the users. 885 886 5 Discussion 887 The approach presented in this study was developed in response to a perceived 888 need to combine the benefits of a socio-technical system perspective using an 889 extended version of PD together with a more structured systems development 890 process based on a subset of RUP principles and covering also technical 891 aspects. TheNCORRECTED major modifications of RUP included, for example, a change 892 of name for some terms, introducing the MOPT sub-systems and letting the 893 nine workflowsU all relate to the systems development process rather than to 894 treat some as supportive disciplines. The latter was felt necessary in order to 895 elaborate and add to the development process, above all when introducing 896 the needs analysis and system validation workflows. This does not imply 897 that the supportive aspects are neglected but rather that they belong to the 898 practical guidelines for applying the MOPT-Systems Development Process. 899 As for the introduced needs analysis and corresponding validation against 900

20 Design Studies Vol -- No. -- Month 2007

needs, it was felt important that these workflows receive emphasis in the pro- 901 cess, in order to capture users’ real everyday problems and needs. The differ- 902 ence between a need and a requirement is sometimes subtle but in other cases 903 substantial. Focusing on requirements at too early a stage leads to a risk of 904 thinking in terms of existing technological and organisational constraints as 905 well as suggesting advanced technological solutions, rather than grasping 906 what is really needed. Further, needs are often more easily acknowledged by 907 the users than are requirements, since they relate to their every day context, 908 rather than to an abstract system. The introduction of a needs analysis thus 909 improves the prospects for active user participation. As for the MOPT sub- 910 systems, introducing them is the largest modification to RUP and an extension 911 deemed as absolutely necessary to arrive at socio-technical systems usable and 912 well-functioning in their context. 913 914 In the study, it is not argued that RUP completelyPROOF eludes aspects of involving 915 the end-users and the organisation surrounding the system. However, RUP 916 (RUP, Version 2003.00.06) provides merely a general framework in which 917 these aspects are acknowledged as possible, but are not emphasised. In other 918 words, the approach tells what can be done rather than how to do it. Explicit 919 participatory design techniques are not mentioned. Also, later RUP versions 920 briefly mention change aspects when modelling the enterprise but this seems 921 to relate to officially acknowledged changes put forward by management 922 rather than to true change needs. PD, on the other hand, provides concrete 923 tools that guide active user participation in a development process aimed at 924 changing and improving organisation and work routines as well as technology. 925 On the other hand, also PD has it drawbacks when it comes to structure, 926 formalisation, technology and end-product. In conclusion, the RUP inspired 927 formalisation of the MOPT-Systems Development Process, leads to that the 928 risk of focusing to extensively on early development (a risk that is indeed sub- 929 stantial in ‘‘non-pd’’ projects as well) is avoided. The process adheres to the 930 principle that the work focusing on technology (implementation, integration, 931 deployment, etc) should receive about two thirds of the total time and 932 resources in a systems development project. The remaining time, if used effi- 933 ciently and in a structured and planned manner, should suffice to include 934 a solid context analysis, performing needs analysis and requirements 935 engineering. 936 NCORRECTED 937 5.1 Practical experience 938 So far,U the three first workflows of the MOPT-Systems Development Process, 939 context analysis, needs analysis, and system requirements engineering have been 940 practically applied. This in the helicopter battalion project aimed at develop- 941 ing a command and control system for the entire Swedish helicopter battalion. 942 Work has taken place in a project group, consisting of systems developers and 943 user representatives from command personnel to helicopter crew. The users, 944 from the outset, have played an active role in the development process; by 945

Integrating the Rational Uniﬁed Process and participatory design 21

(1) participating in the modeling of the context and system, i.e., the helicopter 946 battalion with a special focus on command and control issues, (2) identifying 947 the needs of the battalion, with a point of departure of the emerging contextual 948 model, and by performing the critical incident technique, Future workshops, 949 and scenarios for capturing needs and requirements, and (3) identifying corre- 950 sponding and additional requirements on the system. The experience is that 951 the major bulk of the work when describing the context could be performed 952 within project group meetings, much of the modeling being performed in 953 real time. The group made use of the user participants’ knowledge and of doc- 954 uments describing, above all, the command and control process. However, 955 some activities where not covered by the experience of the group, neither by 956 the literature. An example is international missions, an activity which is 957 deemed to become crucial in the future Swedish defence. Here, the systems 958 developers had to seek additional data by performing both interviews with 959 experts and by letting experts participate in the modelingPROOF of international mis- 960 sions at a separate meeting. Also, the user representatives in the project group, 961 at the outset, deemed the context model as somewhat abstract and incompre- 962 hensible. This was solved by adding comprised textual explanations to all 963 models. The produced context model reflected the helicopter battalion as it 964 will basically look like in ten years. In this specific case modeling the future 965 was not considered a difficulty, as quite clear guidelines for how the battalion 966 will develop (for instance trough the purchase of attack helicopters) exist. 967 However, additional new directives for the battalion have arrived recently, re- 968 quiring an iteration of the context modeling workflow. 969 970 Performing the needs analysis included more of a trade-off between systems 971 developers and user representatives. Needs were identified partly by the sys- 972 tems developers directly from the context model, and partly at project meet- 973 ings. In the latter case, the most relevant use cases in the model were gone 974 through in detail, and related to what needs occur when performing a certain 975 activity or task. Further, additional needs were identified in the group by car- 976 rying out the mentioned PD techniques. An experience made is that the con- 977 text model is useful for capturing user needs, but that the needs that are 978 identified from the model needs to be further penetrated, detailed, explained 979 and concretised, in order to move the systems development process forwards. 980 Otherwise, there is a risk that the needs analysis simply copies what has already 981 been foundNCORRECTED during the context modeling. The needs analysis workflow is cur- 982 rently iterated, due to the new directives. 983 U 984 As for performing requirements engineering, the experience is that initial work 985 was somewhat slow and cumbersome as the user participants had to ‘‘learn’’ 986 the fundamentals; the basic ‘‘thinking’’ and concepts of requirements engineer- 987 ing. This took longer time than expected, partly because a few user represen- 988 tatives had left and others entered the group as newcomers (the problem with 989 user-turnover has much to with the present status of the Swedish defence 990

22 Design Studies Vol -- No. -- Month 2007

receiving less financial support from the state resulting in cut-downs, layoffs 991 and replacements). However, it is, in retrospect, believed that this initial delay 992 was worth the effort, since the following activities of identifying and filtering 993 the ‘‘true’’ requirements, for instance from the multitude of densely populated 994 governing requirements documents produced by the Swedish defence, went 995 much smoother and would not have been possible with out the domain knowl- 996 edge of the users. 997 998 999 In all workflows, there was common agreement among the users that they did 1000 not have the time to involve themselves immensely in administration, docu- 1001 mentation or other ‘‘homeworks’’. In other words, full user participation 1002 was regarded as dysfunctional and they wanted to focus on the domain knowl- 1003 edge they could provide and on needs and requirements generation. 1004 PROOF 1005 It might be argued that the merging of two systems developments approaches 1006 is demanding in time and in resources. Practical experience from applying the 1007 merge has, thus far, worked smoothly with having a rather small project group 1008 and by having two systems developers perform the work and data collection 1009 between and external to project meetings. A few additional system engineers 1010 have now started to work with the project group as for the subsequent 1011 work. It is likely that more systems development resources are required in later 1012 phases, maybe even requiring additional project groups. On the other hand, 1013 building large technical systems must be ensued to take time and resources 1014 and the PD extensions of RUP will hopefully, in the end, lead to that user 1015 and organisational needs for change are truly captured, thereby resulting in us- 1016 able systems and in less costly and time taking re-buildings. In this respect, also 1017 introducing the workflow of needs analysis is supposed to contribute, as a way 1018 of identifying what users and organisations really need, in contrast to them 1019 telling what they think they need and proceeding directly to requirements. 1020 1021 5.2 Context, limitations and future research 1022 The MOPT-Systems Development Process is aimed at creating an effective 1023 trade-off between users, stakeholders and systems developers, and at deliver- 1024 ing an end-product, while not losing the needs for change in organisations, nei- 1025 ther the general benefits of active user participation. The process embraces 1026 socio-technicalNCORRECTED systems of large-scale in specific. This is, for instance, reflected 1027 in the division of work inside and external to the project group reaching het- 1028 erogeneousU user groups and different organisational layers in the data collec- 1029 tion, and by acknowledging the possibility of forming several project groups, 1030 either from the beginning of or after some time in the development process. 1031 The process is thereby in line with contemporary trends of increasingly large, 1032 distributed, complex and technically sophisticated systems, involving a multi- 1033 tude of people. In specific, it contributes to adapt PD to this continuous 1034 growth. However, the process may as well be applied in projects of smaller 1035

Integrating the Rational Uniﬁed Process and participatory design 23

scale with more homogeneous users e such a context would probably even 1036 make the execution of the process smoother. 1037 1038 Finally, it should be noted that even though the MOPT-Systems Development 1039 Process in many aspect is a novel process, it is not to be seen as entirely 1040 pioneering work breaking new ground. The importance of combining socio- 1041 technical aspects and the end-users with more rigorous and complete processes 1042 for developing organisational yet technically complex and solid systems has 1043 been on the agenda for quite some time. The process described should instead 1044 be seen as a suggested overall approach and a process that is coherent and still 1045 flexible enough to be practically feasible. Thus, far it is only the three first 1046 workflows of the process that have been tested and no formal evaluation 1047 has taken place. Future research should test the MOPT-Systems Development 1048 Process in its entirety in a concrete systems development project. In the heli- 1049 copter project, prototyping and scenario-basedPROOF evaluations with the users 1050 will be applied in subsequent design. In some ensuing workflows, e.g., system 1051 integration and verification, users in the project group will probably play a less 1052 prominent role but will still be present through their continuous feedback on 1053 the emerging system. In other workflows, e.g., sub-systems development, sys- 1054 tem deployment and validation, users, in and outside the project group(s), 1055 again take an active stance by evaluating and proposing modifications to 1056 the system. Important issues to be considered in the further development of 1057 the process include how to balance user participation and the need for soft- 1058 ware engineering skills in the subsequent workflows, how to further develop 1059 the project management aspects, how to really achieve iteration in and be- 1060 tween work flows, and how to coordinate the work of several project groups 1061 and the development of sub-systems in very large projects. In relation to 1062 this, the process needs to be further developed in respect with how to merge 1063 the data collection, analysis, design, implementation and verification per- 1064 formed for each MOPT sub-system with those performed for the overall 1065 system. 1066 1067 6 Conclusion 1068 In the contemporary field of systems development there is an ever growing 1069 awareness about the need to involve users in the development process as 1070 well as about the importance of developing organisation, people, work rou- 1071 tines andNCORRECTED methods simultaneously as the technical system. Still, industrial 1072 development of information systems are still, to a great extent, performed 1073 by softwareU intensive approaches focusing on the technology infrastructure 1074 and less on the end-users’ true needs. This study is one attempt to bridge 1075 the gap between ideology and reality. The MOPT-Systems Development Pro- 1076 cess integrates the formalised, all workflows inclusive development process of 1077 RUP, though in a modified version; with socio-technical aspects of developing 1078 method, organisation and personnel hand in hand, together with the end-users 1079 and accompanied with PD techniques, as well as with a solid data collection 1080

24 Design Studies Vol -- No. -- Month 2007

from the current system context. The expected output is a technically solid 1081 end-product that functions well for the organisation and is appreciated by 1082 its users. Thus, far, parts of the process have been applied when developing 1083 command and control systems for the Swedish defence; however, the process 1084 is supposed to have general applicability for developing information systems, 1085 in particular large-scale systems. Future research should test the MOPT- 1086 Systems Development Process in entire systems development projects, cover- 1087 ing the process from initial organisational analysis to system deployment 1088 and validation. 1089 1090 1091 References 1092 Asaro, P M (2000) Transforming society by transforming technology: the science 1093 and politics of participatory design Accounting, Management and Information 1094 Technology Vol 10 pp 257e290 PROOF 1095 Avison, D E and Fitzgerald, G (1995) Information systems development: methodol- ogies, techniques and tools The McGraw-Hill Companies 1096 Bravo, E (1993) The hazards of leaving out the users in D Schuler and A Namioka 1097 (eds) Participatory design. Principles and practices Lawrence Erlbaum, Hillsdale, 1098 NJ pp 3e11 1099 Carroll, J M (2000) Making use Scenario-based design of human-computer inter- 1100 actions Massachusetts Institute of Technology, MA Cockburn, A (2001) Writing effective use cases Addison-Wesley 1101 Constantine, L L and Lockwood, L A D (1999) Software for use: a practical guide 1102 to the models and methods of usage-centered design Addison-Wesley, Reading, MA 1103 Constantine, LL and Lockwood, LAD (2002) Usage-centered engineering for web 1104 applications IEEE Software March/April 1105 Dean, P J (1998) A qualitative method of assessment and analysis for changing 1106 the organizational culture Performance Improvement Vol 37 No 2 pp 14e23 Doll, WJ and Deng, X (1999) Should end-users participate as much as they want in 1107 the development of collaborative applications? in Proceedings of the 32nd Hawaii 1108 International Conference on System Sciences 1109 Ehn, P (1993) Scandinavian design: on participation and skill in D Schuler and 1110 A Namioka (eds) Participatory design. Principles and practices Lawrence 1111 Erlbaum, Hillsdale, NJ pp 41e77 Ehn P, Davies, RC, Brattga˚rd, B, Ha¨gerfors, A, Nilson, J, Dalholm, E and Mitch- 1112 ell, B (1996) The envisionment workshop e from visions to practice, in Proceed- 1113 ings of the Participatory Design Conference CPSR, Palo Alto, CA pp 141e152 1114 Flanagan, J C (1954) The critical incident technique Mental Bulletin Vol 51 1115 e pp 327 358 1116 Gulliksen, J, Go¨ransson, B, Boivie, I, Blomkvist, S, Persson, J and Cajander, A˚ NCORRECTED 1117 (2003) Key principles for user-centred systems design Behaviour and Information Technology Vol 22 No 6 pp 397e410 1118 Hesse,U W (2003) Dinosaur meets archaeopteryx? or: is there an alternative for Ra- 1119 tional’s Uniﬁed Process? Software and Systems Modeling Vol 2 No 4 pp 240e247 1120 Hull, M E C, Taylor, P S, Hanna, J R P and Millar, R J (2001) Software devel- 1121 e opment processes an assessment Information and Software Technology Vol 44 1122 pp 1e12 Kensing, F. (2000) Participatory design in a commercial context e a conceptual 1123 framework, Proceedings of the Participatory Design Conference CPSR, Pao 1124 Alto, CA pp 116e126 1125

Integrating the Rational Uniﬁed Process and participatory design 25

Kensing, F and Halskov Madsen, K (1991) Generating visions: future workshops 1126 and metaphorical design in J Greenbaum and M Kyng (eds) Design at work Law- 1127 rence Erlbaum, Hillsdale, NJ pp 155e168 1128 Klein, G A, Calderwood, R and Macgregor, D (1989) Critical decision method for 1129 eliciting knowledge Systems, Man and Cyberetics Vol 19 No 3 pp 462e472 1130 1131 Kruchten, PH (2004) The Rational Uniﬁed Process. An introduction Addison- 1132 Wesley 1133 Oesterreich, B (2002) Developing software with UML, 2nd edn. Addison-Wesley 1134 Olsson, E (2004) What active users and designers contribute in the design process 1135 Interacting with Computers Vol 16 pp 377e401 1136 Oostveen, A-M and van den Besselar, P (2004) From small scale to large scale 1137 user participation: a case study of participatory design in E-government sys- 1138 tems, Proceedings of the Participatory Design Conference CPSR, Pao Alto, 1139 CA pp 173e182 1140 Pilemalm, S (2002) Information technology for non-proﬁt organisations. 1141 1142 Extended participatory design of an information system for trade union shop 1143 stewards, Linko¨ping Studies in Science and TechnologyPROOF Dissertation No 749 1144 Reich, Y, Konda, S L, Levy, S N, Monarch, I A and Subrahmanian, E (1996)- 1145 Varieties and issues of participation and design Design Studies Vol 17 pp 165e180 1146 Taylor, S J and Bogdan, R (1998) Introduction to qualitative research methods John 1147 Wiley and Sons, New York 1148 Tollmar, K (2001) Towards CSCW design in the Scandinavian tradition depart- 1149 ment of numerical analysis and computer science, Stockholm University Doctoral 1150 Dissertation 1151 1152

NCORRECTED U

26 Design Studies Vol -- No. -- Month 2007