Welcome to the IBM Rational Unified Process and Certification
This chapter is from the book
This chapter is from the book
This chapter is from the book
By Ahmad K. Shuja
This chapter is about RUP's breadth and not its depth, so this introductory chapter will be mile wide and inch deep in terms of content. It introduces some of the core concepts that the RUP is founded on but does not go into detail about its different parts. It does, however, discuss the most important aspects of the RUP as they relate to software development. This chapter provides an overview of the book content.
An Overview of the Rational Unified Process
The IBM Rational Unified Process, also known as the RUP, is a process framework for successful iterative-incremental software development. In the software engineering domain, there are a number of development methodologies that organizations have successfully adapted and adopted to meet specific business needs. These range from traditional waterfall development to more agile ones. Figure 1-1 shows some of the more famous methodologies and where each can be positioned with respect to agility and discipline. Note that the up-front goals modeling component may not be directly associated with any given software development methodology but is there to ensure alignment between new software products or releases and the business strategy.
)
Figure 1-1 Methodologies map
At its core, RUP is defined by the following three central elements:
- Key principles for business-driven development
- A framework of reusable method content and process building blocks
- The underlying method and process definition language
Key Principles
RUP focuses on six key principles in software engineering (formerly known as best practices). These principles, which are easy to memorize because they start with the letters A through F, constitute the foundation of the RUP:
- Adapt the process.
- Balance stakeholder priorities.
- Collaborate across teams.
- Demonstrate value iteratively.
- Elevate the level of abstraction.
- Focus continuously on quality.
The key principals are not sequential; in fact, you will see in Chapter 2, "Key Principles for Business-Driven Development," that the principles actually reinforce each other. For example, the principle of demonstrating value iteratively supports the principle of focusing continuously on quality. Similarly, other key principles support and drive one another. Chapter 2 explains all six key principles in detail and discusses their inter-relationships.
A Framework of Reusable Method Content and Process Building Blocks
A process framework can be defined as an incomplete support structure in which another process can be organized and developed. Therefore, you need to finish a process framework before you can apply it to specific projects within an organization. Similarly, you need to finish the RUP skeleton and its libraries to fit the organization.
The RUP framework is defined by a family of method plug-ins from which, based on the unique business needs as well as the context (technical and management complexity), organizations are able to create their own method configurations and tailored processes. RUP provides an architectural foundation and wealth of material from which a process definition can be constructed, therefore enabling the adopting organization to configure and extend that foundation as desired.
A few factors influence the configuring and tailoring of RUP:
-
Project complexity
In most cases, the more complex and technical the project, the greater the formality and control required to ensure its successful completion and timely delivery. This formality normally involves greater plan-driven development and more discipline. The term commonly used in RUP to determine the level of formality and control that is required within the process is ceremony. Figure 1-2 shows the relationship between complexity and ceremony. Accordingly, the level of ceremony affects the number of artifacts and details of the workflow descriptions.
Figure 1-2 Complexity and ceremony (source: IBM Rational Unified Process v7.0)
-
Organizational maturity
Less mature organizations might require more discipline than more mature ones.
-
Organization culture
Culture plays an important role in the successful adaptation and adoption of the process.
-
Regulatory compliance and policy requirements
Some industries, especially financial and healthcare, might require more controls, which in turn require a high ceremony process and more artifacts.
-
Development type
The type of software development, such as green field versus COTS based, affects the process.
-
Organization size
The size of the organization determines how to customize the RUP to enable successful development and timely delivery of the software solutions.
)
These factors lead to one or more RUP flavors meeting the specific needs of an organization. IT organizations commonly develop multiple RUP instances to meet the needs of different types of projects. That approach satisfies the need for different levels of ceremony for small or large IT projects. In Part IV, we discuss Rational Method Composer, which can be used for effectively and efficiently customizing and publishing various flavors of RUP. We include some further discussion within Chapter 13, "Environment." Even though hundreds, if not thousands, of RUP customizations have been performed, they are based on the original RUP process framework, which is the subject of this book and the certification.
Architectural Views
RUP represents the software architecture in multiple architectural views. Each architectural view addresses concerns specific to stakeholders in the development process. These stakeholders might include users, designers, managers, and maintainers. The architectural views capture the major design decisions by presenting the software architecture in terms of how components connect to produce useful forms (Perry & Wolf, 1992).
The typical set of views in the RUP, called the 4+1 view model, is composed of the following.
-
Use-Case view
This view provides a basis for planning the technical content of iterations. It is used in the Requirements discipline.
-
Logical view
This view provides a basis for understanding the structure and organization of the design of the system. Logical view is used in the Analysis and Design discipline.
-
Implementation view
This view captures the enumeration of all subsystems in the Implementation Model, the component diagrams illustrating how subsystems are organized in layers, and hierarchies and illustrations showing important dependencies between subsystems.
-
Process view
This view illustrates the process decomposition of the system, including the mapping of classes and subsystems on to processes and threads. The Process view is used in the Analysis and Design discipline.
-
Deployment view
This view illustrates the distribution of processing across a set of nodes in the system, including physical distribution of processes and threads. This view is used in the Analysis and Design discipline.
Method and Process Definition Language
A unified method architecture (UMA) meta-model provides a language for describing method content and processes. UMA is an architecture to conceive, specify, and store method and process metadata. UMA clearly separates Method Content definitions from their application in delivery processes. It does this by defining the reusable core Method Content in the form of general content descriptions and the project-specific applications in the form of process descriptions. Basic elements of UMA are shown in Figure 1-3. We will discuss UMA is greater detail in Part II, "Unified Method Architecture (UMA)."
IBM Rational Unified Process. The diagram was used publicly in a Rational Edgearticle in 2006.
)
Figure 1-3 The basic elements of UMA