Object-Oriented Analysis, Design, and Process Models

This session moves from the homework dice game into the ideas behind object-oriented analysis and design: use cases, collaboration and class diagrams, UML, models, the software process, and the process models that teams choose. A running theme is that modeling comes before coding, and that the process chosen shapes how the whole project runs.

Along the way we answer three questions that every developer meets in practice:

• What should we build? Requirements and use cases capture what the system must do for its users, without yet saying how.
• How should we structure the solution? Object-oriented analysis finds the objects and their responsibilities; collaboration and class diagrams make the structure visible so that design happens on paper before it happens in code.
• How should we organize the work? Process models — waterfall, prototyping, iterative, spiral, fountain, agile, and the Unified Process — decide the order in which requirements, design, coding, and testing happen.

The lecture ties every idea back to one small example: a dice game written as a homework assignment. Because the game is tiny, we can watch each analysis and design step in full detail; the same steps scale up to industrial systems, and the closing sections show how the professional process models package those steps.

3.1 The Dice Game Assignment

The homework sets the theme for this lecture: write a small object-oriented program that plays a dice game. The task is small in size but forces every step of analysis and design: deciding which objects exist, what each object knows, and how the objects talk to each other.

Hook: A game with two dice and two players fits on one page of code, yet it contains every decision a real project faces: which objects exist, what each object knows, and how the objects talk. If we can name the objects and their responsibilities for a dice game, we can do it for a banking system or an airline reservation system — the game just keeps the whole picture visible at once.

3.1.1 The Problem Statement

Two players take turns rolling two dice and adding their totals. The game continues until one player reaches the target total and wins. Every rule matters: the target number, the number of turns, what happens on ties, and who declares the winner. A good solution states these rules in plain words before any code is written.

Example — one turn of the game: suppose the target is 21. Player A rolls a 3 and a 4, adding 7 to their total. Player B rolls a 6 and a 2, adding 8. After a few turns A reaches 21 exactly and the manager declares A the winner. Now change one rule: what if a player rolls a total that overshoots the target? Overshoot could mean "lose immediately", "clamp the total", or "skip the turn" — each is a different game, and the rules must say which one. This is why the plain-words statement comes first: two teams can read the same sentence and build two different games.

The phrase "target total" is itself a design decision: a fixed target for every game, a target chosen by the players, or even a target that changes each round. Spelling out the target, the turns, and the tie behavior in plain words is the first requirement step — no code, no diagrams, just a precise statement of what the game is.

3.1.2 The Objects in the Game

The natural objects are the two dice, the players, and the game manager. Each die object holds a face value and can roll to get a new value. Each player object knows the running total of that player. The manager object enforces the rules, tracks the turns, and announces the winner when the game ends. This mapping from real items to objects and classes is the first act of object-oriented design.

Key Concept: the mapping from real items to classes — "a die becomes a Die class, a player becomes a Player class" — is the first act of object-oriented design. Notice that both dice can be handled by one class with two instances: objects are things the class can make, not things the class is stuck with. The same applies to the players: one Player class, two player objects.

Intuition: knowing an object-oriented language well does not make someone good at object-oriented design — just as owning a hammer does not make someone an architect. The dice game is the proof: a student can write the game in one afternoon of code, but deciding where the rules live, what the manager owns, and which object announces the winner is design thinking, not coding.

3.1.3 Why Projects Fail: The Standish Report

The homework asks for a short report on the Standish Group CHAOS report, a widely cited study of software project outcomes. The study shows that a large share of projects finish late, run over budget, or are cancelled. A common lesson is that unclear requirements and weak planning cause many failures, so the homework makes the point that small modeling habits, like naming the objects first, prevent large problems later.

The original CHAOS report (1994) tracked thousands of projects and found roughly 16% succeeded on time and on budget, 31% failed outright, and 53% finished late, over budget, or with fewer features than promised. The studies that followed consistently point to the same causes: unclear requirements, missing user involvement, and weak planning. A related finding often quoted with CHAOS is that a large share of features built in requirements-first projects are never used at all — work that was fully specified, fully designed, and fully coded for nothing.

Pitfall: the failure lesson is not "requirements are a waste of time" — it is the opposite. The projects that fail are the ones that skip requirements discipline and hope the code will sort itself out. Naming the objects first, as the homework does, is cheap insurance: a wrong object model costs a few minutes to redraw on paper and days to rip out of working code.

3.1.4 Discussion: The Program vs. The Model

The class discussion returned to one phrase: the program is a model of the game, not the game itself. Classes and objects stand in for real items such as dice and players, and the same game rules can be modeled in many different ways. Choosing a good object model is the design work that makes the code easy to change later.

Key Concept: the program never contains an actual die; it contains a Die object with a face value and a roll() method that stands in for the physical object. The model is a representation, and there is always a gap between the real thing and its model — the real die has weight and feel, the model only has state and behavior that the program needs. A good model keeps exactly the details that matter to the program and drops the rest.

The same game rules can be modeled in many different ways, and that is a feature, not a problem:

• one Die class with two instances, or two separate classes DieA and DieB;
• a Manager that holds both players and both dice, or a looser design where the players talk directly to each other;
• a stored "total" attribute on each player, or a total computed on demand from a history of rolls.

Each design is a valid model of the same game. The model chosen decides how easy the game is to extend — for example, adding a third player, a new rule, or a different die with more faces.

One exchange corrected a phrase that kept coming back — several students kept calling the program the game itself:

Real-world: the Standish Group CHAOS report is still quoted in project management training to explain why requirements discipline matters — three decades after the first study, "unclear requirements" still tops the lists of why projects fail.

Exam note: be ready to name the objects of a small game and to state the role of each object — and to explain why the program is a model of the game rather than the game itself.

3.2 From Requirements to Code

Building software is a journey that starts with requirements and ends with code, with design in between. Skipping the middle steps produces code that works by accident and fails at the first change.

Hook: think of the three steps as asking three different questions. Requirements answer "what must the system do?", design answers "how will it be built?", and code answers "make it run." A team that jumps straight from the first question to the third has skipped the second — and the code pays for it with every change, because nobody ever decided how the parts should fit together.

3.2.1 The Requirements Phase

Requirements say what the system must do for its users, in the language of the users. For the dice game, a requirement is "the game ends when a player reaches the target total." Requirements are collected from clients, users, and documents, and they are written down before design starts. An unclear requirement found late costs much more to fix than one found early.

