Software types and the SE knowledge map

What software runs on and whom it serves predict how often it can ship and how carefully; SWEBOK's 18 areas map the discipline.

Before you read: predict

In a mock interview for an ExamHall backend role, Lina, a computer science graduate, is asked which areas of software engineering are her gaps. "None, really," she answers. "I write and debug code fast, and that is software engineering," she adds.

Which reply does the SWEBOK Guide V4 support?

The 30-second version

Place software with two questions: what does it run on, and whom does it serve? The answer predicts its release cadence, set by who installs updates and what one release costs, and its risk, set by who is hurt when it fails. The SWEBOK Guide maps the discipline into 18 areas; coding is one.

What software runs on and whom it serves predict how often it can ship and how carefully; SWEBOK's 18 areas map the discipline.

How it works

Step 1 of 17

Two questions place software. What does it run on: its maker's servers, users' devices, or a device built for one job? Whom does it serve?

Analogy: A skincare brand's product information (personal care)

A skincare brand publishes the same facts in four places. Its website's ingredients page is one copy that a chemist corrects the minute she spots a slip. Its catalogue is already in customers' homes. Its labels are on jars in hundreds of shops. Its lab's batch sheets are read by staff alone.

At the skincare brand	In software
the website's ingredients page, one copy, corrected in a minute	software on its maker's servers (steps 3, 8)
catalogues in customers' homes: a fix waits for the next mailing, and old copies stay in use	apps on users' devices (steps 3, 8)
labels on jars in shops: a van must visit each shop, so labels change rarely, in batches	firmware in devices in the field (steps 6, 9)
the lab's batch sheets	internal tools (step 5)
the sunscreen's protection line checked by a second chemist; the bath salts' colour name not	risk sets the rigour (steps 10, 11)

Breaks down when: a printed label never changes in place, while many devices take updates over the air.

In real terms: for each product, name what it runs on, whom it serves, who installs its updates, what one release costs, and who is hurt when it fails.

Examples, run for real

4.1 ExamHall EXH-4690 → MR !4990: four parts, one tree

ExamHall's onboarding page called all four of its parts "the web app" and gave them one release checklist. EXH-4690 records that page (synthetic); MR !4990 places each part with the two questions.

EXH-4690 · onboarding page: 4 parts, all called "the web app", 1 release checklist
  candidate app             runs on candidates' browsers, served from ExamHall's servers · serves candidates · web app (SaaS) · updated by ExamHall's deploy, taken at the next page load
  proctor console           runs on proctors' browsers, served from ExamHall's servers · serves exam-centre proctors · real-time web app (SaaS) · updated by ExamHall's deploy, taken at the next page load
  grading workers           runs on ExamHall's servers (BullMQ) · serves the exam API, which queues their jobs · backend service · updated by ExamHall's deploy
  browser integrity checks  runs on candidates' browsers · serves the proctors, not the candidate · web app code on the candidate's device · updated by ExamHall's deploy, taken at the next page load
MR !4990 · 4 parts placed by both questions · 3 branches · 3 run on users' machines · 4 updated by ExamHall's own deploy · 0 in devices in the field

The integrity checks run on the candidate's machine yet serve the proctors, so placing a part takes both questions (step 1). All four parts ship through ExamHall's own deploy, and none sits in a device in the field, so ExamHall can release many small changes (steps 8, 9); its checklist can stay one list, but not because all four are "the web app".

4.2 An ExamHall retro on the SWEBOK map

After a slow exam start, ExamHall's team listed six follow-ups.

Retro follow-ups on SWEBOK V4's areas (this pack's placement)
  write "every candidate starts within 60 s of 09:00" as a testable requirement    KA 1 Software Requirements
  give the grading queue workers of its own, apart from the exam API               KA 2 Software Architecture
  fix the off-by-one in the countdown timer                                        KA 4 Software Construction
  load-test 2,400 starts in one minute before each exam season                     KA 5 Software Testing
  alert on the grading queue's backlog after every deploy                          KA 6 Software Engineering Operations
  tag each release so support can tell which build a centre ran                    KA 8 Software Configuration Management
  6 follow-ups · 6 areas · 1 in construction · 5 elsewhere

One follow-up in six is coding. The other five are still software engineering, in five other areas (steps 13, 14): a team that counts only coding skills misses most of its own retro.

Try it

Answer first, then check. Nothing is saved.

Question 1 of 8

A ticketing company's stadium team looks after four programs: the turnstiles' firmware, which also opens every gate when the fire alarm sounds; a bench rig that replays recorded gate events against each new firmware build before it ships; the app fans open at the gates to collect loyalty points; and a planning dashboard, showing ticket sales by match, that the same team uses to schedule each firmware release's install visits.

