Software Engineering

Software Engineering is the systematic approach to developing, operating, and maintaining software using engineering principles.

Key Points:

• Applies engineering methods to software development
• Ensures quality, reliability, and maintainability
• Addresses software crisis: delays, budget overruns, poor quality
• Follows defined processes and methodologies

Software = Programs + Data + Documentation

Software Crisis = Problems faced in software development that led to need for engineering approach.

Problems:

• Projects over budget
• Projects over time
• Low quality software
• Poor maintainability
• Failed projects

Causes:

• Increased complexity
• Poor project management
• Lack of standards
• Inadequate testing

Solution: Software Engineering principles and methodologies

SDLC (Software Development Life Cycle) = Framework defining stages in software development.

Common Phases:

• 1. Requirements - What to build
• 2. Design - How to build
• 3. Implementation - Building it
• 4. Testing - Verifying it works
• 5. Deployment - Releasing it
• 6. Maintenance - Keeping it running

Different models organize these phases differently.

Waterfall Model = Linear sequential SDLC model.

Phases flow down like waterfall:

Requirements → Design → Implementation → Testing → Deployment → Maintenance

Advantages:

✓ Simple and easy to understand

✓ Well-documented

✓ Good for small, well-defined projects

Disadvantages:

✗ No going back to previous phase

✗ Late testing (bugs found late)

✗ Not flexible to changes

When to Use: Stable, well-understood requirements

V-Model (Verification & Validation Model) = Testing parallels development.

V-Shape Structure:

Requirements ←→ Acceptance Testing
   System Design ←→ System Testing
      Architecture ←→ Integration Testing
         Module Design ←→ Unit Testing
              Coding (at bottom)

Advantage: Testing planned early

Use When: High reliability required (safety-critical systems)

Spiral Model = Risk-driven iterative model (Barry Boehm).

4 Quadrants per iteration:

• 1. Planning - Define objectives
• 2. Risk Analysis - Identify and mitigate risks
• 3. Engineering - Develop and test
• 4. Evaluation - Customer review

Advantages:

✓ Risk-focused

✓ Good for large, complex projects

✓ Flexible to changes

Disadvantages:

✗ Complex to manage

✗ Expensive (requires risk expertise)

When to Use: High-risk, large projects

Agile Model = Iterative, incremental, flexible approach.

Key Principles (Agile Manifesto):

• Individuals over processes
• Working software over documentation
• Customer collaboration over contracts
• Responding to change over following a plan

Features:

• Short iterations (Sprints: 2-4 weeks)
• Daily standups
• Continuous delivery
• Customer involvement

Scrum Terms:

• Sprint, Backlog, Sprint Review
• Product Owner, Scrum Master

When to Use: Changing requirements, fast delivery needed

SRS (Software Requirements Specification) = Official document describing what software should do.

Purpose:

• Contract between stakeholders and developers
• Basis for design and testing
• Follows IEEE 830 standard

SRS Structure:

• 1. Introduction (Purpose, Scope, Definitions)
• 2. Overall Description (Product perspective)
• 3. Specific Requirements (Functional, Non-functional)
• 4. Appendices

Functional Requirements = WHAT system should DO

Examples:

• User can login with email/password
• System calculates total price
• Generate monthly report

---

Non-Functional Requirements = HOW WELL system performs

Categories:

SMART = Characteristics of good requirements.

S - Specific

• Clear and unambiguous

M - Measurable

• Can be verified

A - Achievable

• Technically feasible

R - Relevant

• Aligned with goals

T - Time-bound

• Has deadline

Example:

❌ "System should be fast"

✓ "Page load time < 3 seconds for 95% of requests"

Verification = "Are we building the product RIGHT?"

• Checks conformance to specifications
• Static testing (reviews, inspections)
• Done during development

---

Validation = "Are we building the RIGHT product?"

• Checks if it meets user needs
• Dynamic testing (actual execution)
• Done after development

Mnemonic:

• Verification = Right way
• Validation = Right thing (Look at user)

Testing Levels (Bottom-up):

1. Unit Testing

