SW, SYS 검증영역 병렬 진행

이전과 관련이 없는 질문인데, 만약에 설계 쪽에서 일정을 기존 계획보다 너무 많이 소모해서 일정이 촉박한데 고객 마일스톤 납기를 만족하기 위해서 검증쪽에서는 어쩔 수 없이 일정을 맞추어야해. 근데 원래 이상적으로는 ASPICE이론 기준으로 SWE.4 → SWE.5 → SWE.6 → SYS.4 → SYS.5로 끝나야 하자나... 하지만 일정을 맞추기 위해서 SWE.6과 SYS.5를 동시에 병렬로 진행해서 같은 일정에 두 프로세스를 끝낼 수 있어?

 

 

네, 현실 프로젝트에서는 그렇게 하는 경우가 꽤 있습니다.
그리고 ASPICE 관점에서도:

“반드시 SWE.6이 100% 끝난 후에만 SYS.5를 시작 가능”

이라고까지 강제하지는 않습니다.

다만 중요한 조건이 있습니다.

---

먼저 이상적인 V-model 흐름은 말씀하신 대로입니다.

SWE.4 Unit Verification
    ↓
SWE.5 SW Integration & Integration Test
    ↓
SWE.6 Software Qualification Test
    ↓
SYS.4 System Integration Test
    ↓
SYS.5 System Qualification Test

 

이건:

• 아래 단계 안정화 후
• 상위 검증으로 올라가는

“이상적인 sequential model”입니다.

---

근데 현실에서는 일정 때문에 자주 이렇게 합니다.

SWE.6  ─────┐
            ├─ 병렬 진행
SYS.5  ─────┘

 

특히:

• 차량 프로젝트
• ECU 개발
• OEM milestone
• SOP 압박

에서는 굉장히 흔합니다.

---

ASPICE가 여기서 진짜 보는 건:

“병렬 수행 자체”가 아니라

1. Entry Criteria가 정의되었는가

예를 들어 SYS.5 시작 전에:

• critical SW 기능 안정화
• known issue 수준 허용 가능
• integration baseline 존재
• 테스트 가능한 수준

등의 기준이 있어야 합니다.

즉:

“아직 SWE.6 완전 종료는 아니지만 SYS.5 시작 가능한 상태”

라는 근거가 필요합니다.

---

2. Risk를 인지하고 관리했는가

이게 핵심입니다.

왜냐하면 SWE.6 미완료 상태에서 SYS.5를 하면:

• defect leakage
• unstable behavior
• re-test 증가

리스크가 생기기 때문입니다.

그래서:

• open defect 관리
• waiver
• risk acceptance
• known issue list

같은 게 필요합니다.

---

3. 검증 범위가 정의되었는가

실무에서는 종종:

 

이렇게 운영합니다.

즉 SYS.5 전체를 다 하는 게 아니라:

• 가능한 범위 먼저 수행
• unstable 영역은 후속 수행

합니다.

---

4. 재시험(retest) 계획이 있는가

ASPICE에서 중요하게 보는 부분입니다.

병렬 진행 자체보다:

“SW 변경 후 system re-validation 어떻게 보장할 건가?”

를 더 봅니다.

예를 들어:

• SWE.6 defect fix
• SW rebuild
• 영향 기능 SYS.5 regression

이 연결되어야 합니다.

---

실제로 현업에서는 아래 방식 많이 씁니다.

흔한 현실 운영

Case 1. 부분 병렬

SWE.6 : 80% 진행 완료
SYS.5 : Stable 기능 먼저 시작

 

가장 흔함.

---

Case 2. Incremental Qualification

Build A → SYS.5 일부
Build B → SYS.5 확대
Build C → Final regression

 

자동차에서 매우 흔함.

---

Case 3. Known issue acceptance

예:

• Minor defect open 상태
• Safety 영향 없음
• SYS.5 진행 승인

이런 waiver 운영.

---

반대로 ASPICE 심사에서 위험하게 보는 건:

안 좋은 케이스

SWE.6 미완료
↓
왜 SYS.5 했는지 설명 없음
↓
결함 관리 없음
↓
재시험 계획 없음
↓
테스트 기준 불명확

 

이런 경우입니다.

---

그리고 중요한 현실 포인트:

ASPICE는 waterfall 강박 자체를 요구하는 모델은 아닙니다.

오히려 최근 심사원들은:

• iterative
• incremental
• agile-ish
• overlap development

를 많이 봤기 때문에,

“왜 병렬했는가”
“그 리스크를 어떻게 통제했는가”

를 더 중요하게 봅니다.

---

다만 Safety 프로젝트(ISO26262)가 강하게 걸리면 조금 더 엄격해질 수 있습니다.

