Design Changes

The following learning objectives are covered in this lesson:

• Identify how instability of user capability needs, design, and production processes impact program cost and schedule.
• Identify the purpose of specific technical reviews and their relationship to the acquisition process.
• Identify the roles, responsibilities, and methods for interface control and technical data management.
• Recognize how configuration management impacts all functional disciplines (e.g., test, logistics, manufacturing, etc.)
• Identify the impact on configuration management when commercial items are used in the system.
• Relate the different types of program unique specifications to their appropriate configuration baselines and technical review requirements.
• Trace the maturation of system design information as it evolves through the acquisition life cycle of a system.
• Identify the relationship between configuration baselines, specifications, and configuration management planning.
• Identify key acquisition best practices, including commercial practices that impact the relationship between government and industry.

1. Technical reviews are conducted throughout the acquisition life cycle to reduce program risk.  They are event-driven, not schedule-driven, and help determine whether to proceed with development or production.  Technical reviews are used to clarify design requirements, assess design maturity, and evaluate the system configuration at various points in the development process.  They provide a forum for communication across different disciplines in the system development process and establish common configuration baselines from which to proceed to the next level of design.

Types of technical reviews include:

• System Requirements Review (SRR), in which the system specification is evaluated to ensure that system requirements are consistent with the preferred concept and available technologies.
• Preliminary Design Review (PDR), in which the top-level design for each configuration item function and interface is evaluated to determine if it is ready for detailed design.
• Critical Design Review (CDR), in which the detailed Product Baseline is evaluated to determine if system design documentation is good enough to begin production (hardware) or final coding (software).
• Test Readiness Review (TRR), in which test objectives, procedures and resources are evaluated to determine if the system is ready to begin formal testing.

2. Configuration management is a systems analysis and control tool that is used in the systems engineering process to control the design of a product as it evolves from a top-level concept into a highly detailed design. Through configuration management, we ensure that designs are traceable to requirements, interfaces are well defined and understood, change is controlled and documented, and product documentation is consistent and current.

Configuration management involves development of program unique specifications and other technical data to document the design.  As design requirements are finalized at different levels of detail, configuration baselines are established to formally document those requirements and to define an item's functional and physical characteristics. The baselines progress from the overall system level (functional baseline), to the more specific configuration item level (allocated baseline), down to the detailed level (product baseline):
 

BASELINE	SPECIFICATIONS	UAV EXAMPLE
Functional ("system specification")	Overall system performance requirements, including interfaces	Night vision requirement
Allocated ("design to" specification)	Item performance specifications.  Performance characteristics of specific configuration items, including form, fit, function requirements.	Specific light level and resolutions that are required of a digital camera for the night vision capability.  Interface requirement for camera to attach to air vehicle.
Product ("build to" baseline)	Item detail specifications.  Process, procedure, material details, technical documentation	Camera shutter design details.  Video transport circuit detailed design. Drawing showing locking mechanism for camera body.

The Government must determine which baselines should come under Government control.  Generally speaking, the Government maintains control of the functional, or system-level baseline; either the Government or contractor can maintain the allocated baseline; and the contractor is usually responsible for the product, or 'build-to' level baseline and below.

3.Interface management involves the control and definition of the boundaries at which product subsystems come into contact with other components of the system.  Effective interface management involves identifying, developing and maintaining the external and internal interfaces necessary for system operation.  Interface management can become a configuration management challenge when a product is modified.

The contractor is usually responsible for design and control of internal interfaces, while the Government is responsible for external interfaces.  An Interface Control Working Group (ICWG) is often used to establish formal communication links between Government and contractor personnel involved in system interface design.

4. Once a system is fielded, configurationmanagement documentation becomes the basis for supporting the system, whether that support is provided by the contractor or by the Government.  Interoperability and maintenance issues can become very problematic if configuration management isn't done properly.  Even minor changes to a commercial item can create configuration challenges and impact logistics, testing, production and other functional areas.

The contractor will ultimately document the functional, performance, and physical characteristics of their product in a Technical Data Package (TDP).  Ensuring that the TDP is comprehensive and updated regularly is especially important if the Government is going to maintain or modify the system.