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
Quality Plan: → Product standards (code style, docs) → Process standards (review, testing) → Quality metrics (defect density, coverage) → Exception reporting and 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
PR Review Checklist: □ Correctness: does it do what it should? □ Edge cases: what about null, empty, overflow? □ Security: any injection, auth issues? □ Performance: any N+1 queries, loops? □ Readability: can you understand it in 6 months? □ Tests: are the tests 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
Config Management Components: 1. Version Control (Git) 2. System Building (CI/CD pipelines) 3. Change Management (PR process) 4. Release Management (semantic versioning) → Together: controlled, auditable software delivery
🚀

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
Commit → [Build] → [Unit Tests] ↓ [Integration Tests] ↓ [Staging Deploy] ↓ [E2E Tests] ↓ [Production Deploy]

📋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.

🧠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.