Software Engineering

Unified Software Development Process

Published: 2026-08-16

Level: postgraduate

Audience: Postgraduate students in Software Engineering

Prerequisite Knowledge

This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.

Previously Covered in This Subject

The four fundamental software process activities (specification, development, validation, evolution) — covered in Lecture 1 (The Software Process) and Lecture 2 (What Is a Software Process?)
The Rational Unified Process — covered in Lecture 2 (Software Processes)
The waterfall model and incremental development — covered in Lecture 2 (Software Processes)
Software evolution — covered in Lecture 2 (Software Evolution)
Requirements engineering — covered in Lecture 3 (Requirements Engineering)
UML systems modeling — covered in Lecture 4 (Systems Modeling)
Modular decomposition in architectural design — covered in Lecture 5 (Architectural Design)
Verification, validation, and software testing — covered in Lectures 2, 7, and 8 (Software Processes; Software Testing)

# Unified Software Development Process

This lecture presents the unified process (UP), the primary methodology for object-oriented software development. It starts with the big picture — the four core activities every software project shares and the two-dimensional view of workflows inside phases — then walks through how UP came to be, how its technical workflows and business phases work, and what happens after delivery: maintenance and retirement. Along the way, the requirements, analysis, design, implementation, and test workflows are each examined in turn, because understanding what each workflow is for — and where it typically fails — is the key to seeing why the whole process is built the way it is.

9.1 The Unified Process at a Glance

9.1.1 No One Process Model Fits Every Project

Hook: If one fixed, step-by-step recipe could produce all software, every project in the world would follow the same instruction sheet. So why is there no such recipe — and what do we do instead?

Software processes vary from project to project and from organization to organization. No single process model fits all projects. Application domains differ enormously — insurance, aerospace, and manufacturing are just three — and so does the work within them. The method used to take a commercially available off-the-shelf (COTS) package and get it to market earlier than the competition is different from the method used to construct a high-security electronic funds transfer network for a bank. The skills of the software development professionals involved vary just as widely.

Intuition + Analogy: Think of a process model as a chef's cookbook. A cookbook for a fast-food counter (an off-the-shelf product rushed to market) is a short list of fixed steps: fry, assemble, wrap. A cookbook for a state banquet (a bank's high-security funds-transfer network) must handle dozens of courses, dietary restrictions, and unforseen emergencies — no fixed recipe can cover both. The analogy breaks down where software is concerned, because software has no "recipes" at all: the process only shapes the work; it cannot guarantee the product.

The result is that every serious software effort needs a process that has been adapted to its own situation. This lecture's subject — the unified process — is exactly such an adaptable method, and it works precisely because it does not pretend to be one universal recipe.

9.1.2 The Four Core Activities of Software Development

Whatever exact process a project follows, software development has four main activities:

Specification — deciding what the software should do.
Development — building it.
Validation — checking that it does what it should.
Evolution — changing it as needs change.

These four activities are universal: an insurer, an aircraft maker, and a manufacturer each perform them, even though the weight each one gets differs from project to project. For example, a high-security banking network spends heavily on validation (verifying that money transfers are correct and safe), while a COTS product rushed to market may compress validation and lean on evolution instead — releasing early and fixing issues in later versions.

Why the four activities matter: They give you a mental skeleton for any process you meet later. Every process model — waterfall, spiral, agile, or the unified process — is just a particular way of organizing specification, development, validation, and evolution over time. When a new model appears, ask: where does it put each of these four activities, and in what order?

The unified process (UP) integrates the best of other process models. Its two-dimensional view — technical workflows along one axis, business phases along the other — helps you see both the technical and the business aspects of any software development effort.

9.1.3 A Methodology, Not a Fixed Recipe

The unified process is a methodology, meaning it is a general approach rather than a specific series of steps that, if followed, automatically produce a software product. A software development method is one component of a process, and the primary method for object-oriented application development is the unified process. Because software products vary so widely, no single universal process model could ever exist. UP is best viewed as an adaptable method that is modified for the specific product being developed. Much of the full UP is not applicable to small or even medium-scale projects, so this material focuses on the subset of the unified process that applies to a wide variety of software projects.

Methodology vs. process vs. method: A process is everything that goes into producing software in an organization — the methodology, its underlying life-cycle model, the techniques, the tools, and the people. A method (or methodology) is one component of that process: the general approach used to develop the software. The unified process is a methodology, so it is one — very important — component of a complete software process, not the whole of it.

Assumption & Scope: UP was created primarily for large, complex, object-oriented software products, and the full methodology is itself large. Much of it does not apply to small or medium-scale projects. When the lecture or a textbook talks about "the unified process," it usually means the common subset that applies to products of all sizes — and the big-project machinery (detailed case studies, heavy documentation sets) is omitted. Do not assume every UP artifact must be produced for a small project.

9.1.4 The Two Dimensions: Workflows and Phases

UP is built on the object-oriented paradigm and is both iterative and incremental. Its main technical activities are the workflows of specification or requirements, analysis, design, and implementation — which together form development — plus testing for validation. After validation comes maintenance or evolution, and eventually retirement. These technical workflows run inside four business phases: inception, elaboration, construction, and transition. Seeing the software process as a two-dimensional space of workflows and phases is the central idea of the overview.

The two axes answer two different questions. The workflow axis answers the technical question: what kind of engineering work is being done right now? The phase axis answers the business question: how far along is the project toward delivering value?

Dimension	Axis of the model	Question it answers	Units
Workflows (technical)	Horizontal axis	What kind of technical work is happening — requirements, analysis, design, implementation, or testing?	Activities
Phases (business)	Vertical axis	How far along is the project — inception, elaboration, construction, or transition?	Time / business stages

The two axes always work together: any step performed in UP belongs to exactly one workflow and exactly one phase. For example, building a business case is part of the requirements workflow, and it is also part of the inception phase. Understanding this pairing is the single most important idea of the whole lecture, because it is what makes UP a two-dimensional model — unlike classical models such as the waterfall, which has only the single "time" axis.

Pitfalls

Treating UP as a fixed recipe: it is a methodology that must be adapted; following it blindly is not following it at all.
Confusing the four core activities (specification, development, validation, evolution) with the five workflows: the activities are the universal goals, while the workflows are UP's specific technical mechanisms for achieving them.
Forgetting that "methodology" is only one component of a "process" — process also includes tools, techniques, life-cycle model, and people.
Memorizing the phase names without the workflow names: an exam question on "the two dimensions of UP" expects both lists, paired together.

Recap + Bridge: The unified process is an adaptable methodology, not a fixed recipe, built on four universal activities and seen through two dimensions: five technical workflows (requirements, analysis, design, implementation, testing) running inside four business phases (inception, elaboration, construction, transition). With this frame in place, the next question is historical: how did one model come to unify three rival object-oriented methods?

Real-world: These contrasts are not academic. Insurers, aerospace firms, and manufacturers genuinely run different processes; a COTS vendor's time-to-market method and a bank's funds-transfer network method are different in practice — which is exactly why the unified process must be adaptable rather than fixed.

9.2 How the Unified Process Came to Be

9.2.1 Three Methodologies, One Model

The unified process model was the result of amalgamating three object-oriented development methods: the Booch method, Jacobson's Objectory, and Rumbaugh's object modeling technique (OMT). The three shared certain similarities and each had good aspects, so they were unified into one complete software development method. Because the company creating it was Rational, the merged methodology was first called the Rational Unified Process.

The three methods came from different origins. OMT was developed by Jim Rumbaugh and his team at the General Electric Research and Development Center in Schenectady, New York. Grady Booch developed his method at Rational, Inc., in Santa Clara, California. Ivar Jacobson authored the Objectory methodology. All object-oriented development methods are essentially equivalent in power, so the differences between OMT and the Booch method were small — yet each had a loyal following.

How the unification happened: In October 1994, Rumbaugh joined Booch at Rational, and the two began work on a methodology combining OMT and the Booch method. When a preliminary version appeared, critics pointed out that what had been produced was a notation for representing object-oriented software rather than a full methodology — so the name "Unified Methodology" was quickly changed to Unified Modeling Language (UML). In 1995, Ivar Jacobson joined them, and the three — Booch, Jacobson, and Rumbaugh, affectionately nicknamed the "Three Amigos" — worked together. UML version 1.0 was published in 1997 and rapidly became the international standard notation for object-oriented software. The three then went further and published a complete development methodology unifying their three methods: this was first called the Rational Unified Process (RUP) — "Rational" simply because all three were then senior managers at Rational, Inc.

