Process Architecture
What is a Software Engineering
Process 
A process is a set of partially ordered steps intended to reach a goal; in software engineering the goal is to build a software product, or to enhance an existing one; in process engineering, the goal is to develop or enhance a process.
Expressed in terms of business engineering, the software development process is a business process; the Rational Unified Process is a generic business process for object-oriented software engineering. It describes a family of related software engineering processes sharing a common structure, a common process architecture.
This common process architecture is the subject of this chapter.
When a software system is developed from scratch, development is the process of creating a system from requirements. But once the systems has taken form (or in our terms, once the system has passed through the initial development cycle), any further development is the process of conforming the system to the new or modified requirements. This applies throughout the system's lifecycle.
The software-engineering process is the process of developing a system from requirements, either new (initial development cycle) or changed (evolution cycle).
Two Dimensions
To understand the form of the Rational Unified Process, consider the following two dimensions:
- Along core workflows, which groups activities logically by nature.
- Along time, the lifecycle aspects of the process as it unfolds
The process is organized both in time (phases), and content (core workflows).
The first dimension represents the static aspect of the process: how it is described in terms of core workflows, activities, workflows, and so on.
The second dimension represents the dynamic aspect of the process, as it is enacted, and is expressed in terms of cycles, phases, iterations, and milestones.
The description of the process often refers to two different viewpoints:
- A technical viewpoint, where the focus is on the artifacts and deliverables attached to the product being developed.
- A managerial viewpoint, where the focus is on time, budget, people, process, and other economic considerations.
In this presentation, we include business modeling as a part of the software engineering process. This is true, if you perform limited business modeling specifically in order to find requirements on an application. Business modeling can also be performed as a completely separate effort with the primary goal to re-engineer the organization, no just build new applications. On this latter case, business modeling is considered a process on its own.
Process Structure
The static content of the process is organized in core workflows that are described in terms of activities, workers and artifacts. The Rational Unified Process is composed of nine core workflows; consisting of six engineering process workflows:
- Business Modeling
- Requirements
- Analysis & Design
- Implementation
- Test
- Deployment
and three supporting workflows:
- Configuration & Change Management
- Project Management
- Environment
Lifecycle Structure
When we consider the dynamic organization of the process over time, the software lifecycle is broken into cycles, each cycle working on a new generation of the product. The Rational Unified Process divides one development cycle in four consecutive phases:
- Inception
- Elaboration
- Construction
- Transition
Each phase is concluded with a well-defined milestone - a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved.
The phases and major milestones in the process.
For a given product, the first pass through the four phases is called the initial development cycle. Unless the life of the product stops, an existing product will evolve into its next generation by repeating the same sequence of inception, elaboration, construction and transition phases. This period is called "evolution." The development cycles that follow the initial development cycle are called "evolution cycles."
Two consecutive development cycles.
Inception Phase
During the inception phase, you establish the business case for the system and define the project scope. To accomplish this you must identify all external entities with which the system will interact (actors) and define the nature of this interaction at a high-level. This involves identifying all use cases, and describing a few significant ones. The business case includes success criteria, risk assessment, an estimate of the resources needed, and a phase plan showing dates of major milestones.
At the end of the inception phase, you examine the lifecycle objectives of the project and decide whether or not to proceed with the development.
Elaboration Phase
The goals of the elaboration phase are to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. Architectural decisions must be made with an understanding of the whole system. This implies that you describe most of the use cases, and take into account some of the constraints: supplementary requirements. To verify the architecture, you implement a system that demonstrates the architectural choices, and executes significant use cases.
At the end of the elaboration phase, you examine the detailed system objectives and scope, the choice of an architecture, and the resolution of major risks.
Construction Phase
During the construction phase, you iteratively and incrementally develop a complete product that is ready to transition to its user community. This implies describing the remaining use case, fleshing out the design, completing the implementation, and testing the software.
At the end of the construction phase, you decide if the software, the sites, and the users are all ready to "go operational."
Transition Phase
During the transition phase you transition the software to the user community. Once the product has been put in the hands of the end users, issues often arise that require additional development to adjust the system, correct undetected problems, or finish some of the features that may have been postponed. This phase typically starts with a "beta release" of the system.
At the end of the transition phase you decide whether the lifecycle objectives have been met, and possibly if you should start another development cycle. This is also a point where you wrap up some of the lessons learned on this project to improve the process.
Iterations
Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system.
Each iteration within a phase results in an executable release of the system.
Each iteration goes through all aspects of software development, that is all core workflows, although with a different emphasis on each core workflow depending on the phase.
This is shown in the following diagram, by the intensity of work in each core workflow as you progress from iteration to iteration across all four phases.
Phases consist of iterations, in which all core workflows are involved. Each core workflow is responsible for a set of artifacts. The height of the curves indicate the amount of resources.
The main consequence of this iterative approach is that the artifacts described earlier grow and mature over time, as shown in the following diagram.
Information set evolution over the development phases.
