Day 21 – Link the Six Core Software‑Engineering Topics Before Advancing

The past six days covered six knowledge “shelves”; Day 21 integrates them into a complete software‑engineering flow.

Complete Software‑Engineering Flow

Business goals → choose development model → manage requirements → use UML → apply design principles & patterns → code & integrate → test (unit, integration, system, acceptance) → measure and improve.

Development model determines project progression.

Requirements engineering clarifies what the system should do.

UML expresses requirements and design clearly.

Design principles & patterns handle change.

Testing verifies the software.

CMMI improves the organization’s process.

Shelf 1: Development Models

Before selecting a model consider requirement clarity, change frequency, project risk, and need for incremental delivery.

Common models and their traits:

Waterfall : stable requirements, sequential phases.

V‑model : emphasizes correspondence between development and test phases.

Prototype : build a sample when users cannot describe requirements.

Spiral : high‑risk projects; risk analysis each cycle.

Incremental : deliver part of functionality first, then add more.

Iterative : repeatedly refine the same functionality.

Agile : frequent requirement changes, short cycles, continuous feedback.

Increment adds functionality; iteration refines it.

Exam tip: “risk analysis” → think Spiral; “user cannot describe” → Prototype; “frequent changes, short cycles” → Agile.

Shelf 2: Requirements Engineering

It is a continuous activity chain: requirement acquisition → analysis → specification (SRS) → verification → management.

Acquisition methods

Interviews

Questionnaires

Observation

Prototypes

Meetings

Analysis

Handle conflicts, ambiguities, priorities; build requirement models.

Specification

Write a formal SRS.

Verification

Check that requirements are correct, complete, consistent, feasible, and verifiable.

Management

Control changes, versions, status, approvals, and traceability.

Functional requirements answer “what the system does”; non‑functional requirements answer “quality constraints”.

Shelf 3: UML

UML diagrams express system aspects clearly.

Use‑case diagram : actors and provided functions.

Class diagram : classes, attributes, methods, static relationships.

Sequence diagram : time‑ordered message flow.

Activity diagram : business steps, decisions, parallel flow.

State diagram : object state changes.

Component diagram : software components and dependencies.

Deployment diagram : physical nodes and deployment.

Class‑relationship taxonomy: dependency, association, aggregation, composition, generalization, realization.

Use‑case relationships: include (mandatory step) and extend (optional conditional step).

Use‑case shows roles/functions; class diagram shows static structure; sequence diagram shows timed messages; deployment diagram shows physical nodes.

Shelf 4: Design Principles & Patterns

Principles aim to reduce coupling and isolate change, making systems easier to extend and maintain.

Single Responsibility

Open‑Closed

Liskov Substitution

Dependency Inversion

Interface Segregation

Law of Demeter

Pattern categories:

Creational – how objects are created.

Structural – how objects are composed.

Behavioral – how objects collaborate.

Common patterns:

Singleton – only one instance.

Factory – encapsulate object creation.

Adapter – convert incompatible interfaces.

Decorator – add capability without changing the original.

Proxy – control access, caching, remote calls.

Observer – notify multiple objects of a change.

Strategy – swap algorithms dynamically.

Adapter changes interface; Decorator adds ability; Proxy controls access.

Shelf 5: Software Testing

Testing levels answer “what range is being tested”.

Unit testing : test internal logic of a module.

Integration testing : test interfaces and collaboration between modules.

System testing : test the complete system against functional and non‑functional requirements.

Acceptance testing : user or business confirms requirements are met.

Test design methods answer “based on what to design test cases”.

Black‑box : based on requirements, inputs/outputs; techniques include equivalence partitioning, boundary‑value analysis, decision tables.

White‑box : based on internal structure; coverage criteria include statement, decision, condition, condition‑combination, path coverage.

Top‑down integration needs stubs; bottom‑up needs drivers.

Shelf 6: CMMI

CMMI evaluates and improves organizational process capability. Five maturity levels:

L1 – Initial : chaotic, unpredictable.

L2 – Managed : project planning, tracking, requirement and configuration management.

L3 – Defined : organization‑wide documented standard process; projects can tailor.

L4 – Quantitatively Managed : use data and statistics to predict and control.

L5 – Optimizing : root‑cause analysis, defect prevention, continuous innovation.

Mnemonic: people, manage projects, define standards, look at data, continuously improve.

Case Study: E‑commerce Order System

A company wants an order system with fast‑changing requirements, multiple payment methods, inventory calls, amount limits 1‑10000 ¥, and a desire for stable processes.

Mapping to the six shelves:

Development model : frequent changes → Agile; staged rollout → Incremental.

Requirements engineering : interview & prototype, analyze conflicts, write SRS, verify completeness, manage changes.

UML : use‑case diagram for user actions; class diagram for entities; sequence diagram for service calls; deployment diagram for server nodes.

Design : order service depends on payment interface (Dependency Inversion); adding payment methods uses Open‑Closed via new implementations; factories create payment objects; Strategy for discount algorithms; Observer/event for notifying inventory, points, SMS.

Testing : unit test amount calculation; integration test order‑inventory interface; system test full order flow and performance; acceptance test business fit; boundary‑value test amounts 0,1,2,9999,10000,10001.

Process improvement : start with project‑level planning & tracking, then define organization‑wide process, collect defect and productivity data, finally apply root‑cause analysis for continuous optimization.

Exam‑style tip: “frequent changes → Agile”, “risk analysis → Spiral”, etc., are reinforced by the case.

Memory‑Palace Technique

Associate each “location” in a daily commute (building entrance, punch‑in machine, lobby fish‑pond, elevator, 5th floor, desk) with one of the six shelves. Repeated walkthrough compresses the visual scene into a cue‑trigger for the knowledge name, then a one‑sentence description of its role.

Three‑stage recall practice:

Location → knowledge name.

Name → core function.

Name → 3‑5 key points.

Random questioning (e.g., “Which design principle belongs to the elevator?”) strengthens true mastery beyond rote sequencing.

Exam Questions and Answers

Twenty multiple‑choice questions cover model selection, requirement activities, UML diagram choice, pattern identification, testing levels, and CMMI maturity. Answers are listed at the end.

Answers

1.A  2.B  3.C  4.C  5.B  6.B  7.A  8.C  9.B  10.B  11.C  12.B  13.A  14.B  15.B  16.C  17.B  18.B  19.C  20.D