The Ultimate Software Engineering Cheatsheet

SDLC Model Selection Decision Guide
════════════════════════════════════════════════════════════

Q1: Are requirements well-understood and stable?
    YES → Q2: Is the project safety-critical or regulated?
              YES → V-Model (verification & validation)
              NO  → Waterfall (simple, predictable)
    NO  → Q3: Is the project high-risk and large-budget?
              YES → Spiral (explicit risk analysis)
              NO  → Q4: Is time-to-market the top priority?
                        YES → RAD (rapid prototyping)
                        NO  → Agile (flexible, iterative)

Key Interview Points:
• Waterfall = predictable but inflexible
• Agile = flexible but less predictable
• Spiral = risk-focused but expensive
• V-Model = quality-focused but rigid
• RAD = fast but less scalable
• Iterative = balanced but moderate overhead

Use Case Diagram — Online Shopping System
════════════════════════════════════════════════════════════

[Actor: Customer]
    ├── Browse Products
    ├── Search Products
    ├── Add to Cart
    ├── Remove from Cart
    ├── Checkout
    ├── Make Payment          <<include>> → Validate Payment
    ├── View Order History
    └── Track Order           <<extend>>  ← Track by SMS

[Actor: Admin]
    ├── Manage Products (CRUD)
    ├── Manage Users
    ├── View Analytics
    └── Process Refunds

[Actor: Payment Gateway] (External System)
    ├── Validate Payment
    └── Process Refund

Relationships:
• <<include>>  — mandatory sub-flow (always executed)
• <<extend>>   — optional/conditional flow (may or may not happen)
• Generalization — specialized use case inherits from parent

# ── White Box Coverage Example ──
def classify_age(age):
    """Classify a person by age group."""
    if age < 0 or age > 150:       # Branch 1: invalid
        return "Invalid"
    elif age < 13:                  # Branch 2: child
        return "Child"
    elif age < 20:                  # Branch 3: teenager
        return "Teenager"
    elif age < 65:                  # Branch 4: adult
        return "Adult"
    else:                           # Branch 5: senior
        return "Senior"

# Statement Coverage: need test for every return statement
# Tests: -1 (Invalid), 5 (Child), 16 (Teenager), 30 (Adult), 80 (Senior)
# All 5 return statements executed → 100% statement coverage

# Branch Coverage: each if/elif evaluated to True AND False
# Branch 1: True (age=-1), False (age=5)
# Branch 2: True (age=5), False (age=16)
# Branch 3: True (age=16), False (age=30)
# Branch 4: True (age=30), False (age=80)
# Branch 5: always True when reached
# Tests: -1, 5, 16, 30, 80 → 100% branch coverage

# ── Black Box: Boundary Value Analysis ──
# Valid range: [0, 150]
# Test values: -1, 0, 1, 149, 150, 151 (6 values at boundaries)

TEST CASE TEMPLATE
════════════════════════════════════════════════════════════
Test Case ID:  TC-LOGIN-001
Title:         Verify successful login with valid credentials
Pre-conditions: User account exists; browser is open
Priority:       High
Module:        Authentication

Steps:
  1. Navigate to login page
  2. Enter valid username "testuser@example.com"
  3. Enter valid password "SecurePass123!"
  4. Click "Sign In" button

Expected Result: User is redirected to dashboard; welcome message displayed
Actual Result:   (filled during execution)
Status:          PASS / FAIL / BLOCKED

Test Case ID:  TC-LOGIN-002
Title:         Verify login with invalid password
Steps: Same as TC-LOGIN-001 but with password "WrongPass"
Expected Result: Error message "Invalid credentials" displayed; no redirect

UML Diagrams Overview (Unified Modeling Language)
════════════════════════════════════════════════════════════

STRUCTURAL DIAGRAMS (Static View):
┌──────────────────┬──────────────────────────────────────────┐
│ Class Diagram    │ Classes, attributes, methods, relations  │
│                  │ + public, - private, # protected         │
│                  │ Inheritance (▲), Composition (◆), Agg(◇) │
├──────────────────┼──────────────────────────────────────────┤
│ Object Diagram   │ Instance snapshot of class diagram       │
├──────────────────┼──────────────────────────────────────────┤
│ Component Diagram│ Physical components and their interfaces │
│                  │ Used in system architecture design        │
├──────────────────┼──────────────────────────────────────────┤
│ Deployment Diagram│ Hardware nodes and software allocation  │
│                  │ Shows servers, containers, communication  │
├──────────────────┼──────────────────────────────────────────┤
│ Package Diagram  │ Organization of packages and dependencies│
└──────────────────┴──────────────────────────────────────────┘

