2023 question paper

Software Engineering

29 questions

Q1a. To achieve a good design, modules should have a) Weak cohesion and low coupling b) Weak cohesion and high coupling c) Strong cohesion and low coupling d) Strong cohesion and high coupling20232m
Module 3: Software Design & Metrics
To achieve a good design, modules should have

a) Weak cohesion and low coupling
b) Weak cohesion and high coupling
c) Strong cohesion and low coupling
d) Strong cohesion and high coupling

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

Correct Answer: (c) Strong cohesion and low coupling

Explanation

Good modular design principle: High cohesion, Low coupling.

Strong (high) cohesion - elements inside module belong together → maintainable

Low coupling - modules independent → change in one doesn't affect others

Weak cohesion or high coupling are bad (hard to test, ripple errors).

Answer: (c) Strong cohesion and low coupling
Q1b. Which is NOT a non-functional requirement? a) Efficiency b) Reliability c) Product features d) Stability20232m
Module 2: Requirements & SRS
Which is NOT a non-functional requirement?

a) Efficiency
b) Reliability
c) Product features
d) Stability

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

Correct Answer: (c) Product features

Explanation

Non-functional requirements = how system behaves: Efficiency, Reliability, Stability, Portability, Performance, Security → (a),(b),(d) are NFRs.

Product features / Functional requirements = what system does (e.g., login, billing) → Functional, not non-functional. So Product features is NOT an NFR.

Answer: (c) Product features
Q1c. Alpha-testing is done by a) The development team b) A friendly set of customers c) The customer himself d) None of these20232m
Module 4: Software Testing
Alpha-testing is done by

a) The development team
b) A friendly set of customers
c) The customer himself
d) None of these

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

Correct Answer: (a) The development team

Explanation

Alpha testing - Done in-house by development team / internal testers in controlled environment (at developer's site) before beta.

Beta testing - Done by friendly customers / selected external users at customer's site (real environment).

Customer himself is ultimate user but not alpha.

Answer: (a) The development team
Q1d. Which model is generally used for developing GUI of a System? a) Spiral b) Prototyping c) Iterative waterfall d) Evolutionary20232m
Module 1: Introduction & SDLC
Which model is generally used for developing GUI of a System?

a) Spiral
b) Prototyping
c) Iterative waterfall
d) Evolutionary

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

Correct Answer: (b) Prototyping

Why?

When developing a GUI (Graphical User Interface), users need to see and interact with the interface early so that the design can be reviewed and improved through multiple iterations.

The Prototyping Model is well suited for this because it allows developers to:

Create an early working model of the interface.

Get quick feedback from users.

Identify usability and design issues early.

Refine the GUI through repeated iterations.

Why not the others?

Spiral: Primarily focuses on managing risks in large and complex projects.

Iterative Waterfall: Follows a more structured sequence and is less suited to rapid UI experimentation.

Evolutionary: Evolves the system incrementally, but the standard model specifically associated with quickly exploring and refining a GUI is Prototyping.

Exam Tip: For questions about quickly designing, showing, testing, and refining a GUI, remember Prototyping Model → rapid visual feedback and iteration.
Q1e. Measure of reliability is given by a) Mean time between success b) MTBF c) Mean reliable d) MTTR20232m
Module 2: Requirements & SRS
Measure of reliability is given by

a) Mean time between success
b) MTBF
c) Mean reliable
d) MTTR

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

Correct Answer: (b) MTBF

Explanation

Same as Q28: MTBF = Mean Time Between Failures is standard reliability measure (MTTF+MTTR). Larger MTBF = higher reliability.

Answer: (b) MTBF
Q1f. Which one of the following is not desired in a good Software Requirement Specifications (SRS) document? a) Functional requirements b) Goals of implementation c) Non-functional requirements d) Algorithms for software implementation20232m
Module 2: Requirements & SRS
Which one of the following is not desired in a good Software Requirement Specifications (SRS) document?

a) Functional requirements
b) Goals of implementation
c) Non-functional requirements
d) Algorithms for software implementation

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

Correct Answer: (d) Algorithms for software implementation

Explanation

Good SRS should contain Functional, Non-functional, Goals of implementation (high-level purpose). It should NOT contain algorithms / design (how to implement) - that is design phase decision. SRS is what not how.

