Is this legitimate? I was told the the CCB should only be a maintenance activity - but it seems it could be for both maintenance and development
A Configuration Control/Change Board should be responsible for version control and establishing baselines for RDT&E, Production (Procurement) and O&M activities. The Configuration Control/Change Board (CCB) is created for version control and establishing software baselines. Versions of software can contain both fixes (System/Software Problem Reports (SPR)) and/or Engineering Change Requests (ECR) which includes new development; However, it is a best practice to have one CCB control everything. This way, you can manage fixes and new capabilities based on the old baselines and prioritize what gets fixed and what can wait. The simpler the management structure the better.
However, it is a software management best practice to have two boards: (1) The CCB for overall programmatic control and, (2) A subordinate board called the Engineering Review Board (ERB) for more in-depth investigation into technical changes to the software. The CCB sits above the ERB and manages everything to include O&M and RDT&E changes. For example, the ERB would create an ECR for CCB approval. The CCB manages and controls the software baselines and version numbering. The ERB is the more technical arm of the CCB and helps the CCB understand the technical impacts of all changes (fixes and new development).
Please see the "Little Gray Book" enclosed on DoD software configuration management best practices at https://acc.dau.mil/CommunityBrowser.aspx?id=550840. This book is the DoD guidance for how to create and manage software configurations; it has complete procedures for how to establish your CCB, ERB, your CM, your CM processes and how everything works together to manage your software.
Open full Question Details