This Development Case describes how the Rational Unified Process® (RUP®) is applied to the Campbell Prediction System project. It includes such details as:

which activities and artifacts will be used, and which will be dropped,
the relative timing for each phase,
which tools with be used, and,
the level of formality to be applied.

Overview

This project is classified as a small project in the terms of the RUP. As such, the level of formality will be significantly reduced. Many of the RUP disciplines are used, but the number of artifacts is significantly elided. The Business Modeling, Test and Project Managment disciplines are not included in the development case.

Disciplines

Requirements

The purpose of the Requirements discipline is:

To establish and maintain agreement with the customers and other stakeholders on what the system should do.
To provide system developers with a better understanding of the system requirements.
To define the boundaries of (delimit) the system.
To provide a basis for planning the technical contents of iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user-interface for the system, focusing on the needs and goals of the users.

Analysis & Design

The purposes of Analysis & Design are:

To transform the requirements into a design of the system-to-be.
To evolve a robust architecture for the system.
To adapt the design to match the implementation environment, designing it for performance.

Implementation

The purpose of implementation is:

To define the organization of the code, in terms of implementation subsystems organized in layers
To implement classes and objects in terms of components (source files, binaries, executables, and others)
To test the developed components as units
To integrate the results produced by individual implementers (or teams), into an executable system

The Implementation discipline limits its scope to how individual classes are to be unit tested.

Deployment

The Deployment Discipline describes the activities associated with ensuring that the software product is available for its end users. The Deployment Discipline describes three modes of product deployment:

the custom install
the "shrink wrap" product offering
access to software over the internet

Configuration and Change Management

The methods, processes, and tools used to provide change and configuration management for a project can be considered as the project’s CM System. An project's CM System holds key information about its product development, promotion, deployment and maintenance processes, and retains the asset base of potentially re-usable artifacts resulting from the execution of these processes.

Environment

The Environment discipline provides the supporting environment for a project. In doing so, it supports all other disciplines.

Project Lifecycle

Phases

From a management perspective, the software lifecycle of the RUP is decomposed over time into four sequential phases, each concluded by a major milestone; each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

One pass through the four phases is a development cycle; each pass through the four phases produces a generation of the software. Unless the product "dies," it will evolve into its next generation by repeating the same sequence of inception, elaboration, construction and transition phases, but this time with a different emphasis on the various phases. These subsequent cycles are called evolution cycles. As the product goes through several cycles, new generations are produced.

Figure 1. Profile of a typical project showing the relative sizes of the four phases of the Rational Unified Process.

Iterations

An iteration encompasses the development activities that lead to a product release—a stable, executable versions of product, together with any other peripheral elements necessary to use this release. So a development iteration is in some sense one complete pass through all the disciplines: Requirements, Analysis & Design, Implementation, and Test, at least.

Figure 2. Typical iterations within the phases and disciplines employed in the RUP.

Inception Phase

The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

Figure 3. Generic example of tasks and relative timeframes within the Inception phase.

Elaboration Phase

The goal of the elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes.

Figure 3. Generic example of tasks and relative timeframes within the Elaboration phase.

Construction Phase

The goal of the construction phase is on clarifying the remaining requirements and completing the development of the system based upon the baselined architecture. The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.

Figure 3. Generic example of tasks and relative timeframes within the Construction phase.

Transition Phase

The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle.

Figure 3. Generic example of tasks and relative timeframes within the Transition phase.

Artifacts

This section of the development case lists the artifacts that are part of the process, along with guidance on the tools used to create them, comments (which may include tailoring), and whether or not the artifact is a formal deliverable.

Formal deliverables are provided to the customer and must be approved by the customer. Other artifacts are project-internal.

Requirements

Artifact	Tools Used	Comments	Formal Deliverable?
Vision	Microsoft®Word		Yes
Stakeholder Requests	Visual Paradigm®	Requirements Diagrams	No
Use-Case Model	Visual Paradigm®	Use Case Diagrams	No
Glossary	Visual Paradigm®	Textual Analysis	No
Supplementary Specifications	Visual Paradigm®	Requirements Diagrams	No
User Interface Prototype	NetBeans®		No

Analysis & Design

Artifact	Tools Used	Comments	Formal Deliverable?
Architectural Proof of Concept, Prototypes	NetBeans®		No
Analysis Model	Visual Paradigm®	Class Diagrams	No
Design Model Model	Visual Paradigm®	Class Diagrams	No
Software Architecture Document	Microsoft®Word		Yes

Implementation

Artifact	Tools Used	Comments	Formal Deliverable?
Implementation Model including components (source) and builds (modules, executables)	NetBeans®, Visual Paradigm®	The Implementation Model and the Design Model are one-in-the-same within Visual Paradigm.	Yes

Deployment

Artifact	Tools Used	Comments	Formal Deliverable?
Deployment Model	Visual Paradigm®		No
Product	NetBeans®		Yes
End-User Support Material (including Release Notes)	NetBeans®	Built into online help	Yes
Installation Artifacts	HTML	JNLP, Kenai.com downloads, Emxsys.com links	Yes

Configuration & Change Management

Artifact	Tools Used	Comments	Formal Deliverable?
Project Repository	Subversion		No

Environment

Artifact	Tools Used	Comments	Formal Deliverable?
Development Case Document		This document	Yes
Programming Guidelines			Yes

Revision History

Name	Date	Reason for Changes	Version
Bruce Schubert	October 31, 2009	Created.	1.0