SDLC Process

Every customer-facing change at Media Tech moves through the same six phases. The phases exist so that the work product at each stage is observable, reviewable, and ready for whoever owns the next phase. Skipping a phase is allowed only when the project sponsor signs off in writing.

Phase 1 — Idea

Someone proposes a change. The proposal lands in monday.com as a draft Requirement Specification stub: a one-paragraph problem statement, the user group affected, and a guess at scope. No estimates, no design, no commitments yet. The PM owns reviewing the stub within five working days and either accepting it into the pipeline, sending it back with questions, or declining with a written reason.

Phase 2 — Specification

Accepted ideas become full Requirement Specifications using our ten-section format (see developer/requirements-specification). Specs for visual features are drafted with AI assistance from screenshots, videos, or Figma frames — the human then verifies and edits. Each spec gets a unique ID, a primary owner, a list of stakeholders, and a "ready for build" checkbox that only the PM can tick.

Gate to Phase 3: spec is signed off by the PM, the assigned developer has reviewed it, and any legal or compliance flags (GDPR data flows, EU AI Act classification) have been resolved.

Phase 3 — Build

Implementation happens on a short-lived feature branch (see developer/git-workflow). The assigned developer is Responsible; the QA Lead is Consulted. Build phase produces: code, technical test cases (developer/test-cases-technical), and a draft release-notes entry following the user-facing template (developer/release-notes).

Gate to Phase 4: code review approved (developer/code-review), all linked tickets closed, technical tests passing in CI.

Phase 4 — Test

QA picks up using functional test cases (developer/test-cases-functional) generated for the feature. Testers are non-technical by design — they follow checklists, capture screenshots of any deviation, and log bugs back to the developer. A feature is "test-done" when every checklist item is either passing or has a triaged exception.

Gate to Phase 5: functional tests passing, no unresolved Severity 1 or 2 bugs, release notes finalised.

Phase 5 — Release

The feature ships to production on the next release cadence — typically every two weeks for SPYN mobile and weekly for SPYN backend. Release notes are published per developer/release-notes. The deploy is gated on Compliance approval if the release affects customer-visible behaviour or regulated data flows.

Gate to Phase 6: deploy successful, release notes published, customer-success briefed for customer-facing changes.

Phase 6 — Monitor

Post-release, the feature is observed for at least one full release cycle. Operational metrics, error rates, and user feedback feed back into the requirement spec as appendices. Anomalies trigger a corrective-action entry against the original spec — closing the loop into the next Idea phase.

CMMI Level 2 alignment

The six phases map onto CMMI Level 2 process areas: REQM and PP own Phases 1–2; PMC owns ongoing tracking across Phases 3–6; CM is enforced through git and the configuration management plan; PPQA is enforced through the gates. See pm/cmmi-level-2 for the artifact-per-process-area mapping.

Owned by

Engineering Leadership. Audited by the Master skill on a 90-day cadence.