第3章軟件開發(fā)過程管理第3章軟件開發(fā)過程管理本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟件開發(fā)生命周期模型

擴展軟件開發(fā)生命周期模型

3.1質(zhì)量計劃

3.4案例分析

3.5本章小結(jié)

3.6復(fù)習(xí)思考題

3.73.23.3本章內(nèi)容提要CMM和ISO9000傳統(tǒng)軟件開發(fā)生命周期模型

軟件過程是指人們用于開發(fā)和維護軟件及其相關(guān)產(chǎn)品的一系列活動、方法、實踐和革新。軟件開發(fā)過程管理是指在軟件開發(fā)過程中，除了先進技術(shù)和開發(fā)方法外，還有一整套的管理技術(shù)。軟件過程改進是針對軟件生產(chǎn)過程中會對產(chǎn)品質(zhì)量產(chǎn)生影響的問題而進行的，它的直接結(jié)果是軟件過程能力的提高?，F(xiàn)在常見的軟件過程改進方法：ISO9000，SW-CMM和由多種能力模型演變而來的CMMI。3.1CMM和ISO9000軟件過程3.1CMM和ISO90003.1.1SW-CMM和CMMI

SW-CMM簡介為了保證軟件產(chǎn)品的質(zhì)量，1991年美國卡內(nèi)基·梅隆大學(xué)軟件工程研究所（CMU/SEI）將軟件過程成熟度框架進化為軟件能力成熟度模型（CapabilityMaturityModelForSoftware，簡稱SW-CMM），并發(fā)布了最早的SW-CMM1.0版。

SW-CMM為軟件企業(yè)的過程能力提供了一個階梯式的進化框架，階梯共有五級。3.1.1SW-CMM和CMMISW-CMM簡介3.1.1SW-CMM和CMMI1初始級2可重復(fù)級3已定義級4已管理級5優(yōu)化級無序、混亂的軟件過程。依賴個別人的努力和機遇。建立基本的項目管理過程。相似項目，重復(fù)以往成果。文檔化、標(biāo)準(zhǔn)化和標(biāo)準(zhǔn)的軟件軟件過程。軟件過程和產(chǎn)品質(zhì)量有詳細(xì)的度量標(biāo)準(zhǔn)。持續(xù)的對過程進行改進。圖CMM分級標(biāo)準(zhǔn)3.1.1SW-CMM和CMMI1初始級2可重復(fù)級3.1.1SW-CMM和CMMIKPA及KP除第一級外，SW-CMM的每一級都是按完全相同的結(jié)構(gòu)組成的。每一級包含了實現(xiàn)這一級目標(biāo)的若干關(guān)鍵過程域（KPA），每個KPA進一步包含若干關(guān)鍵實施活動（KP），無論哪個KPA，它們的實施活動都統(tǒng)一按六個公共屬性進行組織，即每一個KPA都包含六類KP：

1.目標(biāo)

2.實施保證

3.實施能力

4.執(zhí)行活動

5.度量分析

6.實施驗證3.1.1SW-CMM和CMMIKPA及KP3.1.1SW-CMM和CMMICMMI簡介由于不同領(lǐng)域能力成熟度模型存在不同的過程改進，重復(fù)的培訓(xùn)、評估和改進活動以及活動不協(xié)調(diào)等一些問題。于是由美國國防部出面，美國卡內(nèi)基·梅隆大學(xué)軟件工程研究所（CMU/SEI）于2001年12月發(fā)布的CMMI1.1版本包括四個領(lǐng)域：軟件工程（SW）、系統(tǒng)工程（SE）、集成的產(chǎn)品和過程開發(fā)（IPPD）、采購（SS）。3.1.1SW-CMM和CMMICMMI簡介3.1.1SW-CMM和CMMI

CMMI有兩種不同的實施方法連續(xù)式－－主要是衡量一個企業(yè)的項目能力階段式－－主要是衡量一個企業(yè)的成熟度連續(xù)式與階段式所包含的過程域是完全一致的。兩者的區(qū)別主要在于過程域的組織方式不同，階段式是用來描述組織整體上的成熟度，而連續(xù)式關(guān)注的是組織單個過程域的能力。如果組織注意力主要集中在某幾個過程域上時，則采用連續(xù)式比較合適3.1.1SW-CMM和CMMICMMI有兩種

CMMI的五個臺階完成級管理級定義級量化管理級優(yōu)化級

每一個臺階都是上面一階臺階的基石。要上高層臺階必須首先踏上較低一層臺階。

CMMI的五個臺階與SW-CMM

的結(jié)構(gòu)相比，

CMMI

的模型結(jié)構(gòu)顯得更加復(fù)雜與精細(xì)。

CMMI

從過程域所有的實踐提煉出了多個過程域所共有的實踐，稱為一般實踐，將其目標(biāo)稱為一般目標(biāo)，其余特定于某個過程域的實踐與目標(biāo)稱為特定實踐與特定目標(biāo)。這樣模型取得了相對

SW-CMM

更高的抽象度與適應(yīng)范圍。目標(biāo)（一般目標(biāo)與特定目標(biāo)）首次作為模型構(gòu)成成分出現(xiàn)，這表明CMMI

對過程活動的結(jié)果投入了更多的關(guān)注。

與SW-CMM

的結(jié)構(gòu)相比，

CMMI

的模型結(jié)構(gòu)顯得更加復(fù)3.1.2ISO9000質(zhì)量標(biāo)準(zhǔn)

ISO9000

所謂“ISO9000”不是指一般意義上的一個質(zhì)量保證標(biāo)準(zhǔn)，而是一族系列標(biāo)準(zhǔn)的統(tǒng)稱。

作用強化品質(zhì)管理，提高企業(yè)效益；增強客戶信心，擴大市場份額；獲得了國際貿(mào)易“通行證”，消除了國際貿(mào)易壁壘；節(jié)省了第二方審核的精力和費用；在產(chǎn)品品質(zhì)競爭中永遠(yuǎn)立于不敗之地；有效地避免產(chǎn)品責(zé)任；有利于國際間的經(jīng)濟合作和技術(shù)交流。3.1.2ISO9000質(zhì)量標(biāo)準(zhǔn)ISO9000作用3.1.3三者之間的比較

選擇SW-CMM還是CMMI的考慮實施企業(yè)的業(yè)務(wù)特點。實施企業(yè)的業(yè)務(wù)特點：如果企業(yè)的規(guī)模不是很大，業(yè)務(wù)又集中在軟件開發(fā)為主，那么還是軟件CMM比較適用。如果企業(yè)的規(guī)模比較大（開發(fā)人員100人以上），并且業(yè)務(wù)不僅僅集中在軟件開發(fā)，還包括硬件開發(fā)哪怕是硬件代理（采購）都可以考慮實施CMMI。3.1.3三者之間的比較選擇SW-CMM還是CMM實施企業(yè)對過程改進的熟悉程度：如果企業(yè)已經(jīng)實施過ISO9000，并且取得了較好的效果，那么可以考慮實施CMMI。如果企業(yè)雖然沒有實施過CMM，但是對于過程改進一直比較關(guān)注，接受過不少相關(guān)培訓(xùn)，甚至能夠自發(fā)的進行一些過程改進，那么也可以考慮實施CMMI。如果過去沒有接觸過類似的工作，那么最好先從軟件CMM2級開始，首先建立持續(xù)過程改進的思路。另外，軟件CMM的要求也比CMMI要稍低一些?？梢赃m當(dāng)降低實施的難度實施企業(yè)對過程改進的熟悉程度：如果企業(yè)已經(jīng)實施過ISO9實施企業(yè)對過程改進的熟悉程度。實施企業(yè)對過程改進的熟悉程度：如果企業(yè)已經(jīng)實施過ISO9000，并且取得了較好的效果，那么可以考慮實施CMMI。如果企業(yè)雖然沒有實施過CMM，但是對于過程改進一直比較關(guān)注，接受過不少相關(guān)培訓(xùn)，甚至能夠自發(fā)的進行一些過程改進，那么也可以考慮實施CMMI。如果過去沒有接觸過類似的工作，那么最好先從軟件CMM2級開始，首先建立持續(xù)過程改進的思路。另外，軟件CMM的要求也比CMMI要稍低一些?？梢赃m當(dāng)降低實施的難度實施企業(yè)對過程改進的熟悉程度。實施企業(yè)對過程改進項目的預(yù)算。實施企業(yè)對過程改進項目的預(yù)算：不論怎樣，幾乎可以肯定地說，實施CMMI的費用肯定要比實施CMM高出一些。而就模型本身來看，CMMI的2級7個過程區(qū)域在內(nèi)容上并不比軟件CMM的2級6個關(guān)鍵過程區(qū)域多多少。這樣的話，我們完全可以“少花錢、多辦事”，也就是說可以采用CMM的實施和評估方法，但可以在過程改進的時候參考CMMI的要求，這樣就經(jīng)濟很多。實施企業(yè)對過程改進項目的預(yù)算。----實施企業(yè)是否可以使用階段式的演進路線：如果企業(yè)只希望單方面的提高自己在項目管理、工程活動、支持活動或者過程管理四個方面中的某些方面的能力，那么就只能應(yīng)用CMMI的連續(xù)表示方法。如果實施企業(yè)可以接受成熟度級別的思路（目前看國內(nèi)大多數(shù)企業(yè)還是比較習(xí)慣于成熟度級別的），那么就不一定必須選擇CMMI了。----實施企業(yè)是否可以使用階段式的演進路線----------實施CMM與CMMI可以平滑的轉(zhuǎn)換。

CMMI并不要求一家企業(yè)必須先做CMMI的2級然后再向更高的成熟級別演進，評估的時候也沒有這樣的要求。另外，CMMI的評估都會根據(jù)被評估的成熟度級別，檢查所有不高于該級別的過程區(qū)域。換句話說，一個企業(yè)在CMM正式評估中達(dá)到了2級的成熟度，將來改為基于CMMI進行過程改進。在CMMI3級的正式評估時，CMMI2級的內(nèi)容同樣要進行檢查。如果我們能夠在做CMM2級的時候就按照CMMI的要求實施，效果沒有任何的折扣，但對于實施企業(yè)來說，會節(jié)省很多在培訓(xùn)和評估方面的“額外”費用。（此處的“額外”費用是指CMMI收費比CMM高出的部分）----------實施CMM與CMMI可以平滑的轉(zhuǎn)換。

C

ISO9001與CMM的關(guān)系ISO9001和CMM既有區(qū)別又相互聯(lián)系，兩者不可簡單地互相替代。取得ISO9001認(rèn)證并不意味著完全滿足CMM某個等級的要求。取得CMM第2級(或第3級)不能籠統(tǒng)地認(rèn)為可以滿足ISO9001的要求。ISO9001與CMM的關(guān)系案例1W公司為了推行CMM，組建了獨立的QA部門。盡管在W公司的內(nèi)部宣傳材料上對QA的作用進行了大肆的宣傳，認(rèn)為其對于CMM的推行和項目管理都具有重要作用，但是實際上QA人員的資歷都相對較淺，對開發(fā)過程，技術(shù)和工具都缺乏必要的了解。只能夠照搬一些條文來要求開發(fā)人員，開發(fā)人員對此并不認(rèn)賬，認(rèn)為QA人員是沒事找事。另外，QA這個崗位在薪酬和升遷方面毫不吸引人案例1W公司為了推行CMM，組建了獨立的QA部門。盡管在W公為了避免QA部門成為新手和項目組淘汰人員的集中地，QA部門經(jīng)理設(shè)法推行項目經(jīng)理鍛煉制度，讓項目經(jīng)理到QA部門鍛煉一段時間，然后繼續(xù)擔(dān)任項目經(jīng)理或者升遷。但是因為此項制度沒有得到有效的支持，項目經(jīng)理在QA部門工作一段時間以后竟然沒有開發(fā)部門愿意接收，就更談不上升遷了。QA部門在W公司的威望江河日下。為了避免QA部門成為新手和項目組淘汰人員的集中地，QA部門經(jīng)QA人員對于質(zhì)量保證和CMM的實施至關(guān)重要，如果我們認(rèn)可QA人員對于公司的價值，那就必須在人才和待遇上向QA部門傾斜QA人員對于質(zhì)量保證和CMM的實施至關(guān)重要，如果我們認(rèn)可QAH公司和Z公司都在研發(fā)相同類型的C產(chǎn)品。H公司在推廣CMM，采用了相對嚴(yán)格的過程規(guī)范，并且把相對重要的部分外包給了印度的CMM5級公司。這些手段Z公司都沒有采用，但是Z公司卻搶在了前面。

Z公司的“秘密武器”是一種形式化語言—SDL，Z公司采用SDL作為設(shè)計工具，這樣C產(chǎn)品的相當(dāng)一部分代碼可以由SDL工具自動生成，而且在設(shè)計階段就可以進行仿真運行，這樣就大大地提高了效率并減少了缺陷。H公司雖然采用了相對嚴(yán)格的過程規(guī)范，但是因為全部代碼為手工編制，所以，無論是效率還是質(zhì)量，H公司都落后了H公司和Z公司都在研發(fā)相同類型的C產(chǎn)品。H公司在推廣CMM，H公司顯然忽視了先進技術(shù)可能為生產(chǎn)率帶來的進步，通過了CMM高級別的評估，只能說明被評估的組織機構(gòu)在過程控制上做得更加細(xì)致，但是并不能夠保證你的開發(fā)過程是高效的。某些沉迷于CMM的組織機構(gòu)忘記了先進的軟件工程技術(shù)的重要性H公司顯然忽視了先進技術(shù)可能為生產(chǎn)率帶來的進步，通過了CMM本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟件開發(fā)生命周期模型擴展軟件開發(fā)生命周期模型

3.1質(zhì)量計劃

3.4案例分析

3.5本章小結(jié)

3.6復(fù)習(xí)思考題

3.73.23.3本章內(nèi)容提要CMM和ISO9000傳統(tǒng)軟件開發(fā)生命周期模型

軟件生命周期軟件從需求確定、設(shè)計、開發(fā)、測試直至投入使用，并在使用中不斷地修改、增補和完善，直至被新的系統(tǒng)所替代而停止該軟件的使用的全過程。

可劃分為以下子階段

1.可行性研究

2.需求分析和定義

3.總體設(shè)計

4.詳細(xì)設(shè)計

5.編碼（實現(xiàn)）

6.軟件測試、運行/維護據(jù)此相繼產(chǎn)生了瀑布模型、螺旋模型、進化模型、原型模型、增量模型等。本節(jié)分別對這幾種傳統(tǒng)的軟件開發(fā)生命周期模型予以介紹。

3.2傳統(tǒng)軟件開發(fā)生命周期模型軟件生命周期3.2傳統(tǒng)軟件開發(fā)生命周期模型3.2.1瀑布模型系統(tǒng)需求軟件需求分析設(shè)計編碼測試運行瀑布模型總結(jié)文檔驅(qū)動的模型階段間具有順序性和依賴性項目開發(fā)周期較長實際項目很少按照該模型給出的順序進行3.2.1瀑布模型系統(tǒng)需求軟件需求分析設(shè)計編碼測試運行瀑瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有重要的地位，它提供了軟件開發(fā)的基本框架。瀑布模型的本質(zhì)是一次通過，即每個活動只執(zhí)行一次，最后得到軟件產(chǎn)品，也稱為“線性順序模型”或者“傳統(tǒng)生命周期”。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應(yīng)完成的內(nèi)容給出該項活動的工作成果。并作為輸出傳給下一項活動。同時評審該項活動的實施，若確認(rèn)，則繼續(xù)下一項活動；否則返回前面，甚至更前面的活動。瀑布模型有利于大型軟件開發(fā)過程中人員的組織及管理，

瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有重要的地位瀑布模型的優(yōu)點：（1）它提供了一個模版，這個模板使得分析，設(shè)計，編碼，測試和支持的方法可以在該模板下有一個共同的指導(dǎo)標(biāo)準(zhǔn)。（2）雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好的多。瀑布模型的優(yōu)點：缺點：大部分情況下，實際的項目難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。顧客的需求難以表達(dá)真正的額外需要?？蛻粢鹊介_發(fā)周期的晚期才能看到程序運行的測試版本，如果發(fā)生錯誤，有可能是災(zāi)難的。采用這種線性模型，會經(jīng)常在過程的開始和結(jié)束時碰到等待其他成員完成其所依賴的任務(wù)才能進行下去。

缺點：3.2.2原型模型3.2.2原型模型3.2.2原型模型Prototypingmodel特點在需求定義之前，需要快速構(gòu)建一個系統(tǒng)根據(jù)構(gòu)建系統(tǒng)的優(yōu)缺點，用戶給開發(fā)人員提出反饋意見根據(jù)反饋意見修改軟件需求規(guī)格，以便系統(tǒng)可以更正確地反映用戶的需求減少各種假設(shè)以及風(fēng)險3.2.2原型模型Prototypingmodel特軟件開發(fā)過程管理課件原型的分類①廢棄型：先構(gòu)造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，針對這個模型系統(tǒng)反復(fù)進行分析修改，形成比較好的設(shè)計思想，據(jù)此設(shè)計出更加完整、準(zhǔn)確、一致、可靠的最終系統(tǒng)。系統(tǒng)構(gòu)造完成后，原來的模型系統(tǒng)就被廢棄不用。②追加型或演化型：先構(gòu)造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，作為最終系統(tǒng)的核心，然后通過不斷地擴充修改，逐步追加新要求，最后發(fā)展成為最終系統(tǒng)。

原型的分類3.2.3增量模型當(dāng)使用增量模型時，第1個增量往往是核心的產(chǎn)品，即第1個增量實現(xiàn)了基本的需求，但很多補充的特征還沒有發(fā)布?？蛻魧γ恳粋€增量的使用和評估都作為下一個增量發(fā)布的新特征和功能，這個過程在每一個增量發(fā)布后不斷重復(fù)，直到產(chǎn)生了最終的完善產(chǎn)品。增量模型強調(diào)每一個增量均發(fā)布一個可操作的產(chǎn)品。采用增量模型的軟件過程如下圖所示：3.2.3增量模型當(dāng)使用增量模型時，第1個增量往往是核1.4.3增量模型圖1.5增量模型1.4.3增量模型圖1.5增量模型所示的增量模型表明，必須在開始實現(xiàn)各個構(gòu)件之前就全部完成需求分析、規(guī)格說明和概要設(shè)計的工作。由于在開始構(gòu)建第一個構(gòu)件之前已經(jīng)有了總體設(shè)計，因此風(fēng)險較小所示的增量模型表明，必須在開始實現(xiàn)各個構(gòu)件之前就全部完成需求圖1.6風(fēng)險更大的增量模型1.4.3增量模型1.4.3增量模型描繪了一種風(fēng)險更大的增量模型：一旦確定了用戶需求之后，就著手?jǐn)M定第一個構(gòu)件的規(guī)格說明文檔，完成后規(guī)格說明組將轉(zhuǎn)向第二個構(gòu)件的規(guī)格說明，與此同時設(shè)計組開始設(shè)計第一個構(gòu)件……用這種方式開發(fā)軟件，不同的構(gòu)件將并行地構(gòu)建，因此有可能加快工程進度。但是，使用這種方法將冒構(gòu)件無法集成到一起的風(fēng)險，除非密切地監(jiān)控整個開發(fā)過程，否則整個工程可能毀于一旦。描繪了一種風(fēng)險更大的增量模型：一旦確定了用戶需求之后，就著手漸增模型與快速原型的相同之處是其迭代的特征，不同之處是漸增模型的每一輪都得到一個用戶可真正使用和操作的完整版本，而快速原型每一輪得到的是在性能和功能上大大簡化的版本。優(yōu)點:(1)漸增模型對項目組的組成人員不是非常充裕的情況下十分有用。早期對基本系統(tǒng)的開發(fā)需要的人員比較少，后續(xù)的各輪開發(fā)可以根據(jù)需要補充人員。此外，這種增量式的開發(fā)，可以有效地防止技術(shù)風(fēng)險。(2)漸增模型每一輪都可以向用戶發(fā)布一個高質(zhì)量的可操作的版本。用戶容易接受并可以提出中肯的意見，不需要非常大的原始資金投入。缺點：由于要求下一輪新增的功能能夠無縫集成到上一輪系統(tǒng)中去，如果整體結(jié)構(gòu)設(shè)計不當(dāng)，則有可能導(dǎo)致整個軟件的結(jié)構(gòu)變差。1.4.3增量模型實例三?

基于工作流的科技項目管理系統(tǒng)項目信息發(fā)布項目信息分類項目信息集成項目協(xié)同工作項目過程支持個性化設(shè)置項目管理信息數(shù)據(jù)服務(wù)項目監(jiān)控與評價數(shù)據(jù)服務(wù)應(yīng)用系統(tǒng)集成服務(wù)通訊服務(wù)統(tǒng)一編碼體系項目組織管理項目過程控制項目數(shù)據(jù)分析項目流程管理項目知識管理生命周期管理工作流定義消息組件權(quán)限與安全工作流平臺動態(tài)工作流引擎協(xié)同工作引擎資源管理29漸增模型與快速原型的相同之處是其迭代的特征，不同之處是漸增優(yōu)點1)由于能夠在較短的時間內(nèi)向用戶提交一些有用的工作產(chǎn)品，因此能夠解決用戶的一些急用功能。2）由于每次只提交用戶部分功能，用戶有較充分的時間學(xué)習(xí)和適應(yīng)新的產(chǎn)品。3）對系統(tǒng)的可維護性是一個極大的提高，因為整個系統(tǒng)是由一個個構(gòu)件集成在一起的，當(dāng)需求變更時只變更部分部件，而不必影響整個系統(tǒng)。缺點優(yōu)點增量模型存在以下缺陷：1）由于各個構(gòu)件是逐漸并入已有的軟件體系結(jié)構(gòu)中的，所以加入構(gòu)件必須不破壞已構(gòu)造好的系統(tǒng)部分，這需要軟件具備開放式的體系結(jié)構(gòu)。2）在開發(fā)過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。3）如果增量包之間存在相交的情況且未很好處理，則必須做全盤系統(tǒng)分析，這種模型將功能細(xì)化后分別開發(fā)的方法較適應(yīng)于需求經(jīng)常改變的軟件開發(fā)過程。增量模型存在以下缺陷：3.2.3增量模型

增量模型總結(jié)融合了瀑布模型和原型的迭代特征。每一個增量均發(fā)布一個可操作產(chǎn)品。3.2.3增量模型增量模型總結(jié)3.2.4進化模型建造/修改原型聽取用戶意見用戶測試運行原型

這個模型可看作是重復(fù)執(zhí)行的多個瀑布模型。3.2.4進化模型建造/修改聽取用戶用戶測試這個模3.2.5螺旋模型原型1原型2原型3可運行原型需求計劃生存期計劃開發(fā)計劃集成與測試軟件需求需求確認(rèn)設(shè)計確認(rèn)與驗證

軟件產(chǎn)品設(shè)計詳細(xì)設(shè)計風(fēng)險分析風(fēng)險分析風(fēng)險分析驗收測試實現(xiàn)集成與測試單元測試編碼開發(fā)、驗證下一產(chǎn)品實施工程提交線評審累計成本風(fēng)險分析評價方案，識別風(fēng)險、消除風(fēng)險制訂計劃決定目標(biāo)方案和限制客戶評估3.2.5螺旋模型原型1原型2原型3可運行需求計劃開發(fā)計構(gòu)建原型是一種能使某些類型的風(fēng)險降至最低的方法。為了降低交付給用戶的產(chǎn)品不能滿足用戶需要的風(fēng)險，一種行之有效的方法是在需求分析階段快速地構(gòu)建一個原型。在后續(xù)的階段中也可以通過構(gòu)造適當(dāng)?shù)脑蛠斫档湍承┘夹g(shù)風(fēng)險。當(dāng)然，原型并不能“包治百病”，對于某些類型的風(fēng)險，原型方法是無能為力的。螺旋模型的基本思想:使用原型及其他方法來盡量降低風(fēng)險。理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風(fēng)險分析過程的快速原型模型。完整的螺旋模型如圖。螺旋模型構(gòu)建原型是一種能使某些類型的風(fēng)險降至最低的方法。為了圖：簡化的螺旋模型圖：簡化的螺旋模型優(yōu)點：對可選方案和約束條件的強調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標(biāo)；減少了過多測試（浪費資金）或測試不足（產(chǎn)品故障多）所帶來的風(fēng)險；更重要的是，在螺旋模型中維護只是模型的另一個周期，在維護和開發(fā)之間并沒有本質(zhì)區(qū)別。

主要優(yōu)勢:它是風(fēng)險驅(qū)動的，但這也可能是其弱點。除非軟件開發(fā)人員具有豐富的風(fēng)險評估經(jīng)驗和這方面的專門知識，否則將出現(xiàn)真正的風(fēng)險。當(dāng)項目實際上正在走向災(zāi)難時，開發(fā)人員可能還認(rèn)為一切正常。優(yōu)點：對可選方案和約束條件的強調(diào)有利于已有軟件

螺旋模型主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項目。如果進行風(fēng)險分析的費用接近整個項目的經(jīng)費預(yù)算，則風(fēng)險分析是不可行的。事實上，項目越大，風(fēng)險也越大，因此，進行風(fēng)險分析的必要性也越大。此外，只有內(nèi)部開發(fā)的項目，才能在風(fēng)險過大時方便地中止項目。

3.2.5螺旋模型

螺旋模型總結(jié)

基于風(fēng)險驅(qū)動的開發(fā)模型,使用原型法或其它方法來盡量降低風(fēng)險。適用于需求不明確的大規(guī)模軟件項目3.2.5螺旋模型螺旋模型總結(jié)本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟件開發(fā)生命周期模型

擴展軟件開發(fā)生命周期模型

3.1質(zhì)量計劃

3.4案例分析

3.5本章小結(jié)

3.6復(fù)習(xí)思考題

3.73.23.3本章內(nèi)容提要CMM和ISO9000傳統(tǒng)軟件開發(fā)生命周期模型3.3.1極限模型極限模型簡介

2001年，為了避免許多公司的軟件團隊陷入不斷增長的過程泥潭，一批業(yè)界專家一起概括出了一些敏捷開發(fā)過程的方法：SCRUM，Crystal，特征驅(qū)動軟件開發(fā)（FeatureDrivenDevelopment，簡稱FDD），自適應(yīng)軟件開發(fā)（AdaptiveSoftwareDevelopment，簡稱ASD），以及最重要的極限編程（eXtremeProgramming,簡稱XP）。

3.3.1極限模型極限模型簡介3.3.1極限模型極限編程將開發(fā)階段的4個活動（分析、設(shè)計、編碼和測試）混合在一起，在全過程中采用迭代增量開發(fā)、反饋修正和反復(fù)測試。

3.3.1極限模型極限編程將開發(fā)階段的4個活動（分析、探索階段探索階段的主要工作是開發(fā)初始的用戶故事（UserStories）和體系結(jié)構(gòu)骨架（architecturespike）。用戶故事描述了系統(tǒng)高層的需求，它是制訂發(fā)布計劃的輸入。在探索階段，試探找到系統(tǒng)中固定不變的部分（體系結(jié)構(gòu)骨架），并找出一種形象的比喻，這種比喻描述了你打算如何構(gòu)建系統(tǒng)，起到概念框架的作用。探索階段還應(yīng)根據(jù)用戶故事編制相應(yīng)的測試用例，供以后驗收測試時使用。探索階段計劃階段計劃階段的任務(wù)是根據(jù)用戶故事描述的需求、系統(tǒng)體系結(jié)構(gòu)骨架和系統(tǒng)比喻來制訂迭代計劃和發(fā)布計劃。使用你最熟悉的形式為用戶故事建模，這個模型描述了用戶故事的任務(wù)以及這些任務(wù)之間的關(guān)系。通常圖形方式（可以是草圖）比文字描述更直觀。盡可能精確地估算工作量，這是制訂計劃的重要依據(jù)。對于那些不能確切估算其工作量的難點部分，要進一步作分析，直至能確定其工作量估算。計劃階段迭代到發(fā)布階段迭代到發(fā)布階段根據(jù)迭代和發(fā)布計劃，開發(fā)滿足指定用戶故事需求的軟件，并與前面已完成的軟件版本集成，得到軟件的一個新版本。根據(jù)在探索階段編寫的測試用例，進行驗收測試。一旦發(fā)現(xiàn)錯誤或者通過驗收測試想進入下一輪迭代時，就重復(fù)迭代開發(fā)的工作。在這一階段當(dāng)客戶提出新的用戶故事，或者根據(jù)項目的進展情況認(rèn)為有必要時，可以回到計劃階段，對迭代和發(fā)布計劃做出修改或調(diào)整。迭代到發(fā)布階段產(chǎn)品化階段產(chǎn)品化階段的工作主要是確認(rèn)迭代開發(fā)的軟件已經(jīng)做好進入產(chǎn)品化的準(zhǔn)備。在此階段可進行更多的測試，如系統(tǒng)測試、負(fù)載測試、安裝測試等。另一個工作就是整理文檔。雖然敏捷軟件開發(fā)的價值觀中強調(diào)“可運行軟件高于詳盡的文檔”，但是，必要的文檔仍是需要的。產(chǎn)品化階段可能要寫的文檔：系統(tǒng)文檔系統(tǒng)文檔的目的在于為系統(tǒng)提供一個總覽，來幫助人們理解它。主要包括：系統(tǒng)技術(shù)體系結(jié)構(gòu)和業(yè)務(wù)體系結(jié)構(gòu)的總覽、高層次的系統(tǒng)需求、關(guān)鍵設(shè)計決策的總結(jié)、體系結(jié)構(gòu)圖以及重要的設(shè)計模型（如果有的話）等。操作文檔操作文檔的內(nèi)容包括：系統(tǒng)涉及的依賴關(guān)系，與其他系統(tǒng)、數(shù)據(jù)庫以及文件文互的特性，對備份流程的參考引用，系統(tǒng)的聯(lián)系人列表以及聯(lián)系方法，系統(tǒng)的適用性及可靠性需求的總結(jié)，系統(tǒng)預(yù)期負(fù)載情況概況，以及排錯指導(dǎo)原則?？赡芤獙懙奈臋n：支持文檔支持文檔的內(nèi)容包括：支持人員專用的培訓(xùn)教材，解決問題時作為參考的用戶文檔，排錯指導(dǎo)原則，解決疑難問題時的上報流程，以及維護團隊的聯(lián)系列表。用戶文檔參考手冊用于快速查詢；用戶指南用于指明系統(tǒng)的工作方式；支持指南用于指導(dǎo)如何獲取其他的幫助；培訓(xùn)資料則主要用于培訓(xùn)。支持文檔維護階段維護階段涵蓋了計劃階段、迭代到發(fā)布階段和產(chǎn)品化階段通常這個階段主要包括面向產(chǎn)品的活動，如系統(tǒng)的運行和支持。維護階段3.3.1極限模型XP開發(fā)模型核心思想：交流（Communication）簡單（Simplicity）反饋（Feedback）進?。ˋggressiveness）

3.3.1極限模型XP開發(fā)模型核心思想：交流（Communication）實踐表明，項目失敗的重要原因之一是交流不暢，使得客戶的需求不能準(zhǔn)確地傳遞給開發(fā)人員，造成開發(fā)人員不能充分理解需求；模型或設(shè)計的變動未能及時告知相關(guān)人員，造成系統(tǒng)的不一致和集成的困難所有項目相關(guān)人員之間充分的有效的交流是軟件開發(fā)成功所必不可少的XP方法提倡面對面的交流，這是一種有效的也是效率最高的交流方式交流（Communication）簡單（Simplicity）指在確保得到客戶滿意的軟件的前提下，做最簡潔的工作（簡單的過程、模型、文檔、設(shè)計和實現(xiàn)）在開發(fā)中不斷優(yōu)化設(shè)計，時刻保持代碼簡潔、無冗余體現(xiàn)了敏捷開發(fā)的“剛剛好(Justenough)”思想，即開發(fā)中的活動及制品既不要太多也不要太少，剛好即可簡單（Simplicity）反饋（Feedback）及時有效的反饋能確定開發(fā)工作是否正確，及時發(fā)現(xiàn)開發(fā)工作的偏差并加以糾正。強調(diào)各種形式的反饋，如非正式的評審（走查，Walkthrough）、小發(fā)布等反饋（Feedback）進取信任合作的同事，也相信自己做能做到的最簡單的事只有在絕對需要的時候才創(chuàng)建文檔讓業(yè)務(wù)人員制定業(yè)務(wù)決策，技術(shù)人員制定技術(shù)決策用可能的最簡單的工具，例如白板和紙，只有在復(fù)雜建模工具能提供可能的最好價值時才去使用它們相信程序員能制定設(shè)計決策，不需要給他們提供過多的細(xì)節(jié)需要勇氣來承認(rèn)自己是會犯錯誤的，需要勇氣來相信自己明天能克服明天出現(xiàn)的問題。進取XP方法的12個核心實踐1.完整的團隊（WholeTeam）所有的小組成員應(yīng)在同一個工作地點工作成員中必須有一個現(xiàn)場用戶（On-siteUser）由他提出需求，確定開發(fā)優(yōu)先級通常還設(shè)一個“教練”（Coach）角色

