Skip to content
RFsoftLab

CMMI Level 3 and ALM Traceability: Making Software Delivery Auditable

Process maturity and tooling reinforce each other. See what CMMI Level 3 asks of a software team and how an ALM platform makes traceability a by-product of daily work.

By RFsoftLab Team, IT Governance · · Updated · 4 min read

RFsoftLab cover: CMMI Level 3 and ALM traceability

Organisations that build software for regulated or mission-critical clients are often asked two questions: how mature is your process, and can you show how a requirement became a release? CMMI answers the first; application lifecycle management (ALM) tooling helps answer the second.

What CMMI Level 3 means

CMMI (Capability Maturity Model Integration) is a framework for improving how organisations work. At maturity level 3, often called "defined", the organisation has standard processes that are documented, tailored for each project and applied consistently. The contrast is with lower levels, where success depends heavily on individual heroics or each project invents its own way of working.

In practical terms, a team operating at this level can typically show:

  • Defined processes for requirements, design, build, verification, validation, configuration and risk management, with guidance on how projects tailor them.
  • Project planning and monitoring that tracks scope, effort and risks against a plan.
  • Peer review and verification as ordinary practice, not as a final gate.
  • Configuration management so anyone can tell exactly what was built and from which sources.
  • Measurement that feeds improvement, with lessons shared across projects.
  • Training so people know the standard processes.

An appraisal checks evidence that these practices are actually used. A certificate with no habits behind it is a risk, so treat appraisal as a result of working well rather than the goal.

The role of traceability

Traceability links artefacts across the lifecycle:

requirement, design element, code change, test case, test result, defect, release.

With it you can answer questions that otherwise cost days: Which requirements does this release satisfy? What tests cover this requirement? If this requirement changes, which components and tests are affected? Why was this code changed? Auditors and clients value these answers, and so do engineers doing impact analysis.

How ALM tools help

Polarion ALM manages requirements, tasks, test cases and documents in one repository with configurable workflows, linked work items and reports. Teams use it to author specifications as living documents, link them to tests and tasks, and generate coverage and status reports without manual spreadsheets.

StarTeam has long been used for configuration management and change control, with requirement, task and change-request tracking tied to versioned files. In several long-running banking engagements it has provided the backbone for controlled change.

The tools differ in emphasis, and we are platform-agnostic: the right choice depends on what you already run, your regulatory context and how your teams work. In both cases the value comes from configuration, discipline and workflow design, not from the licence.

Setting up traceability that people will actually keep

  1. Model the lifecycle first. Decide which artefact types you have and how they link before configuring any tool.
  2. Keep the link rules simple. Every change request references a requirement or defect; every test references a requirement. Enforce this through workflow rather than reminders.
  3. Make linking part of the work. If links are created at the time of writing, they cost seconds. Reconstructing them at audit time costs weeks.
  4. Define baselines. Freeze and name the set of artefacts that make up each release so it can be reproduced.
  5. Report from the tool. Coverage, open changes and release content should come from queries, not from slide decks.
  6. Review metrics sensibly. Track things such as requirements without tests or changes without approval, but avoid targets that encourage box-ticking.

Agile and CMMI

Short iterations and defined processes are compatible. Two-week sprints can carry planning, review, retrospectives and definition-of-done checks that map onto model practices. The key is to keep evidence light and automatic: backlog items with acceptance criteria, linked tests, reviewed pull requests and tracked decisions.

A phased approach

Start by assessing current practice against the model. Pick the practice areas that matter most to your clients, define and pilot standard processes on one project, add the tooling support and then extend to other teams. Expect it to take sustained effort and leadership attention, because it changes behaviour as well as documents.

When process and tools are aligned, audits become uneventful and delivery becomes more predictable, which is exactly what clients in regulated sectors are paying for.

Frequently asked questions

Does CMMI require a specific methodology such as waterfall?
No. CMMI describes what good practice areas should achieve, not one method. Teams use agile, iterative or plan-driven approaches and show how their practices meet the model.
Do we need an ALM tool to follow CMMI?
Not strictly, but traceability across requirements, changes, tests and releases is hard to sustain manually. An ALM tool makes it routine.
CMMIALMPolarionStarTeamtraceability

Start a conversation

Tell us what you need. We reply within one business day.

Share a few details and a senior member of our team will come back with questions, matched profiles or a proposed approach. NDA available on request.

  • Reply within one business day
  • NDA signed before you share details
  • Speak directly with a senior architect or engineer

Prefer to share a detailed brief? Use the full project form or explore the talent catalogue.

Confidential. Your details are used only to respond to this enquiry.

WhatsApp
+33 6 22 72 44 13