BEHAVIORAL DIAGRAMS (Dynamic View):
┌──────────────────┬──────────────────────────────────────────┐
│ Sequence Diagram │ Object interactions in time order         │
│                  │ Shows messages between objects            │
├──────────────────┼──────────────────────────────────────────┤
│ Activity Diagram │ Flow of activities/decisions (flowchart+) │
│                  │ Parallel activities, swimlanes            │
├──────────────────┼──────────────────────────────────────────┤
│ State Diagram    │ States an object can be in and transitions│
│                  │ Triggers, guards, actions                │
├──────────────────┼──────────────────────────────────────────┤
│ Use Case Diagram │ Actors and their interactions with system │
├──────────────────┼──────────────────────────────────────────┤
│ Timing Diagram   │ Interaction timing constraints            │
├──────────────────┼──────────────────────────────────────────┤
│ Communication    │ Object interactions (focus on links)      │
└──────────────────┴──────────────────────────────────────────┘

Key Relationships in Class Diagrams:
• Inheritance (Generalization): "is-a" → Solid line with hollow triangle
• Implementation (Realization): "implements" → Dashed line with hollow triangle
• Association: "uses" → Solid line with arrow
• Aggregation: "has-a" (weak) → Solid line with hollow diamond
• Composition: "owns-a" (strong, lifecycle) → Solid line with filled diamond
• Dependency: "depends on" → Dashed line with arrow

THE AGILE MANIFESTO (2001)
════════════════════════════════════════════════════════════

We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:

  Individuals and interactions   over Processes and tools
  Working software               over Comprehensive documentation
  Customer collaboration         over Contract negotiation
  Responding to change           over Following a plan

That is, while there is value in the items on the right,
we value the items on the left more.

12 PRINCIPLES BEHIND THE MANIFESTO:
  1. Highest priority: satisfy the customer through early & continuous delivery
  2. Welcome changing requirements, even late in development
  3. Deliver working software frequently (weeks, not months)
  4. Business and developers must work together daily
  5. Build projects around motivated individuals; trust them
  6. Face-to-face conversation is the most efficient communication
  7. Working software is the primary measure of progress
  8. Sustainable development — maintain a constant pace indefinitely
  9. Continuous attention to technical excellence and good design
  10. Simplicity — maximizing the amount of work not done
  11. The best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly reflect on how to become more effective, then adjust accordingly

USER STORIES & ESTIMATION
════════════════════════════════════════════════════════════

USER STORY FORMAT (As a... I want to... So that...):
  "As a registered user, I want to reset my password via email,
   so that I can regain access to my account if I forget it."

USER STORY ANATOMY:
  Title:        Password Reset via Email
  Description:  As a <role>, I want <action>, so that <benefit>
  Acceptance Criteria (Given-When-Then format):
    Given: I am on the login page and I forgot my password
    When: I enter my registered email and click "Reset"
    Then: A password reset link is sent to my email within 2 minutes
    And:  The link expires after 24 hours

STORY POINTS (Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21):
  1    = Trivial (few minutes, no risk)
  2    = Simple (hours, well-understood)
  3    = Moderate (half a day, some unknowns)
  5    = Complex (1-2 days, needs discussion)
  8    = Very Complex (3-5 days, high risk)
  13   = Extremely Complex (needs to be broken down)
  21   = Too big → MUST split into smaller stories

VELOCITY = Total story points completed in a sprint
  Sprint 1: 5 + 3 + 8 + 2 + 5 = 23 points → Velocity = 23
  Sprint 2: 8 + 3 + 5 + 8 = 24 points → Velocity = 24
  Average velocity ≈ 23.5 points/sprint

  Use velocity to predict: "We have 100 points remaining.
  At 23.5 points/sprint, we need ~5 more sprints (10 weeks)."

PLANNING POKER (Estimation Technique):
  1. Product Owner reads the user story
  2. Team asks clarifying questions
  3. Each member privately selects a card (1, 2, 3, 5, 8, 13...)
  4. Cards revealed simultaneously
  5. Highest and lowest explain their reasoning
  6. Repeat until consensus

# ── Singleton Pattern ──
class DatabaseConnection:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            cls._instance._connection = "Connected to DB"
        return cls._instance

db1 = DatabaseConnection()  # Creates instance
db2 = DatabaseConnection()  # Returns same instance
assert db1 is db2  # True — same object


# ── Observer Pattern ──
class EventManager:
    def __init__(self):
        self._listeners = {}

    def subscribe(self, event_type, listener):
        self._listeners.setdefault(event_type, []).append(listener)

    def notify(self, event_type, data):
        for listener in self._listeners.get(event_type, []):
            listener(data)

