프로젝트 문서작업

오늘은 프로젝트 문서작업에 대하여 말씀드리고자 합니다.

보통의 경우에 SW개발 프로젝트가 끝나갈 즈음이 되면 검수를 위해서 발주처는 산출물들을 요청하게 됩니다. 계약사항에 명기된 인도품에 대한 검수 절차에 들어가는 것이지요. 어떤 경우에는 그 종류만 20여가지가 되는 문서 작업을 추가로 해야 하는 경우가 발생할 수도 있는데 , 나중에 사용되지도 않을 문서들을 작성하기 위해 개발 라이프싸이클 초기부터 기억을 더듬어 정리를 한다는 것은 개발팀으로서는 여간 고역이 아닐 수 없습니다.

"프로젝트 라이프싸이클 모델"을 어떻게 적용하는가에 따라 상당히 다르겠지만 ( 12207 같은 ) 이러한 산출물들의 예를 들어보면 아래와 같습니다. ( 인터넷에서 잠깐 긁었습니다. 내용에는 크게 관심갖지 마십시요. )

01. 착수

      01. 제안서

      02. 프로젝트 계획서

      03. 프로젝트 일정

02. 분석

      01. 기능 요구 사항

      02. 기능 흐름도

      03. 시스템 구성도

03. 설계

      01. 메뉴목록 및 구조도

      02. 화면목록 및 설명

      03. 데이터 흐름도(Data Flow Diagram)

      04. Entity 목록 및 상세

      05. ERD

04. 개발

      01. 작업 일정 및 담당자 배정표

      02. 어플리케이션 구조도

      03. 공용모듈목록 및 설명

      04. 개발 산출물 디렉토리별 설명

      05. 화면별 오브젝트

      06. 단위테스트 결과서

      07. 통합테스트 결과서

05. 구현

      01. Client 설치 및 운영메뉴얼(사용자 메뉴얼)

      02. Server 설치 및 운영메뉴얼(운영자 메뉴얼)

      03. 인수인계 계획서

      04. 검수 확인서

99. 참고자료

      01. 회의록

      02. 업무보고

문서가 한두장 정도라면 부담이 안되겠지만 , 책 한권 분량이 되는 문서도 있어 진짜 난감한 일이 아닐 수 없습니다. 게다가 이런 일에 대한 일정을 충분히 반영 해두지 않는 관리자가 있었다면 퇴근은 다 틀린 이야기입니다. 현실적으로 더 심각한 것은 실제로 이 문서들의 대부분은 유지보수 또는 추가개발등의 단계에서 재활용이 될 이유가 없다는 것입니다. 심하게 말하면 아까운 하드디스크 용량만 차지 한다는 것입니다. 이런걸 주고 받으려고 주소록 찾아가며 이메일도 주고 받고요.

이렇게 할 문서 작업은 차라리 하지 않는 것이 좋습니다.

고객을 설득하시기 바랍니다. 그 시간에 품질개선 작업을 하겠다고요.

내부 감사가 있어서 안된다고요 ? 문서의 품질에 대해 협상을 하시기 바랍니다.

이런 문제가 발생하는 원인은 제안 단계에서 또는 프로젝트 초기에 협의가 되었어야 할 사항을 놓쳤기 때문이기도 합니다.

문서작업에 대한 관점을 바꿔 보겠습니다.

먼저 프로젝트 관리자 (PM)은 이 번 프로젝트를 어떻게 진행 하겠다는 세부적인 계획이 있어야 합니다. 이 계획 수립 단계에서 개발자(리더)들을 활용 할 수는 있겠지만 주요 결정은 관리자가 해야 합니다.

여기서 관리자들이 기본적으로 생각하셔야 할 것은 "산출물"은 말 그대로 프로젝트를 진행하다보면 저절로 나오게 되는 문서가 되도록 계획을 해야 한다는 것입니다. 아래의 그림은 소프트웨어 라이프싸이클을 따라가며 발생 할 수 있는 문서들을 모두 나타낸 것입니다.

그런데 이 모든 문서가 다 나오게 되는 프로젝트 계획을 만들 수 있을까요 ?

아마도 이집트 피라미드 건설과 같은 일은 위의 그림에 나온 문서 만으로도 모자랄 수 있겠지만  현실에서

그런 계획을 세우기는 어렵습니다. 여하튼 계획을 세우게 되면 그 계획이 진행되는 경로를 따라서 발생하게 되는 문서들이 산출물들이 되는 것입니다.

그래서 산출물은 프로젝트를 하게 되면 저절로 나온다는 것이지요. 진행하지도 않은 프로세스 단계의 결과 문서가 나와서는 안된다는 것입니다. DFD ( Data Flow Diagram ) 같은 경우 , OOP 기반의 웹개발 환경에서는 작성의 필요가 거의 없습니다. 그리고 모듈명세서 등의 모듈기반의 여타 설계가 없는 프로세스에서 DFD를 만든다는 것도 앞뒤가 맞지 않습니다.

웹개발의 경우에 대체로 나올 수 있는 산출물은 다음과 같습니다.

- 제안서 : 이미 작성이 되어 있을 것입니다.

- 프로젝트 계획서 ( Scope & Plan ) : 프로젝트에서 개발의 범위를 정의해 둔 문서입니다.

- SRS ( Software Requirement Spec. ) : 기능 요구사항과 시스템 요구사항 , 품질기준 등등

       다음단계의 설계 작업에 영향을 미칠 수 있는 모든 사항을 명세화 해두는 문서 ,

       프로젝트에서 가장 중요한 문서로서 관리자, 고객, 개발자, 등 프로젝트 관련된

       모든 사람이 관여되는 문서

- 설계서 ( 데이터베이스 , 화면 , Action , SQL ) : UI 디자인 , 테이블 구성 , ERD , SQL 등 , 규약서 등

        디자이너 , UI개발자 , 설계자 , 관리자가 관여되는 문서로서 구현 단계에서 필요한 모든 내용을 기술

- 구현 스캐쥴 ( Time Table ) : 지난 포스팅 참조 "조엘따라하기"

        구현단계는 설계에 따른 구현 일정대로 구현을 진행

- 테스트 결과서 : SRS에 명기된 기능리스트를 중심으로 작성한 테스트 대상 리스트 및 그 결과

- 잔여 버그 및 개선이 필요한 사항

- 사용자 / 관리자 설명서

프로젝트 문서라는 것은 프로젝트 라이프싸이클의 진행에 따라서 현재 단계에서 나오는 문서는 다음 단계에서 진행이 되어야 할 내용들을 정리해 두는 것이라고 이해를 하셔야 되고 또 그렇게 작성을 하시면 됩니다. 즉 요구분석 단계의 산출물인 SRS는 설계단계에서 사용하게 되는 것이고 설계 단계의 결과인 설계문서는 다시 구현 단계에서 담당자들이 사용하게 되는 것입니다. 이렇기 때문에 문서는 프로젝트를 진행하게 되면 저절로 나오는 것이지 종료단계에 시간을 잡아서 한꺼번에 몰아서 하는 것이 아닙니다.

이번 글 문서 작업에 대하여 정리해 보겠습니다.

1. 관리자는 프로젝트 초기에 개발 프로세스를 세부적으로 정하여 필요한 산출물을 확정해야 한다.

2. 프로세스상 현단계의 문서 작성의 기준은 다음 단계에서의 활용을 기준으로 한다.

    프로젝트 멤버들간에 이미 알고 있는 내용들은 생략합니다.

3. 관리적으로 문서작업은 별도 시간을 잡지 않는다.

글을 쓰다보니 SI 형태의 개발에 관한 글이 많군요. ( 서비스 형태의 프로젝트이지요. )

시간나면 제품 개발 프로세스에 관해서도 써봐야겠군요.