Software Engineering — Complete Notes with SDLC, Agile, Testing

Software Development Life Cycle (SDLC)

The SDLC is a process for planning, creating, testing, and deploying software.

Phases:

1. Requirements — Gather and document what system should do
2. System Design — Architecture, database, UI design
3. Implementation — Actual coding
4. Testing — Verify software works correctly
5. Deployment — Release to users
6. Maintenance — Bug fixes, updates

---

SDLC Models

1. Waterfall Model

Sequential, each phase completes before next begins.

Requirements → Design → Implementation → Testing → Deployment → Maintenance

Advantages: Simple, well-documented, clear milestones Disadvantages: Inflexible to changes, late testing, no working product until end

Best for: Fixed requirements, short projects, government/defense projects

2. Prototype Model

Build a prototype first, get feedback, then build final product.

• Good for: Unclear requirements, UI-heavy applications
• Risk: Prototype may become the actual system (throwaway vs evolutionary prototype)

3. Spiral Model (Risk-driven)

Combines Waterfall + Prototyping with risk analysis at each cycle.

4 quadrants per spiral:

1. Planning (objectives, constraints)
2. Risk Analysis (identify and mitigate risks)
3. Engineering (develop and test)
4. Evaluation (customer review)

Best for: Large, high-risk projects where risks must be managed

4. Agile Model

Iterative development in short cycles (sprints, usually 2-4 weeks).

Core Values (Agile Manifesto):

• Individuals and interactions > processes and tools
• Working software > comprehensive documentation
• Customer collaboration > contract negotiation
• Responding to change > following a plan

Scrum Framework:

• Sprint: 2-4 week development cycle
• Product Backlog: Prioritized list of all features
• Sprint Backlog: Features for current sprint
• Daily Standup: 15-min daily meeting (what did I do? what will I do? blockers?)
• Sprint Review: Demo to stakeholders
• Sprint Retrospective: Team reflects on process

Roles: Product Owner, Scrum Master, Development Team

5. DevOps

Combines Development and Operations — continuous integration, delivery, and deployment.

CI/CD Pipeline: Code → Build → Test → Deploy → Monitor

---

Requirements Engineering

Types of Requirements:

• Functional: What system should do (login, search, payment)
• Non-Functional: How well it should do it (performance, security, scalability)
• Domain: Requirements from domain/industry constraints

Requirements Document (SRS — Software Requirements Specification):

• Introduction, overall description, specific requirements, appendices

Use Case Specification:

• Actor: User or external system interacting with software
• Use Case: Specific function/feature
• Includes: Basic flow, alternate flows, exceptions

---

UML Diagrams

Structural Diagrams (static view):

1. Class Diagram — classes, attributes, methods, relationships
2. Object Diagram — specific instances at a moment in time
3. Component Diagram — software components and their dependencies
4. Deployment Diagram — physical deployment of software

Behavioral Diagrams (dynamic view):

1. Use Case Diagram — actors and system functionalities
2. Sequence Diagram — interactions in time order
3. Activity Diagram — workflow/flowchart
4. State Machine Diagram — states and transitions

Class Diagram Relationships

| Relationship | Symbol | Meaning | |---|---|---| | Association | → | General relationship | | Aggregation | ◇→ | HAS-A (weak, part can exist independently) | | Composition | ◆→ | HAS-A (strong, part cannot exist without whole) | | Inheritance | △→ | IS-A relationship | | Dependency | --→ | Uses relationship |

---

Software Testing

Levels of Testing:

1. Unit Testing — test individual functions/modules
2. Integration Testing — test interaction between modules
3. System Testing — test entire system end-to-end
4. Acceptance Testing (UAT) — user verifies system meets requirements

Black Box Testing: Tests without knowledge of internal code

• Focus: Input/output behavior
• Techniques: Equivalence partitioning, boundary value analysis, decision table testing

White Box Testing (Glass Box): Tests with knowledge of internal code

• Focus: Code coverage (statement, branch, path)
• Techniques: Control flow testing, data flow testing

Equivalence Partitioning: Divide inputs into equivalent groups; test one value from each

• Example: Age field (0-120): invalid negatives, valid 0-120, invalid >120

Boundary Value Analysis: Test values at boundaries

• For input 1-100: test -1, 0, 1, 50, 99, 100, 101

Regression Testing: Re-running tests after code changes to ensure nothing broke

Performance Testing Types:

• Load testing: under expected load
• Stress testing: beyond capacity
• Spike testing: sudden load surge
• Endurance testing: sustained load over time

---

Software Metrics

Size Metrics:

• LOC (Lines of Code) — simplest but not best
• Function Points — based on number of inputs, outputs, queries, files, interfaces

Quality Metrics:

• Defect Density = Defects / KLOC (thousand lines of code)
• MTBF (Mean Time Between Failures) — reliability
• Cyclomatic Complexity = E - N + 2P (edges, nodes, connected components)
  • Good: < 10; Complex: 10-20; Very complex: > 20

Project Metrics:

• Productivity = Function Points / Person-Month
• Effort = Person × Time
• Schedule Variance = (Planned Date - Actual Date)

---

Software Design Principles

SOLID Principles:

• S — Single Responsibility: one class, one reason to change
• O — Open/Closed: open for extension, closed for modification
• L — Liskov Substitution: subclass must be usable in place of parent
• I — Interface Segregation: many specific interfaces > one general interface
• D — Dependency Inversion: depend on abstractions, not concrete implementations

Design Patterns (Gang of Four):

• Creational: Singleton, Factory, Builder, Prototype
• Structural: Adapter, Decorator, Facade, Proxy
• Behavioral: Observer, Strategy, Command, Iterator

---

Solved PYQ Questions

Q1 (2023): Compare Waterfall and Agile with a real-world example. Building a hospital management system:

• Waterfall: Good only if all hospital requirements are completely known upfront (rare). Risk: delivering wrong features after 2 years.
• Agile: Better — deliver patient registration in sprint 1, appointments in sprint 2, billing in sprint 3. Hospital staff gives feedback after each sprint.

Q2 (2023): What is Cyclomatic Complexity? Calculate for a function with 5 if-statements. Cyclomatic Complexity = Number of independent paths = number of binary decisions + 1 = 5 + 1 = 6. Represents how many test cases needed for full branch coverage.

Q3 (2022): Explain the difference between black box and white box testing with examples. Black box: tester enters username/password and checks if login works — no code knowledge. White box: tester examines code to see which branches of if/else are executed and writes tests to cover all branches.

---

Quick Revision Checklist

• SDLC phases: Requirements, Design, Implementation, Testing, Deployment, Maintenance
• Waterfall vs Agile: sequential vs iterative; rigid vs flexible
• Scrum: Sprint (2-4 weeks), Product Backlog, Daily Standup, Sprint Review
• UML: 4 structural + 4 behavioral diagrams
• Black box vs White box testing
• Equivalence partitioning + Boundary value analysis
• SOLID principles: S, O, L, I, D meanings
• Cyclomatic complexity: E - N + 2P or decisions + 1