Software Engineering Lecture Notes

Table of Contents
• 1. Foundations
• 1.1 What is software?
• 1.2 What is software engineering?
• 1.3 What is a software product?
• 1.4 The need for software engineering
• 1.5 Characteristics of good software
• 2. Software Development Life Cycle (SDLC)
• 2.1 Overview of SDLC phases
• 2.2 Software development paradigms
◦ 2.2.1 Waterfall model
◦ 2.2.2 Structured evolutionary (Prototyping) model
◦ 2.2.3 Incremental model
◦ 2.2.4 Rapid Application Development (RAD) model
◦ 2.2.5 Spiral model
◦ 2.2.6 V-model
◦ 2.2.7 Scrum development model
◦ 2.2.8 Big Bang model
• 3. Requirements Engineering
• 3.1 Requirements engineering process
• 3.2 Requirement elicitation techniques
• 3.3 Types of software requirements
• 4. Measurement and Metrics
• 4.1 Software metrics and measurement fundamentals
• 5. Software Design
• 5.1 Levels of design (architectural, high-level, detailed)
• 5.2 Modularization principles
• 5.3 Cohesion and coupling
• 5.4 Data Flow Diagrams (DFDs)
• 5.5 Structure charts
• 5.6 HIPO diagrams (Hierarchy plus I-P-O)
• 5.7 Entity–Relationship (ER) models
• 6. Project Management & Design Approaches
• 6.1 Software project management overview
• 6.2 Design approaches (top-down, bottom-up, structured)
• 6.3 User interface design
◦ 6.3.1 Command-line interfaces (CLI)
◦ 6.3.2 Graphical user interfaces (GUI)
• 7. Testing
• 7.1 Testing approaches (unit, integration, system, acceptance)

1
 • 7.2 White-box testing techniques
• 7.3 Black-box testing techniques
• 7.4 Test documentation essentials
• 7.5 Testing levels and their objectives

1. Foundations

1.1 What is software?

Software is the collection of computer programs along with associated documentation and data that
instructs hardware to perform tasks. In other words, software consists of programs and documentation
needed to make those programs run 1 . It is intangible (not a physical product) and can be copied,
modified, and distributed easily. Key points:
- Programs & Documentation: Includes source code, compiled code, user manuals, config files 1 .
- Intangible: Unlike hardware, software does not wear out, but can deteriorate in quality if not maintained
2 .

- Custom vs. Generic: May be tailor-made for one client or sold broadly (see Software Product below).
- Diagram suggestion: Illustrate software vs hardware differences (e.g. boxes showing programs and user
manuals).
- Example: Microsoft Word as an application program (with manuals) is software.
- Pros/Cons: Pros: Flexible, easily updated. Cons: No physical form, quality depends on development
process.

1.2 What is software engineering?

Software engineering is the disciplined, structured approach to developing software. Pressman defines it
as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and
maintenance of software” 3 . Sommerville similarly calls it an engineering discipline concerned with all aspects
of software production 4 . In simple terms, it means using engineering principles and best practices to
ensure software quality and reliability. Key elements:
- Phases and Process: Involves defined stages (analysis, design, coding, testing) with review and
management.
- Methods and Tools: Uses methodologies (e.g. Agile, Waterfall) and CASE tools to support development.
- Quality Focus: Emphasizes correctness, efficiency, maintainability, and validation.
- Pros: Improves product quality, predictability, maintainability.
- Cons: May add overhead (documentation, process) and require skilled management.
- Diagram suggestion: Show Pressman’s layered technology model (Tools → Methods → Process → Quality
focus).
- Example: Developing an airline reservation system using defined processes to ensure safety and reliability.

1.3 What is a software product?

A software product is a software system intended for sale or general use. It can be a generic (packaged)
product available to any customer or a customized (bespoke) product built for a particular customer 5 . Key
aspects:
- Generic Products: Off-the-shelf software (e.g. database systems, office suites) sold on the open market
6 . They serve many customers with common needs.

