SDLC Practices Reference Guide¶

Model Selection¶

Core Principle¶

There is no single "best" SDLC. The correct model is a function of requirements volatility, regulatory constraints, and team context. The 2026 enterprise norm is hybrid: phase-gate governance wrapping Agile/continuous execution.

Cynefin Framework for Model Selection¶

Domain	Characteristics	Recommended Approach
Clear/Obvious	Stable requirements, known solutions	Plan-driven, predictive, PMBOK
Complicated	Known unknowns, expertise required	Plan-driven with analysis, RUP
Complex	Emergent requirements, high uncertainty	Agile/empirical, Scrum/Kanban
Chaotic	Crisis, novel situations	Act-first stabilization

Most common error: treating Complex problems as Complicated — over-planning the unknowable.

Waterfall and V-Model¶

Royce's 1970 paper actually advocated iteration and prototyping; the linear "waterfall" caricature inverted his argument.

Waterfall is correct when: requirements are genuinely fixed and change is expensive or dangerous — fixed-price/defense contracts, and safety-critical/regulated systems governed by IEC 61508, DO-178C (avionics), and ISO 26262 (automotive).

V-Model: extends waterfall by pairing each development phase with a verification/validation level (unit/integration/system/acceptance). Dominates embedded, medical-device, and automotive development.

Iterative Models¶

Spiral (Boehm 1986): risk-driven, cycling through four quadrants (objectives/alternatives → risk identification/mitigation → development/test → plan next iteration). Suits large, high-risk programs.
RUP/Unified Process: use-case-driven, architecture-centric, iterative across inception/elaboration/construction/transition. Relevant where formal artifacts and architecture rigor are required.

Agile Family¶

Scrum: time-boxed sprints, Product Owner, Scrum Master, Developers; empirical process control.
Kanban: continuous flow, WIP limits, visualize workflow, no iterations.
FDD: feature lists, design-by-feature/build-by-feature.
DSDM: MoSCoW, timeboxing, fitness-for-business-purpose.
Crystal family (Cockburn): scales ceremony to team size and criticality (Clear/Yellow/Orange/Red).

Requirements Engineering in the SDLC¶

Types and Quality¶

Functional vs. non-functional (NFRs/quality attributes). Quality-attribute taxonomy: performance, scalability, availability, reliability, security, maintainability, usability, testability, observability, deployability.

Critical rule: NFRs must be specified concretely — "p99 latency < 200ms at 1,000 RPS," not "fast." NFRs are the most under-specified and highest-risk area in most software projects.

Documentation Approaches¶

Traditional: IEEE 830 SRS, Jacobson use cases, functional specs.
Agile: user stories (As a/I want/So that) with INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).
BDD (Gherkin via Cucumber, SpecFlow, JBehave): builds shared dev/test/business language.
ATDD: writes acceptance tests before implementation.
Impact mapping: goal → actor → impact → deliverable.

Backlog Management¶

Refinement keeps stories ready; ruthless pruning counters "backlog obesity."
Prioritization: MoSCoW, Kano, RICE (Reach × Impact × Confidence ÷ Effort), WSJF (cost of delay ÷ job size from SAFe).
Story mapping (Jeff Patton): user journey backbone with release slices.
Epic decomposition patterns: by workflow step, user role, data type, business rule, happy/unhappy path.

Architecture as a Continuous Concern¶

Key Practices¶

Architecture Decision Records (ADRs): Nygard format or MADR; stored in-repo alongside code; version-controlled.
Fitness functions (Ford/Parsons/Kua, Building Evolutionary Architectures): make architectural qualities testable in CI.
Spikes: time-box architectural uncertainty.
Tech debt identified and classified as a first-class backlog activity.

Design Principles¶

SOLID, DRY, KISS, YAGNI — applied with judgment; premature DRY/abstraction is itself a smell.
Clean Architecture: dependency rule — dependencies point inward; frameworks are details.
DDD strategic: bounded contexts, context maps, ubiquitous language.
DDD tactical: aggregates, entities, value objects, domain events.
API-first/contract-first: OpenAPI/AsyncAPI before implementation.

Documentation¶

C4 model (Simon Brown — Context/Container/Component/Code): with Structurizr; visualizes architecture at four levels of detail.
Docs-as-code: version-controlled, reviewed, tested.
Agile "just enough, just in time" — not big upfront design.

Development Practices¶

Code Quality Enforcement¶

Linters: ESLint, Pylint, Checkstyle.
Formatters: Prettier, Black, gofmt.
Static analysis: part of the CI pipeline.

