軟件系統(tǒng)發(fā)方法

1、2021年11月7日星期日第1頁(yè)第3章 軟件系統(tǒng)開(kāi)發(fā)方法v3.1 軟件開(kāi)發(fā)生命周期v3.2 軟件開(kāi)發(fā)模型v3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v3.4 面向?qū)ο筌浖_(kāi)發(fā)方法v3.5 rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程v3.6 敏捷軟件開(kāi)發(fā)技術(shù)2021年11月7日星期日第2頁(yè)v在軟件開(kāi)發(fā)的早期，人們常用的軟件開(kāi)發(fā)方法是邊寫(xiě)邊改法。這種開(kāi)發(fā)方法在應(yīng)用開(kāi)發(fā)中最為快捷，但由于其開(kāi)發(fā)的隨意性，因而也最為低效。同時(shí)，使用該方法的項(xiàng)目常常因?yàn)楣芾硎Э囟K結(jié)?；谶@種情況，業(yè)界人士借鑒其它工程領(lǐng)域的方法，提出了許多有規(guī)則可言的軟件系統(tǒng)開(kāi)發(fā)方法。最著名的當(dāng)數(shù)“瀑布式”方法了，即把軟件開(kāi)發(fā)過(guò)程分解成這樣一些階段：制定開(kāi)發(fā)計(jì)劃、需求分析和

2、定義、系統(tǒng)設(shè)計(jì)、編碼實(shí)現(xiàn)、測(cè)試驗(yàn)證。然而，在軟件開(kāi)發(fā)實(shí)踐中完全遵循這種過(guò)程取得成功的案例并不多。其原因主要在于這種方法有一個(gè)前提條件，那就是系統(tǒng)需求必須明確、不變。但在現(xiàn)實(shí)應(yīng)用中，這幾乎是不可能的。需求通常模糊不清，并且在系統(tǒng)開(kāi)發(fā)期間隨時(shí)都有可能發(fā)生變化。因此軟件開(kāi)發(fā)要求采用的方法過(guò)程也必須能適應(yīng)這種變化，這就出現(xiàn)了其它一些軟件開(kāi)發(fā)方法，如原型法、敏捷方法等。2021年11月7日星期日第3頁(yè)3.1 軟件開(kāi)發(fā)生命周期v正如任何事物一樣，軟件也有其孕育、誕生、成長(zhǎng)、成熟以及衰亡的生命過(guò)程，一般稱(chēng)其為“軟件生命周期”。 2021年11月7日星期日第4頁(yè)3.1 軟件開(kāi)發(fā)生命周期v根據(jù)這一思想，可以得到

3、軟件生命周期的六個(gè)階段：制定計(jì)劃需求分析和定義設(shè)計(jì)編碼測(cè)試運(yùn)行及維護(hù)。2021年11月7日星期日第5頁(yè)3.1 軟件開(kāi)發(fā)生命周期v(1) 制定計(jì)劃（planning）團(tuán)隊(duì)人員：分析人員、領(lǐng)域?qū)＜壹坝脩舻?。這個(gè)階段的任務(wù)是確定待開(kāi)發(fā)軟件系統(tǒng)的總體目標(biāo)，給出軟件系統(tǒng)的功能、性能及接口等方面的要求。由團(tuán)隊(duì)人員協(xié)作，共同研究完成該項(xiàng)軟件開(kāi)發(fā)任務(wù)的技術(shù)、經(jīng)濟(jì)、社會(huì)可行性，探討解決問(wèn)題的各種可能方案，并對(duì)現(xiàn)有可利用資源、成本、可取得的效益、開(kāi)發(fā)進(jìn)度等做出估計(jì)，制定出完成該項(xiàng)開(kāi)發(fā)任務(wù)的實(shí)施計(jì)劃，并編寫(xiě)可行性研究報(bào)告。 2021年11月7日星期日第6頁(yè)3.1 軟件開(kāi)發(fā)生命周期v(2) 需求分析和定義（requi

4、rement analysis and definition）團(tuán)隊(duì)人員：分析人員、測(cè)試人員、領(lǐng)域?qū)＜壹坝脩舻?。該階段對(duì)于待開(kāi)發(fā)軟件項(xiàng)目獲取的用戶需求進(jìn)行分析，并給出詳細(xì)定義。這個(gè)階段團(tuán)隊(duì)人員必須協(xié)同工作，讓軟件開(kāi)發(fā)人員充分理解用戶的各項(xiàng)需求，并確定哪些需求是可以滿足的，哪些需求在現(xiàn)有技術(shù)下是不能滿足的，對(duì)能滿足的需求加以確切的描述。然后，編寫(xiě)出軟件需求規(guī)格說(shuō)明書(shū)（srs）或系統(tǒng)功能說(shuō)明書(shū)，以及初步的系統(tǒng)用戶手冊(cè)、測(cè)試用例等。為了團(tuán)隊(duì)人員之間能很好地溝通，從這個(gè)階段開(kāi)始通常會(huì)采用一些標(biāo)準(zhǔn)的建模語(yǔ)言（如：統(tǒng)一建模語(yǔ)言，unified modeling language，簡(jiǎn)稱(chēng)uml）對(duì)系統(tǒng)建模。 2

5、021年11月7日星期日第7頁(yè)3.1 軟件開(kāi)發(fā)生命周期v(3) 軟件設(shè)計(jì)（software design）團(tuán)隊(duì)人員：架構(gòu)設(shè)計(jì)人員、軟件設(shè)計(jì)人員、數(shù)據(jù)庫(kù)設(shè)計(jì)員、用戶界面設(shè)計(jì)員、封裝體設(shè)計(jì)員和集成人員、測(cè)試人員等。這個(gè)階段通常分為兩部分：概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。在軟件設(shè)計(jì)階段，軟件開(kāi)發(fā)人員把已經(jīng)經(jīng)過(guò)用戶和領(lǐng)域?qū)＜掖_認(rèn)的各項(xiàng)需求轉(zhuǎn)換成相應(yīng)的軟件體系結(jié)構(gòu)。結(jié)構(gòu)中的每一成份都是意義明確的子系統(tǒng)、模塊或用例，每個(gè)部分都和某些需求相對(duì)應(yīng)，進(jìn)行所謂的概要設(shè)計(jì)。然后對(duì)每個(gè)模塊或用例要完成的工作采用合適的技術(shù)進(jìn)行具體的描述，如畫(huà)出模塊的程序流程圖或描述類(lèi)的屬性、操作等，為源程序的編寫(xiě)工作打下基礎(chǔ)，即所謂的詳細(xì)設(shè)計(jì)。

6、2021年11月7日星期日第8頁(yè)3.1 軟件開(kāi)發(fā)生命周期v(4) 編碼（coding）團(tuán)隊(duì)人員：編程人員、測(cè)試人員等。將詳細(xì)設(shè)計(jì)階段所描述的模塊程序流程圖或類(lèi)的設(shè)計(jì)轉(zhuǎn)換為計(jì)算機(jī)能處理的程序代碼，即使用特定的程序設(shè)計(jì)語(yǔ)言表示的源程序。目前，通常使用高級(jí)程序設(shè)計(jì)語(yǔ)言編寫(xiě)程序，如c語(yǔ)言、java語(yǔ)言等。2021年11月7日星期日第9頁(yè)3.1 軟件開(kāi)發(fā)生命周期v(5) 軟件測(cè)試（software testing）團(tuán)隊(duì)人員：測(cè)試人員、開(kāi)發(fā)人員、用戶等。測(cè)試是保證軟件質(zhì)量的重要手段，其主要目的是通過(guò)軟件測(cè)試暴露出軟件中隱藏的錯(cuò)誤和缺陷。軟件測(cè)試的主要方式是在設(shè)計(jì)測(cè)試用例的基礎(chǔ)上檢驗(yàn)軟件的各個(gè)組成部分。軟件

7、測(cè)試一般包括單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試等幾個(gè)階段。首先進(jìn)行單元測(cè)試，查找各模塊或類(lèi)在功能和結(jié)構(gòu)上存在的問(wèn)題并加以修改，這個(gè)過(guò)程會(huì)反復(fù)進(jìn)行；其次進(jìn)行集成測(cè)試，驗(yàn)證各軟件單元集成后形成的模塊能否達(dá)到概要設(shè)計(jì)規(guī)格說(shuō)明中各模塊的設(shè)計(jì)目標(biāo)；然后進(jìn)行系統(tǒng)測(cè)試，目的是對(duì)最終軟件系統(tǒng)進(jìn)行全面的測(cè)試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)；最后進(jìn)行確認(rèn)測(cè)試，以檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說(shuō)明書(shū)中確定的各種需求，包括功能需求和性能需求，決定已開(kāi)發(fā)的軟件能否交付用戶使用。 2021年11月7日星期日第10頁(yè)3.1 軟件開(kāi)發(fā)生命周期v(6) 運(yùn)行/維護(hù)（running/maintenance）

8、團(tuán)隊(duì)人員：系統(tǒng)支持人員等。已交付的軟件投入正式使用，軟件便進(jìn)入運(yùn)行階段。軟件在運(yùn)行過(guò)程中可能會(huì)因?yàn)榘l(fā)現(xiàn)了軟件中存在的錯(cuò)誤需要修改；或?yàn)榱诉m應(yīng)變化了的軟件工作環(huán)境，需做一些變更；或?yàn)榱嗽鰪?qiáng)軟件的功能需做變更等。這就稱(chēng)為軟件維護(hù)。 2021年11月7日星期日第11頁(yè)3.2 軟件開(kāi)發(fā)模型v從上節(jié)的內(nèi)容中我們知道，一個(gè)軟件的生命周期包含了若干個(gè)活動(dòng)，那么，這些活動(dòng)應(yīng)該如何組織呢？不同的組織方式可能會(huì)產(chǎn)生很大差別的結(jié)果。v實(shí)際上，與其它工程項(xiàng)目中安排各道工序類(lèi)似，為了反應(yīng)軟件開(kāi)發(fā)生命周期內(nèi)的各種活動(dòng)應(yīng)如何組織，各活動(dòng)之間應(yīng)如何銜接，需要用軟件開(kāi)發(fā)模型做出直觀的圖示來(lái)表達(dá)。2021年11月7日星期日第12

9、頁(yè)3.2 軟件開(kāi)發(fā)模型v軟件開(kāi)發(fā)模型是從軟件項(xiàng)目需求定義到軟件經(jīng)使用后被廢棄為止，跨越整個(gè)軟件生命周期的系統(tǒng)開(kāi)發(fā)、運(yùn)作和維護(hù)的全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架，它給出了軟件開(kāi)發(fā)活動(dòng)各個(gè)階段之間的關(guān)系。每種軟件生命周期模型代表一種軟件開(kāi)發(fā)與管理的組織過(guò)程。 2021年11月7日星期日第13頁(yè)3.2 軟件開(kāi)發(fā)模型v迄今為止，出現(xiàn)了多種軟件開(kāi)發(fā)模型。如：迄今為止，出現(xiàn)了多種軟件開(kāi)發(fā)模型。如：瀑布模型螺旋模型演化模型噴泉模型智能模型增量模型原型化模型 2021年11月7日星期日第14頁(yè)3.2.1 瀑布模型v瀑布模型將軟件生命周期劃分為制定開(kāi)發(fā)計(jì)劃、需求分析和定義、軟件設(shè)計(jì)、程序編寫(xiě)、軟件測(cè)試和運(yùn)行維護(hù)等

10、六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。 2021年11月7日星期日第15頁(yè)3.2.1 瀑布模型v瀑布模型是最早出現(xiàn)的軟件開(kāi)發(fā)模型，在軟件工程中占有十分重要的地位，它提供了軟件開(kāi)發(fā)的基本框架。瀑布模型規(guī)定了各項(xiàng)軟件工程活動(dòng)，其核心思想是按工序?qū)?wèn)題化簡(jiǎn)，將功能的實(shí)現(xiàn)與設(shè)計(jì)分開(kāi)，便于分工協(xié)作，即采用結(jié)構(gòu)化的分析與設(shè)計(jì)方法將邏輯實(shí)現(xiàn)與物理實(shí)現(xiàn)分開(kāi)。 軟件計(jì)劃 需求分析和定義 軟件設(shè)計(jì) 實(shí)現(xiàn) 測(cè)試 運(yùn)行維護(hù) 2021年11月7日星期日第16頁(yè)3.2.1 瀑布模型v瀑布模型每項(xiàng)開(kāi)發(fā)活動(dòng)均應(yīng)具有下述特征：(1) 從上一項(xiàng)活動(dòng)接收本項(xiàng)活動(dòng)的工作對(duì)象，作為本項(xiàng)活動(dòng)的

11、輸入；(2) 利用這一輸入實(shí)施本項(xiàng)活動(dòng)應(yīng)完成的任務(wù)；(3) 給出本項(xiàng)活動(dòng)的工作成果，作為輸出傳遞給下一項(xiàng)活動(dòng)；(4) 對(duì)本項(xiàng)活動(dòng)實(shí)施的工作進(jìn)行評(píng)審。若得到確認(rèn)，則繼續(xù)下一項(xiàng)活動(dòng)；否則，返回到前項(xiàng)活動(dòng)，或更前一項(xiàng)活動(dòng)進(jìn)行返工。 2021年11月7日星期日第17頁(yè)3.2.1 瀑布模型v瀑布模型中軟件維護(hù)的特點(diǎn)：瀑布模型中軟件維護(hù)的特點(diǎn)：(1) 維護(hù)的具體要求是在軟件投入使用以后提出來(lái)的，經(jīng)過(guò)評(píng)價(jià)，確定需求變更的必要性，才進(jìn)行維護(hù)工作。(2) 維護(hù)中對(duì)軟件的變更仍然要經(jīng)歷軟件生命周期在開(kāi)發(fā)中已經(jīng)歷過(guò)的各項(xiàng)活動(dòng)。2021年11月7日星期日第18頁(yè)3.2.1 瀑布模型v瀑布模型的優(yōu)點(diǎn)：瀑布模型的優(yōu)點(diǎn)：(

12、1) 為軟件項(xiàng)目提供了按階段劃分的檢查點(diǎn)，強(qiáng)調(diào)開(kāi)發(fā)的階段性。(2) 強(qiáng)調(diào)早期計(jì)劃及需求調(diào)查。(3) 強(qiáng)調(diào)產(chǎn)品測(cè)試和階段評(píng)審。(4) 強(qiáng)調(diào)文檔的重要性。 2021年11月7日星期日第19頁(yè)3.2.1 瀑布模型v瀑布模型的缺點(diǎn)：瀑布模型的缺點(diǎn)：(1) 在項(xiàng)目各個(gè)階段之間極少有反饋，往往會(huì)將早期的錯(cuò)誤引入到后期各個(gè)階段。(2) 依賴(lài)于早期進(jìn)行的唯一一次需求調(diào)查，用戶參與較少，不能適應(yīng)需求的變化。(3) 只有在項(xiàng)目生命周期的后期才能看到結(jié)果，可能與用戶的需求出現(xiàn)很大的偏差，使風(fēng)險(xiǎn)推遲到項(xiàng)目開(kāi)發(fā)的后期階段才顯露出來(lái)，因而失去及早糾正的機(jī)會(huì)。(4) 通過(guò)過(guò)多的強(qiáng)制完成日期和里程碑來(lái)跟蹤各個(gè)項(xiàng)目階段，靈活性

13、較差。 2021年11月7日星期日第20頁(yè)3.2.1 瀑布模型v瀑布模型缺乏靈活性，無(wú)法通過(guò)開(kāi)發(fā)活動(dòng)來(lái)理清本來(lái)不夠明確的需求，這將可能導(dǎo)致直到軟件開(kāi)發(fā)完成時(shí)才發(fā)現(xiàn)所開(kāi)發(fā)的軟件并非用戶所需要的，此時(shí)必將付出高額的代價(jià)才能糾正出現(xiàn)的偏差。v瀑布模型一般適用于功能、性能明確、完整、無(wú)重大變化的軟件系統(tǒng)的開(kāi)發(fā)。如操作系統(tǒng)、編譯系統(tǒng)等系統(tǒng)軟件的開(kāi)發(fā)。v當(dāng)用戶需求不明確或經(jīng)常變更時(shí)，不宜采用瀑布模型，可以考慮其它的架構(gòu)來(lái)進(jìn)行項(xiàng)目管理，如：演化模型等。 2021年11月7日星期日第21頁(yè)3.2.2 演化模型v演化模型主要針對(duì)事先不能完整定義需求的軟件開(kāi)發(fā)。用戶可以給出待開(kāi)發(fā)系統(tǒng)的核心需求，并且當(dāng)看到核心需求

14、實(shí)現(xiàn)后，能夠有效地提出反饋，以支持系統(tǒng)的最終設(shè)計(jì)和實(shí)現(xiàn)。2021年11月7日星期日第22頁(yè)3.2.2 演化模型v該模型可以表示為：第一次迭代（需求設(shè)計(jì)編碼測(cè)試集成）反饋第二次迭代（需求設(shè)計(jì)編碼測(cè)試集成）反饋. 2021年11月7日星期日第23頁(yè)3.2.2 演化模型 問(wèn) 題 定 義 需求分析 設(shè)計(jì) 編碼 測(cè)試 集成 交付用戶 迭代 1 迭代 2 迭代 3 迭代 n 反饋 反饋 反饋 需求分析 設(shè)計(jì) 編碼 測(cè)試 集成 交付用戶 需求分析 設(shè)計(jì) 編碼 測(cè)試 集成 交付用戶 需求分析 設(shè)計(jì) 編碼 測(cè)試 集成 交付用戶 2021年11月7日星期日第24頁(yè)3.2.2 演化模型v演化模型的主要優(yōu)點(diǎn)：演化模型

