Software Engineering – Complete Exam Guide 2025 | SDLC, Agile, Testing, DevOps

💻 Computer Science · Competitive Exam 2025

Software Engineering
Complete Exam Guide

SDLC · Waterfall · Agile · Spiral · V-Model · Testing · Design Principles · DevOps · Microservices · Scrum · Risk Management · 47 MCQs with Explanations — for GATE, SSC, IBPS, UPSC, NDA & all tech exams

GATE CSSSC CGLIBPS POUPSC GS-III NDA/CDSRBI Grade BBank InternalCampus Placements

📋 Table of Contents

1. What is Software Engineering? 2. SDLC — 6 Phases 3. Development Models 4. Model Comparison Table 5. Design Principles 6. Software Testing 7. Software Maintenance 8. Agile — Scrum, Kanban, XP 9. Project Management & Risk 10. Design Patterns 11. Emerging Trends 12. MCQ Practice (47 Qs) 13. Quick Revision Cards

💡

FoundationWhat is Software Engineering?

Software Engineering is the systematic, disciplined, and measurable approach to developing, operating, and maintaining software. It applies engineering principles to software development to ensure that software is reliable, efficient, maintainable, and delivered on time within budget.

⚡ Core Exam Facts

Goal: Produce reliable + economical + efficient software — all three together (so answer = “All of the above”)
Software characteristics: intangible, does not wear out, is reusable, but is NOT free from defects
SE bridges Computer Science (theory) and Project Management (practice)
Key models: Waterfall, Agile, Spiral, V-Model, Incremental, Prototype
Coined by: Margaret Hamilton (NASA, 1969 NATO conference)
IEEE definition: “the application of a systematic, disciplined, quantifiable approach to software development”

🔄

Most Frequently Tested — Know the OrderSoftware Development Life Cycle (SDLC)

PHASE 1

📋

Requirement Analysis

Gather & document client needs

PHASE 2

✏️

System Design

Build architecture & design specs

PHASE 3

💻

Implementation

Code the solution

PHASE 4

🧪

Testing

Detect and fix bugs

PHASE 5

🚀

Deployment

Release the software

PHASE 6

🔧

Maintenance

Update, fix & improve

🎯 SDLC — Exam Key Points

First phase = Requirement Analysis (NOT design, NOT coding)
Correct order: Requirement → Design → Implementation → Testing → Deployment → Maintenance
User Acceptance Testing (UAT) occurs in the Testing phase (not Design or Maintenance)
Each SDLC model handles these phases in a different order/style
Requirements document = most important output of Phase 1; basis for all future work

📐

Most Tested Topic in SESoftware Development Models

Model 1

🌊 Waterfall

“One-Way Street” Sequential / Linear

Each phase must be fully completed before the next begins. No going back. Like water flowing in one direction. Testing happens only after implementation is complete.

✅ Best For

Small, stable, well-defined requirements

❌ Worst For

Changing requirements, complex systems

Key Pros

Simple, clear milestones, good documentation

Key Cons

Rigid, bugs found late, no customer feedback

Model 2

🔁 Agile

“Adapt & Deliver” Iterative / Incremental

Work divided into short sprints (2–4 weeks). Customer continuously involved. Working software delivered frequently. Embraces changing requirements even late in development.

✅ Best For

Dynamic, complex, customer-driven projects

❌ Worst For

Projects needing fixed scope/timeline

Key Pros

Flexible, frequent feedback, early software

Key Cons

Less predictable, needs active customer

Model 3

🌀 Spiral

“Iterative + Risk Management” Iterative + Risk-driven

Combines Waterfall’s structure with Agile’s iteration. Each cycle (spiral) includes: Planning → Risk Analysis → Engineering → Evaluation. Risk is assessed at every phase. Best risk management of all models.

✅ Best For

High-risk, large, complex, evolving projects

❌ Worst For

Small projects; too expensive

Key Pros

Excellent risk control, early feedback

Key Cons

Complex, expensive, needs expert teams

Model 4

V️ V-Model

“Verification & Validation” Sequential + Test-parallel

Extension of Waterfall. Each development phase has a CORRESPONDING test phase planned simultaneously. Left side = development. Right side = testing. Testing starts early but execution is late. No working version until end.

✅ Best For

Critical systems — defence, medical, aerospace

❌ Worst For

Projects needing flexibility or prototypes

Key Pros

High quality, early test planning, clear structure

Key Cons

Inflexible, no early working version

Model 5

📦 Incremental

“Build in Parts” Iterative Releases

Software is built and delivered in multiple increments. First increment = core functionality. Each subsequent increment adds more features. Customer gets a working (partial) product early and provides feedback.

✅ Best For

Large projects with prioritised features

❌ Worst For

Projects needing the whole system at once

Key Pros

Early working software, reduced risk

Key Cons

Interfaces between increments may be complex

Model 6

🔬 Prototype

“Build to Learn” Exploratory

Build a quick, incomplete version (prototype) for customer to evaluate. Customer provides feedback. Prototype is refined or discarded and the real system is built. Good for unclear requirements.

✅ Best For

Unclear/evolving requirements, UI-heavy systems

❌ Worst For

Systems needing strict quality standards

Key Pros

Reduces misunderstanding, early feedback

Key Cons

May lead to “scope creep”, poor documentation

⚖️

Most Asked ComparisonModel Comparison Table

Feature	Waterfall	Agile	Spiral	V-Model	Incremental
Approach	Sequential	Iterative	Iterative + Risk	Sequential	Iterative releases
Requirements	Fixed upfront	Evolving (welcome changes)	May evolve	Fixed upfront	Prioritised
Customer Involvement	Low (only at start/end)	High (every sprint)	Medium (each cycle)	Low	Medium
Testing Phase	After implementation	Every sprint (continuous)	Each spiral	Planned early, run late	After each increment
Risk Management	Poor	Good	Excellent	Moderate	Good
Documentation	Heavy	Minimal	Moderate	Heavy	Moderate
Working Software	Only at end	Every sprint	Each spiral	Only at end	Each increment
Best For	Small, stable	Dynamic, complex	High-risk, large	Critical systems	Large, feature-rich
Memory Hook	One-Way Street	Sprints + Flexibility	Cycles + Risk Checks	Verify & Validate	Build in Parts

🎯 Quick Rule for Exam — Which Model?

Unclear requirements → Agile or Prototype
High risk / complex / large → Spiral
Critical system (defence, medical) → V-Model
Fixed, stable, small → Waterfall
V-Model is also called the Verification and Validation model
Agile testing = continuous | Waterfall testing = after implementation

🏗️

Frequently Tested DefinitionsSoftware Design Principles

Modularity

Divide into independent parts

Break system into separate, independent modules. Each module handles one specific function. Makes development, testing, and maintenance easier.

Abstraction

Hide unnecessary complexity

Show only essential features; hide implementation details from user. “What it does” not “how it does it.” Like a car’s steering wheel — you steer, not manage the mechanics.

Encapsulation

Bundle data + methods together

Wrapping data (variables) and methods (functions) into a single unit (class). Data is hidden from outside access. Foundation of Object-Oriented Programming (OOP).

Cohesion

High cohesion = GOOD

How closely related the functions within a single module are. High cohesion = module does one thing well. Low cohesion = module does many unrelated things (bad).

Coupling

Low coupling = GOOD

How much modules depend on each other. Low coupling = modules are independent, easy to change. High coupling = changing one breaks others (bad). Aim: high cohesion + low coupling.

✅ Design Principles — Exam Key Points

High Cohesion = GOOD | Low Coupling = GOOD (remember the opposites)
Abstraction = hide details | Encapsulation = bundle data + methods together
Modularity = the principle of dividing into independent parts (NOT cohesion, NOT abstraction)
SOLID principles = Single Responsibility, Open/Closed, Liskov, Interface Segregation, Dependency Inversion
Low coupling + High cohesion = well-designed, maintainable software

🧪

Very High Exam WeightSoftware Testing

Testing Levels — Bottom to Top (Unit → System)

🔬 Unit Testing

Test individual modules/functions by developers. First level. Catches bugs early. Developer performs — uses White Box testing knowledge.

🔗 Integration Testing

Test how modules work together. Verify interfaces between modules. Catches “glue” bugs. Primary purpose = verify module interactions.

⚙️ System Testing

Validate the complete, integrated system. Tests functional and non-functional requirements. Entire system tested as a whole.

✅ Acceptance Testing (UAT)

Final phase — customer verifies if software meets business requirements. User Acceptance Testing. Happens in the Testing phase of SDLC.

Testing Types

⬛ Black Box Testing

Tests software without knowledge of internal code. Tester only knows inputs and expected outputs. Focuses on functionality. Also called Functional Testing.

⬜ White Box Testing

Tests software with full knowledge of internal code. Tester examines code paths, branches, and logic. Also called Glass Box / Clear Box / Structural Testing.

🔄 Regression Testing