• Test individual components/functions
• By developers

2. Integration Testing

• Test modules working together
• Find interface issues

3. System Testing

• Test complete system
• Against requirements

4. Acceptance Testing

• User tests if acceptable
• Alpha (internal) / Beta (external)

V-Model: Each dev phase has corresponding test phase

Software Project Management = Planning, monitoring, and controlling software development.

Objectives:

• Deliver on time
• Stay within budget
• Meet quality requirements
• Manage risks

Triple Constraint Triangle:

    Scope
    /   \
 Time --- Cost

Changing one affects others!

Project Manager Responsibilities:

1. Planning

• Define scope, schedule, budget
• Create WBS (Work Breakdown Structure)

2. Organizing

• Allocate resources
• Define team structure

3. Staffing

• Select team members
• Assign roles

4. Directing

• Lead and motivate team
• Make decisions

5. Controlling

• Monitor progress
• Take corrective action

LOC (Lines of Code) = Size metric counting source code lines.

KLOC = 1000 Lines of Code

Advantages:

✓ Simple to count

✓ Easy to understand

Disadvantages:

✗ Language-dependent

✗ Favors longer code

✗ Hard to estimate early

Uses:

• Effort estimation
• Productivity measurement
• Cost estimation

Function Points (FP) = Size metric based on functionality.

Counts 5 types:

• 1. External Inputs (EI) - Data entering system
• 2. External Outputs (EO) - Data leaving system
• 3. External Inquiries (EQ) - Queries
• 4. Internal Logical Files (ILF) - Internal data stores
• 5. External Interface Files (EIF) - External data references

Formula:

FP = Count Total × [0.65 + 0.01 × ΣFi]

Advantage: Language-independent, measures functionality

COCOMO (Constructive Cost Model) = Software estimation model by Barry Boehm (1981).

Uses KLOC to estimate:

• Effort (person-months)
• Development time
• Team size

Basic Formula:

Effort = a × (KLOC)^b
Time = c × (Effort)^d

Three Types:

• 1. Basic - Quick estimates
• 2. Intermediate - With cost drivers
• 3. Detailed - Phase-wise

COCOMO Project Categories:

Example (Basic COCOMO):

Project: 50 KLOC, Organic

Effort = 2.4 × (50)^1.05 = 145 PM

Intermediate COCOMO adds 15 cost drivers (EAF):

Effort = a × (KLOC)^b × EAF

Risk Analysis = Identifying and managing potential problems.

Risk = Probability × Impact

Risk Categories:

• Technical - Technology failures
• Project - Schedule, budget issues
• Business - Market, funding changes

Risk Management Steps:

• 1. Identify - List potential risks
• 2. Analyze - Assess probability and impact
• 3. Plan - Develop mitigation strategies
• 4. Monitor - Track throughout project