15、的主要優(yōu)點(diǎn)：(1) 用戶能在開(kāi)發(fā)過(guò)程中而不是開(kāi)發(fā)接近尾聲時(shí)看到自己所需要的軟件產(chǎn)品。對(duì)發(fā)現(xiàn)的問(wèn)題能夠提早解決。(2) 在一定程度上減少了軟件開(kāi)發(fā)活動(dòng)的盲目性。如果在某次迭代中，其需求沒(méi)有滿足用戶的要求，軟件開(kāi)發(fā)人員可根據(jù)用戶的反饋信息在下一次迭代中予以修正。(3) 將系統(tǒng)中難度較大、風(fēng)險(xiǎn)較高的部分安排在早期的迭代中，可增加項(xiàng)目的成功率。 2021年11月7日星期日第25頁(yè)3.2.2 演化模型v演化模型的缺點(diǎn)演化模型的缺點(diǎn)(1) 由于項(xiàng)目需求在開(kāi)發(fā)初期不可能完全弄清楚，這樣會(huì)給系統(tǒng)總體設(shè)計(jì)帶來(lái)很大的困難，并影響系統(tǒng)設(shè)計(jì)的完整性。(2) 如果在開(kāi)發(fā)過(guò)程中缺乏嚴(yán)格的過(guò)程管理，演化模型很可能退化為邊寫(xiě)

16、邊改模式。(3) 如果沒(méi)有一定的約束條件，可能永遠(yuǎn)無(wú)法得到一個(gè)最終的軟件產(chǎn)品。 2021年11月7日星期日第26頁(yè)3.2.2 演化模型v采用演化模型的軟件開(kāi)發(fā)過(guò)程，實(shí)際上是從最初的原型逐步演化成最終軟件產(chǎn)品的過(guò)程。在整個(gè)演化過(guò)程中，不斷修正缺陷，以開(kāi)發(fā)出最終滿足用戶需要的軟件產(chǎn)品。v演化模型特別適用于用戶需求不夠明確的軟件開(kāi)發(fā)項(xiàng)目，但不適宜用于大而復(fù)雜的系統(tǒng)。 2021年11月7日星期日第27頁(yè)3.2.3 螺旋模型v對(duì)于復(fù)雜的大型軟件系統(tǒng)，開(kāi)發(fā)一個(gè)原型往往很難達(dá)到要求，顯然用單一的演化模型很難開(kāi)發(fā)出這樣的軟件系統(tǒng)。那么，究竟要使用什么樣的模型才適合用來(lái)開(kāi)發(fā)大型而復(fù)雜的軟件系統(tǒng)呢？答案就是螺旋模

17、型。 2021年11月7日星期日第28頁(yè)3.2.3 螺旋模型v螺旋模型沿著螺線旋轉(zhuǎn)，在笛卡爾坐標(biāo)的四個(gè)象限上分別表達(dá)了每個(gè)迭代周期的四個(gè)階段，從左象限按順時(shí)針?lè)较蛞来螢椋?風(fēng)險(xiǎn) 分析 可運(yùn)行原型 原型 1 原型 2 原型 3 風(fēng)險(xiǎn)分析 風(fēng)險(xiǎn)分析 風(fēng)險(xiǎn)分析 操作概念 需求計(jì)劃、生命周期計(jì)劃 開(kāi)發(fā)計(jì)劃 集成與測(cè)試計(jì)劃 軟件需求 需求確認(rèn) 軟件產(chǎn)品設(shè)計(jì) 設(shè)計(jì)確認(rèn)與驗(yàn)證 詳細(xì)設(shè)計(jì) 編碼 單元測(cè)試 集成測(cè)試 驗(yàn)收測(cè)試 實(shí)施 累計(jì)費(fèi)用 各步驟的進(jìn)度 評(píng)估方案 識(shí)別并排除風(fēng)險(xiǎn) 制定目標(biāo) 選擇方案 設(shè)定約束條件 計(jì)劃下一階段 開(kāi)發(fā)并驗(yàn)證下一級(jí)產(chǎn)品 模擬模型基準(zhǔn) 2021年11月7日星期日第29頁(yè)3.2.3 螺

18、旋模型v(1) 制定計(jì)劃確定該階段的軟件目標(biāo)，選定為完成這些目標(biāo)的實(shí)施方案，設(shè)定這些方案的約束條件。v(2) 風(fēng)險(xiǎn)分析分析所選方案，識(shí)別并努力消除各種潛在的風(fēng)險(xiǎn)，通常用構(gòu)建原型的方法來(lái)消除風(fēng)險(xiǎn)。如果不能消除風(fēng)險(xiǎn)，則停止開(kāi)發(fā)工作或降低軟件項(xiàng)目規(guī)模。如果成功地消除了所有風(fēng)險(xiǎn)，則轉(zhuǎn)向下一個(gè)階段。v(3) 實(shí)施工程實(shí)施軟件開(kāi)發(fā)。這個(gè)階段相當(dāng)于一個(gè)純粹的瀑布模型。v(4) 用戶評(píng)估由用戶評(píng)價(jià)開(kāi)發(fā)工作，提出修改建議。 2021年11月7日星期日第30頁(yè)3.2.3 螺旋模型v螺旋模型將瀑布模型和演化模型結(jié)合起來(lái)，吸取了兩者的優(yōu)點(diǎn)，并加入了兩種模型都忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了兩種模型的不足。 2021年11月7

19、日星期日第31頁(yè)3.2.3 螺旋模型v軟件風(fēng)險(xiǎn)是任何軟件開(kāi)發(fā)項(xiàng)目中普遍存在的實(shí)際問(wèn)題，項(xiàng)目規(guī)模越大，問(wèn)題越復(fù)雜，資源、成本、進(jìn)度等因素的不確定性就越大，承擔(dān)該項(xiàng)目所冒的風(fēng)險(xiǎn)也就越大。軟件風(fēng)險(xiǎn)可能在不同程度上損害軟件的開(kāi)發(fā)過(guò)程和軟件產(chǎn)品的質(zhì)量。因此，在軟件開(kāi)發(fā)過(guò)程中必須及時(shí)對(duì)風(fēng)險(xiǎn)進(jìn)行識(shí)別、分析，采取應(yīng)有的措施，以消除或較少風(fēng)險(xiǎn)的損害。 2021年11月7日星期日第32頁(yè)3.2.3 螺旋模型v在螺旋模型中，沿著螺線由內(nèi)向外每旋轉(zhuǎn)一圈，也就是每完成一次迭代過(guò)程，軟件開(kāi)發(fā)就前進(jìn)一個(gè)層次，開(kāi)發(fā)出一個(gè)更加完善的軟件版本。在每一圈螺線上，風(fēng)險(xiǎn)分析作為開(kāi)發(fā)是否能夠繼續(xù)下去的判斷點(diǎn)。假如風(fēng)險(xiǎn)太大，開(kāi)發(fā)人員和用戶

20、無(wú)法承受，開(kāi)發(fā)項(xiàng)目有可能被終止。但多數(shù)情況下沿螺線的活動(dòng)會(huì)繼續(xù)下去，并由內(nèi)向外逐步延伸，最終得到用戶所期望的系統(tǒng)。 2021年11月7日星期日第33頁(yè)3.2.3 螺旋模型v螺旋模型的優(yōu)點(diǎn)：螺旋模型的優(yōu)點(diǎn)：(1) 設(shè)計(jì)上的靈活性，可以保證在項(xiàng)目的各個(gè)階段進(jìn)行變更。(2) 以小的分段來(lái)構(gòu)建大型系統(tǒng)，使資源、成本和進(jìn)度的估計(jì)變得更加簡(jiǎn)單容易。(3) 用戶始終參與到每個(gè)階段的開(kāi)發(fā)中，保證了項(xiàng)目的正確性與可控性。2021年11月7日星期日第34頁(yè)3.2.3 螺旋模型v螺旋模型的缺點(diǎn)：螺旋模型的缺點(diǎn)：(1) 采用螺旋模型需要具有豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專(zhuān)門(mén)知識(shí)，在風(fēng)險(xiǎn)較大的項(xiàng)目開(kāi)發(fā)中，如果未能及時(shí)識(shí)別出潛在的

21、風(fēng)險(xiǎn)，或者消除風(fēng)險(xiǎn)的能力不足，都會(huì)造成極其重大的損失。(2) 過(guò)多的迭代次數(shù)會(huì)增加軟件開(kāi)發(fā)成本，延遲交付使用的時(shí)間。 2021年11月7日星期日第35頁(yè)3.2.3 螺旋模型v螺旋模型支持需求不明確，特別是大型軟件系統(tǒng)的開(kāi)發(fā)，并支持面向規(guī)格說(shuō)明、面向過(guò)程、面向?qū)ο蟮榷喾N軟件開(kāi)發(fā)方法。由于螺旋模型是以風(fēng)險(xiǎn)分析驅(qū)動(dòng)的，一旦在開(kāi)發(fā)過(guò)程中風(fēng)險(xiǎn)過(guò)大就要停止繼續(xù)開(kāi)發(fā)，因此，螺旋模型比較適合應(yīng)用于產(chǎn)品研發(fā)或機(jī)構(gòu)內(nèi)部大型的復(fù)雜系統(tǒng)的開(kāi)發(fā)，而不適合用于合同項(xiàng)目的開(kāi)發(fā)。如果要將螺旋模型作為合同項(xiàng)目的開(kāi)發(fā)模型，則必須在簽訂合同之前考慮清楚所有的開(kāi)發(fā)風(fēng)險(xiǎn)，否則，在開(kāi)發(fā)過(guò)程中如果由于風(fēng)險(xiǎn)過(guò)大而中途停止開(kāi)發(fā)，就會(huì)賠償經(jīng)濟(jì)損

22、失或者承擔(dān)法律責(zé)任。 2021年11月7日星期日第36頁(yè)3.2.4 增量模型v采用瀑布模型或演化模型開(kāi)發(fā)項(xiàng)目時(shí)，目標(biāo)都是一次性就把一個(gè)滿足所有需求的產(chǎn)品提交給用戶。然而，增量模型則與之不同，它分批地逐步向用戶提交可操作的產(chǎn)品。 2021年11月7日星期日第37頁(yè)3.2.4 增量模型v增量模型融合了瀑布模型的基本成分和快速原型模型的迭代特征。該模型采用隨著日程的進(jìn)展而交錯(cuò)進(jìn)行的線性序列，每一個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量”。v當(dāng)使用增量模型時(shí)，第1個(gè)增量往往是核心產(chǎn)品，即第1個(gè)增量實(shí)現(xiàn)了基本的需求，但很多補(bǔ)充的特征還沒(méi)有發(fā)布?？蛻魧?duì)每一個(gè)增量的使用和評(píng)估都作為下一個(gè)增量發(fā)布的新特征和功能

23、，這個(gè)過(guò)程在每一個(gè)增量發(fā)布后不斷重復(fù)，直到產(chǎn)生了最終的完善產(chǎn)品。v增量模型強(qiáng)調(diào)每一個(gè)增量均發(fā)布一個(gè)可操作的產(chǎn)品。 2021年11月7日星期日第38頁(yè)3.2.4 增量模型 分析 設(shè)計(jì) 實(shí)現(xiàn) 測(cè)試 功能 時(shí)間 分析 設(shè)計(jì) 實(shí)現(xiàn) 測(cè)試 分析 設(shè)計(jì) 實(shí)現(xiàn) 測(cè)試 分析 設(shè)計(jì) 實(shí)現(xiàn) 測(cè)試 增量 1 增量 2 增量 3 增量 4 . 發(fā)布可操作的產(chǎn)品 2021年11月7日星期日第39頁(yè)3.2.4 增量模型v增量模型的優(yōu)點(diǎn)：增量模型的優(yōu)點(diǎn)：(1) 人員分配靈活，剛開(kāi)始不用投入大量人力資源，可以避免不必要的浪費(fèi)。(2) 重要功能被首先交付，可以獲得最多的測(cè)試，保證軟件產(chǎn)品的質(zhì)量。(3) 早期發(fā)布的可操作產(chǎn)品可以

24、作為原型為后期增量開(kāi)發(fā)提供需求。(4) 在較短時(shí)間內(nèi)向用戶提交部分工作的產(chǎn)品，可以讓用戶對(duì)開(kāi)發(fā)項(xiàng)目和開(kāi)發(fā)團(tuán)隊(duì)有信心。(5) 用戶能看到所開(kāi)發(fā)軟件的中間版本，可以使最終產(chǎn)品不至于偏離用戶的需求。(6) 可以將技術(shù)難度大的部分作為早期的增量，能夠有效地管理與控制技術(shù)風(fēng)險(xiǎn)。 2021年11月7日星期日第40頁(yè)3.2.4 增量模型v增量模型的缺點(diǎn)：增量模型的缺點(diǎn)：(1) 在開(kāi)發(fā)過(guò)程中，需求的變化是不可避免的。如果不能有效地控制并管理好需求的變更，增量模型很容易退化為邊寫(xiě)邊改模式，從而使軟件過(guò)程的控制失去整體性。(2) 由于各個(gè)增量逐漸并入已有的結(jié)構(gòu)，所以加入的增量部分不能破壞已構(gòu)造好的系統(tǒng)部分，這需要

25、軟件具備開(kāi)放式的體系結(jié)構(gòu)，對(duì)開(kāi)發(fā)團(tuán)隊(duì)的技術(shù)要求更高。(3) 難以對(duì)所有增量進(jìn)行有效的集成。 2021年11月7日星期日第41頁(yè)3.2.4 增量模型v增量模型與原型模型、演化模型一樣，本質(zhì)上是迭代的，都能應(yīng)用在需求不明確、需求變化大的軟件項(xiàng)目的開(kāi)發(fā)中，但與其它迭代式的模型不一樣的是，增量模型強(qiáng)調(diào)每一個(gè)增量均發(fā)布一個(gè)可操作產(chǎn)品。早期的增量是最終產(chǎn)品的“可拆卸”版本。用戶可對(duì)每一個(gè)可操作產(chǎn)品進(jìn)行評(píng)估，能很好地滿足用戶需求，大大提高了項(xiàng)目的成功率。 2021年11月7日星期日第42頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v在傳統(tǒng)的軟件開(kāi)發(fā)過(guò)程中，最重要的是明確和分解系統(tǒng)功能。這種方法看起來(lái)很符合人們處理事務(wù)的流程，

26、是實(shí)現(xiàn)預(yù)期目標(biāo)的最直接的途徑。然而，一旦系統(tǒng)的需求發(fā)生變化，這種基于功能分解的系統(tǒng)將會(huì)需要大量的修改工作。隨著計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，計(jì)算機(jī)應(yīng)用范圍不斷擴(kuò)大，軟件系統(tǒng)的規(guī)模也變得越來(lái)越龐大?；趥鹘y(tǒng)生命周期的結(jié)構(gòu)化軟件開(kāi)發(fā)方法逐漸暴露出了它自身的一些缺點(diǎn)：難以理解和維護(hù)、可重用性差等。v這些缺點(diǎn)是由什么原因引起的？ 2021年11月7日星期日第43頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v在結(jié)構(gòu)化軟件開(kāi)發(fā)（傳統(tǒng)的面向過(guò)程的軟件開(kāi)發(fā)方法）的整個(gè)過(guò)程中，重點(diǎn)放在了操作上。這些操作是通過(guò)函數(shù)、模塊或一條簡(jiǎn)單的指令來(lái)執(zhí)行的。在整個(gè)開(kāi)發(fā)過(guò)程中，過(guò)程化程序設(shè)計(jì)方法完全將程序中的一個(gè)非常重要的方面數(shù)據(jù)，與操作分離

27、開(kāi)來(lái)，使得數(shù)據(jù)可以被所有函數(shù)或過(guò)程完全訪問(wèn)。 函數(shù) 函數(shù) 函數(shù) 數(shù)據(jù) 數(shù)據(jù) 2021年11月7日星期日第44頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v傳統(tǒng)軟件開(kāi)發(fā)方法遵循軟件生命周期，整個(gè)開(kāi)發(fā)過(guò)程包括可行性研究、需求分析、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測(cè)試和維護(hù)等六個(gè)階段。 2021年11月7日星期日第45頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v結(jié)構(gòu)化方法是傳統(tǒng)軟件開(kāi)發(fā)方法的一個(gè)很好的例子，包括結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計(jì)、結(jié)構(gòu)化編程和結(jié)構(gòu)化測(cè)試等。2021年11月7日星期日第46頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v結(jié)構(gòu)化分析的工具是數(shù)據(jù)流圖和數(shù)據(jù)字典，用來(lái)表達(dá)和理解問(wèn)題的數(shù)據(jù)域和功能域。數(shù)據(jù)域包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)，而功能域則

28、反映這三個(gè)方面的控制信息。通常將一個(gè)復(fù)雜問(wèn)題按功能進(jìn)行分解并逐層細(xì)化。 2021年11月7日星期日第47頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v結(jié)構(gòu)化設(shè)計(jì)的基本思想是模塊化思想。將數(shù)據(jù)流圖進(jìn)一步細(xì)化到每一個(gè)子功能都清晰易懂，每個(gè)模塊完成一個(gè)子功能，每層模塊合成一個(gè)高一級(jí)的功能?？傮w設(shè)計(jì)階段包括數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)、用戶界面設(shè)計(jì)、功能模塊結(jié)構(gòu)設(shè)計(jì)等。詳細(xì)設(shè)計(jì)是根據(jù)每個(gè)模塊的功能設(shè)計(jì)實(shí)現(xiàn)算法以及實(shí)現(xiàn)這些算法的邏輯控制流程。詳細(xì)設(shè)計(jì)的表示工具有程序流程圖、pad圖、n-s圖、判定表和判定樹(shù)、偽碼和pdl等。2021年11月7日星期日第48頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v編程是指把軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換為用某種程序設(shè)計(jì)語(yǔ)言所表

29、示的程序代碼。結(jié)構(gòu)化的程序設(shè)計(jì)語(yǔ)言，例如，fortran、pascal、c等，是通過(guò)把程序劃分成函數(shù)和功能模塊來(lái)控制整個(gè)程序的執(zhí)行流程的。2021年11月7日星期日第49頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v傳統(tǒng)軟件開(kāi)發(fā)方法有以下四個(gè)特點(diǎn)：(1) 以模塊作為基本的構(gòu)造單元。使得編程與現(xiàn)實(shí)世界之間存在理解鴻溝。(2) 自頂向下逐步細(xì)分功能。系統(tǒng)重用性很差。(3) 不同模塊之間的信息傳遞通過(guò)函數(shù)的調(diào)用來(lái)完成。其控制信息傳遞效率極其低下。(4) 堅(jiān)持嚴(yán)格的階段性評(píng)審。雖然能夠保證軟件質(zhì)量，但整個(gè)開(kāi)發(fā)過(guò)程缺少應(yīng)有的靈活性。 2021年11月7日星期日第50頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v當(dāng)函數(shù)與被函數(shù)調(diào)用的數(shù)據(jù)分離

