Module 1 – Introduction to Software Engineering and

Process Models

1.1 Definition

Software Engineering is the systematic approach to the development, operation,

maintenance, and retirement of software.
It applies engineering principles to software to ensure quality, reliability, and efficiency.

1.2 Characteristics of Good Software

• Functionality – meets user needs

• Reliability – performs consistently without failure
• Efficiency – optimized use of resources (CPU, memory)
• Usability – easy to learn and operate
• Maintainability – easy to fix, update, or improve
• Portability – can work on different platforms

1.3 Software Process

A software process is a structured set of activities required to develop a software system:

1. Specification – defining what the system should do

2. Design & Implementation – building the software
3. Validation – ensuring it meets requirements
4. Evolution – modifying to meet new needs

1.4 Software Process Models

A. Waterfall Model

• Linear sequence: Requirement → Design → Implementation → Testing →

Deployment → Maintenance
• Advantages: Easy to understand, suitable for small projects
• Disadvantages: Rigid, difficult to go back to previous stages

Diagram – Waterfall Model:

Requirements → Design → Implementation → Testing → Deployment → Maintenance

B. Incremental Model

• Builds software in small parts (increments)

• Each increment adds new functionality
• Advantages: Early delivery of partial system
• Disadvantages: Requires good planning and design

C. Spiral Model

• Combines iterative development and risk management

• Each loop in the spiral represents a phase (Planning → Risk Analysis → Engineering
→ Evaluation)

Diagram – Spiral Model (Text Representation):

[Planning] → [Risk Analysis] → [Engineering] → [Evaluation]

↖_______________________________________________↙

D. Agile Model

• Focuses on flexibility and customer collaboration

• Short iterations called sprints
• Examples: Scrum, Extreme Programming (XP)
• Advantages: Adapts to changes quickly, fast delivery
• Disadvantages: Less documentation, can be chaotic

1.5 Example – Choosing a Process Model

• Scenario: A banking application with strict security requirements and fixed scope →
Waterfall Model
• Scenario: A startup building a prototype with evolving requirements → Agile Model

Module 2 – Software Requirements Analysis and

Modeling

2.1 Definition

Requirement Analysis is the process of identifying, documenting, and validating the needs
and expectations of the customer for a software system.
2.2 Types of Requirements

1. Functional Requirements (FRs)

o Define what the system should do
o Example: “The system shall allow users to log in using email and password.”
2. Non-Functional Requirements (NFRs)
o Define how the system performs
o Example: “The system shall respond to a login request within 2 seconds.”

2.3 Requirement Engineering Process

1. Elicitation – Gathering requirements from stakeholders

2. Analysis – Prioritizing, resolving conflicts
3. Specification – Writing in a formal document (SRS)
4. Validation – Checking for completeness, consistency
5. Management – Handling changes over time

2.4 Software Requirement Specification (SRS)

An SRS document contains:

• Introduction
• Overall description
• Functional and non-functional requirements
• External interface requirements
• Other requirements (security, reliability, etc.)

2.5 Modeling Requirements

Modeling helps visualize and analyze requirements.

A. Data Flow Diagram (DFD)

• Shows flow of data in the system.

• Levels:
o Level 0 (Context Diagram) – High-level view
o Level 1, 2... – More detail

DFD Example – Online Banking System:

Customer → [Login Process] → Bank Database

B. Use Case Diagram

• Part of UML (Unified Modeling Language)

• Shows actors (users or other systems) and interactions.

Example – ATM System:

[Customer] → (Withdraw Cash)

[Customer] → (Check Balance)

C. Entity Relationship Diagram (ERD)

• Represents data and relationships in a database.

Example – Student Database:

Student (Student_ID, Name, Age)

Course (Course_ID, Name)
Relationship: Student ENROLLED_IN Course

2.6 Example – Choosing Modeling Techniques

• If you need to show data flow → DFD

• If you need to show user interactions → Use Case Diagram
• If you need to design a database → ERD

Module 3 – Software Estimation Metrics

3.1 Definition

Software estimation is the process of predicting the effort, time, and cost needed to develop
a software product.
It helps in planning, scheduling, budgeting, and resource allocation.

3.2 Key Estimation Metrics

Metric Description Formula

LOC (Lines of Size of software in terms of lines of
—
Code) source code.
FP (Function Measures software size based on
FP = UFP × VAF
Points) functionality delivered.
 Metric Description Formula
Effort Total work needed (in person-months). Effort = a × (Size)^b
Productivity Output per unit of time. Productivity = Size / Effort
Cost = Effort × Cost per
Cost Total expense for development.
person-month

3.3 Estimation Models

A. Lines of Code (LOC) Based

• Steps: Estimate LOC → Convert to effort → Convert to cost

• Advantage: Easy to measure once code is complete
• Limitation: Hard to estimate in early stages

B. Function Point (FP) Based

• Considers inputs, outputs, files, and interfaces

• More independent of programming language

C. COCOMO Model (Constructive Cost Model)

• Developed by Barry Boehm

• Three types:
1. Basic COCOMO – Uses size (KLOC) for effort
2. Intermediate COCOMO – Adds cost drivers
3. Detailed COCOMO – More factors for accuracy

3.4 Diagram – COCOMO Process (Text Form)

Size (KLOC)
↓
COCOMO Model
↓
Effort Estimation
↓
Schedule Estimation

3.5 Example 1 – LOC-based Estimation

• Estimated LOC = 10,000

• Productivity = 500 LOC/month
• Effort = 10,000 / 500 = 20 person-months

3.6 Example 2 – Function Point Calculation

 1. Count Unadjusted Function Points (UFP):
