Software Engineering Notes — B.Tech IT Sem 5

Software Engineering — Introduction

Software Engineering: Software ke systematic development, operation, aur maintenance ke liye engineering principles apply karna.

Software Crisis (1968): Large software projects over budget, late, bugs → need engineering discipline.

SWEBOK (Software Engineering Body of Knowledge): Requirements → Design → Construction → Testing → Maintenance → Configuration Mgmt → Project Mgmt → Quality

---

1. SDLC Models

Waterfall Model

Requirements → System Design → Implementation → Testing → Deployment → Maintenance

Advantages: Simple, phases clear, documentation good
Disadvantages: No going back, customer sees product late
When to use: Well-defined requirements, small projects

Spiral Model

Each loop = one phase (requirements/design/build/test)
Risk analysis at every loop
Boehm's model (1988)

Quadrants per loop:
1. Determine objectives & constraints
2. Identify & resolve risks
3. Development & testing
4. Plan next iteration

Best for: Large, complex, high-risk projects

Agile — Scrum Framework

Sprint (1-4 weeks):
  Sprint Planning → Daily Standup → Sprint Review → Retrospective

Roles:
  Product Owner: manages product backlog, priorities
  Scrum Master: facilitates, removes impediments
  Development Team: builds product

Artifacts:
  Product Backlog: all features as User Stories
  Sprint Backlog: stories committed for current sprint
  Increment: potentially shippable product

User Story format:
  "As a [user type], I want [action], so that [benefit]"
  "As a student, I want to search notes by subject,
   so that I can find relevant content quickly"

Story Points: relative complexity estimation (1,2,3,5,8,13)
Velocity: story points per sprint (team metric)

---

2. Requirements Engineering

Types:
Functional: what system does ("Login with email/password")
Non-functional: how system performs ("Response < 2 seconds")
  Performance, Security, Usability, Reliability, Scalability

Requirements Process:
Elicitation → Analysis → Specification (SRS) → Validation

SRS (Software Requirements Specification) IEEE 830:
  Introduction (purpose, scope, definitions)
  Overall description (product perspective, constraints)
  Specific requirements (functional, non-functional)
  Appendices

Techniques:
  Interviews, Questionnaires, Observation
  Use case analysis, Prototyping
  JAD sessions (Joint Application Development)

---

3. UML Diagrams

Use Case Diagram

Actors: external entities interacting with system
Use Cases: system functionality

Student ──── Search Notes
Student ──── Download PDF
Teacher ──── Upload Content
          ⟨⟨include⟩⟩── Authenticate
          ⟨⟨extend⟩⟩─── Show Premium Content

Class Diagram