2
- Customized Products: Developed to a client’s specifications (e.g. in-house accounting system, embedded
control software). The customer controls the requirements 7 .
- Release and Versioning: Products usually have version updates (bug fixes, enhancements) released over
time.
- Pros & Cons: Generic: greater market and reuse but may not fit all users’ needs. Custom: precise fit but
high development cost and no reuse beyond that client.
- Example: Microsoft Office (generic product) vs. a custom-built ATM controller (customized product) 6 .

1.4 The need for software engineering

As software systems grow larger and more complex, the software crisis of late 1960s persists: projects
running late, costing more, or failing outright 8 . Software engineering is needed to manage this
complexity and produce dependable software on time and budget. Reasons include:
- Complexity and Scale: Modern software can have millions of lines of code; engineering methods help
break this down.
- Quality and Reliability: Without rigorous process, defects and security issues abound. SE improves
testing and validation.
- Economics: Software projects consume large resources. Engineering helps control costs and schedules
(Sommerville notes rising software costs in the 21st century) 9 .
- Customer and Stakeholder Demands: To meet changing requirements and quality expectations, a
disciplined approach (requirements management, documentation) is essential.
- Pros/Cons: Pros of SE: Predictable planning, higher quality, maintainability. Cons: Up-front costs, requires
training.
- Example: Launch of a new smartphone app must meet tight deadlines; using an agile SE process (like
Scrum) can manage changing user requirements efficiently.

1.5 Characteristics of good software

Good software meets user needs and technical standards. Key attributes (often cited by Sommerville and
standards bodies) include 10 :
- Correctness/Functionality: Delivers all required functions accurately.
- Reliability/Dependability: Operates without failure; includes safety and security.
- Efficiency: Uses minimal resources (memory, CPU) and responds quickly.
- Usability: Easy to learn and use, with clear interface and documentation.
- Maintainability: Easy to modify or extend; well-organized, documented code.
- Portability: Can run on different platforms with little change.
- Other attributes: Reusability, interoperability, and robustness under stress.
- Diagram suggestion: A chart listing quality attributes (like a hexagon or table).
- Example: An operating system that rarely crashes (reliable), boots quickly (efficient), has a user-friendly GUI
(usable), and allows hardware drivers to be added easily (maintainable/portability).

2. Software Development Life Cycle (SDLC)

2.1 Overview of SDLC phases

The Software Development Life Cycle (SDLC) is a structured framework of phases guiding software
creation 11 . It ensures that work is organized, quality is built in, and deliverables are well-defined. A typical

3
SDLC includes:
1. Planning/Requirements – Define goals, scope, and gather requirements. (Who needs what?)
2. System & Software Design – Architect the system and detail modules/interface design.
3. Implementation/Coding – Write and compile the actual code modules.
4. Testing – Systematically test units, integrations, and the full system for defects.
5. Deployment – Deliver the system to users (could be via installation or release).
6. Maintenance – Fix bugs, adapt to new requirements, and upgrade over time.

Each phase often produces key documents (e.g. SRS, design specs, test plan). A feedback loop may exist
(e.g. maintenance issues can lead back to more design).
- Diagram suggestion: A flowchart or cycle diagram of the phases (sometimes drawn linearly or circularly).
- Example: Building an e-commerce site would follow SDLC: requirements from stakeholders, design
architecture (databases, web front-end), code it, test with test cases, then deploy on a web server, and
maintain with updates.
- Citation: Atlassian notes that adhering to SDLC phases helps teams “deliver reliable, functional software,
avoid common pitfalls, and keep projects on schedule” 11 .

2.2 Software development paradigms

Several SDLC models (paradigms) describe how phases are organized. Each has advantages and
drawbacks:

2.2.1 Waterfall model

A sequential linear process (Royce, 1970). Phases flow one after the other (requirements → design → coding
→ test → maintenance). Characteristics: All requirements are specified up-front. Each phase must
complete before next begins 12 .
- Key Points: Clear milestones and documentation 13 ; rigid phase overlap (no going back easily) 14 .
- Pros: Easy to understand and manage; well-defined milestones; good for stable requirements 13 .
- Cons: Very inflexible to change; late defect detection (testing only after coding) 14 ; assumes requirements
will not change 15 .
- Diagram suggestion: A cascading flowchart (like a waterfall) with phases stacked vertically.
- Example: Often used in government or safety-critical projects where requirements are unlikely to change
(e.g. initial designs for avionics systems).

