Q1 and Q2.

Differentiate between State Chart Diagram, Activity Diagram and Sequence

Diagram in UML.

Aspect State Chart Diagram Activity Diagram Sequence Diagram

Shows different states of an Shows the flow of activities Shows interaction between
Purpose
object in a process objects
Messages and
Focus States and state changes Activities and workflow
communication
Represents Life cycle of an object Step-by-step process Order of message exchange
Main Activities, decisions, flow
States, events, transitions Objects, lifelines, messages
Elements arrows
Completion of one activity Sending and receiving
Trigger Event causes a state change
starts the next messages
Time Order Less important Less important Very important
Limited support for parallel Strong support for parallel Can show simultaneous
Concurrency
states activities interactions
Decision Based on events and Uses decision nodes Based on messages and
Making conditions (diamonds) responses
View of Shows behaviour of a single Shows the overall Shows interaction among
System object workflow multiple objects
Business process and Interaction among system
Used For Object behaviour
workflow components
Order: Placed → Paid → Login process between
Example Online Shopping Process
Delivered User, System and Database

Q3. Explain Activity Diagram in UML. Draw and explain an activity diagram for an Online
Shopping System.

An Activity Diagram is a UML diagram that shows the flow of activities (steps) in a system from start
to finish. It helps us understand how a process works and in what order the activities are performed.

Uses of Activity Diagram

• Shows the workflow of a system.
• Represents step-by-step execution of a process.
• Helps in understanding business processes and algorithms.
• Shows decisions and parallel activities.

Basic Symbols
Symbol Meaning
● Initial (Start) Node
◉ Final (End) Node
Rounded Rectangle Activity/Action
→ Flow/Transition
Diamond Decision/Merge Node
Thick Bar Fork/Join (Parallel Activities)
[Link]: The user starts the system.
[Link]: The user enters username and password.
3. Authentication: The system checks the login details.
4. Check: If the details are invalid
the user goes back to the login page. if the details are valid
the user enters the system.
5. User Activities: After successful login, the user can perform different tasks:
a) Search Product: Search for products
Add products to the cart
Either cancel the order or make payment
After payment
confirm the order.
b) Edit Profile: Change password
View or update account information.
c) View Reports: View payment reports
Delete reports if needed.
6. Complete Activity: After finishing any task, all paths join together.
7. Logout: The user logs out of the system.
8. End: The shopping session ends.
Q4. Explain Sequence Diagram in UML. Draw and explain a sequence diagram for a Login System.

A Sequence Diagram is a UML diagram that shows the interaction between objects and the sequence
of messages exchanged between them to perform a specific function or task.
It shows:
• Who sends a message.
• Who receives the message.
• The order in which messages are exchanged.
• How a particular task is completed in the system.
Symbol Meaning
User or external
Actor
entity
Rectangle Object/Participant
Vertical Line Lifeline
Arrow Message

1. Student clicks the Login button.

2. The Login module sends the User ID and Password for verification.
3. The Validate module checks the details with the Database.
4. The Database checks whether the User ID exists and the password is correct.
5. If the details are correct, the Database sends the result back.
6. The Validate module confirms that the login is successful.
7. The system sends a Login Successful message to the student.
8. The student's class list (grades) is displayed on the screen.
9. The student can now view the information.
Q5. Design a Class Diagram for an ATM System. Show all major classes, attributes, methods, and
relationships (association, aggregation, composition, inheritance). Explain your design.

ATM System Class Diagram

The ATM System Class Diagram consists of classes such as User, Account, ATM, Card-Reader, Screen,
Cash-Dispenser, Bank-System, Transaction, Withdrawal, and Deposit.
• User enters PIN and selects transactions.
• Account stores account number and balance details.
• ATM authenticates users and processes transactions.
• Card-Reader reads and ejects cards.
• Screen displays messages and takes input.
• Cash-Dispenser dispenses cash.
• Bank-System verifies and updates account information.
• Transaction represents banking operations.
• Withdrawal and Deposit are specialized types of Transaction.
Relationships
• Association: User uses Account and interacts with Bank-System.
• Aggregation: ATM contains Screen and Card-Reader.
• Composition: Cash-Dispenser is an essential part of ATM.
• Inheritance: Withdrawal and Deposit inherit from Transaction.
Working
The user inserts a card, enters a PIN, and selects a transaction. The ATM verifies the user through the
Bank-System, processes the transaction, updates the account, dispenses cash if required, and
displays the result on the screen.
Q6. Design a Class Diagram for a Library Management System. Clearly show classes, attributes,
methods, and relationships such as association, aggregation, composition, and inheritance. Explain
the diagram.

Library Management System Class Diagram

Major Classes
• Library: library-Name, address
• Library-Item: item-ID, title, publication-Date, status
• Book, Journal, DVD: Types of Library-Item
• Cata-log: Stores library items
• Account: username, password, email
• Library-Member: member-ID, membership-Date
• Librarian: employee-ID, position
• Book-Instance: barcode, location
• Loan: loan-ID, due-Date, fine-Amount
• Author: Author details
Main Methods
• Account: login(), logout()
• Library-Member: search-Item(), borrow-Item(), return-Item()
• Librarian: add-Book-Item(), register-Member(), issue-Loan()
• Loan: calculate-Fine(), update-Status()
Relationships
• Association: Member borrows books through Loan.
• Aggregation: Library contains many Library-Items.
• Composition: Library contains Cata-log.
• Inheritance: Book, Journal, and DVD inherit from Library-Item. Library-Member and Librarian
inherit from Account.
Design Explanation
The Library Management System allows members to search, borrow, and return library items.
Librarians manage books and members. The Cata-log stores all library items, while the Loan class
tracks borrowed items and fines. The diagram uses inheritance, association, aggregation, and
composition to show relationships between classes.
Q7. Explain State Chart Diagram with example. Discuss its components.
A State Chart Diagram is a UML behavioral diagram that shows the different states of an object and
how it changes from one state to another based on events or actions.
A State Chart Diagram represents the life cycle of an object by showing its states, transitions, events,
and actions from start to end.
Component Description
Initial State Starting point of the process (●)
State A condition or situation of an object
Transition Movement from one state to another
Event Action that causes a transition
Final State End of the process (◎)
Action Activity performed during a state

State Chart Diagram for ATM System:

This State Chart Diagram shows the different states of an ATM during a transaction.
1. Reading Card – ATM reads the inserted card.
2. Reading PIN – User enters the PIN.
3. Choosing Transaction – User selects a transaction.
4. Performing Transaction – ATM performs the selected transaction.
5. Ejecting Card – ATM returns the card after completion or cancellation.
6. End State – The ATM session ends.
If the card or PIN is invalid, or the user cancels the transaction, the ATM directly ejects the card and
ends the session.
Conclusion
The ATM reads the card, checks the PIN, allows the user to perform transactions, ejects the card, and
then ends the session. The State Chart Diagram shows these state changes step by step.
Q8. How Sequence Diagramfrom Collaboration Diagram?

Sequence Diagram Collaboration Diagram

-Shows interactions in time order. -Shows interactions through object relationships.
-Focuses on the sequence of messages. -Focuses on the communication between objects.
-Uses lifelines and message arrows. -Uses objects, links, and numbered messages.
-Time flows from top to bottom. -Time is shown using message numbers.
-Easy to understand the flow of events. -Easy to understand object connections.
-Shows when a message is sent. -Shows which object sends a message.
-More suitable for dynamic behavior. -More suitable for object organization.
-Easier to trace the complete process. -Easier to see object interactions at a glance.
-Takes more space for complex systems. -Uses less space than a sequence diagram.
-Best for showing step-by-step execution. -Best for showing collaboration among objects.

Q9. Explain Work Breakdown Structure (WBS) and its role in project scheduling.

Work Breakdown Structure (WBS) and Its Role in Project Scheduling

Definition
A Work Breakdown Structure (WBS) is a hierarchical breakdown of a project into smaller and
manageable tasks or activities. It divides a large project into smaller parts so that planning,
scheduling, and monitoring become easier.
Example
Website Development Project
• Project
o Requirement Analysis
o Design
o Coding
o Testing
o Deployment
Each phase can be further divided into smaller tasks.
Role of WBS in Project Scheduling
1. Breaks the project into manageable tasks.
2. Helps estimate time and resources for each task.
3. Makes scheduling easier by identifying activities.
4. Helps assign responsibilities to team members.
5. Improves monitoring and control of project progress.
6. Identifies dependencies between tasks.
7. Reduces the chances of missing important work.
Advantages
• Better project planning.
• Easier task management.
• Improved resource allocation.
• Helps complete the project on time.
• Makes project tracking simpler.

Conclusion
A Work Breakdown Structure (WBS) divides a project into smaller tasks, making planning,
scheduling, resource allocation, and project management more effective and organized.
Q10. Explain project staffing in software engineering. Discuss different team structures used in
software projects

Project Staffing in Software Engineering

Definition
Project staffing is the process of selecting, assigning, training, and managing people required for a
software project. It ensures that the right people with the right skills work on the project.
Importance of Project Staffing
• Assigns the right person to the right job.
• Improves productivity and software quality.
• Helps complete the project on time.
• Improves teamwork and communication.
• Reduces risks and delays.
• Ensures effective use of resources.
Team Structures in Software Projects
1. Democratic Decentralized (DD)
• No permanent leader.
• Decisions are made by the team.
• Open communication among members.
• Encourages creativity.
• Suitable for research projects.
2. Controlled Decentralized (CD)
• A leader coordinates the team.
• Decisions are shared between the leader and team.
• Good balance of control and teamwork.
• Suitable for medium and large projects.
3. Controlled Centralized (CC)
• Strong project leader.
• Most decisions are made by the leader.
• Easy to manage and control.
• Suitable for small projects.
Comparison
Feature DD CD CC
Leader No Yes Strong Leader
Decision Making Team Shared Leader
Communication Open Mixed Through Leader
Control Low Medium High

Q11. List the important items that a software project management plan (SPMP) document should
discuss.

Important Items in a Software Project Management Plan (SPMP)

A Software Project Management Plan (SPMP) is a document that describes how a software project
will be planned, managed, and completed. It helps the team work in an organized way.
1. Project Overview
o Purpose, objectives, and scope of the project.
2. Project Organization
o Team members, roles, and responsibilities.
3. Project Schedule
o Tasks, milestones, and deadlines.
 4. Resource Planning
o Required people, hardware, software, and tools.
5. Cost and Budget
o Estimated project cost and budget.
6. Risk Management
o Possible risks and plans to handle them.
7. Quality Assurance
o Quality standards and testing activities.
8. Communication Plan
o How information will be shared among team members.
9. Change Management
o Procedures for managing changes in requirements or design.
10. Monitoring and Control
o Tracking project progress and performance.
11. Project Deliverables
o Documents, software modules, and final product.
12. Assumptions and Constraints
o Project assumptions and limitations such as time and budget.
Role of SPMP
• Provides a roadmap for the project.
• Helps complete the project on time and within budget.
• Improves communication and coordination.
• Helps manage risks and resources.
• Maintains software quality.
• Increases the chances of project success.

Q12. Is system testing of object-oriented programs any different from that for procedural programs?
Explain.

System testing is generally similar for both object-oriented (OO) and procedural programs. In both
cases, the entire software system is tested to check whether it meets user requirements and works
correctly in a real environment.
However, object-oriented programs contain features such as classes, objects, inheritance,
encapsulation, and polymorphism. Therefore, testers must also verify that these features function
correctly and that objects interact properly with each other.

Differences Between Procedural and Object-Oriented System Testing

Procedural Programs Object-Oriented Programs
Focus on testing functions and Focus on testing classes, objects, and their
procedures. interactions.
Checks the flow of data and control
Checks communication between different objects.
between functions.
No inheritance or polymorphism Extra testing is needed for inheritance and
testing is required. polymorphism.
Changes usually affect specific
Changes in one class may affect related classes.
functions.
Testing is often more detailed because of object
Testing is generally simpler.
interactions.
Q13. Using suitable examples, explain how test cases can be designed for an object-oriented
program from its class diagram.

Designing Test Cases for an Object-Oriented Program from a Class Diagram

