Software Engineering

118
SECTION 2  
Software Engineering Practices
a distinct, unavoidable, and compelling perspective of the problem being solved 
and available solutions. Therefore, these practices should not be employed in isola-
tion to one another as a set of sequential tasks. Viewed in operation, each practice 
can lead to two or more of the related practices. A practice can be interrupted to 
facilitate an excursion into another practice, as needed, to clarify some aspect of 
the problem being explored or solution being investigated. Each iteration returns to 
the interrupted practice with additional information upon which further analysis or 
synthesis can be performed. Assumptions can be tested and confirmed while faulty 
speculation marginalized. This iteration provides clarity for the software engineer-
ing team about the problem space that results in a more effective and efficient archi-
tectural solution. It provides a level of comprehension that facilitates creativity, 
ingenuity, and resourcefulness. This results in a solution that is operationally suit-
able, resource efficient, unfaltering, and structurally enduring.
Most software development methodologies struggle with the concept of 
iteration. They emphasize the need to follow a structured approach in which the 
requirements are established before the design solution is derived. This encour-
ages a typical 
requirements, design, code, and test
 strategy. However, it must be 
recognized that the requirements for a software product must be achievable. The 
preferred manner in which to ensure requirements feasibility is to venture into the 
realm of design, even prototyping, to ensure that each specified requirement can 
be satisfied. As the overall software development situation is appraised, there is an 
intriguing dynamic of opposing forces that mandates an iterative approach to any 
engineering problem. Interactions by the technical team with stakeholders warrants 
an evolutionary disclosure of the broadening understanding of the software opera-
tional boundaries, product characteristics, and performance challenges, and the 
underlying structural components upon which the solution will be founded. This 
is referred to as the top-down or structural analysis approach to software develop-
ment. The instinctive reaction of most programmers is to “prototype” a solution 
and socialize it among the stakeholders. This is referred to as the rapid applica-
tion development or agile approach to software development. Neither approach has 
emerged with an irrefutable record of success, and the software development indus-
try remains stymied by its futile attempts to establish a credible approach upon 
which to forge an engineering discipline.
The software engineering practices that are prescribed in this section establish 
an iterative paradigm that accommodates the dynamic forces encountered during 
software development efforts. These underlying forces involve the need to: