第1章 軟件開發(fā)過程

1、 軟件工程強(qiáng)調(diào)軟件開發(fā)組織必須設(shè)計符合項(xiàng)目和開發(fā)團(tuán)隊(duì) 本身實(shí)際的、良好的開發(fā)過程開發(fā)過程，并通過開發(fā)過程對項(xiàng)目各 項(xiàng)活動進(jìn)行組織管理，并采用合適的方法、工具方法、工具來保證軟 件系統(tǒng)的質(zhì)量。 過程、方法和工具是軟件工程三要素。 教材第一章主要介紹軟件開發(fā)過程、軟件方法（結(jié)構(gòu)化方 法、面向?qū)ο蠓椒ê徒M件方法）； 第二章主要介紹軟件開發(fā)工具； 其他章節(jié)按照軟件開發(fā)過程的不同階段，介紹結(jié)構(gòu)化方法 和面向?qū)ο蠓椒ǖ木唧w應(yīng)用。 第一章 軟件開發(fā)過程 1.1軟件工程的概述 1.2 軟件生命周期 1.3 軟件開發(fā)過程模型 1.4軟件企業(yè)過程能力評價模型 1.5軟件開發(fā)技術(shù) 1.6 軟件開發(fā)過程的建模與文檔

2、第一章 軟件開發(fā)過程 1.1軟件工程的概述 1.1.1軟件工程的發(fā)展歷程 1.1.2 軟件的特征和分類 1.1.3 軟件危機(jī) 1.1.4軟件工程概念和基本原則 1.1.1 軟件工程的發(fā)展歷程 “個體化個體化”的手工開發(fā)的手工開發(fā) 主要用于任務(wù)相對單一的科學(xué)或工程計算； 由于問題相對簡單，軟件往往等同于程序； 程序的編寫者和使用者往往是同一個(一組)領(lǐng)域?qū)＜遥?主要使用低級語言（機(jī)器語言、匯編語言）直接面對機(jī)器編寫程序代碼； 沒有系統(tǒng)性的方法和指導(dǎo)思想，對軟件開發(fā)工作也沒有任何管理。 “軟件作坊軟件作坊” 多道程序、多用戶概念開始出現(xiàn)并變得普及，操作系統(tǒng)、數(shù)據(jù)庫技術(shù)、高級 編程語言也陸續(xù)出現(xiàn)了；

3、 軟件應(yīng)用范圍與系統(tǒng)功能的增多促使軟件產(chǎn)品數(shù)量急劇膨脹，軟件也變得更 加復(fù)雜。 基本還是采用早期的個體化開發(fā)方法， “軟件工廠軟件工廠” 軟件也由單純的程序發(fā)展成為了包括程序、數(shù)據(jù)、文檔等諸多要素集合的軟 件產(chǎn)品。 用工程化的概念、原理、技術(shù)和方法來開發(fā)和維護(hù)軟件 1.1.2 軟件的特征和分類 軟件特征軟件特征 軟件的開發(fā)運(yùn)行必須依賴于特定的計算機(jī)系統(tǒng)環(huán)境，比如 硬件、網(wǎng)絡(luò)配置和支撐軟件等等； 軟件是由開發(fā)或工程化而形成的，而不是傳統(tǒng)意義上的制 造產(chǎn)生的。具有復(fù)雜性、不可見性和易變性，難以處理； 軟件復(fù)制非常簡單，軟件不會“磨損”； 大多數(shù)軟件是定制的，絕大部分的軟件都是新的，而且是 不斷變換

4、的。 1.1.2 軟件的特征和分類 軟件軟件分類分類 按功能可將軟件劃分為系統(tǒng)軟件、支撐軟件、應(yīng)用軟件； 按工作方式將軟件劃分為實(shí)時處理軟件、分時處理軟件、 交互式軟件、批處理軟件； 按規(guī)模將軟件劃分微型軟件、小型軟件、中型軟件、大型 軟件； 按服務(wù)對象將軟件劃分通用軟件、定制軟件； 按照軟件是否分布式布置分為單機(jī)軟件、網(wǎng)絡(luò)軟件。 1.1.3 軟件危機(jī) 軟件危機(jī)就是人們在開發(fā)和維護(hù)軟件時遇到一系列的問題， 具體體現(xiàn)在以下方面： 軟件開發(fā)進(jìn)度難以預(yù)測，軟件開發(fā)成本難以控制 用戶對產(chǎn)品功能難以滿足 軟件產(chǎn)品質(zhì)量無法保證 軟件產(chǎn)品難以維護(hù) 軟件缺少適當(dāng)?shù)奈臋n資料 1.1.3 軟件危機(jī) 軟件危機(jī)的原因

5、 從事軟件開發(fā)的人員對這個產(chǎn)業(yè)認(rèn)識不充分、缺乏經(jīng)驗(yàn)； 缺乏統(tǒng)一的、標(biāo)準(zhǔn)化的開發(fā)過程設(shè)計，缺乏規(guī)范化的方法 論進(jìn)行指導(dǎo)； 忽視軟件開發(fā)前期的需求分析； 文檔資料不齊全、不準(zhǔn)確； 忽視測試的重要性； 沒有完善的質(zhì)量保證體系； 開發(fā)團(tuán)隊(duì)內(nèi)部交流不順暢、不充分； 不重視維護(hù)，或由于以上原因造成維護(hù)工作的困難。 1.1.4軟件工程概念和基本原則 軟件工程軟件工程概念概念 是人們?yōu)榱艘驅(qū)浖C(jī)，把軟件系統(tǒng)的開發(fā)等同視為工 程項(xiàng)目，以借鑒傳統(tǒng)工程的思想、原則、方法，以提高質(zhì) 量、降低成本、控制工期為目的地指導(dǎo)計算機(jī)軟件的開發(fā) 和維護(hù)。 簡言之，就是按時、按質(zhì)、有效地進(jìn)行計算機(jī)軟件系統(tǒng)的 開發(fā)和維護(hù)。 1.

6、1.4軟件工程概念和基本原則 軟件工程的基本原則軟件工程的基本原則 用分階段的生命周期計劃嚴(yán)格管理。 堅持進(jìn)行階段評審； 實(shí)行嚴(yán)格的產(chǎn)品控制； 采用現(xiàn)代程序設(shè)計技術(shù)； 結(jié)果應(yīng)能夠清楚地審查； 開發(fā)小組的人員應(yīng)小而精； 承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性 1.2 軟件生命周期 1.2.1 軟件定義期 1.2.2 軟件開發(fā)期 1.2.3 軟件運(yùn)行和維護(hù)期 1.2.1 軟件定義期 軟件定義是由軟件系統(tǒng)分析人員和用戶合作，確定軟件是 什么，針對有待開發(fā)的軟件系統(tǒng)進(jìn)行分析、規(guī)劃和規(guī)格描 述，為今后的軟件開發(fā)做準(zhǔn)備。 （1）軟件任務(wù)立項(xiàng) 需要針對項(xiàng)目的名稱、性質(zhì)、目標(biāo)、意義和規(guī)模等作出回 答，以此獲得對準(zhǔn)備

7、著手開發(fā)的軟件系統(tǒng)的最高層描述。 （2）項(xiàng)目可行性分析 可行性分析是針對準(zhǔn)備進(jìn)行的軟件項(xiàng)目進(jìn)行的可行性風(fēng)險 評估。因此，需要對準(zhǔn)備開發(fā)的軟件系統(tǒng)提出高層模型， 并根據(jù)高層模型的特征，從技術(shù)、經(jīng)濟(jì)和操作對項(xiàng)目作出 是否值得往下進(jìn)行的回答。 1.2.1 軟件定義期 （3）制定項(xiàng)目計劃 針對項(xiàng)目的開展，從人員、組織、進(jìn)度、資金、設(shè)備等多 個方面進(jìn)行合理的規(guī)劃，并制定項(xiàng)目開發(fā)計劃。 （4）軟件需求分析 軟件需求分析是軟件規(guī)格描述的具體化與細(xì)節(jié)化，是軟件 定義時期需要達(dá)到的目標(biāo)。需求分析要求以用戶需求為基 本依據(jù)，從功能、性能、數(shù)據(jù)、操作等多個方面，對軟件 系統(tǒng)給出完整、準(zhǔn)確、具體的描述，用于確定軟件規(guī)

