A practical, step-by-step guide to understanding, assessing, implementing, and continuously improving software engineering processes using 10 industry-recognized maturity frameworks.

A software development team can deliver releases every week and still struggle to explain why production defects occur. Another organization may maintain hundreds of process documents but have no reliable way to measure whether those processes actually improve quality.

The difference is not simply documentation, automation, or development methodology. It is process capability and maturity: the ability to produce reliable outcomes consistently, manage risks, learn from failures, and improve performance.

Frameworks such as Automotive SPICE (ASPICE), SPICE, CMMI, ISO/IEC 330xx, TMMi, and IT-CMF provide structured approaches to evaluating these capabilities.

Some concentrate on automotive engineering. Others assess organizational performance, software testing, medical device development, cybersecurity, or enterprise IT management.

Understanding their differences is essential because selecting the wrong framework can lead to unnecessary documentation, ineffective assessments, and substantial investment without meaningful improvement.

This guide explains all 10 frameworks, their maturity models, assessment approaches, practical implementation steps, evidence requirements, real-world applications, and relationships with Agile, DevOps, and DevSecOps.

---

1. Understanding Software Process Improvement and Maturity

Software Process Improvement (SPI) is the systematic practice of evaluating and improving the processes used to develop, test, deliver, operate, and maintain software and software-intensive systems.

Its purpose is not simply to introduce more procedures. Effective SPI makes engineering activities more predictable, measurable, efficient, and dependable.

What is process capability?

Process capability describes how reliably an individual process achieves its intended purpose.

For example, consider a software requirements management process.

An organization with weak capability might record requirements inconsistently, approve changes informally, and lose traceability between requirements and tests.

A more capable organization would establish a repeatable process for documenting requirements, reviewing changes, managing baselines, verifying implementation, and demonstrating that intended outcomes are achieved.

What is process maturity?

Process maturity describes how systematically an organization establishes, manages, measures, and improves its practices across a defined scope.

Capability and maturity are related, but they are not interchangeable.

An organization may have excellent automated testing while maintaining weak project management or change control.

Similarly, one development team may have highly capable engineering practices even though those practices are not adopted consistently across the organization.

The five questions every maturity assessment should answer

1. Are we performing the necessary activities? Determine whether required process outcomes are achieved.
2. Are those activities controlled? Examine ownership, planning, monitoring, and work-product management.
3. Are practices repeatable? Check whether successful outcomes depend on individuals or established organizational processes.
4. Can performance be measured and predicted? Evaluate quantitative measurement and process stability.
5. Do we improve systematically? Determine whether organizational learning produces sustained improvements.

These questions form a useful starting point, even though individual frameworks apply different definitions, assessment models, and rating rules.

---

2. Overview of the 10 Software Process Maturity Frameworks

Framework	Primary purpose	Best suited for	Assessment approach
ASPICE	Evaluate automotive development process capability	Automotive OEMs, Tier suppliers, embedded engineering	Process-level capability
SPICE	Improve and determine process capability	Software and systems engineering	Process-level capability
CMMI	Improve organizational performance and maturity	Software, services, suppliers, enterprise organizations	Capability and maturity
ISO/IEC 330xx	Standardize process assessment models and methods	Cross-industry process assessment	Standards-based capability and maturity assessment
ISO/IEC 15504	Historical foundation of SPICE assessments	Legacy assessments and migration	Legacy capability assessment
Automotive SPICE for Cybersecurity	Assess automotive cybersecurity engineering processes	Automotive cybersecurity teams and suppliers	Cybersecurity process capability
MDevSPICE	Evaluate medical device software processes	Medical device software manufacturers	Domain-specific process capability
TMMi	Improve organizational software testing maturity	QA, testing, and quality engineering teams	Staged test maturity
TPI NEXT	Identify and prioritize test process improvements	Testing teams and organizations	Key-area maturity assessment
IT-CMF	Improve enterprise IT capability and business value	CIOs, IT leadership, enterprise technology functions	Capability-based maturity assessment

An important distinction is that these are not all independent alternatives.

SPICE is the broader process-assessment approach; ISO/IEC 330xx provides its modern international standards foundation; ASPICE applies related principles to automotive development.

CMMI, TMMi, TPI NEXT, MDevSPICE, and IT-CMF address different, sometimes overlapping improvement objectives.

Organizations can combine selected frameworks when there is a clear business justification.

---

3. How Capability Levels and Maturity Levels Work

Many frameworks use numbered levels to represent increasing process capability or maturity.

However, a Level 3 result in ASPICE is not automatically equivalent to CMMI Maturity Level 3 or TMMi Level 3.

The assessment unit, required practices, evidence, and aggregation rules differ.

Automotive SPICE process capability levels

Automotive SPICE 4.1 identifies six levels numbered 0 through 5.

Level	Name	Meaning
0	Incomplete	The process is missing or does not achieve its purpose
1	Performed	The process achieves its intended purpose
2	Managed	Activities and resulting work products are planned, monitored, and controlled
3	Established	A defined process is implemented consistently
4	Predictable	Quantitative analysis and control support predictable performance
5	Innovating	The process is continually improved through systematic innovation

These levels apply to assessed processes, not automatically to an entire company.

Process attribute rating scale

Automotive SPICE uses process attribute ratings with four categories:

Rating	Meaning	Achievement range
N	Not achieved	0–15%
P	Partially achieved	Above 15% through 50%
L	Largely achieved	Above 50% through 85%
F	Fully achieved	Above 85% through 100%

The percentages describe the degree of process attribute achievement. They are not a formula for counting completed documents or checklist items.

Assessors evaluate evidence and apply the model’s rating and aggregation rules.

For example, to achieve Automotive SPICE Capability Level 3, the Level 1 and Level 2 process attributes must be fully achieved, while the two Level 3 attributes must be largely or fully achieved.

CMMI maturity is different

CMMI provides maturity levels for an organization’s appraised scope and capability levels for individual practice areas.

Its maturity scale includes:

• Level 0 — Incomplete
• Level 1 — Initial
• Level 2 — Managed
• Level 3 — Defined
• Level 4 — Quantitatively Managed
• Level 5 — Optimizing

CMMI’s individual practice-area capability levels run from 0 through 3.

These differences are fundamental when comparing assessment results.

---

4. Automotive SPICE (ASPICE): Complete Implementation Tutorial

What is Automotive SPICE?

Automotive SPICE is an automotive-specific Process Reference Model (PRM) and Process Assessment Model (PAM), maintained by the German Association of the Automotive Industry’s Quality Management Center (VDA QMC).

It evaluates how effectively organizations develop software-intensive automotive systems.

Automotive SPICE is particularly relevant to companies developing vehicle control units, embedded software, electronic systems, automotive middleware, hardware components, and machine-learning-enabled automotive functions.

The Automotive SPICE 4.1 model extends beyond traditional software development and includes system engineering, hardware engineering, machine learning, validation, management, and supporting processes.

