Software Engineering

16. Software Control Tasks
16.1.1 Identify
Architectural
Elements
(Configuration Administration)
16.2.1 Record Engineering
Change Requests
and Proposals
(Change Processing)
16.2.2 Prepare
Change Evaluation
Packages
(Change Processing)
16.3.1 Assess
Change Technical
Merits
(Change Evaluation)
16.3.2 Assess
Architectural
Consequences
(Change Evaluation)
16.3.3 Assess Technical
Work Package
Consequences
(Change Evaluation)
16.3.4 Assess
Technical Plan
Consequences
(Change Evaluation)
16.4.1 Publish
Change Notification
Package
(Change Assimilation)
16.5.1 Maintain
Engineering Artifact
Repository
(Repository Control)
16.5.2 Maintain
Change History
Repository
(Repository Control)
16.5.3 Maintain
Technical Risk
Repository
(Repository Control)
16.4.2 Audit the
Architectural Change
Progress
(Change Assimilation)
16.4.3 Appraise
the Project
Situation
(Change Assimilation)
16.1.2 Maintain
Architectural
Status
(Configuration Administration)
FIGURE 16.1
Software control tasks.

---

277
16.1 
Configuration administration
requests and proposals that affect the project or contract scope may include aspects 
that impact the technical effort. However, such changes involve a more substantial 
impact to the project than the technical or engineering consequences. Therefore, 
they must be processed formally within the project configuration management sys-
tem. Change proposals or requests that do not impact the project scope should be 
processed within the technical configuration control system.
16.1 
Configuration administration
Software configuration administration provides the day-to-day supervision for the 
configuration of the evolving software architecture. This involves identifying each 
element of the software architecture with a project-unique identifier and maintain-
ing the configuration status records for each element.
16.1.1 
Identify architectural elements
Each element of the software architecture must be uniquely identified to associate 
current and historical information with each element of the architecture. Technical 
configuration identification applies to elements of the architecture that emerge dur-
ing the definition of the software architecture. Early in this definition, the archi-
tectural configuration will experience iterative changes as engineering analysis 
promotes a credible solution. During this period, it may be prudent to resist assign-
ing configuration identifiers until the design is stabilized.
Identification of architectural elements involves software requirements; func-
tional design hierarchies, behavioral models, and functional specifications; and 
structural hierarchies, engineering assemblies, integration strategy, models, proto-
types, and structural specifications. In addition, architectural configuration identifi-
cation must establish product versions and baselines that represent the evolution of 
the architectural configuration. Architectural versioning practices should be estab-
lished that provide a common reference point for incorporating design alterations, 
modifications, and variations within an individual architectural partition.
1
 Architec-
tural baselining practices provide a reference point when the three architectural