8、格。 在軟件項(xiàng)目進(jìn)行過程中，需求分析是從軟件定義到軟件開 發(fā)的最關(guān)鍵步驟，其結(jié)論不僅是今后軟件開發(fā)的基本依據(jù)， 同時也是今后用戶對軟件產(chǎn)品進(jìn)行驗(yàn)收的基本依據(jù)。 1.2.2 軟件開發(fā)期 在對軟件規(guī)格完成定義以后，接著可以在此基礎(chǔ)上對軟件實(shí)施開發(fā)， 并由此制作出軟件產(chǎn)品。這個時期需要分階段地完成以下幾項(xiàng)工作。 （1）軟件概要設(shè)計（也稱總體設(shè)計） 概要設(shè)計是從總體上對軟件給出設(shè)計說明。 軟件開發(fā)團(tuán)隊(duì)有開發(fā)人員、高層管理者、安裝配置人員、運(yùn)行維護(hù)人 員、操作者（用戶），不同的人員對于軟件構(gòu)成有不同的觀察角度， 所關(guān)心的軟件系統(tǒng)構(gòu)成元素有所不同。應(yīng)該針對不同的開發(fā)團(tuán)隊(duì)成員， 設(shè)計他們各自所關(guān)心的系統(tǒng)未來

9、結(jié)構(gòu)。 開發(fā)人員關(guān)系軟件系統(tǒng)的構(gòu)造、接口、全局?jǐn)?shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)環(huán)境等； 高層管理者關(guān)心系統(tǒng)的構(gòu)造； 安裝配置人員、運(yùn)行維護(hù)人員關(guān)心硬件系統(tǒng)和相關(guān)軟件配置； 軟件實(shí)際操作者關(guān)心功能模塊結(jié)構(gòu)。 1.2.2 軟件開發(fā)期 （2）軟件詳細(xì)設(shè)計 詳細(xì)設(shè)計以概要設(shè)計為依據(jù)，用于確定軟件結(jié)構(gòu)中每個模 塊的內(nèi)部細(xì)節(jié)，為編寫程序提供最直接的依據(jù)。詳細(xì)設(shè)計 需要從實(shí)現(xiàn)每個模塊功能的程序算法和模塊內(nèi)部的局部數(shù) 據(jù)結(jié)構(gòu)等細(xì)節(jié)內(nèi)容上給出設(shè)計說明。 （3）編碼和單元測試 編碼是對軟件的實(shí)現(xiàn)，一般由程序員完成，并以獲得源程 序基本模塊為目標(biāo)。編碼必須按照“詳細(xì)設(shè)計說明書”的 要求逐個模塊地實(shí)現(xiàn)。 為了方便程序調(diào)試，針對基本模塊

10、的單元測試也往往和編 碼結(jié)合在一起進(jìn)行。單元測試也以詳細(xì)設(shè)計結(jié)果為依據(jù)， 用于檢驗(yàn)每個基本模塊在功能、算法與數(shù)據(jù)結(jié)構(gòu)上是否符 合設(shè)計要求。 1.2.2 軟件開發(fā)期 （4）系統(tǒng)集成測試 系統(tǒng)集成是根據(jù)概要設(shè)計中的軟件結(jié)構(gòu)，把經(jīng)過測試的模塊，按照某 種選定的集成策略，例如漸增集成策略，將系統(tǒng)組裝起來。在組裝過 程中，需要對整個系統(tǒng)進(jìn)行集成測試，以確保系統(tǒng)在技術(shù)上符合設(shè)計 要求，在應(yīng)用上滿足需求規(guī)格要求。 （5）系統(tǒng)確認(rèn)驗(yàn)證 在完成對系統(tǒng)的集成之后，接著還要對系統(tǒng)進(jìn)行確認(rèn)驗(yàn)證。 系統(tǒng)確認(rèn)驗(yàn)證需要以用戶為主體，以需求規(guī)格說明書中對軟件的定義 為依據(jù)，由此對軟件的各項(xiàng)規(guī)格進(jìn)行逐項(xiàng)地確認(rèn)，以確保已經(jīng)完成的

11、 軟件系統(tǒng)與需求規(guī)格的一致性。 為了方便用戶在系統(tǒng)確認(rèn)期間能夠積極參入，也為了系統(tǒng)在以后的運(yùn) 行過程中能夠被用戶正確使用，這個時期往往還需要以一定的方式對 用戶進(jìn)行必要的培訓(xùn)。 在完成對軟件的驗(yàn)收之后，軟件系統(tǒng)可以交付用戶使用，并對項(xiàng)目進(jìn) 行總結(jié)。 1.2.3 軟件運(yùn)行和維護(hù)期 軟件系統(tǒng)的運(yùn)行是一個比較長久的過程，跟軟件開發(fā)機(jī)構(gòu) 有關(guān)的主要任務(wù)是對系統(tǒng)進(jìn)行經(jīng)常性的有效維護(hù)。 軟件的維護(hù)過程，也就是修正軟件錯誤，完善軟件功能， 由此使軟件不斷進(jìn)化升級的過程，以使系統(tǒng)更加持久地滿 足用戶的需要。因此，對軟件的維護(hù)也可以看成為對軟件 的再一次開發(fā)。 對軟件的維護(hù)主要涉及三個方面的任務(wù)，即改正性維護(hù)、

12、 適應(yīng)性維護(hù)和完善性維護(hù)。 1.3 軟件開發(fā)過程模型 軟件過程模型是人們在軟件開發(fā)實(shí)踐中總結(jié)出來的、適用 于具有某一類特征項(xiàng)目的標(biāo)準(zhǔn)開發(fā)過程。 軟件開發(fā)模型提供了一個框架并把必要活動映射這個框架 中，包括主要的開發(fā)階段、各個階段要完成的主要任務(wù)和 活動、各個階段的輸入輸出。 常見的軟件開發(fā)過程模型很多，包括瀑布模型、演化模型 （包括原型模型、增量模型和螺旋模型）、噴泉模型、 RUP過程等等。 在實(shí)踐中，軟件項(xiàng)目開發(fā)團(tuán)隊(duì)必須依據(jù)擬開發(fā)項(xiàng)目的特點(diǎn) 以及對用戶需求的把握程度，選擇某一開發(fā)過程模型并進(jìn) 行一定的剪裁，設(shè)計出適合具體項(xiàng)目的軟件開發(fā)過程。 1.3 軟件開發(fā)過程模型 1.3.1 瀑布模型 1

13、.3.2 原型模型 1.3.3 增量模型 1.3.4 螺旋模型 1.3.5 噴泉模型 1.3.6 統(tǒng)一軟件開發(fā)過程（RUP） 1.3.1 瀑布模型 1.3.1 瀑布模型 瀑布模型（也稱線性順序模型）誕生于20 世紀(jì)70 年代， 是最早出現(xiàn)并獲得最廣泛應(yīng)用的軟件過程模型。瀑布模型 中的“瀑布”意味著過程中的開發(fā)活動是嚴(yán)格線形的，就 像山頂傾瀉下來的水，逐級下落。 瀑布模型是一種基于里程碑的、階段性的過程模型，它所 提供的里程碑式的軟件開發(fā)工作流程，文檔是瀑布模型中 每個階段的成果體現(xiàn)；模型的回溯性很差。因此，瀑布模 型要求項(xiàng)目嚴(yán)格按規(guī)程推進(jìn)，瀑布模型從上至下按順序進(jìn) 行的幾個階段有固定的銜接次序

