Week 3 · Weekly Report
이번 주는 분석 단계의 마무리 단계
다음 주는 화면·구조 설계 시작
조찬희 기획·PM · 기경현 백엔드·데이터
기간 1–3주 · 보고일 2026.09.14
실시간 교통신호 상태정보
오류검지 시스템
Deliverables
| 산출물 | 역할 | 규모 |
|---|---|---|
| 프로젝트정의서 | 왜 만드는가, 범위, 데이터에 대한 정의 | 수업 MVP |
| 제안요청서 요구사항 대응표 | 공단 요청 39건을 수업에서 어디에 붙일지 | 구현 7 / 부분 17 |
| 요구사항정의서 | 무엇을 만들지, 테스트로 가릴 기준 | 기능·비기능 요구 |
| 유스케이스·사용자 스토리 | 누가, 어떤 흐름으로 사용할지 | 흐름 11개 · 구현 단위 33개 |
| 제품 백로그 · WBS | 언제, 누가, 몇 주에 할 작업 내용 | 15주 작업 목록 |
How we wrote
Per document
공단 제안요청서를 수업 범위로 줄였다. 신호 데이터 수집→검지→관제→통제, 실시간 API와 계획 데이터의 대조를 통한 오류 감지
요청 39건중 구현부분과 구현 불가능한 부분을 분리 구현하는 부분은 24건
무엇을 만들지 ID로 쪼개고, 테스트로 통과·실패를 가릴 수 있게 적었다. 통제는 정보·계획·현장 요청으로 나눴다.
흐름 11개, 구현 단위 33개로 나눴다. 백로그를 15주 일정에 따라 분배
Next week · 4주차
| 할 일 | 담당 |
|---|---|
| 프론트·백엔드 스택 확정, 논리 구성도 | 공동 |
| 표본 교차로 수 × 수집 주기 × 보관 | 기경현 |
| 필수 6화면 IA · 와이어 | 조찬희 |
| 원본/제공 분리한 개념·논리 ERD | 기경현 |
After next week · 5주차
화면이 서버에 무엇을 요청하는지 적어 둔다.
어떤 신호를 오류로 볼지 규칙을 적는다.
대시보드·이슈·교차로 상세를 클릭해 보게 만든다.
4–5주 설계를 한 번 점검하고 구현으로 넘어간다.