Version 4.1 updates the preceding model with editorial refinements and a change to the machine-learning architecture process.

Important ASPICE terminology

Process Reference Model (PRM): Defines the purposes and expected outcomes of processes.

Process Assessment Model (PAM): Provides indicators for assessing process performance and capability.

Base Practices (BP): Activities used as indicators of process performance.

Generic Practices (GP): Practices supporting the assessment of capability attributes.

Information Items: Types of process-related or product-related information that may provide objective evidence.

Capability Level (CL): The assessed capability of a process.

Important Automotive SPICE processes

Process	Purpose	Example evidence
SYS.2	System Requirements Analysis	Approved system requirements
SYS.3	System Architectural Design	System architecture and interface definitions
SWE.1	Software Requirements Analysis	Software requirements and traceability
SWE.2	Software Architectural Design	Software architecture documentation
SWE.3	Software Detailed Design and Unit Construction	Detailed design and source code
SWE.4	Software Unit Verification	Unit verification results
SWE.5	Software Component Verification and Integration Verification	Component and integration verification results
SWE.6	Software Verification	Software verification evidence
VAL.1	Validation	Validation procedures and results
SUP.1	Quality Assurance	Quality assurance findings and follow-up
SUP.8	Configuration Management	Baselines and configuration records
SUP.9	Problem Resolution Management	Defect and problem records
SUP.10	Change Request Management	Change analysis and approval records
MAN.3	Project Management	Project plans, tracking, and corrective actions
MAN.5	Risk Management	Project risk records and mitigation tracking

The full model also includes acquisition, supply, hardware, machine learning, measurement, process improvement, and reuse processes.

The applicable assessment scope should be chosen according to project responsibilities, customer expectations, and the assessment method.

Step-by-step ASPICE implementation

Step 1: Define the scope

Determine which engineering activities are performed by the organization.

For example, a supplier developing embedded software but not designing the underlying hardware should not automatically assume that every hardware development process is applicable.

Identify customer-specific requirements and the required assessment scope.

Step 2: Perform an initial gap assessment

Evaluate the selected processes against the official PAM.

Ask questions such as:

• Are software requirements documented, reviewed, and maintained?
• Is architecture consistent with requirements?
• Are unit verification activities defined and executed?
• Are defects linked to the affected software versions?
• Can configuration baselines be reconstructed?
• Is project progress monitored against plans?

Record strengths, weaknesses, evidence, and unresolved questions.

Step 3: Establish process ownership

Assign accountable owners to requirements engineering, architecture, implementation, verification, configuration management, change management, and quality assurance.

Process ownership should include authority to improve the process, not simply responsibility for maintaining documents.

Step 4: Implement traceability

Establish links between requirements, architecture, implementation, verification, and defects.

Consider the following example:

Artifact	Identifier
System requirement	SYS-REQ-017
Software requirement	SW-REQ-024
Architecture component	SW-ARCH-006
Implementation change	COMMIT-8A41
Unit verification	UT-031
Software verification	SV-012
Defect record	DEF-009

The objective is to demonstrate that requirements are implemented appropriately and verified using suitable evidence.

Step 5: Introduce configuration and change controls

Establish controlled baselines for relevant artifacts.

A release baseline may identify:

• Approved requirements
• Design revisions
• Source code commit
• Build configuration
• Toolchain information
• Verification results
• Open defects and dispositions
• Release approval

Step 6: Collect evidence during normal development

Evidence should be created through actual engineering activities rather than manufactured immediately before an assessment.

Configuration records, review outcomes, verification results, and change decisions should be available as part of ordinary project execution.

Step 7: Perform an internal assessment

Select representative projects and examine process performance.

Interview engineers, inspect work products, and compare implementation against the model.

Do not assign formal capability ratings through a simplistic checklist or document-counting formula.

Step 8: Improve and reassess

Prioritize findings based on product risk, process weakness, and business value.

Implement corrective actions and verify their effectiveness using subsequent project evidence.

ASPICE implementation example

A vehicle software team repeatedly experiences regressions after integration.

Investigation identifies three problems: incomplete interface definitions, inconsistent integration verification, and uncontrolled configuration changes.

The organization improves SWE.2, SWE.5, and SUP.8 by establishing reviewed interface specifications, repeatable integration verification procedures, and reproducible release baselines.

The team then measures integration failures, repeat defects, and time spent reproducing failures.

This is meaningful process improvement: engineering outcomes improve because the underlying process weaknesses are addressed.

Key lesson: ASPICE is an assessment and improvement model, not a mandatory waterfall development lifecycle. Agile and iterative engineering practices can be assessed when they achieve the relevant process outcomes.

Official reference: VDA QMC Automotive SPICE publications.

---

5. SPICE: Software Process Improvement and Capability Determination

What is SPICE?

SPICE stands for Software Process Improvement and Capability dEtermination.

It originated as an international initiative to establish systematic approaches to assessing software development processes.

Its scope subsequently expanded beyond software development into systems engineering and other process domains.

SPICE influenced the ISO/IEC 15504 family, whose core process-assessment standards have largely been superseded by the ISO/IEC 330xx family.

Unlike ASPICE, SPICE is not restricted to automotive engineering.

How SPICE assessments work

A SPICE-style assessment typically considers two dimensions.

Process dimension: Which processes are assessed, and what outcomes are expected?

Capability dimension: How effectively are those processes performed and managed?

The assessment model connects these dimensions so assessors can evaluate objective evidence and derive process capability results.

Step-by-step SPICE implementation

Step 1: Select the process domain

Identify whether the assessment concerns software development, systems engineering, IT services, or another defined domain.

Choose an appropriate process reference and assessment model.

Step 2: Identify critical processes

For a software product company, the initial scope might include requirements engineering, project management, development, testing, change management, and problem resolution.

Step 3: Establish assessment criteria

Use the selected model’s defined purposes, outcomes, indicators, and capability measurement rules.

Do not invent custom maturity-level definitions and present them as standardized SPICE ratings.

Step 4: Collect objective evidence

Examine project records, work products, actual process execution, and interviews.

For example, a software team may demonstrate requirements management through approved requirements, change history, reviews, and links to verification results.

Step 5: Determine gaps and prioritize improvements

Identify whether a process fails to achieve outcomes, operates without sufficient control, or lacks consistent organizational deployment.

Step 6: Repeat assessments

Reassess after improvements have been deployed and used long enough to produce meaningful evidence.

Example: Improving an API development process

A company delivers APIs but frequently introduces breaking changes.

Its assessment identifies weak interface change management and insufficient regression verification.

The improvement program introduces API contract reviews, compatibility checks, version-control policies, and automated regression testing.

Performance is measured using the number of unintended breaking changes, customer-reported integration incidents, and the time required to resolve them.

