Software Engineering

Unit 1 — Introduction & SDLC Models

📚 Chapters

📘 Chapter 1 — Introduction to Software Engineering
📘 INTRODUCTION — MIND MAP
Software & SE → Programs + Documentation + Operating Procedures
Need for SE → Handle complexity, quality, deadlines, cost control
Program vs Product → Small vs Large, Single user vs Many users
SDLC → Requirements → Design → Implementation → Testing → Maintenance
Models → Waterfall, Agile, Spiral, V-Model, Evolutionary

1.1 What is Software?

📖 Definition: Software is a collection of programs, documentation, and operating procedures that enable a computer system to perform specific tasks.
💡 Components of Software:
  • Programs: Executable code (the actual software)
  • Documentation: User manuals, technical guides, help files
  • Operating Procedures: How to install, configure, use the software

Example: Microsoft Word = .exe file (program) + User manual (documentation) + Installation guide (procedures)

⚠️ Common Misconception: Software ≠ Just Code. It includes documentation and procedures too!

1.2 What is Software Engineering?

📖 Definition: Software Engineering is the systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software. It applies engineering principles to software development.
💡 Real-life Analogy — Building a Bridge:

Building a bridge requires:

  • Planning (requirements, blueprints)
  • Engineering principles (physics, materials science)
  • Quality standards (safety regulations)
  • Testing (stress tests before opening)
  • Maintenance (regular inspections, repairs)

Similarly, Software Engineering applies systematic methods to build reliable, maintainable software.

How SE Principles are Useful:

✅ 1. Systematic Development: Follow structured processes (not random coding).
✅ 2. Quality Assurance: Built-in testing, reviews ensure high quality.
✅ 3. Time & Cost Management: Planning prevents delays and budget overruns.
✅ 4. Team Collaboration: Clear roles, communication standards for large teams.
✅ 5. Maintainability: Well-documented code easy to update and fix.

1.3 Need for Software Engineering

❌ Problems Without Software Engineering:
  • Software Crisis (1960s-70s): Projects failed, budgets exceeded, quality poor
  • No systematic approach → chaos, confusion
  • Couldn't handle large, complex systems
  • High maintenance costs (fixing bugs all the time)

Why We Need SE:

✅ 1. Handle Complexity:
Modern software (like Facebook, WhatsApp) has millions of lines of code. SE provides methods to manage this complexity.
✅ 2. Meet Deadlines:
SE planning and scheduling ensure projects finish on time.
✅ 3. Control Costs:
Proper estimation and budgeting prevent money waste.
✅ 4. Ensure Quality:
Testing, reviews, standards ensure software works correctly and reliably.
✅ 5. Reduce Maintenance Cost:
Good design and documentation make fixing bugs and adding features easier (cheaper).
✅ 6. Customer Satisfaction:
Meeting requirements, delivering quality product makes customers happy.

1.4 Difference Between Program and Product

📖 Program: A small piece of code written to solve a specific problem, typically used by the developer themselves or a small group.

📖 Product (Software): A complete software package designed for many users, with documentation, support, updates, and quality standards.
Aspect Program Product (Software)
Size Small (hundreds of lines) Large (millions of lines)
Users Single user or small team Many users (thousands/millions)
Purpose Solve one specific task Multiple features, many tasks
Documentation Usually none or minimal Comprehensive (manuals, help)
Testing Informal testing by developer Rigorous testing by QA team
Maintenance Not needed or minimal Regular updates, bug fixes
Support None Customer support, helpdesk
Example Calculator script for personal use Microsoft Excel, WhatsApp
💡 Real Example:
Program: You write a Python script to calculate your monthly expenses. Only you use it.
Product: Quicken (accounting software) used by millions, with installation wizard, user manual, customer support, automatic updates.
Key Difference: Program → Quick solution for yourself. Product → Engineered solution for customers with quality, support, maintenance.

1.5 Software Development Life Cycle (SDLC)

📖 SDLC: A structured process that defines the phases involved in developing software from initial concept to deployment and maintenance. It's a roadmap for building software systematically.
💡 Real-life Analogy — Making a Movie:
  • Planning: Story idea, script, budget
  • Pre-production: Cast, locations, sets
  • Production: Actual filming
  • Post-production: Editing, effects, sound
  • Release: Theaters, marketing
  • Feedback: Reviews, updates for streaming

Similarly, SDLC breaks software development into clear phases.

SDLC Phases:

Phase 1 — Requirements Analysis:

Understand what the customer wants. Gather and document requirements.

Example: "We need an online shopping website with cart, payment, order tracking."

Phase 2 — Design:

Plan HOW to build it. Create architecture, database design, UI mockups.

Example: Design database tables (Users, Products, Orders), sketch homepage layout.

Phase 3 — Implementation (Coding):

Write actual code based on design. Developers build the software.

Example: Code the login page, shopping cart functions in JavaScript/PHP.

Phase 4 — Testing:

Check if software works correctly. Find and fix bugs.

Example: Test if "Add to Cart" button works, payment processes correctly.

Phase 5 — Deployment:

Release software to users. Make it live/available.

Example: Upload website to server, make it accessible at www.shop.com

Phase 6 — Maintenance:

Fix bugs found by users, add new features, update as needed.

Example: Fix checkout bug, add "Wishlist" feature based on user feedback.

SDLC Flow: ┌─────────────────┐ │ Requirements │ ← What to build? └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Design │ ← How to build? └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Implementation │ ← Build it (code) └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Testing │ ← Does it work? └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Deployment │ ← Release to users └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Maintenance │ ← Bug fixes, updates └─────────────────┘ │ │ (Loop back if changes needed) └──────────┐ │ ▼
Fig 1.1 — SDLC Phases
💡 Key Point: SDLC ensures we don't just start coding randomly. We plan, design, then code → results in better quality software.

1.6 SDLC Models

📖 SDLC Model: A framework that defines the process for developing software. Different models follow different approaches to organize the SDLC phases.
💡 Key Point: No single model is "best" — choice depends on project type, size, requirements stability, team experience.

1.6.1 Waterfall Model

📖 Waterfall Model: A linear, sequential approach where each phase must be completed before the next begins. Like water flowing down stairs — can't go back up.
💡 Real-life Analogy — Building Construction:

When building a house:

  • Foundation → Can't build walls before foundation
  • Walls → Can't add roof before walls complete
  • Roof → Can't do interior before roof

Similarly, Waterfall follows strict sequence: Requirements → Design → Code → Test → Deploy

