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

 대학원 연구실 생활을 하면 필수적으로 여러 개의 프로젝트에 참여하게 됩니다. 연구에 필요한 소프트웨어 개발을 할 때, 보통 열악한 환경과 바쁜 실험 일정으로 인해 주먹구구식으로 개발하고 관리는 손도 못 대는 경우가 많이 발생합니다. 보다 나은 개발 환경을 갖추기 위하여 다음의 역량 평가를 해보면 좋을 듯합니다. 역량 평가 항목은 소스코드 관리시스템, 버그 관리시스템을 우선 정리하고, 이후에 요구사항이나 일정, 테스트, 리스크 관리에 대하여 정리해 보도록 하겠습니다.

 

 

1. 소스코드 관리시스템을 딱 하나만 사용.
Subversion, Visual SourceSafe 등의 여러가지 시스템 중에서 하나만 사용하는 경우, 또는 분산 소스 코드 관리 환경만 구축하여 사용하는 경우 1점을 부여합니다. 만약, 소스코드를 개발자의 개인 PC나 공용의 파일 서버에만 보관하고 공유하고 있다면 0점을 부여합니다. 
대개의 작은 규모의 연구실의 경우 개인적으로 문서들을 보관하거나, 사수 또는 부사수와 같이 필요한 인원들만 공유하며 사용하게 됩니다. 이는 해당 연구인원의 부재 또는 졸업 이후, 원활한 인수인계가 이루어지기 어려운 문제가 있고, 그로 인한 연구자료의 분실 및 방치를 유발하는 주된 원인이 됩니다.
2. 소스코드 및 개발 문서는 소스코드 관리시스템에 저장.
소스코드와 개발 문서를 비롯한 제품에 관련된 모든 자료가 소스코드 관리 시스템에 저장되어 있다면 1점을 부여합니다. 만약 일부 소스코드 파일이 개발자 PC에 있다면 0점을 부여합니다. 소스코드 관리시스템에 있는 소스코드만으로 빌드를 할 수 없으면 0점을 부여합니다. 
위의 1번과 마찬가지로 많은 연구실의 경우, 대부분의 소스코드 파일이나 실험 데이터 등이 개발자나 연구자의 개인 PC에 있는 경우가 많습니다.
3. 각 개발 마일스톤마다 베이스라인을 설정함.
Tagging 등의 명령어를 이용해서 베이스라인을 설정하고 있다면 1점을 부여합니다. 만약, 이런 관리 프로그램이나 개념을 모른다면 0점을 부여합니다. 또한, 매번 프로젝트가 다 끝난 뒤에 한 번만 베이스라인을 설정하면 0점을 부여합니다.
베이스라인 구축은 선택사항이라고 생각하거나, 존재 자체를 모르는 연구원들이 꽤 많습니다. 이는 소프트웨어 개발의 경험 부재 또는 협업이 없이도 개개인이 연구를 하며 프로젝트를 진행하는 연구 환경에서 비롯됩니다. 
4. 소스코드 관리시스템 사용시 또는 로그인 시, 메시지를 작성하는 규칙을 가지고 있고, 모든 연구자나 개발자가 이를 지킴.
소스코드 관리시스템을 사용하거나 로그인 시, 모든 개발자가나 연구원이 메시지를 사전에 정해진 규칙에 맞게끔 남기고 있다면 1점을 부여합니다. 일부 개발자들이 소스코드 관리시스템에 로그인할 때, 메시지를 남기지 않는 가면 0점을 부여합니다. 만약, 메시지를 남기고 있어도 규칙이 없거나, 규칙이 있어도 많은 개발자가 규칙을 지키지 않으면 0점을 부여합니다. 
코드 관리 시스템을 구축하여도, 다른 연구원들이 그 규칙을 지키지 않거나 애초에 사용하지 않는 경우가 많이 있습니다. 필요성은 인지하여도 시간이 없다고 하거나 새로운 시스템에 적응하기 싫어하는 경우도 있습니다.
5. 모든 소스코드를 리뷰함.
소스코드 리뷰에 대한 규칙이나 약속을 만든 문서가 있고, 이를 토대로 모든 소스코드를 리뷰할 수 있는 환경이라면 1점을 부여합니다. 그러나, 소스코드에 대하여 리뷰를 해본 적이 없다면 당연히 0점을 부여합니다. 리뷰에 관해서 그때그때 내키는 대로 한다거나, 프로젝트 일정 때문에 처음에는 한 번씩 주기적으로 하다가, 프로젝트가 종료되는 시점에서는 일정에 쫓겨서 못하는 경우 역시 0점을 부여합니다. 또한, 자동정적 분석도구 등을 이용하여 소스코드의 형식만 확인한다면 이 역시 0점을 부여합니다.
일부 연구실의 경우 소스코드 리뷰의 중요성을 모르는 경우도 종종 있습니다. 특히, 개인의 역량이 뛰어나거나, 프로젝트가 개인만이 수행하는 경우, 리뷰를 건너뛰는 경우를 볼 수 있습니다.

 

 

