소프트웨어 개발의 기초: 역량 평가(2)

 소프트웨어 개발의 역량을 평가할 수 있는 항목으로는 소스코드 관리시스템, 버그 관리 관리시스템, 요구사항, 일정, 테스트, 리스크 관리 등이 있습니다. 이 중 소스코드 관리시스템과 버그 관리 관리시스템은 앞 포스팅에서 정리하여 보았고, 이번 글에서는 남은 평가 항목들과, 평가 결과 분석에 대하여 정리해보겠습니다.

11. 스펙 문서를 모든 관련자가 충분히 리뷰 함.
스펙 문서를 책임 연구원(혹은 교수님), 설계자, 개발자, 기술 문서 작성자 등 모든 관련자와 충분히 리뷰하고 있다면 1점을 부여합니다. 그러나 스펙 문서를 리뷰하지 않고 있거나, 스펙 문서를 개발자끼리만 또는 일부 관련자와만 리뷰하고 있다면 0점을 부여합니다.
연구실의 경우, 스펙 문서를 개발자끼리만 공유하는 경우가 많은데, 이는 소수 인원으로 개발함에 따른 편의성 추구가 주요 원인이 될 수 있습니다. 한편, 스펙 문서의 보안 유지를 위해, 의도적으로 관련자들만 리뷰 하기도 합니다.
12. 스펙이 바뀜에 따라 스펙 문서를 업데이트 함.
스펙이 바뀜에 따라 해당 문서도 동시에 업데이트 되며 관리되고 있다면 1점을 부여합니다. 그러나, 스펙이 바뀌어도 중요한 것만 선택적으로 문서 보관함에 반영되고 있다면 0점을 부여합니다. 한편, 처음에는 스펙과 스펙 문서가 동일했으나 시간이 흐를수록 업데이트가 되지 않고, 그 차이가 점점 벌어지고 있다면 0점을 부여합니다.
문서관리의 제일 어려운 사항 중 하나가 바로 업데이트 및 유지입니다. 개발자들의 시간이 부족한 상황 속에서, 스펙의 문서까지 실시간으로 업데이트하기에는 많은 시간과 노동력이 필요하기 때문입니다.
13. 스펙 변경이 통제 관리되고 있음.
스펙을 변경하는 절차와 변경관리 담당자가 있다면 1점을 부여합니다. 그러나, 스펙을 프로젝트 관리자 혼자 알아서 바꾸고 있다면 0점을 부여합니다. 또한, 개발자가 임의로 스펙을 바꾸어 개발하고 있거나, 바뀐 스펙이 잘 파악되지 않는다면 0점을 부여합니다.
1인 개발자 진행하는 프로젝트 일 경우, 별도의 변경관리 담당자를 두기가 어렵습니다. 그렇기에 자연스럽게 혼자 바꾸게 되고, 스펙을 임의로 변경하는 상황도 발생하게 됩니다.
14. 하루 이틀 단위의 상세한 일정을 보유하고 있음.
하나의 작업목록당 하루 또는 이틀, 아니면 시간 단위로 세부적인 사항까지 자세하게 일정을 관리하고 있다면 1점을 부여합니다. 이러한 상세한 일정 계획이 없거나, 프로젝트를 수행할 때 일정을 처음과 같이 주 또는 월 단위로 관리하고 있다면 0점을 부여합니다.
보통 프로젝트이 초반부나 시작단계에서 전반적인 일정을 계획하게 됩니다. 하지만, 하루 이틀의 세부적인 시간 단위의 계획이 동반되지 않으면, 주 단위 또는 월 단위의 관리 일정도 무한히 연기될 수도 있습니다.

 

