프로젝트 산출 목록

 

프로젝트를 수행할 때 PM 이나 PL들은 상당히 많은 문서들을 작업합니다.
그래서 프로젝트가 문서로 시작해서 문서로 끝나는 것은 당연지사입니다.

728x90

아래의 내용은 프로젝트를 진행하면서 발생하는, 만들어야 하는 문서들을 정리한 것 입니다.
물론 이 많은 양의 문서들이 다 들어가는 것은 아닙니다. 프로젝트의 규모에 따라 많은 차이가 나긴 하지만
특별한 것들은 제외하고 아래의 문서들은 클라이언트에게 제출하지 않더라도 기본으로 작성을 해야 하는 것들입니다.

물론, 기획팀에서 이 많은 양의 문서들을 다 만드는 것은 아니며,
기획팀에서, 디자인팀에서, 개발팀에서 준비를 해야 하는 문서들도 있을 수 있습니다.
프로젝트의 시작과 끝은 프로젝트 매니저나 기획팀에서 시작과 마무리를 하지만 중간중간에 일어나는 것들은
대부분 실무에 필요한 문서들이 대부분이라, 필요에 따라 각 파트별로 문서를 작성하여 공유하기도 합니다.

물론 각각의 진행 단계를 확인하고, 체크하는 것은 당연히 PM이나 PL이 되겠지요.

진행단계별 챙겨야 하는 문서들을 정리한 것이니 확인해 보시기 바랍니다.  

1. 분석단계

1-1. 현업요구사항정의서

해당 프로젝트를 수행하는 가장 기본이 되며 고객의 needs을 담고 있는 문서입니다. 이를 통해 다양한 스펙산정이 가능합니다. 이부분에서 요구ID를 도출합니다.

1-2. 기능챠트

현업요구사항을 근간으로 큰 카테고리를 만들어 한눈에 해당 프로젝트가 무슨 일을 하는것인지 보여줄 있습니다. 이부분은 개발방법론에 따라 유스케이스다이어그램으로 대치할 수도 있을 것으로 판단되어지고, 기능챠트와 같이 가도 무관하다는 판단입니다.

1-3. 프로세스 정의서

기능챠트를 기준으로 각각의 프로세스를 보여줍니다. 때에 따라 확대된 프로세스의 표현도 가능합니다. 개발방법론에 따라 시퀀스다이어그램을 넣어도 무방하다는 판단입니다.

1-4. 인터페이스정의서

상기 현업요구사항정의서,기능챠트,프로세스정의서를 근간으로하여 레가시 및 대외계 시스템, 웹서비스 등 어떤식으로 인터페이스를 해야 한다는 정의를 담고 있습니다.

2. 설계단계

 

2-1. UI(화면)설계서

웹App 혹은 CS App 든 간에 고객이 사용하고자 하는 화면단을 보여주는 문서입니다.

2-2. ERD

해당 업무의 DB를 생성하고 테이블관의 상관 관계를 표현하는 문서로 더이상 설명이 필요없으리라 믿습니다.

 

2-3. 테이블목록

테이블정의서도 있지만, 테이블목록은 관리자가 한눈에 시스템을 구성하고 있는 DB테이블을 보여준다는 측면에서 필수라는 판단입니다.

2-4. 테이블정의서

테이블필드 value와 설명, 바이트수 등을 표기합니다.

2-5. 프로그램 목록

실직적으로 설계단계에 프로그램목록이 나오지 않지만 일단 설계 단계에 넣는 것이 타당한 것 같습니다. 개발방법론에 따라 클래스다이어그램, 컨포넌트명세서, 클래스정의서 등도 포함 될 수 있을 것 같습니다.

2-6. 개발표준 정의서

변수명, brace, 클래스네임,파일명,규칙등 코딩관련 규칙을 정의함으로써 일선 담당자가 소스코드를 확인해도 눈에 익숙할 수 있게 하기위한 문서입니다.

2-7. 단위테스트 시나리오

분석,설계의 기본적인 요건이 충적되면 이쯤하여 단위테스트시나리오가 나와야 할 것 같습니다. 아마도 고객의 싸인이 필요한 부분일 것입니다.

2-8. 통합테스트 시나리오

설계단에서 하기는 많은 어려움이 있지만, 단위테스트를 근간으로 고객의 요청을 좀더 보완하여 통합테스트시나리오를 작성합니다. 고객의 싸인은 필수입니다.

 

3. 개발단계

3-1. 소스코드(개발원시코드)

말그대로 오류수정까지 끝난 원시코드 자체를 말합니다.

3-2. 단위테스트 결과서

단위테스트시나리오를 기준으로 테스트한 결과를 보여줍니다. 아마도 많은 문제점을 안고 있고, 이 과정을 통해 고객의 요구사항도 많은 변동이 있는 시점입니다. 변경요청서도 필요할 시점입니다.

3-3. 결함/오류보고서

단위테스트를 통해 알게된 에러의 원인과 수정에 대한 내용을 나타냅니다. 이를 통해 오류코드정의서를 뽑아내고 보완합니다.

3-4. 오류코드 정의서

해당시스템에서 발생할 수 있는 오류들을 코드화하여 보여줍니다.

3-5. 통합테스트 결과서

단위테스트를 통해 보완된 내용들을 포함하고, 통합테스트시나리오의 보완을 통해 실시된 통합테스트 결과를 보여줍니다. 개발을 완료했냐 안했냐의 잣대가 되는 문서로서 고객의 싸인이 가장 필요한 부분입니다. 이부분에서 반려가 일어나면 위의과정을 반복해야 합니다.

3-6. 시스템 이행계획서

통합테스트가 끝나면 Standby하고 있는 시스템에 소프트웨어,하드웨어 기타 등을 몇월, 몇칠, 몇시에 누구누구가 무엇을 가지고 옵져버는 누구이며 어떻게 이행을 할 것인지 등을 표현합니다.

 

4. 구현단계

 

4-1. 시스템 이행결과서

시스템 이행계획서를 통해 이행된 결과를 확인받는 문서입니다.

4-2. 사용자매뉴얼

사용자화면이 있을 경우 나오는 매뉴얼입니다.일반적인 조작법을 기록하며, 화면 등을 예시합니다.

4-3. 운영자매뉴얼

시스템전반에 관한 모든 내용을 담고 있습니다. 분석,설계,개발 절차에서 나오는 문서를 담고 있습니다.

4-4. 교육(인수)명세서

사용자매뉴얼 및 운영자매뉴얼을 중심으로 해당 담당자 및 사용자에게 시스템전반 및 세부사항을 교육/인수한후 싸인받는 문서입니다.

4-5. 개발산출물별 검사리스트

예시된 산출물들이 이상없이 인수되었는지를 개별로 체크한후 고객의 싸인을 받는 문서입니다.

4-6. 프로젝트 완료보고서

최종적으로 개발한 내용, 인도물, 하드웨어, 고객대표, 개발자대표싸인을 받음으로써 명실상부한 프로젝트 완료보고서입니다.

 

 

출처 : http://kimdirecter.blog.me/95463793