SOFTWARE ENGINEERING - COMPLETE EXAM NOTES

🎯 UNIT 1: INTRODUCTION & PROCESS MODELS

1.1 SOFTWARE ENGINEERING - LAYERED APPROACH

Definition (IEEE): Application of systematic, disciplined, quantifiable approach to development,

operation, and maintenance of software.

Four Layers (Bottom to Top):

┌─────────────────────────────┐

│ TOOLS (automation support) │

├─────────────────────────────┤

│ METHODS (technical how-to) │

├─────────────────────────────┤

│ PROCESS (framework/glue) │

├─────────────────────────────┤

│ QUALITY FOCUS (foundation) │

└─────────────────────────────┘

Key Characteristics of Software:

1. Developed, not manufactured - no traditional production phase

2. Doesn't wear out - no physical deterioration (but does deteriorate due to changes)

3. Still mostly custom-built - though moving toward component-based

1.2 SOFTWARE PROCESS FRAMEWORK

Definition: Collection of activities, actions, and tasks performed to create software

5 Generic Framework Activities:

1. Communication - Understand stakeholder objectives, gather requirements

2. Planning - Create project plan (tasks, risks, resources, schedule)

3. Modeling - Create models to understand requirements and design

4. Construction - Code generation + testing

5. Deployment - Deliver to customer, get feedback

Umbrella Activities (apply throughout):

 Project tracking and control

 Risk management
  Quality assurance

 Technical reviews

 Measurement

 Configuration management

 Reusability management

Process Flow Types:

 Linear - Sequential execution

 Iterative - Repeat activities before moving forward

 Evolutionary - Circular manner, each circuit = more complete version

 Parallel - Execute activities in parallel

1.3 WATERFALL MODEL

Characteristics:

 Also called "Classic Life Cycle"

 Systematic, sequential approach

 Works well when requirements are well-understood

Phases:

Requirements → Design → Implementation → Testing → Maintenance

↓ ↓ ↓ ↓

(Each phase must complete before next begins)

Advantages:

 Simple, easy to understand

 Well-defined stages

 Works for smaller projects

 Easy to manage

Disadvantages:

1. Real projects rarely follow sequential flow

2. Difficult for customer to state all requirements upfront

3. Working program late in timeline

4. Cannot accommodate changes easily

V-Model: Variation showing relationship between development phases (left) and testing phases
(right)

1.4 INCREMENTAL MODEL

Concept: Delivers software in increments, each providing more functionality

Process:

Increment 1: Core Product → Test → Deliver

Increment 2: Add Features → Test → Deliver

Increment 3: More Features → Test → Deliver

(Continue until complete)

Advantages:

 Early delivery of partial working product

 Easier to test and debug

 Customer can provide feedback early

 Lower initial delivery cost

 Easier to manage risk

1.5 EVOLUTIONARY MODELS

A. PROTOTYPING MODEL

When to use: Requirements are fuzzy or unclear

Steps:

1. Quick design - Focus on user-visible aspects

2. Build prototype

3. Customer evaluation

4. Refine requirements

5. Iterate until satisfied

Problems:

 Customer may think prototype = final product

 Developer may make implementation compromises

 May become never-ending refinement

B. SPIRAL MODEL (Barry Boehm)

Key Features:

 Risk-driven

 Combines prototyping + waterfall

 Evolutionary releases

Four Quadrants (each spiral loop):

1. Determine objectives - Identify alternatives

2. Identify and resolve risks - Evaluate, prototype

3. Development and testing - Implement next level

4. Plan next phase - Review, plan next iteration

Advantages:

 Realistic for large systems

 Risk reduction

 Incorporates quality objectives

 Integrates development and maintenance

1.6 AGILE MODEL - SCRUM

Agile Principles (Key ones for exam):

1. Early and continuous delivery of valuable software

2. Welcome changing requirements

3. Deliver working software frequently (2 weeks - 2 months)

4. Business people and developers work together daily

5. Working software = primary measure of progress

6. Continuous attention to technical excellence

SCRUM Framework:

Roles:

1. Product Owner - Defines features, prioritizes backlog

2. Scrum Master - Facilitates, removes impediments

3. Team - Cross-functional, self-organizing (5-9 people)

Process Patterns:

1. Backlog - Prioritized list of requirements/features