14、，瀑布模型中的階段只能 逐級到達(dá)，不能跨越。每個階段都有明確的任務(wù)，都需要 產(chǎn)生確定的成果。并且前一階段輸出的成果被作為后一階 段的輸入條件，在某個階段的工作任務(wù)已經(jīng)完成，并準(zhǔn)備 進(jìn)入到下一個階段之前，需要針對這個階段的文檔進(jìn)行嚴(yán) 格的評審，直到確認(rèn)以后才能啟動下一階段的工作。 1.3.1 瀑布模型 瀑布模型必須等到所有開發(fā)工作全部作完以后才能獲得可 以交付的軟件產(chǎn)品，它適用于具有以下特征的項(xiàng)目： 需求穩(wěn)定、變化很小且開發(fā)人員能夠一次性獲取全部需求 的項(xiàng)目； 軟件開發(fā)人員具有豐富經(jīng)驗(yàn)，對于應(yīng)用領(lǐng)域非常熟悉； 軟件項(xiàng)目本身的風(fēng)險很低。 1.3.2 原型模型 1.3.2 原型模型 1.原型模型之快

15、速原型方法 快速原型方法是原型模型在軟件分析、設(shè)計階段的應(yīng)用，用來解決用 戶對軟件系統(tǒng)在需求上的模糊認(rèn)識，或用來試探某種設(shè)計是否能夠獲 得預(yù)期結(jié)果?？焖僭头椒ň哂幸韵乱恍┨攸c(diǎn)： 快速原型用來獲取用戶需求，或是用來試探設(shè)計是否有效。一旦需求 或設(shè)計確定，原型就將被拋棄。因此，快速原型要求快速構(gòu)建、容易 修改，以節(jié)約原型創(chuàng)建成本、加快開發(fā)速度?？焖僭屯捎靡恍?快速生成工具創(chuàng)建，例如4GL 語言。Visual Basic、Delphi 等基于組件 的可視化開發(fā)工具是非常有效的快速原型創(chuàng)建工具，也被應(yīng)用于原 型創(chuàng)建和進(jìn)化。 快速原型是暫時使用的，因此并不要求完整。它往往針對某個局部問 題建立專

16、門原型，如界面原型、工作流原型、查詢原型等。 快速原型不能貫穿軟件的整個生命周期，它需要和其他的過程模型相 結(jié)合才能產(chǎn)生作用。例如，在瀑布模型中應(yīng)用快速原型，以解決瀑布 模型在需求分析時期存在的不足。 1.3.2 原型模型 2.原型模型之原型進(jìn)化模型 原型進(jìn)化對開發(fā)過程的考慮是，針對有待開發(fā)的軟件系統(tǒng)， 先開發(fā)一個原型系統(tǒng)給用戶使用，然后根據(jù)用戶使用情況 的意見反饋，對原型系統(tǒng)不斷修改，使它逐步接近并最終 到達(dá)開發(fā)目標(biāo)。它具有以下兩個特點(diǎn)： 原型進(jìn)化模型將軟件的需求定義、產(chǎn)品開發(fā)和有效性驗(yàn)證 放在同一個工作進(jìn)程中交替或并行運(yùn)作。因此，在獲得了 軟件需求框架以后，例如軟件的基本功能被確定以后，就

17、 可以直接進(jìn)入到對軟件的開發(fā)中。 原型進(jìn)化模型是通過不斷發(fā)布新的軟件版本而使軟件逐步 完善的，因此，這種開發(fā)模式特別適合于那些用戶急需的 軟件產(chǎn)品開發(fā)。它能夠快速地向用戶交付可以投入實(shí)際運(yùn) 行的軟件成果，并能夠很好地適應(yīng)軟件用戶對需求規(guī)格的 變更。 1.3.2 原型模型 原型模型適用于具有以下特征的軟件項(xiàng)目開發(fā)： 對現(xiàn)有軟件產(chǎn)品進(jìn)行升級或功能完善； 開發(fā)人員和用戶交流困難，需求獲取困難； 開發(fā)人員對技術(shù)熟悉或把握性不大； 具有支持快速開發(fā)的工具。 原型模型的優(yōu)點(diǎn)在于靈活性好，簡單快速，能夠適應(yīng)軟件 需求的中途變更； 缺點(diǎn)在于需要額外的花費(fèi)來構(gòu)造原型，且缺乏有效的管理 規(guī)程，軟件版本的快速變更還

18、可能損傷軟件的內(nèi)部結(jié)構(gòu)， 使其缺乏整體性和穩(wěn)定性。 1.3.3 增量模型 1.3.3 增量模型 增量模型在整體上按照瀑布模型的流程實(shí)施項(xiàng)目開發(fā)，以方便對項(xiàng)目 的管理；但在軟件的實(shí)際創(chuàng)建中，則將軟件系統(tǒng)按功能分解為許多增 量構(gòu)件，并以構(gòu)件為單位逐個地創(chuàng)建與交付，直到全部增量構(gòu)件創(chuàng)建 完畢，并都被集成到系統(tǒng)之中交付用戶使用。增量模型具有以下特點(diǎn)： 開發(fā)初期的需求定義可以是大概的描述，只是用來確定軟件的基本結(jié) 構(gòu)，而對于需求的細(xì)節(jié)性描述，則可以延遲到增量構(gòu)件開發(fā)時進(jìn)行， 以增量構(gòu)件為單位逐個地進(jìn)行需求補(bǔ)充； 可以靈活安排增量構(gòu)件的開發(fā)順序，并逐個實(shí)現(xiàn)和交付使用。這不僅 有利于用戶盡早地用上系統(tǒng)，而且

19、用戶在以增量方式使用系統(tǒng)的過程 中，還能夠獲得對軟件系統(tǒng)后續(xù)構(gòu)件的需求經(jīng)驗(yàn)； 軟件系統(tǒng)是逐漸擴(kuò)展的，因此，開發(fā)者可以通過對諸多構(gòu)件的開發(fā)， 逐步積累開發(fā)經(jīng)驗(yàn)，從總體上降低軟件項(xiàng)目的技術(shù)風(fēng)險，還有利于技 術(shù)復(fù)用； 核心增量構(gòu)件具有最高優(yōu)先權(quán)，將會被最先交付，而隨著后續(xù)構(gòu)件不 斷被集成進(jìn)系統(tǒng)，這個核心構(gòu)件將會受到最多次數(shù)的測試從而具有最 高的可靠性。 1.3.3 增量模型 增量模型的工作流程，它被分成以下三個階段： （1）在系統(tǒng)開發(fā)的前期階段，為了確保系統(tǒng)具有優(yōu)良的結(jié) 構(gòu)，仍需要針對整個系統(tǒng)進(jìn)行需求分析和概要設(shè)計，需要 確定系統(tǒng)的基于增量構(gòu)件的需求框架，并以需求框架中構(gòu) 件的組成及關(guān)系為依據(jù)，完成

20、對軟件系統(tǒng)的體系結(jié)構(gòu)設(shè)計。 （2）在完成軟件體系結(jié)構(gòu)設(shè)計之后，可以進(jìn)行增量構(gòu)件的 開發(fā)。這個時候，需要對構(gòu)件進(jìn)行需求細(xì)化，然后進(jìn)行設(shè) 計、編碼測試和有效性驗(yàn)證。 （3）在完成了對某個增量構(gòu)件的開發(fā)之后，需要將該構(gòu)件 集成到系統(tǒng)中去，并對已經(jīng)發(fā)生了改變的系統(tǒng)重新進(jìn)行有 效性驗(yàn)證，然后再繼續(xù)下一個增量構(gòu)件的開發(fā)。 1.3.3 增量模型 增量模型主要適用于有一下特點(diǎn)的項(xiàng)目： 待開發(fā)系統(tǒng)能夠被模塊化； 軟件產(chǎn)品可以分批次交付； 軟件開發(fā)人員對應(yīng)用領(lǐng)域不熟悉，或一次性開發(fā)的難度很 大； 項(xiàng)目管理人員把握全局的水平很高。 1.3.3 增量模型 比較瀑布模型、原型進(jìn)化模型，增量模型具有非常顯著的 優(yōu)越性。

