CSL308 SE S26

Softw re Process Models

“Which is more dif cult — writing code or deciding what to code?”

Anil Mokh de 17 Feb 2026

The hardest problem in software development is not how to build it.

Writing code is the easiest part of software engineering. It is deciding what exactly to build.
a
a
fi
 A company builds a campus attendance system.
They perfectly implement:
•Biometric authentication
The Core Premise •Reporting
•Admin dashboards
WHAT to build? Everything works technically.
vs But faculty say:
HOW to build? •It doesn’t match real classroom work ows.
•It doesn’t handle guest lectures.
“Software development failures rarely happen because programmers cannot code. •It creates administrative overhead.
They happen because the wrong system was built.”
Technically correct.
Conceptually wrong.
Why?
Because requirement understanding was shallow.

Why “What to Develop?” Is the Toughest Question

Stakeholders Don’t Know What They Want
Requirements Are Often Implicit
Users often say:
•Business rules are undocumented.
•“Make it simple.” •Work ows are informal.
•“Make it fast.” •Exceptions are not described.
•“Make it smart.”
But what does that mean technically?
fl
fl
What is a ‘Workflow’?
A piece of work passed through:
-Sequencing of Industrial, Administrative or other processes
-From initiation to completion
Requirements Change with Understanding
-Helps in understanding of data-dependency
-Removal of flow dependency Once users see a prototype, they say:
-Flexibility “Oh, this is not what I meant.”
-Reusability
-Integration
-Scalability

AI Era Makes It Worse

Now users say:
“Add AI.”
What ‘Deep Insight’ we can draw
But:
•What kind of AI? “Coding errors are visible.
Requirement errors are invisible — until it is too late.”
•What accuracy?
•What risk tolerance?
•What data quality?
 Six Generic SDLC Steps
[Link] Understanding
Classi cation told us: [Link] Analysis
•What kind of system we are building. [Link]
•What risk level it carries. [Link]
But classi cation does NOT automatically de ne: [Link]
•Exact system boundaries. [Link] & Maintenance The rst two steps determine the quality of
all the remaining four.
•Detailed functionality.
If requirement understanding is weak:
•Non-functional constraints.
•Stakeholder expectations. •Design is misaligned.
That is requirement understanding.
•Coding solves wrong problem.
•Testing validates wrong functionality.
•Maintenance becomes chaotic.

Before we discuss how to build software through different process models,

we must rst accept that de ning what to build is the most intellectually demanding
part of software engineering.
Conceptual Clari cation (Very Important)
Requirement Understanding ≠ Requirement Documentation
Requirement Understanding means:
•Understanding problem context. Process models exist to structure and control this dif cult
•Understanding stakeholders. activity of requirement discovery.
•Understanding constraints.
•Understanding risks.
•Understanding environment.
It is about problem framing. The cost of building the wrong system correctly is higher
than building the right system slowly.
fi
fi
fi
fi
fi
fi
fi
 Story: The Shortcut

A startup hired two fresh engineering teams.

Both teams were given software projects.
Final Insight
Team 1 was asked to build a movie ticket booking app.
In today’s AI world, where tools can generate code instantly: Team 2 was asked to build software for a blood pressure monitoring device.
The true engineering skill is: Both teams were smart.
•Asking precise questions Both teams knew the latest tech stack.
•Identifying ambiguity Both teams said:
•De ning constraints “Let’s move fast. We will improve later.”
•Clarifying objectives Team 1 launched in 2 weeks.
Not typing syntax. Some bugs appeared.
Users complained.
They patched it in the next release.
Structured thinking under uncertainty. Business continued.

What was the difference?

•Risk?
Team 2 also rushed. •Impact?
During eld testing, the device sometimes delayed sending alerts. •Consequences?
The software did not crash. •Safety?
It just delayed by a few seconds. Both were software.
Both were coded in similar languages.
But those few seconds mattered. But the consequences of failure were completely different, weren't it?
The project was stopped.
Investors withdrew.
The hospital refused certi cation. That difference changes how we should build the system.
Last topic we classi ed software systems.
Now, we will see why different systems require different development discipline.
That discipline is de ned by software process models.
fi
fi
fi
fi
fi
Both were software. But the consequences of failure were different. Why Risk Should Come Before Process Models
We have already learntt:
We will now understand why classi cation alone is not enough. Classi cation of software systems
Now students understand:
Food App •Embedded systems
ICU Device •Transaction systems
AI Loan System
•AI systems
If this fails, what happens(consequences), we now know.
•SoS systems
The difference in consequences is called risk.
At this moment, they are ready to ask:
Risk = Probability × Impact
Why can’t we use the same development approach for all?
Different system types carry different levels of risk.
That question opens the door to risk.
Because:
Different systems → Different consequences of failure → Different risks
So risk becomes the bridge.

