2 marks

• **What is white box testing?**

• **Define software engineering.** White box testing is a testing method where the tester has full knowledge of the software’s
Software engineering is the systematic application of engineering principles, methods, and tools internal code and structure, allowing them to test the logic, code paths, and implementation
to design, develop, test, and maintain software systems, ensuring they are reliable, efficient, and details.
meet user requirements.
• **What is the purpose of a feasibility study?**
• **What is the difference between software and hardware?** The purpose of a feasibility study is to evaluate the viability of a proposed software project by
Software is a set of instructions or programs that tell a computer what to do, intangible and stored assessing its technical, economic, operational, and legal aspects to determine if it is practical and
digitally (e.g., operating systems, applications). Hardware refers to the physical components of a beneficial to proceed.
computer system, such as the processor, memory, and peripherals, which are tangible and
execute software instructions. • **List any two qualities of good software.**
Two qualities of good software are reliability (performs consistently without failures) and usability
• **What is alpha testing?** (easy and intuitive for users to operate).
Alpha testing is an early-stage testing process conducted by internal developers or a limited
group of users in a controlled environment to identify bugs and issues in a software product • **What is the difference between verification and validation?**
before it is released to a broader audience. Verification ensures the software is built correctly by checking if it meets specified requirements
and design (e.g., through reviews). Validation ensures the right software is built by confirming it
• **What is the purpose of a Software Requirement Specification (SRS)?** meets user needs and expectations (e.g., through testing).
The purpose of an SRS is to provide a detailed, structured document that outlines the functional
and non-functional requirements of a software system, serving as a blueprint for development, • **What is version control?**
communication, and validation among stakeholders. Version control is a system that tracks and manages changes to software code, allowing multiple
developers to collaborate, maintain history, and revert to previous versions if needed (e.g., using
• **What are functional requirements?** tools like Git).
Functional requirements specify what a software system should do, detailing specific behaviors,
features, or functions, such as user interactions, data processing, or system outputs, typically • **What is agile methodology?**
described in the SRS. Agile methodology is an iterative, flexible approach to software development that emphasizes
collaboration, customer feedback, and incremental delivery of working software in short cycles
• **Name two software process models.** called sprints.
Two software process models are the Waterfall Model and the Agile Model.
• **Define use case diagram.**
• **What is the waterfall model?** A use case diagram is a visual representation in UML (Unified Modeling Language) that illustrates
The waterfall model is a linear, sequential software development process where each phase (e.g., the interactions between users (actors) and a system, showing the system’s functionality through
requirements, design, implementation, testing, maintenance) is completed before moving to the specific use cases or tasks.
next, with no overlap or iteration.
• **What is modularity in software design?**
• **What is prototyping in software engineering?** Modularity in software design is the practice of dividing a software system into smaller,
Prototyping is the process of creating a preliminary version of a software system to visualize and independent, and reusable components (modules) that perform specific functions, improving
test its features, gather user feedback, and refine requirements before developing the final maintainability and scalability.
product.
• **What is a data flow diagram (DFD)?**
• **What is software maintenance?** A data flow diagram (DFD) is a graphical representation of how data flows through a system,
Software maintenance involves updating, modifying, and enhancing a software system after showing processes, data stores, external entities, and data flows to illustrate the system’s
deployment to fix bugs, improve performance, adapt to new requirements, or ensure compatibility functionality and data processing.
with changing environments.

• **What is a software lifecycle?** 5 marks

A software lifecycle is the sequence of phases a software system undergoes, from initial
conception through development, testing, deployment, maintenance, and eventual retirement or
replacement. 1. **What are White-box Testing and Black-box Testing?**
White-box testing involves testing a software system with full knowledge of its internal code,
• **Define coupling and cohesion.** structure, and logic. Testers design test cases based on the code’s paths, branches, and
Coupling refers to the degree of interdependence between software modules; low coupling is conditions to ensure all code segments are executed correctly (e.g., testing a loop’s iterations).
preferred for modularity. Cohesion measures how well the elements within a module work Black-box testing focuses on testing the software’s functionality without any knowledge of its
together to achieve a single, well-defined purpose; high cohesion is desirable. internal workings, relying solely on inputs and expected outputs as per requirements (e.g., testing
a login feature by entering credentials). White-box testing is typically performed by developers,
• **What is black box testing?** while black-box testing is done by testers or end-users. White-box ensures code correctness,
Black box testing is a testing method where the tester evaluates the software’s functionality whereas black-box verifies user requirements. Both are essential for comprehensive software
without any knowledge of its internal code or structure, focusing on inputs and expected outputs. validation.

