Rational unified process

Last updated

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. [1] RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

Contents

History

Rational Software originally developed the rational unified process as a software process product. The product includes a hyperlinked knowledge-base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process.

Philippe Kruchten, an experienced Rational technical representative was tasked with heading up the original RUP team.

These initial versions combined the Rational Software organisation's extensive field experience building object-oriented systems (referred to by Rational field staff as the Rational Approach) with Objectory's guidance on practices such as use cases, and incorporated extensive content from Jim Rumbaugh's Object Modeling Technology (OMT) approach to modeling, Grady Booch's Booch method, and the newly released UML 0.8. [2] [3]

To help make this growing knowledge base more accessible, Philippe Kruchten was tasked with the assembly of an explicit process framework for modern software engineering. This effort employed the HTML-based process delivery mechanism developed by Objectory. The resulting "Rational Unified Process" (RUP) completed a strategic tripod for Rational:

This guidance was augmented in subsequent versions with knowledge based on the experience of companies that Rational had acquired.

In 1997, a requirements and test discipline were added to the approach, much of the additional material sourced from the Requirements College method developed by Dean Leffingwell et al. at Requisite, Inc., and the SQA Process method developed at SQA Inc., both companies having been acquired by Rational Software.

In 1998 Rational Software added two new disciplines:

  1. business modeling, much of this content had already been in the Objectory Process
  2. a Configuration and Change Management discipline, sourced through the acquisition of Pure Atria Corporation.

These additions lead to an overarching set of principles that were defined by Rational and articulated within RUP as the six best practices for modern software engineering:

  1. Develop iteratively, with risk as the primary iteration driver [4]
  2. Manage requirements
  3. Employ a component-based architecture
  4. Model software visually
  5. Continuously verify quality
  6. Control changes

These best practices were tightly aligned with Rational's product line, and both drove the ongoing development of Rational's products, as well as being used by Rational's field teams to help customers improve the quality and predictability of their software development efforts.

Additional techniques including performance testing, UI Design, data engineering were included, and an update to reflect changes in UML 1.1.

In 1999, a project management discipline was introduced, as well as techniques to support real-time software development and updates to reflect UML 1.3. Besides, the first book to describe the process, The Unified Software Development Process ( ISBN   0-201-57169-2) by Ivar Jacobson, Grady Booch and James Rumbaugh., was published in the same year.

Between 2000 and 2003, a number of changes introduced guidance from ongoing Rational field experience with iterative development, in addition to tool support for enacting RUP instances and for customization of the RUP framework. These changes included:

  1. the introduction of concepts and techniques from approaches such as eXtreme Programming (XP), that would later come to be known collectively as agile methods. This included techniques such as pair programming, test-first design, and papers that explained how RUP enabled XP to scale for use on larger projects.
  2. a complete overhaul of the testing discipline to better reflect how testing work was conducted in different iterative development contexts.
  3. the introduction of supporting guidance - known as "tool mentors" - for enacting the RUP practices in various tools. These essentially provided step-by-step method support to Rational tool users.
  4. automating the customization of RUP in a way that would allow customers to select parts from the RUP process framework, customize their selection with their own additions, and still incorporate improvements in subsequent releases from Rational.

IBM acquired Rational Software in February 2003.

In 2006, IBM created a subset of RUP tailored for the delivery of Agile projects - released as an OpenSource method called OpenUP through the Eclipse web-site. [5]

Rational unified process topics

RUP building blocks

RUP is based on a set of building blocks and content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. The main building blocks, or content elements, are the following:

Within each iteration, the tasks are categorized into nine disciplines:

Four project life-cycle phases

RUP phases and disciplines. Development-iterative.png
RUP phases and disciplines.

The RUP has determined a project life-cycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished. The visualization of RUP phases and disciplines over time is referred to as the RUP hump chart.

Inception phase

The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

  • Stakeholder concurrence on scope definition and cost/schedule estimates.
  • Requirements understanding as evidenced by the fidelity of the primary use cases.
  • Credibility of the cost/schedule estimates, priorities, risks, and development process.
  • Depth and breadth of any architectural prototype that was developed.
  • Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the life cycle objective milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria.

