2022 question paper

Software Engineering

20 questions

Q1a. The spiral model was originally proposed by (i) IBM (ii) Barry Boehm (iii) Pressman (iv) Royce20222m
Module 1: Introduction & SDLC
The spiral model was originally proposed by

(i) IBM
(ii) Barry Boehm
(iii) Pressman
(iv) Royce

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

Correct Answer: (ii) Barry Boehm

Explanation

The Spiral Model was originally proposed by Barry Boehm in his 1986 paper "A Spiral Model of Software Development and Enhancement".

It is a risk-driven evolutionary process model that combines features of the Waterfall and Prototyping models.

Why other options are incorrect:

(i) IBM - Associated with early software processes but not spiral model

(iii) Pressman (Roger Pressman) - Author of SE textbook, explained the model but did not propose it

(iv) Royce (Winston Royce) - Proposed the Waterfall Model (1970), not Spiral

Key Points to Remember:

4 Quadrants of Spiral: 1. Objective Setting 2. Risk Assessment & Reduction 3. Development & Validation 4. Planning

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

Answer: (ii) Barry Boehm
Q1b. Measure of reliability is given by (i) mean time between success (ii) MTBF (iii) mean reliable (iv) MTTR20222m
Module 2: Requirements & SRS
Measure of reliability is given by

(i) mean time between success
(ii) MTBF
(iii) mean reliable
(iv) MTTR

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

Correct Answer: (ii) MTBF

Explanation

Reliability metrics:

MTBF = Mean Time Between Failures = MTTF + MTTR → overall reliability measure. Larger MTBF = more reliable.

MTTF = Mean Time To Failure (for non-repairable)

MTTR = Mean Time To Repair

ROCOF = Rate of Occurrence of Failures

Hence measure of reliability is given by MTBF (and also MTTF/ROCOF variants). Mean time between success and mean reliable are not standard terms.

Answer: (ii) MTBF
Q1c. Which of the following is not a use of a CASE tool? (i) It supports structured analysis and design (SA/SD) (ii) It maintains the data dictionary (iii) It checks whether DFDs are balanced or not (iv) It compiles with the available system.20222m
Module 2: Requirements & SRS
Which of the following is not a use of a CASE tool?

(i) It supports structured analysis and design (SA/SD)
(ii) It maintains the data dictionary
(iii) It checks whether DFDs are balanced or not
(iv) It compiles with the available system.

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

Correct Answer: (iv) It compiles with the available system

Explanation

Same as Q77 (2020):

CASE tools support:

(i) Structured analysis & design - YES

(ii) Data dictionary maintenance - YES

(iii) DFD balancing checks - YES

(iv) Compiling with available system - NOT a CASE use.

Compilers are separate; CASE is for design/analysis automation, not compilation.

Answer: (iv) It compiles with the available system
Q1d. Name of an evaluation technique to assess the quality of test cases is (i) mutation analysis (ii) validation (iii) verification (iv) performance analysis20222m
Module 4: Software Testing
Name of an evaluation technique to assess the quality of test cases is

(i) mutation analysis
(ii) validation
(iii) verification
(iv) performance analysis

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

Correct Answer: (i) mutation analysis

Explanation

Mutation Analysis / Mutation Testing:

Create mutants (seed small faults - e.g., change > to >=, + to -) in program

Run test suite; if test kills mutant (fails), test is good

Mutation Score = Killed mutants / Total mutants → measures quality / effectiveness of test cases.

Validation = checking product meets user needs

Verification = checking phase output correctly

Performance analysis = speed, not test quality.

Answer: (i) mutation analysis
Q1e. What is the most popular model for student program? (i) Waterfall model (ii) Built-and-fix model (iii) Spiral model (iv) Rational unified model20222m
Module 1: Introduction & SDLC
What is the most popular model for student program?

(i) Waterfall model
(ii) Built-and-fix model
(iii) Spiral model
(iv) Rational unified model

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

Correct Answer: (ii) Built-and-fix model

Explanation

Built-and-Fix (also called Build-and-Fix / Ad-hoc / Code-and-Fix):

No formal design, just code → fix until works.

Students use it for small assignments due to no planning overhead, immediate coding.

Other models too heavy for student programs:

Waterfall needs full documentation

Spiral/RUP are for large industrial projects.

Hence most popular for student programs is Build-and-Fix (though not recommended for professional work).

Answer: (ii) Built-and-fix model
Q1g. Independent modules are easier to maintain and test because of (i) code modification is limited (ii) reusable modules are possible (iii) error propagation is reduced (iv) All of the above20222m
Module 3: Software Design & Metrics
Independent modules are easier to maintain and test because of

(i) code modification is limited
(ii) reusable modules are possible
(iii) error propagation is reduced
(iv) All of the above

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

Correct Answer: (iv) All of the above

Explanation

Independent modules (low coupling, high cohesion) are easier to maintain/test because:

(i) Code modification limited - Change isolated to one module, no ripple effect

(ii) Reusable modules possible - Independent modules can be plugged elsewhere

(iii) Error propagation reduced - Fault in one module less likely to affect others, easier to locate

Hence all three are benefits, so (iv) All of the above.
Q1i. Classes communicate with one another via (i) processed information (ii) interfaces (iii) messages (iv) coupling20222m
Module 3: Software Design & Metrics
Classes communicate with one another via

(i) processed information
(ii) interfaces
(iii) messages
(iv) coupling

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

Correct Answer: (iii) messages

Explanation

In Object-Oriented Design, classes/objects communicate via message passing. A message is a request for an object to execute one of its methods (e.g., obj.method() in Java).

Interfaces define what messages can be sent, but the mechanism is messages

Coupling is a metric, not communication means

Processed information is vague

Answer: (iii) messages
Q1j. Software is not considered to be collection of executable programming code, associated libraries and documentations. (i) Statement is true (ii) Software is only data structures with algorithms (iii) Statement is false (iv) Statement underestimates software20222m
Module 1: Introduction & SDLC
Software is not considered to be collection of executable programming code, associated libraries and documentations.

(i) Statement is true
(ii) Software is only data structures with algorithms
(iii) Statement is false
(iv) Statement underestimates software

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

Correct Answer: (iii) Statement is false

Explanation

Definition (IEEE): Software is collection of executable programming code, associated libraries and documentations - This statement is TRUE in standard view. So saying "Software is NOT considered to be collection..." is FALSE.

Options:

(i) Statement is true → wrong, statement undervalues software

(ii) Software is only data structures with algorithms → incomplete definition

(iii) Statement is false → correct, software is considered that collection

(iv) Statement underestimates software → also arguable, but (iii) is more direct correct as per exam key (software is that collection plus documentation). Some keys mark (iv) - but official Mumbai key is (iii) Statement is false.

Answer: (iii) Statement is false (alternative accepted: iv - statement underestimates software, as modern definition includes config data, docs, etc.)
Q2. Explain in detail the classical waterfall model with help of a neat and labelled diagram.202214m
Module 1: Introduction & SDLC
Explain in detail the classical waterfall model with help of a neat and labelled diagram.

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

Classical Waterfall Model (Winston Royce, 1970) - Detailed

Diagram:

Requirements Analysis & Specification ↓ (SRS Document) System & Software Design ↓ (Design Docs) Implementation (Coding) ↓ (Code) Testing (Verification) ↓ (Test Report) Deployment ↓ Maintenance

Each phase feeds next; verification at each gate; no overlap.

Phases in Detail:

Requirements - Elicit, analyze, specify, validate → SRS. Output: SRS.

Design - Architecture, DFD, ERD, modular decomposition, interface specs. Types: High-level & Detailed.

Implementation - Code as per standards, unit testing per module.

Testing - Integration + System testing against SRS; alpha/beta.

Deployment - Delivery, installation, user training.

Maintenance - Corrective, Adaptive, Perfective, Preventive (60% of lifecycle cost).

Advantages: Simple, easy to manage, document-driven, suitable for small stable projects.

Limitations: No working model till late, high risk, poor for changing requirements, not suitable for large complex/OO projects.
Q3a. What is prototyping model? Explain the problems and advantages of prototyping in detail.20227m
Module 1: Introduction & SDLC
What is prototyping model? Explain the problems and advantages of prototyping in detail.

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

Prototyping Model

Definition: Build quick prototype (throwaway or evolutionary) to clarify unclear requirements via customer feedback, then build actual product.

Steps: Requirements Gathering (vague) → Quick Design → Build Prototype → Customer Evaluation → Refine Prototype → Engineer Final Product

Advantages:

Requirement clarity, better customer involvement

Early risk detection, reduces rework

Demonstrates feasibility

Problems / Disadvantages:

Customer may confuse prototype with product (expects quick delivery)

Developer may take shortcuts (poor design compromises)

Scope creep, cost/schedule uncertainty

Extra effort if throwaway prototype discarded

Use when: Requirements vague, GUI-heavy, innovative, human-computer interaction systems.
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

Q3b. Develop a test case for any testing technique for 'student admission system'.20227m

Module 4: Software Testing

Develop a test case for any testing technique for 'student admission system'.

View this question on its own page →

Search Google Ask AI

Worked Solution

Solution - Test Case for Student Admission System

Technique: Equivalence Partitioning + BVA (Black box) for "Eligibility: Marks 45-100, Age 17-25"

Test Case Format: TC_ID, Input, Precondition, Steps, Expected, Actual

TC	Technique	Input (Marks, Age)	Expected	Type
TC1	Valid EP	75, 20	Admission Allowed	Positive
TC2	Invalid EP Low	44, 20	Reject - Marks low	Negative
TC3	Invalid EP High	101, 20	Reject - Marks invalid	Negative
TC4	BVA Lower	45, 17	Allowed (boundary)	Boundary
TC5	BVA Upper	100, 25	Allowed (boundary)	Boundary
TC6	Below boundary	44, 16	Reject both	Boundary
TC7	Above boundary	101, 26	Reject both	Boundary

Steps for TC1:

Login as admin → Admission → New
Enter Name=ABC, Marks=75, Age=20, Docs uploaded
Click Submit → Verify "Application Accepted" + DB entry.

Traceability: Covers functional requirement FR-01: System shall admit if marks ≥45 and age 17-25.

Q4a. Define cohesion and coupling. Explain various types of each of them.20227m

Module 3: Software Design & Metrics

Define cohesion and coupling. Explain various types of each of them.

View this question on its own page →

Search Google Ask AI

Worked Solution

Solution

Cohesion & Coupling (Detailed)

Cohesion - Within module:

Type	Description	Example
Functional	Single purpose	`calculateSalary()`
Sequential	Output→Input	Read→Process→Write
Communicational	Same data	Print/Update Student record
Procedural	Sequential steps	`init()` calls A then B
Temporal	Same time	`startup()`
Logical	Similar functions	`inputAll()`
Coincidental	Random	Utility misc

Order: Functional (best, 10/10) → Coincidental (worst, 1/10).

Coupling - Between modules:

Type	Description
Data	Parameters `x,y`
Stamp	Structure `student`
Control	Flag `if(flag)`
External	Hardcoded protocol
Common	Global `int g;`
Content	`goto` into other module

Order: Data (best) → Content (worst).

Goal: Functional cohesion + Data coupling.

Q4b. What are CASE tools? With a suitable diagram, explain the categories of CASE tools.20227m
Module 2: Requirements & SRS
What are CASE tools? With a suitable diagram, explain the categories of CASE tools.

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

CASE Tools

Definition: Software tools that automate/mamper SDLC activities (see Q110).

Categories (with Diagram)

CASE Tools ├─ Upper CASE (Front-end) - Planning/Analysis: DFD, ERD, SRS ├─ Lower CASE (Back-end) - Coding/Testing: compilers, debuggers └─ Integrated CASE - Covers entire lifecycle + Repository

Detailed Categories:

Business Planning Tools - Project estimation (COCOMO tools)

Project Management Tools - Gantt/PERT (MS Project), tracking

Support Tools - Documentation, DB design, configuration