Waterfall Model Flow: ┌─────────────────────────┐ │ 1. Requirements │ │ Analysis │ └───────────┬─────────────┘ │ ▼ ┌─────────────────────────┐ │ 2. System Design │ │ │ └───────────┬─────────────┘ │ ▼ ┌─────────────────────────┐ │ 3. Implementation │ │ (Coding) │ └───────────┬─────────────┘ │ ▼ ┌─────────────────────────┐ │ 4. Testing │ │ │ └───────────┬─────────────┘ │ ▼ ┌─────────────────────────┐ │ 5. Deployment │ │ │ └───────────┬─────────────┘ │ ▼ ┌─────────────────────────┐ │ 6. Maintenance │ │ │ └─────────────────────────┘ Flow is ONE-WAY (like waterfall)
Fig 1.2 — Waterfall Model

Advantages of Waterfall:

✅ Simple & Easy to Understand: Clear phases, everyone knows what comes next.
✅ Well-Documented: Each phase produces documents (requirements doc, design doc).
✅ Easy to Manage: Project managers can track progress easily (phase-wise).
✅ Works for Stable Requirements: If requirements won't change, Waterfall is efficient.

Disadvantages (Deficiencies) of Waterfall:

❌ 1. No Going Back: Hard to change requirements once you're in coding phase. Changes = very expensive.
❌ 2. Late Testing: Testing happens AFTER coding. If major bugs found → costly to fix.
❌ 3. No Working Software Until End: Customer sees product only at the end. If they don't like it → problem!
❌ 4. Not Good for Complex Projects: Large projects always have changing requirements. Waterfall can't handle this.
❌ 5. Assumes Perfect Requirements: In reality, customers often don't know exactly what they want until they see it.
💡 When to Use Waterfall:
  • Requirements are clear, stable, well-understood
  • Technology is familiar (no new tech learning needed)
  • Short projects with fixed deadlines
  • Small projects where changes unlikely
Example: Payroll system for a company (requirements clear and stable).

1.6.1b Iterative Waterfall Model

📖 Iterative Waterfall Model: It is an updated version of the classical waterfall model. It allows "feedback paths" from any phase to its previous phases so that errors can be corrected.
✅ Key Fix: Classical Waterfall assumes no mistakes are made. Iterative Waterfall acknowledges human errors and lets you go back to fix them!
🔄 How it works: If a bug is found during the testing phase, feedback is sent back to the coding or design phase immediately to fix the defect.
Iterative Waterfall Feedback Paths: [Req Analysis] ◄──────┐ │ │ ▼ │ Feedback [Design] ◄─────────│──────┐ │ │ │ ▼ │ │ [Coding] ◄─────────┘ │ Feedback │ │ ▼ │ [Testing] ─────────────────┘ │ ▼ [Maintenance] * Arrows going BACK represent "Feedback Paths" to fix errors.
Fig 1.6 — Iterative Feedback Loop

1.6.2 Prototype & Evolutionary Model

📖 Prototype Model: Build a quick, simplified version of the software first (prototype). Show it to customer, get feedback, then build the actual system.

📖 Evolutionary Model: Build software in increments. Each version adds more features. Software evolves gradually.
💡 Real-life Analogy — Designing a Car:

Prototype: Build a clay model or 3D render first. Show to customer. Get feedback ("make it sportier"). Then build actual car.

Evolutionary: Release basic car first (engine, wheels, seats). Then add features in updates (GPS, sunroof, advanced brakes).

Strengths of Evolutionary Model:

✅ 1. Early Feedback: Customer sees working software early. Can suggest changes before full development.
✅ 2. Flexible to Changes: Requirements can evolve. Each iteration can adjust based on feedback.
✅ 3. Reduced Risk: Problems discovered early (in first iteration), not at the end.
✅ 4. Customer Involvement: Customer actively participates, sees progress, feels involved.
✅ 5. Handles Unclear Requirements: Perfect when customer doesn't know exactly what they want initially.
❌ Disadvantages:
  • Can be time-consuming (multiple iterations)
  • May lack proper documentation
  • Hard to estimate total cost/time
💡 When to Use: When requirements are unclear, customer wants to see early versions, innovative/new projects.

1.6.3 Spiral Model

📖 Spiral Model: Combines Waterfall and Prototype models. Develops software in spirals (loops). Each loop includes: Planning → Risk Analysis → Development → Evaluation. Focus on RISK management.
💡 Real-life Analogy — Climbing a Mountain:

You don't go straight to top. You climb in stages:

  • Loop 1: Reach base camp, assess risks (weather, oxygen)
  • Loop 2: Climb higher, check health, adjust plan
  • Loop 3: Continue, manage new risks, adapt

Each loop = evaluate risks before proceeding.

Spiral Model (4 Quadrants per loop): Planning │ ▼ Risk ← ─────── → Development Analysis (Build) │ ▼ Evaluation (Customer) Each spiral loop: 1. Planning → Define objectives 2. Risk Analysis → Identify & resolve risks 3. Development → Build & test 4. Evaluation → Customer review, plan next loop Loop 1: Core features Loop 2: Add more features Loop 3: Complete system ...
Fig 1.3 — Spiral Model

Advantages of Spiral:

✅ Risk Management: Focus on identifying and reducing risks early.
✅ Flexible: Can accommodate changes at any stage.
✅ Customer Feedback: Customer reviews after each spiral.
✅ Good for Large Projects: Handles complexity well.
❌ Disadvantages:
  • Expensive (risk analysis costs time & money)
  • Requires expert risk analysts
  • Not suitable for small projects
💡 When to Use Spiral: Large, complex, expensive projects where risk management critical. Example: Banking systems, aerospace software.

1.6.4 Incremental Development Model

📖 Incremental Model: Software is developed and delivered in pieces (increments). Each increment adds more functionality. First increment = core features, then gradually add more.
💡 Real-life Example — Building a Website:
  • Increment 1: Homepage + basic navigation (deploy this first!)
  • Increment 2: Add user login & registration
  • Increment 3: Add shopping cart
  • Increment 4: Add payment gateway

Users can start using website after Increment 1. Features added gradually.

Incremental Model: Increment 1: [Requirements → Design → Code → Test] → Deploy ✓ Core features working Increment 2: [Requirements → Design → Code → Test] → Deploy ✓ Add more features Increment 3: [Requirements → Design → Code → Test] → Deploy ✓ Add even more features Each increment = working software delivered
Fig 1.4 — Incremental Model

Differences: Incremental vs Spiral

Aspect Incremental Spiral
Focus Add features gradually Manage risks
Delivery Each increment = working software Each spiral = prototype/version
Risk Analysis Not emphasized Core focus (every loop)
Cost Moderate High (risk analysis expensive)
Best For Medium projects, web apps Large, high-risk projects
Example E-commerce site (add features) Space shuttle software
✅ Incremental Advantages:
  • Working software delivered early
  • Customer starts using basic version soon
  • Easier to test (smaller pieces)
  • Reduces initial delivery time

1.6.5 V-Model (Verification & Validation)