SPICE provides the assessment logic for understanding the process weakness and evaluating whether improvement has occurred.

Key lesson: SPICE is an approach and historical family of models. A conformant assessment must identify the specific applicable reference model, assessment model, measurement framework, and method.

Official reference: intacs SPICE Center.

---

6. CMMI: Capability Maturity Model Integration

What is CMMI?

CMMI is a performance and process improvement model maintained by ISACA through the CMMI Institute.

It helps organizations build, assess, and improve capabilities that affect quality, delivery, cost, productivity, and business performance.

CMMI is broader than software engineering alone.

CMMI V3.0 includes domains addressing development, services, suppliers, security, safety, data management, people management, and virtual work.

Organizations can select relevant model content according to their business context.

Understanding CMMI maturity levels

Maturity level	Description	Practical example
1 — Initial	Performance depends heavily on reactive practices	Teams solve delivery problems individually
2 — Managed	Work is planned, performed, measured, and controlled	Projects establish plans and track commitments
3 — Defined	Organizational practices are established and tailored	Teams apply approved organizational standards
4 — Quantitatively Managed	Performance is managed using quantitative techniques	Predictive performance analysis supports decisions
5 — Optimizing	Continuous improvement is systematically pursued	Performance analysis drives organizational innovation

CMMI maturity appraisals have defined requirements. An organization cannot establish an official maturity level simply by selecting a number from this table.

Step-by-step CMMI adoption

Step 1: Define business objectives

Begin with problems that matter.

Examples include unpredictable delivery dates, excessive defects, weak supplier performance, and inconsistent engineering quality.

Translate these problems into measurable improvement objectives.

Step 2: Select applicable domains and practice areas

Choose the CMMI content relevant to the organization’s products, services, risks, and business strategy.

Avoid assessing unrelated capabilities solely to increase the scope of the improvement program.

Step 3: Evaluate current performance

Review actual project performance and existing practices.

Assess planning, execution, governance, measurement, quality, risk management, and organizational learning as appropriate.

Step 4: Create an improvement program

Introduce practices that address identified weaknesses.

Examples include consistent project planning, structured risk management, quality assurance, causal analysis, and performance measurement.

Step 5: Institutionalize the improvements

Train relevant employees and establish process ownership.

Ensure practices are applied across the intended organizational scope and tailored appropriately to individual projects.

Step 6: Measure results

Use performance measures connected to business objectives.

Examples include delivery predictability, defect escape trends, rework effort, and customer satisfaction.

Step 7: Conduct an appropriate appraisal

CMMI supports different appraisal types, including:

• Evaluation: A flexible appraisal for understanding improvement opportunities.
• Benchmark: A formal appraisal used to evaluate organizational capability and performance.
• Sustainment: An appraisal assessing whether a previously achieved level is maintained.
• Action Plan Reappraisal: A defined follow-up approach under the appraisal method.

For official appraisal outcomes, organizations should follow the applicable ISACA appraisal policies and work with appropriately qualified professionals.

CMMI implementation example

A software services organization frequently misses customer delivery commitments.

An internal evaluation reveals inconsistent estimation, weak risk escalation, and limited organizational reuse of project knowledge.

The organization establishes a common estimation approach, project monitoring, escalation criteria, and retrospective improvement process.

It monitors delivery variance and analyzes the causes of missed commitments.

Over time, the company can evaluate whether these practices produce more consistent delivery outcomes across projects.

Key lesson: CMMI maturity measures organizational process capability and performance within an appraised scope. It is not equivalent to an individual ASPICE process capability rating.

Official references: CMMI Institute and CMMI appraisal levels.

---

7. ISO/IEC 330xx: The International Process Assessment Standards Family

What is ISO/IEC 330xx?

ISO/IEC 330xx is a family of international standards addressing process assessment.

It provides terminology, requirements, measurement frameworks, and models used to conduct systematic assessments.

It is not a single software development methodology or one universal certification scheme.

The standards help organizations establish assessments that are objective, consistent, repeatable, and relevant to process improvement.

Important ISO/IEC 330xx standards

Standard	Primary focus
ISO/IEC 33001	Process assessment concepts and terminology
ISO/IEC 33002	Requirements for performing process assessments
ISO/IEC 33003	Requirements for process measurement frameworks
ISO/IEC 33004	Requirements for process reference, assessment, and maturity models
ISO/IEC 33020	Measurement framework for process capability
ISO/IEC TS 33060	Assessment model for systems life cycle processes
ISO/IEC TS 33061	Assessment model for software life cycle processes
ISO/IEC TS 33062	Quantitative process assessment model supporting higher capability levels
ISO/IEC TS 33064	Assessment model for safety processes

The applicable edition and status of each standard should be verified before use.

Step-by-step ISO/IEC 330xx assessment

Step 1: Define the assessment purpose

Determine whether the objective is internal process improvement, supplier evaluation, risk assessment, or capability benchmarking.

Step 2: Select the appropriate reference and assessment models

Choose models suited to the processes under assessment.

Step 3: Establish the measurement framework

Identify the capability attributes, rating scale, and aggregation rules.

Step 4: Define assessment inputs

Specify the organizational unit, assessment scope, applicable processes, participants, assessment method, and available evidence.

Step 5: Perform the assessment

Collect and validate evidence, evaluate process outcomes and attributes, and record findings according to the selected method.

Step 6: Prepare the assessment report

Report process capability results, evidence limitations, strengths, weaknesses, and improvement opportunities.

Step 7: Convert findings into improvement actions

Create accountable corrective actions and evaluate their effectiveness.

Example: Assessing a software engineering organization

A company wants to evaluate its software lifecycle processes independently of automotive-specific models.

It selects the appropriate ISO/IEC software lifecycle assessment model and ISO/IEC 33020 measurement framework.

The assessment examines requirements management, implementation, verification, change management, and related processes within the agreed scope.

The resulting process profiles help the organization identify capability weaknesses and prioritize improvements.

Key lesson: ISO/IEC 330xx supplies standardized assessment foundations. Domain-specific models determine which engineering processes and outcomes are relevant.

Official references: ISO/IEC 33000 family and ISO/IEC 33020.

---

8. ISO/IEC 15504: Legacy SPICE Standards and Migration

What is ISO/IEC 15504?

ISO/IEC 15504 was the internationally recognized series associated with SPICE process assessment.

It supported the evaluation of process capability and the use of assessment results for process improvement.

The foundational ISO/IEC 15504 standards have been withdrawn and superseded by standards in the ISO/IEC 330xx family.

This distinction matters because older assessment reports, training materials, supplier contracts, and internal process documents may still reference ISO/IEC 15504.

Understanding the migration

Legacy reference	Modern reference or relevant successor
ISO/IEC 15504-1	ISO/IEC 33001
ISO/IEC 15504-2	ISO/IEC 33002, 33003, 33004, and 33020
ISO/IEC 15504-3	ISO/IEC TS 33030
ISO/IEC 15504 software assessment models	Relevant ISO/IEC 330xx software assessment models
ISO/IEC 15504 systems assessment models	Relevant ISO/IEC 330xx systems assessment models

This is a conceptual migration map, not a claim that all old requirements have identical wording or direct one-to-one replacements.

Step-by-step legacy migration

Step 1: Inventory references

Search process manuals, training material, assessment reports, supplier requirements, and audit checklists for ISO/IEC 15504 references.

Step 2: Identify the actual assessment requirements

Determine which legacy documents contain normative requirements, assessment indicators, and internal procedures.

Step 3: Select appropriate successor standards

Verify the current standards and editions that apply to the intended assessment.

Step 4: Perform a requirements comparison

Identify changes in terminology, model requirements, measurement rules, and assessment procedures.

Step 5: Update internal procedures

Revise assessment methods, policies, and supporting templates where necessary.

Step 6: Train assessors and process owners

Ensure that employees understand the updated model and how existing evidence should be evaluated.

Step 7: Validate the transition

Conduct an assessment using the selected contemporary framework and determine whether additional corrective actions are required.

Key lesson: ISO/IEC 15504 remains important for understanding the history of SPICE and interpreting older assessment records, but new programs should normally begin with the applicable current ISO/IEC 330xx standards.

Official reference: ISO/IEC 15504-1 status and successor.

---

9. Automotive SPICE for Cybersecurity

What is Automotive SPICE for Cybersecurity?

Automotive SPICE for Cybersecurity extends automotive process assessment to cybersecurity engineering activities.

Its objective is to evaluate whether relevant cybersecurity development processes are systematically performed and managed.

The Automotive SPICE for Cybersecurity 2.0 model introduces cybersecurity-related process content, complementing the broader Automotive SPICE assessment model.

The cybersecurity extension is relevant to automotive organizations developing connected vehicle systems, vehicle communication interfaces, software update functionality, and other security-sensitive electronic systems.

It also supports process-related evaluation of supply-chain cybersecurity activities.

Automotive cybersecurity assessment processes

Process	Focus
MAN.7	Cybersecurity Risk Management
SEC.1	Cybersecurity Requirements Elicitation
SEC.2	Cybersecurity Implementation
SEC.3	Risk Treatment Verification
SEC.4	Risk Treatment Validation

The assessment also considers relevant relationships with other automotive engineering and management processes.

Relationship with ISO/SAE 21434 and UNECE R155

Automotive SPICE for Cybersecurity is complementary to automotive cybersecurity engineering requirements and regulations.

ISO/SAE 21434 addresses cybersecurity engineering for road vehicles.

UNECE R155 establishes regulatory requirements relating to vehicle cybersecurity and cybersecurity management systems in applicable markets.

A cybersecurity SPICE assessment does not automatically demonstrate full compliance with ISO/SAE 21434 or UNECE R155.

These frameworks serve related but different purposes.

Step-by-step cybersecurity implementation

Step 1: Identify cybersecurity-relevant systems

Define the item or component, its interfaces, assets, environment, and relevant lifecycle responsibilities.

Step 2: Perform threat analysis and risk assessment

Identify threats, attack scenarios, cybersecurity risks, and appropriate risk treatment decisions.

A Threat Analysis and Risk Assessment (TARA) is a common automotive cybersecurity engineering activity.

Step 3: Establish cybersecurity requirements

Translate applicable risk treatment decisions and stakeholder needs into requirements.

Requirements should be reviewed, traceable, and suitable for subsequent verification.

Step 4: Implement cybersecurity controls

Develop relevant hardware, software, architectural, and operational security measures.

Examples include authenticated communication, secure boot, software integrity verification, and access control.

Step 5: Verify risk treatment

Define and execute verification measures demonstrating that the selected treatments have been implemented appropriately.

Step 6: Validate cybersecurity objectives

Evaluate whether cybersecurity goals and risk treatment objectives are achieved in the intended system context.

Step 7: Maintain cybersecurity evidence

Preserve threat analysis records, decisions, requirements, design information, verification results, validation evidence, and change history.

Example: Secure automotive firmware updates

Consider a vehicle ECU that accepts remotely delivered firmware updates.

A threat analysis identifies the possibility of unauthorized firmware installation.

The engineering team establishes a requirement that firmware authenticity and integrity be verified before installation.

The design introduces cryptographic signature verification.

Verification activities test correctly signed, incorrectly signed, modified, and otherwise invalid update packages.

The team also evaluates the broader cybersecurity objective in the context of its update architecture.

Evidence links the threat scenario, risk treatment decision, cybersecurity requirement, implementation, verification, and validation.

This example demonstrates how cybersecurity assurance is built through connected engineering processes rather than through a single penetration test.

Key lesson: Cybersecurity process maturity requires demonstrable management of security risks throughout engineering. Scanning tools alone cannot establish the required capability.

The official cybersecurity 2.0 publication was developed as an extension to Automotive SPICE 4.0. When combining it with a newer core PAM, verify applicable assessment and transition guidance instead of assuming every edition is automatically interchangeable.

Official reference: VDA QMC Automotive SPICE for Cybersecurity.

---

10. MDevSPICE: Medical Device Software Process Assessment

What is MDevSPICE?

MDevSPICE is a medical-device-specific software process assessment approach developed to help organizations evaluate development practices against relevant medical device engineering and regulatory expectations.

It brings together process assessment concepts with medical device software lifecycle and safety requirements.

MDevSPICE includes a Process Reference Model, Process Assessment Model, and associated assessment approaches.

It is particularly relevant when software failures could affect patient health, diagnosis, treatment, or medical device operation.

Related medical device standards

Standard	Main purpose
IEC 62304	Medical device software lifecycle processes
ISO 13485	Medical device quality management systems
ISO 14971	Medical device risk management
IEC 62366-1	Usability engineering for medical devices

MDevSPICE helps examine the capability of processes that support these objectives.

It does not replace regulatory requirements or guarantee medical device approval.

MDevSPICE and Medical SPICE

A related development is VDI 5702 Blatt 1, which publishes a Medical SPICE Process Assessment Model for medical device software.

The VDI 5702 medical software assessment model is a distinct published standard and should not automatically be treated as the same version or specification as the research-developed MDevSPICE framework.

Organizations choosing a medical software assessment approach should identify the exact model and edition they intend to apply.

Step-by-step medical software process improvement

Step 1: Establish the intended use and regulatory context

Identify the medical device, intended use, applicable jurisdiction, relevant regulatory obligations, and software responsibilities.

Step 2: Determine the applicable lifecycle and risk processes

Identify relevant software development, maintenance, problem resolution, configuration management, verification, and risk management activities.

Step 3: Establish requirements and risk traceability

Connect medical device requirements to software requirements, hazards, risk controls, implementation, and verification evidence.