教練指導(dǎo)XP方法的實施，以及與外部的溝通和協(xié)調(diào)2.計劃對策（PlanningGame）

包括兩類：發(fā)布計劃和迭代（Iteration）計劃XP方法的12個核心實踐1.完整的團隊（WholeTeam3.系統(tǒng)比喻（Metaphor）

系統(tǒng)比喻是待開發(fā)軟件的一個每個成員都熟悉的形象化比喻，相當(dāng)于一個粗略的軟件體系結(jié)構(gòu)4.小發(fā)布（Smallrelease）

經(jīng)常、不斷地發(fā)布可運行的、具有商業(yè)價值的小軟件版本，供現(xiàn)場用戶評估或最終使用

5.測試（testing）

XP方法提倡測試優(yōu)先，即先寫測試后編代碼（testingthencoding）6.簡單設(shè)計（SimpleDesign）設(shè)計只考慮當(dāng)前定義的功能而不考慮以后需求的變化該設(shè)計是完成目前功能所需的最簡潔的設(shè)計3.系統(tǒng)比喻（Metaphor）7.結(jié)對編程（PairProgramming）一個程序員編程的同時，另一個程序員負(fù)責(zé)檢查程序的正確性和可讀性結(jié)對的伙伴可以動態(tài)調(diào)整8.

設(shè)計改進（DesignImprovement）在不影響程序的外部可見行為的情況下，按高內(nèi)聚低耦合的原則對程序結(jié)構(gòu)進行改進，保持代碼簡潔、無冗余持續(xù)集成（ContinuousIntegration）每完成一個模塊的開發(fā)（包括該模塊的單元測試）后，立即將其組裝到系統(tǒng)中，并進行集成測試，完成該集成測試后才能進行下一次集成7.結(jié)對編程（PairProgramming）10.

代碼全體共享（CollectivecodeOwnership）

團隊中的任何人可以在任何時候修改系統(tǒng)任何位置上的任何代碼團隊的成員都可以參加模型的開發(fā)，又有系統(tǒng)比喻、結(jié)對編程、編碼標(biāo)準(zhǔn)、持續(xù)集成等實踐，這些都為代碼全體共有提供了支持編碼標(biāo)準(zhǔn)（CodingStandard）

XP方法強調(diào)制訂一個統(tǒng)一的編碼標(biāo)準(zhǔn)，包括命名、注釋、格式等編程風(fēng)格12.可持續(xù)步調(diào)（SustainablePace）

每周40小時工作制10.

代碼全體共享（CollectivecodeOwn3.3.1極限模型優(yōu)點采用簡單計劃策略，不需要長期計劃和復(fù)雜模型，開發(fā)周期短；在全過程采用迭代增量開發(fā)、反饋修正和反復(fù)測試的方法，能夠適應(yīng)用戶經(jīng)常變化的需求。

缺點目前主要在小規(guī)模項目上應(yīng)用并取得成功，但是否適用于中等規(guī)?；虼笠?guī)模軟件產(chǎn)品，需慎重考慮；由于這個模型較新產(chǎn)品交付后維護成本是否降低，不能確定；對編碼人員的經(jīng)驗要求高

3.3.1極限模型優(yōu)點缺點1.4.6Rational統(tǒng)一過程

最佳實踐RUP充分體現(xiàn)了6條經(jīng)過多年實踐檢驗的軟件開發(fā)經(jīng)驗：1)迭代式開發(fā)：允許每次迭代過程中需求發(fā)生變化，加深對問題的理解，易于滿足需求的變化。2)管理需求：描述了如何提取、組織系統(tǒng)的功能性需求和約束條件并把它們文檔化。3)使用基于構(gòu)件的體系結(jié)構(gòu)：構(gòu)件使軟件重用稱為可能。RUP提供了使用現(xiàn)有的或新開發(fā)的構(gòu)件定義體系結(jié)構(gòu)的系統(tǒng)化方法，降低開發(fā)復(fù)雜性，提高軟件重用率。

3.3.2Rational統(tǒng)一過程（RUP）1.4.6Rational統(tǒng)一過程

最佳實踐3.3.21.4.6Rational統(tǒng)一過程

4)可視化建模：建模是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述?？梢暬膱D形形式更易于理解。5)驗證軟件質(zhì)量：RUP中軟件質(zhì)量評估貫穿于整個開發(fā)過程中，由全體成員參與所有活動中。6)控制軟件變更:RUP描述了如何控制、跟蹤和監(jiān)控修改，以確保迭代開發(fā)的成功。1.4.6Rational統(tǒng)一過程

4)可視化建模3.3.2Rational統(tǒng)一過程（RUP）3.3.2Rational統(tǒng)一過程（RUP）(1)核心工作流

前6個為核心過程工作流程，后3個為核心支持工作流程。(2)工作階段

劃分為4個連續(xù)的階段，每階段都有明確的目標(biāo)，并且定義了用來評估是否達(dá)到這么目標(biāo)的里程碑。每個目標(biāo)都是通過迭代實現(xiàn)。(3)迭代式開發(fā)

采用迭代或漸增的方法開發(fā)軟件。RUP重復(fù)一系列組成軟件生命周期的循環(huán)，每次循環(huán)經(jīng)歷一次完整的生命周期且交付可運行版本。(1)核心工作流3.3.2Rational統(tǒng)一過程（RUP）

用例驅(qū)動

Concise,simple,andunderstandable

以體系結(jié)構(gòu)為中心

Effectivebasisforlarge-scalereuse

增量和迭代開發(fā)基于風(fēng)險前驅(qū)的原則，漸進地展開分析、設(shè)計及其相關(guān)活動，每個迭代都會提供一次驗證和調(diào)整模型機會，推動軟件質(zhì)量的提升。3.3.2Rational統(tǒng)一過程（RUP）用

一、問題陳述

有一個對外營業(yè)的會議中心，有各種不同規(guī)格的會議室，為用戶提供以下服務(wù)：

1、用戶可以按照會議人數(shù)、會議時間預(yù)訂會議室。可以只預(yù)訂１次，也可預(yù)訂定期召開的會議。

2、開會前允許修改會議時間、人數(shù)，重新選擇會議室，甚至取消預(yù)訂的會議。

3、確定會議預(yù)訂后，會議中心負(fù)責(zé)會務(wù)管理：包括通過郵寄或電子郵件，通知開會人員有關(guān)會議信息，制作代表證等。

4、系統(tǒng)根據(jù)會議室的使用情況（緊張與否），調(diào)整、更改會議室和會議時間，并調(diào)整修改預(yù)訂會議的時間。會議管理系統(tǒng)退出下頁末頁案例一一、問題陳述會議管理系統(tǒng)退出下頁末頁案例一二、建立用例模型1、識別角色

