2.2 폭포수 모델

폭포수 모델의 기본형은 각 단계에서 수행되는 활동들이 서로 겹치지 않고, 단계들이 병행 수행되거나 거슬러 반복됨 없이 한 방향으로 진행된다. 따라서 각 단계가 끝날 때마다 결과를 확인한 후에 다음 단계로 진행해야 한다.

여러 사람들에 의해 병행 수행될 수 있다.

1 타당성 조사

• 제안된 시스템의 개발에 투입되는 비용과 그로인한 이득을 평가하여 분석을 수행

1. 조직 측면의 타당성
2. 경제적 타당성
3. 기술적 타당성
4. 운영의 타당성

2 요구 분석과 명세

• 시스템이 갖추어야하는 조건이나 능력으로 표현되어 있다. 매우 중요한 단계로 전체 프로젝트의 성패를 좌우한다
• 이 단계의 결과 문서인 SRS는 시스템이 무엇을 하는지에 관한 설명을 담고 있다
• SRS는 다음의 내용을 포함해야 한다
  1. 문제에 관한 구체적인 기술
  2. 문제 해결을 위한 가능한 대안
  3. 소프트웨어 시스템의 기능적 요구사항들
  4. 소프트웨어 시스템의 제약사항들

3 설계와 명세

• SRS에 표현된 'what'을 'how'로 변환하는 것

1. 전통적 설계 방법
   • 구조적 설계는 아키텍처 설계와 상세 설계로 구분된다.
   • 아키텍처 설계: 상위 수준의 설계, 시스템을 모듈들로 분해하고 모듈들의 인터페이스와 모듈간의 호출 관계를 표현한다.
   • 상세 설계: 하위 수준의 설계, 각 모듈들의 내부 구조를 상세히 설계한다.
2. 객체지향 설계 방법
   • 시스템에서 필요한 다양한 객체들을 파악한 후 그들 간의 관계를 설계한다.
   • 개발 비용과 시간을 단축하고 유지보수성을 높일 수 있다고 알려져 있다.

4 코딩과 단위 테스트

• 이 단계의 결과물은 구현되고 테스트된 모듈 집합이다
• 테스트 작업은 각 모듈이 해당 명세서를 만족하는지 확인하는(verify) 것이다.
• 품질 보증 활동의 하나로 이 단계에서 모듈 테스트 작업을 수행한다. 기능적 정확성 외에 성능이나 코딩 표준 및 적절한 프로그래밍 스타일을 준수하는가를 검사하기 위해 코드 인스펙션 작업을 수행할 수도 있다.

5 통합과 시스템 테스트

• 이 단계에서는 적절한 계획하에 모듈들을 통합하고 테스트하여 전체 시스템이 요구사항을 만족하는지 확인한다.
• 대개 여러 단계에 걸쳐 점증적인 방식으로 통합되며 계속적으로 통합 테스트를 수행한다.
• 모든 모듈들이 성공적으로 통합되어 테스트되면 최종적으로 시스템 테스트를 수행하게 된다.

6 인도와 유지보수

• 수정 유지보수: 시스템에 남아 있는 오류를 고치기 위한 작업
• 적응 유지보수: 환경의 변화에 적응하기 위해 수정 작업을 하는 것. 하드웨어나 운영체제의 변경, 다른 시스템과의 연동
• 완전 유지보수: 기능을 개선하거나 성능을 향상시키기 위한 것
• 예방 유지보수: 잠재적 결함을 찾아 수정함으로써 실제 오류로 연결되지 못하도록 하는 것

최근에는 소프트웨어 진화라는 표현이 자주 쓰인다.

7 폭포수 모델의 장단점

1. 장점
   • 순차적인 선형 모델이므로 단순하고 이해하기 쉽다
   • 각 단계가 분리되어 있어 단계별로 정형화된 접근 방법과 체계적인 문서화 작업이 가능하다
   • 각 단계별로 산출물을 체크함으로써 프로젝트 진행 상황을 명확하게 알 수 있다.
2. 단점
   • 프로젝트 초기에 모든 요구사항을 완벽하게 작성해야 하나 사실상 거의 불가능하다.
   • 변경을 수용하기에 적합한 형태가 아니다
   • 동작이 되는 시스템 버전을 프로젝트 후반부에나 볼 수 있다.
   • 대형 프로젝트에 적용하기 위해 확장되기 어렵다
   • 문서화를 위해 지나친 노력을 소모하는 경향이 있다
   • 기본적으로 생명주기를 거슬러 갈 수 없다
   • 고객의 요구를 명확히 확인해 줄 방법을 가지지 못한다
   • 위험 분석을 수행하지 않는다
   • 실수나 오류가 생기면 일정이 지연되거나 소요 자원이 증가한다
   • 각 단계의 종료를 위해 정형화된 문서를 요구하므로 모든 절차가 문서 위주로 수행된다