2.2.2 Structured evolutionary (Prototyping) model

In the prototyping model, a quick version of the system (prototype) is built early to clarify requirements.
The prototype is refined through user feedback, then a final system is built from it.
- Key Points: Emphasizes early user involvement; requirements evolve by using the prototype.
- Pros: Helps discover misunderstood or missing requirements; users see tangible results early; improves
usability by iterative feedback.
- Cons: Can create false comfort (prototype not full product); risk that prototype code gets used in final
system (poor quality); time spent on multiple iterations.
- Diagram suggestion: Show cycle: Prototype → User Feedback → Refine Prototype → Repeat → Finalize.
- Example: A startup creating a new mobile app might first build a clickable UI mockup (prototype), get user
feedback on features, then iteratively refine until final development.

4
2.2.3 Incremental model

Incremental development builds the system in small parts (increments). Each increment is a portion of the
functionality, delivered and tested, and then integrated with previous increments.
- Key Points: Divide project into modules; after each increment, a partial system is released.
- Pros: Early partial delivery adds value sooner; easier testing of smaller parts; flexibility to change later
increments.
- Cons: Requires careful architecture planning; incremental integration can be complex; total cost may be
higher than building all at once.
- Diagram suggestion: Show layers: base increment deployed, then next layers added, etc.
- Example: A large web platform might first release core features (user login, profile) and then add other
features in later releases.

2.2.4 Rapid Application Development (RAD) model

RAD emphasizes rapid development with user feedback. It often uses component assembly and automated
tools.
- Key Points: Work in short development cycles; use code generators or reusable components; heavy user
participation.
- Pros: Very fast delivery of a functioning system; adapts quickly to requirement changes; high user
engagement.
- Cons: Needs a strong skilled team and governance; not suitable if underlying architecture is complex or if
funding is limited; risk of insufficient design if rushed.
- Diagram suggestion: A timeline of short iterative cycles with user review after each cycle.
- Example: Developing an internal tool for a company with a fixed two-week sprint cycle, using GUI builders
and then collecting immediate feedback.

2.2.5 Spiral model

The Spiral model (Boehm) combines iterative development with risk analysis. The project passes through
repeated spiral cycles. Each cycle has phases: planning, risk analysis (with prototyping if needed),
development, and evaluation.
- Key Points: Focus on identifying and mitigating risks at each cycle; iterative refinement.
- Pros: Good for large, high-risk projects; explicit risk management; flexible iteration.
- Cons: Can be complex and expensive (constant risk assessment); requires expertise in risk analysis.
- Diagram suggestion: A spiral chart showing cycles with layers (each loop of the spiral = a cycle of
development and risk review).
- Example: Building an interplanetary spacecraft’s software, where risk management and iterative
prototyping are crucial.

2.2.6 V-model

The V-model is a variant of Waterfall that emphasizes testing. It pairs each development phase with a
corresponding testing phase on the opposite side of the “V.” For example, system design pairs with system
testing.
- Key Points: Validation and verification steps parallel development steps; test planning is done early.
- Pros: Very disciplined; makes testing responsibility explicit at each level.
- Cons: Like Waterfall, it is rigid and assumes stable requirements; little scope for iteration.

5
- Diagram suggestion: A “V” shaped diagram: left side (down) shows stages (requirements, design,
implementation), right side (up) shows tests (unit, integration, system).
- Example: Common in safety-critical software (e.g. avionics), where formal testing at each stage is
mandatory.

2.2.7 Scrum development model

