畢業(yè)設計（論文）基于MP、RUP的軟件過程研究

1、摘摘 要要隨著計算機的應用和普及，計算機的性能逐年增強，用戶對運行于計算機和因特網(wǎng)上的軟件的功能和性能的渴望也隨之增加，用戶希望更好更復雜更快的軟件來滿足他們的需要；與此同時，市場的激烈競爭迫使現(xiàn)代軟件企業(yè)必須更快地生產(chǎn)出用戶需要的復雜軟件。這樣導致了軟件危機的出現(xiàn)。面對軟件危機 rational 公司推出的 rup 軟件開發(fā)過程和微軟公司推出的 mp 軟件開發(fā)過程在軟件開發(fā)方面都取得了很大的成功。然而 mp、rup 方法的提出并未真正的解決軟件危機，同時人們希望通過追求尋找解決軟件危機的最佳方法。針對現(xiàn)代軟件產(chǎn)業(yè)所處的困境，鑒于現(xiàn)有的軟件工程領(lǐng)域的軟件生命周期模型在解決軟件開發(fā)問題方面存在的

2、局限性，本文提出了 mrup 軟件開發(fā)過程，mrup 過程是基于對 mp、rup 的研究，并針對其中的一些局限提出的一種新的軟件過程。關(guān)鍵字關(guān)鍵字：微軟過程；rational 統(tǒng)一過程；mrup 過程；研究目 錄第一章 緒論.31.1 研究背景.31.2 研究意義和目的.41.3 研究內(nèi)容.6第二章、mp 方法的介紹 .62.1 微軟過程概述.62.2 生命周期.72.3 人員.72.4 方法.72.5 產(chǎn)品.92.6 四要素之間的關(guān)系.92.7 本章小結(jié).9第三章、rup 的介紹 .103.1rational 統(tǒng)一過程概述.103.2 rup 的過程結(jié)構(gòu).113.3 rup 的動態(tài)結(jié)構(gòu).11

3、3.4 rup 的靜態(tài)結(jié)構(gòu).153.5 本章小結(jié).15第四章 mrup 軟件過程模式 .164.1mrup 的概述.164.2mrup 過程模式的生命周期及相關(guān)錯誤的規(guī)避.164.3mrup 過程模式的人員.164.4mrup 過程模式方法.174.5mrup 過程模式的產(chǎn)品.184.6 mrup 過程模式的生命周期、人員、方法與產(chǎn)品四要素間的關(guān)系 .184.7 本章小結(jié).18第五章 總結(jié)與展望.18總結(jié).18展望.19致 謝.19參考文獻.19第一章 緒論1.1 研究背景1946 年，世界上第一臺電子計算機誕生在美國賓夕法尼亞大學的摩爾學院，由此拉開了計算機軟件的發(fā)展史。從宏觀角度而言，計算

4、機軟件發(fā)展主要經(jīng)歷了以下三個階段。（1）第一階段程序設計階段20 世紀 60 年代以前還沒有軟件開發(fā)的說法，那時只有程序設計的概念，最多在寫出程序后配有程序結(jié)構(gòu)說明各使用說明。經(jīng)典的程序設計方法為“程序設計=數(shù)據(jù)結(jié)構(gòu)+算法” 。（2）第二階段軟件工程階段20 世紀 70 年代以來，人們認識到軟件的工作不能僅限于編寫程序，軟件開發(fā)工作在程序編寫之前和之后還有很多重要的工作不能忽略，例如需求分析、測試、維護等等。在總結(jié)“軟件危機”教訓后，人們認識到并建立軟件工程的思想。軟件工程摒棄了認為只有充滿編程技巧的程序才能高水平地發(fā)揮個人才能的觀念，強調(diào)程序的可讀性、可理解性、可測試性和易修改性等工程化的原

5、則。（3）第三階段軟件過程階段從 20 世紀 90 年代開始，人們更加強軟件開發(fā)的效率、軟件的質(zhì)量以及軟件開發(fā)相關(guān)的管理工作，建立了“軟件過程”的概念。軟件過程不僅包括軟件開發(fā)過程，還包括了支持性、管理性過程。到目前為止，人們對軟件工程的研究主要是對軟件生命周期模型的研究。典型的生命周期模型包括瀑布模型、演化模型、螺旋模型、噴泉模型等。（1）瀑布模型瀑布模型規(guī)定了軟件生命周期各階段的不同活動，包括定義階段的項目計劃和需求分析，開發(fā)階段的設計、編碼和測試，維護階段的運行維護。這些活動自上而下，相互銜接，呈線性圖狀，如同瀑布流水，逐級下落。但此模型適用于用戶需求明確、穩(wěn)定的軟件項目。（2）演化模型

6、演化模型包括兩大步驟：第一步進行試驗開發(fā)，得出產(chǎn)品“原型” ，其目標在于弄清軟件需求并探索其可行性；第二步在原型基礎(chǔ)上開發(fā)出較為滿意的軟件產(chǎn)品。因此演化模型又稱為原型模型。演化模型減少了軟件因需求不明確給開發(fā)工作帶來的風險。（3）螺旋模型螺旋模型沿螺線旋轉(zhuǎn)，每旋轉(zhuǎn)一圈都歷經(jīng)笛卡兒坐標系中四個象限的四個方面活動制訂計劃、風險分析、實施工程及客戶評估。螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)一個更為完善的新的軟件版本。采用的是一種自上而下的工作方式。螺旋模型將瀑布模型和演化模型進行結(jié)合，同時加入了這兩種模型中都忽略的風險分析，可應用于指導客戶需求不太穩(wěn)定的軟件開發(fā)以及大型軟件開發(fā)中。（4）噴泉模型相對于螺旋模

7、型，噴泉模型引入了“面向?qū)ο蟮姆治鲈O計方法” 。此模型由于各階段均采用了“對象”這一統(tǒng)一范式，整個過程看起來像噴泉從噴出到落下再噴出的周而復始過程產(chǎn)生的光滑水柱，屬自底向上的工作方式。相對螺旋模型而言，噴泉模型除具有模型的“迭代演化”特點外，還具有軟件過程各階段的無縫銜接性，并且對軟件復用和軟件生命周期內(nèi)多項開發(fā)活動的并行與集成提供了支持。這四種模型均對軟件過程中各過程階段的活動密切關(guān)注，而對過程活動的執(zhí)行者及分工、過程中使用的方法和工具、過程中各階段的目標等方面的論及則很少甚至沒有。因而，用于指導軟件開發(fā)實踐時，表現(xiàn)出較差的可操作性。1.2 研究意義和目的軟件生命周期模型未能改變現(xiàn)代軟件產(chǎn)業(yè)

8、整體處于困境的現(xiàn)狀，且不同的軟件開發(fā)項目在不同的方面有著不足和缺陷，并且不幸的是，有太多的項目最終失敗了，但是我們可以從這項目中找出一些共同的癥狀：對于最終用戶的需求理解不夠準確。對需求的變更束手無策。脆弱的架構(gòu)。軟件質(zhì)量低劣。測試的不充分導致對項目的缺陷發(fā)現(xiàn)比較晚。軟件性能令人無法接受。拙劣的進度計劃和評估。缺乏資源。不具備項目管理方法。缺少管理層的支持。一個不可靠的構(gòu)造和發(fā)布過程。盡管不同的項目以不同的方式失敗，但是似乎大多數(shù)的失敗是由于以下幾點根本原因綜合造成的：特別的需求管理。模糊和不精確的交流。程序模塊互不兼容，及不易擴展。過度復雜。未檢測出需求、設計和實現(xiàn)之間的不一致性。測試不足。

9、對項目狀況的評估過于樂觀。未解決存在的風險。對變化無法掌控。為了解決上面的軟件問題。它需要一個過程來集成軟件的許多方面，它需要一個通用的方法，該方法能：（1）提供應如何對整個開發(fā)團隊的開發(fā)活動進行組織指導。（2）綜合指導單個開發(fā)人員和開發(fā)團隊。（3）規(guī)定開發(fā)成果是什么。（4）提供監(jiān)控和衡量一個項目中的產(chǎn)品和活動的標準。一個定義良好且管理良好的過程是區(qū)別成效卓著的項目和不成功項目之間的重要指標。 “mrup 開發(fā)過程”正是我們在軟件開發(fā)上面臨的難題的解決之道?！癿rup 開發(fā)過程”是在 mp 與 rup 的基礎(chǔ)上對軟件開發(fā)過程的一種研究，利用此方法對提高一個軟件企業(yè)的過程能力，及時且高質(zhì)的完成軟

10、件開發(fā)，進而提高企業(yè)的綜合能力都有深遠的意義。1.3 研究內(nèi)容本文的研究內(nèi)容主要包括以下幾個部分：介紹 mp 方法理論，并對其中的一些優(yōu)缺點進行闡述。學習和研究 rup 過程，提出了 rup 方法的優(yōu)缺點?；?mp、rup 提出了 mrup 方法，并且依次從生命周期、人員、方法、產(chǎn)品等方面對其進行了描述。第二章、mp 方法的介紹2.1 微軟過程概述微軟公司是世界上最大的、也是最成功的軟件公司之一，其產(chǎn)品涵蓋多個領(lǐng)域。但微軟公司并未通過 cmm 認證，也并未宣稱自己使用過 rup 和其它過程。微軟公司有自己的軟件開發(fā)過程，且其過程被幾十年實踐證實是非常行之有效的。到底微軟過程是一個怎么樣的過程

11、呢？微軟解決方案框架（microsoft solution framework , msf ）回答了以上問題。msf 是微軟顧問咨詢部于 1994 年根據(jù)微軟公司成功的產(chǎn)品開發(fā)經(jīng)驗總結(jié)、設計而成的框架體系，該設計該框架體系的目的是幫助企業(yè)提升利用 it 技術(shù)解決商務問題的能力。經(jīng)過不斷的改進和發(fā)展，微軟將公司內(nèi)部的產(chǎn)品開發(fā)人員、顧問咨詢?nèi)藛T以及微軟公司全球的客戶和合作伙伴在項目設計。開發(fā)各管理方面經(jīng)過實踐檢驗的、可重復、可借鑒的成功經(jīng)驗都集成到 msf 之中，從而為不同規(guī)模的組織結(jié)構(gòu)和不同類型的 it 項目提供從項目組織規(guī)劃和產(chǎn)品發(fā)布管理的全方位指導和幫助，是一套高效、靈活、可擴展的軟件開發(fā)管

12、理體系。msf 是一個框架結(jié)構(gòu)的經(jīng)驗知識庫，它包括以下方面的內(nèi)容。企業(yè)結(jié)構(gòu)設計方案。項目開發(fā)準則。應用程序模型。企業(yè)信息基礎(chǔ)設施的實施方法。其中項目開發(fā)準則中的過程模型和組織模型分別是從軟件過程中的過程、人員及組織、方法、產(chǎn)品等不同方面闡述了 msf 的一些經(jīng)驗，而這些方面實質(zhì)構(gòu)成了一套軟件過程模式，即微軟過程（microsoft process, mp）模式。2.2 生命周期微軟過程的每一個生命周期發(fā)布一個遞進的軟件版本，各生命周期持續(xù)、快速地循環(huán)。每個生命周期分為五個階段，分別是：構(gòu)想階段、計劃階段、開發(fā)階段、穩(wěn)定階段和發(fā)布階段。且分別結(jié)束于前景和范圍得到認可、項目計劃得到認可、項目范圍內(nèi)

13、的所有產(chǎn)品特性開發(fā)完成、可發(fā)布版本準備就緒和產(chǎn)品發(fā)布完成這五個主要的里程碑。這五個階段均涉及產(chǎn)品管理、程序管理、開發(fā)、測試、發(fā)布各角色及其活動，并且在每個階段之間都設立了緩沖時間。2.3 人員微軟過程根據(jù)項目組中的所有職能將人員劃分六種角色，分別是產(chǎn)品管理角色、程序管理角色、開發(fā)角色、測試角色發(fā)布管理角色。由產(chǎn)品經(jīng)理、程序經(jīng)理、開發(fā)工程師、測試工程師、用戶體驗人員和發(fā)布管理人員擔任。項目組中雖然多個角色可合并由一個個體擔任，但項目組內(nèi)的開發(fā)人員不兼任其他角色，也不會讓兩個有明顯利益沖突或制約關(guān)系的職能角色合并。且這六種角色中他們的關(guān)系是對等的。在人員管理上，要求所有的成員都參與設計，共同決策，

14、共同管理。讓大家都有明確的目標，闡述產(chǎn)品的前景，讓所有成員都有了解產(chǎn)品前景，并對其有清晰的認識和明確的認同，使每一位成員能以自己為產(chǎn)品的美好前景貢獻力量而感到自豪。把每個角色的人員劃分成多個小型的、多元化的項目組，每個小型的項目組人數(shù)控制在 10 個以下，且每個項目組成員在同一地點辦公，以方便交流與溝通。2.4 方法微軟通常采用“同步穩(wěn)定產(chǎn)品開發(fā)法” 。典型項目的生命周期包括三個階段：計劃階段：完成功能的說明和進度表的最后制定開發(fā)階段：寫出完整的源代碼穩(wěn)定化階段：完成產(chǎn)品，使之能夠批量生產(chǎn)（roll out）在開發(fā)和穩(wěn)定化階段的所有時間中，一個項目通常會將 2/3 的時間用于開發(fā)，1/3 的時

15、間用于穩(wěn)定化。這種里程碑式的工作過程使微軟經(jīng)理們可以清楚地了解產(chǎn)品開發(fā)過程進行到了哪一步，也使他們在開發(fā)階段的后期有能力靈活地刪去一些產(chǎn)品特性以滿足進度要求。并且針對每個階段的活動均提出了一些行之有效的方法和技術(shù)。 2.4.1 計劃階段 主要是做以下事情：（1）.把你準備做什么樣一個產(chǎn)品搞清楚，這個產(chǎn)品有什么特性。（2）.這個產(chǎn)品有沒有市場，用戶為何需要這個產(chǎn)品以及該產(chǎn)品的走勢。（3）.這個產(chǎn)品大概是個什么樣子，是否有個大概的原型展示方便高層決策。（4）.設計的功能，目標，優(yōu)先級，大概的進度。微軟在這個計劃階段保存了很多可行性研究分析和產(chǎn)品規(guī)劃的內(nèi)容在里面，更多的是一個產(chǎn)品規(guī)劃的內(nèi)容。2.4.

16、2 開發(fā)階段開發(fā)階段的計劃對三四個主要的里程碑版本都逐個分配一組特性，規(guī)定出特性的細節(jié)和技術(shù)上的相關(guān)性，記錄下單個開發(fā)員的任務以及對進度的估計。在開發(fā)階段中，開發(fā)員在功能性說明的指導下寫源代碼，測試員寫出測試項目組以檢查產(chǎn)品的特性與工作范圍是否正常，用戶體驗人員則編寫出文檔草案。 當測試員發(fā)現(xiàn)錯誤時，開發(fā)員并不是留待以后處理，而是馬上改正，并在整個開發(fā)階段內(nèi)使測試不斷地、自動地進行。這就改善了產(chǎn)品的穩(wěn)定性并且使版本發(fā)布日期更易估計。當達到項目中的一定階段點后（40%時） ，開發(fā)員就試圖“鎖定”產(chǎn)品的主要功能要求或特性，從此，只允許小范圍的改動。如果在此點之后開發(fā)員想作大的改動，他們必須與程序經(jīng)