2. **What are the limitations of Classical Waterfall Model?** accommodates changing requirements. Waterfall delivers a final product at the end, while Agile
The Classical Waterfall Model, a linear and sequential approach, has several limitations: delivers incremental working software. Waterfall suits projects with stable requirements (e.g.,
- **Inflexibility**: Requirements are fixed early, making it difficult to accommodate changes or new government systems), but its rigidity limits adaptability. Agile promotes collaboration and
user needs later. customer feedback but may lack predictability for large projects. Waterfall is plan-driven; Agile is
- **Late Testing**: Testing occurs only after implementation, delaying defect detection and adaptive, prioritizing speed and responsiveness.
increasing costs to fix issues.
- **Assumes Perfect Requirements**: It assumes all requirements are fully understood upfront, 8. **Describe the characteristics of good software.**
which is unrealistic for complex projects. Good software exhibits the following characteristics:
- **No Working Software Until End**: No functional software is produced until the final phase, - **Reliability**: Performs consistently without crashes or errors (e.g., stable banking software).
risking misalignment with user expectations. - **Usability**: Easy to use with an intuitive interface (e.g., user-friendly mobile apps).
- **Poor Risk Management**: Lack of iteration means risks identified late are harder to mitigate, - **Efficiency**: Optimizes resource usage (e.g., minimal memory consumption).
potentially leading to project failure. - **Maintainability**: Easy to update or fix (e.g., modular code structure).
- **Scalability**: Handles increased loads effectively (e.g., cloud-based systems).
3. **Write a short note on Feasibility Study.** These qualities ensure the software meets user needs, performs reliably, and adapts to future
A feasibility study is a preliminary analysis conducted to assess the viability of a proposed requirements, enhancing user satisfaction and longevity.
software project. Its purpose is to determine whether the project is technically, economically,
operationally, and legally feasible. It evaluates technical feasibility (availability of tools and 9. **What is Software Requirement Specification (SRS)? What are its components?**
expertise), economic feasibility (cost-benefit analysis), operational feasibility (user acceptance and A Software Requirement Specification (SRS) is a detailed document that outlines the functional
organizational fit), and legal feasibility (compliance with laws and regulations). Conducted early in and non-functional requirements of a software system, serving as a blueprint for development and
the project lifecycle, it helps stakeholders decide whether to proceed, adjust scope, or abandon a contract between stakeholders. Its key components include:
the project. A well-executed feasibility study reduces risks, saves resources, and ensures - **Introduction**: Purpose, scope, and objectives of the system.
alignment with organizational goals. - **Overall Description**: System overview, constraints, and assumptions.
- **Functional Requirements**: Specific features and functionalities (e.g., user login process).
4. **Write a short note on Risk Management.** - **Non-Functional Requirements**: Performance, security, and usability criteria.
Risk management in software engineering involves identifying, analyzing, prioritizing, and - **Design Constraints**: Hardware, software, or regulatory limitations.
mitigating risks that could impact project success. Risks may include technical issues (e.g., The SRS ensures clarity, reduces miscommunication, and guides development and testing.
software bugs), schedule delays, or budget overruns. The process includes risk identification
(listing potential risks), risk analysis (assessing likelihood and impact), risk prioritization (ranking 10. **Explain the different types of software maintenance with examples.**
risks by severity), and risk mitigation (implementing strategies like contingency plans or Software maintenance involves modifying software post-deployment to ensure its functionality
prototyping). Effective risk management ensures timely delivery, cost control, and quality and relevance. Types include:
software. Techniques like regular risk reviews and maintaining a risk register help proactively - **Corrective Maintenance**: Fixing bugs or errors (e.g., patching a crash in an app).
address uncertainties throughout the project lifecycle. - **Adaptive Maintenance**: Updating software to work in new environments (e.g., modifying an
app for a new OS version).
5. **Briefly discuss Project Communication Management.** - **Perfective Maintenance**: Enhancing features based on user feedback (e.g., adding a dark
Project Communication Management involves planning, executing, and monitoring the flow of mode to an application).
information among project stakeholders to ensure clarity and alignment. It includes creating a - **Preventive Maintenance**: Proactively improving software to prevent future issues (e.g.,
communication plan (defining what, when, and how information is shared), distributing information refactoring code to improve performance).
effectively (e.g., via meetings, reports, or emails), and managing stakeholder expectations. Each type ensures the software remains functional, efficient, and aligned with user needs over
Effective communication ensures team collaboration, timely issue resolution, and stakeholder time.
satisfaction. Tools like project management software (e.g., Jira) and regular status updates
facilitate this process. Poor communication can lead to misunderstandings, delays, or project 11. **What is risk management in software engineering? Describe any risk mitigation techniques.**
failure, making it a critical aspect of software project management. Risk management in software engineering is the process of identifying, analyzing, and mitigating
risks that could affect project success, such as delays or technical failures. It involves risk
6. **Discuss the responsibilities of a Software Project Manager.** identification, assessment, prioritization, and mitigation. Two mitigation techniques are:
A Software Project Manager oversees the planning, execution, and delivery of software projects. - **Prototyping**: Building a prototype to test uncertain features, reducing the risk of misaligned
Key responsibilities include: requirements (e.g., prototyping a user interface).
- **Project Planning**: Defining scope, objectives, timelines, and resource allocation. - **Contingency Planning**: Preparing backup plans for critical risks, such as allocating extra
- **Team Management**: Assigning tasks, motivating the team, and resolving conflicts. resources for potential schedule overruns.
- **Risk Management**: Identifying and mitigating risks to ensure project success. These techniques minimize disruptions, ensuring timely delivery and quality software.
- **Stakeholder Communication**: Coordinating with clients, developers, and testers to align
expectations and report progress. 12. **Discuss the importance of software testing. Explain black box and white box testing.**
- **Budget and Schedule Control**: Monitoring costs and ensuring timely delivery within Software testing is critical to ensure software quality, reliability, and user satisfaction by identifying
constraints. defects before deployment. It verifies that the software meets requirements, performs as
The manager ensures the project meets quality standards, adheres to requirements, and is expected, and is free of critical bugs, reducing risks and costs. Black-box testing focuses on
delivered on time, acting as a bridge between technical teams and stakeholders. testing functionality without knowledge of internal code, using inputs and expected outputs (e.g.,
testing a calculator app’s addition feature). White-box testing examines the internal code
7. **Compare and contrast the Waterfall model and Agile model.** structure, testing logic and code paths (e.g., ensuring all branches in a conditional statement are
The Waterfall Model is a linear, sequential approach with distinct phases (requirements, design, tested). Both approaches complement each other to achieve comprehensive testing.
implementation, testing, maintenance), while Agile is an iterative, flexible methodology with short
cycles (sprints). Waterfall requires complete, fixed requirements upfront, whereas Agile 13. **Draw and explain a Data Flow Diagram (DFD) for a Library Management System.**
Since I cannot physically draw, I’ll describe a Level-1 DFD for a Library Management System - **Specification**: Documenting requirements in an SRS, detailing functional and non-functional
(LMS). The DFD includes: needs.
- **External Entities**: Librarian, Member. - **Validation**: Reviewing requirements with stakeholders to ensure accuracy.
- **Processes**: Issue Book, Return Book, Search Book, Manage Inventory. - **Prioritization**: Ranking requirements based on importance.
- **Data Stores**: Book Database, Member Database, Transaction Records. Techniques like use case modeling and prototyping aid this process, ensuring the system aligns
- **Data Flows**: Book requests, issue/return details, search queries, and results. with user expectations.
**Explanation**: A Member sends a book request to the “Search Book” process, which queries the
Book Database and returns results. For issuing, the Librarian inputs member and book details into 19. **Write short notes on: (any two) Spiral model, Software metrics, Use case diagram.**
the “Issue Book” process, updating Transaction Records and Book Database. The “Return Book” - **Spiral Model**: The Spiral Model is a risk-driven software development process combining
process updates records similarly. The “Manage Inventory” process handles book additions/ iterative development with elements of the Waterfall Model. It involves repeated cycles (spirals) of
removals. The DFD visually represents data movement, clarifying system functionality. planning, risk analysis, prototyping, and evaluation. Each spiral refines the system, addressing
risks early (e.g., prototyping to validate a complex algorithm). It suits large, high-risk projects but
14. **Explain the concept of software quality assurance. How is it achieved?** is costly and complex to manage.
Software Quality Assurance (SQA) is a systematic process to ensure software meets specified - **Use Case Diagram**: A use case diagram is a UML diagram that visually represents a system’s
quality standards, including reliability, usability, and performance. It involves defining processes, functionality by showing interactions between users (actors) and the system via use cases. For
standards, and metrics to prevent defects and ensure compliance with requirements. SQA is example, in an online shopping system, actors (Customer, Admin) interact with use cases like
achieved through: “Place Order” or “Manage Inventory.” It clarifies system scope and requirements for stakeholders.
- **Process Definition**: Establishing standards (e.g., ISO 9001).
- **Reviews and Audits**: Conducting code and design reviews. 20. **What is software design? Explain any one design principle in detail.**
- **Testing**: Performing unit, integration, and system tests. Software design is the process of defining the architecture, components, interfaces, and other
- **Metrics Monitoring**: Tracking defect rates and performance. characteristics of a software system to meet specified requirements. It bridges requirements and
- **Training**: Ensuring team adherence to quality practices. implementation. A key design principle is **Modularity**, which involves dividing a system into
SQA ensures consistent quality, reduces risks, and enhances user satisfaction. smaller, independent, and reusable modules, each performing a specific function. For example, in
a banking system,08:52 PM IST 6-Feb-25, a “Login Module” handles user authentication, while a
15. **Differentiate between functional and non-functional requirements with examples.** “Transaction Module” processes payments. Modularity improves maintainability, reusability, and
Functional requirements define what a software system should do, specifying features and scalability by reducing dependencies and simplifying updates, ensuring robust and flexible
behaviors. Example: “The system shall allow users to log in with email and password.” Non- software systems.
functional requirements describe how the system performs, focusing on quality attributes like
performance, security, or usability. Example: “The system shall load the login page in under 2 ---
seconds.” Functional requirements address specific user actions, while non-functional
requirements ensure system quality and performance, both critical for a complete SRS. 10 marks