15. 프로젝트의 일정을 개발자가 산정함.
일정을 개발자나 개발 담당 연구원이 산정하고 있다면 1점을 부여합니다. 그러나 개발 일정을 연구원의 사수, 프로젝트의 관리자, 또는 상급 관리자가(보통은 교수님) 산정하고 있다면 0점을 부여합니다. 한편, 교수님이나 사수가 정한 일정에 무조건 맞추어야 하거나, 연구원의 생각이 받아들여지지 않는다면 이 역시 0점을 부여합니다.
지도를 받는 연구원의 입장과 그 위의 상급 관리자의 입장은 다를 수밖에 없습니다. 그렇기에 연구원이나 개발자의 주도적인 일정 산정이 요구됩니다.
16. 일정을 지속적으로 업데이트 함.
일정의 진행도를 매일 같이 하고 있거나, 혹은 충분히 자주 업데이트하고 있으면, 해당 일정에 문제가 생겼을 때 수정하기 위한 행동이 빠르게 이루어지고 있다면 1점을 부여합니다. 그러나 프로젝트 초기에 산정한 일정을 수정하지 않고 프로젝트를 진행하고 있다면 0점을 부여합니다. 한편 개발 일정을 각각의 데드라인에 임박해서 하고 있다면 이 역시 0점을 부여합니다.
일정을 수행하는 만큼, 해당 일정의 진척사항에 대하여 기록하는 것 또한 중요한 포인트입니다. 더군다나 일정에 피치 못할 문제가 생겼을 때, 해당 문제를 교수님이나 사수에게 빠르게 보고하여 가능한 한 빨리 조치를 취하는 것이 중요합니다.
17. 별도의 테스트 팀이나 테스트 연구원이 있음.
별도의 테스트 팀이 존재하거나, 테스트 전담 연구원이 있다면 1점을 부여합니다. 그러나 테스트를 전혀 수행하지 않거나, 개발자가 구현과 테스트를 모두 맡아서 하고 있다면 0점을 부여합니다. 한편, 별도의 테스트 연구원 없이 프로젝트 관리자나 상급 관리자가 테스트를 한다면 역시 0점을 부여합니다.
연구 방향과 결과에 대하여 최종적으로 책임을 지게 되는 것은 각 연구원의 책임이 아닙니다. 그렇기에 실험 결과 분석이나 테스트 수행에 있어서, 복합적인 검토 단계나 시스템을 구축할 필요성이 있습니다.
18. 테스트 케이스를 가지고 있음.
테스트를 하기 위한 테스트 케이스가(버그 사례) 있다면 1점을 부여합니다. 그러나 프로젝트와 실험을 진행하면서 주먹구구식으로 디버깅을 한다면 0점을 부여합니다. 또한, 케이스가 존재하지만 너무 빈약하여 해당 프로젝트에서 요구되는 모든 성능에 대해 검증하지 못한다면 이도 0점에 해당합니다. 처음에는 테스트 케이스가 충분하였으나, 프로젝트나 연구가 업데이트될 때, 같이 업데이트되지 않는다면 0점을 부여합니다.
디버깅 시에는 해당 버그 요소들을 정의하고 정리하는 작업이 동반되어야 합니다. 별도로 기록을 수행하는 경우, 발생했던 케이스에 대하여 일부 누락될 가능성이 있고, 개발 시간에 쫓기어 기록 자체가 누락되는 경우가 있기 때문입니다. 
19. 프로젝트 리스크 관리가 됨.
리스크 관리대장이 있고, 리스트를 관리하고 있다면 1점을 부여합니다. 그러나 프로젝트를 수행하면서 리스크에 대해 신경 써본 적이 없거나, 관리대장 없이 각 개인 연구원들이 고민한다면 0점에 해당합니다.
20. 리스크에 대한 백업 플랜이 있으며, 리스크 관리계획이 주기적으로 갱신됨.
리스크를 꾸준히 관리하고 업데이트 하고 있으며, 리스크 발생을 방지하기 위한 별도의 행동이 있다면 1점을 부과합니다. 그러나 프로젝트 초기에 리스크 관리대장을 만들고 사용하지 않는다면 0점입니다.

 

평가 결과 분석
20개 항목에 해당될 경우 각 항목마다 1점씩 평가하여 합산하면 됩니다. 
20점: 기초가 잘 되어 있는 경우입니다. 소프트웨어 프로젝트를 수행하는 데 있어서 별 문제가 없을 수 있습니다.
15점 이상: 기초는 양호한 편입니다. 해당 연구실에서는 프로젝트를 진행하는데 있어서 소프트웨어 개발로 인한 문제는 없을 수 있습니다.
10점 이상: 프로젝트를 진행하는데 있어서 여러 가지 문제를 개선하려는 노력이 있었겠지만, 여전히 개선해야 할 사항들이 많이 존재합니다. 저의 경우도 여기에 해당하였었고, 이 책의 내용대로 개선 작업을 수행 중입니다.
10점 미만: 프로젝트에 성공했다면 기적이나 운이라고 여겨야 합니다. 개발 환경에 있어서 전반적인 개선이 필요한 상태입니다.

-참고문헌-

• 소프트웨어 개발의 모든 것, 김익환, 페가수스