Answer: (d) Algorithms for software implementation
Q1g. The potential risks are best detected by a) Spiral Model b) Waterfall Model c) Incremental Mod I d) Prototyping Model20232m
Module 1: Introduction & SDLC
The potential risks are best detected by

a) Spiral Model
b) Waterfall Model
c) Incremental Mod I
d) Prototyping Model

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

Correct Answer: (a) Spiral Model

Explanation

Spiral Model is risk-driven - each loop has Risk Analysis quadrant (Boehm). Potential risks (technical, cost, schedule) best detected early via prototype and risk assessment.

Waterfall detects risk late (testing)

Incremental delivers but less risk focus

Prototyping addresses UI risk only

Answer: (a) Spiral Model
Q1h. The largest percentage of total life cycle cost of software is a) Design cost b) Coding cost c) Maintenance cost d) Testing cost20232m
Module 5: Software Maintenance
The largest percentage of total life cycle cost of software is

a) Design cost
b) Coding cost
c) Maintenance cost
d) Testing cost

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

Correct Answer: (c) Maintenance cost

Explanation

Lifecycle cost distribution (typical Boehm data):

Design ~10%, Coding ~15%, Testing ~20%, Maintenance 60-70% (largest).

Software lives long; corrective/adaptive/perfective maintenance dominates.

Answer: (c) Maintenance cost
Q1i. Main difference between program testing and system testing is a) System testing focuses on testing the interfaces between programs, program testing focuses on individual programs b) Program testing is more comprehensive than system testing c) System testing is tough and program testing is easy d) None of these20232m
Module 4: Software Testing
Main difference between program testing and system testing is

a) System testing focuses on testing the interfaces between programs, program testing focuses on individual programs
b) Program testing is more comprehensive than system testing
c) System testing is tough and program testing is easy
d) None of these

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

Correct Answer: (a) System testing focuses on testing the interfaces between programs, program testing focuses on individual programs

Explanation

Program/Unit testing - individual program/module in isolation (with drivers/stubs).

System testing - tests integrated system as whole, interfaces between programs, end-to-end behavior vs SRS.

(b) Program testing more comprehensive → false (system testing broader)
(c) Tough/easy subjective → false

Answer: (a)
Q2a. What is software engineering?20232m
Module 1: Introduction & SDLC
What is software engineering?

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

What is Software Engineering?

Definition (IEEE): Application of systematic, disciplined, quantifiable approach to development, operation and maintenance of software.

Definition (Fritz Bauer, 1969): Establishment and use of sound engineering principles to obtain economically software that is reliable and works efficiently on real machines.

Nature: Layered Technology:

Quality Focus (bedrock)

Process (framework: SDLC, Umbrella activities)

Methods (technical how-to: analysis, design, testing)

Tools (CASE automation)

Goal: Deliver high-quality software on time, within budget, meeting user needs (resolve Software Crisis of 1960s).
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
Q2b. Discuss the software engineering process.20234m
Module 1: Introduction & SDLC
Discuss the software engineering process.

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

Software Engineering Process

Set of framework activities + umbrella activities to build software.

Framework Activities:

Communication - Requirement elicitation from stakeholders

Planning - Estimation, scheduling, risk

Modeling - Analysis (requirements model) + Design (architecture, component)

Construction - Code generation + Testing

Deployment - Delivery, support, feedback

Umbrella Activities (throughout):

Project tracking, Risk management, Quality assurance, Configuration management, Technical reviews, Measurement

Process provides structure and stability to produce quality product predictably. Models include Waterfall, Incremental, Spiral, Agile.
Q2c. Explain waterfall model in detail with the help of diagram. State its advantage and also its limitations.20238m
Module 1: Introduction & SDLC
Explain waterfall model in detail with the help of diagram. State its advantage and also its limitations.

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

Waterfall Model in Detail (with Diagram)

See Q37 for diagram/phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance (linear, no overlap, gated).

Advantages:

Simple, easy to understand and manage

Clear milestones, documentation at each phase

Works well for small, stable-requirement projects

Discipline, predictability

Limitations:

No working software till end → late risk discovery

Difficult to accommodate change (frozen SRS)

Customers see product late (poor feedback)

Not suitable for large, complex, OO, high-risk projects

Testing only at end → costly fixes

Ideal for: payroll, library systems where requirements well-understood.
Q3a. What are the different architectural styles applied for software development?20237m
Module 3: Software Design & Metrics
What are the different architectural styles applied for software development?

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

