Activities across the lifecycle:

1. Introduction
2. Inception Phase Activities
3. Elaboration Phase Activities
4. Construction Phase Activities
5. Transition Phase Activities

Introduction

Component-based development is a variation on general application development in which:

• The application is assembled from discrete executable components which are developed and deployed relatively independently of one another, potentially by different teams.
• The application may be upgraded in smaller increments by upgrading only some of the components that comprise the application.
• Components may be shared between applications, creating opportunities for reuse, but also creating inter-project dependencies.
• Though not strictly related to being component-based, component-based applications tend to be distributed.

Throughout this page, "component" is used to refer to these independently developed and deployable components. Elsewhere in RUP, however, we will use the term "component" in the more general sense described in Concept: Component , and qualify as necessary.

The adaptation of the Rational Unified Process (RUP) to dealing with component-based development challenges is discussed below.

Inception Phase Activities

The basic workflow for the Inception Phase applies, with the following extensions or variations:

Project Management

• Activity: Conceive New Project

• The focus of the Task: Develop Business Case is adjusted to take into account that using components change the cost structure of development. In specific, the cost of developing components decreases, but more effort is spent on identifying components and validating that selected components meet their requirements.

• Activity: Evaluate Project Scope and Risk

• Taking a component approach changes the nature of certain risks and introduces new risks. Specifically:

  • externally-sourced components increase risk because they introduce critical elements not under the direct control of the project team
  • externally-sourced components can reduce development time, reducing resource risk
  • externally-sourced components can distort the architecture of the system if they impose architectural restrictions of their own

• Activity: Plan the Project

• In the Task: Plan Phases and Iterations, the plan for the Construction phase may potentially show the project splitting into two different but parallel tracks: one which develops the application-specific and domain-specific components (organized in the upper layers of the architecture - see Concept: Layering), and the non-application and non-domain-specific components organized in lower layers. In some cases, reusable components will be developed by independently managed development teams. The decision to introduce parallel tracks is largely a staffing and resource issue introduced by a desire to manage reusable components as assets independent of the applications in which they are deployed.

Requirements

• Activity: Refine the System Definition

• When refining the requirements of the system, the constraints imposed by the selected component framework need to be captured. Component frameworks improve development productivity in part by restricting the degrees of freedom offered to the software architect and designer. Task: Detail the Software Requirements must focus on documenting these constraints.

Test

• Activity: Define Evaluation Mission

• A test plan identifying the overall intended testing for the project should be created, called the "Master Test Plan".

Environment

• Activity: Prepare Environment for Project

• When collecting and preparing guidelines for the project, see Task: Prepare Guidelines for the Project for details, take into account the specific component framework and the constraints imposed by it. Guidelines should include how to design and code using the framework. They should also provide testing guidance on how to verify conformance with both the component framework itself and with the interfaces defined between components.

Elaboration Phase Activities

The basic workflow for the Elaboration Phase applies, with the following extensions or variations:

Requirements

• Activity: Refine the System Definition

• Task: Detail the Software Requirements additionally focuses on the technical and non-functional requirements and constraints imposed on the components that are either built or purchased. Specific non-functional requirements to consider are size, performance, memory or disk footprint, run-time licensing issues, and similar constraints that will influence component selection or construction.

Analysis & Design

• Activity: Define a Candidate Architecture

• Task: Architectural Analysis uses the component framework and the technical and non-functional requirements to define an initial architecture, including an initial layering scheme and a default set of components and services (represented as analysis and design mechanisms). Task: Use-Case Analysis focuses on identifying architecturally significant components from architecturally significant use cases.

• Activity: Refine the Architecture

• Task: Structure the Implementation Model establishes an implementation model compatible with the component framework structure and the structure and responsibilities of the development team or teams.

  Task: Identify Design Mechanisms will refine the initial design mechanisms to take into account specific framework services and components.

  Task: Identify Design Elements will identify the major, architecturally significant components of the system. Potentially reusable responsibilities should be grouped together to improve reusability; application-specific functionality should be separated from domain-specific and application-and-domain-independent functionality. For purposes of design, components can be represented as Artifact: Design Subsystems. Artifact: Interfaces should be identified for these components/subsystems.

  Task: Incorporate Existing Design Elements will ensure that identified components are consistent and compatible with existing components identified in prior iterations, in the framework itself, or from outside sources.

  The Task: Describe the Run-time Architecture describes the basic process and thread architecture of the component framework, while the Task: Describe Distribution describes the distributed computing environment in which the component application will execute.

