1.

Software Development Life Cycle (SDLC)

Q1: Explain the various phases of the SDLC.
Answer: The SDLC consists of the following phases:
. Requirement Analysis: Identify user needs and document them.
. System Design: Create the architecture of the system, including modules, interfaces, and
data flow.
. Implementation (Coding): Develop the system according to the design.
. Testing: Verify that the software meets requirements and is free of bugs.
. Deployment: Release the software to production.
. Maintenance: Fix issues, update, and improve the software over time.
4
2. Software Process Models
3
Q2: Compare Waterfall and Agile models.
2
Answer:
1
Feature Waterfall Model Agile Model
Approach Linear and sequential Iterative and incremental
Flexibility Rigid; no scope for Highly flexible;
changes accommodates changes
Delivery Product delivered at the Delivered in iterations
end
Customer Involvement Minimal Continuous and high
Best Suited For Small, well-defined Dynamic, evolving
projects projects
3. Software Design
Q3: What is modularity in software design, and why is it important?
Answer:
● Modularity refers to dividing a software system into smaller, manageable, and
independent modules.
● Importance:
. Enhances readability and maintainability.
. Supports reusability of code.
. Makes debugging and testing easier.
. Reduces system complexity.
6
4. Software Testing
5
Q4: Differentiate between Black Box and White Box Testing.
4
Answer:
3
Feature Black Box Testing White Box Testing
2
Focus External behavior of Internal logic and
1
software
 Internal logic and
software structure
Knowledge Required No knowledge of code Requires knowledge of
required code
Techniques Equivalence partitioning, Statement coverage,
boundary testing path coverage
Tester Done by end-users or Done by developers or
testers testers
5. Requirements Engineering
Q5: What are the functional and non-functional requirements?
Answer:
● Functional Requirements: Define specific behaviors or functions of a system, e.g., login,
search, data validation.
● Non-Functional Requirements: Define quality attributes, e.g., performance, scalability,
security, and usability.

6. Software Maintenance
Q6: Explain the types of software maintenance.
Answer:
. Corrective Maintenance: Fixing bugs or defects.
. Adaptive Maintenance: Modifying software to work in new environments.
. Perfective Maintenance: Enhancing functionality or performance.
. Preventive Maintenance: Updating software to prevent future issues.

7. Risk Management
Q7: What are the steps in software risk management?
Answer:
. Risk Identification: Identify potential risks.
. Risk Analysis: Assess the likelihood and impact of risks.
. Risk Prioritization: Rank risks based on severity.
. Risk Mitigation: Develop strategies to reduce or eliminate risks.
. Risk Monitoring: Continuously track and address risks.

8. Software Project Management

Q8: What is effort estimation? Explain COCOMO.
Answer:
● Effort Estimation: Predicting the resources (time, effort, cost) required to complete a
project.
● COCOMO (Constructive Cost Model):
. Basic COCOMO: For small, simple projects.
. Intermediate COCOMO: Includes project attributes like complexity and size.
. Detailed COCOMO: Incorporates all factors affecting software.
9. CASE Tools
Q9: What are CASE tools? Explain their types.
Answer:
● CASE Tools: Computer-Aided Software Engineering tools help automate software
development processes.
● Types:
. Upper CASE Tools: For planning and designing (e.g., UML tools).
. Lower CASE Tools: For coding and testing.
. Integrated CASE Tools: Cover the entire SDLC.

10. Agile Methodology

Q10: What are the principles of Agile Manifesto?
Answer:
. Customer satisfaction through early and continuous delivery.
. Welcome changing requirements.
. Deliver working software frequently.
. Collaboration between business stakeholders and developers.
. Build projects around motivated individuals.
. Face-to-face communication.
. Working software is the primary measure of progress.
. Sustainable development pace.
. Technical excellence and good design.
. Simplicity.
. Self-organizing teams.
. Reflect regularly to improve.

11. Software Quality

