Q1. Explain Incremental process model with advantages disadvantages.

1. Requirement:
Basic requirements are gathered; detailed ones are defined for each increment.
2. Design:
Overall architecture is planned, and each increment has its own design phase.
3. Development:
Each increment is coded and developed separately in manageable parts.
4. Testing:
Every increment is individually tested and integrated with the previous ones.
5. Feedback:
After each increment, feedback is collected to improve future increments.
6. Advantages - Early Delivery, Easier Testing & Debugging, Flexible to Changes
7. Disadvantages - System Design Issues: making big design changes later is hard.
8. Integration Problems: Combining multiple increments can become complex
over time. Not Good for All Projects

Q1. With neat diagram discuss about Software Engineering layers.

1. Tools: These are the physical or digital resources (like software, machines, or
instruments) that help carry out tasks more effectively and accurately.
2. Methods: These are organized approaches or procedures that guide how tasks
should be performed to achieve the desired outcome.
3. Process: This is a sequence of interconnected steps or activities that transform
inputs into a final product or result.
4. A Quality Process: This is a structured process that includes checks & controls to
ensure output consistently meets or exceeds predefined standards of quality.

Q1. What is software engineering? Explain SDLC in detail.

Requirement Gathering & Analysis → System Design → Implementa on
(Coding) → Tes ng → Deployment → Maintenance

Q1. Illustrate the generic process activities for Software Engineering.

1. Communication: Keep everyone synced — clients, devs, testers.
2. Planning: Define goals, scope, resources, risks, deadlines.
3. Modeling: Map software with clear diagrams.
4. Construction: Code, test, integrate.
5. Deployment: Launch, setup, train users.

Q1. Software Engineering Ethics.

1. Public Interest 2. Client & Employer Interests 3. Product Quality
4. Integrity & Independence 5. Competence 6. Privacy
7. Fairness & Inclusion 8. Social Impact & Sustainability
9. Accountability & Transparency [Link] & Discrimination
11. Security 12. Data Ownership 13. Intellectual Property
14. Computer Misuse [Link] Education on Software.
Q1. What is Agile Development Model ?
1. Agile is an iterative, flexible software development approach focusing on
collaboration, customer feedback, and rapid delivery of small, functional
software increments.
2. Cost of Change: Agile reduces the cost of change by delivering software in small,
manageable chunks, allowing frequent feedback and quick adaptation before
big investments are made.
3. Agile breaks the project into short iterations (sprints), each producing a working
product version, enabling continuous improvement and easy changes.
4. Customer Involvement: Customers or product owners are actively involved
throughout, providing feedback and clarifying requirements during each sprint.
5. Agile welcomes changing requirements, even late in development, enabling
better alignment with business needs.
6. Agile promotes close communication within teams and with stakeholders for
faster decision-making.
7. Traditional Model (Waterfall) vs Agile - Adaptability:
Waterfall is linear and rigid—changes late in the cycle are costly. Agile is flexible
and embraces change anytime.
8. Traditional Model vs Agile - Customer Involvement:
Waterfall has minimal customer input after the requirement phase. Agile
involves customers continuously, ensuring product meets their evolving needs.
Diagram = Plan → Design → Develop → Test → Release → Feedback

Q1. What is waterfall development and How does it address the issue
of the cost of change? Draw and explain in detail.
1. Waterfall Development is a traditional, linear software process where each
phase follows the previous one in order.
2. The main phases are: requirements, design, implementation, testing,
deployment, and maintenance.
3. Each phase must be completed fully before moving to the next, with little to no
overlap.
4. It relies heavily on detailed documentation and upfront planning during the
requirements phase.
5. Changes are ideally caught early during requirements or design to avoid costly
fixes later.
6. If changes happen after implementation or testing, they become expensive and
time-consuming to fix.
7. Waterfall reduces the cost of change by minimizing changes through thorough
initial analysis.
8. The process is easy to manage and track because of its rigid structure and
defined milestones.
9. However, it lacks flexibility and doesn’t adapt well if requirements evolve during
development.
[Link] is best suited for projects with clear, stable requirements and where
change is unlikely.
Diagram = Requirements → Design → Implementa on → Tes ng →
Deployment → Maintenance
Q2. Elicitation Techniques in Software Engineering.
1. Interviews: One-on-one or group talks with stakeholders to gather detailed
insights.
2. Questionnaires: Written sets of questions sent to many users for broad
feedback.
3. Workshops: Collaborative meetings where stakeholders discuss and define
requirements.
4. Observation: Watching users perform tasks to discover implicit needs.
5. Document Analysis: Studying existing system documents and manuals for
requirements.
6. Prototyping: Building early system models to clarify and refine requirements.
7. Brainstorming: Generating ideas in groups to explore system features and
solutions.
8. Focus Groups: Guided discussions with selected users to gather opinions and
priorities.
9. Use Cases: Describing system interactions from the user’s perspective to
capture requirements.
[Link] Analysis: Examining how systems interact with each other to define
integration needs.

Q2. With the help of diagram explain how to translate the

requirements model into design model.
1. The Requirements Model captures what the system should do — including use
cases, user stories, and functional/non-functional requirements.
2. The Design Model focuses on how the system will fulfill those requirements,
including architecture, components, data structures, and interfaces.
3. Translating involves transforming abstract requirements into concrete system
architecture and detailed designs.
4. This process includes: identifying key system components, defining their
interactions, specifying data flow, and designing user interfaces.
5. The design model also addresses performance, scalability, security, and
maintainability concerns.
6. Designers use modeling tools such as UML diagrams to visualize components
and their relationships.
7. Early prototyping during design helps validate architectural choices with
stakeholders.
8. Feedback loops allow designers to revisit requirements if design constraints
reveal issues.
Diagram =
Requirements Model
--(Identify Use Cases & Functional Specs)-->
Functional Decomposition
--(Break down requirements into modules)-->
Architectural Design
--(Define system components & their interactions)-->
Detailed Design
--(Specify data structures, algorithms, interfaces)-->
Design Model
Q2. Non-functional requirement are also essential customer
satisfaction, Justify this statement.
1. Non-functional requirements (NFRs) specify how a system performs its
functions, focusing on qualities like performance, usability, reliability, and
security, rather than specific behaviors or features.
2. Performance: Fast response times and efficient resource use improve user
experience and satisfaction.
3. Reliability: System that work without failure build customer trust & confidence.
4. Usability: Easy-to-use interfaces reduce frustration & increase productivity for
users.
5. Security: Protecting user data, privacy is crucial for customer confidence.
6. Scalability: Ability to handle growth smoothly prevents performance issues as
usage increases.
7. Maintainability: Easier update & bug fixes ensure system stays relevant and
reliable.
8. Availability: High uptime means customers can access the system whenever
needed, boosting satisfaction.
9. Compatibility: Works well with other systems and devices, avoiding user
inconvenience.
[Link]: Ensures all users, including those with disabilities, can use the
software, broadening satisfaction.
[Link] and Regulatory Compliance: Meeting standards avoids penalties and
reassures customers about product legitimacy.

Q2. Functional requirements.

1. Functional requirements define the specific behaviors and functions a software
system must perform. They are essential for customer satisfaction because:
2. Core Functionality: They ensure the system delivers the features and services
customers expect. Without these, the product fails its primary purpose.
3. Meeting User Needs: Functional requirements are based on user needs and
business goals, so fulfilling them means software solves the intended problems.
4. Correctness: They specify what the system should do in different scenarios,
ensuring correct and predictable outcomes.
5. Completeness: Delivering all requested functions avoids gaps that frustrate
users or force workarounds.
6. Usability Through Function: Features like search, data entry, and reporting
enable users to interact effectively with the system.
7. Reliability of Actions: Functional requirements ensure key processes (like
transactions or calculations) work reliably, building user trust.
8. Business Compliance: Meeting functional specs often means complying with
business rules, regulations, & contracts, thus satisfies customers & stakeholders.
9. User Satisfaction: Users expect specific capabilities; delivering these directly
impacts their satisfaction and likelihood of continued use.
[Link] Edge: Having the right functionalities can differentiate a product in
the market, attracting and retaining customers.
[Link] for Quality: Functional requirements provide the basis for testing
and validation, ensuring the software meets customer expectations.
Q3. What is System Testing? Explain any three types of System Testing.
System testing is the process of testing a fully integrated software system to
evaluate its compliance with the specified requirements. It checks the end-to-end
behavior of the system, including functionality, performance, and security in a
complete environment.
Functional Testing
1. Validates that each function of the software operates in conformance with the
requirement specification.
2. Focuses on user commands, data input, and output results.
3. Typically includes boundary value tests, error handling, and input validation.
4. Example: Testing whether the login form accepts valid credentials and blocks
invalid ones.
Performance Testing
1. Measures how the system performs under workload in terms of responsiveness
and stability.
2. Ensures the application can handle expected traffic without crashing or slowing
down.
3. Includes load testing, stress testing, and scalability testing.
4. Eg: Verifying that the website loads within 3 seconds for 1000 concurrent users.
Security Testing
1. Ensures that the system protects data and maintains functionality as intended.
2. Identifies vulnerabilities, threats, and risks in the system.
3. Validates features like authentication, authorization, and data encryption.
4. Example: Checking that users cannot access admin pages without logging in.

Q3. Define Software Testing, Explain graph based functional testing

techniques with suitable graph notations.
Software testing is the process of evaluating a software application to identify
defects and ensure the software meets the specified requirements. It helps ensure
functionality, performance, reliability, and quality of the software system.
Control Flow Graph (CFG)
Represents all paths that might be traversed through a program during execution.
[Start] → (A) → (B) → [Decision: C?]
↘Yes→ (D) → (E)
↘No → (F)
Decision to Decision Path (DD-Path)
Simplified form of CFG focusing only on decision and action nodes. Reduces
redundancy in path testing. Used for branch coverage & decision coverage testing.
State Transition Graph
Represents different states of the system and the transitions between them based
on events or inputs.
[Idle] → (Login) → [Authen cated] → (Logout) → [Idle]
Data Flow Graph
Shows how data values flow through the program.
Focuses on definitions (def) and uses (use) of variables.
Use: Used in data flow testing to find issues like undefined variables, dead code,
etc.
Q4. Apply Mc Call’s quality factors for hotel management system.
1. Correctness
Accurately manages reservations, room availability, billing, and user data to
avoid booking errors.
2. Reliability - Runs continuously without crashes, ensuring secure, consistent
processing of bookings and payments.
3. Efficiency - Processes searches & bookings fast, optimizing resources for quick
responses.
4. Integrity - Protects sensitive customer info with strong security against
unauthorized access.
5. Usability - User-friendly interface for staff & customer,minimizing training needs
6. Maintainability
Modular, well-documented code enables easy bug fixes and feature updates.
7. Testability - Supports thorough testing of booking, payment, and reporting
modules to catch defects early.
8. Flexibility - Easily adapts to changing hotel policies, pricing, or new room types
without major redesign.
9. Portability - Runs smoothly on Windows, Linux, and web browsers, supporting
varied hotel IT setups.
[Link] - Common modules (payment, customer management) designed for
reuse across branches or apps.

Q4. Software Maintenance Lifecycle. Types of software Maintenance.

