Unit 1: Software Engineering

UGC NET / JRF — Computer Science & Applications

High-Yield Study Notes & PYQ-Pattern Workbook (Unit: Software Engineering)

Contents

Ch.1 — Introduction to Software Engineering

Ch.2 — SDLC

Ch.3 — Software Metrics

Ch.4 — Software Requirements Specification (SRS)

Ch.5 — Software Maintenance

One-Shot Revision

Mini Mock Test (45 Qs with Answer Key)

Beginner → Concept → NET-level → JRF-level. Compact by design — exam value over page count.

Syllabus Mapping & PYQ-Pattern Analysis

This book covers the Software Engineering unit of the UGC NET Computer Science & Applications syllabus: the software process/SDLC, software project and product metrics, software requirements specification, and software maintenance. Design, coding and testing methodologies that fall under the same broader syllabus head are referenced only where needed to explain these five chapters, and are not treated as separate chapters here.

Note on PYQs: Where an exact past-year question could not be reliably verified, it is labelled "NTA/UGC NET-style question pattern" rather than presented as a confirmed PYQ with a year. This keeps the pattern-analysis useful without fabricating exam history.

Where marks concentrate (based on syllabus weight & recurring pattern) SDLC models (identification + comparison) → Cyclomatic Complexity numericals → Function Point numericals → Functional vs Non-functional requirement classification → Maintenance-type identification from a scenario → Verification vs Validation.

What separates JRF from NET here NET tests "what is X". JRF tests: (a) numericals with 2–3 combined steps, (b) "which statement is FALSE" with 3–4 statements mixing true and subtly wrong facts, (c) matching + reasoning together, (d) edge cases (e.g., E=0 in cyclomatic complexity is impossible; when Function Points and LOC disagree; when Big Bang/Prototype is preferred over Waterfall).

Chapter 1 — Introduction to Software Engineering

1.1 Software vs Program

SimpleA program is just code that does one job. Software is the program plus documentation, user manuals, and support — a complete product people can rely on.

FormalSoftware = Programs + Documentation + Operating procedures. A program is a set of instructions; software is an engineered product built, tested, documented and maintained over a lifecycle.

NET point"Software is engineered, not manufactured" — this line (from Pressman) is a favourite one-liner MCQ stem.

TrapDon't assume "software" only means the executable — SRS, test cases and user manuals are also part of the software product.

HinglishProgram sirf code hota hai; Software us code ke saath documentation aur support bhi include karta hai.

1.2 Characteristics of Software

• Developed/engineered, not manufactured — no assembly-line production; each copy is identical (unlike hardware wear-and-tear).
• Does not wear out — but suffers from deterioration due to change (repeated maintenance degrades structure).
• Custom-built, though reusable components exist.
• Complex, invisible/intangible, and logically (not physically) constrained.

JRF insight"Software does not wear out" is TRUE, but NET loves the follow-up trap: software reliability still *drops over time* — not because of wear, but because of undiscovered bugs and change-induced side-effects. Distinguish "wear out" (hardware concept, false for software) from "reliability decay" (true for software, different cause).

1.3 Software Crisis & Need for Software Engineering

SimpleIn the 1960s–70s, software projects were routinely late, over-budget, buggy, and hard to maintain. This chaos was called the "software crisis" — it is why software engineering as a discipline was created (term coined 1968, NATO conference).

• Symptoms: cost/schedule overruns, poor quality, unmet requirements, unmaintainable code.
• Causes: growing software size/complexity, absence of systematic methods, no standard process.

PYQ patternTopic: term "software crisis" / term coined at which conference. NTA/UGC NET-style question pattern — remember: NATO Software Engineering Conference, 1968.

1.4 Software Engineering — Definition & Principles

Formal (IEEE)"The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software."

NET pointKey words to recognise in MCQ options: systematic, disciplined, quantifiable, engineering approach. An option missing "quantifiable" is often the wrong/incomplete definition used as a distractor.

1.5 Characteristics of Good Software

Quality	Meaning
Maintainability	Easy to modify/fix after delivery
Dependability & Security	Reliable, safe, doesn't cause damage on failure
Efficiency	Optimal use of memory, CPU, resources
Usability	Understandable, easy to use, matching user needs
Portability	Works across environments/platforms

1.6 Software Process & Software Product

SimpleA software process is the set of activities used to build software (like a recipe). A software product is what you deliver (the dish).

JRF insightGeneric process activities (common to nearly every model): Specification → Development → Validation → Evolution. Every SDLC model is really just a different arrangement/emphasis of these four.

MUST REMEMBER — Chapter 1

• Software = Program + Documentation + Operating procedure.
• Software engineering term coined at the 1968 NATO Conference.
• Software does NOT wear out, but reliability decays via change/bugs.
• Generic process framework: Communication → Planning → Modeling → Construction → Deployment (Pressman).
• Good software = Maintainability + Dependability/Security + Efficiency + Usability + Portability.

DON'T CONFUSE

• Program vs Software — code vs complete engineered product.
• Software crisis vs Software myth — crisis = industry-wide problem; myths = false beliefs (management/customer/practitioner myths) that worsen the crisis.

JRF CHALLENGE ZONE — Chapter 1

1. Which statement is FALSE? (a) Software is engineered not manufactured (b) Software wears out like hardware (c) Software is custom-built though reusable components exist (d) Software is intangible.
Answer: (b) — software does not physically wear out.

2. The NATO conference that coined "software engineering" was held in: (a) 1968 (b) 1972 (c) 1958 (d) 1980. Answer: (a)

3. "Reliability of software can still decrease over its life" — this is explained by: (a) physical wear (b) side-effects of repeated maintenance/change (c) manufacturing defects (d) none. Answer: (b)

Practice Questions — Chapter 1 (12)

1. Software engineering is best defined as a ______ approach to software development.
   Ans: systematic, disciplined, quantifiable
2. State whether True/False: "Software is manufactured like hardware."
   Ans: False — software is engineered, not manufactured
3. Name the four generic software process activities (Sommerville).
   Ans: Specification, Development, Validation, Evolution
4. What is the key difference between a software process and software product?
   Ans: Process = activities used to build it; Product = the delivered software itself
5. List any three characteristics of good software.
   Ans: Any three of: Maintainability, Dependability/Security, Efficiency, Usability, Portability
6. Match: (a) Portability (b) Usability (c) Maintainability → (i) easy to modify (ii) works across platforms (iii) easy to learn/use.
   Ans: a-ii, b-iii, c-i
7. The term "software crisis" refers to which decade primarily?
   Ans: 1960s–70s
8. Why is "custom-built" only partially true for modern software? (Hint: reusable components/COTS).
   Ans: Modern software often reuses existing components/COTS rather than being built entirely from scratch