Step 4: Control software architecture and implementation

Document relevant architectural decisions and ensure that implementation follows applicable development controls.

Step 5: Execute appropriate verification

Verify requirements, software behavior, interfaces, and risk control implementation.

Step 6: Maintain change and problem resolution records

Evaluate changes and defects for their potential impact on safety, effectiveness, and existing verification evidence.

Step 7: Assess process capability

Use the chosen medical device process assessment model to identify weaknesses and improvement opportunities.

Example: Infusion pump software

Consider software that controls medication delivery in an infusion pump.

A hazard analysis identifies the risk of unintended excessive delivery.

The engineering team defines safety-related requirements and associated risk controls.

Software design records identify the relevant monitoring and control mechanisms.

Verification evidence demonstrates the operation of those mechanisms under defined conditions.

Any subsequent software change affecting the delivery algorithm requires impact assessment and suitable regression verification.

The objective is not only to show that a test passed. It is to demonstrate a controlled engineering process connecting medical safety concerns to requirements, implementation, verification, and maintenance.

Key lesson: Medical software maturity and regulatory compliance are related but distinct. Process assessments provide insight into engineering capability; applicable medical device regulatory requirements must be addressed independently.

Official and supporting references: VDI Medical SPICE, IEC 62304, ISO 14971, and ISO 13485.

---

11. TMMi: Test Maturity Model Integration

What is TMMi?

TMMi is a staged maturity model developed by the TMMi Foundation for improving software testing and quality engineering practices.

Where CMMI addresses broader organizational capabilities, TMMi concentrates specifically on test process maturity.

It provides an evolutionary improvement path from unmanaged testing toward managed, defined, measured, and continuously optimized testing.

TMMi Framework Model 2.0 incorporates modern Agile and DevOps practices and guidance relevant to quality engineering and artificial intelligence.

TMMi maturity levels

Level	Name	Practical meaning
1	Initial	Testing is often inconsistent and reactive
2	Managed	Test planning, monitoring, design, and execution are managed
3	Defined	Testing follows established organizational practices
4	Measured	Quantitative evaluation supports process and product quality management
5	Optimization	Testing processes improve through defect prevention and systematic optimization

Step-by-step TMMi implementation

Step 1: Evaluate the current testing process

Review test planning, requirements coverage, test design, execution, environments, defect management, and reporting.

Step 2: Define the testing policy and strategy

Agree on test objectives, risk-based priorities, responsibilities, and quality expectations.

Step 3: Improve test planning and control

Introduce clear planning, estimation, monitoring, and corrective-action practices.

Step 4: Establish appropriate test design and execution

Select test techniques according to product risk and requirements.

Use functional, integration, regression, performance, security, and other testing techniques where appropriate.

Step 5: Integrate testing into development

Embed test activities throughout the development lifecycle.

For Agile teams, this can include refinement, acceptance criteria, automated checks, exploratory testing, and continuous integration.

Step 6: Implement meaningful quality measures

Measure test effectiveness, defect trends, coverage, execution reliability, and relevant quality outcomes.

Step 7: Improve through regular assessments

Use an appropriate TMMi assessment approach to identify weaknesses and determine improvement priorities.

Example: Improving software release quality

A SaaS company experiences defects after releases even though its CI pipeline reports successful automated tests.

Investigation reveals that the test suite covers mostly expected behavior, while integration risks and edge cases receive insufficient attention.

The organization introduces risk-based test design, improved integration testing, explicit test environment controls, and more useful quality reporting.

The team monitors escaped defects and test effectiveness rather than simply increasing the total number of automated tests.

This is an example of testing maturity improving through better practices, not just more automation.

Key lesson: High automated test counts do not necessarily indicate a mature testing organization. TMMi evaluates how testing is planned, managed, integrated, measured, and improved.

Official reference: TMMi Foundation model and publications.

---

12. TPI NEXT: Test Process Improvement

What is TPI NEXT?

TPI NEXT is a test process improvement model developed by Sogeti.

It helps organizations evaluate testing practices and identify practical, prioritized improvement opportunities.

Unlike a model that focuses primarily on achieving a single organizational maturity rating, TPI NEXT evaluates multiple testing-related key areas.

It supports improvement planning through checkpoints, maturity matrices, dependencies, and suggested actions.

The 16 TPI NEXT key areas

TPI NEXT organizes its key areas into three groups.

Group	Key areas
Stakeholder Relations	Stakeholder commitment, degree of involvement, test strategy, test organization, communication, reporting
Test Management	Test process management, estimating and planning, metrics, defect management, testware management
Test Profession	Methodology practice, tester professionalism, test case design, test tools, test environment

These 16 areas allow organizations to identify testing weaknesses with greater specificity.

TPI NEXT maturity categories

The model uses progression through:

1. Initial: Ad hoc or insufficiently controlled practices.
2. Controlled: Fundamental testing activities are established and controlled.
3. Efficient: Testing is performed more effectively and efficiently.
4. Optimizing: Practices continually adapt and improve.

Maturity is evaluated at the relevant key-area level, with dependencies influencing the improvement path.

Step-by-step TPI NEXT implementation

Step 1: Identify business drivers

Clarify whether the main concern is product quality, test cost, release speed, predictability, or another business objective.

Step 2: Assess the key areas

Examine testing practices against the applicable checkpoints.

Collect evidence from testers, development teams, product owners, and other relevant stakeholders.

Step 3: Build a test maturity matrix

Record the current maturity of each key area.

A testing organization might show strong tooling but weak estimation, reporting, or defect management.

Step 4: Analyze dependencies

Identify which foundational practices are necessary before more advanced improvements can succeed.

For example, investing in sophisticated automation may deliver limited value if test design and environment stability are inadequate.

Step 5: Select improvement priorities

Focus on changes that address important business risks and enable further improvements.

Step 6: Implement and measure

Assign owners, introduce improvements, and track their effect on test outcomes.

Step 7: Reassess

Update the maturity matrix after improvements have been adopted.

Example: Reducing test cycle delays

A product team finds that regression testing repeatedly delays releases.

Assessment identifies unstable environments, inadequate test data, and poorly maintained test assets.

Instead of purchasing another automation platform immediately, the team stabilizes its environments and improves testware management.

It then measures environment-related failures, rerun effort, and regression cycle time.

This allows the organization to target the causes of delays rather than only their symptoms.

TMMi versus TPI NEXT

Dimension	TMMi	TPI NEXT
Primary orientation	Organizational testing maturity	Targeted test process improvement
Structure	Staged maturity model	Key-area maturity matrix
Assessment focus	Testing practices across maturity levels	Strengths and weaknesses of 16 key areas
Improvement planning	Progression through maturity practices	Business-driven, dependency-aware improvement
Typical use	Long-term testing maturity program	Practical testing process diagnosis and roadmap

Both approaches can be useful, but combining them should produce an integrated improvement plan rather than duplicate assessments.