21、但是，增量模型對軟件設(shè)計有更高的技術(shù)要求，特別是對 軟件體系結(jié)構(gòu)，要求它具有很好的開放性與穩(wěn)定性，能夠 順利地實(shí)現(xiàn)構(gòu)件的集成。在把每個新的構(gòu)件集成到已建軟 件系統(tǒng)的結(jié)構(gòu)中的時候，一般要求這個新增的構(gòu)件應(yīng)該盡 量少地改變原來已建的軟件結(jié)構(gòu)。因此增量構(gòu)件要求具有 相當(dāng)好的功能獨(dú)立性，其接口應(yīng)該簡單，以方便集成時與 系統(tǒng)的連接。 1.3.4 螺旋模型注重風(fēng)險 控制 1.3.4 螺旋模型 軟件開發(fā)過程中存在許多方面的風(fēng)險。 由于軟件風(fēng)險可能在不同程度上損害軟件開發(fā)過程，并由 此影響軟件產(chǎn)品質(zhì)量，因此，在軟件開發(fā)過程中需要及時 地識別風(fēng)險、有效地分析風(fēng)險，并能夠采取適當(dāng)措施消除 或減少風(fēng)險的危害。 螺旋

22、模型即是一種引入了風(fēng)險分析與規(guī)避機(jī)制的過程模型， 是瀑布模型、快速原型方法和風(fēng)險分析方法的有機(jī)結(jié)合。 1.3.4 螺旋模型 螺旋模型用螺旋線表示軟件項(xiàng)目的進(jìn)行情況，其中，螺旋 線中的每個回路表示軟件過程的一個階段。最里面的回路 與項(xiàng)目可行性有關(guān)，接下來的一個回路與軟件需求定義有 關(guān)，而再下一個回路則與軟件系統(tǒng)設(shè)計有關(guān)，以此類推。 螺旋線中的每個回路都被分成為四個部分： （1）目標(biāo)設(shè)置：確定項(xiàng)目的階段性目標(biāo)，分析項(xiàng)目風(fēng)險。 （2）風(fēng)險評估：對風(fēng)險進(jìn)行詳細(xì)地評估分析，并確定適當(dāng) 的風(fēng)險規(guī)避措施。 （3）開發(fā)軟件：根據(jù)對風(fēng)險的認(rèn)識，決定采用合適的軟件 開發(fā)模型，實(shí)施軟件開發(fā)。 （4）制定計劃：對項(xiàng)目

23、進(jìn)行階段評審，制定項(xiàng)目下一個階 段的工作計劃。 1.3.4 螺旋模型 對軟件項(xiàng)目進(jìn)行風(fēng)險分析也是需要費(fèi)用的，假如項(xiàng)目風(fēng)險 分析費(fèi)用過高，甚至超過項(xiàng)目開發(fā)費(fèi)用，將得不償失。實(shí) 際上，只有較大型的項(xiàng)目才有較高的風(fēng)險，才有進(jìn)行各個 階段詳細(xì)風(fēng)險分析的必要。因此，螺旋模型主要應(yīng)用于大 型軟件項(xiàng)目之中。 1.3.5 噴泉模型 1.3.5 噴泉模型 噴泉模型是專門針對面向?qū)ο筌浖_發(fā)方法而提出的。 “噴泉”一詞用于形象地表達(dá)面向?qū)ο筌浖_發(fā)過程中的迭 代和無縫過渡。 在面向?qū)ο蠓椒ㄖ?，對象既是對現(xiàn)實(shí)問題中實(shí)體的抽象， 也是構(gòu)造軟件系統(tǒng)的基本元素。因此，建立對象模型在面 向?qū)ο蠓椒ㄖ?，既可以用于分析，也可?/p>

24、用于設(shè)計，而且 分析階段所獲得的對象框架模型可以無縫過渡到設(shè)計階段， 以作為軟件實(shí)現(xiàn)的依據(jù)。 1.3.5 噴泉模型 噴泉模型基于面向?qū)ο蠓椒ㄋ鶐淼谋憷?，對軟件的分析?設(shè)計和實(shí)現(xiàn)按照迭代的方式交替進(jìn)行，并通過進(jìn)化的方式， 使軟件分階段逐漸完整、逐步求精。 例如，第一階段軟件開發(fā)的目標(biāo)可以是軟件的基本功能； 第二階段可以是在第一階段建立的軟件的基礎(chǔ)上，對軟件 進(jìn)行進(jìn)一步的完善，并實(shí)現(xiàn)軟件的主要功能；第三階段則 是在第二階段的基礎(chǔ)上，對軟件進(jìn)行加完整的開發(fā)，并以 實(shí)現(xiàn)軟件全部功能作為創(chuàng)建目標(biāo)。 1.3.6 統(tǒng)一軟件開發(fā)過程（RUP） 1.3.6 統(tǒng)一軟件開發(fā)過程（RUP） RUP(Rationa

25、l Unified Process)是Rational公司提出的基于 UML的一種面向?qū)ο筌浖_發(fā)過程模型。它解決了螺旋模 型的可操作性問題，采用迭代和增量的開發(fā)策略，以用例 為驅(qū)動，集成了多種軟件開發(fā)過程模型的特點(diǎn)。 RUP的特點(diǎn)如下： RUP是一個可剪裁定制的軟件開發(fā)過程模型。任何開發(fā)團(tuán) 隊(duì)或開發(fā)企業(yè)都可以以RUP為基礎(chǔ)，設(shè)計適用自身和項(xiàng)目 特點(diǎn)的開發(fā)過程。 RUP為如何適用UML提供了指導(dǎo)，強(qiáng)調(diào)建立和維護(hù)模型， 而不是側(cè)重于產(chǎn)生大量的書面文檔。 RUP能夠有效提高開發(fā)效率。使用RUP，開發(fā)團(tuán)隊(duì)可共享 統(tǒng)一語言、過程和開發(fā)軟件的模型視圖。 1.3.6 統(tǒng)一軟件開發(fā)過程（RUP） RUP吸收

26、了許多在實(shí)踐中已經(jīng)證明的軟件開發(fā)實(shí)踐經(jīng)驗(yàn)， 包括： 迭代式開發(fā) 使用基于組件的體系結(jié)構(gòu) 可視化的軟件建模 強(qiáng)調(diào)需求管理 驗(yàn)證軟件質(zhì)量 嚴(yán)格控制軟件變化 1.3.6 統(tǒng)一軟件開發(fā)過程（RUP） RUP過程的軟件開發(fā)生命周期在時間上被分解為四個順序 的階段，分別是初始、細(xì)化、構(gòu)造和交付。每個階段都允 許多次迭代，并結(jié)束于一個主要的里程碑，在每個階段的 結(jié)尾執(zhí)行一次評估以確定本階段的目標(biāo)是否已經(jīng)滿足。如 果評估結(jié)果令人滿意的話，可以允許項(xiàng)目進(jìn)入下一個階段。 初始階段的目標(biāo)是為系統(tǒng)建立商業(yè)案例并確定項(xiàng)目的邊界； 細(xì)化階段的目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基 礎(chǔ)，編制項(xiàng)目計劃，淘汰項(xiàng)目中最高風(fēng)險的

27、元素； 在構(gòu)建階段，所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集 成為產(chǎn)品，所有的功能被詳細(xì)測試； 交付階段的重點(diǎn)是確保軟件對最終用戶是可用的。 1.3.6 統(tǒng)一軟件開發(fā)過程（RUP） RUP中有9個核心工作流，其中業(yè)務(wù)建模、需求分析、設(shè)計、實(shí) 現(xiàn)、測試、發(fā)布為核心過程工作流， 配置和變更管理、項(xiàng)目管理、環(huán)境為核心支持工作流。 從RUP的核心工作流的構(gòu)成可以看到，除了業(yè)務(wù)建模，RUP的工 作任務(wù)和瀑布過程模型的差異不大，說明RUP更強(qiáng)調(diào)以（現(xiàn)實(shí) 系統(tǒng)的）的業(yè)務(wù)分析作為用戶需求的主要收集來源，這在管理 信息系統(tǒng)之類的軟件項(xiàng)目中尤為重要。 以現(xiàn)實(shí)系統(tǒng)分析作為需求分析的基礎(chǔ)，是RUP過程與其他過程 模型的