2. Sprints - Time-boxed iterations (2-4 weeks)

 o No changes during sprint

o Produces potentially shippable increment

3. Scrum Meetings - Daily 15-minute stand-ups

o What did you do yesterday?

o What will you do today?

o Any impediments?

4. Demos - Show working software to customer

Advantages:

 Rapid delivery

 Adapts to changes

 Customer involvement

 Team empowerment

 Regular feedback

🎯 UNIT 2: REQUIREMENTS ANALYSIS & SPECIFICATION

2.1 REQUIREMENTS ENGINEERING

7 Distinct Tasks:

1. Inception - Establish basic understanding

2. Elicitation - Gather requirements from stakeholders

3. Elaboration - Refine and expand information

4. Negotiation - Resolve conflicts, prioritize

5. Specification - Document requirements formally

6. Validation - Ensure correctness

7. Management - Control changes

2.2 USE CASE APPROACH

Use Case: Describes specific usage scenario from actor's viewpoint

Components:

 Actors - Users or external systems

 Scenario - Sequence of steps

 Preconditions - What must be true before

  Postconditions - State after execution

 Main flow - Normal sequence

 Alternative flows - Variations and exceptions

Use Case Diagram Elements:

┌──────────┐

│ Actor │ (Stick figure)

└──────────┘

│ (interacts)

┌──────────┐

│Use Case │ (Oval)

└──────────┘

Example - ATM System:

 Actors: Customer, Bank System

 Use Cases: Withdraw Money, Check Balance, Deposit Money

 Relationships: <<include>>, <<extend>>

2.3 SRS DOCUMENT (Software Requirements Specification)

Purpose: Complete description of what software should do (not how)

Characteristics of Good SRS:

1. Correct - Every requirement represents actual need

2. Complete - All requirements included

3. Unambiguous - Only one interpretation possible

4. Verifiable - Can be tested/demonstrated

5. Consistent - No conflicts between requirements

6. Ranked - By importance/stability

7. Modifiable - Structure allows changes

8. Traceable - Can track origin and implementation

Typical SRS Structure:

1. Introduction
 - Purpose, Scope, Definitions

2. Overall Description

- Product perspective, Functions, User characteristics

3. Specific Requirements

- Functional requirements

- Non-functional requirements (performance, security, etc.)

4. Validation Criteria

2.4 FLOW-ORIENTED MODELING (Data Flow Diagrams)

DFD Components:

Symbol Name Meaning

Circle/Bubble Process Transforms data

Arrow Data Flow Movement of data

Double Lines Data Store Stored data

Rectangle External Entity Source/sink of data

DFD Levels:

 Level 0 (Context Diagram) - Single process, shows system boundary

 Level 1 - Major processes

 Level 2+ - Further decomposition

Rules for DFD:

1. Process names: Verb + Object (e.g., "Validate Password")

2. Data flow names: Noun (e.g., "Customer Record")

3. Balance between levels (inputs/outputs match)

4. No miracles (output without input) or black holes (input without output)

🎯 UNIT 3: DESIGN MODELING

3.1 TRANSLATING REQUIREMENTS TO DESIGN

Design Model Components:

Requirements Model

↓
┌───────────────────────────┐

│ DESIGN MODEL │

├───────────────────────────┤

│ 1. Data/Class Design │

│ 2. Architectural Design │

│ 3. Interface Design │

│ 4. Component-Level Design │

└───────────────────────────┘

Implementation

3.2 DESIGN PROCESS & CONCEPTS

Key Design Concepts (MUST KNOW):

1. ABSTRACTION

 Procedural Abstraction: Named sequence of instructions (e.g., "open door")

 Data Abstraction: Named collection of data describing object

2. MODULARITY

 Break software into manageable components

 Sweet spot exists - too many or too few modules both bad

 Benefits: Easier maintenance, parallel development, reuse

3. FUNCTIONAL INDEPENDENCE

Measured by:

A. COHESION (High is good)

 How focused is module on single task

 Types (Best to Worst):

1. Functional - Does one thing

2. Sequential - Output of one = input of next

3. Communicational - Operate on same data

4. Procedural - Follow specific sequence

5. Temporal - Execute at same time

6. Logical - Similar functions grouped

 7. Coincidental - No relationship

B. COUPLING (Low is good)

 Degree of interdependence between modules

 Types (Best to Worst):