┌─────────────────────┐
│      Student        │  ← Class name
├─────────────────────┤
│ -rollNo: int        │  ← Attributes (- private)
│ -name: String       │    (+ public, # protected)
│ -gpa: float         │
├─────────────────────┤
│ +enroll(Course)     │  ← Methods
│ +getGpa(): float    │
└─────────────────────┘

Relationships:
─────────── Association (uses)
◄────────── Dependency (uses temporarily)
◇────────── Aggregation (has-a, can exist independently)
◆────────── Composition (has-a, cannot exist independently)
▷────────── Inheritance (is-a)

Sequence Diagram

Student    :UI        :AuthService   :DB
   |          |              |          |
   |─login()─►|              |          |
   |          |─authenticate()►         |
   |          |              |─query()─►|
   |          |              |◄─result──|
   |          |◄─token/error─|          |
   |◄─response|              |          |

---

4. Software Design

SOLID Principles

// S - Single Responsibility
// BAD: User class handles auth + email + DB
public class User {
    public void authenticate() {...}
    public void sendEmail() {...}
    public void saveToDatabase() {...}
}

// GOOD: Separate classes
public class UserAuthService { public boolean login() {...} }
public class UserEmailService { public void send() {...} }
public class UserRepository { public void save() {...} }

// O - Open/Closed
// BAD: modify existing class for new shapes
public class AreaCalculator {
    public double area(Object shape) {
        if (shape instanceof Circle) ...
        if (shape instanceof Square) ...  // keep modifying
    }
}

// GOOD: extend via interface
interface Shape { double area(); }
class Circle implements Shape { public double area() { return Math.PI*r*r; } }
class Square implements Shape { public double area() { return side*side; } }

// D - Dependency Inversion
// BAD: high-level depends on low-level
class OrderService { private MySQLDatabase db = new MySQLDatabase(); }

// GOOD: depend on abstraction
class OrderService {
    private Database db;  // interface
    public OrderService(Database db) { this.db = db; }  // inject
}

Design Patterns

Singleton (Creational):

public class DatabaseConnection {
    private static DatabaseConnection instance;
    private DatabaseConnection() {}  // private constructor
    
    public static synchronized DatabaseConnection getInstance() {
        if (instance == null) instance = new DatabaseConnection();
        return instance;
    }
}

Observer (Behavioral):

interface Observer { void update(String event); }

class EventSystem {
    List<Observer> observers = new ArrayList<>();
    public void subscribe(Observer o) { observers.add(o); }
    public void publish(String event) {
        observers.forEach(o -> o.update(event));
    }
}

Factory (Creational):

interface Payment { void pay(double amount); }
class UPI implements Payment { public void pay(double a) {...} }
class Card implements Payment { public void pay(double a) {...} }

class PaymentFactory {
    public static Payment create(String type) {
        if ("upi".equals(type)) return new UPI();
        if ("card".equals(type)) return new Card();
        throw new IllegalArgumentException("Unknown: " + type);
    }
}

---

5. Software Testing

V-Model (Requirements→Unit test, Design→Integration, etc.)

Testing Levels:
Unit Testing: individual modules (JUnit, pytest)
Integration Testing: combined modules (top-down, bottom-up)
System Testing: complete system
Acceptance Testing: UAT — customer validates

Testing Types:
White-box: code visible to tester (statement, branch coverage)
Black-box: code not visible (equivalence partitioning, BVA)
Grey-box: partial knowledge

Boundary Value Analysis:
  Input range 1-100: test 0, 1, 2, 99, 100, 101

Test Coverage:
Statement coverage: every line executed
Branch coverage: every if/else branch
MC/DC: aviation standard (100% required)

TDD — Test Driven Development:

Red: Write failing test
Green: Write minimum code to pass
Refactor: Clean up code, tests still pass

Benefits: better design, documentation, confidence to change

---

6. DevOps & CI/CD

# GitHub Actions CI/CD Pipeline
name: CI/CD Pipeline
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with: { node-version: '18' }
      - run: npm install
      - run: npm test          # Run unit tests
      - run: npm run lint      # Code quality

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: docker build -t myapp:${{ github.sha }} .
      - run: docker push registry/myapp:${{ github.sha }}

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    steps:
      - run: kubectl set image deployment/myapp myapp=registry/myapp:${{ github.sha }}

---

Exam Important Questions

1. Waterfall vs Agile/Scrum comparison — when use which?
2. SOLID principles explain karo Java examples ke saath
3. UML — Use Case, Class, Sequence diagram banao (library system)
4. Design patterns — Singleton, Observer, Factory explain karo
5. Black-box testing vs White-box testing
6. TDD kya hai? Red-Green-Refactor cycle
7. CI/CD pipeline kya hai? GitHub Actions example
8. SRS document mein kya hota hai?

---

Viva Questions

Q: Technical debt kya hota hai? A: Shortcuts lene se future mein extra kaam — jaise interest payment. Quick fix → accumulates debt. Refactoring se debt reduce karo. Martin Fowler ka concept.

Q: Code review kyun important hai? A: Bugs early find karo (cheaper to fix). Knowledge sharing. Standards enforce. Design improvements. Team ki code quality improve. PR (Pull Request) review standard practice.

Q: Microservices mein kaun se design patterns important hain? A: Saga (distributed transactions), Circuit Breaker (failure isolation), API Gateway (single entry), Service Discovery (find services), CQRS (read/write separation), Event Sourcing (state as events).