Ensures new code changes do not break existing functionality. Run after every bug fix or new feature addition. Critical for continuous development.

⚡ Performance Testing

Tests system behaviour under various load conditions. Includes Load Testing (normal), Stress Testing (beyond limit), and Spike Testing.

🛡️ Security Testing

Identifies vulnerabilities, threats, and risks in the software. Includes penetration testing, vulnerability scanning.

🔁 Smoke Testing

Preliminary testing to check if basic functions work before detailed testing. “Does it turn on?” type test. Quick sanity check.

🤖 Automated Testing

Uses scripts and tools to automatically run tests. Faster than manual, good for regression. Tools: Selenium, JUnit, TestNG.

👤 Manual Testing

Human tester manually executes test cases. More flexible for exploratory testing. Needed for UI/UX evaluation and new features.

🎯 Testing — Exam Key Points

Testing done without code knowledge = Black Box | With code = White Box
Regression testing = ensure new changes don’t break existing functionality
In Waterfall: testing only after implementation | In Agile: every sprint
Unit testing done by developers | UAT done by end users/clients
Integration testing purpose = verify interfaces between modules (not individual modules)
In Agile: testing after each sprint | V-Model: test planning early but execution late

Testing Type	Who Performs	When	Knowledge of Code	Purpose
Unit Testing	Developer	During implementation	Yes (White Box)	Test individual modules
Integration Testing	Developer/Tester	After unit testing	Partial	Test module interactions
System Testing	QA Team	After integration	No (Black Box)	Validate full system
UAT / Acceptance	End User/Client	Before deployment	No	Verify business requirements
Regression Testing	QA Team	After every change	Both	Ensure no breakage

🔧

CAPC — All 4 Types Must Be KnownSoftware Maintenance

🐛

Corrective

Fix bugs and defects discovered after delivery.

Example: Fix login crash reported by users

🌐

Adaptive

Modify software to work in changed environments (new OS, new hardware, new regulations).

Example: Update app for Windows 11 compatibility

⚡

Perfective

Add new features or improve performance based on user requests.

Example: Add dark mode to banking app

🛡️

Preventive

Restructure/optimise code to prevent future problems — improve maintainability.

Example: Refactor legacy code to reduce technical debt

📌 Maintenance Exam Tricks — CACP

Memory: C-A-P-P = Corrective (fix bugs) → Adaptive (new environment) → Perfective (add features) → Preventive (avoid future bugs)
Fixing bugs = Corrective | New OS support = Adaptive | New features = Perfective | Code refactoring = Preventive
Most expensive phase of SDLC = Maintenance (60-80% of total cost in long-running systems)

🔁

Very High Exam Weight — Know All RolesAgile Methodologies — Scrum, Kanban, XP

🏃 Scrum

Most popular Agile framework. Work divided into Sprints (2–4 weeks). Three key roles: Product Owner, Scrum Master, Development Team. Key artifacts: Product Backlog, Sprint Backlog, Burn-down Chart. Daily Stand-up meetings.

Key Roles: Product Owner (defines requirements) | Scrum Master (removes obstacles) | Dev Team (builds it)

📋 Kanban

Visual workflow management. Uses a Kanban Board with columns: To-Do → In Progress → Done. No fixed sprint timeboxes. Work items (cards) move through columns. Limits Work-in-Progress (WIP) to avoid overload.

Key Feature: Visual board | WIP limits | Continuous flow (not sprints)

⚡ Extreme Programming (XP)

Emphasises technical excellence. Key practices: Test-Driven Development (TDD), Pair Programming, Continuous Integration, Frequent small releases, Heavy customer involvement, Simple Design.

Key Feature: TDD + Pair Programming + Continuous Integration

Scrum Element	Description	Exam Role
Product Owner	Defines features, prioritises backlog, represents customer needs	Most asked Scrum role
Scrum Master	Facilitates the process, removes obstacles/impediments for the team	“Who removes obstacles?” = Scrum Master
Development Team	Cross-functional group that builds the product increment	Self-organising team
Product Backlog	Prioritised list of all features and requirements	Primary Scrum artifact
Sprint Backlog	Tasks committed for the current sprint	Subset of product backlog
Sprint	Time-boxed iteration (typically 2–4 weeks)	Unit of Agile work
Burn-down Chart	Shows remaining work vs time in a sprint	Progress tracking tool
Velocity	Amount of work completed in a sprint (measured in story points)	Team capacity metric

📊

Tools & Risk ManagementProject Management & Risk

