Category list

Chapter 7. Software Engineering Essentials

So far this book has predominantly been about design, and how to bring that design to fruition. Design is a large portion of software engineering, but certainly not all.

Software engineering is such a vast subject that we can only hope to touch on it in this chapter. We left it until the latter part of the book because we wanted to concentrate on the design issues, but before we embark further on our journey we need to discuss the broader issue of software engineering. It is important to understand one size does not fit all. Everything presented on the subject of software engineering is only advice based on the latest information, which means it changes.

What Is Software Engineering?

Engineering is (dictionary definition) the application of scientific methods to the design, building, and use of machines, constructions, and so on.

Software is (dictionary definition) the programs and other operating information used by a computer.

Therefore, software engineering, by (our) definition, is programs and operating data that have been designed by the application of science. Or, in other words, designing software by applying defined methods ”the inverse of which is designing software without the application of any methods. The science we've been trying to get across is LCOD. Not tackling the problem with a predefined set of guidelines and techniques, be it LCOD or any other methodology, means the process is ad hoc, or certain to fail!

So, what else is there apart from design? All systems have to go through the same stages: requirements gathering, design, build, verification, and maintenance. Different companies go about these phases in different ways, so what follows is briefly how we do it. We do it this way because we find it works for us. Essentially, what we discuss in this chapter are those aspects of software engineering that are directly applicable to what we are doing, and that is the project.

What you have to be aware of though are software fairy tales and the opposite , software horror stories. Avoid the fairy tales and learn from the horror stories. These fairy tales and horror stories seem to litter software engineering in equal measures.

Top

Fairy Tales

The latest software is so easy anyone could develop the system.
The latest 16GL language is going to make this project a complete success.
The new Disoriented methodology is going to ensure that all software is failproof.
The new project management tools from IAMALIAR Inc., will make failed projects a thing of the past.
The latest Case Tool from HeadCase is going to make software engineers redundant.
The adoption of the Incapable Immaturity Model will make everything work out just fine.
The requirements are fixed and will not change.

Top

Horror Stories

This list would be exhaustive. There has already been enough in the press recently to show how bad things really can be. But guess what, they are always directly or indirectly related to the fairy tales. Robert Glass's book Software Runaways more than adequately describes the catastrophic failure that can be attributed to believing in fairy tales. So, don't get eaten by the big bad wolf, and don't believe in fairy tales.

So how do we make sure that our projects don't become horror stories? By the application of software engineering methods , with a good dose of reality. We have already touched on the religious experience some individuals have with respect to certain tools, methodologies, and so on. We believe in using what works.