8/23

[오후 라이브 세션 - 김진호]

---

---

---

-> 중요한 문서다. 사용자 요구사항 정의서는 과제로 제출도 할 것이다.

-> 요구사항 ID 는 유니크한 값이어야 한다. 이름은 어떤회사, 어떤팀 이냐 등등에 따라 임의로 설정함. 기능 요구사항은 RQ(Requirement)001, RQ002 등으로 하는 것을 권장한다고함.

-> 팀이 모여서 스택오버플로우를 띄어 놓고 요구사항 작성해보는 게 좋다.

---

-> 화면 개요는 최대한 간단하게 써라.

-> 아래에 보면, 앞서 요구사항 정의서에서 요구사항 목록중에서 이 화면에서 수행되는 항목을 모두 적어줌.

---

---

---

---

* 분석단계 : 요구사항 정의서

* 설계단계 : 화면정의서(프론트), 테이블설계서(백엔드)

* 구현단계 : API 문서

* 시험단계 : 구현 하면서 단위 테스트 + 배포

---

* 배포에 대해 가이드라인을 제공하겠다.

-> 가장 이상적인 것은, 개발 서버를 따로 두고 개발 서버에 프론트엔드와 백엔드가 둘다 배포하여 하는 것임. (Case 3의 경우)

-> aws는 돈든다. 그래서 다른 방법을 알려주자면, 백엔드에서 한명의 노트북을 외부에 공개하여 서버처럼 활용하는 방법이 있다. 그렇게 하고 해당 노트북에 톰캣으로 서버화 하고, 이 톰캣위에 jar를 배포하고 프론트엔드측에서 접근하게 할 수 있음. DB도 마찬가지로 해당 노트북의 로컬DB 를 사용할 수 있게된다.

-> NGinx와 WAS 서버가 통신하는 것 같음.

---

---

-> 테스트 API는 단순히 "Hello World"정도 통신이 되는 지 확인하면 됨.

-> 팀장은 WBS 는 간트차트(칸반차트)를 작성해서 담당자 지정하고 Due to를 정하고 매일 확인하여 간트차트를 정리하라.

---

* 추가 설명

-> 팀장에 대해 : 기술적인 것, 담당자 지정, 일정에 대한 압박을 최대한 공손한 말투로 진행해라. 팀원의 의견 취합을 최우선으로 해라.

-> 새로운 기술을 도입하려면 그 이유를 팀원에게 설명할 수 있어야 함.

---

-> 완성 못 했으면, 배포 포기하고 개발만 해도 됨. 혹은 만든 것 까지만 배포해도 됨. 

-> 이번 프리-프로젝트 목표는 완성이 아니라고 함.

-> 뭐든지 만든만큼 하면 된다.

-> 제출은 pdf로 해라. 파일명은 팀명 ( seb_39_pre_35 ). 팀장만 제출하면 됨.

-> 문서의 양식은 자유롭게 하면 된단다.

 

* 프로젝트 기간동안 단 한줄의 코드도 제공되지 않을 것.

---

---

-> EC2에서 한 번에 배포하는 경우는 프론트 분들은 빌드해서 백엔드 분들에게 드리면 되어요

-> rds 도입 여부는 임의로 정하면 됨.

-> 프리티어로는 EC2가 하나로 한정되어 있음.

---

-> 메인 프로젝트때는 (1) 같은 클라우드 배포가 권장됨.

---

* 테스트 API 과정에 대해.

---