A class diagram shows the classes, their attributes, methods, and relationships. Test cases can be
designed by examining each of these elements and checking whether they work correctly.
Example: Library Management System
Classes:
• Book: book-Id, title, issue-Book(), return-Book()
• Member: member-Id, name, borrow-Book()
Test Cases
1. Attribute Testing
o Check whether book-Id, title, member-Id, and name are stored correctly.
2. Method Testing
o Issue-Book() should issue the book successfully.
o Return-Book() should return the book successfully.
3. Relationship Testing
o Verify that a member can borrow a book.
o Check that the correct book is linked to the correct member.
4. Invalid Condition Testing
o Try issuing a book that is already issued.
o Expected Result: Error message is displayed.
5. Boundary Testing
o Try borrowing more books than the allowed limit.
o Expected Result: Request is rejected.
6. Object Interaction Testing
o Check whether Book and Member objects communicate correctly during borrowing
and returning operations.
Conclusion
Test cases for an object-oriented program are derived from the classes, attributes, methods, and
relationships shown in the class diagram. This helps ensure that individual classes and their
interactions work correctly and meet the system requirements

Q14. Is integration testing of object-oriented programs any different from that for the procedural
programs? Explain your answers.

Yes, there are some differences.

In procedural programs, integration testing checks whether different functions or modules work
correctly together and exchange data properly.
In object-oriented programs, integration testing focuses on how different objects and classes
interact with each other. It also checks object-oriented features such as inheritance, polymorphism,
and message passing between objects.
Example:
• In a procedural banking system, testing checks whether the deposit and withdraw functions
work together correctly.
• In an object-oriented banking system, testing checks whether classes such as Account,
Customer, and Transaction interact correctly.
Conclusion:
The goal of integration testing is the same in both cases—to ensure different parts of the software
work together correctly. However, object-oriented integration testing is more focused on
interactions between objects and classes, while procedural integration testing focuses on
interactions between functions and modules.

Q15. Differentiate between verification and validation with proper examples.

Difference Between Verification and Validation

Verification Validation
Checks whether the software is being developed Checks whether the software meets user
correctly. needs.
Focuses on documents, design, and code. Focuses on the final software product.
Done during software development. Done after development through testing.
Does not require running the software. Requires running the software.
Uses reviews, inspections, and walkthroughs. Uses different types of testing.
Finds mistakes early in the development process. Finds problems in the working software.
Usually done by developers and reviewers. Usually done by testers and users.
Checks if requirements are followed correctly. Checks if user requirements are satisfied.
Asks: "Are we building the product correctly?" Asks: "Are we building the right product?"
Examples
Verification Example:
• Reviewing the SRS document.
• Checking the software design before coding.
Validation Example:
• Testing an ATM system to see if cash withdrawal works properly.
• Testing a login page to check whether users can log in successfully.

Q16. Explain System Design in Software Engineering. Discuss its principles and approaches

System Design is the process of creating the overall structure of a software system. It defines how
different modules, components, and data will work together to meet user requirements. It acts as a
bridge between requirement analysis and coding.
Principles of System Design
1. Modularity – Divide the system into smaller modules.
2. Simplicity – Keep the design easy to understand and implement.
3. Reusability – Use components that can be used again in other projects.
4. Flexibility – Allow easy changes and upgrades.
5. Reliability – Ensure the system works correctly and consistently.
6. Efficiency – Use time, memory, and other resources effectively.
7. Maintainability – Make the system easy to maintain and fix.
Approaches to System Design
1. Top-Down Approach – Start with the whole system and break it into smaller modules.
2. Bottom-Up Approach – Start with small modules and combine them into a complete system.
3. Object-Oriented Approach – Design the system using classes and objects.
4. Structured Approach – Design based on functions, processes, and data flow.
Benefits of Good System Design
• Improves software quality and performance.
• Makes development and testing easier.
• Reduces development time and cost.
• Simplifies maintenance and future updates.
• Helps manage large and complex software systems effectively.
Q17. Why is balancing important in DFD? Explain with consequence if violated.

Balancing in a Data Flow Diagram (DFD) means that the input and output data flows of a process
remain consistent when the process is broken down into lower-level DFDs.
Importance of Balancing
• Ensures consistency between different levels of DFD.
• Helps represent the system accurately.
• Makes the design easier to understand and verify.
• Prevents missing or extra data flows.
• Improves system analysis and documentation.
Consequences if Balancing is Violated
• Important data flows may be missing.
• Extra data flows may appear that do not exist in the higher-level DFD.
• Creates confusion and inconsistencies in system design.
• Can lead to incorrect system implementation.
• Makes testing and maintenance more difficult.
Example
If a process in a Level-0 DFD receives Customer Details and produces Order Confirmation, then the
corresponding Level-1 DFD must also show these same input and output flows. If any of these flows
are missing or extra flows are added, the DFD is said to be unbalanced.

Q20. Explain the Spiral Model in detail and justify why it is called a risk-driven model.

he Spiral Model is a software development model that combines features of the Waterfall Model
and Prototyping Model. Development is carried out in a series of loops called spirals. Each loop
represents one phase of the project and helps improve the software step by step.
Phases of the Spiral Model
1. Planning
o Identify objectives, requirements, and project constraints.
2. Risk Analysis
o Identify possible risks and find solutions to reduce them.
3. Engineering (Development)
o Design, code, and test the software.
4. Evaluation
o Customer reviews the work and provides feedback for the next cycle.
These phases are repeated until the final software is completed.
Why It Is Called a Risk-Driven Model
• Risk analysis is the most important activity in each spiral.
• Risks are identified and handled before moving to the next phase.
• Helps reduce project failures and unexpected problems.
• Suitable for large and complex projects where risks are high.
• Decisions are made based on risk assessment at every stage.
Advantages
• Early identification of risks.
• Flexible and easy to accommodate changes.
• Continuous customer feedback.
• Produces high-quality software.
Disadvantages
• More expensive than some other models.
• Requires risk analysis expertise.
• Not suitable for small projects.
Q21. Explain Cost–Benefit Analysis in Software Engineering. Discuss its components, techniques, and
significance.

Cost–Benefit Analysis (CBA) is a technique used to compare the costs and benefits of a software
project. It helps organizations decide whether a project is worth developing and investing in.
Components of Cost–Benefit Analysis
1. Costs
o Development cost
o Hardware and software cost
o Maintenance cost
o Training cost
2. Benefits
o Increased productivity
o Reduced operating costs
o Improved efficiency
o Better customer satisfaction
Techniques of Cost–Benefit Analysis
1. Payback Period
o Calculates how long it takes to recover the project cost.
2. Net Benefit Analysis
o Compares total benefits with total costs.
o Net Benefit = Total Benefits − Total Costs
3. Return on Investment (ROI)
o Measures the profit gained from the investment.
4. Break-Even Analysis
o Determines the point where benefits become equal to costs.
Significance of Cost–Benefit Analysis
• Helps decide whether a project is feasible.
• Supports better decision-making.
• Reduces financial risk.
• Ensures effective use of resources.
• Helps compare different project alternatives.
• Improves project planning and budgeting.

Q22. Discuss the basic COCOMO model for software cost estimation.
COCOMO (Constructive Cost Model) is a software cost estimation model developed by Barry Boehm.
It is used to estimate the effort, development time, and cost required to develop a software project.
The Basic COCOMO model estimates effort mainly based on the size of the software, measured in
KLOC (Thousands of Lines of Code).
Types of Projects in Basic COCOMO
1. Organic Project
o Small and simple projects.
o Developed by experienced teams.
2. Semi-Detached Project
o Medium-sized projects.
o Team has mixed experience levels. .
3. Embedded Project
o Large and complex projects.
o Strict hardware and software constraints.
Basic COCOMO Formula
Effort is estimated using:
 𝐸𝑓𝑓𝑜𝑟𝑡 = 𝑎(𝐾𝐿𝑂𝐶)𝑏
Effort = Person-months required ; KLOC = Thousands of lines of code ; a, b = Constants depending on
project type
Advantages
• Simple and easy to use.
• Helps estimate project cost and effort early.
• Useful for project planning and budgeting.
Limitations
• Depends mainly on code size.
• Less accurate for modern software projects.
• Does not consider all project factors.

Q25. Draw the collaboration diagram of the banking system.

This is a UML Communication Diagram (formerly called Collaboration Diagram) for an ATM Cash
Withdrawal System.
Objects in the Diagram
• Customer – uses the ATM
• Customer Console – ATM screen and buttons
• Withdrawal Transaction – handles the withdrawal process
• Cash Dispenser – gives cash
• Network Connection – connects ATM to the bank
• Bank – checks and approves the transaction
• Log – stores transaction records
Simple Working
1. Customer selects an account.
2. Customer enters the withdrawal amount.
3. ATM sends the request to the withdrawal transaction system.
4. The system asks the bank for approval.
5. The bank verifies the account and balance.
6. If approved, the cash dispenser releases cash.
7. The customer receives the cash.
8. Transaction details are saved in the log. –end—
Purpose
The diagram helps us understand:
• Which components are involved in cash withdrawal.
• How they communicate with each other.
• The order of messages exchanged during the transaction.

Q26. What are the different components used to describe a collaboration diagram?
Components of a Collaboration Diagram:
[Link]
o Represent people, devices, or system parts involved in the process.
o Example: Customer, ATM, Bank.
2. Actors
o External users or systems that interact with the system.
o Example: Customer.
3. Links
o Connections between objects.
o Show which objects can communicate with each other.
4. Messages
o Information exchanged between objects.
o Represented by arrows.
o Example: Withdrawal request, Approval message.
5. Sequence Numbers
o Numbers attached to messages.
o Show the order of communication (1, 2, 3, ...).
6. Conditions (Optional)
o Specify when a message should be sent.
o Example: If balance is available, dispense cash.
7. Roles
o Define the responsibility of each object in the interaction.
o Example: Bank verifies the transaction.
Importance
• Helps understand how system components interact.
• Shows the flow of messages clearly.
• Makes communication between developers and users easier.

Q27. How Activity Diagram different from a flowchart?

Difference Between Activity Diagram and Flowchart (Simple Language)
Activity Diagram Flowchart
Used in UML to model software systems. Used to represent any process or algorithm.
Shows the flow of activities in a system. Shows the step-by-step flow of a process.
Can represent parallel activities
Usually shows one flow at a time.
(concurrency).
Includes UML elements like swim-lanes, Uses basic symbols like process, decision, and
forks, and joins. input/output.
Focuses on the behaviour of a system or Focuses on solving a problem or explaining a
business process. procedure.
Used in many fields such as programming, business,
Commonly used in software engineering.
and manufacturing.
Can show responsibility of different users or
Does not clearly show responsibilities.
departments.
Q28. Why is a class diagram alone insufficient to model a complete system? Justify.

A Class Diagram shows the structure of a system, such as classes, attributes, methods, and
relationships between classes. However, it does not show everything needed to understand a
complete system.
Reasons:
1. Does not show system behaviour
o It shows what classes exist, but not how they work during execution.
2. Does not show interactions
o It cannot explain how objects communicate with each other.
o For this, Sequence or Collaboration Diagrams are used.
3. Does not show workflow
o It cannot represent the flow of activities or business processes.
o Activity Diagrams are needed for that.
4. Does not show state changes
o It cannot describe how an object changes from one state to another.
o State Chart Diagrams are used for this purpose.
5. Does not show user requirements
o It does not explain how users interact with the system.
o Use Case Diagrams help in understanding user requirements.

Q29. What is a Collaboration Diagram? How is it different from Sequence Diagram?

A Collaboration Diagram (also known as a Communication Diagram) is a UML diagram that shows
how different objects in a system communicate with each other to complete a task.
It focuses on:
• Objects involved in the system.
• Messages exchanged between objects.
• Relationships among objects.
• Order of communication using sequence numbers.
Example: In an ATM withdrawal system, the Customer, ATM, Bank, and Cash Dispenser interact to
complete the transaction.

Difference Between Collaboration Diagram and Sequence Diagram