Architectural Styles Applied for Software Development

See Q98 - Detailed with diagrams:

Layered - UI → Application → Data

Client-Server - Distributed request/response

Pipe & Filter - Unix pipeline, compiler phases

Repository - Central DB with tools (IDE)

MVC - Model-View-Controller for interactive apps

Event-driven / Publish-Subscribe - GUI listeners

SOA / Microservices - Loose-coupled services

Each style matches problem domain: Data flow → Pipe-Filter, Interactive → MVC/Event, Data-centric → Repository.
Q3b. What is 'acceptance' testing? Explain briefly alpha testing and beta testing with suitable examples.20237m
Module 4: Software Testing
What is 'acceptance' testing? Explain briefly alpha testing and beta testing with suitable examples.

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

Acceptance Testing

Final testing by customer/user to decide acceptance vs rejection. Validates against SRS / business needs before deployment. Types: Alpha & Beta, Regulation, Operational.

Alpha Testing

Where: At developer's site, controlled environment

By: Internal testers / development team with customer presence

Purpose: Find bugs before beta; Example: Developer tests e-commerce payment flow internally, fixes issues.

Beta Testing

Where: At customer's site, real environment (uncontrolled)

By: Selected real users / friendly customers

Purpose: Real-world feedback, usability, performance; Example: Release beta app to 100 users to report bugs before public launch.

Alpha → Beta → Release. Both are Validation activities.
Q4a. Discuss the software metric that can be applied to the qualitative assessment of software quality and side effects that occur during maintenance phase.20237m
Module 3: Software Design & Metrics
Discuss the software metric that can be applied to the qualitative assessment of software quality and side effects that occur during maintenance phase.

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

Software Metric for Qualitative Assessment & Maintenance Side Effects

Qualitative Metrics (Subjective but measurable):

McCall Quality Factors (Functionality, Usability, etc.) via surveys/checklists

Maintainability Index (MI) = 171 - 5.2 ln(Halstead Volume) - 0.23 CC - 16.2 ln(LOC) → higher MI = easier to maintain

Maintenance Side Effects Metrics:

Stability - Ripple effect: Modules affected / Change size → Low stability means large ripple

Modularity metrics: Coupling/Cohesion before vs after maintenance

Defect metrics: Defects introduced per KLOC maintained (often 50% of maintenance is fixing side-effects)

Impact Analysis matrix: Trace change → affected requirements/design/code

Example: After adding feature, if CC increased from 10 to 25, MI drops → qualitative degradation flagged, indicating refactoring needed.
Q4b. Explain COCOMO model for estimation.20237m
Module 3: Software Design & Metrics
Explain COCOMO model for estimation.

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

COCOMO Model for Estimation (Boehm, 1981)

Types:

Organic - Small, simple, experienced team (2-50 KLOC) $a=2.4, b=1.05$

Semi-detached - Medium, mixed experience (50-300 KLOC) $a=3.0, b=1.12$

Embedded - Complex, tight hardware ( >300 KLOC) $a=3.6, b=1.20$

Models:

Basic: $Effort = a(KLOC)^b$ , $Time = c(Effort)^d$

Intermediate: Basic × Effort Adjustment Factor (15 cost drivers)

Detailed: Phase-wise distribution

Example: 100 KLOC Embedded → $Effort=3.6×100^{1.20}=3.6×251=904 PM$ , $Time=2.5×904^{0.32}=22$ months

Used for budgeting and staffing.
Q5a. What are drivers and stub modules in context of integration and unit testing of software product? Why are stubs and driver modules required?20237m
Module 4: Software Testing
What are drivers and stub modules in context of integration and unit testing of software product? Why are stubs and driver modules required?

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

Drivers and Stub Modules

Context: Integration & Unit Testing

Stub: Dummy called module (subordinate). Replaces not-yet-built lower modules in Top-down integration. Simulates return values.

Ex: Main → Stub pay() returns dummy "success"

Driver: Dummy calling module (superior). Replaces not-yet-built upper modules in Bottom-up integration. Calls unit under test.

Ex: Driver test_harness() calls calculateSalary()

Why Required?

Modules developed independently / incrementally; not all available at test time

Need to isolate unit, simulate interface without building whole system

Reduce dependency, enable early testing