Code Review — Empirical Guidance¶

The SmartBear/Cisco study (~2,500 reviews, 3.2M LOC, 10 months) found: - Review fewer than 200–400 LOC at a time. - Spread the review over no more than 60–90 minutes. - At this size: 70–90% defect-detection yield. - Defect detection drops sharply beyond ~400 LOC. - Author pre-annotation measurably reduces defects.

Common dysfunctions: nitpick theater, rubber-stamping, PRs blocked for weeks. Google's guidelines emphasize splitting large CLs.

Test-Driven Development (TDD)¶

Red-Green-Refactor cycle. Evidence: - Nagappan et al. (Microsoft/IBM) found pre-release defect-density reductions of 40–90% with a 15–35% increase in initial development time. - Meta-analyses (Rafique & Mišić; Bissi et al.) confirm moderate quality benefit with inconclusive productivity effects. - TDD's quality benefit is well-supported; productivity effect is not.

Pair and Mob Programming¶

Pair programming (Hannay et al. meta-analysis): small positive effect on quality, medium positive effect on duration (speed), medium negative effect on effort. Faster on simple tasks, higher-quality on complex tasks, costs more total person-hours.
Mob/ensemble programming: excels for complex, high-knowledge-transfer work.

Refactoring¶

Fowler's catalog (2nd ed.) tied to code smells.
Kent Beck's Tidy First? (2023): separate structural "tidyings" from behavioral changes as economic options.

Version Control and Branching¶

Commit Discipline¶

Atomic commits.
Conventional Commits: feat/fix/docs/chore/refactor/test — enables semantic-release and changelog automation.

Branching Strategies¶

Strategy	Best For	Key Rule
Trunk-Based Development	Most software, DORA-supported default	Integrate to trunk ≥ daily; ≤3 active branches; feature flags decouple deploy from release
GitFlow	Versioned/released software (mobile, embedded, on-prem)	Release branches for specific version cycles
GitHub Flow	Web apps with continuous delivery	One main + short-lived branches

DORA finding: "Elite performers who meet their reliability targets are 2.3 times more likely to use trunk-based development," in which "developers work in small batches and merge their work into a shared trunk frequently."

Advanced Git Tools¶

Merge queues (GitHub Merge Queue, GitLab Merge Trains): serialize integration at scale.
Stacked PRs (Graphite, ghstack): keep changes small.
Monorepo tooling: Nx, Turborepo, Bazel with affected-change detection.
Git internals: reflog, interactive rebase, cherry-pick, bisect for bug-finding.

Dependency Management¶

SemVer (MAJOR.MINOR.PATCH).
Lock files: pin transitive dependency trees; prevent the diamond dependency problem.
SCA/automation: Dependabot, Renovate, Snyk.
SBOMs (CycloneDX, SPDX): increasingly required by regulation (US EO 14028, EU Cyber Resilience Act).

Testing Strategy¶

Testing Pyramid Variants¶

Model	Shape	Best For
Classic pyramid (Cohn)	Many unit, fewer integration, fewest E2E	General software
Trophy (Dodds)	Integration-weighted	Modern JavaScript/React
Honeycomb (Spotify)	Service/integration-focused	Microservices
Ice-cream cone (anti-pattern)	E2E-heavy	Avoid — slow and flaky

Shift-left: move testing earlier. Shift-right: add production observability, chaos engineering, and A/B testing.

Unit Testing¶

Arrange-Act-Assert / Given-When-Then; test behavior, not implementation.
Test doubles: dummy/stub/spy/mock/fake — over-mocking couples tests to implementation.
Coverage: 80% is a heuristic, not a law; line/branch/path/mutation types.
Mutation testing (PIT, mutmut, Stryker): tests the tests themselves.
Property-based testing (Hypothesis, fast-check): auto-discovers edge cases.

Integration and Contract Testing¶

TestContainers: runs real dependencies (DBs, queues) in Docker — now the integration standard.
Consumer-driven contract testing (Pact): verifies service contracts without full E2E.
API contract validation: OpenAPI schema checks, Dredd, Schemathesis.
DB migration testing (Flyway/Liquibase/Alembic) in CI.

End-to-End Testing¶

Playwright (Microsoft): overtook Cypress as the default in mid-2024 — native cross-browser (Chromium/Firefox/WebKit), native parallelism/sharding, trace viewer; used by Amazon, Microsoft, Walmart.
Cypress: retains best in-browser/time-travel debugging DX for JS-centric SPA teams.
Selenium: persists in large/legacy/multi-language enterprises.
Use the Page Object Model; quarantine flaky tests rather than blanket auto-retry.
Visual regression: Chromatic, Percy, Playwright snapshots.

