Rational Unified Process (RUP)

Rational Unified Process (RUP) is an agile software development methodology. It was designed to help a team of software engineers create a dynamic product that meets all of a client’s expectations, while still working within a set, predictable budget and schedule. The process was developed from the Rational Objectory Process, which itself was developed from the Objectory Process.

Rational Unified Process encourages its developers to utilize six best practices. These include controlling the changes to software, visually modeling the software, carefully managing requirements, utilizing iterative development practices, verifying the software quality, and using component-based software architecture. It also breaks down the process of software development into four phases: the inception phase, the elaboration phase, the construction phase, and the transition phase.

Many businesses have encouraged the use of the Rational Unified Process because it helped developers create a quality product in an efficient amount of time. However, others believed the process was unnecessarily complicated. It also relied on having a number of extremely skilled software engineers to utilize.

Background

The first Objectory Process was created by Ivar Jacobson in 1987. Jacobson was an electrical engineer who worked with the telecommunications manufacturer Ericsson AB. He then went on to start his own company, Objectory AB. Jacobson’s process for software development became the standard for the company, and quickly gained renown in the technology community. A version of the process was published as a textbook in 1992.

The Objectory Process, then on version 3.8, was combined with another software development methodology, the Rational Approach, in 1995. This resulted in the creation of the Rational Objectory Process 4.0. The Rational Objectory Process was a software engineering process designed to ensure that software engineers created a product that was pleasing to its users, but also operated within a preset, predictable schedule and budget.

Unlike many previous approaches, Rational Objectory Process utilized an iterative architecture. This means that the software engineers were not expected to create and deliver a perfect product on their first attempt. Instead, at various points in the development timeline, the engineers were expected to reassess situations, address concerns, and integrate new features.

The Rational Observatory Process included a specific and detailed software testing process, similar to the ones used by SQA, Inc. This was designed to ensure that the final product created by the software engineers functioned as intended and was easily usable by its intended audience. It also utilized United Modeling Language, in an effort to further standardize its approach to software design.

In 1998, Rational Objectory Process 4.1 evolved into Rational Unified Process 5.0. Rational Unified Process was able to incorporate more tools than Rational Objectory Process. It was easier to utilize the process during product management and business modeling. Additionally, the process was combined with Pure-Atria, integrating many of Pure-Atria’s software tools into Rational Unified Process 5.0.

Overview

Rational Unified Process is a model and framework for successfully developing software. Developers are expected to tweak the process for their own means, allowing the framework of Rational Unified Process to better suit the project for which it’s being used. It utilizes six identified “best practices,” which are designed to guide developers as they work.

The first among these best practices is a direction to develop software iteratively. This means developing difficult parts of the software at every phase of production. Continuously working on important parts throughout the development cycle ensures that all parts of the finished product will function correctly. Developers are instructed to consistently managing their requirements, including how the program is required to perform for its eventual owner, and any trade-offs necessary to make that happen. They are instructed to use component-based architecture, allowing them to reuse portions of code throughout the current project and future projects. Developers are encouraged to create visual models of their software. They are also instructed to carefully control and track the changes made to each software component as they happen. This allows developers to easily find the cause when something goes wrong. Finally, developers are expected to verify the quality of their software at each step of the design life cycle.

Rational Unified Process breaks down software development into four separate phases. During the first phase, the inception phase, the team develops the basic idea of the project. Team members estimate the time that the project will require, the estimated financial cost of the project, and whether the team would require additional tools to effectively complete the project. By the end of the inception phase, developers should have a list of planned expenditures and formal scheduling estimates. Alternatively, developers calculating these costs may decide that the project is not worth the effort.

The elaboration phase takes place after the inception phase. During this phase, the developers analyze the schedule and development system they developed during the inception phase. They decide if this system will require additional resources, and verify that the company’s vision of a finished product is achievable. The elaboration phase is followed by the construction phase. Most of the coding takes place during this phase. The development team follows the carefully constructed plan from the previous phases. They also work on integrating the product with any other necessary software as stipulated by the client.

The last phase, the transition phase, involves the release of the finished product. Any packaging and delivery deemed necessary by the team is carried out during this phase. Additionally, the transition phase includes post-release support, such as patches and bug-fixing.

Rational Unified Process was effective, but was not without downsides. Its emphasis on integration and client expectations often led to complications and substantial extra work for developers. The process itself relied heavily on having specialized, expert developers available throughout the process. Additionally, the development framework specified by Rational Unified Process is complicated, and training otherwise skilled developers to work according to such a framework requires additional time and resources.

Bibliography

“A Brief History of the Rational Unified Process,” Flylib.com, flylib.com/books/en/1.560.1.31/1/. Accessed 5 Jun. 2019.

Bugajenko, Olga. “What is the Rational Unified Process? – Methodology, Tools, & Examples,” Study.com, 2019, study.com/academy/lesson/what-is-the-rational-unified-process-methodology-tools-examples.html. Accessed 5 Jun. 2019.

Jacobson, Sten. “The Rational Objectory Process – A UML-Based Software Engineering Process,” ISCN, 2002, www.iscn.at/select‗newspaper/object/rational.html. Accessed 5 Jun. 2019.

Kruchten, Philippe. “An Introduction to the Rational Unified Process,” InformIT, 19 Mar. 2004, www.informit.com/articles/article.aspx?p=169549&seqNum=5. Accessed 5 Jun. 2019.

Powell-Morse, Andrew. “Rational Unified Process: What Is It and How Do You Use It?” RUP, 14 Mar. 2017, airbrake.io/blog/sdlc/rational-unified-process. Accessed 5 Jun. 2019.

Mrsic, Maja. “Rational Unified Process,” ActiveCollab, 9 Aug. 2017, activecollab.com/blog/project-management/rational-unified-process-rup. Accessed 5 Jun. 2019.

“Rational Unified Process: Overview,” Tesestec, www.tesestec.com.br/pasteurjr/rup/process/ovu‗proc.htm. Accessed 5 Jun. 2019.

“Rational Unified Process (RUP),” Techopedia, www.techopedia.com/definition/3863/rational-unified-process-rup. Accessed 5 Jun. 2019.

"What Is RUP (Rational Unified Process) and Its Phases?" Geeks for Geeks, 22 May 2024, www.geeksforgeeks.org/rup-and-its-phases/. Accessed 15 Nov. 2024.