SN L2a — Process and Lifecycles

A revision summary of the first Processes lecture. It makes the same move at four scales: write down what you do, decide what tells you it is working, name the level you mean, and pick the shape that fits the work. Each section links to the handbook page carrying the detail and the sources.

1. Why a defined process pays for itself

A defined process is one you can repeat, check and improve. Cannot repeat it? You have a performance. Cannot check it? You have a belief.

It pays because of a property specific to software. A misunderstanding written into a requirement is honoured by the design, implemented faithfully by the code, and confirmed by tests written from the same misunderstanding. Every stage does its job correctly and the error is carried, not caught — which is why a green test suite is consistent with building the wrong thing. The cost of fixing a defect rises steeply with the stage it is found in, steeply enough that the studies disagree about the multiplier [1], so treat the shape as the finding rather than the number.

The range at each stage is the spread of reported multipliers. The shape is the finding.

So the work products before the code — estimates, requirements, architecture, test plans — are each a place a defect can enter, which is what makes them worth reviewing. Quality assurance therefore covers the product and the process that builds it: the process limits how many defects were injected, and inspection only catches what the process already let in. Rework runs 30–80% of effort and inspections cost 20–30% of first-half effort; Fagan calls the fear they delay a project “a myth” [2].

Two practical points. Ask the doers, not the managers — the manager’s version is the process designed, the doers’ is the one that runs [3]. And improvement is a loop: Plan, Do, Check, Act [4]. Check is the rung teams drop, because two questions hide behind “is it working?” — whether the process is followed, and whether following it produces the outcome. A process can be followed faithfully and still be wrong.

→ Process basics · Defining a process · History

2. ETVX: one activity, written so it can be checked

ETVX writes a single activity as four parts [3]: Entry — what must be true before it starts; Task — what is actually done; Validation — how the result is checked; Exit — what must hold before it may finish.

Exit is the part that changes behaviour. Entry and Task are usually written down somewhere already; Exit is what stops work being declared complete because the calendar says so. An activity whose exit criterion is “the document exists” has not been defined, it has been named — whereas “every interface has a named owner and a stated failure mode” cannot be satisfied without having done the design.

ETVX is not a gate chain, and that is the common misreading. Radice rules it out explicitly: the notation “does not imply that all activities or tasks in a later stage must wait for completion of predecessor stages. The later stages may be functioning in parallel with previous stages”. It constrains the handoff between defined activities, not the calendar — which is why it sits underneath plan-driven and iterative work alike.

Example — Oerlikon Aerospace built a laser-guided air-defence system with 60+ engineers and chose ETVX “because of its simplicity” [5]. Their estimation step exits on an approved WBS and OBS, a schedule, cost estimates — and a list of the alternatives considered. That last item cannot be produced retrospectively, so requiring it at exit forces the estimating to have actually happened.

Exam tip: a good exit criterion is one you cannot fake after the fact.

→ ETVX

3. Measuring the process, and what the number does to people

GQM runs backwards from how measurement usually happens [6]: Goal (conceptual — what are we trying to achieve, and for whom) → Question (operational — what would we have to know to tell) → Metric (quantitative — what data answers it). Most measurement runs the other way, collecting what the tooling emits and then looking for a story in it. A metric with no question above it has no reason to exist. Name the object first — a product, a process or a resource: a team whose goal is about a process will reliably propose metrics about the code.

GQM’s drawback comes from its own author, sixteen years on. Measurement programmes fail through “disillusionment about metrics on the part of developers and managers”, and GQM “does not provide explicit support for motivating and integrating measurement at various levels of the organization” [7]. So check the goal is held in common before deriving a single question: “improve quality” means fewer escaped defects to support and less time in legacy code to the engineers, and every question derived from it inherits the disagreement.

A metric aimed at people stops being a measurement. Humphrey states it absolutely: “Process data must not be used to compare projects or individuals. Its purpose is to illuminate the product being developed and to provide an informed basis for improving the process” [8]. Precision is no defence — dysfunction appears “whether or not our models are correct” [9].

Example — twenty-five open defect reports were closed as “duplicates” of one new report whose only shared property was the subsystem it was filed against [9]. Nobody falsified anything and every closure was defensible; the count improved and the defects were still there. The modern version is velocity: make points-per-sprint a target and estimates inflate [10]. So the question is not is this the right number but who will see it, and what happens to them because of it.

Where something matters and cannot be counted — morale, trust, whether estimates are believed — a short recurring anonymous questionnaire tracks judgement as a trend [11]. Read the direction, not one week’s score, and cover every role: one team left the Training Manager off as “a minor role not relevant to measure”, and the omission itself caused “debate and concern”. What you decline to measure is a message too.

→ GQM · Metrics · Scoreboard