Key Concept: requirements are written in the user's language, not the programmer's. "The game ends when a player reaches the target total" is a sentence any player can confirm; "gameLoop() should compare score against threshold" is not. The requirements phase deliberately stays away from classes, methods, and diagrams — those belong to design. The moment a requirement reads like code, the team has slipped into design before the what is even agreed.

The phrase "the game ends when a player reaches the target total" hides a decision: what counts as reaching the target? Exactly equal, or at least equal? If a roll takes the total past the target, is that a win, a loss, or a restart? Requirements like this look simple and are not — which is why they must be written down and confirmed with the client before design starts.

3.2.2 The Design Phase

Design turns requirements into a blueprint. The designer decides which classes exist, what attributes and methods each class has, and how objects collaborate. Good design choices make the later code short, and poor design choices make it long and tangled. Design happens on paper or in a modeling tool, before the first line of code.

Example — the same requirement, two designs: the requirement says "the manager announces the winner." Design A gives the manager a method announceWinner() that reads both totals and decides. Design B spreads the same decision across the player classes, letting each player guess whether it won. Both designs satisfy the requirement, but Design A keeps the rules in one place: changing the target total touches one method. In Design B the same change touches every class that guessed. The design phase is where this choice is made — on paper, in minutes, before any code exists.

The design phase produces the diagrams this session is about: class diagrams for the static structure and collaboration diagrams for the dynamic flow of messages. The dice game's design is a small drawing: three boxes (die, player, manager), a few attributes, a few arrows for messages. Small on paper, but it is the blueprint the code follows.

3.2.3 The Coding Phase

Coding is the translation of the design into a working program. If the design is complete, the code is mostly mechanical. Teams that start coding before design spend their time patching, because the structure of the program fights the requirements from the start.

Pitfall: "mostly mechanical" does not mean "trivial" — it means the hard decisions were already made. When the design is missing, the programmer makes the design decisions while typing, one ad hoc decision per line, with no chance to see the whole picture. The result is code that works for today's requirements and breaks on the first change, because its structure was never decided, only improvised. The patches accumulate: a flag to make one case work, a special case to fix one bug, and soon nobody can explain why the code behaves as it does.

3.2.4 Requirements, Design, and Code Together

The three steps form one chain. Requirements describe what; design describes how; code makes it run. The chain is revisited: a new requirement may force a design change, and a design problem may send the team back to the requirements. This back-and-forth is the seed of every software process described later in this session.

Example — the chain moves both ways: the client adds a requirement: "if a player rolls double sixes, they roll again immediately." The requirements change, so the design must change (a new rule in the manager, a new message between manager and player), and then the code changes to match. Later the design hits a wall — the manager does too much — and the team discovers the requirement "the manager enforces all rules" was never really wanted; they go back and rephrase it. The chain is not a one-way street; it is a loop, and later sections show how process models organize that loop.

Intuition: the back-and-forth between requirements, design, and code is not a sign of failure — it is normal. What separates professional processes from amateur habits is deciding in advance when and how the loop happens, instead of letting it happen by accident in the middle of coding.

3.3 Use Cases

Use cases are the first modeling tool of the session. A use case is a story of how an actor uses the system to reach a goal, written from the outside in.

Hook: a use case treats the system as a black box. The story never says how the system works inside — only what happens at the boundary: the actor does something, the system responds, the actor sees a result. "The player rolls the dice and the system reports the new total" is a complete use case even though it says nothing about classes, methods, or code.

3.3.1 What a Use Case Is

A use case describes one interaction between an actor and the system. Each use case has a name, a trigger, a flow of steps, and a result. For the dice game, "play a turn" is a use case: the player rolls the dice, the system totals the faces, and the system reports the new total. Use cases are written in plain language so that clients can confirm them.

