Rational Unified Process (RUP)

Latest revision as of 16:33, 18 December 2018

Developed by Vasileios Lessis

The Rational Unified Process (RUP) is an iterative, software development methodology, firstly introduced by the Rational Software Corporation which was acquired by IBM in 2003. RUP is a disciplined approach to assign tasks within a development organization and software project teams. It was developed to ensure the production of high quality software by providing the development team with a set of guidelines, templates and tool mentors, for all the critical life-cycle activities within a project. This cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule ^[1]. RUP is the most popular and extensively documented refinement of the Unified Process, an iterative and incremental software development process framework. Other worth mentioning forms are the OpenUP and Agile Unified Process.

[edit] Process Overview

Figure 1. The iterative model graph shows how the process is structured along two dimensions

The best possible way to describe the methodology is through a 2 - dimensional graph ^[2].

• The first dimension (horizontal axis) represents the dynamic aspect of the process. It expresses time in terms of phases and iterations.
• The second dimension (vertical axis) represents the static aspect of the process. It expresses workflows in terms of 6 core and 3 supporting disciplines (more on that on "Disciplines" section).

[edit] Time Dimension - Phases and Iterations

When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle ^[3]. RUP delicately breaks the software life cycle down to four consecutive phases ^[4].

• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

Depending on the project, each of these phases can consist of one to a number of iterations. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones ^[5].

Figure 2. The four phases and milestones of a project

[edit] Inception Phase

The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects. The expected outcome of the inception phase includes :

• A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
• An initial use-case model (10%-20% complete)
• An initial project glossary
• An initial business case, including the business context, success criteria and a financial forecast.
• An initial risk assessment
• A project plan (phases and iterations)
• A business model (if necessary)
• Prototypes

At the end of the inception phase lies the first major project milestone; the Lifecycle Objective Milestone. The inception phase has five evaluation criteria:

• Stakeholder concurrence on scope definition and cost/schedule estimates.
• Depth and breadth of any prototype that was developed.
• Actual expenditures versus planned ones.
• Requirements understanding.
• Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

[edit] Elaboration Phase

The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

• A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
• Supplementary requirements (if any).
• A clear description of the software architecture.
• An architectural prototype.
• A more detailed risk assessment and business case.
• A development plan for the overall project.
• A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the Lifecycle Architecture Milestone. The elaboration phase has six evaluation criteria:

• Is the vision stable enough?
• Is the system architecture stable enough?
• Have all the major risks been successfully identified and resolved?
• Is the plan for the construction phase accurate enough?
• Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
• Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

[edit] Construction Phase

The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases ^[6]. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality ^[3]. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

• First external release of the software.
• User manuals.
• A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the Initial Operation Capability Milestone. The construction phase has three evaluation criteria:

• Is the software release stable enough to be given to the user community?
• Are all the stakeholders ready for the transition to the user community?
• Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

[edit] Transition Phase

The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

• Beta-testing to fix any major software bugs and add any missing features.
• Conversion of operational databases
• Training of end users and maintainers.
• Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the Product Release. The transition phase has two evaluation criteria:

• Are the end - users satisfied with the product?
• Is the actual vs planned resource expenditure in acceptable levels?

[edit] Iterations

As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional waterfall approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process ^[7].

[edit] Workflow Dimension - Disciplines

Figure 4. Individuals, Roles and Activities

Figure 5. Example of a workflow

A process describes who is doing what, how and when. RUP addresses those terms with four modelling elements; Roles, Activities, Artifacts and Workflows respectively ^[2]. A role, formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. Activities are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. Artifacts, are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called workflows. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called disciplines. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective ^[8].

There are six core "engineering" disciplines:

• Business Modelling Discipline
• Requirements Discipline
• Analysis and Design Discipline
• Implementation Discipline
• Test Discipline
• Deployment Discipline

And three core "supporting" disciplines:

• Project Management Discipline
• Configuration and Change Management Discipline
• Environment Discipline

[edit] Business Modelling

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

[edit] Requirements

The purpose of the requirements discipline is to describe in detail what the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

[edit] Analysis and Design

The purpose of the Analysis and Design discipline it to investigate how the system requirements will be translated into a detailed implementation plan. The system needs to:

• Perform exactly as described in the use-case descriptions.
• Fulfill all requirements.
• Have a robust structure.

Analysis and Design result in the creation of a design model ^[7]. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

[edit] Implementation

The purpose of the Implementation discipline is to:

• Arrange the code into subsystems, organized in layers.
• Implement classes and objects in terms of components.
• Uni-test the developed components to ensure quality.
• Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

[edit] Test

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:

• Functionality.
• Reliability.
• Application Performance.
• System Performance.

[edit] Deployment

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

• Developing external software releases
• Distributing the software
• Installing the software
• Providing help to the end – users
• Creating an up-to-date user manual
• Conducting beta testing

[edit] Project Management

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

• A framework for managing software-intensive projects.
• A framework to successfully manage risks.
• A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved ^[9].

[edit] Configuration and Change Management

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

[edit] Environment

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

[edit] Why RUP - Best Practices

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

• Develop Software Iteratively
• Manage Requirements
• Use component-based architectures
• Visually model software
• Continuously verify software quality
• Control changes to software

[edit] Develop Software iteratively

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. ^[10]

[edit] Manage requirements

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs. ^[11]

[edit] Use component-based architectures

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components. ^[12]

[edit] Visually model software

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system. ^[13]

[edit] Continuously verify software quality

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

[edit] Control changes to software

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

[edit] Limitations

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

• In order for team members to start developing software under this methodology, they need to be experts in their respective fields.
• The development process can easily become too complex to handle.
• When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
• While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

[edit] Conclusion

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be experts in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

[edit] Further Reading

A practical example of using the Rational Unified Process.

[edit] References

1. ↑ Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.
2. ↑ ^{2.0 2.1} IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational
3. ↑ ^{3.0 3.1} IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.
4. ↑ A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.
5. ↑ Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82.
6. ↑ KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.
7. ↑ ^{7.0 7.1} KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.
8. ↑ RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation.
9. ↑ Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998.
10. ↑ Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72
11. ↑ Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p
12. ↑ Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos, CA, 1996, pp.140.
13. ↑ Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language 1.3, White paper, Rational Software Corp., 1998