Software Engineering

44
CHAPTER 3 
Software Architecture
The final element of the software product architecture is the physical architec-
ture that depicts the structural aspects of the software product and provides insight 
into how the product will be assembled and integrated to form one or more soft-
ware configuration items. The physical architecture is derived from the functional 
architecture in a manner that involves a top-down conceptualization and a bottom-
up manifestation. As the functional architecture is initially formulated the upper-
most structural components of the physical architecture may be identified. The 
foundation of the physical architecture is derived from the functional units, which 
are grouped and synthesized to identify structural units. This exposes a gap in the 
structural configuration that is resolved with the establishment of a software inte-
gration strategy. This approach to configuring the physical architecture is explained 
in detail in Chapter 12.
Without the physical architecture, the software implementation effort cannot 
be properly defined, planned, and controlled. The software engineering integrated 
product team (SWE-IPT) is responsible for developing and controlling the software 
architecture and its integrated design and configuration documentation. The soft-
ware architecture must characterize the design of the software product to be devel-
oped. This necessitates the crafting of different types of design diagrams, views, 
and documentation that depict the software architecture. The general categories of 
design documentations include:
●
  Descriptions of the functional architecture and its design representations, such 
as functional specifications, functional decomposition hierarchies, data flow dia-
grams, behavioral models, and data dictionaries.
●
  Descriptions of the physical architecture and its design representations, such as 
interface block diagrams, structural specifications, and configuration assembly 
and integration plans.
●
  Requirements baseline and its representations, such as software requirement 
specifications, software interface specifications, and database requirement 
specifications.
●
  Description of the computational environment.
●
  Post-development process specifications and design documentation.
There exist relationships and dependencies among all of these design descrip-
tions that must be harmonized and synchronized to enable the project to consider 
potential software design opportunities, and respond to change requests and propos-
als by incorporating approved changes into the software architecture.
The elements of the software architecture, the computing environment, and the 
relationships and dependencies that exist among these elements are identified in 
Figure 3.1
. These relationships are indicated by the arrows between any two ele-
ments of the software architecture. These relationships represent the dependen-
cies a source element has with regard to the target element. These relationships 
and their dependencies are further examined in the following sections. Notice that 
the stakeholder needs, software implementation, and test and evaluation elements 
in the figure are grayed out to indicate that they are not elements of the software 

---