2026 question paper

Software Engineering

28 questions

Q1a. Which SDLC model explicitly incorporates risk analysis into every development cycle? (i) Waterfall (ii) Code-and-Fix (iii) Spiral (iv) Incremental20262m
Module 1: Introduction & SDLC
Which SDLC model explicitly incorporates risk analysis into every development cycle?

(i) Waterfall
(ii) Code-and-Fix
(iii) Spiral
(iv) Incremental

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iii) Spiral

Explanation

The Spiral Model (Barry Boehm) is a risk-driven process model. Every loop of the spiral contains an explicit Risk Analysis phase, where risks are identified and resolved (often through prototyping) before the next loop begins.

Why other options are incorrect:

(i) Waterfall - Linear and sequential; has no explicit risk analysis step.

(ii) Code-and-Fix - Ad hoc coding with no planning or risk handling.

(iv) Incremental - Delivers the product in increments, but does not build risk analysis into every cycle.

Key Points to Remember:

Four quadrants of Spiral: Objective Setting, Risk Assessment & Reduction, Development & Validation, Planning.

Best suited for large, complex, high-risk projects.

Answer: (iii) Spiral
Q1b. Brooks' "No Silver Bullet" argument primarily concerns the difficulty of reducing (i) Hardware cost (ii) Compilation time (iii) Essential complexity of software (iv) Database size20262m
Module 1: Introduction & SDLC
Brooks' "No Silver Bullet" argument primarily concerns the difficulty of reducing

(i) Hardware cost
(ii) Compilation time
(iii) Essential complexity of software
(iv) Database size

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iii) Essential complexity of software

Explanation

In his paper "No Silver Bullet" (1986), Fred Brooks separates software difficulty into:

Accidental complexity - caused by tools, languages and methods; technology can reduce it.

Essential complexity - inherent in the problem itself (complexity, conformity, changeability, invisibility).

His argument: no single technique can give an order-of-magnitude improvement in productivity, because the hard part is the essential complexity of the problem, not the tools.

Why other options are incorrect:

(i) Hardware cost and (iv) Database size - not part of Brooks' argument.

(ii) Compilation time - a tool-level (accidental) issue.

Answer: (iii) Essential complexity of software
Q1c. A requirement expected to change because of evolving business conditions is classified as (i) Enduring requirement (ii) Structural requirement (iii) Volatile requirement (iv) Derived requirement20262m
Module 2: Requirements & SRS
A requirement expected to change because of evolving business conditions is classified as

(i) Enduring requirement
(ii) Structural requirement
(iii) Volatile requirement
(iv) Derived requirement

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iii) Volatile requirement

Explanation

Requirements are classified by how stable they are:

Enduring requirements - stable, tied to the core activity of the organization; they change rarely.

Volatile requirements - likely to change during development or after delivery because of evolving business conditions, policies, laws or technology.

A requirement expected to change because of evolving business conditions is therefore volatile.

Why other options are incorrect:

(i) Enduring - the opposite: stable and long-lasting.

(ii) Structural - not a standard stability category.

(iv) Derived - a requirement obtained from other requirements, not defined by how often it changes.

Answer: (iii) Volatile requirement
Q1d. Which characteristic of an SRS indicates that every requirement has only one clear interpretation? (i) Complete (ii) Unambiguous (iii) Consistent (iv) Modifiable20262m
Module 2: Requirements & SRS
Which characteristic of an SRS indicates that every requirement has only one clear interpretation?

(i) Complete
(ii) Unambiguous
(iii) Consistent
(iv) Modifiable

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) Unambiguous

Explanation

An unambiguous SRS ensures that every requirement has exactly one interpretation, so the client, developers and testers all understand it the same way. This is achieved with precise language, defined terms, and formal or structured notations where needed.

Why other options are incorrect:

(i) Complete - all required functions, constraints and interfaces are included.

(iii) Consistent - no requirement conflicts with another.

(iv) Modifiable - the document can be changed easily while keeping its structure.

Key Points to Remember:

Characteristics of a good SRS: correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, traceable.

Answer: (ii) Unambiguous
Q1e. Which combination generally represents desirable modular design? (i) High coupling and low cohesion (ii) Low coupling and high cohesion (iii) High coupling and high cohesion (iv) Low coupling and low cohesion20262m
Module 3: Software Design & Metrics
Which combination generally represents desirable modular design?

(i) High coupling and low cohesion
(ii) Low coupling and high cohesion
(iii) High coupling and high cohesion
(iv) Low coupling and low cohesion

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) Low coupling and high cohesion

Explanation

Cohesion = how strongly the elements inside one module are related. High is good.

Coupling = how dependent modules are on each other. Low is good.

A good modular design has high cohesion within modules and low coupling between modules, which makes software easier to understand, test, maintain and reuse.

Why other options are incorrect:

(i) High coupling, low cohesion - the worst combination.

(iii) High coupling, high cohesion - modules are focused but too dependent on each other.

(iv) Low coupling, low cohesion - independent modules, but each does unrelated things.

Answer: (ii) Low coupling and high cohesion
Q1f. A DFD primarily represents (i) Program execution time (ii) Source-code complexity (iii) Class inheritance (iv) Flow and transformation of data20262m
Module 3: Software Design & Metrics
A DFD primarily represents

(i) Program execution time
(ii) Source-code complexity
(iii) Class inheritance
(iv) Flow and transformation of data

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iv) Flow and transformation of data

Explanation

A Data Flow Diagram (DFD) models how data flows through a system and how processes transform it. Its four elements are: processes, data flows, data stores and external entities.

A DFD shows what happens to data, not when or how the code runs.

Why other options are incorrect:

(i) Program execution time - not shown in a DFD.

(ii) Source-code complexity - measured by metrics such as cyclomatic complexity.

(iii) Class inheritance - shown in UML class diagrams.