From Classi cation to Risk

“If this embedded system fails, what happens?”
“If this food delivery app fails, what happens?”
“If this AI loan system fails, what happens?” From Risk to Process
What are your answers: So, if we say:
•Annoyance? “If risk levels differ, should development discipline differ?”
•Financial loss? This is where the Software Processes come in:
•Safety hazard? “Software process models are structured ways of managing risk and uncertainty.”
•Ethical damage? Do process models make sense?
Can we then say:
Failure Impact = Risk?
Do we realize the need for discipline?
fi
fi
fi
 Why Not Start With Formal Risk-Driven Theory?
“Today we study Waterfall, V-Model, Spiral…”
If we immediately start with:
“Risk-driven development, Barry Boehm…”
•Another theoretical topic?
It becomes abstract.
•Just exam content?
Better approach:
•Sequence of steps to memorize?
Let us discover risk intuitively through consequences.
Let us understand why process models exist.
Then formalize it.

The Correct Order

Classi cation
“If risk levels differ, should our development discipline be the same?” ↓
No. Failure Consequences
↓
System Type → Risk Level → Required Discipline Risk Awareness
↓
Need for Structured Approach
We need a structured way to manage that discipline. ↓
Process Models
“That structured discipline is called a software process model.” ↓
Risk-Driven Model (Spiral) as special case
This sequence builds conceptual clarity.
fi
 “Process model de nes how we will discover, re ne, validate, and
Process model is not the next engineering step after classi cation. control requirements.”
It is not: Let us see the analogy:
Classi cation → Choose Process → Then De ne Requirements. “Process model is like the rules of a scienti c experiment.
Instead…” Requirements are what we discover during that experiment.”
Process Model
= Framework for “This means requirements engineering happens inside the process
Requirement Discovery & Risk Control model.”
This is the conceptual correction.

How Different Processes Handle Requirements Differently

Let us introduce process models brie y but through the lens of requirements. V-Model
Assumption: Requirements System System Detailed
specification specification design design

🔹 Waterfall Failure cost is high.

Requirements

Assumption:
definition
Approach: Acceptance
System Sub-system Module and
integration integration unit code

Requirements are stable. System and

software design
•De ne requirements carefully. test plan
test plan test plan and test

Approach:
Implementation
•Plan testing alongside requirements. Service
Acceptance System Sub-system

•De ne requirements fully upfront. and unit testing

•Strong veri cation. test integration test integration test

•Freeze them. Integration and

system testing

•Proceed sequentially. Operation and

“Used when safety risk is high.”
maintenance

“This works when uncertainty is low.”

fi
fi
fi
fi
fi
fl
fi
fi
 Agile
Assumption:
Requirements evolve. Spiral (Risk-Driven)
Approach: Barry Boehm
•Discover requirements incrementally. Assumption:
•Continuous user feedback. Major risks exist.
“This works when uncertainty is high Approach:
but failure impact is moderate.”
•Identify biggest risk.
Concurrent
activities
•Prototype to reduce it.
Specification
Initial
•Re ne requirements based on
version
learning.
Outline Intermediate “Here risk directly shapes
description Development versions
requirement understanding.”
Final
Validation version

AI Era Clari cation

“In AI systems, requirements are not just functional.
They include:
•Accuracy threshold
•Bias limits Where Risk-Driven Approach Comes In
•Data quality We have seen Waterfall and V-model brie y, now can we say:
•Monitoring needs.” “These models assume requirements stability?”
Thus process must allow: The Spiral Model by
•Iteration Barry Boehm
•Validation Spiral explicitly organizes development around identifying and reducing risks.
•Monitoring The spiral model is like evolution, not just another diagram.
•Re nement
Traditional: Requirements → Build
AI Systems: Requirements ↔ Data ↔ Model ↔ Validation (loop)
“In AI systems, requirements may evolve after deployment.”
fi
fi
fi
fl
 System Type
→ Failure Impact
→ Risk Level “Different systems fail differently.
→ Required Discipline And when failure consequences change, development discipline must change.”
→ Process Model
This creates logical coherence.

What Is a Risk-Driven Approach?

