Rational Unified Best Practices (RUP): A Primer for the Project Manager

Rational Unified Best Practices: A Primer for the Project Manager

Crystal Lee, PMP

If you are an application development project manager, or if you are looking to become one, you will very likely be asked if you have ever used RUP, or Rational Unified Process. For the uninitiated, RUP can seem very much like a mysterious “black box,” or a magic potion from which the perfect piece of software will flow. In fact, there are a set of RUP Best Practices defined in the RUP literature which give some easy-to-understand guidelines on what it takes to implement RUP successfully. In this article, I will provide some background on each best practice, in the context of current RUP adoption, as well as my own personal experience using RUP to manage software development projects. Each best practice is accompanied by suggestions on how you as a project manager can implement or integrate these RUP best practices into your own project.


RUP Best Practice #1: Develop iteratively.

Iterative development came about because too many software projects were being delivered with the perception of poor quality, which is generally the result of poor testing practices. In addition, too many bugs, or defects, were being found late in the system development life cycle. The problem is that if design defects are being discovered during the UAT (user acceptance testing) phase, this is far too late in the cycle to give adequate attention to addressing the bugs without slipping the delivery date.

An iteration is defined as a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable operable release. This methodology makes it possible to develop a pre-defined set of working software in iterations. The RUP initiation, elaboration, construction, and transition phases can all be iterated.

One or more iterations can occur with each of the four RUP phases, each iteration concluding with a milestone. In the inception phase, the milestone is an idea. In elaboration, the milestone is the architecture. In construction, the milestones are the internal executable releases. In the transition phase, the milestone is the finished software product.

For the Project Manager: The project manager must guide the project team to divide a development project into manageable RUP iterations. At each stage of the resulting iterations, the project manager needs to identify possible risks and take action during the current iteration to try to remediate that risk. Lowering the project’s overall risk profile is preferable to carrying the risk over to the next iteration.


RUP Best Practice #2: Manage requirements.

The effective management of requirements is the key to building a software application product that genuinely meets user needs. Generally, managing requirements effectively is important whether RUP is used or not. However, RUP provides a tried and tested framework that defines how requirements are managed.

In RUP, the use case is an essential tool for capturing requirements. The use case is written in the form of scenarios that describe all the services that can be offered to users and to other systems, in a meaningful and complete manner. Once requirements are documented in use cases, they can be organized and prioritized according to importance, ability to deliver, cost, and other assorted criteria to determine if the requirement is needed for the final product.

For the Project Manager: One of the project manager’s highest priorities is to get stakeholders involved during the earliest elaboration phases. Then as requirements change, the team must evaluate the impact of the change, and decide whether or not a certain change should be implemented. The benefit of RUP is that change is expected, and the team should understand that requirements must always be reassessed. The project manager must constantly be communicating any requirements changes to all stakeholders and participants, as this will be of utmost importance to gaining final acceptance for each iteration and ultimately the final product.


RUP Best Practice #3: Use component architectures.

RUP development is based on the use and reuse of component modules or subsystems that serve a certain function. The use of component architectures lessens complexity as well as the relative size of the application. A system that reuses well-tested architectural components is less prone to variability and more robust as well. The use of component based architectures usually results in fewer dependencies between code modules and provides more flexibility when building additional functionality and feature sets during the next iteration.

During RUP inception and elaboration, various architectural elements must be defined and baselined. There are four distinct architectures in RUP: 1) business-specific, 2) application-specific, 3) middleware-specific, and 4) system software-specific. The system software refers to more infrastructure-related components such as operating systems. Of the four architectures, the business-specific architecture is the one that may most easily be eliminated.

For the Project Manager: The project manager can greatly influence the ability of a team to move toward component-based architectures. First, the project needs to engage architects and developers who are well-versed in RUP, and component infrastructures such as Java, CORBA, COM, and .NET. The project manager also must ensure that the project budget takes into account the purchase of any development tools that will be needed. Often these tools may be free or open-source, but they still need to be purchased when used at an enterprise level.


RUP Best Practice #4: Model visually.

Unified Modeling Language, or UML, has become a fundamental tool for effective object-oriented programming, and the construction of component architectures as mentioned above. UML functions as a common language that business analysts, web designers, and developers can all understand. A software application or platform can be expressed through various UML models with accompanying diagrams as an output, for instance, the Use Case Model, or requirements model, has use case diagrams as an output. Other common types of modeling diagrams that result from the use of UML models are class diagrams, object diagrams, sequence diagrams, collaboration diagrams, state diagrams, activity diagrams, component diagrams, and deployment diagrams. The advantage of using a platform-based modeling tool versus a stand-alone tool is that it is then possible to generate pseudocode to aid programming efforts based on the model.

For the Project Manager: Just as project managers have project management best practices in the PMBOK, RUP can be considered as a collection of best practices for the software developer. Any project manager involved in software development projects should take the time to become familiar with the terminology, models, and phases of RUP and UML.