9. Fill in: Software engineering conference, 1968, held by ______.
   Ans: NATO
10. Which quality attribute is most related to "does not cause physical/economic damage on failure"?
    Ans: Dependability & Security
11. Give one example each of a management myth and a practitioner myth about software.
    Ans: Management myth — "adding more people to a late project speeds it up"; Practitioner myth — "once the program is written and working, the job is done"
12. Why does software reliability decay even though software doesn't wear out physically?
    Ans: Because repeated maintenance/changes introduce side-effects and undiscovered bugs surface over time

---

Chapter 2 — SDLC (High Priority Chapter)

2.1 SDLC — Concept & Generic Phases

SimpleSDLC is the step-by-step roadmap for building software: figure out what's needed, design it, build it, test it, release it, then keep fixing/upgrading it.

Requirement Analysis → Design → Implementation (Coding) → Testing → Deployment → Maintenance

NET pointFeasibility study (technical, economic, operational, legal, schedule) usually precedes/overlaps requirement analysis — a common "which comes first" MCQ.

2.2 Waterfall Model

IdeaStrictly sequential, linear phases; each phase must complete before the next begins. Oldest model (Royce, 1970).

• Best for: well-understood, stable requirements, short projects.
• Adv: simple, easy to manage, clear milestones/documentation.
• Dis: no feedback loop until the end; working software appears very late; poor for changing requirements.

JRF trap"Pure Waterfall has no feedback path" — actually the classical diagram DOES show feedback arrows to the immediately previous phase only (not to any arbitrary earlier phase). This nuance is a common false-option trap.

2.3 Prototype Model

IdeaBuild a quick working mock-up (prototype) when requirements are unclear, get customer feedback, refine, then build the real system.

• Best for: unclear/evolving requirements, unfamiliar domain.
• Adv: reduces risk of misunderstanding requirements; strong user involvement.
• Dis: customer may mistake prototype for final product; can increase cost/time if over-engineered.

2.4 Incremental Model

IdeaSystem is divided into builds/increments; each increment adds functionality to a working, deliverable product.

• Best for: when core requirements are clear but full scope can be delivered in parts; needed early on market.
• Adv: early partial delivery, lower initial cost, easier to test/manage risk.
• Dis: needs good modular design planning upfront.

2.5 Iterative Model

IdeaBuild the whole system in a rough version first, then repeatedly refine it across iterations, improving each time.

JRF trap: Incremental vs IterativeIncremental = adds NEW functionality each release (builds are functional subsets). Iterative = REFINES the same functionality across passes (each pass improves the whole). Many students conflate these — a top JRF distinguishing question.

2.6 Spiral Model

IdeaBoehm's risk-driven model. Each cycle (spiral) = Objective setting → Risk analysis → Engineering (develop/verify) → Planning next cycle. Combines Waterfall + Prototyping with explicit risk management.

• Best for: large, high-risk, complex projects with evolving requirements.
• Adv: strong risk handling, suitable for long-term projects.
• Dis: expensive, needs risk-assessment expertise, complex to manage.

NET pointThe four quadrants of one spiral loop, in order: (1) Determine objectives/alternatives/constraints (2) Evaluate alternatives, identify & resolve risks (3) Develop & verify next-level product (4) Plan next phase. Sequence questions are common.

2.7 V-Model

IdeaVerification (left arm: requirement→design→coding) is mirrored by Validation (right arm: unit→integration→system→acceptance testing) forming a "V". Each development phase has a corresponding testing phase planned in parallel.

Requirements ↔ Acceptance Testing System Design ↔ System Testing Architectural Design ↔ Integration Testing Module Design ↔ Unit Testing (Coding at the bottom tip of the V)

JRF trapAcceptance testing pairs with Requirements (not System Design); System testing pairs with System Design; Integration testing pairs with Architectural/High-Level Design; Unit testing pairs with Module/Detailed Design. Mismatched pairing is the #1 trap in V-Model MCQs.

2.8 RAD Model (Rapid Application Development)

IdeaEmphasises very fast development using component-based construction, heavy reuse, and short fixed time-boxes (typically 60–90 days), with parallel teams working on different modules.

• Best for: systems that can be modularised, with tight deadlines and available skilled teams.
• Dis: needs modularisable system, heavy resource requirement, not suited for high-performance/technically risky systems.

2.9 Agile — Key Concepts (Syllabus-Relevant)

• Values (Agile Manifesto): Individuals & interactions over processes/tools; Working software over documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.
• Iterative + incremental delivery in short cycles (sprints).
• Scrum roles: Product Owner, Scrum Master, Development Team. Artifacts: Product Backlog, Sprint Backlog, Increment.

NET pointAgile Manifesto has 4 values and 12 principles — NET sometimes asks to identify a genuine value/principle among distractors that sound plausible but aren't in the manifesto.

2.10 Verification vs Validation (used across models)

	Verification	Validation
Question answered	"Are we building the product right?"	"Are we building the right product?"
Checks against	Specifications/design documents	User needs/requirements
Typical methods	Reviews, walkthroughs, inspections	Actual testing/execution
Stage	Throughout development (static)	After a working build exists (dynamic)

2.11 SDLC Models — Master Comparison

Waterfall

Core idea: Strict sequential phases

Feedback: Only to previous phase

Best for: Stable, well-understood requirements

Weakness: Late working software; rigid

Prototype

Core idea: Mock-up first, then build

Feedback: Continuous with customer

Best for: Unclear requirements

Weakness: Scope creep; prototype mistaken as final

Incremental

Core idea: Functional builds delivered in parts

Feedback: Per increment

Best for: Clear core + phased delivery

Weakness: Needs strong modular architecture upfront

Iterative

Core idea: Whole system refined across passes

Feedback: Per iteration

Best for: Evolving understanding of whole system

Weakness: Hard to bound scope/cost

Spiral

Core idea: Risk-driven repeated cycles

Feedback: Every cycle + risk review

Best for: Large, high-risk, complex projects

Weakness: Costly, needs risk expertise

V-Model

Core idea: Test phase parallel to each dev phase

Feedback: Verification/validation mirrored

Best for: Safety/quality-critical, fixed requirements

Weakness: Inflexible to change, like Waterfall

RAD

Core idea: Fast, component-based, time-boxed

Feedback: Frequent, short cycles

Best for: Modularisable systems, tight deadlines

Weakness: Not for high-performance/technical-risk systems

Agile

Core idea: Short sprints, working software

Feedback: Continuous (every sprint)

Best for: Changing requirements, active customer

Weakness: Hard to predict cost/schedule upfront

