SPICE (Software Process Improvement and Capability Determination): SPICE – Tutorial (about 60 minutes)

SPICE (Software Process Improvement and Capability Determination) is the international approach to process assessment that began as the ISO/IEC 15504 series and lives on today as the ISO/IEC 330xx family. It gives organisations a common way to look at how their processes actually run, rate how capable each process is on a six-level scale, and use that result either to improve or to judge whether a supplier can be trusted with important work. After this tutorial you will be able to explain how a SPICE-style assessment is built and performed, read a capability profile, and plan a sensible first assessment and improvement cycle.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: SPICE is not a single book any more. The name belongs to the ISO/IEC 15504 series, whose core parts have been withdrawn; its current successor is the ISO/IEC 330xx family on process assessment, maintained by the joint ISO and IEC committee for software and systems engineering (ISO/IEC JTC 1/SC 7). The core documents are ISO/IEC 33001:2015 (concepts and terminology, which replaced 15504-1), ISO/IEC 33002:2015 (requirements for performing process assessment), ISO/IEC 33003:2015 and ISO/IEC 33004:2015 (requirements for measurement frameworks and for reference, assessment and maturity models), ISO/IEC 33020:2019 (second edition of the measurement framework for process capability), guidance such as ISO/IEC TR 33014:2013 (guide for process improvement), and ready-made assessment models such as ISO/IEC TS 33061:2021 for software life cycle processes, which replaced ISO/IEC 15504-5:2012 when that part was withdrawn in 2021. According to the ISO catalogue, 33001, 33002 and 33020 were last reviewed and confirmed in 2026 and TS 33061 in 2024, so these editions remain current and no newer edition has been announced. This tutorial teaches the 330xx family and points out where older 15504 terms still appear. Verified 2026-10-29 from the ISO catalogue entries (as indexed by search engines, because iso.org blocks automated reading), the IEC webstore and national standards bodies.

Who it is for: quality and process engineers, software and systems engineers, project and delivery managers, supplier-quality and procurement staff, and internal auditors who are new to process assessment and expect to run, take part in, or commission a SPICE-style assessment.

Prerequisites: none. Some experience of how software or system projects are planned and delivered helps, but every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why SPICE was created and how ISO/IEC 15504 evolved into the ISO/IEC 330xx family.
You will be able to describe the two dimensions of an assessment: the processes being examined and the capability scale used to rate them.
You will be able to name the six capability levels and the nine process attributes, and apply the N-P-L-F rating rules to derive a level.
You will be able to outline the activities, roles and assessment classes of a conformant assessment.
You will be able to tell process improvement apart from capability determination and use a target profile to find gaps and risks.
You will be able to plan a realistic first assessment and improvement cycle for a software organisation.
You will be able to position SPICE against CMMI, Automotive SPICE, ISO 9001, ISO/IEC/IEEE 12207 and ISO/IEC 29110.

Lesson 1 – Origins, purpose and scope

The problem SPICE set out to solve

By the early 1990s, buyers of software, from defence ministries to telecom operators, had learned an expensive lesson: the quality of a delivered system depends heavily on how it was built. A supplier with disciplined requirements, planning, configuration control and testing usually delivers something that works; a supplier that improvises usually does not, however talented its programmers are. Buyers therefore wanted to look at a supplier's process before signing a contract, and suppliers wanted a reliable way to find and fix weaknesses in their own way of working.

Several assessment methods already existed. The best known was the Capability Maturity Model (CMM) for software from the Software Engineering Institute in the United States; in Europe there were national and company schemes such as Bootstrap and Trillium. Each used its own vocabulary, its own scales and its own rules, so results could not be compared, and a supplier selling to customers in several countries could face several incompatible assessments. The international software engineering community concluded that what was missing was an international standard for process assessment that would make results comparable and repeatable, whatever model or method was underneath.

From a project to a standard

In 1993 the ISO/IEC committee for software engineering launched a project to develop that standard and named it SPICE. The project was unusual because it tested its drafts in the field: from 1995 onward, so-called SPICE trials collected data from real assessments around the world and fed the lessons back into the text. The first result was a technical report, ISO/IEC TR 15504, published in 1998 in nine parts. It contained its own process model, an assessment model and guidance.

