1. What is So ware Engineering? Explain its characteris cs and classifica on. 2. Explain different so ware process models.

odels. (Waterfall, Prototype, RAD,

So ware Engineering is a systema c, disciplined, and quan fiable approach to the Spiral, V-Model)
development, opera on, and maintenance of so ware. It applies engineering A so ware process model is a structured framework that defines the sequence
principles to so ware development to ensure the crea on of reliable, efficient, and flow of so ware development ac vi es. These models help in planning,
and maintainable so ware systems. The main aim is to produce high-quality organizing, and managing so ware projects effec vely. Each model has its
so ware within a given me and budget. strengths and is chosen based on project requirements, complexity, and melines.
Characteris cs of So ware:
1. Intangibility – So ware is not a physical en ty; it cannot be touched or 1. Waterfall Model
seen, unlike hardware. The Waterfall model is a linear and
2. Complexity – So ware can be highly complex, involving thousands or sequen al approach where each phase
millions of lines of code. must be completed before the next
3. Scalability – It can be scaled easily to handle more users or data, but begins. Phases include Requirement
improper design can make scaling difficult. Analysis, Design, Implementa on,
4. Flexibility – So ware can be modified or upgraded more easily than Tes ng, Deployment, and Maintenance.
physical systems.
5. Maintenance – So ware requires con nuous updates and maintenance Advantages:
a er deployment.  Simple and easy to use
6. Reusability – Components or modules of so ware can o en be reused in  Phases are well defined
other applica ons.  Works well for small projects with clear requirements

Classifica on of So ware: Disadvantages:

 Difficult to accommodate changes once the process starts
1. System So ware – So ware that controls and manages computer
 Late detec on of issues since tes ng comes at the end
hardware (e.g., Opera ng Systems, Compilers).
 Not suitable for complex or dynamic projects
2. Applica on So ware – Programs developed for end users to perform
specific tasks (e.g., MS Word, web browsers).
3. Embedded So ware – So ware built into hardware devices (e.g., so ware Here's a short explana on of each phase:
in washing machines, ATMs). 1. Requirements: Collect and document what the so ware must do.
4. Web-based So ware – Applica ons accessed through browsers (e.g., 2. Design: Create the architecture and design of the system.
Google Docs, online banking systems). 3. Development: Write the actual code based on the design.
5. AI So ware – So ware designed to simulate intelligent behavior (e.g., 4. Tes ng: Test the so ware to find and fix bugs.
chatbots, recommenda on systems). 5. Deployment: Deliver the finished product to users.
6. Engineering and Scien fic So ware – So ware used for scien fic 6. Maintenance: Update and fix the so ware as needed a er release.
calcula ons, simula ons, and modeling.
 2. Prototype Model 3. Rapid Applica on Development (RAD) Model
In this model, a prototype (working model) of the so ware is developed first to RAD focuses on rapid prototyping and quick feedback from users with the use of
understand user requirements. A er user feedback, the actual system is reusable components and tools.
developed. Advantages:
Advantages:  Fast development and delivery
 Helps clarify requirements early  Encourages user involvement
 Users can interact and give feedback  Suitable for projects with well-defined func onality
 Reduces chances of requirement misunderstanding Disadvantages:
Disadvantages:  Requires skilled developers
 Time-consuming due to repeated prototyping  Not suitable for large-scale systems
 Poorly managed prototypes may become the final product  Poor design may lead to performance issues
 Increases development cost if not controlled

