폭포수 모델 - 특징, 적용, 의견

폭포수 모델(Waterfall Model)은 1970년대에 등장한 프로세스 모델 중 하나입니다. 

방법론을 공부하는 사람들에게 가장 처음 접하게 되는 모델로, 간단하고 직관적인 프로세스로 이해하기 쉽습니다. 이 모델을 '모델'이라고 할 수도 있고 '방법론'이라고도 할 수 있습니다

 

폭포수 모델은 소프트웨어 개발을 일련의 선형적인 단계로 분할하는 방법을 가지고 있습니다. 

이 모델은 순차적이며 단계별이며, 각 단계는 이전 단계가 완료된 후에 시작됩니다. 

[목차]

• 특징
• 적용 방법
• 의견

특징

• 선형적인 진행 
  • 각 단계가 선형적으로 연결되어 있어 이전 단계가 완료된 후에 다음 단계가 시작될 수 있습니다. 
• 요구 사항의 고정성 
  • 초기에 요구된 사항이 변경되지 않는 한, 개발 과정 중에는 요구 사항이 변경되지 않습니다. 
• 문서 중심 
  • 각 단계는 문서 작업에 중점을 둡니다. 요구 사항 명세서, 설계 문서, 테스트 계획서 등이 기본으로 작성되고 관리됩니다. 
• 일정 및 비용 예측 용이 
  • 각 단계가 명확히 정의되어 있기 때문에 일정과 비용을 예측하기 쉽습니다. 

적용 방법

1. 요구 사항 수집 
   • 프로젝트 시작 시 초기에 요구되는 모든 사항을 수집하고 문서화합니다. 
2. 설계 단계 
   • 요구 사항을 기반으로 아키텍처와 디자인을 수립합니다. 
   • 이는 상세한 문서로 작성, 관리됩니다. 
3. 구현 
   • 설계된 시스템을 실제로 코드화합니다.
4. 테스트 
   • 각 단계가 완료될 때마다 해당 단계의 테스트를 진행하여 기능이나 문제점을 확인합니다. 
5. 유지보수 
   • 개발이 완료된 이후에도 유지보수를 통해 문제를 수정하거나 변경 요청을 수용합니다. 

의견

모든 단계가 어느 정도 예측 가능한 모델로 사실 모든 개발자가 아주 좋아하는 모델이라고 생각합니다. 

그 이유는 결정된 요구 사항으로 개발 중에는 요구 사항이 변경되지 않으므로, 설계를 바꾸지 않아도 됩니다. 

설계를 바꾸지 않아도 되니, 개발에만 집중할 수 있습니다. ( 물론, 문서화는 빼고요. ) 

 

혹시, 이런 이야기 들어보셨나요? "요구 사항 명세서에 고객의 사인을 받는다. " 

보통 외주 개발을 할 때에는 고정된 예산 안에서 프로젝트를 진행해야 하기 때문에 예산을 산정할 때 사용된 요구 사항이 변경되지 않도록 하기 위한 것으로 활용되었습니다. 

대기업에서도 요구 사항 변경에 대해서는 민감하게 생각했었습니다. 

지금 생각해보면, 대부분의 외주 개발은 폭포수 모델을 채택했던 것 같습니다. 기본만 그렇고,  프로젝트의 마지막은 애자일스러웠지요. 

 

대다수의 개발자들이 한 번쯤은 경험해 본 적이 있을 겁니다. 프로젝트의 마지막 단계는 대개 야간 근무와 함께 진행되었습니다.
이는 고객의 입장에서도 정말 괴로운 시간이 었을 것입니다.

요구 사항 수집과 분석 과정에서는 모든 요구 사항이 완벽하게 수렴될 것으로 예상했지만, 실제 개발된 프로그램을 보면 그렇지 않은 경우가 많기 때문입니다.

 

폭포수 모델의 유연성에 대한 단점을 보완하는 점점적인 방법론으로는 애자일 개발 방법론이 있습니다. 

그렇지만, 폭포수 모델은 아직까지도 매우 많이 쓰이고 있습니다. 

요구 사항이 명확한 경우나 아주 작은 라이브러리 같은 것을 만들 때 사용됩니다.

고도의 집중력을 발휘해야 할 때 매우 유용하다고 생각됩니다.