1. Data - Pass simple data

2. Stamp - Pass data structure

3. Control - Pass control information

4. Common - Share global data

5. Content - One modifies another's data

Goal: High Cohesion + Low Coupling

3.3 STRUCTURE CHARTS

Purpose: Show hierarchical organization of modules

Components:

┌─────────────┐

│ Module │ (Rectangle)

└──────┬──────┘

┌───┴───┐

│ │

┌──▼───┐ ┌─▼────┐

│Child1│ │Child2│

└──────┘ └──────┘

Notations:

 Data couple: Arrow with empty circle (data passed)

 Control couple: Arrow with filled circle (control info passed)

 Module call: Line connecting modules

Reading Structure Charts:

 Top-down hierarchy shows calling relationships

 Left to right typically shows sequence of execution

 Loops and conditions shown with special notation

🎯 UNIT 4: SOFTWARE METRICS & ESTIMATION

4.1 SOFTWARE MEASUREMENT

Why Measure?

 Assess quality

 Estimate cost and effort

 Track progress

 Improve process

Categories of Metrics:

1. Process Metrics - Efficiency of process

2. Project Metrics - Track project status

3. Product Metrics - Quality of deliverables

4.2 METRICS FOR SOFTWARE QUALITY

Key Quality Metrics:

1. Correctness - Defects per KLOC (thousand lines of code)

2. Maintainability - Mean Time To Change (MTTC)

3. Integrity - System's resistance to attacks

4. Usability - Ease of use (measured through surveys)

Defect Removal Efficiency (DRE):

DRE = (Errors before release / Total errors) × 100%

Good software: DRE > 95%

4.3 FUNCTION POINT (FP) BASED ESTIMATION

Why Function Points?

 Size measure independent of language

 Based on user view of system

 Available early in project

Steps to Calculate FP:

Step 1: Count Information Domain Values

Component Count Weight (Simple/Avg/Complex)

External Inputs (EI) # 3/4/6

External Outputs (EO) # 4/5/7

External Inquiries (EQ) # 3/4/6

Internal Files (ILF) # 7/10/15

External Interfaces (EIF) # 5/7/10

Step 2: Calculate Unadjusted FP

UFP = Σ(Count × Weight)

Step 3: Determine Value Adjustment Factor (VAF)

 Assess 14 complexity factors (0-5 scale each)

 Total Degree of Influence (TDI) = Sum of all 14 factors

VAF = 0.65 + (0.01 × TDI)

Range: 0.65 to 1.35

Step 4: Calculate Final FP

FP = UFP × VAF

Using FP for Estimation:

Effort (Person-Months) = FP / Productivity

Duration (Months) = 3.0 × (Effort)^(1/3)

Cost = Effort × Average_Monthly_Cost

Example Problem:

System has:

- 10 External Inputs (Average complexity) = 10 × 4 = 40

- 5 External Outputs (Simple) = 5 × 4 = 20

- 3 Inquiries (Average) = 3 × 4 = 12

- 2 Internal Files (Complex) = 2 × 15 = 30

- 1 External Interface (Simple) = 1 × 5 = 5

UFP = 107

TDI = 35 (assume)

VAF = 0.65 + (0.01 × 35) = 1.00

FP = 107 × 1.00 = 107

If productivity = 5 FP/PM:

Effort = 107/5 = 21.4 person-months

4.4 PROJECT SCHEDULING

Timeline Charts (Gantt Charts):

 Horizontal bars show task duration

 Shows start date, end date, dependencies

 Tracks progress visually

Key Scheduling Concepts:

1. Work Breakdown Structure (WBS)

o Decompose project into tasks

o Estimate each task

2. Critical Path

o Longest path through network

o Determines minimum project duration

o Tasks on critical path cannot be delayed

3. Earned Value Analysis

Schedule Variance (SV) = BCWP - BCWS

Where:

- BCWP = Budgeted Cost of Work Performed

- BCWS = Budgeted Cost of Work Scheduled

SV > 0: Ahead of schedule

SV < 0: Behind schedule

Tracking the Schedule:

 Regular status meetings

 Compare actual vs. planned

 Update timeline charts

 Identify slippages early

  Take corrective action

🎯 UNIT 5: QUALITY CONTROL & RISK MANAGEMENT

