Software Engineering

Participate in the SWE-IPT.
 The senior representatives of the software test and 
evaluation organization should participate in the SWE-IPT to contribute to mak-
ing favorable software architecture decisions. The representatives from software 
test and evaluation bring their knowledge of the testing demands and challenges 
to the SWE-IPT.

---

313
18.1 
Preliminary architecture definition
2. 
Identify software test and evaluation challenges, constraints, and risks
. As the 
component architecture is derived via the software engineering process, senior 
representatives of the software test and evaluation team should identify imple-
mentation challenges, constraints, feasibility, and risks associated with the 
requirements baseline and functional and physical architecture alternatives.
3. 
Prepare software test plan.
 The software test and evaluation organization must 
refine the software test plan. The software test cases should be derived by iden-
tifying test threads within the operation model. A test case describes the initial 
test environment state; inputs, actions, or events that occur throughout the test 
conduct; and the expected software response, or results of data processing transac-
tions. This plan must identify the test and evaluation tasks, work packages, and 
schedule milestones for establishing the software acceptance test environment and 
procedures, qualifying the test environment, and performing acceptance testing. 
This plan will not have the requisite clarity necessary to be executable due to the 
amorphous state of the structural configuration. However, it should provide a more 
accurate forecast of the anticipated workload than previous versions of the plan.
4. 
Conduct software quality assurance inspections and audits.
 Software quality 
inspections should be conducted periodically to examine software engineering 
artifacts and products to ensure that they are complete, accurate, and conform to 
established policies and procedures. Software quality inspections should be con-
ducted to ensure that organizations are complying with established procedures 
and are observing approved plans. The following software quality inspections 
should be conducted during the preliminary architecture definition effort:
●
  Inspection of the functional hierarchy
●
  Inspection of the functional component specifications
●
  Inspection of the functional unit specifications
●
  Inspection of the conceptual configuration documentation
●
  Inspection of organizational technical plans
●
  Inspection of the software nomenclature register
●
  Inspection of the requirements traceability matrix
Software audits should be conducted prior to the PDR to ensure the software 
products and architectural artifacts are complete and have incorporated approved 
change proposals and requests. The following audits should be conducted:
1. 
Functional architecture audit
. Tracing the functional element requirements from 
the originating source (stakeholders’ needs) through the operational model, 
requirements baseline, and functional architecture. The source for derived func-
tional elements should be traceable to architectural decisions or the result of 
engineering analysis.
2. 
Acceptance test case audit
. Tracing each test case to the specification require-
ments it is intended to validate. A test case must be traced from an operational 
thread (operational model), to the source of the requirements (stakeholder 
needs), to the specified requirement (specification identifier) it is intended 
to qualify. A software test may affect one or more of the architectural 

---