Scrum is an Agile framework for iterative development in short cycles called sprints 16 . Work is organized
by a prioritized backlog of features. A Scrum Team (Product Owner, Scrum Master, Developers) works in time-
boxed sprints (usually 1–4 weeks). Daily 15-minute stand-up meetings track progress.
- Key Points: Iterative/incremental approach; frequent feedback and adaptability 16 ; team self-
organization.
- Pros: Very flexible to requirement changes; continuous user feedback ensures product remains on target;
promotes high team communication.
- Cons: Requires strong team discipline and stakeholder involvement; scope can creep if not managed; not
ideal for all team sizes or cultures.
- Diagram suggestion: Scrum cycle diagram (product backlog → sprint backlog → sprint → review).
- Example: Developing a consumer mobile app with frequent releases; each 2-week sprint yields a working
increment and demo to stakeholders.

2.2.8 Big Bang model

The Big Bang model is informal: little or no planning, requirements may be unclear, and developers code
with minimal process. All resources are thrown at development, and the product may or may not work.
- Key Points: No defined structure or phases; high uncertainty.
- Pros: Minimal management overhead; suitable when scope is very small or experimental.
- Cons: Extremely high risk of project failure; no control or metrics; likely chaotic and late.
- Diagram suggestion: Possibly a chaotic diagram showing all activities colliding.
- Example: A quick-and-dirty prototype built by a single programmer to demonstrate an idea, with no
guarantee it will function as a full product.

3. Requirements Engineering

3.1 Requirements engineering process

Requirements Engineering (RE) involves all activities to discover and define what software should do. It is
“the process of identifying, eliciting, analyzing, specifying, validating, and managing the needs and expectations
of stakeholders for a software system” 17 . Typical process steps:
- Feasibility Study: Early evaluation (technical, economic, legal) to see if requirements gathering should
proceed.
- Elicitation/Gathering: Use techniques (interviews, surveys, prototyping) to collect user and stakeholder
needs 18 .
- Analysis and Specification: Organize and document requirements formally (e.g. in a Software
Requirements Specification, SRS). Define functional and quality (non-functional) requirements.
- Validation/Review: Check requirements for completeness, consistency, and correctness with
stakeholders. Use reviews or prototypes.
- Management: Handle changes to requirements over time, traceability, and version control of

6
requirements docs.
- Diagram suggestion: A flowchart from stakeholder needs → requirements → validation → requirements
baseline.
- Example: For a hospital management system, RE ensures doctors, nurses, and admin all agree on what
features (patient records, scheduling) are needed and documented.

3.2 Requirement elicitation techniques

Effective elicitation is key to finding true requirements. Common techniques include:

- Interviews: One-on-one meetings with users and customers to ask about needs.
- Workshops (JAD): Facilitated group sessions where stakeholders jointly discuss requirements.
- Questionnaires/Surveys: Written questions distributed to a broad user group.
- Observation: Watch users in their normal work environment to discover implicit needs.
- Prototyping: Build quick mock-ups or UI prototypes to elicit feedback (a form of interactive elicitation).
- Brainstorming/Storyboarding: Creative sessions to generate and prioritize ideas.
- Document Analysis: Review existing systems, manuals, or competitor products.
- Example: Observing call-center agents using the current system may reveal undocumented requirements
(like shortcut commands users rely on).

3.3 Types of software requirements

Requirements can be classified into:

- Functional Requirements (FRs): Specific behaviors or functions (what the system should do). Examples:
“The system shall allow users to log in” or “calculate salary”.
- Non-Functional Requirements (NFRs) / Quality Attributes: System qualities or constraints. Typical NFRs
include: - Performance: response time, throughput, resource usage.
- Reliability: uptime, mean time between failures.
- Usability: ease of use, user interface standards.
- Maintainability: ease of updates, modularity.
- Security: access control, encryption.
- Portability: ability to run on various platforms.
- Domain Requirements: Constraints or needs specific to the application domain (e.g. safety rules in
aviation software).
- User vs. System Requirements: User requirements are high-level needs (often in natural language);
system requirements are detailed, precise specifications (often in SRS).
- Diagram suggestion: Table contrasting a functional requirement example vs. non-functional examples.
- Example: FR: “Process online orders.” NFR: “Handle up to 10,000 orders per hour” (performance) or “encrypt
all customer data” (security).