找出所有可能與系統(tǒng)發(fā)生交互行為的外部實體、對象、系統(tǒng)?？紤]系統(tǒng)的主要功能的使用者，就會想到用戶和系統(tǒng)管理者，但如果直接將用戶定義為角色，系統(tǒng)的所有功能幾乎都由用戶使用。根據(jù)問題的描述，系統(tǒng)要求將會議和會議的召開分開來。從會議的角度看，允許用戶定義、更改或刪除一個會議。從會議召開的角度看，允許用戶為某個會議定義召開時間、參加人數(shù)、更改相應(yīng)的數(shù)據(jù)或刪除已定義的會議召開。因此，將用戶識別為“會議管理者”和“會議申請者”兩個角色。本系統(tǒng)定義以下角色：會議管理者（MeetingAdministrator）會議申請者（MeetingInstanceRequester）郵局（PostOffice）會議人員管理（AttendeeManagement）系統(tǒng)維護者（SystemMaintainer）退出上頁首頁下頁末頁二、建立用例模型1、識別角色退出上頁首頁下頁末頁

在識別角色的基礎(chǔ)上，列出與角色相關(guān)的用例，有的用例與多個角色相關(guān)，經(jīng)過分析，確定系統(tǒng)的用例（打）。⑴與會議管理者相關(guān)的用例：

定義一個會議（DefineMeeting

）更改一個會議（AlterMeeting

）

刪除一個會議（RemoveMeeting

）

⑵與會議申請者相關(guān)的用例：

申請會議召開（RequestMeetingInstance

）

更改申請（ChangRequest

）

取消申請（CancelRequest

）

定義參加人員（AddAttendee

）

歸還會議室（ReleaseRoom

）

2、用例識別退出上頁首頁下頁末頁在識別角色的基礎(chǔ)上，列出與角色相關(guān)的用例，有的用例與多個3、會議管理系統(tǒng)的Usecase圖圖1會議管理系統(tǒng)的Usecase圖歸還會議室申請會議召開更改申請取消申請定義參加人員會議召開申請者郵局會議人員管理設(shè)置預(yù)定時限會議室維護定義會議更改會議刪除會議系統(tǒng)維護者會議管理員

退出上頁首頁下頁末頁3、會議管理系統(tǒng)的Usecase圖圖1會議管理系統(tǒng)的Us用例1、定義會議（DefineMeeting）輸入會議名稱確定會議規(guī)模確定會議類型其中會議規(guī)模是指參會人數(shù)范圍。用例２、更改會議（AlterMeeting）改變會議名稱改變會議規(guī)模改變會議召開頻度用例３、刪除會議（RemoveMeeting）如果該會議沒有召開申請從會議列表中刪除如果該會議有召開申請取消與之相關(guān)的會議召開信息刪除該會議使用：用例8刪除參加人員（RemoveAttendee）用例6取消申請（CancelRequest）4、對用例的進一步描述用例4、申請會議召開（RequestMeetingInstance)

確定召開時間（年、月、日）確定參加人員確定侯選會議室發(fā)會議通知使用：用例11發(fā)會議通知（InformofMeeting）用例13選擇參加組（SelectGroupAttendee）擴展：①如果召開時間在申請時限之外用例12申請拒絕(RequestRejection）②如果還沒定義參加人員用例7定義參加人員(AddAttendee

)用例5：更改申請（ModifyRequest）更改召開時間更改參加人員更改取得會議室發(fā)會議更改通知使用：用例13選擇參加組（SelectGroupAttendee）用例11發(fā)會議通知(InformofMeeting)

擴展：①如果更改的時間不合法用例12申請拒絕（RequestRejection）②用例7定義參加人員(AddAttendee)退出上頁首頁下頁末頁用例1、定義會議（DefineMeeting）用例２、更用例6：取消會議召開（CancelRequest）、取消申請歸還會議室發(fā)會議取消通知使用：用例8歸還會議室（ReleaseRoom）用例14發(fā)會議取消通知（InformRejection）擴展：①如果會議已召開用例12申請拒絕（RequestRejection）用例7：定義參加人員(AddAttendee)輸入?yún)⒓尤藛T的詳細(xì)信息定義參加組用例9：會議維護（MeetingRoomMaintenance）加入一個會議室（用例15)標(biāo)記一個會議室不可用（用例16)查詢會議室預(yù)定情況（用例17)用例10：設(shè)置預(yù)定時限制（SetReservationTomeLimit）設(shè)置時間限用例11：發(fā)會議通知(InformofMeeting)

從會議人員管理獲得參加人員的投遞地址填寫通知（會議召開時間、會議室號碼）發(fā)送通知用例12：申請拒絕（RequestRejection）作廢當(dāng)前的一切輸入中字止用戶當(dāng)前的操作用例13：選擇會議參加人員組(SelectGroupAttendee)瀏覽會議組成員選擇參加組用例14:會議取消通知（InformofCancellation)從會議人員管理處獲取參加人員地址填寫通知發(fā)送通知

用例８：歸還會議室（ReleaseRoom）輸入會議室號碼輸入使用時間刪除參加人員歸還會議室使用：用例９會議室維護（MeetingRoomMaintenance）用例18刪除參加人員（RemoveAttendee）退出上頁首頁下頁末頁用例6：取消會議召開（CancelRequest）、用例7用例15:增加會議室（AddMeetingRoom）輸入會議室號碼輸入會議室規(guī)模輸入會議室可使用狀態(tài)（可使用、不可使用）加入該會議室用例16:設(shè)置會議室不可使用（SetUnusableFlag）輸入會議室號碼通知該會議室的預(yù)定者標(biāo)記該會議室的可所以狀態(tài)為不可用用例17:查詢會議室的使用情況(BrowseMeetingroomusage)輸入會議室號碼查詢本用例返回會議室的使用狀態(tài)（已使用、空閑）和會議室的可否使用情況。用例18：刪除會議參加人員（RemoveAttendee）刪除參加人員刪除參加組圖2描述了會議管理系統(tǒng)完整的用例模型。退出上頁首頁下頁末頁用例15:增加會議室（AddMeetingRoom）退出5、完整的會議管理系統(tǒng)的Usecase圖圖2完整的會議管理系統(tǒng)Usecase圖退出上頁首頁下頁末頁5、完整的會議管理系統(tǒng)的Usecase圖圖2完整的會議管

除了用例模型外，其他模型都依賴于類模型，因此，類模型是ＯＯ方法的核心，類模型從對象的角度描述系統(tǒng)的組成，描述類（對象）及相互間的關(guān)系。為了建立類模型，首先要識別類，鑒于篇幅，這里就不再討論類的識別過程。通過分析，識別以下類：

1、Meeting類，標(biāo)識一個會議（名稱、類型、規(guī)模）。

2、MeetingInstance類,Meeting類的子類，對會議時間、人數(shù)等進行描述。

3、MeetingRoom類,描述會議室的有關(guān)信息。

4、MeetingAdministration類，管理會議。

5、Attendee類，描述參會人員（姓名、性別、地址、頭銜等）。

6、GroupAttende類，創(chuàng)建一個參加會議的組。

7、Address類，描述郵寄地址E-mail地址。

8、PostOffice類，負(fù)責(zé)發(fā)送郵寄通知。

9、AttendeeManagement類，數(shù)據(jù)庫管理。

10、ReservationCriteria類，定義會議室預(yù)定準(zhǔn)則。

11、Information類，構(gòu)造一條通知。三、建立類模型退出上頁首頁下頁末頁除了用例模型外，其他模型都依賴于類模型，因此，類模型是Ｏ

該類與會議召開不同，它標(biāo)識了一個會議（圖3），因此，其屬性包括會議名稱、類型、規(guī)模（參加會議的人數(shù)）。其操作則有：增加會議、取消會議。一個會議往往有多個子會議（子類）的召開，因此，必須描述Meeting類與其子類MeetingInstance類之間的關(guān)聯(lián)，如圖4所示。2、

MeetingInstance類

MeetingInstance類是Meeting類的子類，描述會議的具體情況，會議的開始(StartTime)、結(jié)束時間(EndTime)，參會的人數(shù)(AttendeeNumber)，其操作有：添加參加人員AddAttendee()、添加參加人員組AddGroupAttendee()，而AttachMeetingRoom()表示為該類分配一個會議室，而Cancel()則表示取消該會議的召開。MeetingMeetingInstanceStartTimeEndTimeAttendeeNumberAddAttendee()AttachMeetingRoom()AddGroupAttendee()Cancel()Meeting

Name

Type

SizeAddMeetingInstance()CancelMeetingInstance()圖3Meeting類圖圖4MeetingInstance類圖1、