6. 자동으로 일일 빌드를 함.
빌드 서버에서 매일 정해진 시간에 자동으로 빌드를 하고 있다면 1점을 부여합니다. 만약 하루에 한번씩 빌드를 하지만 수동으로 손을 여러 번 거쳐야 빌드가 된다면 0점을 부여합니다. 또한, 연구자들이 각자 알아서 빌드를 하고 있거나, 일일 빌드를 하더라도 그 실패 비율이 10% 이상이라면 0점을 부여합니다.
매일 정해진 시간에 자동으로 빌드가 된다면, 유사실에 코드를 복원하여 최소한의 피해만 입게 되고, 최대한 원래 작업량만큼 복구할 수 있게 됩니다. 그러나 많은 경우 해당 프로젝트 프로그램을 테스트하는 경우에 빌드를 하는 모습을 볼 수 있습니다.
7. 버그관리 시스템을 오직 한 개만 사용함.
버그 관리시스템을 하나라도 사용하고 있다면 1점을 부여합니다. 그러나 시스템이 아닌 엑셀 파일 등의 수동 파일을 만들고, 이를 공유 서버에 올려서 버그를 공유하고 있다면 0점을 부여합니다. 또한 철저한 버그 관리 시스템이 아닌 내부망이나 게시판의 작업 순서를 따르고 있다면 0점을 부여합니다.
개발의 대부분의 시간은 디버깅 단계에서 이루어집니다. 그렇기에 버그를 효율적으로 관리하고 추적해야 나중이나 후임자가 인계 받아서 작업을 수행 시에 최소한의 노력으로 해당 디버깅 작업을 완료할 수 있게 됩니다. 
8. 버그를 버그관리시스템에 등록하고 있고, 다른 곳에 별도로 관리하지 않음.
최종 프로그램에 대한 모든 버그나 유지보수 사항들을 버그관리시스템에 등록하고 있다면 1점을 부여합니다. 그러나, 일부 버그가 개별로 관리되거나, 메일 또는 전화 혹은 일반적인 회의록을 통하여 전달된다면 0점을 부여합니다.
9. 모든 연구원이 버그관리시스템을 활용함.
모든 연구원이 버그 리포트를 위해 단일 버그 관리시스템을 사용하고 있다면 1점을 부여합니다. 단, 일부 연구원이 버그 관리시스템을 사용하지 않거나 기타 별도의 시스템을 활용한다면 0점을 부여합니다.
10. 프로젝트의 문서화 및 문서를 소유함.
완성하려는 프로그램의 요구사항 또는 기능명세서와 같은 역할을 하는 기술 문서가 만들어져 있고, 해당 문서를 보유하고 있다면 1점을 부여합니다. 그러나 간단한 기능 또는 요구만을 기록하고 있다면 0점을 부여합니다. 또한 체계화된 문서가 없어도 0점을 부여합니다.

 

 

-참고문헌-

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