📖 V-Model: Extension of Waterfall with strong emphasis on testing. Forms a "V" shape — each development phase has a corresponding testing phase. Left side = development, Right side = testing.
V-Model: Requirements ─────────────────────→ Acceptance Testing │ ▲ ▼ │ Design ──────────────────────────→ System Testing │ ▲ ▼ │ Detailed Design ─────────────────→ Integration Testing │ ▲ ▼ │ Coding ───────────────────────────→ Unit Testing Left side = Build it Right side = Test it Each phase has matching test
Fig 1.5 — V-Model

V-Model Testing Phases:

1. Unit Testing: Test individual modules/functions (corresponds to coding).
2. Integration Testing: Test how modules work together (corresponds to detailed design).
3. System Testing: Test entire system as a whole (corresponds to system design).
4. Acceptance Testing: Customer tests if it meets requirements (corresponds to requirements phase).
✅ V-Model Advantages:
  • Testing planned early (not an afterthought)
  • Defects found early in corresponding phase
  • Works well for small/medium projects
  • Clear structure, easy to understand
❌ V-Model Disadvantages:
  • Rigid like Waterfall (hard to change)
  • No early prototypes
  • Not good if requirements unclear

1.6.6 Agile Software Development

📖 Agile: An iterative, incremental approach that emphasizes flexibility, collaboration, customer feedback, and rapid delivery of working software. Embraces change rather than fighting it.
💡 Real-life Analogy — Cooking with Feedback:

Traditional (Waterfall): Get complete recipe, buy all ingredients, cook entire meal, serve. If customer doesn't like it → too late!

Agile: Make a small portion, taste (feedback), adjust spices, make more, taste again, adjust. Continuous improvement based on feedback!

Characteristics of Agile:

✅ 1. Iterative & Incremental: Work in short cycles (sprints, usually 2-4 weeks). Each sprint delivers working software.
✅ 2. Customer Collaboration: Customer is actively involved throughout. Frequent demos and feedback sessions.
✅ 3. Embrace Change: Requirements can change anytime. Agile welcomes changes even late in development.
✅ 4. Self-Organizing Teams: Team decides how to do work (not micromanaged). High autonomy and ownership.
✅ 5. Working Software Over Documentation: Focus on delivering working product, not creating tons of documents.
✅ 6. Face-to-Face Communication: Daily stand-up meetings. Direct communication preferred over emails.

Agile Manifesto (4 Core Values):

Agile Manifesto Values: 1. Individuals and interactions OVER processes and tools → People matter more than rigid procedures 2. Working software OVER comprehensive documentation → Deliver product, not just documents 3. Customer collaboration OVER contract negotiation → Work WITH customer, not against 4. Responding to change OVER following a plan → Adapt to changes, don't stick to old plan While right side has value, Agile values LEFT side MORE.

Core Principles of Agile:

1. Customer Satisfaction: Deliver valuable software early and continuously.
2. Welcome Change: Even late requirements changes are welcome.
3. Frequent Delivery: Deliver working software frequently (weeks, not months).
4. Daily Collaboration: Business people and developers work together daily.
5. Motivated Teams: Build projects around motivated individuals. Trust them to get job done.
6. Face-to-Face: Most efficient communication is face-to-face conversation.
7. Working Software = Progress: Working software is primary measure of progress.
8. Sustainable Pace: Work at sustainable pace (no burnout). Maintain constant pace indefinitely.
9. Technical Excellence: Continuous attention to technical excellence and good design.
10. Simplicity: Maximize the amount of work NOT done (keep it simple).
11. Self-Organizing: Best architectures/designs emerge from self-organizing teams.
12. Reflect & Adjust: Team reflects on how to be more effective, then tunes behavior.
💡 How Agile Enhances Adaptability, Communication & Collaboration:

Adaptability: Short sprints + welcome changes = quickly adapt to new requirements, market changes, customer feedback.

Communication: Daily stand-ups, face-to-face talks, frequent demos = everyone knows what's happening. No surprises.

Customer Collaboration: Customer is part of team, sees progress every sprint, gives feedback immediately = final product matches customer vision.

Result: Faster delivery, higher quality, happier customers, motivated teams!
✅ Agile Advantages:
  • Quick delivery of working software
  • High customer satisfaction (continuous involvement)
  • Handles changing requirements well
  • Early detection of issues (frequent testing)
  • Team morale high (autonomy, collaboration)
❌ Agile Challenges:
  • Requires experienced, self-disciplined team
  • Less documentation (can be problem for maintenance)
  • Hard to estimate total cost/time upfront
  • Needs active customer involvement (time commitment)

1.7 SDLC Models Comparison

Model Approach Best For Key Feature
Waterfall Linear, sequential Small, stable requirements Simple, well-documented
Prototype Build sample first Unclear requirements Early customer feedback
Spiral Risk-driven loops Large, risky projects Focus on risk management
Incremental Build in pieces Medium projects Gradual feature addition
V-Model Testing at each stage Small/medium, clear requirements Strong testing emphasis
Agile Iterative, flexible Changing requirements Embraces change, collaboration
📋 Chapter 2 — Software Requirements
📋 REQUIREMENTS — MIND MAP
Requirement Analysis → Understand what customer wants
Types → Functional (what system does) vs Non-functional (how it performs)
SRS → Software Requirements Specification document
Prototyping → Build sample to clarify requirements
Data Modeling → ER diagrams, database design

2.1 Requirements Analysis

📖 Requirements Analysis: The process of gathering, documenting, and understanding what the customer wants from the software. It's the foundation of successful software development.
💡 Real-life Analogy — Doctor's Diagnosis:

Before treating a patient, doctor must:

  • Ask questions (symptoms?)
  • Listen carefully (understand the problem)
  • Document (write prescription, medical record)

Similarly, requirements analysis = understand customer's "symptoms" (needs) before "prescribing" (building) software.

Impact of Inadequate Requirement Analysis:

❌ If requirements are poorly analyzed:

1. Project Cost Increases: Building wrong features → waste money → have to redo work.
Example: Build e-commerce site without payment feature → customer says "we need payments!" → costly to add later.

2. Software Quality Suffers: Unclear requirements → developers guess → bugs, missing features.
Example: "Make it user-friendly" is vague → developers interpret differently → customer unhappy with result.

3. Development Schedule Delayed: Changing requirements mid-project → rework → deadlines missed.
Example: Halfway through coding, customer says "Actually, we need mobile app too" → months of delay.

4. Customer Dissatisfaction: Final product doesn't match expectations → customer refuses to pay/accept.

5. Team Frustration: Constantly changing requirements → developers demoralized → productivity drops.
✅ Good Requirement Analysis Prevents:
  • Scope creep (uncontrolled feature additions)
  • Miscommunication between customer and developers
  • Building the wrong product
  • Budget overruns and delays