30、時(shí)，數(shù)據(jù)被破壞的可能性極大。另外，當(dāng)數(shù)據(jù)和函數(shù)相互獨(dú)立時(shí)，總存在著用錯(cuò)誤的數(shù)據(jù)調(diào)用正確的程序模塊或用正確的數(shù)據(jù)調(diào)用了錯(cuò)誤的程序模塊的可能性。v所以，需要有一種方法來(lái)約束所有函數(shù)對(duì)數(shù)據(jù)的訪問(wèn)，即將這些數(shù)據(jù)有效地隱藏起來(lái)，這就是面向?qū)ο蟮男畔㈦[藏思想。 2021年11月7日星期日第51頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v傳統(tǒng)的面向過(guò)程的結(jié)構(gòu)化開(kāi)發(fā)方法的另一個(gè)問(wèn)題是它不能很好地表示現(xiàn)實(shí)世界。這些現(xiàn)實(shí)世界中的事物可直接映射到面向?qū)ο蟮慕饪臻g，用面向?qū)ο蟮能浖_(kāi)發(fā)方法能很好地解決現(xiàn)實(shí)世界的問(wèn)題。 2021年11月7日星期日第52頁(yè)3.3 傳統(tǒng)軟件開(kāi)發(fā)方法v為了提高系統(tǒng)的可理解性、可維護(hù)性和可重用性，并能很好地表

31、示現(xiàn)實(shí)世界，開(kāi)發(fā)軟件項(xiàng)目時(shí)，最好采用面向?qū)ο筌浖_(kāi)發(fā)技術(shù)。 2021年11月7日星期日第53頁(yè)3.4 面向?qū)ο筌浖_(kāi)發(fā)技術(shù)v“對(duì)象”一詞在現(xiàn)實(shí)生活中經(jīng)常會(huì)遇到，它表示現(xiàn)實(shí)世界中的某個(gè)具體的事物，例如，一臺(tái)計(jì)算機(jī)。v現(xiàn)實(shí)世界中的事物包含了物質(zhì)和意識(shí)兩大部分，物質(zhì)表達(dá)的是具體的事物，而意識(shí)則描述了某一個(gè)抽象的概念，是對(duì)客觀存在的事物的一種概括。v對(duì)象的概念源于用計(jì)算機(jī)程序?qū)ΜF(xiàn)實(shí)世界的復(fù)雜事物進(jìn)行建模的過(guò)程。2021年11月7日星期日第54頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-1：對(duì)象對(duì)象對(duì)象是指現(xiàn)實(shí)世界中各種各樣的實(shí)體。它既可以是具體的能觸及的事物，如一個(gè)人、一棟大樓、一架飛機(jī)，甚至一個(gè)地

32、球等；也可以是無(wú)法觸及的抽象事物，如一項(xiàng)計(jì)劃、一次約會(huì)、一場(chǎng)演出等。一個(gè)對(duì)象既可以非常簡(jiǎn)單，又可以非常復(fù)雜，復(fù)雜的對(duì)象往往可以由若干個(gè)簡(jiǎn)單的對(duì)象組合而成。 2021年11月7日星期日第55頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅對(duì)象定義了狀態(tài)和行為。對(duì)象的狀態(tài)用數(shù)據(jù)值來(lái)表示，而對(duì)象的行為則用來(lái)改變對(duì)象的狀態(tài)。在面向?qū)ο蟮南到y(tǒng)中，對(duì)象是基本的運(yùn)行實(shí)體。2021年11月7日星期日第56頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅所有這些對(duì)象，除去它們都是現(xiàn)實(shí)世界中所存在的事物之外，它們都還具有各自不同的特征：(1) 有一個(gè)名字用來(lái)區(qū)別于其它對(duì)象。例如：張三、李四等。 2021年11月7日星期日第57頁(yè)3.4.1

33、面向?qū)ο蟮幕靖拍?2) 有一個(gè)狀態(tài)用來(lái)描述對(duì)象的某些特征。例如：v對(duì)象張三的狀態(tài)：姓名：張三性別：男身高：179cm體重：71kg 2021年11月7日星期日第58頁(yè)3.4.1 面向?qū)ο蟮幕靖拍?3) 有一組操作，每一個(gè)操作決定對(duì)象的一種功能或行為。對(duì)象的操作可分為兩類(lèi)：一類(lèi)是自身所承受的操作，使用setter、getter作為操作名；一類(lèi)是施加于其它對(duì)象的操作。例如：v對(duì)象張三的操作（可完成的功能）：回答姓名回答性別回答身高回答體重打電話踢足球駕車(chē) 屬于對(duì)象自身所承受的操作 屬于施加于其它對(duì)象的操作 2021年11月7日星期日第59頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-2：類(lèi)類(lèi)類(lèi)

34、是對(duì)一組客觀對(duì)象的抽象，它將該組對(duì)象所具有的共同特征（包括結(jié)構(gòu)特征和行為特征）集中起來(lái)，以說(shuō)明該組對(duì)象的性質(zhì)和能力。例如：“人”這個(gè)詞就是抽象了所有人（單個(gè)的人，如張三、李四等，這些都是對(duì)象）的共同之處。 2021年11月7日星期日第60頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅在面向?qū)ο缶幊讨?，通常把?lèi)定義為抽象數(shù)據(jù)類(lèi)型，而對(duì)在面向?qū)ο缶幊讨?，通常把?lèi)定義為抽象數(shù)據(jù)類(lèi)型，而對(duì)象是類(lèi)的類(lèi)型變量。當(dāng)定義了一個(gè)類(lèi)以后，就可以生成任象是類(lèi)的類(lèi)型變量。當(dāng)定義了一個(gè)類(lèi)以后，就可以生成任意多個(gè)屬于這個(gè)類(lèi)的對(duì)象，這個(gè)過(guò)程叫做實(shí)例化。例如，意多個(gè)屬于這個(gè)類(lèi)的對(duì)象，這個(gè)過(guò)程叫做實(shí)例化。例如，用用java語(yǔ)言定義一個(gè)類(lèi)語(yǔ)

35、言定義一個(gè)類(lèi)car為：為：public class car v這時(shí)可生成任意多個(gè)屬于這時(shí)可生成任意多個(gè)屬于car類(lèi)的對(duì)象：類(lèi)的對(duì)象：car car1 = new car();car car2 = new car(); 2021年11月7日星期日第61頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-3：類(lèi)與對(duì)象的關(guān)系：類(lèi)與對(duì)象的關(guān)系組成類(lèi)的對(duì)象均為該類(lèi)的實(shí)例。類(lèi)與對(duì)象之間的關(guān)系就是抽象與具體的關(guān)系。例如，張三是一個(gè)學(xué)生，學(xué)生是一個(gè)類(lèi)，而張三作為一個(gè)具體的對(duì)象，是學(xué)生類(lèi)的一個(gè)實(shí)例。類(lèi)是多個(gè)實(shí)例的綜合抽象，而實(shí)例又是類(lèi)的個(gè)體事物。 2021年11月7日星期日第62頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅在面

36、向?qū)ο缶幊讨?，定義一個(gè)類(lèi)就定義了這個(gè)類(lèi)的一系列屬性與操作，對(duì)于同一個(gè)類(lèi)的不同實(shí)例之間，必定具有如下特點(diǎn)：(1) 相同的屬性集合；(2) 相同的操作集合；(3) 不同的對(duì)象名。 2021年11月7日星期日第63頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅相同的屬性集合與操作集合用于標(biāo)識(shí)這些對(duì)象屬于同一個(gè)類(lèi)，用不同的對(duì)象名來(lái)區(qū)別不同的對(duì)象。2021年11月7日星期日第64頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-4：面向?qū)ο螅好嫦驅(qū)ο竺嫦驅(qū)ο螅╫bject-oriented，簡(jiǎn)稱(chēng)oo）是指人們按照自然的思維方式認(rèn)識(shí)客觀世界，采用基于對(duì)象（實(shí)體）的概念建立模型，模擬客觀世界，從而用來(lái)分析、設(shè)計(jì)和實(shí)現(xiàn)軟件的

37、方法。把軟件組織成一系列離散的、合并了數(shù)據(jù)結(jié)構(gòu)和行為的對(duì)象集。 2021年11月7日星期日第65頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅面向?qū)ο笫钱?dāng)前計(jì)算機(jī)界關(guān)注的重點(diǎn)，它是90年代主流軟件開(kāi)發(fā)方法。通過(guò)面向?qū)ο蟮睦砟钍褂?jì)算機(jī)軟件系統(tǒng)能與現(xiàn)實(shí)世界中的系統(tǒng)一一對(duì)應(yīng)。面向?qū)ο蟮母拍詈蛻?yīng)用已超越了程序設(shè)計(jì)和軟件開(kāi)發(fā)，擴(kuò)展到很寬的范圍。如數(shù)據(jù)庫(kù)系統(tǒng)、分布式系統(tǒng)、人工智能等領(lǐng)域。 2021年11月7日星期日第66頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅采用面向?qū)ο蠹夹g(shù)開(kāi)發(fā)軟件的方法，稱(chēng)為面向?qū)ο筌浖_(kāi)發(fā)方法。面向?qū)ο蠓椒ň哂幸韵聨讉€(gè)特性：(1) 對(duì)象唯一性v每個(gè)對(duì)象都有唯一的標(biāo)識(shí)（如同人們的身份證號(hào)碼），通過(guò)這個(gè)標(biāo)

