Page 1210 - The Mechatronics Handbook

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

the output is designed or selected as part of a design; an implementation or programming phase, where
one or more tools are used to write and/or generate code; a testing (debugging) phase, where the code
is tested against a business test case and errors in the program are found and corrected; an installation
phase, where the systems are placed in production; and a maintenance phase, where modifications are
made to the system. But different people develop systems in different ways. These different paradigms
make up the opposing viewpoints of software engineering.

49.2 The Nature of Software Engineering

Engineers often use the term “systems engineering” to refer to the tasks of specifying, designing, and
simulating a non-software system such as a bridge or electronic component. Although software may be
used for simulation purposes, it is but one part of the systems engineering process. Software engineering,
on the other hand, is concerned with the production of nothing but software.
In the 1970s industry pundits began to notice that the cost of producing large-scale systems was growing
at a high rate and that many projects were failing or, at the very least, resulting in unreliable products.
Dubbed the software crisis, its manifestations were legion and the most important include the following:
• Programmer Productivity. In government in the 1980s, an average developer using C was expected
to produce 10 lines of code per day (an average developer within a commercial organization was
expected to produce 30 lines a month); today the benchmark in the government is more like 2 to
5 lines a day while at the same time the need is dramatically higher than that, perhaps by several
orders of magnitude, ending up with a huge backlog. Programmer productivity is dependent upon
a plethora of vagaries—from expertise to complexity of the problem to be coded to the size of the
program that is generated. The science of measuring the productivity of the software engineering
process is called metrics. Just as there are many diverse paradigms in software engineering itself,
there are many paradigms of software measurement. Today’s metric formulas are complex and
often take into consideration the following: cost, time to market, productivity on prior projects,
data communications, distributed functions, performance, heavily used configuration, transaction
rate, online data entry, end-user efficiency, online update, complex processing, reusability, instal-
lation ease, operational ease, and multiplicity of operational sites.
• Defect Removal Costs. The same variables that affect programmer productivity affect the cost of
“debugging” the programs and/or objects generated by those programmers. It has been observed
that the testing and correcting of programs consumes a large share of the overall effort.
• Development Environment. Development tools and development practices greatly affect the quan-
tity and quality of software. Most of today’s design and programming environments contain only
a fragment of what is really needed to develop a complete system. Life-cycle development envi-
ronments provide a good example of this phenomena. Most of these tools can be described either
as addressing the upper part of the life cycle (i.e., they handle the analysis and design) or the lower
part of the life cycle (i.e., they handle code generation). There are few integrated tools on the
market (i.e., that seamlessly handle both upper and lower functionalities). There are even fewer
tools that add simulation, testing, and cross-platform generation to the mix. Rare are the tools
that seamlessly integrate system design to software development.
• GUI Development. Developing GUIs is a difficult and expensive process unless the proper tools are
used. The movement of systems from a host-based environment to the workstation and/or PC saw
the entry of countless GUI development programs onto the marketplace. But the vast majority of
these GUI-based tools do not have the capability of developing the entire system (i.e., the processing
component as opposed to merely the front-end). This leads to fragmented and error-prone systems.
To be efficient, the GUI builder must be well integrated into the software development environment.
The result of these problems is that most of today’s systems require more resources allocated to mainte-
nance than to the original development of that system. Lientz and Swanson [4] demonstrate that the
problem is, in fact, larger than the one originally discerned during the 1970s. Software development is

©2002 CRC Press LLC