문서등급:                (배포제한 내역:              )

<프로젝트 타이틀>

프로젝트 수행 계획서

문서 버전:

작성일:

작성자1:	(연락처:              )

작성자2:	(연락처:              )

작성자3:	(연락처:              )

(회사명) 부서명:

*문서검토자

부서명	직책	이름	서명	서명 날짜

문서 수정 내역(Revision Chart)

호서대학교 게임공학과	문서완료일	문서번호:	페이지: /총페이지수
작성자:	승인자:	문서관리자:
다찾아봐 프로젝트 수행 계획서		문서버전:

문서 버전	수정 승인 완료일	주 저자 및 공동작성자	주요 수정 내용	승인자

목차

1. 프로젝트 개요

1.1 목표

1.2 프로젝트 범위

1.3 제약

1.4 게임개발 방법

1.5 프로젝트 수행 조직

2. 프로젝트 관리 기본 방향

2.1 프로젝트 관리 초점

2.2 단계별 관리 지표

2.3 프로젝트 추적 및 통제(Project Tracking and Control)

2.4 문서 작성/승인/등록 지침

3. 일정 계획

3.1 단계별 작업계획

3.2 주요경로상의 작업내역

3.3 추진 일정

4. 자원 소요 계획

4.1 인력의 스킬 및 자원 요구사항들

4.2 인력자원 소요 계획

4.3 인력자원 확보 계획

4.4 일반자원 소요 계획

5. 개발 비용

5.1 개발비용 개요

5.2 개발비용 상세내역

6. 품질관리 계획

6.1 품질 목표 및 지수

6.2 품질관리 체계 및 수행 절차

7. 위험관리 계획

7.1 식별된 위험 내역들

7.2 위험의 대응 활동 내역들

7.3 위험 모니터링 방법

8. 형상관리 계획

8.1 형상식별 체계

8.2 버전관리

8.3 형상변경 신청/검토/승인 절차

9. 테스트 계획

9.1 게임개발 툴 시험

9.2 게임프로그램 컴포넌트 및 DB 단위시험

9.3 그래픽 리소스 단위시험

9.4 사운드 리소스 단위시험

9.5 게임소프트웨어 통합시험

9.6 게임소프트웨어 품질시험

9.7 게임시스템 통합시험

9.8 게임시스템 품질시험

9.9 게임밸런싱 품질시험

10. 의사소통 계획

10.1 이해관계자들의 기대사항

10.2 조직 간의 의사소통 방식

10.3 의사소통 활동 내역

11. 개발 방법 및 도구

11.1 설계 및 분석 기법

11.2 개발 도구

11.3 프로그래밍 언어

11.4 관리 도구

[첨부] 각종 문서양식들

용어설명

참고자료

<본문 작성 가이드>

* 작성기준

1. 이 문서의 기재된 내용들을 통해 프로젝트를 추진하면 개발활동이 계획대로 진행되고 보고되고 통제될 수 있기에 충분한가 ? (충분성)

-적어도 타문서 참조의 안내를 포함하면 충분한가?

2. 이 문서의 기재된 내용들은 실제로 추진하는 경우 발생할 수 있는 오류들은 없는가? (정확성)

3. 이 문서의 기재된 내용들은 비현실적인 부분은 없는가? (실현성)

4. 이 문서의 기재된 내용들은 프로젝트 참여자들이 모두 이해하기 쉽도록 작성되어 있는가? (독해성)

1. 프로젝트 개요

1.1 목표

<작성요령>

목표는 달성여부를 객관적으로 판단할 수 있도록 SMART 원리로 내용을 작성함

1) Specific: 목표 정의가 분명하게 표현되어야 함

2) Measurable: 측정 가능한 진행 상황 관리 기준이 존재

3) Assignable: 목표완수를 위한 한 명의 책임자를 지정

4) Realistic: 현실적인 제약 조건들을 수용

5) Time-related: 목표달성 제한 기간 존재

<작성 예제>

(1). 제작기간: 6개월

(2). 제작비용: 2000만원

(3). 게임의 오락성:  연령층별 평가자들 30명의 평가를 통해 경쟁제품 "찾아봐"보다  오락성 우위의 판정이 70%이상

1.2 프로젝트 범위 (산출물 범위 및 활동 범위)

<작성요령> WBS의 산출물 내역 표로 작성하고 인도물을 구분표시하고 산출물들의 관계도를 그릴 것

<작성예제>

