Software Engineering Notes
1. What is Software?
Definition:
Software is a collection of programs, data, and instructions that tell a computer how to
perform specific tasks.
It is the intangible component of a computer system — unlike hardware, which you can touch
and see.
Components of Software:
1. Programs: Executable code that performs a function (e.g., MS Word, web browser).
2. Data: Files and databases used by the program.
3. Documentation: Manuals, help files, and comments for users and developers.
Real-World Examples:
● Banking System: Core banking software manages accounts, transactions, and customer
data.
● Healthcare: Hospital management systems track patients, appointments, and billing.
● E-commerce: Platforms like Amazon use recommendation algorithms and inventory
management systems.
2. What is Software Engineering?
Definition:
Software Engineering is the systematic, disciplined, and quantifiable approach to the
development, operation, and maintenance of software.
It applies engineering principles to software creation — just like civil engineers use structured
methods to build bridges
Key Objectives:
Objective Explanation
Quality The software must meet requirements and perform reliably.
Maintainability Easy to update, fix, and improve.
Scalability Should handle growing workloads.
Reusability Code components can be reused in other projects.
Efficiency Optimal use of time, cost, and computing resources.
Key Differences between Software and Software Engineering:
Aspect Software Software Engineering
Meaning A product (set of A process (how software is built).
programs).
Focus Functionality and Development process, quality, and maintenance.
usability.
Example Microsoft Word. The method used by Microsoft to develop and update
Word.
Analogy Like a completed Like the architecture and construction process.
building.
Software Categories
Software can be divided into different categories based on how it operates, where it runs, and
what purpose it serves.
1. Static Type Software
Definition:
Static-type software refers to non-interactive programs or data systems that perform a fixed
set of operations.
It does not change dynamically during execution — its logic, flow, and functionality are
predefined and usually don’t interact with external systems in real-time.
Characteristics:
● Fixed or predefined output for given input.
● No real-time interaction with users or environment.
● Data and structure remain unchanged after deployment.
● Often used for analysis, record-keeping, or configuration.
Examples:
Example Description
Payroll system Calculates salaries based on stored employee data — same logic each
month.
Reports generator Produces fixed reports from existing data.
Real-World Scenario:
● A school report card generator that reads student marks from a file and prints grades
based on a fixed rule.
→ No real-time user interaction or external feedback, so it’s static-type software.
2. Practical Type Software
Definition:
Practical-type software (also called application software) is designed to perform practical,
real-world tasks for users. It allows interaction, input/output, and often solves business or
personal problems.
It is called “practical” because it’s directly used in daily operations, office automation, and
decision-making.
Characteristics:
● Focused on real-world problem-solving.
● User-oriented and interactive.
● Can be standalone or web-based.
● Used for data processing, communication, and productivity.
Examples:
Example Function
Microsoft Word / Excel Create and manage documents and spreadsheets.
Hospital Management System Manages patient records, billing, and appointments.
E-commerce Applications (Amazon) Enables buying, selling, and payments online.
Banking Software Allows account management and transactions.
Education Systems (LMS) Manages online classes and grading.
Real-World Scenario:
At SZABIST University, the Student Portal is a practical-type software:
● Students log in to check grades, attendance, and schedules.
● Teachers upload assignments and marks.
● Admins generate reports.
It directly supports real operations and decision-making — making it a practical software.
3. Embedded Type Software
Definition:
Embedded software is built to control hardware devices or specific machines. It resides inside
firmware or hardware chips and performs real-time, dedicated tasks.
Characteristics:
● Hardware-dependent and task-specific.
● Usually runs on microcontrollers or processors.
● Performs real-time operations (e.g., responding instantly to sensor input).
● Requires high reliability — failures can be dangerous.
● Usually has limited user interface (or none).
Examples:
Example Description
Car Airbag System Detects impact and triggers airbags in milliseconds.
Washing Machine Software Controls wash cycles, timers, and sensors.
Smart TVs / IoT Devices Embedded software controls display and connectivity.
ATMs Software embedded in machines to manage secure
transactions.
Medical Devices Monitors heart rhythm and delivers electric pulses.
(Pacemaker)
Real-World Scenario:
Consider Tesla’s Autopilot system:
● Sensors collect real-time data (speed, distance, lane).
● Embedded software inside the car’s control unit processes data and controls steering,
brakes, etc.
→ This is embedded software because it’s directly controlling hardware with real-time
response.
Comparison Table
Feature Static Type Practical Type Embedded Type
Purpose Fixed, predefined Solve real-world Control specific hardware
tasks user problems
Interaction Little to none High (user With hardware
interaction) sensors/devices
Flexibility Rigid, not Flexible and Limited, hardware-specific
changeable upgradable
Environment Desktop/server Desktop, mobile, Inside
web hardware/microcontroller
Example Static website, Word, banking ATM, car control unit, IoT
payroll system app, LMS device
Programming SQL, HTML, Java, Python, C#, C, C++, Embedded C
Languages simple scripts PHP
Real-World Reporting, storage Business, Electronics, automotive,
Domain education, robotics
healthcare
Five Ps of Software Engineering
P Meaning Example
People The team and users involved Developers, testers, users
Problem The issue software aims to solve Manual attendance taking
Process The method or approach to build it Agile, Waterfall
Project Resources, time, and management Budget, schedule, tools
Product The final working software Attendance system, banking app
Example Integration (Scenario-Based Answer):
Scenario: A university wants a system to manage student attendance and grades online.
● People: Developers, project manager, faculty, and students.
● Problem: Manual attendance and grading cause delays and errors.
● Process: Agile development — iterative design and feedback from teachers.
● Project: 6-month timeline, 4 developers, using Django and MySQL.
● Product: A web-based portal for automated attendance and grade tracking.
Software Development Life Cycle (SDLC)
The Software Development Life Cycle (SDLC) is a step-by-step process used by the
software industry to design, develop, and test high-quality software.
Its main goal is to produce software that meets customer needs, is delivered on time,
and stays within budget
Phases of SDLC (According to Lecture)
1. Requirement Gathering and Analysis
Purpose:
To understand what the customer wants from the software.
Activities:
● Meetings with users and stakeholders.
● Identify who will use the system, what data is needed, and how the system will work.
● Document requirements in:
○ User Requirements Document (URD) – written from the user’s point of view.
○ Software Requirements Specification (SRS) – written by analysts describing
features, functions, and constraints.
Example:
For a university attendance system, the team defines:
● Users: Teachers, Students, Admins.
● Inputs: Roll numbers, attendance data.
● Outputs: Attendance reports, summaries.
Role:
● Business Analysts (BA) gather and document requirements and review them with the
team.
2. Design
Purpose:
To create the architecture and blueprint of the software before coding starts.
Activities:
● Define hardware/software requirements.
● Prepare system architecture, database design, and module specifications.
Two levels of design:
● High-Level Design (HLD):
○ Describes modules, their functions, and relationships.
○ Includes architecture diagrams and database structure.
● Low-Level Design (LLD):
○ Details logic for each module (pseudo code).
○ Defines database elements, APIs, input/output, and error handling.
Example:
For an attendance system:
● HLD: Modules – Login, Student Management, Attendance Entry, Reports.
● LLD: Logic for how the “Attendance Entry” module updates records.
Comparison Table: HLD vs LLD
Feature High-Level Design (HLD) Low-Level Design (LLD)
Meaning Big-picture design of the Detailed design of individual
system modules
Focus Architecture, modules, data Logic, database fields,
flow functions
Level of Detail Abstract / Conceptual Detailed / Technical
Prepared By System Architect Developer or Technical
Designer
Purpose Defines what to build Defines how to build it
Output Architecture diagrams, module Pseudo code, data structures,
list APIs
Dependencies Shows relationships between Shows internal logic within
modules modules
Database Identifies main tables and keys Specifies all fields, data types,
sizes
Tools UML diagrams, flowcharts Pseudo code, class diagrams
Example (Attendance Login, Attendance, Reports Algorithm for attendance
System) modules marking
3. Implementation / Coding
Purpose:
To write the actual code according to the design.
Activities:
● Divide work into modules or units.
● Developers write and integrate the code.
● Use programming languages, frameworks, and version control tools.
Example:
Developers code the attendance entry module in Python or Java and connect it with the
database.
4. Testing
Purpose:
To verify that the software works correctly and meets all requirements.
Activities:
Different testing types are performed:
Type Description
Unit Testing Each module is tested individually by developers.
Integration Check if modules work together (e.g., login → attendance →
Testing report).
System Test the complete system as one application.
Testing
Acceptance Client tests the product in a real environment before final
Testing approval.
Example:
Test if teachers can mark attendance and generate reports without errors.
5. Deployment
Purpose:
To deliver the product to the customer or deploy it in the real environment.
Activities:
● Conduct beta testing (trial run by users).
● Fix bugs or make changes suggested by clients.
● Then final deployment happens for full use.
Example:
Deploying the attendance system on the university’s server for all departments.
6. Maintenance
Purpose:
To keep the software running smoothly after it’s deployed.
Activities:
● Bug fixing: Resolve errors found during use.
● Upgrades: Update features or technologies.
● Enhancements: Add new functionality based on user feedback.
Example:
Adding a face recognition attendance feature after launch or updating the database when new
semesters start.
Summary Table (from the Lecture)
Phase Description Example
Requirement Gathering Understand what Define attendance features
& Analysis users want
Design Create system Plan modules and
blueprint database
Implementation / Coding Write the actual Develop attendance entry
code module
Testing Verify that Check if reports are
software works generated correctly
Deployment Deliver software Launch on SZABIST
to users server
Maintenance Fix issues and Add new features after
improve launch
Software Process Models
A Software Process Model is a simplified representation of a software process, showing
how activities such as analysis, design, coding, and testing are organized and related.
1. Linear Sequential Model (LSM)
(Also known as the Waterfall Model or Classical Life Cycle)
Definition:
This is one of the earliest and most straightforward models.
It provides a systematic and step-by-step approach where each phase must be completed
before moving to the next.
Works best when requirements are well understood and stable.
Diagram:
Phases:
1. System and Information Engineering:
○ Define all system-level and business requirements.
2. Software Requirement Analysis:
○ Gather and document software-specific needs from clients.
3. Designing:
○ Convert requirements into a design (architecture, database, procedures).
4. Coding:
○ Convert the approved design into actual program code.
5. Testing:
○ Verify if software meets requirements; detect and fix logical/syntax errors.
6. Maintenance & Support:
○ Handle post-delivery updates, bug fixes, and enhancements.
Advantages:
● Simple and easy to use and understand.
● Each phase has clear deliverables and review points.
● Works well for small projects with fixed requirements.
Disadvantages:
● Hard to make changes once a phase is completed.
● High risk and uncertainty.
● Not suitable for complex, long-term, or object-oriented projects.
● The customer sees the product only after full testing.
Example:
Developing a Payroll Management System where requirements (like tax calculations, payslip
generation) are fixed and won’t change.
2. The Prototype Model (PRM)
Definition:
This model involves building a prototype (sample system) that demonstrates basic features of
the final software.
It allows client-developer interaction and helps clarify unclear requirements through feedback
and iterations.
Diagram:
Versions (as per lecture):
1. Version I – Prototype as Requirement Tool:
○ Prototype helps gather user needs; discarded after requirements are finalized.
2. Version II – Prototype as Design Tool:
○ Prototype evolves into final design; speeds up specification and avoids
ambiguities.
Comparison Table
Feature Version I Version II
Purpose To understand and finalize To serve as a design and evolve into
requirements final system
Prototype Temporary – discarded after Permanent – refined into final system
Usage requirements
Focus Requirement gathering Design and implementation
Output Finalized specifications document Working, refined product
Advantages Helps clarify unclear needs early Saves time, avoids redundant
documentation
Disadvantages Extra effort to build and discard Risk of skipping formal
prototype documentation
Example Mock-up of a library app (for Building and refining a real student
requirement clarity) portal step-by-step
Advantages:
● Continuous feedback from the client.
● Helps when the client’s requirements are unclear.
● Reduces misunderstandings between developers and users.
● Prototype acts as a visual reference for the final product.
Disadvantages:
● May reduce final software quality due to pressure for quick results.
● Clients may expect immediate delivery.
● Developers may take shortcuts to meet deadlines.
● Hard to convince clients to discard the prototype.
Example:
Creating a Mobile Banking App Prototype to show customers features like login, fund transfer,
and notifications before finalizing design.
3. Rapid Application Development (RAD) Model
Definition:
RAD is a high-speed version of the Linear Sequential Model that focuses on fast
development and short delivery time using reusable components and parallel development.
In this approach individual components developed by different people are assembled to develop
a large software system.
Diagram:
Phases Explained:
1. Business Modeling:
Understand how information flows through the business (inputs, outputs, sources).
2. Data Modeling:
Identify data objects and entities based on the business model.
3. Process Modeling:
Define operations on data (add, delete, modify, retrieve).
4. Application Design:
Use 4GL (fourth-generation languages) or tools to rapidly build the application.
5. Testing:
Test all new components and integrations.
Advantages:
● Fast delivery and early results.
● Encourages component reusability.
● Reduces development time significantly.
Disadvantages:
● Requires high commitment from both client and developer.
● Not suitable for large or high-risk projects.
● Works best for modular and reusable systems.
● Needs experienced developers and quick user feedback.
Example:
Developing a Student Information Portal within a short academic term using modular, parallel
development teams.
4. Incremental Model (INM)
Definition:
This model combines Linear Sequential and Prototyping approaches. Software is developed
and delivered in small, usable parts (increments). Each increment adds new features or
functionality based on client feedback.
Diagram:
Working:
1. The first increment (core product) covers the primary functions.
2. Client evaluates and gives feedback.
3. Developers plan the next increment adding new features.
4. Process repeats until the full product is complete.
Advantages:
● Delivers working software early.
● Needs fewer human resources initially.
● Allows client feedback at each stage.
● Ideal when full manpower is not available or deadlines are tight.
Disadvantages:
● Software quality may be compromised in the rush for early delivery.
● Managing integration between increments can be complex.
Example:
Developing a Learning Management System (LMS):
● Increment 1: Student login and course registration.
● Increment 2: Assignment submission.
● Increment 3: Grading and reporting.
Summary Table (Lecture-Based)
Model Description Advantages Disadvantages Best Used For
LSM Sequential Simple, easy Rigid, late Small, fixed
(Waterfall) step-by-step to manage feedback projects
process
PRM Build and refine Clarifies Time pressure, UI-heavy or
(Prototype) prototype with unclear unrealistic unclear projects
user feedback requirements expectations
RAD Fast development Quick Needs Time-sensitive
using components delivery, commitment, not systems
and parallel teams reusable for large projects
modules
INM Software Early Integration Long-term or
(Incremental) delivered in small delivery, issues resource-limited
parts flexible projects
Functional and Non-Functional requirements
Aspect Functional Requirements Non-Functional
Requirements
Focus What the system should do How the system should
perform
Type Features, functions, services Performance, quality,
constraints
Measureme Based on correctness of Based on quality attributes
nt outputs (speed, reliability)
Example “User can log in and view “Dashboard should load
dashboard.” within 2 seconds.”
Documenta Use Cases, User Stories System Attributes,
tion Constraints
Failure System won’t work as System will work but with
Effect intended poor user experience
Scenario-Based Example
Scenario: Online Shopping System (e.g., Daraz or Amazon)
Requirement Example
Type
Functional The system should allow customers to add items to a
Requirement shopping cart, place orders, and make payments through
multiple payment options.
Non-Functional The system should process payments within 5 seconds,
Requirement handle at least 10,000 concurrent users, and ensure data
encryption during transactions.
Requirements Modeling Techniques
During the Requirement Analysis phase of the Software Development Life Cycle (SDLC),
software engineers use modeling techniques to represent how the system should behave.
Two commonly used UML (Unified Modeling Language) techniques are:
1. Use Case Diagram
2. Activity Diagram
Elements of a Use Case Diagram
Element Description Example
Actor A user or external system Student, Admin,
interacting with the system Teacher
Use Case A specific functionality or action Login, View Report,
the actor performs Submit Form
System Defines the scope of the system The attendance system
Boundary
Relationships Shows how use cases or actors Include, Extend,
relate Association
Relationships:
● Association (→): Link between actor and use case (e.g., student → mark attendance).
● Include (<<include>>): A use case that always happens as part of another (e.g., “Login”
included in “Submit Assignment”).
● Extend (<<extend>>): An optional or conditional use case (e.g., “Forgot Password”
extends “Login”).
Advantages:
● Easy for clients to understand.
● Captures all functional requirements.
● Useful in early communication between clients and developers.
2. Activity Diagram
Elements of an Activity Diagram
Element Symbol Description
Start Node ● (filled Beginning of process
circle)
Activity / Rounded Task or operation
Action rectangle
Decision Diamond Represents a condition (Yes/No)
Transition / → Flow between actions
Arrow
End Node ⦿ (bull’s End of process
eye)
Swimlanes Columns Separate actions by roles (e.g., student,
admin)
Advantages:
● Helps visualize control flow and logic clearly.
● Useful for detecting bottlenecks or missing steps.
● Easy to convert into algorithms or process documentation.
Comparison: Use Case vs. Activity Diagram
Feature Use Case Diagram Activity Diagram
Purpose Shows what the system does Shows how the system
performs activities
Focus Interaction between users and Flow of operations and
system decisions
Used For Capturing functional Modeling process flow
requirements
Main Actors, Use Cases, Actions, Decisions, Flows
Elements Relationships
Level High-level overview Detailed process level
Example “Teacher marks attendance” “Login → Select class →
Mark → Save”