DOCSLIB.ORG

Rational Unified Process with Scrum

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Rational Unified Process with Scrum https://doi.org/10.48009/2_iis_2009_340-348 A HYBRID SOFTWARE DEVELOPMENT METHOD FOR LARGE-SCALE PROJECTS: RATIONAL UNIFIED PROCESS WITH SCRUM Juyun Cho, Colorado State University-Pueblo, [email protected] ABSTRACT mentioned that the conventional methods were not initially designed to respond to requirements change Conventional software development methods have occurring in the middle of the development process, gradually been replaced by lightweight agile and the ability to take action appropriate to the software development methods since the mid-1990s. change often determines the success or failure of a This phenomenon is mainly due to the conventional software product [37]. According to the Standish methods’ shortcomings, including a slow adaptation Group report [33], numerous projects with the to rapidly changing business requirements, and a conventional methods in various industry and tendency to be over budget and behind schedule. This government sectors were completed with fewer paper analyzes characteristics, strengths, and features and functionalities than specified in the user weaknesses of both conventional and agile methods. requirements. It is also a challenge for the This paper also explains the four major phases and conventional methods to create a complete set of nine disciplines of the Unified Process, and the requirements up front due to constant changes in the common elements of the Scrum process. Finally, this technology and business environments. paper suggests a new hybrid software development method that combines the Rational Unified Process Despite the existing shortcomings, the conventional with the Scrum process to accommodate the strengths methods are still widely used in industry, particularly, of both methods while suppressing their weaknesses. for large-scale projects. The driving force of this The hybrid method can be utilized in the software broad utilization of the conventional methods comes industry, particularly, in the business sectors that from their straightforward, methodical, and structured deal with large-scale projects. nature [12], as well as their capability to provide predictability, stability, and high assurance [6]. Keywords: Hybrid software development method, Unified process, Scrum process, conventional Agile software development methods focus on software development methods, agile software iterative and incremental development, customer development methods. collaboration, and frequent delivery [33] through a light and fast development life cycle. There are many INTRODUCTION positive benefits of the agile approaches. Shorter development cycles, higher customer satisfaction, Conventional heavyweight, document-driven lower bug rates, and quicker adaptation to rapidly software development methods can be characterized changing business requirements have been reported as extensive planning, codified process, rigorous [6, 22, 24]. reuse, heavy documentation and big design up front [3]. The conventional methods were predominant in In spite of the potential benefits of the agile methods, the software industry up until the mid 1990s. Since many organizations are reluctant to throw their then, the conventional methods have been replaced conventional methods away and jump into agile by lightweight agile software development methods methods due to several issues. These include: 1) agile mostly in small-scale and relatively simple projects. methods significantly reduce the amount of This phenomenon is mainly due to the conventional documentation and rely heavily on tacit knowledge, methods’ shortcomings, including a slow adaptation 2) agile methods have not been sufficiently tested for to rapidly changing business requirements, and a mission/safety-critical projects, 3) agile methods are tendency to be over budget and behind schedule [3, 6, not adequate for highly stable projects, 4) agile 9, 15, 26, 34, 36]. The conventional methods also methods can be successful only with talented have failed to provide dramatic improvements in individuals who favor many degrees of freedom, and productivity, reliability, and simplicity [9]. 5) agile methods are not appropriate for large-scale projects. Table 1 below summarizes the Some researchers reported that during their project characteristics, strengths, and weaknesses of the development experience, requirements often changed conventional and agile methods. by 25% or more [5, 18]. An interesting research Volume X, No. 2, 2009 340 Issues in Information Systems A Hybrid Software Development Method For Large-Scale Projects Table 1. Comparisons between Conventional and Agile Methods Conventional Methods Agile Methods Characteristics Extensive planning Iterative and incremental Codified process development Rigorous reuse Customer collaboration Heavy documentation Frequent delivery Big design up front Light and fast development cycle Tacit knowledge within a team Light documentation Strengths Straightforward, methodical, and Short development cycle structured nature High customer satisfaction Predictability, stability, and high Low bug rate assurance Quick adaptation to rapidly changing business requirements Weaknesses A slow adaptation to rapidly Significant document reduction and changing business requirements heavy dependence on tacit A tendency to be over budget knowledge A tendency to be behind schedule Not sufficiently tested for Difficult to create a complete set of mission/safety-critical projects requirements up front Not adequate for highly stable projects Can be successful only with talented individuals who favor many degrees of freedom Not appropriate for large-scale projects As shown in the table, strengths and weaknesses exist The UP takes an iterative, requirements-driven, and with both methods. It would be very beneficial if we architecture-centric approach, which is based on can come up with a new method that accommodates sound engineering principles [19]. Some of the the strengths while suppressing the weaknesses of universal principles of UP includes: 1) adapt the both methods. This paper suggests a new method that process, 2) balance stakeholder priorities, 3) combines the Rational Unified Process (conventional collaborate across teams, 4) demonstrate value method) with the Scrum (agile method) to maximize iteratively, 5) elevate the level of abstraction, and 6) the strengths of the two approaches. focus continuously on quality. The remainder of this paper is organized as follows: The UP has a long and proven history and has clearly The next two sections describe the characteristics of evolved [2]. Table 2 depicts how the UP has evolved the Rational Unified Process and the common through several variations. Among the many different components of the Scrum process. Next, a new versions, Rational Unified Process (RUP) 2003 was hybrid model/method is presented with an utilized in this study as a framework. As shown in explanation how the Rational Unified Process is table 2, RUP came from the Objectory process v1.0 combined with the Scrum. Finally, the author and evolved into RUP 2003 with various additions concludes the paper with a suggestion for possible and enhancements. More recently, a lighter UP called future research. the Agile Unified Process (AUP) was developed for an agile software development. The AUP utilizes a RATIONAL UNIFIED PROCESS streamlined approach, which has fewer activities and deliverables with a simplified method. The Unified Process (UP) is a well-defined object- oriented system development process originally The structure of RUP is two dimensional: phases and offered by IBM Rational Software and was disciplines. The phases represent the four major developed by Booch, Rumbaugh, and Jacobson [25]. stages that a project goes through over time. The Volume X, No. 2, 2009 341 Issues in Information Systems A Hybrid Software Development Method For Large-Scale Projects major stages include inception, elaboration, Project construction, and transition. The disciplines represent Management the logical activities that take place throughout the Environment project. The nine disciplines can be employed across two or Table 2. History of Unified Process more phases during the RUP development life cycle. Year Event For example, the business modeling discipline can be 1988 Objectory v1.0 is created by Jacobson’s utilized in both the inception and elaboration phases Objectory AB company. Rational Unified to understand the business environment, the Process and Enterprise Unified Process came requirements, the design, the implementation, and the out from the Objectory process. testing disciplines can be employed across all four 1996 Rational Objectory Process (ROP) 4.0 is phases to classify requirements that the system must created. Iterative concept is introduced. implement, to design a solution for the system that 1998 ROP is renamed into Rational Unified satisfies the requirements, to write code that makes Process and RUP 5.0 is released. the system actually work, and to conduct unit and 1999 Rational Unified Process 5.5 is released with integrated system testing. The deployment discipline an enhancement of real-time and web-based can occur during the elaboration, construction, and development. transition phases to place a portion of the system or 2000 Rational Unified Process 2000 is developed the full system into operation for users. The support with the addition of business engineering disciplines can also occur across all four phases for techniques to the business modeling planning and controlling the project.
Load more