5.1 QUALITY CONTROL vs QUALITY ASSURANCE

Quality Control (QC) Quality Assurance (QA)

Product-focused Process-focused

Finds defects Prevents defects

Testing, reviews Process definition, audits

Reactive Proactive

"Does product work?" "Are we building right?"

Quality Control Activities:

 Testing (unit, integration, system)

 Technical reviews

 Inspections

 Walkthroughs

Quality Assurance Activities:

 Process definition

 Process audits

 Standards compliance

 Training

5.2 SOFTWARE PROCESS ASSESSMENT & IMPROVEMENT

Why Assess?

 Identify weaknesses

 Benchmark against standards

 Plan improvements

 Increase maturity

Assessment Models:

1. CMMI (Capability Maturity Model Integration)

5 Maturity Levels:
Level 5: OPTIMIZING - Continuous improvement

Level 4: QUANTITATIVELY MANAGED - Measured process

Level 3: DEFINED - Standard process for organization

Level 2: MANAGED - Project-level process

Level 1: INITIAL - Ad hoc, chaotic

Key Process Areas by Level:

 Level 2: Requirements Management, Project Planning, Configuration Management

 Level 3: Organization Process Definition, Training, Peer Reviews

 Level 4: Quantitative Process Management, Quality Management

 Level 5: Defect Prevention, Process Change Management

2. ISO 9001

 International quality standard

 Applies to any organization

 Focuses on quality management system

5.3 SOFTWARE RISKS

Definition: Potential problem that may or may not occur

Risk Categories:

1. Project Risks - Budget, schedule, resources

2. Technical Risks - Design, implementation, technology

3. Business Risks - Market, strategy, management

Risk Components:

Risk Exposure (RE) = Probability × Impact

5.4 RISK IDENTIFICATION

Common Software Risks:

1. Schedule/Budget - Unrealistic, underestimated

 2. Staffing - Lack of skills, turnover

3. Requirements - Changes, unclear, conflicting

4. Technology - Unproven, complex

5. External Dependencies - Third-party delays

Identification Techniques:

 Checklists

 Brainstorming

 Expert interviews

 Historical data review

5.5 RISK PROJECTION (Risk Assessment)

Steps:

1. Estimate Probability

 Very Low (0-10%)

 Low (10-25%)

 Moderate (25-50%)

 High (50-75%)

 Very High (75-100%)

2. Estimate Impact

Impact Scale: 1 (negligible) to 5 (catastrophic)

Consider: Cost, Schedule, Quality, Scope

3. Calculate Risk Exposure

RE = Probability × Impact

4. Create Risk Table

Risk Probability Impact RE Priority

Key dev leaves 40% High (4) 1.6 1

Tech not mature 60% Med (3) 1.8 2

5.6 RISK MITIGATION

Strategies:
1. Avoidance - Eliminate risk source

 Example: Use proven technology instead of new

2. Minimization - Reduce probability or impact

 Example: Hire experts, do prototyping

3. Acceptance - Acknowledge and monitor

 Example: Have contingency plans

Risk Mitigation Plan Contains:

 Risk to be mitigated

 Mitigation strategy

 Resources needed

 Timeline

 Responsible person

 Monitoring approach

5.7 RISK MONITORING & MANAGEMENT

Monitoring Activities:

 Track identified risks

 Watch for new risks

 Check if mitigation working

 Reassess probability/impact

Risk Indicators (Triggers):

 Warning signs that risk becoming real

 Example: For "Staff turnover" risk

o Trigger: Key person starts job hunting

o Action: Begin knowledge transfer

Contingency Planning:

 "What if" plans

 Activated when risk occurs

 Pre-defined actions

 Resources identified
🎯 UNIT 6: SOFTWARE TESTING

6.1 STRATEGIC APPROACH TO SOFTWARE TESTING

Testing Objectives:

1. Find errors before user does

2. Demonstrate software meets requirements

3. Assess quality

4. Provide confidence

Testing Principles:

1. Testing shows presence of errors, not absence

2. Exhaustive testing impossible

3. Test early in lifecycle

4. Defects cluster (80-20 rule)

5. Pesticide paradox (tests lose effectiveness over time)

Verification vs Validation:

Verification: "Are we building product right?"

- Check against specifications

- Done by developers

Validation: "Are we building right product?"