1. Problem/Request Identification - Users or stakeholders reports issues.
2. Analysis - Assess the problem’s impact and feasibility of the requested changes.
3. Planning - Create a maintenance plan, including schedules, resources, priorities.
4. Design - Modify system design to incorporate fixes or new features.
5. Implementation - Write and test the modified or new code.
6. Testing - Conduct testing (unit, integration, system) to ensure changes work and
no new issues arise.
7. Deployment - Release the updated software to users.
8. Documentation - Update system and user documentation to reflect changes.
9. Review & Feedback -
Collect feedback to identify further improvements or new issues.
Types of Software Maintenance:
1. Corrective Maintenance
Fixing bugs and defects discovered after software release.
2. Adaptive Maintenance
Updating software to work with new or changed environments (OS, hardware,
regulations).
3. Perfective Maintenance
Enhancing performance, maintainability, or adding new features based on user
feedback.
4. Preventive Maintenance
Making changes to prevent future problems, improving reliability and
maintainability.
Q5. Explain Software Re-engineering process model with suitable eg.
Software re-engineering is the process of analyzing and modifying an existing
software system to improve it, make it easier to maintain, enhance functionality, or
migrate to new platforms without starting from scratch.
1. Source Code Analysis:
Understanding the existing system by analyzing source code, documentation,
and system behavior.
2. Reverse Engineering:
Extracting higher-level abstractions and design information from the existing
code to understand its structure and functionality.
3. Restructuring:
Improving the internal structure of the code without changing its external
behavior, such as cleaning up code, modularizing, or refactoring.
4. Forward Engineering:
Adding new features, improving performance, or migrating the system to new
platforms or technologies.
5. Testing:
Rigorous testing to ensure that changes do not break existing functionality and
that new features work correctly.
Example:
Imagine a hotel management system developed 10 years ago using outdated
technology. The system has become difficult to maintain, and new features are
hard to add. Instead of rebuilding the whole system, the development team:
 Analyzes the existing code and documents how the system works.
 Reverse engineers the system to recover design models and understand
modules like booking, billing, and room management.
 Restructures the code to improve readability and modularity.
 Migrates the system to a modern web-based platform, adding features like
online booking and payment gateway integration (forward engineering).
 Tests thoroughly to confirm that old and new functions perform correctly.

Q5. Business Model Re-engineering.

1. Definition: Fundamental redesign of a company’s business model for major
performance improvement.
2. Purpose: Adapt to market changes, technology, and customer needs.
3. Focus: Redesign processes, structure, products, revenue, and customer
relations.
4. Triggers: Competitive pressure, tech advances, poor performance.
5. Activities: Analyze current model → Iden fy gaps → Redesign → Implement.
6. Customer-Centric: Aligns business to deliver more customer value.
7. Technology: Uses digital tools for efficiency and innovation.
8. Organizational Change: Requires culture shift and new roles.
9. Risks: Resistance, disruption, and potential business loss.
[Link]: Bookstore shifts from physical sales to online ebooks & subscriptions.
Q6. Explain how efforts & cost estimations are by COCOMO model.
1. COCOMO (Constructive Cost Model) is a method to estimate the effort, time,
and cost of software development projects.
2. Based on KLOC:
It uses KLOC (thousands of lines of code) as the input to calculate effort.
3. Effort Formula:
Effort = a × (KLOC)^b
Constants a and b depend on project type (Organic, Semi-detached, Embedded).
4. Time Estimation:
Time = c × (Effort)^d
Gives development time in months.
5. Cost Calculation:
Cost = Effort × Cost per Person-Month
(e.g., salary, overheads)
6. Project Types:
 Organic: Small/simple projects
 Semi-detached: Medium complexity
 Embedded: Large/complex systems
7. Example:
For 10 KLOC (Organic):
Effort = 2.4 × (10)^1.05 ≈ 26.7 PM
8. Cost Drivers (Intermediate/Advanced):
Adjust estimates based on experience, tools, reliability, etc.
9. Scalable : Adapts to project size & provides a solid foundation for planning.
[Link] in Planning: Used to allocate budget, schedule, manpower effectively.

Q6. Discuss about Empirical Estimation Models.

