Topics

Introduction
Process Overview
Inception Phase Activities
Elaboration Phase Activities
Construction Phase Activities
Transition Phase Activities
A Minimal Development Case

Project Overview

General Tailoring

Disciplines

Additional Concepts:

Additional Guidance:

Introduction

The key to achieving the delicate balance between delivering quality software and delivering it quickly (the e-software paradox!) is to understand the essential elements of the process and to follow certain guidelines for tailoring the process to best fit your project's specific needs. This should be done while adhering to the best practices that have been proven throughout the industry to help software development projects be successful.

No project requires all the activities and artifacts described in the Rational Unified Process (RUP). Small projects, especially, are best served by a light-weight process which enables the project team to spend most of its time developing software, without a lot of administrative overhead. In all cases, it is important not to include activities and artifacts that cannot be clearly justified.

As a project grows and succeeds (which is the objective of all successful small projects!), it will be important to include more and more tools to help automate your team's implementation of the best practices. But the key to success, is to start small, implementing only those essential elements, and add the others when they are clearly needed.

Process Overview

The RUP consists of the following disciplines.

With the possible exception of Business Modeling, all of the above disciplines should be represented in any variant of the RUP, even for small projects. In particular, small projects should focus on best practices, and the essentials of each discipline.

Inception Phase Activities

The basic workflows for the Inception Phase are streamlined, through the focus on the essential activities and essential artifacts.

The Milestone: Lifecycle Objectives completes this phase

Elaboration Phase Activities

The basic workflows for the Elaboration Phase are streamlined, through the focus on the essential activities and essential artifacts.

The Milestone: Lifecycle Architecture completes this phase.

Construction Phase Activities

The basic workflows for the Construction Phase are streamlined, through the focus on the essential activities and essential artifacts.

The Milestone: Initial Operational Capability completes this phase.

Transition Phase Activities

The basic workflows for the Transition Phase are streamlined, through the focus on the essential activities and essential artifacts.

The Milestone: Product Release completes this phase

A Minimal Development Case

The following is an example of Artifact: Development Case for a project of ABC Company, called Project Small. Project Small wishes to adopt minimal process and tools, but still follow the RUP best practices.

Project Overview

Project Small is a team consisting of a project manager and four programmers. The duration of the project is only four months. The stakeholders have good informal working relationships with the development team, and there is no need for formal contracts or reviews. The stakeholders have ongoing visibility during development. The team is highly skilled and disciplined, and has shown in the past to produce quality products without much formal process.

The team believes that they can improve their productivity and the end-product by following the best practices recommended in the RUP. However, given the short time-frame of the project, and lack of experience with integrated toolsets, the team has decided to use a minimal set of tools. A separate parallel activity will be initiated to investigate tool benefits, re-use opportunities, and to further refine the process for future projects.

Roles

Project Small has a small team, so each person is responsible for a variety of RUP roles. The following table provides this mapping:

Project Small Job Title	RUP Role
Project Manager	Project Manager Process Engineer Deployment Manager Requirements Reviewer Architecture Reviewer
ABC Company Executive	Project Reviewer Stakeholder Requirements Reviewer
Chief Programmer	System Analyst Requirements Specifier User Interface Designer Software Architect Design Reviewer Process Engineer Tool Specialist Configuration Manager Change Control Manager and to a lesser extent the same roles as the Programmer.
Programmer	Designer Implementer Code Reviewer Integrator Test Designer Tester
Administrative Assistant	Responsible for maintaining the Project Small web site, assisting the Project Manager role in planning/scheduling activities, and assisting the Change Control Manager role in controlling changes to artifacts. May also provide assistance to other roles as necessary.

General Tailoring

Artifacts and Activities

Project Small uses the essential artifacts of the RUP. Some exceptions are as follows.

The following "essential" artifacts are considered not applicable to Project Small, and so are not implemented:

Data Model - we do not use a database.
Use Case Modeling Guidelines - we are using Use Cases informally and in a small enough group that we will refine our approach to use cases as the project proceeds.

Configuration Management artifacts are not marked as "essential" in the RUP, however, Project Small considers a minimum level of Configuration Management to be essential, as shown below. Project Small also considers Status Assessment and Change Request to be essential, although these may be managed very informally, for example with a project notebook and post-it notes or with email.

All documentation artifacts are provided and maintained exclusively as web pages on the Project Small web site. All templates for these artifacts have been generated as initial drafts of these web pages.

The tailoring of the artifacts implies a certain level of tailoring of the process. Only those activities which contribute directly to the artifacts are considered as a mandatory part of the Project Small process.

Reviews

All artifacts are to be reviewed informally by at least one other person, usually the chief programmer, who approves the artifact before it is considered complete for a given milestone. Any defects found during review which are not corrected prior to releasing for integration must be captured as Change Requests so that they are not forgotten.

Disciplines

Business Modeling

Not used.

Requirements

For details see the Requirements Overview.