Key lesson: TPI NEXT is especially useful when a testing organization needs to understand exactly where its test process is weak and which improvements should come first.

Official reference: TMAP — Test Process Improvement.

---

13. IT-CMF: IT Capability Maturity Framework

What is IT-CMF?

IT-CMF stands for IT Capability Maturity Framework.

It was developed by the Innovation Value Institute (IVI), associated with Maynooth University in Ireland.

IT-CMF examines an organization’s ability to manage information technology effectively and generate business value from technology investments.

Unlike ASPICE or TMMi, its primary focus is not the detailed software development or test lifecycle.

Instead, it addresses broader enterprise IT capabilities, investment decisions, operations, innovation, and value realization.

The four IT-CMF macro-capabilities

Macro-capability	Focus
Managing IT Like a Business	Running IT with clear business objectives and accountability
Managing the IT Budget	Funding, cost management, and sustainable investment
Managing the IT Capability	Developing, maintaining, and improving IT capabilities
Managing IT for Business Value	Demonstrating and maximizing the benefits of IT investments

The IT-CMF framework organizes these strategic areas into critical capabilities and capability building blocks.

The IVI framework viewer documents a library of 35 critical capabilities.

IT-CMF maturity levels

Level	Name	Description
1	Initial	Practices are unstable and outcomes are difficult to repeat
2	Basic	Some practices are defined, but consistency remains limited
3	Intermediate	Practices become more standardized and repeatable
4	Advanced	Capabilities support broad organizational needs and adaptability
5	Optimizing	Capabilities demonstrate sustained, highly effective performance

IT-CMF supports targeted capability improvement. An organization does not necessarily need to achieve the highest level in every capability.

Step-by-step IT-CMF implementation

Step 1: Define enterprise objectives

Identify the business outcomes technology must support.

Examples include reducing operational risk, accelerating product delivery, improving customer experience, or optimizing infrastructure investment.

Step 2: Identify critical IT capabilities

Select the capabilities most relevant to business priorities.

Step 3: Evaluate current maturity

Use the framework’s capability definitions, assessment questions, and maturity descriptions.

Step 4: Establish target maturity

Set realistic targets based on organizational needs and the value expected from improvement.

Step 5: Define capability improvement initiatives

Improvements may involve governance, processes, skills, technology, investment management, or organizational coordination.

Step 6: Link practices to business outcomes and metrics

Use the framework’s practices, outcomes, and metrics approach to connect improvements with measurable value.

Step 7: Review and refine

Evaluate whether improved capabilities are producing the expected outcomes.

Example: Improving enterprise cloud investment

An enterprise spends heavily on cloud infrastructure but cannot clearly connect its spending to business outcomes.

Its IT leadership identifies weaknesses in cost visibility, capacity planning, service ownership, and investment accountability.

The organization introduces clearer service ownership, budget governance, cost allocation, and performance reporting.

It then evaluates whether these practices improve spending predictability and business value.

Key lesson: IT-CMF is valuable when engineering capability is only one part of a broader challenge involving technology strategy, governance, investment, and enterprise performance.

Official reference: Innovation Value Institute — IT-CMF.

---

14. How to Choose the Right Process Improvement Framework

Selecting a framework should begin with the organization’s business domain and the specific problems it wants to solve.

Your situation	Recommended starting point	Why
Developing automotive embedded software	ASPICE	Automotive engineering process capability
Developing automotive cybersecurity functions	ASPICE + Automotive SPICE for Cybersecurity	Integrates engineering and cybersecurity process assessment
Improving general software and service delivery performance	CMMI	Broad organizational capability and performance
Building a standards-based process assessment program	ISO/IEC 330xx	International assessment requirements and models
Modernizing a legacy SPICE program	ISO/IEC 330xx	Successor framework for foundational ISO/IEC 15504 standards
Developing medical device software	Medical-device-specific process assessment approach	Addresses regulated software lifecycle and risk-related processes
Establishing organization-wide testing maturity	TMMi	Structured testing maturity improvement
Diagnosing specific testing weaknesses	TPI NEXT	Detailed testing key-area assessment
Improving enterprise IT strategy and investment outcomes	IT-CMF	IT capability and business value alignment

These recommendations identify useful starting points rather than mandatory combinations.

The organization’s customers, applicable regulations, contracts, and assessment objectives may require additional or different models.

Can multiple frameworks be implemented together?

Yes.

An automotive supplier could use ASPICE as the main engineering process assessment model, Automotive SPICE for Cybersecurity for relevant security processes, and selected TMMi practices to strengthen testing.

A software services organization could use CMMI for broader process performance and selected TPI NEXT practices for targeted testing improvements.

The important principle is to maintain one coherent operating process with reusable evidence, rather than creating a separate engineering workflow for each framework.

---

15. Building a Unified Process Improvement System

Organizations often struggle because they treat assessments as separate activities from engineering.

A better approach is to integrate process requirements, responsibilities, work products, and evidence into existing engineering systems.

Consider the following conceptual workflow:

Business objective → Select relevant framework → Define processes → Assign ownership → Perform engineering activities → Capture evidence → Assess capability → Identify weaknesses → Implement improvements → Measure outcomes → Reassess

Every stage should have a clear purpose.

Example engineering evidence architecture

Engineering activity	Evidence	Supporting tools
Requirements management	Requirements, approvals, traceability	Jira, Azure DevOps, IBM DOORS, Polarion
Architecture and design	Design records, interface definitions	Modeling tools, Git repositories, documentation platforms
Source code management	Commits, reviews, branches, baselines	GitHub, GitLab, Bitbucket
CI/CD	Build history, checks, deployment records	GitHub Actions, GitLab CI/CD, Jenkins
Test management	Test cases, results, defects	Xray, Zephyr, TestRail
Software quality	Static analysis and quality findings	SonarQube, Semgrep
Security testing	Vulnerability and dependency findings	OWASP Dependency-Check, Trivy, Semgrep
Change management	Change requests, impact decisions, approvals	Jira, Azure DevOps, service management tools
Operational monitoring	Availability, incidents, performance trends	Prometheus, Grafana
Process assessment	Assessment scope, findings, evidence index	Assessment workbooks and governance systems

These tools are examples, not mandatory products or evidence of automatic framework compliance.

A CI pipeline can execute thousands of tests while still failing to provide adequate evidence of verification planning, coverage, configuration control, or defect disposition.

Tools support a process. They do not replace the process itself.

---

16. Practical Tutorial: Building End-to-End Traceability

Traceability is especially important in regulated and safety-sensitive software development, but it also benefits general engineering quality.

Consider an automotive system that must reject unauthorized firmware updates.

Step 1: Create the requirement

Requirement ID: SYS-REQ-017

Requirement: The system shall prevent installation of firmware packages that fail the defined authenticity verification.

Record the requirement’s source, rationale, owner, approval status, and applicable version.