4. Process, lifecycle, framework — four rungs

Three words get used as if they were one. They are rungs, each more concrete than the one above:

Rung	What it is	Example
Lifecycle model	The phases, and the go/no-go points between them	Waterfall · Spiral · V
Framework	Reusable structure — roles, events, practices — to work inside those phases	Scrum · RUP · Kanban
Process	What one organisation actually does, in detail	This team’s definition of done
ETVX	The unit any of them decomposes into	entry · task · validation · exit

The one-sentence version: a lifecycle names the phases; a framework supplies reusable structure to work within them. Waterfall is a lifecycle; Scrum is a framework. Scrum settles its own case, describing itself as “a container for other techniques, methodologies, and practices” [12] — it tells you how to organise a fortnight, not what order the phases come in, and that fortnight can sit inside a waterfall phase or an iterative one.

SWEBOK licenses the whole block: “There is no best software process… No ideal process, or set of processes, exists” [13] — and defines a process as inputs → activities → outputs that “may also include its entry and exit criteria”, which is ETVX restated in 2014.

A software lifecycle is the cradle-to-grave existence of a product. Most of a lifecycle model’s value is communication: the team can say where it is, management can see status, the customer can be told what happens next. Those three want different things from the same phase name, so the rule is define, communicate, define, communicate.

Exam tip: the distinction is examined, not the words. Be ready to place a named example on the right rung and say why.

→ Lifecycles · ETVX

5. Six shapes, and what each one buys

Model	Structure	Feedback	Choose it when
Waterfall	Linear, once through	Late	Requirements are stable and the work must be contractible and audited
V-Model	Waterfall, drawn to show V&V	Late, tests designed early	Verification must be demonstrated to a regulator or customer
Incremental	Usable slices, staged	Per increment	You know what to build but cannot build it all at once
Iterative	Whole product, repeated	Every iteration	You do not yet know exactly what to build
Prototyping / RAD	Build to answer a question	Immediate	One uncertainty is cheaper to resolve by building than by analysis
Spiral	Risk-driven loops	Every cycle	Risk should decide what happens next, and you control the commitment points

Three things the table cannot say, and they are the examined ones.

Waterfall’s advantage and its disadvantage are the same property. Fixed phases with defined exit criteria make it contractible — you can price a phase, staff it, audit it, hold someone to it, which for fixed-scope procurement and regulated work is the point rather than bureaucracy. The same property delays the first honest feedback to the end: testing is “the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed” [14]. Royce’s own fix was to do it twice — ten months of a thirty-month effort on a pilot pass in the critical areas. One pass to retire originality risk, not iterative development [15].

Incremental adds parts; iterative improves parts. Both repeat; the difference is how well the requirements are known when you start [16]. Incremental assumes requirements “reasonably well defined” and ships an operational slice each pass, core product first. Iterative expects requirements to move and produces “an increasingly more complete version”, with the feedback part of the deliverable. So choosing incremental assumes stakeholders can tell you now what the slices are — and will still want the same ones in six months.

The spiral’s defining property is not the loops. It “creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process” [17]. Risk-driven does not mean the project is risky — the risks choose the next step. Boehm’s own Difficulties section says it suits internal development and needs further work for contract acquisition, the opposite of what most people guess, so use it where you control the commitment points.

In practice nobody runs one row: a 1996 acquisition guidebook already reported that “most programs use a combination of all three” [18].

→ Waterfall · V-Model · Incremental · Iterative · Prototyping · Spiral

6. Choosing one — and what the evidence does not say

Start from a question, not a list: what kind of software is this — a back-end component, a service to an end user, or a visual interface [19]? Then the criteria that move the answer: stakeholders (expertise, commitment, availability), the environment (business, market, legal), and requirements certainty. Stakeholder availability is the one most often forgotten and most often decisive, because an iterative model with an absent customer is a plan-driven model with extra meetings.

Do not make the project fit the lifecycle. “The puritan approach of using a method, framework, process, and so forth without tailoring it to fit the specific organization’s business, technical, and marketing context is naive at best” [20]. Find the model that fits, then tailor it. In a survey of practitioners only about one process in five came from a planned improvement programme — the great majority emerged from experience on the ground [21]. Hybrids are not a failure of discipline; they are what the population actually does.

No study in this material says which lifecycle wins. What the sources establish is vocabulary and mechanism, not performance, and the “choose it when” column is reasoned from what each model does. Two things follow: say which argument you chose the model on, because the argument is the only part that can be examined; and treat “this lifecycle outperforms that one” as unsourced until someone shows you the comparison.