17、理以及開發(fā)經(jīng)理進行討論協(xié)商，也許還要征求產(chǎn)品部門經(jīng)理的意見。(這里有兩點，一個是提倡及早的發(fā)現(xiàn)缺陷和持續(xù)的集成，一個是后期嚴格的對需求變更進行控制）一個項目是圍繞著 3 或 4 個主要的內(nèi)部版本，或“里程碑子項目”來組織開發(fā)階段的。一般用 2 至 4 個月來開發(fā)每一個主要的里程碑版本。每個版本都包括其自身的編碼、優(yōu)化、測試以及調(diào)試活動。項目為意外事故保留總開發(fā)1/3 的時間，即“緩沖時間” 。(應該說 1/3 時間是足夠多的，一般研發(fā)項目很難預備這么足夠的 buffer)。 當對最后一個主要的里程碑版本做了測試與穩(wěn)定化之后，產(chǎn)品就要進行“外觀固定” ，即確定產(chǎn)品的主要用戶界面，如菜單、對話框以

18、及文件窗口等。此后有關(guān)用戶界面將不再進行大的改動，以免引起同步修改相應文檔的困難。 2.4.3 穩(wěn)定化階段穩(wěn)定化階段著重于對產(chǎn)品的測試與調(diào)試。項目在此階段盡量不再增加新的功能，除非是競爭產(chǎn)品或者市場發(fā)生了變化。穩(wěn)定化階段也包括了緩沖時間，以應付不可預見的問題或者延遲。在軟件的開發(fā)流程中，軟件的測試與開發(fā)是一種“矛與盾”的關(guān)系，互為補充，缺一不可。在微軟，可能這種關(guān)系發(fā)揮到了極至：有時開發(fā)部門與測試部門互相較著勁，開發(fā)經(jīng)理和測試經(jīng)理的地位是相同的，有時甚至測試經(jīng)理的地位甚至凌駕于開發(fā)經(jīng)理之上，但他們之間沒有根本的利益沖突，只有一個共同的目標：將產(chǎn)品的質(zhì)量提高。 為了保證產(chǎn)品的質(zhì)量，微軟一直采取零

19、缺陷管理、手工測試與自動測試相結(jié)合、內(nèi)部測試與外部測試相結(jié)合的原則。2.5 產(chǎn)品微軟過程的產(chǎn)品主要包括各類文檔、源代碼、可執(zhí)行文件以及相應的文檔代碼。且微軟過程提出了以產(chǎn)品特性及優(yōu)先級指導整個項目。2.6 四要素之間的關(guān)系在微軟過程中，生命周期的進度、方法、人員及方法工具等項目資源、產(chǎn)品的功能與性能三者之間存在一種相互制約的均衡三角形關(guān)系。均衡三角形的任意一邊的改變將導致另外一邊或兩邊的變化。產(chǎn)品的開發(fā)關(guān)鍵是在進度、資源、產(chǎn)品功能與性能三者之間尋找一個最佳的均衡。2.7 本章小結(jié)微軟過程是一套比較完整的軟件過程模式，作為一種針對商業(yè)環(huán)境下具有有限資源和有限時間限制的項目的軟件過程模式，它綜合了

20、諸多軟件過程模式的優(yōu)點，并且在人員及其組織過程中的方法等方面提出了獨具特色的、操作性很強的實踐規(guī)范，是一套優(yōu)秀的成功項目開發(fā)實踐經(jīng)驗總結(jié)。但是，微軟過程也存在某些缺陷，如對方法和工具的選擇、產(chǎn)品的優(yōu)先級等方面的論述不夠全面，并且有的原則本身也存在問題。 第三章、rup 的介紹3.1rational 統(tǒng)一過程概述rational 統(tǒng)一過程（rational unified process, rup）是由 rational 公司推出的一種軟件過程產(chǎn)品，其目標是：按照預先制定的時間計劃和經(jīng)費預算，開發(fā)高質(zhì)量的軟件產(chǎn)品以滿足用戶的需求。rup 提高了團隊生產(chǎn)力。對于所有的關(guān)鍵開發(fā)活動它為每個團隊成員提

21、供了能使用準則、模板、工具指導來進行訪問的知識基礎(chǔ)，而通過對相同知識基礎(chǔ)的理解，無論你是進行需求分析、設計、測試、項目管理或配置管理，均能確保全體成員共享相同的知識、過程和開發(fā)軟件的視圖。rup 的活動創(chuàng)建和維護模型。并且能對大部分開發(fā)過和提供自動化的工具支持。此過程以適合于在范圍項目和機構(gòu)的方式捕捉了許多現(xiàn)代軟件開發(fā)過程的最佳實踐部署。rup 包括 6 項最佳實踐： （1）迭代式開發(fā)。在軟件開發(fā)的早期階段就想完全、準確的捕獲用戶的需求幾乎是不可能的。實際上，我們經(jīng)常遇到的問題是需求在整個軟件開發(fā)工程中經(jīng)常會改變。迭代式開發(fā)允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。迭

22、代式開發(fā)不僅可以降低項目的風險，而且每個迭代過程以可以執(zhí)行版本結(jié)束，可以鼓舞開發(fā)人員。（2）管理需求。確定系統(tǒng)的需求是一個連續(xù)的過程，開發(fā)人員在開發(fā)系統(tǒng)之前不可能完全詳細的說明一個系統(tǒng)的真正需求。rup 描述了如何提取、組織系統(tǒng)的功能和約束條件并將其文檔化，用例和腳本的使用以被證明是捕獲功能性需求的有效方法。（3）基于組件的體系結(jié)構(gòu)。組件使重用成為可能，系統(tǒng)可以由組件組成。基于獨立的、可替換的、模塊化組件的體系結(jié)構(gòu)有助于管理復雜性，提高重用率。rup 描述了如何設計一個有彈性的、能適應變化的、易于理解的、有助于重用的軟件體系結(jié)構(gòu)。（4）可視化建模。rup 往往和 uml 聯(lián)系在一起，對軟件系統(tǒng)

23、建立可視化模型幫助人們提供管理軟件復雜性的能力。rup 告訴我們?nèi)绾慰梢暬膶浖到y(tǒng)建模，獲取有關(guān)體系結(jié)構(gòu)于組件的結(jié)構(gòu)和行為信息。（5）驗證軟件質(zhì)量。在 rup 中軟件質(zhì)量評估不再是事后進行或單獨小組進行的分離活動，而是內(nèi)建于過程中的所有活動，這樣可以及早發(fā)現(xiàn)軟件中的缺陷。（6）控制軟件變更。迭代式開發(fā)中如果沒有嚴格的控制和協(xié)調(diào)，整個軟件開發(fā)過程很快就陷入混亂之中，rup 描述了如何控制、跟蹤、監(jiān)控、修改以確保成功的迭代開發(fā)。rup 通過軟件開發(fā)過程中的制品，隔離來自其他工作空間的變更，以此為每個開發(fā)人員建立安全的工作空間。3.2 rup 的過程結(jié)構(gòu)rup 軟件開發(fā)生命周期是一個二維的軟件開