4. Measurement and Metrics

4.1 Software metrics and measurement fundamentals

Software metrics provide quantitative measures of products and processes. A metric is simply a standard of
measurement. In software engineering, metrics help estimate effort, monitor progress, and assess quality.
Examples include:
- Size Metrics: Lines of Code (LOC), Function Points (FP) – measure software size or functionality.

7
- Complexity Metrics: Cyclomatic complexity, depth of inheritance – assess code complexity or design
complexity.
- Schedule/Cost Metrics: Effort in person-hours, calendar time estimates (COCOMO uses LOC to predict
cost).
- Quality Metrics: Defect density (bugs per KLOC), Mean Time to Failure (MTTF), customer-reported bugs.
- Productivity Metrics: LOC per developer-month, features delivered per release.
- Process Metrics: Requirements stability index, test case coverage (% of requirements tested), rate of
change requests.
- Measurement principles: Metrics should be objective, repeatable, and aligned with goals. They support
informed decision-making (e.g. if defect density is high, focus on testing).
- Diagram suggestion: A sample graph (e.g. effort vs LOC, or a bar chart of defects found over time).
- Example: A team might track the number of test cases passed per build (a metric) to gauge stability. Using
Function Points early helps plan the project size.

5. Software Design

5.1 Levels of design (architectural, high-level, detailed)

Software design occurs at multiple levels:

- Architectural Design: The highest level, defining the system’s overall structure. It identifies major
components or subsystems and their interactions (for example, client-server modules, database, network
components).
- High-Level Design: Breaks each architectural component into modules or classes and defines interfaces
between them. It describes data structures and algorithms at a broad level (e.g. which classes handle user
input vs. data access).
- Detailed (Low-Level) Design: Specifies the internal logic of each module or class. It includes detailed
algorithms, data structures, and pseudocode or design diagrams (UML class diagrams, sequence diagrams,
etc.).
- Diagram suggestion: Show a system overview (boxes for subsystems) vs. a class or module diagram for a
subsystem.
- Example: In designing an e-commerce system, architectural design might show Web Server, Application
Server, and Database components. High-level design breaks the Application Server into modules
(CatalogManager, OrderProcessor, PaymentGateway), and detailed design defines each module’s code
structure.

5.2 Modularization principles

Modularization means dividing software into independent modules or components. Good modules have
clear functionality and interface. Principles include:
- Single Responsibility: Each module should have a well-defined purpose.
- Encapsulation: Modules should hide their internal details, exposing only necessary interfaces.
- Abstraction: Focus on “what” a module does, not “how” it does it.
- Separation of Concerns: Different functionalities separated into different modules (e.g. UI vs data
storage).
- Reuse: Modules should be designed so they can be reused in other systems if generic.
- Pros: Easier maintenance, parallel development by teams, and better understanding.
- Cons: Over-modularization can cause overhead (many module calls) and management complexity.

8
- Example: An image processing system might have separate modules for image loading, filtering, and
display.

5.3 Cohesion and coupling

Two key design quality metrics:

- Cohesion: Measures how closely related the responsibilities of a single module are. High cohesion means
a module does one thing or a set of related things (good). Low cohesion (a “God object”) does unrelated
tasks (bad).
- High Cohesion Example: A CustomerAccountManager module that only handles customer account logic.
- Types: Functional cohesion (best), sequential, communicational, procedural, logical, coincidental (worst).
- Coupling: Measures the interdependence between modules. Low coupling (modules interact through
simple, well-defined interfaces) is desirable. High coupling (modules heavily dependent on each other’s
internals) is bad.
- Low Coupling Example: A payment module that communicates with an order module only via a defined
interface, not by accessing its inner data.
- Types: Content coupling (worst, one module directly changes another’s data), common, control, stamp,
data (best form).
- Diagram suggestion: Illustrate two modules with high coupling (many connections) vs. low coupling (one
connector).
- Example: If a GUI module directly reads a database’s internal structures (high coupling), any change in DB
structure breaks GUI. Better to have GUI call database via a clean interface (low coupling).