Analysis & Design Tools - UML (Rational Rose), DFD editors

Programming Tools - Code generators, compilers, 4GL

Integration & Testing Tools - Test case generators, coverage analyzers

Maintenance Tools - Reverse engineering, re-engineering

Diagram shows Upper → Design, Lower → Implementation, Repository central.

Q5. What are the different COCOMO models? Explain the phases involved in the detailed COCOMO model.202214m

Module 3: Software Design & Metrics

What are the different COCOMO models? Explain the phases involved in the detailed COCOMO model.

View this question on its own page →

Search Google Ask AI

Worked Solution

Solution

COCOMO Models

1. Basic COCOMO - Effort $= a(KLOC)^b$ , Time $= c(Effort)^d$ (no cost drivers).
2. Intermediate COCOMO - Basic × EAF (15 cost drivers: reliability, complexity, experience).
3. Detailed / Advanced COCOMO - Intermediate per phase (requirements, design, coding, testing) - phase-sensitive.

Phases in Detailed COCOMO

Detailed splits effort across SDLC phases with different multipliers per mode:

Phase	Organic	Semi-detached	Embedded
Planning & Requirements	6%	7%	8%
System Design	16%	17%	18%
Detailed Design	26%	25%	28%
Module Code & Test	42%	33%	30%
Integration & Test	16%	25%	32%

Process:

Estimate KLOC and mode
Compute nominal effort via Basic
Apply phase-wise cost drivers
Distribute effort/time per phase using above %

Detailed gives most accurate phase-wise staffing.

Q6a. What are the types of user-interface design?20227m
Module 3: Software Design & Metrics
What are the types of user-interface design?

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

Types of User Interface Design

1. Command Line Interface (CLI)

Text commands. Efficient for experts. Ex: Linux terminal.

2. Graphical User Interface (GUI)

Windows, Icons, Menus, Pointer (WIMP). User-friendly. Ex: Desktop apps.

3. Menu-driven

Selection from menus. Hierarchical. Ex: ATM.

4. Form-based

Fill forms/fields. Ex: Admission system, web forms.

5. Natural Language Interface

Human language input. Ex: Chatbot, voice assistant.

6. Direct Manipulation

Drag-drop, touch, gesture. Ex: Mobile apps, drawing tools.

Modern: Web UI, Touch + Voice (Multimodal), VR/AR interfaces. Choice depends on user type (novice vs expert).
Q6b. Explain the stages of object-oriented design process.20227m
Module 3: Software Design & Metrics
Explain the stages of object-oriented design process.

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

Stages of Object-Oriented Design (OOAD) Process

1. System Analysis / Requirements

Use-case modelling, identify actors, scenarios.

2. Object/Entity Identification

Nouns → objects/classes, verbs → methods. CRC cards.

3. Object Modelling

Class diagram (classes, attributes, associations, inheritance)

Relationship identification (is-a, has-a)

4. Dynamic Modelling

Sequence diagrams, State charts, Collaboration diagrams.

5. Functional Modelling

What system does: activity diagrams, DFD for OO.

6. Conceptual / Architectural Design

Subsystem decomposition, reuse library design.

7. Detailed Design & Implementation

Refine classes, design interfaces, code in OO language (Java/C++), test.

Iterative, incremental, uses UML throughout.
Q7. Write short notes on the following: (a) Unified modelling language [5] (b) Object-oriented analysis modelling [5] (c) Object-oriented design concepts and methods [4]202214m
Module 3: Software Design & Metrics
Write short notes on the following:

(a) Unified modelling language [5]
(b) Object-oriented analysis modelling [5]
(c) Object-oriented design concepts and methods [4]

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

(a) Unified Modelling Language (UML) [5]

UML is OMG standard visual language for OO systems. Diagrams:

Structural: Class, Object, Component, Deployment

Behavioral: Use-case, Sequence, Collaboration, State, Activity
Benefits: Standard notation, communication, tool support.

(b) Object-Oriented Analysis Modelling [5]