2.1.1 Analysis Principles

📖 Analysis Principles: Basic rules or guidelines that a software engineer must follow when analyzing requirements. These ensure we fully understand what to build.
🔑 Core Principles (Rules):

1. Understand the Information Domain: Know exactly what data goes IN (input), how it changes, and what data comes OUT (output).

2. Define Software Functions: Clearly list every feature and function the software must do.

3. Represent System Behavior: Understand how the software will react to user actions (e.g., what happens when user clicks 'Submit'?).

4. Partition the Models (Modularity): Break down big, complex requirements into smaller, manageable pieces.

5. Focus on WHAT, not HOW: Requirements analysis is about WHAT the software should do, not HOW to code it (that comes in Design phase!).

2.2 Functional vs Non-Functional Requirements

📖 Functional Requirements: What the system DOES. The features and functions the software must provide.

📖 Non-Functional Requirements: How the system PERFORMS. Quality attributes like speed, security, usability.
Aspect Functional Non-Functional
Focus What system does How well it does it
Nature Features, behavior Quality attributes
Captured By Use cases, user stories Constraints, standards
Testing Functional testing Performance, security testing
Example (Banking) Transfer money, check balance Secure (encryption), fast (<2s)
Example (E-commerce) Add to cart, checkout, pay Available 99.9%, handles 10k users
💡 Detailed Examples:

Functional Requirements (E-commerce):
  • User must be able to register with email
  • System shall display product catalog
  • User can add items to shopping cart
  • System shall process payments via credit card
  • Admin can add/remove products

Non-Functional Requirements (E-commerce):
  • Performance: Page load time < 2 seconds
  • Security: All passwords encrypted with SHA-256
  • Availability: System available 99.9% of time (max 8 hours downtime/year)
  • Scalability: Support 10,000 concurrent users
  • Usability: Checkout process in max 3 clicks
💡 Key Difference: Functional = "Login button" (feature). Non-functional = "Login in under 1 second" (performance constraint).

2.3 Software Requirements Specification (SRS)

📖 SRS: A document that completely describes what the software system will do (and how well it will do it). It's the contract between customer and developers.

Characteristics of Good SRS:

✅ 1. Complete: All requirements included — nothing missing.
✅ 2. Consistent: No contradictory requirements.
✅ 3. Unambiguous: Each requirement has only ONE interpretation.
✅ 4. Verifiable: Can test if requirement is met.
✅ 5. Modifiable: Easy to update when requirements change.

Components of SRS:

1. Introduction: Purpose, scope, definitions, overview.
2. Overall Description: Product perspective, functions, user characteristics, constraints.
3. Functional Requirements: Detailed description of all features.
4. Non-Functional Requirements: Performance, security, usability constraints.
5. External Interface Requirements: User, hardware, software, communication interfaces.
6. Appendices: Data models, diagrams, glossary.

2.3.1 Software Prototyping Specification

📖 Software Prototyping: Creating a working, basic version of the software before building the final product. It helps in gathering clear requirements when the customer isn't sure what they want.
✅ Why use Prototyping for Specifications?
Sometimes customers can't explain their needs in words. Showing them a prototype makes it easier for them to say, "Yes, this is what I want!" or "No, change this part."
🔄 Prototyping Workflow:

1. Gather Requirements: Collect basic needs.
2. Build Prototype: Create a quick, workable design.
3. Evaluation: Customer tests the prototype.
4. Refine: Improve based on feedback.
5. Final Specification: Once the prototype is approved, write the final SRS document based on it.

2.4 Generic vs Customized Software

📖 Generic Software: Built for general market. One product sold to many customers.
Example: Microsoft Word, Photoshop, Chrome browser

📖 Customized Software: Built for specific customer. Tailored to their unique needs.
Example: Banking system for HDFC, Inventory system for Walmart
Aspect Generic Software Customized Software
Built For General market, many users Specific customer
Requirements Company decides features Customer specifies needs
Cost Low (cost shared by many) High (one customer pays all)
Control Developer controls features Customer controls everything
Updates Regular updates for all Updates as per contract
Example MS Office, WhatsApp, Zoom Hospital management (specific)

2.5 Data Modelling & Data Dictionary

📖 Data Modelling: The process of organizing and structuring data in a system. It defines what data objects exist, their properties (attributes), and how they connect to each other (relationships).
Popular Tool: Entity-Relationship (ER) Diagrams.
📖 Data Dictionary: A central repository or "master list" that stores definitions of all the data objects in the software. It ensures everyone on the team uses exactly the same names and meanings for data items.
💡 Data Dictionary Example:
If building a student portal, the Data Dictionary will strictly define that "Student_ID" must be a 10-digit number, so no developer accidentally names it "Roll_No" in their code.
Entity-Relationship (ER) Diagram Concept: ┌────────────┐ ┌────────────┐ │ Customer │ │ Product │ └────────────┘ └────────────┘ │ │ │ ╱──────────╲ │ └──────( buys )────────┘ ╲──────────╱ Entity (Data Object) = Customer, Product Relationship = buys
Fig 2.1 — Basic ER Diagram

2.6 Behavioural Modelling

📖 Behavioural Modelling: Shows how the software behaves over time or responds to different internal/external events (user inputs, system errors, etc.).
Popular Tool: State Transition Diagrams (shows how object changes from one state to another).
⚙️ Example of Behavioural Model:
Think of an ATM screen:
1. State: "Idle/Waiting for Card"
2. Event: User inserts card → Changes to State: "Enter PIN"
3. Event: Wrong PIN entered → Changes to State: "Error Sequence"

2.7 Mechanics of Structural Modelling

📖 Mechanics of Structural Modelling: The core rules or "mechanics" used to build a structured representation of the software's data and functions.
🔑 Two Main Mechanics:

1. Data Objects (Entities): Identifying exactly what information needs to be stored (e.g., 'Customer', 'Product').

2. Relationships (Links): Defining how these data objects interact with each other (e.g., 'Customer' purchases 'Product').
These are often visualized using ER Diagrams or Class Diagrams.
🎨 Chapter 3 — Object-Oriented Design & UML
🎨 DESIGN & UML — MIND MAP
Design Phase → Transform requirements into implementable structure
OO Concepts → Classes, Objects, Inheritance, Polymorphism, Encapsulation
UML → Unified Modeling Language — visualize design
Diagrams → Use Case, Class, Activity, State Chart, Interaction
Data Flow → DFD shows how data moves through system

3.1 Importance of Design Phase

📖 Design Phase: The stage where we plan HOW to build the software. It bridges the gap between requirements (what to build) and implementation (building it).
💡 Real-life Analogy — Building Construction:

Before constructing a house:

  • Requirements: "I want 3 bedrooms, 2 bathrooms, kitchen"
  • Design: Architect creates blueprints showing room layouts, plumbing, electrical
  • Implementation: Construction workers follow blueprints to build