The diagram shows the Concurrent Development Model (or Concurrent

Here are the phases of the Prototyping Model in short: Engineering Model). Below are the phases in short:
1. Requirements Analysis – Gather basic user needs. 1. Elicit Requirements – Understand what the user needs from the system.
2. Design – Create an ini al system design. 2. Modularize Requirements – Break down requirements into manageable
3. Prototyping – Build a quick, working model of the system. modules.
4. Customer Evalua on – User tests the prototype and gives feedback. 3. Module Development (Team-wise) – Each team independently designs,
5. Review and Refine – Modify the prototype based on feedback. codes, and tests its module.
6. Develop – Build the actual full system. 4. Integrate Modules – Combine all developed modules into a single system.
7. Test – Test the final product for errors and performance. 5. Test Final Product – Perform system-level tes ng to ensure everything
8. Release – Deliver the final so ware to the user. works together.
6. Deliver – Provide the final, integrated, and tested product to the customer.
 4. Spiral Model 5. V-Model (Valida on and Verifica on Model)
The Spiral model combines itera ve development with risk analysis. It progresses It is an extension of the Waterfall model, where tes ng is planned in parallel with
in a spiral manner through repeated cycles of planning, risk analysis, engineering, development. Each development stage has a corresponding tes ng phase.
and evalua on. Advantages:
Advantages:  Early detec on of
 Excellent for large and high-risk projects defects
 Risk is managed at every itera on  Clear and structured
 Flexible to changes process
Disadvantages:  Simple to understand
 Complex to manage and use
 Expensive due to con nuous risk assessment Disadvantages:
 Requires exper se in risk analysis  Rigid and not flexible to
changes
 High dependency on
ini al requirements
 No early working
so ware available

Phases of V-Model (in short & simple):

1. Requirement Analysis
→ Understand what the user wants.
(Later verified using Acceptance Tes ng)
2. System Design
The Spiral Model has four key phases, repea ng in cycles (spirals). Here are the → Plan how the en re system will work.
phases in short:
(Tested using System Tes ng)
1. Iden fy Objec ves – Define goals, requirements, and constraints of the
3. Architecture Design
current phase. → Break system into smaller sec ons (like layers/modules).
2. Risk Analysis – Iden fy poten al risks, uncertain es, and ways to minimize
(Verified with Integra on Tes ng)
them. 4. Module Design
3. Product Development – Design, code, and implement the product
→ Design individual parts or modules of the system.
increment or prototype.
(Tested using Unit Tes ng)
4. Evalua on – Review progress, gather user feedback, and plan for the next 5. Coding
spiral.
→ Actual development or wri ng code.
3. What is CMM? Explain its levels. 4. What are the characteris cs of a good SRS (So ware Requirements
CMM (Capability Maturity Model) is a Specifica on)?
framework developed by SEI (So ware An SRS is a structured document that clearly and completely describes the
Engineering Ins tute) that helps func onal and non-func onal requirements of a so ware system before
organiza ons improve their so ware development begins.
development process in a structured and
measurable way. It defines 5 maturity Contents of SRS (Short Form)
levels through which an organiza on 1. Introduc on – Purpose, scope, defini ons, and document overview.
progresses to improve so ware quality and 2. Overall Descrip on – System environment, func ons, user details,
project management. constraints.
3. Specific Requirements – Func onal and non-func onal requirements.
Levels of CMM: 4. External Interfaces – User, hardware, so ware, and communica on
1. Ini al (Level 1) interfaces.
o No defined process; success 5. Appendices – Extra info like references or glossary.
depends on individual efforts.
o Highly chao c and unstructured environment. Characteris cs of a Good SRS:
o Project outcomes are unpredictable. 1. Correctness: All the informa on men oned in the SRS must be accurate
2. Repeatable (Level 2) and reflect the client’s needs properly.
o Basic project management processes established. 2. Unambiguous: Every requirement should have only one interpreta on.
o Past success can be repeated with similar projects. There should be no confusing terms or vague phrases.
o S ll limited standardiza on across the organiza on. 3. Complete: It should cover all possible inputs, outputs, and behaviors of the
3. Defined (Level 3) system under all scenarios.
o Organiza on-wide standards and procedures are defined. 4. Consistent: There must be no conflic ng requirements. For example, two
o Every project uses tailored versions of these defined processes. statements should not contradict each other.
o There is be er control and understanding of processes. 5. Verifiable: Each requirement should be testable. If a requirement can't be
4. Managed (Level 4) checked (e.g., "system should be user-friendly"), it should be revised.
o Quan ta ve metrics are used to measure process performance. 6. Modifiable: The structure of the SRS should be easy to update or change as
o Project and quality management is based on data. project scope evolves.
o Processes are predictable and under control. 7. Traceable: Each requirement should be uniquely numbered and traceable
5. Op mizing (Level 5) to its source and further design or implementa on elements.
o Focus is on con nuous process improvement.
o Innova ve methods are applied to improve quality and produc vity.
o Lessons learned are systema cally applied.
5. Differen ate between Func onal and Non-Func onal Requirements  Analyst can ask follow-up ques ons to clarify doubts.
In so ware engineering, requirements are broadly categorized into two types —  Builds a strong understanding between the analyst and the user.
func onal and non-func onal — both of which are essen al for developing a Disadvantages:
complete and efficient system.  Time-consuming, especially with mul ple stakeholders.
Func onal Requirements: These define what the system should do — the core  Results may vary depending on the interviewee’s communica on skills.
func onali es and features of the so ware. They describe the interac ons  Can be biased if users are unwilling to share real issues.
between the system and its users, and how the system responds to specific inputs. 2. Ques onnaire: Ques onnaires are wri en sets of ques ons prepared to collect
Examples: informa on from many people at once. They can have open-ended ques ons (for
 The system shall allow users to log in using a username and password. detailed responses) or close-ended ques ons (for yes/no or mul ple-choice
 The applica on shall generate monthly reports. answers). This method is best when feedback is needed from a large number of
 The ATM must allow balance inquiry, cash withdrawal, and PIN change. users spread across departments or loca ons. Example: A ques onnaire is
