1. What is Software Engineering?
Definition:
Software engineering is the systematic application of engineering principles to the design,
development, testing, and maintenance of software.
Logic/purpose:
To build reliable, efficient, maintainable, and cost-effective software within time and budget.
Example:
Building an e-commerce website like Daraz requires planning (requirements), design
(architecture, UI), coding, testing, and maintenance.
2. SDLC (Software Development Life Cycle)
Definition:
The process followed to develop software systematically.
Phases:
1. Requirement analysis – Understand what the user needs
2. Design – Plan architecture & components
3. Implementation (coding) – Write code
4. Testing – Find and fix defects
5. Deployment – Release to users
6. Maintenance – Fix issues & update
Logic:
To reduce risk and control complexity by organizing work into phases.
Example:
A mobile banking app follows SDLC to make sure it is secure and user-friendly.
3. Software Process Models
Definition:
Frameworks that describe how to organize the SDLC phases.
Types & logic:
Model Logic When to use
Waterfall Linear, finish one phase before the Stable requirements
next
Incremental Build software in parts Early delivery, changing
needs
Spiral Focus on risk analysis High-risk projects
Agile (e.g., Scrum) Short iterations, user feedback Dynamic, changing projects
Example:
WhatsApp updates features incrementally, adding status and voice features over time.
4. Software Requirements
Definition:
Statements of what the software must do.
Types:
● Functional: What the system should do (e.g., "System shall send an email")
● Non-functional: How well it should do (e.g., "Response time < 2 sec")
Logic:
Clear requirements prevent misunderstandings and rework.
Example:
In an online ticket system: functional – book ticket; non-functional – 99.9% uptime.
5. Requirement Engineering
Definition:
The process of gathering, analyzing, documenting, and managing requirements.
Steps:
1. Elicitation – Find out what stakeholders want
2. Analysis – Remove conflicts
3. Specification – Write requirements (SRS)
4. Validation – Confirm with users
5. Management – Track changes
Logic:
Ensures software meets user needs.
6. Software Design
Definition:
Converting requirements into a blueprint for coding.
Levels:
● Architectural design: Overall structure (components, relationships)
● Detailed design: Algorithms, data structures
● Interface design: Screens, reports, APIs
Logic:
Reduces complexity, improves maintainability.
Example:
Layered architecture in Gmail (UI layer, business layer, database).
7. Design Principles
● Modularity: Break into smaller parts (modules)
● Abstraction: Hide details, show only needed features
● Encapsulation: Keep data inside modules/classes
● Separation of concerns: Different parts handle different tasks
Logic:
Easier to build, test, and maintain.
8. UML (Unified Modeling Language)
Definition:
Standard diagrams to visualize software design.
Important UML diagrams:
● Class diagram: Shows classes, attributes, methods, relationships
● Sequence diagram: Shows object interactions over time
● Use case diagram: Shows system functions from user's view
● State diagram: Shows states and transitions
Example:
For an ATM: use case – withdraw cash; sequence – user → ATM → bank server.
9. Software Implementation (Coding)
Definition:
Translating design into source code.
Logic:
Follow coding standards for readability and maintainability.
Example:
Using version control (e.g., Git) to manage code.
10. Software Testing
Definition:
Process of verifying the software meets requirements and is defect-free.
Types:
Type Purpose
Unit testing Test individual functions/modules
Integration testing Test modules together
System testing Test complete system
Acceptance User tests before release
testing
Static vs Dynamic:
● Static: Code reviews
● Dynamic: Running code
Example:
Testing login with wrong password, invalid email.
11. Software Maintenance
Definition:
Updating software after deployment.
Types:
● Corrective: Fix bugs
● Adaptive: Adjust to new environment (e.g., new OS)
● Perfective: Improve performance/features
● Preventive: Prepare for future changes
Logic:
Software needs updates to stay useful.
12. Software Project Management
Definition:
Planning, organizing, and controlling software projects.
Tasks:
● Estimation (time, cost)
● Scheduling
● Resource allocation
● Risk management
● Tracking progress
Tools: Gantt charts, PERT charts
Example:
Using MS Project to plan a website launch.
13. Risk Management
Definition:
Identify, analyze, and plan to handle risks.
Steps:
1. Identify risks (e.g., developer leaves)
2. Assess impact & probability
3. Plan mitigation (e.g., backup resources)
Logic:
Minimizes surprises.
14. Software Quality Assurance (SQA)
Definition:
Activities to ensure the software process and products meet standards.
Activities: Audits, reviews, testing, standards enforcement.
Example:
Peer review of code to catch bugs early.
15. CASE Tools (Computer-Aided Software Engineering)
Definition:
Software that supports SE activities.
Types:
● Upper CASE: Planning, analysis, design
● Lower CASE: Coding, testing
● Integrated CASE: Supports full SDLC
Examples: Rational Rose, Visual Paradigm
Logic:
Increase productivity and consistency.
16. Software Metrics
Definition:
Measurement of software attributes.
Types:
● Size metrics (e.g., Lines of Code)
● Complexity metrics (e.g., Cyclomatic complexity)
● Quality metrics (e.g., number of defects)
Logic:
Help estimate, control, and improve software quality.
17. Software Process Improvement
Definition:
Systematic effort to enhance the process.
Models:
● CMM (Capability Maturity Model)
● ISO 9001
Logic:
Higher process maturity → better quality, predictability.
18. Reuse and Component-Based SE
Definition:
Build software by assembling existing components.
Logic:
Reduce cost, speed up delivery.
Example:
Using authentication libraries instead of coding from scratch.
19. Software Configuration Management (SCM)
Definition:
Managing changes to software artifacts.
Activities:
● Version control
● Change control
● Build management
Example:
Using GitHub to manage code versions.
20. Documentation
Definition:
Written materials about the software.
Types:
● User manuals
● Design docs
● Test plans
Logic:
Helps users and maintainers understand and use software.
21. Black Box Testing
Definition:
A testing method where the tester checks the functionality of the software without knowing
the internal code or structure.
Logic/purpose:
To verify what the software does against its requirements, regardless of how it does it.
Focus:
Inputs and outputs, user perspective.
Types:
Type Purpose Example
Equivalence Divide input into valid/invalid Test age field with <0, 18, 100
Partitioning groups
Boundary Value Test at edges of input ranges Age = 17, 18, 19
Analysis
Decision Table Testing Test combinations of conditions Rules for discount offers
State Transition Testing Test different states and ATM: card inserted → PIN
transitions entered
Use Case Testing Based on user scenarios User buys product online
Example:
In a login form: enter valid and invalid username/password to check correct messages appear.
22. White Box Testing
Definition:
A testing method where the tester knows the internal code and logic and tests paths,
conditions, and statements.
Logic/purpose:
To ensure code works as intended and covers all logical paths.
Focus:
Internal structure of code.
Types:
Type Purpose Example
Statement Every statement executed at least Ensure all lines run
Coverage once
Branch Coverage Every branch (if/else) tested Test both true & false of conditions
Path Coverage All possible paths tested Complex loops and conditions
Condition Each boolean expression tested If (A && B) test A true/false, B
Coverage true/false true/false
Loop Testing Test loops with 0, 1, many For loop runs 0, 1, n times
iterations
Example:
If a function calculates tax, tester checks code to ensure all “if tax > 1000” conditions execute
correctly.
Difference Table (for clarity):
Feature Black Box Testing White Box Testing
Knowledge of code Not required Required
Focus Functionality Code logic, paths
Test cases Based on Based on code
requirements
Who does Testers Developers/testers
Tools Selenium, JMeter JUnit, coverage tools
Why both?
● Black box: finds missing functionality, wrong features
● White box: finds hidden bugs, unreachable code
Summary to remember easily:
🖤 Black box → “test from outside” → user view → input/output
🤍 White box → “test from inside” → developer view → code paths
