[공개SW 활용 및 참여] Waterfall 방법론

---

Waterfall 방법론이란?

소프트웨어 개발 초기에 기존 산업에서 차용해온 소프트웨어 개발 프로세스. 정해진 단계에 따라 엄격한 순서를 따르는 순차적인 개발 과정이다.기존의 제조업과 건설업에서 효과적으로 적용되었기 때문에 소프트웨어 개발에서도 적용될 수 있다고 여겨졌다.

 

Waterfall model

• Waterfall(폭포수) 방법론은 순차적인 선형 프로세스를 따르며 소프트웨어 엔지니어링 및 IT 프로젝트를 위한 시스템 개발 라이프 사이클의 가장 보편적인 방법론이다.

• 간트 차트 (각 작업의 시작 날짜와 종료 날짜를 보여주는 막대차트)를 사용하여 계획되기도 한다. 단계 중 하나가 완료되어야 다음 단계로 이동한다. 팀은 처음부터 전체 프로세스를 시작하지 않고 이전 단계로 돌아갈 수 없다. 다음 단계롤 넘어가기 전에 요구 사항을 검토하고 승인해야 할 수도 있다.

• The Waterfall model은 진행과정 도중의 변화가 치명적인 제조 및 건설산업과 같은 고도로 구조화 된 산업에서 시작되었다. Waterfall에 대한 최초의 공식적인 설명은 1970년에 Winston W. Royce의 기사인데, 이 기사에서는 소프트웨어 개발에서  The Waterfall model의 결함에 대해 이야기하고 있다.

---

Waterfall 방법론의 장점

• 간편한 사용 및 관리 : Waterfall 모델은 각 프로젝트마다 동일한 순차 패턴을 따르므로 사용하기 쉽고 이해하기 쉽다. Agile과 달리 팀은 Waterfall 프로젝트를 진행하기 전에 사전 지식이나 훈련이 필요하지 않다. 각 단계마다 구체적인 결과물과 검토가 있기에 관리 및 제어가 쉽다.

• Waterfall의 모든 단계에 시작점과 종료점이 있으며, 이해 관계자 및 고객과의 진전을 쉽게 공유 할 수 있다. 코드를 작성하기 전에 요구 사항과 디자인에 중점을 두어 팀은 마감 기한이 누락 될 위험을 줄일 수 있다.

• 잘 문서화 된 접근법이 필요하다. 모든 단계에 대한 문서화가 필요하므로 코드 및 테스트의 논리를 보다 잘 이해할 수 있다. 또한 향후 프로젝트 이해 관계자가 특정 단계에 대한 세부 정보를 볼 필요가 있는 경우에도 산출물이 도움이 된다.

---

Waterfall 방법론의 단점

• 변경 사항을 쉽게 수용 할 수 없다. 일단 팀이 단계를 완료하면 되돌릴 수 없다. 테스트 단계에 도달하고 요구 사항 단계에서 기능이 누락되었다는 것을 발견하면 되돌아 가서 수정하는 것이 매우 어렵고 비용과 시간이 많이 든다.

• 단계를 마치지 않으면 마지막까지 소프트웨어가 제공되지 않는다. 결과적으로 이해 관계자는 개발과정의 후반부까지 작업 소프트웨어를 보지 못한다.

• 정확한 요구 사항을 수집하는 것이 어려울 수 있다. Waterfall 프로젝트의 첫 번째 단계 중  하나는 고객 및 이해 관계자와 대화하고 요구 사항을 식별하는 것이다. 그러나 프로젝트 초기에 원하는 것을 정확히 찾아내는 것은 어려울 수 있다. 종종 고객은 조기에 원하는 것을 모르고 프로젝트가 진행됨에 따라 요구 사항을 파악하고 식별한다.

---

Waterfall 방법론을 사용해야 할 때

• 범위의 변경은 기대하지 않고 고정된 가격 계약으로 작업하고 있는 경우

• 프로젝트는 매우 간단하거나 여러 번 해본 적이 있어 숙달 된 경우

• 요구 사항은 잘 알려져 있고 고정되어 있을 때

• 고객이 우너하는 것을 정확하게 미리 알 고 있는 경우

• 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우

---