DOCSLIB.ORG

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

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Integrating the Rational Unified Process and Participatory Design for Development of Socio-Technical Systems 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 Unified 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 Please cite this article in press as: Pilemalm, S et al., Integrating the Rational Unified 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 3/26 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 Unified Process and participatory design 3 Please cite this article
Load more

Recommended publications
  • Writing and Reviewing Use-Case Descriptions
    Bittner/Spence_06.fm Page 145 Tuesday, July 30, 2002 12:04 PM PART II WRITING AND REVIEWING USE-CASE DESCRIPTIONS Part I, Getting Started with Use-Case Modeling, introduced the basic con- cepts of use-case modeling, including defining the basic concepts and understanding how to use these concepts to define the vision, find actors and use cases, and to define the basic concepts the system will use. If we go no further, we have an overview of what the system will do, an under- standing of the stakeholders of the system, and an understanding of the ways the system provides value to those stakeholders. What we do not have, if we stop at this point, is an understanding of exactly what the system does. In short, we lack the details needed to actually develop and test the system. Some people, having only come this far, wonder what use-case model- ing is all about and question its value. If one only comes this far with use- case modeling, we are forced to agree; the real value of use-case modeling comes from the descriptions of the interactions of the actors and the system, and from the descriptions of what the system does in response to the actions of the actors. Surprisingly, and disappointingly, many teams stop after developing little more than simple outlines for their use cases and consider themselves done. These same teams encounter problems because their use cases are vague and lack detail, so they blame the use-case approach for having let them down. The failing in these cases is not with the approach, but with its application.
    [Show full text]
  • Document Title Requirements on Debugging in AUTOSAR
    Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Document Title Requirements on Debugging in AUTOSAR Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 332 Document Classification Auxiliary Document Status Final Part of AUTOSAR Release 4.2.2 Document Change History Release Changed by Change Description 4.2.2 AUTOSAR Marked the document as obsolete Release Management 4.2.1 AUTOSAR Editorial changes Release Management 4.1.2 AUTOSAR Updated reference to RS feature document Release Editorial changes Management 4.1.1 AUTOSAR Updated the format of requirements according Administration to TPS_StandardizationTemplate Updated the chapters 2 and 5 Replaced Complex Device Driver by Complex Driver 3.1.5 AUTOSAR Initial release Administration 1 of 19 Document ID 332: AUTOSAR_SRS_Debugging - AUTOSAR confidential - Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only.
    [Show full text]
  • The Guide to Succeeding with Use Cases
    USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0? 4 First Principles 5 Principle 1: Keep it simple by telling stories 5 Principle 2: Understand the big picture 5 Principle 3: Focus on value 7 Principle 4: Build the system in slices 8 Principle 5: Deliver the system in increments 10 Principle 6: Adapt to meet the team’s needs 11 Use-Case 2.0 Content 13 Things to Work With 13 Work Products 18 Things to do 23 Using Use-Case 2.0 30 Use-Case 2.0: Applicable for all types of system 30 Use-Case 2.0: Handling all types of requirement 31 Use-Case 2.0: Applicable for all development approaches 31 Use-Case 2.0: Scaling to meet your needs – scaling in, scaling out and scaling up 39 Conclusion 40 Appendix 1: Work Products 41 Supporting Information 42 Test Case 44 Use-Case Model 46 Use-Case Narrative 47 Use-Case Realization 49 Glossary of Terms 51 Acknowledgements 52 General 52 People 52 Bibliography 53 About the Authors 54 USE-CASE 2.0 The Definitive Guide Page 2 © 2005-2011 IvAr JacobSon InternationAl SA. All rights reserved. About this Guide This guide describes how to apply use cases in an agile and scalable fashion. It builds on the current state of the art to present an evolution of the use-case technique that we call Use-Case 2.0.
    [Show full text]
  • INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”
    in Proceedings of the 16th Intern. Symposium of the International Council on Systems Engineering (INCOSE'06), Orlando, FL, USA, Jul 2006. The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations Magnus Eriksson1,2, Kjell Borg1, Jürgen Börstler2 1BAE Systems Hägglunds AB 2Umeå University SE-891 82 Örnsköldsvik SE-901 87 Umeå Sweden Sweden {magnus.eriksson, kjell.borg}@baesystems.se {magnuse, jubo}@cs.umu.se Copyright © 2006 by Magnus Eriksson, Kjell Borg and Jürgen Börstler. Published and used by INCOSE with permission. Abstract. This paper describes a use case driven approach for functional analysis/allocation and requirements flowdown. The approach utilizes use cases and use case realizations for functional architecture modeling, which in turn form the basis for design synthesis and requirements flowdown. We refer to this approach as the FAR (Functional Architecture by use case Realizations) approach. The FAR approach is currently applied in several large-scale defense projects within BAE Systems Hägglunds AB and the experience so far is quite positive. The approach is illustrated throughout the paper using the well known Automatic Teller Machine (ATM) example. INTRODUCTION Organizations developing software intensive defense systems, for example vehicles, are today faced with a number of challenges. These challenges are related to the characteristics of both the market place and the system domain. • Systems are growing ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. • Systems have very long life spans, typically 30 years or longer. • Due to reduced acquisition budgets, these systems are often developed in relatively short series; ranging from only a few to several hundred units.
    [Show full text]
  • The Timeboxing Process Model for Iterative Software Development
    The Timeboxing Process Model for Iterative Software Development Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur – 208016; India Aveejeet Palit, Priya Kurien Infosys Technologies Limited Electronics City Bangalore – 561 229; India Contact: [email protected] ABSTRACT In today’s business where speed is of essence, an iterative development approach that allows the functionality to be delivered in parts has become a necessity and an effective way to manage risks. In an iterative process, the development of a software system is done in increments, each increment forming of an iteration and resulting in a working system. A common iterative approach is to decide what should be developed in an iteration and then plan the iteration accordingly. A somewhat different iterative is approach is to time box different iterations. In this approach, the length of an iteration is fixed and what should be developed in an iteration is adjusted to fit the time box. Generally, the time boxed iterations are executed in sequence, with some overlap where feasible. In this paper we propose the timeboxing process model that takes the concept of time boxed iterations further by adding pipelining concepts to it for permitting overlapped execution of different iterations. In the timeboxing process model, each time boxed iteration is divided into equal length stages, each stage having a defined function and resulting in a clear work product that is handed over to the next stage. With this division into stages, pipelining concepts are employed to have multiple time boxes executing concurrently, leading to a reduction in the delivery time for product releases.
    [Show full text]
  • Best Practice of SOA
    JOURNAL OF COMPUTING, VOLUME 2, ISSUE 2, FEBRUARY 2010, ISSN: 2151-9617 38 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ Improvement in RUP Project Management via Service Monitoring: Best Practice of SOA Sheikh Muhammad Saqib1, Shakeel Ahmad1, Shahid Hussain 2, Bashir Ahmad 1 and Arjamand Bano3 1Institute of Computing and Information Technology Gomal University, D.I.Khan, Pakistan 2 Namal University, Mianwali , Pakistan 3 Mathematics Department Gomal University, D.I.Khan, Pakistan Abstract-- Management of project planning, monitoring, scheduling, estimation and risk management are critical issues faced by a project manager during development life cycle of software. In RUP, project management is considered as core discipline whose activities are carried in all phases during development of software products. On other side service monitoring is considered as best practice of SOA which leads to availability, auditing, debugging and tracing process. In this paper, authors define a strategy to incorporate the service monitoring of SOA into RUP to improve the artifacts of project management activities. Moreover, the authors define the rules to implement the features of service monitoring, which help the project manager to carry on activities in well define manner. Proposed frame work is implemented on RB (Resuming Bank) application and obtained improved results on PM (Project Management) work. Index Terms—RUP, SOA, Service Monitoring, Availability, auditing, tracing, Project Management NTRODUCTION 1. I 2. RATIONAL UNIFIED PROCESS (RUP) Software projects which are developed through RUP RUP is a software engineering process model, which provides process model are solution oriented and object a disciplined approach to assigning tasks and responsibilities oriented. It provides a disciplined approach to within a development environment.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Descriptive Approach to Software Development Life Cycle Models
    7797 Shaveta Gupta et al./ Elixir Comp. Sci. & Engg. 45 (2012) 7797-7800 Available online at www.elixirpublishers.com (Elixir International Journal) Computer Science and Engineering Elixir Comp. Sci. & Engg. 45 (2012) 7797-7800 Descriptive approach to software development life cycle models Shaveta Gupta and Sanjana Taya Department of Computer Science and Applications, Seth Jai Parkash Mukand Lal Institute of Engineering & Technology, Radaur, Distt. Yamunanagar (135001), Haryana, India. ARTICLE INFO ABSTRACT Article history: The concept of system lifecycle models came into existence that emphasized on the need to Received: 24 January 2012; follow some structured approach towards building new or improved system. Many models Received in revised form: were suggested like waterfall, prototype, rapid application development, V-shaped, top & 17 March 2012; Bottom model etc. In this paper, we approach towards the traditional as well as recent Accepted: 6 April 2012; software development life cycle models. © 2012 Elixir All rights reserved. Keywords Software Development Life Cycle, Phases and Software Development, Life Cycle Models, Traditional Models, Recent Models. Introduction Software Development Life Cycle Models The Software Development Life Cycle (SDLC) is the entire Software Development Life Cycle Model is an abstract process of formal, logical steps taken to develop a software representation of a development process. SDLC models can be product. Within the broader context of Application Lifecycle categorized as: Management (ALM), the SDLC
    [Show full text]
  • Ovum Decision Matrix: Selecting an Application Lifecycle Management and Devops Solution, 2019–20
    Ovum Decision Matrix: Selecting an Application Lifecycle Management and DevOps Solution, 2019–20 Publication Date: 27 Jun 2019 | Product code: INT003-000374 Michael Azoff Ovum Decision Matrix: Selecting an Application Lifecycle Management and DevOps Solution, 2019–20 Summary Catalyst Software lifecycle management (SLM) is the management of software development by taking a lifecycle approach from concept through the management of requirements, testing, coding, deployment, upgrades, maintenance, and final retirement. The market provides tools to support this lifecycle in the form of application lifecycle management (ALM) tools and, with the rise of DevOps, tools that provide DevOps-style release management, orchestration, and automation. This Ovum Decision Matrix (ODM) examines ALM tools that cross over into DevOps to support the full arc of the lifecycle from application/product concept to deployment into production. Ovum view ALM origins and trends The need for taking an SLM approach is best thought of as good practice in the relatively young art of software development. The ALM tools market has evolved to support SLM through the years; at its core is the development methodology or work process, and this has evolved over time, starting with waterfall or linear stage-gate processes and incorporating various innovations such as Tom Gilb's evolutionary delivery, Barry Boehm's spiral model, and Rational's unified process, before Agile and lean swept the board with examples such as Scrum, extreme programming, and Kanban boards post- 2001 (when the Agile Manifesto was created). The integrated ALM suite tools market really took off around 2003 but supported waterfall because Agile was still under the radar.
    [Show full text]
  • Use Case Tutorial Version X.X ● April 18, 2016
    Use Case Tutorial Version X.x ● April 18, 2016 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 www.website.com [Company Name] [Document Name] [Project Name] [Version Number] Table of Contents Introduction ..............................................................................................3 1. Use cases and activity diagrams .......................................................4 1.1. Use case modelling ....................................................................4 1.2. Use cases and activity diagrams ..................................................7 1.3. Actors .......................................................................................7 1.4. Describing use cases.................................................................. 8 1.5. Scenarios ................................................................................10 1.6. More about actors ....................................................................13 1.7. Modelling the relationships between use cases ...........................15 1.8. Stereotypes .............................................................................15 1.9. Sharing behaviour between use cases........................................ 16 1.10. Alternatives to the main success scenario ..................................17 1.11. To extend or include? ...............................................................20
    [Show full text]
  • User-Stories-Applied-Mike-Cohn.Pdf
    ptg User Stories Applied ptg From the Library of www.wowebook.com The Addison-Wesley Signature Series The Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Books in the series are personally chosen by expert advi- sors, world-class authors in their own right. These experts are proud to put their signatures on the cov- ers, and their signatures ensure that these thought leaders have worked closely with authors to define topic coverage, book scope, critical content, and overall uniqueness. The expert signatures also symbol- ize a promise to our readers: you are reading a future classic. The Addison-Wesley Signature Series Signers: Kent Beck and Martin Fowler Kent Beck has pioneered people-oriented technologies like JUnit, Extreme Programming, and patterns for software development. Kent is interested in helping teams do well by doing good — finding a style of software development that simultaneously satisfies economic, aesthetic, emotional, and practical con- straints. His books focus on touching the lives of the creators and users of software. Martin Fowler has been a pioneer of object technology in enterprise applications. His central concern is how to design software well. He focuses on getting to the heart of how to build enterprise software that will last well into the future. He is interested in looking behind the specifics of technologies to the patterns, ptg practices, and principles that last for many years; these books should be usable a decade from now.
    [Show full text]
  • Multi Objective Analysis for Timeboxing Models of Software Development
    MULTI OBJECTIVE ANALYSIS FOR TIMEBOXING MODELS OF SOFTWARE DEVELOPMENT Vassilis C. Gerogiannis and Pandelis G. Ipsilandis Department of Project Management, Technological Education Institute of Larissa, Larissa, Greece Keywords: Software Project Management, Iterative Development, Timeboxing, Project Scheduling, Linear Programming, Multi-Objective Optimization. Abstract: In iterative/incremental software development, software deliverables are built in iterations - each iteration providing parts of the required software functionality. To better manage and monitor resources, plan and deliverables, iterations are usually performed during specific time periods, so called “time boxes”. Each time box is further divided into a sequence of stages and a dedicated development team is assigned to each stage. Iterations can be performed in parallel to reduce the project completion time by exploiting a “pipelining” concept, that is, when a team completes the tasks of a stage, it hands over the intermediate deliverables to the team executing the next stage and then starts executing the same stage in the next iteration. In this paper, we address the problem of optimizing the schedule of a software project that follows an iterative, timeboxing process model. A multi objective linear programming technique is introduced to consider multiple parameters, such as the project duration, the work discontinuities of development teams in successive iterations and the release (delivery) time of software deliverables. The proposed model can be used to generate alternative project plans based on the relative importance of these parameters. 1 INTRODUCTION team of experts is usually assigned to each stage, i.e., a team for a stage performs only the activities In iterative and incremental development, software for that stage.
    [Show full text]