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
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
What Is Software Engineering?
Engineering is (dictionary definition) the application of scientific
methodsto 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
What you have to be aware of though are software fairy tales and the
The latest software is so easy
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
The adoption of the Incapable Immaturity Model will make everything work out just fine.
The requirements are fixed and will not change.
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
So how do we make sure that our projects don't become horror stories? By the application of software engineering