《軟件工程基礎(chǔ)》第2章-軟件開發(fā)過程

《《軟件工程基礎(chǔ)》第2章-軟件開發(fā)過程》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。

1/38第2章軟件開發(fā)過程2.1軟件過程2.2常見的軟件過程模型2.3軟件過程的新發(fā)展 2/38第2章軟件開發(fā)過程2.1軟件過程2.1.1軟件過程的概念與理論基礎(chǔ)2.1.2軟件過程討論的主要內(nèi)容2.2常見的軟件過程模型2.3軟件過程的新發(fā)展 3/382.1.1軟件過程的概念與理論基礎(chǔ)軟件過程的概念軟件過程模型的理論基礎(chǔ) 4/38軟件過程的概念軟件過程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。在完成開發(fā)任務(wù)時必須進(jìn)行一系列開發(fā)活動，并且使用適當(dāng)?shù)馁Y源，在過程結(jié)束時將把輸入轉(zhuǎn)化為輸出。因此，ISO9000把過程定義為“使用資源將輸入轉(zhuǎn)化為輸出的活動所構(gòu)成的系統(tǒng)?！边^程定義了運(yùn)用方法的順序、應(yīng)該交付的文檔資料、為保證軟件質(zhì)量和協(xié)調(diào)變化所需要采取的管理措施，以及標(biāo)志軟件開發(fā)各個階段任務(wù)完成的里程碑。 5/38軟件過程模型及理論基礎(chǔ)通常使用生命周期模型簡潔地描述軟件過程。建立軟件開發(fā)過程模型的理論基礎(chǔ)是軟件生命周期理論和相關(guān)的軟件工程原則，因此，軟件過程模型又稱軟件生命周期模型（SoftwareLifeCycleModel）其核心思想主張把軟件過程劃分成若干個階段，每個階段所包含的活動內(nèi)容和性質(zhì)具有“高內(nèi)聚，低藕合”的特征，這樣有助于簡化問題、有助于驗(yàn)證階段性的工作成果、有助于對軟件工程的施工與管理。生命周期模型規(guī)定了把生命周期劃分成哪些階段及各個階段的執(zhí)行順序，因此，也稱為過程模型。軟件過程模型是對軟件開發(fā)活動進(jìn)行有效地組織、協(xié)調(diào)、管理與控制的一種策略過程模型化是為了便于理解和操作。 6/38SoftwareLifeCycleModel 7/382.1.2軟件過程討論的主要內(nèi)容軟件過程討論的主要內(nèi)容包括軟件過程模型、項(xiàng)目軟件過程定義、軟件過程裁剪、軟件過程改進(jìn)及軟件能力成熟度的評價等內(nèi)容。軟件過程模型給出了適合不同軟件項(xiàng)目的軟件過程活動組織的參考框架。對不同的軟件組織來講，典型軟件過程模型僅僅是理論參考框架。為了不斷提高軟件能力，軟件組織（企業(yè)與團(tuán)隊(duì)）應(yīng)該不斷積累經(jīng)驗(yàn)，針對不同的軟件項(xiàng)目和軟件組織自身的特點(diǎn)，在軟件過程定義、軟件過程裁剪、軟件過程改進(jìn)等方面不斷努力和提高。軟件能力成熟度模型（CMM）是對一個軟件組織的軟件能力成熟度進(jìn)行評價的框架模型，它同時對軟件組織不斷提高軟件能力具有的一定的促進(jìn)作用。 8/382.2常見的軟件過程模型軟件過程包括軟件開發(fā)過程和軟件維護(hù)過程。實(shí)踐中，人們基于軟件工程方法論和軟件項(xiàng)目特點(diǎn)總結(jié)出了不同的軟件過程模型。好的過程模型吸收了成功的軟件工程經(jīng)驗(yàn)和有效的軟件工程原則，因此參考軟件過程模型框架組織軟件項(xiàng)目有利于提高工作效率、把握開發(fā)質(zhì)量，總體上可以提高軟件項(xiàng)目的成功率。為獲得高質(zhì)量的軟件產(chǎn)品，軟件過程必須科學(xué)、有效。沒有一個適用于所有軟件項(xiàng)目的任務(wù)集合。因此，科學(xué)、有效的軟件過程應(yīng)該定義一組適合于所承擔(dān)的項(xiàng)目特點(diǎn)的任務(wù)集合。通常，一個任務(wù)集合包括一組軟件工程任務(wù)、里程碑和應(yīng)該交付的產(chǎn)品。 9/38典型的過程模型實(shí)際的軟件開發(fā)活動中，應(yīng)該項(xiàng)目的特點(diǎn)來劃分階段，但是，下面講述典型的軟件過程模型時并不是針對某個特定項(xiàng)目講的，因此只能使用“通用的”階段劃分方法。由于瀑布模型與快速原型模型的主要區(qū)別是獲取用戶需求的方法不同，因此，下面在介紹生命周期模型時把“規(guī)格說明”作為一個階段獨(dú)立出來。此外，問題定義和可行性研究的主要任務(wù)都是概括地了解用戶的需求，為了簡潔地描述軟件過程，把它們都?xì)w并到需求分析中去了。同樣，為了簡潔起見，把總體設(shè)計和詳細(xì)設(shè)計合并在一起稱為“設(shè)計”。 10/381.4.1瀑布模型在20世紀(jì)80年代之前，瀑布模型一直是惟一被廣泛采用的生命周期模型，現(xiàn)在它仍然是軟件工程中應(yīng)用得最廣泛的過程模型。傳統(tǒng)軟件工程方法學(xué)的軟件過程，基本上可以用瀑布模型來描述。圖1.2所示為傳統(tǒng)的瀑布模型。按照傳統(tǒng)的瀑布模型開發(fā)軟件，有下述的幾個特點(diǎn)。 11/38圖1.2傳統(tǒng)的瀑布模型 12/381.階段間具有順序性和依賴性這個特點(diǎn)有兩重含義：①必須等前一階段的工作完成之后，才能開始后一階段的工作；②前一階段的輸出文檔就是后一階段的輸入文檔，因此，只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結(jié)果。2.推遲實(shí)現(xiàn)的觀點(diǎn)對于規(guī)模較大的軟件項(xiàng)目來說，往往編碼開始得越早最終完成開發(fā)工作所需要的時間反而越長。這是因?yàn)?，前面階段的工作沒做或做得不扎實(shí)，過早地考慮進(jìn)行程序?qū)崿F(xiàn)，往往導(dǎo)致大量返工，有時甚至發(fā)生無法彌補(bǔ)的問題，帶來災(zāi)難性后果。 13/38瀑布模型在編碼之前設(shè)置了系統(tǒng)分析與系統(tǒng)設(shè)計的各個階段，分析與設(shè)計階段的基本任務(wù)規(guī)定，在這兩個階段主要考慮目標(biāo)系統(tǒng)的邏輯模型，不涉及軟件的物理實(shí)現(xiàn)。清楚地區(qū)分邏輯設(shè)計與物理設(shè)計，盡可能推遲程序的物理實(shí)現(xiàn)，是按照瀑布模型開發(fā)軟件的一條重要的指導(dǎo)思想。3.質(zhì)量保證的觀點(diǎn)軟件工程的基本目標(biāo)是優(yōu)質(zhì)、高產(chǎn)。為了保證所開發(fā)的軟件的質(zhì)量，在瀑布模型的每個階段都應(yīng)堅持兩個重要做法： 14/38（1）每個階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務(wù)。完整、準(zhǔn)確的合格文檔不僅是軟件開發(fā)時期各類人員之間相互通信的媒介，也是運(yùn)行時期對軟件進(jìn)行維護(hù)的重要依據(jù)。（2）每個階段結(jié)束前都要對所完成的文檔進(jìn)行評審，以便盡早發(fā)現(xiàn)問題，改正錯誤。事實(shí)上，越是早期階段犯下的錯誤，暴露出來的時間就越晚，排除故障改正錯誤所需付出的代價也越高。因此，及時審查，是保證軟件質(zhì)量，降低軟件成本的重要措施。 15/38傳統(tǒng)的瀑布模型過于理想化了，事實(shí)上，人在工作過程中不可能不犯錯誤。在設(shè)計階段可能發(fā)現(xiàn)規(guī)格說明文檔中的錯誤，而設(shè)計上的缺陷或錯誤可能在實(shí)現(xiàn)過程中顯現(xiàn)出來，在綜合測試階段將發(fā)現(xiàn)需求分析、設(shè)計或編碼階段的許多錯誤。因此，實(shí)際的瀑布模型是帶“反饋環(huán)”的，如圖1.3所示（圖中實(shí)線箭頭表示開發(fā)過程，虛線箭頭表示維護(hù)過程）。當(dāng)在后面階段發(fā)現(xiàn)前面階段的錯誤時，需要沿圖中左側(cè)的反饋線返回前面的階段，修正前面階段的產(chǎn)品之后再回來繼續(xù)完成后面階段的任務(wù)。 16/38圖1.3實(shí)際的瀑布模型 17/38瀑布模型有許多優(yōu)點(diǎn)：可強(qiáng)迫開發(fā)人員采用規(guī)范的方法（例如，結(jié)構(gòu)化技術(shù)）；嚴(yán)格地規(guī)定了每個階段必須提交的文檔；要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證。各個階段產(chǎn)生的文檔是維護(hù)軟件產(chǎn)品時必不可少的，沒有文檔的軟件幾乎是不可能維護(hù)的。遵守瀑布模型的文檔約束，將使軟件維護(hù)變得比較容易一些。由于絕大部分軟件預(yù)算都花費(fèi)在軟件維護(hù)上，因此，使軟件變得比較容易維護(hù)就能顯著降低軟件預(yù)算?？梢哉f，瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動的模型。 18/38但是，“瀑布模型是由文檔驅(qū)動的”這個事實(shí)也是它的一個主要缺點(diǎn)。在可運(yùn)行的軟件產(chǎn)品交付給用戶之前，用戶只能通過文檔來了解產(chǎn)品是什么樣的。但是，僅僅通過寫在紙上的靜態(tài)的規(guī)格說明，很難全面正確地認(rèn)識動態(tài)的軟件產(chǎn)品。而且事實(shí)證明，一旦一個用戶開始使用一個軟件，在他的頭腦中關(guān)于該軟件應(yīng)該做什么的想法就會或多或少地發(fā)生變化，這就使得最初提出的需求變得不完全適用了。事實(shí)上，要求用戶不經(jīng)過實(shí)踐就提出完整準(zhǔn)確的需求，在許多情況下都是不切實(shí)際的?？傊捎谄俨寄Ｐ蛶缀跬耆蕾囉跁娴囊?guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。 19/381.4.2快速原型模型所謂快速原型是快速建立起來的可以在計算機(jī)上運(yùn)行的程序，它所能完成的功能往往是最終產(chǎn)品能完成的功能的一個子集。如圖1.4所示（圖中實(shí)線箭頭表示開發(fā)過程，虛線箭頭表示維護(hù)過程），快速原型模型的第一步是快速建立一個能反映用戶主要需求的原型系統(tǒng)，讓用戶在計算機(jī)上試用它，通過實(shí)踐來了解目標(biāo)系統(tǒng)的概貌。 20/38通常，用戶試用原型系統(tǒng)之后會提出許多修改意見，開發(fā)人員按照用戶的意見快速地修改原型系統(tǒng)，然后再次請用戶試用……一旦用戶認(rèn)為這個原型系統(tǒng)確實(shí)能做他們所需要的工作，開發(fā)人員便可據(jù)此書寫規(guī)格說明文檔，根據(jù)這份文檔開發(fā)出的軟件可以滿足用戶的真實(shí)需求。從圖1.4可以看出，快速原型模型是不帶反饋環(huán)的，這正是這種過程模型的主要優(yōu)點(diǎn)：軟件產(chǎn)品的開發(fā)基本上是線性順序進(jìn)行的。能做到基本上線性順序開發(fā)的主要原因如下： 21/38圖1.4快速原型模型 22/38（1）原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不會因?yàn)榘l(fā)現(xiàn)了規(guī)格說明文檔的錯誤而進(jìn)行較大的返工。（2）開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西（至少知道了“系統(tǒng)不應(yīng)該做什么，以及怎樣不去做不該做的事情”），因此，在設(shè)計和編碼階段發(fā)生錯誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯誤的可能性。軟件產(chǎn)品一旦交付給用戶使用之后，維護(hù)便開始了。根據(jù)所需完成的維護(hù)工作種類的不同，可能需要返回到需求分析、規(guī)格說明、設(shè)計或編碼等不同階段，如圖1.4中虛線箭頭所示。 23/38快速原型的本質(zhì)是“快速”。開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。因此，原型系統(tǒng)的內(nèi)部結(jié)構(gòu)并不重要，重要的是，必須迅速地構(gòu)建原型然后根據(jù)用戶意見迅速地修改原型。UNIXShell和超文本都是廣泛使用的快速原型語言，最近的趨勢是，廣泛地使用第四代語言（4GL）構(gòu)建快速原型。當(dāng)快速原型的某個部分是利用軟件工具由計算機(jī)自動生成的時候，可以把這部分用到最終的軟件產(chǎn)品中。 24/381.4.3增量模型增量模型也稱為漸增模型，如圖1.5所示。使用增量模型開發(fā)軟件時，把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計、編碼、集成和測試。每個構(gòu)件由多個相互作用的模塊構(gòu)成，并且能夠完成特定的功能。使用增量模型時，第一個增量構(gòu)件往往實(shí)現(xiàn)軟件的基本需求，提供最核心的功能。第二個增量構(gòu)件提供更完善的編輯和文檔生成功能；第三個增量構(gòu)件實(shí)現(xiàn)拼寫和語法檢查功能；第四個增量構(gòu)件完成高級的頁面排版功能。 25/38把軟件產(chǎn)品分解成增量構(gòu)件時，應(yīng)該使構(gòu)件的規(guī)模適中，規(guī)模過大或過小都不好。最佳分解方法因軟件產(chǎn)品特點(diǎn)和開發(fā)人員的習(xí)慣而異。分解時惟一必須遵守的約束條件是，當(dāng)把新構(gòu)件集成到現(xiàn)有軟件中時，所形成的產(chǎn)品必須是可測試的。采用瀑布模型或快速原型模型開發(fā)軟件時，目標(biāo)都是一次就把一個滿足所有需求的產(chǎn)品提交給用戶。增量模型則與之相反，它分批地逐步向用戶提交產(chǎn)品，整個軟件產(chǎn)品被分解成許多個增量構(gòu)件，開發(fā)人員一個構(gòu)件接一個構(gòu)件地向用戶提交產(chǎn)品。從第一個構(gòu)件交付之日起，用戶就能做一些有用的工作。顯然，能在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，是增量模型的一個優(yōu)點(diǎn)。 26/38圖1.5增量模型 27/38增量模型的另一個優(yōu)點(diǎn)是，逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。使用增量模型的困難是，在把每個新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設(shè)計得便于按這種方式進(jìn)行擴(kuò)充，向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便，也就是說，軟件體系結(jié)構(gòu)必須是開放的。但是，從長遠(yuǎn)觀點(diǎn)看，具有開放結(jié)構(gòu)的軟件擁有真正的優(yōu)勢，這樣的軟件的可維護(hù)性明顯好于封閉結(jié)構(gòu)的軟件。 28/38因此，盡管采用增量模型比采用瀑布模型和快速原型模型需要更精心的設(shè)計，但在設(shè)計階段多付出的勞動將在維護(hù)階段獲得回報。如果一個設(shè)計非常靈活而且足夠開放，足以支持增量模型，那么，這樣的設(shè)計將允許在不破壞產(chǎn)品的情況下進(jìn)行維護(hù)。事實(shí)上，使用增量模型時開發(fā)軟件和擴(kuò)充軟件功能（完善性維護(hù)）并沒有本質(zhì)區(qū)別，都是向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程。 29/38從某種意義上說，增量模型本身是自相矛盾的。它一方面要求開發(fā)人員把軟件看作一個整體，另一方面又要求開發(fā)人員把軟件看作構(gòu)件序列，每個構(gòu)件本質(zhì)上都獨(dú)立于另一個構(gòu)件。除非開發(fā)人員有足夠的技術(shù)能力協(xié)調(diào)好這一明顯的矛盾，否則用增量模型開發(fā)出的產(chǎn)品可能并不令人滿意。 30/38圖1.5所示的增量模型表明，必須在開始實(shí)現(xiàn)各個構(gòu)件之前就全部完成需求分析、規(guī)格說明和概要設(shè)計的工作。由于在開始構(gòu)建第一個構(gòu)件之前已經(jīng)有了總體設(shè)計，因此風(fēng)險較小。圖1.6描繪了一種風(fēng)險更大的增量模型：一旦確定了用戶需求之后，就著手?jǐn)M定第一個構(gòu)件的規(guī)格說明文檔，完成后規(guī)格說明組將轉(zhuǎn)向第二個構(gòu)件的規(guī)格說明，與此同時設(shè)計組開始設(shè)計第一個構(gòu)件……用這種方式開發(fā)軟件，不同的構(gòu)件將并行地構(gòu)建，因此有可能加快工程進(jìn)度。但是，使用這種方法將冒構(gòu)件無法集成到一起的風(fēng)險，除非密切地監(jiān)控整個開發(fā)過程，否則整個工程可能毀于一旦。 31/38圖1.6風(fēng)險更大的增量模型 32/381.4.4螺旋模型軟件風(fēng)險是任何軟件開發(fā)項(xiàng)目中都普遍存在的實(shí)際問題，項(xiàng)目越大，軟件越復(fù)雜，承擔(dān)該項(xiàng)目所冒的風(fēng)險也越大。軟件風(fēng)險可能在不同程度上損害軟件開發(fā)過程和軟件產(chǎn)品質(zhì)量。因此，在軟件開發(fā)過程中必須及時識別和分析風(fēng)險，并且采取適當(dāng)措施以消除或減少風(fēng)險的危害。 33/38構(gòu)建原型是一種能使某些類型的風(fēng)險降至最低的方法。正如1.4.2節(jié)所述，為了降低交付給用戶的產(chǎn)品不能滿足用戶需要的風(fēng)險，一種行之有效的方法是在需求分析階段快速地構(gòu)建一個原型。在后續(xù)的階段中也可以通過構(gòu)造適當(dāng)?shù)脑蛠斫档湍承┘夹g(shù)風(fēng)險。當(dāng)然，原型并不能“包治百病”，對于某些類型的風(fēng)險，原型方法是無能為力的。螺旋模型的基本思想是，使用原型及其他方法來盡量降低風(fēng)險。理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風(fēng)險分析過程的快速原型模型，如圖1.7所示。完整的螺旋模型如圖1.8所示。 34/38圖1.7簡化的螺旋模型 35/38圖1.8完整的螺旋模型 36/38螺旋模型有許多優(yōu)點(diǎn)：對可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標(biāo)；減少了過多測試（浪費(fèi)資金）或測試不足（產(chǎn)品故障多）所帶來的風(fēng)險；更重要的是，在螺旋模型中維護(hù)只是模型的另一個周期，在維護(hù)和開發(fā)之間并沒有本質(zhì)區(qū)別。螺旋模型主要適用于內(nèi)部開發(fā)的大規(guī)模軟件項(xiàng)目。如果進(jìn)行風(fēng)險分析的費(fèi)用接近整個項(xiàng)目的經(jīng)費(fèi)預(yù)算，則風(fēng)險分析是不可行的。事實(shí)上，項(xiàng)目越大，風(fēng)險也越大，因此，進(jìn)行風(fēng)險分析的必要性也越大。此外，只有內(nèi)部開發(fā)的項(xiàng)目，才能在風(fēng)險過大時方便地中止項(xiàng)目。 37/38螺旋模型的主要優(yōu)勢在于，它是風(fēng)險驅(qū)動的，但是，這也可能是它的一個弱點(diǎn)。除非軟件開發(fā)人員具有豐富的風(fēng)險評估經(jīng)驗(yàn)和這方面的專門知識，否則將出現(xiàn)真正的風(fēng)險：當(dāng)項(xiàng)目實(shí)際上正在走向?yàn)?zāi)難時，開發(fā)人員可能還認(rèn)為一切正常。