SOFTWARE ENGINEERING (KCS601)
Section-wise Detailed Answers – B.Tech Semester VI
SECTION A
(Attempt all questions – brief but descriptive answers)
Q1(a) Characteristics of software
Software is an intangible product that is developed rather than manufactured. It does not wear out like hardware but deteriorates due to changes and maintenance. Software is highly complex, custom-built for specific requirements, and continuously evolves over time. It requires systematic development and maintenance to ensure reliability and quality.
Q1(b) Define SDLC
Software Development Life Cycle (SDLC) is a structured framework that defines the phases involved in developing software from initial requirement analysis to deployment and maintenance. It ensures systematic planning, development, testing, and delivery of high-quality software products.
Q1(c) Define software crisis
Software crisis refers to the difficulties faced during software development due to increasing complexity, cost overruns, delayed delivery, poor quality, and failure to meet user requirements. It highlighted the need for disciplined software engineering practices.
Q1(d) Comparison between ISO 9000 and SEI-CMM
ISO 9000 focuses on quality management systems and documentation standards applicable across industries, while SEI-CMM (Capability Maturity Model) focuses specifically on improving software development processes by defining maturity levels. ISO emphasizes compliance, whereas CMM emphasizes process improvement.
Q1(e) Cyclomatic complexity and methods of finding it
Cyclomatic complexity measures the logical complexity of a program by counting the number of independent paths. It can be calculated using control flow graphs, decision points, or the formula V(G) = E − N + 2, where E is edges and N is nodes. Higher complexity indicates higher testing effort.
Q1(f) Function-oriented design
Function-oriented design organizes software around functions rather than data. The system is decomposed into smaller functional modules using techniques such as Data Flow Diagrams. Each module performs a specific task, and data is passed between modules.
Q1(g) Verification vs Validation
Verification ensures that the software is built correctly according to specifications, while validation ensures that the right software is built according to user needs. Verification focuses on process correctness, whereas validation focuses on product correctness.
Q1(h) Stub and driver
A stub is a dummy module used to simulate lower-level modules during top-down testing. A driver is a temporary program used to invoke higher-level modules during bottom-up testing. Both support incremental integration testing.
Q1(i) Adaptive vs corrective maintenance
Corrective maintenance fixes defects found after software delivery. Adaptive maintenance modifies software to adapt to changes in environment such as hardware or operating system. Corrective deals with errors, while adaptive deals with external changes.
Q1(j) Software re-engineering vs reverse engineering
Reverse engineering analyzes existing software to understand its structure and behavior without altering functionality. Software re-engineering goes a step further by improving the system through restructuring, refactoring, or modernization.
SECTION B
(Attempt any three – detailed explanations)
Q2(a) Prototyping model of SDLC and its advantages
The prototyping model involves creating an early working model of the software to understand user requirements clearly. The prototype is evaluated by users, refined repeatedly, and finally converted into the actual system. This model reduces requirement ambiguity, improves user involvement, and minimizes rework compared to conventional models like Waterfall.
(Diagram explanation: prototype loop between user feedback and refinement)
Q2(b) Level-2 DFD of Smart College Campus
A Level-2 Data Flow Diagram of a Smart College Campus further decomposes major processes such as admissions, attendance, library management, examination system, and fee management. It shows detailed data flows between students, faculty, administration, and databases, enabling better system understanding and design clarity.
Q2(c) Top-down vs Bottom-up software design
Top-down design starts from high-level system functions and gradually breaks them into detailed modules. It provides better system overview but delays testing of lower modules. Bottom-up design starts from low-level modules and integrates them upward, allowing early testing but lacking early system visibility. Each approach has advantages depending on project nature.
Q2(d) Regression testing and test case prioritization
Regression testing ensures that changes in software do not introduce new defects in existing functionality. Test case prioritization ranks test cases based on factors such as fault detection capability, code coverage, and risk. Prioritization improves testing efficiency under limited time and resources.
Q2(e) Need and types of software maintenance
Software maintenance is required to correct defects, adapt to environmental changes, improve performance, and add new features. Types include corrective, adaptive, perfective, and preventive maintenance. Maintenance ensures long-term usability and reliability of software systems.
SECTION C
Q3(a) Spiral model and risk analysis
The Spiral Model combines iterative development with systematic risk analysis. Each spiral loop involves planning, risk identification, development, and evaluation. Risk analysis is the core feature, allowing early detection and mitigation of technical, cost, and schedule risks, making it suitable for large and complex projects.
Q3(b) Need of SDLC and evolutionary development model
SDLC is needed to manage complexity, ensure quality, and control project execution. The evolutionary development model builds software incrementally by delivering functional versions in stages. It allows continuous user feedback and accommodates changing requirements effectively.
Q4(a) Decision tables and bookstore discount scenario
Decision tables represent complex decision logic using conditions and actions. In the bookstore scenario, conditions include customer type and number of books ordered, while actions specify discount percentages. Decision tables ensure clarity, consistency, and completeness of business rules.
Q4(b) Importance of Software Requirement Specification (SRS)
SRS document clearly defines functional and non-functional requirements of software. It acts as a contract between users and developers and serves as a basis for design, testing, and maintenance. The IEEE SRS format includes introduction, overall description, system features, external interfaces, and constraints.
Q5(a) Modularity and low coupling–high cohesion
Modularity divides software into independent modules. High cohesion ensures each module performs a single task, while low coupling minimizes interdependence. This improves maintainability, reusability, and functional independence, resulting in better software quality.
Q5(b) Software design strategies and FOD vs OOD
Software design strategies include top-down, bottom-up, structured, and object-oriented approaches. Function-Oriented Design focuses on functions and data flow, while Object-Oriented Design focuses on objects, classes, and encapsulation. OOD offers better scalability and maintainability.
Q6(a) Halstead software metrics and token count
Halstead metrics measure software complexity based on operators and operands. Token count refers to counting distinct and total operators and operands. These metrics estimate program length, effort, difficulty, and development time.
Q6(b) Black-box vs white-box testing
Black-box testing focuses on functionality without internal code knowledge, while white-box testing examines internal logic and control paths. Using both together ensures comprehensive testing of functionality and internal correctness.
Q7(a) Risk management and project vs technical risk
Risk management involves identifying, analyzing, and controlling uncertainties. Project risks affect schedule, cost, and resources, while technical risks affect design, technology, and performance. Effective risk management ensures project success.
Q7(b) Cost analysis and COCOMO model
Cost analysis estimates development effort and cost. The COCOMO model uses size-based estimation and classifies projects into organic, semi-detached, and embedded modes. It provides effort, development time, and cost estimates using empirical formulas.
(Diagram explanation: COCOMO estimation flow)
