Configuration Management

This section describes how the GMAT Product Development Team performs Configuration Management (CM). The CM process is performed under the direction of the Product Development Lead (PDL) and the Configuration Management Officer (CMO). The primary CM activities for the GMAT project are described in the table below and later sections describe how each activity is performed. Day-to-day CM activities are guided by the Data Management List and the CM process described in this Chapter.

Area	Activities
Configuration Identification	Define levels of control Roles with change authority Establish baselines Baseline creation and storage
Configuration Control	Establish data storage locations and tools Establish CCB Define CCB responsibilities, authority, and processes Evaluate change requests and approve or disapprove
Configuration Status Accounting	Establishment process to manage change of controlled items Record and monitor changes to evolving CIs
Configuration Audits	Establishment of validation activities that ensure that the software conforms to released documentation and approved changes

Configuration Identification

This section describes the levels of control and change authority for GMAT configuration items, and describes how baselines for configuration items are created and stored.

Levels of Control

The GMAT Data Management List contains a complete list of all project configuration items along with the level of control and the role with change authority for each item. GMAT configuration items are all assigned one of the following levels of control:

Level of Control Acronym	Policy and Requirements
CM	A configuration item which requires version control Changes must be approved by the CCB
VERA	A configuration item which requires version control. Changes can only be made by individuals acting in a role with change authority.
VER	A configuration item which requires version control. Changes can be made by any team member. For CI items defined as VER, the DML contains a (N/A) in the change authority column.
STORED	An item that is not version controlled, such as email, notes, meeting minutes that are simply stored in a documented location.

Change Authority

GMAT configuration items marked as CM or VERA are all assigned an owner by role and only individuals acting in the assigned roles are permitted to make changes to a configuration item. This process ensures that changes to configuration items are made only by those with the required expertise and if necessary, CCB approval is obtained. For example, only software developers can modify source code and make files, only flight dynamics engineers can modify mathematical and algorithmic specifications. Roles for the GMAT project are defined in the Roles and Responsibilities sections. The DML contains a complete list of configuration items and the role with change authority for each item. The next section describes which roles have change authority for major project configuration items.

Planned Baselines

The table below contains a summary of baselined configuration items along with their level of control, change authority role, and project phase when baselined. As new configuration items are identified, they are added to the DML along with the required level of control and change authority. Only configuration items shown in the table below are baselined. Baselines are created and maintained through the process described in the next section.

Configuration Item	Level of Control	Change Authority	Phase when Baselined
Feature Prioritization	CM	CCB	Cycle Start
Product Plan	CM	CCB	Cycle Start
Requirements Specification	CM	CCB	Release
User Interface Specification	VERA	CCB	Release
Feature Specification	VERA	SE/DE	Release
Mathematical Specification	VERA	FDE	Release
Design Specification	VERA	SE	Release
Source Code	VERA	SE	Release
Build/Make Files	VERA	SE	Release
Doxygen Output	VER	N/A	Release
User's Guide	VERA	TW	Release
Version Description Doc.	VER	N/A	Release
Test Plan	VERA	TE	Release
Requirements to Test Matrix	VER	N/A	Release

Creation and Storage of Baselines

The GMAT team creates and stores baselines for all configuration items stored on SourceForge and Jazz by creating Tags in the revision control software and by creating repository branches for each major release. After code freeze for a release, a tag is created in the revision control system using the release ID (2012a for example). Next, a branch is created in the repository structure with a duplicate of all versioned items at the time of the release. The Tag ensures that all configuration items in the revision control system can be retrieved by release ID. The branch ensures that the GMAT team can address critical issues in a specific release and provide an incremental build for users years after the initial release date. This is important when switching to a new version that is unacceptably risky to a customer and the best solution is to fix a bug in the version approved for use by the customers organization.

Configuration Control

The section below describes policies and procedures for making changes to GMAT configuration items, the primary storage location for those items, and the organization and function of the CCB.

Data Storage Locations

The GMAT team uses the primary data storage locations shown in the table below. Similar types of data are stored in different locations so that code and documents approved for public release are publicly available while code/docs not yet approved for release – or that are proprietary or potentially ITAR – are firewalled. Configuration items approved for public release under the NASA Open Source Agreement (NOSA) are located on the project's SourceForge page. All other configuration items that require version control are stored on the JAZZ server maintained by Code 580. Backups of the SourceForge repository are performed monthly by the GMAT team. Backups of the JAZZ repository are performed (Daily ??) by code 580.
The GMAT team uses Google docs for selected project documentation to facilitate collaboration and co-authoring and reviewing of documents. The publicly available google docs service is used for docs related to publicly approved material. The NASA google docs Paul Arnold: Is NASA google docs located somewhere different? How does this work?
stevenphughes: There is a bigger issue. We can't use Google docs for this and need to come up with another solution.service is used for material not approved for public release and these documents are not available to the public until approved for release.

