SW 품질관리

[왜 시스템 개발만 하면 싸워댈까] 시스템개발 V모형과 요구사항 추적표 예시

바질크림떡볶이 2023. 4. 5. 15:24

 

[ 왜 시스템 개발만 하면 싸워댈까 ]  호소카와 요시히로

 

 

■ 줄거리 

아리스카와 도코라는 가상의 IT 전문 변호사가 주인공으로, 시스템 개발 중에 발생하는 여러 문제를 이야기 형식으로 풀어냄. 해결방안은 실제 IT 소송이나 현장 분쟁 사례를 근거로 제시함.

 

이해하기 쉽게 폭포수 모형 개발 방식을 기준으로 써서 현 진행하고 있는 프로젝트에도 대입해 보며 읽을 수 있었음. 프로젝트의 QCD (Quality 품질, Cost 가격, Delivery 납품기간)을 고민하는 PM, 개발자, 발주자까지 도움이 될 책이라고 생각된다.

 

 

목차 

Chapter1. 요구사항 정의 | 말했다 vs. 안했다, 하기로 했다 vs. 안 했다

Chapter2. 프로젝트 계획과 관리 | 일정표 체크만이 관리는 아니다.

Chapter3. 설계 | 벤더와 발주자가 협의할 사항

Chapter4. 프로그래밍 | 작동만 하면 끝이 아니다.

Chapter5. 테스트 | 뭘 테스트해야 하는지 아는가?

Chapter6. 계약과 프로젝트 완료 | 뭘 약속했지?

 


 

요구사항 추적표 예시

 

시스템 요건이나 설계가 바뀌면 그와 관련된 다른 문서와 프로그램도 빠짐없이 수정해야 한다. 수정한 요소가 어떤 문서와 프로그램에 영향을 미치는지 정확하게 파악하려면 요구사항 추적표를 만들어 양방향으로 추적할 수 있게 하면 효과적이다.

 

작업산출물 사이의 양방향 추적으로 가능하게 하는 방법을 설명하기 전에 알아두면 좋은 시스템 개발 V 모형을 간단히 설명한다. 다음은 시스템 개발의 일반적인 공정 관계를 나타낸 그림으로, 실선 화살표는 작업 순서를 나타내고 점선 화살표는 상호 정합성을 유지하기 위한 산출물의 연관성을 나타낸다.

 

 

시스템 개발  V  모형

 

그림을 보면 요구사항 정의서는 외부설계서와 시스템 테스트 관련 문서(계획서와 명세서, 테스트 시나리오 등)에 논리적 모순이 없어야 함을 알 수 있다. 그러므로 요구사항 정의서를 수정하면 외부설계서나 시스템 테스트 관련 문서들도 수정해야만 한다. 이는 다른 문서나 프로그램도 마찬가지이다.

 


추적 가능성 확보란 이처럼 수정해야 할 부분이 어딘지 구체적으로 쉽게 추적할 수 있는 것을 의미한다. 사실 많은 프로젝트가 이와 같은 추적 가능성을 확보하지 못해 요건이나 설계를 변경했을 때 누락된 요소가 생겨 분쟁이 발생한다.

 

그래서 이런 양방향 추적 가능성을 확보하려고 고안한 것이 다음 표와 같은 ‘요구사항 추적표’로, 상당히 효과적이다. 요구사항 추적표를 작성해 관리하면 변경이 있을 때 어디에 영향을 주는지 일목요연하게 알 수 있다.

 

이렇게 관리하면 요건 A-02에 변경사항이 생겼을 때 설계 21, 설계 31, 설계 33이 영향을 받는 것을 금방 알 수 있다. 위 도표는 요구사항과 외부설계만으로 작성했지만 똑같은 방법으로 외부설계와 내부설계, 외부설계와 프로그램과 같이 작성하면 요건을 변경했을 때 누락된 요소가 생겨 분쟁이 발생하는 것은 훨씬 줄어들 것이다.

 

그러나 추적표를 작성하고 유지하기 위해서는 많은 공수가 들기 때문에 일정 규모 이상의 프로젝트에서는 대부분 전용 시스템을 사용한다.