• Activity: Design Components

• The Task: Subsystem Design further refines the design of the components, identifying classes within the component which provide the real behavior of the component. In the early stages of the Elaboration phase, there is likely to be a single class, a kind of 'subsystem/component proxy' which acts as a stub to simulate the behavior of the component for architectural prototyping purposes. Later the behavior of this class is distributed to a collaboration of classes contained within the subsystem. These contained classes are refined in the Task: Class Design.

• Activity: Design the Database

• The focus in elaboration is on ensuring that the persistence strategy is scalable and that the database design and persistence mechanism will support the throughput requirements of the system. Persistent classes are identified and mapped to the persistence mechanism. Data-intensive use cases are analyzed to ensure the mechanisms will be scalable. In conjunction with the Testing Activities, the persistence mechanism and database design is assessed and validated.

Implementation

• Activity: Implement Components

  Task: Implement Design Elements must conform to the constraints imposed by the component framework, as described in the Programming Guidelines, provided as part of Work Product: Project-Specific Guidelines. In the Elaboration phase, most of the components will contain a great deal of 'stub' code, as the implementation here focuses on validating the architecture, not producing production-quality code.

Test

• Activities: Define Evaluation Mission, Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets

  The testing activities in Elaboration focus on validating the architecture. For a component-based system, this focus translates to:

  • exercising the interfaces between components, to ensure that component boundaries are appropriate
  • an increased focus on performance testing, especially performance scaling tests, to ensure that anticipated transaction volumes can be sustained
  
  

  Any inherent assumptions in the component framework need to be assessed as well. These commonly include the scalability and throughput of the persistence and transaction management mechanisms, in which hidden assumptions made by the mechanism designer often effectively undermine the application architecture if it does not understand the assumption.

Project Management

• Activity: Plan for Next Iteration

  Using the implementation subsystems as 'logical units of responsibility', the construction work can be partitioned into to or more parallel "tracks": one which focuses on application-specific functionality, and one or more which focus on generic, reusable components. This, of course, depends on having sufficient resources to staff parallel development efforts. The ability to divide the development teams and work in parallel depends wholly on the stability of the architecture, and more specifically on the quality and stability of the interfaces between components. Strong effort in the Elaboration phase will enable this division.

Construction Phase Activities

The basic workflow for the Construction Phase applies, with the following extensions or variations:

Project Management

• Activity: Plan for Next Iteration

  Planning for the first construction iteration was described previously, as it occurs towards the end of elaboration. Follow-on iteration planning, and the ability to divide the development teams and work in parallel, continues to be dependent on the stability of the architecture, and the quality and stability of the interfaces between components.

Analysis & Design

• Activity: Refine the Architecture and Activity: Design Components

  The focus in construction is on analyzing the remainder of the use cases and identifying appropriate components and component collaborations that realize the use cases. The existing architecture is expanded and completed, and the 'internal behaviors' of the component are completely designed and implemented.

• Activity: Design the Database

  The focus in construction is on completing the database design, ensuring that all persistent classes are supported by both the database and the persistence mechanism. This work is performed in parallel and iteratively with the work done in Activity: Refine the Architecture and Activity: Design Components. The ideal organization is to have integrated component teams, with cross-team coordination on persistence issues to ensure a good database design.

Implementation

• Activity: Implement Design Elements

• The work here is similar to that in Elaboration, but the remaining details are increasingly complete as the phase progresses.

• Activity: Integrate each Subsystem and Activity: Integrate the System

• The system is progressively built as the phase continues.

Test

• Activities: Define Evaluation Mission, Verify Test Approach, Validate Build Stability, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets.

Transition Phase Activities

• Product release in the web environment tends to be incremental and continuous, and less focused on traditional distribution of media. Release planning must be adjusted accordingly.
• Production support is increasingly the focus of the phase.
• Data conversion activities are performed.