8. Software Engineering — Computer Science | CSS Solved Past Papers

FPSC CSS Computer Science past papers (2016–2026) — 51 questions: 8 MCQs, 43 subjective parts. Newest first.

Part A — Subjective Questions

2026 · Paper-I · Q6(a) (6 marks)

Question

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

Solution

Software maintenance is typically the longest and costliest phase of the SDLC (often cited as consuming 60-80% of total lifecycle cost) for several reasons:

Duration: maintenance continues for the entire operational lifetime of the software (years, sometimes decades) after a comparatively short development phase, so costs accumulate over a much longer period.
Accumulated complexity: as fixes and enhancements are layered onto existing code over years by different developers (some unfamiliar with the original design), the system's complexity grows, making each subsequent change slower, riskier, and more expensive to implement and test safely.
Types of maintenance: corrective (fixing bugs found in production, often urgent/costly), adaptive (adjusting to new OS/hardware/regulatory environments), perfective (adding new features/improving performance as user needs evolve), and preventive (refactoring to ease future maintenance) — all of these keep generating ongoing cost throughout the software's life.
Regression risk: every change to a live, in-use system risks breaking existing functionality, requiring extensive regression testing, which is expensive and slows delivery.
Documentation/knowledge gaps: original developers may leave the project, and poor or outdated documentation makes understanding legacy code time-consuming, further inflating the cost of even small changes.

Because of this, many software engineering effort/cost-estimation studies (e.g., in Pressman's and Sommerville's texts) consistently show maintenance dominating total lifecycle cost far more than the initial design and coding phases combined.

2026 · Paper-I · Q6(b) (6 marks)

Question

What is the purpose of Use Case Diagrams?

Solution

A Use Case Diagram is a behavioural UML diagram that captures the functional requirements of a system from the end-user's perspective, showing WHAT the system does without describing HOW it is implemented internally.

Its main components are actors (external entities — users or other systems — that interact with the system, drawn as stick figures), use cases (specific pieces of functionality or goals the system provides, drawn as ovals), and the system boundary (a box enclosing all use cases). Relationships such as association (actor performs a use case), include (one use case always invokes another), extend (a use case optionally extends another under certain conditions), and generalization (an actor/use case specializes another) are used to structure these interactions.

Purpose:

Communicates system scope and functional requirements clearly to both technical and non-technical stakeholders (customers, business analysts, developers, testers) early in the project, without needing programming knowledge to understand it.
Serves as a basis for further, more detailed design artefacts (e.g., sequence diagrams, class diagrams) and for deriving test cases (each use case often maps directly to one or more acceptance test scenarios).
Helps identify all the actors and their required interactions with the system, ensuring no important functional requirement is missed during requirements analysis.

2026 · Paper-I · Q6(c) (8 marks)

Question

Why do Agile projects need frequent customer interaction?

Solution

Agile development is built around iterative, incremental delivery of working software in short cycles (sprints), and frequent customer interaction is essential to make this model work effectively, for several reasons:

Validating requirements continuously: unlike the Waterfall model, Agile assumes requirements are not fully known or fixed upfront and will evolve; regular customer feedback at the end of each sprint (sprint reviews/demos) confirms whether the delivered increment actually matches what the customer needs, catching misunderstandings early rather than at the very end of the project.
Embracing changing requirements: one of Agile's core principles is 'welcome changing requirements, even late in development'; this is only feasible if the customer stays engaged throughout, continually re-prioritizing the product backlog based on evolving business needs.
Reducing risk of building the wrong product: without frequent check-ins, a team could spend months building features the customer no longer needs or misunderstood requirements for — frequent interaction (e.g., daily availability of a Product Owner, sprint reviews, backlog grooming sessions) catches this quickly, since each sprint is short.
Maintaining alignment and trust: ongoing collaboration keeps the customer's priorities and the team's implementation in sync, ensures the highest-value features are built first, and builds stakeholder confidence through visible, incremental progress instead of a single, high-risk, big-bang delivery at the very end.

2026 · Paper-I · Q8(b) (6 marks)

Question

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 using proper requirement engineering techniques:

Requirements elicitation and stakeholder negotiation: bring both stakeholder groups (the client demanding strong security and the teachers wanting fast login) together in a joint requirements workshop to make each side's underlying concerns explicit — the client's real goal is likely preventing cheating/impersonation and unauthorized access, while teachers' real goal is convenience and not wasting class time.
Requirements prioritization (e.g., MoSCoW — Must have, Should have, Could have, Won't have): classify security as a 'Must have' non-functional requirement (given it is an exam system, integrity of results is critical), while treating login speed as a 'Should have' that must be satisfied WITHIN the security constraint, not instead of it.
Propose a balanced technical compromise: e.g., use single sign-on (SSO) integrated with the institution's existing credentials so teachers log in quickly with one already-trusted step, combined with strong security enforced transparently in the background (session tokens, encrypted communication, device/IP monitoring, and multi-factor authentication reserved only for sensitive actions like starting/grading an exam) — satisfying both groups without literally contradicting either.
Requirements validation: document the agreed compromise as a formal Software Requirements Specification (SRS), and have both the client and teacher representatives review and sign off on it, ensuring the conflict is explicitly resolved and recorded rather than left ambiguous.

Impact of wrong requirement handling on the SDLC: requirements form the foundation of every later phase — design, coding, testing, deployment. If a requirement conflict like this is not properly resolved upfront, the team may build inconsistent or partially-contradictory features, leading to expensive rework once the mismatch is discovered late (rework cost grows exponentially the later a requirement defect is caught, per the well-known cost-of-change curve). It can also cause missed deadlines, budget overruns, stakeholder dissatisfaction/disputes over what was 'promised', increased testing/defect rates from ambiguous acceptance criteria, and in the worst case, a delivered system that satisfies neither stakeholder group and must be substantially redesigned after deployment.

2025 · Paper-I · Q7(a) (6 marks)

Question

A project management involves different types of planning stages to finalize the project. Discuss the different types of planning phases conducted during software development with list of specific tasks performed during each planning stage.

Solution

Software project planning typically covers several sub-plans, each addressing a different concern:

Scope planning: define project objectives, deliverables and boundaries; create a Work Breakdown Structure (WBS) decomposing the project into manageable tasks.
Schedule/time planning: estimate task durations, sequence tasks, build a timeline (e.g., Gantt chart, critical path analysis), and set milestones.
Resource planning: identify and allocate human resources, hardware, software and tools needed; assign roles and responsibilities to team members.
Cost/budget planning: estimate development cost using models such as COCOMO or function-point analysis, and prepare and monitor the project budget.
Risk management planning: identify potential risks (technical, schedule, resource), assess their probability/impact, and define mitigation and contingency strategies.
Quality planning: define quality standards, review/testing strategies, and metrics to be tracked (e.g., defect density).
Communication planning: establish reporting structure, meeting schedules, and stakeholder communication channels.

Together these planning phases produce the Software Project Management Plan (SPMP), which guides execution, monitoring and control of the project throughout the SDLC.

2025 · Paper-I · Q7(b) (6 marks)

Question

Illustrate the difference between software validation and software verification testing techniques. Give examples to strengthen your answer. Clearly elaborate the case where each type of technique should be used.

Solution

Verification asks "Are we building the product right?" — it checks that the software conforms to its specifications/design at each development stage, usually through static techniques such as reviews, walkthroughs, inspections and static analysis, without executing the code. Example: reviewing a requirements document against the design document, or a code walkthrough checking that a sorting module matches its design spec.

Validation asks "Are we building the right product?" — it checks that the finished software actually meets the user's real needs and intended use, typically through dynamic techniques that execute the software, such as unit testing, integration testing, system testing and user acceptance testing. Example: running the completed system with real user scenarios to confirm it solves the customer's business problem.

When to use each: Verification should be applied continuously throughout development — after requirements, design and coding — to catch defects early and cheaply (defects found early cost far less to fix). Validation is applied once executable components/the complete system exist, especially before delivery/release, to confirm that the product actually satisfies stakeholder expectations, not just written specifications (a system can perfectly satisfy a wrong specification — verification alone would not catch that, only validation with real users would).

2025 · Paper-I · Q7(c) (8 marks)

Question

What is the Software Process Improvement (SPI) framework? Highlight the different steps of SPI framework and the key elements involved. Also provide the description of the models used within SPI framework and how to determine the projects for which SPI framework should be used.

Solution

Software Process Improvement (SPI) is a structured, continuous approach for assessing and improving how an organization develops software, aiming at higher quality, lower cost, and shorter cycle time by refining processes rather than just individual projects.

Steps (commonly following the IDEAL model):

Initiating — set improvement goals aligned with business objectives and secure management sponsorship.
Diagnosing — assess the current process (e.g., via a CMMI appraisal or SPICE assessment) to identify strengths/weaknesses.
Establishing — prioritize findings and build a concrete improvement action plan.
Acting — pilot and roll out the new/improved practices across the organization.
Learning — measure results, capture lessons learned, and feed them back into the next improvement cycle.

Key elements: process assessment, measurement/metrics, defined process standards, training, and management commitment.

Models used within SPI: CMMI (Capability Maturity Model Integration) — defines five maturity levels (Initial, Managed, Defined, Quantitatively Managed, Optimizing); ISO/IEC 15504 (SPICE) — an international standard for process assessment; Six Sigma — a statistical, defect-reduction-driven improvement approach; ISO 9001 — a general quality-management-system standard applicable to software organizations.

Determining where SPI applies: SPI is worth applying to organizations/projects that show recurring problems such as frequent schedule/cost overruns, high defect rates, inconsistent quality across projects, or difficulty scaling as team size grows — i.e., where the root cause is the process itself rather than a one-off project issue. Small, one-time projects with no repeat business rarely justify the overhead of a full SPI program.

2024 · Paper-I · Q7(a) (6 marks)

Question

Discuss the phases of project management including conception and initiation, project planning, project execution, performance/monitoring, and project close.

Solution

Conception and Initiation: the project idea is proposed and evaluated for feasibility/value; a project charter is created defining objectives, scope, and key stakeholders, and a decision is made whether to proceed.
Project Planning: detailed plans are developed covering scope (Work Breakdown Structure), schedule (timelines/milestones), budget/resources, risk management, quality standards, and communication plans - producing the roadmap the team will follow.
Project Execution: the team carries out the planned tasks, produces deliverables, coordinates resources, and manages stakeholder communication as the actual work of the project is performed.
Performance/Monitoring: progress is continuously tracked against the plan using KPIs, budget/schedule variance analysis, and quality checks; changes are managed through a formal change-control process, and corrective actions are taken as needed (this phase typically runs in parallel with execution).
Project Close: final deliverables are handed over to the customer/stakeholders, contracts are closed, project documentation is finalized, resources are released, and a post-project review captures lessons learned for future projects.

2024 · Paper-I · Q7(b) (6 marks)

Question

What are the different types of test design techniques? When would you use these types of test design techniques?

Solution

Black-box techniques (based on requirements/specification, no knowledge of internal code needed): equivalence partitioning (dividing inputs into classes expected to behave similarly), boundary value analysis (testing at the edges of input ranges, where defects commonly occur), decision table testing (for complex combinations of conditions), and state transition testing (for systems with defined states/events). Used when testing from a functional/user perspective, or when testers do not have (or should not rely on) source code access.
White-box techniques (based on internal code structure): statement coverage, branch/decision coverage, condition coverage, and path coverage. Used during unit testing by developers who have full visibility into the code, to ensure thorough exercising of all logic paths.
Experience-based techniques: exploratory testing and error guessing, where the tester uses domain knowledge and past experience of common defect patterns. Used when specifications are incomplete/ambiguous, for exploratory/ad hoc coverage, or as a supplement to systematic techniques.

2024 · Paper-I · Q7(c) (8 marks)

Question

Exemplify the difference between Quality Assurance, Quality Control, and Testing?

Solution

Quality Assurance (QA) is process-oriented and proactive: it focuses on defining and improving the development PROCESS itself (standards, guidelines, audits, process reviews) to prevent defects from being introduced in the first place - answering "are we following the right process to build the product correctly?" Example: establishing a mandatory code-review checklist and coding standards for all developers.

Quality Control (QC) is product-oriented and reactive: it focuses on evaluating the actual DELIVERABLE (code, documents, builds) to identify defects that have already occurred, through inspections, reviews, and walkthroughs of work products. Example: a peer conducting a code review of a completed module to check it against the coding standards.

Testing is a specific ACTIVITY within QC: actually executing the software (or parts of it) with prepared test cases to observe its behavior and detect defects. Example: running a suite of test cases against the login feature to verify it accepts valid credentials and rejects invalid ones.

In short: QA improves the process to prevent defects, QC inspects the product to find defects that occurred, and Testing is the concrete technique of running the software to uncover those defects - testing is essentially a subset of QC activities.

2023 · Paper-I · Q6(a) (8 marks)

Question

Discuss the architecture of aspect-oriented system.

Solution

An aspect-oriented system architecture separates a program into two categories of concerns:

Core (business logic) concerns: implemented as ordinary classes/components/modules, containing the primary functional logic of the application.
Cross-cutting concerns: behaviors that would otherwise be scattered across many core modules (e.g., logging, security/authorization, transaction management, error handling) are instead modularized separately into aspects.

An aspect is defined using: join points (well-defined points in the program's execution where an aspect can be inserted, e.g., a method call or exception), pointcuts (expressions that select a set of join points, e.g., "all methods in package X"), and advice (the actual code to run at those join points - before, after, or around them).

These aspects are combined with the core modules by a weaver, either at compile time, class-load time, or run time, producing the final executable system in which the cross-cutting behavior appears to be interwoven throughout the base code, without the base code itself containing that logic explicitly. This architecture keeps core business logic clean while still consistently applying cross-cutting behavior application-wide.

2023 · Paper-I · Q6(b) (6 marks)

Question

Briefly discuss the motivation for aspect-oriented programming.

Solution

In traditional object-oriented programming, certain concerns - such as logging, security checks, transaction management, caching, or error handling - cut across many unrelated classes/modules rather than belonging naturally to any single one. Implementing them conventionally leads to two problems: code scattering (the same logic is duplicated across many modules) and code tangling (a module's core logic gets mixed together with unrelated cross-cutting logic, making it harder to read and maintain).

Aspect-Oriented Programming (AOP) was motivated by the need to solve this: by allowing cross-cutting concerns to be captured and modularized separately as "aspects" and then automatically woven into the appropriate places in the base code, AOP improves separation of concerns, reduces code duplication, and makes the core business logic easier to understand and maintain, since it no longer needs to explicitly handle concerns unrelated to its primary responsibility.

2023 · Paper-I · Q6(c) (6 marks)

Question

Briefly describe 05 agile software development frameworks.

Solution

Scrum: organizes work into fixed-length iterations called sprints (typically 2-4 weeks), with defined roles (Product Owner, Scrum Master, Development Team) and ceremonies (sprint planning, daily stand-up, sprint review, retrospective).
Kanban: a visual workflow-management method using a board with columns (e.g., To Do, In Progress, Done) and work-in-progress limits, focusing on continuous delivery rather than fixed-length sprints.
Extreme Programming (XP): emphasizes engineering practices like test-driven development, pair programming, continuous integration, and frequent small releases to improve software quality and responsiveness to changing requirements.
Lean Software Development: adapts lean manufacturing principles to software - eliminate waste, amplify learning, deliver as fast as possible, and empower the team.
Feature-Driven Development (FDD): organizes development around building and designing features in short iterations, driven by an overall model, with defined feature lists and regular builds.

(Other valid examples: Crystal, Dynamic Systems Development Method (DSDM).)

2023 · Paper-II · Q8(b) (8 marks)

Question

Suppose your web team is going to make a contract with the customer and you need to estimate the cost of application development. What pricing factors you consider to estimate the cost?

Solution

Key factors to consider when estimating web application development cost:

Project scope and complexity: number and complexity of features/modules required.
Number of pages/screens and UI/UX design complexity (custom design vs template-based).
Technology stack chosen (licensing costs, developer availability/rates for that stack).
Team composition, size, and skill level/experience (senior developers command higher rates).
Timeline/deadline: tighter deadlines often require more resources, increasing cost.
Third-party integrations (payment gateways, APIs, external services) and their licensing/integration effort.
Testing and quality assurance effort required.
Hosting/infrastructure and ongoing maintenance/support costs after launch.
Geographic location of the development team (labor cost varies significantly by region).
Risk buffer/contingency for scope changes or unforeseen technical challenges.

2022 · Paper-I · Q7(a) (8 marks)

Question

The following function performs binary search on a given array of n numbers:

int binarySearch (int x, int v[], int n)

{

int low, high, mid;

low = 0;

high = n - 1;

while (low <= high)

{

mid = (low + high )/2;

if (x < v[mid])

high = mid - 1;

else if (x > v[mid])

low = mid + 1 ;

else return mid;

}

return -1;

} Draw control flow graph for the above function. Also find its cyclomatic complexity.

Solution

Control flow graph (nodes = basic blocks, edges = control transfers):

N1: lines 4-5 (low=0; high=n-1;)
N2: line 6, while condition (low<=high)
N3: line 8, mid=(low+high)/2
N4: line 9, if (x<v[mid])
N5: line 10, high=mid-1
N6: line 11, else-if (x>v[mid])
N7: line 12, low=mid+1
N8: line 13, return mid
N9: line 15, return -1 (exit)

Edges: N1->N2; N2->N3 (loop true); N2->N9 (loop false); N3->N4; N4->N5 (true branch); N4->N6 (false branch); N5->N2 (back edge); N6->N7 (true branch); N6->N8 (false branch); N7->N2 (back edge).

This graph has 3 decision (predicate) nodes: the while condition, the if condition, and the else-if condition. Using the formula V(G) = P + 1, where P is the number of predicate nodes: V(G) = 3 + 1 = 4.

(Equivalently, using V(G) = E - N + 2 with E=10 edges and N=9 nodes -> careful counting of the graph above also yields 4 independent paths, matching the well-known result that binary search has a cyclomatic complexity of 4.) This means 4 independent test paths are needed to achieve full branch coverage of this function.

2022 · Paper-I · Q7(b) (6 marks)

Question

What is the difference between white box (Glass Box) testing and black box testing? Which of these testing techniques helps in identifying more errors in a system under evaluation? Explain.

Solution

White-box (glass-box) testing examines the internal logic, code structure, and paths of the program; the tester has access to the source code and designs test cases to achieve statement, branch, or path coverage (e.g., unit testing). Black-box testing treats the software as an opaque box, testing only its inputs and outputs against the specification, without knowledge of internal implementation (e.g., equivalence partitioning, boundary value analysis).

Which finds more errors? Neither alone is sufficient, but white-box testing tends to uncover more errors overall because it directly exercises internal logic paths, loops, and conditions that black-box testing (driven only by external requirements) may never trigger - e.g., dead code, off-by-one errors in loops, or unreachable branches. Black-box testing, however, is essential for catching errors of omission (missing functionality, requirements the code fails to implement at all) that white-box testing cannot detect since it only checks what the code does, not what it fails to do. In practice, a combination of both (grey-box testing) gives the best overall defect-detection coverage.

2022 · Paper-I · Q7(c) (6 marks)

Question

Requirements can be specified using natural language specification. Write one user requirement and one system requirement for the following function: Automatically highlight incorrect spelling mistakes in an MS Word document.

Solution

User requirement (what the user needs, in non-technical language): "The word processor shall automatically detect and visually highlight any word that is spelled incorrectly, as the user types, so that spelling mistakes can be noticed and corrected immediately."

System requirement (detailed, precise, implementable specification): "Whenever the user finishes typing a word (detected by a word-boundary character such as a space, punctuation mark, or newline), the system shall tokenize the word, look it up in the installed dictionary/spell-check lexicon (including any user-defined custom dictionary), and if no match is found, the system shall apply a red wavy underline text-decoration to that word's character range in the document view within 100 milliseconds."

2021 · Paper-I · Q3(c) (5 marks)

Question

What are IDEs? How do they help in software development? List the IDEs you have ever used.

Solution

An IDE (Integrated Development Environment) is a software application that bundles together the essential tools for software development into a single, unified package: a source-code editor (syntax highlighting, autocomplete), a compiler/interpreter and build-automation tools, a debugger, and typically integration with version-control systems (e.g. Git). IDEs help software development by increasing developer productivity (code completion, quick navigation between files/definitions), catching errors early through real-time syntax and static analysis checks, streamlining the edit-build-test-debug cycle within one tool, and providing integrated debugging (breakpoints, variable inspection, step-through execution) that would otherwise require several separate tools. Commonly used IDEs: Visual Studio, Visual Studio Code, Eclipse, IntelliJ IDEA, NetBeans, PyCharm, Code::Blocks, and Android Studio.

2021 · Paper-I · Q7(a) (8 marks)

Question

Write detailed notes on any TWO of the following: i. PERT chart ii. Unified Modeling Language iii. AVL Trees

Solution

PERT chart (Program Evaluation and Review Technique): a project-management tool that models a project as a network diagram of nodes (events/milestones) connected by directed edges (activities), showing task dependencies. Each activity is given three time estimates — optimistic (O), most likely (M), and pessimistic (P) — combined into an expected time via Te = (O + 4M + P) / 6. PERT identifies the CRITICAL PATH — the longest path through the network — which determines the minimum possible project completion time, and reveals SLACK/FLOAT (how much a non-critical activity can be delayed without affecting the overall schedule), helping managers prioritise attention on critical activities. Unified Modeling Language (UML): a standardised, general-purpose graphical modelling language for specifying, visualising, constructing, and documenting the artifacts of a software system, especially for object-oriented analysis and design. It includes structural diagrams (Class diagram, Object diagram, Component diagram, Deployment diagram) that show the static structure of a system, and behavioural diagrams (Use Case diagram, Sequence diagram, Activity diagram, State Machine diagram) that show dynamic interactions and workflows. UML gives developers, analysts, and stakeholders a common visual vocabulary to communicate a system's design unambiguously.

2021 · Paper-I · Q7(b) (7 marks)

Question

What is a Software Process Model? Explain the Spiral model in detail.

Solution

A software process model is an abstract representation of the sequence of activities — requirements gathering, design, implementation, testing, deployment, maintenance — followed during software development, providing a framework/roadmap for organising and managing the development effort (e.g. Waterfall, Incremental, Spiral, Agile models). The Spiral Model (proposed by Barry Boehm) combines iterative development with systematic risk analysis, particularly suited to large, complex, high-risk projects. It is represented as a spiral with multiple loops (cycles), and each loop repeats FOUR quadrant activities:

Determine objectives, alternatives, and constraints for that phase of the product.
Identify and resolve risks — through risk analysis and, where needed, building prototypes to reduce the biggest uncertainties.
Develop and verify the next level of the product — design, code, and test the increment.
Plan the next iteration — review progress with stakeholders and plan the following loop. Each successive loop around the spiral produces a more complete, refined version of the system, while explicitly managing risk at every stage — making it well suited to projects where requirements are not fully known upfront or carry significant technical/business risk.

2021 · Paper-I · Q7(c) (5 marks)

Question

What do you mean by software quality? List at least five quality attributes.

Solution

Software quality is the degree to which a software product meets its specified functional requirements as well as implicit and explicit non-functional expectations of its users, and is free of defects — encompassing both 'doing the right thing correctly' and 'doing it well.' Five (of many) recognised quality attributes:

Reliability — the software operates correctly and consistently without failure over time.
Usability — how easily users can learn and effectively use the software.
Efficiency/Performance — appropriate use of resources (CPU, memory) and acceptable response time.
Maintainability — how easily the software can be modified to fix defects, add features, or adapt to a changed environment.
Portability — the ease with which the software can be transferred to run in different environments or platforms. (Other commonly cited attributes: security, correctness, testability, and scalability.)

2021 · Paper-I · Q8(e) (4 marks)

Question

Write a note on Aspect Oriented Programming

Solution

Aspect-Oriented Programming (AOP) is a programming paradigm aimed at increasing modularity by allowing the separation of 'cross-cutting concerns' — functionality such as logging, security checking, or transaction management that would otherwise need to be duplicated across many unrelated classes/methods in a purely object-oriented design, causing code tangling and scattering. Key concepts: an Aspect is a module that encapsulates one cross-cutting concern; a Join Point is a point during program execution (e.g. a method call) where the aspect can be applied; a Pointcut is an expression selecting a set of join points; Advice is the code executed at a matched join point (before/after/around it); and Weaving is the process — done at compile-time, load-time, or runtime — of combining aspects into the base program to produce the final system. AspectJ is the most widely known implementation of AOP for Java. Benefits include improved modularity, reduced code duplication for cross-cutting behaviour, and easier independent maintenance of both the core business logic and the cross-cutting functionality.

2020 · Paper-II · Q8(b) (6 marks)

Question

Briefly discuss the role of validation and verification in requirement engineering.

Solution

Verification checks 'are we building the product RIGHT?' — it confirms that a work product (design document, code) correctly conforms to its written specification, typically through reviews, inspections, and testing against the spec. Validation checks 'are we building the RIGHT product?' — it confirms that the requirements themselves (and ultimately the delivered system) genuinely satisfy the real needs and intentions of the customer and stakeholders, typically through stakeholder reviews, prototyping, and acceptance testing. Both play essential complementary roles in requirement engineering: validation catches errors where the requirements were wrong/incomplete/misunderstood in the first place — the most expensive kind of error to fix late — while verification ensures that whatever gets built downstream faithfully implements whatever was specified. Using both together is necessary because a system can perfectly satisfy (be verified against) an incorrect specification and still fail to be validated as what the customer actually needed.

2019 · Paper-I · Q7(a) (10 marks)

Question

Discuss the architecture of aspect-oriented system.

Solution

An Aspect-Oriented Programming (AOP) system architecture has the following components:

Core/base modules — ordinary classes/functions implementing the primary business logic of the application.
Aspects — separate modules that encapsulate a cross-cutting concern (e.g. logging, security, transaction management, caching) that would otherwise be scattered across many core modules.
Join points — well-defined points during program execution where an aspect can be inserted, such as a method call, method execution, object creation, or exception being thrown.
Pointcuts — expressions/predicates that select a specific set of join points (e.g. 'all public methods in package com.bank').
Advice — the actual code that runs when a pointcut is matched, and can execute 'before', 'after', or 'around' the join point.
Weaver — the component that combines (weaves) aspects with the core code to produce the final executable system. Weaving can happen at compile-time (source-to-source), post-compile/binary time, or load-time/runtime (dynamic proxies). Overall data flow: Base Program source + Aspect definitions → AOP Weaver → Woven executable, which behaves as though the cross-cutting code had been written directly into every relevant location in the base program, without the base program's source having been touched.

2019 · Paper-I · Q7(b) (5 marks)

Question

Briefly discuss the motivation for aspect-oriented programming.

Solution

OOP alone struggles to modularise 'cross-cutting concerns' — functionality like logging, security checks, transaction handling, or performance monitoring that logically applies across many unrelated classes/methods. Implementing such concerns directly inside every relevant class causes: (1) code tangling — a single method mixes its core logic with unrelated concerns, reducing readability, and (2) code scattering — the same concern's code is duplicated across many modules, making maintenance error-prone (a change to the logging format means editing dozens of files). AOP's motivation is to pull each cross-cutting concern into its own single module (an aspect) and let a weaver automatically apply it wherever needed, improving separation of concerns, reducing duplication, and making both the core logic and the cross-cutting logic easier to understand and maintain independently.

2019 · Paper-I · Q7(c) (5 marks)

Question

What is the significance of quantification and obliviousness?

Solution

Quantification and obliviousness are the two defining properties of AOP: Quantification is the ability to state, in one place, a general rule that automatically applies to many parts of a program without having to enumerate every location individually — e.g. 'log every call to any public method in this package.' This is what lets a single aspect affect potentially hundreds of join points scattered across the codebase. Obliviousness means the base/core code does not need to know that aspects exist or will be applied to it — programmers write the core business logic without anticipating, referencing, or calling any aspect code; the weaver inserts the cross-cutting behaviour transparently. Together, these two properties are what make AOP fundamentally different from normal method calls or design patterns: quantification lets you say 'do this everywhere that matches,' while obliviousness means the affected code never has to be modified or made aware of it, keeping the core logic clean and the cross-cutting concern centrally maintainable.

2019 · Paper-II · Q7(b) (6 marks)

Question

Describe briefly the role of validation in requirement engineering process.

Solution

Requirements validation is the activity of checking that the documented requirements genuinely and accurately reflect what the customer/stakeholders actually want — answering 'are we building the RIGHT product?' It is distinct from verification, which checks that the system built matches the written specification ('are we building the product right?'). Validation techniques include requirements reviews and walkthroughs with stakeholders, prototyping to let users confirm the requirements against a tangible mock-up, and deriving test cases directly from requirements to check they are unambiguous and testable. Its role is to catch requirement errors (missing, conflicting, infeasible, or misunderstood requirements) as early as possible in the development lifecycle, since fixing a requirement error found during validation is far cheaper than discovering it after design, coding, or deployment.

2018 · Paper-I · Q2(d) (3 marks)

Question

List down any four best practices for coding standards.

Solution

Use meaningful, consistent naming conventions for variables, functions, and classes (e.g. camelCase or snake_case consistently) so code is self-descriptive.
Write clear comments and documentation for complex logic, function purposes, and parameters, without over-commenting obvious code.
Maintain consistent indentation and formatting (spacing, brace placement) throughout the codebase for readability.
Keep functions/methods small and focused on a single responsibility (avoid overly long or multi-purpose functions), and avoid duplicated code (DRY principle - Don't Repeat Yourself).

2018 · Paper-I · Q7(a) (4 marks)

Question

Outline the difference between software verification and software validation.

Solution

Verification asks 'Are we building the product RIGHT?' - it checks that the software correctly implements its specifications/design at each stage of development, typically through static techniques (reviews, inspections, walkthroughs, static analysis) without necessarily executing the full system.

Validation asks 'Are we building the RIGHT product?' - it checks that the finished software actually satisfies the customer's real needs and intended use, typically through dynamic techniques (executing/testing the system, user acceptance testing) with real or realistic inputs.

In short: verification is an internal, specification-conformance check performed throughout development; validation is an external, user-needs-conformance check typically performed on the completed (or a working increment of the) system.

2018 · Paper-I · Q7(b) (4 marks)

Question

Give an outline of the unit testing process for verification.

Solution

Unit testing verifies the smallest testable pieces of code (individual functions, methods, or classes) in isolation from the rest of the system. Outline of the process:

Identify the unit to be tested (a function/method/class) and understand its expected behavior/specification.
Design test cases covering normal ('happy path') inputs, boundary/edge cases, and invalid/erroneous inputs.
Isolate the unit from its dependencies using stubs, mocks, or fakes (so the unit is tested independently of other, possibly-unfinished or slow, components like databases or network calls).
Execute the test cases (often automated, using a testing framework such as JUnit/Google Test/pytest) and compare actual output against expected output.
Record and analyze results - passing tests confirm correct behavior for that scenario; failing tests indicate a defect to be fixed.
Re-run tests after any code change (regression testing) to ensure the unit still behaves correctly, ideally as part of an automated continuous-integration pipeline. Unit testing catches defects early (before integration), when they are cheapest to fix, and forms the foundation of the testing pyramid beneath integration and system testing.

2018 · Paper-I · Q7(c) (4 marks)

Question

Agile Development is a process that values responding to change over following a plan. Discuss three issues a Software Engineer should be mindful of when adopting this approach during software development.

Solution

Documentation trade-off: Agile favors working software over comprehensive documentation, so engineers must be careful not to let documentation become so sparse that knowledge transfer, maintenance, and onboarding of new team members become difficult later.
Scope and requirements volatility: since Agile embraces changing requirements even late in development, engineers must design flexible, loosely-coupled architectures that can absorb change without excessive rework, and must manage stakeholder expectations so 'responding to change' doesn't turn into unmanaged scope creep that derails timelines/budgets.
Technical debt accumulation: the pressure of delivering working software in short, frequent iterations can tempt teams to cut corners (skip refactoring, inadequate test coverage) to meet sprint deadlines; engineers must consciously balance speed with ongoing code quality/refactoring discipline, or technical debt will compound and slow future iterations significantly.

2018 · Paper-I · Q7(d) (4 marks)

Question

What type of project is not suited to incremental methods?

Solution

Incremental development methods are poorly suited to projects where:

The complete system's requirements must be fully and rigidly specified upfront and cannot be usefully decomposed into independently deliverable, meaningful increments (e.g. certain safety-critical or embedded real-time systems where the whole system must be verified as one integrated unit before any part is trustworthy for use, such as flight-control or nuclear-plant control software).
There is a hard requirement for complete, formal, upfront specification and verification before ANY deployment (common in high-assurance/regulated domains), since incremental delivery of a partial, unverified system would be unacceptable or even dangerous.
The system is small/simple enough that breaking it into increments adds unnecessary process overhead without real benefit.
Tightly coupled, monolithic architectures where individual features cannot be isolated or delivered independently without the whole system being complete first. In general, projects demanding a single, fully-validated, all-at-once delivery due to safety, regulatory, or extreme interdependency constraints are not well suited to incremental methods.

2018 · Paper-I · Q7(e) (4 marks)

Question

Outline the difference between Black box and White box testing.

Solution

Black Box Testing: tests the software's functionality based purely on its specified inputs and expected outputs, WITHOUT any knowledge of, or reference to, the internal code structure, logic, or implementation. The tester treats the system as an opaque 'black box'. Techniques include equivalence partitioning, boundary value analysis, and use-case-based testing. It is typically used for system/acceptance testing and can be performed by testers without programming knowledge.

White Box Testing: tests the software based on explicit knowledge of its INTERNAL code structure, logic, and implementation paths. The tester designs test cases to exercise specific statements, branches, conditions, or paths within the code (e.g. achieving a target level of statement/branch/path coverage). It requires programming knowledge and is typically used for unit and integration testing, performed by developers.

Key difference: black box testing verifies WHAT the system does (external behavior, specification conformance), while white box testing verifies HOW the system does it (internal correctness, logic coverage) - the two are complementary, not competing, testing strategies.

2018 · Paper-II · Q8(C) (6 marks)

Question

Discuss Agile and Water Fall methodologies in the context of web application development.

Solution

Waterfall in web application development: follows a strict sequential process - full requirements gathering for the web app, followed by complete design (UI mockups, database schema, architecture), then full implementation, then testing of the whole application, then deployment, then maintenance. This works reasonably well only when the web application's requirements are well-understood, stable, and unlikely to change (e.g. a simple, well-specified informational site), since it does not accommodate feedback or change well once development is underway - but web application needs (user experience trends, competitor features, changing user behavior) evolve rapidly, making pure Waterfall poorly suited to most modern web projects, since a fully-built site based on months-old requirements risks being outdated or misaligned with users' actual needs by the time it launches.

Agile in web application development: uses short, iterative sprints (typically 1-4 weeks) to incrementally build and release working features of the web application, with continuous stakeholder/user feedback after each sprint used to adapt priorities and requirements for the next sprint. This suits web development very well because: web technologies, browsers, and user expectations change quickly; early and frequent releases (even a Minimum Viable Product) let real user feedback and analytics guide further development; and features can be prioritized/reprioritized as market conditions or business needs shift.

Conclusion: Agile is generally preferred for web application development due to the domain's fast pace of change and the value of continuous user feedback, while Waterfall may still suit smaller, well-defined web projects (e.g. a fixed-scope brochure website) where requirements are genuinely stable and unlikely to change.

2017 · Paper-I · Q4(a) (8 marks)

Question

What factors should be considered when choosing particularly between evolutionary and incremental models? Elucidate the characteristics of Rapid Application Development, Joint Application Development and Agile Software Engineering.

Solution

Factors for choosing evolutionary vs incremental models: clarity/stability of requirements (evolutionary suits poorly-understood, changing requirements; incremental suits requirements that are known upfront but can be delivered in usable chunks), project size and risk tolerance, need for early user feedback, availability of a working prototype early on, time-to-market pressure, and team/customer availability for continuous collaboration.

Rapid Application Development (RAD): emphasizes very short development cycles using component-based construction and heavy user involvement; phases include business modelling, data modelling, process modelling, application generation (often via CASE tools/prototyping), and testing/turnover; best for projects with well-defined scope and modular functionality that must be delivered quickly (60-90 days).

Joint Application Development (JAD): a structured, workshop-based requirements-gathering technique bringing together users, managers, and developers in facilitated sessions to define and agree on system requirements collaboratively, reducing miscommunication and rework caused by later-discovered misunderstandings.

Agile Software Engineering: an iterative, incremental approach (e.g. Scrum, XP) valuing individuals/interactions over processes, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a rigid plan; delivers working software in short sprints/iterations with continuous customer feedback and adaptive planning.

2017 · Paper-I · Q4(b) (6 marks)

Question

Differentiate between Software Validation and Verification. Discuss some of the techniques used for empirical software evaluation.

Solution

Verification: 'Are we building the product right?' - checks that the software conforms to its specification/design at each development stage, without necessarily running the complete system (e.g. reviews, walkthroughs, inspections, static analysis).

Validation: 'Are we building the right product?' - checks that the final software actually meets the customer's real needs and intended use, typically through dynamic testing/execution and user acceptance testing.

Techniques for empirical software evaluation:

Controlled experiments: comparing two approaches/tools under controlled conditions with measurable metrics.
Case studies: in-depth study of the software's use/development in a real project setting.
Surveys/questionnaires: gathering user satisfaction and usability feedback.
Usability testing: observing real users performing tasks to measure effectiveness, efficiency and satisfaction.
Metrics-based evaluation: measuring code quality metrics (cyclomatic complexity, defect density, code coverage) empirically over time.
A/B testing: comparing two versions of software with real users to measure which performs better against a chosen metric.

Together these techniques provide objective, data-driven evidence about software quality beyond the developer's own judgement.

2017 · Paper-I · Q4(c) (6 marks)

Question

Discuss the importance of Requirements Engineering in the success of a software project. Explain in detail the process of 'Requirements Sign-off'.

Solution

Requirements Engineering (RE) is critical to project success because most costly software failures stem from poor, incomplete, or misunderstood requirements - errors caught late (during coding or after deployment) are exponentially more expensive to fix than those caught during RE. Good RE ensures the delivered system matches actual stakeholder needs, provides a clear basis for planning, estimation, design, and testing, and reduces scope creep and disputes between client and developer.

Requirements Sign-off is the formal process by which stakeholders (client, product owner, key users) review, agree to, and formally approve the documented requirements (usually the SRS) before design/development begins.

Process:

Finalize the requirements document after elicitation, analysis, and internal review.
Present/walk through the requirements with all relevant stakeholders, clarifying any ambiguity.
Address and incorporate stakeholder feedback/change requests.
Obtain formal, documented approval (a signature or equivalent formal acknowledgment) from authorized stakeholders, indicating requirements are complete, correct, and agreed upon.
Baseline the signed-off requirements - any subsequent change must go through a formal change-control process rather than ad-hoc modification.

Sign-off establishes a contractual reference point, protecting both the client (guaranteeing what will be delivered) and the developer (protecting against uncontrolled scope creep).

2017 · Paper-I · Q6(a) (8 marks)

Question

The design methodologies of programs can have multiple approaches including the Big Bang, Code and Fix, Water Fall and the Spiral Model. Consider a test application and describe the development of the application while following each of these four approaches.

Solution

Consider building a simple 'To-Do List' test application under each model:

Big Bang model: no formal planning, design, or process - developers simply start coding based on a vague idea, throw all resources and effort at it at once, and hope it comes together; for the To-Do app this means jumping straight into writing code with no requirements document, discovering features/bugs only after most/all effort is spent. Suitable only for tiny, low-risk, exploratory projects; highly risky for anything larger.

Code-and-Fix: a minimal process where code is written quickly, then fixed/patched reactively as bugs and missing features are discovered, with no upfront design; for the To-Do app, a basic version is built fast, then features are bolted on and bugs patched as users complain - leads to messy, hard-to-maintain code over time.

Waterfall model: strict sequential phases - first fully gather requirements for the To-Do app (add/edit/delete/mark-complete tasks), then design its architecture and UI, then implement, then test the whole application, then deploy, then maintain; no phase begins before the previous is complete and signed off.

Spiral model: iterative, risk-driven - each 'loop' of the spiral repeats four activities (planning, risk analysis, engineering/build a prototype, and customer evaluation) for the To-Do app: first build a bare-bones prototype (just adding tasks), evaluate risk and user feedback, then loop again adding editing/deleting, then again adding persistence/sync, progressively refining the product each cycle while managing risk early.

2017 · Paper-I · Q6(b) (6 marks)

Question

Discuss the design issues of Task Partitioning and Task Allocation in Distributed Software Engineering tasks.

Solution

Task Partitioning: the process of decomposing an overall system/application into smaller, largely independent tasks/modules/processes that can be executed concurrently or distributed across multiple nodes. Design issues:

Granularity: too fine-grained partitioning increases communication/coordination overhead; too coarse limits parallelism/distribution benefit.
Dependency management: tasks often share data or must execute in a certain order, requiring careful identification of dependencies to avoid excessive synchronization.
Cohesion/coupling: each partition should be functionally cohesive internally and loosely coupled to others, to minimize inter-node communication.

Task Allocation: deciding which processing node/machine each task/partition should be assigned to run on. Design issues:

Load balancing: distributing tasks so no single node becomes a bottleneck while others are idle.
Locality of reference: placing a task near the data/resources it needs most (to reduce network communication cost/latency).
Fault tolerance: allocation strategy must consider node failures - critical tasks may need replication across nodes.
Scalability: the allocation scheme should adapt gracefully as nodes are added or removed.
Communication cost: minimizing the volume/frequency of inter-node messages, since network latency is typically the dominant cost in distributed systems.

Both partitioning and allocation directly affect overall system performance, reliability, and scalability, and are usually solved together since a poor partition can make good allocation impossible, and vice versa.

2017 · Paper-I · Q6(c) (6 marks)

Question

Explain the importance of Design Patterns under the umbrella of Agile software design and programming. Explain Software Testing and different methodologies.

Solution

Design Patterns are proven, reusable solutions to commonly recurring software design problems (e.g. Singleton, Observer, Factory, Strategy). Under Agile, where code must remain flexible and easily changeable across many short iterations, design patterns are important because they:

Provide a shared vocabulary among team members, speeding up communication and code reviews during fast-paced sprints.
Promote loose coupling and high cohesion, making it easier to refactor and extend code as requirements evolve iteration-to-iteration (a core Agile need).
Encourage best-practice, tested solutions rather than ad-hoc designs that may need costly rework later.
Support Agile principles like 'simple design' and continuous refactoring, since well-known patterns are easy to recognize and safely modify.

Software Testing verifies that software behaves as expected and is free of defects. Methodologies:

Unit Testing: testing individual functions/components in isolation.
Integration Testing: testing interactions between combined modules.
System Testing: testing the complete, integrated system against requirements.
Acceptance Testing: validating the system with the customer/end-user against real-world scenarios.
Black-box Testing: testing based only on inputs/outputs, without knowledge of internal code.
White-box Testing: testing based on knowledge of internal code structure/logic (e.g. path/branch coverage).
Regression Testing: re-running tests after changes to ensure no existing functionality broke - especially important in Agile's frequent iterations.

2016 · Paper-I · Q7(c) (5 marks)

Question

Describe Software Development Life Cycle (SDLC). Explain your answer with the help of depicting and describing different phases of pure water fall software life cycle.

Solution

SDLC (Software Development Life Cycle) is a structured process/framework that defines the sequence of activities followed to plan, create, test, deploy and maintain a software system, ensuring quality and predictability.

Pure Waterfall model phases (strictly sequential, one phase completes before the next begins):

Requirements Analysis - gather and document what the system must do (produces the SRS).
System Design - define architecture, data structures, and interfaces based on requirements.
Implementation (Coding) - translate the design into actual program code.
Testing (Verification) - test individual units and the integrated system against requirements.
Deployment - release the system into the production/operational environment.
Maintenance - fix defects and adapt the system to new needs after release.

Diagram: Requirements -> Design -> Implementation -> Testing -> Deployment -> Maintenance (each arrow = one-way flow; no phase begins until the previous is fully signed-off)

The model's rigidity makes it best suited to projects with clear, stable, well-understood requirements, since going back to an earlier phase after moving forward is costly.

2016 · Paper-I · Q7(d) (5 marks)

Question

What is the difference between SRS document and design document? What are the contents we should contain in the SRS document and design document.

Solution

SRS (Software Requirements Specification) document describes WHAT the system should do - the complete set of functional and non-functional requirements, from the user's/client's perspective, without describing how it will be built internally. Contents: introduction & purpose, scope, functional requirements, non-functional requirements (performance, security, reliability), use cases/user stories, external interface requirements, constraints, and acceptance criteria.

Design document describes HOW the system will be built to satisfy the SRS - the internal technical solution. Contents: system architecture (modules/components and how they interact), data design (database schema, data structures), interface design (APIs, UI layout), algorithm design for key modules, class/object diagrams, and technology choices.

Key difference: the SRS is a contract between stakeholders and developers about required behaviour (problem space), written for both technical and non-technical readers; the design document is a technical blueprint used by developers to implement the system (solution space), written for the development team. The design document is derived from, and must be consistent with, the SRS.

2016 · Paper-I · Q8(a) (5 marks)

Question

What are the purposes of Data Flow diagrams, Entity-Relationship diagrams? Give an example diagram of each.

Solution

Data Flow Diagram (DFD): purpose is to graphically show how data moves through a system - the processes that transform data, the data stores where it rests, the external entities that supply/consume it, and the flows connecting them. It is used during requirements/analysis to understand system functionality independent of implementation. Example (Level-0 / context diagram for a Library System): [Student] --borrow request--> ( Issue Book Process ) --update--> [Book Records store] --confirmation--> [Student]

Entity-Relationship (ER) Diagram: purpose is to model the data of a system - the entities (things about which data is stored), their attributes, and the relationships between entities - used to design a database schema. Example: STUDENT (RollNo, Name) --< ENROLLS IN >-- COURSE (CourseCode, Title) (a many-to-many relationship, since one student enrolls in many courses and one course has many students)

In short: DFDs model process/behaviour (function-oriented), while ER diagrams model structure/data (data-oriented); both are core requirement-analysis and design tools.

Part B — MCQs

2026 · Paper-I · Q14 (MCQ)

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

Answer: D

Explanation: Agile methodology's central principle is delivering working software through short iterative cycles with continuous customer feedback and adapting to change, rather than rigid upfront planning or fixed initial requirements.

2026 · Paper-I · Q19 (MCQ)

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

Answer: D

Explanation: Agile teams respond to schedule slippage by re-prioritizing and adjusting scope collaboratively with the team/stakeholders in the next iteration, rather than simply adding people (which per Brooks's Law often slows a late project further) or forcing overtime.

2026 · Paper-I · Q20 (MCQ)

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

Answer: A

Explanation: Using open-source components with known vulnerabilities directly exposes the system to security breaches and can also cause the project to fail regulatory/compliance requirements (e.g., OWASP, industry security standards).

2025 · Paper-I · Q2 (MCQ)

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

Answer: A

Explanation: CMMI is a process-improvement framework whose primary goal is to assess and raise the maturity level of an organization's software development processes; better quality is a downstream benefit, not the direct goal.

2025 · Paper-I · Q3 (MCQ)

Which type of software testing is used to confirm whether the software is according to customer's requirements?

A. Performance testing
B. Acceptance testing
C. Regression testing
D. None of these

Answer: B

Explanation: Acceptance testing (often User Acceptance Testing) is performed to verify the system meets the customer's business requirements before final sign-off.

2025 · Paper-I · Q5 (MCQ)

Which software development model uses iterative cycles and continuous development?

A. Agile model
B. Spiral model
C. V-model
D. None of these

Answer: A

Explanation: The Agile model develops software in short, repeated iterations (sprints) with continuous integration, feedback and delivery, unlike the sequential V-model.

2025 · Paper-I · Q8 (MCQ)

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

Answer: B

Explanation: Refactoring restructures existing code to improve readability, maintainability and design without changing its external behavior or functionality.

2024 · Paper-I · Q5 (MCQ)

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

A. Scrum
B. Waterfall
C. Kanban
D. None of these

Answer: B

Explanation: Waterfall is a traditional sequential (non-agile) software development model; Scrum and Kanban are both agile frameworks.