28、顯著不同。本書結(jié)合瀑布過程模型和RUP過程，設(shè)計了 適用于管理信息系統(tǒng)之類軟件項(xiàng)目的開發(fā)過程模型（具體見1.6 節(jié)），設(shè)計的過程模型具有方便實(shí)用、各階段模型銜接性好的 特點(diǎn)。開發(fā)人員或企業(yè)也可以此過程模型為基礎(chǔ)，設(shè)計適用于 自身和特定項(xiàng)目的軟件開發(fā)過程。 1.4軟件企業(yè)過程能力評價模型 軟件開發(fā)團(tuán)隊(duì)通常需要對過程模型進(jìn)行改造、裁剪，以實(shí) 現(xiàn)對項(xiàng)目開發(fā)活動的組織和軟件質(zhì)量控制。在軟件開發(fā)企 業(yè)級，也需要穩(wěn)定和規(guī)范的開發(fā)過程，作為衡量和評價其 軟件開發(fā)能力和項(xiàng)目開發(fā)質(zhì)量的基準(zhǔn)。 軟件工程研究所(SEI)提出了一個五級別的過程成熟度綜合 模型，可以很好地衡量和評價一個軟件開發(fā)組織的軟件過 程能力，即

29、所達(dá)到的過程成熟度。該模型定義了在不同的 過程成熟度級別上所需要的關(guān)鍵活動， 1.4軟件企業(yè)過程能力評價模型 第一級：初始級軟件過程的特征是無序的，有時甚至是混亂的。 任何軟件開發(fā)組織，都具有這一級的能力任何軟件開發(fā)組織，都具有這一級的能力。 第二級：可重復(fù)級建立了基本的項(xiàng)目管理過程，能夠追蹤費(fèi)用、 進(jìn)度和功能。只有那些能夠?qū)⒊晒?xiàng)目經(jīng)驗(yàn)用于未來項(xiàng)目將成功項(xiàng)目經(jīng)驗(yàn)用于未來項(xiàng)目的企業(yè)才具 有二級能力。 第三級：定義級用于管理和工程活動的軟件過程已經(jīng)文檔化、標(biāo) 準(zhǔn)化，并與整個組織的軟件過程相集成。具有第三級能力的開發(fā)企業(yè) 已經(jīng)將過往項(xiàng)目的成功經(jīng)驗(yàn)標(biāo)準(zhǔn)化成功經(jīng)驗(yàn)標(biāo)準(zhǔn)化，并用于未來項(xiàng)目。 第四級：管理

30、級軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量數(shù)據(jù)被收集，通 過這些度量數(shù)據(jù)，軟件過程和產(chǎn)品能夠被定量地理解和控制。擁有該 級能力的企業(yè)能夠?qū)?xiàng)目活動進(jìn)行定量估算、控制定量估算、控制，因此能夠按時按 成本按質(zhì)量地保證項(xiàng)目開發(fā)。 第五級：優(yōu)化級通過定量的反饋，進(jìn)行不斷的過程改進(jìn)，這些反 饋來自于過程或通過測試新的想法和技術(shù)而得到。擁有第五級能力的 企業(yè)能夠?qū)⑿碌募夹g(shù)、方法、工具無縫嵌入到企業(yè)標(biāo)準(zhǔn)中，企業(yè)能夠 很好地適應(yīng)社會技術(shù)經(jīng)濟(jì)環(huán)境、自主成長自主成長。 1.5軟件開發(fā)技術(shù) 1.5.1 結(jié)構(gòu)化技術(shù) 1.5.2 面向?qū)ο蠹夹g(shù) 1.5.3 組件技術(shù) 1.5.1 結(jié)構(gòu)化技術(shù) 結(jié)構(gòu)化方法是一種傳統(tǒng)的軟件開發(fā)方法，它是由

31、結(jié)構(gòu)化分 析、結(jié)構(gòu)化設(shè)計和結(jié)構(gòu)化編程三部分有機(jī)組合而成的。結(jié) 構(gòu)化思想強(qiáng)調(diào)以數(shù)據(jù)為中心，自頂向下、逐步細(xì)化進(jìn)行問 題的求解（或項(xiàng)目的開發(fā)）。結(jié)構(gòu)化方法最先應(yīng)用在編碼 實(shí)現(xiàn)階段（結(jié)構(gòu)化實(shí)現(xiàn)， Structured Programming ，SP）， 并逐步向設(shè)計階段（結(jié)構(gòu)化設(shè)計，Structured Design,SD）、 需求分析階段（結(jié)構(gòu)化分析，StructuredAnalysis，SA） 擴(kuò)展。 結(jié)構(gòu)化方法學(xué)是一個以數(shù)據(jù)為中心的思想體系，它的基本 要點(diǎn)是：自頂向下、逐步求精、模塊化設(shè)計、結(jié)構(gòu)化編碼。 通過把一個復(fù)雜問題的求解過程分階段進(jìn)行，而且這種分 解是自頂向下，逐層分解，使得每個階段處

32、理的問題都控 制在人們?nèi)菀桌斫夂吞幚淼姆秶鷥?nèi)。 1.5.1 結(jié)構(gòu)化技術(shù) 在業(yè)務(wù)分析時，用業(yè)務(wù)流程描述業(yè)務(wù)操作過程，業(yè)務(wù)流程中的臺帳就是業(yè)務(wù) 操作的數(shù)據(jù)，逐步細(xì)化的業(yè)務(wù)流程和業(yè)務(wù)流程中的臺帳體現(xiàn)出結(jié)構(gòu)化思想； 在需求分析過程，以逐步細(xì)化的數(shù)據(jù)流圖（DFD）和數(shù)據(jù)字典為主要表達(dá)手段 描述擬開發(fā)系統(tǒng)。通過逐步細(xì)化數(shù)據(jù)流圖中的加工，對相應(yīng)的數(shù)據(jù)做細(xì)化、 并將它們分離開來。數(shù)據(jù)流圖中的數(shù)據(jù)流以及逐步細(xì)化的數(shù)據(jù)流圖都體現(xiàn)出 結(jié)構(gòu)化思想。 結(jié)構(gòu)化設(shè)計以模塊化為基點(diǎn)，以信息隱蔽化、局部化和保持模塊獨(dú)立為準(zhǔn)則。 概要設(shè)計（也稱總體設(shè)計）時，以需求分析的數(shù)據(jù)流圖和數(shù)據(jù)字典作為輸入， 得到軟件系統(tǒng)的基本框架，包括系

33、統(tǒng)功能結(jié)構(gòu)（用功能結(jié)構(gòu)圖描述）、軟件 系統(tǒng)結(jié)構(gòu)（用系統(tǒng)流程圖描述）、軟件模塊結(jié)構(gòu)（用IPO圖描述）和數(shù)據(jù)庫 （用ER圖、數(shù)據(jù)庫邏輯結(jié)構(gòu)、數(shù)據(jù)庫物理結(jié)構(gòu)描述），其中反映數(shù)據(jù)流向的 系統(tǒng)流程圖、逐步細(xì)化的IPO圖和數(shù)據(jù)庫設(shè)計中的結(jié)構(gòu)化思想都體現(xiàn)得很明顯； 詳細(xì)設(shè)計是明確系統(tǒng)內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，每個過程（或函數(shù)）都有輸入輸出數(shù) 據(jù)和處理指令，處理指令采用三種基本的程序結(jié)構(gòu)（順序、選擇、循環(huán)）描 述。結(jié)構(gòu)化實(shí)現(xiàn)采用結(jié)構(gòu)化的高級編程語言，將詳細(xì)設(shè)計編碼為模塊。 1.5.1 結(jié)構(gòu)化技術(shù) 從結(jié)構(gòu)化方法在分析、設(shè)計和程序編碼階段的應(yīng)用可以看 到，結(jié)構(gòu)化方法和人類思維的方式是不一致的。 在業(yè)務(wù)分析階段，業(yè)務(wù)流程中的

