Software Engineering

104
CHAPTER 6 
Impediments to Software Design
software product architecture. The software requirements analysis practice trans-
forms stakeholders’ needs and expectations into the software product, structural 
component, and unit specifications. The functional analysis provides the systematic 
techniques for understanding what data processing transactions the software prod-
uct must perform to accomplish the product requirements as they are decomposed 
into software functions. The software design synthesis practice establishes the 
structural configuration of the software product and the FAIT strategy. The result 
is a completely specified software product architecture documented as the software 
technical data package (TDP). This software TDP includes the specifications, dia-
grams, drawings, and software integration strategy that facilitate software imple-
mentation (programmatic design, coding, integration, and testing).
The software industry has not been able or willing to step up to the demands 
of transitioning from a chaotic craft to a disciplined engineering profession. The 
unwillingness of software professionals to adopt a more disciplined set of prac-
tices for developing software products is a result of their unawareness and inex-
perience with other engineering disciplines. Ignorance is bliss goes the old saying! 
This implies that it is often preferred not to know something due to the unpleas-
ant or foreboding consequences of knowing and accepting the truth. This is not to 
blame or insult software professionals; ignorance is simply a lack of awareness, 
knowledge, or education that prohibits their pursuing a better approach to design-
ing software products. Because software personnel do not have awareness that 
there is a better way to perform their vocation, they continue to flail about clutching 
onto newly proposed stratagems in hopes of hiding their lack of competency. Most 
software professionals have been trained to program, which is predominantly a 
low-level design tactic. There has been no software methodology that offers a com-
prehensive approach to design a complete software product.
Software prototyping logically emerged as a way to rapidly develop software 
products with little or no effort to design the complete product. This approach 
has been renamed and repackaged in various clandestine attempts to divert atten-
tion away from the obvious lack of a formal design approach and permit software 
mavens to perform what they know how to do, which is program. This concept 
of software prototyping originated as a software development methodology enti-
tled Rapid Application Development (RAD). The RAD philosophy suggests that 
a software product can be developed with “minimal planning and the incremen-
tal building of a prototyping. The ‘planning’ of software developed using RAD 
is interleaved with writing the software itself. The lack of extensive preplanning 
generally allows software to be written much faster, and makes it easier to change 
requirements.”
5
 This has led to the establishment of the Agile Manifesto, which 
attempts to formalize prototyping as a genuine software development methodology.
Fundamentally, the software development occupation will only be elevated 
to professional status when a set of principles and practices that guide its teach-
ing, conduct, and management has been established. Software development 
5 
See 
http://en.wikipedia.org/wiki/Rapid_application_development
.

---