Tool/Concept	What It Is	Used For
Gantt Chart	Bar chart showing tasks vs timeline	Project scheduling — most common answer in exams
PERT Chart	Program Evaluation and Review Technique — network diagram	Task dependencies and scheduling
CPM	Critical Path Method — finds longest path of tasks	Identifies which tasks cannot be delayed
Critical Path	The longest sequence of dependent tasks	Any delay on critical path = project delay
WBS	Work Breakdown Structure — hierarchical task decomposition	Breaking project into manageable pieces

Risk Management

Risk Type	Examples	Mitigation Approach
Project Risks	Budget overruns, schedule slippage, staffing	Detailed planning, buffer time, resource tracking
Technical Risks	System failures, technology incompatibilities, performance	Prototypes, testing, backup technologies
Business Risks	Changing market conditions, competitor moves, requirement changes	Market research, flexible architecture

📌 Risk Management Steps

Step 1: Risk Identification — what could go wrong?
Step 2: Risk Analysis — how likely + how severe?
Step 3: Risk Planning — what’s the mitigation strategy?
Step 4: Risk Monitoring — ongoing tracking throughout project
Risk mitigation = reducing the impact or probability of risk (not just identifying it)
Business risks include: changing market conditions (NOT budget overruns — that’s project risk)

Software Metrics & Quality

Metric	Full Form / Meaning	What It Measures
LOC	Lines of Code	Size of software — simple but crude measure
KLOC	Kilo Lines of Code (1000 lines)	Productivity and effort estimation
Defect Density	Defects per KLOC	Quality — number of bugs per 1000 lines
Cyclomatic Complexity	McCabe’s metric	Number of independent paths in code — measures complexity
Function Points	FP	Measures software functionality (independent of programming language)
MTBF	Mean Time Between Failures	Reliability — average time between system failures
MTTR	Mean Time to Repair	How quickly failures are fixed

🧩

Reusable Solutions to Common ProblemsDesign Patterns

Category	Pattern	What It Does	Exam One-liner
Creational	Singleton	Ensures only ONE instance of a class exists throughout the application	“Only one instance” = Singleton
Creational	Factory	Creates objects without specifying the exact class to create	“Create without knowing class” = Factory
Creational	Builder	Constructs complex objects step by step	“Step-by-step object creation” = Builder
Structural	Adapter	Converts one interface to another (compatibility layer)	“Convert one interface to another” = Adapter
Structural	Decorator	Adds behaviour to objects dynamically without changing class	“Add features dynamically” = Decorator
Behavioral	Observer	When one object changes, all dependent objects are notified automatically	“Notify on change” = Observer
Behavioral	Strategy	Define a family of algorithms and make them interchangeable	“Switch algorithms at runtime” = Strategy
Behavioral	Proxy	Provides a surrogate/placeholder to control access to another object	“Control access via placeholder” = Proxy

🚀

Current Affairs + Exam OverlapEmerging Trends in Software Engineering

⚙️ DevOps

Combines Development and Operations teams. Emphasises Continuous Integration (CI), Continuous Delivery (CD), Infrastructure as Code (IaC). Eliminates manual deployments. Goal: faster, reliable software delivery.

🔲 Microservices

Application built as small, independent, loosely coupled services. Each service handles one business function and can be deployed independently. Enables scalability, fault isolation, independent deployment. Opposite of monolithic architecture.

☁️ Cloud Computing

On-demand computing resources over the internet (AWS, Azure, GCP). IaaS (Infrastructure), PaaS (Platform), SaaS (Software). Enables elastic scaling, cost efficiency, global deployment.

🤖 AI in Software Engineering

AI tools that assist developers: automated code generation (GitHub Copilot), automated testing, AI-powered debugging, code review, requirements analysis. Reduces development time significantly.

🔗 API-First Development

Design APIs before building implementation. Enables parallel development of frontend and backend. RESTful APIs, GraphQL, gRPC are dominant. Foundation for microservices and integrations.

🔒 DevSecOps

Security integrated into DevOps pipeline from the start (“Shift Left Security”). Security testing automated in CI/CD. Static code analysis, dependency scanning, penetration testing in pipeline.

🌐 Serverless Architecture

Run code without managing servers. Functions execute on demand. Pay only for execution time. AWS Lambda, Azure Functions, Google Cloud Functions. Enables extreme scalability.

📱 Low-Code / No-Code

Build applications with minimal or no traditional coding. Visual drag-and-drop development. Enables non-developers to create apps. Growing rapidly for business workflows.

✅ Trends — Exam Key Facts

