뒤늦게 알게 된 ASPICE - MAN.3

○프로젝트 범위에 대한 정의가 뜻하는 것은?
제품 개발 관점과 업무 수행 관점을 말한다.  또 Q,C,D 각가의 관점에서
목표가 있어야 한다.ex) CL2 달성, 불량률 몇 %이하로 등등
 
○목표 성취에 대한 실현 가능성이란?
고객 마일스톤과 align된 내부의 마일스톤, 예산, 필요 자원, 기술력을 말한다.
 
○실현 가능성을 왜 따지게 되는가?
예를 들어 현재 프로젝트를 기술적으로 수주 받을 여력이 안되더라도 회사는
돈을 버는 이익 집단이기에 일단 어떻게든 수주를 받는다. 먼저 수주를
받아 놓기 때문이다. 때문에 앞으로 이 기술적으로 안되는 부분에 대해서
외주를 준다던지 교육을 시켜 역량을 키운다던지 그런 프로젝트 완수를 위한
대응책을 계획해야 한다. 
 
○MAN.3에서 말하는 프로젝트 내 인터페이스가 될 수 있는 것?
회의체, 메일, 리뷰회의, 도구의 알림 등이 될 수 있다.
또 인터페이스는 내 외부 고객 모두에 대해서 있어야 하고 특히 외부 고객에
대해서 외부 고객의 이름과 Contact point는 명시가 되어야 한다.
 
○MAN.3에서 corrective action의 예시?
전체 개발 주기의 업무 중 엔지니어링 관련한 업무는 그 중요도가 매우 높다
이런 업무들이 하루라도 밀리면 전체 업무가 하루가 밀리게 되는 것이
critical path라 하는데 해당 critical path를 반드시 따로 관리하며 이것에
영향을 미치게 된다고 예상이 되면 반드시 바로 시정조치에 들어가야 한다.
 
MAN.3에서 말하는 일관성을 보장하라는 것은?
예를 들어, 프로젝트 관리를 할 때 일정이 연기될 거 같은 경우 우리는 무언가 
조치를 취해야 하고 일정 조정에는 여러 업무를 통한 방법이 있고 그 업무들
간에 영향을 미칠 수 있음을 우리는 짐작할 수 있다. 만약 일정을 늘리는
방법을 택한다면, 필요 인원을 증가하는 방법은 적게 늘려도 되고, 만약
일정을 늘리지 않는 방법을 택한다면, 필요 인원을 늘려야 한다. 
즉 프로젝트 완수를 위해 서로 유기적으로 연결된 것들 끼리는 반드시
논리적 일관성이 있어야 한다는 것이다.

즉 내가 보기에 MAN.3는 제품 완성을 위한 Q,C,D관리와 기술적인 부분과 제품은 전혀 터치하지 않지만, 그 기술 문서와 제품을 생성하는 주체 및 모든 환경적 영향을 관리 하는 것