SPICE for Space: SPICE for Space – Tutorial (about 60 minutes)

SPICE for Space, usually written S4S or "SPiCE for SPACE", is the software process assessment and improvement scheme of the European space sector. It takes the international SPICE approach (ISO/IEC 15504) and adds what European space standards demand of software suppliers, so that customers can judge how capable a supplier's software processes are and suppliers can find out what to improve. After this tutorial you will be able to read an S4S capability profile, explain how an assessment is planned, performed and rated, and plan a realistic improvement path for a space software team.

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

Course overview

Edition and status: S4S is defined by the handbook ECSS-Q-HB-80-02, "Space product assurance – Software process assessment and improvement", published in two parts by the European Cooperation for Space Standardization (ECSS) through the ESA Requirements and Standards Division: Part 1A – Framework and Part 2A – Assessor instrument, both dated 8 October 2010 and listed as active handbooks. CEN and CENELEC republished them in 2021 as the European technical reports CEN/CLC/TR 17602-80-11 (framework) and CEN/CLC/TR 17602-80-12 (assessor instrument). We found no later edition of the handbook. The handbook supports clause 5.7 of the software product assurance standard ECSS-Q-ST-80C, whose current revision is Rev.2 dated 30 April 2025. Be aware that the 2010 handbook is built on ISO/IEC 15504 (2003–2006 editions), which ISO and IEC have since replaced with the ISO/IEC 330xx process assessment family; the concepts carry over, but check which references your contract names. Verified 2026-10-29 from the handbook text, the ECSS catalogue entries, the CEN/CLC catalogue and ESA Bulletin 107 (the ECSS website itself was temporarily unavailable that day).

Who it is for: software engineers, software product assurance and quality staff, project managers and supplier-quality people in space agencies, prime contractors and software companies who are new to process assessment, and anyone moving into the space sector from automotive, aviation, rail or defence.

Prerequisites: none. A rough idea of how software is developed (requirements, design, code, test) helps; every assessment term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why ESA and the European space industry created S4S and how it relates to SPICE and the ECSS standards.
You will be able to describe the two dimensions of the S4S model: its process groups and its six capability levels with nine process attributes.
You will be able to apply the N-P-L-F rating scale and derive a capability level from attribute ratings.
You will be able to distinguish the three assessment purposes: process improvement, capability determination and ECSS conformance.
You will be able to outline the assessment activities, the roles involved and the competence expected of assessors.
You will be able to use target profiles based on software criticality to plan improvements.
You will be able to position S4S against ISO/IEC 330xx, Automotive SPICE, CMMI and ECSS-Q-ST-80C.

Lesson 1 – Origins, purpose and scope

Why space software needs process assessment

Software flies on almost every spacecraft and runs almost every ground segment. It controls attitude and orbit, handles telecommands, manages power and thermal systems, processes payload data and schedules operations. Once a satellite has been launched, there is no technician who can walk up to it. A software fault can be patched only if the system was designed for in-flight updates, and some faults end a mission before anyone can react. At the same time, space software is rarely written by a single organisation. An agency places a contract with a prime contractor, the prime subcontracts subsystems to equipment suppliers, and those suppliers often subcontract software to specialist companies. The customer at the top of that chain needs confidence that every software team below it works in a disciplined way.

Testing the finished product is necessary but never enough. Testing can show the presence of defects, not their absence, and for highly critical software the space of possible states is too large to cover completely. Customers therefore look at how the software is produced: are requirements analysed and traced, is the design reviewed, is configuration controlled, are problems tracked to closure, is verification independent where the risk demands it? Process assessment is the disciplined way of answering such questions with evidence instead of impressions.

From SPICE to S4S

In the 1990s an international initiative called SPICE (Software Process Improvement and Capability dEtermination) developed what became the ISO/IEC 15504 standard for process assessment. SPICE offered a common measurement scale for process capability and a set of rules for performing assessments, so that results from different assessors could be compared. It deliberately did not prescribe one way of developing software; it defined what a capable process must achieve and how to rate it.