Answer: (iv) Flow and transformation of data
Q1g. Which representation is most suitable for showing different actions corresponding to combinations of conditions? (i) Decision table (ii) Data dictionary (iii) Structure chart (iv) Control-flow graph20262m
Module 2: Requirements & SRS
Which representation is most suitable for showing different actions corresponding to combinations of conditions?

(i) Decision table
(ii) Data dictionary
(iii) Structure chart
(iv) Control-flow graph

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (i) Decision table

Explanation

A decision table lists conditions and the actions to take for each combination of those conditions, in a compact tabular form. Each column (rule) maps one combination of condition values to its actions, which makes it ideal for complex business logic.

Why other options are incorrect:

(ii) Data dictionary - stores definitions of data items.

(iii) Structure chart - shows the module hierarchy and calls.

(iv) Control-flow graph - shows the flow of control in a program (used for path testing and cyclomatic complexity).

Answer: (i) Decision table
Q1h. Halstead's software science primarily uses counts of (i) Modules and classes (ii) Operators and operands (iii) Test cases and defects (iv) Inputs and outputs only20262m
Module 3: Software Design & Metrics
Halstead's software science primarily uses counts of

(i) Modules and classes
(ii) Operators and operands
(iii) Test cases and defects
(iv) Inputs and outputs only

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (ii) Operators and operands

Explanation

Halstead's software science measures a program using counts of its operators and operands:

n1 = distinct operators, n2 = distinct operands

N1 = total operators, N2 = total operands

From these:

Vocabulary n = n1 + n2

Length N = N1 + N2

Volume V = N × log2(n)

Why other options are incorrect:

(i) Modules and classes - used in design metrics, not Halstead.

(iii) Test cases and defects - testing/quality metrics.

(iv) Inputs and outputs only - that is closer to Function Point Analysis.

Answer: (ii) Operators and operands
Q1i. Cyclomatic complexity of a connected control-flow graph with E edges, N nodes and P connected components is (i) E+N+P (ii) E-N-P (iii) N-E+2P (iv) E-N+2P20262m
Module 3: Software Design & Metrics
Cyclomatic complexity of a connected control-flow graph with E edges, N nodes and P connected components is

(i) E+N+P
(ii) E-N-P
(iii) N-E+2P
(iv) E-N+2P

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (iv) E - N + 2P

Explanation

McCabe's cyclomatic complexity of a control-flow graph with E edges, N nodes and P connected components is:

V(G) = E - N + 2P

For a single connected program (P = 1) this becomes V(G) = E - N + 2. It also equals:

number of predicate (decision) nodes + 1

number of regions in the planar graph

It gives the number of linearly independent paths, i.e. the minimum number of test cases for branch coverage.

Why other options are incorrect:

(i) E+N+P, (ii) E-N-P, (iii) N-E+2P - not valid forms of the formula.

Answer: (iv) E - N + 2P
Q1j. Configuration management primarily provides control over (i) Software versions and changes (ii) Computer hardware temperature (iii) Programming language syntax (iv) Employee attendance20262m
Module 5: Software Maintenance
Configuration management primarily provides control over

(i) Software versions and changes
(ii) Computer hardware temperature
(iii) Programming language syntax
(iv) Employee attendance

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution

Correct Answer: (i) Software versions and changes

Explanation

Software Configuration Management (SCM) controls how the items that make up a software product (code, documents, test cases, build scripts) change over time. Its main activities are:

Configuration identification - naming and versioning items

Version control - managing versions and branches

Change control - reviewing and approving changes

Configuration auditing and status reporting

Why other options are incorrect:

(ii) Hardware temperature and (iv) Employee attendance - unrelated to SCM.

(iii) Language syntax - handled by compilers and coding standards.

Answer: (i) Software versions and changes
Budget App•POCKETLY
Pocketly on Android
Log daily food, travel, and hostel expenses instantly. Set monthly spending limits and see where your money goes without complex spreadsheets.
Install Pocketly

Q2a. A project manager is considering Waterfall, Incremental and Spiral models for a safety-critical system. Construct a comparative decision matrix using risk, requirement volatility, feedback and delivery characteristics and justify the selection criteria.20267m

Module 1: Introduction & SDLC

A project manager is considering Waterfall, Incremental and Spiral models for a safety-critical system. Construct a comparative decision matrix using risk, requirement volatility, feedback and delivery characteristics and justify the selection criteria.

View this question on its own page →

Search Google Ask AI

Worked Solution

Decision Matrix: Waterfall vs Incremental vs Spiral for a Safety-Critical System

Selection criteria

For a safety-critical system a failure can cause injury or loss of life, so risk handling matters most. The other criteria are requirement volatility, feedback and delivery.

Comparative matrix

Criterion	Waterfall	Incremental	Spiral
Risk	Weak: risks surface late, mostly during testing	Moderate: risk handled per increment	Strong: explicit risk analysis in every loop
Requirement volatility	Poor: requirements frozen early	Good: new needs go into later increments	Good: requirements refined every loop
Feedback	Late: only after testing/delivery	After every increment	After every loop (prototype + review)
Delivery	Single big-bang release	Early partial working releases	Versions/prototypes; final release after several loops

Weighted score (scale 1 to 5, illustrative)

Criterion (weight)	Waterfall	Incremental	Spiral
Risk (0.4)	2	3	5
Volatility (0.2)	1	4	4
Feedback (0.2)	1	4	4
Delivery (0.2)	2	5	3
Weighted total	1.6	3.8	4.2

Example: Spiral = 0.4(5) + 0.2(4) + 0.2(4) + 0.2(3) = 4.2.

Justification

Risk has the highest weight because hazards in a safety-critical system must be found and removed early.
Spiral scores highest: each loop has a risk-analysis step, prototypes are evaluated, and verification can be repeated before the next loop.
Waterfall gives strong documentation but finds risks too late and cannot absorb change.
Incremental gives early feedback but has no built-in risk analysis.

