optional · CSS study notes
🗄️ OLD — Software Processes and Process Models (consolidated)
CSS Computer Science (Optional) — Paper-I, Section-B, Topic V. Covers two distinct syllabus items: Software Processes and Software Process Models (Agile Software Development gets its own detailed treatment below, since FPSC treats it as a separate syllabus line item).
What a "Software Process" Actually Is
- Software Process: the structured set of activities needed to turn a requirement into a delivered, working system.
- Generic process activities (every model below is just a different arrangement of these four): Specification (what should the system do, and under what constraints), Development (design + implementation), Validation (checking it does what was asked), Evolution (changing it as needs change after delivery).
- Umbrella activities — run throughout the whole project rather than at one stage: SQA, project tracking, risk management, documentation, measurement/metrics. A common trap question asks you to place a given activity into "process" vs "umbrella" — if it happens once, at one stage, it's a process activity; if it happens continuously, it's an umbrella activity.
Process Models
- Waterfall Model: strictly sequential — requirements → design → implementation → testing → deployment → maintenance, one phase completes before the next begins. Simple to manage, but brittle: a late-discovered requirement change is expensive because you must step back through completed phases.
- Incremental Model: builds and delivers the system in usable, functional slices/increments rather than all at once — each increment adds functionality to the previous one.
- RAD (Rapid Application Development): component-based, heavily time-boxed, aims for very fast delivery by reusing existing components and prototyping tools.
- Prototyping: build a partial, working version early to clarify unclear requirements — throwaway prototyping (discard it, build the real system from scratch) vs evolutionary prototyping (refine the prototype itself into the final system).
- Spiral Model (Boehm): iterative and risk-driven — each loop repeats four quadrants: (1) determine objectives/alternatives/constraints, (2) evaluate alternatives and identify/resolve risks, (3) develop and verify the next-level product, (4) plan the next iteration. The spiral widens with each pass, reflecting growing cost and completeness — best for large, high-risk, poorly-understood projects. Be ready to sketch the four-quadrant spiral diagram from memory.
- V-Model: an extension of Waterfall that pairs each development stage with a matching verification/test stage on the way back up (requirements ↔ acceptance testing, design ↔ system testing, etc.) — makes the testing plan explicit from day one instead of leaving it until the end.
| Waterfall | Spiral | Agile | |
|---|---|---|---|
| Structure | Sequential, one pass | Risk-driven loops, widening scope | Short, repeated iterations (sprints) |
| Best for | Fixed, well-understood requirements | Large, high-risk, high-cost projects | Evolving requirements, fast feedback |
| Cost of late change | High | Managed explicitly via risk analysis each loop | Low — change is expected, not exceptional |
| Customer involvement | Front-loaded (requirements phase only) | Reviewed at the end of each loop | Continuous (every sprint) |
🔥
Repeated in past papers: 2021, Q7(b) asked for the Spiral model in detail (7 marks). 2025's Part-I MCQs directly tested "which model uses iterative cycles and continuous development" (Agile). Process-model questions have shown up in 4 of the last 7 available papers (2021, 2023, 2024, 2025) — see 🔥 Most Repeated — Software Engineering for full worked answers.
MCQ Trap
- "Iterative and risk-driven" → Spiral, not Agile. "Iterative and customer-collaborative, short sprints" → Agile. Both are iterative — the exam distinguishes them by why they iterate (risk vs feedback).
Agile Software Development
Agile is its own syllabus line item, not a subtype of "process models" — FPSC has asked aspirants to name and describe multiple frameworks by name, so knowing "Scrum" alone is not enough.
The Agile Manifesto — Four Values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a fixed plan
Frameworks Worth Naming (FPSC has asked for five by name)
- Scrum: fixed-length sprints (1–4 weeks), a Product Backlog, a Scrum Master, a Product Owner, and daily stand-ups.
- Extreme Programming (XP): pair programming, test-driven development (TDD), continuous integration, frequent small releases.
- Kanban: a visual board of work states, explicit work-in-progress (WIP) limits, continuous flow rather than fixed sprints.
- Crystal: a family of methods scaled by team size and project criticality — prioritizes people and communication over rigid process.
- Lean Software Development: adapts Lean manufacturing principles — eliminate waste, amplify learning, decide as late as possible, deliver fast.
- Feature-Driven Development (FDD): organizes work around building a prioritized list of client-valued features, each designed and built in a short iteration.
Why Agile Needs Frequent Customer Interaction
Short iterations only work if the customer is available to steer each one: it validates direction early (before too much effort is sunk into the wrong thing), lets requirements evolve without being treated as "failures" late in the project, and is the mechanism behind the Manifesto's "customer collaboration" value — concretely realized through sprint reviews/demos and a Product Owner role.
🔥
Repeated in past papers: 2023, Q6(c) asked to briefly describe five agile software development frameworks (6 marks) — a question that punishes anyone who only prepared Scrum. 2024 and 2025 both carried a direct Agile MCQ. See 🔥 Most Repeated — Software Engineering for the full "why frequent customer interaction" model answer.
MCQ Trap
- Waterfall is explicitly the wrong answer whenever an MCQ describes "iterative cycles and continuous development" — that phrase is Agile's signature, not Waterfall's.
Evolutionary Model (2017)
Develops software through repeated cycles, producing successively refined, more complete versions with each pass — rather than one single delivery at the end. Combines prototyping with iterative development.
Two Variants
- Exploratory programming: work directly with the customer to explore requirements and deliver a final system — well suited to systems with a small, manageable requirement set, or where a complete spec can't be written upfront (e.g. small e-commerce systems, AI applications).
- Throwaway prototyping: build a prototype purely to understand and validate requirements, then discard it and develop the final system from scratch using those validated requirements.
Advantages / Disadvantages
- Advantages: users see and can react to early working versions; feedback is incorporated while it's still cheap to act on; well suited to poorly-understood or evolving requirements.
- Disadvantages: the process is not visible — there's no fixed set of intermediate deliverables to track progress against; systems often end up poorly structured because continual, unplanned change erodes the original design; requires specialized skills and languages that support rapid change.
MCQ Trap
- Don't confuse with Incremental: Evolutionary repeatedly refines the same evolving version (spiral-like, one system getting better each pass); Incremental delivers a series of separate, complete, usable slices that are added together.
Incremental Model (2017)
Builds the system as a series of increments, or usable "builds," each of which adds functional capability until the system is complete. The first increment is typically a core product with the most basic requirements; each later increment refines and extends it.
How Each Increment Runs
Each increment goes through its own mini-Waterfall — analysis → design → code → test → deliver — applied repeatedly, in a linear sequence of increasingly complete builds.
Advantages / Disadvantages
- Advantages: generates working software quickly; early increments double as testable, usable products; cheaper to accommodate scope/requirement changes than a single-shot delivery; smaller increments are easier to test and debug; customer feedback on one increment can steer the next.
- Disadvantages: needs solid upfront planning and a well-defined overall architecture so later increments fit cleanly into earlier ones; total cost can end up higher than Waterfall if increments aren't planned carefully.
MCQ Trap
- Incremental delivers complete, working slices one after another; Evolutionary keeps refining one evolving version. If a question describes "usable builds added on top of each other," that's Incremental.
Rapid Application Development — RAD (2017)
A linear-sequential process model that emphasizes an extremely short development cycle (typically 60–90 days) using a component-based construction approach.
Phases (James Martin's RAD Model)
Business modeling → Data modeling → Process modeling → Application generation (using 4GLs, reusable components, and code generators rather than writing everything from scratch) → Testing and turnover.
Conditions for Use
Requires a system that can be decomposed into modular functional components/subsystems developable in parallel by separate teams, adequate staffing to run multiple teams at once, and both developers and the customer committed to a rapid, fast-turnaround pace.
Advantages / Disadvantages
- Advantages: very fast delivery; reduced development time through heavy component reuse.
- Disadvantages: not suitable for every application — poor fit when a system resists clean modularization; needs enough human resources to staff the right number of parallel teams; carries real risk if requirements weren't well understood before the fast-tracked build began.
MCQ Trap
- RAD is a complete process model built around speed and reuse — don't confuse it with JAD below, which is only the requirements-gathering technique that often feeds into it.
Joint Application Development — JAD (2017)
A structured requirements-gathering technique that brings business/end users and technical staff together into facilitated workshops ("JAD sessions") to define and clarify requirements collaboratively, in real time — replacing the slow back-and-forth of separate interviews and draft documents.
Roles in a JAD Session
- Facilitator/session leader — runs the workshop and stays neutral between competing stakeholder interests.
- Scribe — records decisions and open issues as they're made.
- Business/end users — represent and explain their actual requirements.
- IT/technical staff — assess feasibility and translate needs into technical terms live.
- Executive sponsor — provides authority to resolve disputes and confirm final decisions.
Why It's Used
Drastically shortens the requirements-gathering timeline compared to protracted individual interviews; surfaces and resolves conflicting stakeholder requirements immediately, in the room, rather than after the fact; increases stakeholder buy-in because users participate directly in shaping the outcome.
Relation to RAD
JAD is frequently used as the requirements-gathering front-end that feeds a RAD-style rapid build — the two are commonly paired in exam questions ("how does JAD support RAD?").
MCQ Trap
- JAD is a requirements-elicitation technique, not a full SDLC model — describing it as "a complete development process" the way RAD is described would be a mistake.
Software Paradigms
The fundamental philosophy used to organize and structure software — distinct from a process model. A process model (Waterfall, Agile, Spiral) is about workflow — the order activities happen in; a paradigm is about how the code and system itself is organized.
The Named Paradigms
- Procedural/Structured: program organized as a sequence of steps, using sequence/selection/iteration, built up from functions/procedures operating on data.
- Object-Oriented: organizes software around objects that bundle data and behavior together — encapsulation, inheritance, polymorphism (see the OOP portion of the syllabus for full depth).
- Functional/Declarative: describes what the program should accomplish rather than how to do it step by step — built on side-effect-free mathematical functions (e.g. Haskell); the declarative family also includes logic programming (e.g. Prolog) and query languages (e.g. SQL).
- Component-Based/Service-Oriented: assembles systems from pre-built, independently deployable components or services rather than writing everything from scratch — the paradigm underlying both RAD and distributed software engineering above.
- Aspect-Oriented: pulls cross-cutting concerns (logging, security, transactions) out into standalone aspects (see the AOSE page for full depth).
MCQ Trap
- A question asking to "name different software development paradigms" wants this list of code-organization philosophies — naming Waterfall, Agile, or Spiral in answer to it confuses a paradigm with a process model, a distinction examiners test deliberately.