Non-Func onal Requirements: These define how the system should behave — the distributed to all employees asking about their sa sfac on with the current payroll
quality a ributes of the so ware. They don’t deal with specific behaviors but with system and sugges ons for improvement.
the overall performance, usability, and reliability of the system. Advantages:
Examples:  Economical and less me-consuming for large groups. Responses can be
 The system shall load the homepage within 3 seconds. quickly analyzed and sta s cally evaluated. Provides anonymity,
 The system should support up to 1000 users simultaneously. encouraging honest feedback.
 The applica on must be accessible on both desktop and mobile devices. Disadvantages:
 No opportunity to ask follow-up ques ons. Low response rate if not
6. Explain any three Fact-Finding Techniques with Examples (Detailed
Explana on) mandatory. Misunderstood ques ons may lead to incorrect responses.
Fact-finding is a vital step in system analysis where the analyst collects informa on 3. Observa on: In this technique, the analyst observes how users interact with the
about the current system, user requirements, workflows, and system environment. current system without interfering. This helps the analyst understand real working
This data helps in designing an efficient and accurate new system. Below are three condi ons, user habits, and any undocumented processes. There are two types of
widely used fact-finding techniques explained in detail: observa on: Passive (observer watches silently) and Ac ve (observer asks
1. Interview: An interview is a personal and direct method of collec ng ques ons while observing). Example: A system analyst sits in the inventory
informa on. The system analyst conducts interviews with stakeholders such as department and observes how staff record incoming goods in the stock register or
users, clients, or managers to understand their expecta ons, problems, and so ware.
current procedures. Interviews can be structured (fixed set of ques ons), Advantages: Helps discover issues users might not report. Reveals the actual
unstructured (free conversa on), or semi-structured (a mix of both). Example: A workflow and user behavior. Useful for understanding manual and informal
system analyst interviews the HR manager to understand the current employee processes.
a endance process and ask about the difficul es faced in maintaining monthly Disadvantages: Time-consuming if the process being observed is long. Users may
reports. Advantages: behave differently when being watched. Complex tasks may be hard to understand
 Offers in-depth and firsthand informa on. without explana on.
