프로젝트 계획서

기본 사항
교과목명	객체지향프로그래밍II	담당교수	이종민
프로젝트 명	호텔 관리 시스템 (HMS)
분반	1분반	조 번호	1
조 구성원 (학번/성명)
개발 환경	(필요시 수정 가능) * 운영체제: Ubuntu 14.04.3 LTS / 윈도우즈 10 / 기타 ( ) * IDE: NetBeans IDE / 기타 ( )

제출일: 2000년 00월 00일

이 프로젝트 계획서는 동의대학교 컴퓨터소프트웨어공학과 객체지향프로그래밍II 교과목에서 프로젝트 계획을 기술하기 위하여 사용되는 것으로, ISO/IEC/IEEE 29148:2011 요구공학 국제 표준과 IEEE Std 830-1998 SW 요구사항 명세서 추천 규준을 일부 인용합니다.

1. 서론 (Introduction)

1.1 비전 (Vision)

프로젝트 계획서에서 제안하는 프로젝트의 가치와 목적을 기술한다. 시스템이나 사업의 장기간, 고수준 관점을 기술하는 문장으로 나타낼 수 있다.

예1) Gary의 게임 시스템 프레임워크(GSF) 사례:

GSF는 게임 설계에 필요한 반복적 코딩 작업을 없애고, 개별 게임을 쉽게 만드는데 필요한 게임 관리 도구를 제공한다.

예2) HMS

현대 호텔 산업은 고객 경험의 극대화와 운영 효율성 향상을 동시에 요구합니다. 본 호텔 관리 시스템(HMS)은 프론트 데스크, 예약, 객실 관리, 고객 서비스, 회계 및 보고 기능을 통합하여 호텔 운영의 디지털 전환을 지원합니다.

1.2 범위 (Scope)

1.2.1 유스케이스 다이어그램

시스템 범위: use case diagram을 그린 후 각 유스케이스에 대한 간단한 설명을 한다. 이해관계자가 모두 액터로 표현되어야 하며, 시스템 기능(system functionality)을 유스케이스로 표현해야 한다.

참고자료: https://seps8.deu.ac.kr/redmine/boards/44/topics/1036

예) 웹메일 시스템의 유스케이스 다이어그램

* 웹메일 시스템 유스케이스 다이어그램의 PlantUML 코드

@startuml

' top to bottom direction

left to right direction

actor User

actor Administrator

actor MailUser

actor MailServer

User <|-d- Administrator

User <|-d--- MailUser

package "WebMail System" {

together {

usecase Login

usecase "Administrate Users" as admin

usecase "Add Users" as addUser

usecase "Delete Users" as delUser

usecase "Read Mail" as read

usecase "Write Mail" as write

}

}

User -r-> Login

Login ---> MailServer

Administrator -r-> admin

addUser ..> admin : <<extend>>

delUser ..> admin : <<extend>>

admin -r-> MailServer

MailUser -r--> read

MailUser -r--> write

read --r--> MailServer

write --r--> MailServer

@enduml

1.2.2 SW 제품의 특징(Feature, 또는 기능)

개발하려는 SW 제품의 주요 특징(feature)을 나열하고 간단하게 설명한다.

예) 일반적인 HMS의 제품 특징  (수정 필요)

시스템 기능	설명
예약 관리	온라인 및 오프라인 예약 처리, 예약 일정 확인, 예약 변경 및 취소 기능 제공
체크인/체크아웃	고객 체크인/체크아웃 프로세스 자동화, 디지털 서명 및 신원 확인 지원
객실 관리	객실 상태 추적(청소, 점검, 사용 가능 여부), 객실 배정 최적화
고객 정보 관리	고객 프로필 저장, 선호도 및 방문 이력 관리, VIP 고객 관리 기능 포함
결제 및 회계 처리	다양한 결제 수단 지원, 자동 청구서 생성, 세금 및 할인 적용
보고 및 분석	실시간 운영 보고서, 수익 분석, 고객 만족도 통계 제공
다국어 및 다통화 지원	글로벌 고객을 위한 언어 및 통화 설정 기능
보안 및 접근 제어	사용자 역할 기반 접근 제어, 데이터 암호화 및 백업 기능
API 및 외부 연동	OTA(Online Travel Agency), POS 시스템, CRM 등과의 연동 지원
모바일 접근성	스마트폰 및 태블릿을 통한 기능 접근 및 알림 기능

1.3 용어 정의 (Definitions, acronyms and abbreviations)

프로젝트 계획서에서 사용하는 중요한 용어의 의미를 정의한다.

예)

HMS: 호텔 관리 시스템(Hotel Management System)

고객: HMS를 이용하여 호텔 예약을 하는 사용자

직원: 프론트 데스크에서 고객을 응대하는 호텔 근무자로, 온라인/오프라인 예약을 접수한다.

IT 관리자: 고객 정보, 호텔 예약 정보 등을 관리하는 호텔 근무자

1.4 참고 문헌 (References)

프로젝트 계획서를 작성하면서 인용한 참고 문헌, 즉 도서, 인터넷 URL 등을 기술한다.