The full International Standard ISO/IEC 15504 followed between 2003 and 2006 in five parts, later extended with further parts for system life cycle processes, organisational maturity and other domains. An important design decision was made along the way: instead of owning a fixed list of processes, the standard would define a measurement framework and requirements, and borrow the processes from other standards, above all ISO/IEC 12207 for software life cycle processes and ISO/IEC 15288 for system life cycle processes. That decision made SPICE a general method that industries could tailor, and several did: Automotive SPICE for car electronics is the most widely used offspring, and others appeared for space, medical devices, testing and IT services.

From 15504 to 330xx

From 2015 the committee restructured the material into the ISO/IEC 330xx family. The new family keeps the SPICE ideas but separates them more cleanly into concepts, requirements, measurement frameworks, assessment models and guidance. It also generalises the method: capability is now one example of a "process quality characteristic", and the family allows other characteristics to be measured with their own frameworks. ISO/IEC 15504 parts were withdrawn step by step as their 330xx replacements appeared, the last widely used one being the exemplar software assessment model, Part 5, replaced in 2021. In everyday speech, people still say "SPICE" or "15504" when they mean this whole approach, and this tutorial does the same.

Two purposes, one method

The name itself states the two purposes. Process improvement is an organisation looking at its own processes to find strengths and weaknesses and decide what to change. Capability determination is someone, usually a customer, judging whether an organisation's processes are capable enough for a particular piece of work, and what risk remains if they are not. Both use the same assessment method and the same rating scale; what differs is who asks for the assessment, what they compare the results against and what they do with them afterwards.

Scope: what SPICE covers and what it does not

SPICE assesses processes, not products and not people. It does not tell you whether a particular release is free of defects, whether an individual engineer is skilled, or whether a company meets a regulation. It also does not prescribe how to do the work: it states what a process should achieve and what good management of that process looks like, and leaves methods, tools, templates and life cycle order to the organisation. That is why agile teams, plan-driven teams and mixed teams can all be assessed with it. Finally, SPICE is not limited to software: the 330xx family is written for any process domain, and assessment models exist for system engineering, testing, information security management, quality management and enterprise processes.

Lesson 2 – Key concepts and vocabulary

Process assessment has a precise vocabulary. Many misunderstandings in real assessments come from people using these words loosely, so it is worth learning them before looking at the structure. The definitions below are explanations in plain language, not the formal wording of ISO/IEC 33001.

Process – a set of related activities that turns inputs into outputs to achieve a purpose, for example requirements definition, project planning or configuration management.
Process assessment – a disciplined evaluation of an organisation's processes against a process assessment model, carried out by a team using objective evidence.
Process reference model (PRM) – a catalogue of processes, each described by its purpose and its outcomes (the observable results of achieving the purpose). ISO/IEC/IEEE 12207 plays this role for software.
Process measurement framework – the scale used to rate a process quality characteristic. For capability it is ISO/IEC 33020, with its capability levels and process attributes.
Process assessment model (PAM) – the working tool for assessors: it combines processes from a PRM with a measurement framework and adds indicators that show what evidence to look for. ISO/IEC TS 33061 is the PAM for software life cycle processes.
Process capability – how well a process is able to meet current or projected business goals consistently; the main characteristic SPICE measures.
Capability level – one of six points on the ordinal scale from Level 0 (incomplete) to Level 5 (innovating), each characterised by one or two process attributes.
Process attribute (PA) – a measurable property of a process that contributes to capability, such as PA 2.2 Work product management. Ratings are given to attributes, and levels are derived from them.
Assessment indicator – a sign an assessor uses to judge achievement. Performance indicators (base practices and the information or work products they produce) relate to Level 1; capability indicators (generic practices and resources) relate to the higher attributes.
Objective evidence – documents, records, tool data, observations and interview statements that show what really happens, as opposed to what people believe or wish happened.
Process instance – one specific occurrence of a process, for example the configuration management of one particular project. Assessors rate attributes by examining instances.
Process profile – the set of attribute ratings for the assessed processes, often shown as a table or bar chart with the derived capability level of each process.
Target capability profile – the capability a customer or the organisation itself wants for selected processes, against which an assessed profile is compared.
Assessment sponsor – the person or body who commissions the assessment, defines its purpose and receives the results.
Lead assessor – the competent assessor who is responsible for the assessment and confirms that it meets the requirements of ISO/IEC 33002.
Assessment class – the level of rigour of an assessment (Class 1, 2 or 3), which determines how much confidence and comparability its results can claim.