7. Draw and Explain a Data Flow Diagram (DFD). 3. Level 2 DFD: Expands the Level 1 processes into more detailed sub-processes.
A DFD is a graphical tool used to represent the flow of data in a system. It shows Shows internal logic of each main func on. Highlights inter-process
how data enters a system, how it moves between processes, and how it is stored. communica on, condi ons (like wai ng), and more specific data stores.
DFD helps in understanding the logic and structure of the system without focusing
on how it will be implemented.
Key Elements:
 External En ty: Source or des na on of data (e.g., user, organiza on)
 Process: Transforma on or opera on performed on data
 Data Flow: Movement of data between en es, processes, and data stores
 Data Store: Where data is held for future use
1. Level 0 DFD (Context Level DFD): It represents the en re system as a single
process. Shows interac ons between external en es (like users or systems) and
the system as a whole. No internal processes or data stores are shown.
 Purpose: Gives a bird’s-eye view of the system.

DFD Level Purpose Details Shown

Level 0 Overview of the system Only external en es and single process

High-level func onal

Level 1 Main processes, data stores, external en es
breakdown

Level 2 Detailed design Sub-processes, data stores, internal data flow

2. Level 1 DFD: Breaks the single process of Level 0 into sub-processes. Shows
main processes, data stores, and data flow between them. Displays major
func onal modules like Reserva on Process, Enquiry, Ticket Genera on, etc.
7. Draw and Explain a En ty Rela onship Diagram (ERD) Library management System
An ERD (En ty Rela onship Diagram) is a visual representa on of data that shows
Tables (A ributes...)
how en es (like objects or concepts) relate to each other in a system. It's
1. Books (Book_id, Title, Author, Price, Available)
commonly used in database design.
2. Publisher (Pub_ID, Name, Address)
Main Components of ERD:
3. Member (Member_ID, Name, Address, Member_Type, Member_Date,
1. En es:
Expairy_Date)
o These are objects or concepts that have a dis nct existence in the
4. Borrowed_by (Book_id, Member_ID, Issue, Due_date, Returndate) ← This
domain being modeled.
is a rela onship table
o Represented using rectangles.
5. Published_by (Book_id, Pub_ID) ← This is a rela onship table
o Example: Passenger, Train, Reserva on.
2. A ributes: En ty – Rela onship – En ty
o Proper es or characteris cs of en es. 1. Books — Published_by — Publisher
o Represented using ellipses (circles). 2. Books — Borrowed_by — Member
o Example: Passenger may have a ributes like Name, Age, Gender.
3. Primary Key (PK):
o A unique iden fier for each en ty.
o Underlined in the diagram.
o Example: PassengerID, TrainNumber.
4. Rela onships:
o Show how en es are connected to each other.
o Represented using diamonds.
o Example: A Passenger makes a Reserva on.
5. Cardinality:
o Shows the number of instances of one en ty that can be associated
with instances of another.
o Examples: One-to-One (1:1), One-to-Many (1:N), Many-to-Many
(M:N).
 8. What are design principles? Explain coupling and cohesion with examples. 9. Differen ate between Object-Oriented and Func on-Oriented Design
Design principles are standard guidelines followed during so ware design to Object-Oriented Design focuses on iden fying objects in a system that interact
ensure the so ware is reliable, maintainable, and scalable. These principles help in with each other through methods. It models real-world en es using classes and
organizing the structure of code and improving code quality. The aim is to reduce supports principles like encapsula on, inheritance, and polymorphism.
complexity, increase reusability, and promote clear interac on between different Key Features:
modules of a so ware system.  Emphasizes objects and classes.
Coupling: Coupling refers to the degree of interdependence between so ware  Promotes data encapsula on (data + methods together).
modules. If modules are ghtly coupled, a change in one will affect others. Loosely  Uses UML diagrams (e.g., class diagram, use case).
coupled systems are preferred, as they increase flexibility and reduce the risk of  Reusability through inheritance and polymorphism.
error propaga on.  Be er suited for complex and evolving systems.
Types of Coupling (in order from ght to loose): Example: In a school management system, en es like Student, Teacher, and
 Content Coupling: One module uses the code/data of another. Course are modeled as classes with a ributes and behaviors.
 Common Coupling: Modules share global data. Func on-Oriented Design focuses on func ons or procedures. It divides the
 Control Coupling: One module controls the behavior of another. system into smaller func ons based on opera ons performed, using a top-down
 Stamp Coupling: Modules share composite data structures. approach.
 Data Coupling: Only necessary data is shared. Key Features:
Example: If Module A calls a func on in Module B and passes only necessary  Emphasizes func ons and procedures.
arguments, it’s data coupling (good design). If Module A accesses global variables  Focuses more on how tasks are done than who does them.
from Module B, it’s common coupling (bad design).  Uses tools like DFDs (Data Flow Diagrams).
Cohesion: Cohesion is the degree to which the elements of a module belong  Data is global or passed between func ons.
together. High cohesion within a module means its components work towards a  Be er for simple and linear problems.
single task, which improves clarity, reusability, and maintainability. Example: In a billing system, func ons like calculateTotal(), generateInvoice() are
Types of Cohesion (from worst to best): wri en as separate procedures.
 Coincidental Cohesion: Random func ons in a module. Feature Object-Oriented Design Func on-Oriented Design
 Logical Cohesion: Related tasks controlled by a flag. Focus Objects and classes Func ons and procedures
 Temporal Cohesion: Func ons executed at the same me (e.g., init tasks). Approach Bo om-up Top-down
 Procedural Cohesion: Func ons follow a sequence. Data HandlingEncapsulated in objects Global/shared between func ons
 Communica onal Cohesion: Func ons use the same data. Reusability High (via inheritance) Limited
 Sequen al Cohesion: Output of one part is input to another. Tools Used UML diagrams DFDs, structure charts
 Func onal Cohesion: Every part contributes to one task. Best for Large, complex, reusable systemsSimple and smaller applica ons
Example: A module that handles only file reading is func onally cohesive (ideal). A
module that does logging, reading, and prin ng randomly is coincidentally
cohesive (poor design).
 Ques on 10. What are Control Models and Modular Decomposi on? 11: What are Coding Guidelines? Explain Structured Programming and Code
Control Models: Control models define how the flow of control is managed within Documenta on.
a system or so ware. These models help in designing how different parts of the 1. Coding Guidelines:
so ware interact, coordinate, and trigger ac ons during execu on. These are a set of rules to maintain consistency in code across a team or project.
Types of Control Models:  Use meaningful variable and func on names
1. Centralized Control Model: One main module (like a controller) controls  Maintain proper indenta on and forma ng
the flow of the program. Other modules report to or are ac vated by the  Write simple, readable, and reusable code
controller.  Follow naming conven ons (like camelCase or snake_case)
2. Event-Driven Control Model: Ac ons are triggered based on events (like 2. Structured Programming:
mouse click, keyboard input, etc.). Commonly used in GUI-based This is a programming approach that promotes clean and organized code.
applica ons.  Uses clear control structures (if-else, loops, switch)
3. Call-Return Model: Func ons/modules call each other and return control  Avoids use of goto to reduce complexity
a er execu on. Common in procedural programming.  Encourages breaking the program into func ons or modules
4. Interrupt-Driven Model: The flow is interrupted by external events (e.g., 3. Code Documenta on:
hardware signals), and special rou nes handle them. It refers to wri ng explana ons within the code or in separate files.
Modular Decomposi on: Modular decomposi on is the process of breaking a  Comments help explain logic or purpose of code blocks
complex system into small, manageable modules to improve understanding,  Documents include descrip ons of func ons, input/output, etc.
development, tes ng, and maintenance.  Useful for debugging, collabora on, and future maintenance
Key Points: 12. LOC-based vs FP-based Metrics
 Each module handles a specific task or func onality.