5.4 Data Flow Diagrams (DFDs)

A Data Flow Diagram graphically represents how data moves through a system. DFDs use standardized
symbols:
- Processes (circles/rectangles): Actions or transformations (e.g. “Process Order”).
- Data Stores (open-ended rectangles): Places where data is held (files or databases).
- External Entities (squares): Outside systems/actors (e.g. “Customer”).
- Data Flows (arrows): Movement of data between these elements.

DFDs can be layered in levels: a Level 0 (context) DFD shows the system as a single process with external
entities. Level 1 and beyond decompose processes into sub-processes for detail.
- Key Points: Useful for modeling functional requirements and understanding system context.
- Diagram suggestion: Include a simple DFD (e.g. order processing with Customer → (Process Order) →
DataStore) to illustrate the concept.
- Example: The figure below shows a simple Level-1 DFD where customer order data flows to a processing
system and then to a database, with confirmation returned to the customer:

Figure: Sample Data Flow Diagram (e.g. customer orders to order-processing system)

5.5 Structure charts

Structure charts depict the hierarchical organization of modules. They show how the system is broken into
submodules and how these modules call each other (often used with modular decomposition). In a
structure chart:

9
- Modules are drawn as rectangles (or boxes).
- Lines/arrows show “calls” or “control flow” between them (often top-down).
- May include information flows (parameters passed).

Structure charts are used in structured design to document module relationships. They complement DFDs
by focusing on program structure rather than data flow.
- Diagram suggestion: A hierarchical tree of modules, e.g. “Main” at top calling “InputHandler”,
“ComputeEngine”, “OutputGenerator” below it.
- Example: A payroll system’s structure chart might show ComputePayroll as the parent module, with
children like ValidateInput , CalculateTaxes , GeneratePayslip .

5.6 HIPO diagrams (Hierarchy plus Input-Process-Output)

HIPO charts combine a module hierarchy (like a structure chart) with I-P-O (Input-Process-Output)
descriptions. Each module has an associated IPO box listing:
- Inputs: Data required by the module.
- Processes: Actions performed by the module.
- Outputs: Data produced by the module.

HIPOs were popular in the 1970s as documentation. They provide a drill-down view: top-level processes
broken into sub-processes, with each box detailing its function via IPO.
- Diagram suggestion: A top-level HIPO box labeled “Process Order” with sub-modules (Validate Order,
Compute Total, Print Invoice) each listing their input, process steps, output.
- Example: In an ATM system HIPO, a module “WithdrawCash” might list Input: account number, amount;
Process: check balance, update account; Output: dispense cash, updated balance.

5.7 Entity–Relationship (ER) models

ER models are used for database design. An Entity–Relationship (ER) model represents data objects and
their interrelations:
- Entities: Real-world objects or concepts (e.g. Customer, Order). Shown as rectangles.
- Attributes: Properties of entities (e.g. Customer has Name, ID). Often listed inside or below entity box.
- Relationships: Associations between entities (e.g. Customer places Order). Shown as diamonds or labeled
lines.
- Cardinality: Specifies how many instances relate (1-to-1, 1-to-many, many-to-many).

ER diagrams help design the database schema.

- Diagram suggestion: A simple ER diagram for, say, a library system: Entities: Book, Member; Relationship:
borrows (Member borrows Book), with cardinality “one member can borrow many books”.
- Example: Designing a university database, one might model entities Student, Course, and an Enroll
relationship (many-to-many).

10
6. Project Management & Design Approaches

6.1 Software project management overview

Software project management oversees planning and control of a software project to meet goals (scope,
quality, time, cost). Key activities:
- Scope & Requirements Management: Defining exactly what to deliver.
- Time/Schedule Management: Creating a schedule (Gantt charts or Agile backlogs) and tracking progress.
- Cost/Budget Management: Estimating costs (personnel, equipment) and controlling spending.
- Quality Management: Setting quality standards and ensuring design/reviews/testing meet them.
- Resource & Team Management: Assigning tasks, managing team skillsets, and communicating roles.
- Risk Management: Identifying potential project risks (technical, cost, schedule) and planning mitigation.
- Communication: Regular status reports and meetings with stakeholders.
- Diagram suggestion: A Gantt chart example or a resource allocation chart.
- Example: A project manager for a mobile app would create a timeline of sprints, allocate developers to
features, and hold status meetings to ensure deadlines are met.

