Software Engineering

from the Perspective of Competitive Advantage

by
Edwin B. Dean

The IEEE (Anon., 1990) defines software engineering as "the application of a systematic, disciplined, quantifiable, approach to the development, operation, and maintenance of software."

To me, software engineering is the integrated set of activities (the meta-activity) required to bring forth, sustain, and retire digital computer code which satisfies the appropriate customer desires. Customers include the users, owners, and regulators of the product. An activity is an integrated effort which applies resources to implement objects, including functions and data, necessary to satisfy the negotiated customer desires. The resources include hardware, software, people, processes, and information. The integration includes both the internal integration within the activities and the external integration across all activities.

An appropriate software engineering activity is customer directed. From that all else must follow. Since requirements are the derived form of customer desires, they must be a transformation of the customer desires into the technical language of software engineering necessary to implement them. If not, then the software engineering activity fails to be customer directed and, hence, is not appropriate.

My observations over thirty years as a software professional and user, indicate that the typical software engineering activity has not been appropriate, and still isn't. Most commercial software fails to gain adequate market share. These observations are supported by others (Gibbs, 1994).

Value is the measure of customer choice. Value is defined by the primary dimensions of quality and cost. Quality is defined by the customer. To be competitive, delivered software must have high value. This means software must be delivered at the appropriate time with lower cost than the competition or higher quality than the competition or both. As defined above, an appropriate software engineering process is necessary for the delivered software to be competitive. It must be customer focused. Nejmeh (1995) provides an interesting and simplified perspective for designing for value.

How, then, can I become competitive? There are certainly many ways. The software engineering literature abounds in proposals. A related question is: How can I best attain level 5, the optimizing level, in the Software Engineering Capability Maturity Model? Again, there are many ways. However, my research indicates that probably the fastest and most direct known approach to attain both goals simultaneously is through the appropriate application of quality function deployment (QFD) and the seven new tools. QFD is a system engineering process which transforms the desires of the customer/user into the language required, at all project levels, to implement a product. It also provides the glue necessary, at all project levels, to tie it all together and to manage it. Finally, it is an excellent method for assuring that the customer obtains high value from your product.

The use of QFD for software engineering takes on even more importance in the context of Jones (1995). He indicates that "It is interesting and significant that the first six factors associated with software disasters are specific failures in the project-management domain, and three others can be indirectly assigned to poor management practices. The tenth factor, creeping user requirements, is sometimes outside of the control of the entire software organization. ... From a technical point of view, the most common reason for software disasters is poor quality control." QFD, as implemented under total quality control, provides a superior project-management system, superior management practices, a superior method of linking requirements and system design, and superior quality control.

Besides implementing QFD, what can be done to improve software engineering. Noting Dr. Lemings observations on software productivity, the three primary drivers of software productivity are the ratio of lines of code which must be rewritten, the ratio of lines of code which have to do with what the customer wants rather than with control of internal computer communications or the user interface, and the percentage of applications which provide sufficient value to the customer. An enterprise which designs and implements software engineering processes which improve these three ratios will have a major competitive advantage. Significant improvements may require paradigm shifts such as new software languages and more implementation of function in hardware. As these ratios improve, cycle time and cost will reduce drastically and customer acceptance of the product in the marketplace will increase dramatically.

More to follow. Until then, I must let the bibliography and world pointers below do the talking for me.

Many references of historic value have been included in the bibliography. My philosophy is that to learn a subject requires that one read the masters, no matter how long ago their thoughts arose. This is particularly true in software engineering where we have come a long way but have not come very far. Because of the immense data base, it will be some time before I have included even what I consider to be the masters. Besides the masters, I am trying to sprinkle the bibliography liberally with significant tutorial content and with thoughts near the edge which tend to spawn creativity.

References

Anon. (1990) IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990
Gibbs, W. W. (1994). "Software's Chronic Crisis," Scientific American, September, pp. 86-95.
Jones, C. (1995). "Patterns of Large Software Systems: Failure and Success," Computer, March, pp. 86-87.
Nejmeh, B. A. (1995). "Process Cost and Value Analysis," Communications of the ACM, Vol. 38, No. 6, June.

Software Engineering

References

Bibliographies

Societies

Surfing the Web