Three ideas that hold the vocabulary together

First, the separation between what a process must achieve (the PRM), how well it is managed (the measurement framework) and how an assessor recognises it (the indicators in the PAM). Second, the rule that ratings are based on objective evidence from real process instances, never on intentions or on the existence of a policy document alone. Third, the difference between a rating, which applies to one attribute of one process, and a level, which is derived from several ratings. When you hear someone say "we are a Level 3 company", treat it with care: SPICE results are first of all per process.

Lesson 3 – Structure of the 330xx family and the capability scale

How the documents fit together

The 330xx family is organised by the job each document does. Concept and requirement documents say what a conformant assessment and a conformant model must look like. Measurement frameworks provide the scales. Assessment models apply a framework to a specific set of processes. Guidance documents help people use the rest. The numbering follows these groups loosely, with the 3300x documents holding the core requirements, the 3302x documents the measurement frameworks and the 3306x and 3307x documents the domain models.

Figure 1 – The core of the ISO/IEC 330xx family: the concepts document, the requirements that shape the capability scale and the assessment models, and the guidance that supports assessment and improvement.

For a beginner, five documents matter most. ISO/IEC 33001 explains the concepts and gives the shared terminology. ISO/IEC 33002 sets the minimum requirements an assessment must meet for its results to be objective, consistent, repeatable and representative. ISO/IEC 33004 states what a process reference model, process assessment model or maturity model must contain to be usable in a conformant assessment. ISO/IEC 33020 is the capability scale. And a process assessment model, such as ISO/IEC TS 33061 for software, gives assessors the concrete indicators. Industry models like Automotive SPICE play the same role as TS 33061 for their own domain, declaring conformance with 33004 and using a capability scale based on 33020.

The two dimensions of an assessment

Every SPICE assessment looks at processes along two dimensions at once. The process dimension answers "which processes, and are they achieving their purpose?" It comes from a process reference model. For software, TS 33061 takes its processes from ISO/IEC/IEEE 12207, which groups them into agreement processes (acquisition and supply), organisational project-enabling processes (such as quality management and life cycle model management), technical management processes (such as project planning, risk management, configuration management and quality assurance) and technical processes (from stakeholder needs and requirements through architecture, design, implementation, verification, transition and validation to operation and maintenance). Older 15504-5 models used different groupings with three-letter prefixes such as ENG for engineering, MAN for management and SUP for support, and you will still meet them in older reports.

The capability dimension answers "how well is each process performed and managed?" It comes from the measurement framework, ISO/IEC 33020, and is the same for every process. That independence is the strength of the design: the same scale can rate requirements definition, configuration management or supplier management, so results across processes and across organisations become comparable.

Figure 2 – How the process dimension and the capability dimension combine in an assessment model, and how evidence turns into ratings and a profile.

The six capability levels

The capability scale in ISO/IEC 33020 has six levels. Each level is defined by one or two process attributes, giving nine attributes in total. The levels build on each other: a process cannot be reliably managed if it is not performed, and cannot be standardised across an organisation if it is not managed in at least one place.

Level 0 – Incomplete process – the process is not performed, or it fails to achieve its purpose. There are no attributes at this level; it is simply where a process sits if Level 1 is not reached.
Level 1 – Performed process – the process achieves its purpose and outcomes, even if in an ad hoc way. Attribute: PA 1.1 Process performance.
Level 2 – Managed process – the process is planned, monitored and adjusted, and its outputs are properly established, controlled and maintained. Attributes: PA 2.1 Performance management and PA 2.2 Work product management.
Level 3 – Established process – the process follows a defined standard process of the organisation, tailored for the situation, and is deployed with qualified people and suitable infrastructure. Attributes: PA 3.1 Process definition and PA 3.2 Process deployment.
Level 4 – Predictable process – the process is measured and understood quantitatively, and kept within defined limits using that data. Attributes: PA 4.1 Quantitative analysis and PA 4.2 Quantitative control.
Level 5 – Innovating process – the process is continually changed to meet business goals, with improvements identified from data and from new ideas and then introduced in a controlled way. Attributes: PA 5.1 Process innovation and PA 5.2 Process innovation implementation.

