瀑布水 모델

위키百科, 우리 모두의 百科事典.

瀑布水 모델 (waterfall model)은 順次的인 소프트웨어 開發 프로세스 (소프트웨어를 만들기 위한 프로세스)로, 開發의 흐름이 마치 瀑布水처럼 持續的으로 아래로 向하는 것처럼 보이는 데서 이름이 붙여졌다. 이 瀑布水 모델의 흐름은 소프트웨어 要求事項 分析 段階에서 始作하여, 소프트웨어 設計 , 소프트웨어 具現 , 소프트웨어 試驗 , 소프트웨어 統合 段階 等을 거쳐, 소프트웨어 維持補修 段階에까지 이른다.

最初의 "瀑布水 모델". 作業의 進展이 위로부터 아래로 瀑布水처럼 흐른다.
소프트웨어 開發 프로세스
活動과 段階
要求事項 分析   · 機能 明細
救助   · 設計
具現   · 테스팅
配置   · 維持補修
開發 模型
애자일 소프트웨어 開發   · 클린룸
DSDM   · 循次漸增的 開發   · 反復型 開發
RAD   · RUP   · 나선 模型
瀑布水 모델   · 익스트림 프로그래밍
스크럼   · V 모델   · TDD
支援 活動
構成 管理   · 文書化
品質保證   · 프로젝트 管理
使用者 經驗 設計
道具
컴파일러   · 디버거   · 프로파일러
GUI 디자이너   · 統合 開發 環境

흔히 "瀑布水" 槪念을 처음으로 使用한 글로 1970年에 윈스턴 W. 로이스 (1929?1995) [1] 의 論文이 引用되지만, 實際로 로이스는 그 論文에서 "瀑布水"라는 槪念을 使用하지는 않았다. 그리고 逆說的이게도 로이스는 그 論文에서 이 모델을 缺陷이 있는, 제대로 動作하지 않는 事例로 提示하고 있다.

모델 [ 編輯 ]

로이스가 提示한 最初의 瀑布水 모델은 다음과 같은 段階가 順次的으로 記述되어 있다.

  1. 소프트웨어 要求事項 技術
  2. 소프트웨어 設計
  3. 소프트웨어 具現 (또는 코딩)
  5. 試驗과 디버깅
  6. 設置
  7. 소프트웨어 維持補修

瀑布水 모델을 따르기 위해서는, 完全히 順次的으로 한 段階, 한 段階를 進行해 나가야 한다. 例를 들어, 가장 먼저 要求事項 技術을 進行하여 이를 確定하여야 하며, 그런 以後에 設計를 進行할 수 있다. 소프트웨어가 設計된 後, 그 設計圖(blueprint)가 具現者(또는 코더)에게 따라서 具現해야할 計劃으로 傳達된다. 따라서 設計가 完全히 完了된 後에 設計에 對한 具現이 코더에 依해 進行될 수 있는 것이다. 이 具現의 마지막 段階에 이르면, 各各의 生成된 컴포넌트를 結合하여, 새로운 機能을 실현시키고 그때까지 發生한 버그를 解決하게 된다(디버깅). ]

그러므로 瀑布水 모델은 前 段階가 遂行되어 完了되기 前에는 다음 段階로 進行할 수 없도록 制限한다. 그러나, 最初의 元來 瀑布水 모델과는 달리 프로세스 一部 또는 많은 部分이 變形된 모델들이 存在하며, 로이스의 最終 모델도 그 中 하나이다.

使用 事例 [ 編輯 ]

瀑布水 모델은 美國 國防省 (United States Department of Defense)이나 NASA 에 雇用된 大規模 소프트웨어 開發 하우스에 依해 널리 使用되었으며, 그外에 多數의 大規模 政府 프로젝트에서 使用되었다. (" 標準 瀑布水 모델 " 參照) 그러나 이를 使用하는 業體나 開發者는 굳이 純粹 瀑布水 모델과 變形 모델 사이를 區分하여 公式的으로 言及하지 않았기 때문에, 正確히 어떤 모델이 使用되었는지를 整理하는 것은 어려운 일이다.

參考로 美 國防省은 1994年 의 MIL-STD-498 과 1998年의 IEEE 12207 을 통해 瀑布水 모델의 制約 條件을 벗어났다.

關聯 論議 [ 編輯 ]

소프트웨어 開發 初期에 適切히 使用된 時間은 生命 週期(lifecycle)의 後期에 큰 經濟的 影響을 줄 수 있다. 다시 말하면, 經濟學的 觀點에서 소프트웨어 開發의 初期(要求事項 技術 또는 設計 段階)에 發見된 버그는 後期에 發見된 것에 비해 고치는 時間과 돈, 그리고 努力이 몇倍는 적게 들기 마련이다. 關聯하여 스티브 脈코넬 은 그의 著書, "Rapid Development"에서 "要求事項 上의 缺陷이 具現이나 維持補修 段階에까지 發見되지 않고 남아 있을 境遇, 이를 修正하는 費用은 要求事項 技術 時에 修正하는 것에 비해 最小 50倍에서 最大 200倍까지 드는 것"으로 豫測했다.

