Software Engineering

2
SECTION 1
  Software Engineering Fundamentals
a set of standard practices. It is essential for the software industry to stabilize the 
manner in which they discuss their professional practices with other engineering 
professionals, stakeholders, and customers. It is not prudent to speak an alien dia-
lectal when attempting to illuminate technical challenges or the merits of design 
ingenuity.
Professor Fred Brooks addressed the confusion caused by the various software 
lexicons by discussing the Tower of Bable. His book 
The Mythical Man-Month: 
Essays on Software Engineering
1
 identified the quagmire that erupted as a result of 
the ever-expanding software dialects. Since its first publication, the software culture 
had disseminated more programming languages, techniques, and methodologies in 
the shortest span of time than any other vocation in the history of humankind. This 
trend continues to disperse, diffuse, and magnify the communication barriers between 
conventional engineering professions and software artisans and engineering impres-
sionists. Software engineering is a demanding occupation that can no longer afford 
to promote undisciplined techniques and methodologies. Software jargon and dialects 
must coalesce as a united lexicon based on established engineering terminology. The 
quagmire stemming from the variety of software languages and methodologies threat-
ens to overwhelm the industrial and academic communities attempting to keep pace 
with the endless stream of new and provocative software strategies.
Therefore, this section patiently explores the influences that surround the devel-
opment of a software product. These influences, or environmental variables, must 
be appreciated for a software engineering effort to be successful. Therefore, this 
section discusses the various technical and business motives that must be embraced 
by any approach to engineering software products. Fundamentally, it is essential to 
recognize that software products are intended to contribute to the financial pros-
perity of the businesses that adopt them, as well as the businesses that supply this 
unique merchandise.
A major category of software products is intended to make businesses more 
productive by automating routine, labor-intensive tasks. These software products 
reduce a business’s reliance on manual data gathering, analysis, and manipulation, 
especially where computational errors result in costly mistakes that could reduce 
the profitability of an enterprise. The companies that develop software products 
want to enjoy a beneficial compensation from the investment in the development of 
the software product. Consequently, it is in the interest of both the software devel-
oper and the businesses using the software to ensure that the software development 
project results in a proficient, user-friendly product that actually works properly. 
However, the success rate associated with software development projects has hov-
ered between 25% and 30% throughout the two decades of the Standish Group’s 
Chaos reports.
2
 Clearly, businesses are losing confidence in the software industry’s 
ability to successfully deliver a product on time and within budget that actually 
1 
Brooks, F. (1975). 
The Mythical Man-Month: Essays on Software Engineering
. Reading, MA: 
Addison-Wesley.
2 
See 
http://blog.standishgroup.com/pmresearch
.

---

3
Systems engineering principles and practices
does what it is supposed to do. 
FAILURE! CHAOS!
 It does not seem to faze soft-
ware professionals that their reputation is so disgracefully tarnished.
Never fear, because there is always another self-proclaimed software guru ready 
on the sideline with a new-fangled solution to software development. Another 
approach, excitingly new terminology, and a flourish of activity as desperate mavens 
leap aboard another bandwagon bound for somewhere. The software development 
industry is desperately seeking a solution that significantly offers to bring some cred-
ibility to their defense. Software specialists fail to embrace the fundamental princi-
ples and practices encouraged by other engineering disciplines because software is 
different than other products. How true! However, there may be some value from 
garnering those engineering practices that may have applicability to the engineering 
of software products.
This section provides six introductory chapters that set the stage for examining 
software engineering principles and practices. This material is based on my experi-
ences applying systems engineering practices for the past two decades. My inves-
tigation into systems engineering was prompted by a 1989 congressional report 
entitled “Bugs in the Program
.
”
3
 The findings and recommendations of this repots 
included the following:
National Science Foundation should assure that computer science or software 
engineering curricula should expose students to systems engineering concepts 
throughout their education.
The Government’s present system for procuring software does not meet the 
Government’s needs and wastes resources. The application of “systems engi-
neering” disciplines is needed to remedy the procurement system’s defects. 
…
 
Software Development is a complex process that requires modern “systems engi-
neering” techniques.
While the systems engineering discipline has promoted a cohesive set of prac-
tices for dealing with complex product development endeavors, they have been 
improperly adapted to the unique nature of software products. Section 2 presents 
the six practices associated with systems engineering. However, they have been 
acclimated to the challenges of software development.