ESA saw that the European space industry could benefit from this approach, but also that space programmes had their own requirements. ESA software projects must follow the ECSS standards, in particular the software engineering standard (today ECSS-E-ST-40C) and the software product assurance standard (today ECSS-Q-ST-80C). As part of an ESA-sponsored software process improvement programme, the company SYNSPACE, the UK firm InterSPICE and ESA's Product Assurance and Safety Department developed an assessment method conformant with the then technical report ISO/IEC TR 15504 and tailored to ECSS. ESA Bulletin 107 (August 2001) reports four pilot assessments of space software projects in late 1999, followed by trial assessments in 2000 and 2001 at space software suppliers in seven European countries. The method also included a software tool, report templates and a process improvement method.

The early S4S model kept the ISO exemplar processes and practices and added space-specific content wherever ECSS asked for something the exemplar model did not cover. The most visible additions were independent software verification and validation, safety and dependability assurance, contract maintenance and information management. In 2010 the method was published as the ECSS handbook ECSS-Q-HB-80-02, now aligned with the later ISO/IEC 15504 parts and their exemplar process assessment model.

Figure 1 – Where S4S comes from: the ISO/IEC 15504 exemplar model plus ECSS space requirements, published as the two parts of ECSS-Q-HB-80-02.

What S4S is for

The handbook names four uses. An organisation can use S4S to understand the state of its own processes, to check whether its processes are suitable for a particular kind of requirement or contract, to evaluate another organisation's processes before or during a contract, and to improve weaknesses it has found. Customers gain a way to identify supplier risks before contract award and to put controls in place for those risks. Suppliers gain a structured route to better processes and evidence they can show customers.

Scope and limits

S4S covers software processes: the activities of acquiring, supplying, engineering, operating and maintaining software, together with the supporting, management, improvement, resource and reuse activities around them. It does not certify a product, it does not replace the requirements of ECSS-E-ST-40C or ECSS-Q-ST-80C, and it does not tell you which design method or programming language to use. The ECSS standards state requirements on processes; S4S turns those requirements into an assessment model so that someone can measure how well an organisation meets them. The handbook is addressed to quality managers, project managers and process improvement managers in organisations already in the space domain or planning to enter it.

Lesson 2 – Key concepts and vocabulary

Process assessment has its own vocabulary, and S4S uses the ISO/IEC 15504 terms almost unchanged. The handbook also notes where an ISO term matches an ECSS term, which helps space engineers translate. Learn these terms well; the rest of the course builds on them.

Process – a set of interacting activities that transforms inputs into outputs, such as software requirements analysis or configuration management.
Process reference model (PRM) – a catalogue of processes, each described by its purpose and its outcomes, plus the architecture that relates the processes to each other.
Process assessment model (PAM) – the detailed model assessors actually use: the reference processes plus indicators that show whether outcomes and capability are achieved. Part 2 of the handbook contains the S4S PAM.
Process dimension – the set of processes in the model, grouped into categories and groups.
Capability dimension – the measurement scale of six capability levels and nine process attributes, applicable to any process.
Process outcome – an observable result of performing a process successfully, for example "software requirements are defined and agreed".
Base practice (BP) – an activity that, when performed consistently, contributes to the purpose of one specific process. In ECSS language it corresponds to a detailed activity or task.
Work product – an artefact used, produced or changed by a process, such as a software requirements specification, a test report or a problem report. It corresponds to what ECSS calls an expected output.
Generic practice – a management activity that supports one process attribute at Levels 2 to 5 and applies to every process, for example planning the performance of the process.
Process attribute (PA) – a measurable characteristic of process capability, such as performance management or process definition. Each capability level is defined by one or two attributes.
Organizational unit (OU) – the part of an organisation that is assessed: a project, a group of related projects, a department or a whole small company.
Process profile and capability profile – the attribute ratings for one assessed process, and the resulting capability levels across all assessed processes.
Target capability profile – the level an organisation or customer wants each process to reach, used for capability determination and for setting improvement goals.
Software criticality category – the ECSS classification of software (A to D) by the severity of the consequences its failure can cause, from catastrophic (A) to minor or negligible (D).
Independent software verification and validation (ISVV) – verification and validation performed by a team that is organisationally independent of the developer, used for highly critical space software.
Competent assessor and provisional assessor – an assessor who has shown the competence to lead conformant assessments, and an assessor who is trained but works under a competent assessor's guidance.
Mandatory indicator – in an ECSS conformance assessment, a base practice or work product that traces to an ECSS requirement applicable to the project, and which therefore must be present.