1. Data-Driven - Based on actual project data (e.g., effort, time, cost).
2. Experience-Based - Uses experience from previous similar projects.
3. Realistic Estimation - Provides practical results grounded in reality.
4. Statistical Techniques - Applies regression, averages, or trend analysis.
5. Repeatable & Scalable - Can be reused for similar projects with predictable
outcomes.
6. Reduces Guesswork - Less reliance on intuition; more on measurable facts.
7. Supports Risk Management - Helps identify possible budget issues early.
8. Improves Planning Accuracy - Results in better project schedules and resource
allocation.
9. Adaptable - Works across domains (web, mobile, embedded systems, etc.)
[Link] Continuous Improvement - Data from one project refines the next
estimation.
Example : -
Imagine you built a school management app last year. It had 10 modules and took
800 hours.
Now you're building a hospital management app with 15 similar modules.
Using empirical estimation, you can say:
Effort = (15 / 10) × 800 = 1200 hours
Q2. Interpret about feasibility studies of requirement engineering
process with suitable example.
1. Definition: Feasibility study assesses if a software project is practical and
achievable before detailed development begins.
2. Purpose: To identify potential risks and constraints related to cost, time,
technology, and resources.
3. Technical Feasibility: Checks if the required technology and expertise are
available to build the system.
4. Economic Feasibility: Evaluates if the project’s benefits justify the development
and operational costs.
5. Operational Feasibility: Determines if the organization and users can effectively
use and support the system.
6. Schedule Feasibility: Assesses whether the project can be completed within the
required timeline.
7. Legal Feasibility: Ensures compliance with laws, regulations, and ethical
standards.
8. Example: A startup wants to build a food delivery app. They check if they have
skilled developers (technical), if the investment will be profitable (economic), if
their staff can manage the system (operational), and if the app can launch in 6
months (schedule).
9. Outcome: A positive feasibility study confirms the project can proceed; a
negative result may require revising plans or dropping the project.
[Link]: Helps avoid wasting time and resources on projects that are not
viable or profitable.

Q2. What are the key-component of a Software Requirements

Specification. (SRS)
1. A Software Requirements Specification (SRS) is a detailed document that
describes the software system to be developed.
2. It acts as a contract between stakeholders and developers, outlining functional
and non-functional requirements clearly.
3. Introduction: Overview of the system, purpose, scope, and definitions.
4. Overall Description: General factors like user needs, assumptions, and
constraints.
5. Functional Requirements: Detailed list of system functions and behaviors.
6. Non-functional Requirements: Performance, security, usability, reliability, etc.
7. System Interfaces: Description of how the software interacts with other
systems or hardware.
8. User Interfaces: Design of user interaction including screens and commands.
9. Performance Requirements: Speed, capacity, and resource usage specifications.
[Link] Constraints: Limitations such as platforms, programming languages, or
regulatory rules.
[Link] and Dependencies: External conditions or software/hardware
dependencies.
[Link] and Glossary: Supporting documents, terms definitions, and
references.
Q1. What is lean development.
1. Eliminate Waste: Remove any non-value-adding activities to save time and cost.
2. Create Knowledge: Use continuous feedback to learn and improve the process
and product.
3. Empower Team: Allow teams to make decisions quickly, speeding up response
to change.
4. Deliver Fast: Release small, frequent updates to catch issues early and reduce
rework.
5. Optimize Whole: Improve the entire development system, not just individual
parts.
6. Build Quality: Integrate quality throughout to avoid expensive fixes later.
7. Defer Decision: Delay choices until enough info is available, increasing flexibility.
8. Cost of Change: Lean lowers cost by enabling early issue detection and quick
adaptation, preventing expensive late changes.
9. Adaptability: Unlike traditional rigid models, Lean welcomes continuous
change, allowing teams to pivot based on feedback.
[Link] Involvement: Lean involves customers throughout the development
cycle, unlike traditional models which limit customer input mainly to the
beginning and end.
Diagram = Eliminate Waste → Create Knowledge → Empower Team →
Deliver Fast → Op mize Whole → Build Quality → Defer Decision

Q1. What is iterative development ?

1. Iterative development breaks the project into small cycles (iterations), each
producing a working software version.
2. Each iteration includes planning, designing, coding, testing, and evaluating.
3. Frequent iterations enable early detection and correction of defects or
requirement changes.
4. This reduces the cost of change by avoiding late, expensive fixes common in
traditional models.
5. Customers give feedback after every iteration, improving product continuously.
6. The process is flexible and adapts to changing requirements throughout
development.
7. Risks are minimized by focusing on smaller parts of the project at a time.
8. Customers stay involved during the entire project, unlike limited involvement in
traditional methods.
9. Iterative development supports better quality through repeated testing and
refinement.
[Link] traditional waterfall’s rigid, linear approach, iterative is cyclical, adaptive,
and customer-
focused.
Q1. What is Spiral Model ?
1. Spiral development is an iterative process combining design, prototyping, and
risk analysis.
2. It breaks the project into cycles (spirals), each addressing specific risks.
3. Each spiral has four phases: Planning, Risk Analysis, Engineering, and Evaluation.
4. Early risk identification reduces the cost of change by preventing late surprises.
5. Customer feedback is gathered after each spiral, improving the product
continuously.
6. The model is highly adaptable, allowing requirement changes throughout
development.
7. Each spiral delivers an incrementally improved software version.
8. Risk-driven focus helps manage uncertainties and reduces project failure.
9. Compared to traditional models, spiral is more flexible and emphasizes ongoing
assessment.
[Link] customer involvement ensures the product meets evolving needs
better than rigid waterfall.

Q1. What is DevOps Model ?

1. DevOps integrates development and operations for better collaboration.
2. It reduces cost of change by enabling fast, automated deployments.
3. DevOps uses a continuous cycle: Plan → Develop → Build → Test → Release →
Deploy → Operate → Monitor.
4. Automation speeds up processes and cuts manual errors.
5. Continuous Integration/Continuous Delivery (CI/CD) pipelines allow frequent,
smaller updates.
6. Developers and operations share responsibility, improving communication.
7. Customer feedback is received quickly due to rapid release cycles.
8. DevOps adapts easily to change with incremental updates.
9. It reduces downtime and improves product reliability through monitoring.
[Link] traditional models, DevOps breaks silos and speeds delivery with
continuous feedback.
Q4. With suitable example describe various SQA activities.
1. Quality Planning - Define quality standards and processes.
Example: Set coding and testing guidelines for a banking app.
2. Quality Control - Monitor project outputs to meet standards.
Example: Perform code reviews and unit tests to catch bugs early.
3. Quality Audits - Check adherence to processes regularly.
Example: Audit healthcare app development for regulatory compliance.
4. Process Implementation – Establish & enforce development/testing processes.
Example: Use Agile sprint reviews to maintain quality.
5. Training - Equip teams with skills and knowledge.
Example: Conduct secure coding workshops for fintech developers.
6. Configuration Management - Control changes to software and documents.
Example: Use Git for version control in a collaborative project.
7. Testing & Verification - Test software to detect defects and verify requirements.
Example: Functional and regression testing of an e-commerce site.
8. Defect Management - Track and resolve bugs efficiently.
Example: Use JIRA to manage bug reports in a mobile app.
9. Metrics Analysis - Collect and analyze quality data.
Example: Measure defect density to assess CRM stability.
[Link] Improvement - Continuously enhance processes from feedback.
Example: Introduce automated testing to speed up releases.
Q4. Difference between Six Sigma and IEEE 9000.
Six Sigma IEEE 9000 Standards
Focuses on establishing and
Focuses on reducing defects and
maintaining quality management
improving quality.
systems.
Developed by IEEE for software
Developed by Motorola in the 1980s.
quality standards.
Data-driven, statistical method Standard-based, process
(DMAIC process). documentation and compliance.
Primarily process improvement and Covers software development
defect reduction. lifecycle quality processes.
Six Sigma certification for individuals Certification for organizations
and organizations. complying with standards.
Minimizing variation and defects to Defining quality processes and
3.4 per million opportunities. ensuring consistent software quality.
Uses statistical tools like control Uses process audits, documentation,
charts, root cause analysis. and reviews.
Emphasizes customer requirements Emphasizes customer satisfaction
through Voice of Customer (VOC). through quality management.
Used across industries including Primarily targeted at software
manufacturing, IT, services. development and engineering.
Achieve near-perfect products and Ensure software products meet
processes. specified requirements and quality.
Q3. What are the basic principles of programming practices? Explain
various types of code verification techniques in detail.
1. Modularity – Break code into small, reusable functions/modules.
2. Readability – Use meaningful names, indentation, and comments for clarity.
3. Maintainability – Code should be easy to update/fix without side effects.
4. Simplicity – Avoid unnecessary complexity; keep logic straightforward.
5. Consistency – Follow a uniform coding style across the project.
6. Efficiency – Optimize memory, processing time, and resource usage.
Code Verification Techniques :-
1. Code Review
Manual inspection by peers. Finds logic errors, code smells, standard violations.
Types: Formal (meetings), Informal (pair programming).
2. Static Code Analysis
Automated tools analyze code without running it. Detects syntax issues, style
violations, bugs. Tools: SonarQube, ESLint, Checkstyle.
3. Unit Testing
Tests individual functions/modules in isolation. Validates correctness of small code
units. Tools: JUnit (Java), PyTest (Python), NUnit (.NET).
4. Walkthrough
Developer explains code to team. Aims to find defects and gather feedback.
Less formal, highly interactive.
5. Formal Verification
Uses mathematical logic to prove correctness. Applied in critical systems (e.g.,
avionics, healthcare). Ensures code behaves exactly as specified.