Collaboration Diagram Sequence Diagram
Focuses on object relationships and
Focuses on the time sequence of interactions.
communication.
Messages are shown using numbered arrows. Messages are shown from top to bottom.
Shows how objects are connected. Shows the exact order of message flow.
Emphasizes the structural organization of
Emphasizes the timing of interactions.
objects.
Easier to understand object links. Easier to understand process flow.
Uses lifelines to represent object existence over
Does not clearly show lifelines.
time.
Can become lengthy when many messages are
More compact for complex systems.
involved.
Best for understanding communication among Best for understanding the sequence of
objects. operations.
Q31. Differentiate aggregation and composition.

Aggregation Composition
Represents a weak "has-a" relationship. Represents a strong "has-a" relationship.
The part can exist independently of the whole. The part cannot exist without the whole.
If the whole object is deleted the part can still exist. If the whole object is deleted, the part is also deleted.
Shown by a hollow diamond (◇) in UML. Shown by a filled diamond (◆) in UML.
Ownership is weak. Ownership is strong.
Objects have a loose connection. Objects have a very close connection.
Parts can be shared by multiple objects. Parts belong to only one whole object.
Lifetime of part and whole are separate. Lifetime of part and whole are dependent.
Used when objects can work independently. Used when objects work as a single unit.

Examples
• Aggregation: Department → Teacher, Library → Books, Team → Players.
• Composition: House → Rooms, Car → Engine, Computer → Motherboard.

Q32. Explain UML Class Diagram with key components.

A Class Diagram is one of the most important UML diagrams. It shows the static structure of a
system by representing classes, their attributes, methods, and relationships with other classes.
It helps developers understand how a system is organized and how different classes are connected.

Key Components of a Class Diagram

1. Class
o Represents an object or entity in the system.
2. Attributes
o Describe the properties or data of a class.
3. Methods (Operations)
o Represent the functions performed by a class.
4. Association
o Shows a relationship between two classes.
5. Aggregation
o A weak "has-a" relationship.
6. Composition
o A strong "has-a" relationship. .
7. Inheritance (Generalization)
o One class inherits properties and methods from another class.
o Example: Car inherits from Vehicle.
8. Multiplicity
o Shows how many objects can participate in a relationship.

Advantages
• Provides a clear view of system structure.
• Helps in software design and development.
• Makes relationships between classes easy to understand.
• Acts as a blueprint for coding.
Q33. Why is uncontrolled change considered a major risk? How does SCM mitigate it?

Uncontrolled change means making changes to software without proper planning, approval, or
documentation.
It is a major risk because:
• It can introduce new errors and bugs.
• Different versions of the software may get mixed up.
• Team members may work on outdated files.
• Project cost and development time may increase.
• Important features may stop working.
• It becomes difficult to track who made changes and why.

How Does SCM Mitigate It?

SCM (Software Configuration Management) helps control and manage changes in software.
It mitigates uncontrolled change by:
1. Tracking all changes made to the software.
2. Maintaining version control so old and new versions are not confused.
3. Requiring approval before important changes are made.
4. Keeping records and documentation of every change.
5. Helping team members work on the correct version of the software.
6. Allowing rollback to a previous version if a problem occurs.

Q34. Explain different team structures in software projects.

A team structure defines how team members are organized and how they work together in a
software project.

1. Democratic Decentralized (DD) Team

• No permanent leader.
• Decisions are made by group discussion.
• All members have equal participation.
• Encourages creativity and teamwork.
Advantage: High member involvement.
Disadvantage: Decision-making may take more time.

2. Controlled Decentralized (CD) Team

• Has a team leader.
• Problem-solving is done by the group.
• The leader coordinates and guides the team.
• Communication occurs among all members.
Advantage: Good balance between leadership and teamwork.
Disadvantage: Requires good coordination.

3. Controlled Centralized (CC) Team

• Strong team leader controls the project.
• Most decisions are made by the leader.
• Communication mainly flows through the leader.
• Suitable for small and well-defined projects.

Advantage: Faster decision-making.

Disadvantage: Less creativity and member participation.
Q35. What is a Gantt chart? State its advantages.
A Gantt Chart is a graphical project management tool used to plan, schedule, and track project
activities over time.
It displays:
• Tasks or activities on the vertical axis.
• Time (days, weeks, or months) on the horizontal axis.
• Bars that show the start date, duration, and end date of each task.
It helps project managers monitor progress and ensure that tasks are completed on schedule.
Advantages of a Gantt Chart
1. Shows project schedule clearly
o Displays all tasks and their timelines in one view.
2. Tracks project progress
o Helps compare planned progress with actual progress.
3. Improves planning
o Assists in organizing tasks and setting deadlines.
4. Identifies task dependencies
o Shows which tasks must be completed before others can begin.
5. Improves team coordination
o Team members can easily understand their responsibilities.
6. Helps manage resources
o Ensures proper allocation of people, time, and resources.
7. Detects delays early
o Makes it easier to identify schedule problems and take corrective action.
8. Enhances communication
o Provides a simple visual representation of the project for all stakeholders.

Q36. Can verification succeed while validation fails? Explain.

Yes, verification can succeed while validation fails.
• Verification checks whether the software is built correctly according to specifications and
design documents.
• Validation checks whether the software meets the user's actual needs and requirements.
Example
Suppose a software team develops an online shopping application exactly as described in the design
document.
• All functions are implemented correctly.
• No coding or design errors are found.
• Therefore, verification succeeds.
However, customers wanted a mobile payment option, but it was not included in the requirements
document.
• The software works as designed.
• But it does not satisfy user needs.
• Therefore, validation fails.
Why Does This Happen?
• Requirements may be incomplete or incorrect.
• User needs may not be fully understood.
• The software may be technically correct but not useful to users.
Importance
• Verification helps ensure software quality and correctness.
• Validation ensures customer satisfaction.
• Both are necessary for successful software development.
• A product is considered successful only when it passes both verification and validation.
Q37. Explain Software Configuration Management (SCM).

Software Configuration Management (SCM) is the process of managing, controlling, and tracking
changes made to software during its development and maintenance.
It ensures that the correct versions of software, documents, and source code are used throughout
the project.

Main Activities of SCM

1. Configuration Identification – Identifying software components that need to be managed.
2. Version Control – Maintaining different versions of software.
3. Change Control – Reviewing and approving changes before implementation.
4. Configuration Status Accounting – Recording and tracking all changes.
5. Configuration Audits – Verifying that changes are properly implemented.

Advantages of SCM
• Controls software changes effectively.
• Prevents version confusion and data loss.
• Improves teamwork and coordination.
• Helps track the history of changes.
• Maintains software quality and consistency.
• Allows recovery of previous versions when needed.

Q38. Explain Staffing in Software Project Management.

Staffing is the process of selecting, assigning, and managing people for a software project. It means
choosing the right people with the right skills and giving them suitable jobs so that the project can be
completed successfully. Staffing ensures that enough team members are available when needed and
that everyone knows their responsibilities.

Activities in Staffing
1. Planning Human Resources
o Determine the number and type of people required for the project.
2. Recruitment
o Hire or assign suitable team members.
3. Role Assignment
o Assign responsibilities based on skills and experience.
4. Training and Development
o Provide training to improve technical and managerial skills.
5. Performance Management
o Monitor and evaluate team performance.
6. Team Motivation
o Encourage team members through rewards, recognition, and support.

Importance of Staffing
• Ensures the right people are available at the right time.
• Improves productivity and software quality.
• Helps complete projects within budget and schedule.
• Reduces project risks caused by lack of skilled personnel.
• Promotes better teamwork and communication.
Q39. Why is unit testing insufficient for ensuring software quality?

Unit testing checks individual units or modules of a program to make sure they work correctly.
However, it alone cannot guarantee overall software quality.
A module may pass unit testing, but problems can still occur when it interacts with other modules.
Unit testing also does not verify whether the complete system meets user requirements or performs
well in real-world situations.

Reasons
1. Tests only individual modules
o It does not check how different modules work together.
2. Cannot detect integration issues
o Errors may occur when modules interact with each other.
3. Does not test the complete system
o The entire software may behave differently when all parts are combined.
4. Does not check user requirements
o A module may work correctly but still not meet user needs.
5. Cannot find performance problems
o Issues like slow response time or high memory usage are not usually detected.
6. Does not test security and reliability
o Security vulnerabilities and system failures may remain unnoticed.

Q40. Explain testing metrics.

Testing metrics are measurements used to evaluate the progress, effectiveness, and quality of
software testing. They help testers and managers understand how well the testing process is working
and whether the software is ready for release.

Common Testing Metrics

1. Test Cases Executed
o Number of test cases that have been run.
2. Test Case Pass Rate
o Percentage of test cases that passed successfully.
3. Test Case Fail Rate
o Percentage of test cases that failed.
4. Defect Count
o Total number of defects (bugs) found during testing.
5. Defect Density
o Number of defects found per module or per size of software.
6. Defect Removal Efficiency (DRE)
o Measures how effectively defects are detected and fixed.
7. Test Coverage
o Percentage of software code or requirements tested.

Importance of Testing Metrics

• Helps measure software quality.
• Tracks testing progress.
• Identifies problem areas in the software.
• Improves testing efficiency.
• Supports better project decisions.
Q41. Explain Software Reliability.

Software Reliability is the ability of a software system to work correctly and consistently without
failures for a specified period of time under given conditions.
In simple words, it means how dependable and error-free the software is while performing its
tasks.
Features of Software Reliability
1. Correct Operation
o The software produces accurate results.
2. Consistency
o It works properly every time it is used.
3. Failure-Free Performance
o It runs without crashes or unexpected errors.
4. Dependability
o Users can trust the software to perform its functions correctly.
5. Stability
o The software continues to work well over time.
Importance of Software Reliability
• Increases user confidence and satisfaction.
• Reduces software failures and maintenance costs.
• Ensures smooth and continuous operation.
• Improves the overall quality of the software.
• Very important in critical systems such as banking, healthcare, and aviation.
Example
A banking application that processes transactions correctly every day without crashing is considered
highly reliable.

Q42. What is a Test Case? Explain its components.

A Test Case is a set of conditions, inputs, and expected results used to check whether a software
feature is working correctly or not.
Components of a Test Case
1. Test Case ID
o A unique number or name used to identify the test case.
2. Test Objective
o Describes what is being tested.
3. Test Input
o The data entered into the system.
4. Preconditions
o Conditions that must be met before testing starts.
5. Test Steps
o The sequence of actions to perform the test.
6. Expected Result
o The output that should be produced if the software works correctly.
7. Actual Result
o The output obtained after executing the test.
8. Status
o Indicates whether the test Passed or Failed.
Example
Test Case: Login Function
• Input: Valid username and password
 • Steps: Enter username → Enter password → Click Login
• Expected Result: User should successfully log in to the system
• Status: Pass/Fail
Importance of Test Cases
• Ensure software works as expected.
• Help find defects and errors.
• Improve software quality.
• Make testing systematic and organized.

Q43. Explain different levels of testing.

Software testing is performed at different levels to find defects and ensure software quality.
1. Unit Testing
• Tests individual modules or functions of a program.
• Usually performed by developers.
• Ensures each unit works correctly.
Example: Testing a login function separately.
2. Integration Testing
• Tests how different modules work together.
• Detects errors in communication between modules.
Example: Checking whether the login module correctly connects with the database.
3. System Testing
• Tests the complete software as a whole.
• Verifies that all requirements are met.
Example: Testing the entire online shopping system.
4. Acceptance Testing
• Performed by customers or end users.
• Ensures the software meets business and user requirements.
• Final testing before software release.
Example: Users testing an e-commerce website before it goes live.
Importance of Different Testing Levels
• Finds defects at different stages.
• Improves software quality and reliability.
• Ensures all components work together properly.
• Increases user satisfaction.

Q44. Why is balancing in DFD more critical than levelling? Justify

Balancing and levelling are both important in a Data Flow Diagram (DFD), but balancing is more
critical because it ensures the correctness and consistency of the system model.
Balancing
• Balancing means that the input and output data flows of a process remain the same when
moving from a higher-level DFD to a lower-level DFD.
• It ensures that no data is added, removed, or changed incorrectly.
• It maintains the accuracy of the system representation.
Levelling
• Levelling means breaking a process into smaller and more detailed subprocesses.
• It improves understanding by showing more details of the system.
Why Balancing is More Critical?
1. Maintains consistency
o Ensures that all data flows are correctly represented at every level.
2. Prevents errors
o Avoids missing or extra data flows in lower-level diagrams.
 3. Represents the system accurately