38、識(shí)，可以找到相應(yīng)的對(duì)象。在對(duì)象的整個(gè)生命周期（從對(duì)象的創(chuàng)建到對(duì)象的消亡）中，它的標(biāo)識(shí)都不會(huì)改變。不同的對(duì)象（即使其它屬性完全相同，例如兩個(gè)完全一樣的球）必須具有不同的標(biāo)識(shí)。(2) 封裝性v具有一致的數(shù)據(jù)結(jié)構(gòu)（屬性）和行為（操作）的對(duì)象抽象成類(lèi)。(3) 繼承性v子類(lèi)自動(dòng)共享父類(lèi)的數(shù)據(jù)結(jié)構(gòu)和行為的機(jī)制，這是類(lèi)之間的一種關(guān)系。繼承性是面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言不同于其它程序設(shè)計(jì)語(yǔ)言最重要的特點(diǎn)，是其它語(yǔ)言所沒(méi)有的。(4) 多態(tài)性v它是面向?qū)ο笙到y(tǒng)中的又一個(gè)重要特性。多態(tài)性描述的是同一個(gè)消息可以根據(jù)發(fā)送消息對(duì)象的不同采用多種不同的行為方式。即是指相同的操作或函數(shù)可作用于多種類(lèi)型的對(duì)象上并獲得不同的結(jié)果。不同

39、的對(duì)象，收到同一消息可以產(chǎn)生不同的結(jié)果，這種現(xiàn)象就稱(chēng)為多態(tài)性。 2021年11月7日星期日第67頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-5：封裝及面向?qū)ο笙到y(tǒng)的封裝性：封裝及面向?qū)ο笙到y(tǒng)的封裝性封裝也叫做信息隱藏。從字面上理解，封裝就是將某事物包裝起來(lái)，使外界不了解其實(shí)際內(nèi)容。從軟件開(kāi)發(fā)的角度，封裝是指將一個(gè)數(shù)據(jù)和與這個(gè)數(shù)據(jù)有關(guān)的各種操作放在一起，形成一個(gè)能動(dòng)的實(shí)體對(duì)象，使用者不必知道對(duì)象的內(nèi)部結(jié)構(gòu)，只需根據(jù)對(duì)象提供的外部接口訪問(wèn)對(duì)象。從使用者的角度看，這些對(duì)象就像一個(gè)“黑盒子”，其內(nèi)部數(shù)據(jù)和行為是被隱藏起來(lái)、看不見(jiàn)的。面向?qū)ο笙到y(tǒng)的封裝性是一種信息隱藏技術(shù)，它隱藏了某一方法的具體執(zhí)行步

40、驟，取而代之的是通過(guò)消息傳遞機(jī)制傳遞消息給它。 2021年11月7日星期日第68頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅封裝的意義在于保護(hù)或者防止數(shù)據(jù)或者程序代碼被我們無(wú)意中破壞，以提高系統(tǒng)的安全性。既然封裝了對(duì)象，那么，怎樣才能訪問(wèn)對(duì)象呢？答案是通過(guò)對(duì)象提供的公共消息接口來(lái)訪問(wèn)對(duì)象。下面是一個(gè)用java語(yǔ)言所定義的類(lèi)： 2021年11月7日星期日第69頁(yè)3.4.1 面向?qū)ο蟮幕靖拍頿ublic class employee private string name; private int age; private float salary; private string rank; privat

41、e void calculatesalary(float subtract) salary = salary subtract; protected int getage() return age; public void setsalary(float salary) this.salary = salary; public float getsalary() return salary; 2021年11月7日星期日第70頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅在上面所定義的職員（employee）類(lèi)中，包含的數(shù)據(jù)有職員姓名（name）、年齡（age）、工資（salary）、職位（rank）。這些

42、數(shù)據(jù)被定義為私有數(shù)據(jù)（用private定義），就被隱藏起來(lái)，對(duì)于外部對(duì)象來(lái)說(shuō)就不可以直接訪問(wèn)了。它所包含的成員方法或成員函數(shù)（操作）有三種類(lèi)型的可見(jiàn)性： 2021年11月7日星期日第71頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅(1) 私有的用private關(guān)鍵字標(biāo)識(shí)，如：calculatesalary，這樣的成員方法或函數(shù)不向外部公開(kāi)，只供對(duì)象內(nèi)部自己使用。v(2) 受保護(hù)的用protected關(guān)鍵字標(biāo)識(shí)，如：getage，這樣的成員方法或函數(shù)只向部分外界公開(kāi)，只對(duì)派生類(lèi)對(duì)象提供服務(wù)。v(3) 公有的用public關(guān)鍵字標(biāo)識(shí)，如：getsalary等，這樣的成員方法或函數(shù)向所有的外界公開(kāi)，它可以響應(yīng)

43、外界對(duì)象的請(qǐng)求。 2021年11月7日星期日第72頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅定義為公有的成員方法或函數(shù)，才是對(duì)象提供的公共消息接口。外部對(duì)象只有通過(guò)這些公共接口才能訪問(wèn)到對(duì)象的內(nèi)部數(shù)據(jù)，這就是所謂的信息隱藏技術(shù)。 2021年11月7日星期日第73頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅根據(jù)對(duì)封裝的定義可以看出，封裝應(yīng)該具有下面幾個(gè)條件：(1) 具有一個(gè)清晰的邊界。對(duì)象所有的私有數(shù)據(jù)、成員方法或函數(shù)的實(shí)現(xiàn)細(xì)節(jié)都被固定在這個(gè)邊界內(nèi)。(2) 具有一個(gè)接口。這個(gè)接口描述了對(duì)象之間的交互作用，它就是消息。(3) 對(duì)象內(nèi)部的實(shí)現(xiàn)代碼受到封裝體的保護(hù)，其它對(duì)象不能直接修改本對(duì)象所擁有的數(shù)據(jù)和代碼。 202

44、1年11月7日星期日第74頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅面向?qū)ο笙到y(tǒng)中的封裝以對(duì)象為單位，即主要是指對(duì)象的封裝，該對(duì)象的特性是由它所屬的類(lèi)說(shuō)明來(lái)描述，也就是說(shuō)在類(lèi)的定義中實(shí)現(xiàn)封裝。被封裝的對(duì)象通常被稱(chēng)為抽象數(shù)據(jù)類(lèi)型。封裝性提高了對(duì)象內(nèi)部數(shù)據(jù)的安全性。 2021年11月7日星期日第75頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-6：繼承及面向?qū)ο笙到y(tǒng)的繼承性：繼承及面向?qū)ο笙到y(tǒng)的繼承性繼承是指一個(gè)類(lèi)能夠從另一個(gè)類(lèi)那里獲得一些特性。在這個(gè)過(guò)程中，超類(lèi)把它的特性賦給了子類(lèi)。面向?qū)ο笙到y(tǒng)的繼承性是對(duì)具有層次關(guān)系的類(lèi)的屬性和操作進(jìn)行共享的一種方式。在面向?qū)ο笙到y(tǒng)中，若沒(méi)有引入繼承的概念，所有的類(lèi)就

45、會(huì)變成一盤(pán)各自為政、彼此獨(dú)立的散沙，軟件重用級(jí)別較低，每次軟件開(kāi)發(fā)就只能從“零”開(kāi)始。 2021年11月7日星期日第76頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅繼承是面向?qū)ο筌浖夹g(shù)中的一個(gè)概念。如果一個(gè)類(lèi)a繼承自另一個(gè)類(lèi)b，就把這個(gè)a稱(chēng)為b的“子類(lèi)”或“派生類(lèi)”，而把b稱(chēng)為a的“父類(lèi)”或“超類(lèi)”或“基類(lèi)”。例如，在通常的信息管理應(yīng)用系統(tǒng)中，都會(huì)涉及到用戶權(quán)限管理，常常會(huì)有“一般用戶”和“系統(tǒng)管理員”兩種角色，而“一般用戶”和“系統(tǒng)管理員”都是“用戶”，所以，“一般用戶”類(lèi)和“系統(tǒng)管理員”類(lèi)都可以繼承自“用戶”類(lèi)。在這里，“一般用戶”類(lèi)和“系統(tǒng)管理員”類(lèi)都是“用戶”類(lèi)的子類(lèi)，而“用戶”類(lèi)則是“一般用