A risk-driven approach means:
We organize software development activities based on identifying and reducing the highest
risks rst.
Instead of asking: Simple Classroom De nition
•“What should we build next?” A risk-driven process prioritizes solving the most dangerous uncertainties before
We ask: investing heavily in full development.
•“What can go wrong?”
•“What uncertainty can damage this project?”
•“What failure would be most costly?”
Then we design the development plan around reducing those risks early.
fi
fi
What Is “Risk” in Software Engineering?
Risk = Probability of failure × Impact of failure
Types of risk: Where Did Risk-Driven Thinking Come From?
[Link] risk (Will this technology work?) The Spiral Model by
Barry Boehm
[Link] risk (Do we really understand the problem?)
introduced risk as the central organizing principle of development.
[Link] risk (Can we nish on time?)
Unlike Waterfall (sequence-driven),
[Link] risk (Will it scale?) Spiral is risk-driven.
[Link] risk (Can it cause harm?)
[Link] risk (Bias, drift, unpredictability)

How Is It Different From Traditional Approach?

Risk-Driven
Traditional (Activity-Driven)
Identify Risk → Prototype/Test → Reduce Risk → Then Continue
Requirements → Design → Code → Test
The order depends on uncertainty.
Activities are xed in order.
fi
fi
 Example 1 (Simple UG-Level Example) Example 2 (AI System)
You are building a campus payment system. You are building AI for loan approval.
Biggest risk? Biggest risk?
Security breach. Model bias & incorrect decisions.
Risk-driven approach: Risk-driven approach:
•First test authentication & encryption. •First evaluate training data.
•Perform security prototype. •Prototype model.
•Conduct threat modeling. •Test fairness.
•Then build full features. •Validate on unseen data.
Not the other way around. •Then deploy.

Examples of Common Project, Product, and Business Risks

Example 3 (Embedded System) •Staff Turnover

You are building real-time traf c signal controller. •Management Change
Biggest risk? •Hardware Unavailability
Timing failure. •Requirement Change
•Specification Delays
Risk-driven approach:
•Size Underestimated
•Test real-time constraints rst. •CASE Tool underperformance
•Validate hardware integration. •Technology Change
•Then build UI dashboard later. •Product Competition
fi
fi
 Why Risk-Driven Approach Is Important Today
Because systems today are:
•Large Strategy A:
•Distributed Build everything → Then test.
•AI-enabled Strategy B:
•Highly interconnected (System-of-Systems) Find biggest danger → Solve it rst → Then build rest.
Failure cost is high.
Ignoring risk leads to: Which one is more intelligent?
•Technical debt
•System instability That is risk-driven thinking.
•Ethical failure
•Legal liability

Concept
Risk = uncertainty with potential loss.
Strategy
Development sequence is organized around reducing highest risks rst.
Operation
“Good engineers don’t just build features.
Activities include:
They eliminate dangers early.”
•Prototyping
•Simulation
•Proof-of-concept
•Early validation
•Iterative review

fi
In AI Era
Risk-driven approach becomes even more important because:
•AI systems behave probabilistically. Risk-driven development means structuring the software process around
•Failures are often silent. identifying, analyzing, and mitigating the most critical risks early in the
•Bias can cause social harm. lifecycle.
•Model drift can degrade performance.
So iterative validation and monitoring are forms of risk control.

Where Does Process Model Sit in the Big Picture?

simpli ed hierarchy: How Process Model Helps in De ning the Problem
Problem Context This is the key answer to this question.
↓
System Classi cation Process models in uence:
↓ [Link] requirements are elicited
Risk & Uncertainty Assessment [Link] uncertainty is handled
↓ [Link] stakeholders are involved
Process Model Selection [Link] validation happens
↓
Requirements Engineering (within that model) [Link] risk is reduced
Notice: Let us examine concretely.
Process model shapes how requirements are handled.
fi
fi
fl
fi
 Example 2: Spiral Model
(Barry Boehm)
Example 1: Waterfall Model
Spiral assumes:
If you adopt Waterfall:
•You assume requirements are stable. •Requirements are uncertain.
•You attempt complete requirement speci cation upfront. •Risks are high.
•You emphasize documentation. •Prototyping is necessary.
So the process encourages:
•You minimize requirement changes later. •Iterative problem re nement.
So the process model forces:
Clear, stable, well-documented problem de nition early.
•Risk-based requirement discovery.
Thus process model shapes problem framing strategy.
•Early validation through prototypes.
Here, the process explicitly acknowledges that:
The problem is not fully understood initially.

