CMMI Appraisal Rating Guidance

Rating Specific Practices

Code

Name

FI

Practice Fully Implemeted

LI

Practice Largely Implemented

PI

Practice Partially Implemented

NI

Practice Not Implemented

Rating Specific Goals

Code

Name

Goal Satisfied

NS

Goal Not Satisfied

Guidance

A CMMI specific practice should be rated as Fully Implemented if in the opinion of the appraisal team:
1. The UPEDU contains activities that, if performed, would meet all requirements of the specific practice, and
2. The UPEDU identifies output artifacts that, if produced, would provide evidence of the specific practice being undertaken
3. No major or minor weaknesses can be identified in the UPEDU with respect to the specific practice

A CMMI specific practice should be rated as Largely Implemented if in the opinion of the appraisal team:
1. The UPEDU contains activities that, if performed, would meet most of requirements of the specific practice, and
2. The UPEDU identifies output artifacts that, if produced, would provide evidence of the specific practice being undertaken
3. At least one minor weakness can be identified in the UPEDU with respect to the specific practice, and
4. No major weaknesses can be identified in the UPEDU with respect to the specific practice

A CMMI specific practice should be rated as Partially Implemented if in the opinion of the appraisal team:
1. The UPEDU contains activities that, if performed, would meet only some of requirements of the specific practice, and
2. The UPEDU identifies output artifacts that, if produced, would provide limited evidence of the specific practice being und
3. At least one major weakness can be identified in the UPEDU with respect to the specific practice

A CMMI specific practice should be rated as Not Implemented if in the opinion of the appraisal team:
1. The UPEDU does not contain any activities relating to the specific practice, and
2. The UPEDU does not identify any output artifacts that, if produced, would provide evidence of the specific practice being
3. At least one major weakness can be identified in the UPEDU with respect to the specific practice

Guidance

A CMMI specific goal should be rated as satisfied if and only if:

1. All specific practices associated with that goal have been characterised as either Fully Implemented and Largely Implem
2. The aggregation of weaknesses associated with the goal does not have a significant negative impact on goal achieveme

A CMMI specific goal should be rated as not satisfied if:

1. Any specific practices associated with that goal have been characterised as either Partially Implemented or Not Impleme
2. The aggregation of weaknesses associated with the goal has a significant negative impact on goal achievement

Process Area: Configuration Management

Goals and Practices
SG 1
Establish Baselines

Implementation Description

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating
S

SP 1.1

Identify Configuration Items

The UPEDU contains a workflow within the Configuration and Change

Management Discipline called Plan Project Configuration. Within this
Configuration Management Plan
worflow, a person with the role of Configuration Manager is required to
Records from CM Plan review
write a Configuration Management Plan, which will specifically identify the
CM Plan approval documentation
configuration items to be produced throughout the project. This plan will be
reviewed by relevant stakeholders and approved by the Project Manager.

SP 1.2

Establish a Configuration
Management System

The UPEDU requires that a CM Plan be written and that it contains a

description of the configuration management environment. The activity
Create Workspaces within the Change and Deliver Configuration Items
workflow specifically relates to the creation of workspaces within the CM
system.

Configuration Management Plan

Project repository populated with
configuration items

None

FI

SP 1.3

Create or Release Baselines

The UPEDU requires that the project CM Plan contain a list of the
baselines to be created for the project. These baselines are applied to
configuration items in the project as part of the 'Create Baselines' activity
within the 'Change and Deliver Configuration Items' workflow.

Configuration Management Plan

Baselines identified within the CM system

None

FI

SG 2

Track and Control Changes

SP 2.1

Track Change Requests

SP 2.2

Control Configuration Items

The activity 'Make Changes' within the 'Change and Deliver Configuration
Items' workflow describes the control of configuration items. Multiple
version of configuration items are maintained using checkout and checkin
facilities provided by the configuration management system.

SG 3

Establish Integrity

SP 3.2

FI

S
The UPEDU 'Manage Change Requests' worflow defines activities for
ensuring that changes to configuration items are made in a consisten
manner. This workflow requires that proposed changes to baselined
configuration items are submitted, reviewed and approved by the
Configuration Manager and a Configuration Control Board before the
change is allowed to proceed.