Top-down needs stubs, Bottom-up needs drivers, Sandwich needs both.
Q5b. Draw the context diagram and Level 1 DFD for the following Mail Order Processing System. "HMV Records is a mail-order company that distributes CDs and tapes at discount prices to record club members. When an order processing clerk receives an order form, he/she verifies that the sender is a club member by checking the member file. If the sender is not a member, the clerk returns the order along with a member form. If the sender is a member, the clerk verifies the order item data by checking the Item file. Then the Daily Order file. The clerk also prints an invoice and shipping list for each order, which are forwarded to order fulfillment."20237m
Module 3: Software Design & Metrics
Draw the context diagram and Level 1 DFD for the following Mail Order Processing System.

"HMV Records is a mail-order company that distributes CDs and tapes at discount prices to record club members. When an order processing clerk receives an order form, he/she verifies that the sender is a club member by checking the member file. If the sender is not a member, the clerk returns the order along with a member form. If the sender is a member, the clerk verifies the order item data by checking the Item file. Then the Daily Order file. The clerk also prints an invoice and shipping list for each order, which are forwarded to order fulfillment."

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution - Mail Order Processing System DFD

Description: Member checkout, clerk validates membership & item, creates daily order, invoice, shipping.

Context Diagram (Level 0)

Entities: Customer (Member), Member File, Item File, Order Fulfillment

Process: Mail Order System

Flows: Order Form → System → Invoice/Shipping List → Fulfillment; Member check ↔ Member File; Item check ↔ Item File

Customer ─(Order Form)─►│Mail Order System│─(Invoice/Shipping)─► Fulfillment │ │─(Member Form)─► Customer (if not member)

Level 1

Processes:

1.0 Verify Member - Check Member File; if not member → return order + member form

2.0 Verify Order Item - Check Item File for availability/price

3.0 Record Daily Order - Write to Daily Order File

4.0 Generate Invoice & Shipping List - Print and forward to Fulfillment

Data Stores: D1 Member File, D2 Item File, D3 Daily Order File

Order Form →1.0 →(member OK)→2.0 →3.0 →4.0 → Fulfillment ↕D1 ↕D2 ↕D3

Flows balanced; contexts decomposed correctly.
Q6a. What is SRS? Write the features of SRS.20235m
Module 2: Requirements & SRS
What is SRS? Write the features of SRS.

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

SRS - Software Requirements Specification

Definition: Complete description of what system must do (IEEE 830). Serves as contract between client & developer.

Features of SRS

Characteristics of Good SRS:

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

Clear, concise, with glossary

Features / Contents:

Functional Requirements - What system does (use cases)

Non-functional - Performance, reliability, portability

External Interfaces - User, hardware, software, communication

Design Constraints - Standards, hardware limits

Goals of Implementation - Purpose, scope, business goals (high level)

Excluded: Algorithms, architecture, design details (how)

See IEEE structure in Q121.
Q6b. What is Risk? Why Analysis is done?20234m
Module 1: Introduction & SDLC
What is Risk? Why Analysis is done?

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

What is Risk?

Potential uncertain event that, if occurs, negatively affects project objectives (cost, schedule, quality) - Boehm. Types: Project (staff, budget), Technical (tech failure), Business (market).

Why Analysis is Done?

Risk Analysis = Assess $Probability × Impact$ (Exposure). Purposes:

Prioritize - Focus on high-exposure risks first (Pareto)

Estimates contingency - Buffer time/budget

Mitigation planning - Decide Avoid/Transfer/Reduce/Accept

Monitoring - Triggers and tracking

Decision making - Go/no-go, prototype vs full build

Without analysis, management is reactive → cost/schedule overrun. With analysis, proactive, reduces failure chance by 30-50%.

Example: $P=0.6, Impact= High (5) → RE=3.0$ gets mitigation budget before $P=0.2, Impact=2$ .
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
Q6c. What is "Top-Down and Bottom-Up Design" approach?20235m
Module 3: Software Design & Metrics
What is "Top-Down and Bottom-Up Design" approach?

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

Top-Down and Bottom-Up Design

Top-Down:

Start from top-level system → decompose into subsystems/modules → detail. Like breaking overview into parts.

Tools: Structure chart, stepwise refinement.

Pros: Early overview, architecture clear

Cons: Low-level details delayed, needs stubs for testing

Ex: Design Online Exam → split into User, Exam, Evaluation modules

Bottom-Up:

Start from bottom-level components → combine into higher system. Build reusable parts first.

Pros: Reuse, early component testing via drivers

Cons: No system view early, integration complex

Ex: Build DB, utility libraries first → integrate into system

Hybrid: Most projects use both - Top-down for architecture, Bottom-up for building reusable components. Combined gives Sandwich/Hybrid testing.
Q7a. Differentiate between cohesion and coupling, and explain their types in brief.20237m
Module 3: Software Design & Metrics
Differentiate between cohesion and coupling, and explain their types in brief.

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

Cohesion vs Coupling (Difference + Types)

See Q113/Q40 for full table.

Cohesion (within module) - High desired:

Types best→worst: Functional > Sequential > Communicational > Procedural > Temporal > Logical > Coincidental

Coupling (between modules) - Low desired:

Types best→worst: Data > Stamp > Control > External > Common > Content

In brief: Cohesion measures intramodule bonding (why elements belong together), Coupling measures intermodule dependence (how much one depends on another). Good design = Strong cohesion, Loose coupling.

Q7b. Write a short note on PERT charts. Explain when you should use PERT charts and when you should use Gantt charts while you are performing the duties of a project manager.20237m

Module 1: Introduction & SDLC

Write a short note on PERT charts. Explain when you should use PERT charts and when you should use Gantt charts while you are performing the duties of a project manager.

View this question on its own page →

Search Google Ask AI

Worked Solution

Solution

PERT Chart

Program Evaluation & Review Technique - Network diagram for uncertain durations. Uses optimistic (O), most likely (M), pessimistic (P) → $T_e = (O+4M+P)/6$ . Nodes = events, arrows = activities. Finds critical path (longest). Probabilistic.

O—→A—→B—→ End  (with 3 estimates per arrow)

PERT vs Gantt

Aspect	PERT	Gantt
View	Network / dependencies	Bar chart / timeline
Duration type	Uncertain (3-point)	Fixed/deterministic
Shows dependencies	YES (critical path)	Weakly (bars)
Best for	Large R&D, high uncertainty, interdependent tasks	Small, stable, simple schedule
Complexity	High	Simple visual

When to use:

PERT: Project manager faces high uncertainty / R&D (e.g., new software product), need to analyze risk and critical path.
Gantt: Routine / Well-understood project, progress tracking for team, stakeholder presentation.

Often used together: PERT for planning, Gantt for monitoring.

Q8a. What is reliability? Discuss ROCOF, MTTF and MTTR with suitable example.20237m
Module 2: Requirements & SRS
What is reliability? Discuss ROCOF, MTTF and MTTR with suitable example.

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

Reliability

Probability of failure-free operation for specified time in specified environment.

ROCOF, MTTF, MTTR with Example

ROCOF = Rate of Occurrence of Failures - Failures per unit time. Ex: 2 failures/year → ROCOF=2/yr, higher ROCOF = less reliable. Reciprocal of MTBF in steady state.

MTTF = Mean Time To Failure - Average time system runs before failing (for non-repairable). Ex: 5 printers fail avg after 1000 hours → MTTF=1000h.

MTTR = Mean Time To Repair - Avg time to repair. Ex: Avg 2 hours to fix printer → MTTR=2h.

Relations:

MTBF = MTTF + MTTR (for repairable)

Availability = MTTF / (MTTF+MTTR) - Ex: MTTF=1000h, MTTR=10h → Availability=1000/1010=99%

Reliability function $R(t)=e^{-λt}$ where $λ=ROCOF$

Example: E-commerce server: MTTF=500h, MTTR=5h → MTBF=505h, Availability=99%, ROCOF≈0.002 failures/hour.
Q8b. What is cyclomatic complexity? Write a C program to calculate GCD of two numbers and calculate the cyclomatic complexity of the program.20237m
Module 3: Software Design & Metrics
What is cyclomatic complexity? Write a C program to calculate GCD of two numbers and calculate the cyclomatic complexity of the program.

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

Cyclomatic Complexity

$V(G)=E-N+2P$ or $V(G)=P+1$ where $P$ = predicate nodes. Measures independent paths.

C Program - GCD

#include <stdio.h> int gcd(int a,int b){ while(b!=0){ // P1 int t=b; b=a%b; a=t; } return a; } int main(){ int x,y; scanf("%d%d",&x,&y); if(x<=0 || y<=0){ // P2 (with || = 2 predicates) printf("Invalid"); return 0; } printf("GCD=%d",gcd(x,y)); return 0; }