o External Inputs (EI) = 10 × 3 = 30
o External Outputs (EO) = 5 × 4 = 20
o External Inquiries (EQ) = 4 × 3 = 12
o Internal Logical Files (ILF) = 7 × 7 = 49
o External Interface Files (EIF) = 3 × 5 = 15
UFP = 30 + 20 + 12 + 49 + 15 = 126
2. Value Adjustment Factor (VAF) = 1.05
3. FP = 126 × 1.05 = 132.3 ≈ 132 Function Points

Module 4 – Software Design

4.1 Definition

Software design is the process of defining the architecture, components, interfaces, and
data for a system to satisfy specified requirements.

4.2 Objectives of Software Design

• Ensure the software meets requirements

• Make the system easy to understand, modify, and maintain
• Optimize performance, security, and scalability
• Facilitate reusability of components

4.3 Levels of Design

1. High-Level Design (Architectural Design)

o Focuses on system architecture and major components.
o Output: Architecture diagrams
2. Low-Level Design (Detailed Design)
o Focuses on module logic, algorithms, and data structures.
o Output: Flowcharts, pseudo-code

4.4 Principles of Good Design

• Modularity – Divide system into independent modules

• Abstraction – Hide unnecessary details
• Coupling & Cohesion
o Low coupling (less dependency between modules)
 o High cohesion (modules focused on a single task)
• Reusability – Design components that can be reused
• Scalability – Design to handle growth

4.5 Design Approaches

A. Top-Down Design

• Start from the highest level and break into smaller parts.
• Example: Designing a school management system from “Main Functions” → “Sub
Functions”.

B. Bottom-Up Design

• Start from small components and integrate them into a system.

4.6 Software Architecture Styles

1. Layered Architecture – e.g., Presentation → Business Logic → Data

2. Client-Server Architecture – Client requests, server responds
3. MVC (Model-View-Controller) – Separates data, interface, and logic
4. Microservices – Independent services communicating via APIs

4.7 Diagram Examples

1. Layered Architecture

[Presentation Layer]
[Business Logic Layer]
[Data Layer]

2. MVC Pattern

User → View → Controller → Model → Database

4.8 Example – Flowchart for Login Process

Start
↓
Enter Username & Password
↓
Check Credentials
├── Valid → Go to Dashboard
└── Invalid → Show Error → Retry
 ↓
End

Module 5 – Software Testing

5.1 Definition

Software testing is the process of evaluating a software product to detect differences

between expected and actual results and to ensure the product is error-free, reliable, and
meets requirements.

5.2 Objectives of Testing

• Find and fix defects

• Verify that software meets specified requirements
• Ensure quality, performance, and security
• Build confidence in the product

5.3 Testing Process (V-Model)

The V-Model represents the relationship between development stages and testing stages.

Diagram – V-Model (Text Representation):

Requirements → Acceptance Testing

System Design → System Testing
Architectural Design → Integration Testing
Module Design → Unit Testing
Coding

5.4 Types of Testing

A. Manual Testing

• Executed by humans without automation tools.

• Suitable for exploratory and ad-hoc testing.

B. Automated Testing

• Uses scripts and tools (e.g., Selenium, JUnit).

• Suitable for regression and performance testing.
5.5 Levels of Testing

1. Unit Testing – Testing individual components.

2. Integration Testing – Testing interactions between modules.
3. System Testing – Testing the complete system as a whole.
4. Acceptance Testing – Ensuring system meets business requirements.

5.6 Testing Techniques

Black-Box Testing

• Focus on input-output behavior

• Example techniques: Equivalence Partitioning, Boundary Value Analysis

White-Box Testing

• Focus on internal logic and code paths

• Example techniques: Statement coverage, Path coverage

5.7 Example – Boundary Value Analysis

If a field accepts ages 18 to 60:

• Test cases: 17 (below boundary), 18 (lower boundary), 60 (upper boundary), 61

(above boundary)

5.8 Example – Equivalence Partitioning

If a system accepts marks 0 to 100:

• Valid class: 0–100 (e.g., test with 50)

• Invalid class: <0 and >100 (e.g., test with -5 and 120)

Module 6 – Software Configuration Management, Quality

Assurance, and Maintenance
6.1 Software Configuration Management (SCM)

Definition:
SCM is the process of systematically controlling changes to software to maintain its
integrity and traceability throughout the lifecycle.

SCM Activities

1. Configuration Identification – Identify configuration items (CIs) such as code, docs,

and test data.
2. Configuration Control – Approve and manage changes via change control boards.
3. Configuration Status Accounting – Record and report the status of configuration
items.
4. Configuration Auditing – Ensure changes are implemented correctly.

Diagram – SCM Process:

Identification → Control → Status Accounting → Auditing

SCM Tools Examples

• Version Control: Git, SVN

• Build Automation: Jenkins, Maven
• Issue Tracking: Jira, Trello

6.2 Software Quality Assurance (SQA)

Definition:
SQA is the process of ensuring software quality through planned activities and standards.

SQA Activities

• Define quality standards (ISO, CMMI)

• Perform reviews (code review, design review)
• Execute testing (functional, non-functional)
• Maintain quality metrics (defect density, reliability)

Diagram – SQA in Development:

Standards → Reviews → Testing → Metrics → Continuous Improvement

6.3 Software Maintenance

Definition:
The process of modifying software after delivery to correct faults, improve performance, or
adapt to changes.

Types of Maintenance

1. Corrective – Fix defects.

2. Adaptive – Adapt software to new environments.
3. Perfective – Improve performance or maintainability.
4. Preventive – Reduce future problems.

Maintenance Process:

Change Request → Impact Analysis → Implementation → Testing → Release

6.4 Example – Maintenance Scenario

• Corrective: Fixing a bug that causes login failure.

• Adaptive: Updating software to work with a new database version.
• Perfective: Improving page load speed by optimizing queries.
• Preventive: Adding error handling to prevent crashes.