OOA models real-world as objects. Steps: Identify classes/objects -> Attributes -> Services -> Structures (generalization, composition). Output: OOA model with class & relationship diagrams.

(c) Object-Oriented Design Concepts & Methods [4]

Concepts: Encapsulation, Inheritance, Polymorphism, Abstraction, Classes/Objects, Message passing, Reusability. Methods: Responsibility-Driven Design, CRC cards, Booch, Rumbaugh OMT, Jacobson OOSE. Principles: SOLID, low coupling high cohesion.
Q8. Explain coding standards, coding guidelines and code review techniques in detail.202214m
Module 3: Software Design & Metrics
Explain coding standards, coding guidelines and code review techniques in detail.

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

Coding Standards

Rules for code writing (naming, formatting, documentation).

Ex: Use camelCase for variables, PascalCase for classes, header comments, max line length 80, indentation 4 spaces.

Coding Guidelines

Best practices (not mandatory) for quality:

Avoid goto, limit function length <30 lines, single entry/exit, error handling, reuse.

Code Review Techniques

Inspection (Fagan) - Formal, checklist, moderator, 3-7 people, record defects.

Walkthrough - Author explains, informal feedback.

Peer Review / Pair Programming - Colleagues review via tool (GitHub PR) or driver-navigator.

Static Analysis - Automated tool check (lint, SonarQube).

Benefits: Early defect removal (60-90%), knowledge sharing, standards enforcement.
Q9a. What is software quality? Discuss software quality attributes.20227m
Module 3: Software Design & Metrics
What is software quality? Discuss software quality attributes.

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

Software Quality

Degree to which software satisfies stated and implied needs (IEEE). See Q123.

Quality Attributes (McCall / ISO 9126)

Product Operation:

Correctness, Reliability, Efficiency, Integrity, Usability

Product Revision:

Maintainability, Flexibility, Testability

Product Transition:

Portability, Reusability, Interoperability

ISO 9126 adds: Functionality, Reliability, Usability, Efficiency, Maintainability, Portability.

Each factor has metrics (e.g., Reliability = MTBF).

Q9b. Discuss the differences between object-oriented and function-oriented designs.20227m

Module 3: Software Design & Metrics

Discuss the differences between object-oriented and function-oriented designs.

View this question on its own page →

Search Google Ask AI

Worked Solution

Solution

Aspect	Object-Oriented	Function-Oriented
Focus	Objects (data+functions)	Functions/procedures, data flow
Decomposition	Classes/objects	Modules/functions (DFD)
Data	Encapsulated with methods (hidden)	Shared, global
Design notation	UML (class, sequence)	DFD, Structure chart
Reusability	High (inheritance, polymorphism)	Low, function reuse
Example language	Java, C++	C, Pascal
Maintenance	Easier (local change)	Ripple effect (high coupling)

OO is data-centric, FO is action-centric. Modern systems often use hybrid.

Previous year2021 Next year2023

Student FinanceWeb Platform

Pocketly — Personal Finance for Students

Keep your hostel and college expenses under control. Track accounts, log spending in seconds, and stay within your monthly budget.

Open Pocketly

Software Engineering

Solution

Explanation

Why other options are incorrect:

Key Points to Remember:

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Classical Waterfall Model (Winston Royce, 1970) - Detailed

Solution

Prototyping Model

Pocketly on Android

Solution - Test Case for Student Admission System

Technique: Equivalence Partitioning + BVA (Black box) for "Eligibility: Marks 45-100, Age 17-25"

Solution

Cohesion & Coupling (Detailed)

Solution

CASE Tools

Categories (with Diagram)

Solution

COCOMO Models

Phases in Detailed COCOMO

Solution

Types of User Interface Design

Solution

Stages of Object-Oriented Design (OOAD) Process

Solution

(a) Unified Modelling Language (UML) [5]

(b) Object-Oriented Analysis Modelling [5]

(c) Object-Oriented Design Concepts & Methods [4]

Solution

Coding Standards

Coding Guidelines

Code Review Techniques

Solution

Software Quality

Quality Attributes (McCall / ISO 9126)

Solution

Pocketly — Personal Finance for Students