| |||||
![]() |
Reaching CMM Levels 2 and 3 with the Rational Unified
Process Table of Contents Introduction The CMM covers practices for planning, engineering and managing
software development and maintenance. These key practices improve the
ability of organizations to meet goals for cost, schedule, functionality
and product quality.
The CMM has five levels of maturity: Level-1 to Level-5. As illustrated
in Figure 1, each maturity level is composed of Key Process Areas (KPAs),
and each KPA identifies a cluster of related activities. When performed
collectively, these related activities achieve a set of goals considered
important for establishing process capability at that maturity level.
Level-2, 'The Repeatable Level' is defined as follows: Projects in Level-2 organizations have installed basic software
management controls. Realistic project commitments are based on the
results observed on previous projects and on the requirements of the
current project. The software managers for a project track software costs,
schedules, and functionality; problems in meeting commitments are
identified when they arise. Software requirements and the work products
developed to satisfy them are baselined, and their integrity is
controlled. Software project standards are defined, and the organization
ensures that they are faithfully followed. The software project works with
its subcontractors, if any, to establish a strong customer supplier
relationship.
The software process capability of Level-2 organizations can be
summarized as disciplined because planning and tracking of the software
project is stable and earlier success can be repeated. The project's
process is under the effective control of a project management system,
following realistic plans based on the performance of previous projects.
Level-2 KPAs are:
Projects tailor the organization's standard software process to develop
their own defined software process, which accounts for the unique
characteristics of the project. This tailored process is referred to in
the CMM as the project's defined software process. A defined software
process contains a coherent, integrated set of well-defined software
engineering and management processes. A well-defined process can be
characterized as including readiness criteria, inputs, standards and
procedures for performing the work, verification mechanisms (such as peer
reviews), outputs and completion criteria. Because the software process is
well defined, management has good insight into technical progress on all
projects.
The software process capability of Level-3 organizations can be
summarized as standard and consistent because both software engineering
and management activities are stable and repeatable. Within established
product lines, cost, schedule, and functionality are under control, and
software quality is tracked. This process capability is based on a common,
organization-wide understanding of the activities, roles, and
responsibilities in a defined software process.
Level-3 KPAs are:
This paper is written for organizational personnel concerned with
achieving organizational maturity Level-2 and Level-3within the CMM
framework.
Level-2,
Repeatable One of the key features of the Rational Unified Process is that it is
Use-Case driven. Use Cases represent a systematic approach to eliciting,
organizing and communicating user requirements. They provide the way to
document functional requirements that serve as a basis for project
development, testing and iteration planning. In the Rational Unified
Process, Use Cases are maintained in a Use-Case Model and referenced
consistently throughout the project lifecycle, from analysis through
testing to maintenance.
The Rational Unified Process artifacts that capture requirements in the
engineering context are:
Goal-1: System requirements that are allocated to software are
controlled to establish a baseline for software engineering and management
use.
The Rational Unified Process advocates on-going configuration control
of all evolving artifacts, however, the 'formal' baselines correspond to
the following milestones: As such, the Rational Unified Process is compliant with the CMM for
agreement on requirements, their management, tracing and baselining.
Goal-2: Software plans, products, and activities are kept
consistent with the system requirements allocated to software.
The emphasis of this CMM goal is to ensure that delivered systems meet
user requirements. The Rational Unified Process helps organizations reach
this goal in two ways:
The Rational Unified Process advocates that each project establishes a
Change Control Board (CCB) that can arbitrate on the scope and impact
(budgetary, technical or schedule) of proposed changes or defects
uncovered during the course of development. To assist the operation of the
CCB, the Rational Unified Process recommends the use of a strong
configuration management and version control tool/environment.
Software Project Planning Goal-1: Software estimates are documented for use in planning and
tracking the software project.
One of the goals of the Rational Unified Process is to ensure that the
expectations of all parties are synchronized and consistent. This is
ensured through periodic assessments throughout the project life cycle,
and is documented in the Status Assessment Report. The report calls for
tracking data on resources (staffing and financial), top ten risks,
technical progress as gauged through metrics and major milestone results.
The Rational Unified Process makes use of the following classes of
metrics:
Rational Unified Process documents that capture project plans and
commitments are:
Goal-1: Actual results and performances are tracked against the
software plans.
As described in the Software Project Planning section, the Rational
Unified Process has several levels of project plans and a Status
Assessment Report that is generated to assess planned versus actual
performance. This report, generated for specific milestones, is the
Project Manager's responsibility.
Major Rational Unified Process milestones correspond to the end of a
phase (Inception, Elaboration, Construction or Transition) and have well
specified completion criteria. Review opportunities exist at minor
milestones at the end of each iteration within a phase, and serve as
decision points and lessons learned for future directions.
For example: 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 most of the use cases would be described, taking
into account some of the constraints: supplementary requirements. To
verify the architecture, a system is implemented that demonstrates the
architectural choices and executes significant use cases.
At the end of the elaboration phase, the detailed system objectives and
scope are examined, as well as the choice of an architecture and the
resolution of major risks. Corrective actions are taken and managed to
closure when actual results and performance deviate significantly from the
software plans.
The Risk List is a Rational Unified Process artifact that provides an
overview of all known risks on the project, and serves as input to
planning and project assessments. Each risk is described in terms of its
impact and a contingency plan that is to be invoked to mitigate the risk
in question. The Risk List is developed along with the Business Case to
form the basis for a "go" or "no go" decision on the project. The Risk
List is maintained throughout the project life cycle.
Goal-2: Changes to software commitments are agreed to by the
affected group and individuals.
The controlled iterative development process, as described in the
Rational Unified Process, ensures that stakeholders get regular visibility
into project progress and any changes that may be necessary to keep the
project on track. Proposed changes are reviewed by a Change Control Board
(CCB) to ensure that they are realistic and can be accommodated into the
overall project schedule.
Software Subcontract Management Goal-1: The prime contractor selects qualified software
subcontractors.
Goal-2: The prime contractor and the software subcontractor agree
to their commitments to each other.
Goal-3: The prime contractor and the software subcontractor
maintain ongoing communications.
Goal-4: The prime contractor tracks the software subcontractor's
actual results and performances against its commitments.
These goals fall beyond the current scope of the Rational Unified
Process and are dependent on the organization.
While subcontracting is not specifically addressed in the Rational
Unified Process, its tools, techniques and mechanisms are assumed to be
flowed down to subcontractors so that the process remains homogenous.
All subcontracting decisions should be documented in the Business Case.
Subcontractors who are following the same development plan as the prime
contractor would also participate in the same technical interchanges,
major milestones, and status assessments.
Software Quality Assurance The Rational Unified Process considers 'quality' to be the collective
responsibility of all project staff and not embodied in any given
organization per se.
Goal-1: Software quality assurance activities are
planned.
Planning software quality assurance tasks is an organizational
responsibility. However, the Rational Unified Process has a number of
attributes that lend themselves to shaping an effective project quality
assurance program.
Each Rational Unified Process milestone has specific completion
criteria that can serve as a basis for auditing. Each activity within the
Rational Unified Process has a separate review activity. Associated with
each review is a set of checkpoints that represent 'gates' that need to be
'passed' before the following activity can be entered.
The Rational Unified Process provides guidance on who should review
given artifacts. For example, the results of "Object Analysis" as
performed by a Designer need to be reviewed by an independent Architect,
Designer, Use-Case Designer and Design Reviewer. Given the defined
Rational Unified Process and artifact review criteria, an objective body
concerned with product quality should easily be able to assess adherence
to process and conformance to development standards and guidelines.
Goal-2: Adherence of software products and activities to the
applicable standards, procedures, and requirements is verified
objectively.
This goal would be met by the adopting organization's quality
personnel. However, the Rational Unified Process provides the necessary
review checklists and document templates that can be applied as project
standards.
Goal-3: Affected groups and individuals are informed of software
quality assurance activities and results.
As described in Software Project Planning, one of the Rational Unified
Process goals is to ensure that the expectations of all parties are
synchronized and consistent. Apart from any input from quality audit
results, the Rational Unified Process calls on reporting on resources
(staffing and financial), top ten risks, technical progress as gauged
through metrics, and major milestone results. The Rational Unified Process
metrics program provides guidelines on the collection of the following
metrics:
This falls beyond the scope of the Rational Unified Process, and is an
organizational responsibility. However, the Change Control Process
described in the Rational Unified Process would enable a mechanism whereby
non-compliances could documented and escalated for resolution.
Software Configuration Management Goal-1: Software configuration management activities are
planned.
As described in the Rational Unified Process, strong configuration
management is an essential element in the controlled iterative development
method. Since software is evolved in stages, it is vital that software
versions from the preceding development effort be available for subsequent
development. Planning how demonstrably working software is to be produced
at each stage is at the core of the Rational Unified Process.
The Rational Unified Process has two major instruments for defining how
a project's software development assets are to be maintained, and how they
are to be integrated:
Goal-2: Selected software work products are identified,
controlled, and available.
The Rational Unified Process Configuration Management Plan calls for a
description of the configuration control and management process to ensure
that work products are indeed identified, controlled, and available.
Goal-3: Changes to identified software work products are
controlled. The Rational Unified Process advocates that a project
maintains a Change Control Board (CCB) and has a Change Management System
to adequately manage, cost, track and implement change requests.
Goal-4: Affected groups and individuals are informed of the
status and content of software baselines.
The Rational Unified Process advocates that requirements, design and
implementation baselines, and traceability between them, are maintained in
electronic format. Any changes to the baselines are arbitrated by various
levels of project control. For instance, requirement-level changes are
considered by the Change Control Board (CCB) for their impact. Design and
implementation changes that are smaller in scope are reviewed at the
appropriate level of technical authority. Approval, control levels, and
the way they are communicated, is described in the Configuration
Management Plan and in the Software Development Plan.
Level-3,
Defined Goal-1: Software process development and improvement activities
are coordinated across the organization.
The Rational Unified Process is an iterative process that relies on the
re-enactment of the "same" defined process over a number of iterations.
This repetitive nature of process enactment, and the assessment of status
metrics and lessons learned at each phase and iteration, provides an
opportunity for fine-tuning the process for each successive iteration.
Goal-2: The strengths and weaknesses of the software process are
identified relative to a process standard.
The Rational Unified Process represents an overall software development
process that can be tailored for effective use on any given type of
project. Guidance on how to tailor the Rational Unified Process is
provided in the Process Configuration Manual and in the Rational Unified
Process Development Kit. Other than technical and management complexity,
some of the process discriminants that will determine the "shape" of the
process to be used on a project are:
This Level-3 goal depends entirely on the adopting organization.
Organization Process Definition Goal-1: A standard software process for the organization is
developed and maintained.
The Rational Unified Process can provide a head start and serve as an
organization's baseline software development process, that can be evolved,
tailored, and maintained.
Goal-2: Information related to the use of the organization's
standard software process by the software projects is collected, reviewed,
and made available.
This goal would need to be supported by the organization that is
adopting the Rational Unified Process.
Training Program Goal-1: Training activities are planned.
This goal can only be met by the organization adopting the Rational
Unified Process. However, the Rational Unified Process is an 'industry
best practices' knowledge base providing guidelines, concepts and detailed
step-by-step descriptions on how to perform various software development
activities. As such, the Rational Unified Process is itself a good source
for training material.
However, Rational Unified Process-related support courses include:
Goal-3: Individuals in the software engineering group and
software-related groups receive the training necessary to perform their
roles.
These training program goals would need to be met by the organization
that is adopting the Rational Unified Process. However, the Rational
Unified Process provides a range of courses, as described in the preceding
section.
Integrated Software Management Goal-1: The project's defined software process is a tailored
version of the organization's standard software process.
In accordance with the Rational Unified Process 'Process Configuration
Manual', the standard delivery of the Rational Unified Process is
configurable and re-scoping for use on various types of projects.
Goal-2: The project is planned and managed according to the
project's defined software process.
This goal would need to be addressed by the organization that is
adopting the Rational Unified Process.
Software Product Engineering Goal-1: The software engineering tasks are defined, integrated,
and consistently performed to produce the software.
The Rational Unified Process activities and definition of what is
required by each worker, against a backdrop of required project planning
artifacts, ensure that tasks are defined, allocated and completed. The
iterative development process inherent in the Rational Unified Process
serves to quickly prove the effectiveness of the software development team
and provides an assessment of the end-product.
Goal-2: Software products are kept consistent with each
other.
Traceability among the engineering models (use case models, design
models, source code and executable components) is maintained by the
environment.
Intergroup Coordination Goal-1: The customer's requirements are agreed to by all affected
groups.
One substantial benefit of using Use Cases as a basis for requirements
capture and description over other "formal" requirements specification
methods is that Use Cases are readily understandable by involved
stakeholders. As such, the Rational Unified Process Use-Case requirements
capture method means that all stakeholders can agree on what needs to be
done. This is further carried through the process and reflected in the
models and reviews that are used as a basis for software development.
Goal-2: The commitments between the engineering groups are agreed
to by the affected groups.
This goal would need to be addressed by the organization that is
adopting the Rational Unified Process. However, Rational Unified Process
visual models facilitate the understanding of what is required at each
stage of product development, from requirements capture to deployment. The
Rational Unified Process Change and Configuration Management process
ensures that proposed changes are appropriately assessed and communicated
to all stakeholders.
The engineering groups identify, track, and resolve intergroup issues.
The Rational Unified Process iterative development process facilitates
early detection of software problems through on-going integration of all
developed software. Integration problems with software that is developed
by a number of teams can serve as a "common space" for raising and
resolving cross-team issues. This notion is supported by the Rational
Unified Process defect and change request process that provides a formal
mechanism for capturing, tracking and resolving project development
issues.
Peer Reviews Goal-1: Peer review activities are planned.
As described in the Quality Assurance goals for Level-2, each activity
within the Rational Unified Process has a separate review activity.
Since early problem detection lowers overall costs, the Rational
Unified Process advocates "early and often" peer reviews of all, and
particularly critical artifacts. The Rational Unified Process provides
checklists of salient features to review at each stage, and within each
model.
Goal-2: Defects in the software work products are identified and
removed.
The Rational Unified Process artifact reviewers have to determine
whether the artifact is ready for the next stage of development. If the
artifact fails to meet the review "pass" criteria, then in accordance with
the Rational Unified Process metrics program, details need to be captured
on:
|
![]() |
Search | How to Buy | Technical Support | Contact Copyright © 1995-2000 by Rational Software Corporation. All rights reserved. Legal information and policies. | Privacy Statement |