폭포수 모델(Waterfall Model) 개발방법

 

폭포수 모델(warefall model)은 전통적인 개발 프로세스로 '계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 소프트웨어 통합(설치) → 유지보수'의 단계를 거치는 순차적인 (sequential) 소프트웨어 개발 모델이다.

 

폭포수 모델이라는 이름은 개발의 흐름이 지속적으로 아래로 향하는 것처럼 보이는 데서 이름을 붙였다.

 

폭포수 모델은 소프트웨어 개발 초기에 적절히 사용된 시간은 구현이 끝난 후 수정하는 것보다 시간과 돈, 그리고 노력이 몇 배는 적게 든다는 사실을 중요시 한다.

 

이는 프로그램을 설계 단계에서 고치기는 쉬우나 몇 달 뒤 구현과 통합이 진행되는 중에 변경하는 것은 어렵거나 불가능하며 자칫 그때가지 개발된 모든 코드와 컴포넌트를 버릴 수 있다는 문제점을 해결하기 위한 개발 방법론이다. 이러한 논의가 Big design up front와 폭포수 모델의 배경이 되는 중심적인 아이디어이다.

 

즉, 소프트웨어 개발시 전 단계가 100% 완료되고 모두 정확하다는 것을 확인한 후 다음 단계로 진행하는 방법이다. 소프트웨어 요구 사항은 설계가 시작되기 전에 돌과 같이 단단하게 확정되어야 하고, 소프트웨어 설계는 개발자들이 구현을 시작하기 전에 완벽해야 한다. 검토 및 검증, 검사에 의해 프로젝트 전반의 품질 향상을 추구한다.

 

 

폭포수 모델은 소스코드에 있어서 정확하고 완벽한 문서화를 강조한다. 충분히 설계되지 않고, 문서화되지 않은 프로젝트 일수록, 팀 구성원이 떠날 경우 많은 지식이 사라지고 프로젝트 지속에 더 큰 어려움이 따른다는 것이 그 논지이다. 그러나 반대로 완벽하게 동작하는 설계 문서가 존재할 경우, 새로운 팀원이나 심지어 완전히 새로 구성된 팀에게도 프로젝트를 이전하여 문서 기반으로 수행하는 것이 가능하다.

 

또한, 소프트웨어 개발에 구조화 된 접근 방법을 제공하며 쉽게 이해할 수 있고 설명이 가능한 각각의 구분된 단계를 순차적으로 진행하게 하여 프로세스 상의 마일스톤을 정하는 것도 상대적으로 쉽다. 기술적인 위험이 없고 유사한 프로젝트를 해 본 경험이 있어서 비교적 정확한 비용 예측이 일정 계획하에 프로젝트를 추진할 경우 적합하다.

 

하지만 폭포수 모델은 안정적인 요구사항 기반을 가진 프로젝트나 모든 소프트웨어 개발의 문제 영역을 완벽히 예측할 수 있는 설계자를 가진 프로젝트에만 맞을 수 있다. 또한, 구현자들이 설계를 완벽하고 정확하게 구현하지 않을 경우 시스템 통합 단계를 수월하게 진행할 수 없다.

 

따라서 폭포수 모델은 다음과 같은 비판을 받고 있다.

 

1. 실제 실행에 있어 불가능한 모델이다.

2. 설계자들은 설계 시 향후 구현 작업의 난이도를 예측하기 어렵다.

 

 

일반적으로 의미있는 규모의 프로젝트에서는 다음 단계에 대한 이해나 경험이 없이 각 단계를 완벽히 마무리한 후 다음 단계로 진행하는 것이 불가능하다. 또한 고객들은 정해진 요구 사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 통제할 수 있는 방법도 많지 않다.

 

프로젝트를 진행하다보면 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우도 있다. 그럴 경우 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 재설계를 택하는 것이 향후 발생될 수 있는 더 큰 문제를 방지하는데 더 나은 선택이 될 수 있다.