Elaboration phase

The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

The outcome of the elaboration phase is:

  • A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
  • A description of the software architecture in a software system development process.
  • An executable architecture that realizes architecturally significant use cases.
  • Business case and risk list which are revised.
  • A development plan for the overall project.
  • Prototypes that demonstrably mitigate each identified technical risk.
  • A preliminary user manual (optional)

This phase must pass the lifecycle architecture milestone criteria answering the following questions:

  • Is the vision of the product stable?
  • Is the architecture stable?
  • Does the executable demonstration indicate that major risk elements are addressed and resolved?
  • Is the construction phase plan sufficiently detailed and accurate?
  • Do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture?
  • Is the actual vs. planned resource expenditure acceptable?

If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. However, after leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.

The key domain analysis for the elaboration is the system architecture.

Construction phase

The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments to produce demonstrable prototypes.

Transition phase

The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The system also goes through an evaluation phase, any developer which is not producing the required work is replaced or removed. The product is also checked against the quality level set in the Inception phase.

If all objectives are met, the product release milestone is reached and the development cycle is finished.

The IBM Rational Method Composer product

The IBM Rational Method Composer product is a tool for authoring, configuring, viewing, and publishing processes. See IBM Rational Method Composer and an open source version Eclipse process framework (EPF) project for more details.

Certification

In January 2007 the new RUP certification examination for IBM Certified Solution Designer - Rational Unified Process 7.0 was released which replaces the previous version of the course called IBM Rational Certified Specialist - Rational Unified Process. [6] The new examination will not only test knowledge related to the RUP content but also to the process structure elements. [7]

To pass the new RUP certification examination, a person must take IBM's Test 839: Rational Unified Process v7.0. You are given 75 minutes to take the 52 question exam. The passing score is 62%. [8]

Six best practices

Six best software engineering practices are defined for software projects to minimize faults and increase productivity. These are: [9] [10]

Develop iteratively
It is best to know all requirements in advance; however, often this is not the case. Several software development processes exist that deal with providing solutions to minimize cost in terms of development phases.
Manage requirements
Always keep in mind the requirements set by users.
Use components
Breaking down an advanced project is not only suggested but in fact unavoidable. This promotes ability to test individual components before they are integrated into a larger system. Also, code reuse is a big plus and can be accomplished more easily through the use of object-oriented programming.
Model visually
Use diagrams to represent all major components, users, and their interaction. "UML", short for Unified Modeling Language, is one tool that can be used to make this task more feasible.
Verify quality
Always make testing a major part of the project at any point of time. Testing becomes heavier as the project progresses but should be a constant factor in any software product creation.
Control changes
Many projects are created by many teams, sometimes in various locations, different platforms may be used, etc. As a result, it is essential to make sure that changes made to a system are synchronized and verified constantly. (See Continuous integration).

See also

Related Research Articles

The waterfall model is a breakdown of project activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.

<span class="mw-page-title-main">Dynamic systems development method</span>

Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

<span class="mw-page-title-main">Philippe Kruchten</span> Canadian software engineer

Philippe Kruchten is a Canadian software engineer, and Professor of Software Engineering at University of British Columbia in Vancouver, Canada, known as Director of Process Development (RUP) at Rational Software, and developer of the 4+1 Architectural View Model.

<span class="mw-page-title-main">Ivar Jacobson</span>

Ivar Hjalmar Jacobson is a Swedish computer scientist and software engineer, known as major contributor to UML, Objectory, Rational Unified Process (RUP), aspect-oriented software development and Essence.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment. It is part of the agile software development tool kit.

The enterprise unified process (EUP) is an extended variant of the unified process and was developed by Scott W. Ambler and Larry Constantine in 2000, eventually reworked in 2005 by Ambler, John Nalbone and Michael Vizdos. EUP was originally introduced to overcome some shortages of RUP, namely the lack of production and eventual retirement of a software system. So two phases and several new disciplines were added. EUP sees software development not as a standalone activity, but embedded in the lifecycle of the system, the IT lifecycle of the enterprise and the organization/business lifecycle of the enterprise itself. It deals with software development as seen from the customer's point of view.

