DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일...

22
MJ-CE-SE TMPL-0001 Ver. 2 2022-07-06 Death Zone Request for Proposal Copyright © 2012 Team Hope

Transcript of DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일...

Page 1: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

MJ-CE-SE TMPL-0001 Ver. 2

2023-05-17

Death Zone Request for Proposal

Copyright © 2012 Team Hope

Page 2: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

MJ-CE-SE TMPL-0001Ver. 2

2023-05-17

Copyright noticeThis document is Copyright © Team Hope – all rights reserved.

작성자 : 오세도, 이영태, 송재혁, 박정구, 김휘민

상 태 : Public

개 요 : Death Zone 프로젝트의 제안내용 기술

Team Hope 2

Page 3: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

Version Control

VERSION 날짜 내용 작성자 승인자1 2012.09.08 Initial revision 송재혁2 2012.09.09 Review에 의한 수정 사항 반영 송재혁 이강선

Team Hope 3

Page 4: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

목 차

1. 개요...............................................................................................................................................7

1.1. 목적.......................................................................................................................................71.2. 범위.......................................................................................................................................71.3. 정의 및 약어.........................................................................................................................71.4. 참고 문헌..............................................................................................................................81.5. 문서 구조..............................................................................................................................8

2. PROJECT 개요............................................................................................................................9

2.1. PROJECT 목적.........................................................................................................................92.2. PROJECT 범위.........................................................................................................................9

2.2.1. 지원 기능......................................................................................................................92.2.2. 주요 활동 사항...........................................................................................................102.2.3. 일 정............................................................................................................................10

2.3. 가정 및 제한 사항..............................................................................................................102.4. 결과물.................................................................................................................................10

3. PROJECT 조직..........................................................................................................................11

3.1. 외부 조직............................................................................................................................113.2. 내부 조직............................................................................................................................11

4. SOFTWARE 개발 계획.............................................................................................................12

4.1. PROCESS MODEL..................................................................................................................124.2. 일정/인력/자원 할당..........................................................................................................124.3. METHODS, TOOLS, TECHNIQUES..........................................................................................12

5. PROJECT 관리 계획.................................................................................................................15

5.1. CONTROL PLAN....................................................................................................................16

6. 교육 계획....................................................................................................................................17

7. 문서화 계획................................................................................................................................18

7.1. PHASE DEPENDENT DOCUMENT...........................................................................................187.2. Phase Independent Document..............................................................................................18

Team Hope 4

Page 5: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

그림 목차

그림 1. 문서 구조도.............................................................................................................................8그림 2. 게임 플레이화면.....................................................................................................................9그림 3. 외부 조직도...........................................................................................................................11그림 4. 내부 조직도...........................................................................................................................11

Team Hope 5

Page 6: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

표 목차

표 1. 결과물........................................................................................................................................10표 2. 외부 조직의 책임과 역할.........................................................................................................11표 3. 내부 조직의 책임과 역할.........................................................................................................11표 4. 일정/인력/자원 할당표.............................................................................................................12표 5. METHODS, TOOLS, TECHNIQUES 목록........................................................................................12표 6. 개발 계획표...............................................................................................................................13표 7. RISK MANAGEMENT PROCEDURE 일정표 예.............................................................................15표 8. RISK IDENTIFICATION/ANALYSIS 참여 대상자 예.....................................................................15표 9. CONTROL PLAN...........................................................................................................................16표 10. 교육 계획표.............................................................................................................................17표 11. PHASE DEPENDENT DOCUMENT 문서화 계획표......................................................................18표 12. Phase Independent Document 문서화 계획표.........................................................................18

Team Hope 6

Page 7: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

1. 개요

1.1. 목적본 문서는『Death Zone』개발 과정의 근간이 되는 문서로 Project Initiation phase에서 최초 작성되어 각 Phase 마지막에 변경 혹은 추가된 계획이 반영된다.

1.2. 범위본문서는 안드로이드 기기용 네트워크 전략 게임『DeathZone』프로젝트의 개발 및 관리 계획을 기술한다.

1.3. 정의 및 약어소셜 네트워크 게임(소셜 게임) - 소셜 네트워크 서비스 플랫폼을 기반으로, 사용자의 온라인 인맥과 유대관계를 증진하기 위해 사용자참여 및 관계맺기를 극대화한 새로운 형태의 사회적 인맥 기반의 게임이다. 게임 자체가 목적인 일반 온라인 게임과는 달리, 손쉬운 인터페이스를 통해 모든 연령층의 사용자를 대상으로 해당 SNS네트워크 내 사용자 간 친밀감과 동질성을 증대시키는 것이 특징이다

GPS(Global Positioning System) - 현재 완전하게 운용되고 있는 유일한 범지구위성항법 시스템이다. 미국 국방부에서 개발되었으며 공식 명칭은 NAVSTAR GPS(NAVSTAR는 약자가 아님 그러나 종종 NAVigation System with Timing And Ranging 이라고 하기도 한다. )이다. 무기 유도, 항법, 측량, 지도제작, 측지, 시각동기 등의 군용 및 민간용 목적으로 사용되고 있다.

RTS(Real Time Strategy, RTS) - 턴제 전략 게임과 구분되는 전략 게임의 한 장르이다. “실시간”이라는 용어는 더 넓은 장르이며 컴퓨터·비디오 게임 내외로 더 깊은 역사를 지니고 있는 전략 워게임들과 구분하기 위해서 사용되었다. 실시간 전략 게임의 핵심 요소로는 실시간 컨트롤로 이루어지는 전투에 기반한 액션이 있다. 유닛 컨트롤 외에 실시간 전략 게임의 다른 게임플레이 방식은 자원 채취와 기지 건설 및 기술 개발 등의 요소로 이루어진다. 대체로 플레이어는 전장을 위에서 아래로 내려다보는 시점으로 플레이하게 되나, 최근의 3D RTS들은 시점을 자유롭게 변경할 수 있기도 하다. 또한, 게임의 사용자 인터페이스는 컴퓨터 데스크톱 환경의 인터페이스와 대체로 비슷하다. 플레이어는 마우스 클릭과 드래그로 유닛 컨트롤을 비롯한 대부분의 작업을 할 수 있다. RTS 게임에서 플레이하는 각 플레이어들은 각자 독립적으로 게임을 컨트롤할 수 있으며 따라서 다른 플레이어가 자기 차례를 끝낼 때까지 기다릴 필요가 없다. 턴제 전략 게임에서와 비교되는 이런 점은 멀티플레이 게임에 유리한 특성으로 작용한다.

베타테스트 - 회사가 제품을 론칭하기 이전, 고객의 만족도 및 사업의 안정성을 평가하기 위하여 미리 사용자들에게 제품을 평가받기 위하여 서비스를 공개하는 방법이다. 정식으로 서비스를 론칭했을때에 비해 사업성이 없다고 판단될 때 곧바로 그에 대한 대처를 할 수 있다.

좀비 - 살아있는 시체를 말한다. 서인도 제도 원주민의 미신과 부두교의 제사장들이 마약을 투여해 되살려낸 시체에서 유래한 단어라 한다. 영화에서는 1932년 벨라루고시의 <화이트좀비>가 좀비를 다룬 첫 작품이며 조지로메로의 <살아있는 시체들의 밤> 을 기점으로 해서 <좀비오><바탈리언>과 같은 수많은 아류작들이 탄생했다.

Team Hope 7

Page 8: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

사용자(USER) - 컴퓨터의 사용자. 이 관점에서 보면 시스템 설계자(system designer), 프로그래머(programmer), 조작원(operator), 기계실의 관리자도 모두 사용자의 범주에 들어간다. 최종 사용자, 단말 사용자(end-user)란 전임 프로그래머나 오퍼레이터 이외의 현업(現業) 부문에 컴퓨터를 사용하여 자신의 업무를 처리하는 사람, 그와 같은 기업 내의 부문을 말한다.

아바타(avatar) - 컴퓨터 사용자 스스로를 묘사한 것으로 컴퓨터 게임에서는 2/3차원 모형 형태로 인터넷 포럼과 기타 커뮤니티에서는 2차원 아이콘 (그림)으로, 머드 게임과 같은 초기 시스템에서는 문자열 구조로 쓰인다. 다시 말해, 사용자가 스스로의 모습을 부여한 물체라고 할 수 있다.

1.4. 참고 문헌위키피디아 '소셜네트워크게임' 항목-http://ko.wikipedia.org/wiki/%EC%86%8C%EC%85%9C%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EA%B2%8C%EC%9E%84위키피디아 'GPS' 항목- http://ko.wikipedia.org/wiki/GPS위키피디아 '실시간 전략 게임' 항목-http://ko.wikipedia.org/wiki/%EC%8B%A4%EC%8B%9C%EA%B0%84_%EC%A0%84%EB%9E%B5_%EA%B2%8C%EC%9E%84위키피디아 '베타테스트' 항목-http://ko.wikipedia.org/wiki/%EB%B2%A0%ED%83%80%ED%85%8C%EC%8A%A4%ED%8A%B8네이버 지식백과 '좀비' 항목-http://terms.naver.com/entry.nhn?docId=74191&mobile&categoryId=342네이버 지식백과 '사용자' 항목-http://terms.naver.com/entry.nhn?docId=840721&mobile&categoryId=209위키피디아 '아바타' 항목-http://ko.wikipedia.org/wiki/%EC%95%84%EB%B0%94%ED%83%80

1.5. 문서 구조

그림 1. 문서 구조도

Team Hope 8

Page 9: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

2. Project 개요

2.1. Project 목적최근 네트워크 인프라와 휴대기기의 발전으로 인하여 급속도로 활성화 되고 있는 소셜 게임 시장에 게임소재로 자주 사용되는 좀비를 접목하여, 네트워크 대전기능을 지원하는 안드로이드용 전략 시뮬레이션 게임을 제작한다기본적인 소셜게임에 추가적으로 GPS를 이용한 거리측정 개념을 추가하여, 실제 가까운 거리에 위치한 사용자들간의 온라인 플레이를 지원함과 동시에 서로의 친목을 도모하는 방향으로 게임이 진행된다.

2.2. Project 범위

2.2.1. 지원 기능게임 시스템

그림 2. 게임 플레이화면

기본 전투는 AI를 이용한 자동진행으로 진행되며, 터치패널 또는 가속도센서를 이용해 표적을 선택하거나 각 유닛에게 명령을 전달하여 게임의 전략성을 더한다.사용자의 기호에 맞는 전략 및 팀원 편성을 통한 스테이지 공략식 게임 플레이를 지원하고, 네트워크 활성화 시 대전상대와 데이터 통신을 통한 네트워크 플레이를 제공한다싱글플레이플레이어는 아바타와 5인내외의 용병으로 구성된 용병단을 이용하여 스테이지를 진행 하며, 조우한 적을 포획한 후 치료하여 아군으로 사용하거나, 연구재료로 활용하여 획득하는 연구 포인트로 아군을 강화하는 방향으로 용병단을 성장시킨다 스테이지를 진행할수록 다양한 패턴을 가진 적이 등장하며, 난이도에 따라 보상을 차등지급 하여 플레이어에게 도전의식을 부여한다네트워크 플레이네트워크 플레이의 경우 다수의 사용자가 각자의 아바타들로 팀을 구성하여 혼자서는 이기기 힘든 강한 적을 상대하는 것을 주 컨텐츠로, 승리시 네트워크플레이 전용 포인트를 제공하여 싱글플레이와는 다른 도전 요소를 추가한다

Team Hope 9

Page 10: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

연구 시스템플레이 중 포획한 적을 연구하여 해당 적에 대한 이해도를 높일 수 있으며, 이는 게임플레이에 반영되어 피해 증가 등의 보너스를 얻게 되고, 적들의 장비를 사용할 수 있게 되는 등의 혜택을 주어 사용자가 좀 더 전략적으로 게임에 몰입할 수 있는 요소로 작용한다

2.2.2. 주요 활동 사항9월 중순까지 각 팀원이 현재까지 완성된 프로토타입의 분석을 마친 후, 개발방향에 맞추어 분산개발을 실시한다중간발표시점까지 싱글플레이를 완성 한 후 마켓에 등록하여 실제 사용자의 피드백을 받고, 이를 바탕으로 싱글플레이 컨텐츠 보강 및 멀티플레이 시스템 구현에 참고한다네트워크 플레이 구현 시 베타테스트를 통하여 서버의 부하 정도를 확인한다

2.2.3. 일 정 2012.09.11 ~ 2012.10.15 싱글플레이 컨텐츠 개발2012.10.16 ~ 2012.11.20 멀티플레이 컨텐츠 개발

2.3. 가정 및 제한 사항플랫폼적 제한사한개발이 용이하고 사용자가 많고, 배포가 쉬운 안드로이드 플랫폼을 대상으로 제작하되, 범용성을 고려하여 버전은 안드로이드2.2 버전을 기반으로한 게임 환경을 조성한다.네트워크상의 제한사항실시간 네트워크 플레이의 경우 상당한 데이터 전송을 필요로 하게 되므로, 게임진행은 최초 팀 구성 시 받은 데이터를 적극 활용하여 게임을 진행하는 동안 동기화해야 하는 데이터의 양을 최소한으로 줄인다개인정보 이용GPS, 핸드폰 번호 등의 개인정보는 사용자의 동의 하에 사용한다

2.4. 결과물

표 1. 결과물

종류 전달 대상 전달 날짜 전달 방법프로젝트 제안서 명지대학교 2012/09/15 직접전달개념설계 보고서 명지대학교 2012/09/29 직접전달상세설계 보고서 명지대학교 2012/10/13 직접전달시험계획 보고서 명지대학교 2012/10/27 직접전달제작 보고서 명지대학교 2012/11/10 직접전달싱글플레이버전 명지대학교 2012/11/01 샘플파일시범운영보고서 명지대학교 2012/11/24 직접전달프로그램 수정안 명지대학교 2012/12/02 직접전달최종 수정안 명지대학교 2012/12/04 직접전달베타테스트 버전 명지대학교 2012/12/08 샘플파일(시연)시스템테스트결과 명지대학교 2012/12/10 직접전달사용자메뉴얼 명지대학교 2012/12/12 직접전달유지보수계획 명지대학교 2012/12/12 직접전달

Team Hope 10

Page 11: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

3. Project 조직

3.1. 외부 조직

그림 3. 외부 조직도

표 2. 외부 조직의 책임과 역할

조직 책임 및 역할 책임자명지대학교 캡스톤 프로젝트 총괄 담당 김상균인공지능 연구실 장비 및 제공 조세형소프트웨어공학 연구실 자문 담당 이강선

3.2. 내부 조직.

그림 4. 내부 조직도

표 3. 내부 조직의 책임과 역할

조직 책임 및 역할 책임자자문위원 System testing 이강선A 팀 네트워크 서버 구축 및 대전 시스템 개발 박정구B 팀 싱글플레이 컨텐츠 개발 및 밸런스 조절 김휘민C 팀 그래픽 디자인 및 애니메이션 담당 이영태

Team Hope 11

Page 12: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

4. Software 개발 계획

4.1. Process Model네트워크 게임의 경우 사용자의 사용환경에 따라 요구사항이 변할 수 있으므로 지속적인 피드백이 필요하다. 그러므로 Incremental Model을 채택하여 개발하되, 각각의 세부 기능은 완성도를 높이기 위해 Waterfall Model을 채택하여 개발한다.

4.2. 일정/인력/자원 할당

표 4. 일정/인력/자원 할당표

구 분 내 용

일 정본 프로젝트는 Incremental Model을 따르고 있어 요구사항에 변화에 민첩하게 대응해야 하고, 시간적 제약을 고려하여야 하기 때문에 각 task의 주기를 짧게 잡는다.

인 력

네트워크컨텐츠팀, 싱글컨텐츠팀, 그래픽디자인팀으로 나누어 초기 개발단계에서는 각 팀당 한명 으로 구성한 후, 유휴 인원을 적극 활용하여 Task변경에 따라 유동적으로 인원을 추가 투입하여 프로젝트의 개발 속도를 일정하게 유지시킨다.

자 원장비 필요시 학교측에 요청하여 장비를 충당하고, 프로젝트를 텀블벅에 게시하여 소비자의 후원을 받는다

4.3. Methods, Tools, Techniques

표 5. Methods, Tools, Techniques 목록

구 분 내 용Star UML UML 기반의 개발방법론 설계 및 기술

Winscp scp를 쉽게 사용할 수 있도록 지원하는 툴

Eclipse 안드로이드 및 java 개발 툴

Oracle sql 데이터베이스 구축

Adobe Photoshop 그래픽 작업툴

Adobe Flash 애니메이션 작업툴

MS Office 문서작성 및 일정관리

Fedora 16 Linux 운영체제

XML/JSP/JSON 모바일페이지 구성을 위한 언어

Notepad++ 웹 개발을 위한 툴

Sql Developer Sql개발을 돕는 툴

Team Hope 12

Page 13: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

표 6. 개발 계획표

PI: PROJECT INITIATION 2012/09/03 ~ 2012/09/15

Task Output 일정 조직/담당자 Methods, Tools, Techniques

팀 구성 팀 조직도 2012/09/05~2012/09/08 PM/송재혁 MS Office

Star UML

제안서 작성 제안서 2012/09/08~2012/09/15 PM/송재혁 MS Office

필요지식 습득 - 2012/09/15~2012/09/20 각 팀원 -

SS: SOFTWARE SPECIFICATION 2012/09/15 ~ 2012/09/20

Task Output 일정 조직/담당자 Methods, Tools, Techniques

요구사항 분석 요구사항 분석서 2012/09/15~2012/09/15 PM/송재혁 MS Office

부서별 요구사항 구체화

부서별요구사항 분석서

2012/09/16~2012/09/16 전 팀원 MS Office

요구사항 명세화 요구사항 명세서 2012/09/17~2012/09/19 PM/송재혁 MS Office

Star UML

요구사항 검증 - 2012/09/19~2012/09/20

PM/송재혁자문/이강선

-

DE: DESIGN 2012/09/21 ~ 2012/10/13

Task Output 일정 조직/담당자 Methods, Tools, Techniques

아키텍쳐 설계 - 2012/09/21~2012/09/23 PM/송재혁 MS Office

추상 명세화 - 2012/09/24~2012/09/27 PM/송재혁 Ms Office

Star UML

인터페이스 설계 개념설계 보고서 2012/09/27~2012/09/29 PM/송재혁 MS Office

Star UML

컴포넌트 설계 - 2012/10/01~2012/10/03 PM/송재혁 Ms Office

Star UML

데이터구조 설계 - 2012/10/04~2012/10/07 PM/송재혁 MS Office

Star UML

알고리즘 설계 - 2012/10/08~2012/10/11 PM/송재혁 MS Office

Star UML

시스템 설계 상세설계 보고서 2012/10/12~2012/10/13 PM/송재혁 MS Office

Star UML

IM: IMPLEMENTATION 2012/09/27 ~ 2012/12/04

Task Output 일정 조직/담당자 Methods, Tools, Techniques

싱글플레이 컨텐츠 개발

- 2012/09/27~2012/10/20 B팀/김휘민 Eclipse

Visual Studio네트워크 서버

개발- 2012/09/27~

2012/10/20 A팀/송재혁 Oracle SQLJSP, JSON

애니메이션 디자인

- 2012/09/27~2012/10/20 C팀/이영태 Adobe

PhotoshopTeam Hope 13

Page 14: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

시스템 통합 - 2012/10/20~2012/10/25 PM/송재혁 -

싱글플레이 완성 싱글플레이버전 2012/10/26~2012/10/30 PM/송재혁 -

싱글플레이 검토 - 2012/10/31~2012/11/05 자문/이강선 -

밸런스 수정 - 2012/11/06~2012/11/30 B팀/김휘민 Eclipse

Visual Studio네트워크 서버

적용 / 개선- 2012/11/06~

2012/11/30 A팀/박정구 Oracle SQLJSP, JSON

그래픽 개선 - 2012/11/06~2012/11/30 C팀/이영태 Adobe

Photoshop

멀티플레이 완성 베타테스트버전 2012/12/01~2012/12/01 PM/송재혁 -

멀티플레이 검토 - 2012/12/01~2012/12/03

자문/이강선명지대학교

-

VA: VALIDATION 2012/12/04 ~ 2012/12/08

Task Output 일정 조직/담당자 Methods, Tools, Techniques

테스트 계획 테스트 계획서 2012/12/04~2012/12/04 PM/송재혁 MS Office

테스트파일 구축 - 2012/12/04~2012/12/05 전 팀원

EclipseJSP

Oracle SQL

단위 테스트 시범운영 보고서 2012/12/05~2012/12/06 PM/송재혁 MS Office

부서별수정계획 수립

프로그램 수정안 2012/12/06~2012/12/08 전 팀원 MS Office

수정계획 검토 - 2012/12/09 자문 이강선 -

수정계획 작성 최종 수정안 2012/12/09~2012/12/10 PM/송재혁 MS Office

EV: EVOLUTION 2012/12/10 ~ 2012/12/12

Task Output 일정 조직/담당자 Methods, Tools, Techniques

최종 수정 및 보완

프로그램 완성본 2012/12/10~2012/12/11

PM/오세도자문/이강선

Google App, Oracle SQL

Eclipse

메뉴얼 작성 사용자메뉴얼 2012/12/11~2012/12/11

PM/오세도자문/이강선

MS Office

유지보수 계획 수립

유지보수 계획서 2012/12/11~2012/12/12 PM/오세도 MS Office

시스템 교육 2012/12/12~2012/12/12 PM/송재혁 Ms Office

Team Hope 14

Page 15: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

5. Project 관리 계획표 7. Risk Management Procedure 일정표 예

Item Risk Identification Risk Analysis Risk Planning Risk Monitoring일정 Plan document가

check-in 된 후부터 3일 동안

Plan document가 check-in 되고 3일 후

Risk Analysis가 수행된 후부터 3일 동안

Risk mitigation plan과 contingency plan이 세워지고 risk가 사라질 때까지 2주일 단위로 risk status와 action을 기록한다

기타 Risk의 priority는 high, moderate, low priority 중 제일 많은 참여자가 선택한 priority로 결정된다.

Priority가 moderate 이상인 risk에만 mitigation plan과 contingency plan을 세운다

표 8. Risk Identification/Analysis 참여 대상자 예

Phase Plan DocumentRisk Identification/Risk Analysis

주관자 참여자PI 제안서, 관리계획서,

실행계획서PM/송재혁

전 팀원 자문/이강선

SS요구사항 분석서, 요구사향

명세서,부서별 요구사항 분석서

PM/송재혁전 팀원

자문/이강선

DE 개념설계보고서 PM/송재혁 전 팀원상세설계보고서 PM/송재혁 전 팀원

VA테스트 계획서 PM/송재혁

전 팀원 자문/이강선

2차 테스트 계획서 PM/송재혁전 팀원

자문/이강선

프로그램 수정안` PM/송재혁 전 팀원

최종 수정안 PM/송재혁전 팀원

자문/이강선EV

사용자 매뉴얼 PM/송재혁전 팀원

자문/이강선유지보수 계획서 PM/송재혁 자문/이강선

5.1. Control Plan

표 9. Control Plan

대상 모니터링 관점 Risk 해결방안Team Hope 15

Page 16: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

범위관리고객요구사항이 안정적인가? 안정적으로 요구할 수 있도록 폼을 제공

요구사항 변경은 적절히 통제되고 있는가?

변경에 대한 수용과 변경의 대한 통제를 한다

일정관리수행 활동은 계획된 일정대로 진행되는가?

계획표에 따른 관리와 산출물과 보고서를 통한 관리

원가관리작업의 수행에 소요된 원가가 계획된 예산에 범위내인가?

사전 조사를 통한 예산의 산출과 정해진 물품에만 사용함

품질관리

고객이 원하는 기능이 정확하게 설계되어 구현되는가?

산출물과 고객 요구사항간의 비교를 통해 관리

품질보증 활동은 효과적으로 수행되는가?

품질보증팀에 대한 관리와 여러가지 기준의 제시

인력관리

작업은 공정하게 배분되고 개인이 Commit 하는가?

팀장 주최의 회의로 모든 팀원의 의견반영

팀원의 사기는 적절한가? 팀원간의 미팅을 통해 사기를 높인다

책임과 역할이 모호하거나 중복되는 부분은 없는가?

미팅 및 회의를 통한 의견수렴

각 개인이 업무 수행에 필요한 기술은 있는가?

경력 및 교육사항에 대한 조사 및 부족할 경우 별도의 교육실시

의사소통관리

프로젝트 이해 당사자들이 필요한 정보를 필요한 시점에 받아보고 있는가?

산출물과 리포트에 대한 정확한 관리

프로젝트 진행 실적이 정확하게 파악되는가?

산출물과 리포트에 대한 정확한 관리

위험관리식별된 위험에 대한 통제가 이루어 지고 있는가?

위험에 대한 확실한 분석과 적용결과 재분석

조달관리아웃소싱으로 진행하는 부분에 대한 통제가 적절하게 이루어지고 있는가?

외부에 대한 결과물을 받고 우리의 프로젝트와 같이 분석

Team Hope 16

Page 17: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

6. 교육 계획교육계획은 기본 프로토타입 구조 교육, 추가 컨텐츠, 매칭 시스템에 중점을 맞추어 교육하여 비상시 유연성 있는 인력 투입이 가능하도록 유도한다교육 장소 및 시간에 대한 자세한 사항은 교육담당자가 교육 1주일 전에 알린다.

표 10. 교육 계획표

교육 과정 교육 시간 교육 형태 교육 일자 교육 담당자 참석자데스존 프로젝트

1일 ․해당 프로젝트의 전반적인 구성에 대한 교육

․12.9.10 ․이영태 ․ALL

프로토타입구조

5일 ․프로토타입 소스코드 공개 및 작동 구조 설명

․12.9.10~12.9.12

․이영태 ․ALL

싱글컨텐츠개발방향

3일 ․싱글플레이 컨텐츠 확장 방안과 시스템 보완방향에 대한 교육

․12.9.13~12.9.21

․PM․김휘민

․A팀

멀티컨텐츠개발방향

2일 ․컴박스 코리아의 전자 칠판 이해를 위한 교육네트워크 컨텐츠의 서버 유지에 대한 중요성 교육

․12.4.13 ~12.4.21

B팀

Android application 교육

1주 ․android에 대한 기초지식 습득․프로젝트 특징에 적합한 android

개발의 중요성 교육- PC로 구축한 네트워크 서버와

안드로이드 플랫폼간의 연동 체계에 대한 교육

․12.9.13 ~12.9.21

․PM․이영태

-ALL

시스템 운영 2주(주 2회)

․시스템의 운영을 위한 교육 ~12.12.04

․PM ․운영자

시스템 사용 2주(주 2회)

․사용자의 본격적인 사용을 위한 사용법에 대한 교육

~12.12.04

․PM ․User

Team Hope 17

Page 18: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

7. 문서화 계획

7.1. Phase Dependent Document

표 11. Phase Dependent Document 문서화 계획표

PHASE 문서 작성 도구

문서 개수

책임자/작성자 작성기간

PI 제안서 MS Office 1 PM/송재혁 2012/09/08~2012/09/15

DE 개념설계 보고서 MS Office 1 PM/송재혁 2012/09/21~2012/09/29

상세설계 보고서 MS OfficeStar UML 1~N 전 팀원 2012/09/30~

2012/10/13VA 프로그램 수정안 MS Office 1~N 전 팀원 2012/12/06~

2012/12/08

최종 프로그램 수정안 MS Office 1~N PM/송재혁 2012/12/09~2012/12/10

EV 사용자 매뉴얼 MS Office 1~N PM/송재혁 2012/12/11~2012/12/11

유지보수 계획서 MS Office 1~N PM/송재혁 2012/12/11~2012/12/12

결과보고서 MS Office 1 PM/송재혁 2012/12/12~2012/12/13

7.2. Phase Independent Document

표 12. Phase Independent Document 문서화 계획표

문서 작성 도구 작성자 작성 시기Problem Report MS Office PM/송재혁 2012/09/30~

2012/10/13Risk Analysis Record MS Office PM/송재혁 2012/10/13~

2012/10/15Risk Management Report MS Office PM/송재혁 2012/10/15~

2012/10/20Review Report

Management Review ReportTechnical Review Report

Walkthrough ReportInspection Report

MS Office

전 팀원2012/10/20~

2012/10/22

Audit Report MS Office PM/송재혁 매 분기시Test Incident Report MS Office 전 팀원 2012/11/05~

2012/11/20

Team Hope 18

Page 19: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

부 록

A. 부록 1B. 부록 2

Team Hope 19

Page 20: DeathZone RFP - mju.ac.krants.mju.ac.kr/2013Fall/capstone/sample4.doc · Web view구조 5일 ․프로토타입 소스코드 공개 및 작동 구조 설명 ․12.9.10~12.9.12 ․이영태

DeathZone RFP MJU TM-001

색 인

오류! 색인 항목을 찾을 수 없습니다.

Team Hope 20