# Presentation: 425271

## Decennial’s Processing System’s Approach to Process Improvement

- Presented By: Derrell Matthews
- Processing, Coordination and Requirements Branch
- DSCMO

| Developed and Presented By | Reviewed and Approved By |
| --- | --- |
| Derrell Matthews, Process Manager
Dr. Viet Dang, Process Advisor
Jim Cope, Core Process Member | Dennis Stoudt, Assistant Division Chief
Michael Longini, Division Chief |

**Notes:**
My name is Derrell Matthews, I am a Staff Chief for Processing Coordination and Requirement Staff. I am working Dennis Stoudt. I am here today to talk about the Decennial’s Processing Systems’s Approach to Process Improvement.

## Agenda

- Introduction
- Why this process improvement started?
- BOC Software Development & Maintenance Policy
- Assessment
- Potential Benefits
- Approach to Process Definition
- Established the Core Process Team
- Process infrastructure and inter-relationships
- Document As-Is Process
- Define To-Be Process by utilizing ETVX Method and Sample
- Establish Software Process Improvement Roadmap
- Process Improvement Roadmap
- PSS Functional Infrastructure

**Notes:**
Quickly mention the main bullet from agenda.

## Agenda (cont.)

- Process Improvement Plan and Charter
- Mission
- Roles and Responsibilities
- Progress of the PSS Process
- Status of defined process and its training
- Webpage, shared drive and communication plan
- PSS Peer Review Process
- Purpose & Scope of the Peer Review (PR)
- Roles & Responsibilities
- Peer Review Process
- Peer Review Plan
- Defect Types
- Peer Review Record Form and Log
- Summary and Wrap-Up

## Acronyms/Definitions

**BOC** – Bureau of the Census
**CMM** – Capability Maturity Model
**PSS** – Processing Systems Staff
**PPT** – Project Process Team
**SC** – Steering Committee
**PR** – Peer Review
**PSS** – Processing Systems Staff
**QA** – Quality Assurance
**CM** – Configuration Management
**TP** – Training Program
**PAL** – Process Asset Library
**PAM** - Project Area Manager
**Author** – Creator or writer of a document
**Scribe** – Individual who records meeting minutes
**Moderator** – Individual who conducts the meeting
**Reviewer **– Individual who evaluates the work product

**Notes:**
List of the Acronyms and definitions that will be used throughout the presentation.

## Introduction

**Notes:**
Now I am talking a details about the introduction section.

## Why this Process Started?

- Based from Bureau of the Census 2004 to 2008 Strategic Planning
**Objective 3.2:** Meet geographic requirements of the 2010 Census by developing systems that employ new technologies, enhancing geographic partnerships, and integrating quality assurance measures into the geographic and Master Address File systems and databases.
**Objective 4.5:** Improve the timeliness, accuracy, relevance, accessibility, and cost effectiveness of our surveys and censuses by adopting new applications of technologies and methodologies.
**Objective 5.2:** Promote communication and collaboration within the Census Bureau.

**Notes:**
Due to the increase of the Software Functionality and complexity. There is the need for a consistent, predictable, and repeatable software development process.

Per our division perspective, we follow the BOC 2004 to 2008 Strategic Planning goals. 

Here are three main goals that we want to apply to Processing Systems Staff.
Note: read each of the objective and explain what it is intended

## Bureau of the Census Software Development and Maintenance Policy

- CMM Compliance
- Adherence to the Mandatory Policy Requirements will meet the CMM Level 2 - Repeatable Process criteria.
- Adherence to the Mandatory and Optional Policy Requirements will meet the CMM Level 3 - Defined Process criteria.

**Notes:**
BOC Software Development and Maintenance policy was derived from the BOC Strategic Planning goals.

## The Components of the Assessment

- Methodology
- CMM-Based Appraisal for Internal Process Improvement (CBA-IPI)
- Assessment Team
- Independent Lead Assessor - SEI certified
- CMM training - PSS Managers and Practitioners
- During the Assessment
- Documents Review
- Interview PSS Managers independently from Practitioners
- Results
- Findings and recommendations

**Notes:**
The findings became the inputs into the process improvement initiative.

## Potential Benefits

- Increase knowledge/information sharing across projects
- Maintain software development consistency even with the loss of experienced personnel
- Reduce defects in all products that produced by PSS.

