검수요청.png검수요청.png

폭포수 모델

위키원
175.203.80.58 (토론)님의 2023년 5월 16일 (화) 16:33 판 (설계)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)
이동: 둘러보기, 검색

폭포수 모델(Waterfall Model)이란 소프트웨어 개발 시 단계적으로 개발하는 방법론을 말한다. 분석→설계→개발(디자인→퍼블리싱→프로그래밍)→테스트→적용→안정화의 단계를 따른다. 폭포수가 거슬러 올라갈 수 없듯이, 소프트웨어 개발도 반드시 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있다는 뜻이다. 소프트웨어 개발 방법론(SDM)의 일종이다. 반대말은 애자일 개발 방법론이다.

폭포수모델 구성도

개요[편집]

폭포수 모델은 분석, 설계, 개발/구현, 시험, 운영 및 유지보수 등 전 과정을 순차적으로 접근하는 개발모델이다. 순차적으로 접근하며 단계별 검증을 진행한다. 그리고 각 단계를 종료할 때 검증 후에 다음 단계로 진행한다. 관리가 용이하며 문제점이 후반부에 발견될 수 있는 리스크를 가지고 있다.[1] 원래의 폭포수 모델은 폭포에서 내려오는 물이 아래로만 떨어지듯이 각 단계가 순차적으로 진행되며, 병행되어 진행되거나 거슬러 반복 진행되는 경우가 없다. 하지만 실제 사용되고 있는 폭포수 모델은 각 단계의 결과가 확인된 후에 다음 단계로 넘어간다. 이는 사용자 의견이 다르거나 중간 결과를 점검한 결과 전 단계의 작업에 결함이 있다면 다시 수정하도록 전 단계로 돌아가는 피드백이 있기 때문이다.[2]

특징[편집]

폭포수 모델은 SW 개발을 단계적, 순차적, 체계적으로 접근한다. 그리고 각 단계를 철저하게 완료한 뒤 다음 단계를 진행하는 순차적인 특징을 가지고 있다. 개발 방법과 관리 방법론을 연계하여 효과적인 생산성 확보 여부를 판단하며, 각 단계 종료 시 검증 후 다음 단계로 진행하는 단계별 검증을 한다. 이러한 폭포수 모델은 프로젝트 진행과정에 대해서 관리가 용이하지만 목표 시스템이 후반에 가서야 구체화 되므로 중요한 문제점이 프로젝트 후반부에 발견될 수 있다.[1]

구성[편집]

SDLC(Software Development Life Cycle)에서 많이 반복되는 구성 단계로 '계획수립->요구분석->설계->개발/구현->테스트->유지보수' 단계를 순차적으로 진행하며 각 단계 종료 시 검증 후에 다음 단계를 진행한다. 전 단계에서 결함 발견 시 피드백을 받고, 각 단계별 산출물을 명확하게 정의한다. 기술적 위험성이 낮거나 유사프로젝트 경험이 많은 경우에 사용한다.[3]

계획[편집]

타당성 검토라고도 한다. 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서를 작성한다. 고객의 요구조건, 시스템 환경 등을 고려하여 프로젝트 진행 여부를 판단하고, 진행 결정이 나면 프로젝트 전반적인 계획에 들어간다.[3] 문제점을 파악하고 해결 방안을 제시하여 투입 대비 이익을 평가한다. 조직의 전략적 목표를 충족하는지, 비용 대비 수익 효과가 큰지, 정해진 시간 안에 현재의 기술 수준으로 개발이 가능한지, 운영이나 사용하는 능력이나 다른 시스템과의 연동 가능성이 있는지를 판단해야 한다. 짧은 기간 내에 분석과 미래 예측을 해야 하기 때문에 시간적 제약과 정신적 압박감이 존재하는 단계로 문제 정의, 해결 방안, 기대 효과, 타당성, 비용, 인도 날짜 등을 포함한다.[4]

분석[편집]

대상이 되는 문제 영역과 사용자가 원하는 요구를 이해하는 단계이다. 사용자의 요구사항을 듣고 정확히 기능적, 비기능적 요구 사항을 도출한다.[3] 프로젝트에서 무엇을 개발할 것인지 결정하는 단계로 문제의 해결을 위해 시스템이 갖추어야 하는 조건과 능력을 요구사항 명세서, 계약서에 명시한다. 요구사항 명세서의 경우 발주자-개발자 간 의사소통의 수단으로 사용되며 정확성, 일관성, 완전성에 맞추어 작성해야 한다. 명세서의 구성으로는 시스템의 목적과 범위와 기능적, 비기능적 요구사항과 기타 제약 조건 등을 포함한다. 이 때 문제점을 구체적으로 기술하고 대안 법을 제시해야 한다.[4]

설계[편집]

분석 모델을 가지고 이를 세분화함으로써 구현될 수 있는 형태로 전환한다. 요구사항 명세가 전달되면 요구사항 명세에 준수하는 설계에 들어간다.[3] 요구사항을 기반으로 명확하고 조직화된 구조로 설계해야 한다. 설계의 단계는 아키텍처 설계 -> 인터페이스 설계 -> 프로그램 설계 순이며 구조적 설계 방법과 객체지향 설계 방법이 있다.[4]