極端的인 例로, 萬若 프로그램 設計가 具現이 不可能한 것일 境遇, 이것이 設計 段階에서 고쳐지기는 쉬우나 몇달 뒤 具現과 統合이 進行 中에 發見되면, 이를 고치는 것은 不可能하고 그때까지 開發된 모든 코드와 컴포넌트를 버릴 수밖에 없다. 그리고 이러한 論議가 Big Design Up Front (BDUF)와 瀑布水 모델의 背景이 되는 中心的인 아이디어이다. 그런 理由로, 瀑布水 모델을 따르는 이들은 소프트웨어 開發時 前段階가 100% 完了되고 모두 正確하다는 것을 確認한 後에야 다음 段階로 履行하고자 한다. 소프트웨어 要求事項은 設計가 始作되기 前에 돌과 같이 단단하게 確定되어야 하고, (그렇지 않은 境遇, 正確하지 않은 要求事項에 基盤한 設計는 버려질 수 있다.) 소프트웨어 設計는 開發者들이 具現을 始作하기 前에 完璧해야만 한다. (그렇지 않을 境遇 亦是 具現에 쓰이는 時間과 費用은 浪費된다. )

또 다른 論議는 瀑布水 모델에 있어서의 文書化에 對한 强調이다. 瀑布水 모델에서는 要求事項 技術 및 設計, 그리고 소스 코드에 있어서의 正確하고 完璧한 文書化를 强調한다. 充分히 設計되지 않고, 文書化되지 않은 소프트웨어 프로젝트일수록, 팀 構成員이 떠날 境遇에 많은 知識이 사라지고 프로젝트 持續에 더 큰 어려움이 따른다는 것이 그 論旨이다. 그러나 反對로 完璧하게 動作하는 設計 文書가 存在할 境遇, 새로운 팀員이나 甚至於 完全히 새로 構成된 팀에게도 프로젝트를 移轉하여 文書 基盤으로 遂行하는 것이 可能하다.

위 論議에 더하여, 瀑布水 모델은 그 簡潔한 接近 方式으로 인해 選好되기도 한다. 瀑布水 모델은 소프트웨어 開發에 構造化된 接近 方法을 提供하고, 쉽게 理解할 수 있고 說明이 可能한 各各의 區分된 段階를 順次的으로 進行하게하며, 그런 理由로 프로세스 相議 마일스톤을 定하는 것도 相對的으로 쉽기 때문이다. 아마도 그것이 소프트웨어 工學 敎科書나 敎育課程에서 瀑布水 모델을 프로세스의 代表的인 例로 삼는 理由일 것이다.

反對로 瀑布水 모델의 限界를 指摘하는 이들도 存在한다. 그들은 瀑布水 모델이 安定的인 要求事項 基盤을 가진 프로젝트나 모든 소프트웨어 開發의 問題領域을 完璧히 豫測할 수 있는 設計者를 가진 프로젝트에만 맞을 수 있다고 指摘한다. 그들은 또한 구현자들이 設計를 完璧하고 正確하게 具現하지 않을 境遇, 시스템 統合 段階를 수월하게 進行할 수 없음도 指摘한다.

瀑布水 모델에 對한 批判 [ 編輯 ]

瀑布水 모델에 對한 反對意見을 가진 이들도 많다. 主로 實際 實行에 있어 不可能한 모델이라는 點이 그 主要 論旨인데, 意味있는 規模의 프로젝트에서는 다음 段階에 對한 理解나 經驗 없이, 各 段階를 完璧히 마무리한 後 다음 段階를 進行하는 것이 不可能하다는 것이다. 例를 들어 顧客들은 動作하는 프로토타입을 보지 않고는 正確히 自身들이 무엇을 願하는지를 要求事項으로 定하지 못할 수 있다. 또 顧客들은 定해진 要求事項을 頻繁하게 修正해달라고 要求하는 境遇도 많으며, 그럴 境遇 設計者나 具現者가 이를 統制할 수 있는 方法은 많지 않다. 萬若 顧客이 設計가 完了된 以後에 要求事項 變更을 要求했다면, 設計는 새로운 要求事項을 위해 變更되어야 하고 그때까지 投入된 많은 努力은 無爲로 돌아가게 된다.