Q11: What are the attributes of software quality?
Answer:
. Functionality: Completeness and correctness.
. Reliability: Failure-free operation over time.
. Usability: Ease of use.
. Efficiency: Optimal use of resources.
. Maintainability: Ease of modifications.
. Portability: Ability to work in different environments.
1. Software Requirements
Q1: What is Requirements Engineering? Explain its steps.
Answer: Requirements Engineering (RE) is the process of gathering, analyzing, documenting,
and managing the requirements of a software system.
Steps:
. Feasibility Study: Assess whether the requirements are achievable given constraints
(time, cost, technology).
. Requirement Elicitation: Gather requirements through interviews, surveys, or
 .
observations.
. Requirement Analysis: Resolve conflicts, prioritize, and ensure feasibility of requirements.
. Requirement Specification: Document requirements in an SRS (Software Requirements
Specification).
. Requirement Validation: Verify correctness, completeness, and consistency.
. Requirement Management: Handle requirement changes during development.

2. Software Architecture
Q2: What are the different software architecture styles?
Answer:
. Layered Architecture:
○ System divided into layers (e.g., presentation, business logic, data).
○ Example: Web applications.
. Client-Server Architecture:
○ Clients request services from a central server.
○ Example: Online banking systems.
. Microservices Architecture:
○ Independent, small services communicate through APIs.
○ Example: E-commerce platforms.
. Pipe-and-Filter Architecture:
○ Data flows through a sequence of filters (components) via pipes.
○ Example: Data processing systems.
. Event-Driven Architecture:
○ Components interact by sending and receiving events.
○ Example: Real-time monitoring systems.

3. Software Design Principles

Q3: Explain the SOLID principles of Object-Oriented Design.
Answer:
. Single Responsibility Principle (SRP):
○ A class should have one reason to change, i.e., one responsibility.
. Open/Closed Principle (OCP):
○ Classes should be open for extension but closed for modification.
. Liskov Substitution Principle (LSP):
○ Subclasses should be replaceable for their base classes without affecting
correctness.
. Interface Segregation Principle (ISP):
○ A class should not be forced to implement interfaces it doesn’t use.
. Dependency Inversion Principle (DIP):
○ High-level modules should not depend on low-level modules; both should depend
on abstractions.

4. Software Metrics
Q4: What are software metrics? Explain their types.
Answer: Software Metrics measure the quality, productivity, and performance of software.
Types:
. Product Metrics:
○ Measure software quality.
○ Examples: Lines of Code (LOC), Cyclomatic Complexity.
. Process Metrics:
○ Measure the efficiency of software development processes.
○ Examples: Defect density, productivity rate.
. Project Metrics:
○ Measure project management and delivery aspects.
○ Examples: Cost, schedule variance.

5. Software Testing
Q5: Explain different levels of software testing.
Answer:
. Unit Testing:
○ Tests individual components or modules.
○ Example: Testing a login function.
. Integration Testing:
○ Tests interactions between modules.
○ Approaches: Top-down, Bottom-up, Sandwich.
. System Testing:
○ Tests the complete integrated system for compliance with requirements.
○ Includes functional and non-functional testing.
. Acceptance Testing:
○ Performed by the end-user to validate the system meets business needs.

6. Software Configuration Management

Q6: What is Software Configuration Management (SCM)? Explain its activities.
Answer: SCM is the process of tracking and controlling changes in software.
Activities:
. Version Control:
○ Manage changes to source code.
○ Example: Git, SVN.
. Configuration Identification:
○ Identify configuration items (CI) like code, documents, and test cases.
. Configuration Control:
○ Approve and implement changes systematically.
. Configuration Audits:
○ Ensure compliance with specifications and standards.
. Status Reporting:
○ Track and report changes to stakeholders.

7. Risk Management
Q7: What are the common risks in software projects? How can they be mitigated?
Answer: Common Risks:
. Requirement Risks: Changing or unclear requirements.
○ Mitigation: Proper requirement analysis and customer collaboration.
. Technical Risks: Use of new or unproven technologies.
○ Mitigation: Conduct feasibility studies and pilot testing.
. Project Risks: Budget or schedule overruns.
○ Mitigation: Effective project planning and resource management.
. Operational Risks: Inefficient processes or team conflicts.
○ Mitigation: Regular training and conflict resolution strategies.