o Keeps the DFD logically correct.
4. Essential for correctness
o A DFD can still work with less detail, but it cannot be correct if it is unbalanced.

Q45. Compare Decision Tree and Decision Table.

Decision Tree Decision Table

A graphical representation of decisions and their A tabular representation of conditions and
possible outcomes. actions.
Uses rows and columns to organize
Uses a tree-like structure with branches.
information.
Easy to understand and visualize the flow of Easy to represent a large number of conditions
decisions. and rules.
Does not show the sequence of
Shows the sequence in which decisions are made.
decisions.
Suitable for simple to moderately complex decision Suitable for complex decision logic with many
problems. conditions.
Can become large and difficult to read when many Remains organized even when many conditions
conditions exist. are involved.
Helps users quickly find the correct action for
Helps users follow the decision path step by step.
a given condition.
Commonly used for decision analysis and problem Commonly used for testing and requirement
solving. specification.

Q46. Explain the difference between Context Diagram and DFD.

Context Diagram Data Flow Diagram (DFD)

It is the highest-level view of a system. It provides a detailed view of the system.
Shows the entire system as a single process. Shows the system as multiple processes.
Displays processes, data stores, external entities,
Displays only external entities and data flows.
and data flows.
Shows how data moves and is processed inside
Does not show internal working of the system.
the system.
Simple and easy to understand. More detailed and informative.
Used as the starting point of system analysis. Used for detailed system design and analysis.
Contains more detailed information about system
Contains very little detail.
operations.
Example
Context Diagram:
• Shows an Online Shopping System as one process interacting with Customer, Bank, and
Supplier.
DFD:
• Breaks the Online Shopping System into processes such as Login, Order Processing, Payment,
and Delivery.
Q48. What are common errors in DFD? Explain.

While creating a DFD, some common mistakes can make the diagram incorrect or confusing.
1. Black Hole
• A process has input data but no output data.
• Data enters the process but nothing comes out.
2. Miracle
• A process has output data but no input data.
• Data appears without any source.
3. Gray Hole
• A process produces outputs that cannot be generated from the given inputs.
• The output is not logically possible from the input.
4. Unbalanced DFD
• Input and output data flows do not match between different DFD levels.
• Data is added or removed incorrectly when moving to a lower-level DFD.
5. Missing Data Flow
• Required data flow is not shown in the diagram.
• This can make the system incomplete.
6. Incorrect Data Flow Direction
• Data flow arrows point in the wrong direction.
• This gives an incorrect understanding of the system.
7. Direct Connection Errors
• Data should not flow directly:
o From one external entity to another.
o From one data store to another.
o From an external entity directly to a data store.
• A process must be used between them.

Q49. What is a Context Diagram? Explain its importance.

A Context Diagram is the highest-level Data Flow Diagram (DFD) that shows the entire system as a
single process and its interaction with external entities such as users, customers, banks, or other
systems.
It provides a simple overview of the system by showing:
• The system boundary.
• External entities interacting with the system.
• Data entering and leaving the system.
It does not show internal processes or data stores.
Importance of a Context Diagram
1. Provides a clear overview
o Shows the system and its surroundings in a simple way.
2. Defines system boundaries
o Clearly identifies what is inside and outside the system.
3. Shows external interactions
o Displays how users and other systems interact with the system.
4. Easy to understand
o Can be understood by developers, managers, and customers.
5. Acts as a starting point
o Serves as the first step in creating detailed DFDs.
6. Improves communication
o Helps stakeholders understand the scope of the system.
Example
In an Online Shopping System, the context diagram may show:
• Customer
• Bank
• Supplier
interacting with the Online Shopping System through data flows such as orders, payments, and
delivery information.

Q50. Why is SDLC considered iterative even in linear models like Waterfall?

The Waterfall Model follows a linear sequence of phases such as Requirements, Design, Coding,
Testing, and Maintenance. However, SDLC is still considered iterative because projects often need to
go back to previous phases when problems or changes are discovered.
Reasons
1. Errors may be found later
o A mistake in design may be discovered during coding or testing and needs
correction.
2. Requirements may change
o Customers may request changes after development has started.
3. Feedback causes revisions
o Testing and reviews often lead to improvements in earlier work.
4. Continuous improvement
o Each phase is checked and refined to improve software quality.
5. Maintenance involves updates
o After deployment, bugs are fixed and new features may be added, creating another
cycle of development.
Example
Suppose a defect is found during testing. The team may need to return to the design or coding phase
to fix it. This shows that even in Waterfall, some iteration occurs.

Q51. Why does a small error in KLOC estimation lead to a large error in effort estimation?

KLOC (Kilo Lines of Code) means the estimated size of software in thousands of lines of code. Effort
estimation methods, such as COCOMO, use KLOC as a major input to calculate the effort required.
A small error in KLOC estimation can cause a large error in effort estimation because effort is not
directly proportional to KLOC. Most estimation models use mathematical formulas where effort
increases rapidly as software size increases.
Reasons
1. Effort depends heavily on KLOC
o Even a small change in software size affects the estimated effort.
2. Estimation formulas are sensitive
o Models like COCOMO use exponents, so errors get magnified.
3. Affects project planning
o Wrong KLOC leads to incorrect estimates of time, cost, and manpower.
4. Can cause budget overruns
o Underestimating KLOC may result in insufficient resources.
5. May delay project completion
o More code usually requires more development, testing, and maintenance effort.
Example
If a project is estimated as 50 KLOC but the actual size becomes 60 KLOC, the required effort may
increase much more than 20%, leading to higher cost and longer development time.
Q52. When is the Waterfall Model suitable? Explain with reasons.
The Waterfall Model is suitable for projects where the requirements are clear, fixed, and well
understood from the beginning. It works best when changes are not expected during development.
Reasons
1. Requirements are clearly defined
o All project requirements are known before development starts.
2. Requirements are stable
o There is little or no chance of changes during the project.
3. Simple and small projects
o Easy to manage and understand for small projects.
4. Well-defined process
o Each phase is completed before moving to the next phase.
5. Good documentation
o Detailed documentation is maintained at every stage.
6. Easy project management
o Progress can be tracked easily because phases are clearly defined.
7. Suitable for familiar technology
o Works well when the team is using known tools and technologies.
Examples
• Payroll Management System
• Library Management System
• Inventory Management System
• Government or banking projects with fixed requirements

Q53. Explain the Spiral Model and its advantages.

The Spiral Model is a software development model that combines the features of the Waterfall
Model and Prototyping Model. Development is carried out in a series of cycles called spirals. Each
spiral includes planning, risk analysis, development, and testing.
It is known as a risk-driven model because risk analysis is performed in every cycle before moving
forward.
Phases of the Spiral Model
1. Planning
o Gather requirements and define objectives.
2. Risk Analysis
o Identify and evaluate possible risks and find solutions.
3. Engineering (Development)
o Design, code, and test the software.
4. Evaluation
o Customer reviews the work and provides feedback.
These phases are repeated in each spiral until the software is completed.
Advantages of the Spiral Model
1. Risk management
o Risks are identified and handled early.
2. Customer involvement
o Customers provide feedback at every stage.
3. Flexible to changes
o New requirements can be added easily.
4. Improved software quality
o Continuous testing and evaluation reduce errors.
5. Suitable for large and complex projects
o Helps manage projects with high uncertainty.
Q56. Explain the phases of System Development Life Cycle (SDLC) with neat diagram.
SDLC (System Development Life Cycle) is a structured process used to develop high-quality software.

It consists of several phases that guide the development of a software system from start to finish.
1. Planning
• Identify project goals and objectives.
• Determine feasibility, cost, and resources required.
2. Requirement Analysis
• Gather and analyse user requirements.
• Understand what the customer needs from the system.
3. System Design
• Create the system architecture and design.
• Define database, interfaces, and software structure.
4. Coding / Development
• Convert the design into program code.
• Developers write and build the software.
5. Testing
• Check the software for errors and bugs.
• Ensure that all requirements are met correctly.
6. Implementation (Deployment)
• Install and launch the software for users.
• Make the system available in the real environment.
7. Maintenance
• Fix bugs and improve the software after deployment.
• Add new features and updates when required.
Importance of SDLC
• Provides a systematic approach to development.
• Improves software quality.
• Reduces development risks and costs.
• Helps complete projects on time.
Q57. Define Waterfall model. State two advantages of prototype model.

Waterfall Model
The Waterfall Model is a traditional software development model in which development is carried
out in a step-by-step sequence. Each phase must be completed before moving to the next phase, and
there is very little overlap between phases.

Phases:
Requirements Analysis → System Design → Coding → Testing → Deployment → Maintenance
It is called the Waterfall Model because progress flows downward from one phase to another like a
waterfall.

Advantages of Prototype Model

• Better Requirement Understanding:
Users can interact with the prototype and provide feedback, which helps developers
understand requirements more clearly.
• Early Detection of Errors:
Problems and missing features can be identified at an early stage, reducing the cost and
effort of fixing them later.
• Improved User Involvement:
Continuous user participation ensures that the final system meets user expectations.
• Reduced Development Risk:
Since requirements are validated early, the chances of project failure are minimized.

Q58. Compare Prototype and Spiral model.

Prototype Model Spiral Model
Focuses on developing a working prototype to Focuses on risk analysis and risk management
understand user requirements. during development.
Suitable when requirements are unclear or Suitable for large, complex, and high-risk
changing. projects.
User feedback plays a major role. Risk assessment plays a major role.
Less expensive and simpler to implement. More expensive and complex to manage.
Prototype is built and refined until requirements Development proceeds through repeated spiral
are clear. cycles.
Risk analysis is minimal. Detailed risk analysis is performed in every cycle.
Best for small to medium projects. Best for large and critical projects.

Q59. Why is the Incremental Model more flexible than the Waterfall Model? Explain.
The Incremental Model is more flexible than the Waterfall Model because the software is developed
and delivered in small increments (parts) rather than as a single complete product.
In the Waterfall Model, each phase must be completed before moving to the next phase, making it
difficult to accommodate changes once development has started. On the other hand, the
Incremental Model allows changes and improvements to be made in later increments based on user
feedback.
Reasons why Incremental Model is more flexible:
1. Changes in requirements can be incorporated in future increments.
2. Users can provide feedback after each release.
3. Errors can be identified and corrected early.
4. New features can be added gradually without affecting the entire system.
5. Working software is available at an early stage.
Q60. Evaluate Spiral model for risk-driven projects.

The Spiral Model is a software development model that combines the features of the Waterfall
Model and Prototyping Model. It is called a risk-driven model because risk analysis is performed in
every cycle of development.
Evaluation of Spiral Model for Risk-Driven Projects
1. Focuses on Risk Management
o Risks are identified, analyzed, and resolved early in each phase.
o This reduces the chances of project failure.
2. Suitable for Large and Complex Projects
o It is ideal for projects with high cost, complexity, and uncertainty.
o Examples include banking, defense, and aerospace systems.
3. Supports Changing Requirements
o Requirements can be modified during different spiral cycles.
o This makes the model flexible and adaptable.
4. Continuous Customer Involvement
o Customers provide feedback after each cycle.
o This helps ensure the final product meets user needs.
5. Improved Quality
o Regular testing and evaluation in every iteration improve software quality.
Limitations
• It is costly and time-consuming.
• Requires expertise in risk analysis.
• Not suitable for small or low-risk projects.

Q61. Draw a Context Diagram for Library Management System.

Q62. What is Problem Partitioning? Explain with neat diagram.
Problem Partitioning is the process of dividing a large and complex problem into smaller,
manageable sub-problems or modules. Each module can be developed, tested, and maintained
independently, making software development easier and more organized.
Advantages:
• Reduces complexity
• Improves modularity
• Makes testing easier
• Simplifies maintenance
• Allows parallel development

Q63. Compare Top-Down Design and Bottom-Up Design using block diagrams.

Top-Down Design Bottom-Up Design