The older ISO/IEC 15504-2 used slightly different names at the top of the scale: Level 5 was called "optimizing", the Level 4 attributes were process measurement and process control, and PA 5.2 was process optimization. The idea was the same, and you will often see the old names in literature written before 2015.

Figure 3 – The six capability levels of ISO/IEC 33020 and the nine process attributes that define them; each level builds on the one below.

The rating scale and the level rule

Assessors rate each process attribute on a four-point ordinal scale based on the extent to which the attribute is achieved:

N – Not achieved – 0 to 15 percent achievement; little or no evidence.
P – Partially achieved – more than 15 up to 50 percent; some evidence, but aspects are unpredictable.
L – Largely achieved – more than 50 up to 85 percent; a systematic approach with significant achievement, though some weaknesses remain.
F – Fully achieved – more than 85 up to 100 percent; complete and systematic achievement without significant weaknesses.

ISO/IEC 33020 also allows a finer scale in which P and L are split at their midpoints into P-, P+, L- and L+, which helps when a lot of evidence sits near a boundary. The percentages are not calculated from a formula; they express the assessors' professional judgement about how much of the attribute is in place, supported by the indicators.

The capability level of a process follows a simple rule: a process reaches level n when the attributes of level n are rated at least L (largely) and all attributes of the levels below are rated F (fully). For example, if a project planning process has PA 1.1 = F, PA 2.1 = L and PA 2.2 = L, it is at Level 2. If PA 1.1 were only L, the process would stop at Level 1 however good its management, because Level 2 needs Level 1 to be fully achieved. Learners often get this rule backwards, so it is worth memorising: "the level you claim may be largely there, everything beneath it must be fully there".

When several process instances are assessed, for example the same process in three projects, the standard describes ways of aggregating instance ratings into one rating for the process. The method used must be decided in advance and recorded, because different aggregation choices can change the result.

Lesson 4 – How it works in practice

Starting with the assessment input

A SPICE assessment starts long before anyone is interviewed. ISO/IEC 33002 requires the sponsor and the lead assessor to agree an assessment input: the purpose of the assessment (improvement, capability determination or both), the scope (which processes, which organisational units, which projects as instances, and up to which capability level), the process assessment model and measurement framework, the assessment class, the constraints (time, availability of people, confidentiality), the roles and responsibilities, and how results will be reported and kept. Getting this right is the single biggest factor in whether an assessment is useful. A vague purpose leads to a vague report.

The process context is part of this preparation. It describes the size, domain, criticality and business situation of the organisational unit. A two-person team building internal tools and a two-hundred-person team building payment software both need configuration management, but what counts as adequate evidence for each is very different. Assessors judge achievement in context, not against an imaginary ideal.

The assessment activities

Once the input is agreed, the assessment moves through a sequence of activities. ISO/IEC 33002 names them in general terms, and ISO/IEC TS 33030 offers an exemplar documented process that organisations can tailor.

Figure 4 – The flow of a SPICE assessment from the sponsor's purpose to ratings and a report, and the two ways the results are used.

Planning – the lead assessor turns the input into a plan: team, schedule, interviewees, evidence requests, rating method and aggregation rules, and confidentiality arrangements.
Data collection – the team gathers objective evidence: it examines work products and records (plans, requirements, review records, change logs, test reports, repository histories), interviews the people who perform the process, and sometimes observes work as it happens. Evidence is mapped to the indicators in the PAM.
Data validation – the team checks that the evidence is sufficient, consistent and representative of the scope, often by presenting preliminary findings to participants and resolving contradictions.
Rating – the team rates each process attribute in scope using the N-P-L-F scale and the agreed method, and derives capability levels. Ratings are traceable to the evidence that supports them.
Reporting – the team presents the process profile, the main strengths and weaknesses, and, if agreed, recommendations, and produces an assessment record that documents the input, the evidence base and the ratings.