24、發(fā)模型（見圖 2.1） 。縱軸代表核心工作流是靜態(tài)的一面，橫軸代表時間顯示過程動態(tài)的一面，用周期、階段、迭代、里程碑等名詞描述。圖 2.1 rup 的二維結(jié)構(gòu)過程3.3 rup 的動態(tài)結(jié)構(gòu)軟件的生命周期被分解為周期，每一個周期工作在產(chǎn)品新的一代上，rup將周期分為四個個的階段先啟階段、精化階段、構(gòu)建階段、產(chǎn)品化階段。每個階段終結(jié)于良好定義的里程碑某些關(guān)鍵決策必須做出的時間點，因此關(guān)鍵目標必須達到。3.3.1 先啟階段先啟階段的目標是為系統(tǒng)建立業(yè)務用例和確定項目的邊界。為了達到該目的必須識別所有與系統(tǒng)交互的外部實體，在較高層次上定義交互的特性。它包括識別所有用例和描述一些重要的用例。業(yè)務用例包括

25、驗收規(guī)范、風險評估、所需資源估計、體現(xiàn)主要里程碑日期的階段計劃。本階段具有非常重要的意義，在這個階段中，關(guān)注的是整個項目進行工程中的業(yè)務和需求方面的主要風險。對于建立在原有系統(tǒng)基礎(chǔ)上的開發(fā)項目來說，先啟階段的時間可能很短。（1）主要目標本階段的主要目標有：明確軟件系統(tǒng)的規(guī)模和邊界條件，包括運作前景、驗收標準以及希望產(chǎn)品中包括和不包括的內(nèi)容。識別系統(tǒng)的關(guān)鍵用例。對比一些主要場景，展示至少一個備選構(gòu)架。 評估整個項目的總體成本和進度。評估潛在的風險。準備項目的支持環(huán)境。(2)產(chǎn)出本階段的產(chǎn)出有：藍圖文檔：核心項目需求、關(guān)鍵特色、主要約束的總體藍圖。原始用例模型（完成 10%-20%） 。原始項目術(shù)

26、語表原始業(yè)務案例，包括業(yè)務的上下文、驗收規(guī)范，成本預計。原始的風險評估。一個或多個原型。（3）里程碑先啟階段結(jié)束時到達第一個重要的里程碑，即生命周期目標里程碑，其評審標準是：風險承擔者就范圍定義、成本/日程估計達成共識。以客觀的主要用例證實對需求的理解。成本/日程、優(yōu)先級、風險和開發(fā)過程的可信度。被開發(fā)體系結(jié)構(gòu)原型的深度和廣度。實體開支與計劃開支的比較。如果無法通過這個里程碑，則項目可能被取消或者仔細地重新考慮。3.3.2 精化階段精化階段是四個階段中最關(guān)鍵的階段，精化階段的目標是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項目計劃，淘汰項目中最高風險的元素。在此階段，可執(zhí)行的結(jié)構(gòu)原型在一個或多

27、個迭代過程中建立，依賴于項目的范圍、規(guī)模、風險和先進程度。工作必須至少處理初始階段中識別的關(guān)鍵用例，關(guān)鍵用例揭示了項目主要技術(shù)的風險。（1）主要目標精化階段的主要目標：確保構(gòu)架、需求和計劃足夠穩(wěn)定，充分減少風險，從而能夠有預見性地確定完成開發(fā)所需的成本和進度。處理在構(gòu)架方面具有重要意義的所有項目風險。建立一個已確定基線的構(gòu)架，它是通過處理構(gòu)架方面重要的場景得到的，這些場景通?？梢燥@示項目的最大技術(shù)風險。制作產(chǎn)品質(zhì)量構(gòu)件的演進式原型，也可能同時制作一個或多個可放棄的探索性原型，以減小特定風險。證明已建立基線的構(gòu)架將在適當時間、以合理的成本支持系統(tǒng)需求。 建立產(chǎn)品的支持環(huán)境。（2）產(chǎn)出本階段的產(chǎn)出

28、是：用例模型補充捕獲非功能性要求和非關(guān)聯(lián)于特定用例要求的需求?？蓤?zhí)行的軟件原型。經(jīng)修訂過的風險清單和業(yè)務案例?？傮w項目的開發(fā)計劃，包括在致的項目計劃，顯示迭代過程和對應的審核標準。指明被使用過程更新過的開發(fā)用例。（3）里程碑精化階段結(jié)束時到達第二個重要的里程碑，即生命周期架構(gòu)里程碑，其評審標準如下：產(chǎn)品前景和需求是穩(wěn)定的。架構(gòu)是穩(wěn)定的?？蓤?zhí)行原形表明已經(jīng)找到了主要的風險元素，并且得到了妥善解決。構(gòu)建階段的迭代計劃足夠詳細和真實，可以保證工作繼續(xù)進行。構(gòu)建階段的迭代計劃有可靠的估算支持。所有涉眾一致認為，如果在當前架構(gòu)環(huán)境中執(zhí)行當前計劃來開發(fā)完整的系統(tǒng)，則當前的前景可以實現(xiàn)。實際的資源耗費與計劃