또한 設計者들은 設計 時에 向後 具現 作業의 難易度를 豫測하기 어렵다. 卽, 具現 段階에 이르러서야 特定 部分의 設計를 具現하는 것이 不可能하거나 매우 어려움이 明白해지는 境遇가 있을 수 있다. 그럴 境遇, 旣存 設計를 維持하여 어려운 具現을 進行하는 것보다 再設計를 擇하는 것이 向後 發生할 수 있는 더 큰 問題 狀況을 防止하는 데 나은 選擇이다. 윈스턴 W. 로이스 博士 亦是, 瀑布水 모델에 對해 처음으로 說明한 "大規模 소프트웨어 시스템 開發 管理(Managing the Development of Large Software Systems)" [2] 라는 글에서, 위 批判과 類似한 "失敗를 부를 수 있는 危險한" 事例들을 提示한 바 있다.

스티브 脈코넬 亦是 그의 著書, Code Complete (瀑布水 모델의 廣範圍한 使用을 批判하고 있는 冊)에서 設計 上의 " 못된 問題 (wicked problem)" ? 設計나 具現을 끝내기 前에는 完全히 알 수 없는 要求事項이나 制約條件의 問題 -에 對해 論한 바 있다. 이런 問題가 의미하는 바는 소프트웨어 開發에서 하나의 段階만을 完成하는 것은 不可能하며, 따라서 瀑布水 모델을 使用하여 다음 段階로 履行하는 것이 不可能하다는 것이다.

또한 데이빗 派나스 (David Parnas)는 그의 글, "合理的인 設計 프로세스: 어떻게 그리고 왜 속이게 되는가 (A Rational Design Process: How and Why to Fake It)"에서 아래와 같이 쓴 바 있다. [3]

“[시스템의] 細部 事項 中 많은 部分은 우리가 [시스템의] 具現을 進行할 때라야 비로소 우리 눈에 보이기 始作한다. 그리고 그렇게 알게 된 것 中 一部는 우리의 旣存 設計를 無效로 만들고, 다시 前 段階로 돌아갈 수밖에 없게 만든다. ”

瀑布水 모델의 背景이 되는 아이디어는 "두 番 檢討해보고, 한番 實行하라(measure twice; cut once)."는 單純한 格言이지만, 그에 反對하는 이들은, 愼重히 檢討하는 渦中에도 持續的으로 소프트웨어 要求事項이나 問題 自體의 樣相이 變化하기 때문에, 이 아이디어가 非現實的이라고 말한다.

修正 모델들 [ 編輯 ]

純粹 瀑布水 모델에 提起된 問題들과 批判에 對한 反應으로, 多數의 修正 瀑布水 모델이 紹介되었다. 이 修正 모델로 純粹 瀑布水 모델의 問題點을 一部 또는 全部 解決할 수 있을 것이다. 參考로, 스티브 脈코넬의 冊, Rapid Developement: 프로젝트 快速 開發 戰略 中 "生命週期 計劃(lifecycle planning)" 章에서 다양한 修正 瀑布水 모델에 對해 다루고 있다.

사시미(Sashimi) 모델 [ 編輯 ]

사시미 모델은 (日本의 飮食인 사시미가 生鮮膾를 겹쳐 내놓듯이, 이 修正 모델은 各 段階가 겹쳐서 進行된다는 意味에서 이러한 이름이 붙었다.) 처음으로 피터 디그레이스 (Peter DeGrace)에 依해 考案되어 紹介되었다. 때로 이 모델은 "겹친 段階를 가진 瀑布水 모델" 또는 "피드백 있는 瀑布水 모델"이라고 引用되곤 한다. 사시미 모델에서 各 段階들이 서로 겹쳐 있기 때문에, 問題點에 對한 情報는 그 前段階에서 把握될 수 있다. 例를 들어, 사시미 모델에서 設計와 具現 段階는 겹쳐져서 進行되기 때문에, 具現 上의 問題는 設計가 完了되기 以前에 發見된다. 사시미 모델의 이런 點은 瀑布水 모델의 限界點을 緩和하는 데 도움을 준다.

各州 [ 編輯 ]

  1. ↑ Wasserfallmodell > Entstehungskontext , Markus Rerych, Institut fur Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28 , 2007 .
  2. ↑ "Managing the Development of Large Software Systems" Archived 2016年 3月 15日 - 웨이백 머신 , Dr. Winston W. Royce (PDF file)
  3. ↑ "A Rational Design Process: How and Why to Fake It" Archived 2008年 9月 20日 - 웨이백 머신 , 데이빗 派나스 (PDF 파일)

같이 보기 [ 編輯 ]

더 읽을 距離 [ 編輯 ]

外部 링크 [ 編輯 ]

위키미디어 共用 에 關聯된
미디어 分類가 있습니다.
元本 住所 " https://ko.wikipedia.org/w/index.php?title=瀑布水_모델&oldid=36888532 "