Roles and competence

The sponsor owns the purpose and receives the results. The lead assessor plans and leads the assessment and is accountable for its conformity. Assessors collect evidence and take part in rating. Participants are the people whose work is being examined; they provide evidence and validate findings. Many organisations also name an assessment coordinator on the assessed side to arrange interviews and evidence access. ISO/IEC 33002 sets competence expectations for the lead assessor, covering knowledge of the standards and the model, training, and practical assessment experience, but ISO itself does not certify people (Lesson 5 explains who does).

From findings to improvement

An assessment that ends with a report on a shelf has failed. ISO/IEC TR 33014, the technical report that guides process improvement, describes improvement as a cycle driven by business goals: understand why you want to improve, assess the current state, analyse the gaps against the desired state, plan and implement changes, check the effect, and sustain the gains. The capability levels are useful here because they suggest a natural order: stabilise the performance of a process (Level 1), then manage it (Level 2), then standardise it across the organisation (Level 3). Jumping straight to organisation-wide process definitions while projects still miss basic outcomes is a classic waste of effort.

Improvement work is easier when the evidence of a well-run process is a natural by-product of daily work rather than extra paperwork. A team that keeps its backlog, reviews, branches, builds and test runs in tools already produces most of the evidence an assessor needs for Level 1 and Level 2. The aim is not to produce documents for the assessor; it is to work in a way that leaves a trail.

Capability determination in practice

In capability determination, the starting point is a target capability profile: for example, a customer may require Level 2 for project planning, configuration management and quality assurance, and Level 3 for requirements definition on a safety-related project. The supplier is assessed, and the assessed profile is compared with the target. Each gap is translated into a risk statement, for example "configuration management at Level 1 means a risk of releasing unverified versions", and the customer decides whether to accept the risk, require an improvement plan, add contract controls, or choose another supplier. The supplier may also do this exercise on itself before a bid, as a self-check.

Lesson 5 – Assessment, certification and compliance

There is no "SPICE certificate" for an organisation

This point surprises many newcomers. Unlike ISO 9001 or ISO/IEC 27001, the 330xx family does not define a management system that a certification body audits and certifies. An assessment produces a process profile for a defined scope at a point in time, for a stated purpose. An organisation can truthfully say "our requirements and configuration management processes in the X product line were assessed at capability Level 2 in a Class 2 assessment in March", but it cannot honestly claim to be "SPICE certified" as a company. Any statement of results, whoever issues it, still describes the assessed scope rather than certifying the whole organisation.

Assessment classes and confidence

ISO/IEC 33002 defines three classes of assessment to match rigour to purpose. Class 1 is the most rigorous and is designed to give results that can be compared between organisations, for example when a buyer wants to compare competing suppliers. Class 2 gives moderate confidence and suits internal decisions and tracking improvement over time. Class 3 is the lightest and is intended mainly to generate improvement ideas or to give a quick view of the current situation. The classes differ in requirements such as the number of process instances examined, the independence and competence of the team, and the amount of corroborating evidence. The results of a Class 3 assessment should never be presented as if they had the confidence of a Class 1.

Independence and self-assessment

SPICE explicitly supports self-assessment, in which an organisation assesses itself with its own trained people. Self-assessments are valuable for improvement because they are cheap, frequent and build internal understanding. For capability determination, customers usually want an independent assessment, in which the lead assessor is not part of the assessed organisation and has no stake in the result. Both kinds must still follow the 33002 requirements if they claim conformity.

Who certifies assessors

Although organisations are not certified, assessors often are. The most established scheme is run by intacs (the International Assessor Certification Scheme association), a non-profit body that defines training syllabi, examinations and experience requirements for assessor grades such as provisional and competent assessor, and for instructors. For Automotive SPICE, the VDA QMC certification office runs the examinations and certifies assessors on the basis of the intacs rules. Every assessor starts at the provisional grade; a competent assessor has added further training and documented assessment experience; customers in regulated or high-risk supply chains often require that the lead assessor holds such a grade. Other national or industry schemes have existed over the years, so check what your customer or sector expects.

Verifying conformity

A conformant assessment is one that meets the requirements of ISO/IEC 33002, uses a model that meets ISO/IEC 33004 and a measurement framework that meets ISO/IEC 33003 (as ISO/IEC 33020 does). In practice the evidence of conformity is the assessment record: the documented input, the team and their competence, the evidence base, the rating method, the ratings and their traceability. If a customer questions a result, the record is what is examined. This is why experienced lead assessors are strict about keeping it complete, even for a small internal assessment.

Common misreadings of results

Three misreadings appear often. The first is treating a level as permanent: process capability can decline after a reorganisation or the loss of key people, and an old profile says little about today. The second is generalising from a narrow scope: a Level 3 result for two projects in one business unit says nothing about other units. The third is reading a profile as a score to maximise rather than a description of risk: a supplier at Level 2 in the processes that matter for a project may be a better choice than one at Level 3 in processes that do not.

Lesson 6 – Worked example: a payments software supplier

The situation

Kestrel Systems (a fictional company) employs 120 people and builds payment-processing software for banks. A large bank wants to award Kestrel a three-year contract to modernise its card authorisation platform. The bank's supplier management policy says that for critical software suppliers it requires a process capability assessment based on the ISO/IEC 330xx family, with a target profile of Level 2 for project planning, project assessment and control, configuration management, quality assurance and the software requirements definition process. Kestrel has never been assessed. Its head of engineering, Priya, is asked to prepare the company.

Step 1 – Understand the target and scope

Priya first reads the bank's request carefully. The bank wants capability determination, not improvement advice; it names the processes, the target levels and the assessment model (ISO/IEC TS 33061), and it requires an independent lead assessor holding a competent assessor grade and a Class 2 assessment covering two current projects as instances. Priya agrees the scope with the bank: the card platform team and the merchant gateway team, both of which use the same development practices that the new contract would use.

Step 2 – A light self-assessment

Before inviting external assessors, Priya runs a Class 3 self-assessment with two internal staff who have attended an assessor training course. Over two weeks they review work products in both projects and interview team leads, developers, testers and the product owner. Their preliminary profile looks like this:

Software requirements definition – PA 1.1 L, PA 2.1 P, PA 2.2 P. Requirements exist as backlog items, but acceptance criteria are missing on about a third of them and traceability to tests is patchy.
Project planning – PA 1.1 F, PA 2.1 L, PA 2.2 L. Release planning is strong; resource planning for the platform team is informal.
Project assessment and control – PA 1.1 F, PA 2.1 L, PA 2.2 F. Sprint reviews and a monthly steering report work well.
Configuration management – PA 1.1 F, PA 2.1 P, PA 2.2 L. Git and the build pipeline are solid, but baselines for releases are not formally defined and nobody owns configuration management for the gateway project.
Quality assurance – PA 1.1 P, PA 2.1 N, PA 2.2 N. Quality checks happen in code review, but no one independently checks that the agreed process is followed, and QA findings are not tracked.

Applying the level rule, project planning and project assessment and control are already at Level 2. Configuration management is at Level 1 because PA 2.1 is only partially achieved. Requirements definition is at Level 1 at best, with a weak PA 1.1 that must reach F before Level 2 can count. Quality assurance is at Level 0, because PA 1.1 is not even largely achieved.

Step 3 – Improvement plan driven by the gaps

Priya does not try to fix everything at once. She orders the work by the level rule: first get each process fully performed, then managed. The plan, agreed with management, has four actions over four months:

Requirements: add a definition of ready to the backlog workflow so every item has acceptance criteria before a sprint, and link test cases to requirements in the test tool. Plan and track the requirements work in sprint planning and reviews. Target PA 1.1 F, PA 2.1 L and PA 2.2 L.
Quality assurance: appoint a part-time QA lead from the testing group, independent of the projects' delivery management, who checks process adherence monthly against a short checklist and records findings with owners and due dates in a controlled QA log. Target PA 1.1 F, PA 2.1 L and PA 2.2 L.
Configuration management: define release baselines and branch rules in the engineering handbook, name a configuration manager per project, and add a pipeline step that records the exact component versions of each release. Target PA 2.1 L.
Planning: add a simple capacity plan for the platform team and review it at each planning event. Target PA 2.1 F.