16. **What is coupling and cohesion? Explain their types with examples.**
Coupling measures the interdependence between software modules; low coupling is preferred. 1. **Discuss Software Development Life Cycle in your own words.**
Types include: The Software Development Life Cycle (SDLC) is a structured framework that guides the
- **Data Coupling**: Modules share only necessary data (e.g., a function passing a single development of software from conception to retirement. It consists of phases to ensure
parameter). systematic, efficient, and high-quality software production. In my view, SDLC is like a roadmap
- **Content Coupling**: One module modifies another’s internal data (e.g., direct memory access, that organizes tasks into clear steps:
undesirable). - **Planning**: Define project goals, scope, and resources (e.g., budgeting for an e-commerce
Cohesion measures how well a module’s elements work together for a single purpose; high app).
cohesion is ideal. Types include: - **Requirement Analysis**: Gather and document user needs (e.g., features for online shopping).
- **Functional Cohesion**: All elements contribute to one task (e.g., a module calculating tax). - **Design**: Create system architecture and interfaces (e.g., database schema for user accounts).
- **Sequential Cohesion**: Elements execute in sequence (e.g., a module processing input then - **Implementation**: Write and integrate code (e.g., coding the app’s frontend and backend).
outputting results). - **Testing**: Verify functionality and fix bugs (e.g., testing payment processing).
Low coupling and high cohesion improve maintainability and scalability. - **Deployment**: Release the software to users (e.g., launching the app on app stores).
- **Maintenance**: Update and improve the software post-deployment (e.g., patching security
17. **Describe the Agile methodology. What are its advantages and limitations?** issues).
Agile methodology is an iterative, flexible approach to software development emphasizing SDLC ensures alignment with user needs, manages resources, and minimizes risks, with models
collaboration, customer feedback, and incremental delivery in short cycles (sprints). It uses like Waterfall, Agile, or Spiral tailoring the process to project needs.
frameworks like Scrum or Kanban. **Advantages**: Adapts to changing requirements, delivers
working software frequently, enhances customer satisfaction through feedback, and promotes 2. **What are the characteristics of a good Software Requirements Specification? Discuss the role
team collaboration. **Limitations**: Requires constant customer involvement, may lack of a Software Analyst.**
predictability for large projects, can lead to scope creep, and demands skilled teams. Agile suits A good Software Requirements Specification (SRS) is a detailed document that clearly defines
dynamic projects but may struggle with rigid, large-scale systems. system requirements, serving as a foundation for development. Its characteristics include:
- **Clarity**: Unambiguous language to avoid misinterpretation (e.g., “Users shall log in with email
18. **Explain the process of requirement gathering and analysis.** and password”).
Requirement gathering and analysis involve eliciting, documenting, and refining user needs for a - **Completeness**: Covers all functional and non-functional requirements (e.g., performance
software system. The process includes: metrics).
- **Elicitation**: Collecting requirements via interviews, surveys, or workshops with stakeholders. - **Consistency**: Free of contradictions (e.g., no conflicting user access rules).
- **Analysis**: Evaluating requirements for clarity, feasibility, and consistency, resolving conflicts. - **Verifiability**: Requirements are testable (e.g., “Page loads in under 2 seconds”).

