This section revisits the best practices introduced by Grady Booch in Chapter 1 and maps them to major components of the Rational Unified Process. The RUP, however, contains many other best practices in all aspects of software development. Iterative DevelopmentThe iterative approach recommended by the Rational Unified Process is generally superior to a linear, or waterfall, approach for a number of reasons:
Project managers often resist the iterative approach, seeing it as a kind of endless and uncontrolled hacking. In the Rational Unified Process, the iterative approach is very controlled; iterations are planned in number, duration, and objectives. The tasks and responsibilities of the participants are defined. Objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this, too, is controlled carefully . Chapter 4 describes this iterative approach in more detail, and Chapter 7 describes how to manage an iterative process and, in particular, how to plan it. Requirements ManagementRequirements management is a systematic approach to eliciting , organizing, communicating, and managing the changing requirements of a software- intensive system or application. The benefits of effective requirements management include the following:
In Chapter 9, The Requirements Discipline, we revisit and expand on this important feature of the Rational Unified Process. Chapter 13, The Configuration and Change Management Discipline, discusses the aspects related to tracking changes. Architecture and Use of ComponentsUse cases drive the Rational Unified Process throughout the entire lifecycle, but the design activities are centered on the notion of architecture ” either system architecture or, for software-intensive systems, software architecture. The main focus of the early iterations of the process is to produce and validate a software architecture that, in the initial development cycle, takes the form of an executable architectural prototype that gradually evolves to become the final system in later iterations. The Rational Unified Process provides a methodical, systematic way to design, develop, and validate an architecture. It offers templates for describing an architecture based on the concept of multiple architectural views. It provides for the capture of architectural style, design rules, and constraints. The design process component contains specific activities aimed at identifying architectural constraints and architecturally significant elements, as well as guidelines on how to make architectural choices. The management process shows how planning the early iterations takes into account the design of an architecture and the resolution of the major technical risks. A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture. It is the physical realization of an abstraction in your design. Component-based development can take various flavors:
The first point exploits the old concepts of modularity and encapsulation, bringing the concepts underlying object-oriented technology a step further. The final two points shift software development from programming software (one line at a time) to composing software (by assembling components). The Rational Unified Process supports component-based development in several ways:
Chapter 5 defines and expands the concept of architecture and its central role in the Rational Unified Process. Modeling and the UMLA large part of the Rational Unified Process is about developing and maintaining models of the system under development. Models help us to understand and shape both the problem and its solution. A model is a simplification of the reality that helps us master a large, complex system that cannot be comprehended in its entirety. We introduce several models in this book: a use-case model (Chapter 6), business models (Chapter 8), and design models and analysis models (Chapter 10). The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML gives you a standard means of writing the system's blueprints, covering conceptual items such as business processes and system functions as well as concrete items such as classes written in a specific programming language, database schemas, and reusable software components. [3]
The UML is a common language to express the various models, but it does not tell you how to develop software. It provides the vocabulary, but it doesn't tell you how to write the book. That is why Rational has developed the Rational Unified Process hand-in-hand with the UML to complement our work with the UML. The Rational Unified Process is a guide to the effective use of the UML for modeling. It describes which models you need, why you need them, and how to construct them. RUP 2000 and later versions use UML version 1.4. Configuration and Change ManagementParticularly in an iterative development, many work products are modified and modified often. By allowing flexibility in the planning and execution of the development and by allowing the requirements to evolve , iterative development emphasizes the vital issues of tracking changes and ensuring that everything and everyone is in sync. Focused closely on the needs of the development organization, change management is a systematic approach to managing changes in requirements, design, and implementation. It also covers the important activities of keeping track of defects, misunderstandings, and project commitments as well as associating these activities with specific artifacts and releases. Change management is tied to configuration management and to measurements. Chapter 13, The Configuration and Change Management Discipline, expands on these important aspects of software management and their interrelationships. |