DevOps = Dev + Ops | Key: CI/CD, IaC | NOT: manual deployments (manual deployments are NOT DevOps)
Microservices key benefit = independent and scalable services (NOT centralized architecture)
Continuous Delivery = software is always production-ready
Cloud computing provides on-demand computing resources (AWS, Azure, GCP)
Singleton pattern = only one instance | Adapter = converts interface | Observer = notifies on change

📝

Tap Any Option to Reveal AnswerMCQ Practice — 47 Questions

Score: 0 / 0

CH.1Basics of Software EngineeringQ.01–Q.08

Q.01Basics🔥 Most Asked

What is the primary goal of software engineering?

✔ Correct: D — All of the above

Software engineering aims to produce software that is simultaneously reliable (works correctly), economical (within budget), and efficient (uses resources well). Not just one — all three.

Q.02Basics🔥 Most Asked

Which of the following is NOT a characteristic of software?

✔ Correct: C — Software is NOT free from defects

Software is intangible, reusable, and does not wear out physically. However, software is NOT free from defects — all real-world software contains bugs (just varying in severity).

Q.03SDLC🔥 Most Asked

Which is the FIRST step in the Software Development Life Cycle?

✔ Correct: B — Requirement Analysis

The first phase of SDLC is always Requirement Analysis — gathering and documenting what the client needs. Design comes 2nd, Implementation 3rd, Testing 4th. Correct order: Req → Design → Code → Test → Deploy → Maintain.

Q.04SDLC🔥 Most Asked

Which is the correct sequence of SDLC phases?

✔ Correct: B

Correct SDLC sequence: Requirement Analysis → Design → Implementation/Coding → Testing → Deployment → Maintenance. This is the foundation sequence — all models modify it but the logical order remains the same.

Q.05Models🔥 Most Asked

Which SDLC model is BEST suited for projects with unclear or frequently changing requirements?

✔ Correct: C — Agile

Agile is designed for projects with unclear or evolving requirements. It welcomes changing requirements even late in development. Waterfall and V-Model require fixed requirements upfront and are inflexible to change.

Q.06Models🔥 Most Asked

The primary advantage of the Spiral model over all other models is:

✔ Correct: B — Risk Management

The Spiral model’s defining feature = risk analysis at every spiral cycle. This makes it best for high-risk, large, complex projects. It combines Waterfall’s structure with Agile’s iteration, plus adds explicit risk management.

Q.07Models🔥 Most Asked

The V-Model is also known as:

✔ Correct: B — Verification and Validation model

The V-Model = Verification & Validation model. Each development phase (left side of V) has a corresponding test phase (right side of V). Best for critical systems where quality is paramount.

Q.08Models🔥 Most Asked

In the Waterfall model, testing is performed:

✔ Correct: B — After implementation only

In Waterfall, testing is performed only after the complete implementation phase. This is a major weakness — bugs are found very late. In Agile, testing happens every sprint (continuously).

CH.2Design Principles & Software MetricsQ.09–Q.20

Q.09Design🔥 Most Asked

Which principle emphasises dividing a program into independent modules?

✔ Correct: A — Modularity

Modularity = dividing the system into separate, independent modules. Each module has a specific purpose. Makes development, testing, and maintenance easier. Do NOT confuse with cohesion (which measures relatedness within a module).

Q.10Design🔥 Most Asked

The design principle that focuses on minimising interdependencies between modules is called:

✔ Correct: A — Low Coupling

Coupling = interdependency between modules. Low coupling = GOOD — modules are independent and changes in one don’t break others. High coupling = BAD. Remember: Low Coupling + High Cohesion = ideal design.

Q.11Design🔥 Most Asked

High cohesion is achieved when:

✔ Correct: A — Closely related functions

Cohesion = how closely related functions within a module are. High cohesion = GOOD — a module does ONE thing well. Low cohesion = BAD — module does many unrelated things. Goal: Single Responsibility.

Q.12Design

The design principle that focuses on hiding unnecessary details and showing only essential features is:

✔ Correct: A — Abstraction

Abstraction = hide unnecessary complexity, show only what matters. Like a car’s steering wheel — you drive without knowing engine mechanics. Do NOT confuse with Encapsulation (which bundles data + methods together).

Q.13Metrics🔥 Most Asked

Which metric measures the number of defects per thousand lines of code (KLOC)?

✔ Correct: A — Defect Density

Defect Density = number of defects / KLOC. Measures code quality — lower defect density = higher quality. Cyclomatic Complexity measures code complexity (number of independent paths). Function Points measure functionality independent of LOC.

Q.14Metrics

