Software Engineering

5. 
Software unit test results.
 The results of software unit testing should be docu-
mented and captured in the unit SDFs.
6. 
Software component assembly, integration, and test procedures.
 The software 
integration strategy should be detailed by establishing the procedures necessary 
to compile, assemble, and link (integrate) source code files into an executable 
file to support software component testing. The software component 

---

326
CHAPTER 19 
Software Implementation
 
test scenarios and procedures should be described and captured in a component 
SDF.
 7. 
Software integration test results.
 The results of software integration testing 
should be documented and captured in the component SDFs.
 8. 
Dry-run test report
. The dry-run test report should summarize the test results, 
problems, and defects encountered. Each software problem or defect should be 
assigned to the organization responsible for resolving the issue. The associated 
set of regression tests that need to be conducted on the repaired software prod-
uct must be identified. This report will be used in determining the readiness of 
the software product to commence acceptance testing.
 9. 
Acceptance testing report.
 The acceptance testing report should summarize the 
test results, problems, and defects encountered (
there should be no problems 
or defects encountered!
). Each software problem or defect should be assigned 
to the organization responsible for resolving the issue. The associated set of 
regression tests that need to be conducted on the repaired software product 
must be identified. This report will be used in determining the readiness of the 
software product for operational deployment.
10. 
Software build procedures.
 The software build process should be defined, 
which establishes the manner by which the source code files are assembled, 
integrated, and verified to produce executable files for distribution. The build 
procedures should address the following tasks and automated support to script 
calls to compiler and link editors:
●
  Compiling source code into binary code.
●
  Packaging binary code libraries as extractable files.
●
  Verifying build integrity.
●
  Distribution of extractable executable images.
●
  Creating documentation and/or release notes.
●
  Release and patch (binary file fixes) coordination.
11. 
Software problem reports
. Software problem reports should be generated for 
problems or deficiencies uncovered during software implementation.
12. 
Engineering change requests (ECRs).
 ECRs should be generated to capture 
a desired change to the software architecture. Each ECR should include the 
necessary specification and documentation change pages that will be used to 
assimilate the change into the architectural artifacts, and documentation con-
sistent with the proposed change, if approved.
13. 
Prepare waivers and deviations (as necessary).
 Waivers or deviations to a 
requirement in one of the baselined software specifications should be  
prepared and submitted to the project-level change control board (CCB) for 
approval. Deviations do not relieve the program from achieving the speci-
fied requirement, but will permit the initial release of the software product 
with an understanding that the problem will be corrected in a future patch or 
release. Waivers relieve the program from the necessity to satisfy a specified 
requirement.

---