CSS Prepare

optional · CSS study notes

🔥 Most Repeated — Software Engineering

CSS Computer Science (Optional) — Paper-I, Section-B, Topic V. This page originally covered only the 2026 paper (Q1–Q4 below). It has since been expanded with confirmed repeated patterns from the CSS Computer Science papers of 2019 through 2025 (Q5–Q12 below), sourced from solved past papers. More patterns will be added as further years are reviewed.

Q1. Why Maintenance Is the Most Expensive SDLC Phase

Appeared: 2026, Q6(a)

Why is Maintenance the most expensive phase of the software lifecycle?

Solution:

Maintenance typically consumes 60–80% of a software system's total lifetime cost — far more than initial development — for several compounding reasons:

  • Longest duration: a system is maintained for years, sometimes decades, after a comparatively short development period.
  • Accumulated complexity: every fix, patch, and feature addition made after release increases the system's complexity and interdependencies, making each subsequent change slower and riskier than the last (a phenomenon sometimes called "software entropy" or "code rot").
  • Undocumented/lost context: the original developers may have moved on; new maintainers must first spend time understanding existing code before they can safely change it.
  • Four types of maintenance, each adding cost: corrective (fixing bugs found in production), adaptive (adjusting to new OS/hardware/regulatory environments), perfective (improving performance or adding requested features), and preventive (refactoring to ease future maintenance) — a mature system incurs all four repeatedly.
  • Regression risk: every change requires re-testing not just the new feature but the surrounding system, since a fix in one place can silently break another.

Exam angle: naming the four maintenance types explicitly (corrective/adaptive/perfective/preventive) is what distinguishes a strong answer from a generic "because bugs are expensive to fix" response.

Q2. Purpose of Use Case Diagrams

Appeared: 2026, Q6(b)

What is the purpose of Use Case Diagrams?

Solution:

A Use Case Diagram is a UML behavioral diagram that captures a system's functional requirements from the end user's perspective, at a high level, without describing internal implementation.

  • Core elements: Actors (stick figures — a user or external system that interacts with the system), Use Cases (ovals — a discrete piece of functionality/goal the actor can achieve), and Associations (lines connecting actors to the use cases they participate in), plus optional <<include>> (a use case always incorporates another) and <<extend>> (a use case optionally extends another under specific conditions) relationships.
  • Purpose:
    • Documents what the system should do, not how — keeps requirements discussions focused on user-visible behavior.
    • Acts as a communication bridge between non-technical stakeholders (who can read the simple diagram) and developers (who translate use cases into detailed specifications).
    • Helps define system scope/boundary early — anything not represented as a use case is (by implication) outside the system.
    • Forms the basis for later test-case design, since each use case typically maps to one or more test scenarios.

Exam angle: contrast this with a Class Diagram (structural, shows classes/attributes/relationships) if the question invites comparison — Use Case Diagrams are explicitly behavioral and requirements-facing, not structural.

Q3. Why Agile Projects Need Frequent Customer Interaction

Appeared: 2026, Q6(c)

Why do Agile projects need frequent customer interaction?

Solution:

Agile development is built around iterative, incremental delivery rather than fixing all requirements upfront (unlike Waterfall) — and that model only works if the customer is available to steer each iteration.

  • Validates direction early: short sprints/iterations deliver working software every few weeks; frequent customer review confirms the team is building the right thing before too much effort is sunk into the wrong direction.
  • Requirements evolve: real-world business needs change during a project; ongoing customer input lets the backlog be re-prioritized each sprint instead of only being discovered "wrong" at final delivery.
  • Reduces the cost of change: catching a misunderstanding after one 2-week sprint costs far less to fix than catching it after a 12-month Waterfall-style delivery.
  • Builds trust and shared ownership: the customer sees continuous, tangible progress (working increments, not just documents), which the Agile Manifesto's principle of "customer collaboration over contract negotiation" specifically emphasizes.
  • Practical mechanisms: sprint reviews/demos, product backlog grooming, and a Product Owner role that represents the customer's priorities daily within the team.

