Automotive SPICE (ASPICE) v4.0 - Process Assessment Model

Establish and manage hardware requirements derived from system requirements.

• hardware requirements specification
• traceability matrix
• review record
• Baseline

• incomplete traceability
• weak reviews
• no baseline

Develop hardware design including schematic and layout for manufacture.

• hardware design specification
• architecture diagram
• interface specification
• review record

• weak interfaces
• missing diagrams
• no review

Verify that hardware elements meet their specified requirements.

• test plan
• test results
• coverage report
• defect log

• weak coverage
• stale test cases
• poor defect tracking

Verify that the integrated hardware fulfills the hardware requirements.

• qualification plan
• test report
• environmental test evidence
• approval record

• narrow environmental scope
• missing edge cases
• weak approval

Establish ML-specific requirements including performance metrics, data requirements, and operational design domain constraints.

• ML requirements specification
• Performance targets (precision, recall)
• ODD definition
• Data quality requirements

• ODD boundaries not defined
• Performance metrics chosen without rationale
• Data requirements vague

Design ML architecture including data pipeline, model topology, training, deployment, and monitoring components.

• ML pipeline diagram
• Model architecture spec
• Training/inference flow
• Monitoring approach

• Drift monitoring not designed
• Training pipeline ad hoc
• No rollback capability defined

Train ML models with controlled datasets, documented hyperparameters, and reproducible procedures.

• Training dataset catalogue
• Hyperparameter logs
• Training run records
• Model versioning evidence

• Training not reproducible (random seeds undocumented)
• Dataset versions not tracked
• Hyperparameter sweeps undocumented

Test ML models including performance, robustness, edge cases, and ODD boundary behaviour with documented results.

• Test datasets (held out)
• Performance test reports
• Adversarial/robustness test results
• ODD boundary test cases

• Test data leakage into training
• Robustness testing skipped
• No corner case identification process

Identify, analyse, and treat project risks throughout the lifecycle with documented risk register and mitigation tracking.

• Risk register
• Risk analysis methodology
• Mitigation action log
• Periodic risk review minutes

• Risk register static after kickoff
• Probability/impact scoring inconsistent
• Mitigation actions not closed

Define and collect measurements to support management decisions and process improvement objectives.

• Measurement plan
• Metrics dashboard
• Analysis reports
• Decisions linked to measurements

• Metrics collected but not analysed
• No link to decision making
• Definitions inconsistent across projects

Track supplier performance against agreements, including technical progress, schedule, cost, and quality, with documented joint reviews.

• Supplier statement of work
• Joint review minutes
• Supplier KPI dashboard
• Issue and escalation log

• Reviews held but not minuted
• KPIs not tied to contractual targets
• Escalation path undefined

Plan, monitor, and adjust project activities to meet defined objectives within constraints of scope, schedule, cost, and quality.

• Project plan
• Schedule with milestones
• Progress reports
• Resource and budget tracking

• Plan not updated as project progresses
• Risks not reflected in plan
• Slippage not communicated upward

Identify and analyze cybersecurity requirements and threats for the automotive system.

• TARA report
• cybersecurity requirements
• traceability matrix
• review record

• weak TARA
• missing traceability
• stale requirements

Validate that the system meets stakeholder expectations and intended use in the operational environment.

• validation plan
• validation report
• traceability matrix
• approval record

• weak traceability
• narrow scenarios
• missing approval

Establish a software requirements baseline derived from system requirements with full bidirectional traceability.

• Software requirements specification
• Traceability matrix (system to software)
• Requirements review records
• Tool baseline export

• Implicit requirements not captured
• Traceability matrix not maintained
• Review evidence informal

Establish software architecture with components, interfaces, and dynamic behaviour, allocating software requirements to architectural elements.

• Software architecture document
• Component interface descriptions
• Dynamic behaviour models
• Timing and resource analysis

• Timing analysis absent for real-time components
• Interface contracts not enforced in code
• Architecture drift not addressed

Develop detailed designs for software components and implement source code following coding standards, with traceability to architecture.

• Detailed design documents
• Source code in version control
• Coding standards compliance report (MISRA C)
• Static analysis results

• Detailed design skipped for legacy components
• Coding standard deviations unjustified
• Static analysis findings unresolved

Verify software units against detailed design using static analysis and unit tests with documented coverage criteria.

• Unit test specifications
• Test execution reports with pass/fail
• Code coverage reports (statement, branch, MC/DC)
• Static analysis closure records

• Coverage targets not defined or met
• MC/DC coverage missing for critical units
• Test code not under version control

Integrate software components per architecture and verify the integrated software including interfaces and emergent behaviour.

• Integration test plan
• CI/CD pipeline configuration
• Integration test execution reports
• Interface verification matrix

• No automated integration build
• Interface coverage incomplete
• Reintegration after fixes not run

Verify integrated software satisfies software requirements through documented tests with full requirements traceability.

• Software qualification test plan
• Test cases linked to requirements
• Execution reports
• Coverage gap justification

• Robustness and boundary tests omitted
• Requirements without linked tests
• Test evidence overwritten between runs

Control the release of products to customers, ensuring released items meet acceptance criteria with traceability to underlying baselines.

• Release notes
• Acceptance test results
• Baseline configuration list
• Release approval record

• Release contents not baselined
• Known issues not disclosed in release notes
• Approval informal (email only)

Provide independent assurance that work products and processes comply with plans and standards through audits and reviews.

• QA plan
• Audit schedule and reports
• Non-conformance log
• Escalation records

• QA reports to project manager (not independent)
• Findings not tracked to closure
• Escalation path unused

Manage change requests through documented evaluation, approval, implementation, and verification with full traceability.

• Change request tracker
• Impact analysis records
• Approval evidence
• Implementation verification

• Impact analysis cursory
• Verbal approvals
• Implementation not verified end-to-end

Provide data management support processes specifically for machine learning development activities.

• data management plan
• data quality report
• versioning log
• provenance record

• no versioning
• weak provenance
• poor quality controls

Identify, control, and report configuration items and their baselines throughout the product lifecycle.

• CM plan
• Baseline records
• Change control board minutes
• CM tool audit trail

• Baselines not labelled in tool
• Manual baselines outside CM system
• CCB approvals informal

Capture, analyse, and resolve problems with documented root cause analysis and corrective action tracking.

• Problem tracker
• Root cause analysis reports
• Corrective action log
• Trend analysis

• Root cause stopped at symptom
• Corrective actions not verified
• No trend analysis across projects

Gather, understand, and manage stakeholder needs and requirements throughout the lifecycle with documented agreement.

• Stakeholder requirements specification
• Elicitation workshop minutes
• Change request log
• Customer agreement records

• Requirements captured in email threads only
• No formal sign-off
• Stakeholder coverage incomplete

Transform stakeholder needs into a set of system requirements that are analysed, prioritised, and verified for consistency.

• System requirements specification
• Bidirectional traceability matrix
• Analysis report (feasibility, risk)
• Review records

• Non-functional requirements missing
• Traceability one-directional only
• Analysis criteria undefined

Define a system architecture identifying elements and interfaces, allocating system requirements to architectural elements.

• System architecture document
• Interface specifications
• Allocation matrix
• Design rationale record

• Architecture not updated after late changes
• Interfaces specified only at top level
• Allocation gaps to elements

Integrate system elements according to architecture, verifying interfaces and integrated behaviour against integration test specifications.

• Integration test plan and cases
• Integration verification reports
• Interface test logs
• Defect records

• Integration tests cover happy path only
• Interface negative tests omitted
• Defects not linked to requirements

Verify the integrated system satisfies system requirements through documented test cases, results, and traceability.

• System test specification
• Test execution reports
• Requirements-to-test traceability
• Coverage analysis

• Coverage gaps not justified
• Manual test logs not retained
• No retest after defect fixes