About this previous year paper
SECTION A – Very Short Answer Type
(2 × 10 = 20 Marks)
a) Software Engineering
Software Engineering is the systematic, disciplined, and quantifiable approach to the development, operation, maintenance, and retirement of software.
b) Components of Software
The main components of software are:
Programs (code) Documentation Operating procedures
c) Software Crisis
Software crisis refers to the difficulty of developing large, complex, and reliable software systems within time, cost, and quality constraints.
d) ISO 9000 vs SEI-CMM
ISO 9000 focuses on quality management standards, while SEI-CMM focuses on process maturity levels for software development organizations.
e) Top-Down vs Bottom-Up Design
Top-down design starts from the overall system and breaks it into modules, whereas bottom-up design builds the system by integrating small components first.
f) Control Flow Graph
A control flow graph represents all possible paths through a program using nodes and edges, mainly used in white box testing.
g) Failure vs Fault
Fault is a defect in the software.
Failure occurs when the software behaves incorrectly due to a fault.
h) Importance of White Box Testing
White box testing ensures internal logic, loops, and conditions are tested, improving code quality and coverage.
i) Reasons for Increase in Software Cost
Increasing software complexity
Frequent requirement changes
j) Software Configuration Management (SCM)
SCM is the process of tracking, controlling, and managing changes in software throughout its life cycle.
SECTION B – Long Answer Type
(Attempt any three – 10 Marks each)
2(a) Waterfall Model
The Waterfall Model is a linear sequential model where each phase must be completed before the next begins.
Phases: Requirement analysis
System design Implementation
Testing Deployment
Maintenance
Advantages: Simple and easy to understand
Well-defined stages Suitable for small projects
Disadvantages: No flexibility for changes
Late testing Not suitable for large or complex projects
2(b) Decision Tables
Decision tables are used to represent complex business rules clearly.
Components: Condition stub
Condition entries Action stub
Action entries Bookstore Decision Table (Summary):
| Customer Type | Quantity | Discount |
|---|---|---|
| Trade | >6 | 25% |
| Library/Individual | 6–19 | 5% |
| Library/Individual | 20–49 | 10% |
| Library/Individual | ≥50 | 15% |
Decision tables help remove ambiguity in decision-making.
2(c) Cohesion and Coupling
Cohesion:
Measures how closely related the functions within a module are.
Types: Coincidental, Logical, Temporal, Procedural, Communicational, Sequential, Functional.
Coupling:
Measures interdependence between modules.
Types: Content, Common, Control, Stamp, Data.
High cohesion and low coupling are desirable for good software design.
2(d) Test Drivers and Test Stubs
Test Driver: Simulates calling module (used in bottom-up testing).
Test Stub: Simulates called module (used in top-down testing).
They enable early testing and fault isolation.
2(e) Cost Analysis and COCOMO Model
Cost analysis estimates effort, time, and cost of software development.
COCOMO Model: Effort = a × (KLOC)^b
Types: Basic COCOMO
Intermediate COCOMO Detailed COCOMO
It helps in project planning and budgeting.
SECTION C – Descriptive Answer Type
3(a) Spiral Model and Risk Analysis
The Spiral Model combines iterative development with risk analysis.
Phases: Planning
Risk analysis Engineering
Evaluation
Risk analysis identifies technical, schedule, and cost risks early, reducing project failure chances.
3(b) Software Development Life Cycle (SDLC)
SDLC defines stages of software development:
Requirement analysis Design
Coding Testing
Deployment Maintenance
It ensures systematic development and quality assurance.
4(a) Importance of SRS and IEEE Format
SRS defines what the software should do.
Importance: Acts as a contract
Reduces ambiguity Basis for design and testing
IEEE SRS Format: Introduction
Overall description Functional requirements
Non-functional requirements External interfaces
4(b) Requirement Elicitation
Requirement elicitation gathers user needs and expectations.
Techniques: Interviews
Questionnaires Observation
Workshops Prototyping
5(a) Top-Down vs Bottom-Up Design
Top-Down: Easy understanding
Early system overview Needs stubs
Bottom-Up: Reusable components
Easy testing Needs drivers
Both have advantages depending on project type.
5(b) Halstead’s Software Science
Halstead metrics measure: Program length
Volume Difficulty
Effort
They help estimate program complexity and development effort.
6(a) Software Design Strategies
Design strategies include: Modular design
Structured design Object-oriented design
Good design improves maintainability, scalability, and reliability.
6(b) Formal Reviews, Walkthrough, Code Inspection
Formal Technical Review: Structured peer review
Walkthrough: Informal review led by author
Code Inspection: Detailed line-by-line analysis
7(a) Software Maintenance
Maintenance is required to: Fix bugs
Adapt to changes Improve performance
Types: Corrective
Adaptive Perfective
Preventive
7(b) Risk Management
Risk management identifies and controls project uncertainties.
Types: Project risk
Technical risk
Project risks affect schedules and cost, while technical risks affect performance and quality.