특히:

• ASIL-C/D
• safety mechanism
• qualification evidence

는 병렬 진행 시 justification이 더 필요합니다.

 

한 줄로 정리하면:

네, 현실 프로젝트에서는 일정 때문에 SWE.6과 SYS.5를 병렬로 진행하는 경우가 충분히 있습니다. ASPICE도 병렬 수행 자체를 금지하지는 않습니다. 다만 중요한 것은 “왜 SYS.5를 시작 가능한 상태라고 판단했는가”, “미완료 SW 검증 리스크를 어떻게 통제했는가”, “재시험과 영향분석 계획이 있는가”를 설명할 수 있어야 한다는 점입니다.

 

 

그렇다면 SWE.4, SWE.5, SWE.6, SYS.4, SYS.5 모두가 병렬로 진행될 수 있어?

 

이론적으로는 가능합니다.
그리고 실제 대형 자동차 프로젝트에서는 어느 정도 그렇게 돌아가는 경우도 많습니다.

하지만 중요한 건:

“모든 프로세스를 완전히 독립적으로 동시에 수행”

하는 건 아니고,

“일부 결과를 기반으로 중첩(overlap) 수행”

한다는 점입니다.

즉 현실은 이런 느낌에 가깝습니다.

SWE.4  ──────────────
          SWE.5  ──────────────
                SWE.6  ──────────────
                    SYS.4  ──────────────
                        SYS.5  ──────────────

 

완전 waterfall이 아니라,
앞 단계가 “충분한 수준”에 도달하면 다음 단계가 시작되는 overlapping 구조입니다.

---

근데 여기서 굉장히 중요한 한계가 있습니다.

ASPICE가 허용한다고 해서:

“아무 준비 안 된 상태에서 다 동시에 테스트”

를 허용하는 건 아닙니다.

---

실제로 병렬 가능 여부는 아래 4가지에 달려 있습니다.

1. 테스트 대상 안정성(Build Stability)

예를 들어:

 

즉 완전하지 않아도:

• “해당 레벨 테스트 가능한 최소 안정성”
  은 필요합니다.

2. 테스트 목적 분리

실무에서는 각 단계 목적을 조금 나눕니다.

예:

 

그래서 일부 defect가 있어도:

• 다른 레벨 테스트는 진행 가능할 수 있습니다.

---

3. Incremental Build 전략

이게 핵심입니다.

예:

Build 1:
- 기본 boot
- CAN 통신

Build 2:
- 핵심 기능 추가

Build 3:
- 최종 기능 추가

 

이렇게:

• SYS.5는 Build1부터 일부 수행
• SWE.6는 Build2 기준 계속 진행

같이 overlap됩니다.

자동차 프로젝트에서 매우 흔합니다.

---

4. 결함 허용 정책(Open Defect Policy)

현실적으로 병렬 개발에서는:

• defect zero 상태로 못 갑니다.

그래서:

• blocker
• critical
• major
• minor

등급 관리하면서:

 

 

이런 정책이 필요합니다.

---

근데 여기서 진짜 중요한 현실 문제가 있습니다.

병렬이 심해질수록 생기는 부작용

1. 재시험 폭증

예:

• SWE.4 defect 수정
• integration 영향
• SYS.5 다시 깨짐

→ regression avalanche 발생

---

2. Test result 신뢰성 저하

예:

• SYS.5 fail
• 근본 원인이 SWE.4 defect

즉:

“이 defect가 어느 레벨 문제인가?”

구분 어려워짐.

---

3. Traceability 혼란

예:

• 어떤 build 기준 test?
• 어떤 requirement baseline 기준?
• 어떤 SW version 기준?

이게 꼬입니다.

그래서 CM(형상관리)이 매우 중요해집니다.

---

4. 조직 communication explosion

병렬화 심해질수록:

• SW팀
• Integration팀
• Validation팀
• System팀

간 coordination cost가 급증합니다.

---

그래서 성숙한 조직일수록:

“완전 순차”도 아니고

“완전 병렬”도 아닙니다.

보통은:

Controlled Overlap

형태로 갑니다.

즉:

• Entry criteria 정의
• Stable build 기준
• Regression strategy
• Risk acceptance
• Defect triage

를 둔 상태에서 overlap합니다.

---

ASPICE 심사에서도 사실:

“왜 병렬했습니까?”

보다

“병렬 상태를 어떻게 통제했습니까?”

를 더 중요하게 봅니다.

---

반대로 위험한 건 이런 상황입니다.

- baseline 없음
- build 관리 없음
- defect 관리 없음
- regression 계획 없음
- entry criteria 없음
- 누가 승인했는지 없음

 