Two families of indicators deserve a closer look. Process performance indicators (base practices, work products and work product characteristics) tell the assessor whether a process achieves its outcomes. Process capability indicators (generic practices, generic resources, generic work products and related processes) tell the assessor how well the process is managed, defined, measured and improved. Indicators support the assessor's judgement; they are not a checklist in which every line must be ticked, except in the special case of ECSS conformance assessments described in Lesson 5.

Lesson 3 – Structure of the handbook and the model

Two parts, one scheme

Part 1, the framework, explains the organisation and purpose of S4S, its relation to the ECSS and ISO/IEC standards, the process assessment model at a high level, the assessment method, assessor competence, the process improvement method, and the rules for recognising assessment schemes and results. Its annexes propose target profiles by software criticality and give recommended contents for the assessment plan, the assessment report and the assessor record.

Part 2, the assessor instrument, is the working tool. For every process it gives the identifier, name, purpose, outcomes and notes, followed by base practices and input and output work products. Its annexes contain a statement of conformance with ISO/IEC 15504, the links between S4S work products and ECSS expected outputs, and traceability from each base practice to the ECSS clauses it reflects. That traceability is what lets an assessor move from "this project follows ECSS-Q-ST-80C" to "these are the practices I should expect to see".

The process dimension

The S4S process dimension follows the structure of the ISO/IEC 15504-5 exemplar model, which in turn follows the software life cycle processes of ISO/IEC 12207. Processes sit in three categories and nine groups. In the 2010 handbook there are 52 processes, four of which were added to the ISO set to cover ECSS requirements.

Figure 2 – The three process categories and nine process groups of the S4S model, with the number of processes in each group.

A short tour of the groups:

Acquisition (ACQ) – what a customer does to buy software: preparing the acquisition, selecting a supplier, agreeing the contract, monitoring the supplier and accepting the product. S4S adds ACQ.6 Contract maintenance, covering how contract changes are proposed, answered and agreed, which matters in long space programmes where requirements evolve.
Supply (SPL) – what a supplier does: tendering, releasing the product and supporting the customer's acceptance.
Operation (OPE) – operational use of the software and support to its users, important for ground segments and mission operations.
Engineering (ENG) – the technical core, from requirements elicitation and system requirements analysis through system architecture, software requirements, design, construction, integration and testing, to system integration and testing, installation and maintenance (ENG.1 to ENG.12).
Supporting (SUP) – processes that give assurance that work products and processes meet their plans and provisions: quality assurance, verification, validation, joint review, audit, product evaluation, documentation, configuration management, problem resolution and change request management. S4S adds SUP.11 Safety and dependability assurance and SUP.12 Independent software verification and validation.
Management (MAN) – organisational alignment, organisation management, project management, quality management, risk management and measurement. S4S adds MAN.7 Information management, which deals with identifying the information people need and maintaining a reliable information system for it.
Process improvement (PIM), Resource and infrastructure (RIN) and Reuse (REU) – establishing, assessing and improving processes; people, training, knowledge and infrastructure; and systematic reuse of software assets.

The two added supporting processes show the space flavour of S4S most clearly. Safety and dependability assurance expects the supplier to define a strategy for critical software, analyse the criticality of software components, keep those analyses up to date as the design changes, and apply and verify extra measures for critical items. ISVV expects the scope and degree of independence to be agreed with the customer, an independent team to be set up and planned, and its activities to run throughout development and be reported. Beyond the four new processes, ECSS-specific base practices, work products and explanatory notes are spread throughout the existing ISO processes.

The capability dimension

The capability dimension is taken from ISO/IEC 15504-5 without space-specific changes. It defines six capability levels, each building on the one below, and nine process attributes that define what each level requires.

Figure 3 – The six capability levels of S4S and the process attributes that define each level from 1 upwards.

Level 0 – Incomplete: the process is not implemented or does not achieve its purpose; there is little evidence of systematic achievement.
Level 1 – Performed: the process achieves its outcomes (PA 1.1 Process performance). The work gets done and the expected work products exist, even if it depends on individual effort.
Level 2 – Managed: performance is planned, monitored and adjusted (PA 2.1 Performance management), and work products are defined, controlled and reviewed (PA 2.2 Work product management).
Level 3 – Established: the project uses a defined process tailored from an organisational standard process (PA 3.1 Process definition), and that defined process is deployed with competent people, resources and infrastructure and with data collected for improvement (PA 3.2 Process deployment).
Level 4 – Predictable: measurement objectives and quantitative performance objectives are set and used (PA 4.1 Process measurement), and the process is kept within control limits, with special causes of variation analysed and corrected (PA 4.2 Process control).
Level 5 – Optimizing: improvement objectives are derived from business goals and innovations are identified (PA 5.1 Process innovation), and changes are introduced in a controlled way and evaluated against results (PA 5.2 Process optimization).