34、操作和臺賬緊密聯(lián)系； 在需求分析階段，加工和數(shù)據(jù)也是相互密切關(guān)聯(lián)，捆綁在 一起； 在概要設(shè)計階段，設(shè)計人員分別將數(shù)據(jù)和操作分開，分別 進(jìn)行軟件系統(tǒng)的模塊設(shè)計和數(shù)據(jù)設(shè)計； 而在詳細(xì)設(shè)計階段，又必須將數(shù)據(jù)和操作密切關(guān)聯(lián)起來， 設(shè)計軟件系統(tǒng)的基本單元-過程（或函數(shù)）。 這種與人類思維不完全一致的方式，導(dǎo)致生產(chǎn)出來的軟件 系統(tǒng)的可讀性、可理解性、可復(fù)用性不高。 1.5.2 面向?qū)ο蠹夹g(shù) 面向?qū)ο蠓椒ㄊ墙陙沓霈F(xiàn)并繁榮的一種新的軟件開 發(fā)方法，它是由面向?qū)ο蠓治觯∣bject-OrientedAnalysis， OOA）、面向?qū)ο笤O(shè)計（Object-Oriented Design,OOD）和 面向?qū)?/p>

35、象編程（Object-Oriented Programming ，OOP）三 部分有機(jī)組合而成的。 和結(jié)構(gòu)化方法一樣，面向?qū)ο蠓椒ㄒ彩亲钕葢?yīng)用在編碼實(shí) 現(xiàn)階段，并逐步向設(shè)計階段、需求分析階段擴(kuò)展。 面向?qū)ο蠓椒ㄖ鲝垙目陀^世界固有的事物出發(fā)來構(gòu)造系統(tǒng)， 提倡用人類在現(xiàn)實(shí)生活中常用的思維方法來認(rèn)識、理解和 描述客觀事物，強(qiáng)調(diào)最終建立的系統(tǒng)能夠映射問題域，也 就是說，系統(tǒng)中的對象以及對象之間的關(guān)系能夠如實(shí)地反 映問題域中固有事物及其關(guān)系。 1.5.2 面向?qū)ο蠹夹g(shù) 面向?qū)ο蟮幕靖拍畎▽ο?、類、消息等等。面向?qū)ο蟮幕靖拍畎▽ο?、類、消息等等?對象：對象是要研究的任何事物。 類：類是對象的模板

36、。 消息：消息是對象之間進(jìn)行通信的一種規(guī)格說明。一般 它由三部分組成：接收消息的對象、消息名及實(shí)際變元。 面向?qū)ο蠹夹g(shù)的基本特征是：封裝、繼承、多態(tài)。面向?qū)ο蠹夹g(shù)的基本特征是：封裝、繼承、多態(tài)。 封裝性：封裝是一種信息隱蔽技術(shù)，它體現(xiàn)于類的說明， 繼承性：繼承性是子類自動共享父類之間數(shù)據(jù)和方法的 機(jī)制。 多態(tài)性：對象根據(jù)所接收的消息而做出動作。 1.5.2 面向?qū)ο蠹夹g(shù) 在面向?qū)ο蟮臉I(yè)務(wù)分析過程中，使用業(yè)務(wù)用例模型來進(jìn)行業(yè)務(wù) 分析，每個業(yè)務(wù)用例就是 “業(yè)務(wù)用例類”的一個對象； 在面向?qū)ο蟮姆治鲞^程中，重點(diǎn)是找到和描述問題領(lǐng)域的對象 或概念（主要來源于現(xiàn)實(shí)業(yè)務(wù)系統(tǒng)中的臺賬），并以用例模型 來描述

37、需求模型，每個用例就是“用例類”的一個對象。 在面向?qū)ο蟮脑O(shè)計過程中，重點(diǎn)是定義軟件對象，以及它們?nèi)?何協(xié)作來滿足需求，用以類圖為主的設(shè)計模型來表達(dá)擬開發(fā)軟 件，每個類就是“類”這種類的一個對象。 最后在編程的時候，用面向?qū)ο蟮母呒壵Z言來描述細(xì)節(jié)，這些 設(shè)計的類會有具體的實(shí)現(xiàn)-對象。 1.5.2 面向?qū)ο蠹夹g(shù) 面向?qū)ο笏枷霃?qiáng)調(diào)以對象為中心，迭代式進(jìn)行問題的求解 （或項(xiàng)目的開發(fā)）。面向?qū)ο蟮姆庋b、繼承、多態(tài)特征能 夠很好地支持迭代式開發(fā)。 在編程時，直觀上看程序員編碼時主要是一些類，但為什 么不能稱為“面向類”而稱為“面向?qū)ο蟆遍_發(fā)技術(shù)？這 是因?yàn)榫幋a的各種類，假如不實(shí)例化，是不能參與到主程 序

38、中，無法提供實(shí)際的功能的。 同樣可以把這個思想推廣到設(shè)計、分析階段。 1.5.2 面向?qū)ο蠹夹g(shù) 由于面向?qū)ο蟮姆椒ㄇ『每梢允沟萌藗儼凑帐澜绫緛淼拿?目來建立問題域的模型，設(shè)計出盡可能自然地表現(xiàn)求解方 法的軟件，能直接表現(xiàn)人求解問題的思維路徑（即求解問 題的方法），從而使得整個軟件的開發(fā)過程中都保持完全 一致的思維方式。因此開發(fā)的軟件不僅容易被人理解，而 且易于維護(hù)和修改，從而會保證軟件的可靠性和可維護(hù)性， 并能提高公共問題域中的軟件模塊和模塊重用的可靠性。 1.5.3 組件技術(shù) 從軟件開發(fā)工程化以來，軟件復(fù)用就是開發(fā)人員考慮的大 問題，并產(chǎn)生了一些比較常用的軟件復(fù)用方法。 結(jié)構(gòu)化開發(fā)方法下，軟

39、件復(fù)用方法是建立實(shí)現(xiàn)基本通用功 能的“源程序”的函數(shù)庫或“二進(jìn)制”的API庫，不同的 軟件可以調(diào)用它們。 在面向?qū)ο蠓椒ㄏ?，軟件?fù)用則可以通過建立類模塊來實(shí) 現(xiàn)。由于類的繼承性特征，因此，基于類的復(fù)用效果比結(jié) 構(gòu)化方法要好。面向?qū)ο蠹夹g(shù)可以視為一種“源語言”級 別的面向?qū)ο髲?fù)用技術(shù)，即在進(jìn)行復(fù)用時，必須能夠訪問 到基類的源代碼，這意味著被復(fù)用的代碼和擴(kuò)充代碼必須 采用同一開發(fā)語言。 1.5.3 組件技術(shù) 組件技術(shù)是近年才發(fā)展起來的一種“二進(jìn)制”（在Java平 臺上是字節(jié)碼）面向?qū)ο髲?fù)用技術(shù)。 組件可以被看作為一個盒子，它里面封裝了多個稱為組件 類的類模塊。 組件比類更大、更抽象，其中包含了更多

