So what does software engineering mean? Well, the answer you get, as is often the CASE, depends upon who is answering the question. For some readers, the answer is likely to be putting a bridle on innovation. What thwarts the creative process aborts the created product. For others it's just as likely to mean a way to produce better products, in less time, with less waste, and have more fun in the process.
Definitions of software engineering tend to lead to arguments. So for the sake of argument let's say software engineering refers to a technological and technology management discipline concerned with producing and maintaining software products on time and within cost estimates. It doesn't necessarily refer to team programming, but because it is impossible to guarantee that a software product will be maintained by its original author, it does necessarily preclude the kind of clever code that only the original author can understand. Every software product, in this view, is in fact a multiprogrammer project and should be approached as such. Communication is a central issue.
Traditionally, approaches to software engineering have involved most of the following:
The nature of software development is such that decisions of sweeping magnitude can be made and implemented in seconds, and, in fact, this goes on routinely. It is simply impossible for a programmer to break off the programming process and explain the significance of a change he has made every time he does something that could affect a distant portion of the program. One of the ways software engineering attempts to address this problem is to make it impossible for the programmer to affect a distant portion of the program by creating an organizational structure that matches a natural decomposition of the problem. Each programmer (or small group of programmers) works, not on the whole problem, but on a component.
The results of the software engineering efforts, when they work, are predictability and maintainability. the perception among many programmers, including, we believe, a high proportion of DDJ readers, is that this makes programming boring and unimaginative drudge work. This perception must be at least partially true, and the way out of the dilemma seems to be something like CASE: computer-aided software engineering. Rather than force programmers to do boring and restrictive things, the CASE approach automates the boring activities. The programmer's options are still restricted, but he doesn't notice because he is spending his time in areas where he is not restricted. CASE is, to the programmer, a friendly environment and a set of tools for software development. At least that's the theory.
Ron Copeland & Michael Swaine
Fortunately, over the past few years, several companies have developed a collection of specialized methods and tools which address the complex problems of writing and maintaining large programs. These powerful tools are now becoming nore readily available on micro platforms.