## Approach to Process Definitions

## Established the Core Process Team

- The Core Process Team includes:
- Process Manager
- Process Advisor
- Core Process Member
- The Process Advisor is a process expert with hands-on experience in software process improvement (Capability Maturity Model), project management, coaching and mentoring, training, development, and implementation of the software process.
- The Core Process Team is responsible for:
- Interfacing between the Steering Committee (SC), Staff Chiefs, Process Manager, Staff Process Focal and the PPT Members.
- Preparing organization to adopt the software process improvement initiative
- Conducting process awareness training
- Developing the process definition and methodology
- Implementing the defined processes
- Preparing the process assessment
- Developing the maintenance process for continuous process improvement

**Notes:**
The Core Process Team established the foundation of process improvement based from the organizational culture and infrastructure.

## Process Infrastructure and Inter-relationships

- Policy

*Tailoring*

- Operational

- Process

- Procedure

## Document Approach

**Document Approach**

## ETVX Method(Entry Criteria-Tasks-Validation-Exit Criteria)

**ETVX Method****(Entry Criteria-Tasks-Validation-Exit Criteria)**

## Example of ETVX

**Entry Criteria**
- Complete source code,
- Signed off design document,
- Inspected test plan and test     results,
- User documentation (drafted).

**Tasks**
- Create executable from source code,
- Execute test sets according to plan,
-  Examine results against user documentation and test plan,
- Record any deviations,
- Compile reports on status,
- Deliver results to team leader,

**Validation**
- Examine the test scripts,
- Examine progress against plan for testing time,
- Examine test success rate against goal.

**Exit Criteria**
- All test sets run,
- All results archived,
- All deviations in report database,
- Final report issued to team leader/customer.

**Inputs**

**Outputs**

**Example of ETVX**

- Test software product
- Purpose: Test a software product against its design, ensuring that it works properly.

## Establish Software Process Improvement Roadmap

## Process Improvement Roadmap

- Processing Systems Staff (PSS)  Dennis Stoudt, AD Chief

**Process Improvement Roadmap**

## PSS Process Principles

**PSS Process Principles**

## PSS Functional Process Infrastructure

***Establish and Implement Effective Software Processes***
***to Improve Quality and Reduce Defects ***

## Process Improvement Plan and Charter

## Mission

- The mission of the Processing Systems Staff (PSS) Project Process Team (PPT) is to promote the use of consistent, effective and efficient software processes across projects, instill software process improvement, and thus provide a mechanism for improving quality and reducing cost, schedule and risk.

## Scope

- Software process improvement activities apply to all PSS projects:
- Operational Control Staff
- Software Quality Assurance and Testing Staff
- Processing Coordinating and Requirements Staff
- Special Projects and Products Staff
- Data Conversion Staff
- Process Improvement Project.

## Objective

- The objectives of the PPT are to:
- Establish a foundation for continuous software process improvement.
- Institute Capability Maturity Model (CMM) as the improvement model.
- Coordinate and plan software process improvement initiatives.
- Become more competitive by improving cycle time, reducing defects and improving quality.

## The Domain of the PPT

- The PPT is the Focal Point for Process Related Activities for PSS
- Process Definition
- Process Improvement
- Process Support
- Training
- Quality Assurance
- Configuration Management
- Selection of Tools (e.g., DOORS, ClearCase, etc.)

## PPT Structure

- The PPT is organized into:
- Steering Committee (SC)
- Process Manager (PM)
- Process Advisor (PA)
- Core Process Member (CPM)
- Staff Process Focal (SPF)
- DOORS Focal (DF)
- DOORS Administrator (DA)

## Progress of the PSS Process

## Defined and Approved Operational Plans and Processes

- Software Process Improvement Plan and Charter
- Software Development and Maintenance Process
- Software Quality Assurance
- Software Configuration Management
- Configuration Control Board
- Project Planning
- Project Tracking and Oversight
- Peer Review

## Process Asset Library (PAL)

- The PAL is the central repository for all process-related documentation
- The PAL is accessible to all PSS personnel via the LAN
- The PAL contains organizational standards, best practices, training guidelines, policies, templates, process descriptions, and procedures
- Submissions to the PAL follows a defined process as described in the Change Request (CR) form.