SP 3.1

None

Change Requests
Minutes from CCB meeting

None

FI

Configuration items in the project repository

Version history of configuration items

None

FI

Establish Configuration
Management Records

Project repository
The storage of appropriate configuration management records is facilitated Version history for configuration items
by the CM system.
Baselines established in project repository
Configuration Status Accounting Reports

None

FI

Perform Configuration Audits

The project CM Plan identifies the configuration status accounting

Configuration Status Accounting Reports
activities to be conducted. The 'Report on Configuration Status' activity in
Functional Configuration Audit Reports
the 'Monitor and Report on Configuration Status' workflow requires that the
Physical Configuration Audit Reports
Configuration Manager performs periodic checks on the integrity of the
configuration management system and established baselines.

The UPEDU currently provides limited

guidance on how to conduct configuration
audits. The addition of guidelines and
templates in this area may be of benefit.

LI

Process Area: Project Monitoring and Control

Goals and Practices
SG 1
Monitor Project Against Plan

SP 1.1

Monitor Project Planning

Parameters

SP 1.2

Monitor Commitments

SP 1.3

Monitor Project Risks

SP 1.4

Monitor Data Management

SP 1.5

Monitor Stakeholder Involvement

SP 1.6

Conduct Progress Reviews

SP 1.7

Conduct Milestone Reviews

SG 2

Manage Corrective Action to

Closure

SP 2.1

Analyze Issues

SP 2.2

Take Corrective Action

SP 2.3

Manage Corrective Action

t Monitoring and Control

Implementation Description

The UPEDU 'Monitor & Control Project' worflow in 'Project Management'

discipline defines an activity called 'Monitor Project Status' that aimed to
capture current status of the project and evaluate status against plans
(Software Development Plan, Iteration Plan, Measurement Plan).
On this activity, the Project Manager must collect quality and progress
information on the project for assessing current status, derives progress &
quality indicators, and then compares these indicators against the
expected state of the project as defined by the Software Development
Plan and Iteration Plans. The 'Monitor Project Status' activity will produce
metrics data (will be documented in the Project Measurements) that
represent the measurement of certain aspects of the project (the process,
the product, the project, and the resources).

The 'Monitor Project Status' activity also requires the Project Manager to
measure the project teams commitments as one of measurement object
in the Resources aspect. This measurement will be documented on the
'Effort' section in the metrics data that contained in the Project
Measurements document.
The UPEDU 'Project Management' discipline requires the Project
Manager to create the Risk List early in the Inception phase. This Risk
List is maintained throughout the project and is continually updated as
new risks are uncovered and existing risks are mitigated or retired. At a
minimum, it is revisited at the end of each iteration, as the iteration is
assessed.
The UPEDU 'Monitor & Report Configuration Status' worflow in
'Configuration & Change Management' discipline defines 'Report on
Configuration Status' activity that must be performed by the Configuration
Manager. One goal of this activity is to ensure that data is 'rolled-up' and
reported for the purposes of tracking progress and trends.
The UPEDU 'Configuration & Change Management' requires that all data
related with the project (e.g. code and document) must be maintained in
the project repository based on the Configuration Management Plan

The UPEDU doesn't define any spesific activity in order to monitor the
stakeholder involvement during the project.

The UPEDU 'Project Management' discipline requires the Reviewer to

conduct review meetings to review the progress of the project. But these
meetings only for the project team without participation from any
stakeholder.
The milestone reviews also done by the Reviewers in the review meetings
described in the 'Project Management' discipline. Again, the stakeholders
do not participate on these meetings.

The UPEDU 'Develop Software Development Plan' worflow in 'Project

Management' discipline defines 'Review Project Planning' activity that
requires the Reviewers to conduct review meetings during the project. On
these meetings, the Reviewers must review some artifacts (Vision,
Business Case, Risk List, Software Development Plan and its enclosed
plans) to analyze issues and propose strategy how to take corrective
action (when it be needed) .
The UPEDU 'Monitor & Control project' worflow in 'Project Management'
discipline defines an activity called 'Schedule and Assign work' that must
be performed by the project manager to accommodate approved changes
(defects, enhancements), to product and process, which arise during an
iteration. The corrective actions must be taken based on the result of the
review meeting conducted before.
The UPEDU 'Monitor & Control project' worflow in 'Project Management'
discipline also defines an activity called 'Make Changes' to accommodate
the team members' need for access to the set of artifacts to be changed
(change set) in order to take corrective action based on the 'Schedule and
Assign Work' and to fulfill (through performing various activities) the
requirements of their work order.

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Project Measurements
Risk List