Meeting類退出上頁首頁下頁末頁該類與會議召開不同，它標(biāo)識了一個會議（圖3），因此MeetingRoomCapacityBuildingCodeDoorCodeStatusAssignMeetingInstance()SetInvalidate()Release()MeetingInstanceMeeting圖5MeetingRoom類圖該類描述了有關(guān)會議室的情況，因此MeetingRoom類的屬性包括：會議室的規(guī)模Capacity，位置BuildingCode、DoorCode，使用狀態(tài)Status（正在使用、已預(yù)定、空閑和不可用）等。該類的操作有：AssignMeetingInstance()將MeetingRoom分配給MeetingInstance對象,而SetInvalidate()則表示當(dāng)會議室出現(xiàn)故障時，將其狀態(tài)設(shè)置為不可用。Release()為歸還會議室。當(dāng)會議被預(yù)定后，為了便于查詢某個會議室預(yù)定給了哪個會議，應(yīng)建立類MeetingRoom與類MeetingInstanc之間的雙向關(guān)聯(lián)，這里定義為1：1。3、MeetingRoom類退出上頁首頁下頁末頁MeetingRoomCapacityAssignMeetiAttendeeNameSexPostaddressEmailAddressTitleMeetingInstance11..*圖6Attendee類圖

Attendee類描述參加會議人員的有關(guān)信息，如：姓名、性別、地址、E-mail地址、頭銜等。MeetingInstance類與Attendee類之間有一對多的關(guān)聯(lián)“1..*”

。

5、GroupAttendee類MeetingInstanceGroupAttendeeMemberNumberGroupNameAddAttendee()DeleteAttendee()10..*Attendee11..*圖7GroupAttendee類圖該類可創(chuàng)建一個參加會議的組，便于按照小組選擇參加會議的人員。MeetingInstance類與GroupAttendee類之間有一對多的關(guān)聯(lián)“0..*”。4、Attendee類退出上頁首頁下頁末頁AttendeeName11..*圖6Attendee類圖系統(tǒng)中有兩種地址：電子郵件地址（EmailAddress

）和郵寄地址（PostAddress），而且，每個參加會議的人，可以有一個或者多個郵寄地址，有0個或多個E-mail地址。有關(guān)地址的屬性，在再內(nèi)這里不再討論。負(fù)責(zé)發(fā)送郵寄通知。PostOffice類分別與PostAddress、EmailAddress和Information之間有一對多的關(guān)聯(lián)。

7、PostOffice類1..*InformationEmailAddress1..*PostAddress1..*(fromUseCaseView)DelieverInformation()圖9PostOffice類圖PostOfficeAddress

PostAddressEmailAddressAttendee圖8Address類圖1..*0..*6、Address類退出上頁首頁下頁末頁系統(tǒng)中有兩種地址：電子郵件地址（EmailAddres

InformationNoticeTopicReceiverTitleReceivernameTimeEventExplanationSendTimeSendrSignatureCreate()MeetingRoom圖10Information類圖該類用于構(gòu)造一條通知，由于在本系統(tǒng)中，通常有三種：會議召開通知，會議更改通知，會議取消通知。如下例所示，通知的內(nèi)容常包括標(biāo)題、接受者、會議內(nèi)容、會議時間及發(fā)通知的時間等。XXXX會議召開通知XX先生：定于2005年9月15日在櫻都會議中心召開XXXX會議。

XXXX會議籌備組

2005年8月20日8、Information類退出上頁首頁下頁末頁InformationMeetingRoom圖1GroupAttendeeAttendeeAttendeeManagement(fromUseCaseView)AttendNumber()GroupAttendeeNumber()AddAttendee()ChangeAttendee()AddGroupAttendee()DeleteGroupAttendee()圖11AttendeeManagement類圖該類使用數(shù)據(jù)庫對參加會議的人員進行管理。分析階段只確定該類與系統(tǒng)的接口，有關(guān)數(shù)據(jù)庫的設(shè)計在設(shè)計階段解決。該類與GroupAttendee類及Attendee類的關(guān)聯(lián)如圖11所示。

10、

ReservationCriteria類

該類定義了預(yù)定會議室的準(zhǔn)則(如時間)，并建立會議實例（MeetingInstanee類）與該類之間的聯(lián)系。ReservationCriteriaTimeCriteriasetCrieria()GetCriteria()MeetingInstanee圖12ReservationCriteria類圖9、