8. Agile Methodology
Q8: Compare Scrum and Kanban methodologies.
Answer:
Feature Scrum Kanban
Approach Iterative (work in sprints) Continuous (workflows)
Roles Defined (Scrum Master, Flexible, no strict roles
Product Owner)
Work Limits Time-boxed sprints Work-in-progress limits
Best Suited For Complex projects with Maintenance and
changing requirements production environments
9. Software Quality Assurance (SQA)
Q9: What are the activities involved in SQA?
Answer:
. Process Definition: Define standards and procedures.
. Audits and Reviews: Ensure compliance with quality standards.
. Testing: Validate that the system meets requirements.
. Defect Tracking: Identify and resolve defects systematically.
. Metrics Collection: Analyze performance and quality trends.

10. Software Maintenance

Q10: What challenges are faced during software maintenance?
Answer:
. Understanding Legacy Code:
○ Solution: Proper documentation and code reviews.
. Managing Dependencies:
○ Solution: Use dependency management tools and update libraries.
. High Costs:
○ Solution: Use automation for testing and deployment.
. Evolving Requirements:
○ Solution: Adopt Agile methodologies for flexibility.
11. CASE Tools
Q11: Explain how CASE tools improve productivity in software development.
Answer: CASE tools automate repetitive tasks and streamline development:
. Requirement Tools: Document and analyze requirements.
. Design Tools: Create UML diagrams and design blueprints.
. Code Generation Tools: Automatically generate code from models.
. Testing Tools: Perform automated unit, integration, and regression testing.
. Version Control Tools: Manage changes to source code.
12. Software Development Models
Q12: Compare the Spiral and V-Model in software development.
Answer:
Feature Spiral Model V-Model (Verification
and Validation Model)
Approach Iterative and risk-driven Sequential and testing-
driven
Phases Multiple iterations with Each development
risk assessment phase has a
corresponding testing
phase
Risk Management Explicitly addresses risks Minimal risk analysis
Flexibility High; supports changes Low; changes are
during development difficult to handle
Best Suited For Complex, high-risk Small to medium-sized
projects projects with clear
requirements
13. Software Testing Techniques
Q13: Explain the concept of equivalence partitioning and boundary value analysis.
Answer:
. Equivalence Partitioning:
○ Divides input data into partitions (valid and invalid) where test cases are derived.
○ Example: For a range of 1–100, valid inputs are within the range, and invalid ones
are outside.
. Boundary Value Analysis:
○ Focuses on testing at the boundaries of input ranges.
○ Example: For a range of 1–100, test cases include 0, 1, 100, and 101.

14. Software Estimation

Q14: What is Function Point Analysis (FPA)? Explain its steps.
Answer: FPA is a technique to estimate the size of a software project based on its functionality.
Steps:
. Identify Inputs, Outputs, and Inquiries:
○ Count data inputs, outputs, and queries from the system.
. Identify Files and Interfaces:
○ Count internal files and external interfaces.
. Assign Weights:
○ Assign weights to each item based on complexity (low, medium, high).
. Calculate Unadjusted Function Points (UFP):
○ Sum up the weighted counts.
. Determine Complexity Adjustment Factor (CAF):
○ Use a scale (0–5) for 14 factors, such as performance and portability.
. Calculate Function Points (FP):
○ FP = UFP × CAF.

15. Software Reengineering

Q15: What is software reengineering, and why is it important?
Answer: Software Reengineering is the process of improving existing software to enhance
performance, maintainability, or functionality without changing its core purpose.
Steps:
. Inventory Analysis: Assess the existing system.
. Reverse Engineering: Understand and extract existing code structure.
. Code Restructuring: Clean up and optimize code.
. Data Restructuring: Improve database organization.
. Forward Engineering: Develop the improved system.
Importance:
● Reduces maintenance costs.
● Improves scalability and performance.
● Preserves valuable functionality.

16. Software Risk Management

