Software Engineering

115
 
Software Engineering Practices
The systems engineering practices provide the mechanisms for investigating 
architectural design problems and establishing an effective, efficient architectural 
solution. These practices are applied at every level of design, or product decompo-
sition, to ensure that the problem space is fully comprehended and that the solution 
addresses all potential operational situations that could arise.
These software engineering practices have been adapted to support the engi-
neering of software products. They have been defined in terms of the various 
software engineering tasks that should be performed to fulfill the intent of each 
practice. These tasks have been composed using a set of software-specific func-
tional and structural elements that permit readers to understand where in the prod-
uct decomposition the task applies.
Within the functional architecture there is a distinction made between functional 
components and units. Functional components represent complex data process-
ing actions that should be further examined to reveal the subcomponents or units 
that are necessary to support the functional component. Naturally, there are sev-
eral (more than two or three) levels of functional components necessary to describe 
even moderately complex software behaviors. Functional units represent noncom-
plex functions that do not require further decomposition.
Within the physical architecture there are three distinct tiers in which emergent 
structural elements are discussed. At the topmost tier the conceptual components 
are identified to represent placeholders for large software product design segments. 
The bottommost tier involves the fundamental structural units that are derived from 
functional units as the basic building blocks for the physical architecture. One level 
above structural units are the fundamental structural components that form logical 
or operational groupings of units that contribute to achieving a common data pro-
cessing function. The design chasm between the fundamental and the conceptual 
structural elements is populated with integrating components of which the purpose 
is to facilitate the software integration and test strategy.
Requirements must be specified for every element of the software architecture. 
Therefore, the requirements analysis practice must be rationally applied for each 
functional and structural element of the architecture. The requirements analysis 
practice, as a whole, should be applied to assist the exploration of each level of func-
tional decomposition to ensure that the problem/solution space is comprehended.
The software analysis practice should be employed whenever there are multiple 
possible tactics by which requirements may be specified, complex data processing 
functions can be decomposed, or structural elements can be arranged or integrated.
Software verification and validation should be performed periodically to ensure 
that the evolving software architecture is coherently delineated. This involves ver-
ifying that the three architectural perspectives are aligned and consistently stipu-
lated. Validation involves ensuring that the complete structural configuration has 
been properly engineered to satisfy the software specifications.
Software control provides a variety of tasks that capture completed architectural 
artifacts and maintain control over the evolving architectural documentation. This 
includes the processing of change requests and proposals and the updates to techni-
cal plans, schedules, and work packages.

---