Without design (blueprints), construction would be chaotic and error-prone!

Why Design Phase is Important for Large Software:

✅ 1. Manages Complexity:
Large systems have millions of lines of code. Design breaks complexity into manageable modules.
Example: Facebook = separate modules for posts, messaging, notifications, ads — easier to build/maintain.
✅ 2. Early Error Detection:
Design flaws found in design phase are cheap to fix. Flaws found during coding = expensive.
Cost to fix bug: Design phase = $1, Testing = $10, Production = $100!
✅ 3. Facilitates Team Collaboration:
Clear design lets multiple teams work on different modules simultaneously without conflicts.
Example: Team A works on login, Team B on payments — both follow same design architecture.
✅ 4. Ensures Quality:
Good design = modular, maintainable, testable code. Bad design = spaghetti code, bugs, hard to maintain.
✅ 5. Provides Blueprint for Implementation:
Developers know exactly what to build. No guessing or confusion.
✅ 6. Supports Future Changes:
Well-designed systems easy to modify and extend. Add new features without breaking existing code.
❌ Without Proper Design:
  • Developers start coding without clear plan → chaos
  • Code becomes tangled (high coupling) → hard to maintain
  • Bugs multiply → quality suffers
  • Project delays and cost overruns

3.1.1 Structured Analysis

📖 Structured Analysis: A traditional method of analyzing a system by breaking it down into smaller, logical processes (functions). It focuses on WHAT the system does and HOW data flows between processes rather than objects.
✅ Top-Down Approach:
Structured analysis starts with a giant, complex problem and breaks it down (decomposes it) into smaller, simpler, and easier-to-understand sub-problems.
📌 Primary Tool: The main visual tool used in Structured Analysis is the Data Flow Diagram (DFD), which shows how data moves from input to output.

3.2 Basic Object-Oriented Concepts

📖 Object-Oriented Programming: A programming paradigm based on "objects" which contain data (attributes) and code (methods). Models real-world entities.

Core OO Concepts:

1. Class: A blueprint or template for creating objects.
Example: "Car" class defines what all cars have (wheels, engine, color) and can do (start, stop, accelerate).
2. Object: An instance of a class. Actual entity created from the blueprint.
Example: "myCar" is an object of Car class. It's a specific red Honda with plate ABC123.
3. Encapsulation: Bundling data and methods together. Hide internal details, show only necessary interface.
Example: ATM card — you use it without knowing internal banking algorithms.
4. Inheritance: Creating new classes from existing ones. Child inherits properties from parent.
Example: "ElectricCar" inherits from "Car" (gets wheels, engine) + adds battery.
5. Polymorphism: Same interface, different implementations. "Many forms."
Example: "draw()" method — Circle draws circle, Square draws square. Same method name, different behavior.
6. Abstraction: Hide complexity, show only essentials.
Example: Driving car — use steering/pedals (simple interface). Don't need to know how engine combustion works.

3.3 Unified Modeling Language (UML)

📖 UML: A standardized visual language for modeling software systems. Like architectural blueprints for buildings, UML diagrams are blueprints for software.

Types of UML Diagrams:

📌 Two Main Categories:
1. Structural Diagrams: Show static structure (what exists)
2. Behavioral Diagrams: Show dynamic behavior (what happens)
Category Diagram Purpose
Structural Class Diagram Shows classes, attributes, relationships
Object Diagram Shows object instances at runtime
Behavioral Use Case Diagram Shows user interactions
Activity Diagram Shows workflow/process flow
State Chart Diagram Shows object states & transitions
Sequence Diagram Shows object interactions over time

3.4 Use Case Diagram

📖 Use Case Diagram: Shows how users (actors) interact with the system. Represents system functionality from user's perspective.
Use Case Diagram Example (ATM): Actor System Boundary │ ┌─────────────────────┐ │ │ ATM System │ ┌────┴────┐ │ │ │ Customer│────────>│ (Withdraw Cash) │ └────┬────┘ │ ○ │ │ │ │ │ │ (Check Balance) │ └─────────────>│ ○ │ │ │ │ (Transfer Money) │ │ ○ │ └─────────────────────┘ ○ = Use Case (function) → = Actor interacts with use case
Fig 3.1 — Use Case Diagram
💡 Components:
  • Actor: User/external system (stick figure)
  • Use Case: System function (oval)
  • System Boundary: Rectangle showing system scope
  • Relationships: Lines showing interactions

3.5 Class Diagram

📖 Class Diagram: Shows classes in the system, their attributes (data), methods (functions), and relationships between classes.
Class Diagram Example: ┌─────────────────────┐ │ Student │ ← Class Name ├─────────────────────┤ │ - studentID: int │ ← Attributes (data) │ - name: String │ │ - email: String │ ├─────────────────────┤ │ + enroll() │ ← Methods (functions) │ + dropCourse() │ │ + getGrades() │ └─────────────────────┘ - = private + = public Relationships: Student ────> Course (Association) Student ◆───> Address (Composition) Person △───> Student (Inheritance)
Fig 3.2 — Class Diagram

3.6 Activity Diagram

📖 Activity Diagram: Shows workflow of a process. Like a flowchart — represents sequence of activities.
💡 UML Behavioral Modeling for ATM Transaction:
Activity diagram shows step-by-step workflow of ATM transaction with decision points and control flow.
Activity Diagram (ATM Withdrawal): ● Start │ ▼ ┌─────────────┐ │ Insert Card │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Enter PIN │ └──────┬──────┘ │ ▼ ◇ PIN Valid? ╱ ╲ No╱ ╲Yes ╱ ╲ ▼ ▼ [Reject] ┌──────────────┐ │ Select Amount│ └──────┬───────┘ │ ▼ ◇ Balance OK? ╱ ╲ No╱ ╲Yes ╱ ╲ ▼ ▼ [Insufficient] ┌─────────────┐ │ Dispense Cash│ └──────┬──────┘ │ ▼ ● End ◇ = Decision □ = Activity ● = Start/End
Fig 3.3 — Activity Diagram (ATM)

3.7 State Chart Diagram

📖 State Chart Diagram: Shows different states an object can be in and transitions between states based on events.
State Chart (Order Processing): ● Start │ ▼ ┌────────────┐ │ Pending │ └─────┬──────┘ │ [Customer pays] ▼ ┌────────────┐ │ Confirmed │ └─────┬──────┘ │ [Ship] ▼ ┌────────────┐ │ Shipped │ └─────┬──────┘ │ [Deliver] ▼ ┌────────────┐ │ Delivered │ └─────┬──────┘ │ ▼ ● End Each box = State Arrows = Transitions (events)
Fig 3.4 — State Chart Diagram