Q16: What are qualitative and quantitative risk analysis techniques?
Answer:
. Qualitative Risk Analysis:
○ Uses subjective assessments like expert judgment and checklists.
○ Example: Assigning High, Medium, or Low severity levels to risks.
. Quantitative Risk Analysis:
○ Uses mathematical models to determine risk probability and impact.
○ Example: Expected Monetary Value (EMV) = Risk Probability × Impact.

17. Software Metrics

Q17: Explain Cyclomatic Complexity and its calculation.
Answer: Cyclomatic Complexity is a metric to measure the complexity of a program by counting
the independent paths in its control flow.
Formula:
V
(
G
)
=
E
−
N
+
2
P
V(G)=E−N+2P
Where:
● E

E: Number of edges (connections) in the control flow graph.

● N

N: Number of nodes (decision points).

● P

P: Number of connected components (typically 1 for a single program).

Steps:
. Draw the control flow graph.
. Identify E

E, N

N, and P

P.
. Apply the formula.
Importance:
● Helps in determining the effort required for testing and maintenance.

18. Software Design Patterns

Q18: What are design patterns? Explain different types with examples.
Answer: Design Patterns are reusable solutions to common software design problems.
Types:
. Creational Patterns:
○ Focus: Object creation.
○ Example: Singleton, Factory Method.
. Structural Patterns:
○ Focus: Composition of classes/objects.
○ Example: Adapter, Composite.
. Behavioral Patterns:
○ Focus: Communication between objects.
○ Example: Observer, Strategy.
Example (Singleton Pattern):
● Ensures a class has only one instance.
● Code:
● public class Singleton {
● private static Singleton instance;
● private Singleton() {}
● public static Singleton getInstance() {
● if (instance == null) {
● instance = new Singleton();
● }
● return instance;
● }
● }.
●

19. DevOps in Software Engineering

Q19: What is DevOps? Explain its lifecycle.
Answer: DevOps is a culture and set of practices that combine development and IT operations
to automate and improve software delivery.
DevOps Lifecycle:
. Plan: Define requirements and goals.
. Develop: Write and build the code.
. Build: Compile and package the application.
. Test: Perform automated and manual testing.
. Release: Deploy the software to production.
. Operate: Monitor and maintain the system.
. Monitor: Collect feedback and improve.
Tools:
● Planning: Jira, Trello.
● CI/CD: Jenkins, GitHub Actions.
● Monitoring: Nagios, Prometheus.

20. Software Deployment Models

Q20: What are the types of software deployment models?
Answer:
 . Big Bang Deployment:
○ All components are deployed at once.
○ Use Case: Small projects or systems with minimal dependencies.
. Phased Deployment:
○ Incremental rollout of components.
○ Use Case: Enterprise applications with high complexity.
. Rolling Deployment:
○ Gradual replacement of old components with new ones.
○ Use Case: Cloud-based applications.
. Blue-Green Deployment:
○ Two identical environments (Blue: old, Green: new); switch traffic to Green after
testing.
○ Use Case: Zero-downtime applications.
. Canary Deployment:
○ Release to a small subset of users before a full rollout.
○ Use Case: Risk mitigation for major updates.

7.a) Explain the software life cycle model that incorporates risk factors.
Answer: Spiral Model
The Spiral Model is a risk-driven software life cycle model that emphasizes iterative
development while systematically addressing risks at every stage. It was proposed by Barry
Boehm.
Phases of the Spiral Model:
. Objective Setting: Define objectives, alternatives, and constraints for the current iteration.
. Risk Assessment: Identify potential risks and analyze their impact on the project.
. Development and Testing: Develop the system incrementally, perform testing, and
integrate it.
. Planning for the Next Iteration: Plan subsequent phases based on risk analysis and
feedback.
Key Features:
● Emphasis on risk analysis and mitigation.
● Iterative approach to handle evolving requirements.
● Suitable for large, complex, and high-risk projects.