LOC-based Metrics (Lines of Code):
 Modules should have high cohesion (related tasks) and low coupling (less
This method measures the size of so ware by coun ng the number of lines in the
dependency).
code. It includes lines with actual code, but can exclude comments and blank lines.
 Helps in team collabora on, parallel development, and easy modifica on.
 Easy to calculate and understand
 Encourages reuse of components.
 Helps es mate produc vity (e.g., LOC per developer per day)
Example: In a library management system, you can decompose it into modules
 But it doesn’t reflect so ware complexity or quality
like:
FP-based Metrics (Func on Points):
 Book Management
Func on Point Analysis measures the func onality delivered to the user, not the
 Member Registra on
code size. It considers inputs, outputs, user interac ons, files, and interfaces.
 Issue/Return Handling
 Independent of programming language
 Fine Calcula on
 Reflects user requirements be er than LOC
 Useful for comparing projects of different sizes or tech stacks
In summary, LOC is a physical measure focused on code length, while FP is a logical
measure focusing on user-visible func onality.
13. McCall’s Quality Factors and So ware Quality Assurance (SQA) 15. What is Black Box and White Box Tes ng? Explain with examples.
McCall’s Quality Factors provide a framework to assess so ware quality. These Black Box Tes ng is a method where the internal logic or structure of the code is
factors are grouped into three categories: not known to the tester. The tester focuses on inputs and expected outputs,
 Product Opera on (how the so ware runs): without considering how the output is produced. It is mainly used for func onal
Includes correctness, reliability, efficiency, integrity, and usability. tes ng.
 Product Revision (ease of changing so ware): Example: Tes ng a login form by entering valid and invalid creden als, without
Includes maintainability, flexibility, and testability. knowing how the login logic is implemented in the backend.
 Product Transi on (adaptability to new environments): White Box Tes ng, on the other hand, involves knowledge of the internal code
Includes portability, reusability, and interoperability. structure. The tester designs test cases based on logic paths, loops, and condi ons
These factors help evaluate so ware from both technical and user perspec ves. within the code. It is mainly used for unit and integra on tes ng.
So ware Quality Assurance (SQA) is a systema c approach to ensure that the Example: Tes ng each condi onal path in a func on that processes payments,
developed so ware meets specified quality standards. It includes processes like verifying all branches and loops are covered.
reviews, audits, tes ng, and quality control. SQA helps detect issues early, ensures Both techniques are essen al for thorough so ware tes ng—black box for
process adherence, and improves customer sa sfac on. usability and func onality, white box for code reliability and logic.
14. Explain different levels of so ware tes ng.
So ware tes ng is done at different levels to ensure quality at each stage of
development. The four main levels are:
 Unit Tes ng: This is the first level of tes ng where individual components
or func ons of the so ware are tested in isola on. Developers usually
perform this to catch early bugs.
 Integra on Tes ng: A er unit tes ng, different modules are combined and
tested as a group to iden fy issues in their interac on. This checks how
data flows between modules.
 System Tes ng: This level tests the en re integrated system to verify that it
meets the specified requirements. It is done by a separate QA team and
includes both func onal and non-func onal tes ng.
 Acceptance Tes ng: Performed by the end-users or clients, this final level
