워터폴 모델

Waterfall model

워터폴 모델은 프로젝트 활동을 선형 순차 단계로 분할하는 것으로, 각 단계는 이전 단계의 성과물에 따라 달라지며 [1]태스크의 전문화에 대응합니다.이 접근방식은 엔지니어링 설계의 특정 영역에 대해 일반적입니다.소프트웨어 [1]개발에서는, 개념, 개시, 분석, 설계, 건설, 테스트, 도입, [2]및 유지보수의 각 국면을 거쳐, 거의 한 방향(폭포와 같은 「하향」)으로 진행되기 때문에, 반복성과 유연성이 낮은 어프로치에 속하는 경향이 있습니다.

폭포형 개발 모델은 [citation needed]제조 및 건설업에서 비롯되었으며, 그 곳에서 고도로 구조화된 물리적 환경은 설계 변경 [citation needed]비용이 개발 프로세스에서 훨씬 더 빨리 증가했음을 의미합니다.소프트웨어 개발을 위해 처음 채택되었을 때, 지식 기반 크리에이티브 [3][better source needed]작업에 대한 공인된 대안이 없었습니다.

역사

소프트웨어 엔지니어링에서 이러한 단계의 사용을 설명하는 최초의 알려진 프레젠테이션은 Felix Torres와 Herbert D에 의해 개최되었습니다.1956년 [4]6월[citation needed] 29일 디지털 컴퓨터의 고급 프로그래밍 방법에 관한 심포지엄에서 베닝턴.이 프레젠테이션은 SAGE용 소프트웨어 개발에 관한 것이었습니다.1983년에 이 논문은 Benington에 의해 서문과 함께 재게재되었으며, 이 과정은 실제로 엄격한 하향식 방식으로 수행된 것이 아니라 [3]프로토타입에 의존한 것이라고 지적했다.

비록 "waterfall"이라는 용어는 논문에서 사용되지 않지만, 후에 "waterfall model"로 알려진 프로세스의 첫 번째 공식 상세도는 종종 Winston W의 1970년 기사로 인용된다[citation needed]. 로이스.[5][6][7] 그러나 그는 또한 테스트가 "위험하고 [5]실패를 초래한다"고 표현한 과정의 마지막에만 이루어진다는 사실에서 기인하는 큰 결함이 있다고 느꼈다.그의 논문의 나머지 부분에서는 변경되지 않은 폭포 [5]접근과 관련된 "개발 위험의 대부분을 제거하기 위해" 필요하다고 느낀 다섯 가지 단계를 소개했습니다.

로이스의 5개의 추가 단계(다양한 개발 단계에서 완전한 문서를 작성하는 것 포함)는 결코 주류를 이루지 못했지만, 그가 결함이 있다고 생각하는 프로세스에 대한 그의 도표는 "물 건너가는"[8][better source needed] 접근법을 설명할 때 출발점이 되었다.

"waterfall"이라는 용어가 가장 먼저 사용된 것은 벨과 [9][better source needed]테이어가 1976년에 발표한 논문일 것이다.

1985년 미국 국방부는 DOD-STD-2167A에서[citation needed] 소프트웨어 개발 도급업체와 협력하기 위한 표준인 이 접근방식을 포착했습니다.도급업체는 다음 6단계를 포함하는 소프트웨어 개발 주기를 구현해야 합니다.소프트웨어 요건 분석, 예비 설계, 상세 설계, 코딩 및 유닛 테스트, 통합 및 테스트"[10]를 제공합니다.

모델

Royce의 원래 폭포수[citation needed] 모델에서는 다음 단계를 순서대로 따릅니다.

  1. 시스템 및 소프트웨어 요건: 제품 요건 문서에 기재되어 있습니다.
  2. 분석: 모델, 스키마 및 비즈니스 규칙 생성
  3. 설계: 소프트웨어 아키텍처의 결과
  4. 코딩: 소프트웨어 개발, 검증 및 통합
  5. 테스트: 결함의 체계적인 검출 및 디버깅
  6. 운용: 시스템 전체의 설치, 이행, 지원 및 유지보수

따라서 폭포 모델은 이전 단계를 검토하고 검증할 때만 단계로 이동해야 한다는 입장을 고수하고 있다.

그러나 다양한 변형된 폭포수 모델(Royce의 최종 모델 포함)은 이 [5]과정에서 약간 또는 크게 변형될 수 있습니다.이러한 변화에는 하류에서 결함이 발견된 후 이전 사이클로 돌아가거나 하류 단계가 불충분하다고 판단될 경우 설계 단계로 되돌아가는 것이 포함됩니다.

뒷받침하는 인수