System A1 A2 B1 B2
| | | | |
----------------- -------- --------
| | | |
Module A Module B Module A Module B
| | \ /
------- ------- \ /
| | | | \ /
A1 A2 B1 B2 System

Top-Down Design Bottom-Up Design

Starts from the main system and breaks it into Starts from small modules and combines them to
smaller modules. form a complete system.
Focuses on overall system design first. Focuses on individual components first.
Easier to understand system structure. Easier to reuse existing modules.
Testing is done from higher level to lower level. Testing is done from lower level to higher level.
Uses stepwise refinement. Uses module integration.
Q64. Construct a Decision Tree for student result processing system.

1. Collect and verify student data.

2. Check attendance (minimum 75% required).
3. Verify marks of each subject.
4. Check Theory/Practical marks (minimum 40% required).
5. Decide Subject Pass or Subject Fail.
6. Combine all subject results.
7. If all subjects are passed, calculate GPA/Percentage.
8. Classify result:
9. ≥ 70% → First Class with Distinction
10. 60–69% → First Class
11. 50–59% → Second Class
12. 40–49% → Pass Class
13. < 40% → Fail
14. One failed subject → Supplementary Exam.
15. Multiple failed subjects → Repeat Year/Disqualified.

Q65. What is Structured Programming? Mention its features.

Structured Programming is a programming approach in which a program is divided into small and
manageable modules or functions. It uses a logical sequence of instructions and avoids unnecessary
jumps (like go-to statements), making the program easier to understand and maintain.
Features of Structured Programming:
1. Modular Design – Program is divided into smaller functions/modules.
2. Top-Down Approach – Complex problems are broken into simpler subproblems.
3. Sequence, Selection, and Iteration – Uses basic control structures like loops and decision
statements.
4. Easy Debugging – Errors can be found and fixed easily.
5. Easy Maintenance – Modifications can be made without affecting the whole program.
6. Improved Readability – Code is clear and easy to understand.
7. Code Reusability – Functions can be reused in different parts of the program.
Q66. Define Unit Testing and Integration Testing with suitable diagram.

Unit Testing
Unit Testing is a software testing technique in which individual units or components of a program are
tested separately to ensure that each unit works correctly.
Example: Testing a login function independently.

Integration Testing
Integration Testing is a software testing technique in which two or more tested modules are
combined and tested together to verify that they interact correctly.
Example: Testing the interaction between the login module and the database module.

Q67. Explain Information Hiding with class/module diagram.

Information Hiding is the concept of hiding the internal data and implementation details of a class or
module and allowing access only through public methods/interfaces. It improves security, reduces
complexity, and makes maintenance easier.

Q68. Draw and explain different levels of software testing.

Unit Testing→Integration Testing→System Testing→Acceptance Testing

Different Levels of Software Testing

1. Unit Testing
o Tests individual functions, methods, or modules.
o Done by developers.
o Example: Testing the login function separately.
2. Integration Testing
o Tests how different modules work together.
o Finds errors in interactions between modules.
o Example: Checking if the login module correctly connects with the database.
3. System Testing
o Tests the complete software as a whole.
o Ensures all requirements are met.
o Example: Testing the entire online shopping system.
4. Acceptance Testing
o Performed by the customer or end users.
o Verifies whether the software meets user needs.
o Example: Customer checks if all required features work correctly before deployment.

Q70. Differentiate Validation and Verification using flow diagram.

Q71. What is Software Configuration Management? Draw SCM cycle.

Software Configuration
Management (SCM) is the
process of managing, controlling,
and tracking changes made to
software throughout its
development life cycle.
Main Activities of SCM:
• Configuration
Identification
• Version Control
• Change Control
• Configuration Status
Reporting
• Configuration Audits
Benefits:
• Controls software
changes
• Prevents version
conflicts
• Improves team
coordination
• Maintains software
quality

Q72. Define Software Project Scheduling. Draw a simple Gantt Chart.

Software Project
Scheduling is the
process of planning
and organizing
project activities,
resources, and
timelines to
complete the
software project
within the specified
time.
Key Activities:
→Identify tasks
→Estimate effort
and duration
→Assign resources
→Set task
dependencies
→Prepare project
schedule
Q73. Explain the role of Quality Assurance in software project management.
Quality Assurance (QA) is a process that ensures the software is developed according to standards
and meets customer requirements.
Roles of QA:
• Ensures software meets requirements.
• Prevents defects and errors.
• Monitors development processes.
• Improves software quality and reliability.
• Reduces development and maintenance costs.
• Increases customer satisfaction.
• Ensures compliance with standards and procedures.
• Conducts reviews and audits regularly.
• Helps deliver the project on time.
• Reduces project risks and failures.
• Promotes continuous process improvement.
• Improves team productivity and efficiency.

Q74. How does project monitoring help control software risks?

Project monitoring is the process of regularly tracking the progress of a software project to ensure
that it is moving according to the plan. It helps identify problems and risks at an early stage so that
corrective actions can be taken before they become serious.
How project monitoring controls risks:
• Detects delays in project activities early.
• Identifies technical and resource-related problems.
• Tracks project cost and schedule performance.
• Helps managers take corrective actions on time.
• Reduces the chances of project failure.
• Ensures that project goals and quality standards are achieved.
• Monitors changes in requirements and their impact.
• Improves communication among team members.
• Helps manage risks related to budget, time, and quality.
• Provides regular status reports for better decision-making

Q75. What is UML? Why is it used?

UML (Unified Modelling Language) is a standard graphical language used to model, design, visualize,
and document software systems.
Why is UML used?
• Helps understand system requirements clearly.
• Provides a visual representation of the system.
• Improves communication among developers, designers, and users.
• Helps in software design and planning.
• Makes documentation easier.
• Reduces errors during development.
• Supports object-oriented development.
• Helps analyse system structure and behaviour.
• Simplifies complex systems.
• Improves project management and coordination.
• Helps detect design problems early.
• Saves development time and cost.
• Makes system maintenance easier.
• Provides a common standard for software modelling.
Q76. Define Class Diagram and State Chart Diagram.
Class Diagram:
A Class Diagram is a UML diagram that shows the classes of a system, their attributes, methods, and
relationships with other classes.
State Chart Diagram:
A State Chart Diagram is a UML diagram that shows the different states of an object and the
transitions from one state to another based on events.

Class Diagram State Chart Diagram

Shows structure of a system Shows behaviour of an object
Contains classes, attributes, methods Contains states and transitions
Static diagram Dynamic diagram

Q77. Draw Sequence Diagram for Online Shopping System.

Q78. What is the difference between Static Model and Dynamic Model?
Static Model Dynamic Model
Shows the structure of the system. Shows the behaviour of the system.
Describes classes, objects, and relationships. Describes states, events, and interactions.
Does not show changes over time. Shows changes over time.
Represents a fixed view of the system. Represents the working of the system.
Used for system design and organization. Used for understanding system behaviour.
Easier to create and understand. More detailed and interactive.
Focuses on data and relationships. Focuses on activities and processes.
Helps in planning the system structure. Helps in analysing system operations.
Q79. Draw Activity Diagram for Railway Reservation System.

Q80. Compare Collaboration Diagram and Sequence Diagram.

Collaboration Diagram Sequence Diagram
Shows interaction among objects. Shows interaction among objects in time order.
Focuses on relationships between objects. Focuses on sequence of messages.
Time sequence is shown by message numbers. Time sequence is shown from top to bottom.
Easier to understand object links. Easier to understand process flow.
Uses objects and connecting links. Uses lifelines and messages.
More compact diagram. More detailed diagram.
Emphasizes structural organization. Emphasizes behavioral flow.
Suitable for showing object collaboration. Suitable for showing step-by-step execution.
UML Interaction Diagram. UML Interaction Diagram.
Q81. Explain Spiral Model with neat diagram. Mention its merits and demerits.

The Spiral Model is a software development model that combines design, development, testing,
and risk analysis in repeated cycles (spirals). Each cycle improves the product and reduces risks.

Merits (Advantages)
→Suitable for large and
complex projects.
→Identifies risks early.
→Easy to accommodate
changes.
→Continuous customer
feedback.
→Improves software
quality.

Demerits
(Disadvantages)
→Costly and time-
consuming.
→Requires risk analysis
expertise.
→Not suitable for small
projects.
→Management is more
complex.

Q82. Discuss Feasibility Analysis. Explain Technical, Economic and Operational feasibility.

Feasibility Analysis is the process of checking whether a proposed software project is practical,
achievable, and beneficial before development starts.
Types of Feasibility
1. Technical Feasibility
Checks whether the required technology, hardware, software, and technical skills are available to
develop the project.
Example: Whether the team has the knowledge to build a mobile banking app.
2. Economic Feasibility
Checks whether the benefits of the project are greater than its costs.
Example: If developing software costs ₹5 lakh and saves ₹10 lakh, the project is economically
feasible.
3. Operational Feasibility
Checks whether the system will work properly in the organization and be accepted by users.
Example: Whether employees can easily use the new software system.
Importance
• Reduces project risk.
• Saves time and money.
• Helps in decision-making.
• Ensures project success.
Q84. Compare SDLC models (Waterfall, Spiral, Incremental). Select the best model for banking
software and justify.

Feature Waterfall Model Spiral Model Incremental Model

Development Style Sequential Risk-driven iterative Incremental releases
Flexibility Low High High
Risk Handling Poor Excellent Moderate
Customer Feedback Limited Continuous Regular
Cost Low High Moderate
Suitable For Small projects Large, risky projects Medium to large projects
Changes During Development Difficult Easy Easy
Best Model for Banking Software: Spiral Model
Justification:
• Banking software handles sensitive financial data.
• It requires high security and reliability.
• Risks can be identified and managed early.
• Continuous testing improves quality.
• Customer and stakeholder feedback can be incorporated.
• Suitable for large and complex systems.
Banking Software
|
Spiral Model
|
---------------------------------
| | |
Risk Security Quality
Analysis Management Improvement

Q85. Draw a Context Diagram and Level-1 DFD for Library Management System. Explain each
component.
External Entities
• Student – Requests and receives books.
• Display of Book – Shows book details.
Processes
• 1.0 Delivery of Book – Processes requests and issues books.
• 2.0 Search by Topic – Finds books based on a topic.
Data Stores
• Book Shelves – Stores available books.
• List of Authors – Stores author names.
• List of Titles – Stores book titles.
• List of Topics – Stores book categories/topics.
Data Flows
• Book Request – Request for a book.
• Library Card – Student identification.
• Book – Book issued to the student.
• Topic – Subject used for searching.
• Book Request (By Topic) – Request for books on a topic.
• Book (Based on Topic) – Search result books.
• Demanded Book Info – Details of the requested book sent for display.

Q87. Explain structured programming and object-oriented programming. Compare both with
examples.
Structured Programming Object-Oriented Programming (OOP)
Definition: Structured Programming is a
Definition: OOP is a programming approach that
programming approach that organizes a program
organizes a program into objects and classes that
into functions or procedures and follows a top-
contain both data and methods.
down design.
Features:
Features:
• Uses classes and objects.
• Uses functions/modules.
• Focuses on data and its security.
• Focuses on procedures and algorithms.
• Supports encapsulation, inheritance, and
• Data and functions are separate.
polymorphism.
• Easier for small programs.
• Suitable for large and complex programs.
Example (C):
void display() { Example (Java):
printf("Hello"); class Student {
} String name;
void display() {
int main() { [Link](name);
display(); }
return 0; }
}

Structured Programming Object-Oriented Programming

Function-oriented Object-oriented
Data and functions are separate Data and methods are combined
Follows top-down approach Follows bottom-up approach
Less secure, Suitable for small projects More secure through encapsulation, Suitable for large projects
Q89. Prepare test cases for ATM withdrawal module and explain testing strategy.
Test Case
Test Scenario Input/Condition Expected Result
ID
Balance ₹10,000, withdraw Cash dispensed, balance
TC01 Valid withdrawal
₹2,000 updated
Balance ₹1,000, withdraw Transaction rejected with
TC02 Insufficient balance
₹2,000 error message
TC03 Invalid PIN Wrong PIN entered Access denied
Withdraw amount exceeds
TC04 Exceed daily limit Transaction rejected
daily limit
Negative or zero amount
TC05 Invalid amount Error message displayed
entered
Amount not multiple of
TC06 Withdraw ₹125 Transaction rejected
denomination
TC07 ATM out of cash ATM cash unavailable Error message displayed
TC08 Cancel transaction User presses Cancel Transaction terminated
TC09 Card expired Expired ATM card used Transaction rejected
Successful withdrawal Withdraw ₹1,000 from New balance shown as
TC10
updates balance ₹5,000 ₹4,000