예) HMS 계획서 작성에 사용된 ISO/IEC/IEEE 29148 요구공학 국제 표준과 HMS SW 요구사항 명세서를 나열하였음.

[1] IEEE. (2011). ISO/IEC/IEEE 29148:2011 - Systems and software engineering — Life cycle processes — Requirements engineering. IEEE Standards Association.

[2] 페닐 데사니. (2023). Software Requirements Specification for Hotel Management System. SEPS8 프로젝트 문서. https://seps8.deu.ac.kr/redmine/boards/44/topics/1029

2. 전체 시스템 개요

2.1 제품 관점 (Product perspective)

2.1.1 SW 아키텍처

호텔 관리 시스템(이하 “시스템”으로 통칭한다)과 연결되는 외부 시스템 간 인터페이스에 대한 요구사항을 기술해야 한다. 예를 들어, 시스템에서 필요로 하는 외부 DBMS나 다른 시스템과의 인터페이스를 나열하고 필요한 데이터를 설명하면 된다.  0-수준 자료 흐름도(DFD)나 유스케아스 다이어그램으로 표시 가능. 외부 시스템 도출이 주목적임.

(주의) 호텔 관리 시스템은 사용자 화면을 보여 주는 클라이언트 프로그램과 사용자 예약 및 객실 관리 정보를 관리하는 서버 프로그램으로 나누어 구현해야 한다. 프로그램 실행 시 먼저 서버 프로그램을 실행하고 클라이언트 프로그램을 실행해야 한다. 클라이언트 프로그램을 먼저 실행하는 경우 서버 프로그램과 연결되지 않으면 프로그램 실행이 되지 않아야 한다.

예) UML 배포 다이어그램 형태로 SW 아키텍처를 표현 (그대로 사용해도 됨)

위의 배포 다이어그램은 PlantUML을 사용하여 작성한 그림임.

PlantUML URL: https://www.plantuml.com

(PlantUML 코드 참고)

@startuml

actor 고객

actor 직원

node "HMS 클라이언트" as Client

node "HMS 서버" as Server {

[통신 인터페이스]

[관리 프로그램]

[데이터베이스]

}

고객 -> Client

직원 -> Client

관리자 -> Client

Client -- [통신 인터페이스] : JSON or YAML 형태의 요청과 응답

[통신 인터페이스] -- [관리 프로그램]

[관리 프로그램] -- [데이터베이스]

note "Java Swing으로 구현" as note1

Client -right- note1

note "파일로 구현해야 함" as note2

[데이터베이스] -r- note2

@enduml

2.1.2 사용자 인터페이스

클라이언트에서 사용자와 어떻게 인터페이스 하는지 기술한다. 시작 화면에서부터 종료 화면까지의 화면 (흐름) 설계를 통하여 개발할 프로그램이 어떻게 동작할지 알 수 있어야 한다.

화면 설계 도구 정리: https://brunch.co.kr/@cysstory/103

사용 가능한 도구: 파워포인트,  NetBeans IDE의 Swing GUI, Figma, Miro, Lucidchart, UX Pilot AI Wireframe Generator

https://netbeans.apache.org/tutorial/main/kb/docs/java/quickstart-gui/

로그인 화면

호텔 예약 화면

체크인 화면

레스토랑 및 룸서비스 예약 화면

2.1.3 통신 인터페이스

Specify the various interfaces to communications such as local network protocols.

클라이언트와 서버 간 데이터를 주고받을 때 어떤 데이터 형식을 사용하는지 기술한다. TCP 또는 UDP를 사용할 때 응용 계층 프로토콜의 형식을 상세하게 기술한다.

3. 상세 요구사항 (Specific Requirements)

3.1 기능 요구사항 목록

QA.01 문서의 “기능요구사항” 쉬트에 있는 기능 요구사항 목록을 나열한다. 노란색 배경으로 보이는 기능 요구사항(추정치(일) = 0)은 시스템 주요 기능이며, 아래의 기능 요구사항은 해당 시스템 주요 기능을 구성하는 세부 기능 요구사항을 의미한다. 실제로 개발하는 대상은 세부 기능 요구사항임에 유의한다. 3.2절에서는 목록에 있는 기능 요구사항을 사용자 스토리 형태로 간략하게 설명한다.

기능 요구사항 작성: https://compnet.deu.ac.kr/homepage2/bbs.html 공지사항 1125번 (EARS 요구사항 작성 방법) 참고

ID	기능 요구사항	추정치(일)	우선순위
SFR-100	시스템 로그인	0	중
SFR-101	사용자 정보를 폼 입력받는다.	2	중
SFR-102	사용자 인증을 한다.	3	상
SFR-103	관리자 또는 일반 메일 사용자에 맞는 화면을 보여준다.	2	중
SFR-104	로그인 실패 시 로그인 실패 화면을 보여준다.	1	하
SFR-200	사용자 관리	0	중
SFR-201	사용자 추가 또는 삭제를 선택할 수 있다.	2	하
SFR-202	사용자 추가를 위한 정보를 입력한다.	2	하
SFR-203	메일 서버에 연결하여 사용자를 추가한다.	5	상
SFR-204	사용자 추가 성공 또는 실패를 알린다.	1	하
SFR-205	사용자 제거를 위해 현재 사용자 목록을 보여준다.	3	중
SFR-206	제거할 사용자를 선택한다.	1	하
SFR-207	메일 서버에 연결하여 사용자를 제거한다.	3	상
SFR-208	사용자 제거 성공 또는 실패를 알린다.	1	하

3.2 시스템 기능

* 아래와 같이 파란색으로 표시된 예시를 참고하여 작성한다. 작성 후 파란색으로 표시된 부분은 삭제해야 한다.

ID	기능 요구사항	기능 설명
SFR-100	시스템 로그인	아래와 같은 형태로 작성한다. (참고 서적: Head First Software Development, 한빛미디어 (절판 – 원서 참조), 애자일 개발과 스크럼, 노니키 이쿠지로, 하라나베 겐지 지음/이명교 옮김, 한빛미디어 ~로서 (사용자 역할) ...이 필요하다. (기능) 왜냐하면 ***하기 때문이다. (기능의 가치와 목적)
SFR-101	사용자 정보를 폼 입력받는다.	시스템 사용자로서 로그인 하기 위해 사용자 정보를 입력하는 기능이 필요하다. 왜냐하면 로그인에 필요한 정보이기 때문이다.
SFR-102	사용자 인증을 한다.	시스템 사용자로서 입력한 사용자 정보가 등록된 정보와 일치하는지 확인하는 기능이 필요하다. 왜냐하면 등록된 사용자만 로그인하여 시스템 기능을 사용할 수 있기 때문이다..
SFR-103	관리자 또는 일반 메일 사용자에 맞는 화면을 보여준다.	시스템 사용자로서 관리자 또는 일반 메일 사용자 역할에 맞는 화면을 볼 수 있는 기능이 필요하다. 왜냐하면 역할에 맞는 시스템 기능을 사용할 수 있어야 하기 때문이다..
SFR-104	로그인 실패 시 로그인 실패 화면을 보여준다.	시스템 사용자로서 로그인 실패 화면을 볼 수 있는 기능이 필요하다. 왜냐하면 로그인 실패 시 실패 원인을 알 수 있어야 하기 때문이다.
SFR-200	사용자 관리	* SFR-201 ~ 208에 대한 상위 기능으로 별도 작성할 필요 없음
SFR-201	사용자 추가 또는 삭제를 선택할 수 있다.
SFR-202	사용자 추가를 위한 정보를 입력한다.
SFR-203	메일 서버에 연결하여 사용자를 추가한다.
SFR-204	사용자 추가 성공 또는 실패를 알린다.
SFR-205	사용자 제거를 위해 현재 사용자 목록을 보여준다.
SFR-206	제거할 사용자를 선택한다.
SFR-207	메일 서버에 연결하여 사용자를 제거한다.
SFR-208	사용자 제거 성공 또는 실패를 알린다.

4. 일정

프로젝트 기간을 7-8주, 9주(제외), 10-11주, 12-13주, 14주로 계산하여 진행 일정을 예상한다.

소작업 및 임계 경로 생성: https://compnet.deu.ac.kr/homepage2/bbs.html 공지사항 1025번 (CPM 임계 경로 생성 방법) 참고

소작업은 3.1 기능 요구사항 목록을 활용하면 됨.

CPM 임계 경로 생성 방법: https://youtu.be/UoK_BT72Umg?si=Iw0X-pu0pqUJVWHo

4.1 소작업 목록

QA.02 문서를 사용하여 3절에서 나열한 사용자 기능 요구사항을 소작업 목록으로 작성한다. 프로젝트 일정을 감안하여 선행작업을 적절하게 선택하여야 한다.

기준: 4h/day/person * 2days/week * 팀원 수

예) 팀원 수 4명: 4*2*4 = 32h/week --> 32시간/주 * 9주 = 288시간 = 하루 8시간 기준 36일

Activity No.는 요구사항 목록의 ID를 사용하면 됨. SFR-100의 경우 “SFR-”를 생략하고 “100”만 입력하도록 함.

Activity No.	소작업	소요기간	선행작업	담당자
A	개인 정보 관리	2	-
B	학적 변동 자료 관리	6	A
C	휴복학 및 자퇴 관리	4	A
D	교육과정 관리	2	B,C
E	유사/동일 과목 관리	4	D
F	개설 강좌 관리	3	D
G	수강과목 관리	2	E
H	시간표 관리	4	E
I	성적 관리	2	F
J	장학생 관리	1	F
K	등록금 관리	2	G,H
L	졸업사정 관리	2	I,K
M	사회봉사 관리	3	J,L

4.2 임계 경로

4.1절에서 기술한 소작업 목록을 사용하여 임계 경로를 생성하여 정해진 프로젝트 기간 내에 개발 가능한지 일정 추정을 한다. 생성된 임계 경로에 의한 프로젝트 최소 소요기간이 프로젝트 최종 발표일을 만족하여야 한다.

그림 . 프로젝트 일정 계획(예)

5. 역할 분담

프로젝트 조원의 역할을 간단하게 설명한다.