Deep
Understands edge cases and can teach it.
Skill libraryPermissions Academic Professional
Developerskills/developer/sdlc-process/SKILL.md
SDLC Process
Our end-to-end software development lifecycle — idea through production — with explicit gates between phases and CMMI Level 2 alignment.
Open
Any editor can update. Vera routes questions to any team member with relevant expertise.
Owner: Ahmed Mahmood Khan
You can read, edit and deprecate this skill.
Led
Has done it independently and owned outcomes.
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 Castline mobile and weekly for Castline 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.