(1) 산출물 목록 (수정요“ 인도물->인도여부 [O, X])

(2) 산출물의 관계도

1.3 제약

<작성 요령> 프로젝트 챠트나 기타 내외부적인 제약 사항들을 항목별로 육하원칙에 따라 표의 형태로 작성함

<작성 예제>

순번	제약 항목	제약 내용	비고
1	개발 예산	2000만원	시설비는 제외
2	개발 기간	6개월

1.4 개발 방법론

<작성 요령>

게임개발표준프로세스 자료를 참고하여 개발단계를 구분하여 WBS의 최하위단계의 작업패키지 작업 명을 제시함

(가) 게임 개발 단계(게임개발 표준 프로세스 참고)

<작성 예>

컨셉단계

기획단계

1차 설계 단계

1차 구현 단계

1차 테스트 단계(프로토)

2차 설계

단계

2차 구현단계

2차 테스트 단계(알파)

3차 설계 단계

3차 구현 단계

3차 테스트 단계(C베타)

밸런싱 단계

4차 테스트 단계(O베타)

1차 디버깅 단계

2차 디버깅 단계

3차 디버깅 단계

4차 디버깅 단계

(나) 각  개발단계 추진 절차 (게임개발 표준 프로세스 참고요)

<작성 예> 컨셉 단계 추진 절차

1.5 프로젝트 수행 조직

<작성요령> 프로젝트 추진 조직도를 각 조직의 역할을 작성함

<작성 예>

2. 프로젝트 관리 기본 방향

2.1 프로젝트 관리 목표

<작성 요령>

프로젝트 관리의 목표들을 개조식으로 작성함

<작성 예>

관리 목표

① 기간, 예산, 품질 요구사항에 만족하는 산출물들을 개발하는 것

② 기존의 개발 결과물들과 아웃소싱이 가능한 도구, 기술을 적극적으로 활용하여 새롭게 개발해야 할 활동들을 최소화하여 개발 리스크를 줄이는 것

2.2 단계별 관리 지표

<작성요령>

각 개발단계별 관리 핵심내용을 정리하여 설명함

<작성 예>

개발단계	작업내용	관리대상 주요마일스톤	위험요소	관리 핵심내용
컨셉단계	-아이디어 검토 -시놉시스 작성 -시놉시스 평가	-게임시놉시스		-게임 시놉시스

2.3 프로젝트 추적 및 통제(Project Tracking and Control)

<작성요령>

프로젝트 상황 보고에 대한 내용과 프로젝트 점검일의 내역들을 알기쉽게 작성한다.

<작성 예>

(가) 상황 보고

-Daily Delta Report(매일)

.개인별로 하루 업무 종료 1시간 전에 담당 활동의 하루동안 진척내용들을 간략히 작성하여 이메일로 PM에게 보고함

- 주간업무 보고

-월간 업보 보고

.전체 모든 프로젝트 참가자들이 모여 부서별 진행상황을 발표하고 토의함

.매월 마지막 주 금요일 오후 4시 대강당에서 실시함

.각 부서는 목요일 오후 4시까지 PM에게 보고서를 제출할 것

2.4 문서 작성/승인/등록 지침

<작성요령>

-강의자료 중『문서관리법』자료를 참고하여 작성하세요.

<작성 예>

(가) 문서 작성 원칙

- 일반 원칙

(1) 정확성 : 6하 원칙에 의거하여 정확하게 작성한다. (바른 글)

(2) 신속성 : 요점과 결론을 파악하기 쉽게 작성한다. (알기 쉬운 글)

(3) 용이성 : 쉽게 해석할 수 있는 평범한 말과 문장으로 작성한다. (쉬운 글)

(4) 경제성 : 반복사용하는 문서는 내용을 양식화하여 작성한다. (표준화)

- 문서표지의 표식

사용의 정확성과 보안성을 확보하기 위해 문서의 표지에 적절한 표식을 하도록 한다. 단, 고객에게 배포되는 문서의 경우 배포번호, 문서관리번호 등 고객측과 직접 관련이 없는 사항들은 문서의 외부표지에 표시하지 않고 내부표지에 표시할 수도 있다. 문서의 표식은 다음과 같다.

(1) 비밀구분 : 극비, 사내한

비밀문서 표지의 우측상단에 표시한다. 단, 사내한 문서에 한하여 문서표지에 “ 사내한” 이라고만 표시할 수 있다.

(2) 관리본표시 : Controlled copy 또는 Uncontrolled copy

관리본문서의 복사본에 한하여 표지의 우측상단(비밀구분 바로 밑)에 표시한다.

(3) 문서관리번호, 경고문구, 배포번호 표시

문서발행목록표에 등재하여 문서관리번호를 부여받은 극비, 사내한 문서 또는 관리본문서에 한하여 표지의 좌측상단에 표시한다. 이때 배포번호는 임의로 복사된 사본을 식별할 수 있도록 반드기재하여야 한다.

(4) 소유권자, 운영자, 사용자

극비 및 사내한 문서에 한하여 표지의 하단 적절한 곳에 표시한다.

3. 일정 계획

3.1 단계별 작업계획

<작성요령>

각 개발단계의 시작일과 종료일, 주요작업내용, 주요마일스톤을 작성한다.

<작성 예제>

개발단계	시작일	종료일	주요 작업 내용	주요 마일스톤
컨셉 단계	2006. 01. 20	2006. 3. 20	-아이디어 검토 -시놉시스 작성 -시놉시스 평가	게임시놉시스
1차 기획단계

3.2 주요경로상의 작업내역

<작성요령>

주요 경로상에 있는 활동들의 시작일과 종료일, 담당자, 활동내용, 산출물을 작성한다.

<작성예>

순번	활동명	담당자	선행조건 (시작일)	종료일	주요 활동 내용	산출물
1	아이디어 검토	홍길동	-프로젝트 승인 (2006. 01. 20)	(2006. 1. 23)	-아이디어 검토	검토결과서
2	시놉시스 작성

3.3 추진 일정

<작성요령>

활동명	1	2	3	4	5	6	7	8	9	10	11월	12월
아이디어 검토

4. 자원 소요 계획

4.1 인력의 스킬 및 자원 요구사항들

<작성요령>

필요한 인력이 갖추어야 할 스킬과 경력에 대하여 기술하고 필요한 자원들의 사양의 요구사항들을 작성한다.

<작성 예>

(가) 필요한 인력의 갖추어야 할 스킬 및 경력

인력 구분	스킬 요구사항	경력 요구사항	채용방법	비고
프로젝트 관리자 A	-PM기본지식 -MS Project, MS Excel, MS 워드, 한글 상급자	-웹게임개발 프로젝트 관리 경험 4회 이상	-공개채용 -인터뷰 & 포트폴리오 심사
프로젝트 관리자 B
게임디자이너
게임클라이언트

(나) 필요한 자원의 요구사항

자원 구분	모델명	사양	비고
문서작성용 PC	-삼성 매직스테이션 M567	-인텔 펜티엄-4 1.5GHz -메모리 256MB -하드디스크 80GB	-기본 사양에 하드디스크만 추가
게임엔진개발용 PC

4.2 인력자원 소요 계획

<작성 예>

인력구분	1개월	2개월	3개월	4개월	5개월	6개월
프로젝트 관리자 A	1명	1명	1명	1명	1명	1명
프로젝트 관리자 B		2명	2명	2명	2명	2명
클라이언트 프로그래머		1명	1명	1명	1명	1명

4.3 인력자원 확보 계획

<작성예>

인력 구분	인원수	채용방법	채용시기	비고
프로젝트 관리자 A	1	-공개채용 -인터뷰 & 포트폴리오 심사	2006. 01.
프로젝트 관리자 B	2
게임디자이너
게임클라이언트

4.4 일반자원 소요 계획

<작성 예>

자원 구분	1개월	2개월	3개월	4개월	5개월	6개월
문서 작성용 PC	1대	-	-	-	-	-
게임엔진 개발용 PC		2대	-	-	-	-
아도비 포토샵 7.0		1본	-	-	-	-
공CD	200장	50장	50장	10장	10장	10장

5. 개발 비용

5.1 개발비용 개요

<작성 예>

5.2 개발비용 상세내역

<작성 예>

(가) 인건비

(나) 기자재

(다) 소모품

6. 품질관리 계획

6.1 품질 목표 및 지수

<작성 예>

품질 항목	품질 목표	품질 지수	테스트 방법	테스트결과 판정 방법
동작 무결성	5종류의 인터넷 통신망에서 50개 스테이지의 플레이 동안 오류 발생 무	오류발생건수	5종류의 인터넷 통신망에 3가지 PC를 접속하여 50개 시험용 스테이지를 플레이하고 오류여부를 관찰함	오류발생 유무로 합격 불합격으로 판정
동작 안정성
오락성 요구사항 만족도
시스템 사양 요구사항 만족도

6.2 품질관리 체계 및 수행 절차

<작성 예>

7. 위험관리 계획

7.1 식별된 위험 내역들

<작성 예> Top 10 위험들

등급	위험 구분	영향	발생 가능 개발단계	해결책
1	미션 디자인에서의 실패	실패	기획 단계	가능하면 빨리 미션종료
2	사용자 인터페이스 디자인 실패	실패		가능하면 빨리 UI 종료
3	QA 리소스가 프로젝트에 늦게 추가됨	품질하락,실패		QA 리소스의 조기 확보
4	음성녹음이 늦어짐	실패		가능하면 빨리 대화 녹음 종료
5	과잉개발	실패		기능 추가 중지
6	베타 테스터 모집이 늦어짐	실패		베타 테스터 모집을 일찍 실시
7	서버 안정성	품질 하락		테스트 툴 생성
8	디자인 과정의 과잉 분배	엉망이 된 품질관리		디자이너의 수를 줄임
9	반복된 야근	실패, 품질저하		문제 논의
10	너무 대중적인 UI	개성의 부재		디자이너의 수를 줄임

7.2 위험의 대응 활동 내역들

<작성 예>

등급	위험 구분	발생 가능 개발단계	위험 대응 활동 계획
1	미션 디자인에서의 실패	기획 단계	1. 활동목표 2. 활동추진 방법 3. 활동기간 4. 담당자 5. 소요자원 6. 소요예산
2	사용자 인터페이스 디자인 실패
3	QA 리소스가 프로젝트에 늦게 추가됨
4	음성녹음이 늦어짐
5	과잉개발
6	베타 테스터 모집이 늦어짐
7	서버 안정성
8	디자인 과정의 과잉 분배
9	반복된 야근
10	너무 대중적인 UI

7.3 위험 모니터링 방법

<작성 예>

8. 형상관리 계획

<작성요령>

형상이란  개발목표(예: 게임)의 하드웨어 혹은 소프트웨어를 구성하는 각 요소(부품)의 사양을 말한다. 이들 구성요소들의 사양은 전체로 통합되어 오류 없이 동작되기 위해서는 설계서에서 지시된 규정을 지켜야만 한다.

따라서 PM은 각 개발팀에서 개발한 구성요소들의 사양을 변경하는 사건이 발생했을 때는 전체적으로 통합했을 때 문제없는지 검토하여 승인하고 관리하여야 만 한다.

8.1 형상식별 체계

<작성요령>

프로젝트 산출물의 형상을 식별하기 우한 고유 식별 번호 체계를 설명한다.

<작성 예>

프로젝트 산출물의 형상을 식별하기 위해서 다음과 같은 식별 번호 체계를 사용 하여 식별 번호를 부여한다. 식별 번호 체계는 다음과 같다.

- 개발단계구분 코드: C(콘셉단계), P(기획단계), I(구현단계)

- 버전 코드: Major + Minor + Release : 1.00.R

(예) P_프로젝트계획서_Ver1.00.R

8.2 버전관리

<작성 예>

-초안 문서는 Minor 버전만을 가질 수 있으며 0.10를 부여하고 0.1단위로 증가시키도록 한다.

-품질보증담당자(QA)의 검토가 완료되거나 합동검토를 거치 문서는 1.0을 부여할 수 있으며 이후 버전 증가는 Major 변경(ex:핵심체계 변경이나 전체내용의40 %이상 변경)인 경우 1.0단위로 Minor 변경이나 수정이 발생한 경우 0.1단위로 증가할 수 있다.

-단, 단계말 검토 이후 베이스라인으로 설정된 문서의 변경은 공식변경절차에 따라 진행되며 변경이 허가된 이후 담당자에게 변경할 문서를 전달하고 변경된 사항을 확인후 QA가 버전을 부여할 수 있다.

-릴리즈된 최종 문서에는 R를 부여하도록 하며 릴리즈 이후 문서가 변경된 경우, 이전 릴리즈 문서에서 R를 삭제하고 최신 릴리즈 문서에 R를 부여하도록 한다.

8.3 형상변경 신청/검토/승인 절차

<작성예>

개발팀

형상변경

관리팀

변경 영향 분석

이해관계자협상

승인거부

승인

변경신청

형상변경수용

9. 테스트 계획

9.1 게임개발 툴 시험

<작성예>

테스트 구분	테스트 목적	테스트 내용	결과 판정기준	담당자/시기
스프라이트 편집기 요구사항 만족시험	스프라이트 편집기의 사양(기능 및 동작)이 요구사항 만족여부 검사	요구사항의 각 항목별로 만족여부 검사	요구사항의 각 항목의 만족여부로 합격/불합격 판정	홍길동(QA팀)/개발팀의 테스트 신청할 때

9.2 게임프로그램 컴포넌트 및 DB 단위시험

<작성예>

- 본 시험은 각 컴포넌트와 DB 단위의 기능과 동작에서 오류가 없는지 설계내역과 일치하는 지를 검사하는 것으로 개발담당자가 테스트하며 그 결과보고서를 제출하여 PM에게 승인을 얻어야 공식적인 결과물로 인정함

테스트 구분	테스트 목적	테스트 내용	결과 판정기준	담당자/시기
게임엔진의 렌더링 컴포넌트	렌더링 컴포넌트 사양(기능 및 동작)이 요구사항 만족여부 검사	요구사항의 각 항목별로 만족여부 검사	요구사항의 각 항목의 만족여부로 합격/불합격 판정	홍길동(QA팀)/개발팀의 테스트 신청할 때

9.3 그래픽 리소스 단위시험

<작성 예>

- 본 시험은 그래픽 리소스 데이터들이 요구사항과 설계내역과 일치하는 지를 검사하는 것으로 담당개발팀장이 테스트하며 그 결과보고서를 제출하여 PM에게 승인을 얻어야 공식적인 결과물로 인정함

9.4 사운드 리소스 단위시험

<작성 예>

- 본 시험은 사운드 리소스 데이터들이 요구사항과 설계내역과 일치하는 지를 검사하는 것으로 담당개발팀장이 테스트하며 그 결과보고서를 제출하여 PM에게 승인을 얻어야 공식적인 결과물로 인정함

9.5 게임소프트웨어 통합시험

<작성 예>

- 본 시험은 통합된 게임소프트웨어가 요구사항과 설계내역과 일치하는 지를 검사하는 것으로 담당개발팀장과 테스트팀과 프로젝트관리자가 함께 테스트한다.

.테스트 방법은 각 테스트 항목을 도출하고 항목별 테스트방법과 결과 판정법을 결정하여 추진함

- 테스트 수행 시기는 개발팀에서 통합시험을 요청하는 시기임

9.6 게임소프트웨어 품질시험

<작성 요령>

-본 시험은 게임소프트웨어가 설정된 품질을 만족하는지를 검사하는 시험으로 관련 품질항목, 품질지수, 시험방법, 결과판정법, 담당자, 그리고 수행시기에 관하여 표로 만들어 제시함

9.7 게임시스템 통합시험

9.8 게임시스템 품질시험

9.9 게임밸런싱 품질시험

10. 의사소통 계획

10.1 프로젝트 이해관계자들과의 의사소통

<작성 요령>

-이해관계자들이 누구인지 프로젝트를 중심으로 관계도를 그리고 각 관계자들의 정의와 그들이 프로젝트(PM 포함)에 대한 기대를 작성함

10.2 조직 간의 의사소통 방식

<작성요령>

조직간에 공식적인 의사소통 가능한 채널을 관계도를 통해 작성하고 조직들간에 어떤 의사소통이 가능한지를 주기적/비주기적 의사소통들의 대표적인 예들을 들어 설명함

10.3 의사소통 활동 내역

<작성요령> 개인과 팀의 의사소통 활동에 대한 내역을 표로 작성함

정보제공자	의사소통 활동명	정보내용	정보수신처	전달방법	전달시기	비고
팀원	주간업무보고	주간업무내용	팀장/PM	이메일	매주 금요일
팀장
프로그램팀

11. 개발 방법 및 도구

11.1 설계 및 분석 기법

<작성 예>

-시스템과 컴포넌트 설계는 객체지향기반 설계를 하며 원활한 의사소통을 위하여 설계내용과 분석내용은 UML로 표기함을 원칙으로 한다.

11.2 개발 도구

<작성 예>

-DB 개발도구: MYSQL

11.3 프로그래밍 언어

<작성 예>

-게임프로그래밍 언어: MS Visual Studio 6.0 C++

-웹프로그래밍 언어: ASP, Java

11.4 관리 도구

<작성 예>

- 프로젝트 관리도구:  한글 MS Project 2003, 한글 MS Excel 2003