PYQ patternTopic: model selection from a scenario ("requirements are unclear and evolving — which model?"). NTA/UGC NET-style question pattern. What to remember: unclear requirements → Prototype or Agile; high risk + large + evolving → Spiral; fixed requirements + need strong testing traceability → V-Model; tight deadline + modular system → RAD.

MUST REMEMBER — Chapter 2

• Waterfall: sequential, feedback only to immediately previous phase.
• Spiral quadrants order: Objectives → Risk analysis → Engineering → Planning.
• V-Model pairs: Requirements↔Acceptance, System Design↔System Testing, Arch. Design↔Integration Testing, Module Design↔Unit Testing.
• Incremental = new functionality per build; Iterative = refine same functionality each pass.
• RAD time-box ≈ 60–90 days; needs modularisable system.
• Verification = right product built correctly (specs); Validation = right product for the user (needs).
• Agile Manifesto: 4 values, 12 principles; Scrum roles = Product Owner, Scrum Master, Dev Team.

DON'T CONFUSE

• Incremental vs Iterative (new features vs refinement).
• Prototype vs RAD (Prototype = clarify unclear requirements; RAD = fast build of clear, modular requirements).
• Verification vs Validation.

JRF CHALLENGE ZONE — Chapter 2

1. A project has unclear, evolving requirements AND is large, complex and high-risk. The single BEST model is: (a) Waterfall (b) V-Model (c) Spiral (d) RAD. Answer: (c) — risk-driven, handles both largeness and evolving requirements.

2. Which statement is FALSE about the V-Model? (a) It emphasises verification and validation equally (b) Acceptance testing corresponds to requirements (c) It is very flexible to late requirement changes (d) Unit testing corresponds to module design. Answer: (c) — like Waterfall, V-Model is rigid to change.

3. In the Incremental model, if increments are I1, I2, I3, then: (a) each Ii is a refined version of the whole system (b) each Ii adds new functional capability to a working product (c) all Ii must be delivered together (d) none. Answer: (b)

Practice Questions — Chapter 2 (18)

1. List the generic phases of SDLC in order.
   Ans: Requirement Analysis → Design → Implementation → Testing → Deployment → Maintenance
2. Why is the Waterfall model considered risky for long projects?
   Ans: Working software appears only very late, so misunderstandings/requirement changes are discovered too late
3. Match: (a) Spiral (b) Prototype (c) RAD (d) V-Model → (i) risk-driven cycles (ii) fast, time-boxed, modular (iii) verification mirrors validation (iv) mock-up for unclear needs.
   Ans: a-i, b-iv, c-ii, d-iii
4. What are the four feasibility types normally checked before requirement analysis?
   Ans: Technical, Economic, Operational, Legal (and often Schedule)
5. State whether True/False: "Iterative and Incremental models are the same."
   Ans: False — Incremental adds new functionality per build; Iterative refines the whole system per pass
6. Name the four quadrants of one Spiral cycle in order.
   Ans: Objectives/alternatives/constraints → Risk analysis → Engineering (develop/verify) → Planning next phase
7. Which testing phase in the V-Model corresponds to Architectural Design?
   Ans: Integration Testing
8. What is the typical time-box duration in RAD?
   Ans: 60–90 days
9. List the four values of the Agile Manifesto.
   Ans: Individuals & interactions over processes/tools; Working software over documentation; Customer collaboration over contract negotiation; Responding to change over following a plan
10. Differentiate Verification and Validation in one line each.
    Ans: Verification = "are we building it right" (checked against spec); Validation = "are we building the right product" (checked against user needs)
11. Which model is best when core requirements are firm but full delivery must happen in phases?
    Ans: Incremental
12. Why can a customer mistake a prototype for the final system? What risk does this create?
    Ans: Because the prototype looks functional; risk is the customer expecting quick final delivery, causing scope/quality disputes
13. Give a scenario where Waterfall is still the appropriate choice.
    Ans: A short project with fully understood, stable requirements (e.g., a well-specified government form-processing tool)
14. What is the Scrum artifact that holds all pending product features?
    Ans: Product Backlog
15. Name the three Scrum roles.
    Ans: Product Owner, Scrum Master, Development Team
16. Why is RAD unsuitable for high-performance, technically risky systems?
    Ans: Its focus on speed/reuse/modularity doesn't allow the deep technical risk analysis such systems need
17. Explain why Spiral is considered a "meta-model" combining Waterfall and Prototyping.
    Ans: It uses systematic, phase-wise engineering (like Waterfall) within each cycle, plus repeated prototyping/customer feedback across cycles
18. A system with tight regulatory/quality-traceability requirements and stable scope should typically use which model? Justify.
    Ans: V-Model — because every development phase has a matched, planned testing/verification phase, giving strong traceability

---

Chapter 3 — Software Metrics (High-Value: Numericals)

3.1 Measurement, Metrics & Categories

SimpleA metric is a number that tells you something measurable about software — its size, cost, quality, or complexity.

Type	Measures	Examples
Product metrics	Characteristics of the software product itself	LOC, Function Points, Cyclomatic Complexity
Process metrics	Efficiency/effectiveness of the development process	Defect removal efficiency, review effectiveness
Project metrics	Progress and status of a specific project	Effort, cost, schedule variance, productivity

3.2 LOC-Based Metrics

Productivity = KLOC / Effort (person-months) Effort per KLOC = Effort / KLOC Defect Density = Total Defects / KLOC (or / Size in FP)

Worked example (NET level)A module has 20,000 lines of code and took 40 person-months. Productivity = 20 KLOC / 40 PM = 0.5 KLOC/PM.