The project manager in a RUP-based development organization should also spend some time first developing the documentation store for the project. The use of RUP and UML generates a large amount of documentation, diagrams, and other artifacts. The project team – analysts, developers, infrastructure staff, and project managers – must be given an organized structure in which to store documents, otherwise the data store can become completely unsearchable, and thus unusable. Logical organizational breakdowns can include functions, phases, iterations, and modules.

The project manager needs to realize that the high-level documentation structure created for a project will probably stay with the project until the end. Depending on the tool, once the structure is built, it can be very difficult to reorganize, especially for a longer multi-year project.


RUP Best Practice #5: Continuously verify quality.

Like other RUP processes, quality assessment is meant to be built into every activity and process in the development cycle. This means that testing is done throughout the project. The earlier a defect is found, the easier it will be to fix. An even worse situation occurs if a defect is not found, and developers continue to build on top of that defective component. Then when the defect is finally found and fixed, a whole new round of development and testing has to be done with the upstream or downstream components.

Defects should be collected and tracked in a database defect or bug tracking system such as Rational ClearQuest or Mercury Test Director.

For the Project Manager: The project manager should always build in a UAT (user acceptance test) period near the end of each of the construction iterations. This ensures that the project receives customer acceptance at the critical step before the development team moves to the next development milestone. One person or group must be responsible for keeping track of issues discovered during UAT so that they can be addressed either by fixing the problem, negotiating an agreement to leave the problem as is, or perhaps something in between. A lingering issue discovered during UAT may be the same issue that keeps a project stakeholder from signing off on the project.

Besides functional QA testing, UAT or customer acceptance testing, and performance and load testing, there are a few other tests which many development organizations now require an application to pass before allowing it to move into production status. Application security testing, or penetration testing, is now almost mandatory for any software application, especially one that is delivered via the internet. Some organizations also require that the application database pass a series of checks to make sure that the database has been constructed according to data architecture standards such as data consistency, and database object naming. A usability test can be very effective in finding and correcting user interface problems before the end user discovers them in UAT; usability testing is best accomplished with an outside vendor. Finally, depending on the application, the project manager may also have to schedule time to perform integration testing and end-to-end testing.

It is important for any application development project manager to find out what type of testing will be required for their application and what resources will be available to perform the tests, and whether the test must be done from within the project team or by a separate external party. Often these departments are scheduled out months in advance and it may require the engagement of a third party testing company to complete the test on time. In addition, the project team should assign a knowledgeable person to take the lead during these different tests, which at times become mini-projects in themselves; this can be the project manager if he or she has the knowledge and bandwidth to do so.


RUP Best Practice #6: Manage change.

One final RUP best practice is to effectively manage changes to software during the iterative development process. One of the key principles of change management in RUP is to ensure that changes have no negative results – to this end, the RUP process provides excellent guidelines on how to control, track, and monitor changes. One very important aspect of RUP is that each developer should be given his or her own secure development space so that they are isolated from changes made in other workspaces. The integration of different code elements occurs later.

In RUP, change management does not apply to just the code itself, otherwise known as configuration management. The IBM Rational toolkit includes a widely used code management application called ClearCase for this purpose. In RUP, change management should also be applied to all other project artifacts and documents, such as requirements documents, use cases, iteration plans, and test plans.

For the Project Manager: The RUP project manager needs to be an effective change manager. Both RUP and the PMBOK highlight change management as an important discipline. In a software development project, the project manager can try to enforce change management to track different components in the development process but this can be difficult as they may be considered within the scope of the development manager rather than the project manager. In addition, many developers do not want to take the time to log entries into a spreadsheet or tracking system. It is best to employ a separate tool or assign the role of controlling component changes to certain people.


For more information about how to bring RUP best practices to your application development project or a list of resources used in this article, contact Crystal Lee at clee@cprime.com.

Other Frequently Viewed Articles

Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…

Agile, Waterfall and Uncertainty in Project Management: Agile Development vs. Waterfall

Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.

Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.

Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.




(July 10, 2012) James Punnett said:

Thank you for writing this article.

I see a conflict in the “RUP Best Practice #1: Develop iteratively” section. It’s not only this article that I’ve seen this, I’ve noticed it in everything I’ve read so far about RUP/UP. (I haven’t read many of books, only a couple and several articles; I’m new to RUP.)

The first quote is, “An iteration is defined…resulting in an executable operable release.” The second quote is, “The RUP initiation, elaboration, construction, and transition phases can all be iterated.”

I understand both statements and taken in isolation, they are both true. But, they conflict don’t they? How is it possible to have an executable release at the end of the initiation phase?

Trying to resolve this concept of an iteration is driving me batty. To end up with an executable release at the end of an iteration implies that a single iteration spans ALL phases. On the other hand, if we agree that an iteration could begin and end in a single phase, e.g. the inception or elaboration phase, then how can you end up with an executable result?