소프트웨어 실가동 사이클의 초기에 시간을 들이면 이후의 단계에서 비용을 절감할 수 있습니다.예를 들어 초기 단계에서 발견된 문제(요건 사양 등)는 나중에 프로세스에서 발견된 동일한 오류(50~[11]200배)보다 수정 비용이 저렴합니다.

일반적으로 워터폴 방법론에서는 첫 2단계에 20~40%, 코딩에 30~40%의 시간을 투자하고 나머지는 테스트와 구현에 전념하는 프로젝트 스케줄이 생깁니다.실제 프로젝트 조직은 고도로 구성되어야 합니다.대부분의 중대형 프로젝트에는 프로젝트의 [12][failed verification]모든 프로세스를 규제하는 일련의 절차와 제어가 포함되어 있습니다.

워터폴 모델의 또 다른 주장은 소스코드뿐만 아니라 문서([citation needed]요건 문서 및 설계 문서 등)에 중점을 둔다는 것입니다.충분히 설계 및 문서화되어 있지 않은 방법론에서는 프로젝트 완료 전에 팀원이 자리를 비우면 지식이 상실되고 프로젝트에서는 손실로부터 회복하기 어려울 수 있습니다.(빅 디자인 프론트 및 워터폴 모델의 목적과 같이) 완전히 작동하는 설계 문서가 있는 경우, 새로운 팀원 또는 완전히 새로운 팀원들도 문서를 [13]읽음으로써 자신을 이해할 수 있어야 합니다.

워터폴 모델은 구조화된 접근방식을 제공합니다.모델 자체는 개별적이고 이해하기 쉬우며 설명 가능한 단계를 선형적으로 진행하기 때문에 이해하기 쉬우며 개발 프로세스에서 쉽게 식별할 수 있는 이정표를 제공합니다.많은 소프트웨어 엔지니어링 교재 및 [14]코스에서 폭포 모델이 개발 모델의 시작 예시로 사용되는 것은 아마도 이러한 이유 때문일 것입니다.

비판

고객은 실제 가동 중인 소프트웨어를 보기 전에는 요구 사항이 무엇인지 정확히 알지 못할 수 있으며, 따라서 요구 사항이 변경되어 재설계, 재개발 및 재테스트로 이어지며 [15]비용이 증가합니다.

설계자는 새로운 소프트웨어 제품 또는 기능을 설계할 때 미래의 어려움을 인식하지 못할 수 있습니다.이 경우 새로 발견된 제약사항, 요건 [16]또는 문제를 고려하지 않는 설계를 계속하기보다는 설계를 수정하는 것이 좋습니다.

조직은 시스템 분석가를 고용하여 기존 수동 시스템을 조사하고 시스템 분석자의 역할과 대체 방법을 분석함으로써 고객의 구체적인 요구사항 부족에 대처하려고 할 수 있습니다.그러나 실제로는 시스템 분석과 [17]프로그래밍을 엄격하게 분리하는 것이 어렵습니다.이는 중요하지 않은 시스템을 구현하면 시스템 분석가가 고려하지 않은 문제와 엣지 케이스가 노출될 수밖에 없기 때문입니다.

순수 폭포 모델에 대한 인식된 문제에 대응하여 "사시미(위상이 겹치는 폭포)", "하위 프로젝트가 있는 폭포",[11] "위험 감소가 있는 폭포"와 같은 수정된 폭포 모델이 도입되었습니다.

미국 국방부와 같은 일부 조직은 1994년에 발표된 MIL-STD-498을 시작으로 폭포형 방법론에 대해 분명한 선호도를 가지고 있으며, 이는 진화적 획득과 반복적 및 증분적 [18]개발을 장려한다.

신속한 소프트웨어 개발의 지지자들은 폭포수 모델이 소프트웨어 개발에 비효율적인 프로세스라고 주장하는 반면, 일부 회의론자들은 폭포수 모델이 순전히 대체 [19]개발 방법론을 시장에 내놓기 위해 사용되는 잘못된 주장이라고 주장한다.

Rational Unified Process(RUP) 단계는 프로젝트를 정상 궤도에 올려놓기 위한 마일스톤의 프로그램적 필요성을 인정하지만 단계 내에서 (특히 부문 내에서) 반복을 장려합니다.RUP 단계는 흔히 "물방울 유사"[citation needed]라고 합니다.

변경된 폭포 모델

"순수한" 폭포 모델의 인식된 문제에 대응하여, 많은 수정된 폭포 모델이 도입되었습니다.이러한 모델은 "순수한" 폭포 모델에 대한 비판의 일부 또는 전부를 해결할 수 있습니다.