ensures the so ware meets business needs. It includes alpha and beta
tes ng before deployment.
Each level plays a cri cal role in delivering a reliable and error-free so ware
product.
16. What is Cycloma c Complexity? Explain with a flow graph. 2. Adap ve Maintenance: When there is a change in the environment (like new
Cycloma c Complexity is a so ware metric used to measure the complexity of a opera ng systems, hardware, or so ware standards), the so ware needs
program by coun ng the number of linearly independent paths in the code. It updates to remain compa ble. This is known as adap ve maintenance.
helps in understanding how difficult a program will be to test and maintain. A 3. Perfec ve Maintenance: This involves improving or enhancing the so ware’s
higher cycloma c complexity means more poten al paths, making the so ware func onality, performance, or usability based on user sugges ons or to meet
harder to understand and more error-prone. future requirements.
It is calculated using the formula: 4. Preven ve Maintenance: It focuses on detec ng and fixing poten al issues
V(G) = E – N + 2P, before they become real problems. This ensures long-term so ware stability
where: and reduces the chances of unexpected failures.
 E = number of edges in the control flow graph 18. What are CASE Tools? Explain their Importance.
 N = number of nodes CASE (Computer-Aided So ware Engineering) tools are so ware applica ons
 P = number of connected components (usually 1 for a single program) designed to support and automate various ac vi es involved in so ware
Flow Graph Example (Text-Based): development, such as analysis, design, coding, tes ng, and maintenance. These
Consider the following simple if-else code: tools improve the efficiency, accuracy, and consistency of the so ware
if (condi on) development process by assis ng developers in documenta on, modeling, and
doTaskA(); code genera on.
else There are different types of CASE tools like:
doTaskB();  Upper CASE tools: Used in the early phases such as requirements and design.
The control flow graph will have:  Lower CASE tools: Used in later stages such as implementa on, tes ng, and
 3 nodes (start, if condi on, end) maintenance.
 3 edges (start → if, if → TaskA, if → TaskB)  Integrated CASE tools: Support all stages of the development life cycle.
Cycloma c Complexity = 3 - 3 + 2 = 2 Importance of CASE Tools:
This means there are two independent paths to test — one for doTaskA() and one  Improved Produc vity: Automa on of tasks saves me and effort.
for doTaskB().  Be er Documenta on: Helps in crea ng accurate and up-to-date design
17. What is So ware Maintenance? Explain its Types. documents.
So ware Maintenance refers to the process of modifying a so ware system a er  Error Reduc on: Reduces human errors during design and coding.
its ini al deployment to correct faults, improve performance, or adapt it to a  Consistency and Standardiza on: Ensures uniformity across the development
changed environment. It ensures that the so ware con nues to meet user needs team.
over me, even as technology and requirements evolve.  Easy Maintenance: With clear documenta on and design, future modifica ons
There are four main types of so ware maintenance: become easier.
1. Correc ve Maintenance: This type deals with fixing bugs or defects found in These tools play a key role in enhancing so ware quality, speeding up
the so ware a er it has been released. It is reac ve in nature and usually done development, and maintaining standards throughout the so ware life cycle.
in response to user feedback or error reports.
 Ques on Bank
1. What is So ware Engineering? Explain its characteris cs and classifica on.
2. Explain different so ware process models. (Waterfall, Prototype, RAD, Spiral, V-
Model)
3. What is the Capability Maturity Model (CMM)? Explain its levels.
4. What is So ware Requirement Specifica on (SRS)? What are its components?
5. Differen ate between func onal and non-func onal requirements.
6. Explain any three fact-finding techniques with examples.
7. Draw and explain a Data Flow Diagram (DFD) and En ty Rela onship Diagram
(ERD).
8. What are design principles? Explain coupling and cohesion with examples.
9. Differen ate between object-oriented and func on-oriented design.
10. What are control models and modular decomposi on?
11. What are coding guidelines? Explain structured programming and code
documenta on.
12. Differen ate between LOC-based and FP-based metrics.
13. Explain McCall’s Quality Factors. What is So ware Quality Assurance (SQA)?
14. Explain different levels of so ware tes ng. (Unit, Integra on, System,
Acceptance)
15. What is Black Box and White Box tes ng? Explain with examples.
16. What is cycloma c complexity? Explain with a flow graph.
17. What is so ware maintenance? Explain different types.
18. What are CASE tools? Explain their importance.