瀑布模型 RUP模型

一本正經(jīng)地胡鬧 2019-04-14

展開全文

RUP模型

理解

如果認為這個解釋難以理解，可以這樣想：

我們開發(fā)一個產(chǎn)品，如果不太復(fù)雜，會采用瀑布模型，簡單的說就是先定義需求，然后構(gòu)建框架，然后寫代碼，然后測試，最后發(fā)布一個產(chǎn)品。

這樣，幾個月過去了，直到最后一天發(fā)布時，大家才能見到一個產(chǎn)品。

這樣的方式有明顯的缺點，假如我們對用戶的需求判斷的不是很準確時——這是很常見的問題，一點也不少見——你工作了幾個月甚至是幾年，當你把產(chǎn)品拿給客戶看時，客戶往往會大吃一驚，這就是我要的東西嗎？

方法

迭代的方式就有所不同，假如這個產(chǎn)品要求6個月交貨，我在第一個月就會拿出一個產(chǎn)品來，當然，這個產(chǎn)品會很不完善，會有很多功能還沒有添加進去，bug很多，還不穩(wěn)定，但客戶看了以后，會提出更詳細的修改意見，這樣，你就知道自己距離客戶的需求有多遠，我回家以后，再花一個月，在上個月所作的需求分析、框架設(shè)計、代碼、測試等等的基礎(chǔ)上，進一步改進，又拿出一個更完善的產(chǎn)品來，給客戶看，讓他們提意見。

就這樣，我的產(chǎn)品在功能上、質(zhì)量上都能夠逐漸逼近客戶的要求，不會出現(xiàn)我花了大量心血后，直到最后發(fā)布之時才發(fā)現(xiàn)根本不是客戶要的東西的情況。

優(yōu)勢

這樣的方法很不錯，但他也有自己的缺陷，那就是周期長、成本很高。在應(yīng)付大項目、高風(fēng)險項目——就比如是航天飛機的控制系統(tǒng)時，迭代的成本比項目失敗的風(fēng)險成本低得多，用這種方式明顯有優(yōu)勢。

如果你是給自己的單位開發(fā)一個小MIS，自己也比較清楚需求，工期上也不過花上個把月的時間，用迭代就有點殺雞用了牛刀，那還是瀑布模型更管用，即使是做得不對，頂多再花一個月重來，沒什么了不起。

基本算法

有些國外的教材，如《C++ Primer》第四版的中文版，會把iterative翻譯成迭代。

在java中Iterative 僅用于遍歷集合，本身并不提供盛裝對象的能力。如果需要創(chuàng)建Iterative對象，則必須有一個被迭代的集合。沒有集合的Iterative仿佛無本之木，沒有存在的價值。
　　
　　iterative是反復(fù)的意思，所以，有時候，迭代也會指循環(huán)執(zhí)行，反復(fù)執(zhí)行的意思。

利用迭代算法解決問題，需要做好以下三個方面的工作：