Which metric specifically measures software COMPLEXITY?

✔ Correct: B — Cyclomatic Complexity

Cyclomatic Complexity (McCabe’s metric) measures the number of linearly independent paths through the code. Higher value = more complex code = harder to test and maintain.

Q.15Metrics🔥 Most Asked

Software reliability is measured in terms of:

✔ Correct: C — Both MTBF and MTTR

MTBF (Mean Time Between Failures) = average time between system failures. MTTR (Mean Time to Repair) = average time to fix a failure. Together they define software reliability comprehensively.

Q.16Quality🔥 Most Asked

Which quality factor ensures that software meets user requirements?

✔ Correct: A — Correctness

Correctness = software meets all specified requirements exactly. It’s the most fundamental quality factor. Usability = user-friendly. Reliability = works without errors. Maintainability = easy to update.

Q.17Quality

Maintainability in software measures:

✔ Correct: C — Ease of making changes

Maintainability = how easily software can be modified, updated, and extended over its lifetime. High maintainability = low cost of changes. Achieved through good design (low coupling, high cohesion, modularity).

Q.18Design

The primary goal of ABSTRACTION in software design is to:

✔ Correct: A — Hide unnecessary details

Abstraction = show only what’s needed, hide complexity. Like using a TV remote — you press buttons without knowing circuit board logic. Bundling data + functions = Encapsulation (different concept).

Q.19Design

Which design principle ensures all interactions within a module are closely related?

✔ Correct: C — High Cohesion

Cohesion measures how closely the functions within a single module are related. High cohesion = GOOD. A well-designed module should do ONE thing and do it well (Single Responsibility Principle).

Q.20Models

Which model is best suited for high-risk and complex requirements?

✔ Correct: C — Spiral

The Spiral model is specifically designed for high-risk, large, complex projects. Risk analysis happens in every spiral cycle. It combines the best of Waterfall (structure) and Agile (iteration) with explicit risk management.

CH.3Software Testing & MaintenanceQ.21–Q.33

Q.21Testing🔥 Most Asked

Which type of testing is performed WITHOUT knowledge of the internal code?

✔ Correct: A — Black Box Testing

Black Box Testing = no knowledge of internal code. Tests only inputs and expected outputs (functional behaviour). White Box Testing = full code knowledge, examines internal paths and logic.

Q.22Testing🔥 Most Asked

What is the purpose of REGRESSION testing?

✔ Correct: C — Ensure new changes don’t break existing functionality

Regression Testing = re-run tests after every code change to ensure nothing previously working is now broken. Critical in continuous development — run after every bug fix, refactor, or new feature.

Q.23Testing🔥 Most Asked

In which testing phase do developers perform code testing?

✔ Correct: C — Unit Testing

Unit Testing is performed by developers during implementation. Tests individual modules/functions in isolation. First and most fundamental testing level. White box knowledge used.

Q.24Testing🔥 Most Asked

The primary purpose of INTEGRATION testing is to:

✔ Correct: B — Verify interfaces between modules

Integration Testing tests how modules work together — specifically the interfaces between them. Individual modules are already tested in unit testing; now we test that they interact correctly when combined.

Q.25Testing

In which SDLC phase does User Acceptance Testing (UAT) occur?

✔ Correct: C — Testing phase

User Acceptance Testing (UAT) happens in the Testing phase of SDLC, as the final acceptance testing sub-level. It’s performed by end users/clients to verify the software meets business requirements before deployment.

Q.26Maintenance🔥 Most Asked

Fixing bugs discovered in software AFTER it has been delivered to users is called:

✔ Correct: C — Corrective maintenance

Corrective maintenance = fixing bugs/defects found after delivery. Memory: C-A-P-P: Corrective (fix bugs) → Adaptive (new environment) → Perfective (add features) → Preventive (avoid future bugs).

Q.27Maintenance🔥 Most Asked

Modifying software to support a NEW OPERATING SYSTEM is an example of:

✔ Correct: B — Adaptive maintenance

Adaptive maintenance = modifying software to work in a changed environment (new OS, new hardware, new API, new legal regulation). The software isn’t broken — the environment changed.

Q.28Maintenance🔥 Most Asked

Adding NEW FUNCTIONALITY to software after deployment is an example of:

✔ Correct: C — Perfective maintenance

Perfective maintenance = enhancing software with new features or improving performance based on user requests. Adding dark mode, new reports, performance improvements = Perfective.

Q.29Testing

Which chart is MOST commonly used for project scheduling?

✔ Correct: B — Gantt chart