이건 거의 chaos로 봅니다.

---

한 줄로 정리하면:

네, 현실 프로젝트에서는 SWE.4~SYS.5가 상당 부분 병렬/중첩(overlap) 수행될 수 있습니다. 하지만 이는 “완전 동시 독립 수행”이라기보다, 각 단계가 최소 안정성과 entry criteria를 만족한 상태에서 incremental build 기반으로 controlled overlap 되는 형태입니다. ASPICE도 이를 금지하지 않으며, 핵심은 병렬 수행 자체보다 그 상태를 얼마나 체계적으로 통제했는가입니다.

 

그닉까 다시 기초로 돌아가서 너가 말하는 병렬 진행이라는 건, 예를 들어 시스템 요구사항 명세서가 나오면 시스템 테스트 케이스가 모두 나올 수 있고, 시스템 아키텍처 설계서가 나오면, 시스템 통합 테스트 케이스가 모두 만들어질 수 있는데, 만약에 지금 현재 일정이 부족해서 SWE.5를 돌리는 시점인데 시스템 통합 테스트(SYS.4)랑, 시스템 테스트(SYS.5)도 동시 병행해야 한다면 SWE.5에서 안정적으로 체크가 된 기능에 관련한(엘리먼트) 것만 SYS.4, SYS.5에서 병렬 진행이 가능하다는거야? 내 말이 틀렸다면 주저말고 솔직하게 제대로 정리해서 말해줘

 

네, 지금 말씀하신 이해가 상당히 정확합니다.
오히려 이건 실제 현업에서 “Controlled Parallel Verification”을 어떻게 이해해야 하는지를 잘 짚은 겁니다.

그리고 중요한 건:

병렬 진행이라는 건 “미완성 전체를 동시에 막 검증한다”가 아니라,

“충분히 안정화된 범위(scope)에 대해서 상위 레벨 검증을 먼저 overlap한다”

에 가깝습니다.

즉 질문하신 해석이 맞습니다.

---

조금 구조적으로 정리하면:

원래 이상적 흐름

SWE.5 완료
    ↓
SWE.6 완료
    ↓
SYS.4 시작
    ↓
SYS.5 시작

 

이건:

• 아래 레벨 defect 제거 후
• 상위 검증 수행

하는 이상적 waterfall입니다.

---

근데 현실에서는 일정 압박 때문에:

SWE.5 진행 중
 ├─ 안정된 기능 A
 ├─ 안정된 기능 B
 └─ 불안정 기능 C

↓
A/B 범위에 대해 SYS.4 일부 시작
↓
A 범위에 대해 SYS.5 일부 시작

 

이렇게 갑니다.

즉:

• 전체 완료 기준이 아니라
• “기능/엘리먼트 단위 안정성 기준”

으로 overlap합니다.

---

그래서 말씀하신 이 표현이 굉장히 정확합니다.

“SWE.5에서 안정적으로 체크된 기능 관련 부분만 SYS.4/SYS.5 병렬 가능”

네. 실무에서는 거의 이런 의미로 사용됩니다.

---

특히 자동차 ECU 프로젝트에서는:

이런 식으로 scope control 합니다.

---

예를 들어:

현재 상태

SWE.5

그러면:

SYS.4 가능 범위

• CAN ↔ ECU Interface
• Speed Function Integration
• Display Signal Flow

가능

---

SYS.5 가능 범위

• 차량 속도 표시 기능
• 운전자 시나리오

가능

---

반면:

• Diagnostic
• OTA

는 SYS.4/SYS.5 제외 또는 제한.

---

즉 병렬 진행의 핵심은:

“레벨 전체 완료”

가 아니라

“검증 가능한 기능 범위 확보”

입니다.

---

그리고 여기서 아주 중요한 포인트 하나:

당신이 말한:

“시스템 요구사항 나오면 SYS.5 TC 만들 수 있음”

이것도 맞습니다.

ASPICE/V-model에서:

는 원칙적으로 early derivation 가능합니다.

즉:

• 테스트 설계는 미리 가능
• 실행(execution)은 안정성 필요

입니다.

---

그래서 실무에서는:

Test Design  → early
Test Execution → staged overlap

 

이렇게 갑니다.

---

그리고 여기서 병렬 진행이 가능하려면 반드시 필요한 게 있습니다.

핵심 prerequisite

1. Feature-based build 관리

예:

• Feature Matrix
• Integration Status
• Readiness Table

---

2. Entry Criteria

예:

• SWE.5 pass rate > 90%
• blocker defect 없음
• interface stable

---

3. 영향 분석

예:

• SWE.5 defect 수정 시
• SYS.4/SYS.5 retest 범위 정의

---

4. 형상 기준 명확화

예:

• Build 0.9.3 기준 SYS.5 수행
• Requirement baseline v1.7 기준

---

즉 결국 병렬 검증을 가능하게 만드는 핵심은:

“범위 통제(scope control)”

입니다.

---

반대로 잘못된 병렬은 이런 겁니다.

- 전체 기능 unstable
- defect flood 상태
- integration 미완료
- build 기준 불명확
- 근데 SYS.5 전체 강행

 

이건 병렬 검증이라기보다 chaos에 가깝습니다.

---

한 줄로 정리하면:

네, 당신이 이해한 방향이 맞습니다. 현실적인 병렬 검증은 “SWE.5 전체 완료 후 SYS.4/SYS.5 시작”이 아니라, SWE.5에서 충분히 안정화되고 검증 가능한 기능/엘리먼트 범위에 대해 SYS.4/SYS.5를 부분적으로 overlap 수행하는 방식입니다. 즉 병렬 진행의 핵심은 ‘전체 완료’가 아니라 ‘안정된 scope 기반 staged verification’입니다.

 

 

좋아 그러면 여기서 너가 말하는 안정(stable)의 기준은 어떻게 돼? 그리고 너가 도중에 말한 build의 개념에 대해서 자세히 알려줘

 

좋은 질문입니다. 여기서 말하는 stable은 “결함이 전혀 없다”가 아니라,

상위 레벨 테스트를 수행해도 결과를 신뢰할 수 있을 정도로 기능/인터페이스/형상이 통제된 상태

를 의미합니다.

1. Stable의 실무 기준

보통 아래 조건을 만족하면 “상위 테스트로 올려도 된다”고 봅니다.

즉 stable은 “완벽함”이 아니라 상위 검증을 시작해도 되는 최소 신뢰 수준입니다.

예를 들면:

2. Stable 판단 예시

예를 들어 “차량 속도 표시 기능”을 SYS.5에서 테스트하려면 최소한:

• CAN 속도 신호 수신 가능
• SW 내부 속도 계산 정상
• Display 출력 경로 정상
• SWE.5에서 관련 통합 테스트 대부분 Pass
• Critical/Open defect 없음
• 남은 defect가 minor이고 SYS.5 목적에 영향 없음
• 테스트할 SW build 번호가 고정됨

이 정도가 되어야 합니다.

반대로 이런 상태면 stable이 아닙니다.

• 오늘 빌드와 내일 빌드 동작이 다름
• 인터페이스 명세가 계속 바뀜
• 테스트 중 ECU 리셋 발생
• 핵심 입력 신호가 불안정
• 실패 원인이 테스트 환경인지 SW인지 구분 안 됨
• 어떤 버전으로 테스트했는지 기록 안 됨

---

3. Build란 무엇인가?

Build는 쉽게 말하면:

소스코드, 설정파일, 라이브러리, 컴파일 옵션 등을 특정 시점 기준으로 묶어서 만든 실행 가능한 SW 산출물

입니다.

자동차 ECU 기준으로는 보통:

• hex 파일
• bin 파일
• elf 파일
• s19 파일
• a2l 파일
• calibration 파일
• bootloader/application package

같은 형태가 됩니다.

즉 “테스트에 올리는 실제 SW 버전”이라고 이해하시면 됩니다.

---

4. Build가 중요한 이유

테스트 결과는 반드시 특정 build에 묶여야 합니다.

예를 들어:

SYS.5 Test Result
대상: System Test Case STC-001
결과: Pass
SW Build: B_0.9.3
System Requirement Baseline: SyRS v1.4
Test Environment: HIL Bench #2

 

이렇게 남아야 합니다.

그래야 나중에:

“이 Pass 결과는 정확히 어떤 SW 기준으로 나온 결과인가?”

를 설명할 수 있습니다.

---

5. Build와 Version의 차이

헷갈리기 쉬운데, 보통 이렇게 구분합니다.

예:

SW Requirement: v1.5
SW Architecture: v1.3
Source Code: commit a83f21
Build: B_0.9.7
Release: R1.0.0-beta

 

---

6. 병렬 검증에서 Build 운영 예시

일정이 촉박하면 이렇게 갑니다.

즉 병렬 검증은 보통 build 단위로 scope를 나눠서 합니다.

---

한 줄로 정리하면:

Stable은 “결함 0개”가 아니라 “상위 테스트를 수행해도 되는 통제된 상태”이고, Build는 그 stable 여부와 테스트 결과를 묶는 실제 SW 형상 기준입니다. 병렬 검증을 하려면 반드시 기능별 stable 기준과 build 기준이 같이 관리되어야 합니다.