Programming Concepts · Chapter 1 · Foundations
Every software project moves through the same four phases — plan, design, build, ship — wrapped in activities that never stop, inside a rigid model that works only until requirements change.
bookSHelf · Introduction to Programming Concepts and Methodologies · §1.1 · a self-paced section
Outline — by the end of this section you will be able to
§1.1.1 — the four generic phases every project follows
Software teams do not build in a random order. The most common process model is built from four activities called phases — generic because every project uses them, no matter what it builds.
Context Pause — why every project shares the same four phases
No matter what kind of software you build, these four phases are the skeleton every software project shares — the company, the kind of problem, and the size of the project only shift how much work each phase gets.
§1.1.1 — the four phases, named
Definition 1.1.1 — Framework Activities
Framework activities (also called phases) are the four generic activities that every software process model includes: inception, elaboration, construction, and deployment.
Definition 1.1.1: a highlight sweeps inception → elaboration → construction → deployment.
Every phase happens in every project — a two-person hobby app and a fifty-engineer platform both move through the same four stops, just with very different-sized stays in each.
Worked example — one app, four phases
Worked Example 1.1.1 — a name-and-greeting app
Amara wants to build a tiny JavaScript app that asks the user their name and prints a friendly greeting in the browser’s console. Walk each phase of the software life-cycle for this project.
Solution.
console.log the greeting.const name = prompt(...); console.log("Hello, " + name + "!");Answer: inception sets the goal, elaboration plans it, construction writes the code, and deployment runs it in the browser.
Your turn — match each task to its phase
Try It Now 1.1.1 — a school-lunch ordering app
Match each task to the framework activity it belongs to: (a) writing the code that shows the menu, (b) deciding which schools the app will serve, (c) drawing the overall structure of the app, (d) putting the finished app in the app store.
Answer: (a) construction (b) inception (c) elaboration (d) deployment
§1.1.2 — important, but tangential to the four phases
If the framework activities are the cooking, umbrella activities are the things you do alongside it — like keeping your pots clean and your pantry stocked.
Insight Note — umbrella activities are the kitchen cleanup
Umbrella activities run alongside every phase, holding the whole project together rather than belonging to any single one.
Your turn — name the umbrella activity
Try It Now 1.1.2 — testing before release
Miguel’s team is testing its app to find bugs before release. Which umbrella activity does this testing belong to, and why?
Answer: Quality management. That umbrella activity covers the checks — reviews, estimations, metrics, testing — that keep the software correct and reliable.
§1.1.3 — the checklist inside one job
Definition 1.1.2 — Task Set
A task set (or workflow) encompasses all the tasks required to accomplish a specific software engineering action within a framework activity.
Definition 1.1.2: one action reveals a checklist of tasks, one at a time.
Inside each phase you do specific jobs called software engineering actions — “design the architecture,” “define the requirements.” A task set is that action’s to-do list.
Context Pause — a task set is a to-do list for one job
If “design the app” is the action, the task set is the checklist of every small step that job needs, from sketching screens to reviewing them. Task sets vary with the project, and activities within a process model usually overlap instead of running independently.
Worked example — one action, five tasks
Worked Example 1.1.2 — a loop that prints the wrong number of times
The action is “debug the loop.” Write a task set that lists the small tasks this action needs.
Solution.
for/while condition, check where it starts and stops.< to <=) and rerun.Your turn — write a task set of your own
Try It Now 1.1.3 — requirements definition
The inception phase calls for the action “requirements definition.” List two example tasks that a task set for this action might include.
Answer: for example, interviewing users about their needs, and writing down the list of requirements. (Other reasonable tasks are fine too.)
§1.1.4 — one generic template, many shapes
Process models that follow the four generic framework activities are called SDLC methodologies. There is no single right way to build software — process frameworks are elaborated differently depending on four factors:
Insight Note — the four Ps are the recipe’s ingredients
The same cooking steps change based on what you are cooking, who is cooking, and how many people you are feeding. A process framework is adjusted to fit the problem, the project, the people, and the product the same way.
Your turn — a small app vs. a banking system
Try It Now 1.1.4 — why the same framework looks so different
A small team is building a simple app for one school, while a large team is building a banking system for a whole country. Why might the two teams elaborate the same framework activities differently?
Answer: their four Ps differ — the small app can keep each phase light, while the banking system’s larger problem, project, people, and product need far heavier planning, design, and review.
§1.1.5 — waterfall, prototyping, spiral, RUP
These structured, orderly approaches to software engineering may help with four objectives:
§1.1.5 — the rigid recipe, named
Definition 1.1.3 — Prescriptive Process Model
A prescriptive process model advocates an orderly approach to software engineering that involves following a prescribed set of activities in a continuous manner.
Definition 1.1.3: change bounces off a rigid, fixed pipeline.
Context Pause — “prescriptive” just means it tells you what to do
The word does not mean the model is fancy. It simply means the process model identifies a set of process elements — framework activities, software engineering actions, tasks, work products, quality assurance, and change control — for each project.
Insight Note — a rigid recipe vs. cooking to taste
A prescriptive model is like a recipe with exact steps and timings. It is great when the dish is well understood, but it breaks down when the requirements change mid-meal, because the recipe cannot adapt quickly.
Your turn — does the rigid recipe fit?
Try It Now 1.1.5 — a startup whose features change weekly
Zara’s startup is building an app whose features keep changing every week based on customer feedback. Would a traditional prescriptive process model be a good fit? Give one reason.
Answer: no — it is too rigid and inflexible for requirements that change weekly. The next section explores Agile software development, built to handle exactly this kind of change.
Glossary — the vocabulary this section defined
The four phases
framework activities (phases) — inception, elaboration, construction, deployment.
inception — planning goals and scope.
elaboration — analyzing requirements, designing architecture.
construction — coding and building.
deployment — releasing to end users.
Wrapping it all up
umbrella activities — training, risk, configuration, quality, architecture, and security management, run alongside every phase.
task set (workflow) — every task one action needs.
SDLC methodology — a process model that follows the generic framework.
four Ps — problem, project, people, product.
prescriptive process model — a prescribed, orderly, continuous sequence.
The headline result of §1.1
Every process model shares the same four phases
Inception, elaboration, construction, deployment — wrapped in umbrella activities that never stop, and broken down inside each phase into task sets. The four Ps (problem, project, people, product) decide how much weight each phase carries.
plan → design → build → ship
† A prescriptive process model follows that recipe rigidly, which brings efficiency and predictability when requirements hold still — and breaks when they don’t.
§1.1 — Conclusions
Every software process model shares four generic phases — inception, elaboration, construction, deployment — wrapped in umbrella activities, broken into task sets, and shaped by the four Ps (problem, project, people, product).
A traditional prescriptive model follows a fixed, orderly sequence — efficient and predictable while requirements hold still, but too rigid and inflexible once they start changing rapidly.
Next: §1.2 — Variables and Data Types. Back to start.