Exam angle: tie the answer back to a named Agile principle or ceremony (Sprint Review, Product Owner, the Agile Manifesto's collaboration value) rather than a vague "because Agile is flexible" — naming the mechanism is what earns full marks.

Q4. Resolving Conflicting Requirements (Security vs Fast Login) and SDLC Impact

Appeared: 2026, Q8(b)

A software team is building an online examination system. During requirements gathering, the client says they want "very strong security," but teachers want "fast login without multiple checks." The development team becomes confused because the requirements conflict. Explain how the team should resolve this conflict using proper Software Engineering techniques. Also describe the impact of wrong requirement handling on the SDLC.

Solution:

Resolving the conflict — Requirements Engineering techniques:

  • Requirements elicitation & stakeholder analysis: identify all stakeholders (client/security-focused administration vs teachers/end-users) and explicitly document that their requirements conflict — do not let it stay implicit.
  • Requirements negotiation/prioritization: use a structured technique (e.g., MoSCoW — Must have / Should have / Could have / Won't have) to rank "strong security" and "fast login" against the system's actual risk profile (an examination system handling grades/identity verification leans toward prioritizing security as a Must-have).
  • Propose a technical compromise rather than picking one side absolutely: e.g., risk-based / adaptive authentication — a single strong check at login (or biometric/SSO) that is fast for the user but still secure, or step-up authentication (extra checks only for high-risk actions like submitting an exam, not for every screen).
  • Document the agreed trade-off formally in the Software Requirements Specification (SRS), with sign-off from both the client and teacher representatives, so it isn't re-litigated later in the project.
  • Prototype and validate: build a quick prototype of the proposed login flow and get feedback from both groups before full implementation, catching remaining disagreement early and cheaply.

Impact of wrong requirement handling on the SDLC:

  • Requirements phase errors are the cheapest to fix at their own stage but the most expensive to fix later — a well-known finding is that a requirements error caught during requirements gathering costs roughly 1x to fix, but the same error caught after deployment can cost 50–200x as much.
  • Design phase: a design built on the wrong/ambiguous requirement must be reworked, wasting the design effort already invested.
  • Implementation phase: code is written against the flawed requirement; developers may implement two incompatible interpretations if the conflict wasn't resolved before coding started.
  • Testing phase: test cases derived from the flawed requirement will "pass" even though the software doesn't actually meet stakeholder needs — defects surface only in User Acceptance Testing (UAT) or after release.
  • Maintenance phase: the conflict resurfaces as a change request after deployment, now requiring the most expensive kind of fix (see Q1 above on why maintenance is the costliest phase).

Exam angle: examiners specifically reward (a) naming a concrete negotiation technique (MoSCoW, stakeholder analysis) rather than vague "communicate better" advice, and (b) explicitly tracing the cost multiplication of an unresolved requirement across each later SDLC phase.

Q5. Verification vs Validation, and Functional vs Non-Functional Requirements

Appeared: 2019 Q7(c) · 2020 Q8(b) · 2021 Q8(b) · 2025 Q7(b) & Q8(a) — the single most repeated Software Engineering pattern across 2019–2025

In the context of a web application, distinguish functional from non-functional requirements, and explain the roles of verification and validation in the requirements engineering process.

Solution:

  • Functional requirements state what the system must do — specific features and behaviors (e.g. "a student can submit an exam answer sheet"). Non-functional requirements constrain how well it does it — performance, security, usability, scalability (e.g. "the system must support 5,000 concurrent students without exceeding 2-second response time").
  • Verification asks "are we building the product right?" — it checks the product against its written specification, typically through reviews, walkthroughs, and static analysis.
  • Validation asks "are we building the right product?" — it checks the product against the customer's actual, real-world need, typically through acceptance testing and demos with real users.
  • A system can pass every verification check and still fail validation — e.g. a login page built exactly to spec, where the spec itself omitted a two-factor authentication requirement the client actually needed.
  • For a web application specifically, non-functional requirements deserve extra weight versus a desktop system: browser compatibility, network latency tolerance, and concurrent-user load are web-specific non-functional concerns worth naming.

Exam angle: examiners reward answers that give one concrete functional AND one concrete non-functional example for the same system, rather than generic textbook definitions — and that explicitly connect verification/validation back to when each happens in the requirements engineering process (elicitation → analysis → specification → validation → management).

Q6. 3-Tier Web Application Architecture

Appeared: 2022 Q7(a), 8 marks · 2025 Q8(c), 8 marks — an almost verbatim repeat, three exam sittings apart

Explain 3-tier web application architecture.

Solution:

  • Presentation tier: the browser/UI layer — everything the user directly sees and interacts with (HTML/CSS/JS rendering, forms, layout).
  • Application (logic) tier: server-side business rules and processing — sits between the UI and the data, enforcing what operations are valid and orchestrating them.
  • Data tier: the database and its data-access logic — where information is persisted and retrieved from.
  • Why 3-tier, not 1-tier or 2-tier: separating these concerns lets each tier be developed, scaled, secured, and replaced independently — e.g. swapping the database engine, or scaling the application tier across multiple servers under load, without touching the presentation layer.
  • A simple diagram — three labeled boxes (Presentation → Application → Data) with bidirectional arrows between adjacent tiers only (presentation never talks directly to data) — earns easy diagram marks and reinforces that each tier only talks to its immediate neighbor.

Exam angle: this exact question has now appeared twice with identical wording and identical mark weight (2022, 2025) — of everything on this syllabus, it is the single highest-confidence "will be asked again" item. Memorize the three tier names, one sentence on each, and the neighbor-only communication rule.

Q7. Black-Box vs White-Box Testing, and QA vs QC vs Testing

Appeared: 2022 Q7(b) · 2024 Q7(b)&(c)

Differentiate black-box testing from white-box testing, describe test design techniques, and distinguish Quality Assurance, Quality Control, and Testing.

Solution:

  • Black-box testing: tests behavior against the specification with no knowledge of internal code — equivalence partitioning, boundary value analysis. Finds missing-functionality and spec-mismatch defects.
  • White-box (glass-box) testing: tests internal logic paths with full knowledge of the source code — statement/branch/path coverage. Finds logic errors black-box testing structurally cannot reach.
  • Neither finds strictly "more" errors in general — the honest answer states it depends on defect type, since each technique is blind to the errors the other is designed to catch.
  • Quality Assurance: process-focused and preventive, applied across the whole SDLC. Quality Control: product-focused, applied to a specific build/release to detect defects in it. Testing: one concrete activity carried out within QC — executing the software to see if a specific case passes.
  • Test design techniques are the umbrella both black-box and white-box methods sit under: equivalence partitioning, boundary value analysis, and decision tables (black-box side); statement, branch, and path coverage (white-box side) — technique choice depends on what class of defect you are trying to catch.

Exam angle: examiners specifically reward keeping QA, QC, and Testing as three distinct answers rather than collapsing them into two or one — this exact three-way split has been asked for directly, not just implied.

Q8. The Spiral Model, and Naming Agile Frameworks

Appeared: 2021 Q7(b), 7 marks · 2023 Q6(c), 6 marks · direct Agile MCQs in 2024 & 2025

Explain the Spiral model of the software process in detail, and briefly describe five Agile software development frameworks.

Solution:

  • Spiral model (Boehm): risk-driven and iterative — each loop cycles through four quadrants: determine objectives/alternatives/constraints → evaluate alternatives and resolve risks → develop and verify the next-level product → plan the next iteration. The spiral widens each pass, reflecting growing cost/completeness. Best suited to large, high-risk, poorly-understood projects, since risk is explicitly analyzed every loop rather than assumed away.
  • Five Agile frameworks, briefly: Scrum (fixed sprints, backlog, daily stand-ups), Extreme Programming/XP (pair programming, TDD, continuous integration), Kanban (visual board, WIP limits, continuous flow), Crystal (scaled by team size/criticality, prioritizes people over process), Lean Software Development (eliminate waste, decide late, deliver fast), or Feature-Driven Development/FDD (organizes work around a prioritized feature list) — name any five with one distinguishing detail each.
  • A strong answer sketches the spiral's four quadrants as a labeled diagram rather than describing it purely in prose.

Exam angle: the 2023 question specifically punished aspirants who only prepared Scrum — "briefly describe five" means breadth across named frameworks matters more than depth on any single one.

Q9. Software Quality Attributes and CMMI

Appeared: 2021 Q7(c), 5 marks · 2025 Part-I MCQ

What is meant by software quality? List at least five quality attributes, and state the main goal of the Capability Maturity Model Integration (CMMI).

Solution:

  • Software quality is the degree to which a system meets both its specified functional/non-functional requirements and the implicit expectations of professional, well-engineered software.
  • Five quality attributes worth naming: Reliability (operates correctly over time), Usability (easy to learn/use), Efficiency (good use of time/memory resources), Maintainability (easy to modify/extend later), Portability (moves to a new environment with limited effort).
  • CMMI's main goal is to enhance the maturity of an organization's software process — quality improvement is a downstream result of that, not the model's stated purpose, and "user experience" is not what CMMI targets at all.
  • CMMI's five maturity levels, in order: Initial (ad hoc) → Managed → Defined → Quantitatively Managed → Optimizing.

Exam angle: the 2025 MCQ specifically distractor-tested "increase software quality" against the correct "enhance maturity of software process" — know CMMI's goal is about the process, with quality as a side effect, not the primary target.

Q10. Aspect-Oriented Software Engineering: Architecture, Motivation, and Vocabulary

Appeared: 2021 Q8(e) · 2023 Q6(a)&(b) — 14 of that question's 20 marks

Discuss the architecture of an aspect-oriented system and the motivation behind aspect-oriented programming.

Solution:

  • Motivation: certain concerns — logging, security, transaction management — cut across many otherwise-unrelated modules ("cross-cutting concerns"). Without AOP, a single conceptual change (e.g. switching logging frameworks) means editing dozens of scattered modules — a maintainability failure ordinary OOP decomposition can't solve.
  • Architecture/vocabulary: a join point is a point in program execution where an aspect can hook in (e.g. a method call); a pointcut is an expression selecting a set of join points; advice is the code that runs at those join points; weaving is the process (compile-time, load-time, or run-time) of merging aspects back into the base program to produce the final system.
  • The result: core business logic stays clean and focused on its actual purpose, while cross-cutting concerns live in one place each (one aspect per concern) instead of being duplicated everywhere they're needed.

Exam angle: this topic has appeared in only 2 of 7 sampled years, but earned 14 of 20 marks in a single question in 2023 — a rarely-tested topic that pays disproportionately well when it appears. Don't skip it for sounding niche; know join point/pointcut/advice/weaving precisely, since mixing up "pointcut" (which selects) and "advice" (which executes) is the most common way marks are lost here.

Q11. Project Planning Phases, PERT Charts, and Cost Estimation

Appeared: 2021 Q7(a) · 2024 Q7(a) · 2025 Q7(a)

Discuss the different planning phases conducted during software project management, including the tasks performed at each stage, and describe the role of a PERT chart in scheduling.

Solution:

  • Project phases: Conception & Initiation (define purpose, confirm feasibility) → Planning (scope, schedule, resources, budget) → Execution (development work per plan) → Monitoring/Performance Tracking (compare actual vs planned progress) → Closure (handover, lessons learned).
  • PERT chart: a network diagram showing task dependencies and the critical path — the longest chain of dependent tasks, which sets the minimum possible project duration. Distinct from a Gantt chart, which shows the calendar timeline rather than dependency structure.
  • COCOMO: estimates development effort (person-months) from estimated code size and project-complexity multipliers — the named cost-estimation model for this syllabus.
  • Tie planning-phase tasks to concrete deliverables per stage: e.g. Planning produces a schedule and budget; Execution produces working increments; Monitoring produces status/variance reports.

Exam angle: 2024 and 2025 both asked variants of "discuss the phases," back to back — this is one of the few SE sub-topics FPSC has repeated in consecutive recent sittings, making it close to guaranteed prep value.

Q12. The Software Process Improvement (SPI) Framework

Appeared: 2025 Q7(c), 8 marks — a new, dedicated emphasis

What is the Software Process Improvement (SPI) framework? Describe its steps and how an organization determines which projects need it.

Solution:

  • SPI is a repeating cycle: measure current process performance → analyse the gap against a target maturity model (typically CMMI) → plan specific process changes → implement them → measure again to confirm the change actually helped.
  • Relationship to CMMI: CMMI (Initial → Managed → Defined → Quantitatively Managed → Optimizing) is the standard benchmark used to assess an organization's maturity before and after an SPI initiative — the two topics should be studied as one pair, not separately.
  • Determining which projects need SPI: look for recurring, avoidable defects across multiple projects (signals a process problem, not a one-off mistake), consistent schedule/budget overruns, and a current CMMI level well below the organization's target.

Exam angle: this is the first year SPI has carried its own dedicated 8-mark sub-question rather than being folded into a general "process improvement" mention — treat it as graduating into a standalone, exam-relevant topic going forward, not a footnote to CMMI.

Frequency Note

Papers reviewed for this topic so far: 2019–2026 (eight sittings). Across that span, three clusters dominate: Requirements Engineering (functional/non-functional, verification/validation) in 5 of 8 years, Testing & SQA-related questions in 5 of 8 years, and Process Models & Agile in 4 of 8 years. The 2026 paper itself drew from three distinct SE areas in one sitting — SDLC/maintenance economics, UML (Use Case Diagrams), and Agile process — plus a scenario-based Requirements Engineering question worth the most marks (8) of the group. Expect a similar spread of "name and justify" theory questions plus one applied scenario question in future papers. See the full concept breakdown starting at P-I.V. Software Engineering for deeper coverage (process models, requirements analysis, design, testing, SQA, project management).

2026 Past Paper MCQs (Part-I)

  1. You are leading an Agile team developing a mobile app. What's the primary focus?

    A) Detailed upfront planning B) Strict adherence to initial requirements C) Both (A) & (B) D) Iterative development and customer feedback

    Why: the defining Agile characteristic, directly opposite to Waterfall's upfront, fixed-plan approach.

  2. A project is behind schedule. What is a likely Agile response?

    A) Add more developers B) Work longer hours C) Both (A) & (B) D) Review scope and priorities with team

    Why: Agile favors re-prioritizing the backlog (dropping/deferring lower-value scope) over "adding more developers" — Brooks's Law warns that adding people to a late project often makes it later still.

  3. A project is using open-source components with security vulnerabilities. What is the risk?

    A) Security breaches or compliance issues B) Non-technical issues C) Open-source issues D) None of these

    Why: unpatched or vulnerable third-party/open-source dependencies are a well-documented major attack vector and can also violate licensing/regulatory compliance requirements.

  4. Which of the following is NOT an agile software development methodology?

    A) Scrum B) Waterfall C) Kanban D) None of these (2024)

    Why: Waterfall is sequential and plan-driven — the opposite of Agile's iterative, adaptive approach.

  5. Which software development model uses iterative cycles and continuous development?

    A) Agile model B) Spiral model C) V-model D) None of these (2025)

    Why: "iterative cycles and continuous development" is Agile's defining signature — Spiral is iterative but risk-driven, not the best fit for "continuous development."

  6. What is the main goal of Capability Maturity Model Integration (CMMI)?

    A) To enhance maturity of software process B) To increase the quality of software C) To provide user friendly experience D) None of these (2025)

    Why: CMMI's stated purpose is process maturity — quality is a downstream result, not the model's direct goal.

  7. What is meant by refactoring code in SDLC?

    A) To modify the functionality of software B) To improve the code quality C) To find out bugs in a software D) None of these (2025)

    Why: refactoring improves internal structure/quality without changing external behavior — it is not a functionality change or a bug-finding activity.

  8. Which type of software testing confirms whether the software is according to the customer's requirements?

    A) Performance testing B) Acceptance testing C) Regression testing D) None of these (2025)

    Why: acceptance testing specifically validates against the customer's actual requirements, distinct from system testing (checks the written spec) or regression testing (checks nothing broke).