여기에는 Steve McConnell이 "수정된 폭포"[11]라고 부르는 Rapid Development 모델(Peter DeGrace의 "sashimi 모델"(중복되는 단계가 있는 폭포), 서브프로젝트, 위험 감소가 포함된 폭포)이 포함됩니다."증분 폭포수 모델"과 같은 다른 소프트웨어 개발 모델 조합도 존재합니다.[20]

로이스의 최종 모델

로이스 최종 모델

윈스턴 W. Royce의 최종 모델(처음 '워터폴 모델'에 대한 의도된 개선)은 피드백이 코드 테스트에서 설계(설계의 결함이 드러나지 않은 코드 테스트), 설계에서 요건 사양(설계의 문제로 인해 충돌 또는 다른 문제를 제거할 필요가 있을 수 있음)으로 이어질 수 있음을 보여 줍니다.e불만족/불만족 요건).같은 논문에서 로이스는 대량의 문서화를 주창하고, 가능한 한 두 번(소프트웨어 프로젝트 관리의 영향력 있는 책인 신화적 인월을 쓴 것으로 유명한 Fred Brooks와 같은 감정)을 실시해, 가능한 한 많은 고객을 끌어들였습니다(sentim).ent는 익스트림 프로그래밍과 유사합니다).

최종 모델에 대한 Royce 메모는 다음과 같습니다.

  1. 분석 및 코딩 시작 전 프로그램 설계 완료
  2. 문서는 최신 상태로 완전해야 합니다.
  3. 가능하다면 그 일을 두 번 해라.
  4. 테스트를 계획, 제어 및 감시해야 합니다.
  5. 고객을 끌어들이다

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). "The Waterfall Model in Large-Scale Development". Product-Focused Software Process Improvement. Lecture Notes in Business Information Processing. Berlin, Heidelberg: Springer: 386–400. doi:10.1007/978-3-642-02152-7_29. ISBN 978-3-642-02152-7.
  2. ^ "The Traditional Waterfall Approach". www.umsl.edu. Retrieved 2022-02-23.
  3. ^ a b Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" (PDF). IEEE Annals of the History of Computing. IEEE Educational Activities Department. 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. S2CID 8632276. Retrieved 2011-03-21. 2011년 7월 18일 Wayback Machine에서 아카이브 완료
  4. ^ United States, Navy Mathematical Computing Advisory Panel (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738
  5. ^ a b c d Royce, Winston (1970), "Managing the Development of Large Software Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
  6. ^ "Waterfall". Bremen University - Mathematics and Computer Science.
  7. ^ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (eds.). "Historical Roots of Agile Methods: Where Did "Agile Thinking" Come From?". Agile Processes in Software Engineering and Extreme Programming. Lecture Notes in Business Information Processing. Berlin, Heidelberg: Springer: 94–103. doi:10.1007/978-3-540-68255-4_10. ISBN 978-3-540-68255-4.
  8. ^ 콘래드 와이저트, 워터폴 방법론: 그런 건 없어!
  9. ^ 벨, 토마스 E., T.A.테이어.소프트웨어 요건: 그들이 정말 문제가 되나요?제2회 소프트웨어 엔지니어링 국제회의의 진행.IEEE Computer Society Press, 1976.
  10. ^ "Military Standard Defense System Software Development" (PDF).
  11. ^ a b c McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
  12. ^ "Waterfall Software Development Model". 5 February 2014. Retrieved 11 August 2014.
  13. ^ Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF). Retrieved 2012-11-13.
  14. ^ Hughey, Douglas (2009). "Comparing Traditional Systems Analysis and Design with Agile Methodologies". University of Missouri – St. Louis. Retrieved 11 August 2014.
  15. ^ Parnas, David L.; Clements, Paul C. (1986). "A rational design process: How and why to fake it" (PDF). IEEE Transactions on Software Engineering (2): 251–257. doi:10.1109/TSE.1986.6312940. S2CID 5838439. Retrieved 2011-03-21.
  16. ^ McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
  17. ^ Ensmenger, Nathan (2010). The Computer Boys Take Over. p. 42. ISBN 978-0-262-05093-7.
  18. ^ Larman, Craig; Basili, Victir (2003). "Iterative and Incremental Development: A Brief History". IEEE Computer (June ed.). 36 (6): 47–56. doi:10.1109/MC.2003.1204375. S2CID 9240477.
  19. ^ 워터폴 시스템 개발 방법론... 정말?데이비드 디셰이브의 2012년작.2014년 7월 2일 Wayback Machine에서 아카이브 완료
  20. ^ "Methodology:design methods".

외부 링크

Wikimedia Commons에는 워터폴 모델과 관련된 미디어가 있습니다.