Agile unified process (AUP) is a simplified version of the rational unified process (RUP) developed by Scott Ambler. It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test-driven development (TDD), agile modeling (AM), agile change management, and database refactoring to improve productivity.

Internet-Speed Development is an Agile Software Development development method using a combined spiral model/waterfall model with daily builds aimed at developing a product with high speed.

The open unified process (OpenUP) is a part of the Eclipse process framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the rational unified process (RUP) / unified process.

<span class="mw-page-title-main">Unified Process</span> Object oriented software development process framework

The unified software development process or unified process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the unified process is the rational unified process (RUP). Other examples are OpenUP and agile unified process.

ICONIX is a software development methodology which predates both the Rational Unified Process (RUP), Extreme Programming (XP) and Agile software development. Like RUP, the ICONIX process is UML Use Case driven but more lightweight than RUP. ICONIX provides more requirement and design documentation than XP, and aims to avoid analysis paralysis. The ICONIX Process uses only four UML based diagrams in a four-step process that turns use case text into working code.

An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts help describe the function, architecture, and design of software. Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.

The UPEDU or Unified Process for Education is a software development process specialized for education, developed by Pierre-N. Robillard, Philippe Kruchten and Patrick d'Astous.

<span class="mw-page-title-main">Winston W. Royce</span> American software engineer

Winston Walker Royce (August 15, 1929 – June 7, 1995) was an American computer scientist, director at Lockheed Software Technology Center in Austin, Texas. He was a pioneer in the field of software development, known for his 1970 paper from which the Waterfall model for software development was mistakenly drawn.

<span class="mw-page-title-main">RUP hump</span>

A RUP ‘hump’ is a plot of effort spent over time during a particular Rational Unified Process (RUP) discipline. The RUP hump chart consists of a collection of humps for all RUP disciplines. This diagram was created in 1993 during a workshop on architecture and process and was inspired by work by Grady Booch and Boehm. It has been part of the Rational Objectory Process after reviews by Dyrhage and Bylund and moved on to play a more important role in the RUP in 1998 when it served as the initial page for using the digital version of the process. Its final form was published by Philippe Kruchten in 1998. An older version as later used by Jacobson, Booch and Rumbaugh and an altered version was used by Royce.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

References

  1. ↑ IBM Acquires Rational
  2. ↑ Jacobson, Sten (2002-07-19). "The Rational Objectory Process - A UML-based Software Engineering Process". Rational Software Scandinavia AB. Archived from the original on 2019-05-27. Retrieved 2014-12-17.
  3. ↑ Kruchten, Philippe (2004-05-01). The Rational Unified Process: An Introduction. Addison-Wesley. p. 33. ISBN   9780321197702 . Retrieved 2014-12-17.
  4. ↑ Aked, Mark (2003-11-25). "RUP in brief". IBM . Retrieved 2011-07-12.
  5. ↑ "OpenUP". Archived from the original on 2014-01-06. Retrieved 2013-08-03.
  6. ↑ Krebs, Jochen (2007-01-15). "The value of RUP certification". IBM . Retrieved 2014-05-05.
  7. ↑ "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0". IBM . Retrieved 2008-05-13.
  8. ↑ "Test 839: Rational Unified Process v7.0". IBM . Retrieved 2008-05-13.[ permanent dead link ]
  9. ↑ Stephen Schach (2004). Classical and Object-Oriented Software Engineering. 6/e, WCB McGraw Hill, New York, 2004.
  10. ↑ Rational Unified Process white paper Archived 2009-05-01 at the Wayback Machine

Further reading

  1. ↑ Szymkowiak, Paul; Kruchten, Philippe (February 2003). "Testing: The RUP Philosophy". Academia.Edu. Rational Software (Rational Edge e-zine). p. 11. Retrieved 2022-10-13.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.