Software Engineering

1. 
Establish a feasible set of software requirements.
2. 
Establish a solid structural foundation for software implementation.
3. 
Incrementally expose the emerging solution with stakeholders to ensure con-
tinual consensus.
4. 
Ensure that the resulting product can be delivered according to project or con-
tractual provisions.
As the software engineering team endeavors to associate the solution with its 
driving requirements, there arises a disconcerting dilemma that must be appreciated 

---

119
Developing the software product architecture
to devise a unified product solution. The manner by which an engineering solution 
must be fostered involves a concurrent refinement of a solution in both a top-down 
and bottom-up manner. The top-down architectural conception provides a continual 
unraveling of the problem space as expressed by stakeholder needs and software 
requirements. The bottom-up fulfillment clarifies the needed building material from 
which a product can be assembled. Bridging these two coalescing perspectives 
involves a dualistic impetus to translate data processing threads of behavior and 
provide a strategy for software component integration.
This dualistic imperative leads to a software design chasm that will be further 
examined in Chapter 12. The software product architecture matures in a top-down, 
conceptual manner while striving to be definitive in the identification and specifica-
tion of structural elements in a bottom-up manner. The smallest structural parts or 
units represent the building-block material from which the software product will 
be implemented. Each structural unit must be precisely specified so that the soft-
ware implementation team may perform programmatic design, coding, and testing 
of each software unit against the structural unit’s specification. The design chasm 
naturally forms as the gulf of space between the upper layers of conceptual compo-
nents and the lower layers of structural elements. The design chasm can be bridged 
by further top-down functional decomposition, by determining a bottom-up soft-
ware integration strategy, or by working in both directions.
Therefore, the software engineering practices are not individual steps in a pro-
cess by which the software product architecture is generated. They are elements 
of a single, inclusive problem investigation and design discovery paradigm config-
ured to address the myriad of potential software architectural pitfalls. Because of 
the vast array of potential architectural anomalies and inconsistencies, it is impos-
sible to establish an unequivocal description of each software engineering practice. 
Therefore, it should be recognized that the software engineering practices presented 
in this section are defined with an emphasis on presenting a 90% complete and sat-
isfactory set of software engineering practices.

---

This page intentionally left blank

---