Testing Type Purpose

Test individual functions such as PIN validation and balance
Unit Testing
checking.
Integration Testing Verify interaction between ATM, bank server, and database.
System Testing Test the complete ATM withdrawal process end-to-end.
Security Testing Ensure PIN and account data are protected.
Performance Testing Check system response under heavy transaction load.
User Acceptance Testing
Confirm the system meets user requirements.
(UAT)

Q90. Explain Information Hiding and Reusability concepts. How do these improve software quality?
Analyse with examples.

Hides internal implementation details

Enables existing code to be used again in
Definition and allows access only through
different programs or modules.
controlled methods.

Protects data from unauthorized access Reduces the need to write the same code
Purpose
or modification. repeatedly.

Data security and controlled

Main Idea Code reuse and efficiency.
access.

Improves security, reliability, and Saves time, reduces errors, and increases
Benefits
maintainability. productivity.
Information Hiding:
class Account {
private double balance;

public void deposit(double amount) {

balance += amount;
}
}
The balance variable is hidden and can only be changed through methods.

Reusability:
class Calculator {
int add(int a, int b) {
return a + b;
}
}
The Calculator class can be reused in many programs.

Q91. Explain staffing and software configuration management in project management.

Staffing is the process of selecting, assigning, and managing people for a software project. It ensures
that the project has the right number of skilled team members to complete the work successfully.
Activities involved in staffing:
• Recruiting employees.
• Assigning roles and responsibilities.
• Training team members.
• Monitoring performance.
• Managing the project team.
Example: In a software project, a project manager assigns programmers for coding, testers for
testing, and analysts for gathering requirements.
Importance of Staffing:
• Ensures skilled people are available.
• Improves productivity and teamwork.
• Helps complete the project on time.

Software Configuration Management (SCM) is the process of managing and controlling changes
made to software during its development. It keeps track of all software components, documents, and
versions.
Activities involved in SCM:
• Identifying software components.
• Tracking changes in code and documents.
• Managing different versions of software.
• Controlling modifications.
• Maintaining records of updates.
Example: When multiple developers work on the same project, tools like Git help track code changes
and maintain different versions of the software.
Importance of SCM:
• Prevents loss of important data.
• Helps manage software versions.
• Reduces errors and conflicts.
• Ensures consistency and reliability.
Q92. Compare PERT and CPM from the viewpoint of project risk and uncertainty handling.
PERT (Program Evaluation and Review Technique) CPM (Critical Path Method)
Used for projects with high uncertainty. Used for projects with low uncertainty.
Activity times are estimated using optimistic, most
Activity times are fixed and known.
likely, and pessimistic times.
Focuses on time and risk analysis. Focuses on time and cost optimization.
Suitable for construction and routine
Suitable for research, development, and new projects.
projects.
Less effective in handling uncertain
Helps in handling project risks more effectively.
situations.
Deterministic approach (uses exact
Probabilistic approach (uses probability).
values).
Useful when project activities are well-
Useful when project duration is difficult to predict.
defined.

Q93. Draw and explain UML Class Diagram for Student Management System.

The UML Class Diagram shows the main classes and their relationships in a Student Management
System.
• Person is the parent class containing common details like name, email, and phone.
• Student and Teacher inherit properties from Person.
• Student stores student information and can enroll in or drop courses.
• Teacher manages and teaches courses.
• Course represents subjects offered by the institution.
• Department groups multiple courses.
• Enrollment links Students and Courses and stores enrollment details.
• Grade stores marks and grades obtained by students.
Relationships:
• Student and Teacher inherit from Person.
• A Teacher teaches one or more Courses.
• A Department contains many Courses.
• Students enroll in Courses through Enrollment.
• Grades are associated with Enrollments.

Q94. Draw Sequence Diagram and Activity Diagram for Library management System. Explain message
flow.

Message Flow (Sequence Diagram) –

Member logs in through the Library Interface.
1. Library System authenticates the user with the Database.
2. After successful login, the Member searches for a book.
3. The Library System retrieves book details from the Database and displays them.
4. The Member requests to issue a book.
5. The Library System checks availability of the book in the Database.
6. If available:
o Issue record is created.
o Database is updated.
o Issue success message and details are shown to the Member.
7. If not available:
o The Member receives a "Book Not Available" message.
Flow Summary:
Login → Search Book → Check Availability → Issue Book → Update Database → Show Result.
Q95. Compare Static Model and Dynamic Model. Explain State Chart, Collaboration and
Implementation diagrams with examples.

Static Model Dynamic Model

Describes the structure of a system. Describes the behavior of a system.
Shows classes, objects, and relationships. Shows interactions, states, and activities.
Focuses on what the system contains. Focuses on how the system works.
Does not consider time. Considers sequence and time.
Example: Class Diagram. Example: Sequence Diagram, State Chart Diagram.

1. State Chart Diagram

A State Chart Diagram shows the different states of an object and the transitions between them
during its life cycle.
Example: Library Book
Available → Issued → Returned → Available
• Available: Book is in the library.
• Issued: Book is borrowed by a member.
• Returned: Book is returned and becomes available again.
Use: Helps model object behaviour based on events.

2. Collaboration Diagram
A Collaboration Diagram (Communication Diagram) shows how objects interact with each other to
complete a task.
Example: Book Issue Process
Member → Library System → Database
1. Member requests a book.
2. Library System checks availability.
3. Database returns status.
4. Library System issues the book.
5. Member receives confirmation.
Use: Shows object interactions and message exchange.

3. Implementation Diagram
An Implementation Diagram shows the physical implementation of software components and
hardware.
Types:
• Component Diagram
• Deployment Diagram
Example: Library Management System
• Client Computer
• Library Application
• Database Server
Flow:
Client Computer → Library Application → Database Server
Use: Shows how software components are deployed and connected in the real environment.
Q96. Explain the phases of SDLC with a neat diagram.

Q97. Describe the Waterfall model. What are its advantages and limitations?

The Waterfall Model is a traditional SDLC model in which software development progresses through
a series of sequential phases. Each phase must be completed before moving to the next phase.

Explanation of Phases
1. Requirement Analysis – Gather and analyze user requirements.
2. System Design – Prepare system architecture and design.
3. Implementation – Develop the software through coding.
4. Testing – Check for errors and verify requirements.
5. Deployment – Deliver the software to users.
6. Maintenance – Fix bugs and make improvements after release.
Advantages
• Simple and easy to understand.
• Well-structured with clear phases.
• Easy to manage and document.
• Suitable for small projects with fixed requirements.
• Progress can be measured easily.
Limitations
• Difficult to accommodate changes once development starts.
• Testing is done only after coding is completed.
• Not suitable for large or complex projects.
• Errors found late can be costly to fix.
• Customer feedback is limited during development.
Q98. What is feasibility analysis? Explain the different types of feasibility.

Feasibility Analysis is the process of evaluating whether a proposed software project is practical,
achievable, and worth developing before investing time and resources.
It helps organizations determine if the project can be completed successfully and meet its objectives.
Types of Feasibility
1. Technical Feasibility
• Checks whether the required technology, hardware, software, and technical expertise are
available.
• Determines if the system can be developed with existing resources.
Example: Assessing whether a company has the tools and skills to develop a mobile application.
2. Economic Feasibility
• Evaluates the cost and benefits of the project.
• Determines whether the project is financially worthwhile.
Example: Comparing development costs with the expected profits or savings.
3. Operational Feasibility
• Examines whether the proposed system will work effectively in the organization.
• Checks user acceptance and operational requirements.
Example: Determining whether employees can easily adapt to a new management system.
4. Schedule Feasibility
• Determines whether the project can be completed within the given time frame.
• Evaluates deadlines and resource availability.
Example: Checking if a software project can be delivered within six months.
5. Legal Feasibility
• Ensures the project complies with laws, regulations, and organizational policies.
Example: Verifying that a system follows data protection and copyright laws.

Q99. What is a Data Flow Diagram (DFD)? Draw a Level-0 DFD for a library management system.
A Data Flow Diagram (DFD) is a graphical representation of how data moves through a system. It
shows the input, processing, storage, and output of data within a system. DFDs help analysts and
developers understand how information flows between users, processes, and data stores.
Q101. What is UML? List and briefly describe any four UML diagrams.

UML (Unified Modelling Language) is a standard graphical language used to visualize, design,
document, and model software systems. It helps developers understand the structure and behaviour
of a system before implementation.
Four UML Diagrams
1. Class Diagram
• Shows classes, attributes, methods, and relationships.
• Represents the static structure of a system.
Example: Student, Teacher, and Course classes in a Student Management System.
2. Use Case Diagram
• Shows interactions between users (actors) and the system.
• Describes the system's functional requirements.
Example: A student can Login, Register, and View Results.
3. Sequence Diagram
• Shows the sequence of messages exchanged between objects over time.
• Represents the flow of activities in a process.
Example: User Login → System Verification → Database Check → Login Success.
4. Activity Diagram
• Shows the workflow or sequence of activities in a process.
• Similar to a flowchart.
Example: Login → Search Book → Check Availability → Issue Book → Logout.

Q102. Explain project scheduling. What factors are considered while scheduling a software
project?

Project Scheduling is the process of planning and organizing project activities, resources, and
timelines to ensure that a software project is completed within the specified time and budget.
It helps managers allocate resources, monitor progress, and meet project deadlines efficiently.

Factors Considered in Software Project Scheduling

1. Project Size and Complexity
o Larger and more complex projects require more time and resources.
2. Resource Availability
o Availability of developers, testers, tools, and hardware affects scheduling.
3. Project Requirements
o Clear and stable requirements help create accurate schedules.
4. Task Dependencies
o Some tasks must be completed before others can begin.
5. Estimated Effort
o Time required to complete each activity is estimated.
6. Team Skills and Experience
o Experienced team members can complete tasks faster and more efficiently.
7. Project Risks
o Potential risks such as technical issues or requirement changes must be considered.
8. Budget Constraints
o Available budget may affect resource allocation and project duration.
9. Deadlines and Milestones
o Important delivery dates and checkpoints influence the schedule.
10. Testing and Maintenance Time
o Adequate time must be allocated for testing, debugging, and maintenance.
Q103. What is structured programming? How does it differ from object-oriented programming?

Structured Programming is a programming approach that divides a program into smaller functions or
modules. It uses control structures such as sequence, selection (if-else), and iteration (loops) to
solve problems in a systematic way.
Example Languages: C, Pascal

Features of Structured Programming

• Program is divided into functions/modules.
• Follows a top-down approach.
• Focuses on procedures and functions.
• Easier to understand and debug than unstructured programs.

Difference Between Structured Programming and Object-Oriented Programming (OOP)

Structured Programming Object-Oriented Programming (OOP)
Focuses on functions and procedures. Focuses on objects and classes.
Uses a top-down approach. Uses a bottom-up approach.
Data and functions are separate. Data and functions are combined into objects.
Provides limited data security. Supports data hiding through encapsulation.
Less suitable for large projects. Suitable for large and complex projects.
Example: C, Pascal Example: Java, C++, Python

Q104. Describe the concept of software documentation. Why is it important.

Software Documentation
Software Documentation is the collection of written documents that describe the development,
design, operation, testing, and maintenance of a software system.
It provides detailed information about the software for developers, testers, users, and maintenance
teams.

Types of Software Documentation

1. System Documentation
o Describes system design, architecture, requirements, and technical details.
o Used by developers and maintenance teams.
2. User Documentation
o Provides instructions for end users.
o Includes user manuals, installation guides, and help files.

Importance of Software Documentation