40、的 功能，更具有通用性，更加有利于復(fù)用。 由于組件對象和調(diào)用者通常不在同一個進(jìn)程空間、甚至不 在同一臺計算設(shè)備上（最簡單的情況下，組件對象和調(diào)用 者是在同一個進(jìn)程空間），因此調(diào)用者不能像“源語言” 級的面向?qū)ο蠹夹g(shù)一樣，讓調(diào)用者直接操作組件對象，因 此組件對象都是以“接口”的形式把功能暴露出來，供調(diào) 用者調(diào)用。 1.5.3 組件技術(shù) 為了提高組件的管理和應(yīng)用，各種各樣的“容器”被開發(fā)出來 以實(shí)現(xiàn)組件的統(tǒng)一管理。 比如在Windows平臺上，可以用“組件服務(wù)”（ “控制面板- 管理工具-組件服務(wù)”）來集中管理計算機(jī)系統(tǒng)內(nèi)或網(wǎng)絡(luò)中其 他計算機(jī)上的組件； 在Java平臺上，應(yīng)用服務(wù)器（Applica

41、tion Server，例如Jboss、 Weblogic、Websphere等等）用Servlet容器、EJB容器等等來對 Servlet組件和EJB組件進(jìn)行集中管理。 當(dāng)組件沒有放置在容器中時，每個組件必須自己負(fù)責(zé)解決安全、 共享、完整性等等普遍性問題，因此能夠不放置在容器中的組 件必定比較復(fù)雜、龐大；當(dāng)組件放置在容器中時，每個組件只 要按照容器的規(guī)范進(jìn)行設(shè)計開發(fā)，就可以方便地放置在容器內(nèi)， 由容器提供統(tǒng)一的安全、共享、事務(wù)等服務(wù)。 1.5.3 組件技術(shù) 組件特點(diǎn)組件特點(diǎn) 自包容性：每個組件是模塊相對獨(dú)立，功能相對完整的程序單 元；組件通過一些標(biāo)準(zhǔn)或自定義的應(yīng)用接口將自身功能暴露出 來，供

42、使用者使用。 平臺/語言獨(dú)立性：只要遵循組件技術(shù)的規(guī)范，開發(fā)人員就可以 用任何方便的語言去實(shí)現(xiàn)組件，客戶程序或其他組件也可以按 照其標(biāo)準(zhǔn)使用組件提供的服務(wù)，且客戶和組件任何一方的版本 更新都不會導(dǎo)致兼容性問題； 重用性：用戶也可以很方便地在對組件進(jìn)行功能擴(kuò)充。由于組 件已經(jīng)二進(jìn)制化，復(fù)用代碼可以選擇任意開發(fā)語言； 可定制性：通過某些給定的標(biāo)準(zhǔn)接口，允許用戶設(shè)置和調(diào)整組 件的參數(shù)和屬性； 互操作性：組件之間的嚴(yán)格統(tǒng)一的連接標(biāo)準(zhǔn)，實(shí)現(xiàn)組件之間、 組件與用戶程序之間的互操作。這種互操作是在目標(biāo)代碼級上 的，與具體的開發(fā)語言無關(guān)。 1.5.3 組件技術(shù) 組件技術(shù)將面向?qū)ο筇卣骱头植际剑ㄎ锢砘蜻壿嫷模┙Y(jié)

43、合 起來，是分布式計算和Web服務(wù)的基礎(chǔ)。 由于組件技術(shù)的出現(xiàn)，軟件開發(fā)的方式有了很大變化，可 以把軟件開發(fā)的內(nèi)容分成若干個層次，將每個層次封裝成 一個個的組件。在構(gòu)建應(yīng)用系統(tǒng)時，把這些單個的組件組 裝起來就成為一個系統(tǒng)，就像用零件組裝機(jī)器一樣。可以 事先按照需求設(shè)計出不同組件，在構(gòu)建應(yīng)用系統(tǒng)時根據(jù)自 己的應(yīng)用需要選擇需要的組件。 目前主要的組件技術(shù)有OGM組織的CORBA，Microsoft平臺 上的COM/DCOM/COM+/.net，Java平臺上的 J2EE/JavaBeans/SOA等等。 1.6 軟件開發(fā)過程的建模與文檔 開發(fā)過程中需要建立的模型種類繁多，可以按照它們的本 身特征進(jìn)

44、行分類。比如在結(jié)構(gòu)化分析設(shè)計中，將開發(fā)過程 中的模型分為系統(tǒng)模型、功能模型、數(shù)據(jù)模型等等；而面 向?qū)ο蠓治鲈O(shè)計中，將開發(fā)過程中的模型分為用例視圖、 邏輯視圖、實(shí)現(xiàn)視圖、進(jìn)程視圖和發(fā)布視圖。這種分類沒 有和軟件開發(fā)過程緊密銜接起來，不利于開發(fā)團(tuán)隊(duì)成員理 解不同開發(fā)階段的目標(biāo)和任務(wù)，實(shí)際的可操作性不強(qiáng)。 本書以瀑布過程模型和RUP模型為基礎(chǔ)，從開發(fā)人員的角 度出發(fā)，將軟件開發(fā)過程劃分為項(xiàng)目前期、需求分析、概 要設(shè)計、詳細(xì)設(shè)計與編碼實(shí)現(xiàn)、測試、項(xiàng)目結(jié)束等幾個階 段。 1.6 軟件開發(fā)過程的建模與文檔 1.6 軟件開發(fā)過程的建模與文檔 結(jié)構(gòu)化方法模型面向?qū)ο蠓椒Ｐ臀臋n 項(xiàng)目前期組織機(jī)構(gòu)圖、業(yè)務(wù)流 程

45、圖； 軟件系統(tǒng)體系結(jié)構(gòu)圖、 網(wǎng)絡(luò)拓?fù)鋱D、系統(tǒng)架 構(gòu)圖、系統(tǒng)流程圖、 功能結(jié)構(gòu)圖 組織機(jī)構(gòu)圖、業(yè)務(wù)用例 圖+業(yè)務(wù)流程圖； 軟件系統(tǒng)體系結(jié)構(gòu)圖、 網(wǎng)絡(luò)拓?fù)鋱D、系統(tǒng)架構(gòu) 圖/配置圖、構(gòu)件（組 件）圖、功能結(jié)構(gòu)圖 “需求說明書” “技術(shù)應(yīng)答書” “軟件任務(wù)立項(xiàng)報 告”“可行性研究 報告” 需求分析數(shù)據(jù)流圖 數(shù)據(jù)字典 用例圖+用例流程圖 分析類圖 需求規(guī)格說明書 概要設(shè)計功能結(jié)構(gòu)圖 IPO圖 系統(tǒng)流程圖 ER模型 功能結(jié)構(gòu)圖 類圖（活動圖、狀態(tài)圖、 時序圖、協(xié)作圖） 構(gòu)件圖 ER模型 概要設(shè)計規(guī)格說明 書 詳 細(xì) 設(shè) 計 和 實(shí)現(xiàn) 程序流程圖程序流程圖詳細(xì)設(shè)計規(guī)格說明 書 測試測試計劃 測試總結(jié) 項(xiàng)目結(jié)

46、束項(xiàng)目開發(fā)總結(jié) 1.6 軟件開發(fā)過程的建模與文檔 （1）項(xiàng)目前期 項(xiàng)目前期是項(xiàng)目正式進(jìn)入開發(fā)前的早期階段。對于招投標(biāo)項(xiàng)目，主要 由分析人員（可能來自第三方）和用戶合作完成；對于協(xié)議項(xiàng)目，則 由意向的軟件開發(fā)團(tuán)隊(duì)分析人員與用戶合作，針對環(huán)境進(jìn)行現(xiàn)狀分析、 收集需求、粗略設(shè)計待開發(fā)的軟件系統(tǒng)并在此基礎(chǔ)上對項(xiàng)目進(jìn)行可行 性分析。 現(xiàn)狀分析從硬件（這里的硬件不僅僅是計算機(jī)硬件，而是目標(biāo)單位的 建筑、道路、房屋、設(shè)施等等，如果有信息化基礎(chǔ)，則還需要包括現(xiàn) 有的硬件設(shè)施）和軟件（這里的軟件不僅僅是計算機(jī)軟件，而是目標(biāo) 單位的內(nèi)部部門構(gòu)成、崗位職責(zé)、業(yè)務(wù)處理的流程、各種規(guī)章制度等 等，如果有信息化的基礎(chǔ)，則

