Software Engineering & Architecture

This is Unit Nine of Computer Science: software engineering. Every unit before this one was about what computers and programs are. This one is about how software actually gets built by groups of people over time — which is a different problem, with different failure modes. The unit sets out two philosophies, and it is careful not to declare a winner. One prescribes an orderly sequence of activities. The other holds that processes should not be constrained in advance, because requirements change. Both are presented as answers, and which is right depends on the four things named early. There are two error entries, and both are about words. One about a practice whose definition people routinely violate while using its name. The other about the word free, which in this context means something specific and does not mean what most people assume. And the capstone reaches all the way back to Unit One. The transit app that was swept as a user's experience comes back as an engineering project. By the end you will be able to do five things. One: name the four activities every process contains. Two: say what a sprint is and why it ends twice. Three: say what disqualifies a change from being refactoring. Four: name the testing levels and what a regression suite is for. Five: say what free means in free software.

Three entries opening the unit. A definition that stakes a claim in its own wording, four variables that change how any process gets applied, and the roles a team divides into.

The definition.

CS 0471 Software Engineering

A systematic, disciplined and quantifiable approach to the development, operation and maintenance of software. Every word in that phrase is doing work — particularly quantifiable, which is the claim that this is engineering rather than craft.

Four variables.

CS 0472 The Four Ps

Process and method choices get elaborated differently depending on the problem, the project, the people and the product. There is no single correct process, and these four are why.

Who does what.

CS 0473 The Team's Roles

Teams divide into roles — architect, experience designer, developer, quality assurance. The division is the acknowledgement that these are different skills.

Three entries. Four activities that appear in every process regardless of philosophy, then the family of models that prescribes an order — including the one everybody has heard of, named for how it flows.

The four activities.

CS 0474 The Generic Framework

Every software process fits four activities — inception, elaboration, construction and deployment. What differs between models is how they are ordered and how often they repeat.

The first family.

CS 0475 The Prescriptive Family

Advocating an orderly approach — a prescribed set of activities followed continuously. Prescription is the feature, not the flaw, when requirements are genuinely known in advance.

The best-known one.

CS 0476 The Waterfall

Phases flowing downward like water — requirements gathered and analysed, then the complete system designed, then built. Each phase finishing before the next begins.

Four entries on the other philosophy. Its claim is that processes need not be constrained in advance, and the model built on it runs in fixed-length iterations that end twice — once looking at the product, and once looking at the team.

The philosophy.

CS 0478 Agility

The ability to create and respond to change, holding that processes need not be constrained in advance. It is a position about uncertainty rather than about speed.

The cast.

CS 0479 Scrum's Cast

A team of typically ten or fewer, with one person running the process and one owning the product. Small is specified rather than incidental.

The unit of time.

CS 0480 The Sprint

A fixed-length iteration, typically one to four weeks, with backlog items moving into a sprint backlog as the work committed to. Fixed length is what makes it measurable.

Ending twice.

CS 0481 Review and Retrospective

The review demonstrates the increment to stakeholders and gathers feedback on the product. The retrospective examines how the team worked. Two separate endings because those are two separate questions.

One procedure, and it makes the framework concrete rather than abstract. A single backlog item followed through every event in a sprint, with the events counted rather than described.

Watch one story move.

CS 0500 One Story, One Sprint

A single backlog item's trip through one sprint touches every event in the framework, and counting them shows what the ceremony actually consists of rather than what it sounds like.

Four entries on practices that cut across both philosophies, and the error entry here is worth taking literally. A change that alters what the software does is not refactoring — not badly done refactoring, not refactoring with a bug. Something else.

The practice.

CS 0484 Refactoring

A reorganisation technique improving a design without changing what it does. The structure moves and the behaviour is held fixed by definition.

And the error.

CS 0485 "Refactoring Rewrites Behavior"

A change altering what the software does is not refactoring, because the definition requires functionality to be preserved. The name matters here — calling a behaviour change a refactor is how it escapes the review it needed.

Merging often.

CS 0486 Continuous Integration

Merging and testing work frequently, so failures surface promptly and the list of things to fix stays short. Frequency is what keeps the list short.

Joining two functions.

CS 0487 DevOps

Combining agile development with operations to deliver faster and at higher quality — treating running the software as part of building it.

Four entries on verification. What it is for, the levels it runs at from a single component upward, tests that sit outside those levels entirely, and what accumulates when unit tests are kept.

The purpose.

CS 0488 Testing's Purpose

Verifying that software delivers the project's requirements without unintended errors or side effects. Both halves matter — doing the right thing, and doing nothing else.

The levels.

CS 0489 The Testing Ladder

Unit testing checks individual components in isolation, integration testing checks how they combine, and the levels continue upward from there. Each level catches what the one below cannot.

Outside the levels.

CS 0490 Acceptance and Friends

Approach tests sitting beside the levels — acceptance verifying client and user expectations, usability checking ease of use. These ask whether it is the right software, not whether it works.

What accumulates.

CS 0491 The Regression Suite

Unit tests accumulate into a suite rerun after each change to verify that nothing existing broke. The value is cumulative — every test written stays useful long after the change that prompted it.

Two entries, and the error entry is one of the most useful in the course because the confusion is built into the English word. Free here means liberty. It has nothing to do with price, and paying for free software is entirely ordinary.

Four freedoms.

CS 0492 Free and Open-Source Software

Free software grants users four freedoms, with free referring to liberty. Open-source software is distributed under a licence granting comparable rights.

And the error.

CS 0493 "Free Means Gratis"

The word refers to liberty rather than price, and users may be required to pay. Software that costs nothing is a separate category with a separate name — and conflating the two loses both meanings.

Four entries closing the material. A pattern is a documented answer to a recurring problem, patterns form a hierarchy with architectural style at the top, and the last two scale the same idea up to an entire organisation.

The unit of reuse.

CS 0495 The Pattern

Documenting a recurring problem and providing a reusable template — a problem and its solution within a stated context. The context is part of the pattern, not decoration.

The hierarchy.

CS 0496 The Pattern Hierarchy

Design-centric patterns form a hierarchy with architectural style at the top, capturing what makes a structure identifiable. Broadest at the top, most specific at the bottom.

Scaling up.

CS 0497 The Enterprise Architecture Framework

Tools and approaches keeping technical solutions aligned with an organisation's strategy. The concern is alignment rather than construction.

Three views.

CS 0498 The Blueprint

Visualising an architecture at conceptual, logical and physical levels — three views of one thing, each answering a question the others cannot.

One capstone, and it closes a loop opened at the very start of the course. The transit app that Unit One walked through as a user's experience comes back — now as something a team has to plan, staff, build, test and ship.

The capstone. The app, from the other side.

CS 0505 The Build, End to End

Unit One's transit app returning as an engineering project — every phase, role, practice and pattern in this unit applied to the thing the course opened with.

Five things you can now do, and one course nearly complete. You can name the four activities every process contains — inception, elaboration, construction, deployment — and say that models differ in ordering, not in content. You can say what a sprint is and why it ends twice: a review looking at the product, and a retrospective looking at how the team worked. You can say what disqualifies a change from being refactoring — any alteration to what the software does, because preserved functionality is in the definition. You can name the testing levels from unit upward, and say a regression suite exists to verify that nothing existing broke. And you can say what free means in free software: liberty, not price, and users may well be required to pay.