Automotive Software Process Improvement and Capability dEtermination — 자동차 부품 업체들의 소프트웨어 프로세스를 개선하고 능력을 평가하기 위한 프로세스 모델.
※ SPICE는 ISO/IEC가 1993년에 개발한 SW 프로세스 평가 프레임워크로, 원래 ISO/IEC 15504였으며 현재는 ISO/IEC 330xx로 개정됨.
개발 배경
OEM의 고민:
“전장 소프트웨어 시스템의 프로세스와 제품 품질이 모두 우수한 업체를 어떻게 선정하지?”
→ 부품 업체 평가를 위한 자동차 산업 특화 프로세스 품질 평가 기준 필요.
주체와 표준 기반
- HIS (Hersteller Initiative Software): Audi, BMW, VW 등 유럽 OEM 연합이 결성한 그룹
- 현재 주관: VDA QMC Working Group 13 + Automotive SIG (Special Interest Group)
- 기반 표준:
- ISO/IEC 12207 — Systems and Software Engineering: Software Life Cycle Processes
- ISO/IEC 330xx — Information Technology: Process Assessment (구 ISO/IEC 15504)
프로세스 모델 구성
A-SPICE 프로세스 모델은 3가지 요소로 구성된다 (야구 선수 능력 평가에 비유: 평가 대상 / 평가 지표 / 평가 방법).
| 구성 요소 | 역할 | 비고 |
|---|---|---|
| 프로세스 참조 모델 (PRM) | 평가 대상 | 프로세스 ID, Name, Purpose, Outcomes 정의 |
| 프로세스 평가 모델(PAM) | 평가 지표 | Base/Generic Practices, Work Products, Generic Resources |
| 측정 프레임워크 (Measurement Framework) | 평가 방법 | ISO/IEC 33020 채택, N/P/L/F 등급 척도 |
프로세스 모델은 What을 정의하지만 How는 포함하지 않는다.
프로세스 참조 모델 (PRM)
ISO/IEC 12207 SW 생명주기 프로세스 표준에 기반.
구조
- 3개 프로세스 카테고리
- 8개 프로세스 그룹
- 32개 개별 프로세스
8개 프로세스 그룹 (A-SPICE 3.1)
| 그룹 | 약어 | 역할 |
|---|---|---|
| Acquisition | ACQ | 협력업체로부터 제품을 획득할 때 업체 선정·관리 |
| Supply | SPL | 고객에게 제품/산출물을 전달(공급)하고 대응 |
| System Engineering | SYS | 시스템 요구사항 분석, 설계, 통합, 검증 등 |
| Software Engineering | SWE | SW 요구사항 분석, 설계, 구현, 테스팅 등 |
| Management | MAN | 프로젝트 계획/통제, 위험관리 등 체계적 관리 |
| Reuse | REU | 조직의 프로세스 자산 효율적 재사용 |
| Process Improvement | PIM | 조직의 프로세스 개선 |
| Supporting | SUP | 품질보증, 형상관리, 변경 요청 관리 등 지원 |
A-SPICE 4.0 PRM — 11개 프로세스 그룹
4.0에서는 HWE / MLE / VAL 3개 그룹이 신설되어 총 11개가 됨. 기존 3.1의 “SW만 포함” 제약이 해소되고, ML 개발·시스템 Validation이 별도 그룹으로 독립했다.
| 그룹 | 약어 | 3.1 여부 |
|---|---|---|
| Acquisition | ACQ | 기존 |
| Supply | SPL | 기존 |
| System Engineering | SYS | 기존 |
| Software Engineering | SWE | 기존 |
| Hardware Engineering | HWE | 신규 |
| Machine Learning Eng. | MLE | 신규 |
| Validation | VAL | 신규 |
| Management | MAN | 기존 |
| Process Improvement | PIM | 기존 |
| Reuse | REU | 기존 |
| Supporting | SUP | 기존 |
→ 카테고리는 여전히 “Primary / Supporting / Organizational”의 3개. SEC 프로세스는 본 PRM이 아니라 A-SPICE for Cybersecurity에서 별도 확장.
A-SPICE 4.0 용어 변경: “Testing” → “Verification”
A-SPICE 4.0은 SWE/SYS 우측 프로세스 이름에서 “Test”를 “Verification”으로 교체했다.
| A-SPICE 3.1 프로세스명 | A-SPICE 4.0 프로세스명 |
|---|---|
| SWE.4 Software Unit Verification | SWE.4 Software Unit Verification (변경 없음) |
| SWE.5 Software Integration and Integration Test | SWE.5 Software Component Verification and Integration Verification |
| SWE.6 Software Qualification Test | SWE.6 Software Verification |
→ SW Unit은 정적 분석·테스트·코드 리뷰의 조합으로 일관되게 검증(verify) 할 수 있다는 관점 (ISO 26262-6 9절과 동일). Verification 관점이 “Test”보다 포괄적이라는 판단.
개별 프로세스 정의 요소
| 요소 | 예시 (SWE.1) |
|---|---|
| Process ID | SWE.1 |
| Process Name | 소프트웨어 요구사항 분석 |
| Process Purpose | 시스템 요구사항 중 SW와 관련 있는 부분을 SW 요구사항으로 변환 |
| Process Outcomes | SW 요구사항을 구현하기 위한 우선순위가 정의됨 |
이 4가지 요소는 PAM에서도 공통으로 사용됨.
SWE.1 Software Requirements Analysis Process — Base Practices
| BP | 활동 |
|---|---|
| BP 1 | Specify software requirements (명세) |
| BP 2 | Structure software requirements (우선순위) |
| BP 3 | Analyze software requirements (분석) |
| BP 4 | Analyze the impact on the operating environment |
| BP 5 | Develop verification criteria (검증 기준) |
| BP 6 | Establish bidirectional traceability (양방향 추적성) |
| BP 7 | Ensure consistency (일관성) |
| BP 8 | Communicate agreed software requirements (소통) |
→ SWE.1 활동의 자세한 내용은 소프트웨어 요구공학 참조.
SWE.2 Software Architectural Design Process
The purpose of the Software Architectural Design Process is to establish an architectural design and to identify which software requirements are to be allocated to which elements of the software, and to evaluate the software architectural design against defined criteria.
→ 소프트웨어 아키텍처를 설계·평가하고 SW 엘리먼트로 할당. 자세한 내용은 소프트웨어 설계 참조.
SWE.3 Software Detailed Design and Unit Construction
The purpose of the Software Detailed Design and Unit Construction Process is to provide an evaluated detailed design for the software components and to specify and produce the software units.
→ 상세 설계 및 유닛 구현(코딩). 자세한 내용은 소프트웨어 설계, 코딩 표준 참조.
A-SPICE 3.1 → 4.0 SWE.3 BP 변경
3.1의 8개 BP가 4.0에서 5개로 통합됨 (정적/동적 측면 명시적 분리, traceability·consistency 통합).
| A-SPICE 3.1 (BP 8개) | A-SPICE 4.0 (BP 5개) |
|---|---|
| BP1 Develop software detailed design | Specify the static aspects of the detailed design |
| BP2 Define interfaces of software units | Specify dynamic aspects of the detailed design |
| BP3 Describe dynamic behavior | Develop software units |
| BP4 Evaluate software detailed design | Ensure consistency and establish bidirectional traceability |
| BP5 Establish bidirectional traceability | Communicate agreed software detailed design and developed software units |
| BP6 Ensure consistency | |
| BP7 Communicate agreed software detailed design | |
| BP8 Develop software units |
SWE.4 Software Unit Verification
The purpose is to verify that software units are consistent with the software detailed design (A-SPICE 4.0).
Base Practices — 3.1 vs 4.0
4.0에서 7개 BP가 5개로 통합됨. 정적/동적 검증을 별도 BP로 분리하던 3.1과 달리, 4.0은 “측정 수단(measures)“을 명세·선택·수행으로 일반화.
| # | A-SPICE 3.1 | A-SPICE 4.0 |
|---|---|---|
| BP 1 | Develop software unit verification strategy (회귀 포함) | Specify software unit verification measures |
| BP 2 | Develop criteria for unit verification | Select software unit verification measures |
| BP 3 | Perform static verification of software units | Verify software units |
| BP 4 | Test software units | Ensure consistency and establish bidirectional traceability |
| BP 5 | Establish bidirectional traceability | Summarize and communicate results |
| BP 6 | Ensure consistency | |
| BP 7 | Summarize and communicate results |
→ 정적·동적 검증을 함께 수행. 자세한 내용은 검증과 확인 참조.
Test Basis: SWE.3
SWE.4의 테스트 베이시스는 SWE.3 Software Detailed Design and Unit Construction 산출물.
- SWE.3 — Definition of the behavior of a single software unit
- SWE.4 — Verification of a single software unit
→ 좌측 상세설계가 우측 단위 검증의 근거. 테스트 베이시스 원리의 A-SPICE 구현.
SWE.5 Software Integration / Component Verification
- A-SPICE 3.1: Software Integration and Integration Test
- A-SPICE 4.0: Software Component Verification and Integration Verification
The purpose (4.0) is to verify that software components are consistent with the software architectural design, and to integrate software elements and verify that the integrated software elements are consistent with the software architecture and software detailed design.
→ 4.0은 “컴포넌트 검증”과 “통합 검증”을 하나의 프로세스에서 다룬다.
Base Practices — 3.1 vs 4.0
| # | A-SPICE 3.1 | A-SPICE 4.0 |
|---|---|---|
| BP 1 | Develop software integration strategy | Specify software integration verification measures |
| BP 2 | Develop software integration test strategy (회귀 포함) | Specify verification measures for software component behavior |
| BP 3 | Develop specification for software integration test | Select verification measures |
| BP 4 | Integrate software units and software items | Integrate software elements and perform integration verification |
| BP 5 | Select test cases | Perform software component verification |
| BP 6 | Perform software integration test | Ensure consistency and establish bidirectional traceability |
| BP 7 | Establish bidirectional traceability | Summarize and communicate results |
| BP 8 | Ensure consistency | |
| BP 9 | Summarize and communicate results |
→ 자세한 내용은 소프트웨어 통합과 지속적 통합 참조.
Test Basis: SWE.2
SWE.5의 테스트 베이시스는 SWE.2 Software Architectural Design 산출물.
- SWE.2 — Definition of the behavior of a single software component (as opposed to interactions between components)
- SWE.5 — Testing of single software component (prior to integration with other components), integration, and integration testing of software units into their component
→ 좌측 아키텍처 설계가 우측 컴포넌트·통합 검증의 근거.
SWE.6 Software Qualification Test / Software Verification
- A-SPICE 3.1: Software Qualification Test
- A-SPICE 4.0: Software Verification
The purpose (4.0) is to ensure that the integrated software is verified to be consistent with the software requirements.
Base Practices — 3.1 vs 4.0
| # | A-SPICE 3.1 | A-SPICE 4.0 |
|---|---|---|
| BP 1 | Develop software qualification test strategy (회귀 포함) | Specify verification measures for software verification |
| BP 2 | Develop specification for software qualification test | Select verification measures |
| BP 3 | Select test cases | Verify the integrated software |
| BP 4 | Test integrated software | Ensure consistency and establish bidirectional traceability |
| BP 5 | Establish bidirectional traceability | Summarize and communicate results |
| BP 6 | Ensure consistency | |
| BP 7 | Summarize and communicate results |
→ SW 요구사항 기반의 검증. 측정 지표: 요구사항 충족률, 결함 해결률. 자세한 내용은 검증과 확인 참조.
Test Basis: SWE.1
SWE.6의 테스트 베이시스는 SWE.1 Software Requirements Analysis 산출물 (= 통합된 SW 전체를 대상으로 SW 요구사항 충족을 검증).
→ 베이시스 체인: SWE.1 ↔ SWE.6 · SWE.2 ↔ SWE.5 · SWE.3 ↔ SWE.4. 좌측 상위로 올라갈수록 우측도 상위 검증 단계.
VAL.1 Validation (A-SPICE 4.0)
A-SPICE 4.0에서 Validation 프로세스 그룹(VAL)이 독립하면서 추가된 대표 프로세스.
The purpose is to provide evidence that the end product, allowing direct end user interaction, satisfies the intended use expectations in its operational target environment.
→ 최종 제품이 운영 환경에서 의도된 사용 기대를 충족함을 보장. Validation 관점(“올바른 제품인가”)의 프로세스 구현.
Base Practices (A-SPICE 4.0)
| BP | 활동 |
|---|---|
| BP 1 | Specify validation measures for product validation |
| BP 2 | Select validation measures |
| BP 3 | Perform validation and evaluate results |
| BP 4 | Ensure consistency and establish bidirectional traceability |
| BP 5 | Summarize and communicate results |
BP2 선정 기준 예: 배포 목적(test bench / test track / public road validation / field use), homologation/type approval, 요구사항 확인, 이해관계자 요구/니즈 변경으로 인한 회귀 필요 여부.
→ 인수 테스팅·알파/베타 테스트의 A-SPICE 대응.
SUP.8 Configuration Management — Base Practices
The purpose of the Configuration Management Process is to establish and maintain the integrity of all work products of a process or project and make them available to affected parties.
| BP | 활동 |
|---|---|
| BP 1 | Develop a configuration management strategy |
| BP 2 | Identify configuration items |
| BP 3 | Establish a configuration management system |
| BP 4 | Establish branch management |
| BP 5 | Control modifications and releases |
| BP 6 | Establish baselines |
| BP 7 | Report configuration status |
| BP 8 | Verify the information about configured items |
| BP 9 | Manage the storage of configuration items and baselines |
→ SUP (Supporting Process) 그룹의 핵심 프로세스. 자세한 내용은 소프트웨어 형상 관리 참조.
SUP.9 Problem Resolution Management — Base Practices
The purpose of the Problem Resolution Management Process is to ensure that problems are identified, recorded, analyzed, and their resolution is managed and controlled.
4.0에서 9개 BP가 7개로 정돈됨. “전략 개발”(3.1 BP1)과 “결함 추세 분석”(3.1 BP9)이 제거되고, 4.0은 식별·분석·권한·알림·착수·추적·보고의 실행 사이클에 집중.
| # | A-SPICE 3.1 | A-SPICE 4.0 |
|---|---|---|
| BP 1 | Develop a problem resolution management strategy | Identify and record the problem |
| BP 2 | Identify and record the problem | Determine the cause and the impact of the problem |
| BP 3 | Record the status of problems | Authorize urgent resolution action |
| BP 4 | Diagnose the cause and determine the impact of the problem | Raise alert notifications |
| BP 5 | Authorize urgent resolution action | Initiate problem resolution |
| BP 6 | Raise alert notifications | Track problems to closure |
| BP 7 | Initiate problem resolution | Report the status of problem resolution activities |
| BP 8 | Track problems to closure | |
| BP 9 | Analyze problem trends |
→ 결함 관리 활동의 A-SPICE 대응. Cybersecurity 취약점 처리(SEC.4.BP3)도 SUP.9 연계.
A-SPICE for Cybersecurity
Automotive SPICE for Cybersecurity PRM/PAM — 2021.7월 발행, 같은 해 8월 Assessment Guideline 배포. SAE 21434 준수를 A-SPICE 프레임워크로 평가하기 위해 6개 사이버보안 프로세스를 기존 그룹에 추가한 확장판.
Risk Treatment Action 4분류(Avoidance, Reduction, Transfer/Share, Acceptance) 중 A-SPICE for CS는 SEC Process 구현을 통해 Risk Reduction에 집중. 나머지는 TARA·ISO 21434에서 다룸.
추가된 프로세스
| 그룹 | 약어 | 추가 사항 |
|---|---|---|
| Cybersecurity Engineering | SEC | SEC.1 요구사항 도출 / SEC.2 구현 / SEC.3 Risk Treatment 검증 / SEC.4 Risk Treatment 확인 |
| Management | MAN | MAN.7 Cybersecurity Risk Management 신규 |
| Acquisition | ACQ | ACQ.2 Supplier Request and Selection 보안 요구사항 반영 (분산 개발 계약) |
→ ISO 26262(Fault) 기반 기능 안전에 대응하여 자동차 사이버보안(Threat) 영역의 프로세스 보강. ISO 21434의 Management/Development 요구를 A-SPICE 평가 가능 형태로 매핑.
MAN.7 Cybersecurity Risk Management
The purpose of the Cybersecurity Risk Management Process is to identify, prioritize, and analyze risks of damage to relevant stakeholders as well as monitor and control respective risk treatment options continuously.
Process Outcome 8개: 범위 결정 → 관리 방침 정의 → 위험 식별 → Damage 영향 기반 우선순위 → 분석·평가 → 처리 옵션 결정 → 지속 모니터링 → 시정 조치.
Base Practices
| BP | 활동 | 핵심 |
|---|---|---|
| BP1 | Determine cybersecurity risk management scope | Project·Asset·Damage Scenario·Stakeholder·Impact category 정의. CIA 속성 + S/F/O/P (Safety/Financial/Operational/Privacy) |
| BP2 | Define cybersecurity risk management practices | FMEA, TARA, HARA, FTA 등 확립 표준 방법론 채택 |
| BP3 | Identify potential risks | Threat Scenario 결정 — TARA 3~5단계 활용 |
| BP4 | Prioritize potential risks initially for damage | Damage × Impact 초기 우선순위 |
| BP5 | Analyze potential risks and evaluate risks | Probability·Consequence·Severity. Attack Path 기반 + functional analysis/simulation/ATA (Attack Tree Analysis) |
| BP6 | Define risk treatment option | Accept / Reduce / Avoid / Share(Transfer). Accept·Share 대상 = Cybersecurity Claim |
| BP7 | Monitor risks | 상태 변화 추적, 상위 경영진 에스컬레이션 |
| BP8 | Take corrective action | 재평가 + 새 처리 방안 개발/기존 방안 조정 |
Work Products
Risk measure / Recovery plan / Risk management plan / Risk action request / Tracking system / Cybersecurity scenario register / Asset library / Risk analysis report / Risk status report.
Process Activity (예)
Develop a Cybersecurity Risk Management Plan → Analyze the Cybersecurity Risk → Verify the Cybersecurity Risk Analysis → Monitor and Adjust the Progress and Status.
SEC.1 Cybersecurity Requirements Elicitation
The purpose is to derive cybersecurity goals and requirements from the outcomes of risk management, and ensure consistency between the risk assessment, cybersecurity goals and cybersecurity requirements.
Process Outcome 4개: Cybersecurity Goal 정의 → Requirement 도출 → 양방향 추적성·일관성 확립 → 합의·의사소통.
Cybersecurity Goal: concept-level cybersecurity requirement associated with one or more threat scenarios.
Base Practices
| BP | 활동 |
|---|---|
| BP1 | Derive cybersecurity goals and cybersecurity requirements — Risk Reduction 대상 Threat Scenario에 한해 Goal 도출. Functional + Non-functional requirement + 달성 기준. Post-development phase(production·operation·maintenance·decommissioning) 포함 |
| BP2 | Establish bidirectional traceability (Requirement ↔ Goal, Goal ↔ Threat Scenario) |
| BP3 | Ensure consistency (위 두 쌍) |
| BP4 | Communicate agreed cybersecurity requirement |
Work Products
Communication record / Review record / Traceability record / Analysis report / Software requirements specification / System requirements specification / Cybersecurity goals.
Process Activity (예)
Specify → Verify → Confirm cybersecurity goals and requirements.
SEC.2 Cybersecurity Implementation
The purpose is to allocate the cybersecurity requirements to the elements of the system and software and ensure they are implemented.
Process Outcome 8개: architectural design 정제 → requirement 할당 → control 선정 → 취약점 분석 → detailed design 정제 → software unit 개발 → 양방향 추적성·일관성 → 합의·의사소통.
Base Practices
| BP | 활동 |
|---|---|
| BP1 | Refine the details of the architectural design (시스템·SW 레벨) |
| BP2 | Allocate cybersecurity requirements to architectural elements |
| BP3 | Select cybersecurity controls — 회피·탐지·대응·완화 기술적 해결책 |
| BP4 | Refine interfaces (element 간, 운영환경 경계) |
| BP5 | Analyze architectural design — 취약점 식별·분석 |
| BP6 | Refine the details of the detailed design |
| BP7 | Develop software units — language subset / strong typing / defensive implementation / coding guideline(→ 코딩 표준) / appropriate dev environment |
| BP8 | Establish bidirectional traceability (architectural ↔ detailed) |
| BP9 | Ensure consistency |
| BP10 | Communicate agreed results — 취약점 분석 결과 포함 |
Work Products
Software/System architectural design / Software detailed design / Software unit / Communication·Review·Traceability record / Vulnerability analysis report / Cybersecurity controls.
Process Activity (예)
Specify → Analyze → Verify → Confirm the Cybersecurity Implementation.
SEC.3 Risk Treatment Verification
The purpose is to confirm that the implementation of the design and integration of the components comply with the cybersecurity requirements, the refined architectural design and detailed design.
Process Outcome 6개: 검증·통합 전략 개발 → 검증 명세(test cases 포함) 개발 → 산출물 검증 수행 → 양방향 추적성 → 일관성 → 결과 요약·의사소통.
Base Practices
| BP | 활동 |
|---|---|
| BP1 | Develop a risk treatment verification and integration strategy (회귀 전략 포함). 기법: requirements-based testing, interface testing, resource consumption, control/data flow verification, 정적 코드 분석(보안 중심 coding standard), 네트워크 공격 시뮬레이션(비인가 명령/잘못된 hash key 신호/메시지 flooding), brute force 시뮬레이션, audit/inspection/peer review |
| BP2 | Develop specification for risk treatment verification — analysis of requirements, equivalence class, boundary value analysis, error guessing |
| BP3 | Perform verification activities — 설계 구현 + 컴포넌트 통합 테스트 |
| BP4 | Establish bidirectional traceability (Requirement ↔ Spec/Test Case, Design ↔ Spec, Test Case ↔ Result) |
| BP5 | Ensure consistency |
| BP6 | Summarize and communicate results |
Work Products
Test specification / Test plan / Communication·Review·Traceability record / Verification results / Test result / Verification strategy.
SEC.4 Risk Treatment Validation
The purpose is to confirm that the integrated system achieves the associated cybersecurity goals.
Process Outcome 6개: validation 전략 개발·합의 → 구현·통합 컴포넌트 validation → 활동 문서화·결과 기록 → 양방향 추적성 (Goal ↔ Spec ↔ Result) → 일관성 → 결과 요약·의사소통.
Base Practices
| BP | 활동 |
|---|---|
| BP1 | Develop a risk treatment validation strategy — 미식별 취약점 탐지 기법 포함(예: Penetration Testing). Cybersecurity Goal 달성 여부 확인 |
| BP2 | Develop specification for risk treatment validation |
| BP3 | Perform and document validation activities — 부적합·취약점 처리는 SUP.9 (Problem Resolution Management) 연계 |
| BP4 | Establish bidirectional traceability (Goal ↔ Spec, Spec ↔ Result) |
| BP5 | Ensure consistency |
| BP6 | Summarize and communicate results — 추가 발견 취약점 포함 |
SEC.3 vs SEC.4 구분
| 구분 | Verification (SEC.3) | Validation (SEC.4) |
|---|---|---|
| 대상 | 구현·통합이 요구사항 + 설계에 부합하는가 | 통합 시스템이 Cybersecurity Goal을 달성하는가 |
| 관점 | 명세 충족 (bottom-up) | 목표 달성 (top-down) |
| 기법 | 정적 분석·구조 테스트·통합 테스트 | Penetration Testing 중심 |
| 추적성 기점 | Requirement / Design | Cybersecurity Goal |
ACQ.2 Supplier Request and Selection
The purpose is to award a supplier for a contract/agreement based on relevant criteria.
Process Outcome 4개: 평가 기준 수립 → 공급사 평가 → RFQ 발행 → 계약·Action/Risk mitigation plan 합의.
Base Practices
| BP | 활동 |
|---|---|
| BP1 | Establish supplier evaluation criteria — 공급사의 사이버보안 역량(TARA·attack model·vulnerability analysis), 조직 역량(development/post-development/governance/quality/InfoSec의 best practice), Continuous operation, 이전 프로젝트 감시 증적 |
| BP2 | Evaluate potential suppliers — 이전 A-SPICE for CS assessment 요약, 조직 CSMS/ISMS 증적, 품질경영시스템 증적 활용 |
| BP3 | Prepare and execute request for quotation (RFQ) — 공급사 책임, 보안 범위(Cybersecurity Goal·Requirement), 이탈 대응 action plan 포함 |
| BP4 | Negotiate and award contract — Cybersecurity Interface Agreement 명시 (contacts, tailoring, 책임, 정보 공유, milestone, timing). 무지원 deliverable(예: FOSS)은 예외 |
Work Products
Contract / Commitment agreement / Interface agreement / Risk mitigation plan / Request for quotation / Corrective action register / Preferred supplier register / Supplier evaluation report / Supplier evaluation criteria.
→ ISO 21434 Distributed Cybersecurity Activities의 공급사 평가·RASIC 매트릭스 요구를 A-SPICE 평가 가능 형태로 매핑.
Bidirectional Traceability — A-SPICE for CS 전체 매핑
추적성과 일관성의 일반 원리를 CS 3단계에 적용. SEC/SYS/SWE 프로세스의 Traceability BP가 각 계층을 연결:
| 계층 | 좌측 (명세) | 우측 (검증) | 주관 BP |
|---|---|---|---|
| Concept Level | Threat Scenario ↔ Cybersecurity Goal | SEC.4 Validation Spec·Result | SEC.1.BP2/BP3, SEC.4.BP4/BP5 |
| System / HW·SW Level | Cybersecurity Requirement ↔ Architectural Design | SEC.3 Verification Spec·Result | SEC.2.BP2/BP8/BP9, SEC.3.BP4/BP5, SYS.*.BP |
| SW Component Level | Software Detailed Design ↔ Software Unit | Unit Verification Spec·Result | SEC.2.BP8/BP9, SWE.*.BP |
→ 전체 체인: Threat Scenario → Cybersecurity Goal → Requirement → Architecture → Detailed Design → Unit → Unit Verification → Integration Test → Risk Treatment Verification → Risk Treatment Validation.
VDA Scope
조금 더 중요한 필수 프로세스를 VDA Scope으로 지정. OEM과의 협의가 중요.
3가지 적용 케이스:
- Case 1: VDA Scope만 적용
- Case 2: VDA Scope 외의 추가 프로세스 적용
- Case 3: VDA Scope 일부 적용 (예: 부품업체가 SW만 개발하고 고객이 시스템 개발 수행, 또는 협력업체가 없는 경우)
프로세스 능력 수준
6단계 CL (0~5) — Incomplete / Performed / Managed / Established / Predictable / Innovating로 평가. 자세한 내용은 별도 페이지 참조.
7가지 핵심 컨셉
#1 플러그인 컨셉 (The “Plug-in” Concept)
시스템은 SW + HW + 메카닉으로 구성되므로, 도메인 수준 프로세스 일부/전체를 제품에 따라 평가 범위에 추가할 수 있음.
- 단, A-SPICE 3.1은 SW만 포함 (HW와 메카닉은 범위 밖).
- 관리/획득/지원 프로세스는 시스템·도메인 수준에 독립적이라 어느 수준에도 적용 가능 (예: SW 요구사항 분석 + 형상관리).
#2 V 모델 컨셉 (The Tip of the “V”)
시스템 엔지니어링 + SW 엔지니어링 프로세스 그룹은 V 모델 적용.
- 좌측 개발 프로세스 ↔ 우측 테스트 프로세스 대응
- 예: SWE.3 (SW 상세 설계 및 유닛 구현) ↔ SWE.4 (SW 유닛 검증)
#3 엘리먼트 / 컴포넌트 / 유닛 / 아이템
| 용어 | 의미 |
|---|---|
| 엘리먼트 | V 모델 좌측 아키텍처/설계 수준의 모든 구조적 개체 |
| 컴포넌트 | SW 아키텍처(SWE.2)의 최하위 엘리먼트, 상세 설계(SWE.3)의 입력 |
| 유닛 | 더 이상 분해할 수 없는 최하위 컴포넌트 (컴포넌트 = 유닛 1개 이상) |
| 아이템 | V 모델 좌측 엘리먼트에 대응되는 우측 요소 (예: 컴파일된 오브젝트 파일, 라이브러리) |
#4 추적성과 일관성
V 모델 산출물 간 양방향 추적성과 의미 일관성. 자세한 내용은 별도 페이지 참조.
#5 합의한다 / 요약하고 의사소통 한다
V 모델 작업 산출물(요구사항 명세서, 테스트 결과서 등)에 대한 리뷰 완료 후 이해관계자 간 공통 이해를 공유.
- 좌측 (개발): BP “communicate agreed …” (합의된 산출물을 의사소통)
- 우측 (테스트): BP “summarize and communicate …” (결과를 요약하고 의사소통)
#6 평가한다 / 검증 기준 / 준수 보장
- 평가한다 (Evaluate): 시스템·SW 아키텍처, SW 상세 설계의 여러 대안을 평가
- 검증 기준 (Verification Criteria): 요구사항 검증을 위한 정성·정량적 충족 기준 (테스트 케이스와 동일하지 않으며, 테스트 케이스의 입력으로 사용)
- 준수 보장 (Ensuring Compliance): 테스트 명세는 V 모델 좌측 산출물(설계서 등)을 충족하도록 개발되어야 함
#7 전략과 계획의 관계 (The Relation Between “Strategy” and “Plan”)
- 전략: 프로젝트 목표 달성을 위해 프로세스를 수행하는 방안
- 계획: 전략을 구체화하고 이해관계자와 합의해 작성한 결과물 (절차/방법, 도구/장비, 인력 활용 방식)
- CL 1은 프로세스별 계획만 필요, CL 2 이상은 일반 계획이 추가됨
CMMI / A-SPICE / ISO 26262 비교
세 표준의 위치 차이.
| 구분 | CMMI | A-SPICE | ISO 26262 |
|---|---|---|---|
| Focus | What | What | How |
| 적용 산업군 | 넓은 범위 | 자동차 도메인 | 자동차 도메인 |
| 인증 여부 | Level 인증 | Level 인증 | 공식 인증 없음 (인증 기관 자체 인증) |
표준 간의 관계 — 건축물 비유:
- 지붕: CMMI / A-SPICE, ISO 26262 (산업 표준)
- 기둥: Project Mgmt, Support, Engineering, Functional Safety
- 기반: Process Mgmt
→ A-SPICE가 평가 가능한 프로세스 항목(What)을 제시하면, ISO 26262는 안전 활동을 어떻게 수행할지(How)를 규정.
발전 이력
- 일반 산업: CMMI (V1.0 1991 ~ V3.0 2023)
- 일반/자동차: ISO/IEC 33000 Series
- 자동차 산업: A-SPICE (PRM/PAM 2005 ~ V4.0 2023), ISO 26262
산업 사례 — 세온이앤에스
세온이앤에스 정태하 대표에 따르면, A-SPICE는 Agile/DevOps와 대립 개념이 아니다. 1990년대 CMM/CMMI 전문가들 스스로 Agile을 SPICE에 얹는 방향으로 발전시켰고, A-SPICE도 ‘Agile SPICE’ 파생 모델을 공식 배포.
Agile SPICE — 통합 적용 원칙
- “회사의 품질 의사결정 체계는 유지 + 개발팀은 DevOps·Agile의 속도/유연성을 동시 확보”하는 윈윈 구조.
- OEM의 실질 기대치는 레벨 4·5 대규모 혁신이 아니라 레벨 3 수준 지속 개선.
- 100개 프랙티스 중 만족 70 + 보강 필요 30이라면 → ‘지금 가장 큰 효과를 낼 다섯 가지’를 우선 실행. 단계적 스코프 설정으로 리소스 과부하·전체 일정 지연 방지.
Document Oriented Over-engineering 경고
- 정태하 — Agile의 핵심은 “워킹 소프트웨어 > 문서”. 명세서·설계서를 폐기하자는 게 아니라 고객 피드백 가능한 정보 전달에 집중.
- 자동차 현장의 A-SPICE/기능안전성 심사가 ‘아키텍처 명세서’ 같은 명명된 문서를 강제 → 이미 작성된 정보를 다시 옮겨 적게 만들고 형식적 지적(오타·파일명)만 양산.
- CAN 시그널 명칭 변경 한 건에 결함 보고서·변경 요청·영향 분석·형상 검토를 거치는 사례 — 개발 압박 가중, 일정·품질 동시 훼손.
- 인포테인먼트는 컴포넌트 크기·안전 중요도에 따라 기준이 달라야 — 평가자가 도메인 맥락을 모르면 과도한 지적 발생.
통합 실행 — A-SPICE + 기능안전 + 사이버보안
자동차 사이버보안·ISO 21434 대응에서도 같은 사일로 문제. 세온이앤에스는 안전관리자·사이버보안 담당자·SPICE 컨설턴트가 설계·개발·검증 전 과정을 한 팀으로 통합 수행해 중복·회피를 차단.