Decision: Spiral, keeping Waterfall-style rigorous documentation, reviews and verification inside each loop. If the requirements are well understood and risk is low, Incremental is the fallback.

Note: scores and weights are judgement-based; state your assumptions in the exam.

Q2b. Compare Agile development with a conventional sequential process in terms of iteration, customer participation, requirement change and software delivery.20267m

Module 1: Introduction & SDLC

Compare Agile development with a conventional sequential process in terms of iteration, customer participation, requirement change and software delivery.

View this question on its own page →

Search Google Ask AI

Worked Solution

Agile Development vs Conventional Sequential Process

Sequential process (e.g. Waterfall): requirements, design, coding, testing and delivery happen once, in fixed order.
Agile: software is built in short iterations (sprints) of 1 to 4 weeks, each producing a working increment, with continuous customer involvement.

Comparison

Aspect	Agile	Conventional sequential
Iteration	Many short iterations; every cycle repeats analysis, design, code and test	Single pass through each phase; no return to earlier phases without rework
Customer participation	Continuous: customer reviews every iteration and prioritizes the backlog	Mainly at the start (requirements) and end (acceptance)
Requirement change	Welcomed, even late; changes enter the backlog for later sprints	Resisted; requirements frozen early, changes are costly
Software delivery	Frequent, working increments (every sprint)	One delivery at the end of the project
Documentation	Light; working software valued over documents	Heavy, formal, phase-wise
Risk	Found early through frequent feedback	Found late, during testing
Planning	Adaptive; plan per iteration	Detailed up-front plan
Suitable for	Changing or unclear requirements	Stable, well-understood requirements

Conclusion

Agile gives faster feedback, easier handling of change and earlier value to the customer. A sequential process gives predictability and thorough documentation, which suits fixed, stable requirements. Examples of Agile methods: Scrum, XP, Kanban.

Q3a. Construct an SRS-oriented requirement analysis for a hotel management system covering major user needs, functional requirements, constraints and quality requirements.20267m

Module 2: Requirements & SRS

Construct an SRS-oriented requirement analysis for a hotel management system covering major user needs, functional requirements, constraints and quality requirements.

View this question on its own page →

Search Google Ask AI

Worked Solution

SRS-Oriented Requirement Analysis: Hotel Management System

1. Introduction

Purpose: automate room booking, check-in/out, billing and housekeeping for a hotel.
Scope: reception, guests, housekeeping, restaurant billing, management reports.
Users: Guest, Receptionist, Housekeeping staff, Manager/Admin.

2. Major user needs

User	Need
Guest	Search available rooms, book/cancel online, view bill
Receptionist	Quick check-in/out, room allocation, payment collection
Housekeeping	See room status (clean/dirty/occupied), task list
Manager	Occupancy, revenue and staff reports

3. Functional requirements

FR1 Room management: add/update rooms, types and tariffs; show real-time availability.
FR2 Reservation: book, modify, cancel a room for given dates; prevent double booking.
FR3 Check-in/Check-out: record guest ID, allocate room, close the stay.
FR4 Billing: calculate room charges, taxes, restaurant/service charges; generate invoice.
FR5 Payment: cash, card and online payment; issue receipt.
FR6 Housekeeping: update and track room status.
FR7 Reports: daily occupancy, revenue, guest history.
FR8 User management: role-based login.

4. Constraints

Must run on a web browser and a standard database (e.g. MySQL).
Must follow tax/billing laws and guest-ID record rules.
Payment through an approved gateway; fixed budget and delivery time.
Must work with existing hardware (reception PCs, printers).

5. Quality (non-functional) requirements

Quality	Requirement
Performance	Search/booking response within 3 seconds for up to 100 concurrent users
Security	Encrypted passwords, role-based access, secure payments
Reliability/Availability	99.5% uptime; daily backups
Usability	Simple screens; staff trained within one day
Scalability	Support more rooms/branches later
Maintainability	Modular design with documentation

6. Assumptions

Online payment gateway and internet are available; figures such as response time are assumed values.

In the exam, present these in the IEEE SRS layout: Introduction, Overall Description, Specific Requirements.

Q3b. Develop a decision table for an online loan-processing system using customer eligibility, income level, credit score and document verification as conditions. Derive the corresponding system actions.20267m

Module 2: Requirements & SRS

Develop a decision table for an online loan-processing system using customer eligibility, income level, credit score and document verification as conditions. Derive the corresponding system actions.

View this question on its own page →

Search Google Ask AI

Worked Solution

Decision Table: Online Loan-Processing System

Conditions

C1 Customer eligible? (Y/N)
C2 Income level adequate? (Y/N)
C3 Credit score good? (Y/N)
C4 Documents verified? (Y/N)

Actions

A1 Approve loan
A2 Reject loan
A3 Request additional documents
A4 Refer to manual review (e.g. reduced amount or higher interest)