None

FI

Project Measurements

None

FI

Software Development Plan

Measurement Plan
Project Measurements
Risk List

None

FI

Project Measurements

None

FI

The UPEDU currently doesn't provide any

guidance on how to monitor the
stakeholder involvement during the
project. The availability of guidelines and
templates in this area must be of benefit.

NI

The stakeholders must be participate on

the review meetings.

PI

The stakeholders must be participate on

the review meetings.

PI

Review Record
Minutes from review meetings
Review Record
Minutes from review meetings

Rating
NS

Review Record
Minutes from review meetings

None

FI

Work Order
Software Development Plan
Iteration Plan

None

FI

Project Repository
Work Order

None

FI

Process Area: Project Planning

Goals and Practices
SG 1
SP 1.1
SP 1.2
SP 1.3
SP 1.4
SG 2
SP 2.1
SP 2.2
SP 2.3
SP 2.4
SP 2.5
SP 2.6
SP 2.7
SG 3
SP 3.1
SP 3.2
SP 3.3

Establish Estimates
Estimate the Scope of the
Project
Establish Estimates of Work
Product and Task Attributes
Define Project Lifecycle
Determine Estimates of Effort
and Cost
Develop a Project Plan
Establish the Budget and
Schedule
Identify Project Risks
Plan for Data Management
Plan for Project Resources
Plan for Needed Knowledge and
Skills
Plan Stakeholder Involvement
Establish the Project Plan
Obtain Commitment to Plan
Review Plans That Affect the
Project
Reconcile Work and Resource
Levels
Obtain Plan Commitment

ct Planning
Implementation Description

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating

Process Area: Requirements Management

Goals and Practices
SG 1
Manage Requirements

SP 1.1

Obtain an Understanding of
Requirements

SP 1.2

Obtain Commitment to
Requirements

SP 1.3

Manage Requirements
Changes

SP 1.4

Maintain Bidirectional
Traceability of Requirements

SP 1.5

Identify Inconsistencies
Between Project Work and
Requirements