Priya is careful that the changes produce real behaviour, not documents for the assessor. For example, the QA checklist has only twelve questions, and its findings appear in the same issue tracker as other work so they are actually followed up.

Step 4 – The independent assessment

Four months later, the bank's chosen lead assessor and one co-assessor run the Class 2 assessment over four days. They review evidence from the last three sprints of both projects, interview about twenty people and hold a validation session on day three, where two findings are corrected after the gateway team shows release records the assessors had missed. The final profile shows Level 2 for project planning, project assessment and control, configuration management and requirements definition. Quality assurance reaches Level 1 with PA 1.1 F, but PA 2.1 is rated P because the QA lead's activities started only six weeks earlier and have no planning history yet, and PA 2.2 is rated P because QA records are not yet reviewed for completeness.

Step 5 – Capability determination and next steps

The bank compares the assessed profile with its target. Four of five processes meet the target; quality assurance falls one level short. The bank's supplier risk team describes the risk: without managed quality assurance, deviations from the agreed process might go unnoticed during the contract. Rather than reject Kestrel, the bank awards the contract with conditions: a follow-up assessment of quality assurance within nine months, and monthly QA reports to the bank in the meantime.

Inside Kestrel, Priya now uses the same profile for improvement. She plans to bring quality assurance to Level 2 and then, over the next year, to define a company-wide standard process for requirements and configuration management so that new teams start from a proven baseline, the first step toward Level 3. The example shows the core SPICE habits: a clear purpose and scope, evidence-based ratings, the level rule used to order improvements, and results expressed as risk for the people who must decide.

Lesson 7 – Relationship to other standards and frameworks

SPICE among its neighbours

SPICE does not stand alone. It borrows its processes from life cycle standards, shares ideas with maturity models, and has inspired industry-specific variants. Understanding these relationships helps you avoid duplicated effort and explain results to people who know a different framework.

Figure 5 – Where SPICE sits: life cycle standards supply its processes, domain variants build on it, and other frameworks assess or certify the same organisations in different ways.

Standard or framework	What it is	Relationship to SPICE
ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288	Life cycle process standards for software and for systems	Provide the process reference models (purposes and outcomes) that 330xx assessment models such as TS 33061 build on; they describe processes, SPICE measures their capability.
CMMI (owned by ISACA)	A proprietary capability and maturity model with its own appraisal method and certified appraisers	Shares the idea of capability and maturity levels and grew from the same CMM roots; it is not an ISO standard and has its own practice areas, rating rules and appraisal scheme, so results are not directly interchangeable.
Automotive SPICE (VDA QMC)	A process assessment model for automotive embedded systems development	A domain variant that declares conformance with the 330xx requirements and uses a capability scale based on ISO/IEC 33020; it adds its own process set, rules and assessor scheme.
ISO 9001	Requirements for a quality management system, certifiable by accredited bodies	Certifies that a management system exists and works; SPICE rates individual processes on a capability scale. Many organisations use both, with SPICE giving deeper insight into engineering processes.
ISO/IEC 29110	Life cycle profiles and guides for very small entities	Offers lighter-weight profiles and its own assessment guide for organisations of up to about 25 people; it draws on the same assessment ideas but is scaled down.
ISO/IEC 20000-1	Requirements for an IT service management system, certifiable	Service management processes can be assessed with 330xx-style models; the earlier 15504 series had a part for this domain.

SPICE and CMMI in more detail

Because both rate capability and both originated in the software process movement of the 1990s, SPICE and CMMI are often compared. SPICE is an international standard in which the process dimension and the capability dimension are separate, so each process gets its own capability level, and the results describe a profile. CMMI is a proprietary model, now owned by ISACA, that groups its content into practice areas and is most commonly used to obtain an organisational maturity level through its own appraisal method. An organisation that has a CMMI appraisal can reuse much of its evidence for a SPICE assessment and the other way round, but the ratings must be produced by each method's own rules.