46、戶”類(lèi)和“系統(tǒng)管理員”類(lèi)的父類(lèi)。 2021年11月7日星期日第77頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅繼承可以使得子類(lèi)具有父類(lèi)的各種屬性和方法，而不需要再次編寫(xiě)相同的代碼。在子類(lèi)繼承父類(lèi)時(shí)，既可以重新定義子類(lèi)的某些屬性和方法，也可以重寫(xiě)某些方法，來(lái)覆蓋父類(lèi)的原有屬性和方法，使其獲得與父類(lèi)不同的功能。2021年11月7日星期日第78頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅繼承有兩個(gè)方面的作用：避免代碼冗余，提高可理解性和可維護(hù)性；繼承是從老對(duì)象生成新對(duì)象的一種代碼重用機(jī)制，使系統(tǒng)更具靈活性和適應(yīng)性，它使得解釋多態(tài)性成為可能。2021年11月7日星期日第79頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅繼承有單繼承和

47、多繼承之分。 圖形 三角形 矩形 橢圓形 圓形 正方形 長(zhǎng)方形 對(duì)話框 列表框 文本框 組合框 復(fù)選框 各種按鈕 單繼承多繼承2021年11月7日星期日第80頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅多重繼承的引入，使面向?qū)ο笙到y(tǒng)大大增加了模擬現(xiàn)實(shí)世界的能力，但是系統(tǒng)結(jié)構(gòu)變得非常復(fù)雜，增加了系統(tǒng)的理解與維護(hù)難度。v在面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言中，c+支持多繼承，而java語(yǔ)言只支持單繼承，不支持多繼承。 2021年11月7日星期日第81頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅在面向?qū)ο箝_(kāi)發(fā)中，繼承性不僅作用在對(duì)操作的繼承，還作用在對(duì)數(shù)據(jù)的繼承，也就是說(shuō)，既具有結(jié)構(gòu)特性的繼承性，又具有行為特性的繼承性。v子類(lèi)是否可

48、以訪問(wèn)父類(lèi)的所有成員變量和成員方法（或成員函數(shù)）？在前面介紹封裝性時(shí)談到，定義類(lèi)的數(shù)據(jù)成員與方法成員有三種訪問(wèn)域（三種可見(jiàn)性），即公有訪問(wèn)域（public）、受保護(hù)訪問(wèn)域（protected）、私有訪問(wèn)域（private）。父類(lèi)的成員若定義為受保護(hù)訪問(wèn)域和公有訪問(wèn)域，子類(lèi)是可以訪問(wèn)的；若父類(lèi)成員定義為私有訪問(wèn)域，子類(lèi)則無(wú)權(quán)訪問(wèn)。2021年11月7日星期日第82頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-7：重載及面向?qū)ο笙到y(tǒng)的多態(tài)性：重載及面向?qū)ο笙到y(tǒng)的多態(tài)性一個(gè)類(lèi)中的操作具有相同的名稱(chēng)和不同的參數(shù)，這樣的操作被稱(chēng)為“重載”。面向?qū)ο笙到y(tǒng)的多態(tài)性是指，當(dāng)不同的對(duì)象收到相同的消息時(shí)產(chǎn)生不同的動(dòng)

49、作。常用在功能相同但參數(shù)的數(shù)據(jù)類(lèi)型有微小差別的操作中。 2021年11月7日星期日第83頁(yè)3.4.1 面向?qū)ο蟮幕靖拍顅操作名、參數(shù)及其類(lèi)型和操作的返回類(lèi)型合在一起稱(chēng)為操作的簽名（注：這里的操作就是方法或函數(shù)）。一個(gè)類(lèi)中的所有操作都必須具有唯一的簽名，即是說(shuō)一個(gè)類(lèi)中不能存在兩個(gè)相同簽名的操作。v具有相同名稱(chēng)和參數(shù)但是返回類(lèi)型不同的操作不能稱(chēng)為重載，因?yàn)樵谡{(diào)用操作時(shí)并沒(méi)有描述操作的返回類(lèi)型，被調(diào)用的對(duì)象不能分辨出僅僅是返回類(lèi)型不同的兩個(gè)操作，因此這樣的操作具有歧義性，是無(wú)效的。2021年11月7日星期日第84頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v傳統(tǒng)的軟件開(kāi)發(fā)生命周期包含了六個(gè)階段：制定計(jì)劃、需求分析

50、和定義、設(shè)計(jì)、編碼、測(cè)試、運(yùn)行與維護(hù)，面向?qū)ο蟮拈_(kāi)發(fā)和傳統(tǒng)的軟件開(kāi)發(fā)方法不同，它是一種基于現(xiàn)實(shí)世界抽象的新的軟件開(kāi)發(fā)方法。v那么，面向?qū)ο蟮能浖_(kāi)發(fā)中，軟件生命周期又可分為哪幾個(gè)階段？各個(gè)階段主要完成哪些任務(wù)？2021年11月7日星期日第85頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v在面向?qū)ο蟮能浖_(kāi)發(fā)中，軟件生命周期可分為以下幾個(gè)階段：v(1) 系統(tǒng)分析階段在這個(gè)階段，需要建立一個(gè)反映現(xiàn)實(shí)客觀世界情形的模型。為了建立這個(gè)模型，需要分析員和需求人員共同明確現(xiàn)實(shí)世界中的問(wèn)題。這個(gè)模型應(yīng)該解決系統(tǒng)必須做什么，而不是怎么做的問(wèn)題。分析之后將得到分析模型：對(duì)象模型、動(dòng)態(tài)模型和功能模型。v(2) 系統(tǒng)設(shè)計(jì)階段這個(gè)階

51、段需要給出怎樣解決問(wèn)題的決策。包括將系統(tǒng)劃分成子系統(tǒng)和子系統(tǒng)軟硬件如何配置，確定系統(tǒng)的整體框架結(jié)構(gòu)。 2021年11月7日星期日第86頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v(3) 對(duì)象設(shè)計(jì)階段該階段將應(yīng)用領(lǐng)域的概念轉(zhuǎn)換為計(jì)算機(jī)軟件領(lǐng)域的概念。在系統(tǒng)分析階段所定義的問(wèn)題，在這個(gè)階段來(lái)確定解決問(wèn)題的方法。將分析模型的邏輯結(jié)構(gòu)映射到一個(gè)程序的物理組織，得到設(shè)計(jì)模型。v(4) 實(shí)現(xiàn)階段在這個(gè)階段，將在對(duì)象設(shè)計(jì)階段開(kāi)發(fā)的類(lèi)轉(zhuǎn)換成用特定的程序設(shè)計(jì)語(yǔ)言編寫(xiě)的代碼或數(shù)據(jù)庫(kù)。v(5) 測(cè)試階段傳統(tǒng)軟件開(kāi)發(fā)的測(cè)試通常經(jīng)過(guò)單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試三個(gè)環(huán)節(jié)。由于面向?qū)ο笥衅渥陨淼奶攸c(diǎn)，參考面向?qū)ο筌浖_(kāi)發(fā)模式，面向?qū)ο箝_(kāi)

52、發(fā)測(cè)試包括面向?qū)ο蠓治龅臏y(cè)試、面向?qū)ο笤O(shè)計(jì)的測(cè)試、面向?qū)ο缶幊痰臏y(cè)試、面向?qū)ο髥卧獪y(cè)試、面向?qū)ο蠹蓽y(cè)試和面向?qū)ο笙到y(tǒng)測(cè)試。 2021年11月7日星期日第87頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v面向?qū)ο箝_(kāi)發(fā)同樣包含了傳統(tǒng)軟件開(kāi)發(fā)的幾個(gè)階段：分析、設(shè)計(jì)、編碼、測(cè)試等，但面向?qū)ο箝_(kāi)發(fā)是用“面向?qū)ο蟆钡挠^點(diǎn)去認(rèn)識(shí)客觀世界，用“面向?qū)ο蟆钡姆椒ㄈツM客觀世界，所以，在分析階段主要分析現(xiàn)實(shí)世界中的對(duì)象以及對(duì)象與對(duì)象之間的關(guān)系，在設(shè)計(jì)階段除了對(duì)整個(gè)系統(tǒng)的架構(gòu)設(shè)計(jì)外，主要針對(duì)對(duì)象（或類(lèi)）以及對(duì)象（或類(lèi)）與對(duì)象（或類(lèi)）之間的關(guān)系進(jìn)行設(shè)計(jì)，在編碼階段使用面向?qū)ο缶幊陶Z(yǔ)言實(shí)現(xiàn)類(lèi)的各項(xiàng)功能，而在測(cè)試階段則使用面向?qū)ο蟮臏y(cè)

53、試方法與技術(shù)。 2021年11月7日星期日第88頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v人們對(duì)客觀世界的認(rèn)識(shí)是一個(gè)從簡(jiǎn)單到復(fù)雜、從知之不多到知之甚多的反復(fù)的認(rèn)識(shí)過(guò)程，因此，面向?qū)ο蟮能浖_(kāi)發(fā)也將是一個(gè)反復(fù)的迭代過(guò)程，但這種反復(fù)不是簡(jiǎn)單的重復(fù)，而是在前一個(gè)迭代周期基礎(chǔ)上對(duì)于問(wèn)題領(lǐng)域的認(rèn)識(shí)有所提高。 2021年11月7日星期日第89頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v面向?qū)ο箝_(kāi)發(fā)生命周期是一個(gè)迭代的增量式過(guò)程，因此，使用面向?qū)ο筌浖_(kāi)發(fā)技術(shù)能很好地適應(yīng)系統(tǒng)需求的變化，并能提高軟件的可理解性、可維護(hù)性和可重用性，以致于提高軟件企業(yè)的可持續(xù)發(fā)展性。 2021年11月7日星期日第90頁(yè)3.4.2 面向?qū)ο蟮拈_(kāi)發(fā)v面向?qū)?/p>

