설명

폭포수 모형은 소프트웨어 개발에서 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식이다.

• 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용하며 고전적 생명 주기 모형이라고도 한다.
• 소프트웨어 개발 과정의 앞 단계가 끝나야만 다음단계로 넘어갈 수 있는 선형 순차적 모형이다
• 각 단계별로 산출물이 나오며 단계별 평가서가 존재한다.
• 두개 이상의 과정이 병행하여 수행되지 않는다

개발 순서

System engineering
높은 수준의 구조 명세서를 작성한다. 모델에 사용할 각종 문서를 정의한다.

Requirements Analysis
요구사항을 수집하고 문제를 이해, 분석하는 단계이다. 분석가는 고객의 요구사항을 기능, 성능, 인터페이스 등으로 파악하고 문서화 한다. 이 단계에서 산출물은 요구사항 명세서, 기능 명세서, 인수 테스트 명세서등이 있다.

Disign
소프트웨어 아키텍처 명세서, 시스템 테스트 명세서, 디자인 명세서, 서브시스템 테스트 명세서, 단위 테스트 명세서등 모든 시스템 구조를 결정하게 된다.

Construction
설계명세서를 토대로 실제 프로그래밍을 하게 된다.

Testing
단위 테스트 레포트, 서브 시스템 테스트 레포트, 시스템 테스트 레포트, 인수테스트 레포트등의 산출물이 나오며 프로그램이 입력에 따라 제대로 작동하는지 여부와 오류를 발견하기 위해 수행된다.

Installation
시스템에 인스톨해야할 소프트웨어라면 인스톨 작업을 하게 된다.

Maintenance
요구사항 정의 변경에 따른 유지보수 및 산출물 변경을 하게 된다. 유지보수를 하게 되는 이유는 여러가지 인데 고객이 성능향상이나 기능 추가를 요구할 경우, 새로운 운영체제나 주변장치등이 바뀌는 경우, 테스팅 단계에서 미리 체크하지 못한 오류등을 수정할 경우가 있다. 실제 프로젝트 예산의 70%가 유지보수단계에 쓰일 정도로 시스템이 제대로 구축이 안되어있다면 엄청난 예산을 잡아먹는다.

장점

• 모형의 적용 경험과 성공사례가 많다.
• 단계별 정의가 분명하고, 각 단계별 평가가 확실하게 이루어진다.
• 각 프로세스 단계의 역할 이해가 용이하다.
• 단계별 산출물이 정확하여 개발공정의 기준점을 잘 제시한다.
• 프로젝트의 관리가 용이하다.

단점

• 프로젝트 초기, 요구사항을 정의할 때 정확한 요구사항을 제시하지 않을 경우 프로세스의 각 단계가 진행될 수록 요구사항의 변경, 추가가 매우 어렵다. (고객의 feedback 반영이 어려움)
• 각 단계별로 다음 단계로 진행될 때 오류 없이 진행되어야 하지만 현실적으로 오류없이 다음단계로 진행되기 어렵다.
• 만약 계획대로 진행되지 않을 경우 납기일 전 철야, 납기일 지연, 지연에 따른 비난과 스트레스가 개발자에게 향하여 에너지 소진, 고객의 요구를 충족하지 못하는 등의 부작용이 발생한다.
• 고객은 개발된 제품이 자신이 원하는 것인지 알기 위해서 프로젝트 후반까지 기다려야만 한다.
• 만약 고객이 요구한 시스템이 아니면 최악의 경우 프로젝트가 실패하게 될 수도 있다.