7.b) Draw the Context-Level DFD and Level-1 DFD for the Store System
Context-Level DFD:
This shows the system as a single process interacting with external entities.
Entities:
. Customer
. Supplier
. Store Management
Context-Level Diagram:
. Customer places orders and receives updates.
. Supplier provides items and schemes.
. Store Management handles inventory and transaction data.
(Diagram would be drawn with external entities connected to a single central process "Store
System.")
Level-1 DFD:
Break down the context-level process into multiple sub-processes:
. Order Management: Handles customer orders.
. Inventory Management: Maintains item stock and updates availability.
. Supplier Management: Manages supplier registration and schemes.
. Transaction Management: Stores daily transactions and customer details.
(Diagram would show these sub-processes with data flows connecting them.)

8.a) Function Point Analysis (FPA) and Its Advantages Over LOC
Answer:
FPA estimates the size of software based on its functionality, independent of programming
language or technology.
Steps:
. Count:
○ External Inputs (EI), External Outputs (EO), External Interface Files (EIF), Internal
Logical Files (ILF), and External Inquiries (EQ).
. Assign Weights:
○ Assign low, medium, or high weights to each based on complexity.
. Calculate Unadjusted Function Points (UFP):

UFP=∑(Count×Weight)
. Adjust using the Value Adjustment Factor (VAF):
○ Determine VAF based on general system characteristics.
5.

AdjustedFP=UFP×VAF
Advantages over LOC:
. Language-independent.
. Reflects user perspective.
. Accounts for complexity and functionality rather than just code volume.

8.b) Function Point Calculation

Given:
● Low EI: 10
● High EO: 12
● Low ILF: 20
● High EIF: 15
● Average EQ: 12
● VAF = 1.1
Unadjusted Function Point (UFP):
UFP=(10×3)+(12×7)+(20×7)+(15×10)+(12×5)=30+84+140+150+60=464
UFP=(10×3)+(12×7)+(20×7)+(15×10)+(12×5)=30+84+140+150+60=464
Adjusted Function Point:
Adjusted FP= UFP× VAF = 464×1.1= 510.4
AdjustedFP=UFP×VAF=464×1.1=510.4

9.a) Coupling and Cohesion

Answer:
● Cohesion: The degree to which elements within a module are related.
○ Types: Logical, Temporal, Procedural, Communicational, Sequential, Functional.
● Coupling: The degree of dependency between modules.
○ Types: Data, Stamp, Control, Common, Content.

9.b) Why "Low Coupling and High Cohesion" is a Feature of Good Design
Answer:
● Low Coupling:
○ Reduces dependency between modules.
○ Easier to modify or test independently.
● High Cohesion:
○ Enhances clarity and functionality within modules.
○ Promotes reusability and maintainability.

9.c) Function Point Calculation

Given:
● No. of EI = 30
● No. of EO = 62
● No. of EQ = 24
● No. of ILF = 8
● No. of EIF = 2
Assuming all complexity is average:
UFP=(30×4)+(62×5)+(24×4)+(8×10)+(2×7)=120+310+96+80+14=620
Adjusted FP is calculated as per provided VAF.

10. Types of Testing

Regression Testing:
● Retesting after modifications to ensure no new defects were introduced.
Alpha Testing:
● Done by developers or testers before releasing to customers.
Beta Testing:
● Done by a limited set of real users in a production environment.

11.a) Why Software Doesn’t Wear Out

● Software doesn’t degrade physically over time like hardware.
● Failures occur due to design issues or external factors, not wear.
11.b) IEEE Definition of Software Engineering
"Software Engineering is the application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software."

11.c) Characteristics of Software vs. Hardware

Feature Software Hardware
Wear and Tear Doesn’t wear out Wears out physically
physically
Upgrade Can be updated or Requires hardware
patched replacement
Cost of Production High for initial High for manufacturing
development
Reproducibility Easily replicated Requires manufacturing
effort
Q1: Physical and Logical DFD
(a) Definition
. Logical DFD:
○ Represents the flow of data in a system focusing on what the system does.
○ Abstract and implementation-independent.
○ Example: Shows how data moves between entities like "Order Data," "Customer
Details."
. Physical DFD:
○ Describes how the system is implemented.
○ Includes hardware, software, and manual processes.
○ Example: Illustrates physical systems like servers, printers, or databases.
Advantages of Physical DFD Over Logical DFD:
● Provides implementation-level details.
● Helps in identifying specific hardware or software requirements.
● Facilitates system deployment and maintenance.
(b) Differences (with Diagrams)
Aspect Logical DFD Physical DFD
Focus What the system does How the system
operates
Abstraction Level High Low (Implementation
details included)
Entities Conceptual entities (e.g., Physical entities (e.g.,
customer) database, API)
Example Diagrams:
 ● Logical DFD: Shows processes like "Process Order" and "Update Inventory."