54、象的分析與設(shè)計(jì)過(guò)程適合于使用uml來(lái)建模，同時(shí)，使用uml建模工具可以將模型（對(duì)于嵌入式系統(tǒng)，通常指狀態(tài)圖；而對(duì)于一般系統(tǒng)，則是指類(lèi)圖）映射為特定編程語(yǔ)言的程序代碼，也可以將永久類(lèi)映射為關(guān)系數(shù)據(jù)庫(kù)結(jié)構(gòu)，還能將分析模型中得到的邊界類(lèi)的屬性與操作部分映射為用戶界面中的圖形元素。v面向?qū)ο箝_(kāi)發(fā)特別適合采用下一節(jié)將要介紹的rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程。 2021年11月7日星期日第91頁(yè)3.5 rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程vrup（rational unified process，統(tǒng)一軟件開(kāi)發(fā)過(guò)程），是由ibm rational公司提出來(lái)的。它是一個(gè)通用的過(guò)程框架，適用面非常廣，可以適用于不同種類(lèi)的軟件系統(tǒng)、應(yīng)用

55、領(lǐng)域、組織類(lèi)型、性能水平和項(xiàng)目規(guī)模。它是一個(gè)演化的開(kāi)發(fā)過(guò)程。 2021年11月7日星期日第92頁(yè)3.5 rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程vrup是基于構(gòu)件的開(kāi)發(fā)過(guò)程，在開(kāi)發(fā)過(guò)程中非常重視構(gòu)件的應(yīng)用。這意味著利用它開(kāi)發(fā)的軟件系統(tǒng)是由構(gòu)件組成的，構(gòu)件之間通過(guò)定義良好的接口相互聯(lián)系。與其它軟件過(guò)程相比，rup具有三個(gè)顯著的特點(diǎn)：2021年11月7日星期日第93頁(yè)3.5 rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程v(1) 它是用例驅(qū)動(dòng)的過(guò)程。根據(jù)需求分析的用例來(lái)構(gòu)建需要的系統(tǒng)行為。用例定義了系統(tǒng)功能的使用環(huán)境和上下文，每個(gè)用例描述的是一個(gè)完整的系統(tǒng)服務(wù)。 2021年11月7日星期日第94頁(yè)3.5 rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程v(2) 它

56、是迭代和增量式的過(guò)程。每次迭代都產(chǎn)生一個(gè)可執(zhí)行的版本。每次迭代時(shí)，都選用一組還沒(méi)有實(shí)現(xiàn)的用例來(lái)作為增量進(jìn)行開(kāi)發(fā)，優(yōu)先識(shí)別并著手實(shí)現(xiàn)風(fēng)險(xiǎn)較大的用例，例如，集中所有的技術(shù)力量?jī)?yōu)先解決技術(shù)難度最大的用例。 2021年11月7日星期日第95頁(yè)3.5 rup統(tǒng)一軟件開(kāi)發(fā)過(guò)程v(3) 它是以基本架構(gòu)為中心的過(guò)程。在開(kāi)發(fā)之前，首先根據(jù)平臺(tái)而不考慮用例來(lái)設(shè)計(jì)系統(tǒng)架構(gòu)，然后，選用其中幾個(gè)成熟的用例來(lái)修改或擴(kuò)展先前的架構(gòu)，用系統(tǒng)架構(gòu)來(lái)概念化、建立管理和發(fā)展開(kāi)發(fā)之中的系統(tǒng)。 2021年11月7日星期日第96頁(yè)3.5.1rup生命周期vrup是一種軟件開(kāi)發(fā)過(guò)程，包括開(kāi)發(fā)過(guò)程、管理過(guò)程和支撐過(guò)程，它的生命周期是怎樣的呢

57、？ 2021年11月7日星期日第97頁(yè)3.5.1rup生命周期v與傳統(tǒng)的一維瀑布開(kāi)發(fā)模型不同，rup軟件開(kāi)發(fā)生命周期是一個(gè)二維的開(kāi)發(fā)模型。橫軸表示軟件過(guò)程的時(shí)間維，是過(guò)程展開(kāi)的生命周期特征，體現(xiàn)開(kāi)發(fā)過(guò)程的動(dòng)態(tài)結(jié)構(gòu)，被分成四個(gè)順序階段，分別是：先啟階段（inception），精化階段（elaboration），構(gòu)造階段（construction），移交階段（transition）。每個(gè)階段以一個(gè)主要里程碑結(jié)束。每個(gè)階段結(jié)束時(shí)都要安排一次技術(shù)評(píng)審，以確定是否符合該階段的目標(biāo)。如果評(píng)審令人滿意，則允許項(xiàng)目進(jìn)入下一個(gè)階段?？v軸表示內(nèi)容維，體現(xiàn)開(kāi)發(fā)過(guò)程的靜態(tài)結(jié)構(gòu)，描述按性質(zhì)將活動(dòng)邏輯地進(jìn)行分組的工作流程

58、。 2021年11月7日星期日第98頁(yè)3.5.1rup生命周期 先啟 精化 構(gòu)造 移交 階階 段段 環(huán)境 項(xiàng)目管理 配置和變更管理 部署 測(cè)試 實(shí)施 分析與設(shè)計(jì) 需求 業(yè)務(wù)建模 工作流程工作流程 初始 e1 c1 t1 t2 c2 cn e2 迭迭 代代 2021年11月7日星期日第99頁(yè)3.5.1rup生命周期v(1) 先啟階段這是開(kāi)發(fā)生命周期的第一階段。其主要目標(biāo)是實(shí)現(xiàn)所有項(xiàng)目相關(guān)人員在項(xiàng)目的生命周期目標(biāo)上達(dá)成一致，把開(kāi)發(fā)的主要思想確定為現(xiàn)實(shí)的目標(biāo)。其任務(wù)是為系統(tǒng)建立業(yè)務(wù)模型并確定項(xiàng)目的軟件范圍和邊界條件，識(shí)別出系統(tǒng)的關(guān)鍵用例，確定至少一個(gè)體系結(jié)構(gòu)方案，評(píng)估整個(gè)項(xiàng)目的整體成本和進(jìn)度安排、評(píng)

59、估潛在風(fēng)險(xiǎn)，準(zhǔn)備項(xiàng)目的支持環(huán)境。這個(gè)階段所關(guān)注的是整個(gè)項(xiàng)目的業(yè)務(wù)和需求方面的主要風(fēng)險(xiǎn)。主要包括以下幾個(gè)基本活動(dòng)： 2021年11月7日星期日第100頁(yè)3.5.1rup生命周期v 明確項(xiàng)目規(guī)模建立項(xiàng)目的軟件規(guī)模和邊界條件，包括驗(yàn)收標(biāo)準(zhǔn)，了解環(huán)境及重要的需求和約束，識(shí)別系統(tǒng)的關(guān)鍵用例。v 評(píng)估項(xiàng)目風(fēng)險(xiǎn)針對(duì)軟件開(kāi)發(fā)涉及到的風(fēng)險(xiǎn)，包括在軟件開(kāi)發(fā)中可能出現(xiàn)的風(fēng)險(xiǎn)和軟件實(shí)施過(guò)程中外部環(huán)境的變化可能引起的風(fēng)險(xiǎn)等進(jìn)行評(píng)估。v 制定項(xiàng)目計(jì)劃綜合考慮備選構(gòu)架，評(píng)估設(shè)計(jì)和自制或外購(gòu)或重用方面的方案，從而估算出項(xiàng)目成本、進(jìn)度和資源等。v 準(zhǔn)備項(xiàng)目環(huán)境評(píng)估項(xiàng)目和組織，選擇開(kāi)發(fā)工具，確定要改進(jìn)哪些流程部分。v 階段技術(shù)評(píng)

60、審在評(píng)審過(guò)程中，需要考慮項(xiàng)目的規(guī)模定義，成本和進(jìn)度估算是否適中，估算根據(jù)是否可靠，需求是否正確，開(kāi)發(fā)方和用戶方對(duì)軟件需求的理解是否達(dá)成一致，是否已確定所有風(fēng)險(xiǎn)，并且針對(duì)每個(gè)風(fēng)險(xiǎn)有相應(yīng)的風(fēng)險(xiǎn)回避措施等問(wèn)題。 2021年11月7日星期日第101頁(yè)3.5.1rup生命周期v初始階段結(jié)束時(shí)是第一個(gè)重要的里程碑：生命周期目標(biāo)（lifecycle objective）里程碑。用來(lái)評(píng)價(jià)項(xiàng)目基本的生存能力，決定是繼續(xù)該項(xiàng)目還是取消它。2021年11月7日星期日第102頁(yè)3.5.1rup生命周期v(2) 精化階段這是開(kāi)發(fā)過(guò)程的第二階段。該階段的目標(biāo)是建立系統(tǒng)架構(gòu)的基線，為構(gòu)造階段中的大量設(shè)計(jì)和實(shí)施工作提供穩(wěn)固基