Complexity Calculation

For gcd function alone:

Predicate: while(b!=0) → 1

$V(G)=1+1=2$

For main with validation:

Predicates: b!=0 (1), x<=0 (2), y<=0 (3) → $P=3$

$V(G)=3+1=4$

Via graph: $E=11, N=9, P=1$ → $V=11-9+2=4$

Paths: Need 4 test cases (e.g., (48,18), (0,5), (5,0), (18,48)).
Q9a. Write a short note on Software Reuse.20237m
Module 1: Introduction & SDLC
Write a short note on Software Reuse.

View this question on its own page →
Search Google Ask AI
Worked Solution
Solution - Short Notes (Any Two)

a) Software Reuse

Using existing assets (code, design, docs, COTS) in new projects. Types: Application system reuse, Component reuse, Object/function reuse. Benefits: Quality, cost, time saved. Problems: Not invented here, component trust, maintenance. Approaches: COTS, Product lines, Libraries.

b) Spiral Model (Barry Boehm)

Risk-driven iterative model with 4 quadrants: Objective setting → Risk analysis → Development & Validation → Planning next loop. Each spiral = version. Best for large/high-risk projects; supports prototyping. Costly for small projects.

c) Six Sigma

Quality strategy aiming 3.4 defects per million opportunities. DMAIC: Define-Measure-Analyze-Improve-Control. Uses statistical tools (SPC). Levels: White/Yellow/Green/Black Belt. Focus on defect prevention, process variation reduction.

d) Verification and Validation

V&V: Ensure quality.

Verification: Are we building product right? (Static: reviews, inspections) vs

Validation: Are we building right product? (Dynamic: testing).
Both throughout SDLC; V&V plan includes reviews, testing (unit → acceptance) and audits.
Q9b. Write a short note on Spiral model.20237m
Module 1: Introduction & SDLC
Write a short note on Spiral model.

View this question on its own page →
Search Google Ask AI
Worked Solution
Spiral Model - Short Note

Proposed by: Barry Boehm in 1986. It is an iterative, risk-driven software development model where the project is developed in a series of spiral cycles (repeated loops), each of which passes through four phases.

Four Phases of Each Spiral Cycle

Planning - Determine objectives, alternatives and constraints for that cycle; finalize deliverables and the schedule.

Risk Analysis - Evaluate alternatives, identify and resolve risks (prototypes are built for risky areas). This is the distinguishing feature of the model.

Engineering - Development and testing of the product for the current increment.

Customer Evaluation - The customer reviews the output, gives feedback, and approves the next cycle.

Key Characteristics

Combines waterfall + prototyping + incremental development, with emphasis on risk handling.

Each loop produces a prototype of the system; the final prototype is the finished system.

Strong documentation control and support for reuse.

Requirements can change between cycles, so it is very flexible.

Advantages

Risk is analyzed and resolved early, so costly failures are avoided.

Good for large, complex, high-risk projects.

Customers see working results early and can give feedback.

Accommodates requirement changes easily.

Disadvantages

Complex and expensive to manage (risk analysis needs expertise).

Hard to estimate cost and schedule.

Not suitable for small or low-risk projects.

Risk prototypes may not cover all modules.

When to Use

Projects that are large, critical and risk-prone, where risk must be controlled at every phase - e.g. defence, aerospace and large enterprise systems.

Q9c. Write a short note on Six Sigma.20237m

Module 4: Software Testing

Write a short note on Six Sigma.

View this question on its own page →

Search Google Ask AI

Worked Solution

Six Sigma - Short Note

Six Sigma is a disciplined, data-driven quality/process improvement methodology developed by Motorola (1986) and popularised by GE. The Greek letter sigma (σ) denotes standard deviation; Six Sigma means only 3.4 defects per million opportunities (DPMO), i.e. 99.99966% defect-free output.

Core Idea

Identify defects and variation in a process, then remove their root causes so that the process output is consistently within customer specifications.
Focus is on improving the process, not blaming the people.

Two Project Methodologies

DMAIC (improve existing process)	DMADV / Design for Six Sigma (create new process)
Define - problem, goals, team	Define - customer needs and goals
Measure - current performance	Measure - CTQs (critical to quality) characteristics
Analyze - find root causes	Analyze - design alternatives
Improve - implement and verify solution	Design - detailed design
Control - sustain the gains	Verify - validate the design with trials

