Free through lesson 3

How Software Projects Run

Proposal, requirements, high-level design, detailed design, implementation, testing, release, operation. One project — an equipment lending system for a general affairs department, 400 users and a budget of 12 million yen — runs from lesson 1 to lesson 30, so you learn the connections between the phases along with the phases themselves. Every lesson confirms in numbers how a decision made upstream plays out downstream.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are grouped into six chapters, and working through them in order is the best way. Note: every output in the text comes from running small calculation and charting scripts written with nothing but the Python standard library (no frameworks, no database). You do not need to read the code — reading the output is enough.

Chapter 1 — Before a project begins (lessons 1–5)

The overall shape of the phases, choosing a process model, team structure and RACI, contracts and estimates, WBS and the critical path. What has already been decided before anyone writes a line of code, in order.

1

The big picture of software development (writing code is 20% of it)

The eight phases of a software project and the share of effort each one takes. Also calculating how much more it costs to fix an upstream mistake in a later phase.

Free
2

Development process models (it is not that you cannot go back, it is that going back is expensive)

The differences between waterfall, agile, iterative, prototyping and hybrid, and how to choose. Deriving from the V-model when the test plan should be written.

Free
3

Team structure and roles (the person who decides and the person who knows are different people)

The eight roles in a software project and where responsibility divides, classifying stakeholders, and building and checking a RACI matrix.

Free
4

Contracts and estimates (a fixed-price contract promises completion, a time-and-materials one promises effort)

The differences between fixed-price, time-and-materials, deliverable-based and staffing contracts, and which fits which phase. Analogy, bottom-up and three-point estimation on one project, reconciled.

🔒 Basic
5

Project planning and the WBS (break it down by deliverable, not by activity)

Decomposing a WBS by deliverable, and drawing a schedule by computing the critical path from the dependencies. Also confirming by calculation where you can and cannot compress it.

🔒 Basic

Chapter 2 — Requirements (lessons 6–11)

From analysing the current state to a finished requirements document. Six lessons take you through turning problems into numbers, counting the handoffs in a business process, working them down into use cases and non-functional requirements, and getting agreement at review.

6

Analysing the current state and framing the problem (do not turn a request straight into a feature)

Separating what people ask for from what is actually hurting them. Turning workload into numbers to compute the return, and separating what the system should solve from what the process should.

🔒 Basic
7

Visualising the business process (count the handoffs, not the steps)

Drawing the As-Is and To-Be process as swimlanes and counting handoffs and waiting time. Also how to surface the exceptions hiding behind the happy path.

🔒 Basic
8

Use cases and functional requirements (write them with the user as the subject)

Rewriting a request as a functional requirement, writing a use case description, and building traceability between requirement IDs and the problems they address.

🔒 Basic
9

Non-functional requirements ("a fast system" is not a requirement)

Surfacing non-functional requirements in six categories, and turning performance, availability and data volume into numbers from actual usage. With how to verify each and what counts as passing.

🔒 Basic
10

The requirements document and scope management (the chapter that works is the one listing what you will not do)

The table of contents of a requirements document, how to write what is out of scope, detecting vague wording mechanically, and the change control process with the arithmetic of scope creep.

🔒 Basic
11

Reviews and reaching agreement (a review with no findings is not a success)

Four ways to run a review and when to use each, assigning the roles, classifying findings, what approval means, and how to record it. Also review speed against detection rate, in numbers.

🔒 Basic

Chapter 3 — High-level design (lessons 12–17)

The chapter that settles the externally visible shape. Screen flows, ER diagrams, tables, APIs and architecture, all built up in order from the requirements of the same single project.

12

The big picture of high-level design (decide only the externally visible shape)

The boundary between high-level and detailed design, the deliverables and who reviews them, allocating requirements to screens, tables and APIs, and recording design decisions.

🔒 Basic
13

Screen design and screen flow (decide the flow before the fields)

Building a screen inventory with view counts and designing from the screen flow. Writing a screen specification, the wording of error messages, and choosing defaults for lists and forms.

🔒 Basic
14

Data modelling (list the nouns, then check each multiplicity one at a time)

Picking the nouns out of the requirements to settle the entities, and confirming multiplicity by asking in both directions. Adding sample data and moving time forward to find gaps in the model.

🔒 Basic
15

Table design (normalise first, then denormalise only as far as you need)