• Helps understand the software system easily.
• Acts as a reference for developers and users.
• Simplifies maintenance and future updates.
• Improves communication among team members.
• Assists in testing and debugging.
• Reduces training time for new team members.
• Ensures continuity even when team members change.
Q105. Explain the purpose of a decision table. Give a simple example.
A Decision Table is a tabular technique used to represent and analyse complex decision-making
situations. It shows different conditions and the corresponding actions to be taken for each
combination of conditions.
It helps ensure that all possible cases are considered during system analysis, design, and testing.
Purpose of a Decision Table
• Represents decision logic in a simple and clear format.
• Handles multiple conditions effectively.
• Helps identify missing or inconsistent rules.
• Useful for designing test cases and business rules.
• Improves accuracy in decision-making.
Simple Example: ATM Cash Withdrawal
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Valid Card? Yes Yes No No
Sufficient Balance? Yes No Yes No
Action Allow Withdrawal Display "Insufficient Balance" Reject Card Reject Card

Q106. What is software quality? List any four software quality attributes.
Software Quality
Software Quality refers to the degree to which a software product meets specified requirements and
satisfies user needs. A high-quality software system is reliable, efficient, easy to use, and performs its
intended functions correctly.
Four Software Quality Attributes
1. Reliability
o The ability of software to perform correctly without failures for a specified period.
2. Efficiency
o The ability to use system resources such as memory, CPU, and time effectively.
3. Usability
o The ease with which users can learn, operate, and understand the software.
4. Maintainability
o The ease of modifying, correcting, or updating the software after deployment.

Q107. What is a context diagram? How is it different from a Level-1 DFD?

A Context Diagram is the highest-level DFD (also called Level-0 DFD) that represents the entire
system as a single process and shows its interaction with external entities.
It provides an overview of the system boundaries and the flow of data between the system and
external users.
Example: In a Library Management System, the main process "Library Management System"
interacts with entities such as Member and Librarian.

Difference Between Context Diagram and Level-1 DFD

Context Diagram (Level-0 DFD) Level-1 DFD
Breaks the main process into multiple sub-
Shows the entire system as a single process.
processes.
Provides a high-level overview. Provides more detailed information.
Does not show internal processes or data stores. Shows internal processes and data stores.
Focuses on system boundaries and external
Focuses on data flow within the system.
entities.
Simple and easy to understand. More detailed and complex.
Q108. Compare the Waterfall model and the Spiral model. When would you choose one over the
other?
Difference Between Waterfall Model and Spiral Model
Waterfall Model Spiral Model
Linear and sequential development process. Iterative and risk-driven development process.
Each phase is completed before the next begins. Development occurs in repeated cycles (spirals).
Requirements must be clearly defined at the
Requirements can evolve during development.
beginning.
Customer involvement is limited after requirements
Customer feedback is obtained at every iteration.
gathering.
Risk analysis is minimal. Strong focus on risk analysis and management.
Simpler and easier to implement. More complex and costly to manage.
Suitable for small and medium projects. Suitable for large, complex, and high-risk projects.
When to Choose Waterfall Model?
Choose the Waterfall Model when:
• Requirements are clear and stable.
• Project size is small or medium.
• Technology is well understood.
• Minimal changes are expected during development.
Example: Payroll Management System, Library Management System.
When to Choose Spiral Model?
Choose the Spiral Model when:
• Project is large and complex.
• Requirements may change frequently.
• Risk analysis is important.
• Continuous customer feedback is required.
Example: Banking Systems, Air Traffic Control Systems, Large E-commerce Platforms.

Q109. Explain the COCOMO model. What are its three modes of software development?
COCOMO (Constructive Cost Model) is a software cost estimation model developed by Barry Boehm.
It is used to estimate the effort, development time, and cost required to develop a software project.
Purpose of COCOMO
• Estimates project effort.
• Predicts development time.
• Calculates project cost.
• Helps in project planning and scheduling.
Three Modes of Software Development
1. Organic Mode
• Small and simple projects.
• Team has good experience.
• Requirements are well understood.
• Few constraints.
2. Semi-Detached Mode
• Medium-sized projects.
• Team has mixed experience levels.
• Project complexity is moderate.
3. Embedded Mode
• Large and complex projects.
• Strict hardware, software, or regulatory constraints.
• High reliability and performance requirements.
Q110. Explain the different levels of testing: unit, integration, system, and acceptance
testing.
Software testing is performed at different levels to ensure that the software works correctly and
meets user requirements.
1. Unit Testing
• Tests individual modules, functions, or components of a program.
• Usually performed by developers.
• Ensures that each unit works correctly in isolation.
Example: Testing a login function to verify that it accepts valid usernames and passwords.
2. Integration Testing
• Tests the interaction between two or more modules.
• Ensures that integrated components communicate correctly.
Example: Testing whether the Login Module correctly connects with the Database Module.
3. System Testing
• Tests the complete software system as a whole.
• Verifies that all requirements are met.
• Performed after integration testing.
Example: Testing the entire Library Management System, including login, book issue, return, and
report generation.
4. Acceptance Testing
• Final level of testing performed by the customer or end users.
• Checks whether the system satisfies business requirements and is ready for deployment.
Example: Library staff testing the system before it is officially used in the library.

Q111. Describe software configuration management (SCM). What are its main activities?
Software Configuration Management (SCM) is the process of managing, tracking, and controlling
changes made to software during its development and maintenance.
It ensures that the correct versions of software and documents are used throughout the project.
Main Activities of SCM
1. Configuration Identification
o Identifies software components such as source code, design documents, and test
files.
2. Version Control
o Maintains different versions of software and tracks modifications.
3. Change Control
o Reviews, approves, and implements requested changes.
4. Status Accounting
o Records and reports the status of software components and changes.
5. Configuration Auditing
o Verifies that software follows standards and approved changes.
6. Build and Release Management
o Combines software components and prepares releases for users.
Importance of SCM
• Controls software changes effectively.
• Prevents loss of important files and code.
• Maintains version history.
• Improves software quality and reliability.
• Helps developers work together smoothly.
• Reduces errors and duplication of work.
• Makes maintenance and updates easier.
• Ensures consistency throughout the project.
Q112. Explain the sequence diagram with an example. How does it differ from a collaboration
diagram?
A Sequence Diagram is a UML behavioral diagram that shows the order of messages exchanged
between objects over time to perform a specific task.
It focuses on when messages are sent and received.
Example: Library Book Issue Process

Explanation
1. Member requests a book.
2. Library System checks book availability in the database.
3. Database returns the status.
4. Library System issues the book and sends confirmation to the member.

Difference Between Sequence Diagram and Collaboration Diagram

Sequence Diagram Collaboration Diagram
Shows interactions in time order. Shows interactions among objects and their relationships.
Focuses on the sequence of messages. Focuses on object collaboration.
Time flow is represented vertically. Uses numbered messages to show order.
Easier to understand the process flow. Easier to understand object relationships.
Example: Login process, Book issue Example: Interaction between Member, Library System, and
process. Database.

Q113. What is software risk? Describe the steps in the risk management process.
Software Risk is the possibility of an event that may negatively affect the success of a software
project. Risks can cause delays, increased costs, poor quality, or project failure.
Examples:
• Requirement changes
• Lack of skilled staff
• Technical problems
• Schedule delays
Steps in the Risk Management Process
1. Risk Identification
• Identify possible risks that may affect the project.
• Example: shortage of developers or changing requirements.
2. Risk Analysis
• Analyse the likelihood and impact of each risk.
 • Determine which risks are most serious.
3. Risk Prioritization
• Rank risks according to their importance and impact.
• Focus on high-priority risks first.
4. Risk Planning
• Develop strategies to avoid, reduce, or handle risks.
• Prepare contingency plans.
5. Risk Monitoring
• Continuously track identified risks throughout the project.
• Detect new risks as they arise.
6. Risk Control
• Take corrective actions when risks occur.
• Implement the planned risk response.

Q114. Explain functional vs object-oriented design approaches. What are the key differences?
The Functional Design Approach focuses on the functions or processes performed by the system.
The system is divided into smaller functions, and each function performs a specific task.
Example: In a Library System, separate functions are created for Issue Book, Return Book, and Search
Book.
The Object-Oriented Design Approach focuses on objects and classes that contain both data and
methods. Objects interact with each other to perform tasks.
Example: Classes such as Book, Member, and Library are created, each having its own data and
functions.
Key Differences
Functional Design Object-Oriented Design
Focuses on functions and processes. Focuses on objects and classes.
Data and functions are separate. Data and functions are combined in objects.
Uses a top-down approach. Uses a bottom-up approach.
Reusability is limited. Supports high reusability through inheritance.
Less suitable for large systems. Suitable for large and complex systems.
Easier for small applications. Easier to maintain and extend.

115. What is quality assurance? How is it different from quality control in software projects?
Quality Assurance (QA) is a process-oriented activity that ensures proper methods, standards, and
procedures are followed during software development to prevent defects.
Its goal is to improve the development process and produce high-quality software.
Examples:
• Defining development standards.
• Conducting process reviews.
• Following coding guidelines.
Difference Between Quality Assurance and Quality Control
Quality Assurance (QA) Quality Control (QC)
Focuses on improving the development process. Focuses on checking the final product.
Prevents defects from occurring. Detects defects after development.
Process-oriented. Product-oriented.
Performed throughout development. Performed during testing and review.
Ensures correct procedures are followed. Ensures the software meets requirements.
Example: Code standards, process audits. Example: Testing, bug detection.
Q116. Draw a Level-1 DFD for an online shopping system. Identify the major processes and data
stores.

Major Processes:
1. Browse Products
2. Manage Order
3. Process Payment
4. Delivery Management
Data Stores:
1. Products Database
2. Orders Database
3. Payments Database
External Entities (optional):
• Customer
• Payment Gateway
• Delivery Agent
Purpose:
Processes perform the system activities, while data stores keep the information required by the
system.

Q117. Explain cost-benefit analysis in software projects. How is it used to justify project investment?
Cost-Benefit Analysis is a technique used to compare the expected costs of a software project with
its expected benefits. It helps determine whether the project is financially worthwhile.
If the benefits are greater than the costs, the project is considered feasible and worth investing in.
Costs in a Software Project
• Development costs (hardware, software, tools).
• Employee salaries and training costs.
• Testing and maintenance costs.
• Deployment and operational costs.
Benefits of a Software Project
 • Increased productivity and efficiency.
• Reduced operating costs.
• Improved customer service.
• Higher profits and business growth.
• Better data management and decision-making.
How It Justifies Project Investment
1. Estimate all project costs.
2. Estimate the expected benefits.
3. Compare costs with benefits.
4. If benefits exceed costs, the project is approved.
5. Helps management make informed investment decisions.
Example
• Project Cost: ₹5,00,000
• Expected Benefit: ₹8,00,000
Since the benefit is greater than the cost, the project is considered a good investment.

Q118. Explain software reliability assessment. What metrics are used to measure software reliability?

Software Reliability Assessment

Software Reliability Assessment is the process of evaluating how reliably a software system
performs its required functions without failure for a specified period under given conditions.

It helps determine the quality, dependability, and performance of software.

Importance of Reliability Assessment
• Improves software quality.
• Reduces system failures.
• Increases user confidence.
• Helps identify and fix defects.
• Ensures smooth system operation.
Metrics Used to Measure Software Reliability
1. Mean Time Between Failures (MTBF)
• Average time between two consecutive failures.
• Higher MTBF indicates better reliability.
2. Mean Time To Failure (MTTF)
• Average operating time before a failure occurs.
• Commonly used for non-repairable systems.
3. Mean Time To Repair (MTTR)
• Average time required to fix a failure and restore the system.
• Lower MTTR indicates better maintainability.
4. Failure Rate
• Number of failures occurring in a given time period.
• Lower failure rate means higher reliability.
5. Probability of Failure on Demand (POFOD)
• Probability that the system fails when a service is requested.
• Used in safety-critical systems.
6. Availability
• Percentage of time the software is operational and available for use.
• Higher availability indicates greater reliability.
Q119. Describe the concept of cohesion and coupling in software design. Why are high cohesion and
low coupling desirable?