Rating attributes and deriving a level

Assessors rate each process attribute on a four-point scale. N (Not achieved, 0–15 %) means little or no evidence. P (Partially achieved, above 15 % up to 50 %) means some evidence of a systematic approach, with unpredictable aspects. L (Largely achieved, above 50 % up to 85 %) means a sound systematic approach with significant achievement, though performance may vary in some areas. F (Fully achieved, above 85 % up to 100 %) means a complete and systematic approach without significant weaknesses across the organisational unit.

The rule for turning ratings into a level is simple and worth memorising. A process reaches a given level when the attributes of that level are rated at least Largely and the attributes of all lower levels are rated Fully. For example, Level 2 requires PA 1.1 to be F and PA 2.1 and PA 2.2 to be L or F. Level 3 requires PA 1.1, PA 2.1 and PA 2.2 to be F and PA 3.1 and PA 3.2 to be L or F. If PA 1.1 itself is only N or P, the process is at Level 0 whatever the other ratings say.

Ratings found	Resulting level	Why
PA 1.1 = L	1	Level 1 needs PA 1.1 at L or F; higher levels need PA 1.1 at F.
PA 1.1 = F, PA 2.1 = L, PA 2.2 = F	2	Both Level 2 attributes are at least L.
PA 1.1 = F, PA 2.1 = L, PA 2.2 = F, PA 3.1 = F, PA 3.2 = F	2	Level 3 needs both Level 2 attributes at F; PA 2.1 is only L.
PA 1.1 = F, PA 2.1 = F, PA 2.2 = F, PA 3.1 = L, PA 3.2 = L	3	Lower levels fully achieved and Level 3 attributes at least L.

The third row is a common surprise: a team can have a good standard process and still be rated Level 2, because its project planning or work product control has a weakness that keeps a lower attribute at L.

Lesson 4 – How it works in practice

Three reasons to assess

S4S recognises three assessment purposes. The first two come from ISO/IEC 15504; the third is specific to the space scheme.

Process improvement – an organisation characterises its current practice, identifies strengths, weaknesses and risks, and uses them to prioritise changes. Results are usually for internal use.
Process capability determination – the capability of selected processes is analysed, normally against a target profile, to identify the risks of using those processes on a particular project or contract. Customers use it to select or monitor suppliers; suppliers can also use it to support bids.
ECSS conformance – an organisation or project determines whether its processes conform to the ECSS requirements that apply to it. The activities are the same as in the other purposes, but data collection and rating are stricter (see Lesson 5).

The assessment process

Part 1 defines the assessment process in detail, with numbered tasks, the responsible role, and the inputs and outputs of each task. Some tasks are marked as recommended rather than required. That distinction matters: when an assessment is used to claim compliance with ECSS-Q-ST-80C, only the steps and activities marked as recommended may be omitted or changed.

Figure 4 – The eight activities of an S4S assessment, including the loop back from validation to data acquisition when evidence is incomplete.

Initiation. The sponsor and the assessment team leader agree the purpose, the scope (organisational unit, processes and the highest capability level to investigate), the context (size, domain, criticality of the products), the constraints, the ownership of the results and the confidentiality rules. They map the organisation's own process names onto the S4S processes and choose the participants.
Planning. The team leader produces the assessment plan: schedule, data collection approach, interviews, documents to examine and, for a conformance assessment, the list of mandatory indicators.
Briefing. Participants are told what the assessment is for, how it works and how their information will be used. This is recommended rather than mandatory, but skipping it usually makes interviews tense and less useful.
Data acquisition. Assessors collect objective evidence through interviews with the people who do the work and by examining work products such as plans, specifications, reviews, test records and configuration logs.
Data validation. The team checks that the evidence is sufficient, consistent and representative of the scope. Gaps lead back to more data collection.
Process rating. The team first agrees and documents how it will reach decisions (for example consensus or majority vote), then rates each process attribute in scope on the N-P-L-F scale from the recorded evidence and derives process profiles and capability levels.
Reporting and recording. Results are presented to the organisation, a report is delivered, and an assessment record is kept with the inputs, the evidence base and the ratings.
Inputs to risk management. Recommended: weaknesses found in the processes are passed to the project or organisational risk management process, and risk information is used to justify improvement actions.

Who does what

The method defines clear roles. The assessment sponsor commissions the assessment, approves its inputs and ensures that people and resources are available; the sponsor also verifies that the team leader is competent. The local assessment coordinator is the contact inside the assessed organisation who arranges logistics, documents and interview slots. The assessment team leader, who must be a competent assessor for a conformant assessment, plans and directs the work, guides the team in applying the model and rating, and verifies at the end that the S4S rules were met. Other assessors may be competent or provisional; technical specialists can join to bring domain knowledge; observers may attend without taking part in rating; and assessment participants are the staff of the organisational unit who are interviewed and provide evidence.

The improvement cycle

An assessment that is not followed by change is an expensive snapshot. Part 1 therefore includes a process improvement method based on the improvement cycle of ISO/IEC 15504, with guidance adapted to space software organisations.

Figure 5 – The eight-step S4S process improvement cycle, which starts from business goals and returns to them after improvements are sustained.

The cycle starts with business goals, not with capability levels: top management states which quality, cost, schedule or product problems matter most. An improvement programme is then set up with its own plan, budget and roles. An assessment provides the baseline. The team analyses the assessment output, compares the actual profile with the target profile, groups the gaps into improvement projects and plans them. Improvements are implemented, often first on a pilot project, then confirmed (for example by a focused re-assessment or by measurements), sustained by making them part of the standard process and training, and finally monitored over time.

The handbook names the roles here too: top management sets direction and keeps commitment; an improvement programme manager runs the whole programme; improvement project leaders run individual improvement projects; a software process improvement group (SPIG) does much of the process design work; process owners are responsible for individual processes; and the staff of the organisational unit actually change how they work.

The handbook is also frank about why improvement fails. Its failure factors include purely top-down or purely bottom-up programmes, an unsuitable pilot project, relying only on training or only on tools, chasing capability levels instead of business benefits, promising too much, and results that arrive too late to keep people interested. Its success factors mirror these: management commitment, attention to values and behaviour, early short-term benefits, baseline data, an open information policy, well-chosen pilots, incremental rollout, coaching, teamwork and recognition of people's efforts.

Lesson 5 – Assessment, certification and compliance

Where S4S becomes a requirement

S4S is a handbook, and ECSS handbooks are guidance rather than requirements. It becomes binding through the software product assurance standard ECSS-Q-ST-80C when a contract makes that standard applicable. In the 2009 issue of ECSS-Q-ST-80C, clause 5.7 asks, in summary, that the supplier monitors and controls how effective its software processes are; that the assessment model and method are documented; that assessments and models conform to the ISO/IEC 15504 requirements for performing an assessment; that the model, method, scope, results and assessors are checked against the project's requirements; that assessments carried out with ECSS-Q-HB-80-02 are led by a competent assessor; and that assessment results feed a documented improvement process with evidence of improvement. A note in that issue says the CMMI model may also be used if the SCAMPI A appraisal method is applied. Later revisions of the standard update these references, for example because ISO/IEC 15504 has been replaced by the ISO/IEC 330xx family, so always read the revision that your contract cites.

The handbook then offers itself as one clear and proven way of meeting clause 5.7, while allowing alternative methods that meet its recognition rules. A note in clause 5.7 also says that assessment and improvement done at organisation level can be used as evidence for a project; a supplier does not necessarily need a new assessment for every contract, provided the scope and context fit.

Assessor competence

The handbook defines two levels of assessor competence. A provisional assessor has the required education, training (including S4S-specific training) and experience but has not necessarily taken part in S4S assessments. A competent assessor has also taken part in conformant S4S assessments and keeps a record of education, training and experience. Team members may be provisional or competent; the team leader must be competent, and the sponsor verifies this. To build up experience, a provisional assessor may act as team leader only while supervised by a competent assessor. Competence is maintained through continued education, professional activity and further assessments, recorded in the assessor's log.

The handbook gives an example of concrete criteria rather than a fixed rule. In that example, a provisional assessor needs a technical or numerate degree, at least three years of recent relevant experience (highly critical software, safety-related systems or space systems) and a passed S4S assessor course with examination, while a competent assessor needs at least six years of such experience. The example experience requirements for a competent assessor are of the order of four S4S assessments and 120 assessment hours within two years, including two as team leader. The handbook also describes how a certification body could certify assessors, and notes that certification is one way, not the only way, to verify competence.

Recognition of schemes and results

Clause 8 of Part 1 answers a practical question: what if a supplier was assessed with something other than S4S? Use of S4S itself is recognised when the method of Part 1 and the model of Part 2 have been applied as described, without tailoring, by competent assessors. Another scheme can be recognised when its assessment model declares its scope (reference model, processes and capability levels), uses indicators that address the purposes and outcomes of the S4S processes and the process attributes, and maps its elements clearly and completely to the S4S processes and attributes. Its assessment method must follow a documented process, define the assessment inputs before data collection and have them approved by the sponsor, and be led by a competent assessor. The handbook names CMMI and the ISO/IEC 15504-5 exemplar model as examples of other schemes, and stresses that such schemes generally do not cover all ECSS-specific requirements, so the gaps (for instance ISVV or safety and dependability assurance) must be addressed separately.

ECSS conformance assessments

The conformance purpose changes how indicators are used. In improvement or capability determination assessments, indicators guide the assessor's professional judgement and are not verified one by one. In an ECSS conformance assessment, every base practice or work product that traces to an ECSS requirement applicable to the project becomes a mandatory indicator. During planning, the team leader, with the local coordinator, studies the contract and in-house rules, takes into account any project tailoring of the ECSS standards (requirements may be deleted, added or modified), and lists the mandatory indicators using the traceability tables in Part 2. During data collection, participants are interviewed separately to corroborate evidence, and the data collection takes longer than in other assessments. During rating, PA 1.1 can only be rated Largely or Fully if all mandatory indicators are present. Activities that the project legitimately tailored out are treated as not defined for that process, rather than as failures.

Target profiles and software criticality

Annex A of Part 1 proposes target capability profiles for software criticality classes A to D. They were derived by identifying typical risks of space projects, the processes that mitigate each risk, and how severe each risk is. The pattern is intuitive: the more critical the software, the higher the proposed target. For example, the proposed target for independent software verification and validation is Level 4 for class A, 3 for class B, 2 for class C and 0 for class D, while software requirements analysis is proposed at 4, 3, 3 and 2. These profiles are informative proposals. A customer and supplier agree the actual targets, which may differ for good reasons.

Is there an S4S certificate?

No organisation is "S4S certified" in the way a company can hold an ISO 9001 certificate. The outcome of an assessment is a capability profile: ratings and levels for the assessed processes, in a defined organisational unit and context, at a point in time, together with strengths, weaknesses and recommendations. Ownership and use of the results are agreed at initiation. When someone tells you "we are S4S Level 3", ask which processes, which organisational unit, which purpose, when, and who led the assessment.

Lesson 6 – Worked example: a supplier prepares for a Category B contract

Kestrel Orbital Software is a fictional company of 60 people that develops on-board and ground software. A prime contractor building an Earth observation satellite plans to subcontract the payload data handling software, classified as criticality category B. The contract will make ECSS-E-ST-40C and ECSS-Q-ST-80C applicable, and the prime wants a capability determination before awarding it. Kestrel has never had a formal assessment.

Step 1 – Agree purpose, scope and targets

The prime acts as assessment sponsor and engages an external team: a competent assessor as team leader, a provisional assessor and a technical specialist in on-board data handling. Kestrel's quality manager becomes the local assessment coordinator. The purpose is capability determination. The organisational unit is Kestrel's flight software department, sampled through its two most recent projects. Instead of all 52 processes, the sponsor selects the six processes whose weaknesses would hurt this contract most, and uses the class B column of the Annex A proposal as a starting point for the target profile, agreeing the final targets with Kestrel.

Step 2 – Prepare and plan

Kestrel maps its own procedures to the S4S processes: its "Requirements engineering procedure" maps to ENG.4, its "Test procedure" to ENG.8, and so on. The team leader sends a pre-assessment questionnaire, agrees a four-day on-site schedule, lists the people to interview (project managers, engineers, testers, the configuration manager, the product assurance manager) and the documents to examine. A confidentiality statement is signed because the prime is also a potential competitor in other markets.

Step 3 – Collect and validate evidence

After a short briefing, the assessors interview staff and examine evidence: software requirements specifications and their traceability to system requirements, review records, test plans and reports, configuration status accounts, problem reports, project plans and progress reports, and the software criticality analysis. When the product assurance manager says the criticality analysis is updated at every milestone, the assessors ask for the versions and find only one, produced at the preliminary design review. That gap goes into the assessor records.

Step 4 – Rate and report

The team rates each attribute by consensus and derives the levels. Dashes mean the attribute was not in scope for that process because the target was lower.

Process	Target	PA 1.1	PA 2.1	PA 2.2	PA 3.1	PA 3.2	Level
`ENG.4` Software requirements analysis	3	F	L	F	P	P	2
`ENG.8` Software testing	3	F	F	F	L	L	3
`SUP.8` Configuration management	3	F	F	F	F	L	3
`SUP.9` Problem resolution management	2	F	F	L	–	–	2
`SUP.11` Safety and dependability assurance	2	L	P	P	–	–	1
`MAN.3` Project management	3	F	L	L	P	N	2

The report explains each gap. For ENG.4, requirements work is done and controlled, but each project invents its own way of doing it, so there is no standard process to tailor (PA 3.1 Partially). For SUP.11, the criticality analysis exists but is not maintained as the design changes and measures for critical components are not systematically verified; the process outcomes are only largely achieved and it is not managed. For MAN.3, planning is good, but there is no organisational project management process with tailoring guidelines, and no evidence that project data are collected to improve it. Strengths are recorded too: testing and configuration management meet their targets.

Step 5 – Feed the risks and plan improvement

The prime treats the three gaps as contract risks. It awards the contract with conditions: an improvement plan within six weeks, extra product assurance reviews of the safety and dependability analyses at each milestone, and a focused re-assessment of ENG.4, SUP.11 and MAN.3 after twelve months. Kestrel's management sets business goals for the improvement programme (fewer late requirement changes, no safety findings at milestone reviews) rather than simply "reach Level 3". It nominates an improvement programme manager, forms a small process improvement group with experienced engineers, and starts three improvement projects: a standard requirements engineering process with tailoring guidelines, a safety and dependability assurance procedure tied to milestones, and an organisational project management process.

Step 6 – Implement, confirm, sustain

The new requirements process is piloted on the new payload software project first, adjusted after the pilot, and then rolled out with training. Criticality analyses are now a milestone entry criterion, so they cannot be forgotten. After twelve months the re-assessment finds ENG.4 and MAN.3 at Level 3 and SUP.11 at Level 2. Kestrel keeps the new procedures in its standard process, measures requirement change rates and review findings, and plans its next improvement cycle around the process for independent verification, which a future category A contract will demand.

Notice what made this example work: the scope was chosen for the contract's risks, the target profile was agreed rather than copied blindly, evidence rather than claims drove the ratings, and improvements were tied to business goals and confirmed by a second look.

Lesson 7 – Relationship to other standards and frameworks

S4S sits in a family of SPICE-based and maturity-based models, and inside the ECSS system of space standards. Understanding the neighbours helps you reuse evidence and avoid duplicated effort.

Framework	Owner	Main focus	Relationship to S4S
ECSS-Q-ST-80C and ECSS-E-ST-40C	ECSS	Requirements for space software product assurance and space software engineering	The source of the space-specific practices in S4S; ECSS-Q-ST-80C clause 5.7 is the requirement that S4S helps meet.
ISO/IEC 15504 and its successor ISO/IEC 330xx	ISO/IEC JTC 1	Generic framework for process assessment: concepts, assessment requirements, measurement framework, exemplar models	S4S is a space-specific instantiation of the ISO/IEC 15504-5 exemplar model and method; the 330xx series now holds the current generic rules.
ISO/IEC/IEEE 12207	ISO/IEC and IEEE	Software life cycle processes	The process architecture behind the ISO exemplar model and therefore behind the S4S process groups.
Automotive SPICE	VDA QMC	Process assessment for automotive embedded systems and software	A sibling SPICE adaptation for another industry: same capability levels and rating idea, different process set and assessor scheme.
CMMI	ISACA (CMMI Institute)	Maturity and capability model with an appraisal method	An alternative scheme; it can be recognised for ECSS purposes if the appraisal method and mapping meet the recognition rules, with space-specific gaps covered separately.
ISO 9001 and EN 9100	ISO and IAQG	Quality management systems, the latter for aviation, space and defence	Certify the management system of an organisation; they do not rate the capability of individual software processes.

A few points are worth drawing out. First, S4S and Automotive SPICE share their heritage, so engineers who know one quickly understand the other; the space version differs mainly in its acquisition and supply emphasis, the ECSS traceability and the added space processes. Second, CMMI uses staged maturity levels for whole organisations as well as capability levels for practice areas, while S4S rates each process separately; when a CMMI result is offered to a space customer, someone must map it to the S4S processes and show how ECSS-specific needs are covered. Third, an ISO 9001 or EN 9100 certificate tells a customer that a quality management system exists and is audited, which is useful but different from knowing that software requirements analysis is performed at capability Level 3. Finally, because the 2010 handbook references ISO/IEC 15504, organisations that follow the newer ISO/IEC 330xx documents should check the conformance argument; the measurement ideas (levels, attributes, N-P-L-F rating) are essentially the same, so the translation is usually straightforward.

Common pitfalls and best practices

Pitfalls

Chasing levels instead of benefits. Treating "Level 3" as the goal leads to paperwork that satisfies assessors but does not reduce defects, delays or risks.
Quoting results out of context. A profile from one department, project sample or year is reused for a different unit or contract without asking whether it still applies.
Assessing everything. Putting all 52 processes in scope wastes effort; scope should follow the assessment purpose and the risks of the contract.
Copying target profiles blindly. The Annex A profiles are proposals; using them without considering the project's real risks gives targets that are too low or unnecessarily high.
Ignoring tailoring in conformance assessments. Rating against the untailored ECSS standards punishes legitimate project decisions and produces misleading results.
Relying only on training or tools. Buying a tool or running a course without changing roles, procedures and habits rarely changes the rating or the outcomes.
No follow-through. An assessment report that is filed without an improvement plan, owners and a confirmation step wastes the money spent on it.

Best practices

Start from business goals. Link every improvement project to a quality, cost, schedule or product problem that management cares about.
Agree the assessment inputs early. Purpose, scope, highest level, context, constraints and ownership of results should be written down and approved by the sponsor before any data are collected.
Use competent assessors and record evidence. A competent team leader, consensus rating and a complete assessment record make results defensible.
Record the unachieved indicators. For every attribute below Fully, note what was missing and whether the fix belongs to the project or the organisation; this turns a rating into an action list.
Pilot, then roll out. Try new procedures on a suitable project, adjust them, then deploy them with training and coaching.
Integrate with ECSS work. Use the Part 2 traceability so that the same plans, reviews and records serve product assurance, engineering and assessment.
Feed the risk process. Pass process weaknesses to project risk management and use risk data to justify improvement priorities.

Summary and key takeaways

S4S is the European space sector's software process assessment and improvement scheme, defined in ECSS-Q-HB-80-02 Parts 1A and 2A (2010), also published as CEN/CLC/TR 17602-80-11 and 17602-80-12.
It instantiates the ISO/IEC 15504 approach for space, adding processes such as ISVV, safety and dependability assurance, contract maintenance and information management, plus ECSS-specific practices throughout.
The model has a process dimension of 52 processes in nine groups and a capability dimension of six levels defined by nine process attributes.
Attributes are rated N, P, L or F, and a level is reached when its attributes are at least Largely and all lower attributes are Fully achieved.
Assessments serve process improvement, capability determination or ECSS conformance; conformance assessments treat ECSS-linked indicators as mandatory.
S4S supports clause 5.7 of ECSS-Q-ST-80C; conformant assessments are led by a competent assessor, and other schemes can be recognised if they map to S4S and cover space-specific gaps.
Target profiles tied to software criticality turn assessment results into risk-based improvement goals.
There is no company-wide S4S certificate: results describe specific processes in a specific organisational unit and context.

Reflection questions

Think of a software project you know. Which six S4S processes would you put in scope for a customer's capability determination, and why those?
Your team has excellent tests but no organisation-wide standard process. Which levels would you expect for software testing and why might PA 3.1 hold the rating back?
How would you explain to a manager that a profile from a two-year-old assessment of another department may not support a new bid?
A project has tailored out several ECSS-Q-ST-80C requirements. How would you prepare an ECSS conformance assessment so that the tailoring is treated fairly?
If your company already holds a CMMI appraisal result, what would you need to show a space customer before they accept it in place of an S4S assessment?