Industry variants

The flexibility of the 330xx design, in which a domain supplies its own processes and reuses the measurement framework, explains the number of SPICE variants. Automotive SPICE is by far the most widespread and is expected by most carmakers from their electronics and software suppliers. Other variants and models have been developed for medical device software, for space projects, for software testing (ISO/IEC 33063 and the industry model TestSPICE) and for enterprise and IT service processes. When you meet one, look for its declared conformance with 33004 and a measurement framework based on 33020 (or another framework conforming to 33003); if it has that, everything in this tutorial about levels, attributes and ratings will still apply.

SPICE and agile ways of working

A frequent question is whether SPICE fits agile teams. The 330xx models describe outcomes and management attributes, not a life cycle, so an agile team can show planning through release and sprint planning, monitoring through reviews and burn-down data, and work product management through version control and definitions of done. The challenge is usually evidence: agile teams must be able to show, not just tell, that these things happen consistently. Experienced assessors look for this evidence in the team's tools rather than in separate documents.

Common pitfalls and best practices

Pitfalls

Chasing a number – treating "reach Level 3" as the goal leads to paperwork that satisfies assessors for a week and changes nothing. Start from business goals and risks.
Vague assessment input – without a clear purpose, scope, class and model, the team collects the wrong evidence and the sponsor cannot use the results.
Skipping levels – writing organisation-wide standard processes while projects still miss basic outcomes; the level rule means Level 3 effort is wasted if Level 1 and Level 2 are not fully in place.
Rating intentions instead of evidence – accepting a policy or a template as proof that a process is performed and managed, without records from real process instances.
Overstating results – presenting a Class 3 self-assessment as if it were an independent Class 1, or extending a narrow-scope result to the whole company.
Report on a shelf – finishing the assessment without an owner, a plan and follow-up for the findings.

Best practices

Agree the input in writing – purpose, scope, instances, target levels, model, class, rating and aggregation method, and confidentiality, before any interview is scheduled.
Use the level rule to order improvements – first make processes fully performed, then managed, then standardised.
Let evidence come from daily tools – backlogs, repositories, pipelines and trackers already hold most of what assessors need if the team uses them consistently.
Validate findings with participants – a short validation session catches misunderstandings and builds trust in the result.
Choose competent, appropriately independent assessors – match their grade and independence to the purpose and the customer's expectations.
Express results as risk – translate gaps against the target profile into business risks so decision-makers can act on them.
Reassess periodically – capability changes over time; schedule follow-ups to confirm that improvements have taken hold.

Summary and key takeaways

SPICE is the international approach to process assessment that started as ISO/IEC 15504 and continues as the ISO/IEC 330xx family; the core 15504 parts are withdrawn.
It serves two purposes with one method: process improvement for the organisation itself and capability determination for a customer or sponsor.
Assessments combine a process dimension from a reference model with a capability dimension from ISO/IEC 33020, using indicators from a process assessment model.
The capability scale has six levels, Incomplete to Innovating, defined by nine process attributes rated N, P, L or F.
A process reaches a level when that level's attributes are at least largely achieved and all lower attributes are fully achieved.
ISO/IEC 33002 sets the requirements for a conformant assessment, including the input, activities, roles and the three assessment classes.
Organisations are not certified to SPICE; they receive scoped, dated process profiles, while assessors can be certified by schemes such as intacs.
The value of SPICE lies in evidence-based findings that drive a prioritised improvement plan or an informed decision about supplier risk.

Reflection questions

Pick one process in your own organisation, such as release management or requirements handling. What objective evidence would you show an assessor for PA 1.1, PA 2.1 and PA 2.2, and where are the gaps?
Your customer asks for "SPICE Level 3". What questions would you ask before agreeing, and how would you turn the request into a precise target profile?
Would a Class 3 self-assessment or an independent Class 2 assessment serve your organisation better this year? Explain the purpose that drives your choice.
Think of an improvement initiative that produced documents but no change in behaviour. How could the level rule and an evidence-based approach have prevented that?
If your organisation already holds ISO 9001 certification or a CMMI appraisal, which parts of that work could support a SPICE assessment, and what would still be missing?