Skip to main content

RUP ( Rational Unified Process )

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. 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.

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. This journey began with the creation of the Rational Objectory Process (ROP) in 1996, when Rational acquired the Objectory Process that had been written by Ivar Jacobson and company. This was renamed Rational Unified Process (RUP) in subsequent releases, in part to align the name with that of the Unified Modeling Language.

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.

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:

a tailorable process that guided development
tools that automated the application of that process
services that accelerated adoption of both the process and the tools.
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:

business modeling, much of this content had already been in the Objectory Process
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:

Develop iteratively, with risk as the primary iteration driver
Manage requirements
Employ a component-based architecture
Model software visually
Continuously verify quality
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), 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:

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.
a complete overhaul of the testing discipline to better reflect how testing work was conducted in different iterative development contexts.
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.
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.

Comments

Post a Comment

Popular posts from this blog

Activity Diagram

What is an Activity Diagram? An activity diagram visually presents a series of actions or flow of control in a system similar to a  flowchart  or a  data flow diagram . Activity diagrams are often used in business process modeling. They can also describe the steps in a  use case diagram . Activities modeled can be sequential and concurrent. In both cases an activity diagram will have a beginning and an Basic Activity Diagram Notations and Symbols Initial State or Start Point A small filled circle followed by an arrow represents the initial action state or the start point for any activity diagram. For activity diagram using swimlanes, make sure the start point is placed in the top left corner of the first column. Activity or Action State An action state represents the non-interruptible action of objects. You can draw an action state in SmartDraw using a rectangle with rounded corners. Action Flow Action flows, also called edges and paths, illustrate the transitions f
Post a Comment
Read more

Sequence Diagram

Sequence diagram A  sequence diagram  is an interaction diagram that shows how objects operate with one another and in what order. It is a construct of a message sequence chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called  event diagrams  or  event scenarios . A sequence diagram shows, as parallel vertical lines ( lifelines ), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. Diagram building blocks If the lifeline is that of an ob
Post a Comment
Read more

Use Case

Dalam rekayasa perangkat lunak dan sistem, use case adalah daftar tindakan atau langkah-langkah acara yang biasanya mendefinisikan interaksi antara peran (dikenal dengan Unified Modeling Language sebagai aktor) dan sebuah sistem untuk mencapai suatu tujuan. Aktor tersebut bisa menjadi manusia atau sistem eksternal lainnya. Dalam kasus penggunaan teknik sistem digunakan pada tingkat yang lebih tinggi daripada rekayasa perangkat lunak yang sering mewakili misi atau tujuan pemangku kepentingan. Persyaratan rinci kemudian dapat ditangkap dalam Sistem Pemodelan Bahasa (SysML) atau sebagai laporan kontraktual. Analisis kasus penggunaan merupakan teknik analisis persyaratan penting dan berharga yang telah banyak digunakan dalam rekayasa perangkat lunak modern sejak diperkenalkan secara formal oleh Ivar Jacobson pada tahun 1992. Pengembangan use case driven adalah karakteristik utama dari banyak model dan kerangka proses seperti ICONIX, Unified Proses (UP), IBM Rational Unifi
Post a Comment
Read more