Phase 5 of 5  ·  Management
Week 20 / 20   ·   Ch 24–25

Quality &
Configuration Management

"ISO 9001, Git, Code Review — the boring stuff that saves projects"

📚 Ch 24–25 — Quality & Config Mgmt✅ Quality Processes📁 Version Control & CI/CD⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

✅

Software Quality Management

Organizational process ensuring software meets defined quality standards through planning, assurance, and control.
⌄

When to Use

Any organization producing software for external use or regulated environments.

Real-World Example

ISO 9001 certification: companies must document processes and demonstrate continuous improvement. Required for enterprise sales.

✓ Advantages

  • Consistent, repeatable quality
  • Customer confidence
  • Regulatory compliance

⚠ Watch Out

  • Overhead and bureaucracy risk
  • Documentation-heavy
  • Can stifle agility if too rigid
What a quality plan covers
Product standardsCode style, documentation
Process standardsReview & testing practices
Quality metricsDefect density, coverage
Exception handlingReporting & correction
🔍

Code Reviews and Inspections

Systematic examination of code by team members. One of the highest ROI quality activities in software development.
⌄

When to Use

Every non-trivial code change — especially before merging to main.

Real-World Example

Microsoft research: code review catches 60-80% of defects. Cost: ~1hr per PR. Cost of not reviewing: potentially much more.

✓ Advantages

  • Catches bugs before testing
  • Knowledge sharing
  • Enforces standards
  • Architecture alignment

⚠ Watch Out

  • Time overhead
  • Can create bottlenecks
  • Needs good culture to be non-adversarial
Pull-request review checklist
1Correctness — does it do what it should?
2Edge cases — null, empty, overflow?
3Security — any injection or auth issues?
4Performance — N+1 queries, hot loops?
5Readability — still clear in 6 months?
6Tests — is coverage adequate?
📁

Version Control & Configuration Management

Tracking and controlling changes to software — who changed what, when, why. Git is the foundation.
⌄

When to Use

From day 1, on every project, always. No exceptions.

Real-World Example

Every PR in GitHub is configuration management: change proposal → review → approval → merge → CI → deploy.

✓ Advantages

  • Full history of all changes
  • Rollback capability
  • Team coordination
  • Audit trail

⚠ Watch Out

  • Merge conflicts
  • Complex branching strategies
  • Learning curve for Git
The four parts of configuration management
Version ControlGit
System BuildingCI/CD pipelines
Change ManagementPR process
Release ManagementSemantic versioning
Together they make software delivery controlled and auditable.
🚀

CI/CD and Release Management

Continuous Integration: automatically build and test every commit. CD: automatically deploy validated builds.
⌄

When to Use

Any team deploying software more than once a month — which should be all teams.

Real-World Example

Netflix deploys thousands of times per day. Possible only with fully automated CI/CD pipelines.

✓ Advantages

  • Catch integration bugs early
  • Fast feedback
  • Repeatable releases
  • Reduced deployment risk

⚠ Watch Out

  • Investment in pipeline setup
  • Flaky tests break pipeline
  • Needs good test coverage
CI/CD pipeline — commit to production
1BuildCompile on every commit.
2Unit TestsFast checks on each function.
3Integration TestsComponents working together.
4Staging DeployShip to a production-like environment.
5E2E TestsFull user-flow validation.
6Production DeployRelease to users.

📋Quick Reference

θ Ch 24–25 Cheat Sheet — Quality & Configuration Management
Quality Plan
Defines standards, metrics, and processes. Reviewed each milestone.
Code Review
Human inspection before merge. Catches 60-80% of defects. Non-negotiable.
Version Control
Git + branching strategy (GitFlow, trunk-based). Every change tracked.
CI
Automatically build + test every commit. Catch integration bugs early.
CD
Automatically deploy validated builds. Reduces deployment risk.
Semantic Versioning
MAJOR.MINOR.PATCH. Breaking.Feature.Bugfix. v2.3.1.
ISO 9001
International quality management standard. Process documentation + continuous improvement.
Configuration Audit
Verify that delivered system matches approved configuration. Required before major releases.
θ
Sommerville's Key Points — Ch 24–25
Author's own summary from the end of the chapter.
  • 1Software quality management: planning, assurance, and control of quality throughout development.
  • 2Quality plans: define product and process standards, quality goals, metrics.
  • 3Code inspections and reviews: systematic defect finding. High ROI quality activity.
  • 4Configuration management: version control, system building, change management, release.
  • 5Version control (Git): foundation of all software configuration management.
  • 6CI/CD: automated build, test, deploy pipeline. Enables fast, reliable delivery.
  • 7ISO 9001: process-oriented quality management standard for external certification.

🌍From the Book & Beyond

📖

Case Study — ISO 9001 & Its Nine Core Processes (Fig 24.5)

Chapter 24's centerpiece standard is ISO 9001 — part of the ISO 9000 family, originally developed in 1987 and reoriented by the 2000 revision around nine core processes (Figure 24.5), spanning business acquisition, design and development, test, configuration management, and supplier management. Crucially, ISO 9001 doesn't prescribe how to build software: it's a framework requiring companies to define, document, and demonstrate their own quality processes in a quality manual. Sommerville's warning is sharper than the standard itself — certification proves you follow your defined processes; it does not guarantee that a certified company's software is better than anyone else's.

⚡

2026 Perspective — Quality Gates in CI

In 2026, quality management lives in the CI pipeline. Quality gates run as GitHub Actions: linting, tests, coverage thresholds, and security scans must pass before a pull request can merge — Sommerville's "quality plan" encoded as branch protection rules. Peer code review is the modern inspection: continuous and cheap instead of a scheduled meeting. And configuration management became invisible-but-critical — Git, lockfiles, container image digests, and infrastructure-as-code mean every build is a reproducible baseline. Nobody says "configuration management" anymore; they just can't ship without it. The discipline won by disappearing into automation.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
What is the difference between Quality Assurance (QA) and Quality Control (QC)?
QA is process-oriented: ensures quality processes are followed (code reviews, testing standards, documentation). Prevents defects. QC is product-oriented: inspects actual output (test results, code review findings, defect reports). Detects defects. QA = prevent. QC = detect. Both are needed.
Q2
Apply
What are the 4 components of software configuration management?
1. Version control: tracking changes to software artifacts (Git). 2. System building: assembling components into a running system (CI/CD, Gradle, npm). 3. Change management: process for proposing and approving changes (PR process). 4. Release management: packaging and delivering versions to customers (semantic versioning, release branches).
Q3
Analyze
What is trunk-based development and how does it enable CI?
Trunk-based development: all developers integrate changes into a single main branch (trunk) at least daily. No long-lived feature branches. Enables true Continuous Integration because everyone's code is always integrated. Feature flags hide in-progress features from users. Contrast with GitFlow which has long-lived feature branches that diverge and cause painful merges.