Q3. Test plan type shit.

1. Test Plan ID - Unique identifier for the test plan.
o Example: TP-LoginModule-01
2. Introduction - Overview of the test plan, its purpose, and scope.
o Example: Testing login functionality for authentication system.
3. Test Items - List of features/modules to be tested.
o Example: Login page, Forgot Password, Session timeout.
4. Features to be Tested - Specific functionalities under test.
o Example: Correct username/password validation.
5. Features Not to be Tested - Out-of-scope features.
o Example: Third-party OAuth login (Google, Facebook).
6. Test Approach - Strategy and levels of testing to be used.
o Example: Manual black-box testing with boundary value analysis.
7. Pass/Fail Criteria - Conditions for declaring a test successful or failed.
o Example: Login succeeds only with valid credentials.
8. Test Deliverables - All test-related documents and reports.
o Example: Test cases, bug reports, test summary report.
9. Testing Schedule - Timeline of testing phases and milestones.
o Example: Unit testing (May 10–12), System testing (May 13–17).
10. Resources and Responsibilities
 People, tools, and roles involved in testing.
 Example: QA Lead – test planning, Tester – execution, Tool – Selenium.
Q2. Requirements Analysis - Structured Analysis, Object Oriented
Modelling.
Requirements Analysis is the process of gathering, understanding, and specifying
what a software system must do, including its functionalities and constraints, to
meet the needs of stakeholders.
Structured Analysis :
1. Data Flow Diagrams (DFDs): Represent the flow of data through the system and
the processes that transform it.
2. Process-Oriented: Focuses on breaking down the system into a hierarchy of
functions or processes.
3. Data Dictionary: Provides detailed descriptions of data elements used in system.
4. Emphasizes Functionality: Captures what the system does by modeling inputs,
outputs, and data stores.
5. Good for Procedural Systems: Best suited for systems where process flow and
data transformation are primary concerns.
Object-Oriented Modeling :
1. Focus on Objects: Models the system as interacting objects with attributes
(data) and methods (behavior).
2. Use Case Diagrams: Capture system functions as interactions between users
(actors) and the system.
3. Class Diagrams: Show the structure of classes, attributes, methods,
relationships.
4. Encapsulation: Combines data & behavior into object promoting modularity,
reuse.
5. Better for Complex Systems: Ideal for modeling real-world entities and
promoting maintainability and flexibility.

Q2. Requirement Engineering Tools (CASE)

1. Definition: CASE (Computer-Aided Software Engineering) tools assist in
automating and managing software requirement engineering activities.
2. Purpose: They streamline requirement gathering, analysis, documentation, and
validation, reducing manual errors.
3. Upper CASE Tools: Focus on early phases like requirement analysis and system
modeling (e.g., use case diagrams, DFDs).
4. Lower CASE Tools: Support later phases like coding, testing, and maintenance.
5. Integrated CASE Tools: Combine both upper and lower tools to support the
entire software development lifecycle.
6. Requirement Modeling: Help create visual models such as ER diagrams, UML,
class diagrams for better understanding.
7. Version Control: Track changes to requirements and maintain history for better
project management.
8. Traceability: Maintain links between requirements, design elements, and test
cases for validation and impact analysis.
9. Examples: IBM DOORS, Rational Rose, StarUML, Enterprise Architect are
popular CASE tools.
[Link]: Improve accuracy, collaboration, productivity, and ensure high-quality
software aligned with customer needs.
Q6. How LOC and FP are used in project estimation? Discuss. Explain
both estimation techniques with suitable example.
1. 📏 Lines of Code (LOC) Estimation
 Measures the size of a software project by counting the number of lines in