Intuition + Analogy: Imagine three rival cooks each with a praised signature dish: one excels at sauces (OMT's data modeling), one at plating (Booch's design), and one at running the kitchen (Objectory's use-case approach). Rather than keep three separate restaurants, they merge into one kitchen that keeps the best technique of each cook. The analogy holds for the technique (each method contributed its strengths), but breaks down where naming is concerned: the merged product was not simply one of the three dishes — it became a new, unified way of working that none of the three alone provided.

9.2.2 From Rational to the Unified Process

Rational was later bought by IBM, and the process was renamed the unified software development process. Today it is called the unified process for brevity. None of this changes the essentials: UP is not a series of steps for constructing a product, because no methodology fits all types of software. It remains an adaptable method that can be modified for the specific product to be developed.

Scope note: The historical names matter mainly for recognizing older documents. The Rational Unified Process (RUP), the unified software development process (USDP), and the unified process (UP) all refer to essentially the same methodology at different points in its naming history. RUP in particular survives as a widely used commercial product name in industry, so you will meet all three spellings — they are not different methods.

9.2.3 UML, the Modeling Language

UP includes the unified modeling language (UML), one of the best modeling languages available today. UML enables software engineers to build graphical models and to communicate their analysis and design ideas quickly and accurately.

Why a graphical language: An orchestral score shows which instruments play which notes and when, plus tempo, key, and dynamics — no verbal description could replace it ("the first bar begins with the A above middle C on the violin, while the pianist plays a seven-note chord..."). Software is the same: the cleanest way for engineers to communicate structure is a diagram. UML is the international standard notation for that purpose, maintained through the Object Management Group (OMG), so that every software professional worldwide draws the same symbols.

Recap + Bridge: The unified process unified the Booch method, Objectory, and OMT into one adaptable methodology — first called the Rational Unified Process, later renamed the unified process — and it ships with UML, the standard modeling language for expressing its models. Next we see what modeling means inside UP: a model is a set of UML diagrams, and the object-oriented paradigm behind them is iterative and incremental by nature.

Real-world: UML and the unified process are widely used in industry, from large enterprise systems to embedded software; tools implementing UML (originally including Rational's own CASE tools) are standard items in software organizations.

9.3 UML and the Object-Oriented Paradigm

9.3.1 A Model Is a Set of UML Diagrams

UP is a modeling technique. A model is a set of UML diagrams that represent one or more aspects of the software product to be developed. The main reason for using a graphical representation is simple: a picture is worth more than a thousand words, and UML is at its best expressed through pictures.

Hook + Analogy: How do you describe a house to a builder — with a thousand words, or with floor plans? The floor plans, of course. A model is exactly that: a set of UML diagrams that represents one or more aspects of the software product to be developed. UML diagrams let software professionals communicate with each other more quickly and more accurately than verbal descriptions ever could — the professor's proverb, a picture is worth a thousand words, is the whole justification for modeling.

What a model is: A model is not the product itself — it is a representation of the product, focused on the aspects that matter at a given moment. Different diagrams capture different aspects: some show the structure of the data, others show behavior over time, others show how components interact. One model may contain many diagrams, and one product may need several models at different levels of abstraction. UML is the notation in which these models are drawn.

9.3.2 Iterative and Incremental by Nature

The object-oriented paradigm is both iterative and incremental in nature. Today this is the best way to develop any software when the requirements are uncertain: you iterate and increment using UML and keep going until the requirements are satisfied. A workflow consists of a number of steps, and to carry out that workflow the steps are repeated until the members of the development team are satisfied that they have an accurate UML model of the software product they want to develop.

Iteration vs. incrementation, precisely:

Iteration means producing successive versions of one artifact — build version 1, revise it into version 2, and so on — each version closer to the target than the last.
Incrementation means building the artifact piece by piece: construct the pieces that solve the most important sub-problems, then add more pieces, extending the artifact until it covers the whole problem.

They are used together: an artifact is constructed piece by piece (incrementation), and each piece goes through multiple versions (iteration). In the object-oriented paradigm, the pieces are expressed as UML models, so the team iterates and increments the diagrams until the models accurately represent the product.

Why requirements uncertainty forces iteration: When the requirements are uncertain, no one can draw a correct model immediately. The only reliable strategy is to draw the best possible model given what is known now, then repeatedly refine it (iterate) and extend it (increment) as more is learned — until the team agrees the model is accurate. This is why UP is said to be iterative-and-incremental by nature.

9.3.3 Why Even Experts Iterate

Even the most experienced software professionals iterate and re-iterate until they are finally satisfied that the UML diagrams are correct. Almost no software engineer today, no matter how outstanding, gets the analysis and design work products right the first time. Everything in software development is iterative and incremental because it is difficult to consider too many aspects of the software product at once. That is why the process needs levels of abstraction and modeling at various levels, which the unified process model provides.

Why even the best engineers fail on the first attempt: Human beings can actively process only about seven chunks of information at a time — Miller's Law. A real software product has far more than seven requirements, variables, and interactions. So nobody can hold the whole product in mind at once; everyone must work on the most important pieces now and postpone the rest (stepwise refinement), then revisit. Iteration and incrementation are not a sign of weakness — they are the only way human minds can handle software complexity at all.

Pitfalls

Believing that a correct analysis or design "should" be possible on the first attempt: even outstanding professionals almost never produce correct work products first time — plan for revision rather than perfection.
Treating iteration as aimless rework: every iteration must move the model closer to the target, guided by what was learned in the previous pass.
Forgetting the levels of abstraction: because no one can consider everything at once, the process must offer modeling at several levels — the unified process model is what provides them.
Confusing the workflow (the steps repeated) with the model (the diagrams produced): a workflow is carried out by iterating; the UML model is the result of that iteration.

Recap + Bridge: A model is a set of UML diagrams; the object-oriented paradigm is iterative and incremental by nature, and even the most experienced professionals iterate because human working memory handles only about seven chunks at once. This is why UP provides levels of abstraction — and next we see what iteration and incrementation look like in practice: the effort picture of the five workflows spread across four increments.

Real-world: Iterative development is empirically the dominant successful strategy — industry surveys of project outcomes repeatedly associate iterative processes with successful projects, which is one reason UP-style iteration underpins most modern agile practices as well.

9.4 Workflows Within Increments: The Effort Picture

9.4.1 Reading the Effort Curves

Hook: If every project needs requirements, analysis, design, implementation, and testing, does the team do all five activities only once, in a strict order? The effort picture of the unified process shows the truth: all five run throughout the life cycle — but each one dominates at a different time.

In the graphical representation of iteration within UP, the shaded area under each curve is the effort — measured in person hours — spent on each of the five technical workflows: requirements, analysis, design, implementation, and testing. These workflows are performed iteratively for each increment. An increment is a delivery of the product with some features, which later increments elaborate with more features. Any number of increments is possible, but for simplicity the explanation uses four increments (A, B, C, and D), in which the product is delivered as four modules.

The axes and the meaning of the picture: Imagine a chart with time on the horizontal axis and person hours on the vertical axis — one person hour is the amount of work one person can do in one hour, so a team of five working a full day (8 hours) produces $5 \times 8 = 40$ person hours. For each of the five workflows there is a curve whose height at any moment shows how many person hours per day the team is spending on that workflow. The shaded area under each curve is the total effort spent on that workflow:

$E_{i} = \int_{t_{0}}^{t_{1}} p_{i} (t) d t$

where $E_{i}$ is the total effort (in person hours) on workflow $i$ over the project, $t_{0}$ is the project start, $t_{1}$ the finish, and $p_{i} (t)$ is the person hours per unit time spent on workflow $i$ at time $t$ . A curve that is high and wide has a large shaded area — that workflow consumed a large share of the total effort.

9.4.2 How Effort Moves Between Workflows

During the first increment, the effort spent on requirements is significant, and it tapers down toward the second increment as the requirements become clearer. The analysis workflow — where the UML models are drawn — follows requirements capture and is primarily in the second increment. Design activity appears in the second increment and predominates in the third. Implementation starts concurrently once design has begun and takes a significant amount of effort in the third increment. Testing effort, though present right from the initial phase, is heaviest toward the fourth increment. This is the pattern of iteration of the five technical workflows within each increment.

Visual intuition: Picture the four increments as four vertical columns (A, B, C, D) side by side, each containing the same five horizontal bands — requirements, analysis, design, implementation, testing. In column A the requirements band is tall; in column B the analysis band is tallest; in column C the design band is tallest, with implementation rising; in column D the testing band dominates while requirements has almost vanished. Read the columns from left to right and you literally watch the emphasis flowing from early workflows to late ones. The one-sentence takeaway: the five workflows all run throughout the project, but each has its own peak period.

Assumption & Scope: This picture shows one possible decomposition, not the universal truth. Another product might be built in just two increments, a third in fourteen. The chart is not an accurate plan of any particular project — it exists to show how the emphasis shifts from workflow to workflow over time. Do not memorize "increment A = requirements only": every increment contains parts of all five workflows, in different proportions.

9.4.3 The Effort Split Across the Life Cycle

How does the total effort divide among workflows? As a rough rule of thumb, about one-fifth of the total effort goes to the requirements and analysis workflows taken together, another one-fifth to the design workflow, and about three-fifths to the implementation workflow:

$E_{req+analysis} \approx \frac{1}{5} E_{total}, E_{design} \approx \frac{1}{5} E_{total}, E_{implementation} \approx \frac{3}{5} E_{total}$

These proportions match the relative sizes of the shaded areas in the effort picture: the requirements and analysis curves cover about a fifth of the total area, design another fifth, and implementation — together with the testing that accompanies it — the remaining three-fifths. The exact figures vary from project to project; the point is the shape: the effort is heavily weighted toward the later, code-producing workflows, which is why getting the early workflows right is so valuable — errors found there are far cheaper to fix than errors discovered during implementation.

Pitfalls

Reading the effort curves as "requirements only in increment A, testing only in increment D": all five workflows are present in every increment, just in different proportions.
Forgetting what the vertical axis measures: effort is person hours, not calendar time — five people for a week equals more effort than one person for a week, even though both may take a week of calendar time.
Treating the 20/20/60 split as a precise budget: it is a rough guide to emphasis, not a billing rule.
Confusing an increment (a delivery of the product with some features) with an iteration (a revision pass inside an increment) — increments deliver, iterations refine.

Recap + Bridge: The effort picture shows all five technical workflows running through every increment, each with its own peak — requirements early, analysis and design in the middle, implementation and testing late — with effort weighted about 20% to requirements+analysis, 20% to design, and 60% to implementation. These four increments are the business phases of UP, examined next: inception, elaboration, construction, and transition.

Real-world: Person-hour effort curves are the same currency project managers use today when they build burndown charts and capacity plans: the chart tells the business where the money is being spent and when.

9.5 The Four Phases of the Unified Process

Hook: The four increments of the effort picture (A, B, C, D) are not abstract labels — they are the four business phases of the unified process. Each one answers a business question: Should we build this? What exactly will we build? Can we build it? Have we met the client's needs?

9.5.1 Inception

The increments just described are identified as the phases of the unified process; these are business phases. In the inception phase you primarily capture requirements and start testing. There is not much implementation, design, or analysis yet, although analysis begins very early — soon after the basic requirements are captured.

What inception really decides: The aim of the inception phase is to determine whether it is worthwhile to develop the target software product at all — its primary purpose is deciding economic viability. The steps are: gather domain knowledge, build a business model, delimit the project's scope, and make the initial business case — answering whether the product is cost effective, can be delivered in time, and what risks are involved and how they can be mitigated. Implementation is mostly absent (sometimes only a proof-of-concept prototype is built), and testing begins at once, mainly to ensure the requirements are determined accurately.

9.5.2 Elaboration

In the elaboration phase, the artifacts created during inception are elaborated: the requirements, the analysis artifacts, a little design of prototypes, and some implementation of prototypes or related activity. Testing continues to be an important activity carried out throughout the life cycle.

What elaboration really does: The name says it all — the major activities of this phase are refinements of the previous phase. The aim is to refine the initial requirements, refine the architecture, monitor the risks and refine their priorities, refine the business case, and produce the software project management plan. Most of the analysis workflow is performed here, and the design of the architecture begins. By the end of elaboration, the team knows what will be built and how it will be organized — the architecture is settled enough that construction can proceed.

9.5.3 Construction

In the construction phase there is little requirements work, more analysis, more design, and substantial implementation, and testing also begins in earnest.

What construction really produces: The aim of the construction phase is to produce the first operational-quality version of the software product — the so-called beta release. The emphasis is on implementation and testing: components are coded and unit tested, the code artifacts are compiled and linked (integrated) into subsystems, the subsystems are integration tested, and the combined system is product tested. By the end of construction, the product works; what remains is proving it in the client's world.

9.5.4 Transition

Testing begins and ends in the final phase, transition. The four phases of the unified process model are inception, elaboration, construction, and transition.

What transition really verifies: The aim of the transition phase is to ensure that the client's requirements have indeed been met. This phase is driven by feedback from the sites where the beta version has been installed (for a custom product, that is a single client site). Faults are corrected, all manuals are completed, and any previously unidentifed risks are sought out. When transition finishes, the product is delivered.

Phase	Business question	Main emphasis	Key results
Inception	Is it worth building?	Requirements capture, initial business case, early testing	Initial requirements, initial business case, risk list
Elaboration	What exactly will we build?	Refining requirements, almost all analysis, architecture design	Completed requirements and analysis artifacts, architecture, software project management plan
Construction	Can we build it?	Implementation and testing in earnest	First operational-quality (beta) version
Transition	Did we meet the client's needs?	Testing driven by beta-site feedback, fault fixing, manuals	Final version meeting the requirements

Exam note: The four phases of the unified process — inception, elaboration, construction, and transition — and what each phase emphasizes are core examinable material. Be ready to state the phase names in order, name the dominant workflows of each phase, and explain that these phases correspond to increments of the iterative-and-incremental model.

Pitfalls

Writing "inception = requirements, transition = testing": all four phases contain all five workflows — inception primarily captures requirements and starts testing; transition is where testing culminates.
Forgetting that the phases are business phases: they answer business questions (viability, scope, delivery, acceptance), while the workflows are the technical context.
Thinking transition is a small "handover meeting": it is a full phase driven by beta-site feedback, fault correction, and manual completion.
Confusing "phase" with "iteration": phases are increments (deliveries), while iterations are the revision passes that happen inside each phase — the topic of the next section.

Recap + Bridge: The four increments of the effort picture are the four business phases: inception decides viability, elaboration refines requirements and settles the architecture, construction produces the first operational-quality version, and transition verifies the client's requirements are met. Inside each phase, the team does not work once through the five workflows — it iterates, as section 9.6 shows.

Real-world: This four-phase skeleton is exactly how large industrial projects are funded and reviewed: a company commits money at the end of inception (go/no-go on the business case) and again at the end of elaboration (go/no-go on architecture), then funds construction and transition.

9.6 Iteration Within Phases

Hook: The effort picture shows four big increments — but between any two deliveries, the team is not idle. Inside each phase, the five workflows are repeated in small passes called iterations. What does one of those passes look like?

9.6.1 Iterations Inside a Phase

Incrementation produces the phases; iteration happens inside them. Consider the elaboration phase, increment B. The iteration is shown as B.1, B.2, and B.3 — three iterations, each containing some requirements, analysis, design, implementation, and testing activity. You iterate the requirements until they are satisfied, then move to the next iteration, and keep going until the work products are satisfactory. Only when the iterations within a phase are complete do you move to the next increment.

Iteration B.1, B.2, B.3, step by step: Each numbered iteration is a complete mini-pass through all five workflows. Iteration B.1 consists of requirements, analysis, design, implementation, and testing activity, and it continues until the artifacts of each of the five workflows are satisfactory. Then all five sets of artifacts are iterated again in B.2 — the requirements artifacts are improved, which triggers improvements to the analysis artifacts, which trigger design improvements, and so on. The third iteration B.3 repeats the cycle. Only when all iterations inside the phase are complete does the team finish increment B and move to the next phase.

Worked example — the ripple effect inside an iteration: Suppose Iteration B.1 delivers an analysis model with three classes: Customer, Account, and Transfer. In B.2, the team realizes that a customer can hold accounts in two currencies. That single requirements-level correction ripples through the iteration: the analysis model gains a Currency class (analysis), the design adds a currency attribute to Account (design), a small prototype is extended to display both amounts (implementation), and the test cases are updated to cover currency conversion (testing). The ripple is exactly why each iteration re-runs all five workflows rather than only fixing the one artifact — one change in one artifact forces changes in the others.

9.6.2 Iteration and Incrementation Together

The workflows — requirements, analysis, design, implementation, and testing — are iterated as long as the results are satisfactory to the team, and then the team moves to the next phase. Incrementation and iteration are used in conjunction with one another. Notice that there is no dedicated requirements phase or design phase: every phase contains all five workflows, just in different proportions.

Intuition + Analogy: Think of writing a report. You do not write the introduction, then the body, then the conclusion once each and hand it in. You write a rough draft of the whole report (incrementation — one version), read it, fix the introduction, adjust the body to match, update the conclusion (iteration — a revision pass), and repeat until it reads well. The report's final "deliverables" only emerge after several revision passes, and every pass touches all parts of the report. The analogy breaks down in scale: a software iteration touches thousands of artifacts, not three sections — which is why the process must structure the passes instead of leaving them informal.

Pitfalls

Believing a phase is "the requirements phase" or "the design phase": UP has no dedicated phase for any single workflow — every phase contains all five workflows in different proportions.
Thinking iteration is optional polish: iteration is the mechanism that makes requirements uncertainty survivable — without the B.1/B.2/B.3 passes, errors would survive into delivery.
Confusing iteration with incrementation: incrementation delivers new pieces (phases A, B, C, D); iteration refines the pieces already there (B.1, B.2, B.3 inside phase B).
Ending a phase early because the current workflow looks finished: the team may move on only when the work products of the whole iteration are satisfactory.

Recap + Bridge: Iteration happens inside phases: increment B runs iterations B.1, B.2, and B.3, each a complete mini-pass through all five workflows, and the team moves to the next phase only when the work products are satisfactory. This per-iteration pass through the five workflows makes each iteration a miniature waterfall — a point the episode model makes concrete next.

Real-world: This is the structure behind modern practice: each sprint or iteration in industry is expected to deliver something testable and working — exactly the "all five workflows in every iteration" rule of UP, decades before the term sprint became popular.

9.7 Episodes: Versions, Maintenance, and Mini-Projects

Hook: The effort picture makes development look like a clean sequence of four deliveries. Real projects are messier: an implementation gets started and abandoned, a design is thrown out and redone, requirements change in the middle. The episode model captures exactly that messy reality — and shows how maintenance fits between the deliveries.

9.7.1 A Sequence of Episodes

Development proceeds through episodes. Episode 1 is straightforward: one iteration of requirements, analysis, design, and implementation. In episode 2, the team starts a new alternative implementation based on the same design, and aborts it as soon as it begins. Based on the analysis, a new design is created and tried out in episode 3. Then the requirements change, and episode 4 redoes requirements, analysis, design, and implementation once again with the new requirements. Products are built incrementally in various versions, and not every version includes every workflow: episode 2 has only the implementation workflow, episode 3 has a little design and implementation, and episode 4 has the full set.

What the episode picture shows: Draw each episode as a column of boxes — one box per workflow used. Episode 1 shows the full stack: Requirements 1, Analysis 1, Design 1, Implementation 1. Episode 2 contains only Implementation 2 (an alternative implementation of the same design, drawn truncated because it was aborted). Episode 3 shows Design 3 and Implementation 3 — a new design tried out, based on the existing analysis. Episode 4 shows the full stack again with new content: Requirements 4, Analysis 4, Design 4, Implementation 4. Two lessons follow. First, an increment may be abandoned — increment B (episode 2) was never completed because its implementation was not found to be useful. Second, not every increment includes every workflow: the iterative-and-incremental model does not require all five workflows in every increment.

Pitfalls

Assuming every increment must contain all four development workflows: episode 2 has only implementation, episode 3 only design and implementation — a partial increment is legitimate.
Reading "aborted implementation" as a sign of failure: abandoning an alternative implementation early is cheap, deliberate risk-taking — the team tested an idea and dropped it before investing more.
Confusing episodes with phases: episodes are the actual history of versions (with abandonments and restarts), while phases are the four business stages of UP — the episode picture is a description of what really happens, not a plan.

9.7.2 Corrective and Perfective Maintenance

In the graphical picture, solid lines are development and dotted lines are maintenance. Improving the implementation or the design is maintenance. Each episode corresponds to an increment, and an increment may be abandoned — increment B was not completed because its implementation was not found to be useful. Maintenance that improves the implementation or the design is corrective maintenance; maintenance that changes the requirements to improve the product, as episode 4 does, is perfective maintenance.

The two maintenance types, contrasted:

Aspect	Corrective maintenance	Perfective maintenance
What changes	The implementation or the design	The requirements themselves
Why	To fix faults or replace a bad implementation/design	To improve the product by changing what it must do
Example (episodes)	Episode 2: abort a poor alternative implementation; episode 3: replace the design with a faster algorithm	Episode 4: the requirements are changed (e.g., increased accuracy demanded) and all downstream workflows are redone

Episode 2 corrects the implementation; episode 3 corrects the design. Episode 4 is different in kind: the requirements change, so analysis, design, and implementation must all be redone to match. Note the causal chain in the picture: solid arrows show development (each episode builds on the previous one), dotted arrows show maintenance (episode N revises artifacts inherited from earlier episodes).

9.7.3 Each Iteration Is a Mini-Waterfall

The project as a whole can be considered a set of many mini-projects and increments. Each mini-project extends the requirements, analysis, design, and implementation artifacts, and the final set of artifacts is the complete project. Each iteration can be viewed as a very small but complete waterfall lifecycle model: you select a portion of the software product and run it through the requirements, analysis, design, and implementation phases of the waterfall model.

Intuition + Analogy: A waterfall model is a strict one-way flow: requirements, then analysis, then design, then implementation. A single UP iteration is a tiny waterfall: the team selects one portion of the product, runs it through the same sequence, and checks it before moving on. The whole project is simply a sequence of many tiny waterfalls, one after another — which is why the iterative-and-incremental model is as disciplined as the waterfall, not a chaotic free-for-all: at every moment, some mini-project is executing its own orderly requirements-to-implementation flow.

9.7.4 Baselines: A Snapshot After Every Episode

A useful idea that comes out of the episode picture is the baseline: the complete set of artifacts that exists at the end of an episode. After episode 1 the baseline is {Requirements 1, Analysis 1, Design 1, Implementation 1}. After episode 2 it is the same requirements, analysis, and design with the modified (but never completed) Implementation 2 — so the baseline reflects the change even though the episode aborted. After episode 3 the baseline is {Requirements 1, Analysis 1, Design 3, Implementation 3}. After episode 4 it is the all-new {Requirements 4, Analysis 4, Design 4, Implementation 4}.

The point of a baseline is that the team always knows exactly what the product is at any moment: a baseline is the official snapshot that testing, review, and future maintenance work against. When a later episode changes only part of the product, the unaffected artifacts stay exactly as they were in the previous baseline — nothing silently drifts.

Recap + Bridge: Episodes show the real history of a product: solid arrows are development, dotted arrows are maintenance; corrective maintenance improves implementation or design, perfective maintenance changes the requirements; each iteration is a miniature waterfall, and a baseline snapshot exists at the end of every episode. With the life cycle fully mapped, the lecture now turns to the workflows themselves, starting with the requirements workflow — where the whole process begins.

Real-world: Baselines are everyday practice in industry: version-control tags, release branches, and configuration management records exist precisely so the organization can say, at any moment, exactly what the product contains — the same idea as the episode baselines.

9.8 Requirements Workflow

Hook: The client asks for a product, the developers build it to the specification, and a year later the client says: "This may be the specification, but this is not what I really wanted." Why does this happen so often — and how does the requirements workflow try to stop it?

9.8.1 Aim: Determine the Client's Needs

Software development is expensive, and the process usually begins when a client approaches a development organization with a software product that, in the client's opinion, is either essential to the profitability of the enterprise or can be justified economically. The aim of the requirements workflow is for the development organization to determine the client's needs. The first task of the development team is to acquire a basic understanding of the application domain — the specific environment in which the target software product is to operate. The domain could be the industry itself: banking, automobile, manufacturing, nuclear power, and so on.

Domain first, product later: The developers cannot give any kind of reliable opinion about a proposed product until they understand the domain in which it will operate. Whether the domain is a television network, a machine-tool company, or a hospital specializing in liver disease, little reliance can be placed on anything built without domain knowledge. The team's first job is to learn the environment; only then can they judge whether the client's request makes sense — a theme that returns in 9.8.5.

9.8.2 The Business Case

At any stage of the process, if the client stops believing that the software will be cost effective, the development project will be terminated immediately. So a vital aspect of software development is the business case: a document that shows the cost effectiveness of the target product. The cost is not always purely financial — some products are built for strategic or tactical reasons. The cost of the software can be understood as the potential damage that could be suffered in the absence of the software being developed.

What "cost" means in the business case: The business case shows that the target product is cost effective — that the benefits of building it outweigh the costs. The cost is not always a price tag: for military software, the "cost" of the software is the potential damage that could be suffered in the absence of the weapon being developed, so the product is justified strategically or tactically rather than financially. Because the project dies the moment the client stops believing in cost effectiveness, the business case is a living document: if it stops being convincing at any stage, development ends immediately.

9.8.3 The Initial Meeting and Constraints

At the initial meeting between client and developers, the client outlines the product as he conceptualizes it. From the developers' viewpoint, that description may be vague, unreasonable, contradictory, or simply impossible to achieve. The developers' task at this stage is to determine exactly what the client needs and to find out what constraints exist. One major constraint is usually the deadline: the client may stipulate that the project must be completed within three months. In almost any application domain today, target software is mission critical — the client needs it for core activities of the organization, and any delay in delivery can be detrimental. A variety of other constraints apply too, like reliability, performance, and cost. Early on we met the triple constraints of quality, time, and cost — good, fast, and cheap — and cost is invariably an important constraint.

The constraint set: The developers must extract every constraint, not just the headline ones:

Deadline — e.g., the product must be delivered within three months. Because the software is mission critical (needed for the client's core activities), any delay is detrimental to the client organization.
Reliability — e.g., the product must be operational 99% of the time, or the mean time between failures must be at least four months.
Performance and size — e.g., response times, or an executable that must fit on the client's hardware.
Cost — almost invariably important; the triple constraints of quality, time, and cost (good, fast, and cheap) apply here as everywhere in software engineering.

The client's opening description is only a starting point: it may be vague, unreasonable, contradictory, or impossible — the developers' job is to discover the needs behind it and the constraints around it.

9.8.4 Concept Exploration and the Bidding Process

The client rarely tells the developers how much money is available to build the product. A common practice instead: once specifications are finalized, the client asks the developers to name their price for completing the project. Clients follow this bidding procedure in the hope that the amount the developers bid is lower than the amount the client has budgeted. The preliminary investigation of the client's needs is sometimes called concept exploration, where, in subsequent meetings between clients and developers, the functionality of the proposed product is successively refined and analyzed for technical feasibility and financial justification.

Intuition + Analogy: The bidding procedure works like asking a contractor to price a house without ever revealing your budget: the client wants the developers' honest number to be below what the client has secretly set aside. The analogy breaks down where information is concerned — in software the client's request is usually imprecise, so the price the developers quote is only as good as the requirements behind it. That is why concept exploration (successive refinement of functionality, checked for technical feasibility and financial justification) must come before any bid.

9.8.5 When Requirements Work Is Done Badly

When the requirements workflow is performed inadequately, the final product delivered a year or two later may be met with: "this may be the specification, but this is not what I really wanted." Several reasons explain this. The client may not truly understand what goes on in her own organization — a client has no use asking for a faster operating system if the real cost of the current slow turnaround is a badly designed database. Or a client running an unprofitable chain of stores may ask for a financial management information system that reflects items such as sales, salaries, and accounts payable — but such a product would reduce the real value of the losses, namely shrinkage or theft by customers and employees. What that client actually needs is a stock control system rather than a financial management system.

Worked example — the stock control system (what the client really needed): A store chain loses money every year. The client asks the developers for a financial management information system that reports sales, salaries, and accounts payable — a perfectly reasonable-sounding request. But suppose shrinkage — theft by customers and employees — is the true source of loss:

Recorded annual sales: USD 2,000,000. Recorded inventory purchases at cost: USD 500,000.
Shrinkage rate in this chain: about 3% of sales → $0.03 \times $2, 000, 000 = $60, 000$ of goods vanish each year without being recorded as sold.
A financial MIS reads the recorded numbers: sales, salaries, payables. It can report exactly what is in the books — and the books say nothing about the USD 60,000, because the goods were never recorded as sales at all. The financial system cannot see shrinkage.
A stock control system tracks physical inventory: at year-end it counts goods still in the store — say USD 440,000 worth at cost remain, meaning $$500, 000 - $440, 000 = $60, 000$ is unaccounted for, matching the shrinkage estimate.

Final answer: the product the client needed was a stock control system, not a financial management system — the financial system would report the losses, the stock control system would reveal and reduce them. Sense-check: the financial MIS answers "how much did we lose?" while the client's real question was "where does the money go?" — only inventory tracking answers the second.

The same pattern repeats with a second classic example: the client asks for a faster operating system, but the true bottleneck lives elsewhere entirely.

Worked example — the faster operating system (fixing the symptom): A client complains that computer turnaround is slow and asks for a faster operating system. Work the numbers:

Each transaction currently takes 2.0 seconds; the client runs 5,000 transactions per day → $5000 \times 2.0 = 10, 000$ seconds ≈ 2.8 hours of compute time per day.
A 20% faster operating system would save $0.20 \times 2.0 = 0.4$ s per transaction → $5000 \times 0.4 = 2, 000$ s ≈ 33 minutes saved per day.
But the real cost driver is a badly designed database: queries scan 100,000 records instead of using an index, making the query portion of each transaction 1.2 s. Rebuilding the index cuts that portion to 0.2 s → saving $1.0$ s per transaction → $5000 \times 1.0 = 5, 000$ s ≈ 1.4 hours saved per day.

Final answer: the faster OS saves about 33 minutes per day; fixing the database saves about 1.4 hours per day — the client asked for the wrong product. Sense-check: the symptom (slow turnaround) and the cause (database design) are different things, and the requirements workflow exists to discover the cause.

The professor's warning is blunt: both failures trace back to the same root — inadequate requirements work.

Why requirements work fails (the professor's warning): When requirements are done badly, the client's verdict is: "this may be the specification, but this is not what I really wanted." Two root causes: the client may not truly understand what goes on in her own organization (asking for a faster OS when the database is the bottleneck), or the client may describe the symptoms rather than the problem (a financial system when shrinkage is the real loss). The requirements team must look past what the client says and into how the organization actually operates.

9.8.6 Why Clients Ask for the Wrong Product

The major reason clients frequently ask for the wrong product is that software is complex. It is difficult even for a software professional to visualize a piece of software and its functionality, and the problem is far worse for a client who does not understand software systems. The unified process helps here: UML diagrams can assist the client in gaining the necessary detailed understanding of what needs to be developed.

Intuition + Analogy: Imagine ordering a building over the phone, without blueprints: you could say "something modern, about this big, with lots of light" — and the builder will build what they imagine, not what you imagine. Software is worse, because nothing physical exists to point at. UML diagrams give the client a blueprint: something concrete to look at and correct. Even a software professional struggles to visualize software and its functionality; for a client who does not understand software systems the problem is far worse — which is precisely why UP's graphical models are part of the requirements process.

That completes the requirements workflow: its artifacts belong to the client, in the client's language — and that is exactly where the analysis workflow takes over.

Recap + Bridge: The requirements workflow determines the client's needs — beginning with the application domain, sustained by the business case, bounded by constraints (deadline, reliability, performance, cost), and refined through concept exploration and the bidding process. Done badly, it produces exactly what the client asked for but not what was needed; the deep reason is that software is complex and hard to visualize. The output of this workflow must be comprehensible to the client — which is why UP adds a second, more precise workflow on top of it: the analysis workflow.

Real-world: Requirements elicitation is where whole industries part ways: banks, insurers, and manufacturers each run domain-specific requirements practices, and the "stock control versus financial system" lesson generalizes to every domain — the requirements team must study the organization, not just transcribe requests.

9.9 Analysis Workflow

Hook: The requirements workflow's output must be fully understood by the client — so it is written in the client's language: ordinary English. But ordinary language is ambiguous. How can a document that must be unambiguous be written in a language that is inherently imprecise? UP's answer: use two workflows.

9.9.1 Aim: Detailed, Precise Understanding

The aim of the analysis workflow is to analyze and refine the requirements to achieve the detailed understanding of the requirements essential for developing a software product correctly and maintaining it easily. At first sight, no separate analysis workflow seems needed — an apparently simpler way would be to continue with further iterations of the requirements workflow. The key point is that the output of the requirements workflow must be totally comprehensible by the client: the artifacts of the requirements workflow must be expressed in the language of the client, in natural language such as English.

Why "one more iteration of requirements" is not enough: If the team simply refined the requirements further, the artifacts would remain in the client's natural language — and so would remain imprecise. But the design and implementation workflows need a precise basis: the developers must know exactly what to build. The analysis workflow exists to add that precision: it analyzes and refines the requirements into a form that is unambiguous enough to develop correctly and maintain easily, while the requirements artifacts themselves stay comprehensible to the client.

9.9.2 Natural Language Is Ambiguous

All natural languages are somewhat imprecise and lend themselves to misunderstanding. Consider the sentence: "a part record and a plant record are read from the database if it contains." At first sight this requirement seems perfectly clear — but what does "it" refer to: the part record, the plant record, or the database? Ambiguities of this kind cannot arise if the requirements are expressed in a precise, mathematical notation. However, if a mathematical notation is used for the requirements, the client is unlikely to understand much of them. Miscommunication between client and developers follows, and the software product developed may not be what the client needs.

Worked example — where does "it" point? The full requirement reads: "A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant."

At first sight this looks perfectly clear. Now ask: what is it? Three candidates:

The part record — then the test is "does the part record contain 'AQ'?"
The plant record — then the test is "does the plant record contain 'AQ'?"
The database — then the test is "does the database contain 'AQ'?"

Three readings produce three different programs: reading (1) triggers transport costing for parts whose record contains "AQ"; reading (2) triggers it for parts going to plants whose record contains "AQ"; reading (3) is likely nonsense (a whole database "containing AQ"). Final answer: the word "it" is genuinely ambiguous — natural-language requirements cannot tell the developers which interpretation the client meant, and the wrong pick silently produces the wrong product. Sense-check: a mathematical or diagrammatic statement ("if the part record contains…") has exactly one reading, which is why precision is required for the developers even though the client reads the natural-language version.

The requirements artifacts must stay in natural language, yet the developers need precision — that tension sets up the two-workflow answer.

The precision dilemma: Expressing requirements in a precise, mathematical notation eliminates ambiguity — but then the client is unlikely to understand much of them, and miscommunication returns from the other direction. Both extremes fail: natural language is ambiguous for the developers; mathematics is opaque for the client. The solution is not to choose one language, but to use two workflows, each in its own language.

9.9.3 Two Workflows, Two Languages

The solution is two separate workflows. The requirements workflow is expressed in the language of the client. The analysis workflow is expressed in a more precise language, which ensures that the design and implementation workflows are carried out properly. During analysis, more details are also added — details not relevant to the client's understanding of the target software product but essential for the software professionals who develop it.

Who reads what: The client reads the requirements artifacts (natural language, fully comprehensible). The developers work from the analysis artifacts (precise, technical, carrying details the client never needs — for example, the initial state of a statechart). The analysis workflow is the bridge: it takes the client-comprehensible requirements and produces the developer-precise basis for design and implementation.

9.9.4 Specifications as a Contract

The specifications of a product constitute a contract: the software developers are deemed to have completed the contract when they deliver a product that satisfies the acceptance criteria of the specifications. For this reason, specifications should not include imprecise terms like ample, enough, convenient, or suitable. Such terms might sound exact but are in practice equally imprecise — like optimal or 98% complete. Contract software development can lead to a lawsuit. Even when the client and developers are from the same organization, and there is no chance of the specifications forming a basis for legal action, the specifications should always be written as if they will be used as evidence in court. More importantly, specifications are essential for both testing and maintenance: unless the specifications are precise, there is no way to determine whether they are correct, let alone whether the implementation satisfies them, and it is hard to change the specifications unless some document states exactly what the specifications currently are.

Why "enough" is a lawsuit waiting to happen: Suppose a specification says the system must have "ample storage." The developers deliver 10 GB; the client expected 100 GB. Who is right? Nobody can say — the word is imprecise, so the acceptance criteria are undefined, so the contract is unenforceable. The same applies to optimal or 98% complete: they sound exact and are not. The rule the professor stresses: write every specification as if it will be used as evidence in court, even for an internal project where no lawsuit could ever occur — because the specification is also the basis for testing (is the implementation correct?) and maintenance (what was the product supposed to do?). Without a precise document stating exactly what the specifications currently are, none of that can be done.

9.9.5 UP Replaces the Specification Document

When the unified process is used, there is no specification document in the usual sense of the term. Instead, a set of UML artifacts is shown to the client, and these diagrams with their descriptions can obviate many of the problems of the classical text-written specification document.

Intuition + Analogy: A classical text specification is like a legal contract written in prose — every clause can be read two ways. UP's UML artifacts are like a blueprint plus short annotations: the picture pins down what the words alone cannot. The diagrams with their descriptions eliminate many (though by no means all) of the ambiguity, incompleteness, and contradiction problems of the classical specification document — which is why UP replaces the specification document with UML artifacts shown to the client.

9.9.6 The Three Classic Specification Faults

A classical analysis team can make three kinds of mistakes:

Ambiguity — the specifications are ambiguous, and this ambiguity is intrinsic to natural languages.
Incompleteness — some relevant fact or requirement is omitted. For instance, the specification document may not state what actions are to be taken if the input data contain errors.
Contradictions — two parts of the document say incompatible things. Consider a specification for a product that controls processes: in one place, if the pressure exceeds 35 psi, valve 17 should be shut immediately; in another place, if the pressure exceeds 35 psi, the operator must immediately be alerted, and only if the operator takes no remedial action within 30 seconds should valve 17 be shut.

Software development cannot proceed until such problems in the specification have been corrected. UML diagrams together with descriptions are less likely to contain ambiguity, incompleteness, and contradictions, so using the unified process for requirements reduces these problems.

Worked example — the valve 17 contradiction: A specification for a process-control product says, in section 5:

If the pressure exceeds 35 psi, valve 17 must be shut immediately.

And in section 12:

If the pressure exceeds 35 psi, the operator must immediately be alerted; only if the operator takes no remedial action within 30 seconds should valve 17 be shut.

Under section 5, valve 17 closes the instant pressure passes 35 psi. Under section 12, valve 17 stays open for 30 seconds while the operator decides. The two instructions are incompatible: with pressure at 36 psi, closing the valve now (section 5) and waiting 30 seconds (section 12) are mutually exclusive behaviors. Final answer: this is a classic contradiction — two parts of the document saying incompatible things — and software development cannot proceed until it is corrected. Sense-check: any programmer reading both sections would have to guess which rule the client actually wants, and guessing in a safety-critical system is unacceptable.

These three faults are exactly what the professor expects you to recognize and fix — and they are a favorite exam target.

Exam note: The three classic specification faults — ambiguity, incompleteness, and contradictions — are core examinable material. For each fault, be ready to give its definition, its example (the "it" sentence for ambiguity, missing error-handling rules for incompleteness, the 35 psi valve 17 case for contradictions), and why each blocks development until corrected.

9.9.7 Planning and Estimation

Once the client has approved the specifications, detailed planning and estimation begins. No client authorizes a software project without knowing in advance how long the project will take and how much it will cost, and from the developers' viewpoint these two items are just as important. If the developers underestimate the cost, the client pays the agreed-upon fee, which may be significantly less than the developers' actual cost. Conversely, if the developers overestimate the cost, the client may turn down the project or have the job done by other developers whose estimate is more reasonable. Similar issues apply to duration estimates: underestimating how long the project will take risks late delivery, loss of confidence from the client, and at worst late penalty clauses in the contract, which make the developers suffer financially. Overestimating duration may lead the client to award the job to developers who promise faster delivery.

The two-sided risk of estimates: Both underestimating and overestimating punish the developers. Underestimate cost → the client pays the agreed fee, which may be far below the developers' real cost (the developers lose money). Overestimate cost → the client turns down the project or hires a cheaper competitor. Underestimate duration → late delivery, lost client confidence, and worst of all, penalty clauses in the contract. Overestimate duration → the client hires someone who promises faster delivery. The estimates must be as accurate as possible, because the client authorizes no project without knowing the duration and cost in advance.

Estimating duration and total cost is not enough. Developers need to assign appropriate personnel to the various workflows of the development process. For example, the implementation team cannot start until the relevant artifacts have been approved by the software quality assurance (SQA) group, and the design team is not needed until the analysis team has completed its task. In other words, the developers have to plan ahead.

9.9.8 The Software Project Management Plan

The software project management plan must be drawn up to reflect the separate workflows of the development process and to show which members of the development organization are involved in each task, as well as the deadlines for completing the tasks. The earliest time such a detailed plan can be drawn up is when the requirements specifications have been finalized; before that time the project is too amorphous for complete planning. Some aspects of the project certainly must be planned right from the start, but until the developers know exactly what is to be built, they cannot specify all aspects of the plan for building it. Once the specifications have been approved by the client, preparation of the plan begins. The major components of the plan are the deliverables (what the client is going to get), the milestones (when the client gets them), and the budget (how much it will cost). The plan describes the software process in full detail: the lifecycle models to be used, the organization structure of the development organization, project responsibilities, managerial objectives and priorities, the techniques and CASE tools to be used, and the detailed schedule, budgets, and resource allocation. Underlying the entire plan are the duration and cost estimates and the techniques for producing them, which are studied later in software project planning and estimation. The software project management plan is a major artifact of the analysis workflow.

The three components of the plan: Deliverables — what the client is going to get; milestones — when the client gets them; budget — how much it will cost. Underneath the whole plan sit the duration and cost estimates. The plan cannot be finalized until the specifications are approved: before that, the project is too amorphous for complete planning (some aspects are planned from the start, but not all). Because the plan assigns people to workflows and sets task deadlines, it is the document that makes the workflows executable — and it is a major artifact of the analysis workflow.

Two cautions tie the whole workflow together before we move on.

Pitfalls

Writing specifications in one language for both audiences: the client must read natural language; the developers must work from precision — that is why two workflows exist.
Leaving "enough", "ample", "optimal", or "98% complete" in a specification: they sound exact but are as imprecise as any vague word.
Planning everything before the specifications are approved: until the developers know exactly what is to be built, they cannot specify all aspects of the plan.
Confusing the three faults: ambiguity (a word or phrase with several readings), incompleteness (a fact or rule missing), contradiction (two parts saying incompatible things) — an exam answer must name the right fault for the right example.

With the plan in hand, the analysis artifacts are ready to be transformed into a buildable form.

Recap + Bridge: The analysis workflow refines the requirements into a precise language the developers can build from, while the requirements workflow stays in the client's language; the specifications form a contract (written as if for court), the three classic faults (ambiguity, incompleteness, contradictions) block development until corrected, and once the specifications are approved, detailed planning and estimation produce the software project management plan. The analysis artifacts are now precise enough to design from — which is exactly the design workflow's starting point.

Real-world: Requirement specifications written as "evidence for court" are industry practice — aviation, medical devices, and banking regulators require precisely worded requirements precisely because ambiguity, incompleteness, and contradictions have caused real-world failures.

9.10 Design Workflow

Hook: The analysis artifacts say what the product must do. But "what" cannot be coded — programmers need to know how. The design workflow is the bridge: it refines the analysis artifacts into a form that can be implemented directly.

9.10.1 What Versus How

The specifications of a product spell out what the product is to do; the design workflow shows how the product is to do it. More precisely, the aim of the design workflow is to refine the artifacts of the analysis workflow until the material is in a form that can be implemented by the programmers.

What vs. how, precisely: The specification says the product must "let a customer withdraw cash from an ATM"; the design says exactly how — which class handles the withdrawal request, which object validates the PIN, which routine updates the balance, what parameters each method takes. The same "what" can be satisfied by many different "hows", and choosing a good how is the design workflow's job. Its success criterion is simple: the output must be directly implementable by the programmers.

9.10.2 Modular Decomposition and Interfaces

During the classical design phase in structured systems analysis, the design team determines the internal structure of the product. The designers decompose the product into modules — independent pieces of code with well-defined interfaces to the rest of the product. The interface of each module, meaning the arguments passed to the module and the arguments returned by the module, must be specified in detail.

Worked example — the nuclear reactor water-level module: A module in a reactor monitoring system might measure the water level in the nuclear reactor and cause an alarm to sound if the level is too low. Its interface is fully specified:

Input arguments: one sensor reading — current water level $L$ (in cm).
Behavior: compare $L$ against the safety threshold $L_{min} = 150$ cm; if $L < L_{min}$ , set the alarm.
Output arguments: alarm status $A$ , where $A = 1$ when the level is too low and $A = 0$ otherwise.

With the interface fixed, the rest of the product can be built against it: the control panel module reads $A$ and displays it, without knowing anything about how the level was measured. Final answer: the module is an independent piece of code with a well-defined interface — exactly the kind of unit the design workflow produces. Sense-check: every caller agrees on "level in, alarm out", so a sensor change affects only this module, not the control panel.

The same idea scales up to products where several modules must cooperate — as in this avionics example.

Worked example — the avionics collision-avoidance module: A module in an avionics product might take as input two or more sets of coordinates of an incoming aircraft, compute the aircraft's trajectory, and invoke another module to advise the pilot about possible action to avoid a collision.

Input arguments: two successive coordinate sets of the incoming aircraft, $(x_{1}, y_{1}, z_{1})$ and $(x_{2}, y_{2}, z_{2})$ , at times $t_{1}$ and $t_{2}$ .
Behavior: compute the aircraft's velocity vector $v = (\frac{x _{2} - x _{1}}{t _{2} - t _{1}}, \frac{y _{2} - y _{1}}{t _{2} - t _{1}}, \frac{z _{2} - z _{1}}{t _{2} - t _{1}})$ , project the aircraft's position forward in time, and check it against the pilot's own aircraft trajectory.
Output arguments: an advisory message to the pilot (e.g., "climb 500 feet") passed to a separate display module.

Final answer: two modules with well-defined interfaces — trajectory computation produces advice, the advisory module renders it. Sense-check: the design team can develop each module independently and integrate them later because every argument of every interface is specified in detail.

Both examples share the same lesson: interfaces are the contract between modules.

9.10.3 Architectural and Detailed Design

Once the team has completed the decomposition into modules — that is, the architectural design — detailed design is performed for each module: the algorithms are selected and the data structures are chosen. In the object-oriented paradigm, classes are selected during the analysis workflow and designed during the design workflow, so object-oriented design is performed as part of the design workflow.

Two levels of design: Architectural design is the whole-product decomposition into modules — the shape of the product, showing the components and how they fit together. Detailed design works inside each module: selecting the algorithms and choosing the data structures. In the object-oriented paradigm, this maps cleanly onto the workflows: classes are selected during the analysis workflow (they appear in the analysis models) and designed during the design workflow (their methods, attributes, and inter-class relationships are fully worked out) — so object-oriented design happens as part of the design workflow.

9.10.4 Records of Design Decisions

The design team must keep a record of the design decisions that are made. During design, the team can reach a dead end and must backtrack and redesign certain pieces; a written record of why specific decisions were made assists the team when this occurs and helps it get back on track.

Why the record matters (the professor's warning): Design is a journey with dead ends. The team tries a design, discovers it does not work, backtracks, and redesigns. Without a written record of why specific decisions were made, the team cannot tell whether a rejected idea was rejected for a reason that still holds — so it may repeat the same dead end, or worse, refuse to revisit a decision whose justification has expired. The record makes backtracking cheap and safe. It matters even more later: if the product is ever redesigned as a whole, the redesign team's task is considerably easier when they are given the reasons behind the original design.

9.10.5 Open-Ended Design and the Compromise

The design product should be open-ended, meaning future enhancements and post-delivery maintenance can be done by adding new classes or replacing existing classes without affecting the design as a whole. In practice this is an ideal design goal that is difficult to achieve. Deadline constraints in the real world are such that designers struggle to complete a design that satisfies the original specifications within the deadline, without worrying about later future enhancements. If future enhancements are included in the specifications, then they must be allowed for in the design — but this situation is extremely rare. In general, the specifications and so the design deal only with present requirements, and while the product is still being designed there is no way to determine all possible future enhancements. A design that has to take all future possibilities into account will at best be unwieldy, and at worst so complicated that implementation will be impossible. Designers have to compromise: put together a design that can be extended in as many reasonable ways as possible without the need for total redesign. Still, for a product that undergoes major enhancement, a time comes when the design simply cannot handle further changes. When that stage is reached, the product must be redesigned as a whole, and the task of the redesign team can be considerably easier if the team is provided with the record of the reasons for the original design decisions.

Assumption & Scope — when open-ended design applies and when it breaks: Open-ended design assumes the product will change, so new classes can be added or existing ones replaced without affecting the design as a whole. The assumption fails in two situations. First, deadlines: under real-world deadline pressure, designers struggle to satisfy the original specifications on time, let alone accommodate unknown futures — enhancements are included in the design only when the specifications themselves include them, which is extremely rare. Second, scale of change: a design that tries to take all future possibilities into account becomes unwieldy at best and unimplementable at worst. The compromise is a design extendable in as many reasonable ways as possible without total redesign — but even that fails eventually, and the product must then be redesigned as a whole.

The same compromise has a set of recurring traps worth naming.

Pitfalls

Treating open-ended design as an absolute rule: it is an ideal, compromised by deadlines and by the impossibility of knowing future requirements.
Over-engineering for every imaginable future: a design that allows for everything is at best unwieldy and at worst impossible to implement — the goal is reasonable extensibility, not universal flexibility.
Designing without recording decisions: without the record, backtracking after a dead end is blind, and a later full redesign loses the reasons behind the original design.
Thinking the specification includes future enhancements: in general the specifications — and so the design — deal only with present requirements.

Recap + Bridge: The design workflow refines the analysis artifacts into a buildable form: what becomes how, the product is decomposed into modules with fully specified interfaces, architectural design gives way to detailed design (algorithms and data structures), decisions are recorded for backtracking, and open-endedness is pursued as a compromise, not an absolute. With the design complete, the programmers can finally build the product — the implementation workflow.

Real-world: Modular decomposition with well-defined interfaces is the backbone of every safety-critical industry — from reactor monitoring and avionics collision avoidance to medical devices — because modules can be verified, tested, and replaced independently without disturbing the rest of the product.

9.11 Implementation Workflow

Hook: The design is finished — now dozens of programmers start writing code, each working on their own piece. How can the team know, while coding, that the design they are implementing is actually correct? The uncomfortable answer: they cannot — and the discovery comes later, at integration.

9.11.1 Aim and Partitioning

The aim of the implementation workflow is to implement the target software product in the chosen implementation language. A small software product is sometimes implemented by the designer. In contrast, a large product is partitioned into smaller subsystems or modules, which are then implemented in parallel by multiple coding teams. The subsystems in turn consist of components, or code artifacts, implemented by an individual programmer.

The partitioning chain: A large product is not coded as one file. It is partitioned into subsystems, each implemented in parallel by a coding team; each subsystem consists of components (code artifacts), each implemented by one individual programmer. The chain matters for two reasons: parallelism (teams can code at the same time, so the calendar time shrinks) and scale (no single programmer holds the whole product in mind — remember the seven-chunk limit from 9.3). The price is that nobody sees the whole picture — which is exactly what 9.11.3 warns about.

9.11.2 The Programmer's Documentation

The documentation given to a programmer is the relevant design artifact. In the classical paradigm, the programmer is given the detailed design of the module to be implemented, which usually provides enough information to implement the code without too much difficulty. Any problems can quickly be cleared up by consulting the responsible designer.

What the programmer works from: The programmer does not receive the whole specification or the whole architecture — only the relevant design artifact, typically the detailed design of the module to be implemented. That artifact usually provides enough information to implement the code without too much difficulty; when a problem arises, the programmer clears it up by consulting the responsible designer. This works well for within-module questions — the difficulty starts when the question is about how the module fits the design as a whole.

9.11.3 Integration Reveals Design Flaws

There is no way for the individual programmer to know whether the architectural design is correct. Only when the integration of the individual code artifacts begins do the shortcomings of the design as a whole come to light. The correctness of the design, as well as of the other artifacts, is checked as part of the test workflow.

The professor's warning — who gets blamed when integration fails: Suppose several code artifacts have been integrated and appear to work. A programmer has correctly implemented artifact a45, but when a45 is integrated with the existing artifacts, the product fails. The cause of the failure lies not in a45 itself but in the way a45 interacts with the rest of the product — as specified in the architectural design. Yet in practice the programmer who just coded a45 tends to be blamed, even though the programmer simply followed the designer's instructions and implemented the artifact exactly as described. Programmers are rarely shown the big picture, let alone asked to comment on it. The lesson: an individual programmer cannot judge the architectural design — its correctness is only revealed by integration, and it is checked as part of the test workflow, not during implementation.

This division of responsibility breeds a set of recurring traps.

Pitfalls

Expecting the individual programmer to spot architectural faults: no programmer can judge the design as a whole from one artifact — integration is where such faults come to light.
Blaming the programmer when an integrated product fails: the failure may be caused by the interaction specified in the architectural design, not by the artifact itself.
Implementing from memory instead of from the design artifact: the design artifact is the programmer's documentation; deviating from it silently invalidates the interface contract that the rest of the teams rely on.
Believing that code correctness equals product correctness: an individual artifact can be perfectly correct while the integrated product fails — correctness of the design as a whole is established in the test workflow.

Recap + Bridge: The implementation workflow implements the product in the chosen language: large products are partitioned into subsystems (implemented in parallel by coding teams) and components (implemented by individual programmers); programmers work from the relevant design artifact; and the correctness of the design as a whole is unknowable until integration begins — which is where the test workflow, running in parallel from the very start, takes over.

Real-world: The partitioning chain is standard industry structure: product teams, feature teams, and individual engineers mirror UP's subsystems, components, and code artifacts — and continuous integration exists precisely because integration is where design-level faults are discovered.

9.12 Test Workflow

Hook: Everyone thinks of testing as "what happens at the end, before delivery." In the unified process, testing starts on day one and runs in parallel with every other workflow — because by the time a product is finished, it is far too late to find out whether the design and the requirements were right.

9.12.1 Testing Runs in Parallel, From the Start

In the unified process, testing is carried out in parallel with the other workflows, starting from the beginning. There are two major aspects to testing. Every developer and maintainer is personally responsible for ensuring that his or her work is correct, so a software professional has to test and retest each artifact he develops or maintains. Once the software is developed and tested, it is handed over to the software quality assurance (SQA) group for independent testing. The nature of the test workflow changes depending on the artifacts being tested.

Two layers of testing: First, self-testing: every developer and maintainer is personally responsible for the correctness of his or her own work — each artifact is tested and retested by the person who produced it. Second, independent testing: once the software professional is convinced an artifact is correct, it is handed to the software quality assurance (SQA) group for methodical, independent testing. The two layers are complementary: self-testing catches the obvious faults cheaply; independent testing catches the faults the author cannot see in their own work.

9.12.2 Traceability

An important feature applicable to all artifacts during development is traceability, which is necessary for successful testing. For the requirements artifacts to be testable over the life cycle of the software product, one property they must have is traceability: it must be possible to trace every item in an analysis artifact back to a requirements artifact, and similarly for the design artifacts and the implementation artifacts. If the requirements artifacts are presented methodically — properly numbered, cross-referenced, and indexed — the developers can trace the subsequent artifacts and ensure that these reflect the client's requirements, and when the requirements team's work is later checked by the independent SQA group, traceability simplifies their job as well.

Traceability, precisely: Traceability means every item in every artifact can be traced back to the requirement it serves: every item in an analysis artifact back to a requirements artifact, every part of the design back to an analysis artifact, and every part of the implementation back to a design artifact. If the requirements are presented methodically — properly numbered, cross-referenced, and indexed — developers can walk the chain in either direction: forward, to check that every requirement is reflected somewhere in the product; backward, to check that every piece of the product exists to satisfy some requirement. When the SQA group later checks the requirements team's work, traceability simplifies their job as well.

9.12.3 Testing the Requirements and Analysis Artifacts

A major source of faults in delivered software is faults in the specifications that are not detected until the software has been installed on the client's computer. Both the analysis team and the SQA group must check the analysis artifacts in detail. They must ensure that the specifications are feasible — that a specific hardware component is fast enough, or that the client's current online storage capacity is adequate to handle the new product. An excellent way of checking the analysis artifacts is a review, using the reviews and inspections we have seen. They must also check the software project management plan meticulously, paying particular attention to the plan's duration and cost estimates. One way to do this is for management to get two or more independent estimates of duration and cost when detailed planning starts, and then reconcile any significant differences. With regard to the software project management planning document, an excellent way to check it is a review similar to the review of the analysis artifacts. If the duration and cost estimates are satisfactory, the client will give permission for the project to proceed.

What gets tested before any code exists: Specification faults found after installation are among the most expensive faults there are — so the analysis artifacts are checked before design even starts. Two checks matter: feasibility (is a specific hardware component fast enough? is the client's current online storage capacity adequate for the new product?) and review — the analysis artifacts and the software project management plan are reviewed, with particular attention to duration and cost estimates. A powerful check on the estimates: get two or more independent estimates when detailed planning starts, and reconcile any significant differences. Only when the estimates are satisfactory does the client give permission for the project to proceed.

9.12.4 Testing the Design Artifacts

For the design artifacts, the critical aspect of testability is again traceability: every part of the design can be linked to an analysis artifact. A suitably cross-referenced design document gives the developers and the SQA group a powerful tool for checking whether the design agrees with the specifications and whether every part of the specifications is reflected in some part of the design. Design reviews are similar to the reviews the specifications undergo; however, in view of the technical nature of most designs, the client is usually not present. Members of the design team and SQA can go through the design as a whole as well as each separate design artifact, ensuring that the design is correct. The types of faults to look for include logic faults, interface faults, exception handling, non-conformal specifications, and so on. The review team should also always be aware of the possibility that some analysis faults were not detected during the analysis workflow, so those need careful review using the review process.

Design review fault list: Design reviews check the design as a whole and each separate design artifact for: logic faults, interface faults, exception handling (processing of error conditions), non-conformance to the specifications — and, because faults can slip through earlier stages, the review team must also watch for analysis faults that were not detected in the analysis workflow. Unlike specification reviews, the client is usually not present — the design is technical material, and the review is a matter for the design team and the SQA group.

9.12.5 The Four Test Levels

Implementation artifacts — the coding — are tested at various levels: unit testing, integration testing, system testing, and acceptance testing. Each component should be tested by the programmer while it is being implemented and after it has been implemented, by running it against test cases; the quality assurance group then tests the component methodically. A variety of techniques can be used for designing test cases for unit testing and module testing. In addition to execution-based testing, a code review can be a powerful technique for detecting programming faults: a team of programmers and reviewers goes through the code, keeps a detailed record of the review meetings, and takes corresponding follow-up actions.

The four test levels: the coding is tested at four successive levels, starting from the smallest piece of code and rising to the delivered product, each with its own question to answer (a summary table closes this section).

Each component is tested by the programmer while it is being implemented and after implementation (running it against test cases); the quality assurance group then tests the component methodically. Beyond execution-based testing, a code review — a team of programmers and reviewers going through the code, keeping a detailed record, and taking follow-up actions — is a powerful technique for detecting programming faults.

9.12.6 Integration Testing and Interfaces

Once a unit or component has been implemented, it can be combined with other components so that the independent testing group can determine whether the partial product or the whole product functions correctly. The way in which the components are integrated can have a critical influence on the quality of the resulting product. If the product is integrated bottom-up, a major design fault, if present, will show up very late, necessitating expensive redesign and implementation. Conversely, if the components are integrated top-down, the lower-level components usually do not receive as thorough testing as they would with bottom-up integration. These and other problems are the reason why coding and integration must be performed in parallel. Integration testing checks that the components combine correctly to achieve a product that satisfies its specification. During integration testing, particular care must be taken in testing the component interfaces: the number, order, and types of formal arguments must match the number, order, and types of actual arguments between components. Strong type checking is best performed by the compiler and linker, but many languages are not strongly typed; when such a language is used, the testing group must test the interfaces.

Worked example — bottom-up versus top-down integration: Consider a five-module product shaped like a tree: M1 (the top module) calls M2 and M3; M2 calls M4; M3 calls M5. Say each module takes two weeks to code and unit test, and M1's interface to M2 contains a design fault — M1 passes distance in kilometers while M2 returns altitude in feet.

Bottom-up integration: the team integrates M4+M2, then M5+M3, then M1 on top. The fault lives at the last interface to be exercised — M1's call to M2 — so it is discovered at the very end, around week 8. Fixing it means redesigning M1's interface, changing M2's behavior, and re-running every test from week 1: roughly 4–6 weeks of expensive rework, discovered last.

Top-down integration: the team integrates M1 first with stubs standing in for M2 and M3. The faulty M1↔M2 interface is exercised in week 2–3, when the fix is cheap — the design fault surfaces almost immediately. But the lower-level modules M4 and M5 now live under stubs and drivers: the exercises they get are less thorough than they would receive in bottom-up integration, so their own edge cases (error handling, boundary conditions) tend to escape testing until later.

Final answer: bottom-up finds a major design fault very late (expensive redesign); top-down under-tests the lower-level components. The design fault itself will be found in both orders — the difference is when and how much it costs. Sense-check: because each strategy has a blind spot, coding and integration must be performed in parallel, so the design is continuously exercised as it is built.

Whatever the integration order, the interfaces themselves demand discipline.

Interface discipline: During integration testing, particular care goes into the component interfaces: the number, order, and types of formal arguments must match the number, order, and types of actual arguments between components. Strong type checking is best performed by the compiler and linker — but many languages are not strongly typed, and when such a language is used, the testing group itself must check the interfaces. A mismatched interface compiles, runs, and corrupts data silently — it will not announce itself.

9.12.7 System Testing

When the integration testing is completed, the SQA group performs system testing: the functionality of the product as a whole is tested against the specifications. In particular, the constraints listed in the specification must be tested — a typical example is whether the response time requirements have been met. Because the main aim of product testing is to determine whether the specifications have been correctly implemented, many of the test cases can be drawn up as soon as the specifications are complete. Not only must the correctness of the product be tested, but also its robustness: intentionally erroneous input data are submitted to determine whether the product will crash or whether its error handling capabilities are adequate for dealing with bad data. If the product is to be run together with the client's currently installed software, tests must also be performed to check that the new product will have no adverse effect on the existing client computer system operations. Finally, you must check whether the source code and all types of documentation are complete and internally consistent. On the basis of system testing, the development organization decides whether the product is ready to be released to the client for acceptance testing.

What system testing checks: The functionality of the product as a whole against the specifications — including the constraints (e.g., has the response time requirement been met?). Because the aim is "does the implementation satisfy the specifications?", many test cases can be drawn up as soon as the specifications are complete. Beyond correctness, system testing checks robustness: intentionally erroneous input data are submitted to see whether the product crashes or handles bad data adequately. If the product will run alongside the client's installed software, tests check for adverse effects on existing operations. Finally, the source code and all documentation are checked for completeness and internal consistency. Only on the basis of system testing does the development organization decide whether the product is ready for acceptance testing.

9.12.8 Acceptance Testing

The final step in implementing and testing the implementation artifacts is acceptance testing. The software is delivered to the client, who tests it on actual hardware using actual data, as opposed to test data. No matter how methodical the development team or the SQA group might be, there is a significant difference, by their very nature, between the test cases and the actual data. A software product cannot be considered to satisfy the specifications until the product has passed the acceptance test.

Why acceptance testing is non-negotiable: Test cases are, by their very nature, artificial — the team invents them from the specifications. Actual data are real: real volumes, real distributions, real mistakes, real combinations nobody predicted. No matter how methodical the development team and the SQA group are, the gap between test cases and actual data cannot be closed by diligence. That is why a product cannot be considered to satisfy the specifications until it has passed the acceptance test on the client's actual hardware with actual data.

9.12.9 Alpha and Beta Releases

In the case of commercially available products, as soon as product testing is complete, versions of the complete product are given to selected possible future clients. The first such version is named the alpha release, and the following release is called the beta release; in general, the beta release is intended to be close to the final version. Alpha and beta releases are generally applied to all types of software, not just commercially available off-the-shelf components. Faults in a product can sometimes result in poor sales and huge losses for the development company, so if many faults are discovered as early as possible — especially during alpha and beta testing — the company may be able to correct the bugs and release the product. Companies that take the role of beta testing get a head start in using the new product, which can give them an advantage over their competitors. One caution: problems can occur when client organizations use alpha testing in place of product testing by the SQA group. Although alpha testing brings to light a large variety of faults, there is no substitute for the methodical testing of the software quality assurance group.

Alpha and beta, precisely: Once product testing is complete, versions of the complete product are given to selected possible future clients for testing on site. The first such version is the alpha release; the corrected alpha release is the beta release, intended to be close to the final version. The exchange: the vendor discovers faults early (faults found during alpha and beta testing can be corrected before general release, avoiding poor sales and huge losses), and the testing companies get a head start in using the new product — an advantage over competitors.

One caution closes the section — a warning the professor repeated for a reason.

The alpha-testing trap (the professor's caution): Some client organizations use alpha testing in place of the SQA group's product testing. Alpha testing at many sites brings a large variety of faults to light — but there is no substitute for the methodical testing the SQA group provides. Alpha releases are fault laden by design; relying on them as the main test program shifts the risk onto the client's own operations.

For reference, the four test levels at a glance:

Level	What is tested	Who does it	Question it answers
Unit testing	A single component	Programmer first (desk checking + test cases), then the SQA group methodically	Does this component work in isolation?
Integration testing	Combinations of components	SQA group	Do the components work together?
System testing	The product as a whole	SQA group	Does the product meet the specifications?
Acceptance testing	The delivered product	The client, on actual hardware with actual data	Will the client accept the product?

With that table in view, the two examinable themes of this section follow.

Exam note: Two themes from this section are core examinable material. First, traceability: every item in an analysis artifact must be traceable back to a requirements artifact, and similarly for design and implementation artifacts — it is what makes testing possible across the life cycle. Second, the four test levels: unit testing, integration testing, system testing, and acceptance testing — be ready to state what each level tests, who performs it, and the special risks of the integration order (bottom-up finds design faults late; top-down under-tests lower-level components).

With all four levels understood, the test workflow's place in the life cycle is clear.

Recap + Bridge: Testing runs in parallel from the start in two layers (self-testing, then independent SQA testing); traceability links every artifact back to the requirements; analysis, design, and implementation artifacts are each checked in turn; implementation is tested at four levels (unit, integration, system, acceptance); and alpha and beta releases put the tested product into real hands before final delivery. After acceptance, the product enters the longest phase of its life: post-delivery maintenance.

Real-world: The four test levels are standard industry vocabulary, and alpha/beta programs are everyday practice in commercial software — from operating systems to mobile apps — where the same trade-off of early fault discovery versus methodical internal testing plays out.

9.13 Post-Delivery Maintenance

Hook: After delivery, the product lives for years — and the money spent on that life dwarfs everything spent building it. If maintenance is the most expensive part of software, why do teams keep treating it as an afterthought?

9.13.1 Maintenance Is Planned, Not an Afterthought

Post-delivery maintenance is not an activity that is grudgingly carried out after the product has been delivered and installed on the client's computer. On the contrary, it is an integral part of the software process that must be planned for from the beginning. The design, as far as possible, should take future enhancements into account, and coding must be performed with future maintenance kept in mind. More money is spent on post-delivery maintenance than on all other software activities combined, so it is a vital aspect of software production. Post-delivery maintenance must never be treated as an afterthought; instead, the entire software development effort must be carried out in such a way as to minimize the impact of the inevitable future post-delivery maintenance.

Why maintenance is the biggest cost: More money is spent on post-delivery maintenance than on all other software activities combined — the professor's single most important figure of this section. A typical software product lives 10, 15, or even 20 years after delivery, being continually enhanced to meet changing needs, while residual faults keep appearing even after years of successful maintenance; hardware migration every 3 to 5 years also counts as maintenance. Because the cost is so large, the whole development effort must be shaped to minimize future maintenance: the design takes future enhancements into account as far as possible, and coding is performed with future maintenance kept in mind. Maintenance is an integral part of the software process — planned from the beginning, never an afterthought.

9.13.2 The Documentation Problem

A common problem with post-delivery maintenance is the documentation, or rather the lack of it. In the course of developing software against a tight timeline, the original analysis and design artifacts are frequently not updated and are almost useless to the maintenance team. Other documentation, such as the database manual or the operating manual, may never be written because management decided that delivering the product to the client on time was more important than developing the documentation in parallel with the software. In many instances the source code is the only documentation available. The high rate of staff turnover in the software industry exacerbates the maintenance situation, in that none of the original developers may be working for the organization at the time when maintenance is performed. For all these reasons, post-delivery maintenance frequently is the most challenging aspect of software production.

Why maintenance teams work blind (the professor's warning): Three forces combine. First, under a tight timeline, the original analysis and design artifacts are frequently not updated — so by delivery they are stale and almost useless to the maintenance team. Second, other documentation (the database manual, the operating manual) may never be written at all, because management decided on-time delivery outranked documentation. In many instances the source code is the only documentation available. Third, staff turnover in the software industry is high — none of the original developers may still be with the organization when maintenance is performed, so nobody can explain the decisions behind the code. The result: maintenance is frequently the most challenging aspect of software production.

9.13.3 Testing Changes: Regression Testing

There are two aspects to testing changes made to a product during post-delivery maintenance: first, checking that the required changes have been implemented correctly, and second, checking that in the course of making the changes no other inadvertent changes were made. Once a programmer has determined that the desired changes have been implemented, the product must be tested against the previous test cases to make certain that the functionality of the rest of the product has not been compromised. This procedure is called regression testing. To assist in regression testing, it is necessary that all previous test cases be retained, together with the results of running those test cases.

Regression testing, precisely: A change to a product can break something that used to work — a regression fault: a change in one component induces a fault in an apparently unrelated part. Regression testing is the safety net: once the programmer has determined that the desired change has been implemented correctly, the product is tested against the previous test cases to make certain that the functionality of the rest of the product has not been compromised. Two aspects, always: (1) the required changes were implemented correctly; (2) no other inadvertent changes were made. Regression testing only works if all previous test cases are retained, together with the results of running them — which is why those artifacts are a form of documentation, kept for the whole life of the product.

9.13.4 Change Records

A major aspect of post-delivery maintenance is the record of all changes made, together with the reason for each change. When software is changed, it has to be regression tested, so regression test cases are a form of documentation.

The change record as documentation: Every change is recorded together with the reason for the change — not just what changed, but why. And because every change triggers regression testing, the regression test cases become documentation in their own right: they are the retained evidence of what the product is supposed to do. The change record and the regression suite together give the maintenance team exactly what the missing manuals cannot: a precise, current statement of the product's behavior and its history.

Against that background, the recurring traps of this workflow come into focus.

Pitfalls

Treating maintenance as an afterthought: it costs more than all other software activities combined, so it must be planned from the beginning.
Discarding old test cases after a change: regression testing requires all previous test cases and their results to be retained.
Trusting un-updated artifacts: analysis and design artifacts not updated during development are almost useless to the maintenance team.
Skipping the "no inadvertent changes" check: verifying only that the desired change works leaves regressions undiscovered.

Exam note: Three points from this section are core examinable material: (1) post-delivery maintenance must be planned from the beginning — more money is spent on it than on all other software activities combined; (2) regression testing — testing the changed product against the previous test cases to make sure no other functionality was compromised, requiring all previous test cases and their results to be retained; (3) when maintenance is no longer cost effective, retirement replaces it — the topic of the next and final section.

With those three points fixed in mind, the section's lesson is complete.

Recap + Bridge: Post-delivery maintenance is an integral, planned part of the software process and the biggest cost in it; documentation gaps and staff turnover make it the most challenging phase; regression testing (re-running the previous test cases) protects the product from inadvertent damage, and change records with their reasons are central documentation. Eventually, even maintenance stops being cost effective — and the product reaches retirement.

Real-world: Regression testing is universal industrial practice — continuous integration pipelines in every major software company re-run the full test suite on every change, which is exactly the professor's "test against previous test cases" rule automated at scale.

9.14 Retirement

Hook: Every software product eventually stops being worth the money spent on it. But "the product was replaced" and "the product was retired" are not the same thing — and the difference is surprising.

9.14.1 When Maintenance Is No Longer Cost Effective

The final stage in the software life cycle is retirement. After many years of service, a stage is reached when further post-delivery maintenance is no longer cost effective. Sometimes the proposed changes are so drastic that the design as a whole would have to be changed, and in some cases it is less expensive to redesign and recode than to maintain the entire product. Sometimes so many changes have been made since the original design and development that many interdependencies have been built into the product, and even a small change to one minor component can have a drastic effect on the functionality of the product as a whole. The documentation may not have been adequately maintained, or not written at all, thereby increasing the risk of a regression fault to the extent that it would be safer to develop from scratch, recode, and maintain. And if the hardware and operating system on which the product runs are to be replaced, it may be more economical to re-implement from scratch than to modify the old system, because the new version should be compatible with the new hardware.

The four situations that end maintenance:

Drastic proposed changes — the changes are so large that the design as a whole would have to be changed; it becomes less expensive to redesign and recode than to maintain.
Accumulated interdependencies — so many changes have been made since the original design that dependencies have built up; even a small change to one minor component can drastically affect the whole product.
Missing or stale documentation — with the documentation unmaintained or unwritten, the risk of a regression fault becomes so high that developing from scratch is safer than maintaining.
New hardware and operating system — replacing the platform may make re-implementation from scratch more economical than modifying the old system, since the new version should be compatible with the new hardware.

9.14.2 Replacement Versus True Retirement

In each of these instances, the current version is replaced with a new version, and the software process continues. True retirement, on the other hand, is a rare event: it happens when the product has outgrown its usefulness, the client organization no longer requests the functionality provided by the product, and the product is finally removed from the system.

Replacement is not retirement: In all four situations above, the product is replaced — a new version is built and the process continues. That is the normal end of a product's active life. True retirement is rare: the product has outgrown its usefulness, the client organization no longer requests its functionality, and the product is finally removed from the system. If the same functionality is still needed but the old product cannot be maintained, the correct word is replacement, not retirement.

That distinction carries two more traps worth naming.

Pitfalls

Calling every product shutdown "retirement": replacement (new version, process continues) is the common case; true retirement (product outgrew its usefulness, functionality no longer requested, product removed from the system) is rare.
Assuming old software is retired because it is old: products 10–20 years old are routinely maintained, not retired — age alone does not trigger retirement, cost effectiveness does.
Forgetting the four replacement triggers: drastic changes, accumulated interdependencies, missing documentation (regression risk), and platform replacement.

Recap + Bridge: Retirement is the final stage of the life cycle: when maintenance is no longer cost effective — due to drastic changes, accumulated interdependencies, missing documentation, or a new platform — the version is replaced and the process continues; true retirement, where the product's functionality is no longer requested and the product is removed, is rare. With that, the full unified process arc is complete: workflows, phases, iteration, episodes, maintenance, and retirement.

Real-world: The retirement decision is an everyday business reality: enterprises sunset legacy systems when modernization or reimplementation beats maintenance — while genuinely retired products (functionality no longer needed by anyone) are the exception.

Exam Guidance Summary

No exam-specific instructions — no mark distributions, question patterns, or study advice — were given in this class. The following points are the core knowledge of the session and the ones to be able to explain:

The two-dimensional view of the unified process: five technical workflows (requirements, analysis, design, implementation, testing) running inside four business phases (inception, elaboration, construction, transition), and what each phase emphasizes.
The difference between iteration and incrementation, and how episodes combine development and maintenance, including the contrast between corrective maintenance and perfective maintenance.
Why the requirements workflow speaks the client's language while the analysis workflow uses a precise language, and why the three specification faults — ambiguity, incompleteness, and contradictions — block development until corrected.
Traceability across all artifacts, and the four testing levels: unit testing, integration testing, system testing, and acceptance testing, plus the roles of alpha and beta releases.
Why post-delivery maintenance is planned from the beginning, what regression testing is, and when retirement replaces maintenance.

How to revise this lecture: Build one mental diagram — the two-dimensional UP model — and attach everything to it. Place each workflow (requirements, analysis, design, implementation, testing) and each phase (inception, elaboration, construction, transition) on the model; then attach the story of each workflow (the wrong-product examples for requirements, the "it" and valve-17 cases for analysis, the module examples for design, the integration-order trade-off and the four test levels for testing). Finally, attach the life-cycle story after delivery: corrective vs. perfective maintenance, regression testing, and the difference between replacement and true retirement. If you can redraw that model from memory and narrate each attachment, you have covered the examinable core of the session.

Key Industry Applications

Real-world: The unified process applies across very different domains — insurance, aerospace, manufacturing, banking, automobile, and nuclear power — which is exactly why no fixed step-by-step process can fit every project.
Real-world: A commercially available off-the-shelf (COTS) package is developed with a fast time-to-market method, whereas a bank's high-security electronic funds transfer network needs a different methodology.
Real-world: Mission-critical software is common in almost every application domain; the client's core activities depend on it, so late delivery can be detrimental to the client organization.
Real-world: The bidding procedure, the business case, and the software project management plan (deliverables, milestones, budget) are how client organizations and vendors actually negotiate a project.
Real-world: Specification reviews, independent SQA testing, and alpha and beta releases are standard industry practice; beta testers gain a head start over their competitors.
Real-world: The nuclear reactor water-level alarm module and the avionics collision-avoidance module illustrate modular design in safety-critical systems.
Real-world: Regression testing carried out in continuous integration pipelines, and the retirement-versus-replacement decision for legacy systems, show that the life cycle of this lecture is not a classroom ideal — it is how real software organizations operate every day.

SE Lecture 9 notes · Unified Software Development Process

Software Engineering· postgraduate· 2026-08-16

Sections Breakdown

1The Unified Process at a Glance

Why no single process model fits every project, the four universal activities of software development, and the two-dimensional view of UP: five technical workflows inside four business phases.

2How the Unified Process Came to Be

How the Booch method, Jacobson's Objectory, and Rumbaugh's OMT were unified into the Rational Unified Process — later renamed the unified process — together with UML, the standard modeling language.

3UML and the Object-Oriented Paradigm

A model is a set of UML diagrams; the object-oriented paradigm is iterative and incremental by nature, and even the most experienced professionals iterate because of Miller's Law.

4Workflows Within Increments: The Effort Picture

The effort curves: all five workflows run through every increment with different peak periods, and effort splits roughly one-fifth to requirements and analysis, one-fifth to design, and three-fifths to implementation.

5The Four Phases of the Unified Process

Inception, elaboration, construction, and transition — the four business phases of UP, each answering a business question and each containing all five workflows in different proportions.

6Iteration Within Phases

Iterations inside phases (B.1, B.2, B.3): each iteration is a complete mini-pass through all five workflows, and the team moves to the next phase only when the work products are satisfactory.

7Episodes: Versions, Maintenance, and Mini-Projects

The episode picture: solid arrows for development and dotted arrows for maintenance, corrective versus perfective maintenance, each iteration as a mini-waterfall, and baselines as snapshots after every episode.

8Requirements Workflow

Determining the client's needs: the application domain, the business case, constraints, concept exploration and the bidding process — and why clients end up asking for the wrong product.

9Analysis Workflow

The analysis workflow refines the requirements into a precise language for the developers; specifications as a contract, the three classic faults (ambiguity, incompleteness, contradictions), and planning and estimation.

10Design Workflow

What becomes how: modular decomposition with well-defined interfaces, architectural and detailed design, records of design decisions, and open-ended design as a compromise, not an absolute.

11Implementation Workflow

Implementing the product in the chosen language: partitioning into subsystems and components, the programmer's documentation, and why integration reveals design flaws.

12Test Workflow

Testing runs in parallel from the start; traceability across artifacts; the four test levels — unit, integration, system, and acceptance — and the roles of alpha and beta releases.

13Post-Delivery Maintenance

Maintenance is planned from the beginning and costs more than all other software activities combined; the documentation problem, regression testing, and change records.

14Retirement

When maintenance is no longer cost effective: the four replacement triggers, and the difference between replacement and true retirement.

15Exam Guidance Summary

The examinable core of the lecture: the two-dimensional UP model, iteration versus incrementation and episodes, the two-language requirements/analysis split, traceability, and the four test levels.

16Key Industry Applications

How the unified process and its workflows apply in insurance, aerospace, manufacturing, banking, and safety-critical systems.

Postgraduate students in Software Engineering

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

The Unified Process at a Glance

Must-know: UP is a two-dimensional model: five technical workflows (requirements, analysis, design, implementation, testing) run inside four business phases (inception, elaboration, construction, transition); every UP step belongs to one workflow and one phase. UP is a methodology - an adaptable approach, not a fixed recipe.

⚠️ Top pitfall: Treating UP as a fixed step-by-step recipe, or confusing the four core activities (specification, development, validation, evolution) with the five workflows.

Self-check: Why can there be no single universal software process model? Because application domains, products (COTS vs high-security networks), and the skills of professionals vary too widely.

Connects to: How the Unified Process Came to Be, Workflows Within Increments: The Effort Picture, The Four Phases of the Unified Process

How the Unified Process Came to Be

Must-know: UP came from unifying three methods: the Booch method, Jacobson's Objectory, and Rumbaugh's OMT (the 'Three Amigos': Booch, Jacobson, Rumbaugh). It was first called the Rational Unified Process, renamed the unified software development process after IBM's acquisition, and is now just the unified process; UML is its modeling language.

⚠️ Top pitfall: Thinking RUP, USDP, and UP are different methodologies - they are the same method at different points in its naming history.

Self-check: Why was the preliminary merged work renamed 'Unified Modeling Language' instead of 'Unified Methodology'? Because critics showed it was a notation for representing software, not a full methodology.

Connects to: The Unified Process at a Glance, UML and the Object-Oriented Paradigm

UML and the Object-Oriented Paradigm

Must-know: A model is a set of UML diagrams representing aspects of the software product. The object-oriented paradigm is iterative and incremental: iteration revises successive versions of an artifact, incrementation builds it piece by piece. Even experts iterate because of Miller's Law (about seven chunks of information at once).

⚠️ Top pitfall: Confusing the workflow (the repeated steps) with the model (the resulting diagrams), or treating iteration as aimless rework rather than a structured refinement toward an accurate model.

Self-check: Why do even the most experienced software professionals iterate and re-iterate their UML diagrams? Because it is difficult to consider too many aspects of the product at once (Miller's Law), so levels of abstraction and repeated revision are necessary.

Connects to: Workflows Within Increments: The Effort Picture, Iteration Within Phases

Workflows Within Increments: The Effort Picture

Must-know: The shaded area under each curve in the effort picture equals the person hours spent on that workflow (E_i = integral of p_i(t)). Requirements effort is significant in increment A and tapers; analysis peaks in increment B; design in B-C; implementation in C; testing peaks in D. Effort split is roughly 1/5 requirements+analysis, 1/5 design, 3/5 implementation.

$E_{i} = \int_{t_{0}}^{t_{1}} p_{i} (t) d t$

⚠️ Top pitfall: Reading the curves as 'requirements only in increment A, testing only in increment D' - all five workflows run in every increment, in different proportions.

Self-check: What does the shaded area under a workflow curve represent? The total effort (in person hours) spent on that workflow over the project.

Connects to: The Four Phases of the Unified Process, Iteration Within Phases

The Four Phases of the Unified Process

Must-know: The four phases of UP are inception, elaboration, construction, and transition. Inception primarily captures requirements and starts testing; elaboration refines the inception artifacts (requirements, analysis, a little design and implementation of prototypes); construction does little requirements work but substantial implementation with testing in earnest; transition is where testing culminates, driven by beta-site feedback. Every phase contains all five workflows in different proportions.

⚠️ Top pitfall: Equating each phase with a single workflow (e.g., 'inception = requirements, transition = testing') - all four phases contain all five workflows, just in different proportions.

Self-check: Which phase produces the first operational-quality version of the product (the beta release)? The construction phase.

Connects to: Workflows Within Increments: The Effort Picture, Iteration Within Phases, Test Workflow

Iteration Within Phases

Must-know: Iteration happens inside phases: increment B runs iterations B.1, B.2, B.3, each containing some of all five workflows; only when the iterations within a phase are complete does the team move to the next increment. No phase is dedicated to a single workflow - every phase contains all five workflows in different proportions.

⚠️ Top pitfall: Thinking each phase is dedicated to one workflow (e.g., a 'requirements phase' or 'design phase') - every phase contains all five workflows, in varying proportions.

Self-check: In the elaboration phase (increment B), what do the labels B.1, B.2, and B.3 represent? Three iterations inside the phase, each containing some requirements, analysis, design, implementation, and testing activity.

Connects to: Workflows Within Increments: The Effort Picture, The Four Phases of the Unified Process, Episodes: Versions, Maintenance, and Mini-Projects

Episodes: Versions, Maintenance, and Mini-Projects

Must-know: Episodes are the actual history of versions: episode 1 does requirements, analysis, design, implementation; episode 2 starts and aborts an alternative implementation (only the implementation workflow); episode 3 tries a new design (a little design and implementation); episode 4 redoes all workflows after requirements change. Solid lines are development, dotted lines are maintenance. Corrective maintenance improves implementation or design; perfective maintenance changes the requirements. Each iteration is a mini-waterfall.

⚠️ Top pitfall: Thinking every increment must contain all workflows - episode 2 has only implementation and episode 3 only design plus implementation, and increment B was abandoned entirely.

Self-check: In the episodes picture, what distinguishes corrective maintenance from perfective maintenance? Corrective maintenance improves the implementation or design, while perfective maintenance changes the requirements (as episode 4 does).

Connects to: Workflows Within Increments: The Effort Picture, Iteration Within Phases, Post-Delivery Maintenance

Requirements Workflow

Must-know: The aim of the requirements workflow is to determine the client's needs. Key elements: application domain (first task - understand the environment), business case (shows cost effectiveness; the project dies if the client stops believing in it; cost may be strategic/tactical, e.g., damage in the absence of the software), constraints (deadline, reliability, performance, cost; triple constraints quality/time/cost), concept exploration and the bidding procedure. When done badly the client says: this may be the specification, but not what I really wanted. Clients ask for the wrong product mainly because software is complex and hard to visualize.

⚠️ Top pitfall: Transcribing the client's request instead of discovering the client's needs - e.g., building a financial management system when a stock control system is required to catch shrinkage, or a faster OS when the database design causes the slowdown.

Self-check: Why does the project terminate immediately if the client stops believing the software will be cost effective? Because the business case - demonstrating cost effectiveness - is a vital aspect of software development; without it there is no justification for the project.

Connects to: The Unified Process at a Glance, Analysis Workflow

Analysis Workflow

Must-know: The analysis workflow refines requirements for detailed, precise understanding; the requirements workflow output must be totally comprehensible by the client (natural language), while the analysis workflow uses a more precise language. The specifications are a contract: no imprecise terms like ample/enough/convenient/suitable, and always written as if used as evidence in court. Three classic faults: ambiguity (intrinsic to natural language - the 'it' sentence), incompleteness (e.g., no statement of actions for erroneous input data), contradictions (e.g., the 35 psi valve 17 case). After approval, planning and estimation begin; the software project management plan (deliverables, milestones, budget) is a major artifact of the analysis workflow.

⚠️ Top pitfall: Writing a specification with imprecise terms (ample, enough, optimal, 98% complete) - they sound exact but define no acceptance criteria; or planning in detail before the specifications are approved (the project is too amorphous).

Self-check: In 'a part record and a plant record are read from the database if it contains', what does 'it' refer to? It is ambiguous - it could be the part record, the plant record, or the database - which is why natural-language requirements need a separate, precise analysis workflow.

Connects to: Requirements Workflow, Design Workflow

Design Workflow

Must-know: The specifications say what the product is to do; the design workflow shows how. Designers decompose the product into modules - independent pieces of code with well-defined interfaces (arguments passed and returned, specified in detail). Architectural design is the decomposition into modules; detailed design selects algorithms and data structures per module. In the object-oriented paradigm, classes are selected during analysis and designed during design. The design team must record design decisions for backtracking, and open-ended design (future enhancements via adding/replacing classes without affecting the design as a whole) is an ideal compromised by deadlines - designers aim for a design extendable in as many reasonable ways as possible.

$v = (\frac{x _{2} - x _{1}}{t _{2} - t _{1}}, \frac{y _{2} - y _{1}}{t _{2} - t _{1}}, \frac{z _{2} - z _{1}}{t _{2} - t _{1}})$

⚠️ Top pitfall: Over-engineering the design for all possible future enhancements - it becomes unwieldy at best and impossible to implement at worst; the goal is reasonable extensibility.

Self-check: What is the aim of the design workflow? To refine the artifacts of the analysis workflow until the material is in a form that can be implemented by the programmers (showing how, not just what).

Connects to: Analysis Workflow, Implementation Workflow, Post-Delivery Maintenance

Implementation Workflow

Must-know: The implementation workflow aims to implement the product in the chosen implementation language. Large products are partitioned into subsystems, implemented in parallel by coding teams; subsystems consist of components (code artifacts) implemented by individual programmers. The programmer's documentation is the relevant design artifact (detailed design of the module). There is no way for an individual programmer to know whether the architectural design is correct - only integration reveals the shortcomings of the design as a whole; correctness is checked as part of the test workflow.

⚠️ Top pitfall: Blaming the programmer when an integrated product fails - the failure may lie in the interaction specified by the architectural design, not in the artifact; the programmer usually implemented the artifact exactly as designed.

Self-check: When do the shortcomings of the architectural design come to light? Only when the integration of the individual code artifacts begins.

Connects to: Design Workflow, Test Workflow

Test Workflow

Must-know: Testing is carried out in parallel with the other workflows from the beginning; two aspects: personal responsibility (each developer tests and retests each artifact) and independent testing by the SQA group. Traceability: every item in an analysis artifact must be traceable back to a requirements artifact, similarly for design and implementation artifacts. The four test levels: unit testing (component, programmer then SQA), integration testing (combinations of components; interfaces - number, order, types of formal and actual arguments; strong type checking by compiler/linker when available), system testing (whole product against specifications, constraints, robustness with erroneous input), acceptance testing (client on actual hardware with actual data). Bottom-up integration surfaces major design faults late (expensive rework); top-down under-tests lower-level components. Alpha release is the first version given to selected future clients; the corrected beta release is close to the final version; alpha testing is no substitute for methodical SQA testing.

⚠️ Top pitfall: Using alpha testing in place of product testing by the SQA group - alpha testing brings many faults to light but is no substitute for methodical SQA testing; alpha releases are fault laden by design.

Self-check: Why must it be possible to trace every item in an analysis artifact back to a requirements artifact? Because traceability is necessary for successful testing across the life cycle - it lets developers ensure artifacts reflect the client's requirements and lets the SQA group check the work.

Connects to: Analysis Workflow, Design Workflow, Implementation Workflow

Post-Delivery Maintenance

Must-know: Post-delivery maintenance is not grudgingly carried out after delivery - it is an integral part of the software process, planned for from the beginning; more money is spent on it than on all other software activities combined, so design should take future enhancements into account and coding should keep future maintenance in mind. Documentation problems: original analysis and design artifacts frequently not updated; database/operating manuals may never be written; the source code may be the only documentation; staff turnover removes the original developers. Regression testing: two aspects - (1) required changes implemented correctly, (2) no other inadvertent changes; the product is tested against the previous test cases, which must all be retained together with their results. Change records: all changes recorded with the reason for each; regression test cases are a form of documentation.

⚠️ Top pitfall: Discarding previous test cases after a change - regression testing is impossible without them, since the product must be re-tested against all previous test cases to ensure no inadvertent changes were made.

Self-check: What is regression testing? Once a programmer has determined that the desired changes have been implemented, the product is tested against the previous test cases to make certain that the functionality of the rest of the product has not been compromised.

Connects to: Episodes: Versions, Maintenance, and Mini-Projects, Test Workflow, Retirement

Retirement

Must-know: The final stage of the life cycle is retirement. Further post-delivery maintenance is no longer cost effective when: (1) proposed changes are so drastic the whole design would have to change (redesign and recode is cheaper); (2) so many changes have been made that interdependencies make even small changes drastically affect the product; (3) documentation is missing or unmaintained, so the risk of regression faults makes recoding safer; (4) the hardware and operating system are to be replaced, making re-implementation from scratch more economical. In each case the current version is replaced and the process continues. True retirement is a rare event: the product has outgrown its usefulness, the client no longer requests its functionality, and the product is removed from the system.

⚠️ Top pitfall: Calling every product shutdown 'retirement' - replacement (new version, process continues) is the common case; true retirement is rare.

Self-check: When does true retirement happen? When the product has outgrown its usefulness, the client organization no longer requests the functionality, and the product is finally removed from the system.

Connects to: Post-Delivery Maintenance

Exam Guidance Summary

Must-know: The examinable core of the lecture: the two-dimensional view of UP (five technical workflows inside four business phases and what each phase emphasizes); iteration vs incrementation and episodes including corrective vs perfective maintenance; the requirements workflow in the client's language vs the analysis workflow in a precise language, and the three specification faults (ambiguity, incompleteness, contradictions); traceability and the four test levels (unit, integration, system, acceptance) plus alpha and beta releases; why post-delivery maintenance is planned from the beginning, what regression testing is, and when retirement replaces maintenance.

⚠️ Top pitfall: Studying the phase names without the workflows or the workflows without the phases - the two-dimensional pairing is the central idea of the lecture.

Self-check: What are the five workflows and the four phases of the unified process? Workflows: requirements, analysis, design, implementation, testing. Phases: inception, elaboration, construction, transition.

Connects to: The Unified Process at a Glance, The Four Phases of the Unified Process, Test Workflow, Post-Delivery Maintenance

Key Industry Applications

Must-know: Industry applications: UP spans insurance, aerospace, manufacturing, banking, automobile, and nuclear power; COTS development is a fast time-to-market method while a high-security electronic funds transfer network needs a different methodology; mission-critical software means late delivery is detrimental; the bidding procedure, business case, and software project management plan (deliverables, milestones, budget) are how projects are negotiated; specification reviews, independent SQA testing, and alpha/beta releases are standard practice with beta testers gaining a head start; nuclear reactor and avionics modules illustrate safety-critical modular design.

⚠️ Top pitfall: Assuming one process fits all domains - the same lecture's core lesson: different domains and product types demand different adapted methods.

Self-check: Why does a COTS package need a different method than a bank's high-security funds transfer network? Because the two products have different risks, deadlines, and quality demands - which is why UP must be adaptable.

Connects to: The Unified Process at a Glance, Requirements Workflow, Design Workflow, Test Workflow

Previous LectureLecture 08 · Software Testing: Test-Driven Development, Release Testing, and User Testing

Next LectureLecture 10 · Software Quality Management

Was this lecture useful?

Loading comments…

🤖

BitsNotes AI Assistant

Subject Notes Assistant

Configure AI Chat

Choose how to access the chatbot

Have your own API key?

Switch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.

AI Provider Preset

API Endpoint URL (OpenAI-Compatible)

API Key

Model Name

🔑 Enter API key above to fetch live models from provider, or enter model name manually.

Remember key for this session (until tab closes)

OpenAI-Compatible API Support

Choose any provider preset (Gemini, DeepSeek, Kimi, GLM, MiniMax, Qwen, OpenAI, Groq, Ollama, etc.) or enter a custom endpoint URL.

Security & Privacy First

Your API key is sent directly from your browser to your specified provider. BitsNotes servers never store or see your key.