Software Product Assurance Plan (SPAP)#


Document	Software Product Assurance Plan (SPAP)
DRD	ECSS-Q-ST-80C Rev.2 (30 April 2025), Annex B
Container	Product Assurance File (PAF)
Project	`sar-processor` — generic spaceborne SAR data processor
Configuration item	`gitlab.eopf.copernicus.eu/ipf/sar-processor`
Software criticality	Category C (ECSS-Q-ST-80C Rev.2 Annex D / ECSS-E-ST-40C Rev.1 Annex R)
Baselined at	SRR
Status	Draft for SRR

This SPAP is the software product assurance constituent of the Product Assurance File for the sar-processor project. It follows the ECSS-Q-ST-80C Rev.2 Annex B DRD section structure (clauses <1>–<8>), tailored for Category C and proportionate to a single-developer ground-segment project. Its central tenet: in the absence of an independent PA organisation, product assurance is operationalised as automated, version-controlled CI quality and security gates plus documented checklists, so that PA objectives are evidenced by pipeline artefacts rather than asserted. It is consistent with, and cross-references, the SDP (compliance/software-development-plan.md).

<1> Introduction#

The sar-processor is an operational ground-segment forward data processor that transforms downlinked raw (Level-0) Synthetic Aperture Radar (SAR) instrument source packets into focused, calibrated and geolocated products — L1 SLC, L1 GRD and geocoded GTC. It is a generic spaceborne SAR processor: the chain (decode → focusing → radiometric calibration → detection/multi-look → geocoding) is sensor-agnostic and driven by a per-sensor profile plus the per-acquisition product annotation. It is built on the ESA EOPF (each stage an EOPF CPM EOProcessingUnit, products as EOProduct, outputs as cloud-native Zarr, eopf == 2.8.1).

Purpose and objective. The purpose of this SPAP is to provide information on the organisational aspects and the technical approach to the execution of the software product assurance programme for sar-processor, in conformance with ECSS-Q-ST-80C Rev.2. The objective is to give assurance — to the project owner and to any downstream user of the products — that the processor is developed under a controlled, standards-conformant process and that the delivered software meets its specified quality requirements.

Content. This plan describes the PA organisation and independence model (<5.1>–<5.2>), the PA resources, reporting, quality models, risk and supplier contributions, and the methods and tools (<5.3>–<5.10>); the software process assurance measures including dependability, security, configuration/non-conformance control, metrics, reuse and per-activity PA planning (<6>); the software product quality assurance approach mapping each CI gate to a PA objective (<7>); and the compliance matrix to the applicable ECSS-Q-ST-80 clauses (<8>).

Reason prompting preparation. This document is prepared at project start to establish the SRR baseline of the software product assurance programme, and is maintained throughout the life cycle.

<2> Applicable and reference documents#

Applicable documents

Ref	Document
AD-1	ECSS-Q-ST-80C Rev.2 (30 April 2025) — Space product assurance — Software product assurance
AD-2	ECSS-E-ST-40C Rev.1 (30 April 2025) — Space engineering — Software
AD-3	ECSS-Q-ST-10C Rev.1 — Space product assurance — Product assurance management
AD-4	ECSS-M-ST-40C — Configuration and information management
AD-5	ECSS-M-ST-80C — Risk management

Reference documents

Ref	Document
RD-1	SDP — Software Development Plan (`compliance/software-development-plan.md`)
RD-2	SRevP — Software Review Plan (`compliance/drd/srevp-software-review-plan.md`)
RD-3	Risk Register (`compliance/drd/risk-register.md`)
RD-4	V&V Plan — SVerP/SValP/SUITP (`compliance/drd/vv-plan.md`)
RD-5	SRF — Software Reuse File (`compliance/drd/srf-software-reuse-file.md`)
RD-6	EOPF SDE — User Manual & CI/SonarQube quality-gate guidelines
RD-7	EOPF Core Python Modules (CPM) documentation (`eopf == 2.8.1`)

<3> Terms, definitions and abbreviated terms#

Terms and definitions follow AD-1, AD-2 and the SDP §3 / SSS §3. Abbreviations specific to or emphasised in this SPAP and not already defined there:

Abbreviation	Definition
NCR	Non-Conformance Report
NRB	Non-conformance Review Board (here: the documented single-developer disposition record)
PA	Product Assurance
PAF	Product Assurance File
SAST	Static Application Security Testing
SCA	Software Composition Analysis (dependency vulnerability scanning)
SPA	Software Product Assurance
SPAMR	Software Product Assurance Milestone Report (tailored out — see `<5.4>`)
SQ	SonarQube

(ECSS review acronyms SRR/PDR/CDR/QR/AR and DRD acronyms per the SDP §3.)

<4> System Overview#

A full description of the system and software products is given in the SDP §1 and in the SSS/IRD; it is not duplicated here. In summary, the configuration item is the Python package sar_processor (the main branch of the Git repository), composed of L0→GTC processing stages implemented as EOPF CPM EOProcessingUnits with a pure, unit-testable core.py plus a thin unit.py wrapper, parameterised by a per-sensor profile and the per-acquisition product annotation. Outputs are Zarr EOProducts (complex SLC, detected GRD, geocoded GTC). The software is distributed as a Python wheel and a container image; the runtime is the EOPF SDE (registry.eopf.copernicus.eu/sde/..., Python 3.11).

Data and exportability policy (PA-relevant). Source code is public (Apache-2.0). Raw input data and instrument calibration ADFs (AUX_CAL/INS/PP1, orbit, attitude, DEM) are private — never committed and never used in public CI; they may be held in the project Studio VM data store and referenced at run time. Numerical verification on real data is performed locally / on the Studio VM. This split shapes the PA approach: CI assures process and code quality plus a synthetic point-target focusing test that needs no private data; numerical product quality (focusing/calibration/geolocation) is assured locally on real Sentinel-1 data and recorded in the SVR.

<5> Software product assurance programme implementation#

<5.1> Organization#

Organizational structure. sar-processor is a single-developer project. The project owner holds, concurrently, the supplier-side software engineering, software product assurance, and verification roles. There is no separate PA department and no customer/supplier hierarchy beyond the project owner and the hosting EOPF SDE programme.

Interfaces. The only external organisational interface is the EOPF SDE platform team (provider of the build image, CI runner, SonarQube instance and Pages hosting), consumed as a service. There are no internal sub-organisations. ECSS milestone governance is the ipf GitLab group (SRR→PDR→CDR→QR→AR milestones).

Relationship to system-level PA and safety. sar-processor is ground-segment software with no flight, safety or mission-loss function (see <6.3>); there is no system-level safety case to interface with. System-level PA reduces to the milestone reviews and the Risk Register (RD-3).

Independence of the SPA function. Personnel independence is not achievable in a single-developer project. Independence of the verification and PA judgement is therefore obtained by structural and automated means:

Automated, non-overridable gates — the CI pipeline (.gitlab-ci.yml) executes the quality and security checks of <5.8>/<7> on every merge request; blocking gates fail the pipeline independently of the developer’s opinion. The developer cannot merge a gate-failing change without an explicit, recorded waiver.
Static, version-controlled tool configurations — gate thresholds live in pyproject.toml, .flake8, .mypy.ini, bandit.yml, .coveragerc, .hadolint.yml and .pre-commit-config.yaml; changing a threshold is itself a reviewable diff with audit trail.
A third-party adjudicator — SonarQube applies the EOPF quality gate (<5.5>) as an external pass/fail authority on coverage, reliability, security and maintainability.
Documented checklists — merge-request and milestone-review checklists (RD-2) force an explicit, recorded self-review against PA criteria before baselining.

Delegation to a lower-level supplier. None. No software is procured or subcontracted; all third-party software is open-source reuse assured per <5.7>/<6.7> and the SRF (RD-5).

<5.2> Responsibilities#

The SPA function (the project owner acting in the PA role) is responsible for:

defining and maintaining this SPAP and the PA-relevant configurations of the CI gates;
ensuring every change to main passes the blocking CI gates, or carries a recorded waiver;
triaging, classifying and dispositioning non-conformances (<6.5>);
maintaining standards conformance (<6.9>) and the compliance matrix (<8>);
assuring reused software (scaffold, EOPF CPM, OSS) via the SRF and the SCA gate (<6.7>);
reporting PA status at each milestone review (<5.4>).

<5.3> Resources#

Human resources and skills. One person (the project owner), competent in Python, EOPF CPM, SAR/remote- sensing data processing and the ECSS-E-40/Q-80 framework. No additional PA staff are allocated; the staffing model and its rationale are in the SDP §4.

Hardware. Development workstation; the EOPF SDE Studio VM hosting the GitLab shell-executor CI runner and the private data store. Container-runtime / Dask-gateway / S3-dependent jobs are not runnable on the shell runner and are configured non-blocking until a Kubernetes runner is available (see <5.8>).

Software tools. The CI toolchain of <5.8> (flake8, black, isort, mypy, bandit, trivy, xenon, hadolint, docstr-coverage, pytest+coverage, SonarQube, pre-commit), the GitLab platform (issues, merge requests, milestones, package & container registries, Pages), and the EOPF CPM build image. All tools are open-source or platform-provided; licences are recorded in the SRF.

<5.4> Reporting#

PA reporting is artefact-based and continuous rather than periodic written reports:

Per change: the CI pipeline status and its artefacts (linter.txt, coverage.xml, TEST-pytests.xml, vulnerability.json, trivy output, SonarQube dashboard) are the standing PA record for each merge request.
Per milestone: PA status (gate results, open non-conformances by severity, waivers, standards- conformance and compliance-matrix status) is summarised in the milestone review per RD-2 and recorded against the GitLab milestone.

A standalone Software Product Assurance Milestone Report (SPAMR, Annex C) is tailored out for this Category C single-developer project; its content is subsumed by the milestone review record and the SVR (RD-4). This tailoring is recorded in the SDP §5.6 and in <8>.

<5.5> Quality models#

The applicable product-quality model is the EOPF SonarQube quality gate (RD-6), expressed as quantitative thresholds and used to derive the product quality requirements assured in <7>:

Quality characteristic	Metric	Target
Reliability	SonarQube reliability rating	A
Security	SonarQube security rating	A
Maintainability	Technical-debt ratio	≤ 5 %
Testability	Unit-test line coverage (new code)	≥ 70 %
Security (vulnerabilities)	Open vulnerabilities	0
Analysability	Comment / documentation density	≥ 20 %

Complexity is additionally bounded by xenon (<5.8>). These thresholds are the contract between the CI gates (<7>) and the PA objectives; deviations are non-conformances (<6.5>).

<5.6> Risk management#

The SPA function contributes to project risk management (AD-5) by surfacing process and product risks (e.g. uncovered code paths, unfixed dependency CVEs, complexity hotspots, EOPF complex/burst feasibility, IPF-version-gating sprawl, ground-truth-data availability) from the CI gate outputs and the engineering analysis into the Risk Register (RD-3), which is reviewed at each milestone. PA-originated risks are raised as GitLab issues with the Risk template and linked to their mitigation merge requests.

<5.7> Supplier selection and control#

There are no commercial software suppliers and no subcontracting. The only “suppliers” are the open-source projects reused by sar-processor (the scientific-Python stack incl. the FFT backend) and the EOPF SDE platform. The SPA contribution to their selection and control is:

Selection — driven by the EOPF CPM ecosystem and recorded, with licence and provenance, in the SRF (RD-5); only permissively licensed (Apache-2.0/MIT/BSD/PSF) components are admitted. In particular the FFT backend defaults to numpy.fft (BSD) to avoid the copyleft (GPL) obligation of FFTW/pyFFTW (SRF <3>).
Control — versions are pinned (pyproject.toml, eopf == 2.8.1); dependency vulnerabilities are monitored by the trivy SCA gate (deps-sec, <6.7>); licence and exportability constraints are tracked in the SRF.

<5.8> Methods and tools#

PA is implemented through an automated toolchain applied at two stages — local pre-commit and CI pipeline — over the development cycle. All tools are mature, widely adopted open-source products at stable releases (versions and licences in the SRF, RD-5); their configurations are version-controlled.

Local gate. pre-commit (.pre-commit-config.yaml) runs fast formatting/lint hooks before each commit, shifting defect detection left of CI.

CI gate inventory (.gitlab-ci.yml). Blocking = pipeline fails on violation; Non-blocking = allow_failure: true (reported, not gating — pending the SDE Kubernetes runner, or advisory by nature):

Job	Tool	Config	Invocation (essentials)	Gating
`linter`	flake8	`.flake8`	`flake8 sar_processor tests`	Blocking
`formater`	black, isort	`pyproject.toml`	`black --check --diff .`; `isort --check --diff`	Blocking
`typing`	mypy	`.mypy.ini`	`mypy sar_processor`	Blocking
`unit-tests`	pytest, coverage	`pyproject.toml`, `.coveragerc`	`pytest --cov -m unit` → cobertura + junit	Blocking
`security`	bandit	`bandit.yml`	`bandit -c bandit.yml -r sar_processor` (+ JSON)	Blocking
`docker-linter`	hadolint	`.hadolint.yml`	`hadolint Dockerfile` (codequality report)	Blocking
`deps-sec`	trivy	—	`trivy fs --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed`	Non-blocking
`complexity`	xenon	—	`xenon --max-average B --max-modules C --max-absolute D`	Non-blocking
`docs-cov`	docstr-coverage	—	`docstr-coverage -F 30`	Non-blocking
`sonarqube`	SonarQube scanner	server gate	`sonar-scanner -Dsonar.qualitygate.wait=true` (ingests flake8/bandit/coverage/junit)	Non-blocking

Maturity note. trivy, complexity and sonarqube are intended to be blocking once the SDE Kubernetes runner replaces the shell executor; until then they run advisory so that no infrastructure limitation silently weakens a PA objective. This planned hardening is tracked as a risk in RD-3.

<5.9> Process assessment and improvement#

Scope and objectives. Assessment is limited to verifying that the documented life cycle (SDP) and the CI gates of this SPAP are actually applied, and to incrementally tightening gates as the codebase and infrastructure mature. Formal external process assessment (e.g. ISO/IEC 15504) is tailored out as disproportionate for Category C single-developer scope.

Methods and tools. Assessment evidence is the Git/CI history (every change is a reviewed merge request with an attached pipeline) and the milestone-review checklists (RD-2). Improvement actions are raised as GitLab issues (Action template) and closed via merge requests — e.g. promoting a non-blocking gate to blocking, raising the coverage target, or adding a check.

<5.10> Operations and maintenance (optional)#

Operations and maintenance PA is light. Maintenance is performed through the same gated issue→branch→merge-request→review flow as development; releases follow semantic versioning with Git tags and GitLab Releases. A standalone Software Maintenance Plan is tailored out (SDP §5.5.2); maintenance quality is assured by re-running the full CI gate set on every change, including after delivery.

<6> Software process assurance#

<6.1> Software development cycle#

The software development life cycle is defined in the SDP (RD-1, §5.1–5.2): an incremental paradigm synchronised by the ECSS reviews SRR→PDR→CDR→QR→AR (GitLab milestones), with implementation starting only after CDR. The SPAP does not redefine it. The milestone immediately before the start of software validation is CDR: design, test plans (RD-4) and the reuse file are baselined at CDR, after which coding and then validation proceed.

<6.2> Projects plans#

All project plans and their relationships are defined in the SDP §5.5 (tailored DRL). The plans relevant to PA are: this SPAP, the SDP (RD-1), the SRevP (RD-2), the V&V Plan (RD-4), the Risk Register (RD-3) and the SRF (RD-5). Each plan is baselined at the review indicated in the SDP DRL and updated through merge requests thereafter; timely preparation/update is enforced by tying each plan to its GitLab milestone.

<6.3> Software dependability and safety#

sar-processor is classified Category C (ECSS-Q-ST-80C Rev.2 Annex D). Rationale: a failure produces degraded or incorrect data products only — there is no safety, mission-loss or space-segment consequence, and any defect is recoverable by reprocessing. Consequently:

No safety-critical functions exist; no safety case, FMECA or fault-tree analysis is required, and the corresponding ECSS-Q-ST-80 dependability/safety requirements are tailored out for Category C (recorded in <8>).
The dependability measures retained are correctness measures, proportionate to Category C: deterministic unit tests with coverage gating, static typing (mypy), bounded complexity (xenon), and numerical- accuracy control of the SAR algorithms — focusing (impulse-response PSLR/ISLR/IRW), radiometric calibration (σ0 accuracy) and geolocation (ALE) — verified on a synthetic point target (CI) and locally on real Sentinel-1 data and recorded in the SVR (see <6.9> item 15 and <7>). Determinism of the FFT backend and complex dtype is fixed (SSS SYS-RAM-01) so numerical budgets are reproducible.

<6.4> Software security#

The software handles no classified or security-sensitive information; there is no security-sensitive function. The security assurance approach is nonetheless concrete:

No secrets in the repository. Credentials and platform tokens (e.g. SQ_LOGIN, CI_REGISTRY_PASSWORD, DATASTORE_TOKEN, Studio VM tokens) are CI variables only; a validate-variables step fails the pipeline if a required variable is unset. Raw data and calibration ADFs are never committed.
SAST — bandit (security job, blocking) statically scans sar_processor for common Python security defects; findings are also fed to SonarQube.
SCA — trivy fs (deps-sec job) scans dependencies for HIGH/CRITICAL CVEs.
Container hardening — hadolint (docker-linter, blocking) lints the Dockerfile.

This clause constitutes the security assurance section required by the DRD: the related security activities are the gates above and the no-secrets/data-privacy policy of <4>. No separate security file is produced (none is warranted at this criticality).

<6.5> Software documentation and configuration management#

Contribution to documentation and CM. PA assures that every configuration item — code, formal DRD documents, CI configuration — is under Git version control with change introduced only through reviewed merge requests, per ECSS-M-ST-40C (AD-4). Configuration identification, status accounting and the baseline-per-milestone scheme are defined in the SCF/CIDL and the SDP §5.2.

Non-conformance control system. Non-conformances are managed as GitLab issues on the project, which constitute the NCR channel. The procedure applies from the SRR baseline onward. The workflow is:

Report — an issue is opened using the appropriate template (Bug, Action, Documentation, Risk), or auto-evidenced by a failing CI gate.

Classify — a severity label is applied:

Label	Meaning
`severity:critical`	Wrong/lost product data, security exposure, or pipeline-blocking failure
`severity:major`	Incorrect result (e.g. mis-focused / mis-calibrated product) or broken feature with no workaround
`severity:minor`	Degraded behaviour with a workaround
`severity:trivial`	Cosmetic / documentation defect

Disposition — the project owner records the disposition (fix / waiver / N/A) on the issue; this is the single-developer equivalent of an NRB decision. A waiver of a blocking gate is only valid when recorded on the issue with rationale and an expiry/closure condition.
Verify & close — the fix is delivered by a linked merge request that must pass the full gate set; the issue is closed with the merge reference, giving end-to-end traceability from report to verified fix.

Protection, integrity key and labelling of delivered software. The delivered wheel and container image are integrity-identified by SHA-256 checksum (wheel) and image digest (container); the labelling/marking of a release is the semantic-version Git tag + GitLab Release (and the package- registry version), which is the authoritative delivered-media label. These identifiers are recorded in the SRelD/SRN.

<6.6> Process metrics#

Process metrics are derived from the quality model (<5.5>) and collected automatically by the CI pipeline as build artefacts: test pass/fail and coverage trend (coverage.xml, TEST-pytests.xml), static-analysis and security findings (linter.txt, vulnerability.json, trivy output), complexity and docstring- coverage, and the SonarQube history. They are stored as pipeline artefacts and in the SonarQube project, analysed at each milestone, and used to manage the process (e.g. promoting gates to blocking, prioritising refactoring of complexity hotspots such as the focusing kernels).

<6.7> Reuse of software#

sar-processor reuses (a) the sensor-agnostic scaffold/process of the sibling msi-processor project, (b) the EOPF CPM framework and the scientific-Python stack (incl. the FFT backend) as runtime dependencies, and (c) the public Sentinel-1 algorithm basis (IPFDPM/SentiWiki) as the algorithm reference (SDP §1, SRF RD-5). The PA approach for reuse:

Every reused component is declared in the SRF (RD-5) with category, version, licence, exportability constraints and execution environment.
Delta qualification of reused scaffold/code is achieved by integration into the gated pipeline: reused libraries are exercised through sar_processor’s own unit/integration tests, type checks and the trivy SCA gate; only permissive licences are admitted (<5.7>).
Reuse of the algorithm basis is qualified by writing each SAR Core new against its ATBD and verifying numerical results (synthetic point target in CI + real Sentinel-1 data locally, recorded in the SVR), since the basis is public mathematics, not a black-box binary. No structural identity with msi-processor is levied (SRF); the SAR product/complex/burst elements are new development.

<6.8> Product assurance planning for individual processes and activities#

Activity	PA measures
Software requirements analysis	Uniquely-identified `REQ-*` requirements with forward/backward traceability (SRS + traceability matrix); reviewed at PDR.
Architectural & detailed design	EOPF CPM PU pattern (pure core + thin wrapper) reviewed against SRS at CDR; design recorded in SDD/DJF; `product/` + complex/burst new-development boundary recorded in SRF.
Coding	`flake8` + `black` + `isort` + `mypy` + `bandit` blocking gates; `xenon` complexity bound; PEP 8; deterministic FFT/dtype.
Testing & validation (incl. regression)	`pytest -m unit` blocking with ≥ 70 % coverage gate incl. the synthetic point-target focusing test; full gate set re-run on every change provides regression assurance; integration tests when runner available; numerical validation locally on real S1 data → SVR.
Verification	Per the V&V Plan (RD-4); gate artefacts are verification evidence; milestone checklists (RD-2).
Delivery & acceptance	Wheel/image built and (on tag) published; integrity checksums and SemVer labelling (`<6.5>`); acceptance at QR/AR.
Operations & maintenance	Light (`<5.10>`): same gated flow post-delivery.

<6.9> Procedures and standards#

#	Aspect	Standard / procedure	PA adherence measure
1	Project management	SDP (RD-1), GitLab milestones	Milestone review checklist
2	Risk management	AD-5, Risk Register (RD-3)	Reviewed each milestone
3	Config. & documentation mgmt	AD-4, SCF/CIDL	All CIs in Git; MR-only changes
4	Verification & validation	V&V Plan (RD-4)	Gate artefacts; SVR
5	Requirements engineering	ECSS-E-ST-40 DRDs	Traceability matrix
6	Design	EOPF CPM PU pattern	CDR design review
7	Coding	PEP 8	`flake8`/`black`/`isort` (blocking)
8	Metrication	EOPF SQ quality gate (`<5.5>`)	SonarQube + coverage gates
9	Non-conformance control	`<6.5>`	GitLab issues + severity labels
10	Audits	Self-audit via Git/CI history	`<5.9>`
11	Alerts	GitLab security advisories; trivy CVEs	`deps-sec` job
12	Procurement	N/A (no procurement)	SDP §4
13	Reuse of existing software	SRF (RD-5)	`<6.7>`
14	Use of methods and tools	`<5.8>`	Version-controlled tool configs
15	Numerical accuracy	ATBD / SVR	Point-target (CI) + real-data (local) verification of focusing/calibration/geolocation
16	Delivery, installation, acceptance	SRelD/SRN	Checksums + SemVer (`<6.5>`)
17	Operations / maintenance	`<5.10>`	Gated MR flow
18	Device programming and marking	N/A (no programmable devices)	—

<7> Software product quality assurance#

The approach to ensuring software-product quality is the mapping of each CI gate to a PA objective, with target values from the quality model (<5.5>) and automated collection. This is the core of the single- developer independence model (<5.1>): the gates are the assurance activities.

Gate → PA objective mapping

PA objective	Product metric & target	CI gate (job/tool)	Collection means	Feedback
Code is style-conformant & lint-clean	0 flake8 violations	`linter` / flake8 (blocking)	`linter.txt` artefact → SonarQube	Pipeline fails; fix via MR
Code is consistently formatted	0 black/isort diffs	`formater` (blocking)	check-mode diff	Pipeline fails
Type contracts hold	0 mypy errors	`typing` / mypy (blocking)	job log	Pipeline fails
Behaviour is correct & covered	tests pass; coverage ≥ 70 %; point-target focusing budgets met	`unit-tests` / pytest+cov (blocking)	cobertura + junit artefacts	Pipeline fails; coverage trend
No SAST security defects	0 bandit findings	`security` / bandit (blocking)	`vulnerability.json` → SonarQube	Pipeline fails
No vulnerable dependencies	0 HIGH/CRITICAL CVEs	`deps-sec` / trivy (advisory→blocking)	trivy report	Risk/issue raised
Container image well-formed	0 hadolint errors	`docker-linter` / hadolint (blocking)	codequality report	Pipeline fails
Complexity bounded	xenon ≤ B avg / C module / D abs	`complexity` / xenon (advisory→blocking)	job log	Refactor issue
Code is documented	docstring coverage ≥ 30 % (→ SQ ≥ 20 %)	`docs-cov` / docstr-coverage	badge artefact	Issue raised
Overall product quality	SQ gate: reliability A, security A, debt ≤ 5 %, vulnerabilities 0	`sonarqube` (`qualitygate.wait=true`)	SonarQube dashboard	Gate verdict
Numerical/product correctness	focusing/σ0/ALE within tolerance vs reference (local)	local verification (not CI)	SVR (RD-4)	Documented at QR

Metrication programme. Metrics are collected on every push and merge request (continuous metrication); trends accumulate in SonarQube and in pipeline artefacts and are reviewed at each milestone (<6.6>).

Analyses and feedback. Gate failures feed back immediately to the developer (the pipeline blocks the merge); trend analyses (coverage, complexity, debt) feed back at milestones and drive the improvement actions of <5.9>.

Documentation quality requirements. Code is documented to the docstring-coverage and comment-density targets above; formal DRD documents follow their Annex structure and are reviewed per RD-2.

Assurance activities. The blocking gates, the SonarQube quality verdict, the review checklists and the local numerical verification together constitute the assurance that the product meets its quality requirements.

<8> Compliance matrix to software product assurance requirements#

Compliance to the applicable ECSS-Q-ST-80C Rev.2 clauses (per the SPAP traceability of DRD Table B-1), tailored for Category C. Legend: C = compliant, NC = non-compliant, NA = not applicable / tailored out.

ECSS-Q-ST-80 clause	Topic	Compliance	SPAP reference	Remarks
5.1.2 / 5.1.3 / 5.1.4	PA organisation, responsibility, authority	C	`<5.1>`, `<5.2>`	Single-developer; independence via tooling
5.2.1	PA planning and control	C	`<5.4>`, `<5.8>`	Artefact-based, continuous
5.2.1.4	Operations & maintenance measures	C	`<5.10>`	Light
5.2.1.5	Compliance matrix maintained	C	`<8>`	This table
5.2.6	Non-conformances	C	`<6.5>`	GitLab issues + severity labels
5.2.7	Quality requirements and quality models	C	`<5.5>`, `<7>`	EOPF SQ quality gate
5.3	Risk management contribution	C	`<5.6>`	Risk Register (RD-3)
5.4.3 / 5.4.4	Supplier selection & control	NA	`<5.7>`	No suppliers; open-source reuse only
5.6.1	Methods and tools	C	`<5.8>`	Version-controlled tool configs
5.7	Process assessment & improvement	C	`<5.9>`	Self-audit via Git/CI; ext. assessment tailored out
6.1	Software development cycle	C	`<6.1>`	Defined in SDP (RD-1)
6.2.x	Documentation of processes / metrics / CM / verification	C	`<6.2>`,`<6.5>`,`<6.6>`,`<7>`	—
6.2.2 / 6.3.x	Dependability and safety; critical software	NA	`<6.3>`	Category C; no safety function
6.2.7	Reuse of existing software	C	`<6.7>`	SRF (RD-5) + delta qualification
6.2.9 / 6.2.10	Software security / sensitive software	C / NA	`<6.4>`	Security gates present; no sensitive data
6.3.3–6.3.5	PA for design / coding / testing & validation	C	`<6.8>`	Per-activity gates
7.1	Product quality objectives & metrication	C	`<5.5>`, `<7>`	Gate→objective mapping
7.1.7	Numerical accuracy	C	`<6.9>` #15, `<7>`	Point-target (CI) + real-data (local) → SVR
7.2.2.3	Design/related documentation quality	C	`<6.8>`, `<7>`	—
7.5.x	Programmable device programming/marking/calibration	NA	`<6.9>` #18	No programmable devices
Annex C	SPAMR	NA	`<5.4>`	Tailored out; subsumed by milestone review + SVR

End of SPAP. Authored per ECSS-Q-ST-80C Rev.2 Annex B; tailored for Category C, single-developer. May be combined with the project Product Assurance Plan (ECSS-Q-ST-10) per DRD B.2.2.