A Practical Guide to Enterprise Architecture

In Canaxia there are organizations in the company that are utilizing Rational Unified Process (RUP) for software development projects with varying degrees of success. Myles Standish sees that because of the steep learning curve required to understand the UML syntax, some of the groups are struggling with creating consistent artifacts at each stage of a project's development. What Myles finds is that the groups that are more mature in the use of RUP are effectively creating reusable components and have solid specifications and documentation to support those components. The RUP-oriented development teams are directed more toward software framework than the other organizations and have defined components that can be used easily for new project developments. The business groups that work with these RUP-oriented development teams are having a hard time picking up all the syntaxes required to create the deliverables associated with this process. It seems that though the quality of the documentation associated with the design and implementation of the projects is exceptionally high, the quality of the requirements specification artifacts are inconsistent.

RUP is an evolution of the practices and process definitions created by Rational Software over the past 15 years. Identified as the Unified Process back in 1998, this process definition was the next generation of Rational's Objectory Process, which encompassed software development for object-oriented and component-based systems. Despite the changing of names, RUP continues to be a software engineering process framework for defining, implementing, and deploying software applications. At its core, RUP utilizes the Unified Modeling Language (UML) to clearly communicate requirements, architectures, and designs. The great benefit of basing the process framework around UML is that it is an industry-accepted language for modeling software systems. Though UML has a focus in describing object-oriented systems, the modeling syntax is a well defined and ubiquitously accepted standard across today's technology industry.

One of the characteristics of RUP is the well-defined grammar and terminology used throughout the process definition. At the highest level, RUP defines the following phases of a software project's delivery:

• Inception: The Inception phase is synonymous with the concept and specification phases described in the SDLC. This phase of a project is used to define the business case for any new software-development endeavor. It is also used to start describing the scope of a project's delivery, the primary actors that will interact with the software, and the criteria for evaluating the success of a project delivery.

• Elaboration: The elaboration phase is generally synonymous with the design phase described in the SDLC. Its purpose is to analyze the domain of the application design and establish a sound architectural foundation. The elaboration phase is many times the most important phase of a project's delivery, as many of the high-risk areas are dealt with during this phase and an overall "mile-high, inch-deep" description of the system is created during this phase.

• Construction: The construction phase of a RUP project encompasses the development and integration of each of the application components. The management mind-set undergoes a transition from the development of intellectual property during inception and elaboration to the development of deployable products during this phase of a project.

• Transition: The transition phase focuses on the activities required to place the software into the hands of the end-users. Typically, this phase includes several iterations that include beta releases and general availability releases, as well as bug-fix and enhancement releases. A large amount of effort is dedicated in this phase to develop user-oriented documentation, train users, support users in their initial product use, and react to user feedback.

• Evolution: The evolution of a software project is the ongoing activities associated with managing and deploying new releases of a product. Each evolution cycle encompasses another entire series of phases that include inception, elaboration, construction, and transition.

The Unified Modeling Language (UML)

It is important to understand the role and history of UML in the RUP. UML is a software modeling language used to describe the structure and processes encompassed by software systems. UML is the product of an evolution of various second-generation, object-oriented methods that were developed during the 1990s. Starting with Rational Software Corporation and three of the most prominent methodologists in object-oriented information systems, Grady Booch, James Rumbaugh, and Ivar Jacobson combined their respective approaches into a unified syntax for modeling software systems. Over the years, UML has pervaded the industry and was adopted as a standard for software modeling by the software consortium, the Object Management Group (OMG), in 1997.

Core Process Disciplines

Along with the four RUP phases of a software development release, nine core process disciplines are associated with a project in a RUP software delivery process. The nine core process disciplines are as follow:

1. Business modeling discipline: One of the key problem areas defined in software development projects is that the business users and the technical teams do not communicate properly because of differences in perspectives, knowledge, and semantics. Business modeling defines a common syntax to document business processes that can be translated into business use cases. These use cases can be readily analyzed by both the development and the business members.

2. Requirements discipline: The requirements work flow is used to define what the system will do. This process usually entails hashing out all the use cases that will be required to describe the behavior of the entire system. The use cases are then used as a unifying thread throughout the system's development cycle to analyze, design, and ultimately test the developed application.

3. Analysis and design discipline: This work flow deals specifically with defining how the system will realize all the requirements defined by the use cases in the context of the technology that will be used. Activities in this work flow include creation of the component design models, the definition of all the architectural details, and the analysis of how the components will interact in a software system.