6.2 Design approaches (top-down, bottom-up, structured)

Different strategies guide how design is carried out:

- Top-Down Design: Start with the highest-level view and break it down. Begin by outlining the entire
system, then decompose it into sub-systems and modules progressively. Good for understanding overall
architecture and ensuring consistency.
- Pros: Provides clear overall structure; easier to verify at each level.
- Cons: May rely on assumptions at top levels; bottom details may be overlooked early on.
- Bottom-Up Design: Build from the basic building blocks first, then integrate into larger components. Use
existing components or libraries and combine them into a full system.
- Pros: Good when core modules are well-understood or reusable; can prove feasibility early (by building
working parts).
- Cons: Hard to see the overall system early; integration can be challenging if higher-level architecture wasn’t
planned.
- Structured Design (Stepwise refinement): Often top-down, where at each step the design is refined in
more detail. Uses data-flow or control-flow decomposition (e.g. using HIPO or structure charts). Emphasizes
clear modular design and documentation.
- Diagram suggestion: Two mini-diagrams: one showing broad system being split (top-down), another
showing small modules being integrated (bottom-up).
- Example: To design a compiler, one might use top-down (overall phases: lexical, syntax, codegen) vs.
bottom-up (start by implementing a generic parsing engine then add to it).

6.3 User interface design

A software’s user interface (UI) determines how users interact with it. Two main types:
- Command-Line Interfaces (CLI): Text-based interfaces where users type commands.
- Pros: Efficient for experienced users; low resource usage; easy to script.
- Cons: Steep learning curve; poor discoverability (users must memorize commands); not friendly for casual
users.
- Example: UNIX shell, Windows Command Prompt.

11
- Graphical User Interfaces (GUI): Visual interfaces with windows, icons, menus, and pointers.
- Pros: Intuitive and user-friendly; easier onboarding for new users; supports rich interaction (drag/drop,
graphics).
- Cons: More complex and costly to design; higher development effort; may hide powerful features behind
menus.
- Example: Web browsers, desktop applications with menus and buttons.
- Design principles: Follow consistency (uniform look/feel), feedback (immediate response to user actions),
and usability guidelines.
- Diagram suggestion: Side-by-side sketch or screenshot – one of a CLI (terminal window) and one of a GUI
(application window).

6.3.1 Command-line interfaces (CLI)

A CLI allows users to type commands in a console or terminal.

- Key Features: Commands often have syntax (flags, arguments). Scripting and automation are
straightforward.
- Example: A git CLI where developers enter git commit -m "message" .
- Design Note: Provide helpful error messages and documentation ( --help or man pages) to assist users.

6.3.2 Graphical user interfaces (GUI)

A GUI presents buttons, menus, forms, and graphics.

- Key Features: Uses windows, dialogs, icons, and menus. Often event-driven (clicks, gestures).
- Example: A visual file explorer where users click icons to open folders.
- Design Note: Follow platform standards (e.g. Windows, MacOS) for consistency; prioritize clarity (clear
labels, logical layout).

7. Testing

7.1 Testing approaches (unit, integration, system, acceptance)

Software testing is done in levels to uncover defects:

- Unit Testing: Tests individual components or functions in isolation. Each “unit” (e.g. a class or function) is
tested with known inputs to verify correct output. Often automated.
- Integration Testing: Tests interactions between combined modules. After units pass, integrate two or
more modules and test their joint behavior (e.g. testing the interface between a database module and UI
module).
- System Testing: Tests the complete, integrated system as a whole against requirements. It checks end-to-
end scenarios (functionality, performance, security). Often done in an environment close to production.
- Acceptance Testing: Formal testing against user needs; often done by the customer or end-users.
Determines whether to accept the system. Includes user-acceptance testing (UAT) and beta testing.
- Diagram suggestion: A pyramid or flow showing unit → integration → system → acceptance.
- Example: For an e-commerce site: Unit test the payment function; integrate payment with order
processing; system test the full purchase workflow; have real customers try it for acceptance.