29、相比是可以接受的。3.3.3 構(gòu)建階段在構(gòu)建階段，所有剩余的構(gòu)件和應用程序功能被開發(fā)并集成為關(guān)品，所有的功能被詳盡地測試。主要目標：優(yōu)化資源和避免不必要的報廢與返工，以最大限度的降低成本。快速達到足夠好的質(zhì)量?？焖偻瓿捎杏玫陌姹就瓿伤兴韫δ艿姆治?、開發(fā)和測試。迭代式、遞增式地開發(fā)出隨時可以發(fā)布到用戶群的完整產(chǎn)品。確定軟件、場地和用戶是否已經(jīng)為部署應用程序作好準備。 使開發(fā)團隊的工作實現(xiàn)某種程度的并行。（2）產(chǎn)出特定平臺上的集成產(chǎn)品。用戶手冊。當前版本的描述。（3）里程碑構(gòu)建階段結(jié)束時到達每三個重要的里程碑，即最初操作性能的里程碑其評審標準應回答：該產(chǎn)品的發(fā)布版本是否足夠穩(wěn)定和成熟，是否可部

30、署在用戶群中?所有涉眾是否己準備好將產(chǎn)品發(fā)布到用戶群?實際的資源耗費與計劃的相比是否仍可以接受?3.3.4 產(chǎn)品化階段產(chǎn)品化階段是將軟件產(chǎn)品交付給用戶群體。（1）主要目標：進行 beta 測試，使其能夠達到用戶的期望。 beta 測試和舊系統(tǒng)接并軌。轉(zhuǎn)換操作數(shù)據(jù)庫。培訓用戶和維護人員。市場營銷、進行分發(fā)和向銷售人員進行新產(chǎn)品介紹。具體部署相關(guān)活動。 調(diào)整活動，如進行調(diào)試、性能或可用性的增強。根據(jù)產(chǎn)品的完整前景和驗收標準，對部署基線進行的評估。實現(xiàn)用戶的自我支持能力。在涉眾之間達成共識，即部署基線已完成且與前景的評估標準一致。（2）里程碑產(chǎn)品化階段結(jié)束時到達第四個重要的里程碑，即產(chǎn)品發(fā)布里程碑，

31、其評審的應能對以下問題進行回答：用戶是否滿意？實際的資源耗費與計劃相比是否可以接受？3.4 rup 的靜態(tài)結(jié)構(gòu)3.4.1 模型元素開發(fā)流程定義了“誰” “何時” “如何”做“什么事” 。即角色、活動、產(chǎn)品、工作流程，四種主要的建模元素來表達 rup。角色定義了明確行為和責任的個人和團隊?；顒邮侵赣晒ぷ鹘巧瓿傻墓ぷ鳎ǔＳ忻鞔_的目標。產(chǎn)品是由過程產(chǎn)生、修改或使用的信息。工作流程描述了一系列活動執(zhí)行的順序，以及這些活動能關(guān)生價值的結(jié)果。3.4.2 核心工作流rup 的 9 個核心工作流是：業(yè)務建模，理解待開發(fā)系統(tǒng)所在的機構(gòu)及其商業(yè)運作，確保所有人員對它有共同的認識，評估待開發(fā)系統(tǒng)對結(jié)構(gòu)的影響；需

32、求，定義系統(tǒng)功能及用戶界面，為項目預算及計劃提供基礎(chǔ)；分析與設計，把需求分析結(jié)果轉(zhuǎn)換為分析與設計模型；實現(xiàn)，把設計模型轉(zhuǎn)換為實現(xiàn)結(jié)果，并做單元測試，集成為可執(zhí)行系統(tǒng)；測試，驗證所有需求是否已經(jīng)被正確實現(xiàn)，對軟件質(zhì)量提出改進意見；部署，打包、分發(fā)、安裝軟件，培訓用戶及銷售人員；配置與變更管理，跟蹤并維護系統(tǒng)開發(fā)過程中產(chǎn)生的所有制品的完整性和一致性；項目管理，為軟件開發(fā)項目提供計劃、人員分配、執(zhí)行、監(jiān)控等方面指導，為風險管理提供框架；環(huán)境，為軟件開發(fā)機構(gòu)提供軟件開發(fā)環(huán)境。3.5 本章小結(jié)rup 是一種具有二維結(jié)構(gòu)和面向?qū)ο蟮能浖_發(fā)過程方法，由四個階段和九個核心工作流組成。這四個階段通過時間來進行

33、組織，是過程的生命特征，體現(xiàn)了開發(fā)過程的動態(tài)結(jié)構(gòu)，主要以目標、產(chǎn)出和里程碑對其進行介紹。而九個核心工作流主要以內(nèi)容組織為活動，體現(xiàn)了開發(fā)過程的靜態(tài)結(jié)構(gòu)，且以活動、產(chǎn)品、工作者和工作流程對其進行描述。rup 的用例驅(qū)動 、 以架構(gòu)為中心 、迭代和增量的過程 ，這三大特點讓 rup 在很多地方優(yōu)于其它軟件過程。但是rup 也存在著諸多的缺點，比如：大量文檔，詳細的計劃:在基本工作之上存在大量的過程和時間開銷。強調(diào)關(guān)注于諸多的規(guī)則，造成了一定程度上的對人員的忽視。第四章 mrup 軟件過程模式4.1mrup 的概述mrup 過程是基于 mp、rup 而提出來的一種新型的軟件開發(fā)過程，主要從軟件的生命

