PLCS Statement of Technical Requirements. Technical Requirements Product Life Cycle Support. Configuration Management, страница 25

5.7  Product Configuration Change

5.7.1  Change Control Basics

A need for change to the baseline configuration may arise from[32]:

·  an enhancement: a new or improved product_requirement;

·  a discrepancy: product_instance(s) based on the same design that fails to meet one or more product_requirement. A discrepancy may be a functional design, physical design or a support design discrepancy;

·  a mission need: a product_instance that is reconfigured, in one of the permissible configurations, for a mission;

·  a repair activity:  a product_instance defective component[33] is replaced by a spare part ( the product_instance structure is changed).

The configuration change activity results in the creation of new data instances, such as new part/assembly identifications and new relationships. Diagram in figure 12 illustrates, for each of the above triggers for change, the product objects that are affected.

Figure 12 – Product Objects affected by different Change Triggers

For example:

(1)  an enhancement may trigger the creation of new instances of product_requirement, product_design and product_instance;

(2)  a support discrepancy may result in new support design data and new product_instance/product_design relationships;

(3)  a configuration change for a mission need may create a new product_instance structure but would not affect product_requirement and product_design.

5.7.1.1  Change Process

The key components of configuration change are: (1) request, (2) implementation directive[34], (3) actual resolution.

The following are some data requirements to support the change process:

75.  the change process normally starts with a request that could be either a request for initial issue or a change request;

76.  a change request may be either a request for enhancement or a request to correct or accept a discrepancy[35];

77.  a request for enhancement may be triggered by a new, user defined, usage_scenario or a new user product_requirement.

78.  a request is submitted by an organization at a certain point in time (date and time);

79.  the requesting organization assigns an identifier to the request. The identifier is to be unique within the organization domain. The combination of the requesting organization identifier and the request identifier will uniquely define the request;

80.  the request identifies either the baseline product_concept, product_requirement, product_design and/or product_instance that are impacted by the request;

81.  an initial issue request should address a product_concept and its product_requirement baseline;

82.  an enhancement related change request should address a product_requirement or product_design and may address a product_instance baseline;

83.  a discrepancy related change request should address either a product_design or a product_instance baseline;

84.  a discrepancy related change request should include a narrative identifying the reason how and why the non-conformance occurred and the detection method that was used to determine the anomaly;

85.  a request may be referenced by zero, one or many approvals[36]. The approval related information includes: (a) approval status; (b) approval level; (c) date and time of approval; (d) approval organization and organization role; (e) relationship with other approvals;

86.  an approved request may be referenced by zero, one or many implementation_directive[37];

87.  an implementation_directive describes the resolution applied to the related request. It may include description of tasks, manpower, facilities, parts, kits, support equipment, money needed to apply the actual resolution. It also identifies the organization responsible for applying the actual resolution and the timetable for finalization;