Name	What is Stored	Type of Control	Location
Source Forge	Files approved for public release: Code Data Build files Prototypes Documents	Manual Version Control	https://gmat.svn.sourceforge.net/svnroot/gmat
Jazz	Files not approved for release yet, items that are proprietary, or ITAR: Code Libraries Documents Test system	Manual Version Control	https://gs580s-jazz.ndc.nasa.gov/svn/GMAT
Google Docs	Initial file generated for use on the GMAT project.	Automatic Version Control	https://docs.google.com
Personal Hard Disk	Individual data SBU data	Stored Manually	Team member's personal hard disk

Configuration Control Board

The GMAT Configuration Control Board (CCB) is composed of selected members (by role) of the product development team and provides documented authorization for all changes to configuration items defined as CM-level control in the Data Management List. CCB members are selected to ensure broad interdisciplinary representation, and additional subject matter experts are selected as needed for the material under review. The Acting CCB (ACCB) is formed when the PDL or designee selects team members and subject matter experts for the purpose of analyzing or approving a requested change or issue for a CM-level configuration item. The Acting CCB for one type of request may be different than the Acting CCB for another request. For example, approval of changes to software requirements requires may require a different set of individuals than changes to the product plan or test plan.
Most CCB decisions are made during weekly GMAT meetings and do not require a meeting for the sole purpose of performing CCB activities. These decisions are marked as CCB approved in the weekly meeting minutes and the initials of the Acting CCB members are added to the meeting minutes. In the rare event that a meeting is held just for the sole purpose of CCB activites, the minutes are documented in the same manner as the weekly meetings. Additionally, to ensure efficiency of GMAT development process, ACCB concurrence can be documented electronically without an in-person meeting by obtaining electronic signatures in the issues tool discussed Issues Tracking section of the Management Approach chapter.

Defect Reporting

Software defect reports are managed in the project's Bugzilla database (see DML for URL). Processes for reporting and resolving defects are discussed in detail in the GMAT Test Plan and only a high level overview is included here. Defects related to the GMAT application are classified by feature area. There are special categories for documentation, test system, and other types of defects. All defects follow these basic steps:

New – The initial state of a defect report.
Assigned – Assigned to an individual for analysis and tracking. If the bug is marked as P1 (Priority 1), then the assignee is the individual responsible for addressing the defect.
Needs Test – The assignee has resolved the defect, unit tested, and passed the issue to tester so if appropriate, a test case is added to the regression system.
Needs Documentation - The defect has been resolved; if necessary, explain the issue in documentation.
Resolved – There is no remaining work; the defect is closed.

The prioritization of a bug is used to indicate that it has been approved for resolution. Defects marked as P1 must be addressed by the next major release. Defects marked as P2 are bugs that should be fixed if the schedule allows. Defects prioritized as P3 or below will not be addressed in the next release.

Configuration Status Accounting

The purpose of Configuration Status Accounting is to record and monitor changes to evolving CIs throughout the project life cycle. The change history for configuration items maintained in the project's SourceForge or Jazz repositories is automatically documented for all of these items by Subversion (SVN). SVN client software such as TortoiseSVN or SmartSVN provide tools to view the change logs of all version controlled files. Below is the change log for a randomly selected source code file. All GMAT configuration items that require configuration status accounting are maintained in a SVN repository.

Figure: Log Messages

Additional configuration status accounting items are CCB minutes, discussed in the Meeting Minutessection, Configuration Audit reports, discussed in the configuration audits section.

Configuration Audits

Configuration audits are performed to maintain the integrity of the configuration baselines. Specifically, audits ensure that developed and installed products meet their technical requirements, that the products are accurately described in documentation, and that the products do not include any unauthorized changes. The CMO will conduct configuration audits, document and retain the audit results as indicated in the DML, and forward the audit results to the PDL and/or relevant stakeholders. The PDL and members of the PDT will work closely with the CMO to resolve any problems identified in the audit results.
The CMO will conduct the following configuration audits:

Baseline audit will be conducted for major releases. A Baseline audit verifies that the content and versions of the CIs are consistent with the baseline documentation that defines them (i.e., the Baselines Table). See Planned Baselines for content description.

Physical Configuration audit(PCA) will be conducted for major releases. The PCA verifies that a CI, as built, conforms to the technical documentation that defines it (i.e., it verifies that all baseline elements of the delivery match the documentation). During this audit, the CMO will analyze the following to assure that the documentation is accurate:
- Baselines Table
- DML
- Version Description Document (VDD)
- Physical contents of the project's CM Libraries (where the CIs reside)

Functional Configuration audit(FCA) will be conducted for major releases. The FCA verifies that the CI has been completed satisfactorily, that the item has achieved the performance and functional characteristics, and that its operational and support documents are complete and satisfactory. During this audit, the CMO will analyze the:
- Requirements Traceability Matrix
- Requirements documentation
- Test reports
- Change authorizations

Control of Non-conforming Products

Issues related to non-conforming products are managed using the Issues Tool described in the Issues Tracking section. Any member of the PDT may fill out a problem report (i.e., non-conformance) against any system product or tool at any time. Issues are reviewed monthly or at the request of any team member or stakeholder. All non-conformance issues that adversely impacts the cost, schedule, or scope of the effort are reported to stakeholders and customers for approval of the proposed solution.

Control of Customer-Supplied Products

There are currently no customer supplied products.

Browser not supported