4. Implementation discipline: The implementation work flow encompasses all the activities associated with defining the organization of the code, the implementation of classes and object, unit testing, and integration of the code across the software team.

5. Test discipline: The test work flow is used to verify the quality and behavior of the new software system. This work flow includes verifying the proper integration of all the implemented components, verification that all the use cases have been satisfied, and identification of any defects found in the software that can be used to provide feedback to the development team.

6. Deployment discipline: The deployment work flow defines the activities required to successfully manage software product release and to deliver the software to the end-user. Activities in this work flow include packaging software, installation of software in the deployment environments, providing support to the end-users, and coordinating the formal acceptance of the new software system by the end-users.

7. Project management discipline: This work flow details the activities that are required to effectively balance competing objectives, project risks, project cost, and project schedule. This work flow identifies activities to manage the planning, staffing, budgeting, and tracking of a software development effort.

8. Configuration and change management discipline: All the deliverables associated with a RUP project are known as project artifacts. This work flow defines the activities associated with managing the versioning and update notification associated with developing and maintaining the software artifacts.

9. Environment discipline: The environment work flow is an ancillary set of activities that identify the processes and tools that are used to support the development team.

Figure 5-4 describes the relationship of the core process work flows in relation to where effort is applied during the various phases described by the RUP methodology.

The Rational Suite of Tools

Along with providing the thought leadership, process information, and training for deploying RUP in an organization, Rational also provides a suite of software tools designed to work effectively in facilitating a RUP process implementation. Rational Software, acquired by IBM in the spring of 2003, provides commercial tools to support the full development life cycle of software. The following list is a subset of tools that are recommended by Rational for the various parts of the core process work flows. These tools are not required to implement RUP in an organization, but they greatly facilitate the maintenance and adherence of RUP standards at all stages during a software delivery.

• Rational Requisite^® Pro. This tool is used to capture and organize the requirements for a software project. This software is used to manage the activities associated with business modeling and requirements management.

• Rational ClearQuest™. This is a Web-based change-request management product that enables project teams to track and manage change activities that occur throughout the development life cycle.

• Rational Rose^®. This tool is an industry-leading software product used to analyze and model software systems. The tool has all the UML concepts and syntaxes built in to facilitate the creation and maintenance of UML-based component and process designs.

• Rational TeamTest. This tool is used to create, maintain, and execute automated functional tests, allowing you to more manageably test code and determine that the software meets project requirements.

• Rational ClearCase^®. This is a configuration management tool used for version control and tracking project progress.

The Benefits and Shortcomings of RUP

RUP is a software development process that has been developed and championed across the IT industry for almost a decade. The process definition is based upon a language (UML) that is in accord with industry standards and is widely accepted as the de facto modeling language for object-oriented and component-based systems. Throughout its evolution, RUP has matured into a variety of applications, and today one of the key characteristics that Rational is touting for this methodology is that the process can be tailored for the needs of an organization. Varieties of RUP have been defined that incorporate using RUP in a CMM organization or to attain CMM certification. Process-light versions of RUP have been developed to manage smaller, more agile projects. At the same time, this software development methodology is scalable to the full software delivery life cycle and includes details for managing software across organizations and the enterprise. Lastly, Rational provides the suites of tools, training, and process information that can be used to roll out RUP effectively across a company.

The first and most apparent shortcoming of RUP is, because it is based on UML, that it is biased to supporting OO and component-based software projects. For companies that support hybrid application environments where some systems may not fit directly into an object-oriented metaphor, UML is not as effective at incorporating these systems into its modeling language. The next shortcoming is that RUP can be very complex. The modeling syntax requires far more notation than what the average developer wants or needs. The third shortcoming is that purchasing the tools and training for RUP tends to be very expensive for an organization. Probably because RUP is proprietary to Rational and is its flagship product offering, implementing RUP in the enterprise can be costly in terms of software licensing and training support.

RUP is a software development methodology that has some limitations, specifically when dealing with the entire software life cycle. The Enterprise Unified Process (EUP), described in detail in Chapter 6, extends the RUP to make it a complete life cycle. As you can see in Figure 5-4, it adds two new phases, Production and Retirement, as well as two new disciplines, Enterprise Management and Operations & Support. Mid-to-large sized organizations find that they require these additions to have a life cycle that meets actual real-world needs, see Figure 5-5.