Performance Testing¶

k6: load-as-code, thresholds; good for CI integration.
Gatling: Scala, complex flows.
Locust: Python, distributed.
Performance gates and trend tracking belong in CI; profiling (async-profiler, py-spy, pprof) and flame graphs for root cause.

Security Testing¶

SAST: CodeQL, SonarQube, Semgrep, Checkmarx.
DAST: OWASP ZAP, Burp.
SCA: Dependabot, Trivy, Snyk.
Secrets scanning: gitleaks, detect-secrets, truffleHog, GitHub Secret Scanning.
IaC scanning: Checkov, tfsec, KICS.
Container scanning: Trivy, Grype.
OWASP Top 10 (2021) anchors training.
Threat modeling: STRIDE, DREAD, attack trees, PASTA.

CI/CD and DevOps¶

CI/CD Principles¶

CI: integrate to shared mainline ≥ daily; automated build + test; keep the build green (Andon-cord discipline — stop the line on red).
Pipeline ordering (fail-fast): lint → unit → build → integration → security → deploy.
Hermetic, reproducible builds (Docker multi-stage).
CD (Delivery): every commit is releasable.
CD (Deployment): every commit is released automatically.

Deployment Strategies¶

Feature flags: decouple deploy from release.
Rolling: gradual replacement.
Blue-green: instant switch between two environments.
Canary: metric-gated gradual rollout.
A/B testing: traffic split for experiments.
Dark launching: new code runs but results are not surfaced.
GitOps (Argo CD, Flux): Git as the source of truth for declarative desired state.

DORA Metrics (5 metrics as of 2025)¶

Deployment frequency: how often code is deployed to production.
Lead time for changes: time from commit to production.
Change failure rate: percentage of deployments causing production failures.
Failed deployment recovery time (formerly MTTR, redefined): time to recover from a change-caused failure.
Rework rate (added 2024): ratio of unplanned deployments caused by a production incident to total deployments.

2025 evolution: DORA replaced low/medium/high/elite tiers with seven team archetypes: - Harmonious High-Achievers (20%) - Pragmatic Performers (20%) - Constrained by Process (17%) - Stable and Methodical (15%) - Legacy Bottleneck (11%) - Foundational Challenges (10%) - High Impact/Low Cadence (7%)

Top two archetypes (~40%) share: strong platform engineering, small batches, and clear AI stance.

DevSecOps and Supply Chain Security¶

Supply-chain attacks roughly doubled in 2025 (Sonatype: 454,600+ new malicious packages, 99% in npm).

Regulatory mandates: US EO 14028, EU Cyber Resilience Act — both mandate SBOMs and provenance.

Key standards and tools: - SLSA (Supply-chain Levels for Software Artifacts): provenance/build integrity, levels 1–3+. Level 2 + Sigstore signing is achievable on GitHub Actions/GitLab CI in 1–2 days. - Sigstore: keyless signing via Cosign/Fulcio + Rekor transparency log. - in-toto attestations. - NIST SSDF (SP 800-218), OWASP SAMM, BSIMM — measure program maturity.

Code Quality and Tech Debt¶

Key Metrics¶

Cyclomatic complexity (McCabe): concern threshold ~10–15.
Cognitive complexity (SonarSource): better proxy for comprehensibility than cyclomatic.
Duplication: jscpd, Simian, SonarQube.
Coupling/cohesion: afferent/efferent, instability metric.
LCOM: lack of cohesion of methods.

Tech Debt Management¶

Fowler's quadrant: deliberate/inadvertent × reckless/prudent.
SonarQube SQALE method: quantifies debt ratio.
Manage via ~20% capacity allocation, debt as first-class backlog items.
Boy Scout Rule: leave code cleaner than you found it.
Strangler Fig pattern: for legacy modernization.
Feathers's Working Effectively with Legacy Code: characterization tests, seam identification.

Code Review Culture¶

Automate style/lint/security checks; reserve humans for design, logic, and intent.
Keep PRs <400 LOC and review SLAs short — review lag is a measurable productivity drag.
Psychological safety: non-personal feedback is prerequisite for effective review culture.

Release and Operations¶

Versioning and Releases¶

SemVer (MAJOR.MINOR.PATCH) automated via semantic-release/release-please.
Changelogs generated from Conventional Commits.
Release trains vs. continuous delivery; feature freezes signal either genuine stabilization needs or accumulated debt.

