2.1: Process Tailoring

Introduction

Process tailoring adapts the ASPICE Process Assessment Model (PAM) to your project's specific context. Not all ASPICE processes and practices apply equally to every project. Effective tailoring balances compliance requirements with practical efficiency.

ASPICE PAM Tailoring Framework

Tailoring Decision Matrix

ASPICE Rating Scale (as determined by assessors, not selected by teams):

Rating Abbreviation Range Meaning
Fully Achieved F 86-100% Base practices consistently performed
Largely Achieved L 51-85% Base practices mostly performed, minor gaps
Partially Achieved P 16-50% Significant gaps in base practice performance
Not Achieved N 0-15% Little or no evidence of base practice performance

Important: These percentages represent assessor ratings, not selectable targets. An assessor determines the rating based on objective evidence. The table below shows the minimum acceptable assessment outcome for each process at each capability level.

Process CL1 Target CL2 Target CL3 Target Safety Critical
SYS.2 System Req Largely Largely Fully Fully
SYS.3 System Arch Partially Largely Fully Fully
SYS.4 System Int Largely Largely Fully Fully
SYS.5 System Test Largely Largely Fully Fully
SWE.1 SW Req Largely Fully Fully Fully
SWE.2 SW Arch Partially Largely Fully Fully
SWE.3 SW Design/Code Largely Fully Fully Fully
SWE.4 SW Unit Test Largely Fully Fully Fully
SWE.5 SW Integration Largely Fully Fully Fully
SWE.6 SW Qualification Largely Fully Fully Fully
SUP.1 Quality Assur Partially Largely Fully Fully
SUP.8 Config Mgmt Largely Fully Fully Fully
SUP.9 Problem Resol Largely Fully Fully Fully
SUP.10 Change Mgmt Largely Fully Fully Fully
MAN.3 Project Mgmt Largely Fully Fully Fully

AI-Assisted Process Tailoring

Tailoring Prompt Template

"""
AI Process Tailoring Assistant
Generates tailored ASPICE process based on project context
"""

TAILORING_PROMPT = """
You are an ASPICE process expert. Tailor the ASPICE PAM to this project context:

**Project Context:**
- Team Size: {team_size} developers
- ASPICE Target: CL{capability_level}
- Safety Level: {asil_level}
- Duration: {duration} months
- Domain: {domain}
- Development Model: {dev_model}

**Tailoring Requirements:**
1. List which ASPICE processes MUST be fully achieved
2. List which can be partially achieved
3. Recommend work products to create vs skip
4. Suggest lightweight alternatives where appropriate
5. Identify critical review gates

**Output Format:**
For each relevant process (SYS.2, SYS.3, SWE.1-6, SUP.8-10, MAN.3):
- Achievement target: Fully/Largely/Partially
- Critical base practices to implement
- Work products required
- Suggested tools
- Review/approval gates
"""

# Example usage
context = {
    "team_size": 8,
    "capability_level": 2,
    "asil_level": "ASIL-B",
    "duration": 12,
    "domain": "Body Electronics",
    "dev_model": "Agile V-Model"
}

# Send to AI assistant (Claude/ChatGPT) for tailored process definition

Practical Tailoring Examples

Example 1: Small Agile Team (ASPICE CL1)

Context: 5 developers, 6-month project, QM level, body control module

Tailored Process:

# Lightweight ASPICE for Agile Team
processes:
  SYS.2_System_Requirements:
    achievement: Largely
    practices:
      BP1_Specify_requirements: [OK] (Jira user stories + acceptance criteria)
      BP2_Structure_requirements: [OK] (Epic > Story hierarchy)
      BP3_Analyze_feasibility: [OK] (Sprint planning poker)
      BP4_Define_interfaces: [OK] (API specs in OpenAPI)
      BP5_Establish_traceability: [OK] (Jira > Git commits)
      BP6_Ensure_consistency: [OK] (Sprint reviews)
      BP7_Communicate_requirements: [OK] (Confluence + Jira)
    work_products:
      required: [User Stories, Acceptance Criteria, Interface Specs]
      optional: [Formal SRS document - use Confluence instead]
    tools: [Jira, Confluence, Git]
  
  SWE.1_Software_Requirements:
    achievement: Largely
    practices:
      # Selected key practices shown; others covered by Definition of Done
      BP1_Specify: [OK] (Detailed in Jira stories)
      BP2_Structure: [OK] (Component-based)
      BP3_Analyze: [OK] (Story point estimation)
      BP4_Ensure_Consistency: [OK] (Integrated into sprint reviews)
      BP5_Traceability: [OK] (Story > Commits > Tests)
      BP6_Verify: [OK] (Acceptance tests)
      BP7_Communicate: [OK] (Confluence + sprint demos)
    work_products:
      required: [Software Stories, DoD Checklist, Test Cases]
      skipped: [Formal SWRS - agile stories sufficient]
  
  SWE.3_Software_Design:
    achievement: Partially
    practices:
      BP1_Develop_architecture: [OK] (C4 diagrams in docs/)
      BP2_Define_interfaces: [OK] (Header files)
      BP3_Verify_design: [OK] (Architecture review in sprint)
      BP4_Establish_traceability: [OK] (Code > Stories)
      BP7_Ensure_consistency: Partially (automated checks only)
    work_products:
      required: [Architecture diagrams, Interface definitions]
      lightweight: [No formal design document - use README.md]
  
  SUP.8_Configuration_Management:
    achievement: Largely
    practices:
      BP1_Strategy: [OK] (Git branching strategy documented)
      BP2_Identify_items: [OK] (Git tags for releases)
      BP3_Control_changes: [OK] (PR reviews required)
      BP4_Track_status: [OK] (GitHub releases)
      BP5_Establish_baselines: [OK] (Semantic versioning)
    tools: [Git, GitHub, Semantic Release]

Example 2: Large Safety-Critical Project (ASPICE CL3 + ASIL-D)

For contrast, consider a larger safety-critical project with ASIL-D requirements. This necessitates fundamentally different tailoring decisions driven by regulatory mandates, independence requirements, and comprehensive verification obligations.

Context: 30 developers, 24-month project, ASIL-D ADAS system

Tailored Process:

# Full ASPICE + ISO 26262 for Safety-Critical
processes:
  SYS.2_System_Requirements:
    achievement: Fully
    practices:
      ALL_BP1-9: Mandatory (Full achievement required for CL3)
    work_products:
      required:
        - System Requirements Specification (SRS)
        - Safety Goals (ISO 26262-3)
        - Technical Safety Requirements (TSR)
        - Traceability Matrix (Requirements > Safety Goals)
        - Interface Control Documents (ICD)
        - Requirements Review Records
      format: DOORS Next modules with formal approval workflow
    reviews:
      - Technical Review after each milestone
      - Safety Review for all ASIL-D requirements
      - Customer approval for system requirements baseline
    tools: [DOORS Next, PTC Integrity, Jama]
  
  SWE.2_Software_Architecture:
    achievement: Fully
    practices:
      ALL_BP1-8: Mandatory
      Additional_ISO26262:
        - Freedom from interference analysis
        - ASIL decomposition justification
        - Hardware-software interface definition
    work_products:
      required:
        - Software Architecture Document (SAD)
        - AUTOSAR SWC definitions (ARXML)
        - Safety Architecture Analysis
        - FMEA/FTA for safety mechanisms
        - Architecture traceability (SWE to SYS)
      certification: All work products require safety manager sign-off
    tools: [Enterprise Architect, Rhapsody, Capella, medini analyze]
    note: All tools must be qualified per ISO 26262-8 for ASIL-D use
  
  SWE.4_Software_Unit_Verification:
    achievement: Fully
    practices:
      ALL_BP1-7: Mandatory
      ISO26262_additions:
        - MC/DC coverage 100% for ASIL-D
        - Back-to-back testing for code generation
        - Interface testing with stubs
    work_products:
      required:
        - Unit Test Specification
        - Unit Test Reports with 100% MC/DC coverage
        - Code Review Records (peer + tool-based)
        - Static Analysis Reports (MISRA, Coverity)
        - Traceability: Unit Tests > Software Units > SW Requirements
    tools: [VectorCAST, Tessy, BullseyeCoverage, Coverity]
    quality_gates:
      - 100% MC/DC coverage (no exceptions)
      - Zero high/critical static analysis findings
      - All unit tests passing
      - Peer review completed and documented
  
  SUP.1_Quality_Assurance:
    achievement: Fully
    practices:
      ALL_BP1-8: Mandatory
      ISO26262_ASPICE:
        - Independent quality audits every 3 months
        - Safety assessor reviews all work products
        - Tool qualification (ISO 26262-8)
    work_products:
      required:
        - Quality Assurance Plan
        - Audit Reports (quarterly)
        - Non-Conformance Reports
        - Quality Metrics Dashboard
    independence: QA team reports to separate management chain

Tailoring Documentation Template

Process Tailoring Justification Document

# ASPICE Process Tailoring Justification
**Project**: Door Lock Controller ECU
**Date**: 2025-12-17
**Approved by**: [Project Manager, Quality Manager]

## 1. Project Context