AttendeeManagement類退出上頁首頁下頁末頁AttendeeManagement(fromUseCa該類管理系統(tǒng)中由用戶定義的所有會議，并提供給用戶友好的用戶界面。由于該類有定義會議（DefineMeeting）、更改會議（AlterMeeting）、刪除會議（RemoveMeeting）等操作，建立與Meeting類之間的關(guān)聯(lián)關(guān)系。MeetingName:stringMeetingAdministration(fromeetingPack)MeetingNumber:intDefineMeeting()AlterMeeting()RemoveMeeting()Meeting(fromMeetingPack)圖13MeetingAdministration類圖11、MeetingAdministration類退出上頁首頁下頁末頁該類管理系統(tǒng)中由用戶定義的所有會議，并提供給用戶友好的用MeetingMeetingName:stringMeetingAdministrationReservationCriteriaMeetingInstance

InformationMeetingRoom1..*1..*1..*PostOfficeGroupAttendeeAttendeeManagement

Address

PostAddressEmailAddressAttendee1..*0..*1..*0..*110..*0..*0..*111圖14會議管理系統(tǒng)類圖會議管理系統(tǒng)類圖退出上頁首頁下頁末頁MeetingName:stringMeetingAdmin四、建立系統(tǒng)包圖引入包圖來對類進行管理，圖15為本系統(tǒng)的包圖。系統(tǒng)由會議包(MeetingPack)、人員包(AttendeePack)和郵寄包(PostOfficePack)三類包組成。圖16、圖17、圖18分別描述了這三類包的構(gòu)成。PostOfficePack圖15系統(tǒng)包圖MeetingPackAttendeePack退出上頁首頁下頁末頁四、建立系統(tǒng)包圖引入包圖來對類進行管理，圖15為本系統(tǒng)的1、會議包（MeetingPack）2、人員包（AttendeePack）3、郵寄包（PostOfficePack）GroupAttendeeAddress

PostAddressEmailAddressAttendee圖17人員包構(gòu)成0..*1..*1..*1圖18郵寄包構(gòu)成

InformationPostOffice（fromUseCaseView）1..*0..*MeetingMeetingName:stringMeetingAdministrationReservationCriteriaMeetingInstanceMeetingRoom圖16會議包構(gòu)成111包圖退出上頁首頁下頁末頁1、會議包（MeetingPack）2、人員包（Att

靜態(tài)模型關(guān)注的是系統(tǒng)各成分的組織結(jié)構(gòu)，而動態(tài)模型則要描述系統(tǒng)各成分之間的交互行為，即系統(tǒng)的動態(tài)特征。結(jié)合本系統(tǒng)，建立動態(tài)模型，包括交互圖、合作圖、活動圖。（一）對象交互模型

在面向?qū)ο蟮姆椒ㄖ校磺性囟寂c對象緊密相關(guān)，事件也不例外。因此，對象在其生命期中不斷地與其它對象交互。使用對象交互模型來描述用例圖中的每個用例，從對象觀點來描述用例的動態(tài)交互過程。在UML中，交互模型由兩類圖來描述：順序圖（Sequencediagram）強調(diào)的是對象交互行為的時間“順序”，直觀描述了對象的生存期，用消息傳送來清晰地描述了在對象生存期中某一時刻的動態(tài)行為。只適宜描述簡單的對象交互情況。合作圖（Collaborationdiagram）強調(diào)的是對象合作的交互行為關(guān)系，對象間由各種關(guān)聯(lián)連接，對象之間的合作情況（交互情況）使用消息流來表示，但消息沒有發(fā)送時間和傳送時間的概念。適宜描述對象數(shù)目較多，交互情況教復(fù)雜的情況。五、建立動態(tài)模型退出上頁首頁下頁末頁靜態(tài)模型關(guān)注的是系統(tǒng)各成分的組織結(jié)構(gòu)，而動態(tài)模型則要描述系：MeetingAdministration：Meeting：MeetingAdministrattor1:DefineMeeting(meeting)[IsMeetingExisted=.T.]3:Fail(MeetingExisted)2:{new(meeting)}圖19定義會議的順序圖當(dāng)用戶向會議中心申請召開會議時，首先要定義一個會議。會議管理者發(fā)送DefineMeeting消息給MeetingAdministration對象,消息參數(shù)是有關(guān)會議的一個臨時對象(meeting)，根據(jù)該臨時對象檢查會議是否存在？若不存在，創(chuàng)建新會議：2:{new(meeting)}，若當(dāng)條件表達(dá)式為真時：[IsMeetingExisted=.T.]，表示會議已經(jīng)被定義，不需要再定義。1、用例：定義會議(DefineMeeting)的順序圖退出上頁首頁下頁末頁：Meeting1:DefineMeeting(meetin當(dāng)用戶確定要取消某個會議時，首先檢查會議是否定義，如果沒有可以直接刪除，否則要先取消相關(guān)的會議。如圖20所示,首先系統(tǒng)用戶對象MeetingAdministrator發(fā)出RemoveMeeting(MeetingName)消息給對象MeetingAdministration，通過消息的參數(shù)檢索要取消的會議對象，并向該對象發(fā)出取消會議召開的消息。表達(dá)式“[IsOpen=.F.]”表示如果會議不處于召開狀態(tài)，就取消它。表達(dá)式“[IsAllMeetingInstancesCanceled=.T.]”表示該會議的所有會議召開都已經(jīng)被取消，則會議管理就發(fā)出取消會議召開的消息。否則返回取消失敗（如會議正在召開）的消息。2、用例：取消會議(RemoveMeeting)的順序圖圖20取消會議的順序圖：MeetingAdministration：MeetingInstance：MeetingAdministrator1：RemoveMeeting(MeetingName)[IsAllMeetingInstancesCanceled=.F.]5:Fail(MeetingExisted)2:CancelMeetingInstance()：Meeting[IsAllMeetingInstancesCanceled=.T.]4:Fail(MeetingExisted)[IsOpen=.F.]3:Cancel()退出上頁首頁下頁末頁當(dāng)用戶確定要取消某個會議時，首先檢查會議是否定義，如３、用例：撤消會議召開（CancelRequestment）的順序圖：MeetingAdministration：Meeting：MeetingInstance：MeetingRoom：PostOffice1:CancelMeetingInstance(Instance)[IsOpen=.F.]2:Cancel()3:Release()4:DelieverInformation(cancellation)圖21撤消會議召開的順序圖要撤消某個會議召開，發(fā)送Cancel信息給MeetingInstance對象。該對象先要在Meeting對象中注銷自己，再歸還已分配的會議室，并向參會人員發(fā)撤消會議的通知。圖21中會議管理對象發(fā)送給會議對象的消息CancelMeetingInstance(Instance)中的參數(shù)用于檢索會議召開。條件表達(dá)式[IsOpen=.F.]表示如會議召開未進行，則撤消會議召開。如果會議已進行，則返回失敗消息（圖中未列出）。退出上頁首頁下頁末頁３、用例：撤消會議召開（CancelRequestment圖22撤消會議召開的順序圖：PostOffice：MeetingAdministration：Meeting：MeetingInstance：MeetingRoom1:AddMeetingInstance(instance)2:{new}6:AssignMeetingInstance()7:DelieverInformation(info)5:AttachMeetingRoom(room)4:AddGrooupAttendee(group)3:AddAttendee(member)如果時間合法，就創(chuàng)建一個會議召開對象。４、用例：申請會議召開（RequestMeetingInstance）的順序圖用戶申請一個會議召開時，應(yīng)該指定會議召開的名稱，召開的時間，及會議參加人員。圖22中instance、member、group、room、info都是臨時對象，instance記錄了用戶指定的會議屬性（時間、參加人數(shù)等），member為一個參會代表，是Attendeegroup參會人員組的對象；而room是滿足要求的會議室。４、用例：申請會議召開退出上頁首頁下頁末頁圖22撤消會議召開的順序圖：PostOffice1:Ad六、合作圖與活動圖對于簡單的對象交互情況，順序圖可以作很好的描述，可是，當(dāng)交互對象數(shù)目增加，交互情況復(fù)雜時，順序圖就很難描述清楚了，可用合作圖來描述。合作圖描述了系統(tǒng)中所有對象之間的交互合作關(guān)系，注重對象之間的整體交互情況，交互關(guān)系由消息流來表示。在Rose中，還可以將順序圖與合作圖進行轉(zhuǎn)換。本案例不再給出合作圖。

七、活動圖

活動圖模型主要用于描述系統(tǒng)在問題域空間中的活動流程，活動圖可以方便地描述系統(tǒng)中的并發(fā)活動。由于本例中并沒有復(fù)雜的并發(fā)活動，而且也也沒有明顯的基于核心的、具有復(fù)雜狀態(tài)和行為的對象，所以可以不必畫出合作圖和活動圖。六、合作圖退出上頁首頁六、合作圖與活動圖對于簡單的對象交互情況，順序圖可以作很3.3.3微軟產(chǎn)品開發(fā)周期模型微軟產(chǎn)品周期模型產(chǎn)品規(guī)劃階段測試階段產(chǎn)品開發(fā)階段發(fā)布階段M1…MnCCZBBRTM/WRC1…RCnAlphaGoldenMastersBetaProductVisionFunctionSpecQFEsRTM/WQAMnM03.3.3微軟產(chǎn)品開發(fā)周期模型微軟產(chǎn)品周期模型產(chǎn)品規(guī)劃MSF過程模型將里程碑分為兩大類：主要里程碑（Majormilestone）和臨時里程碑（Interimmilestone）。主要里程碑是在項目階段和階段之間設(shè)置的，用于審核前一階段工作完成情況的里程碑。如圖3?4所示，MSF過程模型包含5個主要里程碑：前景/范圍得到認(rèn)可項目計劃得到認(rèn)可開發(fā)完成可發(fā)布版本準(zhǔn)備就緒發(fā)布完成這5個主要里程碑適用于大多數(shù)IT項目。臨時里程碑用于將較大的工作階段或工作任務(wù)劃分為較小的、可管理的單元，并對每個單元的完成情況進行審核。臨時里程碑的設(shè)置是根據(jù)項目的類型和具體情況而定的。項目組可根據(jù)項目的目標(biāo)、范圍和進展，在項目過程中設(shè)置和使用臨時里程碑。MSF過程模型將里程碑分為兩大類：主要里程碑（Majorm軟件開發(fā)過程管理課件本章內(nèi)容提要CMM和ISO9000

傳統(tǒng)軟件開發(fā)生命周期模型

擴展軟件開發(fā)生命周期模型

3.1質(zhì)量計劃

3.4案例分析

3.5本章小結(jié)3.6復(fù)習(xí)思考題

3.73.23.3本章內(nèi)容提要CMM和ISO9000傳統(tǒng)軟件開發(fā)生命周期模型3.4.1質(zhì)量與質(zhì)量規(guī)劃

軟件質(zhì)量是“所有描述計算機軟件優(yōu)秀程度的特性的組合”。軟件質(zhì)量度量模型由三層組成第一層為質(zhì)量特性第二層為質(zhì)量子特性第三層稱為度量3.4.1質(zhì)量與質(zhì)量規(guī)劃軟件質(zhì)量3.4.1質(zhì)量與質(zhì)量規(guī)劃ISO／IEC9126–1991（GB／T16260–1996）標(biāo)準(zhǔn)標(biāo)準(zhǔn)定義的6個質(zhì)量特性功能性可靠性易使用性高效性可維護性可移植性

質(zhì)量規(guī)劃指識別哪些質(zhì)量標(biāo)準(zhǔn)適用于軟件項目，并確定如何滿足這些標(biāo)準(zhǔn)的要求

3.4.1質(zhì)量與質(zhì)量規(guī)劃ISO／IEC9126–3.4.2質(zhì)量體系、質(zhì)量手冊和質(zhì)量計劃

質(zhì)量體系指為保證產(chǎn)品、過程或服務(wù)質(zhì)量，滿