- Check against user needs

- Done with users

6.2 LEVELS OF TESTING

┌──────────────────────────────────┐

│ SYSTEM TESTING │

├──────────────────────────────────┤

│ INTEGRATION TESTING │

├──────────────────────────────────┤

│ UNIT TESTING │

└──────────────────────────────────┘
6.3 UNIT TESTING

Purpose: Test individual modules/components

What to Test:

1. Module Interface

o Input parameters correct type/range

o Output parameters correct

o Proper data flow in/out

2. Local Data Structures

o Variables initialized

o Data types consistent

o Array bounds correct

3. Independent Paths

o All logical paths executed

o Each statement executed at least once

4. Boundary Conditions

o Test at limits

o Test just inside/outside limits

5. Error Handling

o Error messages correct

o Exception handling works

Unit Test Environment:

DRIVER (calls module)

┌─────────┐

│ MODULE │

│ UNDER │

│ TEST │

└─────────┘

STUB (simulates called modules)

6.4 INTEGRATION TESTING

Purpose: Test module interfaces and interactions

Approaches:

A. TOP-DOWN INTEGRATION

Start with main control module

Add subordinates one at a time

Use STUBS for modules not yet integrated

Order: Depth-first OR Breadth-first

Advantages:

- Early verification of major control

- Test case design easier

B. BOTTOM-UP INTEGRATION

Start with lowest level modules

Combine into clusters

Use DRIVERS to test clusters

Move upward in hierarchy

Advantages:

- No stubs needed

- Easier debugging (lower levels stable)

C. SANDWICH TESTING

 Combines top-down and bottom-up

 Test high levels top-down

 Test low levels bottom-up

 Meet in middle

Regression Testing:

 Re-run previous tests

 Ensure new changes don't break existing functionality

 Automate with tools

  Maintain regression test suite

6.5 SYSTEM TESTING

Types:

1. Recovery Testing

 Force system to fail

 Verify proper recovery

 Test backup/restore

 Check mean-time-to-repair (MTTR)

2. Security Testing

 Attempt penetration

 Test authentication

 Check authorization

 Verify encryption

 Test for vulnerabilities

3. Stress Testing

 Abnormal quantity/frequency/volume

 High interrupt rates

 Maximum memory usage

 Disk thrashing scenarios

 Goal: Find breaking point

4. Performance Testing

 Response time

 Throughput

 Resource utilization

 Processing time

 Often use profiling tools

6.6 VALIDATION TESTING

Purpose: Ensure software meets customer requirements

Types:
Alpha Testing:

 Conducted at developer's site

 Developer present

 Controlled environment

 Representative users

Beta Testing:

 Conducted at customer site

 Developer NOT present

 Real environment

 Actual users

 Problems reported to developer

Acceptance Testing:

 Formal testing by customer

 Against acceptance criteria

 Often contractual

 Go/No-go decision

6.7 WHITE BOX TESTING

Concept: Test internal structure/logic

Techniques:

1. BASIS PATH TESTING

Steps:

a) Draw Flow Graph

Nodes = Statements/Blocks

Edges = Control flow

Predicate nodes = Decision points

b) Calculate Cyclomatic Complexity (V(G))

Method 1: V(G) = Regions in flow graph

Method 2: V(G) = E - N + 2

(E=edges, N=nodes)

Method 3: V(G) = P + 1
 (P=predicate nodes)

c) Determine Independent Paths

 Number of paths = V(G)

 Each path traverses at least one new edge

d) Design Test Cases

 One test case per independent path

 Ensure all statements executed

Example:

IF A > 1 THEN

IF B = 0 THEN

X=X/A

ENDIF

ENDIF

IF A = 2 OR X > 1 THEN

X=X+1

ENDIF

Flow Graph:

Nodes: 1-5

Edges: 7

Predicate nodes: 3

V(G) = 7-5+2 = 4

OR V(G) = 3+1 = 4

Need 4 test cases to cover all paths

2. CONDITION TESTING

 Test logical conditions

 True/False branches

 Compound conditions (AND, OR)

3. LOOP TESTING
Simple Loops:

 Skip loop

 One pass

 Two passes

 m passes (m < n)

 n-1, n, n+1 passes (n=max)

Nested Loops:

 Start with innermost

 Hold outer at minimum

 Test innermost thoroughly

 Move outward

