뒤늦게 알게 된 ASPICE - SUP.9

○ SUP.9에서 식별된 문제를 Closure해야 하는 자는?

최초 문제 제기자가 문제가 해결되었는지 봐야 한다.

 

○문제해결 관리 프로세스 감독은 누가 해야 하나?

기본적으로 문제해결관리 담당자는 해야 하고 또한 추가적으로 이슈와 관련이

있는 담당자도 할 수 있다.

 

○문제 해결관리 담당자는 무슨 일?

식별된 문제를 해결하는 것이 아니라 누군가에게 식별된 문제가

문제해결 관리 절차에 따라 진행이 되고 있고 각 이슈들의 상태를

관리 감독하여 문제가 제 시간에 빨리 해결이 되도록 지원하는 자다

 

○문제를 해결해야 할 때 반드시 명시해야 하는 것?

문제의 근본원인을 추적해야 한다

예를 들어 엔지니어링 이슈인 경우 그 추적관계를 따라가서 최초 문제의 

근원을 밝혀내야 한다. 관리 지원의 영역의 경우에는 추적으로 따라갈 것은

없지만 근본 원인을 파악하면 좋다. 엔지니어링에서의 이런 근본 원인

파악은 나중에 엔지니어링 테스트 쪽에서 회귀시험을 할 때 써먹는다.

 

○긴급 해결

Ex)

-소스코드 먼저 수정해서 보내고 연관된 모든 상위 문서를 나중에 

업데이트 한다. (원래는 상위 문서가 먼저 업데이트 되어야 하고 소스코드가

변경되어야 하는 게 올바로 보이지만.. 긴급할 땐 이렇게 한다는 것)

-혹은 회귀시험 중 일부만 하고 전체 회귀시험은 나중에 하겠다 

※고객에서 긴급 해결을 원하는 경우가 있다. 이럴 때 이런 전략이 반드시 

있어야 하는데 없다면 혼난다.

 

○경보 알림이란?

베이스 모델이 A,B 프로젝트에서 사용되었는데 만약 A에서 그 모델에 의한

문제가 발생시 이를 B에도 발생할 수 있음을 알려주어야 하는 장치를 마련

하라는 것이다. 

※알림을 주고 받는 자가 미리 정의되어 명시가 되어야 한다.

 

○문제해결 관리와 변경요청 관리의 차이?

문제해결은 지금 식별된 문제를 적기에 제대로 끝내자는 마인드

변경요청 관리는 어떤 이슈 때문에 이미 베이스라인 되었던 문서를

변경을 해야 할 때 해당 절차를 태움

 

○문제 경향 분석의 목적?

next cycle에서는 혹은 next 프로젝트에서는 문제 경향을 미리 분석해서

재발하지 않도록 하자~

이를 응용하여 전략을짜서 가장 버그가 많이 발견된 component는 다음에

반드시 inspection으로 검토하자! 이런 식으로 써먹는 것

 

○문제 상태 보고는

ALM을 통해 Dash board를 캡쳐해서 활용 가능 근데 주기적으로 미리

캡쳐를 해놔야 문제 상태가 어떻게 되는지 보이므로 이렇게 할 거면

반드시 주기적으로 캡쳐하자