폭포수 모델 (Water fall model)

폭포수 모델(waterfall model) = 선형 순차적 모델 (linear sequential model)

 

폭포수 모델의 개발 절차

폭포수 모델에서는 폭포의 물이 위에서 아래로 떨어지듯이

계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며,

병행되거나 거슬러 반복되지 않는다.

 

이 모델에서는 요구사항분석단계가 끝나면 '요구 분석 명세서'라는 문서가 산출된다.

이 명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계인 설계 절차로 넘어간다.

이렇게 각 단계의 산출물에 대해 확인 절차를 거침으로써 서로 간의 책임 소재를 분명히 할 수 있다.

 

계획(planning) 단계

• 문제를 정의한 후 프로젝트 영역을 결정
• 작업 분할 구조도(WBS: Work Breakdown Structure)로 세부 작업 결정
• CPM(Critical Path Method)로 작업 순서 결정
• 간트 차트를 이용해 일정표 작성
• 기능 점수(FP: Function Point) 등으로 프로젝트에 소요되는 비용 산정
• 계획 단계의 최종 산출물인 '개발 계획서' 작성

요구 분석(requirement analysis) 단계

• 기존 시스템 분석 및 인터뷰 등을 통한 사용자 요구사항 수집
• 사용자가 요구하는 기능적 요구사항과 비기능적 요구사항 파악
• 각 방법론에 따른 표기법을 이용해 정리된 요구사항을 표현
• 객체지향 방법론에서는 유스케이스 다이어그램 작성
• 요구 분석 단계의 최종 산출물인 '요구 분석 명세서' 작성

설계(design) 단계

설계 단계는 크고 전체적인 시스템 구성을 나타내는 상위설계(아키텍처 설계)와 각 모듈(컴포넌트, 자료구조, 알고리즘)의 세부 내용을 설계하는 하위 설계로 나뉜다.

 

상위설계

• 개발하려는 소프트웨어의 전체 구조를 볼 수 있는 아키텍처 설계
• 아키텍처의 품질 속성 결정
• 아키텍처의 스타일 결정
• 설계 패턴 결정

하위설계

• 모듈 간 결합도와 모듈 내 응집력 고려해 각 모듈의 세부내용 설계
• 객체지향 방법론에 따라 설계를 한다면 설계 원리, 클래스 간의 관계, 클래스 설계 원칙 고려

구현(implenemtation) 단계

구현은 코딩을 하는 단계이다. 코딩을 할 땐 가능한 표준 코딩 스타일을 지키는 것이 좋다.

또한, 최근에는 보안이 매우 중요하므로 시큐어 코딩(sequre coding)방법도 고려한다.

 

테스트(test) 단계

테스트 방법은 다음과 같이 분류 가능하며 프로젝트의 성격에 맞는 방법을 선택한다.

• 개발자 또는 사용자 시각에 따른 분류
• 사용되는 목적에 따른 분류
• 프로그램의 실행 요구 여부에 따른 분류
• 품질 특성에 따른 분류
• 소프트웨어 개발 단계에 따른 분류

유지보수(maintenance) 단계

소프트웨어를 사용하다보면 추가 요구 사항, 수정 사항 등이 발생한다.

유지보수 단계는 사용 중인 소프트웨어를 문제없이 잘 유지하고, 보수하면서 사용하는 단계이다.

• 수정 유지보수
• 적응 유지보수
• 기능 보강 유지보수
• 예방 유지보수

폭포수 모델의 장점

- 관리가 용이하다

폭포수 모델은 절차가 간결하고 이해하기 쉽다. 또, 순차적 모델이므로 단계별 진척 사항에 대한 관리가 용이하다. 따라서 유사 분야의 소프트웨어 개발 경험이 많으면 효율과 품질 측면에서 우수한 결과를 낼 수 있다.

 

- 체계적으로 문서화할 수 있다

폭포수 모델은 각 단계별로 정형화된 접근 방법을 사용한다. 따라서 단계별 산출물을 체계적으로 문서화할 수 있다. 그리고 단계별 산출물을 검토하여 프로젝트 진행을 명확하게 할 수 있다.

 

- 요구사항의 변화가 적은 프로젝트에 적합

폭포수 모델은 초기에 어느 정도 요구사항이 확정되고 요구사항의 변화가 비교적 적은 형태의 프로젝트를 개발할 때 적합하다

 

폭포수 모델의 단점

- 각 단계는 앞 단계가 완료되어야 수행할 수 있다.

앞 단계가 끝날 때 까지 대기해야한다. 따라서 각 단계를 개발하는 절차 중에는 사용자의 요구 사항을 반영할 수 있는 체계적인 방법이 없어, 개발이 완료되어 동작하는 것을 보기 전에는 사용자가 원하는 것을 정확히 알 수 없다.

 

- 각 단계의 결과물이 완벽한 수준이여야 다음 단계에 오류가 발생하지 않는다.

하지만 현실은 그렇지 못하다. 산출물을 충분히 검토했다 해도 발견하지 못한 오류가 있을 수 있다. 따라서 추후에 오류가 발견된다면 수정하는 데 시간과 비용이 많이 들 것이다. 또한, 개발된 이후에 새로운 요구사항이 추가된다면 프로젝트 전체 일정에 큰 부담을 줄 것이다.

 

- 사용자가 중간에 가시적인 결과를 볼 수 없어 답답할 수 있다.

사용자가 실제로 소프트웨어 작동 모습을 보려면 구현이 끝나야한다. 오랜 기다림 끝에 확인한 실행 결과가 만족스러우면 다행이지만, 원하는 결과가 아니라면 수정 요구사항을 받아 보완하기 위해 시간과 비용이 많이 들 것이다.

 

 

요즘처럼 소프트웨어 개발이 매우 빠르고 끊임없이 변경되는 시대에는 적합한 모델이 아니다.

하지만 요구사항이 어느정도 고정되어 있고 작업이 선형으로 진행된다면 유용하다.