Quality Levels (Sigma Levels)

Sigma Level	DPMO	Yield
4σ	6,210	99.38%
5σ	233	99.9767%
6σ	3.4	99.99966%

Roles (Belt System)

Champion - sponsors the project
Master Black Belt - trains and mentors
Black Belt - leads projects full time
Green Belt - assists part time
Yellow Belt - basic awareness

Advantages

Fewer defects, lower cost of poor quality and rework.
Higher customer satisfaction and consistency.
Data-driven decisions, measurable results.
Works for manufacturing and service/software processes.

Limitations

Needs strong management commitment and trained experts.
Over-emphasis on statistics can slow small projects.
Success depends on cultural change, not just tools.

Conclusion: Six Sigma, usually combined with Total Quality Management (TQM), gives a systematic, measurable way to drive defects towards zero.

Q9d. Write a short note on Verification and Validation.20237m

Module 4: Software Testing

Write a short note on Verification and Validation.

View this question on its own page →

Search Google Ask AI

Worked Solution

Verification and Validation - Short Note

Verification and Validation (V&V) are the two pillars of software quality assurance, applied throughout the SDLC.

Definitions

Verification: "Are we building the product right?" - confirming that each work product (requirement, design, code) conforms to its specification. It is a static activity - done without executing the software.
Validation: "Are we building the right product?" - confirming that the final product actually satisfies the customer's needs and intended use. It is a dynamic activity - done by running the software.

Difference Table

Aspect	Verification	Validation
Question	Building the product right	Building the right product
Checks against	Specification/design	User needs & requirements
Execution	No execution needed	Requires execution
Timing	During development	After development / at delivery
Examples	Reviews, walkthroughs, inspections, static analysis, reviews of SRS/design	Unit, integration, system and acceptance testing, alpha/beta testing
Found by	QA team, peers, reviewers	Test engineers, customer

Techniques

Verification (static): Reviews (informal, walkthrough, peer review, Fagan inspection), static analysis tools, formal/mathematical proof, traceability and document checks.

Validation (dynamic): Unit testing, integration testing, system testing, acceptance testing, prototyping, alpha and beta testing with real users.

Objectives

Detect defects early, when they are cheapest to fix.
Ensure correctness, completeness, consistency and traceability.
Reduce rework, cost and project risk.
Build customer confidence that quality goals are met.

Conclusion: V&V must run in parallel throughout the SDLC - validation without verification misses design flaws, and verification without validation never checks real user needs.

Previous year2022 Next year2024

Official AppAndroid App

PYQDeck for Android

Solve BEU previous-year exam papers anywhere, anytime. Fast search, offline paper viewing, and step-by-step solutions designed specifically for your phone.

Get on Google Play

Software Engineering

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Why?

Why not the others?

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

Explanation

Solution

What is Software Engineering?

Pocketly on Android

Solution

Software Engineering Process

Solution

Waterfall Model in Detail (with Diagram)

Solution

Architectural Styles Applied for Software Development

Solution

Acceptance Testing

Alpha Testing

Beta Testing

Solution

Software Metric for Qualitative Assessment & Maintenance Side Effects

Solution

COCOMO Model for Estimation (Boehm, 1981)

Solution

Drivers and Stub Modules

Why Required?

Solution - Mail Order Processing System DFD

Context Diagram (Level 0)

Level 1

Solution

SRS - Software Requirements Specification

Features of SRS

Solution

What is Risk?

Why Analysis is Done?

Pocketly on Android

Solution

Top-Down and Bottom-Up Design

Solution

Cohesion vs Coupling (Difference + Types)

Solution

PERT Chart

PERT vs Gantt

Solution

Reliability

ROCOF, MTTF, MTTR with Example

Solution

Cyclomatic Complexity

C Program - GCD

Complexity Calculation

Solution - Short Notes (Any Two)

a) Software Reuse

b) Spiral Model (Barry Boehm)

c) Six Sigma

d) Verification and Validation

Spiral Model - Short Note

Four Phases of Each Spiral Cycle

Key Characteristics

Advantages

Disadvantages

When to Use

Six Sigma - Short Note

Core Idea

Two Project Methodologies

Quality Levels (Sigma Levels)

Roles (Belt System)