Unified Process

The information in this section is based primarily on Walker Royce's Software Project Management: A Unified Framework (Addison-Wesley, 1998), and Ivar Jacobson, Grady Booch, and James Rumbaugh's The Unified Software Development Process (Addison-Wesley, 1999). Although we try to summarize this model accurately, this brief discussion nevertheless reflects our interpretation of the Unified Process, which is based on our development experience. For a strict definition of the Unified Process, refer to the source texts.

One commonly used model for the analysis, design, and implementation of enterprise applications is the Unified Software Development Process (Unified Process or UP). The Unified Process, which requires extensive use of the Unified Modeling Language (UML) modeling, is:

• Use-case driven.
• Architecture-centric.
• An iterative development process.
• An incremental development process.
• Risk-confronting.
• An object-oriented and layered design approach.
• A repository for object-oriented system development patterns, objects, and code.

Workflows

The heart of the Unified Process is five core workflows that are continually executed during the four phases of the development process until the application is completed. Each completion of the five-workflow steps is called an iteration, and each iteration culminates in an internal product release. The workflow names are descriptors that simplify communication; they contain no magic or hidden meaning. These core workflows are:

• Requirements The Requirements Workflow is done to gather business, application, and technical requirements.
• Analysis The Analysis Workflow provides business and application modeling derived from requirements.
• Design The Design Workflow uses object-oriented design techniques to complete the application architecture.
• Implementation The Implementation Workflow is execution of the designed work including prototypes.
• Testing The Testing Workflow verifies the proper work has been done.

The next iteration begins the cycle again with the Requirements Workflow. We will briefly summarize the main workflows of the Unified Process.

Requirements

The main purpose of the Requirements Workflow is to aim the iteration toward developing the right application for the customer and users. The underlying goal is to describe the application in enough detail that agreement can be reached between the customer, user, and development team on what the application can and cannot do. Information can be gathered from many sources; the project stakeholders, an existing system, or occasionally an existing requirements document created by the customer.

As the team gathers the information, it develops a list of candidate requirements. These requirements can be structured with a brief name, description, status (proposed, approved, incorporated, or validated), estimated cost to implement, priority, and associated level of risk to implement the feature. The context of the application is also part of this workflow. The Unified Process suggests that the context be described using business modeling or domain modeling. Functional requirements detailing who does what to the application are noted in the use case model. It is also important to capture nonfunctional requirements regarding things such as performance, extensibility, and reliability. These nonfunctional requirements can be tagged to specific use cases as well as appended to the use case model as nonfunctional system requirements.

NOTE

---

The use case model is in the language of the customer and user.

The team can also deliver a set of UI designs or prototypes that represent the interaction of the roles conducted by the users. Ivar Jacobson et al. summarize the high-level deliverables of the Requirements Workflow as:

• A business model or a domain model to set the context of the system.
• A use case model that captures the functional requirements and the nonfunctional requirements that are specific to individual use cases. The use case model is described by a survey description, a set of diagrams, and a detailed description of each use case.
• A set of user interface sketches and prototypes for each actor representing the design of the user interfaces.
• A supplementary requirements specification for the requirements that aregeneric and not specific for a particular use case.

Analysis

During the UP's Analysis Workflow, the application requirements are examined and described in the terms of the application's developers. This description is a refinement and structuring of the functional requirement captured by the use case model in the Requirements Workflow. The Analysis Workflow is an interim step that serves as an abstraction of the requirements and leads to the actual design of the application. Ivar Jacobson et al. summarize the Analysis Workflow as:

• A more precise specification of the requirements than we have in the results from requirements capture, including the use case model.
• An analysis model is described using the language of the developers, and can thereby introduce more formalism and be used to reason about the internal workings of the system.
• An analysis model structures the requirements in a way that facilitates understanding them, preparing them, changing them and in general, maintaining them.
• An analysis model can be viewed as the first cut at a design model (although it is a model of its own), and is thus an essential input when the system is shaped in design and implementation. This is because the system as a whole should be maintainable, not just the description of its requirements.

The high-level deliverable of the Analysis Workflow is the architectural view of the analysis model. This view consists of:

• Analysis classes These consist of border, entity, and control classes. Border classes are situated between the user roles (actors) and the internal working of the application and are often candidates for presentation layer or user services. Entity classes describe long-lived and persistent information. Control classes describe the application behaviors that handle the sequencing, transaction, and control of the application, excluding those described by border and entity classes.
• Use case realization analysis Ivar Jacobson et al. define this as:

  …a collaboration within the analysis model that describes how a specific use case is realized and performed in terms of the analysis classes and their interacting analysis objects.

  This combination, or collaboration, of use case diagrams and analysis class diagrams depicts their interaction. The team can then determine how to group the use cases by the classes, their objects and iterations.

• Analysis packages These seek to organize the analysis classes, use case realizations, and potentially other analysis packages. They represent the grouping of functional requirements described by use cases. Thus, analysis packages can be based on use cases that support a specific business process, a specific user role (actor), or related use cases noted by generalization or extended relationships.

Design

Following the analysis of the application, the lower-level Design Workflow can begin. The design classes and their behaviors are developed and assigned to one of four layers: standard user interface (presentation view), business, access, and data.

The Design Workflow consists of the following activities:

• Define the structure into subsystems (design model).
• Distribute the subsystems to layers (design model).
• Define the class and object interfaces (design model).
• Mapping active classes into deployment nodes (deployment models).

At the conclusion of the Design Workflow, the application's architecture is complete. The design model, which is the representation of the application's physical model, is also complete. Unlike the analysis model, the design model should be maintained throughout the application's life cycle. The design classes are fully described including their state, properties, and methods, as well as their relationship to other classes.

Implementation

The Unified Process is strongly based on the Spiral Model and features incremental prototyping and development until the development team is satisfied with the product and all required features are implemented. The Implementation Workflow is the actualization of the Design Workflow. There should be a one-to-one correspondence between the design classes and the code that is developed during this workflow. Each class can be compiled into an executable or many classes can be combined into a single executable, depending on the implementation language and analysis package design. The steps for this workflow, which are fed by the Design Workflow, are:

• Implement architectural prototype.
• Implement the components (classes and objects).
• Unit test the components.
• Integrate the components.
• Build the application.
• Derive tests from use cases.
• Evaluate architecture.
• Plan the next build.
• Iterate development.

Testing

The Testing Workflow verifies the expected results against the actual results of the Implementation Workflow. Testing is conducted upon conclusion of the Implementation Workflow regardless of whether the iteration's release is internal, intermediate, or external. Through each iteration, the testing model is refined to remove obsolete test cases, generate regression test cases, and create new test cases for future builds. Test cases specify a particular way of validating the application including the conditions of the test, the required input, and expected output. Test cases should be derived from use cases. In addition to testing the application as a whole, further test cases should be executed to verify the installation on the given application platform and verify the application is correctly configured. Finally, test components can be developed to automate the execution of the test cases.

Project Phases

Because the Unified Process is based primarily on the Spiral Model, like that model, its four phases of development are Inception, Elaboration, Construction, and Transition. Each phase strives to achieve specific goals:

• Inception Phase iterations focus on producing the business case.
• Elaboration Phase iterations are responsible for developing the baseline architecture.
• Construction Phase iterations focus on creating the product with incremental releases of product builds and features.
• Transition Phase iterations ensure the product is ready for release to the user community.

Requirements and the analysis, design, and implementation architecture represent the majority of the work within the Inception and Elaboration Phases. The completion of each phase describes the application in a level of detail using the Unified Process models. In addition, movement from one phase to the next is the result of accomplishing the goal for the phase and reaching the milestone for the phase. At each phase's major milestone, a critical go/no-go business decision is made about whether the project should continue, thus approving the next phase's requirements for budget and schedule. These major milestones are the synchronization points between the technical portions and business portions of the project.

Inception

Although no specific number of iterations can be associated with the Inception Phase, typically this phase does not exceed two workflow iterations and relies primarily on the Requirements Workflow. The Inception Phase is defined strictly by its goals, which are to set the scope of what the product should do, reduce the probability that the worst project risks will materialize, and prepare the project justification via the initial business case. The four steps used to make the business case are as follows:

• Delimit the scope of the proposed system This is the identification of the applications boundaries and its relationship to other systems.
• Describe the candidate architecture These contain more detail on the new, difficult, or risky portions of the application with the goal of creating confidence that the team can create a stable architecture.
• Identify the critical risks In addition to simply identifying the risks, a management plan is created to mitigate the risks at the appropriate time.
• Demonstrate that the proposed system is capable of supporting the business case An application prototype along with the initial use case can generate this agreement from the application's customer and user.