Artifacts	Tailoring
Vision	States the main product features. See outline on Project Small web site.
Supplementary Specifications	Supplementary requirements are covered in a section of the Vision web page.
Glossary	Provided on Project Small web site.
Use-Case Model (Actors, Use Cases)	Important actors and use cases identified and flows of events will be outlined for only the most critical use cases. Hand-drawn diagrams and informal descriptions will be the principal means of deriving use cases. Rational Rose is available for those developers who wish to use it, but it is not required.

Analysis & Design

Workflow

For details on the workflow, see the Analysis & Design Overview.

Artifacts

Prototypes	Project small will use executable architectural prototypes to explore critical functionality and architecturally significant scenarios.
Software Architecture Document	A description of the architecture will be captured which briefly describes the architecturally significant use cases (use-case view), identification of key mechanisms and design elements (logical view), plus definition of the process view and the deployment view (of the Deployment Model). The architecture is expected to be similar to previous projects implemented by ABC company, and therefore much of this document will reference existing documentation. The focus of the document for Project Small is to capture any architectural aspects unique to Project Small. See Project Small web site for an outline.
Design Model (and all constituent artifacts)	The design model is expected to evolve over a series of brainstorming sessions in which developers will use CRC cards, and hand-drawn diagrams to explore and capture the design. The Design Model will only be maintained as long as the developers find it useful. It will not be kept consistent with the implementation, but will be filed for reference.

Implementation

Workflow

For details see the Implementation Overview.

Artifacts

Implementation Model (and all constituent artifacts, including Components)

Project Small will use a series of executable architectural prototypes to explore critical functionality and architecturally significant scenarios. The implementation model is captured in the project directory structure rooted at the Project/Small/Implementation folder on the network common drive.

Additional Review Procedures

Informal code reviews are performed. All code must be examined line by line by one other developer, typically the Chief Programmer. Any defects found during review which are not corrected prior to releasing for integration must be captured as Change Requests so that they are not forgotten.

The code will not be released for integration until the reviewer agrees that code and unit testing is of sufficient quality, and that any deferred defects have been properly captured as Change Requests.

Testing

Workflow

For details on the process, see the Test: Overview.

Artifacts

Test Model (and all constituent artifacts)

The team has a great deal of experience in testing on similar projects. There will be no formal test documentation - the documentation is the well-documented test scripts used to drive the system.

The code reviewer is responsible for ensuring that sufficient testing has been done prior to release of code for integration. The Chief Programmer is responsible for ensuring that sufficient integration testing, performance testing, etc. is being performed at the system level.

Deployment

Workflow

For details on the process, see the Deployment: Overview.

Artifacts

Deployment Plan	The schedule and activities for deployment will be captured in the project scheduling tool (see Software Development Plan under management activities).
Training Materials	Online help is the only form of training material to be provided.
Product	(No specific tailoring provided here).
Release Notes	Are built into the online help.
Installation Artifacts	Will be built into the Installation Wizard and online help.
End-User Support Material	Built into online help. Also our company web site has a End User Support page to which we will add a list of Frequently Asked Questions.

Configuration & Change Management

Workflow

For details on the process, see the Configuration & Change Management: Overview.

For Project Small, we have a lightweight configuration management process which ensures that:

Developers know how to submit approved changes for integration.
Baselines are created at milestones.
Work is backed up so that it is not lost.
Stakeholder requests are captured so they can be assessed.

Hand-generated artifacts are stored in a filing cabinet. Softcopy artifacts are snapshot at regular intervals and backed up.

Artifacts

Configuration Management Plan	See outline on the Project Small web site.
Change Request	The primary means of capturing defects is using a text file on the common network drive. Stakeholder requests are to be emailed to the Project Manager - who maintains these to a separate text file on the common network drive. See the Configuration Management Plan for details.
Project Repository	A proposed directory structure is provided on the network common drive, rooted in projects/small/repository.
Workspace	The organization of workspaces is described in Configuration Management Plan.

Project Management

Workflow

For details, see Project Management: Overview.

Artifacts

Business Case	The Business Case has been produced and approved by company management and the customer. It is not expected to be maintained. It may be found on the Project Small web site.
Risk List	Initial project risks have been identified. This risk list is maintained by the Project Manager in a spreadsheet located at: projects/small/management/risks.xls
Software Development Plan	The Software Development Plan is managed as follows. The budget and schedule is managed in a set of Microsoft Project files which may be found on the common network drive at projects/small/management/schedule. Other aspects of the plan are covered as needed on the Project Small web site.
Iteration Plan	See above.
Product Acceptance Plan	Encapsulated in the Software Development Plan.
Status Assessment	At the end of each iteration, the team will meet to discuss the project status and brainstorm improvements. The intent is to capture lessons learned. The project manager will then send an email summarizing the status to the project team and to the stakeholders.

Environment

Workflow

For details on the process, see the Environment: Overview.

Artifacts

Development Case	This document will be maintained on the Project Small web site.
Project-Specific Templates	Initial outlines are provided on the Project Small web site.
Guidelines, such as Design Guidelines and Programming Guidelines.	The Project Small web site provides links to applicable design and programming guidelines.
Tools	The tools to support the project are the standard tools used by all ABC Company projects. One copy of the Rational Suite will be purchased for evaluation purposes.

Rational Unified Process