Software Engineering — Complete BSCS-Level Guide

1. Introduction to Software Engineering

What is Software Engineering? The systematic application of engineering principles to the development,
operation, and maintenance of software.

"Software Engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines." — Bauer,
1969

Why Software Engineering exists:

 Software crisis of 1960s — projects over budget, late, unreliable

 Need for discipline, methods, tools to build large complex systems

Software vs Hardware:

Software Hardware
Wears out? No (degrades through change) Yes (physical wear)
Manufactured? No (developed/engineered) Yes
Custom built? Usually Often reused components
Failure curve Spikes at changes Bathtub curve

Software Failure Curve:

Failure
Rate
│ ↑ spike at each change
│ ┐ ┐
│ └┐ └┐
│ └────└──────── actual
│ ─────────────── ideal (flat)
└──────────────────────── Time

Software Characteristics:

 Intangible (can't touch it)

 Flexible (easy to change — but this causes problems)
 Doesn't wear out but deteriorates through poor maintenance
 Custom built (few standard components)
 Complex (millions of interacting parts)

Types of Software:

Type Example
System Software OS, compilers, device drivers
Application Software Word, browsers, games
Engineering/Scientific MATLAB, simulation tools
Embedded Software in car ECU, medical devices
Web Applications Facebook, Gmail
AI/ML Software Recommendation systems, chatbots
 Type Example
Legacy Software Old COBOL banking systems still running

Software Engineering Layers:

┌─────────────────────────────┐
│ Tools │ ← CASE tools, IDEs
├─────────────────────────────┤
│ Methods │ ← How to build (design, test)
├─────────────────────────────┤
│ Process │ ← Framework (Agile, Waterfall)
├─────────────────────────────┤
│ Quality Focus │ ← Foundation: commitment to quality
└─────────────────────────────┘

Software Development Challenges:

 Scale — from 100 lines to 100 million lines

 Quality — correctness, reliability, security
 Cost — most expensive part is people, not hardware
 Change — requirements always change
 Complexity — interactions between components

2. Software Process Models

Software Process = a structured set of activities required to develop a software system.

Four fundamental activities (any process includes these):

1. Specification — what should the system do?

2. Development — design and program it
3. Validation — check it does what customer wants
4. Evolution — change it as requirements change

Waterfall Model

Sequential phases, each must complete before next begins.

Requirements
↓
System Design
↓
Implementation
↓
Testing & Integration
↓
Deployment
↓
Maintenance

Pros:

 Simple and easy to manage

 Well-documented
  Clear milestones
 Good for fixed, well-understood requirements

Cons:

 Inflexible — hard to go back

 Working software only at end
 Customer doesn't see product until late
 High risk — problems found late are expensive to fix

When to use: Requirements are clear, fixed, well-understood. Government contracts, safety-critical systems.

V-Model (Verification and Validation Model)

Extension of Waterfall — each development stage has a corresponding testing stage.

Requirements ─────────────────── Acceptance Testing

System Design ─────────── System Testing
Architecture ─────── Integration Testing
Module Design ── Unit Testing
Coding

Left side: Development activities (define what to build) Right side: Testing activities (verify each level)

 Verification: "Are we building the product right?" (process check)

 Validation: "Are we building the right product?" (customer check)

Pro: Testing planned early, defects caught earlier Con: Still rigid like Waterfall

Incremental Model

Deliver system in increments. Each increment adds functionality.

Increment 1: Core features → deliver → feedback

Increment 2: Add features → deliver → feedback
Increment 3: Add features → deliver → feedback
...

Pros:

 Working software delivered early

 Lower risk
 Customer feedback incorporated
 Easier to test smaller increments

Cons:

 Architecture may degrade over time

 Requires good planning of increments
Spiral Model (Barry Boehm, 1986)

Risk-driven model. Each iteration (spiral) covers 4 quadrants.

Planning ←───────────── Start

↓
Risk Analysis & Prototyping
↓
Development & Testing
↓
Evaluate & Plan Next Spiral
↓ (next spiral outward)

4 Quadrants each spiral:

1. Determine objectives — goals, alternatives, constraints

2. Identify and resolve risks — prototype, analyze risks
3. Development and test — build the deliverable
4. Plan next iteration — review and plan

Risk-driven — if risk is too high, project can be cancelled early (saves money).

Best for: Large, high-risk, complex projects. Con: Complex to manage, expensive, hard to define risk always.

Prototyping Model

Build a quick, incomplete version to understand requirements, then throw it away (or evolve it).

Requirements → Build Prototype → User Evaluates

↑ ↓
└─── Refine ←──────┘
↓ (when satisfied)
Build actual system

Types:

 Throwaway prototype — quick and dirty, only for learning

 Evolutionary prototype — prototype becomes the actual system

Pro: Helps clarify unclear requirements Con: Users may think prototype IS the system. Poor quality code goes to
production.

RAD Model (Rapid Application Development)

Emphasizes rapid prototyping and quick feedback. Uses components and code generation.

Business Modeling → Data Modeling → Process Modeling

→ Application Generation → Testing
(done in 60-90 days per module)

Pro: Very fast delivery Con: Needs skilled team, not good for very large systems
Unified Process (RUP — Rational Unified Process)

Use-case driven, architecture-centric, iterative and incremental.

4 Phases:

Phase Focus
Inception What is the scope? Is it worth doing?
Elaboration What is the architecture? What are the risks?
Construction Build the system iteratively
Transition Deploy to users, training, bug fixes

9 Workflows (disciplines) run across all phases with varying intensity: Business Modeling, Requirements,
Analysis & Design, Implementation, Test, Deployment, Config Management, Project Management, Environment.

Comparison Summary

Model Best For Key Feature

Waterfall Fixed requirements Sequential
V-Model Safety-critical Test at every level
Incremental Partial delivery needed Iterative delivery
Spiral High-risk large systems Risk driven
Prototyping Unclear requirements Quick prototype
RAD Fast delivery Component reuse
RUP Large enterprise Use-case driven

3. Agile Software Development

Agile = an umbrella term for iterative, flexible development approaches that emphasize people, working software,
and customer collaboration over rigid processes.

Agile Manifesto (2001) — The Foundation

4 Values:

Individuals and interactions OVER processes and tools

Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan

12 Principles (key ones):

 Deliver working software frequently (weeks, not months)

 Welcome changing requirements, even late
 Business people and developers work together daily
 Build projects around motivated individuals
 Face-to-face conversation is most efficient
 Working software is the primary measure of progress
 Sustainable development pace (no crunch culture)
 Continuous attention to technical excellence
  Simplicity — maximize work NOT done
 Self-organizing teams produce best architectures
 Regular reflection and adaptation

Scrum (Most Popular Agile Framework)

Roles:

Role Responsibility
Product Owner Defines what to build, maintains Product Backlog, business rep
Scrum Master Facilitates process, removes impediments, protects team
Development Team Cross-functional, self-organizing, 3-9 people, builds the product

Artifacts:

Artifact Description
Product Backlog Prioritized list of all desired features (user stories)
Sprint Backlog Features selected for current sprint
Increment Working software at end of sprint

Events (Ceremonies):

Event Duration Purpose

Sprint 1-4 weeks Time-boxed development iteration
Sprint Planning 2-8 hours Select backlog items for sprint
Daily Scrum (Standup) 15 min Sync: What did I do? What will I do? Blockers?
Sprint Review 2-4 hours Demo working software to stakeholders
Sprint Retrospective 1-3 hours Improve process: what went well/badly?

Scrum Process Flow:

Product Backlog
↓ (Sprint Planning)
Sprint Backlog
↓
[Sprint 1-4 weeks]
Daily Scrum ↺
↓
Increment (Potentially Shippable Product)
↓
Sprint Review + Retrospective
↓ (next Sprint)

Definition of Done (DoD): Agreement on what "done" means — coded + tested + reviewed + documented +
deployed.

Kanban

Visual workflow management. No sprints — continuous flow.

TO DO | IN PROGRESS | REVIEW | DONE
─────────┼─────────────┼────────┼──────
Task A │ Task C │ Task E │Task F
Task B │ │ │Task G
│ [WIP = 2] │ │

WIP Limits (Work In Progress): Maximum items allowed in each column. Prevents bottlenecks.

Key Metrics:

 Lead Time — time from request to delivery

 Cycle Time — time from start of work to delivery

Kanban vs Scrum:

Scrum Kanban
Cadence Fixed sprints Continuous
Roles 3 defined roles No required roles
Change After sprint Anytime
Best for New product development Ongoing support/maintenance

Extreme Programming (XP)

Engineering-focused agile. Strong technical practices.

Key Practices:

Practice Description
Pair Programming Two developers, one keyboard — driver + navigator
TDD (Test-Driven Development) Write test first, then code to pass it
Continuous Integration Integrate and build multiple times per day
Refactoring Improve code structure without changing behavior
Simple Design Build simplest thing that works
Collective Ownership Any developer can change any code
On-site Customer Customer available full-time
Small Releases Release frequently
Sustainable Pace No overtime
Coding Standards Consistent style across team

TDD Cycle (Red-Green-Refactor):

1. RED → Write a failing test

2. GREEN → Write minimum code to pass test
3. REFACTOR → Improve code, keep tests passing
4. Repeat

SAFe (Scaled Agile Framework)

Agile for large enterprises with many teams.

 Organizes teams into Agile Release Trains (ARTs)

  PI Planning (Program Increment) — all teams plan together every 8-12 weeks

4. Software Requirements Engineering

Requirements Engineering = process of finding out, analyzing, documenting, and verifying what the system
should do.

Getting requirements wrong is the most expensive mistake in software development.

Types of Requirements

Functional Requirements: What the system does — specific behaviors, functions.

"The system shall allow users to login with email and password."
"The system shall send a confirmation email upon registration."

Non-Functional Requirements (Quality Attributes): How the system performs — constraints on quality.

Category Example
Performance System shall respond in < 2 seconds
Reliability System shall be available 99.9% uptime
Scalability System shall support 10,000 concurrent users
Security Passwords must be stored as bcrypt hashes
Usability New user shall complete registration in < 3 minutes
Maintainability Code shall follow SOLID principles
Portability System shall run on Windows, Linux, macOS

Domain Requirements: Requirements from application domain.

"The system shall calculate VAT according to FBR tax regulations."

Requirements Engineering Process

Feasibility Study
↓
Requirements Elicitation & Analysis
↓
Requirements Specification
↓
Requirements Validation
↓
Requirements Management (ongoing)

Elicitation Techniques:

Technique When to use

Interviews Get detailed information from stakeholders
Questionnaires Many users, quantitative data
Observation (Ethnography) Understand real work practices
 Technique When to use
Workshops/JAD Group sessions, consensus building
Brainstorming Creative, generate new ideas
Prototyping Unclear requirements, user feedback
Use Case Analysis Identify user-system interactions
Document Analysis Study existing documents

Use Cases

Describes how a user (actor) interacts with the system to achieve a goal.

Use Case: Login

Actor: Registered User
Precondition: User has an account
Main Flow:
1. User enters email and password
2. System validates credentials
3. System grants access
4. User sees dashboard
Alternative Flow:
2a. Invalid credentials → show error → return to step 1
2b. Account locked → show message
Postcondition: User is authenticated

User Stories (Agile)

As a [type of user],
I want [some goal],
So that [some reason/value].

Example:
"As a customer, I want to save items to a wishlist,
so that I can purchase them later."

INVEST criteria for good user stories:

 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

Acceptance Criteria:

Given [context],
When [action],
Then [outcome].

Given I am logged in,

When I add an item to wishlist,
Then the item appears in my wishlist page.

Requirements Specification (SRS Document)

SRS (Software Requirements Specification) — the contract between customer and developer.
IEEE 830 SRS Structure:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions
2. Overall Description
2.1 Product Perspective
2.2 User Characteristics
3. Specific Requirements
3.1 Functional Requirements
3.2 Non-Functional Requirements
3.3 Interface Requirements

Properties of Good Requirements:

 Unambiguous — one interpretation only

 Complete — all requirements included
 Consistent — no conflicts
 Verifiable — can be tested
 Traceable — can trace to source and design
 Feasible — technically and financially possible

Requirements Validation Techniques

 Reviews/Walkthroughs — team reads requirements together

 Prototyping — build prototype to validate
 Test-case generation — if you can't write a test → requirement is bad
 Traceability matrix — maps requirements to design, code, tests

5. Software Project Management

Project Management = planning, monitoring, and controlling software projects to deliver on time, within budget,
with required quality.

Iron Triangle:

Scope
/\
/ \
/ \
/ \
Cost ──────── Time

Changing one affects the others!

Project Manager Responsibilities:

 Planning and scheduling

 Estimating cost and effort
 Risk management
 Team management
 Progress monitoring and reporting
 Stakeholder communication
Project Planning

Work Breakdown Structure (WBS): Hierarchically decompose project into manageable tasks.

Software Project
├── Requirements
│ ├── Stakeholder interviews
│ ├── Use case modeling
│ └── SRS document
├── Design
│ ├── Architecture design
│ └── Database design
├── Implementation
│ ├── Frontend
│ └── Backend
└── Testing
├── Unit tests
└── Integration tests

Gantt Chart: Bar chart showing tasks against time. Shows start/end dates and dependencies.

Task Week: 1 2 3 4 5 6
Requirements [====]
Design [===]
Implementation [======]
Testing [==]

PERT Chart (Program Evaluation Review Technique): Network diagram showing task dependencies and
critical path.

Critical Path Method (CPM):

Identify the longest path through the network = Critical Path

Any delay on critical path = delay in project
Tasks NOT on critical path have float/slack (can be delayed without affecting deadline)

Example:
A(3) → B(2) → D(4) = 9 days ← Critical Path
A(3) → C(5) = 8 days

Effort Estimation

Lines of Code (LOC): Count expected lines. Simple but problematic (language dependent, different styles).

Function Point Analysis: Count functional units — inputs, outputs, inquiries, files, interfaces.

FP = Unadjusted FP × Technical Complexity Factor

COCOMO (Constructive Cost Model):

Effort (person-months) = a × (KLOC)^b

Duration (months) = c × (Effort)^d
Staff = Effort / Duration

Where a, b, c, d depend on project type:

Organic (simple): a=2.4, b=1.05
Semi-detached: a=3.0, b=1.12
Embedded (complex): a=3.6, b=1.20
Planning Poker (Agile): Team estimates user story size using story points. Everyone reveals estimate
simultaneously → discuss disagreements.

T-shirt sizing: XS, S, M, L, XL for relative estimation.

Project Monitoring

Earned Value Management (EVM):

PV (Planned Value) = budgeted cost of work scheduled

EV (Earned Value) = budgeted cost of work performed
AC (Actual Cost) = actual cost of work performed

Schedule Variance (SV) = EV - PV (positive = ahead of schedule)

Cost Variance (CV) = EV - AC (positive = under budget)

SPI (Schedule Performance Index) = EV/PV (>1 = good)

CPI (Cost Performance Index) = EV/AC (>1 = good)

Velocity (Agile): Story points completed per sprint. Used to predict future sprints.

6. Software Design

Design = translating requirements into a blueprint for building the software.

Design Levels:

 Architectural Design — overall structure, components

 High-Level Design (HLD) — modules and interactions
 Low-Level Design (LLD) — detailed design of each module

Design Goals:

 Correctness, Completeness
 Cohesion — elements within a module belong together (HIGH is good)
 Coupling — dependency between modules (LOW is good)

Cohesion (High is GOOD)

How strongly related the elements within a single module are.

Type Quality Description Example

Functional Best ✅ All elements contribute to single task calculateTax()
Sequential Good Output of one = input of next Read → Process
Communicational Good Work on same data All use customer
Procedural Medium Follow sequence of steps Init → Read → Write
Temporal Low Things done at same time initializeAll()
Logical Low Similar operations, selected by flag handleIO(type)
Coincidental Worst ❌ Random elements grouped together [Link]
Coupling (Low is GOOD)

How much modules depend on each other.

Type Quality Description

No coupling Best Independent modules
Data coupling Good ✅ Share data via parameters
Stamp coupling OK Share composite data
Control coupling Bad One passes control flag to other
External coupling Bad Both depend on external format
Common coupling Worse Share global data
Content coupling Worst ❌ One directly accesses internals of other

Design Principles

DRY (Don't Repeat Yourself): Every piece of knowledge has a single, unambiguous representation.

KISS (Keep It Simple, Stupid): Simplest solution is usually best.

YAGNI (You Aren't Gonna Need It): Don't add functionality until needed.

Separation of Concerns: Divide system into distinct sections, each addressing a separate concern.

SOLID (revisited at design level):

S – Single Responsibility: One class, one reason to change

O – Open/Closed: Open for extension, closed for modification
L – Liskov Substitution: Subclass can replace parent class
I – Interface Segregation: Many specific interfaces > one general
D – Dependency Inversion: Depend on abstractions, not concretions

Design Patterns (Gang of Four)

Reusable solutions to commonly occurring design problems.

Creational Patterns:

Singleton — ensures only one instance exists:

class Singleton {
private static Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) instance = new Singleton();
return instance;
}
}

Factory Method — create objects without specifying exact class:

interface Shape { void draw(); }

class Circle implements Shape { void draw() { ... } }
class Square implements Shape { void draw() { ... } }

class ShapeFactory {
 static Shape create(String type) {
if ([Link]("circle")) return new Circle();
return new Square();
}
}

Builder — construct complex objects step by step.

Structural Patterns:

Adapter — makes incompatible interfaces work together (like a power adapter).

Decorator — add behavior to objects dynamically without subclassing.

Facade — simplified interface to a complex subsystem.

Behavioral Patterns:

Observer — when one object changes, all dependents notified (event system):

interface Observer { void update(String event); }

class EventSystem {
List<Observer> observers = new ArrayList<>();
void subscribe(Observer o) { [Link](o); }
void notify(String event) {
for (Observer o : observers) [Link](event);
}
}

Strategy — define family of algorithms, make them interchangeable:

interface SortStrategy { void sort(int[] arr); }

class BubbleSort implements SortStrategy { ... }
class QuickSort implements SortStrategy { ... }
class Sorter {
SortStrategy strategy;
void setStrategy(SortStrategy s) { strategy = s; }
void sort(int[] arr) { [Link](arr); }
}

Command — encapsulate request as an object (undo/redo).

Iterator — traverse collection without knowing its internals.

Template Method — define skeleton of algorithm, let subclasses fill in steps.

7. Software Architecture

Software Architecture = the high-level structure of a software system — its components, how they interact, and
the principles governing that design.

"Architecture is the set of significant decisions about the organization of a software system."
— Garlan & Shaw

Architectural Drivers:

 Functional requirements
 Quality attributes (performance, security, scalability)
  Constraints (technology, budget, team skills)

Architectural Patterns

Layered (N-Tier) Architecture:

┌─────────────────────┐
│ Presentation Layer │ ← UI
├─────────────────────┤
│ Business Logic │ ← Application rules
├─────────────────────┤
│ Data Access Layer │ ← DB queries
├─────────────────────┤
│ Database │ ← Storage
└─────────────────────┘

 Each layer only communicates with adjacent layers

 Used in: most enterprise web apps
 Pro: Separation of concerns, testable
 Con: Can be slow due to layers, changes ripple through

MVC (Model-View-Controller):

User → Controller → Model (data/logic)

↓
View (UI) ← Model

 Model — data and business logic

 View — presentation layer
 Controller — handles input, coordinates Model and View
 Used in: Django, Rails, Spring MVC

Microservices Architecture:

[User Service] [Order Service] [Payment Service] [Inventory Service]

↑ ↑ ↑ ↑
└───────────────┴───────────────┴────────────────┘
API Gateway
↑
Clients

 Each service = independent deployable unit

 Communicate via REST APIs or message queues
 Used by: Netflix, Amazon, Uber
 Pro: Independent deployment, scalability, fault isolation
 Con: Distributed system complexity, network overhead

Event-Driven Architecture:

Producer → Event Bus → Consumer A

→ Consumer B
→ Consumer C

 Components communicate via events

 Loose coupling
 Used in: real-time apps, IoT, financial systems
Client-Server:

Client (browser/app) → HTTP/API → Server → Database

 Most common web architecture

Pipe and Filter:

Input → Filter1 → Filter2 → Filter3 → Output

 Each filter transforms data

 Used in: Unix pipelines, ETL processes, compilers

Repository/Blackboard: Central data store that components read/write to. Used in: IDEs (central AST), AI
systems.

Service-Oriented Architecture (SOA): Similar to microservices but coarser grain, uses enterprise service bus
(ESB).

Architecture Evaluation

ATAM (Architecture Tradeoff Analysis Method): Evaluate architecture against quality attributes. Identify
sensitivity points, tradeoffs, risks.

Quality Attributes (FURPS+):

F – Functionality
U – Usability
R – Reliability
P – Performance
S – Supportability
+ Security, Portability, Scalability

8. User Interface Design

UI Design = designing the visual and interactive layer users interact with.

UX (User Experience) = overall experience of using the product — broader than just UI.

UI Design Principles (Shneiderman's 8 Golden Rules)

1. Strive for consistency — same actions, terminology throughout

2. Enable frequent users to use shortcuts — keyboard shortcuts, macros
3. Offer informative feedback — every action should have feedback
4. Design dialogs to yield closure — beginning, middle, end to tasks
5. Offer error prevention and simple error handling — confirm dangerous actions
6. Permit easy reversal of actions — Ctrl+Z, back button
7. Support internal locus of control — user should feel in control
8. Reduce short-term memory load — don't make users remember across screens
Nielsen's 10 Usability Heuristics

1. Visibility of system status — always keep users informed

2. Match between system and real world — use familiar language
3. User control and freedom — easy undo
4. Consistency and standards — follow platform conventions
5. Error prevention — prevent problems from occurring
6. Recognition over recall — show options, don't make user remember
7. Flexibility and efficiency — accelerators for expert users
8. Aesthetic and minimalist design — no irrelevant information
9. Help users recognize, diagnose, and recover from errors — plain language error messages
10. Help and documentation — easy to search, task-focused

UI Design Process

User Research → Information Architecture → Wireframing

→ Prototyping → Usability Testing → Visual Design → Implementation

User Research: Interviews, surveys, personas, user journey maps.

Personas: Fictional character representing a user type.

Persona: "Ahmed, 28, Software Engineer"

Goals: Quick task completion, keyboard shortcuts
Pain points: Complex navigation, slow loading
Tech level: High

Wireframe: Low-fidelity sketch of UI layout (no colors/images).

Mockup: High-fidelity static design (colors, fonts, images).

Prototype: Interactive mockup (clickable, shows user flows).

Usability Testing:

 Watch real users perform tasks

 Note where they struggle
 Measure: Task success rate, time on task, error rate, satisfaction

Accessibility (a11y)

Design for users with disabilities.

WCAG (Web Content Accessibility Guidelines) 4 principles (POUR):

 Perceivable — info presentable to all senses

 Operable — interface is navigable (keyboard accessible)
 Understandable — content is readable, predictable
 Robust — works with assistive technologies
Responsive Design

UI adapts to different screen sizes.

Desktop (1200px+) → Tablet (768px-1199px) → Mobile (< 768px)

 Fluid grids, flexible images, media queries

9. Software Implementation & Coding

Implementation = translating design into executable code.

Coding Standards & Best Practices

Naming Conventions:

# Variables: descriptive, lowercase_with_underscores (Python)

total_price = 0 #✅
tp = 0 #❌

# Classes: PascalCase
class CustomerAccount: # ✅

# Constants: UPPER_SNAKE_CASE
MAX_RETRY_COUNT = 3 # ✅

# Functions: verb_noun
def calculate_total(): # ✅
def ct(): #❌

Clean Code Principles:

 Functions should do ONE thing

 Functions should be small (< 20 lines)
 No more than 3 parameters per function
 No side effects
 DRY — Don't Repeat Yourself
 Comments explain WHY, not WHAT

Code Smells (signs of bad code):

Smell Description Fix

Long Method Function too long Extract method
God Class Class does too much Split into smaller classes
Duplicate Code Same code in multiple places Extract to shared function
Long Parameter List Too many parameters Use parameter object
Magic Numbers Unexplained constants Named constants
Dead Code Unused variables/functions Delete it
Inappropriate Intimacy Classes too dependent Reduce coupling
Refactoring: Improving internal structure of code WITHOUT changing external behavior.

Common refactorings:

 Extract Method — pull code into its own function

 Rename Variable — make purpose clearer
 Extract Class — split God class
 Move Method — method in wrong class
 Replace Magic Number with Constant

Code Review

Systematic examination of code by peers before merging.

Benefits:

 Catch bugs early (cheapest time to fix)

 Share knowledge
 Maintain code quality
 Enforce standards

Good Code Review:

 Review ≤ 400 lines at a time

 Focus on logic, not style (use linter for style)
 Be constructive, not personal
 Check: correctness, security, performance, readability, tests

Version Control with Git (in development context)

Branching Strategies:

main (production)
├── develop (integration)
│ ├── feature/login
│ ├── feature/payment
│ └── feature/search
├── hotfix/critical-bug
└── release/v2.0

Git Flow: feature → develop → release → main GitHub Flow: feature → main (simpler, for CI/CD) Trunk-
Based Development: All commits go directly to main (needs feature flags)

CI/CD Pipeline

Code Push → Automated Tests → Build → Deploy to Staging

→ Integration Tests → Deploy to Production

CI (Continuous Integration): Merge code frequently + automated tests run on every push.

CD (Continuous Delivery): Code always in deployable state, deploy at any time.

CD (Continuous Deployment): Every passing build automatically deployed to production.

Tools: Jenkins, GitHub Actions, GitLab CI, CircleCI.

10. Software Testing

Testing = process of evaluating a system to find defects and ensure it meets requirements.

"Testing shows the presence of bugs, not their absence." — Dijkstra

Verification vs Validation:

 Verification: "Are we building the product right?" — process check

 Validation: "Are we building the right product?" — customer needs check

Testing Levels (V-Model)

Unit Testing: Test individual functions/methods in isolation.

def add(a, b):

return a + b

def test_add():
assert add(2, 3) == 5
assert add(-1, 1) == 0
assert add(0, 0) == 0

 Written by developers
 Fast, isolated
 Mock external dependencies

Integration Testing: Test how modules work together.

 Top-down: Test from UI down, stub lower modules

 Bottom-up: Test from lowest module up, use test drivers
 Big Bang: Integrate everything at once, test (risky)
 Sandwich/Hybrid: Combine top-down and bottom-up

System Testing: Test complete integrated system against requirements.

 Done by QA team
 Black-box testing

Acceptance Testing: Customer validates system meets business needs.

 UAT (User Acceptance Testing) — real users test

 Alpha testing — testing at developer site by real users
 Beta testing — released to limited real users in their environment
Testing Techniques

Black Box Testing: Test without knowledge of internal code. Based on requirements.

 Equivalence Partitioning: Divide input into equivalence classes. Test one value from each.

Input: age (1-120)

Partitions: Invalid (<1), Valid (1-120), Invalid (>120)
Test: -5, 25, 150 (one from each partition)

 Boundary Value Analysis: Test at boundaries (most bugs occur there).

Input range: 1-100

Test: 0, 1, 2, 99, 100, 101

 Decision Table: Test all combinations of conditions.

 State Transition Testing: Test transitions between system states.

White Box Testing: Test with knowledge of internal code. Verify internal logic.

 Statement Coverage: Every statement executed at least once.

 Branch Coverage: Every branch (true/false) taken at least once.
 Path Coverage: Every possible path through code tested.
 Condition Coverage: Every boolean sub-expression true and false.

def classify(x):
if x > 0: # Branch 1: T/F
if x > 100: # Branch 2: T/F
return "large"
return "small"
return "non-positive"

# For full branch coverage, need tests:

# x = 50 (T,F → "small")
# x = 150 (T,T → "large")
# x = -5 (F → "non-positive")

Grey Box Testing: Partial knowledge of internals.

Types of Testing

Type What it checks

Functional Does it do what it should?
Performance Speed, throughput under load
Load Testing Behavior under expected load
Stress Testing Behavior beyond normal load (break it)
Reliability Works correctly over time
Security Vulnerabilities, access control
Usability Is it easy to use?
Regression New changes didn't break existing features
Smoke Testing Basic sanity check — is build stable enough to test?
Sanity Testing Quick check of specific functionality
Exploratory Unscripted, creative testing
 Type What it checks
Mutation Testing Modify code slightly → tests should catch it

Test-Driven Development (TDD)

1. Write failing test (RED)

2. Write minimal code to pass (GREEN)
3. Refactor code (REFACTOR)
4. Repeat

Benefits:
- Tests always exist
- Forces good design (testable code = modular code)
- Confidence to refactor
- Documentation through tests

BDD (Behavior-Driven Development): Extends TDD — tests written in natural language.

Feature: User Login

Scenario: Successful login
Given I am on the login page
When I enter valid credentials
Then I should see the dashboard

Defect Management

Defect Life Cycle:

New → Assigned → Open (being fixed) → Fixed → Retest

→ Verified → Closed
or
→ Reopen (if not fixed properly)

Defect Severity vs Priority:

 Severity: Technical impact (High/Medium/Low)

 Priority: Business urgency (High/Medium/Low)
 A cosmetic bug on the login page might be Low severity but High priority (very visible)

Test Metrics:

 Defect density = defects / KLOC

 Test coverage = % of requirements tested
 Defect detection efficiency = defects found in testing / total defects

11. Software Maintenance & Evolution

Maintenance = modification of software after delivery to correct faults, improve performance, or adapt to changed
environment.

Fact: 60-80% of total software cost is maintenance!

Types of Maintenance (Lientz & Swanson)

Type % of maintenance Description Example

Corrective 20% Fix bugs Crash on null input
Adaptive 20% Adapt to environment changes Upgrade to new OS
Perfective 50% Improve performance/features Add new search feature
Preventive 10% Prevent future problems (refactoring) Reduce technical debt

Software Evolution (Lehman's Laws)

Lehman studied how large software systems evolve over time.

Law Description
Continuing Change System must be continually adapted or becomes less satisfactory
Evolving system becomes more complex unless work is done to reduce
Increasing Complexity
it
Self Regulation Evolution process is self-regulating
Conservation of Organizational
Rate of change stays roughly constant
Stability
Conservation of Familiarity Can't add too much at once
Continuing Growth Functionality must increase to satisfy users
Declining Quality Quality appears to decline unless rigorously maintained
Feedback System Process is multi-level feedback system

Legacy Systems

Old systems that are still in use but use outdated technology.

Strategies (STAMP):

 Scrap — discard entirely, build new (risky, expensive)

 Maintain — keep fixing bugs, no major changes
 Re-engineer — restructure/rewrite with modern architecture
 Replace — buy commercial product

Technical Debt: The accumulated cost of poor design decisions and shortcuts. Like financial debt — the longer
you ignore it, the more interest you pay.

Reengineering Activities

Source Code → Reverse Engineering → Design Recovery → Restructuring → Forward Engineering → New
System

 Reverse Engineering — understand existing system from code

 Refactoring — improve code structure
 Forward Engineering — build improved system
12. Software Quality Assurance

SQA = set of activities ensuring the software development process and product meet defined quality standards.

Quality Definitions

Product Quality — does the software have the right attributes?

Process Quality — are we following good processes? (good process → good product)

McCall's Quality Model:

Product Operation: Correctness, Reliability, Efficiency, Integrity, Usability

Product Revision: Maintainability, Testability, Flexibility
Product Transition: Portability, Reusability, Interoperability

ISO/IEC 25010 Quality Model: Functional Suitability, Performance Efficiency, Compatibility, Usability,
Reliability, Security, Maintainability, Portability.

CMM / CMMI (Capability Maturity Model Integration)

Framework for assessing and improving software development process maturity.

5 Levels:

Level Name Description

1 Initial Chaotic, ad hoc, success depends on heroes
2 Managed Basic project management, repeatable
3 Defined Standard processes documented, followed
4 Quantitatively Managed Process measured and controlled
5 Optimizing Continuous process improvement

Most organizations are Level 1-2. Level 3+ needed for government/defense contracts.

ISO Standards

Standard Purpose
ISO 9001 General quality management systems
ISO/IEC 12207 Software life cycle processes
ISO/IEC 25010 Software product quality model
ISO/IEC 27001 Information security management

Reviews and Inspections

Informal Review: Casual, ad-hoc reading.

Walkthrough: Author leads team through document, collects feedback.

Technical Review: Peer check for technical correctness.

Inspection (Fagan Inspection): Most formal and effective.

Roles: Moderator, Author, Reader, Inspector(s)

Steps: Planning → Overview → Preparation → Inspection Meeting → Rework → Follow-up

Inspections find 60-90% of defects — most cost-effective defect removal method!

Software Audits

Formal review of software project, process, or product by an independent team to check compliance with standards.

13. Software Metrics & Measurement

Software Metrics = quantitative measure of software process, product, or project.

Why measure?

 "You can't manage what you can't measure" — Peter Drucker

 Predict cost/schedule, assess quality, improve process

Types of Metrics

Process Metrics: Measure development process.

 Defect detection rate, cost of quality, review efficiency

Product Metrics: Measure software product.

 Size, complexity, coupling, cohesion

Project Metrics: Measure project status.

 Budget variance, schedule variance, team productivity

Size Metrics

Lines of Code (LOC):

 Simple but problematic

 Different languages, different LOC for same functionality
 Doesn't measure complexity

Function Points (FP): Measure functionality delivered to user regardless of language.

Count:
- External Inputs (EI)
- External Outputs (EO)
- External Inquiries (EQ)
- Internal Logical Files (ILF)
- External Interface Files (EIF)

Each weighted by complexity (simple/average/complex)

Adjusted by Technical Complexity Factor (TCF)

Complexity Metrics

Cyclomatic Complexity (McCabe): Measures number of linearly independent paths through code.

CC = E - N + 2P
Where: E = edges, N = nodes, P = connected components (usually 1)

Or simply: CC = number of decision points + 1

int example(int x, int y) {

if (x > 0) // decision 1
if (y > 0) // decision 2
return 1;
return 0;
}
CC = 2 + 1 = 3

Guidelines:

 CC ≤ 10: Simple, low risk

 CC 11-20: More complex
 CC > 20: High risk, should refactor

OO Metrics (Chidamber & Kemerer)

Metric Name Description

WMC Weighted Methods per Class Sum of complexities of all methods
DIT Depth of Inheritance Tree Length of longest path to root
NOC Number of Children Direct subclasses
CBO Coupling Between Objects Number of classes coupled to
RFC Response for a Class Methods callable in response to a message
LCOM Lack of Cohesion in Methods Methods not sharing instance variables

Quality Metrics

Defect Density = Total Defects / KLOC

Defect Removal Efficiency = Defects found before release / Total defects × 100%
(Good DRE = >95%)

Mean Time Between Failures (MTBF) = Mean time system operates without failure

Mean Time To Repair (MTTR) = Average time to fix a failure

Availability = MTBF / (MTBF + MTTR) × 100%

14. Software Configuration Management

SCM = tracking and controlling changes to software throughout its lifecycle.

Why SCM?

 Multiple developers changing same files

 Need to reproduce old versions
 Track who changed what and when
 Manage multiple versions/releases

Key SCM Concepts

Configuration Item (CI): Any artifact that needs to be controlled: source code, documents, test cases, build
scripts, configuration files.

Baseline: An approved, formally reviewed version of a CI that serves as basis for further development. Changes
only through formal change control.

Version: A specific instance of a CI at a point in time.

Release: Version delivered to customer.

Branch: Diverged line of development.

Change Management Process

Change Request Submitted

↓
Change Control Board (CCB) Review
↓
Approved? → No → Rejected (notify requester)
↓ Yes
Impact Analysis
↓
Assign to Developer
↓
Implement, Test
↓
Review & Approve
↓
Update Baseline
↓
Release

Change Control Board (CCB): Committee that approves/rejects change requests based on impact on cost,
schedule, quality.
Version Control Systems

System Type Description

CVS Centralized Old, limited
SVN (Subversion) Centralized Single central repository
Git Distributed Every clone is full repository
Mercurial Distributed Similar to Git

Git Internals:

Working Directory → (git add) → Staging Area → (git commit) → Local Repo → (git push) → Remote Repo

Semantic Versioning:

[Link]
2.4.1
│ │ └── Bug fixes (backward compatible)
│ └──── New features (backward compatible)
└────── Breaking changes

Build Management

Build automation = automatically compile, link, test, package software.

Source Code → Compile → Link → Package → Deploy

Tools: Make, Maven (Java), Gradle, CMake

Continuous Integration — trigger build on every commit, run all tests.

15. Software Risk Management

Risk = potential problem that may cause loss or harm. Has two dimensions:

 Probability — likelihood of occurring

 Impact — severity if it occurs

Risk Exposure = Probability × Impact

Types of Software Risks

Type Example
Project Risks Team member leaves, budget cut
Product Risks Requirements change, wrong architecture
Business Risks Competitor releases same product, company sold
Technical Risks New technology doesn't scale, performance
People Risks Key developer sick, team conflicts
Risk Management Process

Risk Identification
↓
Risk Analysis (Probability × Impact)
↓
Risk Prioritization
↓
Risk Planning (mitigation strategies)
↓
Risk Monitoring (ongoing)

Risk Identification Techniques

 Checklist — known risks from past projects

 Brainstorming — team generates risks
 Assumption Analysis — what if our assumptions are wrong?
 SWOT Analysis — Strengths, Weaknesses, Opportunities, Threats
 Risk Taxonomy — categorized risk checklist

Risk Analysis — Risk Matrix

Impact
Low Medium High
Probability
High │ Med │ High │ Critical
Medium │ Low │ Med │ High
Low │ Low │ Low │ Med

Risk Mitigation Strategies (ATAM)

Strategy Description Example

Avoid Change plan to eliminate risk Drop risky feature
Transfer Shift risk to third party Buy insurance, outsource
Mitigate Reduce probability or impact Prototype to validate tech
Accept Acknowledge and monitor Low impact risks

Contingency Plan: If risk occurs, what do we do?

Risk: Key developer leaves

Mitigation: Cross-train team members, document knowledge
Contingency: Hire contractor, extend deadline by 2 weeks

Risk Register

Formal document tracking all identified risks.

ID | Risk Description | Probability | Impact | Exposure | Owner | Mitigation | Status

1 | DB won't scale | Medium | High | High | DBA | Load test | Active
2 | Key dev leaves | Low | High | Medium | PM | Cross-train| Monitored
16. Software Security Engineering

Security Engineering = building security into software from the start, not as an afterthought.

"Security is not a feature — it's a property."

Security Goals — CIA Triad:

Confidentiality — data only accessible to authorized parties

Integrity — data only modified by authorized parties
Availability — system available when needed

Extended: + Authentication, Authorization, Non-repudiation

OWASP Top 10 (Most Critical Web Vulnerabilities)

# Vulnerability Description
1 Broken Access Control Users can act outside their permissions
2 Cryptographic Failures Weak/no encryption, storing sensitive data in plaintext
3 Injection SQL, NoSQL, LDAP injection attacks
4 Insecure Design Missing security controls in design phase
5 Security Misconfiguration Default credentials, unnecessary features enabled
6 Vulnerable Components Using outdated libraries with known vulnerabilities
7 Auth Failures Weak passwords, session management flaws
8 Data Integrity Failures Untrusted deserialization, insecure CI/CD
9 Logging Failures Not logging security events
10 SSRF Server-Side Request Forgery

Common Vulnerabilities in Detail

SQL Injection:

-- Vulnerable code:
query = "SELECT * FROM users WHERE name='" + username + "'"

-- Attacker inputs: ' OR '1'='1

-- Query becomes: SELECT * FROM users WHERE name='' OR '1'='1'
-- Returns ALL users!

-- Fix: Use parameterized queries

query = "SELECT * FROM users WHERE name=?"
[Link](query, (username,))

XSS (Cross-Site Scripting):

<!-- Attacker inputs in a comment field: -->

<script>[Link]='[Link]

<!-- If stored and displayed without sanitization, runs in other users' browsers -->

-- Fix: Escape output, Content Security Policy (CSP) headers

Buffer Overflow:

 Write past array boundary → overwrite return address

 Fixed with: bounds checking, safe functions, ASLR, stack canaries

Secure Development Practices

Microsoft SDL (Security Development Lifecycle):

Training → Requirements → Design → Implementation → Verification → Release → Response

↑ security activities embedded at every phase

Threat Modeling (STRIDE): Identify threats systematically:

Threat Property Violated Example

Spoofing Authentication Fake login
Tampering Integrity Modify data in transit
Repudiation Non-repudiation Deny sending message
Information Disclosure Confidentiality Data leak
Denial of Service Availability Flood server
Elevation of Privilege Authorization Gain admin rights

Threat Modeling Process:

1. Decompose application (data flow diagrams)

2. Identify threats (STRIDE per element)
3. Rate threats (DREAD: Damage, Reproducibility, Exploitability, Affected users, Discoverability)
4. Mitigate threats

Secure Coding Practices:

 Input validation — validate ALL user input on server side

 Output encoding — encode before displaying
 Parameterized queries — prevent SQL injection
 Least privilege — minimum permissions for DB accounts, service accounts
 Secure defaults — system secure by default, must opt OUT of security
 Defense in depth — multiple layers of security controls
 Fail securely — on error, deny access (don't expose info)
 Never trust user input — all input is potentially malicious
 Keep security simple — complexity is the enemy of security

Authentication Best Practices:

- Never store plaintext passwords (use bcrypt/Argon2 with salt)

- Enforce strong password policy
- Implement MFA
- Secure session management (random tokens, HTTPS only, expire sessions)
- Lock accounts after failed attempts
Cryptography in Security Engineering:

Symmetric (AES-256): Encrypt large data, fast

Asymmetric (RSA-2048): Key exchange, digital signatures
Hashing (SHA-256, bcrypt): Passwords, integrity
TLS/SSL: Encrypt data in transit

Security Testing:

Type Description
SAST (Static Analysis) Analyze code without running it (SonarQube)
DAST (Dynamic Analysis) Test running application (OWASP ZAP)
Penetration Testing Ethical hackers try to break in
Vulnerability Scanning Automated tools scan for known vulnerabilities
Code Review Security-focused manual review
Fuzzing Send random/malformed input to find crashes

Master Quick-Reference Table

# Topic Must-Know
1 Intro to SE Software characteristics, layers, types, system calls
2 Process Models Waterfall, V-model, Spiral, Incremental — pros/cons/when
3 Agile Scrum roles/artifacts/events, Kanban, XP, TDD cycle
4 Requirements Functional vs NFR, user stories, use cases, SRS
5 Project Management Iron triangle, WBS, Gantt, Critical Path, COCOMO, EVM
6 Software Design Cohesion/coupling, SOLID, design patterns (GoF)
7 Architecture Layered, MVC, Microservices, Event-driven, patterns
8 UI Design Shneiderman's 8 rules, Nielsen's heuristics, UX process
9 Implementation Clean code, code smells, refactoring, CI/CD, Git
10 Testing Levels (unit→acceptance), BB/WB, TDD, defect metrics
11 Maintenance 4 types, Lehman's laws, legacy systems, tech debt
12 Quality CMMI levels, ISO, inspections, DRE
13 Metrics LOC, FP, Cyclomatic Complexity, C&K metrics
14 Config Management Baseline, versioning, change control, Git flow
15 Risk Management Risk = Prob × Impact, risk matrix, ATAM, risk register
16 Security CIA, OWASP Top 10, STRIDE, SQL injection, SDL

Focus hardest on topics 3 (Agile/Scrum), 6 (Design patterns), 10 (Testing), 15 (Risk), and 16 (Security) —
these are highest-frequency in industry-level competency assessments. You've got everything you need to ace this!