47、需要包括現(xiàn)有軟件框架）兩個方面著手， 從軟件開發(fā)的角度，現(xiàn)狀分析需要關(guān)注目標(biāo)單位的硬件（建筑布局和 網(wǎng)絡(luò)硬件設(shè)施）、軟件（組織構(gòu)成、崗位職責(zé)和業(yè)務(wù)處理的流程、現(xiàn) 有軟件的總體結(jié)構(gòu)）。 1.6 軟件開發(fā)過程的建模與文檔 軟件分析主要包括組織機(jī)構(gòu)分析和業(yè)務(wù)流程分析。開發(fā)管理信息系統(tǒng)的目的， 大多是為了替代人工系統(tǒng)或已有的軟件系統(tǒng)，實(shí)現(xiàn)事務(wù)處理的更新和自動化。 即使是完全創(chuàng)新型的事務(wù)系統(tǒng)，也必須設(shè)計合理的組織結(jié)構(gòu)和成熟穩(wěn)定的業(yè) 務(wù)流程。進(jìn)行目標(biāo)系統(tǒng)的現(xiàn)狀分析，不僅有助于分析設(shè)計人員深入了解項(xiàng)目 目標(biāo)單位信息化建設(shè)狀況、目標(biāo)單位的組織構(gòu)成和事務(wù)處理內(nèi)部細(xì)節(jié)，也有 助于協(xié)助用戶收集（功能性）需求。對于組

48、織機(jī)構(gòu)設(shè)置或職能混亂的用戶單 位，還必須邀請領(lǐng)域?qū)＜疫M(jìn)行合理的機(jī)構(gòu)調(diào)整和業(yè)務(wù)流程優(yōu)化。 組織機(jī)構(gòu)分析的結(jié)果，應(yīng)該以組織機(jī)構(gòu)圖的方式呈現(xiàn)；業(yè)務(wù)流程分析的結(jié)果， 應(yīng)該以業(yè)務(wù)流程圖的方式呈現(xiàn)，每個業(yè)務(wù)流程有一個單獨(dú)的業(yè)務(wù)流程圖。如 果采用面向?qū)ο蠓椒ㄟM(jìn)行現(xiàn)狀分析，可以用一個總括的業(yè)務(wù)用例圖來描述所 有業(yè)務(wù)，每個業(yè)務(wù)就是一個業(yè)務(wù)用例，每個業(yè)務(wù)用例有一個單獨(dú)的業(yè)務(wù)流程 圖。 各種需求的收集，主要來源于現(xiàn)狀分析。通過與用戶合作，了解用戶期望實(shí) 現(xiàn)業(yè)務(wù)流程的自動化環(huán)節(jié)，以及其他的一些非功能性需求或約束條件。需求 收集中的功能需求，更是直接來源于業(yè)務(wù)分析的結(jié)果，功能性需求可以用功 能結(jié)構(gòu)圖的方式呈現(xiàn)，其他需求

49、以文字的方式呈現(xiàn)。 1.6 軟件開發(fā)過程的建模與文檔 粗略設(shè)計是對準(zhǔn)備開發(fā)的軟件系統(tǒng)提出高層模型。高層模 型通常包括描述軟件系統(tǒng)抽象構(gòu)成的體系結(jié)構(gòu)圖、描述硬 件設(shè)施和網(wǎng)絡(luò)構(gòu)成的網(wǎng)絡(luò)拓?fù)鋱D（結(jié)構(gòu)化方法）、描述系 統(tǒng)軟件構(gòu)成的系統(tǒng)流程圖（結(jié)構(gòu)化方法）/組件圖（面向 對象方法）、描述功能需求收集結(jié)果的功能結(jié)構(gòu)圖、描述 未來系統(tǒng)配置的系統(tǒng)架構(gòu)圖（結(jié)構(gòu)化方法或面向?qū)ο蠓椒ǎ?/構(gòu)件圖（面向?qū)ο蠓椒ǎ?。由于粗略設(shè)計往往不是以精 確的需求分析結(jié)果為基礎(chǔ)，因此允許存在些許遺漏、錯誤。 可行性分析是針對準(zhǔn)備進(jìn)行的軟件項(xiàng)目進(jìn)行的可行性風(fēng)險 評估。因此，并根據(jù)高層模型的特征，從技術(shù)可行性、經(jīng) 濟(jì)可行性和操作可行性等

50、幾個方面，對項(xiàng)目作出是否值得 往下進(jìn)行的回答，由此決定項(xiàng)目是否繼續(xù)進(jìn)行下去。 1.6 軟件開發(fā)過程的建模與文檔 項(xiàng)目前期的技術(shù)文檔，主要包括“需求說明書”、“技術(shù)應(yīng)答 書”、“軟件任務(wù)立項(xiàng)報告”、“可行性研究報告”。 “需求說明書”主要按條目羅列用戶關(guān)于未來軟件系統(tǒng)的功能 性和非功能性需求； “技術(shù)應(yīng)答書”主要按條目羅列用戶關(guān)心的技術(shù)問題以及未來 擬應(yīng)對的策略； “軟件任務(wù)立項(xiàng)報告”主要針對項(xiàng)目的名稱、性質(zhì)、目標(biāo)、意 義和規(guī)模等作出回答，呈現(xiàn)現(xiàn)狀分析的結(jié)果，并在文檔中給出 對準(zhǔn)備著手開發(fā)的軟件系統(tǒng)的粗略設(shè)計結(jié)果，包括軟件系統(tǒng)體 系結(jié)構(gòu)圖、描述網(wǎng)絡(luò)構(gòu)成的網(wǎng)絡(luò)拓?fù)鋱D、系統(tǒng)流程圖（結(jié)構(gòu)化 方法）/構(gòu)

51、件圖（面向?qū)ο蠓椒ǎ?，以及需求收集結(jié)果的功能結(jié) 構(gòu)圖。 “可行性研究報告”除了涵蓋“軟件任務(wù)立項(xiàng)報告”的內(nèi)容之 外，還有增加可行性分析的相關(guān)信息。 1.6 軟件開發(fā)過程的建模與文檔 （2）需求分析 需求分析是軟件開發(fā)的最關(guān)鍵步驟，其結(jié)論不僅是今后軟件開 發(fā)的基本依據(jù)，同時也是今后用戶對軟件產(chǎn)品進(jìn)行驗(yàn)收的基本 依據(jù)。需求分析要求以用戶需求為基本依據(jù)，從功能、性能、 數(shù)據(jù)、操作等多個方面，對軟件系統(tǒng)給出完整、準(zhǔn)確、具體的 描述，用于確定軟件規(guī)格。 軟件需求分析是應(yīng)以項(xiàng)目前期的工作（尤其是現(xiàn)狀分析的結(jié)果） 為基礎(chǔ)，是軟件規(guī)格描述的具體化與細(xì)節(jié)化。其結(jié)果以數(shù)據(jù)流+ 數(shù)據(jù)字典（結(jié)構(gòu)化方法）、用例模型（面向?qū)ο蠓椒ǎ?述所有用例的用例圖和每個用例的流程圖）呈現(xiàn)。在某些場合， 面向?qū)ο蠓椒梢栽谛枨蠓治鲭A段建立反映問題域數(shù)據(jù)信息的 類模型（也稱分析類或?qū)嶓w類）。需求分析的結(jié)果以“軟件需 求規(guī)格說明書”的文檔形式提交。 1.6 軟件開發(fā)過程的建模與文檔 “軟件需求規(guī)格說明書”主要由以下及部分組成： 引言：編寫目的、背景說明、術(shù)語定義及參考資料等。 概述主要功能、約束條件或特殊需求。 數(shù)據(jù)流圖與數(shù)據(jù)字典（結(jié)構(gòu)化方法）、用例模型（面向?qū)?象方法）。 用戶接口、硬件接口及軟件接口。 性能需求、屬性等。 其它需