uirements Management
Implementation Description
The UPEDU 'Understand The Problem' worflow in 'Requirements'
discipline defines two activities ('Elicit Stakeholder Requests' and 'Find
Actors and Use cases') that system analyst must perform for collecting
and eliciting information from the stakeholders of the project in order to
understand what requirements they need to be provided in the intended
system.
The UPEDU 'Plan for Next Iteration' worflow in 'Project Management'
discipline defines 'Develop Iteration Plan' that Project manager must
perform some steps for developing a fine-grained plan for each single
iteration. One step on this activity is 'Assign Responsibilities' where each
work product that represent a single requirement will be assigned by the
project manager to one or more project team members.
The UPEDU 'Review' worflow in 'Requirements' discipline defines
'Review Requirements' activity that requires the project team to conduct
review meetings during the project. One goal of those meetings is to
review change requests which impact the existing requirements set.
The UPEDU requires that the Software Requirements Specification
(SRS) must define the requirements in a traceable way, facilitates the
backward and forward referencing.
Another goal of the review meetings in the 'Review Requirements'
activity is to identify problems related to the requirements and propose
recommendations for resolution.

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Actor
Use Case
Use-Case Model
Supplementary Specifications
Glossary
Software Requirements Specifications
(SRS)

None

FI

Iteration Plan

None

FI

Review Record
Minutes from review meetings

None

FI

None

FI

None

FI

Software Requirements Specifications

(SRS)
Review Record
Minutes from review meetings

Rating
S

Process Area: Technical Solution

Goals and Practices
Select Product Component
SG 1
Solutions
Develop Alternative Solutions
SP 1.1
and Selection Criteria
Select Product Component
SP 1.2
Solutions
SG 2
SP 2.1
SP 2.2

Develop the Design

Design the Product or Product
Component
Establish a Technical Data
Package

SP 2.3

Define Interfaces Using Criteria

SP 2.4

Perform Make, Buy, or Reuse

Analysis

SG 3
SP 3.1
SP 3.2

Implement the Product

Design
Implement the Design
Develop Product Support
Documentation

nical Solution
Implementation Description

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating

Process Area: Verification

Goals and Practices
SG 1
Prepare for Verification
Select Work Products for
SP 1.1
Verification
Establish the Verification
SP 1.2
Environment
Establish Verification
SP 1.3
Procedures and Criteria
SG 2
SP 2.1
SP 2.2
SP 2.3
SG 3
SP 3.1
SP 3.2

Perform Peer Reviews

Prepare for Peer Reviews
Conduct Peer Reviews
Analyze Peer Review Data
Verify Selected Work
Products
Perform Verification
Analyze Verification Results

Implementation Description

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating

Process Area: Product Integration

Goals and Practices
SG 1
Prepare for Product Integration
SP 1.1 Determine Integration Sequence
Establish the Product Integration
SP 1.2
Environment
Establish Product Integration
SP 1.3
Procedures and Criteria
SG 2
SP 2.1
SP 2.2
SG 3
SP 3.1
SP 3.2
SP 3.3
SP 3.4

Ensure Interface Compatibility

Review Interface Descriptions for
Completeness
Manage Interfaces
Assemble Product Components
and Deliver the Product
Confirm Readiness of Product
Components for Integration
Assemble Product Components
Evaluate Assembled Product
Components
Package and Deliver the Product or
Product Component

Integration
Implementation Description

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating

Process Area: Requirements Development

Goals and Practices
SG 1
Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2

Develop the Customer Requirements

SG 2

SP 2.3

Develop Product Requirements

Establish Product and Product
Component Requirements
Allocate Product Component
Requirements
Identify Interface Requirements

SG 3

Analyse and Validate Requirements

SP 2.1
SP 2.2

SP 3.1
SP 3.2
SP 3.3
SP 3.4
SP 3.5

Establish Operational Concepts and

Scenarios
Establish a Definition of Required
Functionality
Analyze Requirements
Analyze Requirements to Achieve
Balance
Validate Requirements

ments Development
Implementation Description

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating

Process Area: Validation

Goals and Practices
SG 1
Prepare for Validation

SP 1.1

Select Products for Validation

SP 1.2

Establish the Validation

Environment

SP 1.3

Establish Validation
Procedures and Criteria

SG 3

Verify Product or Product

Components

SP 3.1

Perform Validation

SP 3.2

Analyze Validation Results

Implementation Description
The UPEDU contains a workflow within the 'Test' discipline called 'Plan and
Design Test'. Within this worflow, persons with the role of Testers are
required to write a Test Plan. The Test Plan must specifically define the
products/items for the validation (i.e. testing) process. List of products that
will be validated are listed on 'Requirement for Test' section of the Test Plan
document. This list is represents what will be validated.
The UPEDU requires that a Test Plan be written and that it contains a
description of the validation environment that will be used during the
validation (i.e. testing) process. The validation environment is described on
the 'Resources' section of the Test Plan document.
Test Plan contains a section named 'Test Strategy' which contains a subsection named 'Test Type'. The 'Test Type' sub-section describes the
procedure and the criteria for the validation process for each functionality on
the product/product component.

Within the 'Execute Test' workflow, Testers are required to perform 'Execute
Test' activity. This activity represent the validation process and performed by
Testers to validate the products/product components based on procedure
and criteria defined in the Test Plan.
Within the 'Execute Test' workflow, Testers are required to perform 'Evaluate
Test' activity. This activity is aimed to evaluate the test results and log
change requests, calculate and deliver the key measures of test, and
generate the test evaluation summary.

Direct and Indirect Artifacts Produced

Opportunities for Improvement

Rating
S

Test Plan

None

FI

Test Plan

None

FI

Test Plan
Test Cases

None

FI

S
Test Results
Defect

None

FI

Test Evaluation Report

None

FI