GSP PCIDS SOP.pdf

PCIDS Process Overview

Summary

Persistence Capabilities Integration & Development System (PCIDS) was developed as a means to assess, approve, and track capabilities developed, transitioned, installed, and maintained by GSP. Using the DoD Joint Capabilities Integration and Development System (JCIDS) as a backdrop, PCIDS leverages the Configurations Management II (CMII) process to keep documented requirements clear, concise, and valid to ensure that configurations conform to their requirements in every case. PCIDS is a transparent process that encourages participation and advice from organizations outside of NASIC that have equity in the capability requirements process.

Process Explained

A user tool going through development may have many different capabilities go through the PCIDS Process. For any capability that has an impact to the user, it must go through an OUA. For process for any back-end capability ends once it has been through the CCB. Bug fixes are treated differently than capability development.

Initial Scientific Review Board (iSRB) – Capabilities originating within NASIC GSPR begin with an iSRB.

The iSRB is chaired by NASIC GSPR. At this stage details, scope and plans are decided for the proposed research project.

Initial Engineering Review Board (iERB) – All capabilities that do not originate from within NASIC GSPR start at the iERB. Examples: Capabilities from a Program Management Office, other GSP flights, external partners. The iERB is chaired by the Chief Architect in NASIC GSPO. This is where the technical approach to the development is discussed as well as the plans for testing.

Final Scientific Review Board (fSRB) – This is where the final review of all the research conducted is presented.

Final Engineering Review Board (fERB) – Once all the development is completed for a certain capability, it will be presented to GSPO in the fERB. It is highly encouraged that the developers engage with NASIC GSPO frequently throughout development to improve success at the fERB.

Configuration Change Board (CCB) – Chaired by NASIC GSPO, CCB is the stage where a capability will be approved for install into a production platform environment.

User Acceptance Testing (UAT) – Once the capability has been installed onto a production platform environment, the Government Task Manager will schedule an OUA to get user feedback. The feedback may require additional development which could send the process back to the fERB or CCB stage depending on the depth of the development.

Operational Acceptance Review (OAR) – Program Management Office (PMO) responsible for development of end product chairs the OAR. An OAR is required when a User Tool hits IOC, FOC, or has a major capability addition in between IOC and FOC.

PCIDS Program Level of Review

When determining which level of PCIDS review is required, use the following as a guideline. If you have any questions, please contact NASIC GSPO for further guidance.

Program version numbers determine the level of review:

1. First number (1.x.x.x): Is a major change or introduction of a new version. This project will begin PCIDS at the iERB level

2. Second number (x.1.x.x): Is a minor change to an existing program. This project will begin PCIDS at the fERB level

3. Third number (x.x.1.x) Tracks patches or major bug fixes to an existing program. This project may begin PCIDS at the CCB level*

4. Fourth number (x.x.x.1) Tracks changes less significant than a patch; minor bug fixes. This project may begin PCIDS at the installation level*

*Major Bug fixes, or development capabilities that will not add any new major functionality can go straight to CCB with approval from GSPO. Minor bug fix may go straight to installation with approval from GSPO. GTM’s will decide major versus minor bug fixes, GSPO will provide recommendations on type of bug fix if requested from GTM.

*Finished Capabilities received from outside sources will go straight to fERB to evaluate if the development will work within our architecture prior to moving to CCB. This may result in the capability needing modifications in design or additional development items before passing the fERB.

PCIDS Board Scheduling

PCIDS boards may be convened virtually or as scheduled meetings at the discretion of the board chair. In order to allow for adequate review, confluence page documentation must be completed 48 hours prior to the scheduled board. All scheduling, with exception of self-scheduled Configuration Control Boards (CCB), must be coordinated with the PCIDS Manager.