Cohesion refers to the degree to which the elements within a module are related to each other and
work together to perform a single task.
• High Cohesion means a module focuses on one specific function.
• Makes the module easier to understand, maintain, and reuse.
Example: A Login Module that handles only user authentication.
Coupling
Coupling refers to the degree of dependency between different modules.
• Low Coupling means modules are independent and interact minimally.
• Changes in one module have little effect on other modules.
Example: The Login Module works independently from the Payment Module.
Difference Between Cohesion and Coupling
Cohesion Coupling
Measures the relationship within a module. Measures the dependency between modules.
High cohesion is desirable. Low coupling is desirable.
Focuses on a single responsibility. Focuses on module independence.
Why are High Cohesion and Low Coupling Desirable?
• Easier maintenance and debugging.
• Improves code readability.
• Increases software reliability.
• Makes testing simpler.
• Enhances reusability of modules.
• Reduces the impact of changes in the system.

Q120. Explain software quality standards (ISO 9001 or CMM). How do they help in delivering quality
software?

Software Quality Standards are guidelines and practices that help organizations develop high-quality
software in a systematic and controlled manner.
Two commonly used quality standards are ISO 9001 and CMM (Capability Maturity Model).
1. ISO 9001
• An international standard for quality management systems.
• Focuses on improving processes and customer satisfaction.
• Ensures that organizations follow documented procedures and quality practices.
2. CMM (Capability Maturity Model)
• A framework used to assess and improve software development processes.
• Defines different maturity levels of an organization's processes.
CMM Levels:
1. Initial → [Link] → 3. Defined → 4. Managed → 5. Optimizing
Higher levels indicate better process control and quality.
How They Help in Delivering Quality Software
• Improve software development processes.
• Reduce errors and defects.
• Ensure consistent quality.
• Increase customer satisfaction.
• Improve project management and control.
• Enhance productivity and efficiency.
• Support continuous process improvement.
Q121. Explain the major SDLC models (Waterfall, Spiral, and Incremental) in detail, including their
diagrams, advantages, and disadvantages.
1. Waterfall Model
The Waterfall Model is a linear and sequential SDLC model in which each phase is completed before
the next phase begins.
Diagram
Requirements → Design → Implementation (Coding) → Testing → Deployment → Maintenance
Advantages
• Simple and easy to understand.
• Easy to manage and document.
• Suitable for small projects with fixed requirements.
• Clear project milestones.
Disadvantages
• Difficult to make changes once development starts.
• Testing occurs late in the process.
• Not suitable for large or complex projects.
• Customer feedback is limited.
2. Spiral Model
The Spiral Model combines iterative development with risk analysis. Development proceeds through
repeated cycles (spirals). (Draw diagram)
Advantages
• Strong risk management.
• Accommodates changing requirements.
• Continuous customer feedback.
• Suitable for large and complex projects.
Disadvantages
• More expensive than other models.
• Complex to manage.
• Requires expertise in risk analysis.
• Not suitable for small projects.
3. Incremental Model
In the Incremental Model, the software is developed and delivered in small parts (increments). Each
increment adds new functionality.
Diagram
Requirements
↓
Increment 1 → Basic System
↓
Increment 2 → Additional Features
↓
Increment 3 → Final System
Advantages
• Early delivery of working software.
• Easier to accommodate changes.
• Lower risk compared to Waterfall.
• Customer feedback can be incorporated in each increment.
Disadvantages
• Requires careful planning and design.
• Integration of increments can be challenging.
• Overall cost may increase.
• Not suitable when the system cannot be divided into modules.
Q122. What is feasibility analysis? Describe technical, economic, operational, and schedule feasibility
with examples.

Feasibility analysis is the study done before starting a software project to check whether it is practical
and worth developing.
It has four types:
1. Technical Feasibility:
Checks whether the required technology and skills are available.
Example: Building a face recognition system is feasible if AI tools and skilled developers are available.
2. Economic Feasibility:
Checks whether the project is cost-effective and benefits are more than cost.
Example: If a system saves more money than its development cost, it is feasible.
3. Operational Feasibility:
Checks whether users will accept and use the system easily.
Example: A new hospital software is feasible if staff can use it comfortably.
4. Schedule Feasibility:
Checks whether the project can be completed within the given time.
Example: If an app cannot be built before a deadline, it is not feasible.
Conclusion:
Feasibility analysis helps decide whether a project should be started or not.

Q123. Explain system design using DFD. Draw Level-0 and Level-1 DFDs for a student result
management system.
System design using DFD is a method of representing how data moves through a system. It shows
inputs, processes, outputs, and data storage in a graphical form, helping to understand and design
the system clearly.
What is a DFD?
A Data Flow Diagram (DFD) is a visual representation of the flow of data in a system. It explains:
• From where data comes
• How it is processed
• Where it is stored
• Where it goes as output
Q126. Explain software project management. Discuss project scheduling, staffing, and monitoring
techniques.
Software Project Management is the process of planning, organizing, scheduling, and controlling a
software project to complete it on time, within budget, and with the required quality.
1. Project Scheduling
• Planning project tasks and activities.
• Estimating time required for each task.
• Assigning resources and setting deadlines.
• Helps track project progress.
• Tools: Gantt Chart, PERT Chart, CPM.
2. Project Staffing
• Selecting suitable team members.
• Assigning roles and responsibilities.
• Providing training when required.
• Maintaining coordination among team members.
• Ensures effective use of human resources.
3. Project Monitoring
• Tracking project progress regularly.
• Comparing actual progress with planned progress.
• Identifying risks and delays.
• Taking corrective actions when needed.
• Techniques: Progress Reports, Status Meetings, Milestone Reviews.
Importance of SPM
• Ensures timely project completion.
• Controls project cost.
• Improves software quality.
• Enhances team coordination.
• Reduces project risks.

Q 128. Explain the Spiral model in detail with its diagram. What are the four quadrants? Discuss its
advantages and suitability for large projects.
The Spiral Model is a software development model that combines the features of the Waterfall
Model and Prototyping Model. It follows a spiral path, where each cycle focuses on planning, risk
analysis, development, and evaluation

Four Quadrants of Spiral Model

1. Planning
• Gather requirements.
• Define objectives and constraints.
• Estimate cost and schedule.
2. Risk Analysis
• Identify and analyze risks.
• Evaluate alternative solutions.
• Reduce project risks.
3. Engineering
• Design, code, and test the software.
• Develop the next version of the product.
4. Customer Evaluation
• Customer reviews the developed product.
• Feedback is collected for the next cycle.
Suitability for Large Projects
The Spiral Model is ideal for large, complex, and high-risk projects because:
• Risks are identified early.
• Changes can be handled easily.
• Continuous customer feedback improves the product.
• Development is done in stages, reducing project failure chances.

(2) Risk Analysis

↑
|
|
(1) Planning ---------+--------- (3) Engineering
|
|
↓
(4) Customer Evaluation

Each loop of the spiral = One development phase

[Link] the software project management lifecycle. Explain cost estimation using
the COCOMO model with a numeric example.

The Software Project Management Lifecycle consists of the following phases:

1. Project Initiation
• Define project objectives and scope.
• Identify feasibility and requirements.
2. Project Planning
• Estimate cost, effort, and time.
• Prepare schedules and allocate resources.
3. Project Execution
• Develop the software according to the plan.
• Coordinate team activities.
4. Project Monitoring and Control
• Track progress and performance.
• Identify risks and take corrective actions.
5. Project Closure
• Deliver the final product.
• Prepare documentation and review project outcomes.

Cost Estimation using COCOMO Model

COCOMO (Constructive Cost Model) is used to estimate the effort, cost, and development time of a
software project.
Basic COCOMO Formula
For Organic Projects:
𝐸𝑓𝑓𝑜𝑟𝑡 = 2.4 × (𝐾𝐿𝑂𝐶)1.05
Where:
• Effort = Person-Months (PM)
• KLOC = Thousands of Lines of Code
Q130. Design a simple ATM system using UML diagrams. Draw the use-case diagram, sequence
diagram, and class diagram.

Q133. Describe the V-model and how it maps testing phases to development phases.
The V-Model is a software development model where each development phase has a matching
testing phase. It is shaped like the letter “V”.
Left side (Development / Verification)
1. Requirement Analysis
2. System Design
3. High-Level Design
4. Low-Level Design
5. Coding
Right side (Testing / Validation)
Each stage is tested after development:
• Requirement Analysis → Acceptance Testing
• System Design → System Testing
• High-Level Design → Integration Testing
• Low-Level Design → Unit Testing
 • How it works
• First the system is designed step by step.
• Then testing is planned for each step.
• After coding, testing is done in reverse order.

Example
If you build a banking system:
• Unit test checks each module (login, balance check)
• Integration test checks modules working together
• System test checks full banking system
• Acceptance test checks if users are satisfied

Q132. Discuss risk management strategies in software engineering. How are risks identified,
analysed, prioritized, and mitigated

Risk Management is the process of identifying, analysing, prioritizing, and controlling risks that may
affect a software project.

Risk Management Strategies

• Risk Avoidance – Change plans to eliminate the risk.
• Risk Reduction (Mitigation) – Take actions to reduce the probability or impact of the risk.
• Risk Transfer – Shift the risk to another party (e.g., outsourcing, insurance).
• Risk Acceptance – Accept the risk and prepare a contingency plan.
•
1. Risk Identification
Identify possible risks that may affect the project.
Examples:
Requirement changes, Budget shortage , Schedule delays , Lack of skilled staff , Technical
problems
2. Risk Analysis
Analyse the likelihood and impact of each risk.
Factors:
• Probability of occurrence
• Severity of impact
• Cost and time effects
3. Risk Prioritization
Rank risks according to their importance.
Priority Levels:
• High Risk – Needs immediate attention.
• Medium Risk – Monitor regularly.
• Low Risk – Handle if resources are available.
4. Risk Mitigation
Develop actions to reduce or control risks

Importance of Risk Management

• Reduces project failures.
• Improves project planning.
• Controls cost and schedule overruns.
• Enhances software quality.
• Increases the chances of project success.
Q134. Design a complete system for an online library management system using DFD (Level 0 and
Level 1) and UML diagrams (Use Case, Class, and Sequence). Justify your design choices.

Justification of Design Choices

• DFD Level-0 and Level-1: Clearly show system boundaries, processes, data stores, and data
flow.
• Use Case Diagram: Identifies major user interactions such as login, search, issue, return, and
payment.
• Class Diagram: Represents key entities (Book, Member, Transaction, Payment) and their
relationships.
• Sequence Diagram: Shows the step-by-step flow of issuing a book and interaction between
system components.
• Modular Design: Separates functions into independent modules, making the system easier
to maintain and expand.
Q135. Develop a comprehensive testing strategy for a hospital management system. Include test
plan, test cases, types of testing to be used, reliability metrics, and quality assurance procedures.

A Hospital Management System (HMS) manages patient records, appointments, billing, pharmacy,
and reports. Testing ensures the system is reliable, secure, and error-free.
1. Test Plan
• Define testing objectives and scope.
• Test modules: Registration, Appointments, Billing, Pharmacy, Laboratory, Login.
• Assign testers and schedule testing activities.
• Perform Unit, Integration, System, and Acceptance Testing.

2. Test Cases
Test Case Input Expected Result
Patient Registration Patient details Record created successfully
Login Valid username & password Login successful
Appointment Booking Doctor and date Appointment confirmed
Billing Treatment details Correct bill generated
Lab Report Patient ID Correct report displayed

3. Types of Testing
• Unit Testing: Tests individual modules.
• Integration Testing: Tests interaction between modules.
• System Testing: Tests the complete HMS.
• Acceptance Testing: Performed by hospital staff.
• Security Testing: Protects patient data.
• Performance Testing: Checks system under heavy load.
• Regression Testing: Verifies existing features after changes.

4. Reliability Metrics
• MTBF (Mean Time Between Failures): Higher value indicates better reliability.
• MTTR (Mean Time To Repair): Lower value is better.
• Failure Rate: Number of failures over time.
• Availability: Percentage of system uptime.

5. Quality Assurance Procedures

• Requirement Review
• Code Review
• Test Case Review
• Defect Tracking
• Documentation Verification
• User Feedback and Continuous Monitoring