3.8 Interaction Diagrams (Sequence & Collaboration)

📖 Interaction Diagrams: These UML diagrams show how different objects in the system interact and communicate with each other to perform a specific task or use case.
1. Sequence Diagram (Time-focused):
Shows the flow of messages between objects over time.
Visuals: It has vertical "lifelines" for objects and horizontal arrows for the messages they send, in exact chronological order (from top to bottom).
Example: User clicks Login → System checks DB → DB returns true/false → System shows dashboard.
Sequence Diagram Example (Login Flow): User System Database │ │ │ ├─(1) Enter ID/PW─▶ │ │ ├─(2) Check records─▶│ │ │ │ │ │◀─(3) Return True───┤ │ │ │ │◀─(4) Show Dash──┤ │ │ │ │ * Vertical lines = Lifelines (Time passing downwards) * Horizontal arrows = Messages
Fig 3.5 — Sequence Diagram
2. Collaboration Diagram (Relationship-focused):
Also known as a Communication Diagram. Shows the same information as a Sequence Diagram but focuses more on how objects are connected (their structural relationships) rather than strict time sequences.
Collaboration Diagram Example (Login Flow): (1) Enter ID/PW ┌────────┐ ─────────────▶ ┌────────┐ │ User │ │ System │ └────────┘ ◀───────────── └────────┘ (4) Show Dash │ ▲ │ │ (3) Return True (2) Check records│ │ ▼ │ ┌────────┐ │ DB │ └────────┘ * Focuses on structural links and numbered message order.
Fig 3.6 — Collaboration Diagram

3.9 Data Flow Diagrams (DFD)

📖 DFD: Shows how data moves through a system. Focuses on DATA FLOW, not control flow.
DFD Symbols: External Entity: □ (Source/destination of data) Process: ○ (Transforms data) Data Store: ═ (Storage - database, file) Data Flow: → (Movement of data) Example DFD (Library System): ┌─────────┐ │ Student │ ─── Book Request ──→ ○ ─── Query ──→ ═════════ └─────────┘ Search Book DB ▲ Books │ │ │ │ └──── Book Details ──────────┘ │ │ ┌─────────┐ │ │Librarian│ ─── Update Books ─────────────────────┘ └─────────┘
Fig 3.5 — Data Flow Diagram
⚡ Ready for Exam? Sab padh liya? Ab Quick Revision karo — tricks, mnemonics aur exam tips! Quick Revision Karo →
⚡ Quick Revision — Last Minute Exam Prep!
📌 How to use: Read this 15 minutes before exam. Includes definitions, tricks, mnemonics, examples — everything you need!

📘 Chapter 1 — Introduction & SDLC

📖 Software Engineering Basics:
Software = Programs + Documentation + Operating Procedures
SE = Systematic, disciplined approach to software development

💡 Trick: SE applies engineering principles to software (like civil engineering for bridges)
Why Important: Handle complexity, meet deadlines, control costs, ensure quality
✅ Program vs Product (Remember "S-U-D-T-S"):
Size - Program small, Product large
Users - Program (1), Product (many)
Documentation - Program (none), Product (comprehensive)
Testing - Program (informal), Product (rigorous)
Support - Program (none), Product (customer support)

Example: Personal calculator script vs Microsoft Excel
📌 SDLC PHASES (Remember "R-D-I-T-D-M"): Requirements → Design → Implementation → Testing → Deployment → Maintenance Quick Flow: WHAT to build? → HOW to build? → BUILD it → TEST it → RELEASE it → UPDATE it Exam Tip: Always draw SDLC diagram in 5M answers!
🎯 SDLC Models Quick Comparison:
ModelKey FeatureBest For
WaterfallLinear, sequentialStable requirements
PrototypeBuild sample firstUnclear requirements
SpiralRisk-focusedLarge, risky projects
IncrementalBuild in piecesGradual delivery
V-ModelTesting emphasisClear requirements
AgileFlexible, iterativeChanging requirements
❌ Waterfall Deficiencies (Remember "N-L-N-N-A"):
No going back - Changes expensive
Late testing - Bugs found late = costly
No working software till end
Not good for complex projects
Assumes perfect requirements

Exam Trick: Always mention "late testing" and "no early feedback"
💡 Evolutionary Model Strengths (Remember "E-F-R-C-H"):
Early feedback from customer
Flexible to changes
Reduced risk (problems found early)
Customer involvement (active participation)
Handles unclear requirements

Real Example: Building app prototype → customer sees → suggests changes → build v2
✅ Agile Manifesto (4 Values - Remember):
1. Individuals over processes
2. Working software over documentation
3. Customer collaboration over contracts
4. Responding to change over following plan

How Agile Enhances:
• Adaptability: Short sprints = quick adapt to changes
• Communication: Daily stand-ups = everyone informed
• Collaboration: Customer part of team = feedback immediate
🔄 Incremental vs Spiral (Quick Diff):

Incremental: Add features gradually (Increment 1, 2, 3...)
Focus: Feature addition | Example: E-commerce (login → cart → payment)

Spiral: Risk-driven loops (Planning → Risk → Build → Evaluate)
Focus: Risk management | Example: Banking system (high security risk)

📋 Chapter 2 — Requirements

📋 Requirements Analysis: Understanding what customer wants