34、周期、人員、方法、產(chǎn)品這四個要素及他們之間的相互關(guān)系對軟件過程進行了描述。4.2mrup 過程模式的生命周期及相關(guān)錯誤的規(guī)避mrup 軟件過程模式在大型的軟件開發(fā)項目中，為適當?shù)谋苊忭椖康娘L險，生命周期中采用 rup 中的迭代與增量的二維過程結(jié)構(gòu)為主要的框架，每個生命周期采取四個連續(xù)的階段，每個階段要據(jù)需要細分為一次或多次迭代。每次迭代經(jīng)歷業(yè)務建模、需求、分析設計、實現(xiàn)、測試、部署、配置各變更管理、項目管理、環(huán)境工作流程中的若干項，并在每個階段增設緩沖時間，以降低進度壓力和風險。而對于小型的軟件開發(fā)，如：資源有限、時間進度限制比較多的小型項目時，最佳軟件過程主要采取可采用微軟過程中的五階段模型

35、，且可以根據(jù)需要對一些過程中的不必要事件進行裁剪（減少中間產(chǎn)品的輸出） ，可以有效的節(jié)約時間，加快進度和提高資源的利用率。在生命周期中通常會出現(xiàn)對項目的生命周期進度計劃過于樂觀和進度落后的情況。我們首先應該在早期進行預防，比如在生命周期的每個階段加上一次的緩沖時間。且對于難以實現(xiàn)的進度要求進行堅決地、同時技巧性地頂住壓力，據(jù)理力爭。同時如果時間是無法改變的，可以對軟件過程模式四大要素中的其他三要素進行調(diào)整，爭取能找到一個平衡點，來滿足客戶的需求。4.3mrup 過程模式的人員軟件公司的差別可能有各種各樣的，但最大的應該是人的差別，重視人的作用，以人為本是一個企業(yè)成功的關(guān)鍵。在最佳軟件過程中的人

36、員及組織管理主要采用微軟過程中的矩陣結(jié)構(gòu)的模式。4.3.1 人員的分配及角色安排把項目組的人員分成產(chǎn)品管理、程序管理、開發(fā)、測試、用戶體驗與發(fā)布管理六種角色，一個人員或一組成員可以擔任多個角色，但是兩個明顯有利益沖突或沖突的角色不能由同一個或同一組人員擔任。在地位上各種角色是平等的，并且針對不同的角色進行好任務分配，使之責、權(quán)、利，能夠清晰明了，避免部門間的扯皮。同時對各項目小組的人員進行控制，最好在 10 人以下，這樣使使小組能進行更好的交流和管理。另外在人員的角色安排上根據(jù)個人的特點合理的安排其職務，比如有創(chuàng)意的人安排在開發(fā)上，細心的人安排測試方面，爭取避人所短，用人所長。4.3.2 人員

37、的選取和激勵人員的素質(zhì)直接影響到一個項目的質(zhì)量，在這里我們更推薦專家式的管理，從事并管理一個行業(yè)必需對一個行業(yè)有所了解，甚至精通。這樣才能使得被自己所管理的人員不至于敷衍了事。且能在手下遇到問題時能夠更好的解決。同時對項目的時間進度的把握能夠更加的客觀。至于人員的激勵包括物質(zhì)和精神兩個層面。1、物質(zhì)方面的激勵主要包括高薪、獎金、股權(quán)、舒適的工作環(huán)境和合理的工作時間及假期。作為軟件過程開發(fā)人員，一般都是高素質(zhì)的人才，這樣的人更加的重視精神層的激勵。2、精神層面的激勵主要包括受重視和尊重的程度、對從事工作的興趣程度、個人技術(shù)技能得以提高的機會、個人得以升遷的機會。比如：在薪酬方面，工作人員不僅關(guān)注

38、自己的實際收入而且容易在乎自己的相對收入，即：把自己的收入與同事同一時期的收入進行比較，如果相對比（實際收入/同事的收入）等于 1 就覺得很公平，否則就覺得不公平。類似現(xiàn)象是工作過程中經(jīng)常遇到同時也是負責人必須處理的問題。因為這類問題處理的恰當與否對工作人員地工作積極性有著嚴重的影響，從而影響軟件開發(fā)的進度與軟件的質(zhì)量。4.4mrup 過程模式方法4.4.1 關(guān)于需求分析方面構(gòu)建用戶模型以獲取需求，在此階段通過以一個可見的、可觸摸的、可操作的用戶模型展示在用戶的面前，使用戶能更清楚的了解項目，并且積極引導客戶的參與，通過其不斷反饋來修改原型，以爭取能夠更清楚的了解用戶的需求，并且使客戶了解項目

39、人員。在自己開發(fā)新軟件時可以通過對客戶的細分，最大程度的滿足各種不同客戶的需求。針對于變化則采取前期歡迎變化、后期穩(wěn)定需求，即：先基線化后凍結(jié)的策略，使自己在后期不至于因為需求的更改造成時間進度的拖延，甚至無法完成工作。4.4.2 關(guān)于工具的選擇、實現(xiàn)與測試選擇比較成熟的、適合自己的、而且被許多廠家實踐證明是非常有效的工具對工作質(zhì)量和工作效率的提高都很有幫助。在編譯代碼時就要注意到代碼的運行效率、安全性、穩(wěn)定性、可理解性、可維護性等多個方面。并且建立源代碼的管理庫，每日進行檢查和編譯，持續(xù)更新和集成。把高要求的“零缺陷”的觀念引入到軟件的質(zhì)量管理當中，并且把手工測試與自動測試、內(nèi)部測試與外部測