The Inception Phase's milestone is the Life-Cycle Objective Milestone.

Elaboration

Like the Inception Phase, the Elaboration Phase is typically limited to at most two or three workflow iterations. The Elaboration Phase maintains a focus on "do-ability." The primary goals of this phase are to deliver the application architecture baseline, to estimate in some detail the cost and the schedule, and to plan for the Construction Phase. The main steps of this phase are as follows:

• Create an architectural baseline This covers significant functionality and features important to the project stakeholders.
• Identify significant risks These should take into account the plan, its cost, and the schedule of later phases.
• Specify quality attributes These include reliability, defect rates, and performance (response times).
• Capture use cases These should include 80 percent of the functional requirements.
• Prepare a project bid This encompasses the schedule, staff requirements, and cost within the limits set by business practices.

The Elaboration Phase's milestone is the Life-Cycle Architecture Milestone.

Construction

In relation to the other phases, the Construction Phase consumes the longest time period and requires the highest resource requirements. It also requires the greatest number of workflow iterations. The Construction Phase is focused on creating the application. Its primary goal is to complete development of the application and ensure that it can begin transition to customers. This transition means the application has achieved initial operational capability and is ready to begin beta testing. Incremental development provides ongoing feature releases with each additional application build. The Construction Phase activities include the following:

• Extend use cases This includes identification of details, descriptions, and realization for all use cases.
• Finish the first three workflows The Analysis, Design, and Implementation Workflows should be completed.
• Start testing About 15 percent of the Testing Workflow should be completed.
• Maintain the integrity of the architecture Changes and updates should be carried out as needed, but within the context of the application's architecture.
• Manage risks Continue managing the risks identified in the earlier phases.

The Construction Phase's milestone is the Initial Operation Capability Milestone.

Transition

The Transition Phase is denoted by the initial beta release of the application to the customer and limited release to the user community. The two primary goals of this phase are to ensure that the product is ready to be released and to train users how to use the product. The additional burden placed upon the application by the user community and the application's true environment provides the necessary testing to determine whether the development process has reached its final milestone: the Product Release Milestone. The Transition Phase activities can include the following:

• Prepare for deployment This includes environment and site preparation and advising the customer on necessary environment updates.
• Prepare documentation This includes operation, user, and other manuals that will accompany the product when it is released.
• Tune the application The product must be prepared for the production environment.
• Correct defects All bugs found during the beta tests must be addressed.
• Modify the application The software might need modification to accommodate problems that were unforeseen earlier in the process.

Iterations

As development of the product continues through its phases, each workflow iteration brings the product closer to its final release. Iterations are continued within a specific phase until the goal for the phase has been reached. The emphasis of each iteration changes as time progresses through the four phases. Figure 4.3, which is based on a diagram in The Unified Software Development Process by Ivar Jacobson et al., shows the amount of effort needed to execute each workflow over the project's life cycle.

Figure 4.3 Workflow emphasis over the project life cycle

Additionally, heavy emphasis is placed on managing the project and creating a development environment during the Inception and Elaboration Phases.

Over the course of time, the amount of detail displayed within each Unified Process model grows, and the models are gradually completed. Figure 4.4, which is also based on a diagram in The Unified Software Development Process by Ivar Jacobson et al., shows that the six primary Unified Process models are almost complete by the end of the Construction Phase, though some fine tuning is usually required to finish the models during the Transition Phase.

Figure 4.4 Detailed model completion over the project life cycle

Ivar Jacobson et al. also note that the important consequences of a Unified Process iterative and incremental approach are as follows:

• To make the business case in the Inception Phase, the organization has emphasized reducing critical risks and demonstrating proof-of-concept.
• To make a business-worthy bid at the end of the Elaboration Phase, the organization has to know what it is contracting to build (represented by the architecture baseline plus requirements) and be confident that it contains no hidden risks (i.e., insufficiently explored cost and schedule expanders).
• To minimize costs, defects, and time-to-market, the organization has to employ reusable components (an outgrowth of early architectural development based on study of the domain in which the proposed system falls).
• To avoid delivery delay, cost overrun, and poor-quality product, the organization has to "do the hard stuff first."
• To avoid building a product that is out-of-date at delivery, the organization can no longer stubbornly say no to all changes. The phased, iterative approach enables it to work changes into development much further along the development trail.