Risk Mitigation Strategies (4 T's):

1. Terminate (Avoid)

• Change plans to eliminate risk
• Example: Use proven technology

2. Transfer

• Shift risk to another party
• Example: Insurance, outsourcing

3. Treat (Mitigate)

• Reduce probability or impact
• Example: More testing, prototyping

4. Tolerate (Accept)

• Accept risk if low impact
• Have contingency plan

Risk Register: Document tracking all risks

WBS (Work Breakdown Structure) = Hierarchical decomposition of project into tasks.

Structure:

Project
├── Phase 1
│   ├── Task 1.1
│   └── Task 1.2
└── Phase 2
    ├── Task 2.1
    └── Task 2.2

Benefits:

• Clear scope definition
• Easier estimation
• Clear responsibilities
• Progress tracking

Rule: Decompose until tasks are 8-80 hours

Gantt Chart:

• Bar chart showing tasks over time
• Visual timeline
• Shows dependencies
• Easy to understand

---

PERT (Program Evaluation Review Technique):

• Network diagram
• Shows task dependencies
• Calculates critical path
• Time estimates: Optimistic, Most Likely, Pessimistic

Expected Time = (O + 4M + P) / 6

---

Critical Path:

• Longest path through network
• Determines minimum project duration
• No slack time allowed

Requirements Analysis = Process of refining and structuring gathered requirements.

Key Tasks:

• 1. Elicitation - Gather requirements
• 2. Analysis - Understand and organize
• 3. Specification - Document in SRS
• 4. Validation - Verify correctness
• 5. Management - Handle changes

Techniques:

• Interviews
• Questionnaires
• Observation
• Document Analysis
• Prototyping
• Use Cases

Requirements Elicitation = Gathering requirements from stakeholders.

Techniques:

1. Interviews

• Structured or unstructured
• Direct stakeholder interaction

2. Questionnaires/Surveys

• Large number of users
• Quantifiable data

3. Observation

• Watch users work
• Understand actual workflow

4. Prototyping

• Build mock-up
• Get feedback early

5. Document Analysis

• Existing system documentation
• Industry standards

Data Dictionary = Central repository of data definitions.

Contains for each element:

• Name
• Alias (alternative names)
• Description
• Composition
• Range/Values
• Format

Notation:

• = means "composed of"
• + means "and" (sequence)
• [ ] means "or" (selection)
• { } means repetition
• ( ) means optional

Example:

CustomerName = FirstName + (MiddleName) + LastName

FSM (Finite State Machine) = Model where system is always in one of finite states.

Components:

• 1. States - Circles
• 2. Transitions - Arrows
• 3. Initial State - Arrow pointing in
• 4. Final State - Double circle
• 5. Events/Inputs - Labels on arrows

Uses:

• Compilers
• UI navigation flows
• Network protocols
• Game AI

State Transition Table = Tabular representation of FSM.

Types of FSM:

• DFA (Deterministic) - One transition per input
• NFA (Non-deterministic) - Multiple possible transitions

DFD (Data Flow Diagram) = Graphical representation of data flow in a system.

4 Symbols:

• 1. Process - Circle (transforms data)
• 2. Data Flow - Arrow (data movement)
• 3. Data Store - Open rectangle (storage)
• 4. External Entity - Rectangle (outside source)

Part of Structured Analysis methodology

DFD Levels (Top-down decomposition):

Level 0 (Context Diagram):

• Single process = Entire system
• Shows external entities only
• Highest abstraction

Level 1:

• Breaks down Level 0
• Shows 3-7 main processes
• More detail

Level 2:

• Further decomposition
• Even more detail
• Continue until primitives

Balancing Rule: Data flows in parent = Data flows in children

CFD (Control Flow Diagram) = DFD extended with control information.

Shows:

• When processes execute
• Conditions for data flow
• Event triggers

Components:

• Control bars (conditions)
• CSPEC (Control Specification)
• PSPEC (Process Specification)

Used with:

• State Transition Diagrams
• For complete behavioral model

Design Fundamentals:

1. Modularity

• Divide system into modules
• Each module: one function

2. Cohesion (HIGH is good)

• How related elements are within module
• Single purpose = High cohesion ✓

3. Coupling (LOW is good)

• Dependencies between modules
• Independent modules = Low coupling ✓

4. Information Hiding

• Hide internal details
• Expose only interfaces

Types of Cohesion (Best to Worst):

1. Functional (Best)

• All elements for single function

2. Sequential

• Output of one = Input of next

3. Communicational

• Share same data

4. Procedural

• Follow specific sequence

5. Temporal

• Execute at same time

6. Logical

• Similar logical function

7. Coincidental (Worst)

• No meaningful relationship

Goal: Maximize cohesion!

Design Metrics:

Fan-in:

• Number of modules CALLING this module
• Higher = More reusable ✓

Fan-out:

• Number of modules CALLED by this module
• Lower = Simpler ✓

Depth:

• Levels in module hierarchy
• Not too deep, not too shallow

Width:

• Modules at same level
• Balance is key

Architecture Patterns:

1. Layered Architecture

• Presentation → Business → Data → DB
• Clear separation of concerns

2. Client-Server

• Multiple clients, central server
• Web applications

3. MVC (Model-View-Controller)

• Model: Data
• View: UI
• Controller: Logic

4. Microservices

• Small independent services
• Own databases, communicate via API

5. Pipe and Filter

• Data flows through filters
• Each filter transforms data

MVC (Model-View-Controller):

Model:

• Data and business logic
• Database operations
• Independent of UI

View:

• User interface
• Displays data from Model
• User input

Controller:

• Handles user input
• Updates Model
• Selects View

Flow:

User → Controller → Model → View → User

Advantages:

• Separation of concerns
• Multiple views for same data
• Easier testing

SDD (Software Design Document):

Contents:

• 1. Overview - High-level description
• 2. Architectural Design - System structure
• 3. Detailed Design - Module specifications
• 4. Interface Design - APIs, protocols
• 5. Data Design - Database schema

Uses:

• Guide for developers
• Reference for testers
• Maintenance documentation
• Knowledge transfer

OOA (Object-Oriented Analysis) = Modeling problem domain using objects.

Steps:

• 1. Identify Objects - Nouns in requirements
• 2. Identify Attributes - Properties of objects
• 3. Identify Methods - Verbs ??? operations
• 4. Identify Relationships - Associations

Focus: WHAT the system should do

Example:

Requirement: "Student registers for Course"

• Objects: Student, Course
• Relationship: Registration

4 Pillars of Object-Oriented Design:

1. Encapsulation

• Bundle data + methods
• Hide internal state
• Public interface only

2. Inheritance

• Derive new classes from existing
• Code reuse
• Is-a relationship

3. Polymorphism

• Same interface, different behavior
• Method overloading/overriding

4. Abstraction

• Hide complexity
• Show essential features only

Mnemonic: E-I-P-A (A PIE!)

Design Patterns = Reusable solutions to common problems.

Types:

Creational:

• Singleton - One instance only
• Factory - Create objects without specifying class

Structural:

• Adapter - Interface compatibility
• Decorator - Add behavior dynamically

Behavioral:

• Observer - Notify dependents of changes
• Strategy - Interchangeable algorithms

Gang of Four (GoF) book defines 23 patterns

UML Class Relationships:

1. Association ———

• General relationship
• "Uses" or "knows about"

2. Aggregation ◇———

• "Has-a" (weak)
• Parts can exist independently
• Example: Team has Players

3. Composition ◆———

• "Has-a" (strong)
• Parts cannot exist independently
• Example: House has Rooms

4. Inheritance ———▷

• "Is-a" relationship
• Child extends Parent

5. Dependency - - - >

• Temporary usage

UML (Unified Modeling Language) = Standard visual language for software models.

Created by: Booch, Rumbaugh, Jacobson

Two Categories:

Structural (Static):

• Class Diagram
• Object Diagram
• Component Diagram
• Deployment Diagram

Behavioral (Dynamic):

• Use Case Diagram
• Sequence Diagram
• Activity Diagram
• State Diagram

Use Case Diagram = Shows system functionality from user perspective.

Elements:

• Actor - Stick figure (user/system)
• Use Case - Oval (functionality)
• System Boundary - Rectangle
• Relationships - Lines

Relationships:

• Include - Always included
• Extend - Optional extension
• Generalization - Is-a

Example:

  [Actor] --- (Login)
           --- (View Profile)
           --- (Search)

Sequence Diagram = Shows object interactions over time.

Elements:

• Lifelines - Vertical dashed lines (objects)
• Messages - Horizontal arrows
• Activation Bars - Rectangles on lifelines
• Return - Dashed arrow back

Example (Login):

User     LoginForm    AuthService    Database
  |          |            |             |
  |--enter-->|            |             |
  |          |--validate->|             |
  |          |            |---query---->|
  |          |            |<--result----|
  |          |<-success---|             |
  |<-redirect|            |             |

Object Modularization = Organizing classes into packages/modules.

Principles:

1. Package Cohesion

• Group related classes
• Single purpose per package

2. Acyclic Dependencies

• No circular dependencies
• A→B→C but not C→A

3. Stable Dependencies

• Depend on stable packages
• Stable = Less likely to change

Package Diagram:

Shows packages and dependencies between them