Impact of Poor Requirements:
1. ❌ Cost increases (build wrong thing → redo)
2. ❌ Quality suffers (unclear → bugs)
3. ❌ Schedule delays (changes mid-project)
4. ❌ Customer unhappy (product doesn't match expectations)

Real Example: E-commerce without payment → customer: "We need payments!" → costly to add later
✅ Functional vs Non-Functional (Never Confuse!):
FunctionalNon-Functional
FocusWHAT system doesHOW WELL it does
NatureFeaturesQuality
ExampleLogin, Add to cartLoad <2s, 99.9% uptime
Mnemonic: Functional = Functions/Features | Non-functional = Numbers/Constraints
📄 SRS Characteristics (Remember "C-C-U-V-M"):
Complete - Nothing missing
Consistent - No contradictions
Unambiguous - One interpretation only
Verifiable - Can test it
Modifiable - Easy to update
💡 Generic vs Customized Software:

Generic: One product for many customers
Example: MS Word, Chrome | Low cost, developer controls

Customized: Built for specific customer
Example: HDFC banking system | High cost, customer controls

Quick Trick: Generic = General market | Customized = Custom-made for one

🎨 Chapter 3 — Design & UML

🎨 Design Phase Importance for Large Software:
1. ✅ Manages complexity (break into modules)
2. ✅ Early error detection (cheap to fix in design)
3. ✅ Team collaboration (parallel development)
4. ✅ Ensures quality (modular, maintainable)
5. ✅ Blueprint for coding (no guessing)
6. ✅ Supports future changes (easy to extend)

Cost to Fix Bug: Design = $1 | Testing = $10 | Production = $100
Example: Facebook = separate modules (posts, messages, ads) → manageable
✅ OO Concepts (Remember "C-O-E-I-P-A"):
Class - Blueprint for objects
Object - Instance of class
Encapsulation - Bundle data + hide details
Inheritance - Child inherits from parent
Polymorphism - Same interface, different behavior
Abstraction - Hide complexity, show essentials

Quick Examples:
• Class: Car | Object: myCar (red Honda)
• Inheritance: ElectricCar extends Car
• Polymorphism: draw() → Circle draws ○, Square draws □
📊 UML Diagrams Quick Guide:
TypeDiagramShows
StructuralClassClasses, attributes, relationships
BehavioralUse CaseUser interactions
BehavioralActivityWorkflow (like flowchart)
BehavioralState ChartObject states & transitions
BehavioralSequenceObject interactions over time
💡 UML Diagram Examples:

Use Case: ATM → Customer → (Withdraw, Check Balance, Transfer)
Class: Student [-studentID, -name, +enroll(), +getGrades()]
Activity: ATM workflow with decision points (PIN valid? Yes/No)
State Chart: Order states (Pending → Confirmed → Shipped → Delivered)
DFD: Data flow → Student → Search Books → Book DB
🎨 ACTIVITY DIAGRAM FOR ATM (Common Exam Question): Start → Insert Card → Enter PIN → Decision (Valid?) → NO: Reject → YES: Select Amount → Decision (Balance OK?) → NO: Insufficient → YES: Dispense Cash → End Key Elements: ○ Start/End □ Activity ◇ Decision → Flow Exam Tip: Always draw decision points clearly with Yes/No paths!

🎯 Last Minute Exam Strategy

❌ TOP 5 Mistakes Students Make:
1. Waterfall: Not mentioning "late testing" disadvantage
2. Requirements: Confusing functional vs non-functional
3. SDLC: Forgetting to draw diagram in 5M answers
4. Agile: Writing only 2-3 principles (need full manifesto for 5M)
5. UML: Not labeling diagram elements properly
✅ 2 Mark Questions Strategy:
• Definition (1-2 lines) + Example (1 line) = Full marks
• "State two" = Write EXACTLY 2, no more
• "Differentiate" = Make a small table (2-3 rows)
• Keep it short — 4-5 lines maximum

Example:
Q: What is software engineering?
Ans: Systematic, disciplined approach to software development. Applies engineering principles to build quality software. Example: Following SDLC phases systematically.
✅ 5 Mark Questions Strategy:
• Definition + Explanation + Diagram + Example = 5 marks
• SDLC: Describe all 6 phases + draw flow diagram
• Agile: 4 values + key principles + how it helps
• Models Comparison: Always draw comparison table
• UML: Draw diagram with proper labels (Start, End, Decision)

Time Management: 2M = 3 mins, 5M = 8 mins
🔥 MUST REVISE (High Priority Topics):

From PYQs:
  1. SE Principles usefulness (2M)
  2. Waterfall deficiencies (2M)
  3. Evolutionary model strengths (2M)
  4. Incremental vs Spiral (2M/5M)
  5. Agile characteristics (2M)
  6. Functional vs Non-functional (2M)
  7. Design phase importance (2M)
  8. SDLC phases with diagram (5M)
  9. Agile Manifesto + principles (5M)
  10. UML Activity diagram for ATM (5M)
Practice Tasks:
  • Draw SDLC flow diagram NOW
  • Write Agile 4 values from memory
  • Make Waterfall vs Agile comparison table
  • Draw ATM activity diagram with decisions
💡 Power Mnemonics (Use These!):
  • SDLC Phases: R-D-I-T-D-M (Requirements, Design, Implementation, Testing, Deployment, Maintenance)
  • Program vs Product: S-U-D-T-S (Size, Users, Documentation, Testing, Support)
  • Waterfall Problems: N-L-N-N-A (No back, Late test, No software, Not complex, Assumes perfect)
  • Evolutionary Strengths: E-F-R-C-H (Early, Flexible, Reduced risk, Customer, Handles unclear)
  • SRS Characteristics: C-C-U-V-M (Complete, Consistent, Unambiguous, Verifiable, Modifiable)
  • OO Concepts: C-O-E-I-P-A (Class, Object, Encapsulation, Inheritance, Polymorphism, Abstraction)
✅ Quick Exam Tips:
  • Always mention real-life examples (helps explain & impresses examiner)
  • Draw diagrams even if not explicitly asked (visuals = bonus marks)
  • Use proper technical terms (SDLC, not "software making process")
  • Write point-wise for clarity (easier to check, looks organized)
  • For comparisons, ALWAYS make tables (saves time, looks professional)
❓ Important Questions — PYQ Based
📌 Note: These questions are based on actual Mid Semester Test papers and the expected exam pattern. Click on any question to see the clear, point-wise answer.

Section A — 2 Marks Questions (Short Answer)

2M PYQ 2024-25
Q1. How software engineering principles are useful in developing software in systematic way? ▼
Answer:
They provide a structured approach using SDLC phases instead of random coding.
1. Organization: Follows defined steps (Requirements → Design → Code → Test).
2. Quality Control: Built-in testing ensures the software is bug-free and reliable.
3. Teamwork: Clear documentation helps large teams avoid confusion.
2M PYQ 2024-25
Q2. List two major deficiencies of the Waterfall Model. Which model overcomes these deficiencies? ▼
Answer:
Deficiencies:
1. Cannot accommodate requirement changes mid-way (No going back).
2. Testing happens at the very end, so major bugs are found too late.
Solution: The Agile Model (or Iterative Model) overcomes these by welcoming changes and testing continuously.
2M PYQ 2024-25 & 2025-26
Q3. What are the strengths associated with evolutionary model? ▼
Answer:
1. Early Delivery: Customer gets a basic working version quickly.
2. Flexible: Accommodates new requirements or changes easily in subsequent versions.
3. Risk Reduction: Major errors are found early in the first few iterations.
2M PYQ 2024-25
Q4. List any two differences between the Incremental and Spiral Development Model. ▼
Answer:
Incremental ModelSpiral Model
Focuses on delivering a fully working sub-system in every increment.Focuses heavily on Risk Analysis before building anything.
Used for projects where basic requirements are known.Used for highly complex, risky projects with unclear requirements.
2M PYQ 2024-25
Q5. Why are structured software development processes essential in today's technology-driven world? ▼
Answer:
Because modern software is highly complex.
1. Without structure, "spaghetti code" is produced which is impossible to maintain.
2. Structured processes ensure security, scalability, and ability to handle millions of users.
3. Guarantees delivery within time and tight budget constraints.
2M PYQ 2025-26
Q6. State any two differences between generic and customized software. ▼
Answer:
Generic SoftwareCustomized Software
Built for the mass open market (e.g., MS Word).Built for a specific client (e.g., Hospital System).
Developer decides requirements and features.Customer dictates requirements and features.
2M PYQ 2025-26
Q7. What is the importance of design phase for the development of a large Software System? ▼
Answer:
The design phase gives the detailed "blueprint" to programmers.
1. Breaks down massive complexity into manageable, codeable modules.
2. Catching a logical error in design is cheap; fixing it later in code is very expensive.
2M PYQ 2025-26
Q8. List any two characteristics of Agile software development. ▼
Answer:
1. Iterative & Incremental: Software is developed in rapid, short cycles (sprints).
2. Customer Collaboration: Customers are constantly involved to provide feedback rather than just signing a contract at the start.
2M PYQ 2025-26
Q9. Distinguish between functional and non-functional requirements. ▼
Answer:
Functional Requirement: What the system DOES. (e.g., "User must be able to log in").
Non-Functional Requirement: How the system PERFORMS. (e.g., "System must load in 2 seconds" or "Must be highly secure").
2M Expected
Q10. What is Software Engineering? Define it according to IEEE. ▼
Answer:
According to IEEE: "Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software."
Simply: It's engineering rules applied to coding to make reliable software.
2M Expected
Q11. Define Software Prototyping and specify one advantage. ▼
Answer:
Prototyping: Creating a basic, working dummy version of the software to show the client.
Advantage: Helps in identifying exact customer requirements when the customer isn't clear on what they actually want in words.
2M Expected
Q12. What is the main purpose of a Data Flow Diagram (DFD)? ▼
Answer:
The primary purpose of a DFD is to visually represent how data moves into, through, and out of a system. It shows data sources, processes that transform the data, and where data is stored (databases).
2M Expected
Q13. Differentiate between Sequence and Collaboration UML Diagrams. ▼
Answer:
Sequence Diagram: Strongly focuses on TIME. Shows messages passing between objects in exact chronological series (top-to-bottom lifelines).
Collaboration Diagram: Focuses on RELATIONSHIPS. Shows how objects are connected structurally, with numbers indicating message order.
2M Expected
Q14. Define "Data Dictionary" and state its importance. ▼
Answer:
Data Dictionary: A centralized master repository containing precise definitions of all data objects used in the software.
Importance: Prevents naming conflicts. Ensures every developer knows exactly what format and type "CustomerID" or "Password" should be.
2M Expected
Q15. What is the primary difference between Classical and Iterative Waterfall Models? ▼
Answer:
Classical Waterfall represents a strict one-way street; there is absolutely no mechanism to go back and fix errors found in previous phases.
Iterative Waterfall introduces "Feedback Paths", allowing developers to jump backward to correct errors discovered during testing.

Section B — 5 Marks Questions (Long Answer)

5M PYQ 2024-25
Q16. Explain Software Development Life Cycle (SDLC) detailing phases, objectives, and activities. ▼
Answer:
SDLC is a structured process to design, develop, and test high-quality software.

Phases:
1. Requirement Analysis: Gather details from the customer. Output: SRS Document.
2. Design: Plan the architecture, databases, and UI. Output: SDD (Software Design Document).
3. Coding/Implementation: Developers write the code based on the design.
4. Testing: QA team finds bugs to ensure the software works as expected.
5. Deployment: Releasing the software to the actual users in the live server.
6. Maintenance: Fixing future bugs and adding new features requested by clients.
5M PYQ 2024-25
Q17. Discuss core principles of Agile as outlined in the Agile Manifesto. How does it enhance adaptability? ▼
Answer:
The Agile Manifesto values flexibility and speed.

4 Core Values:
1. Individuals and Interactions over Processes & Tools.
2. Working Software over Comprehensive Documentation.
3. Customer Collaboration over Contract Negotiation.
4. Responding to Change over Following a Plan.

How it enhances adaptability:
By working in 2-4 week "Sprints", if a customer's business needs change mid-project, Agile allows shifting focus in the very next sprint, dodging the rigid traps of Waterfall.
5M PYQ 2025-26
Q18. How does inadequate requirement analysis affect project cost, software quality, and schedule? Justify with example. ▼
Answer:
Inadequate requirement analysis means "starting to build without knowing exactly what is needed."

1. Project Cost: Building wrong features wastes developer salary. Fixing a misunderstood requirement during the testing phase costs 10x to 100x more than catching it early.
2. Software Quality: Misunderstood requirements lead to incorrect code architectures, resulting in buggy software that doesn't satisfy client needs.
3. Development Schedule: Changing the foundation halfway through forces massive rework, heavily delaying the final delivery.

Example: Developing an E-commerce site without realizing the client wanted "Apple Pay". Hardcoding generic payments first means re-engineering the entire payment module later, delaying the launch by months and costing thousands of extra dollars.
5M PYQ 2025-26
Q19. Apply UML behavioral modeling concepts to represent ATM workflow through an Activity Diagram. ▼
Answer:
● Start │ ▼ ┌─────────────┐ │ Insert Card │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Enter PIN │ └──────┬──────┘ │ ▼ ◇ PIN Valid? ╱ ╲ No╱ ╲Yes ╱ ╲ ▼ ▼ [Reject] ┌──────────────┐ │ Select Amount│ └──────┬───────┘ │ ▼ ◇ Balance OK? ╱ ╲ No╱ ╲Yes ╱ ╲ ▼ ▼ [Insufficient] ┌─────────────┐ │ Dispense Cash│ └──────┬──────┘ │ ▼ ● End
5M Expected
Q20. Diagrammatically explain the Iterative Waterfall Model and compare it with Classical Waterfall. ▼
Answer:
Iterative Waterfall incorporates "Feedback Paths" meaning we can reverse to previous phases to fix errors.
[Req Analysis] ◄──────┐ │ │ ▼ │ Feedback [Design] ◄─────────│──────┐ │ │ │ ▼ │ │ [Coding] ◄─────────┘ │ │ │ ▼ │ [Testing] ─────────────────┘

Comparison (Classical vs Iterative):
Classical: One-way, rigid, no error correction, assumes perfection.
Iterative: Allows going backward (arrows), flexible to corrections, highly realistic and practical.
5M Expected
Q21. What is an SRS? Explain its components why it is considered the most important document. ▼
Answer:
SRS (Software Requirements Specification) is an official document outlining completely what the software will do and how it will be expected to perform.

Key Components:
1. Introduction and Project Scope.
2. Functional Requirements (What it does).
3. Non-Functional Requirements (Speed, Security, Reliability).
4. External Interfaces (Hardware/Software connections).

Why is it most important?
It serves as an exact "Contract" between the development team and the client. Without it, developers write software based on guesswork, leading to failed projects.