- **Traceability**: Links requirements to design and testing phases. rectangles (entities), ovals (attributes), and lines (relationships). For example, in an e-commerce
- **Feasibility**: Requirements are realistic within constraints. system, an ERD shows a “Customer” entity linked to an “Order” entity via a “Places” relationship.
ERDs guide database design, ensuring data integrity and efficient storage.
**Role of a Software Analyst**: A software analyst bridges stakeholders and developers by
eliciting, analyzing, and documenting requirements. They conduct interviews, workshops, or 6. **What are the characteristics of a good Software Requirements Specification? Discuss the role
surveys to gather user needs, analyze feasibility, and resolve ambiguities. They create and of a Software Analyst.**
maintain the SRS, ensure stakeholder agreement, and validate requirements against project goals. (Repeated question, same response as Q2 for consistency.)
For example, in a banking system, the analyst ensures the SRS includes secure transaction A good Software Requirements Specification (SRS) is a detailed document that clearly defines
features and performance standards, facilitating clear communication and successful system requirements, serving as a foundation for development. Its characteristics include:
development. - **Clarity**: Unambiguous language to avoid misinterpretation (e.g., “Users shall log in with email
and password”).
3. **Discuss the different types of Cohesion and Coupling.** - **Completeness**: Covers all functional and non-functional requirements (e.g., performance
**Cohesion** measures how well a module’s elements work together for a single purpose. High metrics).
cohesion is desirable. Types include: - **Consistency**: Free of contradictions (e.g., no conflicting user access rules).
- **Functional Cohesion**: All elements perform one task (e.g., a module calculating payroll tax). - **Verifiability**: Requirements are testable (e.g., “Page loads in under 2 seconds”).
- **Sequential Cohesion**: Elements execute in sequence, with one’s output as another’s input - **Traceability**: Links requirements to design and testing phases.
(e.g., a module reading and processing data). - **Feasibility**: Requirements are realistic within constraints.
- **Communicational Cohesion**: Elements operate on the same data (e.g., a module updating
customer records). **Role of a Software Analyst**: A software analyst bridges stakeholders and developers by
- **Temporal Cohesion**: Elements are executed together but unrelated (e.g., startup initialization eliciting, analyzing, and documenting requirements. They conduct interviews, workshops, or
tasks, less desirable). surveys to gather user needs, analyze feasibility, and resolve ambiguities. They create and
- **Logical Cohesion**: Elements perform similar but unrelated tasks (e.g., a module handling all maintain the SRS, ensure stakeholder agreement, and validate requirements against project goals.
input types, weak cohesion). For example, in a banking system, the analyst ensures the SRS includes secure transaction
features and performance standards, facilitating clear communication and successful
**Coupling** measures interdependence between modules. Low coupling is preferred. Types development.
include:
- **Data Coupling**: Modules share minimal data (e.g., passing a single parameter). 7. **a. Create a Decision Table for the following scenario: A business organization pays its Sales
- **Stamp Coupling**: Modules share a data structure (e.g., passing an entire record). Staff a bonus if they sell more than $1000 worth of goods in a month. The bonus is as follows: i.
- **Control Coupling**: One module controls another’s behavior (e.g., passing a flag to dictate 1% for selling more than $2000 worth of goods in a month. ii. 1% if the member of sales staff has
logic). been associated with the Company for more than 5 years. iii. 2% if the member of sales staff has
- **Common Coupling**: Modules share global data (e.g., accessing a shared database, risky). been associated with the Company for more than 5 years and has sold more than $2000 worth of
- **Content Coupling**: One module modifies another’s internal data (e.g., direct memory access, goods in a month.**
highly undesirable). **Decision Table**:
High cohesion and low coupling enhance modularity, maintainability, and scalability. | Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 | Rule 5 | Rule 6 | Rule 7 | Rule 8 |
|--------------------------------|--------|--------|--------|--------|--------|--------|--------|--------|
4. **What is Prototype Model? What are the advantages and disadvantages of Prototype Model?** | Sales > $1000? |N |Y |Y |Y |Y |Y |Y |Y |
The Prototype Model is a software development approach where a preliminary version (prototype) | Sales > $2000? |- |N |Y |N |Y |N |Y |Y |
of the system is built to visualize and refine requirements before final development. It involves | Years > 5? |- |N |N |Y |Y |N |N |Y |
creating mock-ups or partial implementations, gathering feedback, and iterating. | **Actions** | | | | | | | | |
**Advantages**: | Bonus 0% |X |X | | | | | | |
- **Improved Requirements**: Prototypes clarify user needs (e.g., a UI mock-up for an app). | Bonus 1% | | |X |X | | | | |
- **Early Feedback**: Users test prototypes, reducing miscommunication. | Bonus 2% | | | | |X | | |X |
- **Risk Reduction**: Identifies issues early, saving costs (e.g., testing a complex algorithm).
- **Flexibility**: Allows requirement changes based on feedback. **Explanation**: The table evaluates conditions (sales > $1000, sales > $2000, years > 5) to
**Disadvantages**: determine the bonus. Rule 1: No bonus if sales ≤ $1000. Rule 2: No bonus if sales ≤ $2000 and
- **Time-Consuming**: Multiple iterations can delay development. years ≤ 5. Rule 3: 1% bonus for sales > $2000, years ≤ 5. Rule 4: 1% bonus for sales > $1000 but
- **Costly**: Building and refining prototypes requires resources. ≤ $2000, years > 5. Rule 5 and 8: 2% bonus for sales > $2000 and years > 5. Rules 6-7 are
- **Scope Creep**: Users may demand excessive changes. redundant or covered.
- **Incomplete Prototypes**: May mislead stakeholders about final system readiness.
The model suits projects with unclear or evolving requirements, like user-centric applications. **b. Draw the control flow graph (CFG) of the following program and find out the cyclomatic
complexity of the graph:**
5. **Write short notes on DFD and ERD.** **Program**:
- **Data Flow Diagram (DFD)**: A DFD visually represents how data flows through a system, ```
showing processes, data stores, external entities, and data flows. It illustrates system functionality procedure greater;
at different levels (e.g., Level-0 for overview, Level-1 for detailed processes). For example, in a integer: x, y, z = 0;
Library Management System, a DFD shows a “Member” entity sending a book request to the 1 enter the value of x;
“Issue Book” process, updating the “Book Database.” DFDs clarify data movement, aiding design 2 enter the value of y;
and communication. 3 if x > y then
- **Entity-Relationship Diagram (ERD)**: An ERD models a system’s data structure, depicting 4 z = x;
entities (e.g., Customer, Order) and their relationships (e.g., Customer places Order). It uses else
5 z = y; Scrum ensures transparency, adaptability, and continuous improvement, ideal for dynamic
6 end greater projects.
```
10. **What is risk management in software projects? Explain the steps involved in risk
**Control Flow Graph (CFG) Description**: management with examples.**
- **Node 1**: Enter x (start). Risk management in software projects involves identifying, analyzing, and mitigating risks that
- **Node 2**: Enter y. could hinder project success (e.g., delays, bugs). Steps include:
- **Node 3**: Decision point (x > y?). - **Risk Identification**: List potential risks (e.g., unclear requirements for an app).
- **Node 4**: If true, z = x. - **Risk Analysis**: Assess likelihood and impact (e.g., high likelihood of scope creep).
- **Node 5**: If false, z = y. - **Risk Prioritization**: Rank risks by severity (e.g., prioritizing critical bugs).
- **Node 6**: End (program terminates). - **Risk Mitigation**: Implement strategies like:
**Edges**: 1→2, 2→3, 3→4 (true), 3→5 (false), 4→6, 5→6. - **Avoidance**: Clarify requirements early to avoid scope creep.
- **Reduction**: Use prototyping to test complex features.
**Cyclomatic Complexity**: - **Transfer**: Outsource specific tasks to experts.
Cyclomatic complexity (V(G)) is calculated as V(G) = E - N + 2, where E = edges, N = nodes. - **Acceptance**: Plan contingencies for minor delays.
- Nodes (N) = 6 (1, 2, 3, 4, 5, 6). - **Risk Monitoring**: Track risks using tools like risk registers (e.g., updating risks weekly).
- Edges (E) = 6 (1→2, 2→3, 3→4, 3→5, 4→6, 5→6). Effective risk management ensures timely delivery and quality, minimizing disruptions.
- V(G) = 6 - 6 + 2 = 2.
Alternatively, V(G) = P + 1, where P = predicates (decision points). Here, P = 1 (if x > y), so V(G) = 1 11. **Differentiate between black-box and white-box testing. Describe techniques used in each.**
+ 1 = 2. The complexity is 2, indicating two independent paths. **Black-Box Testing**: Tests functionality without knowledge of internal code, focusing on inputs
and outputs.
8. **What is software design? Explain in detail the principles of software design.** - **Techniques**:
Software design is the process of defining a software system’s architecture, components, - **Equivalence Partitioning**: Divide inputs into equivalent classes (e.g., testing valid/invalid
interfaces, and modules to meet specified requirements. It translates requirements into a blueprint emails for login).
for implementation. Key principles include: - **Boundary Value Analysis**: Test edge cases (e.g., testing a field accepting 1-100 at 1, 100).
- **Modularity**: Divide the system into independent modules (e.g., a payment module in an e- - **Decision Table Testing**: Test combinations of conditions (e.g., bonus calculation rules).
commerce system), improving maintainability. **White-Box Testing**: Tests internal code structure with full knowledge of logic.
- **Abstraction**: Focus on essential details, hiding complexity (e.g., using APIs to abstract - **Techniques**:
database operations). - **Statement Coverage**: Ensure all code statements are executed (e.g., testing all lines in a
- **Encapsulation**: Bundle data and methods, restricting access (e.g., private variables in a function).
class). - **Branch Coverage**: Test all decision outcomes (e.g., true/false paths in an if-else).
- **Coupling**: Minimize module interdependence (e.g., passing minimal data between modules). - **Path Coverage**: Test all possible code paths (e.g., all loop iterations).
- **Cohesion**: Ensure each module has a single, well-defined purpose (e.g., a module solely for Black-box ensures user requirements; white-box ensures code correctness. Both are
user authentication). complementary.
- **Scalability**: Design for growth (e.g., cloud-based architecture for increased users).
These principles ensure the system is robust, maintainable, and adaptable, reducing complexity 12. **Write short notes on (any two): Software configuration management, Software metrics,
and enhancing quality. CASE tools.**
- **Software Configuration Management (SCM)**: SCM manages changes to software artifacts
9. **Discuss the Agile Software Development approach. Explain Scrum methodology with roles, (code, documents) to ensure consistency and traceability. It includes version control (e.g., Git for
events, and artifacts.** code tracking), change management (e.g., approving code updates), and release management
Agile is an iterative, flexible software development approach emphasizing collaboration, customer (e.g., deploying a new app version). SCM ensures team collaboration, prevents conflicts, and
feedback, and incremental delivery in short cycles (sprints). It adapts to changing requirements maintains software integrity.
and prioritizes working software. - **Software Metrics**: Metrics quantify software attributes to measure quality, progress, or
**Scrum Methodology**: A popular Agile framework with: performance. Examples include lines of code (size), defect density (quality), and function points
- **Roles**: (functionality). Metrics guide decision-making, track project health (e.g., bug rates), and improve
- **Product Owner**: Defines product vision, prioritizes the backlog (e.g., prioritizing new processes, but misinterpretation can lead to poor decisions.
features).
- **Scrum Master**: Facilitates the process, removes obstacles (e.g., resolving team conflicts). 13. **What is software maintenance? Explain types of software maintenance and challenges
- **Development Team**: Builds the software (e.g., coders, testers). involved.**
- **Events**: Software maintenance involves modifying software post-deployment to ensure functionality,
- **Sprint**: A 2-4 week cycle to deliver a working increment. performance, and relevance. **Types**:
- **Sprint Planning**: Team plans sprint goals and tasks. - **Corrective**: Fixing bugs (e.g., patching a crash in an app).
- **Daily Scrum**: 15-minute stand-up to discuss progress. - **Adaptive**: Updating for new environments (e.g., supporting a new OS).
- **Sprint Review**: Stakeholders review the increment. - **Perfective**: Enhancing features (e.g., adding a search function).
- **Sprint Retrospective**: Team reflects on improvements. - **Preventive**: Proactively improving to avoid issues (e.g., refactoring code).
- **Artifacts**: **Challenges**:
- **Product Backlog**: Prioritized list of features. - **High Costs**: Maintenance can consume significant resources.
- **Sprint Backlog**: Tasks for the current sprint. - **Legacy Systems**: Outdated code is hard to modify.
- **Increment**: Working software delivered each sprint. - **Documentation Gaps**: Poor documentation complicates updates.
- **Regression Risks**: Changes may introduce new bugs.