Step 2: Derive the software requirement

Requirement ID: SW-REQ-024

Requirement: The update component shall verify the firmware package signature using the configured trusted verification mechanism before authorizing installation.

Link the software requirement to SYS-REQ-017.

Step 3: Create the architectural design

Architecture ID: SW-ARCH-006

Identify the update manager, verification component, trust configuration, and relevant interfaces.

Record the architectural relationship with SW-REQ-024.

Step 4: Implement the requirement

Develop and review the software changes.

Link the implementation records to the relevant requirement and design.

Step 5: Define verification

Create verification activities covering valid packages and relevant invalid or modified packages.

Document expected results, prerequisites, execution environment, and acceptance criteria.

Step 6: Execute verification

Preserve test results, software version, relevant configuration, and identified defects.

Step 7: Establish a release baseline

Record the approved requirements, architecture revision, source code version, test evidence, and release decision.

Example traceability matrix

Requirement	Design	Implementation	Verification	Result
SYS-REQ-017	SW-ARCH-006	FW-UPDATE-01	SV-012	Passed
SW-REQ-024	SW-ARCH-006	FW-VERIFY-02	UT-031	Passed
SW-REQ-024	SW-ARCH-006	FW-VERIFY-02	IT-014	Passed

This example is illustrative, not a formal assessment artifact.

An assessor would still need to evaluate the quality and consistency of the relationships and supporting evidence.

Common traceability failures

• Requirements are linked to tests that do not actually verify them.
• Traceability links point to outdated design revisions.
• Test results cannot be associated with the exact software version.
• Changes are approved without adequate impact analysis.
• Requirements are marked complete despite unresolved verification findings.

The objective is not maximum link quantity. It is accurate, meaningful traceability that supports engineering decisions.

---

17. A Practical 90-Day Software Process Improvement Roadmap

A process improvement program should be structured as an incremental transformation, not a sudden documentation exercise.

The following roadmap is illustrative. Actual durations depend on organizational scope, process weaknesses, regulatory obligations, and the depth of assessment.

Phase	Period	Activities	Deliverables
Discovery	Days 1–15	Define objectives, scope, stakeholders, and framework	Scope and assessment charter
Baseline assessment	Days 16–30	Interview teams, examine evidence, identify gaps	Baseline assessment and gap register
Improvement design	Days 31–45	Prioritize gaps, design target practices, assign ownership	Improvement backlog and process definitions
Pilot implementation	Days 46–60	Apply practices to selected projects	Working processes and pilot evidence
Validation	Days 61–75	Evaluate outcomes, refine practices, address weaknesses	Performance measures and corrective actions
Expansion planning	Days 76–90	Review pilot results and plan wider adoption	Next-stage improvement roadmap

Phase 1: Establish objectives

Select measurable business problems.

Examples include high defect escape, poor release predictability, weak configuration control, or insufficient cybersecurity traceability.

Phase 2: Establish the baseline

Assess the current processes without assuming that existing procedures are effective simply because they are documented.

Use representative evidence and obtain input from the people performing the work.

Phase 3: Prioritize findings

Rank improvements by risk reduction, business impact, effort, and dependencies.

Correct foundational weaknesses before investing heavily in advanced optimization.

Phase 4: Pilot the improvements

Introduce changes within a manageable project or organizational scope.

Capture feedback from engineers and process owners.

Phase 5: Validate effectiveness

Determine whether the changes are being applied and whether performance has improved.

Distinguish implementation completion from demonstrated effectiveness.

Phase 6: Expand sustainably

Standardize successful practices where appropriate and preserve flexibility for legitimate project differences.

A pilot can demonstrate feasibility. It cannot, by itself, prove organization-wide maturity.

---

18. How to Measure Software Process Improvement

Process improvement needs meaningful measurements.

A maturity score alone is insufficient because it does not fully explain whether business outcomes are improving.

Recommended engineering and process metrics

Metric	Definition	Why it matters
Requirements traceability coverage	Percentage of applicable requirements with required traceability links	Identifies traceability completeness
Verification coverage	Percentage of applicable verification objectives with valid evidence	Helps identify unverified scope
Defect escape rate	Post-release defects relative to a defined release or defect population	Evaluates effectiveness of pre-release controls
Change failure rate	Production changes causing defined failures divided by total production changes	Measures deployment reliability
Build success rate	Successful builds divided by total eligible builds	Highlights build reliability
Lead time for changes	Elapsed time from the defined change starting point to delivery	Supports delivery performance analysis
Defect resolution time	Time from defect recording to resolution using defined rules	Assesses problem resolution efficiency
Assessment finding closure	Findings effectively closed relative to findings due for closure	Tracks improvement execution
Rework effort	Effort spent correcting previously completed work	Helps evaluate process inefficiency

Metric definitions must remain consistent over time.

For example, defect escape rate can vary substantially depending on whether the denominator includes all defects, only customer-reported defects, or total released features.

A mature measurement system documents these rules.

Example calculations

Requirements traceability coverage

If 180 of 200 applicable requirements have the required traceability relationships:

Traceability coverage = (180 / 200) × 100 = 90%

This measures link coverage, not the correctness of those links.

Change failure rate

If 6 out of 120 production changes cause failures under the organization’s defined criteria:

Change failure rate = (6 / 120) × 100 = 5%

Assessment action effectiveness

If 20 actions have been completed but only 14 have demonstrated the intended corrective outcome:

Effectiveness validation rate = (14 / 20) × 100 = 70%

This last calculation is an illustrative internal management metric, not a standardized framework rating.

Avoid misleading metrics

More documentation does not automatically mean higher maturity.

More test cases do not automatically mean better testing.

More automated checks do not automatically mean fewer escaped defects.

Faster releases do not necessarily indicate lower risk.

A useful measurement system examines both process execution and actual outcomes.

---

19. Preparing for a Process Maturity Assessment

A successful assessment requires clear scope, adequate evidence, appropriate participants, and a recognized assessment method.

The following checklist is suitable for internal preparation across many process assessment programs. It does not replace framework-specific assessment requirements.

Assessment readiness checklist

• Business objectives and assessment purpose are documented.
• Applicable framework, model, and edition are identified.
• Assessment scope and organizational boundaries are defined.
• Relevant process owners are assigned.
• Actual engineering practices are documented where needed.
• Representative projects and work products are available.
• Requirements and applicable traceability relationships can be demonstrated.
• Change and configuration records are accessible.
• Verification and validation evidence is available.
• Risks and problems are actively managed.
• Process performance measures are defined.
• Known deviations and limitations are recorded.
• Assessment participants understand their responsibilities.
• Improvement actions have accountable owners.

What assessors typically examine

Assessors may review several categories of evidence.

Direct evidence: Actual engineering work products such as requirements, architecture documents, test results, or change records.

Supporting evidence: Plans, procedures, dashboards, approvals, and records explaining how activities are managed.

