Page 1211 - The Mechatronics Handbook

0066_frame_C49.fm Page 6 Thursday, January 10, 2002 5:05 PM

indeed complex, and the limitations on what can be produced by teams of software engineers given finite
amounts of time, budgeted dollars, and talent have been amply documented by Jones [5].
Essentially the many paradigms of software engineering attempt to rectify the causes of declining
productivity and quality. Unfortunately, this fails because current paradigms treat symptoms rather than
the root problem. In fact, software engineering is itself extremely dependent upon both the software and
hardware as well as the business environments upon which they sit [6].
SEI’s process maturity grid very accurately pinpoints the root of most of our software development
problems. The fact that a full 86% of organizations studied remain at the ad hoc or chaotic level indicate
that only a few organizations (the remaining 14%) have adopted any formal process for software engi-
neering. Simply put, 86% of all organizations react to a business problem by just writing codes. If they
do employ a software engineering discipline, in all likelihood it is one that no longer fits the requirements
of the ever-evolving business environment.
In the 1970s, the “structured methodology” was popularized. Although there were variations on the
theme (i.e., different versions of the structured technique included the popular Gane–Sarson method
and Yourdon method), for the most part, it provided a methodology to develop usable systems in an era
of batch computing. In those days, online systems with even the dumbest of terminals were a radical
concept and GUIs were as unthinkable as the fall of the Berlin Wall.
Although times have changed and today’s hardware is one thousand times more powerful than when
structured techniques were introduced, this technique still survives. And it survives in spite of the fact
that the authors of these techniques have moved on to more adaptable paradigms, and more modern
software development and systems engineering environments have entered the market.
In 1981, Finkelstein and Martin popularized “information engineering” [7] for the more commercially
oriented users (i.e., those whose problems to be solved tended to be more database centered) which, to
this day, is quite popular among mainframe developers with an investment in CASE strategies of the
1990s. Information engineering is essentially a refinement of the structured approach. However, instead
of focusing on the data so preeminent in the structured approach, information engineering focuses on
the information needs of the entire organization. Here business experts define high-level information
models, as well as detailed data models. Ultimately, the system is designed from these models.
Both structured and information engineering methodologies have their roots in mainframe-oriented
commercial applications. Today’s migration to client/server technologies (where the organization’s data
can be spread across one or more geographically distributed servers while the end-user uses his or her GUI
of choice to perform local processing), disables most of the utility of these methodologies. In fact, many
issues now surfacing in more commercial applications are not unlike those that needed to be addressed
earlier in the more engineering-oriented environments such as telecommunications and avionics.
Client/server environments are characterized by their diversity. One organization may store its data
on multiple databases, program in several programming languages, and use more than one operating
system, and hence, different GUIs. Since software development complexity is increased 100-fold in this
new environment, a better methodology is required. Today’s object-oriented techniques solve some of
the problems. Given the complexity of the client/server environment, code trapped in programs is not
flexible enough to meet the needs of this type of environment. We have already discussed how coding
via objects rather than large programs engenders flexibility as well as productivity and quality through
reusability. But object-oriented development is a double-edged sword.
While it is true that to master this technique is to provide dramatic increases in productivity, the sad
fact of the matter is that object-oriented development, if done inappropriately, can cause problems far
greater than problems generated from structured techniques. The reason for this is simple. The stakes
are higher. Object-oriented environments are more complex than any other, the business problems chosen
to be solved by object-oriented techniques are far more complex than other types of problems, and there
are few if any conventional object-oriented methodologies and corollary tools to help the development
team develop good systems. There are many flavors of object orientation. But with this diversity comes
some very real risks. As a result, the following developmental issues must be considered before the
computer is even turned on.

©2002 CRC Press LLC