Normalising an Excel spreadsheet, judging when deliberate duplication is right, protecting data with constraints, and choosing indexes from the search conditions on the screens.

🔒 Basic
16

API design (URLs are nouns, operations are methods)

Taking stock of the external interfaces, naming URLs, returning errors, and the CSV interchange specification with its pre-import checks. Actually reading a CSV to see the ways it breaks.

🔒 Basic
17

Architecture and technology selection (novelty gets a weight of zero)

Deriving the architecture from the non-functional requirements, comparing candidate architectures alongside their costs, and scoring a technology choice with the weights decided in advance.

🔒 Basic

Chapter 4 — Detailed design and implementation (lessons 18–22)

From detailed design that documents only what an implementer would hesitate over, through security design, code review, measuring progress and log design. The chapter of things that pay off while you are building.

18

Detailed design (write only where the implementer would hesitate)

The criteria for what goes into detailed design and what does not, writing a processing specification, choosing boundary values, and running the code to watch it break under concurrent access.

🔒 Basic
19

Security design (hiding the button does not stop the API being called)

The difference between authentication and authorisation, building a permissions matrix, why screen-level control cannot protect you, handling input, where secrets live, and how to verify all of it.

🔒 Basic
20

How implementation proceeds (agree the definition of done before you start)

What to settle before coding begins, the definition of done, what a coding standard decides versus what a human must check, and what to look for in a code review. Plus the cost of scattered rules.

🔒 Basic
21

Progress, issue and risk management (why "90% done" lasts three weeks)

Comparing self-reported progress against progress measured in completed features. Spotting slippage on a burndown, the four options when you are late, and building an issue log and a risk register.

🔒 Basic
22

Error handling and log design (write for the person who will search these later)

Choosing log levels, following one operation with structured logs and a correlation ID, classifying errors and deciding where to catch them, when to retry, and how to investigate an incident.

🔒 Basic

Chapter 5 — Testing and acceptance (lessons 23–26)

Test planning, system testing, acceptance testing and sign-off. You count by what was verified, set the pass criteria in advance, and put yourself in a position to make a GO/NO-GO call.

23

Test planning, unit and integration testing (do not count by how many times you ran it)

The test levels and who owns each, what goes into a test plan, the exit criteria, and creating test data. Actually running the tests and confirming the links back to requirement IDs.

🔒 Basic
24

System testing (a defect found here for the first time is a hole in the requirements)

Business scenario testing, judging performance at the p95, and how to run failure testing. Writing a defect report, analysing which phase introduced it, and judging convergence.

🔒 Basic
25

Acceptance testing (agree the pass criteria before the test starts)

How acceptance testing differs from system testing, setting the pass criteria, what to prepare, three categories of finding, and judging a conditional pass.

🔒 Basic
26

Sign-off and the release decision (not "does it work" but "does it meet the conditions")

What sign-off means for the contract, payment and liability, what you submit for it, the release checklist and how to make the GO/NO-GO call, and how to cost a delay.

🔒 Basic

Chapter 6 — Release and operation (lessons 27–30)

Release procedures and rollback, migrating data out of an Excel spreadsheet, operations and incident response, and a round-up of all 30 lessons. Built on the assumption that the time after you ship is the longer part.

27

Migration and release (write the rollback procedure alongside it)

Choosing a release approach, building the runbook and timeline for the day, the deadline for deciding to roll back, and how to rehearse.

🔒 Basic
28

Data migration (count the rows that will not load before you load anything)

What the migration plan settles, the problems you usually find in source data, running the conversion to count the rows that will not load, and reconciling row counts and monetary totals.

🔒 Basic
29

Operations, maintenance and incident response (the first thing you do is establish the blast radius)

The operational calendar, choosing monitoring thresholds, measuring the benefit realised, and the four kinds of maintenance. For incidents, establish the blast radius first, then write the report.

🔒 Basic
30

Wrapping up (what gets handed on is the reasoning for what you did not build)

Reviewing all 30 lessons as the flow of a single project, with a list of the threads that run across phases and a 67-item checklist you can use at work.

🔒 Basic

Once you have finished all 30 lessons, take a closer look at the agile methods touched on in lesson 2 with Agile Scrum for Beginners, at the testing techniques deferred in lesson 23, or at Git & GitHub for Beginners, which lesson 21 left out. Membership unlocks every course.