미정

심사원이 보고 싶은 것은 **"각 마일스톤에서 배포되는 SW가 정확히 어떤 사양(Spec)이고, 어떤 품질 기준을 통과한 물건인지"**에 대한 명확한 정의입니다. 이를 만족시키기 위해 프로젝트 계획서(또는 부속 릴리즈 계획서)에 포함되어야 할 핵심 수준은 다음과 같습니다.1. 배포 대상의 구체적 정의 (Content Definition)각 마일스톤(PROTO, M/CAR, P1 등)에서 배포될 SW의 **'실체'**를 정의해야 합니다.기능 범위: 해당 배포본에 포함되는 요구사항 ID 리스트 또는 핵심 기능(Feature) 목록.HW 버전: 이 SW가 구동되는 타겟 보드의 버전(예: HW v1.0용인지 v2.1용인지).변경 사항: 이전 배포 대비 추가된 기능이나 수정된 버그 리스트.2. 마일스톤별 '종료 ..

ASPICE MAN.3 (프로젝트 관리) 프로세스에서 "마일스톤별 목표와 범위"를 묻는 질문은 프로젝트의 **'가시성(Visibility)'**과 **'실현 가능성(Feasibility)'**을 확인하려는 의도입니다.단순히 "PROTO 때는 기능을 구현한다" 수준으로 쓰면 'Partially Achieved(일부 달성)'를 받기 십상입니다. 심사원이 고개를 끄덕일 만한 수준은 다음과 같습니다.1. 지적받지 않는 '목표(Objective)'의 수준목표는 **SMART(구체적, 측정 가능, 달성 가능, 실제적, 시간 제한)**해야 합니다.Bad: "PROTO 단계에 맞는 SW 기능을 개발하고 고객에게 전달함." (측정 불가)Good:"고객 요구사양서 v1.2 기반의 핵심 기능(기능 ID: F01~F20) 구..

ASPICE 심사(특히 SUP.9 문제 해결 관리)에서 "긴급 시 조치(Urgency/Emergency Action)" 절차는 심사원이 협력사의 **'위기 대응 성숙도'**를 판단하는 아주 중요한 척도입니다.단순히 "빨리 고친다"라고 쓰면 100% 지적을 받습니다. 심사원들이 합격점을 주는 기준과 지적을 하는 기준을 명확히 나누어 정리해 드릴게요.1. 지적을 받는 수준 (Bad Case)"문제가 발생하면 즉시 담당자에게 보고하고, 긴급 회의를 거쳐 최우선으로 수정하여 배포한다."왜 지적받나? * 객관적 기준 부재: 무엇이 '긴급'인지 기준이 없습니다. (누구에겐 긴급인데 누구에겐 아닐 수 있음)프로세스 무시: 긴급하다고 해서 ASPICE의 기본인 검증(V-Model)을 건너뛰어도 되는지 명시되지 않았습니..

✅ 결론베이스라인 = 반드시 고객(OEM)에게 릴리즈되는 형상항목이다 ❌베이스라인 = 특정 시점에 “통제 기준으로 고정된 형상 집합”이다 ✅1️⃣ 핵심 개념부터 바로 잡자베이스라인의 본질Baseline = 변경 통제를 위한 기준점 👉 목적:변경 기준 제공비교 기준 제공추적 기준 제공👉 즉Baseline ≠ Release 2️⃣ Release와 Baseline의 관계관계는 이겁니다:Baseline ⊇ Release (일 수도 있음) 경우 1 (겹치는 경우)Baseline → 고객 릴리즈 경우 2 (훨씬 더 일반적)Baseline (내부)→ 여러 개 존재→ 그 중 일부만 Release 3️⃣ 왜 다르냐 (중요)Baseline은 내부 통제 개념예:- 요구사항 Baseline- 설계 Baseline- 코드 ..

한 줄로 먼저 말하면:테스트 방법(Test method)은 “어떤 방식으로 검증할 것인가”이고,Test case 도출 방법은 “무슨 시험 케이스를 어떤 논리로 뽑아낼 것인가”이다.즉,테스트 방법 = 시험의 실행 방식 / 검증 접근테스트 케이스 도출 방법 = 시험할 입력, 조건, 시나리오를 만드는 방법1. 개념 비교1) 테스트 방법(Test method)이건 말 그대로어떤 방식으로 대상이 요구사항을 만족하는지 확인할 것인가에 대한 것이다.예를 들면:요구사항 기반 테스트인터페이스 테스트fault injection testback-to-back testboundary testrobustness testintegration testscenario-based test즉, 시험의 “종류”나 “검증 방식”에 가깝다...

각 고객 마일스톤(PROTO, M/CAR, P1, P2)은 각각 “독립적인 V-cycle을 가진다 고객 마일스톤의 본질은:"각 단계마다 검증된 수준의 제품을 제공하라" 이다. 👉 즉 매 단계마다“이 시점에서 요구사항이 만족되는가?” 를 확인해야 함👉 이게 바로 V-cycle 그래서 만약 PROTO에 V 사이클을 생략하고 M/CAR에서 V사이클하고P1, P2의 V사이클을 돌리겠다? 이것도 허용 안됨.!단 하나의 사이클도 생략이 되면 안됨. 대신 리소스가 부족할 경우 OEM과 사전 협의하에 각 마일스톤 단계의 검증 범위를 줄여서 사이클을 돌리는방법이 있음 물론 마지막 마일스톤에선 고객 요구사항의 모든 범위를 만족해야 함 예를 들어 실제 프로젝트는 이렇게 돌아갑니다:🔹 PROTO부분 V-cycle- 일..

ES/MS 스펙 “문서 이름”을 그대로 요구사항으로 가져오면 안 되는 이유는 “요구사항이 아니라 참조 문서(reference)”이기 때문입니다.그리고 그 이유는 단순히 버전 문제 하나가 아니라 구조적으로 4~5가지 중요한 이유가 있습니다.✅ 1️⃣ 가장 핵심 이유: “요구사항 vs 참조문서” 차이ES/MS 스펙은 본질적으로:요구사항 문서 ❌ (direct requirement 아님)외부 표준/참조 문서 ✅ 즉"ES95400-10 적용" 이건 요구사항이 아니라👉 “이 문서를 참고해라”는 선언문제이걸 그대로 쓰면:❌ Requirement: ES95400-10 적용 👉 이건 검증 불가능한 요구사항올바른 방식✔ The system shall comply with voltage transient require..

고객 요구사양서(Customer Requirements)는 “외부에서 들어온 것”이고이해관계자 요구사항 명세서(Stakeholder Requirements Specification)는 “그걸 포함해서 내부적으로 정리·확장한 것”입니다.단순 번역 차이가 아니라 역할과 책임, 활용 목적이 완전히 다릅니다.1️⃣ 핵심 차이 한 줄 정리 2️⃣ 개념 구조 (ASPICE 기준)전체 흐름은 이렇게 이해하면 정확합니다.즉👉 고객 요구사항은 그대로 쓰는 게 아니라 반드시 가공됨3️⃣ 고객 요구사양서 (Customer Requirements)정의고객(OEM, Tier1 등)이 제공한 요구사항특징외부에서 들어옴형식 제각각 (문서, Excel, DOORS 등)불완전 / 모호한 경우 많음예시👉 문제점구체성 부족테스트 가..