개발[편집]

설계 단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트를 수행한다. 단위테스트는 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차로 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 것이다.[3] 설계 결과를 프로그램으로 작성하는 단계로 구현된 모듈이 명세서를 만족하는지 테스트해서 확인해야 한다. 작성 시 코딩 표준과 테스트 절차를 준수하며 작성해야 하며 코드의 정적 분석을 진행한다.[4]

시험[편집]

발생 가능한 실행 프로그램 오류를 발견, 수정하는 단계이다. 테스트는 모듈들을 통합시키며 진행하는 통합 테스트, 전체 시스템 동작에 대해 검증을 하는 시스템 테스트, 사용자가 현장에서 검증해보는 인수테스트가 있다.[3] 모듈과 서브시스템을 전체 시스템으로 통합시킨다. 통합 시스템의 경우 모듈들을 통합하여 점층적으로 시스템 구축을 하고, 시스템 테스트는 최종적으로 통합된 전체 시스템이 요구사항을 만족하는지 확인한다. 베타 테스트는 고객의 실제 사용 환경에서 수행한다. 제품 출시 전 릴리즈 된 베타 버전으로 가망 사용자로부터 미리 제품을 평가하는 방법이다. 이 외에 알파 테스트는 소프트웨어 개발 현장에서 수행하는 테스트로 일반 소프트웨어는 테스트 팀이 알파 테스트를 수행하고 베타 버전으로 보낸다. 주문형 소프트웨어의 경우 제품 인수 동의가 이루어질 때까지 테스트를 수행한다.[4]

운영/유지보수[편집]

시스템의 사용 중 발생하는 여러 변경사항에 대해 적응하고, 변화에 대비하는 과정이다. 소프트웨어를 사용하면서 나타나는 오류들을 수정하며, 환경변화나 고객 요구에 따른 추가 기능 개발을 진행하는 과정으로 유지보수 계약 종료 후 재계약을 하지 않았을 때와 소프트웨어가 폐기됐을 때 유지보수가 종료된다.[3] 실제 사용을 위해서 고객에게 소프트웨어를 배포해 운영한다. 운영 중에 소프트웨어의 수정 및 보완 활동을 유지보수라고 하는데 이 유지보수의 종류는 수정, 적응, 완전, 예방 유지보수가 있다. 수정 유지보수는 오류를 수정, 적응 유지보수는 환경 변화에 대응하며, 완전 유지보수는 기능을 개선하고 성능을 향상시킨다. 그리고 예방 유지보수는 미래 유지 보수성을 향상시키기 위한 활동이다.[4]

장단점[편집]

장점[편집]

  • 고전적인 방법론으로써 적용 사례가 풍부하다.
  • 전체 과정의 이해가 쉽다.
  • 현재 단계에 대한 이해가 빠르고 쉽다.
  • 문서, 산출물의 관리와 적용이 쉽다.

단점[편집]

  • 병행 작업이 안된다.
  • 피드백에 대한 반복 단계가 어렵다.
  • 테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다.
  • 고객 요구사항에 대한 상세한 반영이 어렵다.

활용[편집]

응용분야를 잘 알고 있거나, 단순한 프로젝트를 개발할 때 용이하다. 비전문가가 사용할 시스템을 개발하는 데 적합하고, 단계 종료 후에 나와야 하는 산출물에 대한 명확한 정의가 필요한 사이트 제작에 사용하기 좋고 초기에 정의한 요구사항 변경이 적은 프로그램에 적용해 사용하기 좋다. [5]

고려사항[편집]

폭포수 모델을 적용할 때 고려해야 하는 사항들이 있다. 우선, 관리가 상대적으로 쉬우나 요구사항의 변경에 대한 대응력이 떨어진다. 단계별로 개발을 진행하기 때문에 요구사항 단계가 끝이 나고 다음 단계에서 요구사항을 변경했을 때 수정이 어렵기 때문이다. 그리고 기술 위험이 낮고 유사한 프로젝트 경험이 있는 경우와 요구사항이 비교적 명확하게 정의되어 있을 때 적용하는 것이 좋다.[6]

각주[편집]

  1. 1.0 1.1 도리의 디지털라이프, 〈폭포수 모델 (Waterfall Model)〉, 《개인블로그》, 2018-11-20
  2. 푸른제비, 〈폭포수 모델 Waterfall Model〉, 《개인 블로그》, 2008-05-09
  3. 3.0 3.1 3.2 3.3 3.4 3.5 3.6 바보상자, 〈소프트웨어 공학 - 폭포수 모델(Waterfall Model)〉, 《개인블로그》, 2014-02-14
  4. 4.0 4.1 4.2 4.3 4.4 4.5 버터필드, 〈소프트웨어 개발 프로세스 모델 - 폭포수 모델(Waterfall Model)〉, 《개인 블로그》, 2020-04-18
  5. 자비스가 필요해, 〈SDLC의 고전적 모델, 폭포수모델(Waterfall Model)〉, 《개인 블로그》, 2016-09-08
  6. 보통 인간 보통인간, 〈폭포수(Waterfall) 모델〉, 《개인 블로그》, 2014-01-22

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 폭포수 모델 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.