Decision table ("-" = don't care)

	R1	R2	R3	R4	R5	R6
C1 Eligible	N	Y	Y	Y	Y	Y
C2 Income adequate	-	-	Y	Y	N	N
C3 Credit score good	-	-	Y	N	Y	N
C4 Documents verified	-	N	Y	Y	Y	Y
A1 Approve loan			X
A2 Reject loan	X					X
A3 Request documents		X
A4 Manual review				X	X

Derived system actions

R1: not eligible, so reject whatever the other conditions are.
R2: eligible but documents not verified, so request more documents.
R3: eligible, income adequate, good credit, documents verified, so approve.
R4 / R5: eligible and documents verified, but only one of income/credit is satisfactory, so manual review.
R6: eligible and documents verified, but both income and credit are poor, so reject.

Completeness check

Without "don't cares" the table needs 2^4 = 16 rules. R1 covers 8, R2 covers 4, and R3 to R6 cover 1 each (documents verified = Y), so 8 + 4 + 4 = 16: every combination is covered and none overlaps.

The business rules above are assumptions; state them in the exam.

Q4a. Compare different types of coupling and cohesion and determine which combination should be targeted for a maintainable modular system.20267m

Module 3: Software Design & Metrics

Compare different types of coupling and cohesion and determine which combination should be targeted for a maintainable modular system.

View this question on its own page →

Search Google Ask AI

Worked Solution

Coupling and Cohesion: Types, Comparison and Target Combination

Coupling = interdependence between modules (want it low).
Cohesion = relatedness of elements within a module (want it high).

Types of coupling (best to worst)

Type	Meaning	Quality
Data	Modules share only simple parameters	Best
Stamp	Share a composite structure (record) but use only part of it	Good
Control	One module passes a flag that controls the other's logic	Moderate
External	Share an external device, format or protocol	Poor
Common	Share global data	Poor
Content	One module modifies or jumps into another's internals	Worst

Types of cohesion (worst to best)

Type	Meaning	Quality
Coincidental	Unrelated tasks grouped randomly	Worst
Logical	Tasks of the same category, selected by a flag (e.g. all input routines)	Poor
Temporal	Tasks executed at the same time (e.g. initialization)	Poor
Procedural	Tasks follow a fixed order of execution	Moderate
Communicational	Tasks work on the same data	Good
Sequential	Output of one task is input to the next	Better
Functional	All elements contribute to one single function	Best

Comparison

Basis	Coupling	Cohesion
Concerns	Between modules	Within a module
Goal	Minimize	Maximize
Measures	Dependence	Relatedness
Effect when poor	Changes ripple across modules	Module is hard to understand

Target combination for a maintainable modular system

Low coupling (data coupling) with high cohesion (functional cohesion).

A change stays inside one module, so maintenance is cheaper.
Modules can be tested, reused and developed independently.
Errors do not spread to other modules.

Avoid content/common coupling and coincidental/logical cohesion.

Q4b. Construct a DFD for an online library system that supports registration, book search, issue/return and fine calculation. Show the major data stores and external entities.20267m

Module 3: Software Design & Metrics

Construct a DFD for an online library system that supports registration, book search, issue/return and fine calculation. Show the major data stores and external entities.

View this question on its own page →

Search Google Ask AI

Worked Solution

DFD for an Online Library System

Elements

External entities: Member, Librarian
Processes: 1.0 Register Member, 2.0 Search Book, 3.0 Issue Book, 4.0 Return Book, 5.0 Calculate Fine
Data stores: D1 Member File, D2 Book Catalogue, D3 Issue/Return Record, D4 Fine Record

Level 0: Context diagram

                registration details, search request,
                issue / return request, fine payment
   [ Member ] ------------------------------------> (  0  Online  )
   [ Member ] <------------------------------------ (  Library    )
                login status, search results,         (  System     )
                issue slip, fine receipt                  ^   |
                                                          |   v
   [ Librarian ] -- book details, member approval --------+   |
   [ Librarian ] <-------- reports, overdue list -------------+

Level 1 DFD

[Member]--registration details-->(1.0 Register Member)--member record-->[D1 Member File]
[Member]--search request-->(2.0 Search Book)<--book data--[D2 Book Catalogue]
(2.0 Search Book)--search results-->[Member]
[Member]--issue request-->(3.0 Issue Book)
(3.0 Issue Book)<--member check--[D1 Member File]
(3.0 Issue Book)<--availability / update copies-->[D2 Book Catalogue]
(3.0 Issue Book)--issue entry-->[D3 Issue/Return Record]
(3.0 Issue Book)--issue slip-->[Member]
[Member]--return request-->(4.0 Return Book)
(4.0 Return Book)<--issue entry-->[D3 Issue/Return Record]
(4.0 Return Book)--update copies-->[D2 Book Catalogue]
(4.0 Return Book)--return date-->(5.0 Calculate Fine)
(5.0 Calculate Fine)--fine record-->[D4 Fine Record]
(5.0 Calculate Fine)--fine receipt-->[Member]
[Librarian]--book details-->[D2 Book Catalogue]
[Librarian]<--overdue / fine reports--[D3, D4]

Data flow summary

Process	Inputs	Outputs
1.0 Register Member	Registration details	Member record to D1, confirmation
2.0 Search Book	Search request, D2 data	Search results
3.0 Issue Book	Issue request, D1, D2	Issue entry to D3, updated D2, issue slip
4.0 Return Book	Return request, D3	Updated D3 and D2, return date
5.0 Calculate Fine	Return date, due date	Fine to D4, fine receipt

Rules followed

Every process has at least one input and one output.
Data stores connect only to processes, never directly to entities.
Data flows are labelled; the Level 1 inputs and outputs match the context diagram (balancing).

In the exam, draw the diagram with circles (processes), rectangles (entities), open rectangles (data stores) and labelled arrows.

Q5a. For a program segment containing one loop and three conditional branches, construct its control-flow graph and calculate McCabe's cyclomatic complexity. Relate the result to the minimum number of independent paths.20267m

Module 3: Software Design & Metrics

For a program segment containing one loop and three conditional branches, construct its control-flow graph and calculate McCabe's cyclomatic complexity. Relate the result to the minimum number of independent paths.

View this question on its own page →

Search Google Ask AI

Worked Solution

Control-Flow Graph and McCabe's Cyclomatic Complexity

Assumed program segment (1 loop + 3 conditional branches)

1  i = 0;
2  while (i < n) {          // loop condition
3     if (a[i] > 0)         // branch 1
4         pos++;
5     if (a[i] < 0)         // branch 2
6         neg++;
7     if (a[i] == 0)        // branch 3
8         zero++;
9     i++;
   }
10 print(pos, neg, zero);

Control-flow graph

Nodes (N = 10): 1 to 10, one per statement/decision.
Edges (E = 13): 1-2, 2-3, 2-10, 3-4, 3-5, 4-5, 5-6, 5-7, 6-7, 7-8, 7-9, 8-9, 9-2.
Predicate nodes (4): node 2 (loop), nodes 3, 5, 7 (branches).

1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 9 -> (back to 2)
     |    \_____/    \_____/    \_____/
     |   (3 skips 4)(5 skips 6)(7 skips 8)
     +-> 10 (loop exit)

Cyclomatic complexity (three equivalent methods)

V(G) = E - N + 2 = 13 - 10 + 2 = 5
V(G) = P + 1 (P = predicate nodes) = 4 + 1 = 5
V(G) = number of regions = 5 (4 bounded regions + 1 outer region)

Independent paths (V(G) = 5)

Path	Route	Meaning
P1	1-2-10	Loop never entered
P2	1-2-3-5-7-9-2-10	All branches false
P3	1-2-3-4-5-7-9-2-10	Branch 1 true
P4	1-2-3-5-6-7-9-2-10	Branch 2 true
P5	1-2-3-5-7-8-9-2-10	Branch 3 true

Each path adds at least one new edge not used by earlier paths, so they are linearly independent.

Relation to the minimum number of independent paths

V(G) equals the number of linearly independent paths in the graph. It is therefore the minimum number of test cases needed to execute every statement and every branch at least once (basis path testing). Here at least 5 test cases are required.

V(G)	Risk
1 to 10	Simple, low risk
11 to 20	Moderate
21 to 50	High
over 50	Untestable

A complexity of 5 means a simple, easily testable module.

Q5b. A project has 30 external inputs, 60 external outputs, 23 external inquiries, 8 files and 2 external interfaces. The corresponding complexity weights are 4, 5, 4, 10 and 7. Four of the fourteen value-adjustment factors have value 0, four have value 3 and the remaining six have value 4. Calculate the Function Point value.20267m

Module 3: Software Design & Metrics

A project has 30 external inputs, 60 external outputs, 23 external inquiries, 8 files and 2 external interfaces. The corresponding complexity weights are 4, 5, 4, 10 and 7. Four of the fourteen value-adjustment factors have value 0, four have value 3 and the remaining six have value 4. Calculate the Function Point value.

View this question on its own page →

Search Google Ask AI

Worked Solution

Function Point Calculation

Formula: FP = UFP x VAF

UFP (Unadjusted Function Points) = sum of (count x weight) for the five components
VAF (Value Adjustment Factor) = 0.65 + 0.01 x (sum of the 14 factor ratings)

Step 1: Unadjusted Function Points

Component	Count	Weight	Count x Weight
External Inputs (EI)	30	4	120
External Outputs (EO)	60	5	300
External Inquiries (EQ)	23	4	92
Internal Logical Files (ILF)	8	10	80
External Interface Files (EIF)	2	7	14
UFP			606

Step 2: Value Adjustment Factor

The 14 factors (rated 0 to 5):

4 factors with value 0: 4 x 0 = 0
4 factors with value 3: 4 x 3 = 12
6 factors with value 4: 6 x 4 = 24

Sum of ratings (ΣFi) = 0 + 12 + 24 = 36

VAF = 0.65 + 0.01 x 36 = 0.65 + 0.36 = 1.01

Step 3: Function Points

FP = UFP x VAF = 606 x 1.01 = 612.06

Answer

Function Point value = 612.06 (about 612 FP)

Since VAF is slightly above 1, the system is a little more complex than average, so the adjusted size is a little higher than the unadjusted count.

Q6a. Compare black-box and white-box testing with respect to information used for test-case design, typical techniques and defect types detected.20267m

Module 4: Software Testing

Compare black-box and white-box testing with respect to information used for test-case design, typical techniques and defect types detected.

View this question on its own page →

Search Google Ask AI

Worked Solution

Black-Box vs White-Box Testing

Black-box testing tests the software without looking at the code, using only the specification (inputs and expected outputs).
White-box testing tests the internal structure and logic of the code.

Comparison

Basis	Black-box testing	White-box testing
Information used for test-case design	Requirements/specification, input and output domains	Source code, control-flow and data-flow structure
Knowledge of code needed	No	Yes
Typical techniques	Equivalence class partitioning, boundary value analysis, decision table testing, cause-effect graphing, state-transition testing	Statement coverage, branch/decision coverage, condition coverage, path testing (basis paths), data-flow testing, mutation testing
Defect types detected	Missing or incorrect functions, interface errors, wrong output, input/output (boundary) errors, incorrect specification handling	Logical errors, unreachable or dead code, wrong conditions, loop errors, incorrect data usage, uncovered paths
Performed by	Testers / independent test team	Developers
Test level	Mostly system and acceptance	Mostly unit and integration
Limitations	Cannot find hidden code paths or dead code	Cannot find missing functionality

Conclusion

The two are complementary. Black-box testing checks that the software does what the customer asked for; white-box testing checks that the code is built correctly. A good test strategy uses both (grey-box testing combines them).

Q6b. A program accepts marks from 0 to 100. Construct test cases using Boundary Value Analysis and Equivalence Class Testing and compare the resulting test sets.20267m

Module 4: Software Testing

A program accepts marks from 0 to 100. Construct test cases using Boundary Value Analysis and Equivalence Class Testing and compare the resulting test sets.

View this question on its own page →

Search Google Ask AI

Worked Solution

Test Cases for Marks (0 to 100): BVA and Equivalence Class Testing

Valid range: 0 <= marks <= 100 (integers). Anything else must be rejected with an error message.

1. Boundary Value Analysis (BVA)

Test at and around each boundary (min-1, min, min+1, nominal, max-1, max, max+1):

TC	Input	Expected output
B1	-1	Invalid (just below minimum)
B2	0	Valid (minimum)
B3	1	Valid (just above minimum)
B4	50	Valid (nominal)
B5	99	Valid (just below maximum)
B6	100	Valid (maximum)
B7	101	Invalid (just above maximum)

Total = 7 test cases (robust BVA). Standard BVA without the two invalid values has 5.

2. Equivalence Class Testing (ECT)

Divide the input domain into classes whose members behave alike; test one value per class.

Class	Range	Type	Representative input	Expected output
EC1	marks < 0	Invalid	-20	Error
EC2	0 to 100	Valid	55	Accepted
EC3	marks > 100	Invalid	150	Error

Non-integer or non-numeric input (e.g. "abc") can be added as a further invalid class.

Total = 3 test cases (4 with the non-numeric class).

3. Comparison of the test sets

Basis	BVA	Equivalence class testing
Number of tests	7	3
Focus	Edges of ranges, where off-by-one errors occur (e.g. `<` written instead of `<=`)	Whole classes of input, one representative each
Defect finding	Strong for boundary errors	Strong for general class errors, weak at boundaries
Redundancy	Higher	Minimal

Example: if the code wrongly checks marks < 100, ECT value 55 passes but BVA input 100 exposes the bug.

Conclusion

ECT reduces the number of tests; BVA finds boundary defects. Using them together (for example 3 + the boundary values) gives better coverage with a small test set.

Budget App•POCKETLY
Pocketly on Android
Log daily food, travel, and hostel expenses instantly. Set monthly spending limits and see where your money goes without complex spreadsheets.
Install Pocketly

Q7a. Analyse the need for software maintenance and categorize suitable maintenance activities for changes caused by defects, operating-environment changes and new user requirements.20267m

Module 5: Software Maintenance

Analyse the need for software maintenance and categorize suitable maintenance activities for changes caused by defects, operating-environment changes and new user requirements.

View this question on its own page →

Search Google Ask AI

Worked Solution

Need for Software Maintenance and Categories of Maintenance

Software maintenance is the modification of software after delivery to correct faults, improve performance or adapt it to a changed environment.

Need for maintenance

Defects remain after delivery: testing cannot find every fault.
Environment changes: new operating systems, hardware, databases, laws or tax rules.
New user requirements: users ask for new features or improvements once they use the system.
Prevent decay: repeated changes degrade the structure; software must be restructured to stay maintainable.
Long life of software: maintenance is typically the largest part (often 60% or more) of total life-cycle cost.

Types of maintenance

Type	Purpose	Trigger
Corrective	Fix errors/bugs found after delivery	Defects
Adaptive	Modify software to work in a changed environment	OS, hardware, platform, regulation changes
Perfective	Add or improve features and performance	New or changed user requirements
Preventive	Improve structure/readability to avoid future problems	Reduce future maintenance cost

Mapping the given changes

Cause of change	Maintenance category	Example
Defects	Corrective	Fixing a wrong tax calculation
Operating-environment changes	Adaptive	Porting the app to a new OS version or database
New user requirements	Perfective	Adding a report or a new payment option

Preventive maintenance (code cleanup, refactoring, updating documentation) applies when there is no immediate trigger but the code is becoming hard to change.

Typical effort split

Perfective is usually the largest share (about 50%), then adaptive (about 25%), corrective (about 20%) and preventive (about 5%).

Q7b. A healthcare company plans an application through which patients can register, consult doctors online, upload medical reports, receive prescriptions and make payments. Requirements are expected to evolve after pilot deployment. Analyse the requirement and formulate an appropriate SDLC strategy, major functional and nonfunctional requirements, one suitable prototyping activity and two risks that should influence process selection.20267m

Module 1: Introduction & SDLC

A healthcare company plans an application through which patients can register, consult doctors online, upload medical reports, receive prescriptions and make payments. Requirements are expected to evolve after pilot deployment. Analyse the requirement and formulate an appropriate SDLC strategy, major functional and nonfunctional requirements, one suitable prototyping activity and two risks that should influence process selection.

View this question on its own page →

Search Google Ask AI

Worked Solution

Healthcare Application: Requirement Analysis and SDLC Strategy

1. Requirement analysis

Stakeholders: patients, doctors, administrators, pharmacy/lab staff, payment provider.
Key points: health data is sensitive, so privacy and security are critical; requirements are expected to evolve after the pilot, so the process must absorb change.

2. Major functional requirements

FR1 Patient registration and login
FR2 Doctor search and appointment booking
FR3 Online consultation (video/chat)
FR4 Upload and view medical reports
FR5 Doctor issues e-prescription; patient views/downloads it
FR6 Online payment and receipts
FR7 Notifications and reminders
FR8 Admin: manage users, doctors and reports

3. Major non-functional requirements

Quality	Requirement
Security & privacy	Encrypted data, role-based access, consent, audit log, compliance with health-data laws
Availability	High uptime, especially for consultations
Performance	Fast page loads, smooth video, large report uploads
Usability	Simple UI for non-technical patients and elderly users
Reliability/Integrity	Prescriptions and reports must never be lost or altered
Scalability	Handle growth in patients and doctors
Interoperability	Work with payment gateways and hospital systems

4. Appropriate SDLC strategy

Iterative-incremental with prototyping, run in an Agile/Spiral style.

Requirements are unclear and will change after the pilot, so a one-pass Waterfall is unsuitable.
Build and release in increments: registration and booking first, then consultation, then reports and prescriptions, then payments.
Use the pilot deployment as a feedback cycle; update the backlog before the next increment.
Add a risk review in every cycle (Spiral element) because of the sensitive data.

5. One prototyping activity

Build a throw-away UI prototype of the appointment booking and online consultation flow (clickable wireframes). Show it to a few patients and doctors, collect feedback on screens, navigation and steps, then refine the requirements before coding.

6. Two risks that influence process selection

Risk	Effect on process choice
Requirement volatility after the pilot	Needs an iterative/incremental model with change handling
Data privacy / regulatory compliance and security breaches	Needs early and repeated security review (risk analysis every cycle), traceable documentation

Other possible risks: payment-gateway failures, video-service downtime, low user adoption.

Conclusion

An iterative, incremental, prototype-driven process with risk analysis (Agile/Spiral hybrid) fits best: it manages changing requirements while keeping security and privacy under control.

Q8a. Compare reverse engineering and software reengineering with respect to objectives, activities, outputs and their role in modernizing legacy systems.20267m

Module 5: Software Maintenance

Compare reverse engineering and software reengineering with respect to objectives, activities, outputs and their role in modernizing legacy systems.

View this question on its own page →

Search Google Ask AI

Worked Solution

Reverse Engineering vs Software Re-engineering

Reverse engineering = analysing an existing system (usually just the code or binary) to recover its design, specification and understanding. It does not change the software.
Re-engineering = restructuring or rewriting an existing system to improve quality or move it to a new platform, while keeping its functionality. It includes reverse engineering as a first step.

Comparison

Basis	Reverse engineering	Software re-engineering
Objective	Understand the system and recover design/requirements when documentation is missing	Improve maintainability, performance or platform of a legacy system
Changes the software?	No (analysis only)	Yes (restructure, convert, rewrite)
Main activities	Code reading and analysis, extracting data and control flow, building structure charts, UML/ER diagrams, documentation	Reverse engineering, restructuring/refactoring code and data, translating to a new language/platform, forward engineering, retesting
Outputs	Design documents, models, call graphs, recovered requirements	A restructured/migrated system that behaves the same way, plus updated documentation
Direction	Backward (code to design)	Backward then forward (code to design to new code)
Effort and cost	Lower	Higher, but lower than a full rewrite

Re-engineering process

Inventory analysis, document restructuring, reverse engineering, code restructuring, data restructuring, forward engineering, testing.

Role in modernizing legacy systems

Legacy systems are old, poorly documented and costly to maintain.

Reverse engineering first recovers lost knowledge of how the system works.
Re-engineering then restructures it or moves it to modern technology (new language, database, cloud) without rewriting from scratch.
Result: lower maintenance cost, better quality, longer system life, and less risk than building a new system.

Reverse engineering is the analysis stage; re-engineering is the full modernization process that uses it.

Q8b. A development team maintains five released versions of the same product. Design a configuration-management structure showing configuration items, version identification, change control and release management.20267m

Module 5: Software Maintenance

A development team maintains five released versions of the same product. Design a configuration-management structure showing configuration items, version identification, change control and release management.

View this question on its own page →

Search Google Ask AI

Worked Solution

Configuration-Management Structure for a Product with Five Released Versions

Software Configuration Management (SCM) keeps every released version identifiable, reproducible and controlled while several versions are maintained at the same time.

1. Configuration items (CIs)

Category	Items
Requirements/design	SRS, design documents, architecture diagrams
Source	Source code, libraries, configuration files
Build/deploy	Build scripts, installers, environment settings
Test	Test plans, test cases, test data, results
Data	Database schema and migration scripts
User	User manual, release notes

2. Version identification

Use semantic versioning: MAJOR.MINOR.PATCH (e.g. 3.2.1)

MAJOR: incompatible or large changes
MINOR: new backward-compatible features
PATCH: bug fixes only

Baselines are frozen, approved sets of CIs (e.g. v1.0, v2.0). Each CI and each build is tagged with its version.

main (latest development)
 |--- release/1.x  --> 1.0, 1.0.1, 1.1 ... (maintenance branch)
 |--- release/2.x  --> 2.0, 2.0.1 ...
 |--- release/3.x  --> 3.0, 3.1 ...
 |--- release/4.x  --> 4.0, 4.2 ...
 |--- release/5.x  --> 5.0, 5.1 ...   (current)

Each released version has its own maintenance branch; a fix is applied to the affected branches and merged back to main.

3. Change control process

Change request raised (bug, enhancement, environment change)
Impact analysis: which CIs and versions are affected
Change Control Board (CCB) reviews and approves or rejects
Implementation on a branch
Verification: review and regression testing
Merge and baseline update, change log recorded
Status reporting and audit

4. Release management

Activity	Purpose
Release planning	Decide which fixes/features go into which version
Build and package	Reproducible build from tagged CIs
Release notes	List changes, known issues, upgrade steps
Deployment and rollback plan	Safe installation with a way back
Support policy	Define how long each version is maintained
Audit	Check that the released build matches the approved baseline

Tools

Git/SVN for version control, Jenkins/CI for builds, Jira for change requests.

Benefit

Any of the five versions can be rebuilt exactly, bugs can be traced to the version they affect, and changes are controlled and recorded.

Q9a. Write short notes on any two of the following: Functional and Non-functional Requirements20267m

Module 2: Requirements & SRS

Write short notes on any two of the following:

Functional and Non-functional Requirements

View this question on its own page →

Search Google Ask AI

Worked Solution

Functional and Non-functional Requirements

Functional requirements (FR)

Describe what the system must do: its functions, features, inputs, processing and outputs.

Example (online shopping): The system shall allow a user to add items to a cart, place an order and receive an order confirmation.
Written as "The system shall..."; tested by black-box functional tests.

Non-functional requirements (NFR)

Describe how well the system must work: quality attributes and constraints.

Categories: performance, security, reliability, availability, usability, portability, maintainability, scalability, plus legal and standards constraints.
Example: The system shall respond to a search within 2 seconds for 500 simultaneous users.

Comparison

Basis	Functional	Non-functional
Describes	What the system does	How the system performs (quality)
Focus	Features and behavior	Quality attributes and constraints
Source	User/business needs	Standards, constraints, quality goals
Verification	Functional testing	Performance, security, usability testing
If missing	System cannot do its job	System is unusable, slow or unsafe
Example	Login, generate invoice	Login in under 2 s, 99.9% uptime

Importance

Both must be recorded in the SRS. A system that meets all functional requirements but fails its NFRs (slow, insecure) is still a failure.

Q9b. Write short notes on any two of the following: Top-down and bottom-up approach20267m

Module 3: Software Design & Metrics

Write short notes on any two of the following:

Top-down and bottom-up approach

View this question on its own page →

Search Google Ask AI

Worked Solution

Top-Down and Bottom-Up Approach

Top-down design

Start with the overall system and repeatedly break it into smaller sub-systems/modules until each module is simple enough to code (stepwise refinement).

Begins with the main module and works down; lower modules are first replaced by stubs.
Example: Banking system, then Accounts / Loans / Transactions, then Deposit, Withdraw, Transfer.
Advantages: clear overall structure, early detection of design and interface errors, easy to manage.
Disadvantages: low-level details come late; reuse of existing components is limited.

Bottom-up design

Start by designing and building the lowest-level, basic modules, then combine them into larger modules until the whole system is built.

Uses drivers to test lower modules first.
Example: Build and test Deposit, Withdraw and Transfer first, then combine them into Transactions, then the Banking system.
Advantages: encourages reuse of existing modules, low-level modules are tested thoroughly, suits projects built on existing libraries.
Disadvantages: overall structure and interface problems appear late; system-level design is unclear at the start.

Comparison

Basis	Top-down	Bottom-up
Starts from	Whole system / main module	Lowest-level modules
Direction	Decomposition (divide)	Composition (combine)
Testing aid	Stubs	Drivers
Strength	Clear structure, early design validation	Reuse, early detail testing
Weakness	Late low-level detail	Late integration problems

In practice a combination of both is used.

Q9c. Write short notes on any two of the following: Alpha & beta testing20267m

Module 4: Software Testing

Write short notes on any two of the following:

Alpha & beta testing

View this question on its own page →

Search Google Ask AI

Worked Solution

Alpha and Beta Testing

Both are forms of acceptance testing done before a product's final release.

Alpha testing

Performed in-house at the developer's site, in a controlled environment, by the development/QA team or internal users.
Done before beta testing, when the product is nearly complete.
Uses both white-box and black-box techniques; defects are fixed immediately.
Goal: find major bugs and crashes early.

Beta testing

Performed at the customer's site, in the real environment, by a limited group of real end users.
Done after alpha testing, just before public release.
Mainly black-box; the developer is not present.
Users report bugs, usability problems and compatibility issues.
Goal: validate the product under real conditions and gather feedback.
Example: pre-release app versions offered to a small group of users.

Comparison

Basis	Alpha testing	Beta testing
Performed by	Developers / internal testers	Real end users / customers
Location	Developer's site	User's site (real environment)
Environment	Controlled	Uncontrolled, real world
Timing	Before beta	After alpha, before release
Technique	White and black box	Black box
Bug fixing	Immediate	Collected, fixed in later versions
Purpose	Find major defects early	Check real-world use, gather feedback

Significance

Together they reduce the chance that serious defects reach the public, improve quality and usability, and increase customer confidence.

Q9d. Write short notes on any two of the following: SRS standards20267m
Module 2: Requirements & SRS
Write short notes on any two of the following:

SRS standards

View this question on its own page →
Search Google Ask AI
Worked Solution
SRS Standards (IEEE)

An SRS (Software Requirements Specification) is the document that states what the software must do and acts as an agreement between client and developer. Standards give a common structure so every SRS is complete and consistent.

Main standards

IEEE 830-1998: Recommended Practice for Software Requirements Specifications (the classic SRS format used in syllabi).

ISO/IEC/IEEE 29148:2018: the current standard that replaced IEEE 830 and covers requirements engineering processes and documents.

IEEE 830 structure

Introduction

1.1 Purpose, 1.2 Scope, 1.3 Definitions, acronyms, abbreviations, 1.4 References, 1.5 Overview

Overall description

2.1 Product perspective, 2.2 Product functions, 2.3 User characteristics, 2.4 Constraints, 2.5 Assumptions and dependencies

Specific requirements

External interfaces (user, hardware, software, communication)

Functional requirements

Performance requirements

Design constraints

Software system attributes (reliability, availability, security, maintainability, portability)

Other requirements

Appendices and index

Characteristics of a good SRS (IEEE 830)

Correct, unambiguous, complete, consistent, ranked for importance/stability, verifiable, modifiable, traceable.

Benefits of following a standard

Common understanding between client, analysts and developers

Fewer missing or conflicting requirements

Easier review, testing and maintenance

Basis for estimating cost and schedule

Previous year2025

Free AppAndroid App

Coursify Android App

Generate AI courses, take quick quizzes between classes, and master complex engineering concepts on the go.

Install Coursify

Software Engineering

Solution

Explanation

Why other options are incorrect:

Key Points to Remember:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Key Points to Remember:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Solution

Explanation

Why other options are incorrect:

Pocketly on Android

Decision Matrix: Waterfall vs Incremental vs Spiral for a Safety-Critical System

Selection criteria

Comparative matrix

Weighted score (scale 1 to 5, illustrative)

Justification

Agile Development vs Conventional Sequential Process

Comparison

Conclusion

SRS-Oriented Requirement Analysis: Hotel Management System

1. Introduction

2. Major user needs

3. Functional requirements

4. Constraints

5. Quality (non-functional) requirements

6. Assumptions

Decision Table: Online Loan-Processing System

Conditions

Actions

Decision table ("-" = don't care)

Derived system actions

Completeness check

Coupling and Cohesion: Types, Comparison and Target Combination

Types of coupling (best to worst)

Types of cohesion (worst to best)

Comparison

Target combination for a maintainable modular system

DFD for an Online Library System

Elements

Level 0: Context diagram

Level 1 DFD

Data flow summary

Rules followed

Control-Flow Graph and McCabe's Cyclomatic Complexity

Assumed program segment (1 loop + 3 conditional branches)

Control-flow graph

Cyclomatic complexity (three equivalent methods)

Independent paths (V(G) = 5)

Relation to the minimum number of independent paths

Function Point Calculation

Step 1: Unadjusted Function Points

Step 2: Value Adjustment Factor

Step 3: Function Points

Answer

Black-Box vs White-Box Testing

Comparison

Conclusion