For any software project, large or small, architecture is key to managing the intrinsic complexity of software. The design of a system includes its architecture, so, more broadly, design is key to managing software complexity. Informally, architecture partitions a system into parts that are easier to work with than the system as a whole. Let us refer to the parts as architectural elements, or simply elements. With a clean architecture, we can reason about the system in terms of the properties of its elements, without worrying about how the elements are implemented.

Software engineering is the application of engineering methods to software development and evolution. Its principles and practices address three fundamental goals: discover user requirements, manage software complexity, and build quality products and services. This chapter introduces the goals, their associated challenges, and how to deal with the challenges.

The selection of a development process is one of the earliest decisions in the life of a software project. A process orchestrates the workings of a team: it guides what each role does and when in order to define and build a product. This chapter introduces the two main groupings of processes: agile and plan-driven. Agile processes are designed to accommodate requirements changes. Plan-driven processes emphasize careful upfront design. Each process class within these groupings addresses some, but not all, of the challenges faced by projects. Teams therefore customize their processes by borrowing best practices as needed. For example, all teams benefit from essentially the same testing practices.

The combination of reviews, static analysis, and testing is highly effective at detecting defects during software development. By themselves, the individual techniques are much less effective; see . Testing is covered in ; the other techniques are covered in this chapter.

A use case describes how a user interacts with a system to accomplish something of value to the user. Written in plain English, use cases are intended to be a single description that is suitable for all stakeholders.

For metrics to be useful, they must be consistent with our intuitions about the real world. As an example, defects can be a useful metric for product quality – the fewer severe defects, the better.

Rather than start each design from scratch, software architects tend to adapt earlier successful designs for similar problems. Even if they do not reuse any code, the solution approach gives them a head start with the current problem. Problems like fault tolerance have been addressed over and over again. (The idea for a solution is to have a live backup system that takes over if the primary system fails due to a hardware or software fault.)

All software projects face the twin questions of what users want and what to build to address those wants. These are related, but logically distinct questions. Requirements elicitation is the process of discovering user wants and writing them down as user requirements. Requirements analysis is the process of prioritizing user requirements from various sources and defining what to build as a product. In practice, elicitation and analysis are entwined: the same user-developer conversation can touch on a user goal, its priority, and acceptance tests for it.

Software testing is the process of running a program in a controlled environment to check whether it behaves as expected. The purpose of testing is to improve software quality. If a test fails – that is, the program does not behave as expected – there must be a fault, either in the program or in the specification of expected behavior. Either way, the test has uncovered a problem that should be resolved.

Once user needs and goals are recorded as user requirements, the emphasis shifts to requirements analysis. User requirements, even specific and measurable ones, correspond to wish lists from the various stakeholders. Requirements analysis prioritizes these wish lists to define precisely what to build as a product; see . To prioritize, we must answer three questions. First, what properties of the product will prioritization be based on? Examples of properties include not only cost and functionality, but usefulness, usability, and desirability. Second, how will the properties be quantified? Quantification involves classification into ranked categories; for example, must-have, should-have, could-have, won’t have. Third, how do we rank order requirements based on a combination of properties, such as benefit, cost, and perhaps risk?