In AI-Based Systems
This becomes even more important.
AI systems often have:
Example 3: Agile •Unclear performance boundaries.
Agile assumes: •Data uncertainty.
•Requirements evolve. •Ethical concerns.
•Users learn as system evolves. •Unknown failure modes.
So requirement de nition becomes: If you choose Waterfall blindly:
•Incremental •You may freeze requirements prematurely.
•User-feedback driven •You may ignore model uncertainty.
•Adaptive If you choose iterative + MLOps:
Thus the process model determines how we de ne and re ne the problem. •You incorporate validation loops.
•You continuously re ne problem understanding.
Thus process model determines:
How we manage ambiguity in the problem.
fi
fi
fi
fi
fi
fi
 What Is a Prototype? (Simple De nition)

A prototype is a preliminary version of a system built to explore,

“Would you build a bridge rst and test whether it stands… validate, or reduce uncertainty before full-scale development.
or test a small model rst?” Underline:
Explore. Validate. Reduce Uncertainty.
Prototype is not primarily for coding practice.
It is for learning.

“Prototype is a learning instrument, not a

Where Prototype Fits in Software
production system.”
Process
In Waterfall:
Why Prototype Appears in Process Discussion Why This Matters in AI Era
•Rare
When do we prototype? •Usually before requirement freeze Because AI tools now allow:
•When requirements are unclear In Agile: •Rapid prototyping
•When risk is high •Frequent •Code generation instantly
•When technology is new •Small increments •Model experimentation quickly
•When stakeholders cannot visualize the system In Spiral: So engineers must learn:
•When AI model performance is uncertain •Core mechanism •When to prototype
So prototype is a risk-reduction tool. In AI: •What to prototype
•Almost mandatory •What risk they are trying to reduce
Otherwise they just generate random systems.
fi
fi
fi
 Throwaway Prototype
Purpose:
In AI Systems (Very Important Today)
• Understand requirements
• Get user feedback Prototype becomes even more critical
because:
• Explore idea Evolutionary
After learning, it is discarded.
Prototype •We don’t know model accuracy
Purpose: beforehand.
Example:
• UI mockup • Start small •Data quality is uncertain.
• Early AI model experiment • Gradually re ne •Performance may vary. “Whenever uncertainty is high, prototyping becomes intelligent.
In Risk-Driven Process (Spiral) • Eventually become •Bias must be checked. Whenever risk is high, prototyping becomes necessary.”
nal system
Mention brie y: So AI projects often begin with:
Used often in Agile and
Barry Boehm AI development. •Proof-of-concept model
Spiral model uses prototyping to: •Small dataset experiment
• Identify major risk •Feasibility validation
• Build prototype to reduce it That is prototyping.
• Evaluate
• Move forward
So prototype is central to risk-driven development.

Conceptual Clari cation (Very Important)

Students often think:
Requirements → then process → then development.
Concept
Actually:
Process model = structured approach to managing uncertainty, change, and risk in
Process model is the meta-structure that governs how requirements evolve.
software development.
Think of it this way:
Requirements are content.
Process is the container.
Without container, content spills everywhere.
fi
fi
fl
fi
 Strategy
Different system types demand different strategies:
Operation
Stable, regulated system → structured upfront requirement strategy (Waterfall/V-model)
Operationally, process determines:
Uncertain, evolving system → iterative requirement discovery (Spiral/Agile)
•When requirements are frozen.
AI-driven system → continuous validation and retraining (MLOps)
•How changes are handled.
Thus process model in uences:
•How validation is performed.
•Requirement completeness •How feedback loops are integrated.
•Stakeholder involvement
•Risk control

Analogy
Let us reaf rm: Key Insight
The process model is like the rules of a scienti c experiment. Process model does not de ne the problem.
Requirements are like hypotheses. It de nes how rigorously and adaptively we discover the problem.
Without experimental design, hypotheses remain vague. That is the subtle but critical distinction.
Process gives structure to discovery.
fi
fi
fl
fi
fi
In Today’s AI World
AI makes problems more ambiguous.
Conclusion
Therefore:
“Process models are not about coding order.
•Iterative validation becomes essential. They are about managing uncertainty in understanding the problem.”
•Risk-driven thinking becomes central. This sentence alone clari es everything.
•Continuous monitoring becomes part of problem de nition.
Thus process models are more important today, not less.

Thank You
fi