the source code.
 Effort, time, and cost are estimated based on average productivity (e.g., LOC
per person-month).
2. 🔧 Example – Food Delivery App (Prototype)
 Estimated size: ~10,000 LOC (Login, Browse Menu, Cart, Checkout, Track
Order).
 Average productivity: 500 LOC/month per developer.
3. 🔹 Effort = 10,000 / 500 = 20 person-months
🔹 Team = 4 developers
🔹 Time = 20 / 4 = 5 months
4. Tools Needed:
 IDE (e.g., VS Code)
 Version Control (Git)
 Backend frameworks ([Link]/Django)
 Mobile SDKs (Flutter/React Native)

2. 📐 Function Point (FP) Estimation

 Measures functionality delivered to the user based on inputs, outputs, files,
interfaces, and user interactions.
 Technology-independent — focuses on what the system does, not how.
🔧 Example – Food Delivery App (Prototype)
 Estimated FP:
 External Inputs: 5 (Login, Register, Add to Cart, Search, Checkout)
 External Outputs: 4 (Order Status, Confirmation, Error Messages,
Notifications)
 Internal Files: 3 (User DB, Menu DB, Orders)
 External Interfaces: 2 (Payment Gateway, Google Maps API)
 Total Unadjusted FP = 5 + 4 + 3 + 2 = 14 FP
Productivity rate: ~5 FP/person-month
 🔹 Effort = 14 / 5 = 2.8 person-months
🔹 Team = 2 developers
🔹 Time = ~1.5 months
Tools Needed:
 API Testing Tools (Postman)
 Firebase/SQL DB
 UI/UX tools (Figma)

Q6. What is Risk Management in-Software Projects? Outline the

Process of Identifying, Assessing and Mitigating Risks.
Risk Management is the process of identifying, analyzing, and responding to
potential risks that could affect the success of a software project. Process - Risk
Identification, Risk Assessment, Risk Mitigation
Q5. What are the advantages of SCM repository? Explain functions
performed by SCM repository.
Functions Performed by SCM Repository:
1. Version Management: Stores different versions of files and tracks changes over
time.
2. Configuration Identification: Manages and identifies configuration items like
source files, documents, and executables.
3. Change Control: Supports request, review, approval, and implementation of
changes.
4. Build Management: Maintains build scripts and supports automated builds.
5. Access Control: Controls user permissions to read/write files.
6. Audit and Reporting: Generates reports on changes, versions, and project
status.
7. Backup and Restore: Provides mechanisms for backing up and restoring stored
items.
8. Concurrent Access Management: Handles simultaneous editing and merging of
files by multiple users.
9. Release Management: Manages packaging and release of software versions.
[Link] Support: Links code with requirements, defects, and test cases for
impact analysis.
Advantages of SCM Repository:
1. Centralized Storage: All source code, documents, and related files are stored in
one central place.
2. Version Control: Keeps track of all changes, allowing rollback to previous
versions.
3. Collaboration: Multiple developers can work simultaneously without conflicts.
4. Audit Trail: Maintains history of who changed what and when for
accountability.
5. Backup and Recovery: Protects code from loss by maintaining backups.

Q5. Create a basic SCM plan for a web-based e-learning platform. What
components would you include and why?
1. Track Items - Code, database files, documents, images.
✅ Keeps everything organized.
2. Version Control - Use Git with GitHub.
✅ Helps manage changes and go back if needed.
3. Branching - main = live version , dev = testing
✅ Avoids breaking live site.
4. Change Management - Every update needs a review before merging.
✅ Reduces bugs.
5. Access Control - Only devs can change code, others read-only.
✅ Keeps it secure.
6. Backups - Daily backups of code and database.
✅ For safety in case of failure.
7. Release Tags - v1.0, v1.1, etc., with short notes.
✅ Easy to track updates.