The thread tying the block together is risk, which has been choosing the process since 1970 in five notations: Royce’s do it twice (originality risk), Boehm’s spiral (risk as the driver), STSC 1996 (risk as an axis for choosing) [18], Cockburn (risk as criticality — “a more critical system… needs more publicly visible correctness in its construction”) [22], and Boehm and Turner (risk as a selector between method families) [23]. One question in five costumes: what could go wrong here, and which process is built to catch that?

→ Lifecycles · Balancing agility and discipline

Where this goes next

L2b makes the last row of that lineage its whole subject: the named frameworks — Scrum, XP, Kanban, RUP, SAFe — and Boehm and Turner’s five discriminators. See SN L2b. Revision questions for both Processes lectures are in RQ2.

---

Acknowledgments

This content is heavily inspired by and adapted from lectures by Eduardo Miranda and David Root [24] on software project management. The structure, examples, and pedagogical approach reflect their teaching materials and frameworks.

References

1. B. W. Boehm and P. N. Papaccio,
   “Understanding and controlling software costs,” IEEE Transactions on Software Engineering, vol. 14, no. 10, pp. 1462–1477, Oct. 1988, doi: 10.1109/32.6191.
2. M. Fagan,
   “A History of Software Inspections,” in Software Pioneers: Contributions to Software Engineering, M. Broy and E. Denert, Eds., Springer, 2002, pp. 215–222.
3. R. A. Radice, N. K. Roth, A. C. O’Hara, and W. A. Ciarfella,
   “A programming process architecture,” IBM Systems Journal, vol. 24, no. 2, pp. 79–90, 1985, doi: 10.1147/sj.242.0079.
4. W. E. Deming,
   Out of the Crisis. MIT Center for Advanced Engineering Study, 1986.
5. C. Y. Laporte and N. R. Papiccio,
   “Software and systems engineering process improvement at Oerlikon Aerospace,” 1996.
6. V. R. Basili, G. Caldiera, and H. D. Rombach,
   “The Goal Question Metric Approach,” in Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
7. V. R. Basili et al.,
   “Linking Software Development and Business Strategy Through Measurement,” Computer, vol. 43, no. 4, pp. 57–65, 2010, doi: 10.1109/MC.2010.108.
8. P. Fowler and S. Rifkin,
   “Software Engineering Process Group Guide,” 1990.
9. D. Hoffman,
   “The Darker Side of Metrics,” in Pacific Northwest Software Quality Conference (PNSQC), 2000.
10. K. S. Rubin,
    Essential Scrum: A Practical Guide to the Most Popular Agile Process. in Addison-Wesley Signature Series (Cohn). Addison-Wesley Professional, 2012. [Online]. Available: https://innolution.com/essential-scrum
11. P. J. Mota,
    “Scoreboard: A Support for Management Information Needs.” Carnegie Mellon University, 2009.
12. K. Schwaber and J. Sutherland,
    “The Scrum Guide.” Nov. 2020. [Online]. Available: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
13. P. Bourque and R. E. Fairley, Eds.,
    “SWEBOK: guide to the software engineering body of knowledge.” IEEE Computer Society, 2014.
14. W. W. Royce,
    “Managing the Development of Large Software Systems,” in Proceedings of IEEE WESCON, 1970, pp. 1–9.
15. C. Larman and V. R. Basili,
    “Iterative and incremental developments. a brief history,” Computer, vol. 36, no. 6, pp. 47–56, June 2003, doi: 10.1109/MC.2003.1204375.
16. R. S. Pressman,
    Software Engineering: A Practitioner’s Approach, 7th ed. McGraw-Hill, 2010.
17. B. W. Boehm,
    “A spiral model of software development and enhancement,” Computer, vol. 21, no. 5, pp. 61–72, May 1988, doi: 10.1109/2.59.
18. “System Life Cycle and Methodologies.” US Air Force Software Technology Support Center, 1996.
19. N. B. Ruparelia,
    “Software development lifecycle models,” ACM SIGSOFT Software Engineering Notes, vol. 35, no. 3, pp. 8–13, May 2010, doi: 10.1145/1764810.1764814.
20. A. J. Lattanze,
    Architecting Software Intensive Systems: A Practitioner’s Guide. Auerbach Publications, 2009. doi: 10.1201/9781420045703.
21. M. Kuhrmann et al.,
    “Hybrid Software Development Approaches in Practice: A European Perspective,” IEEE Software, vol. 36, no. 4, pp. 20–31, 2019, doi: 10.1109/MS.2018.110161245.
22. A. Cockburn,
    “Selecting a Project’s Methodology,” IEEE Software, vol. 17, no. 4, pp. 64–71, July 2000, doi: 10.1109/52.854070.
23. B. Boehm and R. Turner,
    “Using risk to balance agile and plan-driven methods,” Computer, vol. 36, no. 6, pp. 57–66, June 2003, doi: 10.1109/MC.2003.1204376.
24. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

---

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.