Software Engineering

310
CHAPTER 18 
Software Architecture Definition
 
stakeholder needs and expectations, and opportunity to achieve program cost 
and schedule objectives. The SWE-IPT should evaluate identified conflicts 
between the functional and initial physical architectures to determine potential 
courses of corrective action. Viable approaches to resolving architectural con-
flicts should be explored and evaluated against program objectives and stake-
holder needs. The software implementation and testing challenges and risks 
associated with each approach must be identified. The alternative approaches 
should be prioritized to facilitate architectural decision making.
 5. 
Specify the functional architecture.
 The SWE-IPT should conduct software 
requirements analysis to coherently specify functional component and unit 
requirements. The internal software interface or data exchange requirement 
must be stipulated for the transmitting and receiving functional element. The 
control, error handling, and resource regulation mechanisms must be desig-
nated to preclude ineffective solution.
 6. 
Verify the functional architecture.
 As the functional architecture matures it 
must be verified to ensure that it reflects a solution that satisfies the require-
ments baseline and is achievable within program objectives. When the require-
ments baseline and functional architecture are aligned, the requirements 
traceability matrix must be updated to reflect how the software requirements 
have been allocated among the elements of the functional architecture. The 
requirements traceability matrix should associate the elements of the func-
tional architecture to elements of the requirements baseline and test cases.
 7. 
Update risk mitigation plans.
 Risk mitigation plans should be prepared for 
those risks that could not be eliminated or avoided and still threaten the 
achievement of program objectives. Risk assessment reports should capture 
the results of each risk assessment, including the probability of occurrence, 
and the consequences should the risk be realized. Risk mitigation plans should 
identify the course of action being taken to monitor and prevent the risk from 
occurring, the criteria that would make the risk unacceptable to proceed as 
planned, and the contingency actions that would be executed should the risk 
deviation criteria be encountered.
 8. 
Revise technical plans.
 The tasks identified in the work packages need to be 
reexamined and refined to accurately reflect the work remaining to be performed. 
The technical plans should be revised and the program work breakdown structure 
(WBS), work package, and resource allocations must be adjusted to reflect the 
improved understanding of the remaining scope of the development effort.
 9. 
Refine project plans.
 The program plans for the remaining stages of the soft-
ware development project should be updated to reflect the remaining scope 
of the development effort. The program plans must be living documents and 
reflect the design decisions that have been made on the scope of work remain-
ing to be performed.
10. 
Update the software nomenclature register.
 The software nomenclature regis-
ter should be updated and expanded to reflect the elements of the functional 
architecture.

---