Database Change Management¶

Tools: Flyway, Liquibase, Alembic, golang-migrate.
Expand-contract pattern: for zero-downtime schema changes.

Incident Management¶

Blameless postmortems: 5 Whys, timeline reconstruction.
Severity levels: P0–P4 with response SLAs.
Error budgets and SLI/SLO/SLA hierarchy (SRE).
Chaos engineering: Chaos Monkey, AWS FIS, Azure Chaos Studio.
Sustainable on-call rotations with runbooks and escalation paths.

Observability¶

Three (Plus One) Pillars¶

Metrics: time-series measurements; SLO-based/burn-rate alerting.
Logs: structured logging (JSON, correlation IDs).
Traces: distributed request tracing; W3C TraceContext propagation.
Continuous profiling (fourth pillar, emerging).

OpenTelemetry (OTel)¶

The unified, vendor-neutral CNCF graduated standard (OTLP, semantic conventions, 90+ vendors). Spans traces/metrics/logs; profiling as a fourth signal. Replaces per-vendor agents.

Alerting Philosophy¶

Symptom-based alerting over cause-based — alert on user-visible impact, not internal indicators.
Error tracking (Sentry, Rollbar, Bugsnag) integrated into the SDLC.
Feature-flag-driven gradual rollouts double as observability tools.

AI-Assisted Development (2024–2026)¶

Evidence Summary¶

The evidence is mixed and important — do not apply AI tooling uncritically.

Study	Finding
DORA 2024	AI adoption correlated with −1.5% throughput, −7.2% stability per 25% adoption increase; larger batch sizes were the cause.
DORA 2025	AI now correlates positively with throughput (reversed), but instability remains negative. AI is a "mirror and multiplier" — amplifies existing strengths or dysfunctions.
METR RCT (July 2025)	Experienced developers were 19% slower with AI on familiar codebases, despite forecasting a 24% speedup.
Veracode 2025	45% of AI-generated code introduced a detectable OWASP Top 10 vulnerability; XSS failed 86% of the time.
Stack Overflow 2025	84% adoption; trust in AI accuracy fell from 40% to 29%. Biggest frustration (66%): "AI solutions that are almost right, but not quite."

DORA AI Capabilities Model (7 foundational capabilities)¶

Clear and communicated AI stance
Healthy data ecosystems
AI-accessible internal data
Strong version control practices
Working in small batches
User-centric focus
Quality internal platforms

Production Guidance¶

Spec-driven development (GitHub Spec-Kit, Amazon Kiro) has replaced "vibe coding" for production work.
"Vibe coding" (Karpathy, Feb 2025) is appropriate for prototyping, dangerous for production.
The "90% problem": AI reaches 90% quickly; the last 10% (debugging, integration, edge cases) is where human expertise is decisive.
Gate AI-generated code through the same SAST/secrets/SCA pipeline as human-written code.
Intensify (do not relax) testing when using AI-assisted development.
If instability/rework rate climbs after AI rollout: slow AI adoption and fix the testing/review pipeline first.

AI Code Review Tools¶

CodeRabbit: breadth and precision.
Greptile: deep-context recall (~82% catch rate in independent benchmark).
GitHub Copilot code review: zero-friction GitHub integration.
False positives remain the #1 complaint — tune aggressively for the "cry wolf" problem.

Team Structures¶

Feature vs. component teams: cross-functional, stream-aligned teams reduce cognitive load.
Team Topologies (Skelton & Pais): Stream-Aligned, Platform, Enabling, Complicated-Subsystem; three interaction modes (Collaboration, X-as-a-Service, Facilitating).
"You build it, you run it" (Werner Vogels / Amazon): ties ownership to on-call, changes development behavior.
Platform engineering / IDPs: Gartner forecasts 80% of large software-engineering organizations will have platform teams by 2026 (up from 45% in 2022).

Key Evidence and Caveats¶

The speed-quality "tradeoff" is largely a myth: a decade of DORA data shows throughput and stability move together in elite organizations — quality practices accelerate delivery over the medium term.
DORA is correlation, not causation: survey-based correlations; do not use as cross-org benchmarks.
METR 19%-slowdown result: small (16-developer) RCT on experienced devs working on familiar, large codebases — does not generalize to greenfield work or junior developers.
Vendor benchmarks for AI code-review tools are self-serving: treat single-vendor claims skeptically.
Coverage targets and "more process" are weakly supported by research — flow metrics and small batch sizes have the most robust evidence.

Plugin: engineering-process · View SKILL.md on GitHub