Maintenance ensures long-term usability but requires careful planning and testing. Software Quality Assurance (SQA) is a systematic process to ensure software meets quality
standards (reliability, usability) throughout development. It focuses on processes, not just
14. **Discuss the importance of software project management. What are the responsibilities of a products. **SQA Activities**:
software project manager?** - **Process Definition**: Establish standards (e.g., ISO 9001 for coding practices).
Software project management is critical to deliver software on time, within budget, and meeting - **Audits and Reviews**: Conduct code and design reviews to catch errors early.
quality standards. It coordinates resources, schedules, and stakeholders, minimizing risks and - **Testing**: Perform unit, integration, and system tests to verify functionality.
ensuring success. Its importance lies in aligning technical efforts with business goals, optimizing - **Metrics Collection**: Track defect rates, performance metrics to monitor quality.
resources, and handling uncertainties (e.g., scope changes). - **Training**: Educate teams on quality standards and tools.
**Responsibilities of a Software Project Manager**: - **Documentation Control**: Ensure accurate, updated documentation (e.g., SRS).
- **Planning**: Define scope, schedule, and budget (e.g., for a CRM system). SQA ensures consistent quality, reduces defects, and enhances user satisfaction by embedding
- **Resource Management**: Allocate team roles and tools. quality in every phase.
- **Risk Management**: Identify and mitigate risks (e.g., delays).
- **Communication**: Liaise with stakeholders for updates and feedback. 18. **What is object-oriented design? Explain its principles and advantages with suitable
- **Monitoring**: Track progress using metrics (e.g., sprint velocity). examples.**
- **Quality Assurance**: Ensure deliverables meet standards. Object-Oriented Design (OOD) is a design approach that models a system as interacting objects,
The manager drives project success by balancing constraints and fostering collaboration. each encapsulating data and behavior. It uses classes and objects (e.g., a “Customer” class with
attributes like name and methods like placeOrder).
15. **Explain the concept of verification and validation. Why are they important in software **Principles**:
development?** - **Encapsulation**: Bundle data and methods, restricting access (e.g., private fields in a
**Verification** ensures the software is built correctly by checking if it adheres to specifications BankAccount class).
and design (e.g., code reviews to confirm coding standards). **Validation** ensures the right - **Inheritance**: Reuse code via parent-child classes (e.g., a “SavingsAccount” inherits from
software is built by confirming it meets user needs (e.g., user acceptance testing for a shopping “Account”).
app). - **Polymorphism**: Allow objects to take multiple forms (e.g., a “Shape” class with different draw
**Importance**: methods for Circle, Square).
- **Quality Assurance**: Verification catches design flaws; validation ensures user satisfaction. - **Abstraction**: Hide complexity, exposing only essentials (e.g., a database API hiding SQL
- **Cost Reduction**: Early defect detection reduces rework costs. queries).
- **Reliability**: Ensures software performs as expected (e.g., secure banking transactions). **Advantages**:
- **Stakeholder Confidence**: Validates alignment with requirements. - **Reusability**: Inheritance promotes code reuse (e.g., reusing a base class).
Both processes are critical to deliver functional, reliable software, reducing risks and ensuring - **Maintainability**: Encapsulation simplifies updates (e.g., modifying a single class).
success. - **Scalability**: Polymorphism supports extensibility (e.g., adding new shapes).
OOD enhances modularity and flexibility, ideal for complex systems like e-commerce platforms.
16. **Design a Library Management System using DFD (Level 0 and Level 1). Explain each
process clearly.** ---
**Level-0 DFD (Context Diagram)**:
- **Entities**: Member, Librarian. These responses are tailored to provide depth for 10-mark questions, balancing theory, examples,
- **Process**: Library Management System (LMS). and clarity. For diagrams (DFD, CFG), textual descriptions ensure reproducibility. Let me know if
- **Data Flows**: you need further elaboration or specific clarifications!
- Member → LMS: Book request, return request.
- LMS → Member: Book availability, issue confirmation.
- Librarian → LMS: Manage books, update records.
- LMS → Librarian: Reports, status.
**Explanation**: The LMS interacts with Members (requesting/returning books) and Librarians
(managing inventory), providing a high-level system overview.

**Level-1 DFD**:
- **Processes**:
- **Search Book**: Members query book availability; system checks Book Database.
- **Issue Book**: Librarian processes member requests, updates Transaction Records.
- **Return Book**: Processes returns, updates Book Database and Transaction Records.
- **Manage Inventory**: Librarian adds/removes books in Book Database.
- **Data Stores**: Book Database, Member Database, Transaction Records.
- **Data Flows**: Book details, member details, transaction updates.
**Explanation**: The Search Book process retrieves book data for members. Issue Book verifies
member eligibility and updates records. Return Book processes returns and updates availability.
Manage Inventory handles book additions/removals, ensuring accurate records. The DFD clarifies
data flow and system functionality.

17. **What is software quality assurance (SQA)? Explain the SQA activities in detail.**