A Gantt chart is the standard tool for project scheduling. It shows tasks on the Y-axis, time on X-axis, and bars representing task duration and sequence. Most recognised project management tool in exams.

Q.30Project🔥 Most Asked

The critical path in project management is defined as:

✔ Correct: A — Longest sequence of dependent tasks

The Critical Path = the longest path through the project network (not shortest). Any delay on the critical path = direct delay to project completion. Tasks not on critical path have “float” (slack) time.

Q.31Risk🔥 Most Asked

Business risks in software engineering include:

✔ Correct: C — Changing market conditions

Business risks = market-related risks (competitor moves, market demand changes, regulatory changes). Schedule slippage/budget = Project risks. Technical incompatibilities = Technical risks.

Q.32Risk

Risk mitigation involves:

✔ Correct: D — All of the above

Risk Mitigation is the complete process: Identify → Analyze → Plan (mitigation strategies) → Monitor (ongoing). All steps together constitute risk mitigation in software projects.

Q.33Testing

Which type of testing is performed WITHOUT knowledge of internal code, testing only functionality?

✔ Correct: A — Black Box Testing

Black Box = Functional Testing. No code knowledge needed. Tests only “does the output match expected output for given input?” System Testing and UAT are typically Black Box. White Box = Structural/Glass Box Testing (uses code knowledge).

CH.4Agile, DevOps & Emerging TrendsQ.34–Q.47

Q.34Agile🔥 Most Asked

In Agile methodology, work is divided into:

✔ Correct: B — Iterations or Sprints

In Agile, work is divided into short time-boxed iterations called Sprints (in Scrum, typically 2–4 weeks). Each sprint produces a working increment of software with features tested and ready to ship.

Q.35Agile🔥 Most Asked

The primary artifact used to manage work in Scrum is:

✔ Correct: B — Product Backlog

The Product Backlog = prioritised list of all features, requirements, and work items for the project. Owned by the Product Owner. The Sprint Backlog is a subset selected for the current sprint.

Q.36Agile🔥 Most Asked

In Scrum, who is responsible for removing obstacles faced by the development team?

✔ Correct: B — Scrum Master

The Scrum Master‘s primary role = facilitate the Scrum process and remove impediments/obstacles that block the team. Product Owner = defines requirements and prioritises backlog. Dev Team = builds the product.

Q.37Agile

What is a key feature of the Agile model compared to Waterfall?

✔ Correct: B — Iterative, incremental, continuous feedback

Agile’s defining features vs Waterfall: iterative (repeating cycles), incremental (built piece by piece), continuous customer feedback, and working software delivered frequently. Agile Manifesto values working software over documentation.

Q.38DevOps🔥 Most Asked

Which practice is NOT part of DevOps?

✔ Correct: C — Manual deployments are NOT DevOps

DevOps principles: Continuous Integration, Continuous Delivery, Infrastructure as Code, automated testing. Manual deployments are the exact opposite of DevOps — DevOps automates the entire pipeline.

Q.39DevOps🔥 Most Asked

Continuous Delivery (CD) in DevOps ensures that:

✔ Correct: A — Software is always production-ready

Continuous Delivery ensures that the main codebase is always deployable — every code change passes automated tests and can be released to production at any time. It does NOT eliminate all testing — it automates it.

Q.40Trends🔥 Most Asked

The Singleton design pattern ensures:

✔ Correct: B — Only one instance

Singleton pattern = a class that allows only ONE instance to be created. All parts of the application share this single instance. Common use: database connection, logging system, configuration manager.

Q.41Trends🔥 Most Asked

Which design pattern is used to CONVERT one interface to another (compatibility layer)?

✔ Correct: A — Adapter pattern

Adapter pattern = converts interface of a class to another interface clients expect. Like a power plug adapter. Observer = notify on change. Builder = step-by-step construction. Proxy = access control.

Q.42Trends🔥 Most Asked

Which is NOT a benefit of microservices architecture?

✔ Correct: C — Centralized monolithic architecture is NOT microservices

Microservices is the opposite of centralized monolithic architecture. Microservices = small, independent, loosely coupled services. Benefits: scalability, independent deployment, fault isolation, technology flexibility.

Q.43Trends🔥 Most Asked

Which technology supports on-demand computing resources over the internet?

✔ Correct: B — Cloud Computing

Cloud Computing = on-demand computing resources (servers, storage, databases, networking) over the internet. Examples: AWS (Amazon), Azure (Microsoft), Google Cloud. Three models: IaaS, PaaS, SaaS.