JRF-level numericalTwo modules: Module A = 15 KLOC in 25 PM; Module B = 30 KLOC in 40 PM. Combined productivity = (15+30) / (25+40) = 45/65 = 0.69 KLOC/PM (NOT the average of the two individual productivities — a very common JRF trap: don't average ratios, recompute from totals).

Common mistakeAveraging two productivity figures directly instead of recomputing total-size/total-effort.

3.3 Function Point (FP) Analysis

IdeaMeasures functional size of software independent of the programming language, based on 5 components: External Inputs (EI), External Outputs (EO), External Inquiries (EQ), Internal Logical Files (ILF), External Interface Files (EIF).

UFP (Unadjusted FP) = Σ (count of each component × its complexity weight) FP = UFP × CAF CAF (Complexity Adjustment Factor) = 0.65 + 0.01 × Σ(14 General System Characteristics, each rated 0–5)

Worked exampleIf UFP = 100 and total GSC rating sum = 35, CAF = 0.65 + 0.01×35 = 1.00 → FP = 100×1.00 = 100 FP.

JRF-level numericalUFP = 220, Σ GSC = 20 → CAF = 0.65+0.20 = 0.85 → FP = 220×0.85 = 187. Note the CAF range is always 0.65 to 1.35 (since GSC sum ranges 0–70). A CAF outside this range in an option is automatically wrong — a fast JRF elimination trick.

3.4 LOC vs Function Point

	LOC	Function Point
Depends on language?	Yes (language-dependent)	No (language-independent)
Measured from	Actual code	Requirements/specification (usable earlier)
Best used when	Comparing same-language projects	Comparing across languages/technologies, early estimation

PYQ patternTopic: LOC vs FP — "which is language-independent and can be computed from requirements before coding?" NTA/UGC NET-style question pattern. Answer: Function Point.

3.5 Cyclomatic Complexity (Very High-Yield)

SimpleCyclomatic Complexity (CC) counts how many independent "paths" a program can take — more decision points (if/while/for) → more paths → harder to test.

CC = E − N + 2P where E = edges, N = nodes, P = connected components (usually 1) CC = P + 1 (P = number of predicate/decision nodes, for a single connected graph) CC = Number of regions in the flow-graph (including the outer region)

Worked exampleA flow graph has 11 edges, 9 nodes, 1 connected component. CC = 11 − 9 + 2(1) = 4. This also equals the number of independent paths and the minimum number of test cases needed for full branch coverage.

JRF-level numericalA program has 3 decision nodes (if/while conditions) and is a single connected graph. Using CC = P+1 → CC = 3+1 = 4. If instead this same code had 3 independent IF statements plus one WHILE loop = 4 predicate nodes → CC = 5. Always count every condition (including compound conditions like if (a AND b), which may count as TWO decision points, not one) — a frequent JRF-level trap.

Common mistakeForgetting that a compound condition (using AND/OR) can itself add extra decision points; and forgetting CC can never be less than 1 (E=N with P=1 gives CC=1, the simplest straight-line program — CC=0 is impossible).

JRF insightCC gives a lower bound on the number of independent test paths needed for branch/path coverage — it's directly used to plan white-box (structural) testing effort.

3.6 Effort & Cost Estimation (Syllabus-Relevant Basics)

Effort (Person-Months) is estimated from Size (KLOC or FP) using empirical models (e.g., COCOMO: Effort = a × (KLOC)^b ) Cost = Effort × Cost per person-month

NET pointYou are not usually expected to memorise every COCOMO constant — but you should recognise that effort is a non-linear (power) function of size, not a simple straight-line proportional relationship.

MUST REMEMBER — Chapter 3

• Productivity = Size / Effort; recompute combined productivity from totals, never average ratios.
• FP = UFP × CAF; CAF always lies between 0.65 and 1.35.
• FP components: EI, EO, EQ, ILF, EIF.
• CC = E − N + 2P = P(decision nodes) + 1 = number of regions in flow graph.
• CC gives the minimum number of independent test paths.
• Compound conditions (AND/OR) can add extra decision points to CC.
• FP is language-independent and usable pre-coding; LOC is language-dependent and post-coding.

DON'T CONFUSE

• Product metrics (about the software) vs Process metrics (about the development activity) vs Project metrics (about this specific project's progress).
• UFP vs FP (FP = UFP adjusted by CAF).

JRF CHALLENGE ZONE — Chapter 3

1. A flow graph has 16 edges and 12 nodes (1 connected component). CC = ? Answer: 16−12+2 = 6

2. UFP = 150, Σ GSC = 50. Find FP. CAF = 0.65+0.50 = 1.15; FP = 150×1.15 = 172.5

3. Which is FALSE about Cyclomatic Complexity? (a) It can be computed from the number of predicate nodes (b) A straight-line program (no decisions) has CC = 0 (c) It gives the number of independent paths (d) It helps plan white-box test cases. Answer: (b) — minimum CC is 1, not 0.

Practice Questions — Chapter 3 (16)

1. Define software metric and give one example each of product, process and project metrics.
   Ans: A quantifiable measure of a software attribute. Product — LOC; Process — defect removal efficiency; Project — effort/cost
2. A module has 12 KLOC and took 20 PM. Find productivity.
   Ans: 12/20 = 0.6 KLOC/PM
3. Two modules of 10 KLOC/20PM and 25 KLOC/30PM — find combined productivity (not average).
   Ans: (10+25)/(20+30) = 35/50 = 0.7 KLOC/PM
4. List the five components used in Function Point counting.
   Ans: External Inputs (EI), External Outputs (EO), External Inquiries (EQ), Internal Logical Files (ILF), External Interface Files (EIF)
5. What is the valid numeric range of the Complexity Adjustment Factor?
   Ans: 0.65 to 1.35
6. Compute FP if UFP = 90 and ΣGSC = 10.
   Ans: CAF = 0.65+0.10 = 0.75; FP = 90×0.75 = 67.5
7. Write the three formulas for Cyclomatic Complexity.
   Ans: CC = E−N+2P = P(decisions)+1 = number of regions in the flow graph
8. A graph has 9 edges, 7 nodes, 1 component. Find CC.
   Ans: 9−7+2 = 4
9. Why can CC never be zero?
   Ans: The minimum possible value is 1, for a straight-line program with no decisions (E=N, P=1)
10. Why does a compound (AND/OR) condition sometimes increase CC beyond simply counting "if" statements?
    Ans: Each AND/OR inside a condition can itself act as an additional decision point, adding extra independent paths
11. State one advantage of Function Points over LOC for early-stage estimation.
    Ans: FP is language-independent and can be computed from requirements, before any code is written
12. State one advantage of LOC over Function Points.
    Ans: LOC is simple, directly measurable from code, and useful for comparing same-language projects
13. What does Defect Density measure and how is it computed?
    Ans: Defects per unit size; Total Defects / KLOC (or / FP)
14. Fill in: Effort in COCOMO is a ______ (linear/non-linear) function of size.
    Ans: non-linear (power function)
15. What does Cyclomatic Complexity tell a tester about the minimum number of test cases required?
    Ans: CC gives the minimum number of independent paths/test cases needed for full branch/path coverage
16. True/False: "UFP already accounts for project complexity, so CAF is not needed." Justify.
    Ans: False — UFP only counts functional components; CAF separately adjusts for 14 general system characteristics (complexity factors)

---

Chapter 4 — Software Requirements Specification (SRS)

4.1 Requirement Engineering — Overview

Feasibility Study → Requirements Elicitation → Requirements Analysis → Requirements Specification (SRS document) → Requirements Validation → Requirements Management (handles ongoing change)

SimpleBefore writing SRS, you must first gather requirements (elicitation — talking to users, observing), then make sense of them (analysis), then write them down formally (specification), then double-check them (validation).

4.2 Functional vs Non-Functional Requirements

	Functional Requirement	Non-Functional Requirement
Means	What the system SHOULD DO (features/behaviour)	HOW WELL the system does it (quality attribute)
Example	"System shall allow user login"	"System shall respond within 2 seconds"
AKA	Behavioural requirement	Quality/constraint requirement (performance, security, usability, reliability)

JRF trap"System must encrypt passwords" LOOKS behavioural but is actually a security-related NON-functional requirement (a quality/constraint attribute), even though it's phrased as an action. Focus on WHAT KIND of property is being constrained, not just sentence phrasing.

4.3 User Requirements vs System Requirements

User requirements: high-level statements in natural language, for customers/end users (what they want, in their words). System requirements: detailed, structured, technical specification used by developers to design/build the system.

4.4 Purpose & Characteristics of a Good SRS

Characteristic	Meaning
Correct	Every requirement stated actually reflects real need
Unambiguous	Only one interpretation possible
Complete	All significant requirements are included; no "TBD" left
Consistent	No requirement contradicts another
Verifiable	A finite, cost-effective process exists to check it's met
Modifiable	Structure allows easy, consistent updates
Traceable	Origin of each requirement is clear; can be tracked through design/code/test
Ranked (for importance/stability)	Requirements are prioritised, not all treated equally

JRF-level distinction: Completeness vs ConsistencyCompleteness = nothing important is MISSING. Consistency = nothing present CONTRADICTS something else. An SRS can be complete but inconsistent (everything is there, but two sections disagree), or consistent but incomplete (nothing contradicts, but something important is missing). NET/JRF loves scenario questions built exactly on this distinction.

JRF-level distinction: Traceability vs ModifiabilityTraceability = can you trace a requirement's origin and its impact forward (to design/code/tests)? Modifiability = can the DOCUMENT be changed easily and consistently? Traceability supports modifiability but they are not the same property.

4.5 Requirements Elicitation, Analysis, Validation

• Elicitation techniques: interviews, questionnaires, observation, brainstorming, use cases, prototyping.
• Analysis: resolving conflicts, setting boundaries (scope), classifying (functional/non-functional), prioritising.
• Validation: requirement reviews, prototyping, test-case generation from requirements — checks the SRS itself is correct/complete before design begins (different from software testing/validation of the built product).

4.6 Requirement Conflicts, Ambiguity & Traceability

Trap"Ambiguity" is a language/interpretation problem (multiple valid readings); it is NOT the same as "incompleteness" (a requirement missing) or "inconsistency" (two requirements clashing). Keep these three distinct in scenario MCQs.

4.7 Common UGC NET Confusions — Scenario Table

Scenario	Classification
"The system shall generate a monthly report"	Functional requirement
"The system shall be available 99.9% of the time"	Non-functional (reliability/availability)
"Users want faster checkout" (informal, from a customer interview)	User requirement
"The checkout module shall complete a transaction in ≤3 DB calls"	System requirement
Reviewing SRS with stakeholders before design starts	Requirements validation (not software testing)
Checking that built software matches the SRS after coding	Verification (against spec)/Validation (against user need) of the product

MUST REMEMBER — Chapter 4

• Requirement engineering order: Elicitation → Analysis → Specification → Validation → Management.
• Functional = what system does; Non-functional = quality/constraint on how well.
• Eight SRS characteristics: Correct, Unambiguous, Complete, Consistent, Verifiable, Modifiable, Traceable, Ranked.
• Completeness ≠ Consistency; Traceability ≠ Modifiability; Ambiguity ≠ Incompleteness.
• User requirements = natural language, customer view; System requirements = technical, developer view.

DON'T CONFUSE

• Requirements Validation (reviewing the SRS document) vs Software Validation (testing the finished product against user needs).
• Functional requirement phrased as an action but actually describing a quality constraint (e.g., encryption, logging for audit).

JRF CHALLENGE ZONE — Chapter 4

1. An SRS states in Section 3 "response time ≤ 2 sec" and in Section 7 "response time ≤ 5 sec" for the same feature. This is a failure of: (a) Completeness (b) Consistency (c) Verifiability (d) Traceability. Answer: (b)

2. "The system shall log all failed login attempts for audit" is best classified as: (a) purely functional (b) non-functional/security-related, even though phrased as an action (c) user requirement only (d) not a valid requirement. Answer: (b)

3. Which is NOT one of the 8 standard SRS characteristics? (a) Verifiable (b) Traceable (c) Portable (d) Ranked. Answer: (c) — Portable is a software-quality attribute, not an SRS characteristic.

Practice Questions — Chapter 4 (17)

1. List the steps of requirement engineering in order.
   Ans: Elicitation → Analysis → Specification → Validation → Management
2. Differentiate functional and non-functional requirements with one example each.
   Ans: Functional — "system shall allow login"; Non-functional — "system shall respond within 2 seconds"
3. Give an example of a requirement that looks functional but is really non-functional.
   Ans: "System shall encrypt stored passwords" — phrased as an action, but is a security/quality (non-functional) requirement
4. List all 8 characteristics of a good SRS.
   Ans: Correct, Unambiguous, Complete, Consistent, Verifiable, Modifiable, Traceable, Ranked
5. Differentiate Completeness and Consistency with an example each.
   Ans: Completeness = nothing important missing (e.g., no error-handling requirement at all); Consistency = nothing contradicts (e.g., two sections giving different response-time limits)
6. Differentiate Traceability and Modifiability.
   Ans: Traceability = origin/impact of each requirement can be tracked; Modifiability = the SRS document itself can be changed easily and consistently
7. What is the difference between User requirements and System requirements?
   Ans: User requirements = high-level, natural-language, customer view; System requirements = detailed, technical, developer view
8. Name three requirement elicitation techniques.
   Ans: Interviews, questionnaires, observation (also: brainstorming, use cases, prototyping)
9. What is requirement validation, and how does it differ from software testing?
   Ans: Checking the SRS document itself is correct/complete before design; software testing checks the built product after coding
10. What does "Verifiable" mean for a requirement? Give a bad (non-verifiable) requirement example.
    Ans: A finite, cost-effective process can check it's met; bad example — "response time shall be reasonable"
11. Why must requirements be "Ranked"? What problem does this prevent?
    Ans: To prioritise effort/importance; prevents treating a trivial requirement the same as a critical one
12. Classify: "The system shall support 10,000 concurrent users."
    Ans: Non-functional (performance/scalability)
13. Classify: "The admin shall be able to delete a user account."
    Ans: Functional requirement
14. What causes "ambiguity" in a requirement? Give an example.
    Ans: Language allowing multiple interpretations, e.g., "the system shall process orders quickly" (quickly = undefined)
15. What is requirement management, and why is it needed even after the SRS is signed off?
    Ans: Managing ongoing changes to requirements; needed because requirements keep evolving even after sign-off
16. State True/False: "A complete SRS is automatically consistent." Justify.
    Ans: False — an SRS can include everything needed yet still contain contradicting statements
17. Give one technique used specifically for requirements validation.
    Ans: Requirement reviews (also: prototyping, generating test cases from requirements)

---

Chapter 5 — Software Maintenance

5.1 Why Maintenance is Needed

SimpleSoftware is never really "finished" at delivery — bugs surface, environments change, users want new features, and code needs cleanup to stay maintainable. All of this ongoing work after delivery is "maintenance."

5.2 Four Types of Maintenance

Corrective

Why: Fix a bug/defect found in production

Example: Fixing a crash on invalid input

Key word: "bug", "defect", "error"

Adaptive

Why: Environment changed (OS, hardware, regulation)

Example: Updating app for a new Android version

Key word: "environment/OS/platform changed"

Perfective

Why: Improve performance/functionality/usability

Example: Adding a new report feature; speeding up a query

Key word: "enhancement", "improve"

Preventive

Why: Reduce future maintenance difficulty

Example: Refactoring messy code before it breaks

Key word: "future-proofing", "refactor"

Memory trickC-A-P-P: Corrective = Crash fix. Adaptive = Adjust to new environment. Perfective = Performance/feature improvement. Preventive = Prevent future problems (refactor).

5.3 Scenario-Based Practice (Identify the Maintenance Type)

Pattern"Operating system changed, therefore software modified" → Adaptive maintenance.

Pattern"Bug fixed" → Corrective maintenance.

Pattern"Performance/functionality improved for existing users" → Perfective maintenance.

Pattern"Code restructured/refactored so future changes are easier, no behaviour change" → Preventive maintenance.

JRF trap"Adding a brand-new feature the customer never asked for originally, purely to enhance the product" is Perfective — NOT Adaptive (Adaptive is specifically about EXTERNAL environment change, not internal feature growth). Many students wrongly pick Adaptive whenever "change" is mentioned.

5.4 Maintenance Cost & Effort Distribution

NET pointHistorically, Perfective maintenance consumes the LARGEST share of total maintenance effort (roughly half), followed by Adaptive, then Corrective, with Preventive being the smallest share — a frequently tested ranking fact.

5.5 Legacy Systems, Reverse Engineering, Re-engineering, Refactoring

Term	Meaning
Legacy system	Old system, still in use, often poorly documented, costly to maintain
Reverse engineering	Analysing existing code/system to recover its design/specification (code → design understanding)
Re-engineering	Restructuring/rewriting an existing system to improve it (often uses reverse engineering first), without changing overall functionality
Refactoring	Small-scale internal code restructuring for cleanliness/maintainability without changing external behaviour (a form of preventive maintenance)

JRF insightOrder of the "reverse engineering pipeline": Existing System → Reverse Engineering (recover design/abstraction) → Re-engineering / Forward Engineering (rebuild improved system). Refactoring is smaller-scale and usually done continuously, not as a one-time pipeline stage.

MUST REMEMBER — Chapter 5

• Four types: Corrective (bug), Adaptive (environment), Perfective (enhancement), Preventive (future-proofing/refactor).
• Perfective maintenance typically consumes the largest share of total maintenance effort.
• Adaptive = external environment change only; new feature requests = Perfective, not Adaptive.
• Reverse engineering recovers design from code; Re-engineering rebuilds/improves the system; Refactoring is small-scale, behaviour-preserving code cleanup.

DON'T CONFUSE

• Adaptive (environment-driven) vs Perfective (feature/performance-driven) — both involve "change" but for different reasons.
• Re-engineering (system-level rebuild) vs Refactoring (code-level cleanup).

JRF CHALLENGE ZONE — Chapter 5

1. A payroll system is modified because a new government tax regulation was introduced. This is: (a) Corrective (b) Adaptive (c) Perfective (d) Preventive. Answer: (b) — external/regulatory environment change.

2. Which type of maintenance typically consumes the largest share of total effort historically? Answer: Perfective

3. Restructuring internal code with no change in external behaviour, done proactively, is: (a) Adaptive (b) Corrective (c) Preventive/Refactoring (d) Perfective. Answer: (c)

Practice Questions — Chapter 5 (12)

1. Name the four types of software maintenance.
   Ans: Corrective, Adaptive, Perfective, Preventive
2. Classify: "Fixed a null-pointer exception reported by users."
   Ans: Corrective maintenance
3. Classify: "Migrated the app because the cloud provider deprecated an old API."
   Ans: Adaptive maintenance
4. Classify: "Added a dark-mode feature by customer request."
   Ans: Perfective maintenance
5. Classify: "Refactored a module to reduce coupling before adding future features."
   Ans: Preventive maintenance
6. Which maintenance type consumes the largest share of effort historically?
   Ans: Perfective maintenance
7. Differentiate Reverse Engineering and Re-engineering.
   Ans: Reverse engineering recovers design/specification from existing code; Re-engineering rebuilds/restructures the system to improve it, generally preserving functionality
8. What is a legacy system, and why is it costly to maintain?
   Ans: An old, still-in-use system, often poorly documented — costly because understanding and safely changing it takes much longer
9. Is refactoring closer to Corrective or Preventive maintenance? Why?
   Ans: Preventive — it proactively improves code structure to reduce future maintenance difficulty, without fixing a reported bug
10. Why is "Adaptive" maintenance strictly about EXTERNAL environment changes?
    Ans: Because it is triggered by changes outside the software's control (OS, hardware, regulation) — new internal feature requests are Perfective instead
11. Give the C-A-P-P memory trick and explain each letter briefly.
    Ans: Corrective = crash/bug fix; Adaptive = adjust to new environment; Perfective = performance/feature improvement; Preventive = prevent future problems (refactor)
12. Why do legacy systems often have poor documentation, and how does this affect maintenance cost?
    Ans: They were often built long ago under different standards/staff; poor documentation raises the time and risk (hence cost) of any future change

---

One-Shot Software Engineering Revision

Definitions in one line

• Software = Program + Documentation + Operating procedures.
• Software Engineering = systematic, disciplined, quantifiable approach to build/operate/maintain software.
• SDLC = structured phase-wise process to build software (Requirement→Design→Build→Test→Deploy→Maintain).
• Software metric = quantifiable measure of a software attribute (size, cost, quality, complexity).
• SRS = formal document specifying what the system must do (and how well).
• Software maintenance = post-delivery modification of software.

SDLC models — one-line memory

• Waterfall — sequential, no early feedback.
• Prototype — mock-up first for unclear requirements.
• Incremental — new functionality per build.
• Iterative — same functionality refined per pass.
• Spiral — risk-driven repeated cycles (4 quadrants).
• V-Model — every dev phase paired with a test phase.
• RAD — fast, time-boxed (60–90 days), component-based.
• Agile — sprints, working software, customer collaboration.

Formulas

Productivity = Size(KLOC) / Effort(PM) FP = UFP × CAF, CAF = 0.65 + 0.01×ΣGSC (CAF ∈ [0.65, 1.35]) CC = E − N + 2P = P(decisions) + 1 = number of regions

SRS characteristics (8)

Correct • Unambiguous • Complete • Consistent • Verifiable • Modifiable • Traceable • Ranked

Maintenance types (C-A-P-P)

Corrective (bug) • Adaptive (environment) • Perfective (enhancement, largest share) • Preventive (future-proofing/refactor)

Top exam traps to remember

• CC minimum is 1, never 0.
• Incremental ≠ Iterative.
• Adaptive maintenance ≠ any change; it must be an external environment trigger.
• Completeness ≠ Consistency; Traceability ≠ Modifiability.
• V-Model test-phase pairing must match the exact corresponding dev phase.
• Don't average productivities across modules — recompute from totals.
• CAF always lies between 0.65 and 1.35.

Potential future exam areasPotential high-value exam area based on syllabus importance and historical question patterns: multi-statement "which of the following is/are true" questions combining an SDLC model characteristic with a metrics numerical; scenario-based SRS classification questions; and combined Cyclomatic-Complexity-plus-test-case-count numericals.

---

Software Engineering — UGC NET/JRF Mini Mock Test

45 questions across all five chapters. NTA/UGC NET-style question patterns — mixed NET/JRF difficulty, numerical, statement-based, matching and scenario-based. Answer key with explanations follows each question.

Q1. Software engineering as a discipline was formally recognised at a conference held in: (a) 1965 (b) 1968 (c) 1972 (d) 1980
Ans: (b) — NATO Software Engineering Conference. [Topic: Ch1 | NET]

Q2. Which is NOT a generic characteristic of software? (a) Engineered, not manufactured (b) Wears out physically over time (c) Custom-built (though reusable components exist) (d) Intangible
Ans: (b) [Ch1 | NET]

Q3. A project has stable, fully-understood requirements and a short timeline. The most appropriate model is: (a) Spiral (b) Waterfall (c) RAD with unclear scope (d) Prototype
Ans: (b) [Ch2 | NET]

Q4. In the Spiral model, the correct order of a single cycle's quadrants is: (a) Risk analysis → Objectives → Engineering → Planning (b) Objectives → Risk analysis → Engineering → Planning (c) Engineering → Objectives → Planning → Risk analysis (d) Planning → Engineering → Objectives → Risk analysis
Ans: (b) [Ch2 | JRF]

Q5. Match: (1) Incremental (2) Iterative (3) V-Model (4) RAD → (i) same functionality refined (ii) time-boxed, component-based (iii) new functionality per build (iv) parallel test-phase mapping
Ans: 1-iii, 2-i, 3-iv, 4-ii [Ch2 | NET]

Q6. Which of the following statements is FALSE? (a) Verification checks "are we building it right" (b) Validation checks "are we building the right product" (c) Verification typically involves reviews/inspections (d) Validation happens only before coding begins
Ans: (d) — Validation happens with a working build, i.e., after some construction, not only before coding. [Ch2 | JRF]

Q7. A flow graph has E=13, N=10, P=1. Cyclomatic Complexity = ?
Ans: 13−10+2 = 5 [Ch3 | NET numerical]

Q8. A module has 4 independent decision points including one compound (AND) condition that itself adds one extra decision point. Total CC = ?
Ans: (4+1)+1 = 6 — 4 simple decisions + 1 extra from compound condition = 5 predicate nodes; CC = P+1 = 6. [Ch3 | JRF numerical]

Q9. UFP = 180, ΣGSC = 40. Find FP.
Ans: CAF = 0.65+0.40 = 1.05; FP = 180×1.05 = 189 [Ch3 | JRF numerical]

Q10. Which lies OUTSIDE the valid CAF range and is therefore impossible? (a) 0.70 (b) 1.35 (c) 1.50 (d) 0.90
Ans: (c) — valid range is [0.65, 1.35]. [Ch3 | JRF]

Q11. Module A: 12 KLOC/24 PM. Module B: 18 KLOC/18 PM. Combined productivity = ?
Ans: (12+18)/(24+18) = 30/42 ≈ 0.71 KLOC/PM [Ch3 | JRF numerical]

Q12. Which metric category does "defect removal efficiency of code reviews" belong to? (a) Product (b) Process (c) Project (d) None
Ans: (b) [Ch3 | NET]

Q13. "The system shall allow the manager to approve leave requests" is a: (a) Non-functional requirement (b) Functional requirement (c) System constraint (d) Design decision
Ans: (b) [Ch4 | NET]

Q14. "The system shall maintain 99.5% uptime annually" is best classified as: (a) Functional (b) Non-functional/reliability (c) User requirement only (d) None
Ans: (b) [Ch4 | NET]

Q15. An SRS has no contradicting statements but is missing the error-handling requirements entirely. This SRS fails: (a) Consistency only (b) Completeness only (c) Both (d) Neither
Ans: (b) [Ch4 | JRF]

Q16. Which of these is NOT one of the eight standard SRS characteristics? (a) Traceable (b) Ranked (c) Portable (d) Verifiable
Ans: (c) [Ch4 | NET]

Q17. "The admin panel shall encrypt stored passwords using a salted hash" — best classified as: (a) Purely functional, no other classification needed (b) Non-functional/security requirement, though phrased as an action (c) User requirement only (d) Cannot be classified
Ans: (b) [Ch4 | JRF]

Q18. Reviewing a draft SRS with stakeholders to check it reflects real needs, before design starts, is called: (a) Software testing (b) Requirements validation (c) Verification of code (d) Requirements elicitation
Ans: (b) [Ch4 | NET]

Q19. A banking app is updated purely because the mobile OS deprecated an old permissions API. This is: (a) Corrective (b) Adaptive (c) Perfective (d) Preventive
Ans: (b) [Ch5 | NET]

Q20. A team refactors a module (no behaviour change) purely to make future feature additions easier. This is: (a) Corrective (b) Adaptive (c) Perfective (d) Preventive
Ans: (d) [Ch5 | NET]

Q21. Historically, which maintenance type consumes the largest share of total maintenance effort? (a) Corrective (b) Adaptive (c) Perfective (d) Preventive
Ans: (c) [Ch5 | NET]

Q22. Which of the following is FALSE? (a) Reverse engineering recovers design from code (b) Re-engineering always changes the external functionality of the system (c) Refactoring preserves external behaviour (d) Legacy systems are often poorly documented
Ans: (b) — re-engineering improves the system without necessarily changing overall functionality. [Ch5 | JRF]

Q23. "A new report-generation feature is added purely to improve usability, not requested due to any external change" — this is: (a) Adaptive (b) Perfective (c) Corrective (d) Preventive
Ans: (b) [Ch5 | JRF]

Q24. Which statement about the Waterfall model is TRUE? (a) It allows unrestricted feedback to any earlier phase (b) It provides working software very early (c) It is best when requirements are well understood and stable (d) It is the most flexible model to changing requirements
Ans: (c) [Ch2 | NET]

Q25. Which pairing in the V-Model is INCORRECT? (a) Requirements ↔ Acceptance Testing (b) System Design ↔ System Testing (c) Module Design ↔ Integration Testing (d) Architectural Design ↔ Integration Testing
Ans: (c) — Module Design pairs with Unit Testing, not Integration Testing. [Ch2 | JRF]

Q26. A flow graph has 3 predicate (decision) nodes and is a single connected component. CC = ?
Ans: 3+1 = 4 [Ch3 | NET numerical]

Q27. Which of the following, if true, would make an SRS non-verifiable? (a) "Response time shall be reasonable" (b) "Response time shall not exceed 2 seconds" (c) "System shall log all errors" (d) "System shall support 500 users"
Ans: (a) — "reasonable" cannot be objectively tested. [Ch4 | JRF]

Q28. Which model explicitly and repeatedly performs risk analysis as a core activity in every cycle? (a) Waterfall (b) Spiral (c) RAD (d) V-Model
Ans: (b) [Ch2 | NET]

Q29. True/False: "Function Points can be computed before any code is written." Justify in one line.
Ans: True — FP is based on requirements/specifications (EI, EO, EQ, ILF, EIF), not code. [Ch3 | NET]

Q30. Which of these BEST distinguishes Incremental from Iterative development? (a) Incremental refines the same features; Iterative adds new ones (b) Incremental adds new functional capability per build; Iterative refines the whole system per pass (c) They are identical (d) Iterative is only used in Agile
Ans: (b) [Ch2 | JRF]

Q31. A defect is found and fixed after deployment because a user reported a crash on a specific input. This is: (a) Adaptive (b) Corrective (c) Perfective (d) Preventive
Ans: (b) [Ch5 | NET]

Q32. Which of the following is a User requirement rather than a System requirement? (a) "API shall return JSON with a 200 status" (b) "Customers want to check their order status easily" (c) "DB index shall be created on order_id" (d) "Response payload shall not exceed 2MB"
Ans: (b) [Ch4 | NET]

Q33. Which of the following is TRUE regarding software's characteristics? (a) It deteriorates due to physical wear (b) It deteriorates due to repeated change/maintenance side-effects (c) It cannot be reused in any form (d) It is manufactured identically each time from raw materials
Ans: (b) [Ch1 | NET]

Q34. Two developers separately compute productivity for their own modules as 0.4 KLOC/PM and 0.8 KLOC/PM. The COMBINED team productivity: (a) is always 0.6 KLOC/PM (simple average) (b) must be recomputed as total KLOC / total PM (c) cannot be determined (d) equals the higher value
Ans: (b) [Ch3 | JRF]

Q35. Which SDLC model is most associated with the phrase "does not provide working software until very late in the process"? (a) Agile (b) Prototype (c) Waterfall (d) Incremental
Ans: (c) [Ch2 | NET]

Q36. "Requirements are elicited, then structured into a formal document, then reviewed with stakeholders" — this sequence corresponds to: (a) Elicitation → Specification → Validation (b) Specification → Elicitation → Validation (c) Validation → Elicitation → Specification (d) Analysis → Validation → Elicitation
Ans: (a) [Ch4 | NET]

Q37. A system has CC = 1 for a particular module. What does this indicate? (a) The module has no decision points (straight-line code) (b) The module is invalid (c) The module has maximum complexity (d) CC = 1 is impossible
Ans: (a) [Ch3 | NET]

Q38. Which of these is the correct definition of Re-engineering? (a) Writing brand-new requirements from scratch (b) Restructuring/rebuilding an existing system to improve it, generally preserving overall functionality (c) Only fixing bugs in legacy code (d) Testing a system after deployment
Ans: (b) [Ch5 | NET]

Q39. Which statement about RAD is FALSE? (a) It uses short, fixed time-boxes (b) It requires the system to be modularisable (c) It is ideal for high-performance, technically risky systems (d) It relies heavily on component reuse
Ans: (c) [Ch2 | JRF]

Q40. Match: (1) Corrective (2) Adaptive (3) Perfective (4) Preventive → (i) refactor for future ease (ii) fix reported bug (iii) new OS support (iv) enhance existing feature
Ans: 1-ii, 2-iii, 3-iv, 4-i [Ch5 | NET]

Q41. A flow graph has E=20, N=15, P=1. Also assume 2 disconnected exception-handling subgraphs exist not counted in P. If P should actually be taken as 1 (single connected component per standard convention for a single program unit), CC = ?
Ans: 20−15+2(1) = 7 [Ch3 | JRF numerical]

Q42. Which of the following about Agile is TRUE per the Agile Manifesto? (a) Documentation is prioritised over working software (b) Contract negotiation is prioritised over customer collaboration (c) Responding to change is valued over following a rigid plan (d) Processes/tools are valued over individuals and interactions
Ans: (c) [Ch2 | NET]

Q43. An SRS states two different maximum file-upload sizes in two different sections. This is a failure of: (a) Verifiability (b) Consistency (c) Traceability (d) Ranking
Ans: (b) [Ch4 | NET]

Q44. Given UFP = 200 and FP = 170, find ΣGSC (approx).
Ans: CAF = 170/200 = 0.85 = 0.65+0.01×ΣGSC → ΣGSC = 20 [Ch3 | JRF numerical]

Q45. Which of the following correctly ranks the typical share of total maintenance effort from HIGHEST to LOWEST? (a) Perfective > Adaptive > Corrective > Preventive (b) Corrective > Perfective > Adaptive > Preventive (c) Adaptive > Perfective > Corrective > Preventive (d) Preventive > Corrective > Adaptive > Perfective
Ans: (a) [Ch5 | JRF]

— End of Mock Test — Cross-check your score, revisit the "Don't Confuse" and "JRF Challenge Zone" boxes for any topic you missed, then re-attempt after 48 hours. —

Share: