Why difficult to perform the Verification(Test)?

※ 해당 글은 "SW 요구사항 개발" 강의를 들으면서 메모하고 싶은 내용을 기록하고 공유하기 위함입니다. 저작권 및 위배가 되는 경우 해당 글은 별도의 공지 없이 삭제될 수 있습니다. 가급적 위배가 되지 않는 내용에서 글을 작성합니다. 

 

 

검증(테스트)이 어려운 이유는? 

이유는 요구사항을 기반으로 해야 하기 때문이다.

 

즉, 요구사항이 불명확거나, 요구사항이 모호하거나, 요구사항이 일치하지 않거나 충돌이 발생하는 등 모두를 포함해서 검증(테스트)가 어려운 이유이다.

 

 

ASPICE PAM3.1 Figure D.2 — The tip of the "V"

 

위 ASPICE PAM3.1 그림에서의 V 사이클 그림을 보면 요구사항을 분석하면서 System Qualification Test 단계가 수행된다. 즉 검증(테스트)의 수행이 개발 초기에도 이뤄져야 하고 할 수 있다는 것이다.

 

그런데 요구사항이 실제로 Release 되는 시점은... 많이 다르다.

현실적으로 V Cycle 모델링을 고려한 개발의 첫 단계부터 삐그덕 거릴 수 있다는 것이다.

첫 단추가 늦게 시작(?)되니 검증(테스트)도 늦어지게 된다.

 

요구사항으로이 문제가 되는 원인으로 아래와 같은 예시가 있다.

• 비공식적인 정보 취합
• 암시적인 기능
• 잘못 전달된 가정
• 형편없이 구체화된 요구사항
• 변경 프로세스 미 이행

 

실제 경험을 바탕으로 위 원인이 되는 경우에 이런 경우들이 있었다.

• A는 C다. --> 출처가 어디인가? 모른다. 그렇게 알고 있다. 근거가 무엇인가? 그렇게 들었던 것 같다....
• 요구사항을 첫 Release 했는데, 이미 구현된 소프트웨어가 나와 있었다? 
  시스템 요구사항을 고려한 것이 아니라, 고객 요구사항 (합의 전 또는 구체화되기 전)을 바탕으로 구현되는 경우
• 요구사항을 아주 늦게 Release 하는 경우.. 
• 변경 요청이 SW 엔지니어 사이에서만 알고 있는 경우, 몇 명의 소수의 엔지니어들만 알고 있는 경우
• 각 프로젝트 별로 각 요구사항을 작성하고 관리하는 경우.. Bundle 또는 유사한 프로젝트의 개수만큼 요구사항 관리가 늘어나게 되어 변경에 긴밀하게 대응하기 어렵고, 업데이트 되거나 Release 되는 포인트가 늘어남에 따라 점점.. 
• 요구사항을 작성해놓고, Review 없이 Release 하는 경우.. 예전부터 말씀 드리지만, Review는 합의를 하는 가장 좋고 빠른 과정입니다. 
• 요구사항 작성에 너무 공을 들이는 경우.. 요구사항은 점진적으로 발전, 보완, 진화하게 됩니다. 첫 Release에서 모든 요구사항을 성숙도 있게 하려는 너무 신중한 모습은... 아니 잘못된 모습은... 옳지 않습니다.

 

위 내용을 포함해서 수 많은, 무수히 많은 사례가 있지만 간략하게 이정도까지만 적어 본다.

 

감사합니다.