| Parameter | Value | Impact on ASPICE |
|-----------|-------|------------------|
| Team Size | 8 developers | Medium-scale processes |
| ASPICE CL Target | CL2 | Largely/Fully achievement |
| Safety Level | ASIL-B | Enhanced requirements/tests |
| Duration | 12 months | Phased work products |
| Customer | Tier-1 Automotive | Customer-specific templates |

## 2. Process Achievement Targets

### Fully Achieved Processes (86-100%)
- SWE.1 (Software Requirements Analysis)
- SWE.3 (Software Detailed Design and Unit Construction)
- SWE.4 (Software Unit Verification)
- SWE.5 (Software Integration and Integration Test)
- SUP.8 (Configuration Management)
- SUP.10 (Change Request Management)

**Justification**: Core engineering processes must be fully achieved for ASIL-B compliance.

### Largely Achieved Processes (51-85%)
- SYS.2 (System Requirements Analysis) - Rationale: Requirements primarily managed by customer
- SYS.3 (System Architectural Design) - Rationale: ECU-level focus, vehicle architecture by OEM
- SUP.9 (Problem Resolution Management) - Rationale: Using Jira with team experience, lighter process acceptable given ASIL-B context
- MAN.3 (Project Management) - Rationale: Agile ceremonies cover most practices

### Partially Achieved / Excluded
- HWE.* (Hardware Engineering) - Not applicable, hardware design by vendor
- ACQ.* (Acquisition) - Not applicable, no supplier management

## 3. Work Product Tailoring

### Required Work Products
[PASS] Software Requirements Specification (Jira + Confluence)
[PASS] Software Architecture Document (Markdown in repo)
[PASS] Source Code (C code in Git)
[PASS] Unit Test Specifications and Results
[PASS] Integration Test Specifications and Results
[PASS] Build and Release Notes
[PASS] Traceability Matrix (automated from Jira > Git)

### Simplified / Combined Work Products
⚙ Design Review Records → Captured in Git PR approvals + meeting minutes
⚙ Interface Specification → Combined into Architecture Document
⚙ Release Notes → Auto-generated from Git changelog

### Excluded Work Products (with justification)
[FAIL] Hardware-Software Interface Spec → Provided by hardware vendor
[FAIL] Supplier Monitoring Reports → No subcontractors
[FAIL] Formal Risk Management Plan → ASIL-B acceptable to use project risks in Jira

## 4. Tool Tailoring

| ASPICE Need | Standard Tool | Our Selection | Justification |
|-------------|---------------|---------------|---------------|
| Requirements Mgmt | DOORS | Jira + Confluence | Cost-effective, team familiarity |
| Version Control | Any | Git + GitHub | Industry standard, CI/CD integration |
| Build System | Any | CMake + Jenkins | Open-source, flexible |
| Test Framework | Any | Unity + Ceedling | Embedded C focus, lightweight |
| Static Analysis | MISRA checker | Cppcheck + SonarQube | Free + commercial hybrid |

## 5. Review Gates

| Milestone | Work Products Reviewed | Approver | Success Criteria |
|-----------|------------------------|----------|------------------|
| **M1: Requirements Freeze** | SW Requirements | Tech Lead + QA | All stories refined, DoD defined |
| **M2: Architecture Review** | SW Architecture | Architect + Customer | Design approved, interfaces stable |
| **M3: Alpha Release** | Code + Unit Tests | All devs + QA | All tests pass, 80%+ coverage |
| **M4: Beta Release** | Integration Tests | QA + Customer | No critical bugs, 95%+ coverage |
| **M5: Production Release** | All work products | PM + QA + Customer | Full regression pass, docs complete |

## 6. Approval and Maintenance

**Approved by**:
- [Project Manager] - 2025-12-17
- [Quality Manager] - 2025-12-17
- [Technical Lead] - 2025-12-17

**Review Frequency**: Quarterly or when project context changes significantly

**Change Control**: Any tailoring changes require approval from at least two of the three stakeholders (Project Manager, Quality Manager, Technical Lead)

Summary

Process Tailoring ensures ASPICE compliance without unnecessary overhead:

  • Context-Driven: Tailor based on team size, CL target, safety level, duration
  • Risk-Based: Full achievement for critical processes, lighter for supporting
  • Work Product Optimization: Combine/simplify where appropriate, justify exclusions
  • Tool Flexibility: Choose tools that fit your workflow and budget
  • Documented Decisions: Maintain tailoring justification for assessments

Key Principles:

  1. Compliance is not negotiable, but implementation can be tailored
  2. Document all tailoring decisions with rationale
  3. Get stakeholder buy-in on tailoring before project start
  4. Review and adjust tailoring quarterly as project evolves
  5. Use AI to generate initial tailoring, then validate with experts
Previous
Project Setup
Next
Repository Structure