Key Concept — the parts of a use case: the name says what the actor wants ("Play a Turn", "Declare a Winner"); the trigger says what starts the interaction (the player's turn begins); the flow of steps is the story of the interaction, step by step, in the actor's language; the result is the goal reached (the new total is shown). A use case is a text story, not a diagram — the diagram comes later, and the story is the source of truth.

A use case can be written at different levels of detail: a brief version is a single paragraph, a casual version adds the main flow, and a fully dressed version adds alternatives, exceptions, and preconditions. Whatever the level, the rule is the same — essential style: describe what happens, not how the screen should look. "The system shows the total" is a use case step; "the total appears in the top-right corner in blue" is a design decision that does not belong here.

3.3.2 Actors and the System Boundary

An actor is anything outside the system that interacts with it: a human user, another system, or a clock. In a use case diagram, actors sit outside the system boundary, and use cases sit inside as labeled ovals. The boundary decides what the system does itself and what it leaves to the actors. Drawing the boundary early settles arguments about scope.

Example — the boundary decides the scope: the dice game's boundary is drawn around the game itself. "Roll the dice" is inside, because the system rolls. "Decide the target total" might be outside, left to the players before the game starts. "Keep a permanent history of past games" is a candidate — if no use case says the system records history, then recording history is out of scope, no matter how nice it would be. That is the power of the boundary: scope arguments become a simple test. Is the behavior inside a use case? If yes, it is in scope. If not, it is out.

Use cases are named with strong verb phrases: "Withdraw Funds", "Roll the Dice", "Declare a Winner". Weak names like "Process Turn" or "Do Game" say nothing about the goal and are a warning that the use case itself is unclear.

3.3.3 Example: Use Cases for the Dice Game

The dice game yields a small set of use cases: start a new game, roll the dice, show the current total, and declare the winner. The actor is the player. Each use case is one oval inside the boundary, connected by a line to the player. The set of use cases is a checklist: when every use case works, the game is complete.

The diagram for this set is small: one rectangle for the system boundary, one actor (the player) drawn outside it, and four ovals inside. Each oval is labeled with the use case name. Every oval connects to the player with a line — the player starts all four stories.

3.3.4 Benefits of Use Case Modeling

Use cases give the team a shared language with the client, so misunderstandings surface while the cost of fixing them is still low. They also set scope: anything not inside a use case is out of scope. Later in the process, use cases drive testing, since each use case becomes a test scenario. This is why the session calls use cases the entry point of object-oriented analysis.

Key Concept — use cases as the requirement backbone: the set of use cases is the requirements document in story form. Clients confirm it, designers read classes out of it, and testers convert it into scenarios: "start a new game, roll, show total" becomes a test script the team can run against the finished program. One artifact feeds every later phase — which is why a use case written in plain, confirmable language is worth more than a page of technical specification.

Real-world: teams write user stories in the same spirit as use cases, keeping the description small enough for one iteration — "as a player, I want to roll the dice" is the agile cousin of "Roll the Dice", with the same goal: a shared, confirmable story of what the system does.

Exam note: know how to draw a use case diagram with actors, ovals, and the system boundary, and how to read the scope out of it — list the actors, name each use case with a strong verb phrase, and be ready to say which behaviors fall inside the boundary and which do not.

3.4 Object-Oriented Analysis

Analysis studies the problem and produces a list of candidate objects, their data, and their behavior. The main technique is reading the problem statement for nouns and verbs.

Hook: analysis is the translation step between the use cases and the design. The use cases tell a story about the game; analysis reads that story and asks "which things in this story are objects, and which actions are responsibilities?" Nouns become candidates for objects; verbs become candidates for methods. The result is not code — it is a list of candidates that the design phase will refine into classes.

3.4.1 The Purpose of Analysis

Analysis asks what the system must do, not how it will do it. The output is a set of objects discovered from the problem, not invented from the code. Analysis is finished when every requirement can be traced to one or more objects and their responsibilities.

Key Concept — discovered, not invented: analysis finds objects that are already in the problem. "Dice" and "players" are in the problem statement, so they are discovered. A DataManager or DisplayHelper class is not in the problem statement — it is an implementation idea, and it belongs to design, not analysis. If the analysis output needs explaining in terms of the code, the analysis has drifted into design.

The traceability test gives a clean stopping rule. Take each requirement and point at the objects that serve it: "the game ends when a player reaches the target total" traces to the game manager (which enforces the rule) and the player (which holds the total). When every requirement has such a trace, analysis is done; nothing more can be discovered from the problem.

3.4.2 Finding Objects: Nouns

Nouns in the problem statement are candidate objects. In the dice game, the nouns are dice, player, game, target, and total. Each noun is tested: does it hold data, and does something act on it? A noun that only names a rule, such as "winning", may be better modeled as a method than as an object. The session walks the dice game statement line by line, circling nouns and testing each one.

Example — walking the statement: "Two players take turns rolling two dice and adding their totals. The game continues until one player reaches the target total and wins."

Noun	Holds data?	Acted on?	Verdict
players	yes (each holds a total)	yes (they roll)	candidate class Player
turns	yes (whose turn it is)	yes (tracked)	attribute of the game, not its own class
dice	yes (face values)	yes (rolled)	candidate class Die
game	yes (rules, state)	yes (started, ended)	candidate class Game (manager)
target	yes (a number)	no (just compared)	attribute, not a class
total	yes (a number)	yes (added to)	attribute of Player
winning	no — it is a state, not a thing	—	a method (declareWinner), not a class

This noun test is called noun phrase identification, and it is one of three standard strategies for finding candidate objects: reuse a model from a similar previous project, work from a category list of common object types, or read the statement for noun phrases. For a small problem like the dice game, the noun walk alone is enough.

3.4.3 Finding Responsibilities: Verbs

Verbs suggest responsibilities and methods. "Roll" becomes a method on the die object. "Add" becomes an operation on the total. "Declare the winner" becomes a method on the manager. Pairing each verb with an object that can carry it out is a fast way to build a first method list, and it keeps behavior close to the data it uses.

Key Concept — pair the verb with the noun that owns it: each verb is a candidate responsibility, and the noun that the verb acts on is the natural home. "Roll the dice" belongs to the dice — the die rolls itself and returns a new face value; nobody else should be reaching inside it. "Declare the winner" belongs to the manager, the only object that knows all the rules. This pairing rule has a payoff that shows up later in design: a method lives next to the data it reads and writes, so the object's data stays coherent and the code stays short.

Not every verb becomes a method: "continues" in "the game continues until…" is the game loop itself, a property of the whole program rather than a single object's responsibility. The pairing works best on verbs that name actions of one object on one other object.

3.4.4 The Object Dictionary

The session recommends collecting the chosen objects in a small dictionary: one page per object, listing its attributes, its methods, and the objects it talks to. The dictionary is a shared reference for the whole team. It is cheap to write, and it stops two programmers from modeling the same object in two different ways.

Example — one page of the dictionary: the entry for the die object reads: attributes — faceValue: int; methods — roll(): int; talks to — the game manager (returns its face value), the player (reports the total of the roll). One page, three lines, and the whole team now agrees on what a die is. The manager's page lists the rules it enforces, the players it tracks, and the message it sends to announce a winner.

Pitfall: the dictionary only works if it is treated as a living document. Two programmers who stop reading it will quietly diverge — one models the total as a number on the player, the other stores a list of every roll and computes the total. Both work, and the dictionary exists precisely to catch that divergence on paper, where it costs minutes, instead of in code, where it costs days. When a candidate object changes during design, the dictionary page changes with it.

3.5 Collaboration Diagrams and the Seven Game

Collaboration diagrams show how objects exchange messages to carry out a task. The session works through the "seven game": what is the chance that two dice sum to seven, and which pairs make it happen?

Hook: a collaboration diagram is the object dictionary in motion. The dictionary says "the die has a roll() method and the manager totals the values"; the collaboration diagram shows those methods being called, one message at a time, in the order they happen. Reading a collaboration diagram is like reading a script: every line says who talks to whom, and the whole scenario runs like a play.

3.5.1 What a Collaboration Diagram Shows

A collaboration diagram is a snapshot of one scenario. Objects are drawn as boxes with a label such as player or die. A message is an arrow between boxes, labeled with the message name and a sequence number, so the diagram reads like a numbered script of who talks to whom. The same scenario can be drawn as a sequence diagram, which stresses time, while the collaboration diagram stresses the links between objects.

Key Concept — numbered messages and links: each arrow carries a sequence number ("1:", "2:", "3:") and a message name, so the reading order is fixed: message 1 happens first, then message 2, and so on. The arrows also do double duty — a message can only travel between objects that have a link, so the diagram silently shows which objects are connected to which. Draw two objects with an arrow between them, and you have also drawn an association that the class diagram must contain.

Collaboration diagrams are used in practice for a handful of jobs: a bird's-eye view of all the objects cooperating in a scenario (especially in real-time and embedded systems, where the topology of connections matters more than the timing), an alternate view to the sequence diagram for explaining a design to a colleague, allocating functionality to objects during design, modeling a complex operation's logic, and exploring the roles objects play. The common form is the instance-level diagram — one diagram for one concrete scenario with named objects like player, die1, and die2, exactly as the dice game uses.

3.5.2 The Seven Game Worked Example

The dice game walkthrough in this part focuses on the total seven. Each die takes a value from the uniform distribution over the six faces:

$$X\sim \mathcal{U}\{1,2,3,4,5,6\}$$

and the event of interest is that the two dice sum to seven:

$$X_1+X_2=7$$

3.5.3 Counting the Pairs

With two dice there are 36 equally likely ordered outcomes. The pairs that sum to seven are (1,6), (2,5), (3,4), (4,3), (5,2), and (6,1): six pairs in total. The probability is 6 out of 36, which reduces to 1 out of 6. Seven is the most likely sum of two dice because it has the most pairs. The sum nine can be made in only four ways, (3,6), (4,5), (5,4), and (6,3), so it is less likely. The same counting idea, not the formulas, is the skill the session wants to teach.

Intuition: the pattern in the table is a pyramid that peaks at seven — one pair for 2, two for 3, and so on up to six pairs for 7, then back down. That is why seven is the most likely sum of two dice: not because the number is lucky, but because more ordered pairs land on it than on any other total. Notice the pairs are ordered: (1,6) and (6,1) are different outcomes (first die 1 and second die 6, versus the other way around), and both count.

3.5.4 Walkthrough: Messages in the Dice Game

In the walkthrough of the dice game, the player object sends a roll message to each die object, the die objects reply with their face values, and the manager object totals the values and decides the winner. The collaboration diagram for one turn has three objects and a handful of numbered messages. Drawing the walkthrough before coding turns the object dictionary into a working story, and the story is the first draft of the code.

Real-world: counting outcomes by listing pairs is the standard first lesson in probability in statistics courses and game design — game designers count outcomes the same way when balancing dice-based mechanics, and the pyramid table above is the same table that appears in any introduction to probability.

Exam note: expect a small probability question built from the seven game, such as counting the pairs that sum to a given total — list the ordered pairs, count them, and write the probability as (count)/36.

3.6 Class Diagrams: Static Structure vs. Dynamic Behavior

Class diagrams describe the types of objects and their relationships, which is the static view of the system. Collaboration diagrams describe behavior over time, which is the dynamic view.

Hook: think of a building. The floor plan is the static view — which rooms exist, how they connect, where the doors are. The behavior of the building is dynamic — people moving through corridors, doors opening, deliveries arriving. Software is the same: the class diagram is the floor plan, the collaboration diagram is the activity. Both describe the same building; neither one is the building.

3.6.1 Reading a Class Diagram

A class diagram is a box with the class name, a list of attributes, and a list of methods. Lines between boxes show relationships such as "a game has two dice" or "a player can be a winner". The diagram is a picture of the design: it shows what can exist, not what happens at a particular moment.

Key Concept — the three compartments: a class box is drawn as a rectangle divided into three compartments: the class name at the top, the attributes in the middle, and the methods at the bottom. The notation is a compact convention: attributes read as name : type (for example, faceValue : int), and methods read as name(params) : returnType (for example, roll() : int). A line between two boxes records a relationship between the classes: "a game has two dice" is a line from Game to Die, and "a player can be a winner" is a line between Player and the winner state. Every line in the diagram is a fact about what can exist, stated once and read by everyone.

3.6.2 Static vs. Dynamic Views

The static view answers "what exists": classes, attributes, and relationships. The dynamic view answers "what happens": messages, states, and sequences. A class diagram and a collaboration diagram of the same game describe different things, and both are needed. Confusing the two is a common beginner error, because both diagrams use the same object boxes.

Pitfall: the two diagrams share the same vocabulary — both draw rectangles with labels like player and die — so beginners read one as the other. The test is the question each diagram answers. Point at a class diagram and ask "what exists?" — classes, attributes, relationships. Point at a collaboration diagram and ask "what happens?" — who sends which message, in what order. A diagram that shows messages is dynamic; a diagram that shows classes and lines is static. If the answer mixes the two, the diagram has been misread.

3.6.3 Example: The Dice Class

The Dice class has the attribute faceValue and the method roll(). The Player class has the attribute total and the method addToTotal. The GameManager class has the attribute target and the method checkWinner. In the class diagram these three boxes sit side by side; in the collaboration diagram the same boxes swap messages during a turn. The class diagram is the static structure, and the collaboration diagram is the dynamic flow.

Exam note: be ready to label a given diagram as static or dynamic and to justify the choice — static answers "what exists" (classes, attributes, relationships), dynamic answers "what happens" (messages, sequences).

3.7 UML: Unified Modeling Language

UML gives the team a standard notation for the diagrams of this session, so that a diagram drawn by one person can be read by anyone.

Hook: UML is to software diagrams what sheet music is to music. Any musician can read any score written in the standard notation, no matter who composed it. Without that standard, every composer invents their own symbols and the music stops being shareable. UML plays the same role for diagrams: it makes the drawing readable by anyone, anywhere, and by the tools that exchange it.

3.7.1 Why a Standard Notation

A standard notation removes ambiguity. Every team member reads "a class box with two compartments" the same way, and tools can exchange the diagrams. Without a standard, each developer invents a private symbol set and the diagrams stop being a shared language. The session stresses that UML is a notation, not a process: it says how to draw, not which steps to follow.

Key Concept — notation, not process: this is the single most important thing to remember about UML. It answers the question "how do I draw a class diagram?" — boxes, compartments, arrows, ovals. It does not answer "should I write requirements before design?" or "how many iterations should my project run?" Those are process questions, answered by the process models later in this session. A team can use UML inside a waterfall process or inside an agile process; UML only guarantees that whatever they draw means the same thing to everyone.

3.7.2 The Main Diagram Types

UML has many diagram types, and the session covers the ones used in the course: the use case diagram for actors and goals, the class diagram for static structure, and the collaboration and sequence diagrams for behavior. Each diagram type exists to answer one kind of question, so choosing the right diagram for the question matters more than drawing a fancy one.

Example — picking the right diagram: a client asks "can a player start a game?" — that is a scope question, answered by the use case diagram. A designer asks "does the manager know the target?" — that is a structure question, answered by the class diagram. A programmer asks "who calls roll() first?" — that is a behavior question, answered by the collaboration or sequence diagram. Every diagram type exists to answer one kind of question; the skill is matching the question to the diagram before drawing anything.

3.7.3 UML Tools

The diagrams can be drawn by hand or in a modeling tool. The session names a few widely used tools, including Rational Rose, ArgoUML, StarUML, and Violet, and notes that the tooling space keeps changing as vendors such as IBM fold modeling into their product lines. A simple tool is enough for this course; the skill being taught is reading and writing the diagrams, not mastering a product.

Intuition: a pencil and paper is a legitimate UML tool. Hand-drawn diagrams carry the same notation as tool-generated ones, and for a course-sized problem they are faster. The tools earn their keep on real projects — sharing, versioning, and generating code from the model — but the exam and the design skill are about the notation, not the menu of a product. If a diagram is correct in pencil, it is correct in Rational Rose.

3.7.4 UML and the Process

UML diagrams are used in most of the process models in this session, because analysis and design produce diagrams regardless of the process chosen. The reference text for the course, the Larman book on object-oriented analysis and design, uses UML throughout, and the session advises keeping the book nearby as the notation reference.

Key Concept — diagrams in every process: waterfall, prototyping, spiral, and agile all produce analysis and design artifacts, and in this course those artifacts are UML diagrams. The process decides when the diagrams are drawn and how many times they are revisited; UML decides how they look. That separation is why the session treats UML early and the process models later: first the language of the diagrams, then the rhythm of the work that produces them.

3.8 Models and Architecture

A model is a simplified view of a system that keeps the details that matter for one purpose and drops the rest. A project is described by several models, and the architecture is the way the pieces fit together.

Hook: an architect never hands a builder one giant drawing. There is a floor plan for the rooms, an electrical plan for the wiring, a plumbing plan for the pipes — each plan keeps exactly the details one trade needs and drops everything else. Software is the same: no single document can describe a system usefully, so a project keeps several models, each deliberately incomplete.

3.8.1 What a Model Is

The use case model lists what the system does for actors. The class model lists the objects and relationships. The collaboration model shows behavior. Each model is deliberately incomplete: a use case diagram says nothing about data structures, and a class diagram says nothing about the order of events. Working with several small models is easier than working with one giant description, because each model can be checked and changed on its own.

Key Concept — deliberate incompleteness is a feature: a model that included everything would be as big and as hard to read as the system itself. The use case model is incomplete by design — it drops all data structures; the class model drops all timing; the collaboration model drops all code. Each one can be reviewed alone: the client checks the use case model without wading through classes, the designer checks the class model without reading a story. When one model changes, only that model is reworked, not one giant document.

3.8.2 The Architecture

The architecture is the overall structure of the system: the major components, their responsibilities, and the connections between them. Architecture decisions are the hardest to change later, because everything else hangs on them. For the dice game the architecture is simple, but the session notes that the same thinking scales to large systems, where a good architecture is what keeps the project buildable.

Example — the dice game's architecture: three major components — the dice, the players, and the manager — with clear responsibilities (roll, track totals, enforce rules) and clear connections (players talk to dice, the manager talks to players). It is a small architecture, but the same three ingredients are present as in a large system: named components, assigned responsibilities, defined connections. Change the architecture — for example, let the dice talk directly to the manager — and every diagram and every class in the design shifts with it. That is why architecture decisions are the hardest to change later: they are the first decisions, and everything else hangs on them.

3.8.3 Views for Different Readers

Different readers need different views. The client reads the use case model. The designer reads the class and collaboration models. The builder reads the code. A model made for one reader is still useful to the others, because all the models describe the same system from different angles. The session compares this to looking at a building from the front, the side, and the top: each view is true, and together they give the full picture.

Example — the same system, three readers: the client reads the use case model and confirms "yes, the game ends when a player reaches the target." The designer reads the class and collaboration models and decides where the rule lives. The builder reads the code that follows those models. The front view, the side view, and the top view are all views of the same building — if the views disagree, the building is wrong somewhere, and finding the disagreement is exactly what the models are for.

3.9 The Software Process and the SRS

A software process is the set of steps a team follows to build and maintain software, and the process gives the project its timeline and its discipline.

Hook: a process is the difference between a team and a crowd. A crowd of developers all typing at once will produce software eventually, but nobody can say in what order, who is responsible for what, or whether the pieces will fit. A process answers those questions in advance: who does what, in what order, with what outputs — and the discipline of following it is what turns the crowd into a team.

3.9.1 Defining the Software Process

The software process covers the whole life of a product: requirements analysis, design, implementation, testing, deployment, and maintenance. A process defines who does what, in what order, and with what outputs. Teams without a process still do these steps, but in a hidden, uncontrolled order. The session emphasizes that a process is not paperwork; it is a way of making the steps visible so that problems can be caught early.

Key Concept — visible steps catch problems early: every team, even the most chaotic, does requirements, design, and testing — but in chaos the steps happen invisibly and out of order: testing squeezed in at the end, design improvised during coding, requirements remembered halfway through. A process makes each step a named, scheduled event with an output, so problems surface where they happen — a design reviewed on Tuesday fails on Tuesday, not during the deployment weekend. The paperwork is only the evidence that the step really happened.

3.9.2 The Software Life Cycle

The life cycle starts when the product is conceived and ends when it is retired. Between those ends, the product passes through phases, and each phase produces something the next phase consumes. A product eventually retires when it is no longer used or maintained, and the process should plan for that end, including the transfer of knowledge and data. The session calls the life cycle the timeline inside which every process model operates.

Example — the phases as a production line: conception produces the idea; requirements produce the SRS; design produces the blueprints; implementation produces the code; testing produces the verified build; deployment puts it in service; maintenance keeps it alive; retirement ends it. Each phase consumes the previous phase's output and produces the next phase's input. The life cycle is longer than the development project itself: a product can be maintained for years after its build project ended, and the process should plan the retirement too — who owns the knowledge, and what happens to the data, when the product is switched off.

3.9.3 The SRS Document

The Software Requirements Specification, or SRS, records what the system must do. It is the contract between the client and the team: the team builds to the SRS, and the client checks the result against it. A good SRS is precise enough to test: each requirement can be marked as met or not met. Vague phrases in the SRS, such as "fast response", are a warning sign, because they cannot be tested and leave the contract open to argument.

Key Concept — the testability test: a requirement is well written if a tester can mark it "met" or "not met". "The game ends when a player reaches the target total" passes the test: the tester runs the game and checks. "The system responds quickly" fails the test: what does "quickly" mean, and who decides? The fix is to make it measurable — "the system responds within one second for a game of two players". Every vague phrase in the SRS is a future argument between the client and the team, and the testability test is the filter that removes them.

Real-world: in industry, the SRS is often attached to the project contract, so a change to the SRS triggers a formal change order — a documented, costed amendment to the contract, which is exactly why the testability of each requirement matters: an untestable phrase cannot be checked, but it can still be argued about.

Exam note: be able to list the phases of the life cycle and to say what an SRS is used for — it is the testable contract between client and team, and each requirement in it must be checkable as met or not met.

3.10 Preconditions and Postconditions

Preconditions and postconditions describe a method's contract: what must be true before the method runs, and what the method guarantees afterwards.

Hook: a method is a promise, and a contract states the promise in writing. A bank withdrawal method promises "the money leaves the account" — but only if the caller promises "the account holds enough, and the amount is positive." Preconditions and postconditions are those two promises made explicit, so the caller knows what to provide and the method knows what to deliver.

3.10.1 The Method Contract

Every method can be described by a contract with two parts. The precondition is the responsibility of the caller: the conditions the caller must satisfy. The postcondition is the responsibility of the method: the conditions the method promises on completion. A contract makes the boundary between caller and method explicit, so each side knows what it can rely on.

Key Concept — who owns which promise: the split of responsibility is the whole point. The caller owns the precondition: if the input is wrong, the caller broke the contract. The method owns the postcondition: if the promised result is missing, the method broke the contract. Written next to the method signature in the design documents, the contract answers the two questions every programmer asks about an unfamiliar method — "what do I have to give it?" and "what do I get back?" — without reading the implementation.

3.10.2 Preconditions

A precondition states what must hold before the method runs. For example, a method that computes a square root requires a non-negative input, and a method that divides requires a non-zero divisor. If the caller breaks the precondition, the method is not obligated to give a useful result. Stating preconditions in the design documents, next to the method signature, turns silent assumptions into stated rules.

Example — the dice game's preconditions: checkWinner() on the game manager has the precondition "two players have rolled at least once" — calling it before any roll would decide a winner on two empty totals. roll() on the die has no precondition worth stating, because a die can always roll. The manager's contract is the more interesting one: the method's behavior is only guaranteed when the game is in a state the caller is responsible for creating.

3.10.3 Postconditions

A postcondition states what holds after the method completes, assuming the precondition held. For the dice game, the roll() postcondition is that the face value of the die is between 1 and 6. Postconditions make testing easier, because a test can check the promise directly. They also make reuse safer, because a new caller can read the contract instead of guessing at the behavior from the code.

Key Concept — postconditions describe the state after, not the action taken: a postcondition is an observation, not a to-do list. "The die's face value is between 1 and 6" is a postcondition; "the method sets the face value" is an action. The distinction matters because the postcondition can be checked: a test rolls the die and verifies the face value sits in 1-6. Postconditions typically fall into a few categories: an instance was created, an association was formed, or an attribute was modified — for addToTotal(int), the postcondition is an attribute modification: "the player's total is the old total plus the value". The roll() postcondition — "the face value is between 1 and 6" — is exactly the kind of promise a test can verify directly, which is why contracts make testing easier and reuse safer.

Exam note: for any given method, be able to write one precondition and one postcondition in plain words — the precondition is the caller's responsibility before the call, the postcondition is the method's promise after, and it must describe the resulting state, not the action taken.

3.11 Build-and-Fix, Waterfall, and Prototyping

The first three process models of the session are build-and-fix, the waterfall, and prototyping. Each answers the same question differently: how much planning before code, and what happens when the plan is wrong.

Hook: every process model is an answer to one question: what do you do before you write code, and what do you do when the plan turns out to be wrong? Build-and-fix plans nothing and fixes everything later. The waterfall plans everything in advance and can barely move when the plan is wrong. Prototyping plans almost nothing but spends hours, not months, finding out what the plan should be.

3.11.1 Build-and-Fix

Build-and-fix is the informal model: write code immediately, then fix whatever breaks. It works for tiny programs and fails for everything else, because the cost of a fix grows as the program grows. The session calls build-and-fix the default trap: it feels fast, but the later fixes are paid at the worst possible time, when the code is large and the schedule is short.

Pitfall — why the trap closes: build-and-fix works for a five-minute homework because a fix costs five minutes. In a large program, a fix is no longer a fix: the changed piece touches other pieces, which touch others, and each fix drags the structure further from any plan. The trap is psychological — writing code feels like progress, so the team keeps doing it — while the bill arrives later, all at once, exactly when the deadline arrives. The homework's dice game is the dividing line: one student's build-and-fix dice game is finished in an afternoon; a build-and-fix payroll system is finished, if ever, years later and on its third rewrite.

3.11.2 The Waterfall Model

The waterfall model is a strict sequence of steps: requirements, design, implementation, testing, and maintenance. Each step finishes before the next starts, like water falling from one level to the next. The strength is discipline: nothing is built before its input is ready. The weakness is rigidity: once a step is finished, going back is expensive, and a misunderstanding in the first step travels down the whole waterfall. The session notes that the waterfall works best when the requirements are stable and fully known at the start.

Key Concept — the waterfall's real flaw is feedback timing: each stage consumes the previous stage's output and never looks back, so the first feedback the team gets about a requirement error arrives at the end, in testing — the most expensive moment to learn anything. Research on project outcomes consistently associates this model with the highest failure rates. The waterfall's discipline is real: nothing is built before its input is ready, and the documents are complete. But that discipline is bought at the price of rigidity: the later a mistake is discovered, the more it costs, and the waterfall guarantees that mistakes are discovered as late as possible.

3.11.3 Prototyping

Prototyping builds a rough version fast, in a matter of hours, to check the ideas with the client. The prototype is a model of selected behavior, not the real system: it may ignore performance, security, and the parts of the system the client already understands. After the review, the prototype goes onto the shelf, and the real system is built from what was learned. The client feedback, not the prototype code, is the output the team keeps. The session warns that teams often mistake the prototype for the final product and keep extending it, which turns the quick check into a slow mess.

Example — the prototype that taught the team: a client wants a dice game but cannot say whether the total should be shown after every roll or only at the end of a turn. Instead of debating, the team builds a prototype in an afternoon: dice roll, totals appear, nothing else — no error handling, no security, no winner logic yet. The client plays with it for ten minutes and says "show the total after every roll, but grey out the dice during a roll." That is the feedback. The prototype goes on the shelf; the real game is built with the answers it produced. If the team had kept extending the prototype instead — adding the winner rule, saving games, polishing graphics — the "quick check" would have become the real project, built on a foundation nobody planned.

Real-world: the advantages of prototyping show up in client-facing projects, where users cannot describe what they want until they see something running — the prototype exists to produce that "something running" in hours, not months.

Exam note: compare the waterfall and prototyping models, naming the advantages and disadvantages of each — waterfall: discipline and complete documents, but rigidity and late feedback (works only with stable requirements); prototyping: fast client feedback, but the prototype is not the product and must be shelved.

3.12 Incremental vs. Iterative Development

Incremental and iterative are often used as if they were one word, but they describe different ways of growing a system.

Hook: imagine building a house as a deck of cards. Incremental growth deals the cards into new hands — the house grows by adding parts. Iterative growth reshuffles and deals again — the same hand, improved each time. The distinction matters because the two ideas solve different problems: incremental solves "when does the customer see something working?", iterative solves "what do we do when we do not fully understand the problem?"

3.12.1 Incremental Delivery

Incremental development delivers the system in versions, and each version adds parts to the previous one. Version 1 of the dice game might include only one player; version 2 adds the second player; version 3 adds the target and the winner rule. The customer gets working software early, and each version is a natural check of progress. The parts are added until the full scope is delivered.

Example — the dice game in versions: Version 1: one player can roll two dice and see the faces — already working software. Version 2: a second player joins, and the totals are tracked per player. Version 3: the target total and the winner rule complete the game. Every version runs, every version is demonstrable, and the customer's "yes, that is what I meant" after each version is worth more than any page of requirements. Incremental answers the question "when does the customer first see something real?" — after the first increment, not after the whole project.

3.12.2 Iterative Refinement

Iterative development repeats the same core cycle, refining the design each time. Each iteration passes through analysis, design, and implementation again, but with a better understanding of the problem. The product is not delivered in new pieces; it is the same product, sharpened on each pass. Iteration is how a team handles requirements that cannot be fully known in advance.

Key Concept — sharpening the same blade: an iteration is a full pass through the core cycle — analyze, design, build, test, review — and the output of each pass is not a throwaway sketch but a production-grade subset of the system. What changes between passes is understanding: the feedback from iteration N refines the work of iteration N+1. This is how a team handles requirements that cannot be fully known in advance — not by waiting for perfect requirements, but by cycling through the work, each pass a little wiser than the last. Iterations are timeboxed: a fixed length (one week, three weeks), so each pass has a rhythm and a deadline, and the review at the end of each pass decides what the next pass refines.

3.12.3 Combining Both

In practice the two ideas are combined: the team delivers incrementally, and inside each increment it iterates. The customer deploys each version, uses it, and the feedback refines the next cycle. The session notes that combining both is the basis of the modern process models, including the unified development process described at the end of the session.

Example — delivery grows, work cycles: the team ships Version 1 (incremental growth) after iterating on it three times (iterative refinement). Version 1's deployment feedback goes into the iterations that build Version 2, and so on. The customer always sees working software, and the team is always refining what it understands. This pairing — incremental delivery with iterative refinement — is not an exotic option; it is the backbone of the modern models, including the unified process, and it is why the session spends a whole section separating the two words before joining them.

Exam note: give a one-line definition of each term and an example of a system built both ways — incremental adds parts in versions (the dice game in three versions), iterative refines the same core cycle again and again (each pass sharpens the design), and the two are combined in practice.

3.13 Spiral, Fountain, and Agile Models

Three more process models: the spiral, which is risk-driven; the fountain, which is iterative; and the agile family, which is customer-driven.

Hook: the waterfall assumed the plan is right and the risk is small; prototyping assumed the client does not know what they want. The models in this section answer two more questions: what do we do when the danger is not in the requirements but in the unknown parts of the project (spiral), and what do we do when requirements keep changing (agile)? Each model exists because the previous ones left a failure mode uncovered.

3.13.1 The Spiral Model

The spiral model repeats a loop, and each loop moves the project outward while re-checking risk. Each pass through the loop has four parts: set the objectives, examine the risks, build and test a version, and review the result with the stakeholders. The next loop starts from the review. The spiral makes risk the steering wheel: the risky parts are attacked early, when they are cheapest to fix, instead of being discovered at the end.

Example — risk steers the loop: imagine the dice game needs a graphical interface that the team has never built. The first spiral loop sets the objectives (a playable turn with a window), examines the risks (the graphics library is the biggest unknown), attacks that risk first — a small experiment with the library, not the whole game — builds a test version, and reviews it with the stakeholders. The second loop starts from the review: now the risk is smaller, and the next unknown is addressed. The spiral is drawn as a growing curve precisely because each loop widens the area of the project that is understood, while the risk review at each corner decides what the next loop must attack.

3.13.2 The Fountain Model

The fountain model is iterative and allows phases to overlap. The image is a fountain: water rises through the phases, and when it falls back, the cycle repeats at a higher level. Unlike the strict waterfall, the fountain lets analysis, design, and implementation feed one another during a cycle, and it explicitly supports going back up for another pass. The analogy is used to show that phases are not one-shot floors but a repeated cycle.

Key Concept — the fountain image: in a fountain, water rises through the levels and then falls back to the basin, only to rise again. A phase in the fountain model works the same way: the project climbs through analysis, design, and implementation, then "falls back" to an earlier level for another pass with what was learned. The phases are not floors — once you leave a floor in the waterfall you never return; in the fountain you are always returning. That single image captures the whole difference between the two models.

3.13.3 Agile Methods

The agile family puts the customer and working software first: short iterations, small teams, pair programming, and continuous feedback. Extreme programming is the best-known member, with its pair programming practice in which two developers share one task at one machine. Agile methods keep the process light, but the session adds a warning: agile still needs discipline. Skipping steps such as the review or the test pass turns the method into uncontrolled build-and-fix, so the practice only works when the team follows it completely.

Example — the agile iteration: an agile team runs short, fixed-length iterations (commonly one to four weeks). Each iteration opens with a short planning session, includes a daily stand-up meeting where each member reports what they did and what blocks them, and closes with a demo of working software to the customer, whose feedback feeds the next iteration. The team is self-organizing: it decides its own tasks instead of receiving them from a manager. Everything is designed to keep feedback cycles as short as possible — from the customer every iteration, from teammates every day, from the tests every hour.

Pitfall — the discipline warning: agile is not "do whatever feels right, quickly." Pair programming works only if pairs really switch regularly; the review works only if the demo really happens; the tests work only if they really run. Skip the steps and the method quietly decays into build-and-fix — the exact chaos agile was meant to avoid. The practice only works when the team follows it completely.

3.13.4 Choosing a Model

No model is best for every project. The waterfall suits stable, well-understood requirements. The spiral suits risky, high-stakes projects. Agile suits projects where requirements change often and the customer is available. The session closes the comparison by noting that teams should choose deliberately, not by habit, and that mixing models without understanding them usually produces the weaknesses of all of them.

Key Concept — match the model to the project's main risk: the choice of model is really a choice about which failure mode frightens you most. Stable requirements and a known domain? Waterfall's discipline costs little. A big unknown component or a novel technology? The spiral attacks it first. A customer who discovers what they want by using the software? Agile's short feedback loops are built for it. The common mistake is choosing by fashion or habit — or bolting pieces of several models together without understanding why each piece exists. A mix built that way inherits each model's weaknesses and loses each one's strengths; a mix built deliberately, as the unified process does, is a different matter.

Real-world: surveys of agile teams keep reporting that the top cause of failure is not the method itself but abandoning its practices under schedule pressure — the discipline warning from the session, confirmed in the field.

Exam note: know the core idea of each model and the risks each one is meant to control — spiral is risk-driven (attack risk early), fountain is iterative with overlapping phases (water rises and falls back), agile is customer-driven with short feedback loops (and needs discipline).

3.14 The Unified Development Process

The unified development process ties the session together: it is use-case driven, architecture-centric, and iterative and incremental at the same time.

Hook: every model in this session fixed one problem and created another. The waterfall was disciplined but rigid; prototyping was flexible but threw the work away; agile was fast but demanded discipline. The unified process is the attempt to combine the strengths: the discipline of phases, the early attack on risk from the spiral, and the short feedback cycles of iteration — all organized around the UML notation the course has been using.

3.14.1 The Three Amigos and UML

The unified process grew out of the work of Ivar Jacobson, Grady Booch, and James Rumbaugh, who joined forces in the 1990s and unified their methods into one process and one notation, UML. Their collaboration is why the course treats UML and the unified process as a pair: the notation and the process were designed together. The session notes that the three founders' companies and ideas were later folded into larger firms, with IBM among the companies that continued the work.

Key Concept — notation and process designed together: before the Three Amigos, the field had competing methods with competing notations: a diagram drawn in one method meant something slightly different in another. The three men unified their methods — their process ideas and their notation — into one package: the unified process and UML. That is why the course teaches them as a pair: the diagrams of UML are the language, and the unified process is the rhythm of work that produces them. Later the founders' companies were absorbed into larger firms, IBM among them, which is how the notation and process spread into industrial tooling.

3.14.2 Phases of the Unified Process

The unified process organizes work into four phases: inception, elaboration, construction, and transition. Inception scopes the project. Elaboration designs the architecture and handles the risky parts. Construction builds the bulk of the system in iterations. Transition moves the system to the users. The phases are not a waterfall: each phase can run several iterations, and the phases overlap across the project timeline.

Pitfall — not a waterfall with more steps: the phase names make the model look like the waterfall — inception, elaboration, construction, transition sounds like a four-stage sequence. It is not. Each phase runs multiple iterations, the phases overlap in time (construction starts on some parts while elaboration still refines others), and work flows back into earlier phases when the iterations reveal new understanding. The four names describe when the emphasis shifts, not what happens in that window.

3.14.3 Iterations inside Phases

Inside each phase, the team repeats the same mini-process: requirements work, design, implementation, and test, producing a new version of the system at the end of each iteration. A construction phase might run ten iterations, each one delivering working software. This is the iterative and incremental heart of the model, and it is what makes the process able to absorb changing requirements.

Key Concept — the mini-process inside each iteration: every iteration runs the full cycle the session started with — a little requirements work, a little design, implementation, and tests — and ends with a working version. Ten iterations in construction means ten working versions, each built on the last, each reviewed by the customer. This is incremental delivery and iterative refinement joined: the versions grow the system (incremental), and each pass sharpens the understanding (iterative). Requirements that change are absorbed because the next iteration simply plans around them — the process never waits for a perfect, frozen requirements document.

3.14.4 Components and Deployment

The unified process also thinks in components: pieces with well-defined interfaces that can be built, tested, and replaced independently. The deployment view describes where the components run, on which machines, and how they talk over the network. For a small game the deployment view is one machine, but for enterprise systems it is the view that connects the software to the hardware plan. The session ends by saying that a process is only as good as its discipline: the best model fails if the team does not follow its steps.

Example — components and the deployment view: the dice game could be split into two components — the game engine (rules, totals, winner logic) and the interface (displaying the dice and taking the roll command) — with a well-defined interface between them, so the interface can be swapped for a new one without touching the engine. The deployment view then says where each piece runs: for the game, one machine; for an enterprise system, a diagram of servers, databases, and networks, connecting the software plan to the hardware plan. The components are the answer to "how is the system built and replaced?", and the deployment view is the answer to "where does it run?"

Real-world: enterprise teams often adopt a customized version of the unified process, complete with its four phases and iterative construction — the phase names survive in company-specific variants, but the iterative heart is what the teams keep.

Exam note: name the four phases in order — inception, elaboration, construction, transition — and explain why the unified process is both iterative (each phase runs repeated iterations) and incremental (each iteration delivers a working version) and not a waterfall with more steps.

Exam Guidance Summary

The session's examinable skills fall into four groups.

Modeling and analysis skills

• Name the objects of a small game and state the role of each object, as in the dice game.
• Draw a use case diagram with actors, ovals, and the system boundary, and read the scope from it.
• Label any given diagram as static structure or dynamic behavior, and justify the label.

Contracts and requirements

• Define preconditions and postconditions, and write one of each for a given method.
• Count the pairs that sum to seven and write the probability, using the seven game method.
• Name the phases of the life cycle and say what an SRS is used for.

Process models

• Compare build-and-fix, waterfall, and prototyping, naming the advantages and disadvantages of each.
• Distinguish incremental delivery from iterative refinement with one example of each.
• Explain the spiral and fountain models and the risks of agile without discipline.
• Name the four phases of the unified process in order and say why the model is iterative.

How to prepare: for each skill, practice the doing, not just the reading — draw the diagram, write the contract, count the pairs. Every item above is a task the exam can set.

Key Industry Applications

The ideas of this session appear in industry practice in six recurring forms:

• Requirements discipline: the Standish Group CHAOS report is used across industry to justify analysis before coding — project management training still quotes it, decades after the first study.
• Modeling tools: Rational Rose, ArgoUML, StarUML, and Violet are used to draw the UML diagrams of this session in real projects, and modern tool suites continue the same role that the IBM product lines took over.
• Contracting: the SRS is attached to project contracts so that scope changes are tracked formally — a change to the SRS triggers a documented change order with cost implications.
• Prototyping: client-facing teams build throwaway prototypes in hours to settle the requirements before full development — the feedback is kept, the prototype is shelved.
• Process selection: teams choose among waterfall, spiral, agile, and unified-style processes based on project risk and requirement stability — the choice is deliberate, not habitual.
• Process training: the unified process and its phases are still taught and customized in enterprise software training, and the iterative and incremental heart of the model survives in company-specific variants.