ProPath Documents and PMAS Outcome Assessments

ProPath Documents and PMAS Outcome Assessments

PMAS Required Artifacts

  1. Requirements Specification Document (RSD)
  1. Project Charter
  1. Integrated Project Team (IPT) Charter
  1. Acceptance Criteria Plan
  1. Quad Chart
  1. System Design Document (SDD)
  1. Project Management Plan (PMP)
  1. Acquisition Strategy
  1. Project Schedule
  1. Risk Log
  1. Enterprise Project Structure (EPS)

Not found in ProPath.

  1. Contract Information
  1. Product Evaluation and Decision Analysis
  1. PMAS Readiness Checklist
  1. Customer Acceptance Form

PMAS andotherProPath Documents

  1. Updates to PMAS Required Documents

ProPath also defines updates to initial project documents; they are necessary to track modifications to original documents throughout the project life cycle.

  1. Other ProPath Documents to be reviewed duringProgram/Project Assessments

Program/Project Management / ProPath Process
Project Team Kick-off Meeting Agenda and Minutes

Requirements Traceability Matrix (RTM)

Independent Review Summary

Master Test Plan

Configuration Management Plan

Deployment Plan

EA
Requirements Traceability Matrix (RTM)

Conceptual Business Diagram
Template in development
Product Architecture Document

Technical
Product Architecture Document

Section 508 Compliance (non-ProPath)
Master Test Plan

Test Cases and Test Scripts
Document templates in development.
Test Evaluation Summary

Disaster Recovery Plan

System Security Plan
Document template in development
Record of Notification (SORN)

Release Management Plan

Authority to Operate (ATO)
Document template in development
Technical Manual
Document template in development
User Documentation

Concept of Operations

Data
Test Cases and Test Scripts
Document templates in development.
Test Evaluation Summary

Security
System Security Plan
Document template in development
Certification and Accreditation Checklist

Security and Privacy Checklist

Financial Management
Basis of Estimate (part of VA300)
Work Breakdown Structure (part of the Project Management Plan)

Acquisition Management
Acquisition Plan

Contract Information

Project Planning

  • Acquisition Plan

This plan addresses acquisition activities such as acquisition of hardware, software and infrastructure services as well as suppliers who will provide and maintain these tools and provide support in the development, testing and maintenance of the system.

Q1: What were the regulations considered when devising the plan?

Q2: Describe the approach for vendor orientation.

  • Contract Information

It is used to document the approval of the Contract Information Collection during the Formal Review. It ensures the accuracy and timeliness of contract information.

Q1: Did all required stakeholders sign this document?

Q2: What is the recommended course of action by Contract Action Team?

Project Launch

  • Record of Notification

This is a component which ensuresthat communications between stakeholders are recorded.

  • Project Team Kick-off Meeting Agenda and Minutes

This document helps determine whether project and/or increment data, goals, etc. were shared amongand agreed upon by stakeholders at the start of the project and/or increment.

Q1: Were all stakeholders present?

Q2: Have all action items assigned been resolved?

Project Monitoring and Control

  • Independent Review Summary

This document is still in development.

Monthly Reports

<none>

Requirements Elaboration

  • Requirements Traceability Matrix (RTM) + updates

This is a report documenting traceability relationships between requirements, rules, and associated work products, and assists in identifying areas of suspect traceability. Having this document available helps determine traceability of high level requirements to lower level requirements and the relationship of requirements to associated work products.

Q1: How have risks, action items and issues been captured?

Q2: Has the project schedule been updated as the RTM was revised?

Product Architecture

  • Conceptual Business Diagram

Template in development

It documents the vision for a single business area or system, and a high-level business system that will achieve that vision. It frames what is expected of the solution’s ultimate capability and functionality to baseline the system concept.

Q1: How have the business process, organizational and technology perspectives been addressed?

Q2: Does the diagram reflect the potential impacts the business solution may have on the business?

  • Interface Control Document + updates

It describes the relationship between two components of a system in terms of data items and messages passed, protocols observed and the timing and sequencing of events. The benefit of reviewing it is that it represents one important building block for architecting and designing the solution.

Q1: Are solution interfaces consistent with enterprise standards and industry best practices?

Q2: How was the impact on touched systems evaluated?

  • Product Architecture Document + updates

This document provides an architectural overview of the solution. It completely describes the Use-Case, Logical, Process, Deployment, and Implementation sets of views.

Q1: What applications support what processes?

Q2: What is the logical design of the security mechanisms?

Architecture Evaluation

  • <none>

Product Design

  • <none>

Design Evaluation

  • <none>

Test Preparation

  • Master Test Plan

This plan identifies the items to be tested, high-level test activities, organizations and roles responsible for testing and the risks associated with this plan. The benefit of adding this document is that it renders a complete picture of the solution testing.

Q1: What risk-based testing techniques have been considered?

Q2: How are test metrics communicated to the appropriate stakeholders?

  • Test Cases and Test Scripts

Document templates in development.

These documents describe the data sets, rules, methods and procedures used in testing the solution. The benefit of reviewing them is that they help determine whether the right functionality is being built in and if the testing methodology chosen is appropriate for the solution.

Q1: Are the planned test cases and test scripts scalable?

Q2: Have they been approved by the appropriate authority?

Product Build

  • Test Evaluation Summary

It presents a summary analysis of the key results and key measures of the tests for review and assessment. It provides a general statement of the relative quality of the system under test.

Q1: What were the areas that did not perform as expected?

Q2: How were those issues mitigated?

Product Documentation

  • System Security Plan

Document template in development

It ensures that the solution properly addresses security and privacy considerations and is authorized to operate with live data.

  • Technical Manual

Document template in development

This document covers the technical information and prescribes the procedures to be used by the operations and help desk teams.

Q1: Are sections on installation, configuration, systems integration, operations and management, and troubleshooting included?

Q2: Is the document written in a language suitable to the technical level of the O&M team?

  • User Documentation

This document helps end users perform on the new system. It is a detailed how-to manual and includes Frequently Asked Questions and troubleshooting sections.

Q1: Is the document written in a language easy to understand by the average computer user?

Q2: Do procedures include screen shots?

Test and Certification

  • Authority to Operate

Document in development

  • Certification and Accreditation Checklist
  • Security and Privacy Checklist

Release Management

  • Configuration Management Plan

This document describes the processes and procedures for managing and controlling the development, delivery and maintenance throughout the project life cycle. This ensures that project artifacts are baselined and maintained in a stable environment.

Q1: What is the CI structure for this project?

Q2: What team members have privileges to upload new and modified documents?

  • Disaster Recovery Plan

The scope of the plan is the location where the system has been installed. The objective is to ensure the continued operation of the business system.

Q1: Have the responsibilities for each team been clearly specified?

Q2: How many recovery scenarios been developed?

  • Concept of Operations

It describes how a system or an asset will be employed and supported. It provides a reference for determining “fitness for purpose and effectiveness in use.”

Q1: Are the required matrices complete?

Q2: Describe the system-wide operational potential impacts the solution will have.

  • Release Management Plan + updates

This document contains information on what will be released, when, how, to whom, release schedule, go/no go testing, change and configuration management processes.

  • Deployment Plan + updates

Its benefit consists in that it defines a controlled environment and process for setting up the developed system or component into production.

Q1: Does the plan include a communications plan with site managers affected by the deployment?

Q2: Does the plan include a list of issues and corresponding mitigating responses?

Other - no ProPath equivalents

  • Development /Unit Test Government Equipment List (GEL)
  • Functional Configuration Audit Report
  • Physical Configuration Audit Report

1