1. Define Software Quality.
Software Quality shows how good and reliable a product is.
Software Quality → It is the degree to which a software product satisfies the specified
requirements, user needs, and expectations, ensuring it is reliable, efficient, maintainable,
and meets defined standards.
2. Differentiate between Product and Process in software engineering.
Aspect Product Process
The set of activities,
The final software system methods, and practices
Definition
delivered to the customer. used to develop the
product.
Focuses on how it is
Focuses on what is
Focus developed (the steps
delivered (the outcome).
followed).
Quality measured in terms
Quality measured in terms
of efficiency, defect rate,
Measurement of performance, reliability,
adherence to standards,
usability, etc.
etc.
3. What do you mean by Feasibility Study in project management.
Purpose: Determines whether the project is viable before development begins.
Checks whether it is technically possible, economically viable, legally permissible, and
operationally achievable before actual development begins.
4. Apply effort estimation techniques COCOMO model to a small project scenario.
5. Apply the LOC-based productivity measure to calculate productivity, given total LOC
and effort in person-months.
6. Demonstrate with an example how software metrics can be used to assess
software quality.
Software Metrics are quantitative measures used to assess quality.
DD=Number of Defects / KLOC
For example, if a project has 50 defects in 20 KLOC, defect density = 2.5 defects/KLOC.
Lower defect density indicates higher reliability and better software quality.
7. Define Configuration Item (CI).
Perfect 👍 You’ve listed many important exam questions from Unit 1 & Unit 2. Based on
your PDFs , I’ll give you clear, exam-ready answers (short for 2 marks, expanded for 5–10
marks where needed).
8. Define Configuration Item (CI)
A CI is any software component (code, document, design, test case, etc.) that is placed
under configuration management and treated as a single unit for version control and
change tracking. ✅
2. Why do many software projects fail despite good planning?
Unclear or changing requirements
Lack of user involvement & communication
Unrealistic deadlines & poor time estimation
Insufficient testing & quality issues
Underestimating maintenance & resources
3. Agile model: customer collaboration & adaptability
Agile delivers software in small iterations (1–3 weeks).
Customer feedback is taken after every iteration.
Changing requirements are welcomed anytime.
Ensures customer satisfaction & adaptability to evolving needs.
4. Identifying Functional & Non-Functional Requirements (Online Banking System)
Functional: Login, balance inquiry, fund transfer, bill payment.
Non-Functional: Security (SSL encryption), performance (response < 3s), availability
(24×7 uptime).
👉 Identifying both helps design a system that is usable, reliable, and secure.
5. Project Control Technique Example
Milestones & Checkpoints: Set milestones (e.g., "Login module complete by Week
2").
Progress checked at each milestone → deviations spotted early → corrective action
taken.
6. Apply COCOMO (10 KLOC Project)
For Organic Mode (a=2.4,b=1.05a=2.4, b=1.05):
Effort:
E=2.4×(10)1.05≈27 Person-MonthsE = 2.4 \times (10)^{1.05} \approx 27 \text{ Person-
Months}
Time:
T=2.5×(27)0.38≈8.6 MonthsT = 2.5 \times (27)^{0.38} \approx 8.6 \text{ Months}
Avg. Staff: 27/8.6≈327 / 8.6 ≈ 3 persons.
7. What is a Baseline in SCM?
A baseline is a formally reviewed and approved version of a software product (or
document) that serves as a reference for further development and can only be changed
through formal change control.
8. Verification vs Validation
Verification: Are we building the product right? (checking design, code reviews).
Validation: Are we building the right product? (testing against requirements).
9. Role of Baseline in controlling project changes
Provides a reference point to measure progress.
Prevents uncontrolled changes (scope creep).
Any modification must go through formal change control.
10. Requirement Elicitation (Online Food Delivery System)
Interviews with restaurant owners & users.
Brainstorming for features (order tracking, offers).
Use cases (placing an order, making payment).
Prioritize requirements → final SRS.
11. Delphi Technique for Effort Estimation (Uncertain Requirements)
Experts give independent estimates.
Estimates shared anonymously & iteratively refined.
Consensus reached → reliable effort estimate.
12. Differentiate Functional & Non-Functional Requirements
Functional Non-Functional
Define what system must do Define how well system performs
E.g., Login, fund transfer, report E.g., Security, performance, usability,
generation reliability
Directly visible to users Often invisible to users but critical
