미정

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)을 건너뛰어도 되는지 명시되지 않았습니..