Q.44Agile

Kanban is different from Scrum because Kanban:

✔ Correct: C — Continuous flow, no fixed sprints

Kanban = visual workflow with To-Do → In Progress → Done columns. No fixed sprints — work flows continuously. WIP (Work in Progress) limits prevent overloading. Scrum = fixed sprints with defined roles.

Q.45DevOps

Which of the following is NOT a principle of DevOps?

✔ Correct: C — Manual code review only is NOT DevOps

DevOps doesn’t eliminate code review but uses automated quality gates (automated testing, static analysis) as part of CI/CD pipeline. Manual-only review is a bottleneck DevOps seeks to eliminate by complementing it with automation.

Q.46Trends

Which design pattern is used when you want dependant objects to be automatically notified of state changes?

✔ Correct: C — Observer pattern

Observer pattern = when one object (subject/publisher) changes state, all its dependent objects (observers/subscribers) are automatically notified and updated. Used in event systems, notification services, UI frameworks.

Q.47Comprehensive🔥 Most Asked

The primary benefit of microservices architecture in software engineering is:

✔ Correct: B — Independent, scalable services

The key benefit of Microservices: each service is independent (can be developed, deployed, and scaled independently), loosely coupled, and isolated. A failure in one service doesn’t crash the entire application — fault isolation is a core benefit.

⚡

Last-Minute PrepQuick Revision Flash Cards

💡 SE Basics

Goal: Reliable + Economical + Efficient = All three
Software: intangible, reusable, does not wear out
Software is NOT free from defects
SDLC first step: Requirement Analysis

🌊 Waterfall

Sequential, linear, documentation-heavy
Testing: after implementation only
Hook: “One-Way Street”
Best for: small, stable, fixed requirements

🔁 Agile

Iterative sprints, flexible, continuous testing
Hook: “Sprints + Flexibility”
Best for: unclear, dynamic requirements
Testing: every sprint

🌀 Spiral

Iterative + Risk analysis every cycle
Hook: “Cycles + Risk Checks”
Best for: high-risk, large, complex projects
Most expensive model

V️ V-Model

= Verification & Validation model
Each dev phase has matching test phase
Hook: “Verify & Validate”
Best for: critical systems (defence, medical)

🏗️ Design Principles

High Cohesion = GOOD (related functions in module)
Low Coupling = GOOD (less interdependency)
Abstraction = hide complexity
Encapsulation = bundle data + methods

🧪 Testing

Black Box = no code knowledge
White Box = full code knowledge
Regression = ensure new changes don’t break
Unit → Integration → System → UAT

🔧 Maintenance (CAPP)

Corrective = fix bugs
Adaptive = new environment (OS, hardware)
Perfective = add new features
Preventive = avoid future problems

🏃 Scrum Roles

Product Owner = defines requirements, prioritises backlog
Scrum Master = removes obstacles, facilitates
Dev Team = builds the product
Sprint = 2–4 weeks | Backlog = priority list

⚙️ DevOps

Dev + Ops integration
CI/CD = Continuous Integration / Delivery
IaC = Infrastructure as Code
NOT DevOps: manual deployments
Continuous Delivery = always production-ready

🧩 Design Patterns

Singleton = only ONE instance
Adapter = converts interface
Observer = notify on change
Creational | Structural | Behavioral = 3 categories

📊 Metrics

Defect Density = defects per KLOC
Cyclomatic Complexity = code complexity paths
MTBF = reliability (time between failures)
MTTR = time to repair failures
Critical Path = longest path in project

📌 Must-Know Keywords

SDLCWaterfallAgileScrum SpiralV-ModelGantt Chart Black BoxRegression Testing Corrective MaintenanceAdaptive Maintenance DevOps CI/CDMicroservices SingletonObserverAdapter Pattern

📚 Exam Focus: SE goal = reliable+economical+efficient (All of above) · SDLC first step = Requirement Analysis · Correct order: Req→Design→Code→Test→Deploy→Maintain · Agile = unclear requirements · Spiral = high risk · V-Model = Verification & Validation (defence/medical) · Waterfall testing = after implementation · Black Box = no code knowledge · Regression = ensure no breakage · Unit Testing done by developers · Scrum Master removes obstacles · DevOps NOT manual deployments · Singleton = one instance · Adapter = interface conversion · Observer = notify on change · Microservices = NOT centralized · Continuous Delivery = always production-ready · Critical Path = LONGEST sequence

© GyanDesk — Software Engineering Guide | GATE · SSC · IBPS · UPSC · NDA · Bank Exams 2025