Interview evidence: Information from personnel who perform, manage, or oversee the relevant processes.

The admissibility, sampling, and interpretation of evidence depend on the selected framework and assessment method.

Common preparation mistakes

Creating documents only for the assessment

Documents produced retrospectively may not demonstrate actual process implementation.

Confusing tool adoption with process capability

Installing a static analyzer or test management system is not equivalent to demonstrating effective quality or verification processes.

Ignoring unfavorable evidence

Unresolved defects, failed tests, and process deviations can be valuable evidence of how the organization manages problems.

Targeting the highest level immediately

Higher capability levels build on foundational practices. Attempting advanced quantitative optimization before achieving stable process execution is generally ineffective.

Treating every finding as equally important

Prioritize findings according to risk, dependencies, and business impact.

---

20. Integrating Process Maturity with Agile, DevOps, and DevSecOps

A common misconception is that maturity frameworks require slow, document-heavy software development.

In reality, most of the underlying objectives—repeatability, evidence, control, quality, and continuous improvement—are compatible with modern development practices.

The specific implementation must still satisfy the selected assessment model.

Process objective	Agile / DevOps implementation example
Requirements management	Maintained backlog items with approved requirements and acceptance criteria
Change control	Reviewed pull requests with appropriate impact decisions
Configuration management	Version-controlled repositories and reproducible baselines
Verification	Automated and manual verification with retained results
Quality assurance	Independent or appropriately structured quality evaluations
Risk management	Risk reviews integrated into planning and development
Measurement	Pipeline, quality, reliability, and delivery metrics
Continuous improvement	Retrospectives linked to tracked corrective actions
Cybersecurity engineering	Threat analysis, secure design, security verification, and risk treatment records

The main challenge is maintaining a defensible chain of evidence without introducing unnecessary bureaucracy.

For example, a pull request can contribute useful review evidence, but its existence alone may not prove adequate architectural review, requirements analysis, or change impact assessment.

Likewise, a successful CI pipeline can provide verification evidence while leaving other engineering outcomes unaddressed.

The right approach is to make routine engineering activities produce trustworthy evidence naturally.

---

21. Frequently Asked Questions

Is ASPICE the same as SPICE?

No. SPICE refers to a broader approach to process assessment and improvement. Automotive SPICE is an automotive-specific process reference and assessment model built on related process-assessment principles.

Is ISO/IEC 15504 still current?

The foundational ISO/IEC 15504 series has largely been withdrawn and superseded by the ISO/IEC 330xx family. Organizations should verify individual standards and their successors rather than assuming every historic reference has an identical replacement.

What is the main difference between ASPICE and CMMI?

ASPICE focuses on capability assessment of defined automotive development processes. CMMI supports a broader organizational performance and maturity improvement approach across multiple domains.

Their levels are not directly interchangeable.

Does ASPICE require a waterfall development model?

No. Automotive SPICE is not a prescribed development lifecycle. Iterative and Agile approaches can be used if the relevant process purposes, outcomes, and capability requirements are fulfilled.

Is ASPICE Capability Level 3 mandatory for all automotive suppliers?

No universal rule requires every automotive supplier to achieve Capability Level 3 for every process.

Customer contracts, supplier requirements, project context, and assessment scope determine applicable expectations.

Can CMMI and TMMi be used together?

Yes. CMMI can address broader organizational process performance while TMMi provides detailed guidance for improving testing maturity.

What is the difference between TMMi and TPI NEXT?

TMMi uses a staged testing maturity architecture. TPI NEXT evaluates testing through key areas and emphasizes targeted, business-driven improvement planning.

Is MDevSPICE mandatory for medical device companies?

MDevSPICE is not itself a universal regulatory requirement. Medical device manufacturers must determine and satisfy applicable laws, regulations, standards, and customer requirements.

A medical software process assessment can support process improvement but does not automatically establish regulatory compliance.

Can DevSecOps replace Automotive SPICE for Cybersecurity?

No. DevSecOps practices and tools can help implement relevant cybersecurity activities, but they do not replace the assessment model’s process outcomes or the requirements of applicable cybersecurity standards and regulations.

Is maturity Level 5 always the best target?

Not necessarily. The appropriate capability or maturity target depends on business goals, risks, customer requirements, and the value of further improvement.

A stable, well-managed process that meets relevant needs can be more valuable than an expensive effort to pursue a higher rating without a clear business benefit.

Does passing an assessment guarantee software quality?

No. Process assessments provide evidence about defined process capability or maturity within a particular scope.

They do not guarantee that every product is defect-free, secure, safe, or compliant with all applicable requirements.

How long does process maturity improvement take?

There is no universal duration.

Time depends on current capability, assessment scope, organizational size, available resources, process complexity, and how deeply improvements must be institutionalized.

A short pilot may demonstrate better practices, while sustained organizational capability often requires a much longer improvement program.

---

22. Final Recommendations

Software process maturity should be treated as an ongoing engineering and management discipline, not a one-time audit.

The most effective improvement programs begin with a clear problem, select an appropriate framework, establish reliable processes, collect meaningful evidence, and measure whether outcomes actually improve.

Automotive engineering organizations should look closely at ASPICE, with its cybersecurity extension where relevant.

Organizations seeking broader performance improvement can evaluate CMMI.

Those establishing standards-based assessment approaches should understand ISO/IEC 330xx and the historical role of SPICE and ISO/IEC 15504.

Medical device manufacturers can evaluate domain-specific approaches such as MDevSPICE and Medical SPICE, alongside applicable regulatory requirements.

Testing organizations can use TMMi for structured maturity improvement or TPI NEXT for targeted diagnostic assessment.

Enterprise IT leaders seeking better alignment between technology capabilities and business value can evaluate IT-CMF.

Ultimately, the goal is not to collect certificates, maturity ratings, or process documents.

The goal is to build an engineering organization that can explain how its products are developed, demonstrate why they can be trusted, respond effectively when problems occur, and improve its performance with every development cycle.

---

Official References and Further Reading

The following primary and supporting resources provide model definitions, assessment guidance, and authoritative standard information.

1. VDA QMC — Automotive SPICE Reference and Assessment Models
2. intacs — SPICE Center
3. ISACA / CMMI Institute — CMMI
4. CMMI Institute — Appraisal Types
5. ISO — ISO/IEC 33000 Standards Family
6. ISO — ISO/IEC 33020 Process Capability Measurement
7. ISO — ISO/IEC 15504-1 Historical Reference
8. VDI — Medical SPICE Process Assessment Model
9. TMMi Foundation — Models and Assessment Documents
10. TMAP / Sogeti — TPI NEXT
11. Innovation Value Institute — IT-CMF
12. IEC 62304 — Medical Device Software Lifecycle
13. ISO 14971 — Medical Device Risk Management
14. ISO 13485 — Medical Device Quality Management