Recommended publications
  • 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]
  • 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]
  • 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]
  • SSW555 Syllabus
    Stevens Institute of Technology WebCampus.Stevens Syllabus Course Number: SSW 555 Agile Methods for Software Development Professor Name: Mark Ardis Office Hours: Wednesdays 3-5 PM Office address: Babbio 517 Course Web Address: Office phone number: 201 216 5143 (on WebCT) E-mail address: [email protected] Overview In software problem areas that require exploratory development efforts, those with complex requirements and high levels of change, agile software development practices are highly effective when deployed in a collaborative, people-centered organizational culture. This course examines agile methods, including Extreme Programming (XP), Scrum, Lean, Crystal, Dynamic Systems Development Method and Feature-Driven Development to understand how rapid realization of software occurs most effectively. The ability of agile development teams to rapidly develop high quality, customer-valued software is examined and contrasted with teams following more traditional methodologies that emphasize planning and documentation. Students will learn agile development principles and techniques covering the entire software development process from problem conception through development, testing and deployment, and will be able to effectively participate in and manage agile software developments as a result of their successfully completing this course. Case studies and software development projects are used throughout. Prerequisites Programming experience in an object-oriented language, preferably Java. Cross-listed with: CS 555 Learning Goals After
    [Show full text]
  • Software Development a Practical Approach!
    Software Development A Practical Approach! Hans-Petter Halvorsen https://www.halvorsen.blog https://halvorsen.blog Software Development A Practical Approach! Hans-Petter Halvorsen Software Development A Practical Approach! Hans-Petter Halvorsen Copyright © 2020 ISBN: 978-82-691106-0-9 Publisher Identifier: 978-82-691106 https://halvorsen.blog ii Preface The main goal with this document: • To give you an overview of what software engineering is • To take you beyond programming to engineering software What is Software Development? It is a complex process to develop modern and professional software today. This document tries to give a brief overview of Software Development. This document tries to focus on a practical approach regarding Software Development. So why do we need System Engineering? Here are some key factors: • Understand Customer Requirements o What does the customer needs (because they may not know it!) o Transform Customer requirements into working software • Planning o How do we reach our goals? o Will we finish within deadline? o Resources o What can go wrong? • Implementation o What kind of platforms and architecture should be used? o Split your work into manageable pieces iii • Quality and Performance o Make sure the software fulfills the customers’ needs We will learn how to build good (i.e. high quality) software, which includes: • Requirements Specification • Technical Design • Good User Experience (UX) • Improved Code Quality and Implementation • Testing • System Documentation • User Documentation • etc. You will find additional resources on this web page: http://www.halvorsen.blog/documents/programming/software_engineering/ iv Information about the author: Hans-Petter Halvorsen The author currently works at the University of South-Eastern Norway.
    [Show full text]
  • Agile/Devops Development and Agile Acquisition: Differences, Similarities
    GSAW 2006 Tutorial F: Evolutionary Acquisition & Spiral Development Length: Half day Overview: The publication of Department of Defense (DoD) Directives 5000.1and 5000.2 in 2003 established a preference for evolutionary acquisition and spiral development in the acquisition of complex weapon systems. Similarly to the original DoD directives, National Security Space Acquisition Policy 03-01 also positioned evolutionary acquisition and spiral development as preferred strategies for the Space domain. The policy was based on the assumption that the implementation of these strategies would drastically reduce the time to deliver complex weapon systems to the war-fighter. Nevertheless, the DoD still struggles with substantial cost and schedule overruns. Spiral development is blamed, and a revision to the 5000 Directives is expected. Also, as recently as June 8, 2005, Michael Griffin, the newly appointed NASA Administrator was quoted saying with respect to the Crew Exploration Vehicle program that "… I hope never again to let the words spiral development cross my lips." It is unfortunate that even though evolutionary concepts were introduced in the early 1960's and spiral development in the1980's, so much controversy remains about their use. Technical difficulties with the Spiral Development fundamentally stem from the flexibility of the model. While it was originally introduced as a software development life cycle model, in reality it is much more; it is a meta-model, with multiple applications. Itis, in fact, a risk-driven process generator that is applicable not only to Software Engineering, but Systems Engineering as well, and it can be applied to the development of any process, concurrently with product development.
    [Show full text]
  • Using the Rational Unified Process for Small Projects: Expanding Upon Extreme Programming
    UUssiinngg tthhee RRaattiioonnaall UUnniiffiieedd PPrroocceessss ffoorr SSmmaallll PPrroojjeeccttss:: EExxppaannddiinngg UUppoonn eeXXttrreemmee PPrrooggrraammmmiinngg Gary Pollice Rational Software White Paper TP 183, 3/01 Table of Contents Abstract.................................................................................................................................................................................... 1 Introduction............................................................................................................................................................................. 1 A Short Story......................................................................................................................................................................... 1 Overview............................................................................................................................................................................... 2 Project Start — Inception ...................................................................................................................................................... 3 An approved Business Case .................................................................................................................................................. 4 Risk List ................................................................................................................................................................................ 4 Preliminary Project Plan.......................................................................................................................................................
    [Show full text]
  • RUP, Agile, XP
    RUP, Agile, XP Sommerville Book: Chapter 2.1.2, 2.3.3, 2.4, 3.1, 3.3 Pressman & Maxim Book: Chapter 4.1.2, 4.1.3, 4.3, 5.1—5.4 Administrative stuff • TA office hours – Lefan, 2—3:30pm T @ CSIL1 – Yuxi, ??pm Mon/Wed @ CSIL? ?? • Class enrollment • Warmup project Software Development Process Software Development Process • In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle. ---- Wikipedia Outline • The problems of waterfall – How to improve waterfall? • RUP – Phases – (iterative) Activities – UML • Agile – XP Waterfall model Requirement design implementation testing maintenance What are the problems? • 1. difficult to handle changes • 2. take long time to deliver • 3. expensive to fix errors • 4. difficult to estimate/planning How to deliver faster? Incremental process • Produce core products first • Produce further refinements in follow-up releases Incremental process Example • Text editor • Class registration system How to handle changes better? Evolutionary process • Spiral model Design Rational Unified Process 1990’ Rational Unified Process • Basic idea: incremental + iterative • Phases + workflows Business modeling Req. Design Impl. Test Deployment Which workflow happens at which phase? RUP RUP • What is the product of each workflow? – Unified Modeling Language • Business modeling + requirement à Actor and use case diagram • Analysis & design à class diagram, sequence diagram, state diagram • Implementation • Testing • Deployment à deployment diagram UML examples Agile 2001 Background • Planning planning planning – Airplane’s control system needs 10 years to develop • Problems – Too much document – Too late code delivery – Not easy to deal with changes – Too much bureaucracy – Hard to finalize design w/o implementation – Hard to estimate time before design & imp.
    [Show full text]
  • The IBM Rational Unified Process for System Z
    Front cover The IBM Rational Unified Process for System z RUP for System z includes a succinct end-to-end process for z practitioners RUP for System z includes many examples of various deliverables RUP for System z is available as an RMC/RUP plug-in Cécile Péraire Mike Edwards Angelo Fernandes Enrico Mancin Kathy Carroll ibm.com/redbooks International Technical Support Organization The IBM Rational Unified Process for System z July 2007 SG24-7362-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (July 2007) This edition applies to the IBM Rational Method Composer Version 7.1 © Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this IBM Redbooks publication . .x Become a published author . xii Comments welcome. xii Part 1. Introduction to the IBM Rational Unified Process for System z. 1 Chapter 1. Introduction. 3 1.1 Purpose. 4 1.2 Audience . 4 1.3 Rationale . 4 1.4 Scope . 5 1.5 Overview . 5 Part 2. The IBM Rational Unified Process for System z for Beginners . 9 Chapter 2. Introduction to the IBM Rational Unified Process and its extension to Service-Oriented Architecture. 11 2.1 Overview . 12 2.2 Introduction to RUP. 13 2.2.1 The heart of RUP . 13 2.2.2 The IBM Rational Method Composer (RMC) platform . 13 2.3 Key principles for successful software development.
    [Show full text]
  • 16 the Impact of Methods and Techniques on Outcomes from Agile Software Development Projects
    16 THE IMPACT OF METHODS AND TECHNIQUES ON OUTCOMES FROM AGILE SOFTWARE DEVELOPMENT PROJECTS David Parsons Hokyoung Ryu Ramesh Lai Massey University, Albany Auckland, New Zealand AbstrSCt Agile software development methods have become increasingly popular since the late 1990s, and may offer improved outcomes for software development projects when compared to more traditional approaches. However there has previously been little published empirical evidence to either prove or disprove this assertion. A survey carried out in March 2006 gathered responses from a large number of software development professionals who were using many different methods, both traditional and agile. A statistical analysis of this data reveals that agile methods do indeed improve outcomes from software development projects in terms of quality, satisfaction, and productivity, without a significant increase in cost. However, adoption of methods appears to involve a high degree of adaptivity, with many methods being used in com­ bination and sets of techniques being adopted on an ad hoc basis. In this con­ text, our analysis suggests that choosing specific combinations of methods can be particularly beneficial. However, we also find that successful adoption of an agile method is to some extent dependent on rigorous integration of certain core techniques. Keywords Agile method, technique, software development Please use the jbUowingjbrmat when citing this chapter: Parsons, D., Ryu, H., and Lai, R., 2007, in IFIP International Federation for Information Processing, Volume 235, Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda, eds. McMaster, T., Wastell, D., Femeley, E., and DeGross, J. (Boston: Springer), pp. 235-249. 236 Part 3: Software Process Improvement 1 INTRODUCTION This paper provides some statistical analyses of a data set originally gathered using an online survey to determine the level of adoption of agile approaches by software development organizations.
    [Show full text]