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:
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:
The next iteration begins the cycle again with the Requirements Workflow. We will briefly summarize the main workflows of the Unified Process.
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.
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:
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:
The high-level deliverable of the Analysis Workflow is the architectural view of the analysis model. This view consists of:
…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.
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:
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.
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:
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.
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:
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.
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:
The Inception Phase's milestone is the Life-Cycle Objective Milestone.
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:
The Elaboration Phase's milestone is the Life-Cycle Architecture Milestone.
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:
The Construction Phase's milestone is the Initial Operation Capability Milestone.
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:
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: