객체지향모델링 프로젝트 계획서 (O분반-O조)

기본 사항
교과목명	객체지향모델링	담당교수	이종민
프로젝트명
구성원 (학번/성명)	홍길동(학번), 전우치(학번), ...

1. 프로젝트 개요

1.1 비전

프로젝트에서 개발한 소프트웨어 시스템의 목적과 가치를 간략하게 기술한다.

1.2 이해관계자 요구사항

SW 제품에 대한 요구사항(특징 포함)을 도출하는데 여러 요구사항 도출 기법을 사용하여 관련된 이해관계자를 도출하고, 이들로부터 요구사항을 정의한다. (컴퓨팅문제수준설명 속성 6: 이해 당사자의 요구수준 및 범위)

아래에 제시된 이해관계자 요구사항을 참고하여 필요시 수정, 추가 또는 삭제 가능하다.

또한 적용 가능한 디자인 패턴을 예시하였으며, 이를 참고하여 추가 또는 삭제 가능하다.

ID	이해관계자	이해관계자 요구사항
St-001	학생, 조교, 교수	강의가 있는 건물의 강의실(또는 실습실)의 강의 현황을 일별, 주별, 월별로 알 수 있어야 한다. (Template Method Pattern: 일별, 주별, 월별 강의 현황 정렬)
St-002	교수	보강을 위해 특정 건물에 있는 강의실의 빈 강의 시간을 예약할 수 있어야 한다. 단, 예약 가능한 시간은 최대 3시간이며, 즉시 반영되어야 한다.
St-003	교수	세미나 또는 학생 지도 목적으로 강의실의 빈 강의 시간을 예약할 수 있어야 한다. 단, 예약 가능 시간은 최대 3시간이며, 사용 목적과 참석 인원을 등록할 수 있어야 한다.
St-004	교수	보강 또는 세미나 목적으로 강의실을 예약할 때 기존 예약 중 교수가 한 예약이 있으면 예약을 할 수 없다.
St-005	교수	보강 또는 세미나 목적으로 강의실을 예약할 때 모든 예약 또는 예약 대기에 대하여 취소 사실을 알려 주어야 한다. (Iterator Pattern)
St-006	학생	개인 학습 또는 조별 학습을 위해 특정 건물에 있는 강의실의 빈 강의 시간 예약을 사전 신청할 수 있어야 한다. 단, 공정한 사용을 위해 예약 시간은 최대 2시간 이하여야 하며, 사전 신청은 최소 하루 전에 이루어져야 한다. (Builder Pattern: 강의 시간 예약 정보)
St-007	학생	강의실 예약 시 예약하는 학생과 함께 같이 사용하는 학생의 수와 학번, 성명을 등록할 수 있어야 한다.
St-008	학생	강의실 예약 시 쾌적한 사용을 위해 수용 가능한 인원의 50% 까지만 예약을 허용해야 한다. (강의실의 예약 또는 예약 대기 인원이 50% 이상인 경우 강의실 예약이 불가해야 한다.) (Singleton Pattern)
St-009	조교	강의실 예약 신청을 승인 또는 거부할 수 있어야 한다. 이때 승인 여부를 예약 신청한 학생이 로그인해 있을 경우 푸쉬 형태로 알려주어야 하며, 로그인해 있지 않은 경우 추후 로그인 시 즉각적으로 알려 주어야 한다. (Observer Pattern)
St-010	조교	필요 시 한 개 또는 복수 개의 기존 강의실 예약을 취소할 수 있어야 한다. 이때 취소 원인을 등록해야 하며, 취소된 예약을 등록한 학생에게 알려 주어야 한다. (로그인 여부와 관계 없이 등록한 학생에게 알림이 도착할 수 있어야 한다.) (Itertor Pattern 가능)
St-011	조교	특정 강의실의 강의 시간을 학년도/학기 별로 관리할 수 있어야 한다.
St-012	조교	강의실 별 강의 현황과 예약 현황을 백업 및 복구할 수 있어야 한다.
St-013	개발자	강의실 예약 시스템은 Java 21 이상에 기반하여 개발되어야 한다.
St-014	개발자	강의실 예약 시스템은 Java Swing에 기반하여 개발해야 한다. 다만, 향후 웹 기반으로 변경하기 쉽도록 인터페이스가 되어 있어야 한다.
St-015	개발자	강의실 예약 관련 데이터는 파일 형태로 관리되어야 한다. 다만, 향후 DBMS로 이전하기 쉽도록 인터페이스가 되어 있어야 한다. (Singleton Pattern)
St-016	개발자	강의실 예약 시스템 동작 여부를 런타임에 확인할 수 있어야 한다.(Strategy Pattern)

1.3 시스템 범위

유스케이스 다이어그램을 사용하여 특징 목록에서 도출할 수 있는 시스템 기능과 액터를 찾아 시스템 범위를 정의한다.

예)

참고자료: https://seps8.deu.ac.kr/redmine/boards/43/topics/1033

1.4 관련 기술

이해관계자 요구사항을 분석/설계/구현하는데 필요한 관련 기술을 설명한다. (SW 개발에 필요한) 최신 정보와 관련 연구 결과를 잘 활용함을 보여야 한다. (컴퓨팅문제수준설명 속성 1: 지식의 깊이)

모든 이해관계자 요구사항에 대하여 검토한 후 관련 기술을 작성한 것만 기술하면 된다.

ID	이해관계자 요구사항	관련 기술
St-008	강의실 예약 시 쾌적한 사용을 위해 수용 가능한 인원의 50% 까지만 예약을 허용해야 한다. (강의실의 예약 또는 예약 대기 인원이 50% 이상인 경우 강의실 예약이 불가해야 한다.)	예약 신청 버튼을 누르기 전 특정 강의실의 예약 인원이 50% 미만이더라도 예약 신청 버튼을 눌렀을 때 다른 학생이 예약을 하여 50% 초과되면 해당 예약 신청이 허용되면 안 되므로 동기화(synchronization)가 필요하다.
St-012	강의실 별 강의 현황과 예약 현황을 백업 및 복구할 수 있어야 한다.	강의 현황과 예약 현황을 YAML 파일 형식으로 저장한다.

2. 디자인 패턴 계획

2.1 유스케이스

계획한 다섯 가지 이상의 디자인 패턴이 사용될 유스케이스(또는 시나리오)를 기술하고, 유스케이스의 어떤 부분에서 특정 디자인 패턴을 사용할 것인지 명확하게 설명한다. 유스케이스는 디자인 패턴 별로 각각 기술할 수도 있고, 하나의 유스케이스에서 모든 디자인 패턴을 설명할 수도 있다.

여러 개의 유스케이스를 기술할 경우에는 이들 유스케이스가 개발하려는 시스템의 목적을 달성하기 위하여 연관성이 있음을 보여줄 수 있어야 한다.

개발 단계에서 수정 가능하므로 계획서 작성 시 유스케이스를 최대한 많이 작성하도록 한다.

참고자료: https://seps8.deu.ac.kr/redmine/boards/43/topics/1033

유스케이스 예)

유스 케이스	Process Sale (Cash Payment)
액터	고객 (개시자 ), 판매원
목적	판매 및 현금 지불을 기록한다 .
개요	고객은 구매하고자 하는 물품을 가지고 판매원이 있는 계산대로 간다 . 판매원은 구매 항목을 기록하고 지불을 처리한다 . 계산이 완료되면 고객은 구매한 물품을 가지고 매장을 떠난다 .
유형	기본 , 핵심
참조
이벤트 흐름 (flow of events) 또는 주흐름 (main flow, basic flow)	액터	시스템
	① 고객이 구매하고자 하는 물품을 가지고 계산대에 오면 유스 케이스가 시작된다 . ② 판매원은 각 물품의 식별자를 기록한다 . 동일한 물품이 여러 개 있는 경우에는 수량을 기록할 수 있다 . ④ 물품의 입력이 끝나면 , 판매원은 입력이 완료되었음을 시스템에 알린다 . ⑥ 판매원은 고객에게 총액을 알려준다 . ⑦ 고객은 현금을 지불한다 . 대개의 경우 현금은 판매 총액보다 많다 . ⑧ 판매원은 고객에게 받은 현금 금액을 기록한다 . ⑩ 판매원은 현금을 입금시키고 거스름돈을 꺼낸다 . 판매원은 영수증과 거스름돈을 고객에게 전달한다 . ⑫ 고객은 구매한 물품을 가지고 떠난다 .	③ 물품 가격을 결정하고 , 물품 정보를 판매 거래에 추가한다 . ⑤ 판매 총액을 계산하여 표시한다 . ⑨ 거스름돈을 표시한다 . ⑪ 완료된 판매를 기록한다 .
대체 이벤트	② 잘못된 식별자가 입력되면 에러를 표시한다 . ⑦ 고객이 충분한 현금을 소지하지 않은 경우 판매 거래를 취소한다 .

2.2 기능 요구사항 목록

QA.01 문서의 “기능요구사항” 쉬트에 있는 기능 요구사항 목록을 나열한다. 2.1절 유스케이스에서 도출한 요구사항을 모두 기술한다.

노란색 배경으로 보이는 기능 요구사항(추정치(일) = 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	하

2.3 시스템 기능

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

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	사용자 제거 성공 또는 실패를 알린다.

2.4 이해관계자 요구사항-기능 요구사항 추적성 검토

이해관계자 요구사항 문서에 있는 요구사항 추적표를 사용하여 기능 요구사항이 이해관계자 요구사항을 모두 포함하는지 여부를 확인할 수 있어야 한다.

(주의) 표 제시 후 요구사항 추적성 검토 결과를 기술해야 한다.

SFR ID	ST ID
SFR-100	N/A
SFR-101	St-001, St-002
SFR-102	St-003
SFR-103	St-004
SFR-104	St-005, St-007
SFR-200	N/A
SFR-201	St-009
SFR-202	St-010

3. 개발 프로세스

개발 시 적용할 프로세스를 간단하게 기술한다. (폭포수 모형, 스크럼, UP 등의 개발 프로세스 중에서 선택하면 됨.)

4. 조원 역할

조원의 (예상) 역할을 간략하게 기술한다.

5. 시험 계획

디자인 패턴 별로 요구사항에 맞게 올바르게 구현하였음을 확인할 수 있도록 (자동화된) 시험 계획을 기술한다. 사용 예정 도구와 테스트 케이스 작성 방법, 테스트 결과 표현 방법 등을 기술한다.

2절에서 작성한 유스케이스를 기반으로 테스트 케이스를 작성하도록 한다. (ISO/IEC/IEEE 29119 SW 테스팅 국제 표준에서 유스케이스 테스팅 참고)

6. 일정 계획

6.1 WBS

개발을 위한 소작업을 정의하고 의존성과 소요기간을 산정한다.

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

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

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

6.2 최소 소요기간 산정

프로젝트 수행에 필요한 최소 소요기간을 계산한다.

7. 현실적 제한조건 분석

설계 수행 과정에서 다수의 현실적 제한조건을 반영해서 설계할 계획임을 제시해야 한다. 요소설계 교과목에서는 현실적 제한조건 중 일부만 선택적으로 반영할 수 있음. (컴퓨팅문제수준설명 속성 8: 다양한 분야에 미치는 영향을 고려하고 있다.)

항목	내 용
생산성	개발 과정에 생산성을 높일 수 있는 도구를 적용하였는지, 그리고 산출물을 활용하여 기존 시스템에 비해 생산성을 높일 수 있는지를 기술한다.
	NetBeans IDE의 maven 빌드 도구를 사용하여 라이브러리 설치를 자동으로 하게 하였으며, FindBugs 정적 분석 도구를 사용하여 발견된 주요 결함(major 이상)을 제거하였다. 개발된 프로그램을 사용하면 학생들의 성적 증명서를 입력으로 하여 졸업 이수요건을 자동으로 검증하게 하여 기존 수작업에 비하여 소요시간 측면에서 비교불가할 정도로 빠른 처리가 가능하다 기존의 클래스만을 대상으로 하는 프로그래밍의 한계를 극복하고 보다 좋은 구조를 가지는 프로그램을 제작하여 생산성을 높인다.
산업표준	개발 프로세스나 개발 산출물에 산업표준/국가표준/국제표준을 고려하였는지 기술한다.
	개발 프로세스로 애자일 개발 방법론인 스크럼을 사용한다. 개발 단계에서 테스팅시 ISO/IEC/IEEE 29119 SW 테스팅 국제 표준에서 정의하는 테스트 케이스 설계 기법(경계값 분석 등)을 적용한다. 객체지향 분석, 설계의 기본 요소인 클래스 표기 방법인 UML을 이해하고, 클래스의 구조를 디자인 패턴에 맞게 표현할 수 있어야 한다.
기타	위에서 기술한 항목 외에 반영된 현실적 제한 조건을 기술한다.

8. 의사소통 계획

프로젝트 진행을 원활하게 수행하기 위하여 필요한 일간/주간/월간 등의 회의 종류와 의사소통을 위한 도구 설정 등을 기술한다.

9. 형상관리 계획

프로젝트 진행을 원활하게 수행하기 위하여 프로젝트 산출물에 대한 형상관리 계획을 기술한다.