Most software teams say quality matters, but many still improve by opinion. A better approach is simple: define what “good” looks like, measure reality, and only keep changes that improve outcomes.
Six Sigma’s DMAIC model is useful here:
- Define: Start with requirements, constraints, and risk. What problem are we solving? What evidence will prove success?
- Measure: Establish a baseline. Capture data from tests and real systems: timing, memory, defect rates, failure modes, and user-impact metrics.
- Analyse: Look for causal relationships, not anecdotes. Which variables actually move quality or reliability?
- Improve: Make targeted changes and validate them with before/after data.
- Control: Automate checks so gains don’t regress (CI, tests, static analysis, dashboards, alerts).
For embedded teams, this means instrumenting firmware and hardware behaviour early: CPU headroom, stack usage, control-loop stability, sensor noise, and timing margins. These signals should flow into automated pipelines so quality is continuously visible.
Standards and tools help, but they are not the goal. MISRA, DO-178, code review, unit tests, and system tests create value only when tied to risk and measurable outcomes. Avoid “quality theatre” (high activity, low impact).
A practical quality system has five non-negotiables:
- Clear requirements and acceptance criteria.
- Risk-based test strategy.
- Automated regression checks.
- Production/field feedback loops.
- Continuous improvement based on data.
Bottom line: quality is not a one-time phase. It is an operating system for engineering. Measure first, improve deliberately, and remove changes that do not deliver real gains.
Featured image: 6 Sigma Normal distribution by Cmglee, CC BY-SA 3.0, via Wikimedia Commons