Which of them does the SWEBOK Guide treat as safety-critical software?

Question 2 of 8

On this lesson's release model, a ticketing company's turnstiles run the same firmware in its 12 stadiums. Each firmware release needs a 4-day run in the safety test lab, then a half-day technician visit to each stadium to install it. The firmware team can spend 40 working days a year on releases.

How many firmware releases can it ship in a year?

Question 3 of 8

A ticketing company uses four programs it did not write.

Which one does the SWEBOK Guide class as software as a service?

Question 4 of 8

A ticketing company's web team ships its ticket shop several times a day. It is now to write the firmware for a stadium's new turnstiles. Its lead wants to run the firmware project with the shop's process unchanged, "because the SWEBOK Guide's areas are the same for every product".

Which reply does the guide support?

Question 5 of 8

A ticketing company runs six programs. For each, fill two slots: its branch of the tree (system software, web app or SaaS, mobile or desktop app, backend service, embedded, data/ML, internal tool) and who installs its updates.

the ticket shop that 40 venues pay for each month and sell through
the scanner app on venue staff's phones
the turnstiles' firmware
the box office's refund tool
the model that sets tomorrow's prices from today's sales
the driver for the box offices' ticket printers

Fill both slots for each program.

Your answer (optional, stays on this page)

Question 6 of 8

An interviewer asks: "How is building a SaaS product different from building embedded or internal software, in risk and release cadence?" For the ticket shop, the turnstiles' firmware and the box office's refund tool, fill four slots each: who installs an update, how often it can ship, what one bad release costs, and who is hurt when it fails. Then write your answer in at most 120 words.

What do you tell the interviewer?

Your answer (optional, stays on this page)

Question 7 of 8

On this lesson's release model, a firmware fix for the turnstiles in a ticketing company's 12 stadiums passes the safety lab at 17:00 on Monday 1 March 2027. Two technicians install it; updating one stadium's turnstiles takes one technician a full working day, and they work Monday to Friday.

On which day are the last stadium's turnstiles updated?

Question 8 of 8

Four lines from a ticketing team's onboarding notes on the SWEBOK Guide V4.

Which line goes against what the guide says?

Go deeper

Pro tip

Place a product by risk and release cadence before you copy a process. Embedded firmware ships rare, costly releases; a SaaS ships many small ones; that one axis explains most process differences. When: in your first week on a new product, or when an interviewer asks how two products differ. Status: SELF (the curriculum row's tip; not run).

Source

The guide was fetched on 2026-10-17 by fetch-sources.mjs from the PDF the IEEE Computer Society hosts (its pages are headed "SWEBOK Guide V4.0a"); the PDF's sha256 equals the one se-estimation recorded on 2026-10-02. The row's landing page, https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4, holds a download form and no area text, so nothing is keyed on it.

S1 · SWEBOK Guide V4.0a, Foreword and Introduction (IEEE Computer Society, ed. H. Washizaki, 2024), https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf, PDF pages 26 and 38–41 (swebok-v4-intro.txt). "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software"; "Material that falls within this discipline is organized into the 18 KAs listed in Table I.1." (step 13); "the following KAs have been added: the Software Architecture KA, Software Security KA, and Software Engineering Operations KA." (step 15); "Each topic description is meant only to give the reader a general understanding of the topic and to enable the reader to find reference material." (step 16); "The body of knowledge is found in the reference materials, not in the Guide." (step 16); "Software engineering and computer science are related but distinct in the same way chemical engineering and chemistry are related but distinct." (step 17); "the SWEBOK V4 Guide continues to recognize eleven related disciplines, listed in Table I.2." (step 17; the table lists Computer Science, Data Science and Project Management among them).
S1 · KA 4 Software Construction, Introduction, PDF page 99 (swebok-v4-construction.txt). "Software construction refers to the detailed creation and maintenance of software through coding, verification, unit testing, integration testing and debugging." (step 14).
"Software engineering management (SEM) can be defined as a collection of work activities involved with planning, estimating, measuring, controlling, coordinating, leading and managing risk factors for a software project".
"Increasing risk implies increasing SQA and more rigorous review techniques such as inspections" (step 11).
S1 · KA 15 Software Engineering Economics, Introduction, PDF page 288 (swebok-v4-economics.txt).

Steps 1–3 and 5–9 are this lesson's tree and release arithmetic: no source states them, and no cited key rests on them.

Checked against the tools and docs as of 2026-10-17.

Predict first