SPICE (ISO/IEC 15504·330xx, Software Process Assessment)
1. Overview
Definition: SPICE (Software Process Improvement and Capability dEtermination) is an international-standard-based process assessment scheme that evaluates software and system life-cycle processes along two dimensions — a process dimension and a capability dimension — rating each process's capability on a 0–5 scale and using the result for process improvement and supplier capability determination; it evolved from its original standard ISO/IEC 15504 into today's ISO/IEC 330xx family.
The backdrop to SPICE's emergence was the proliferation of competing process-evaluation models in the early 1990s. With the U.S. SW-CMM, the UK's TickIT, and Europe's Bootstrap circulating by region and industry, there was no common yardstick for comparing supplier capability consistently in multinational software trade. ISO/IEC JTC1/SC7 therefore launched the "SPICE project" in 1993 to develop an internationally agreed process assessment standard; its output, after a 1998 Technical Report (TR), was formalized as the ISO/IEC 15504 standard between 2003 and 2006. In other words, SPICE is not a single organization's proprietary model but, from the outset, carries the identity of "process assessment as a standard" aimed at international consensus.
The fundamental reason SPICE is needed lies in the premise that software quality is contingent on the maturity of the process that produces it, combined with the demand that this maturity be measured objectively and repeatably. An acquirer wants to verify a supplier's capability (Capability Determination) before awarding work, while a supplier wants to identify its weak processes and improve them (Process Improvement). SPICE supports both purposes (the two uses of an assessment result) through a single measurement framework, making it a tool that provides "an evidentiary basis for measurable improvement" rather than mere certification. Especially in safety-critical industries such as automotive, aerospace, and medical devices, where process capability must be demonstrated across the whole supply chain, a SPICE-family assessment effectively functions as a condition of doing business.
Here it helps to note the origin of the name. SPICE stands for "Software Process Improvement and Capability dEtermination," the name of an international joint project launched in 1993 under ISO/IEC JTC1/SC7, and by extension the common name of its resulting standard. The word SPICE itself therefore encodes two purposes — "process improvement" and "capability determination" — which connect directly to the dual use of assessment results discussed later.
The two uses of a SPICE assessment result are inscribed in the name (SPICE = Process Improvement + Capability Determination). Capability Determination is the acquirer's use for comparing and judging whether a candidate supplier's process capability reaches the target level the work demands; it acts as a gate for procurement and contracting. Process Improvement is the organization's use for identifying the gap between its current capability profile and a target profile, so as to prioritize improvement investment. The elegance of SPICE's design is that both uses share one measurement system: the same assessment data can serve two distinct decisions — "proof of eligibility to deliver" and "an internal improvement map." For this reason, clearly declaring the purpose before an assessment begins is part of the standard's requirements.
SPICE's key characteristics can be summarized as follows. First, a two-dimensional separation evaluates "what is done (process)" and "how well it is managed (capability)" independently. Second, a continuous approach alone is taken, rating capability per process individually, which distinguishes it from CMMI's staged form that bundles the whole organization into a single grade. Third, standardization of the measurement framework reduces inter-assessor variation and secures repeatability through a four-point N·P·L·F scale. Fourth, separation of reference models modularizes the Process Reference Model (PRM), Process Assessment Model (PAM), and measurement framework into distinct standard documents, making it easy to derive domain-specific models such as Automotive SPICE and medical variants. These four characteristics all converge on one aim — "repeatable process measurement as an international standard." If CMMI is an influential U.S.-centered model, SPICE aims to be interpreted and applied identically anywhere in the world through the consensus of the neutral ISO/IEC standards bodies; this neutrality is precisely why industries with entangled global supply chains choose the SPICE family. The two-dimensional structure, capability levels, and assessment procedure examined below are all best understood as devices for realizing this repeatability, which keeps the whole picture coherent.
2. Overall Structure — The Two-Dimensional Model and the Standard System
The heart of SPICE is a two-dimensional model that makes the Process Dimension and the Capability Dimension orthogonal. The process dimension specifies "which processes exist and what their purpose and work products are," while the capability dimension specifies "how systematically each of those processes is performed, managed, and improved," on a 0–5 scale. The reason for separating the two dimensions is that the very same requirements-engineering process may be performed ad hoc in one organization (level 1) and under quantitative management (level 4) in another. Thanks to this orthogonal structure, an organization can freely choose "which process to raise first," enabling a practical roadmap that concentrates improvement on the most painful processes.
It is easy to picture this two-dimensional structure numerically. Place the assessed processes (e.g., requirements analysis, design, verification, configuration management, project management) along the horizontal axis and capability levels 0–5 along the vertical axis, and the assessment result becomes a capability profile shaped like a bar chart, with a different height for each process. One organization may be at level 3 in project management but level 1 in verification, while another is the reverse. Unlike CMMI's staged form, which compresses an organization into a single number, this SPICE profile reveals an organization's strengths and weaknesses at a glance, which is advantageous for prioritizing improvement investment.
The process dimension is drawn from an external Process Reference Model (PRM). Software references the life-cycle processes of ISO/IEC 12207 and systems those of ISO/IEC 15288, while SPICE itself provides a Process Assessment Model (PAM) that overlays these processes with "assessable indicators (base practices and work products)." The capability dimension is handled by the Measurement Framework, which defines the Process Attributes (PAs) that make up each capability level and the scale for rating their achievement. By separating PRM, PAM, and measurement framework in this way, an industry can reuse the same capability-measurement system merely by swapping in its own PRM.
The life-cycle processes referenced by the process dimension are generally grouped into three categories. Primary life-cycle processes are the core activities that directly build and deliver a product, such as acquisition, supply, development, operation, and maintenance; Support processes are the activities that cut across primary processes to underpin quality, such as quality assurance, verification, validation, configuration management, documentation, and problem resolution; and Organizational processes are activities that strengthen capability across the whole organization, such as management, improvement, human resources, and infrastructure. The reason for categorizing in this way is that, even applying the same capability yardstick, processes differ in their impact on the organization and in the difficulty of improving them; which category to include when scoping an assessment governs how the results are interpreted.
Here the division of roles between PRM and PAM must be made clear. The PRM specifies only "what the purpose (Purpose) and expected outcomes (Outcome) of each process are," as an abstract reference frame, while the PAM makes that purpose assessable by concretizing it into "base practices" and "work product indicators." For example, if the PRM states only that "the purpose of the requirements-elicitation process is to collect and agree stakeholder needs," then the PAM presents base practices such as "identify stakeholders, collect requirements, agree requirements" and work products such as "a requirements specification, a traceability matrix" as evidence items. This separation lets the PRM remain stable while the PAM is refined per industry, and lets assessors rate on verifiable evidence rather than abstract purpose.
graph TD
STD["SPICE Standard System"] --> D1["Process Dimension"]
STD --> D2["Capability Dimension"]
D1 --> PRM["Process Reference Model (PRM): ISO/IEC 12207·15288"]
PRM --> CAT["Process categories: Primary·Support·Organizational"]
D2 --> MF["Measurement Framework"]
MF --> CL["Capability levels 0–5"]
CL --> PA["Process Attributes (PA), 9 of them"]
PA --> RS["Rating scale N·P·L·F"]
D1 --> PAM["Process Assessment Model (PAM): base practice·work product indicators"]
D2 --> PAM
PAM --> AS["Perform assessment"]
In terms of the standard system, the original ISO/IEC 15504 was structured as Part 1 (concepts) through Part 10 (safety), but from around 2015 it was reorganized into the ISO/IEC 330xx family. Summarizing the core documents in prose: 33001 defines concepts and terminology, 33002 the requirements for performing an assessment, 33003 the requirements for measurement frameworks, and 33004 the requirements for reference, assessment, and maturity models. The substance of capability measurement, 33020, holds the process measurement framework for capability assessment (definitions of capability levels and PAs), while 33060 and the like provide PAMs for system and software life-cycle processes. The shift from 15504 to 330xx is not a mere renumbering but the result of an intent to "extend SPICE beyond software into a general framework applicable to any kind of process assessment."
| Aspect | ISO/IEC 15504 (old) | ISO/IEC 330xx (current) |
|---|---|---|
| Nature | Software-centric process assessment | Domain-agnostic process assessment |
| Concepts·terminology | Part 1 | 33001 |
| Assessment-performance requirements | Part 2 | 33002 |
| Measurement framework | Included within Part 2 | 33003·33020 |
| Reference/assessment-model requirements | Part 2·5 | 33004 |
| Assessment model (SW/system) | Part 5 | 33060 etc. |
3. Capability Levels and Process Attributes (PA)
The core of the capability dimension is the capability levels 0–5 and the Process Attributes (PAs) that make up each level. Capability levels are cumulative: to be recognized at a higher level, the PAs of the lower levels must first be satisfied — the same logic by which CMMI's maturity stages cannot be skipped. Each PA indicates how well a given process possesses a particular management characteristic, and as the level rises, the depth of management deepens from "performed → managed → standardized → quantified → innovating."
| Capability level | Name | Process Attributes (PA) | Meaning |
|---|---|---|---|
| 0 | Incomplete | — | Process purpose not achieved |
| 1 | Performed | PA1.1 Process Performance | Purpose achieved but unsystematic |
| 2 | Managed | PA2.1 Performance Management, PA2.2 Work Product Management | Planned·tracked·work-product controlled |
| 3 | Established | PA3.1 Process Definition, PA3.2 Process Deployment | Standard process defined·applied org-wide |
| 4 | Predictable | PA4.1 Process Measurement, PA4.2 Process Control | Statistically managed via quantitative metrics |
| 5 | Optimizing* | PA5.1 Process Innovation, PA5.2 Innovation Implementation | Continuous·proactive improvement |
*In ISO/IEC 33020, level 5 is expressed as "Innovating" and level 4 as "Predictable," with names and PA details adjusted by edition; in an exam answer it is safer to emphasize the direction of "a cumulative structure deepening from performed to innovating" rather than the specific names.
Looking a little more closely at the management characteristic each capability level requires, a common logic emerges: as the level rises, the "object of management" widens. Level 1 (performed) is the minimal bar — essentially "does the process exist?" — requiring only that a result be produced. Level 2 (managed) asks whether that process is planned and tracked and whether its work products are under version and approval control — that is, activities once dependent on individual skill begin to be managed at the project level. Level 3 (established) is where the per-project, idiosyncratic ways are defined as an organizational standard process, tailored, and deployed; organizational asset-building begins here. Level 4 (predictable) measures and controls the standard process with quantitative metrics, handling the variation of outcomes statistically, while level 5 (optimizing/innovating) proactively improves the process itself on the basis of measurement data. Holding this view of "the widening object of management" lets you reconstruct the intent of each PA without rote memorization.
Here the very concept of a "Process Attribute (PA)" also deserves clarification. A PA is not a specific activity (e.g., performing tests) but a measurable characteristic of management quality applied in common to all processes. For example, PA2.1 (performance management) asks, regardless of whether it is requirements engineering or testing, "is that process managed in terms of objectives, plans, responsibilities, and resources?" Because PAs are defined as cross-cutting characteristics independent of the process, wholly different processes can be compared on the same capability yardstick, and a single measurement framework can be reused across all processes. This is the practical payoff of separating the capability dimension from the process dimension.
Each PA is individually rated on a four-point N·P·L·F scale. N (Not achieved, 0–15%) is a state with almost no evidence, P (Partially, 15–50%) partial achievement, L (Largely, 50–85%) mostly achieved with some shortfall, and F (Fully, 85–100%) full achievement. To be recognized as "achieving" a given capability level, all PAs of that level must be L or above and all PAs of the lower levels must be F. For instance, for a process to be rated level 2, PA1.1 must be F and PA2.1·PA2.2 must be L or above. This rule reduces the scale's subjectivity and helps different assessors reach similar conclusions from the same evidence (repeatability).
Looking at a concrete example, suppose a Tier-1 supplier's requirements-engineering process is rated PA1.1=F, PA2.1=L, PA2.2=L, PA3.1=P. In this case the capability level is determined to be level 2 — because the level-2 PAs are all L or above and the level-1 PA is F — and level 3 is not recognized because PA3.1 stops at P. The assessment result leads to the diagnosis that "requirements engineering is managed at the project level (level 2) but has not been defined and deployed as an organizational standard (below level 3)," and the improvement recommendation naturally becomes "define and deploy a standard process to achieve L or above on PA3.1·3.2." Thus an N·P·L·F profile functions not as a mere grade but as a map that points to the next investment point.
The practical implication of this rating structure is that an organization must prove its capability level with "evidence," not "declaration." For example, to earn an F on PA3.1 (process definition), it is not enough that a standard process document exists; there must be evidence that the standard defines tailoring guidelines, roles, and competency requirements, and has been deployed (PA3.2) to actual projects. In other words, SPICE is designed to look at "whether the process is embedded and working in the organization," not "whether a document exists," so formal evidence alone makes a higher level hard to earn.
4. The Assessment Procedure and Automotive SPICE
A SPICE assessment proceeds, per the requirements set out in ISO/IEC 33002, through the flow planning → data collection → data validation → attribute rating → result reporting. The assessment is led by a competent assessor; after first defining the assessment purpose (for improvement vs. for capability determination) and scope (target processes·organizational unit), evidence of each process's base practices and work products is collected through interviews, document review, and observation. The collected evidence is rated per PA as N·P·L·F and produced as a capability-level profile (the distribution of levels by process). This profile is both the starting point for an improvement roadmap and the proof of a supplier's capability.
flowchart LR
P1["1.Assessment planning<br/>define purpose·scope·target processes"] --> P2["2.Data collection<br/>interviews·documents·observation"]
P2 --> P3["3.Data validation<br/>cross-check evidence"]
P3 --> P4["4.PA rating<br/>assign N·P·L·F"]
P4 --> P5["5.Determine capability level<br/>per-process profile"]
P5 --> P6["6.Report results·improvement recommendations"]
P6 -.reassess after reflecting improvements.-> P1
Assessment types also divide by purpose. A self-assessment, conducted by the organization itself, is for improvement — low in cost and suited to repeated application, but relatively weak in objectivity — whereas an independent assessment (second-/third-party) conducted by an external body is used for supplier capability determination or external proof, high in objectivity but heavy in cost and preparation. Organizations typically take a two-stage approach: first tidying up weaknesses through a self-assessment, then receiving a formal result through an independent assessment — to reduce the risk of walking into the real assessment without a rehearsal and losing a bid to a low profile.
Because the reliability of an assessment depends heavily on the assessor's competence and independence, the SPICE scheme institutionalizes assessor qualification. In the automotive field, intacs classifies assessors into Provisional·Competent·Principal grades, defining per-grade requirements for training, assessment experience, and renewal. Assessments are also usually conducted with multiple assessors and the assessed organization's representatives participating together, cross-checking evidence through triangulation of interviews, documents, and work products rather than a single interview. Without such procedural controls, the same organization could be rated differently by two assessors — a reproducibility problem — so repeatability is managed as a core indicator of SPICE assessment quality.
SPICE's foremost industrial success story is unquestionably Automotive SPICE (ASPICE). A PAM in which Germany's automotive industry association (VDA) and intacs tailored ISO/IEC 330xx to automotive embedded-software development, it is the de facto standard by which original equipment manufacturers (OEMs) evaluate the software-development capability of electronics-component suppliers (Tier-1s). ASPICE lays out system and software engineering processes in a left-right symmetric V-model shape (requirements analysis → design → implementation → integration·verification) and especially rigorously requires bidirectional traceability and consistency among requirements, design, and test. In 2023, ASPICE 4.0 was published, extending from the former HIS-scope focus toward encompassing machine-learning- and cybersecurity-related processes. Concretely, many global OEMs require Tier-1s to achieve capability level 2 or 3 on core processes as a condition of delivery, showing that SPICE acts as a real gate deciding supply contracts worth trillions of won, beyond mere recommendation.
The reason an ASPICE assessment is especially demanding is that it requires traceability across the two sides of the V-model as "evidence," not "declaration." That is, system requirements → software requirements → design → code → unit·integration·system tests must be linked bidirectionally, and when either side changes, the scope of impact must surface immediately via a traceability matrix. These traceability and consistency requirements arose from the automotive industry's need to pinpoint responsibility in the event of a recall, well illustrating the general principle that the more a domain's defects bear directly on human safety, the greater the rigor of its process assessment.
SPICE and CMMI are frequently compared. Both address process maturity/capability, but the fundamental reason for the difference lies in design philosophy and governance ownership. CMMI is a model owned by the U.S. SEI (now ISACA), offering both staged and continuous forms and able to express an organization as a single maturity grade (ML), which is advantageous for external marketing. SPICE, by contrast, is an ISO/IEC international standard offering continuous form only, producing a per-process capability-level profile, with a strength in finely diagnosing "which process is weak." A practical implication is that CMMI tends to suit procurement/PR situations that need an enterprise grade expressed in a word, while SPICE tends to suit situations requiring precise diagnosis and regulatory response for a specific process (e.g., verification of safety-related software). That said, the two models are not mutually exclusive; in practice, not a few organizations run them in parallel — setting an organization-wide maturity roadmap with CMMI and precisely verifying a specific product line's process capability with SPICE (ASPICE). Because both models start from the same premise that "process quality determines product quality," the management characteristics they demand (quantitative management, continuous improvement) effectively converge at higher levels.
The numbers on the industry floor show ASPICE's influence well. Many automakers require, as a precondition for new awards, that suppliers achieve capability level 2 or above on core processes (SYS.2 system requirements analysis, SWE.1 software requirements analysis, SWE.3 detailed design·implementation, SWE.4–6 testing, etc.), and some safety-/security-sensitive products require level 3. Suppliers stuck at level 1 are often excluded from bidding outright or bound to improvement-conditional contracts, so a one-level difference in ASPICE can decide awards worth tens to hundreds of billions of won. For this reason, domestic and foreign Tier-1s maintain dedicated ASPICE-response units (process-quality teams) and operate systems that continuously accumulate each project's work products in the form of assessment evidence.
Lastly, a common misconception about adopting SPICE deserves a note. SPICE does not teach "how to build good software" — that is the domain of design, architecture, and coding skill. What SPICE guarantees is "the process capability to build good software repeatably and predictably." Therefore a high capability level does not make all defects vanish, nor does a low one necessarily make a particular product bad. Missing this distinction makes it easy to fall into the overconfidence that "SPICE level 3 = perfect quality," so it must be understood precisely that SPICE is not a device guaranteeing an upper bound on outcome quality but a device for reducing the variability of quality.
| Comparison item | SPICE (ISO/IEC 330xx) | CMMI (ISACA) |
|---|---|---|
| Nature | ISO/IEC international standard | SEI→ISACA proprietary model |
| Representation | Continuous only | Staged + continuous |
| Result form | Per-process capability profile | Organizational maturity grade (ML) |
| Scale | Per-PA N·P·L·F | Practice satisfied or not |
| Representative use | Automotive SPICE (automotive) | Public·defense·SI bidding |
5. Deep Dive — Recent Trends and Spreading Adoption
Recent trends in the SPICE family can be summarized as the spread of domain-specific PAMs and generalization of the standard. Following automotive's ASPICE, industry-specific derivative models have emerged for medical devices (MED SPICE), space (Space SPICE), and finance/enterprise (Enterprise SPICE), so that SPICE is establishing itself as a meta-framework for "assessing the process capability of any domain," beyond "software process assessment." This is possible thanks to the separated structure of PRM, PAM, and measurement framework explained earlier, because each industry need only redefine its PRM and base practices to reuse the same capability-measurement system.
Another current is integration with functional-safety and cybersecurity standards. In the automotive field, as the processes required by ISO 26262 (functional safety) and ISO/SAE 21434 (vehicle cybersecurity) are reflected in ASPICE's process dimension, integrated governance that handles safety, security, and quality together within a single assessment scheme is being demanded. ASPICE 4.0's extension to encompass machine-learning-based functions and cybersecurity processes is in this context, and as the shift to autonomous driving and the SDV (Software Defined Vehicle) accelerates, the importance of proving software process capability grows further. That said, the edition numbers and process composition of such detailed standards can change with revisions, so in an exam answer it is safer to emphasize the direction of "the convergence of safety, security, and quality processes" over specific figures.
A third current is integration with Agile and DevOps. Because SPICE presupposes no particular development method, it can assess whether a process is managed, defined, and measured while leaving Agile practices such as sprints and CI/CD intact. However, in Agile organizations work products exist not as detailed documents but as backlogs, automated tests, and pipeline logs, so flexibility is needed to interpret the evidence a PAM requires as "records left in tools" rather than "documents." For example, the evidence for PA2.2 (work product management) can be sufficiently demonstrated by Git history, PR review records, and an artifact repository rather than a thick configuration-management document. Without this shift in perspective, SPICE can appear as bureaucracy to an Agile team, so it is important for assessors and organizations to agree on the "modern form of evidence."
Domestically too, SPICE has been used as a means of public-SW quality management and of capability proof for automotive-parts export companies. In particular, domestic Tier-1·Tier-2 parts makers must secure ASPICE capability levels to deliver to global OEMs, so cases of operating assessment response and process improvement as a standing system are increasing. As for expected exam directions, ① explaining SPICE's two-dimensional structure and capability levels, ② comparing SPICE and CMMI, ③ linking Automotive SPICE with functional safety (ISO 26262), and ④ the meaning of the transition from ISO/IEC 15504 to 330xx can all be set as both short-answer and essay questions, so composing an answer along the four axes of structure·procedure·comparison·linkage is effective.
In terms of answer-writing strategy, SPICE is set as a standalone topic but is highly likely to appear woven in as a component of the broader topic "process quality." For a question asking, say, "ways to diagnose and improve an organization's SW process capability," presenting CMMI and SPICE together while clearly contrasting SPICE's differentiators (international standard·continuous·profile) is a high-scoring point. Also, when a specific industry context such as automotive or medical is given, it is advisable to also describe domain-specific models such as ASPICE·MED SPICE and their linkage with functional-safety and cybersecurity standards, so as to show "how they are operated in an integrated way in the field" beyond a level of merely memorizing the standard.
6. Considerations and Implications (Professional Engineer's View)
First, one must first align whether the assessment's purpose is "capability determination" or "improvement." Even the same SPICE assessment differs in scope, rigor, and evidence demands between an external determination assessment for supplier selection and an internal improvement assessment. External determination prioritizes objectivity and repeatability, while improvement places more weight on identifying weaknesses and giving actionable recommendations. Confusing the purpose leads to the certification trap of "a grade earned but no improvement," so governance is needed to connect the assessment result to real improvements in substantive metrics such as defect rate, rework, and traceability defects.
Second, higher capability levels (4·5) presuppose quantitative data and a measurement system, so upfront investment is needed. The statistical process control of PA4.1·4.2 cannot be achieved without reliable measurement metrics and data pipelines. From a trade-off view, weigh the cost of building a measurement system against the predictability and quality gains it brings, and apply the realistic selection-and-concentration of raising the core processes with the greatest business risk to level 4 first, rather than uniformly raising all processes. In this regard, SPICE's higher stages link naturally with data governance, observability, and DevOps metric systems.
Third, leverage the strength of the continuous structure to design a "profile-based improvement roadmap." Because SPICE gives a per-process capability profile rather than lumping the organization into a single number, it can prioritize the most painful processes (e.g., requirements management·configuration management·verification) to maximize return on investment. Rather than being consumed by the single goal of an enterprise grade, a gradual approach that fills the "valleys" of the profile fits SPICE's design philosophy.
Fourth, integrated operation with safety/security standards and supply-chain governance is key. In heavily regulated industries such as automotive, medical, and aerospace, SPICE (ASPICE) gains effectiveness when operated together with functional-safety, security, and medical standards such as ISO 26262·ISO 21434·IEC 62304. Without a system that consistently demands and verifies process capability across the whole supply chain (OEM–Tier-1–Tier-2), the safety and quality of the final product cannot be guaranteed, so an organization should operate SPICE not as a standalone certification but as an integrated scheme combining safety·security·quality·supply-chain governance.
Fifth, one must guard against excessive documentation (documentation overload). Mass-producing evidence unrelated to actual work in order to pass a SPICE assessment turns the process into "paperwork" for the assessment instead of value creation. Especially in Agile·DevOps environments, it is desirable to use records naturally left in tools (pipeline logs, test reports, issue trackers) as evidence and to minimize the burden of separately authoring evidence. An assessment yields the best cost-effectiveness when the process is designed so that evidence is left as a by-product of the work.
Sixth, tracking standard revisions and securing assessor competence are continuing success factors (CSFs). As with the 15504→330xx transition and the ASPICE 4.0 revision, standards continually evolve, so an organization must track the latest editions and secure and develop a pool of certified assessors. Ultimately SPICE's value lies not in "whether an assessment was passed" but in "whether the process is measurably improving," and in the future it is expected to combine with AI-based automatic evidence collection and traceability analysis to lower assessment costs and evolve into continuous monitoring.
References
- ISO, "ISO/IEC 33001:2015 — Process assessment — Concepts and terminology": https://www.iso.org/standard/54175.html
- ISO, "ISO/IEC 33020:2019 — Process measurement framework for assessment of process capability": https://www.iso.org/standard/74489.html
- Wikipedia, "ISO/IEC 15504 (SPICE)": https://en.wikipedia.org/wiki/ISO/IEC_15504
- VDA QMC / intacs, "Automotive SPICE": https://www.automotivespice.com/
In one line: SPICE (ISO/IEC 15504→330xx) is an international-standard process assessment scheme that makes a process dimension orthogonal to a capability dimension (levels 0–5·PAs·N/P/L/F), finely diagnosing per-process capability via a continuous profile, and has become the de facto standard for supply-chain quality and safety governance through domain-specific models such as Automotive SPICE.