*If you are looking for a process-related*
* **document, it’s probably in the PAL!*

## Process Asset Library Structure

## Webpage Access

## Templates and Forms

## Training Orientation

- Software Quality Assurance
- Peer Review
- Dynamic Object Oriented Requirements Systems 6.0 (DOORS)
- Process Improvement Plan and Charter
- Process Definition
- Software Development and Maintenance
- Software Configuration Management

## Actual PPT Working Website

## Peer Review

## Peer Review Topics

- Purpose & Scope of the Peer Review (PR)
- Roles & Responsibilities
- Peer Review Process
- Peer Review Plan
- Defect Types
- Peer Review Record Form & Log
- Peer Review Summary

## Purpose & Scope of the Peer Review

- Peer Reviews shall be performed on all Processing Systems Staff (PSS) work products according to the Peer Review Procedures
- Peer Reviews shall be conducted to minimize rework due to defects in the work products, and shall focus only on the work product and not the author of the work product
- Peer Review participants shall be trained in the objectives, principles, roles, and methods of peer reviews
- Peer Review action items shall be analyzed, monitored, and tracked to closure

**Notes:**
How are note used?

## Peer Review Roles

- Author
- Moderator
- Recorder
- Reader
- Reviewer(s), who may include:
- Peers
- Testers
- Technical Experts
- QA Coordinator
- Representatives of affected groups

**PR Team Members may perform more than one role, **_**EXCEPT**_** the Author CAN NOT be the Moderator**

## Peer Review Responsibilities

**The Staff Chief** is responsible for identifying work products requiring peer reviews.
**The Quality Assurance (QA) Staff** is responsible for evaluating the peer review activity and reporting the results to the affected groups.
**The affected groups** are responsible for participating in the PR to ensure that the process/software work product being reviewed meets requirements.

## Peer Review Responsibilities (cont.)

**Author** - shall be responsible for initiating a review by notifying a moderator about his or her process/software work product being ready for a review.
**Moderator** - shall be responsible for facilitating the review.
**Reviewers** - shall review the process/software work product to be reviewed.
**Reader** - shall paraphrase the process/software work product during the review meeting.
**Recorder** - shall be responsible for recording the defects in the review meeting.

## Peer Review Process

## Peer Review Plan

- An approved PR Plan shall be the basis for performing all PR activities for the PSS
- The PR Plan identifies work products that must undergo the PR process
- Checklists, forms, processes and procedures shall be used to assist PSS staff in identifying work product defects

## Defect Types

- Document Peer Reviews shall identify defect types including, but not limited to:
**Requirements:**  failure to meet or fully satisfy applicable approved technical requirements
**Editorial:**  spelling, typographical or grammatical error
**Clarity:**  content unclear or confusing; not concise; ambiguous
**Flow:**  no clear or logical transition between sections; faulty logic, process flow or action direction
**Standards:**  failure to conform to applicable standards and practice
**Graphics:**  included graphics inaccurate; confusing; do not illustrate or supplement textual content
**Detail:**  content insufficient in scope or breadth to satisfy requirements

## Peer Review Record

- The PR Record Form shall be used to track the review type, roles, checklists used, life cycle phase, and disposition of the PR

## Peer Review Log

- The PR Log shall be used to track PR work products and their status

## PR Summary	

- Peer Reviews shall be planned, conducted, and tracked
- Peer Review effort shall be measured
- Defects in the work product shall be identified and removed
- PSS staff shall be trained on the PR process
- Peer Reviews shall focus on the work product and not the author of the work product

## PR Summary

## Decennial’s Processing System’s Approach to Process Improvement Summary

**Decennial’s Processing System’s ****Approach to Process Improvement Summary**

- Software Development & Maintenance Policy

- BOC 2004 to 2008 Strategic Goals

- Assessment Team

- ?

- Process Advisor

- Build Process Infrastructure

- We Really Need Lots of Help!!!

## Wrap Up

- Question and Answer Session
- For additional information regarding the process improvement at Processing Systems Staff please contact:
- Derrell Matthews, Process Manager
- E-mail: Derrell.A.Matthews@census.gov
- Jim Cope, Core Process Member
- E-mail: James.A.Cope III@census.gov
- Dr. Viet Dang, Process Advisor
- E-mail: Viet.Van.Dang@census.gov