em = EventManager()
em.subscribe("order_created", lambda data: print(f"Email: {data}"))
em.subscribe("order_created", lambda data: print(f"Log: {data}"))
em.notify("order_created", "Order #1234 created")
# Output: Email: Order #1234 created
#         Log: Order #1234 created


# ── Strategy Pattern ──
class SortStrategy:
    def sort(self, data): pass

class BubbleSort(SortStrategy):
    def sort(self, data): return sorted(data)  # simplified

class QuickSort(SortStrategy):
    def sort(self, data): return sorted(data, reverse=True)

class Sorter:
    def __init__(self, strategy):
        self._strategy = strategy
    def execute(self, data):
        return self._strategy.sort(data)

sorter = Sorter(QuickSort())
sorter.execute([3, 1, 4, 1, 5])  # [5, 4, 3, 1, 1]


# ── Factory Method Pattern ──
class Notification:
    def send(self, msg): pass

class EmailNotification(Notification):
    def send(self, msg): print(f"Email: {msg}")

class SMSNotification(Notification):
    def send(self, msg): print(f"SMS: {msg}")

class NotificationFactory:
    @staticmethod
    def create(channel):
        if channel == "email": return EmailNotification()
        if channel == "sms":   return SMSNotification()
        raise ValueError(f"Unknown channel: {channel}")

factory = NotificationFactory()
factory.create("email").send("Hello!")  # Email: Hello!

# ── Cyclomatic Complexity Calculation ──
# V(G) = Decision Points + 1
# Decision points: if, elif, for, while, and, or, case, catch

# Example 1: Simple (V(G) = 1)
def add(a, b):
    return a + b  # No decisions → V(G) = 1

# Example 2: One decision (V(G) = 2)
def is_adult(age):
    if age >= 18:       # +1 decision
        return True
    return False        # V(G) = 1 + 1 = 2

# Example 3: Multiple decisions (V(G) = 4)
def classify(age, income):
    if age < 18:                    # +1
        return "Minor"
    elif income < 30000:            # +1
        return "Low Income Adult"
    elif income < 75000:            # +1
        return "Middle Income Adult"
    return "High Income Adult"      # V(G) = 3 + 1 = 4

# Example 4: Nested (V(G) = 3)
def process(data):
    if data is not None:            # +1
        for item in data:           # +1
            if item > 0:            # +1
                process(item)
    # V(G) = 3 + 1 = 4

# Complexity Thresholds:
#  1-10:   Low risk (simple, easy to test)
# 11-20:   Moderate risk (manageable)
# 21-50:   High risk (difficult to test, refactor recommended)
# 50+:     Very high risk (untestable, MUST refactor)

CODE REFACTORING TECHNIQUES
════════════════════════════════════════════════════════════

COMPOSING METHODS (Simplifying Code):
  • Extract Method      — Take a code fragment, make it a separate function
  • Inline Method       — Remove a method body and put it where it was called
  • Replace Temp with Query — Replace a temporary variable with a query method
  • Introduce Explaining Variable — Break complex expressions into named variables
  • Decompose Conditional — Extract if/else branches into separate methods

ORGANIZING DATA:
  • Encapsulate Field     — Make fields private with getters/setters
  • Replace Magic Number  — Replace literal numbers with named constants
  • Replace Type Code with Class — Use classes/polymorphism instead of type flags
  • Replace Array with Object — Replace array of data with a proper data class

SIMPLIFYING CONDITIONALS:
  • Decompose Conditional — Extract condition logic into named methods
  • Consolidate Conditional Expression — Combine conditions with same result
  • Replace Conditional with Polymorphism — Use Strategy/State pattern
  • Introduce Null Object — Instead of null checks, use a null object

MOVING FEATURES:
  • Move Method          — Move method to the class that uses it most
  • Move Field           — Move field to the class that uses it most
  • Extract Class        — Split a large class into two smaller ones
  • Hide Delegate        — Hide the intermediate object from the client

GENERALIZATION:
  • Pull Up Field/Method — Move common fields/methods to a base class
  • Push Down Field/Method — Move specific fields/methods to subclasses
  • Extract Interface     — Create an interface from common methods
  • Replace Inheritance with Delegation — Prefer composition over inheritance

REFACTORING GOLDEN RULES:
  1. Refactor ONLY when you have passing tests
  2. Make small, incremental changes
  3. Run tests after each refactoring step
  4. Use meaningful names
  5. Don't add functionality while refactoring (separate the concerns)