6.8 BLACK BOX TESTING

Concept: Test functionality without knowing internal structure

Techniques:

1. EQUIVALENCE PARTITIONING

Concept: Divide input into classes, test one from each

Rules:

 Range: One valid class, two invalid (below/above)

 Specific value: One valid, two invalid

 Member of set: One valid, one invalid

 Boolean: One valid, one invalid

Example:

Input: Age (18-65)

Classes:

1. Age < 18 (invalid)

2. 18 ≤ Age ≤ 65 (valid)

3. Age > 65 (invalid)

Test cases: Select one value from each

- 15 (from class 1)

- 40 (from class 2)

- 70 (from class 3)

2. BOUNDARY VALUE ANALYSIS (BVA)

Concept: Errors often at boundaries

Rules:

 Test at boundary values

 Test just above boundary

 Test just below boundary

 Apply to input AND output

Example:

Input: 1 ≤ X ≤ 100

Test values:

- 0 (just below min)

- 1 (min)

- 2 (just above min)

- 50 (normal)

- 99 (just below max)

- 100 (max)

- 101 (just above max)

3. CAUSE-EFFECT GRAPHING

 Identify causes (inputs)

 Identify effects (outputs)

 Create graph showing relationships

 Design test cases from graph

6.9 DEBUGGING

Definition: Process of finding and fixing errors

Approaches:

1. Brute Force
  Memory dumps

 Print statements everywhere

 Least efficient

 Use when all else fails

2. Backtracking

 Start at symptom

 Trace back through code

 Works for small programs

 Gets complex for large programs

3. Cause Elimination

 List possible causes

 Test hypotheses

 Eliminate causes

 Use binary partitioning

Debugging Steps:

1. Reproduce the error

2. Isolate the source

3. Identify the cause

4. Determine the fix

5. Apply the fix

6. Test the fix

7. Look for side effects

📊 IMPORTANT FORMULAS (Quick Reference)

1. FUNCTION POINTS:

FP = UFP × VAF

VAF = 0.65 + (0.01 × TDI)

2. EFFORT ESTIMATION:

Effort = FP / Productivity

Duration = 3.0 × (Effort)^(1/3)

3. CYCLOMATIC COMPLEXITY:

V(G) = E - N + 2

V(G) = P + 1

V(G) = Regions

4. RISK EXPOSURE:

RE = Probability × Impact

5. DEFECT REMOVAL EFFICIENCY:

DRE = (Errors found before release / Total errors) × 100%

6. SCHEDULE VARIANCE:

SV = BCWP - BCWS

🎓 EXAM TIPS

For 2-Mark Questions:

 Be concise and precise

 Define terms clearly

 Use diagrams where possible

 Examples help

For 10-Mark Questions:

 Structure your answer

 Use headings/subheadings

 Include diagrams

 Give examples

 Cover all aspects

Common Question Patterns:

1. Define X and explain types/phases

2. Compare X vs Y

3. Explain process with diagram

 4. Calculate (FP, V(G), etc.)

5. Draw and explain diagram

Must-Know Diagrams:

 Process flow diagrams

 DFD symbols and levels

 Structure charts

 Use case diagrams

 Flow graphs for testing

 Waterfall/Spiral/Agile models

✅ QUICK REVISION CHECKLIST

Unit 1:

 4 layers of SE

 5 framework activities

 Waterfall model (phases, pros/cons)

 Incremental model

 Prototyping model

 Spiral model (4 quadrants)

 Scrum (roles, artifacts, ceremonies)

Unit 2:

 7 RE tasks

 Use case components

 SRS characteristics

 DFD symbols and rules

 DFD levels

Unit 3:

 Design concepts (abstraction, modularity, etc.)

 Cohesion types and levels

 Coupling types and levels

 Structure chart notation

Unit 4:
  Function Point calculation (all steps)

 Effort/Duration formulas

 Timeline charts

 Critical path concept

Unit 5:

 QC vs QA

 CMMI levels

 Risk categories

 Risk projection steps

 Mitigation strategies

Unit 6:

 Testing levels

 Unit testing checklist

 Top-down vs Bottom-up integration

 System testing types

 Alpha vs Beta testing

 Cyclomatic complexity calculation

 BVA and Equivalence Partitioning

 Debugging approaches