● Physical DFD: Adds implementation details like "SQL Database" or "Web Application."

Q2: Data Dictionary for a DFD

A data dictionary contains details about data elements, data flows, processes, and data stores.
Example for Bonus Generation System:
. Data Elements:
○ EmployeeID: Unique ID of an employee.
○ BonusAmount: Amount of bonus generated.
. Data Flows:
○ GenerateBonus: Flow of data from process to bonus database.
. Data Stores:
○ EmployeeDB: Stores employee details.
○ BonusDB: Stores bonus calculations.
. Processes:
○ CalculateBonus: Calculates bonus based on performance.

Q3: Coding Standards and Testing

(a) Coding Standards and Guidelines:
● Definition: Rules for writing code to maintain consistency, readability, and maintainability.
● Examples:
. Naming Conventions: Variables, functions, and classes must follow naming
conventions (e.g., camelCase).
. Commenting: Use inline and block comments.
. Indentation: Maintain uniform indentation (e.g., 4 spaces per level).
. Error Handling: Proper use of try-catch blocks.
. Modularity: Divide code into smaller, reusable modules.
(b) Testing Process (Block Diagram):
. Steps in Testing:
○ Requirement Analysis: Understand testable requirements.
○ Test Plan Design: Create a plan for testing activities.
○ Test Case Design: Define test cases.
○ Execution: Run the tests.
○ Defect Logging: Identify and report bugs.
○ Retesting: Verify fixes.

Q4: PERT and Gantt Chart

(a) Definition:
. PERT Chart:
○ Program Evaluation and Review Technique.
○ Represents project tasks and dependencies using a network diagram.
○ Focuses on time estimates and critical paths.
. Gantt Chart:
○ A bar chart representing task schedules.
○ Shows task start and end times along a timeline.
(b) Critical Path Analysis:
● Steps:
. Draw the Activity Diagram.
. Calculate Earliest Start (ES), Latest Start (LS), and Slack for tasks.
. Identify the path with zero slack (Critical Path).

Q5: Use-Case Diagram

System: Mobile Service Providing System
Actors:
. Customer
. Banking System
Use Cases:
. Register
. Login
. Pay Bill (via Credit Card/Net Banking)
. Generate Receipt
Diagram:
● The customer interacts with the system to register, login, and pay bills.
● An external banking system facilitates payments.

Q6: UML Sequence Diagram Messages

(a) Types of Messages:
. Synchronous Message:
○ Requires a response from the receiver.
○ Example: login(username, password).
. Asynchronous Message:
○ Does not require a response.
○ Example: sendNotification().
. Reply Message:
○ Response to a synchronous message.
○ Example: return isValid.
Example:
A sequence diagram for "Customer Login":
. Customer → System: Enter credentials.
. System → Database: Validate credentials.
. Database → System: Return result.
. System → Customer: Display login status.

Q7: Coupling and Cohesion

(a) Problems with High Coupling and Low Cohesion:
. High Coupling:
○ Increases interdependency between modules.
○ Difficult to modify or debug.
. Low Cohesion:
 ○ Modules handle unrelated functionalities.
○ Reduces reusability and clarity.
(b) Structure Chart Definition:
● A hierarchical representation of a system’s design.
● Breaks down the system into modules and shows relationships.

Q8: Structure Chart for Bonus Generation System

Processes:
. Input Employee Data
. Calculate Bonus
. Generate Report
Structure Chart:
● The top-level module is "Bonus Generation System."
● Submodules handle specific tasks like "Input Data" or "Generate Report."