Software Engineering

What is Software Engineering?

The Problem Domain

Software today is used everywhere — from banking to healthcare to social media. As software systems became larger and more complex, building them became harder. Early programmers wrote code without any planning or structure, which led to what we call the "Software Crisis" — projects were late, over budget, and full of bugs.

The problem domain refers to the real-world area that the software is meant to serve. For example, if you're building a hospital management system, the problem domain is healthcare administration. Understanding the problem domain deeply is the very first step in building good software.

Software Engineering Challenges

Building software is fundamentally different from building physical things. Here are the key challenges:

• Complexity: Software systems can have millions of lines of code with intricate interactions. Unlike a bridge, you can't "see" software, making it harder to understand.
• Changeability: Software is expected to change constantly — new features, bug fixes, platform updates. This makes managing change a core challenge.
• Invisibility: You cannot visualize software the way you can a building blueprint. This makes communication between developers and clients difficult.
• Conformity: Software must conform to existing systems, regulations, hardware, and user expectations — things that software engineers have no control over.
• Scale: A small script behaves differently from a system with 10 million users. Scaling introduces performance, reliability, and coordination challenges.

The Software Engineering Approach

The software engineering approach tackles these challenges using a phased, structured methodology. Instead of diving directly into coding, a systematic approach is followed:

1. Understand the problem — Gather requirements from stakeholders.
2. Plan a solution — Design the architecture and modules.
3. Build the solution — Write the code according to the design.
4. Verify and validate — Test the software to ensure it works correctly.
5. Maintain and evolve — Fix bugs and add features over time.

Software Process & Desired Characteristics

A good software process should have these desired characteristics:

• Predictability: You should be able to estimate time, effort, and cost with reasonable accuracy.
• Testability & Maintainability: The process should produce software that is easy to test and maintain.
• Early Error Detection: The process should catch errors as early as possible (remember: cost increases exponentially).
• Support for Change: Since requirements change, the process should accommodate changes gracefully.
• Facilitates Verification & Validation: The process should have built-in checkpoints (reviews, testing phases).

Waterfall Model

The Waterfall Model is the oldest and most straightforward SDLC model. It follows a linear, sequential flow — like water flowing down a waterfall — where each phase must be completed before the next begins.

Fig: The Waterfall Model — linear, sequential phases

Phases:

1. Requirements: Gather and document all requirements upfront.
2. Design: Create the system architecture and detailed design.
3. Implementation: Write the actual code.
4. Testing: Verify the software against requirements.
5. Maintenance: Deploy and maintain the system.

Prototyping Model

In the Prototyping Model, a simplified version (prototype) of the software is built quickly to help understand and refine requirements. Think of it as a "rough draft" that you show to the client to get feedback before building the real thing.

How it works:

1. Gather initial requirements (even if incomplete).
2. Build a quick prototype (just the UI or basic features).
3. Show it to the user and collect feedback.
4. Refine the prototype based on feedback.
5. Repeat steps 3-4 until the user is satisfied.
6. Build the final system using the refined requirements.

Fig: The Prototyping Model — iterative refinement with user feedback

Iterative Development

In Iterative Development, the software is built in repeated cycles (iterations). Each iteration produces a working version of the software with added features. The idea: don't try to build everything at once.

How it works: Each iteration goes through the full cycle — requirements → design → code → test. After each iteration, the software is evaluated and the next iteration plans improvements.

Fig: Iterative Development — repeated cycles of Plan → Design → Code → Test

Need for SRS

Why do we need an SRS? Without it:

• Developers and clients have different expectations → the final product doesn't match what the client wanted.
• There's no basis for testing → how do you test something that was never clearly defined?
• Scope creep → requirements keep growing because nothing was agreed upon.
• Disputes → without a written agreement, disagreements can't be resolved objectively.

Requirement Process

The requirement process is the overall workflow for creating an SRS. It has four major steps:

1. Requirement Gathering (Elicitation): Collect information from stakeholders about what they need.
2. Requirement Analysis: Analyze the gathered information, resolve conflicts, and model the system.
3. Requirement Specification: Write the SRS document in a clear, unambiguous format.
4. Requirement Validation: Review the SRS with stakeholders to ensure it's correct and complete.

Fig: Requirement Process — Gathering → Analysis → Specification → Validation

Requirement Gathering Techniques

How do you find what the client actually needs? Here are the common techniques:

Problem Analysis

After gathering raw requirements, we need to analyze them. Problem analysis involves:

• Identifying conflicts: Two stakeholders may want contradictory things. These must be resolved.
• Removing ambiguity: "The system should be fast" is ambiguous. How fast? Under what conditions?
• Modeling the system: Create visual models (like Data Flow Diagrams) to understand data and processes.
• Prioritizing requirements: Not everything is equally important. Use MoSCoW (Must have, Should have, Could have, Won't have) to prioritize.

Types of Requirements

Non-functional requirements include: Performance Reliability Usability Security Portability Maintainability

Characteristics of a Good SRS

A well-written SRS should be:

• Correct: Every requirement stated actually represents what is needed.
• Unambiguous: Each requirement has only one possible interpretation.
• Complete: All requirements are documented; nothing is missing.
• Consistent: No two requirements contradict each other.
• Verifiable: You can test whether each requirement is met. "The system should be user-friendly" is NOT verifiable.
• Modifiable: Easy to update when requirements change.
• Traceable: Each requirement can be traced to its origin and to the design/code that implements it.
• Ranked for importance: Requirements are prioritized (essential vs. desirable).

Components & Structure of an SRS Document

A standard SRS document (following IEEE 830) has these major sections:

1. Introduction: Purpose, scope, definitions, overview of the document.
2. Overall Description: Product perspective, product functions, user characteristics, constraints, assumptions.
3. Specific Requirements: Functional requirements (listed individually), non-functional requirements (performance, security, etc.), interface requirements (user, hardware, software, communication interfaces).
4. Appendices: Supporting information, data models, glossary.

Design Principles

Software design is the process of transforming requirements (the "what") into a blueprint (the "how"). Good design makes the system easier to build, test, and maintain. The key principles are:

• Abstraction: Hide complex details and expose only what's necessary. Example: When you use a TV remote, you don't need to know how the circuit works — you just press buttons.
• Decomposition (Divide & Conquer): Break a complex problem into smaller, manageable sub-problems. Solve each one independently.
• Modularity: Divide the software into independent modules, each handling one specific function.
• Information Hiding: Each module should hide its internal workings from other modules. Other modules only interact through a well-defined interface.
• Separation of Concerns: Different aspects of the software (UI, business logic, database) should be handled by separate parts of the system.

Modularity

Think of modules like LEGO blocks — each block has a clear purpose and connects to others through a standard interface. Benefits:

• Easier development: Teams can work on different modules simultaneously.
• Easier testing: Test each module independently (unit testing).
• Easier maintenance: Fix or update one module without breaking others.
• Reusability: Well-designed modules can be reused in other projects.

Top-Down and Bottom-Up Strategies

In practice, most projects use a combination of both — top-down for overall architecture and bottom-up for implementing individual components.

Coupling

Types of coupling (from BEST to WORST):

Fig: Types of Coupling — from best (Data) to worst (Content)

Cohesion

Types of cohesion (from WORST to BEST):

Fig: Types of Cohesion — from worst (Coincidental) to best (Functional)

Structure Charts

A Structure Chart is a diagram that shows the hierarchy of modules in a system. It shows which module calls which, and what data flows between them.

Symbols used:

• Rectangle: Represents a module
• Arrow (line with arrowhead): Shows the calling relationship (A calls B)
• Small arrow with open circle: Data flow
• Small arrow with filled circle: Control flow (flag)
• Diamond: Conditional call (module is called only if a condition is true)
• Curved arrow: Repetitive call (loop)

Fig: Structure Chart — module hierarchy with data and control flow

Data Flow Diagrams (DFD)

A Data Flow Diagram shows how data moves through a system. It focuses on the processes that transform data and the data stores where data is kept.

Four symbols:

Levels of DFD:

• Level 0 (Context Diagram): Shows the entire system as one process with external entities. The "bird's eye view."
• Level 1: Breaks the main process into sub-processes. Shows major functions.
• Level 2+: Further decomposition of each sub-process.

Fig: Level-0 Context Diagram — the system as a single process with external entities

Programming Principles & Guidelines

Coding is the phase where the design is translated into a working program. While it may seem like "just writing code," professional software engineering treats coding as a disciplined activity with clear principles:

• Readability: Code is read far more often than it is written. Write code that another developer (or future you) can easily understand. Use meaningful variable names, proper indentation, and comments where the "why" isn't obvious.
• Simplicity (KISS): Keep It Simple, Stupid. Choose the simplest solution that works. Clever, tricky code is hard to debug and maintain.
• DRY (Don't Repeat Yourself): If you find yourself copying the same code in multiple places, extract it into a function. Duplicate code means duplicate bugs.
• Single Responsibility: Each function or module should do one thing and do it well.
• Input Validation: Always validate data coming from the user or external systems. Never trust input blindly — it's one of the most common sources of bugs and security vulnerabilities.

Common Coding Errors

Being aware of common errors helps you avoid them. Here are the most frequent coding mistakes:

Structured Programming

The three building blocks:

1. Sequence: Statements executed one after another in order.
2. Selection: Choose between paths based on a condition (if-else, switch).
3. Iteration: Repeat a block of code (for, while, do-while).

Information Hiding

Information hiding (proposed by David Parnas) is the principle that a module should hide its internal details from the outside world. Other modules only interact through a defined interface — they don't know how things work inside, only what they can do.

Benefits:

• Changes to one module don't cascade to others
• Reduces complexity — developers only need to understand interfaces, not internals
• Increases security — internal state can't be tampered with from outside

Programming Practices & Coding Standards

Coding Standards

Coding standards are agreed-upon rules a development team follows for consistency. Common standards include:

• Naming conventions: camelCase for variables, PascalCase for classes, UPPER_SNAKE for constants.
• Indentation & spacing: Consistent use of tabs or spaces (usually 4 spaces).
• Comment guidelines: Every function should have a header comment explaining purpose, parameters, and return value.
• File organization: Imports at top, constants next, then class/function definitions.
• Error handling: Use try-catch blocks, handle errors gracefully, never silently swallow exceptions.

The Coding Process

Professional coding follows a structured process:

1. Understand the design document for the module you're coding.
2. Write pseudocode or outline the logic before writing actual code.
3. Write the code following coding standards.
4. Self-review the code for errors and style issues.
5. Compile and fix syntax errors.
6. Unit test the module.
7. Code review by a peer (another developer reviews your code).

Error, Fault, and Failure

These three terms are often confused but mean different things. Understanding the difference is important:

Fig: Error → Fault → Failure chain

Psychology of Testing

Testing is fundamentally a destructive activity — the goal is to find bugs, not to prove the software works. This is psychologically difficult because the developer naturally wants to prove their code is correct. Best practice: have someone other than the developer test the code. An independent tester approaches the software with a "break it" mindset.

Test Oracles, Test Cases & Test Criteria

Test Case: A set of inputs, execution conditions, and expected results designed to test a specific aspect of the software. A good test case has:

• Test Case ID — unique identifier
• Description — what is being tested
• Pre-conditions — state of the system before the test
• Input data — what to feed the system
• Expected output — what the system should produce
• Post-conditions — state of the system after the test

Test Criteria: Rules that define when testing is "sufficient." Examples:

• Coverage criteria: All statements, all branches, or all paths must be tested.
• Fault-based criteria: Testing should detect specific types of faults.
• Error-based criteria: Focus testing on areas where errors are most likely.

Black-Box Testing

Fig: Black-Box vs White-Box Testing comparison

Key Techniques:

1. Equivalence Class Partitioning

Divide all possible inputs into groups (classes) where each class is expected to behave the same way. Test one value from each class instead of testing every possible input.

2. Boundary Value Analysis

Bugs tend to cluster at the boundaries of input ranges. Test values at, just below, and just above each boundary.

White-Box Testing

Key Coverage Criteria:

• Statement Coverage: Every line of code is executed at least once. (Weakest criterion)
• Branch Coverage: Every decision (if/else) takes both the true and false path at least once.
• Path Coverage: Every possible path through the code is tested. (Strongest but often impractical for large programs)
• Condition Coverage: Each individual boolean condition is evaluated to both true and false.

Levels of Testing

Integration Testing Strategies:

• Big Bang: Integrate all modules at once and test. Simple but very hard to isolate errors.
• Top-Down: Start from the top module, stub lower modules. Tests high-level logic first.
• Bottom-Up: Start from the lowest modules, use drivers. Tests basic components first.
• Sandwich (Hybrid): Combine top-down and bottom-up approaches.

Fig: Levels of Testing — Unit → Integration → System → Acceptance

Test Plan

A typical test plan includes:

• Test Plan ID & Name
• Scope: What features will and will not be tested.
• Test Strategy: Types of testing (unit, integration, system, acceptance) and techniques (black-box, white-box).
• Entry & Exit Criteria: Conditions to start and stop testing. E.g., "Entry: all modules coded; Exit: 95% test cases pass, no critical bugs."
• Test Environment: Hardware, software, network configuration needed.
• Resources & Schedule: Who tests what, and the timeline.
• Risk Assessment: What could go wrong and how to mitigate it.

Test Case Specifications & Execution

Test Case Specification documents the detailed test cases in a structured format:

Test Execution & Analysis: After running test cases, results are recorded and analyzed. If a test fails, the tester documents the actual vs. expected output, the environment, and steps to reproduce the issue.

Defect Logging & Tracking

When a test case fails, a defect report is filed. It includes:

• Defect ID — unique identifier
• Summary — one-line description
• Severity — how bad is it? (Critical / Major / Minor / Cosmetic)
• Priority — how urgently should it be fixed? (High / Medium / Low)
• Steps to Reproduce — exact steps to trigger the bug
• Environment — OS, browser, device used
• Attachments — screenshots, logs
• Status — New → Assigned → Fixed → Verified → Closed

Fig: Defect Lifecycle — New → Open → Assigned → Fixed → Retested → Closed

Software Maintenance

Four types of maintenance:

Fig: Software Maintenance Types — Perfective dominates at ~50%

COCOMO Model

Three levels of COCOMO:

Three project modes:

Fig: COCOMO Modes — Organic, Semi-Detached, Embedded

Function Point Metric

Five function types counted:

Fig: Function Point Analysis — 5 function types (EI, EO, EQ, ILF, EIF)

Calculation process:

1. Count each function type and classify as Simple, Average, or Complex.
2. Multiply counts by standard weights to get Unadjusted Function Points (UFP).
3. Evaluate 14 General System Characteristics (GSCs) — each rated 0-5 — to get the Value Adjustment Factor (VAF).
4. Calculate: FP = UFP × (0.65 + 0.01 × sum of GSCs)