Possible answers to "What is software design?" include references to process, artifacts and appearances. That is, one can examine the structure of a solution to a problem: how to implement what ? This involves the process/methodology followed in developing software, the artifact produced, and how the system actually appears to various people (e.g., the developers, the users, the administrators). Approaches to software design should be careful to allow for the following:
The phases of software design run from the more abstract levels of designing subsystems and sorting out dependencies to the actual coding process of data structure design and algorithm development. How things actually get done can sometimes be very different from how they appear to be done. Choices to be made include:
The question of what is good software design becomes a bit more complicated. It is analagous in ways to: What is a good book? What is quality? The answer will depends on what the evaluator's values are. For example: Is end-system performance of primary importance? Or are you more interested in ease of maintenance? Or perhaps ease of use? Quality will clearly mean different things to Microsoft, for example, than it will to the Department of Defense.
Software engineering texts seem to like to define "quality metrics" as ways of evaluating software. In general, they seem to be based on notions of coupling : how many interdependencies there are between containers, and cohesion : making sure related parts are in the same container. Other design criteria might include things like modularity, sipmle interfaces, decomposability, and so on. There are often conflicting goals in software design as well. These can range from efficiency vs. safety to defined protocols vs. anarchy, among others.
With regard to creative design, there are again conflicting impulses. On the one hand, well-defined, rigid methodologies tend to stifle creativity and slow the design process. On the other hand, such methodologies will tend to entail repeatable results. In fact, there are many instances in which creativity is not a goal. These include things like DoD projects, traffic light controls, nuclear reactor software and so on. In such projects, the main goals will be reliability, robustness, security and the like as opposed to creativity.
The final question addressed in this talk is whether good software design can be taught. The answer is most likely: "Yes, in a way." There is some structure that can be taught, in particular: well-defined methodologies and good engineering practice. Teaching creativity and innovative design presents different problems. In fact, there are people who would claim that it can't be taught, it's a black art. Ben Schneiderman has suggested eight heuristics or "Golden Rules" for user interface design which may also apply to software design in general. Included are things like: simple error handling, informative feedback, and consistency.
Another thing to bear in mind is that the notion of "software engineering" is relatively new. The phrase was initially coined as wishful thinking, and in fact it's still a very young discipline. The training and competence of its practitioners varies wildly, and there seems to be an obsession with short-term achievement. In other words, products are released even when they may still be fairly buggy. This is often in contrast to "real" engineering which is grounded in a large collection of codified knowledge, and in which professional responsibility seems to be held in greater esteem.