12
7.2 White-box testing techniques

White-box (structural) testing inspects the internal code. Techniques include:

- Statement Coverage: Design test cases so every line of code is executed at least once.
- Branch/Decision Coverage: Ensure each branch (true/false) in the code is tested.
- Path Testing: Test all feasible execution paths through the code (often using basis path testing or
cyclomatic complexity to identify paths).
- Loop Testing: Focus on loops (e.g. for-loops, while-loops) to test zero, one, and multiple iterations.
- Example: If code has if (x > 0) ... else ... , create tests where x > 0, x = 0, and x < 0 to cover
both branches.

7.3 Black-box testing techniques

Black-box (functional) testing ignores internal code; tests are derived from specifications:
- Equivalence Partitioning: Divide input domain into equivalent classes and test one representative from
each class.
- Boundary Value Analysis: Test the edge values of equivalence classes (e.g., if valid input is 1–100, test 1,
100, and just outside 0,101).
- Decision Table Testing: Use tables for combinations of inputs and corresponding outputs, ensuring all
combinations are tested.
- State Transition Testing: For systems with states, create tests for transitions between states.
- Use Case Testing: Test sequences based on real-world usage scenarios.
- Example: For a login form that accepts 1–12 month values, test months “0” (invalid), “1”, “6”, “12”, and
“13” (invalid) to cover partitions and boundaries.

7.4 Test documentation essentials

Good testing relies on clear documentation:

- Test Plan: Outlines testing strategy, scope, resources, schedule, and types of tests to be done.
- Test Cases/Scripts: Detailed instructions for each test: inputs, steps, expected results. Includes ID and
purpose.
- Test Data: The specific input data used in tests.
- Test Reports: Records of test execution results (pass/fail), summary of defects found, and metrics (e.g.
number of tests passed).
- Bug Reports: Detailed reports for each defect (steps to reproduce, severity, environment).
- Traceability Matrix: Maps requirements to test cases to ensure all requirements are tested.
- Example: A test case for a “Submit Order” feature lists the input fields and the expected confirmation
message, with status “Pass” after execution.

7.5 Testing levels and their objectives

Each test level has a different goal:

- Unit Testing: Objective – verify individual components work correctly (debug code-level errors early).
- Integration Testing: Objective – ensure modules interact correctly (data passes, control flows among
modules properly).
- System Testing: Objective – validate the complete system meets requirements (functional & non-
functional).

13
- Acceptance Testing: Objective – confirm the system satisfies user needs and is ready for deployment.
- Regression Testing: (across all levels) – re-running tests after changes to ensure no new defects.
- Example: After a bug fix in one module, regression tests verify that existing features elsewhere still work.

Pros & Cons Summary (where applicable): For each SDLC model above, we listed advantages (Pros) and
disadvantages (Cons) to guide model selection. Note that all designs and processes must be chosen to
balance flexibility, risk, time-to-market, and project constraints, with real-world examples illustrating typical
use cases.

Sources: Definitions and concepts above draw on Pressman and Sommerville (textbook chapters) and other
authoritative sources. For example, Sommerville defines software and software engineering as shown 19 ,
and Pressman emphasizes a disciplined approach 3 . Other statements follow standard academic
references in SE. Each source is cited inline in the format 【…】 .

1 4 5 6 7 8 9 10 19 Sommerville - Software Engineering 8e

[Link]

2 [Link]
[Link]

3 Software engg. pressman_ch-1 | PPT

[Link]

11 What is SDLC? Software Development Life Cycle Explained | Atlassian

[Link]

12 13 14 15 Waterfall Model - Software Engineering - GeeksforGeeks

[Link]

16 Scrum (software development) - Wikipedia

[Link]

17 18 Requirements Engineering Process in Software Engineering - GeeksforGeeks

[Link]

14