40、試相結(jié)合的方法去進行測試。4.4.3 關(guān)于設計方面首先根據(jù)實際情況（時間、費員、人員、技術(shù)等利益的全面衡量）確定是自己建造、復用還是外包，例如：企業(yè)根據(jù)自身的流程，把自己不愿意做的和自己做不好的工作包給別人。其次，對各種方式必須要有一定的了解，例如：自己建造有利于提高開發(fā)人員的水平；而對于自己因缺少技術(shù)而外包的軟件，可以節(jié)約成本，減少風險。4.5mrup 過程模式的產(chǎn)品mrup 過程對各種中間產(chǎn)品和最終產(chǎn)品進行分類，對內(nèi)和對外產(chǎn)品進行分類，對類的產(chǎn)品應該簡潔明了，能使內(nèi)部人員了解就行，這樣便于節(jié)約時間。而對外產(chǎn)品我們應該從用戶的角度出發(fā)，為用戶著想，盡可能做到詳細，易理解，易操作。在產(chǎn)品的開發(fā)

41、中，可以對產(chǎn)品的類型優(yōu)先級進行排列，比如：可以工作的軟件比文檔更能解決實際需要。重視工作軟件的創(chuàng)建而非文檔的制作。而對于最終的產(chǎn)品，就從產(chǎn)品的質(zhì)量性能和功能規(guī)模兩個方面進行度量。由于功能特性是產(chǎn)品競爭力的主要表現(xiàn)，所以強調(diào)盡早確定產(chǎn)品功能特性，以產(chǎn)品優(yōu)先級指導整個項目。在質(zhì)量方面要求低缺陷率、性能方面的可讀性、易維護性、健壯性、可擴展性等等?？傊a(chǎn)品功能規(guī)模和質(zhì)量特性的控制應與項目人員投入、資金投入和進度要求相適應。4.6 mrup 過程模式的生命周期、人員、方法與產(chǎn)品四要素間的關(guān)系在 mrup 過程模式中的生命周期、人員、方法與產(chǎn)品四要素之間始終遵循著微軟過程中的均衡三角形關(guān)系，一個元素的變

42、更直接影響到其他元素中的一個或多個的變化。要想發(fā)布一個符合客戶需求的產(chǎn)品，主要要求在時間、項目人員與方法工具等資源、產(chǎn)品的功能與性能之間找到一個最佳的平衡點。4.7 本章小結(jié)mrup 綜合了 mp、rup 兩種軟件過程，并且針對他們存在的一些不足進行了改進，在生命周期上，它針對不同類型項目提出了不同解決方案；在人員管理上，提出了以人為本的準則；在方法上，對其研究和使用做出了全面的分析；在產(chǎn)品上，產(chǎn)品的分類和優(yōu)先級的提出使工作人員對產(chǎn)品能更好的把握。且通過實踐證明，mrup 過程的應用能夠幫助軟件公司更好的開發(fā)軟件。第五章 總結(jié)與展望總結(jié)本文的研究目標是通過對 mp、rup 的學習，總結(jié)出一種實

43、用的軟件過程模式。在 mp 的學習過程中，我們了解到微軟過程特別重視人的因素，從不同的角度對人員進行了描述，充分發(fā)揮人的主觀能動性。而在 rup 的學習當中，我們感覺到，無論是以用例驅(qū)動，以架構(gòu)為中心，還是增量和迭代，都在重視過程的研究，使過程更清楚明了，以降低風險。而在軟件的開發(fā)過程當中，應該全面的進行考慮，人和方法一樣重要，忽視誰的作用都會為之付出沉重的代價。而本文基于軟件過程的四要素及它們之間的相互關(guān)系提出了 mrup 過程。mrup過程綜合了 mp、rup 的優(yōu)點，避免了它們的缺陷。并且根據(jù)實際情況，對項目的類型進行了分類，這樣更加有利于方法的實施。展望自從軟件危機出現(xiàn)以來，許多大型的

44、軟件公司都致力于尋找新的方法來解決這種尷尬處境，據(jù)統(tǒng)計，現(xiàn)在軟件項目中，順利完成的僅僅只占總項目的 16%，不論是 mp、rup 還是 mrup 過程，雖然有著許多的優(yōu)點，但在這種軟件開發(fā)成功率普遍低下的情況下人們需要在軟件開發(fā)應用上不斷完善，不斷的總結(jié)經(jīng)驗，才能更好的開發(fā)出受到用戶喜愛的軟件。目前在軟件開發(fā)中，有著許多的方法，各自有總各自存在的道理，也有一定的適用環(huán)境。但是可以預測，但是隨著人們對過程方法應用經(jīng)驗的越來越豐富，軟件開發(fā)將會出現(xiàn)更加實用的方法。致 謝首先，我要衷心的感謝 老師，本論文是在 老師的悉心指導下完成的。 老師對本論文的選題、總體結(jié)構(gòu)及論文的內(nèi)容給予了詳盡的指導，并且提出了寶貴的意見，正是他嚴格的要求和嚴謹?shù)闹螌W態(tài)度令本人有了論文研究的方向和最終的研究成果。導師淵博的知識、寬闊的胸襟和謙虛謹慎的人生態(tài)度深深的感召和影響著我，讓我終生受益。其次，感謝計算機系的全體老師們，感謝他