[전통적인 방법론] 폭포수(Waterfall) 모델 - 7. 폭포수 모델 프로젝트 실습 (2. 프로젝트 발표 및 피드백)

2. 프로젝트 발표 및 피드백

프로젝트가 완료된 후에는 결과를 공유하고 피드백을 수집하는 과정이 필수적입니다.
이를 통해 프로젝트의 장점과 개선점을 분석하고, 향후 프로젝트의 품질을 높이는 전략을 수립할 수 있습니다.

이 문서에서는 프로젝트 문서 및 결과물 공유 방법, 발표 전략, 폭포수 모델의 장단점 분석 및 토론 방법을 정리하겠습니다.

---

1️⃣ 프로젝트 문서 및 결과물 공유

📌 프로젝트 발표의 목적
✅ 개발된 소프트웨어의 기능, 구조, 결과물을 명확하게 설명
✅ 프로젝트 진행 과정에서의 도전 과제와 해결 방법 공유
✅ 피드백을 반영하여 향후 개선할 부분을 식별
✅ 폭포수 모델을 활용한 경험을 공유하고, 적용 가능성을 평가

📌 공유해야 할 주요 문서 및 자료

문서 유형	설명
요구사항 명세서(SRS)	프로젝트 목표, 기능, 요구사항 정리
시스템 설계 문서	시스템 아키텍처, 데이터베이스 설계, API 명세
테스트 계획 및 결과	테스트 케이스, 버그 수정 내역, 성능 테스트 결과
코드 및 실행 환경	소스 코드(GitHub, GitLab), 배포 방법
프로젝트 회고 및 개선점	프로젝트 진행 중 발생한 문제와 해결책, 개선 방향

📌 결과물 공유 방법 ✅ GitHub, Notion, Confluence 등의 협업 도구를 활용하여 문서화
✅ API 문서는 Swagger 등으로 정리하여 공유
✅ 배포된 시스템(웹사이트, 앱 등)의 데모 시연을 통해 직접 체험할 수 있도록 제공

---

2️⃣ 프로젝트 발표 전략

📌 효과적인 발표를 위한 전략 ✅ 핵심 내용을 짧고 명확하게 전달 – 불필요한 기술적 설명은 최소화
✅ 실제 데모를 통해 프로젝트 결과를 시각적으로 표현
✅ 팀원들이 각자의 역할을 설명하도록 배분하여 발표 진행
✅ 청중과의 상호작용(질문 및 답변)을 적극적으로 활용

📌 프로젝트 발표 구성 예시

섹션	설명
1. 프로젝트 개요	프로젝트의 목표, 해결하려는 문제
2. 사용 기술 및 시스템 구조	기술 스택, 아키텍처 다이어그램
3. 핵심 기능 및 데모	주요 기능 설명 및 실행 영상/실시간 시연
4. 도전 과제 및 해결 방법	개발 중 발생한 문제와 해결 방안
5. 테스트 및 배포 과정	테스트 수행 결과, 성능 테스트, 보안 점검 내용
6. 향후 개선 방향	추가 개발 예정 기능 및 개선할 부분
7. 질의응답(Q&A)	청중과의 소통을 위한 질의응답 진행

📌 예제 발표 스크립트

"안녕하세요, 저희 팀은 '도서 관리 시스템' 프로젝트를 진행하였습니다.
이 프로젝트의 목표는 사용자가 손쉽게 도서를 관리하고, 검색할 수 있도록 하는 것입니다.
이번 프로젝트에서는 Flask와 React를 활용하여 웹 애플리케이션을 개발했으며, 
백엔드와 프론트엔드를 RESTful API로 연동하였습니다.

이제 주요 기능을 보여드리겠습니다..."

✅ 명확한 발표 흐름을 유지하며, 데모를 활용하여 시각적 이해도를 높이는 것이 중요

---

3️⃣ 폭포수 모델의 장단점 분석 및 토론

📌 폭포수 모델(Waterfall Model)의 특성
✅ 각 개발 단계를 순차적으로 진행(요구사항 분석 → 설계 → 개발 → 테스트 → 배포)
✅ 단계가 완료되면 다음 단계로 넘어가기 때문에 명확한 문서화와 프로세스 관리가 가능

📌 폭포수 모델의 장점

장점	설명
명확한 프로젝트 계획	초기에 모든 요구사항을 정의하여 체계적인 진행 가능
철저한 문서화	각 단계에서 산출물이 남기 때문에 유지보수 용이
대규모 프로젝트에 적합	정부 프로젝트, 제조업 소프트웨어처럼 요구사항이 확정된 경우 유리
개발 프로세스의 안정성	각 단계가 완료된 후 진행되므로 품질 관리가 용이

📌 폭포수 모델의 단점

단점	설명
요구사항 변경이 어렵다	초기에 요구사항이 확정되면 이후 변경이 어려움
개발이 완료될 때까지 결과 확인이 어렵다	최종 제품이 나오기 전까지 사용자 피드백을 반영하기 어려움
긴 개발 주기	모든 단계를 순차적으로 진행하므로 개발 완료까지 시간이 오래 걸릴 수 있음
유연성이 낮다	예상치 못한 문제가 발생할 경우 대응하기 어려움

📌 폭포수 모델이 적합한 경우 ✅ 요구사항이 명확하고 변경 가능성이 낮은 프로젝트
✅ 규제 및 문서화가 중요한 정부/금융/의료 시스템
✅ 명확한 개발 단계가 필요한 대규모 소프트웨어

📌 폭포수 모델이 적합하지 않은 경우 ✅ 요구사항이 자주 변경되는 프로젝트
✅ 빠른 피드백이 필요한 스타트업 제품 개발
✅ 애자일(Agile) 개발 방식이 더 적합한 소프트웨어

---

4️⃣ 팀별 토론 주제 및 피드백 반영

📌 토론 주제 예시

1. 폭포수 모델을 사용하면서 겪은 가장 큰 어려움은 무엇이었는가?
2. 요구사항이 초기와 다르게 변경되었을 때, 어떻게 대응했는가?
3. 폭포수 모델과 애자일 모델 중 실제 개발 환경에서는 어떤 방식이 더 유리할까?
4. 프로젝트를 다시 진행한다면 어떤 점을 개선하고 싶은가?

📌 피드백 수집 및 반영 전략 ✅ 프로젝트 진행 중 발생한 문제를 문서화하여 기록
✅ 향후 프로젝트에서는 변경 가능성이 높은 요구사항을 초기 단계에서 철저히 검토
✅ 팀원 간의 협업 방식(커뮤니케이션 도구, 회의 방식) 개선

📌 피드백 반영 예시 ✔ 문제점: 요구사항이 변경되었을 때 수정이 어려웠음
✔ 해결책: 초기 요구사항 정의 시 프로토타입을 함께 개발하여 실사용자 피드백을 먼저 확보

✅ 토론을 통해 프로젝트 경험을 공유하고, 다음 프로젝트에서의 개선점을 도출하는 것이 중요

---

📌 결론

📌 프로젝트 발표는 결과물을 효과적으로 공유하고, 팀원 간의 경험을 정리하는 중요한 과정
📌 프로젝트 문서 및 결과물을 체계적으로 정리하여 공유하면 유지보수 및 개선이 용이
📌 폭포수 모델의 장단점을 분석하여, 향후 프로젝트에서 적절한 개발 방식을 선택하는 기준을 마련할 수 있음
📌 팀별 토론과 피드백을 통해 문제점을 분석하고 개선점을 도출하여 개발 역량을 향상할 수 있음 🚀