Introduction to (software) design  (Page 3/9)

• the static structure of the system, including any subprograms to be used and their hierarchy;
• any data objects to be used;
• the algorithms to be used;
• the packaging of the system, in terms of how modules are grouped in compilation units (assuming that implementation will use a conventional imperative programming language); and
• interactions between components, including the form these should take, and the nature of any causal links.

Characteristics of software design

Because designing all these aspects of a software system might be hard work, its benefits must be brought to light. We soon see that these benefits are analogous to the benefits of general design. Software development consumes time and money. Also, it is quite obvious that no one wants to spend his or her resources in developing software that solves the wrong problem. Considering this, just like when we were generally describing design, the possibility of early evaluation is desirable because it helps to ensure the stakeholders the development of the right program. Software design enables this early evaluation, because its product describes several aspects of the final program. Also, it is often less expensive to obtain than the whole program.

When modeling a software system, thus designing it, the designer focuses on the domain problem. This enables the designer to distinguish the problem's essential complexity from the accidental one. As stated by Brooks , this separation is known to impact positively on the quality of the final program.

Just like general design, software design helps on estimating costs, e.g. , how long all the development process will be, how many implementers will be necessary for a specific module, should a module be implemented or bought, what group is responsible for implementing a specific module, and so on.

Finally, because it contains knowledge from the system that can be recorded, transmitted, and discussed, software design can act as a communication vehicle. For example, if a software system is to be presented to a new member of the development team, before making her dive into the code, valuable information can be passed to her via the software design. Moreover, if the audience of this presentation is a program user, information (often abridged) from the design is even more necessary, since it may not make sense showing software source code to this kind of audience.

Nevertheless, some important observations related to these characteristics must be made.

While the design process occurs, it is possible that the person who wants the software to be built for solving her problem (the client) (1) change her mind about the very problem, (2) describe her problem incorrectly, or even (3) consider that the problem itself changed, or have been solved, during the design process. All these three possibilities must be kept in mind because they may lead the designer to fail on achieving the client's objectives and eventually to waste time and money.

Since a software design is just a model, its detail level may not be adequate for certain kinds of evaluation. In fact, evaluating a software design without enough details can lead to wrong results and then to wrong programs. This is quite common when evaluating performance, especially when bad designers consider insufficient detail for this purpose. For example, a performance design evaluation stated that a specific system was able to cope with a thousand users accessing it simultaneously. However, this very design did not add enough details on the actions performed by users. The case was that the performance analysis was made considering that each action consumed less resources than they in fact did after implemented. As expected, this system failed miserably when the number of concurrent users started to grow near the expected limit of a thousand users.