Software design is both the process of making structural decisions about a system and the outcome of that process — Robillard: "the construction of abstractions of data and computation and the organization of these abstractions into a working software application."

Design is a verb (the process you follow while designing) AND a noun (the resulting structure). The exam likes this process-vs-outcome distinction.

In practice, designing software = making decisions and trade-offs between quality attributes: ease of implementation, reusability, maintainability, security/safety, performance, …

There is no single 'right' solution. You search for a feasible solution along these attributes. Two correct programs can have very different designs.

We design software for humans to read and maintain — the compiler does not care until it breaks. Readability and comprehensibility are first-class goals.

Good design prevents bugs and misuse proactively, improves maintainability/quality, and makes problems easier to detect and resolve.

Most common causes of project failure: unrealistic/unarticulated goals, badly defined requirements, poor reporting of status, poor communication, sloppy development practices — all leading to the wrong software.

Heartbleed (OpenSSL): a single missing length check on memcpy leaked 64KB of server memory; undetected for ~2 years.

Log4Shell: uncontrolled string substitution allowed arbitrary remote code execution; ~93% of cloud enterprise environments were vulnerable.

Boeing 737 MAX MCAS: software masked an unstable airframe, did not validate its sensor input, could override pilots, with no redundancy — fatal crashes.

Better design = readable/comprehensible code, applied principles (testing, input checks), reusable abstractions.