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.