《軟件系統(tǒng)開發(fā)技術(shù)》課件第1章_第1頁
《軟件系統(tǒng)開發(fā)技術(shù)》課件第1章_第2頁
《軟件系統(tǒng)開發(fā)技術(shù)》課件第1章_第3頁
《軟件系統(tǒng)開發(fā)技術(shù)》課件第1章_第4頁
《軟件系統(tǒng)開發(fā)技術(shù)》課件第1章_第5頁
已閱讀5頁,還剩64頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1.1軟件工程學(xué)的背景和目的1.2軟件和軟件生命期模型1.3軟件質(zhì)量的評價1.4軟件開發(fā)方法和軟件自動工具習題一計算機專業(yè)的學(xué)生在修完編程(Programming)等課程之后,對編寫小型程序,例如字符編輯程序或報表打印程序等,一定是很有把握了。但是,如果需要研制一個大型的軟件系統(tǒng),例如飛機訂票系統(tǒng)或?qū)W校管理系統(tǒng)(包括教務(wù)、財務(wù)、人事、物資等各系科的全面管理),相信會遇到許多困難,因此還必須學(xué)習“軟件工程學(xué)”。

“軟件工程”(SoftwareEngineering)是從“編程”演變過來的,后者一般考慮小型程序的編寫,前者則考慮大型軟件系統(tǒng)的研制?!败浖こ虒W(xué)”出現(xiàn)至今只有二十余年,是一門新的學(xué)科。本節(jié)先討論軟件工程學(xué)產(chǎn)生的背景及這門學(xué)科的目的。1.1軟件工程學(xué)的背景和目的

60年代以來,在一些技術(shù)領(lǐng)先的國家中,計算機的應(yīng)用領(lǐng)域越來越廣,它幾乎涉及到社會生活的各個方面,如工廠管理、銀行事務(wù)、病人監(jiān)護、學(xué)校檔案、圖書館流通、旅館預(yù)訂……,這些系統(tǒng)的軟件規(guī)模都相當大,邏輯很復(fù)雜,而且功能上需要不斷更改和擴充。

至于軍事方面的導(dǎo)彈防御系統(tǒng)、宇航方面的飛行控制系統(tǒng),其軟件就更為龐大和復(fù)雜了。

由于軟件是非實物性、不可見的,開發(fā)軟件本質(zhì)上又是一個“思考”的過程,很難進行管理,開發(fā)人員可以按各自的愛好和習慣進行工作,沒有統(tǒng)一的標準可以遵循,只能以手工藝的方式進行。管理人員事前很難估計項目所需的經(jīng)費和時間,技術(shù)人員在項目完成之前也難以預(yù)料系統(tǒng)是否能成功。人們在開發(fā)上述大型軟件系統(tǒng)時遇到了許多困難,有的系統(tǒng)最終徹底失敗了;有的系統(tǒng)雖然完成了,但比原定計劃遲了好幾年,而且經(jīng)費上大大超過了預(yù)算;有的系統(tǒng)未能完滿地符合用戶當初的期望;有的系統(tǒng)則無法進行修改維護。更糟的是,失敗的系統(tǒng)往往無可挽回,除非再從頭做起,但由于時間和經(jīng)費的限制,這又是不可能的。

IBM公司的OS/360系統(tǒng)和美國空軍某后勤系統(tǒng)在開發(fā)過程中遭受的挫折是眾所周知的。以O(shè)S/360為例:它由4000個模塊組成,共約100萬條指令,人工為5000人年(一個人工作一年其工作量相當于一個人年),經(jīng)費達數(shù)億美元,但結(jié)果卻是令人沮喪的,人們在程序中發(fā)現(xiàn)的錯誤達2000個以上。OS/360系統(tǒng)的負責人Brooks曾生動地描述了開發(fā)過程中的困難和混亂:……像巨獸在泥潭中作垂死掙扎,掙扎得越猛,泥漿就沾得越多,最后沒有一個野獸能逃脫淹沒在泥潭中的命運……程序設(shè)計就像是這樣一個泥潭……一批批程序員在泥潭中掙扎……沒人料到問題竟會這樣棘手……”

。

人們發(fā)現(xiàn),研制軟件系統(tǒng)需要投入大量的人力和物力,但系統(tǒng)的質(zhì)量卻難以保證,也就是說,開發(fā)軟件所需的高成本同產(chǎn)品的低質(zhì)量之間有著尖銳的矛盾,這種現(xiàn)象就是所謂

的“軟件危機”(Softwarecrisis)。與此同時,由于新的電子元器件的出現(xiàn),計算機硬件的功能和質(zhì)量在不斷地提高,而價格卻在大幅度地下降,因此同硬件投資相比,軟件投資比例上升極快,圖11是Boeh-m在l976年對美國計算機總投資的統(tǒng)計和預(yù)測,從圖中可以看出,在50年代,軟件投資約占20%,至70年代已超過60%,當時預(yù)測到1985年軟件投資將高達85%。

硬件價格的大幅度下降意味著計算機可以廣泛使用,因此對軟件的需求量將會迅速上升,但是軟件危機的事實告

訴人們:軟件技術(shù)沒有跟上硬件技術(shù)的高速發(fā)展,人們意識到計算機要推廣使用,其關(guān)鍵在于軟件開發(fā)技術(shù)的革新。圖1.1

Parnas認真分析了開發(fā)大型軟件和編制小型程序之間的差別,他發(fā)現(xiàn),從所需人力來看,小型程序從確定要求、編制、使用、直至修改往往是由同一個人完成的,因此只要他本人心里明白程序的構(gòu)思就夠了,而大型系統(tǒng)則必須由許多人(包括用戶、項目負責人、分析員、高初級程序員、資料員、操作員等)組成一支開發(fā)隊伍來協(xié)同完成,所以人與人之間必須準確地進行協(xié)商討論;另外,從產(chǎn)品使用情況來看,小型程序往往是“一次性”的,意即如果需要作較大的修改,人們通常寧可丟棄舊的程序而重新編寫,但大型系統(tǒng)的開發(fā)耗費了大量的人力與物力,所以人們一般不會輕易將其拋棄,而總是在舊程序的基礎(chǔ)上一改再改,希望延長它的使用期,因而是“多個版本”的。所以,Parnas將大型軟件開發(fā)的特點總結(jié)為:由“多個人”來開發(fā)具有“多個版本”的程序。

大型軟件系統(tǒng)的開發(fā)提出了許多新的問題,諸如:如何將一個系統(tǒng)分解成若干個部分,以便各人分工開發(fā);如何精確地說明每個部分的規(guī)格要求;怎樣才能使軟件產(chǎn)品易于修改維護;……。

顯然,傳統(tǒng)的“編程”沒有考慮這些問題。

量變帶來了質(zhì)變,系統(tǒng)規(guī)模的增大使問題的性質(zhì)發(fā)生了變化,人們認識到:正像不能用造獨木船的手工藝方式來研制航空母艦一樣,沿用50年代個人編寫小型程序的那種手工藝方式來開發(fā)大型軟件系統(tǒng)也是不行的,必須尋找新的技術(shù)來指導(dǎo)軟件的大規(guī)模生產(chǎn)??紤]到機械、建筑等領(lǐng)域都經(jīng)歷過從手工藝方式演變成嚴密完整的工程科學(xué)的過程,一些有識之士認為大型軟件系統(tǒng)的開發(fā)也應(yīng)該向“工程化”方向發(fā)展,逐步發(fā)展成一門嚴格的工程科學(xué)。

1968年在北大西洋公約組織的學(xué)術(shù)會議上有人第一次提出了“軟件工程”這個詞,還提出了一些軟件工程化的技術(shù)并進行了討論。

60年代末至70年代初,“軟件工程學(xué)”還處于學(xué)術(shù)研究階段,但已對軟件開發(fā)的實踐產(chǎn)生了巨大的影響。l971年IBM公司運用一些軟件工程技術(shù)成功地研制了紐約時報情報庫系統(tǒng)和空間實驗室的飛行模擬系統(tǒng)。這也是兩個著名的例子,盡管兩個系統(tǒng)都很龐大,用戶要求又有很多變化,并又減少了人力和削減了經(jīng)費,但由于適當?shù)夭捎昧斯こ袒募?/p>

術(shù),還是按時、高質(zhì)量地完成了,軟件生產(chǎn)率比以前提高了一倍。

這些事實說明用“工程化”的思想作指導(dǎo),可以大大減少軟件開發(fā)成本并提高軟件質(zhì)量,“工程化”為人們開辟了新的道路,“軟件工程學(xué)”這門富有潛力的學(xué)科就此蓬勃地發(fā)展起來了。

在我國,計算機領(lǐng)域近年來迅猛發(fā)展,前面討論的種種問題和矛盾也就在國內(nèi)暴露出來了。國內(nèi)的軟件工作者也意識到要進一步發(fā)展我國的計算機事業(yè),軟件工程學(xué)是個關(guān)

鍵。目前國內(nèi)、國外都有許多人在從事這一領(lǐng)域的研究,軟件工程學(xué)已成為計算機學(xué)科中的一個重要分支。作為一門學(xué)科,軟件工程學(xué)研究的是:如何應(yīng)用一些科學(xué)理論和工程上的技術(shù)來指導(dǎo)大型①軟件系統(tǒng)的開發(fā),使其發(fā)展成一門嚴格的工程科學(xué);軟件工程學(xué)的最終目的是以較

低的成本研制具有較高質(zhì)量的軟件。所以,研究軟件工程學(xué)無疑將促進計算機推廣應(yīng)用的步伐,直接或間接地產(chǎn)生巨大的社會效益和經(jīng)濟效益。表1.1

軟件工程學(xué)包括的面很廣,有基礎(chǔ)理論研究,也有應(yīng)用研究以及實際開發(fā);除了技術(shù)問題之外,它還涉及與開發(fā)軟件有關(guān)的所有活動,例如管理學(xué)、心理學(xué)、經(jīng)濟學(xué)法律、道德等方面。本書只討論軟件工程中的技術(shù)問題,重點是軟件產(chǎn)業(yè)界近年來較流行的實用技術(shù)。

計算機領(lǐng)域從50年代到90年代有了突飛猛進的發(fā)展,人們對許多問題的看法也發(fā)生了根本的變化。所以,在學(xué)習具體的軟件開發(fā)技術(shù)之前,我們有必要對軟件的一些基本概念,如什么是軟件、軟件開發(fā)過程包括哪些活動、如何評價軟件產(chǎn)品的質(zhì)量等,重新進行討論。讀者將會看到目前的看法同傳統(tǒng)的觀點已有了相當大的差別。

軟件和軟件生命期模型是軟件工程學(xué)中兩個重要的概念。過去,人們一般認為所謂“軟件”就是指“程序”,所謂“開發(fā)軟件”也僅僅就是“編程序”而已。但是,對于大型軟件系統(tǒng)而言,這樣的理解是不合適的。1.2軟件和軟件生命期模型眾所周知,凡是工業(yè)產(chǎn)品都有其生命周期,即要經(jīng)過分析要求、設(shè)計、制造、測試、運行(此時需要不斷地維護)等幾個階段。軟件也是一種產(chǎn)品,同樣存在生命周期。那什么是軟件生命期呢?一個軟件從被提出開始研制至軟件最終被廢棄不再使用為止的全過程,稱為軟件生命期。

軟件生命期的劃分應(yīng)該適應(yīng)軟件生產(chǎn)工程化的需要,而不是千篇一律的。圖1.2是一種典型的軟件生命期模型(softwareLifecycleModel)示意圖,由于其形狀似多級瀑布,常稱為“瀑布模型”。這種模型把軟件生命期劃分為可行性研究與計劃、需求分析、設(shè)計、編程、測試、運行與維護等六個階段,每個階段都有明確的任務(wù),并需產(chǎn)生一定規(guī)格的文檔資料交付給下一階段,下一階段在上階段交付的文檔的基礎(chǔ)上繼續(xù)開展工作。

圖1.2在圖1.2生命期模型中,第一個階段有時又稱為計劃期,中間四個階段總稱為開發(fā)期,

最后一個階段稱為運行期。表1.2概括地列出了每個階段的基本任務(wù)、工作結(jié)果(即提交的文檔)以及參加人員。

1.可行性研究與計劃階段

當準備接受一個軟件開發(fā)任務(wù)時,首先要確定是否值得去開發(fā),如果不值得去開發(fā),那么花費在這項開發(fā)工程上的任何時間、資源、人力和經(jīng)費都是無謂的浪費。可行性研究

與計劃階段的基本任務(wù)是搞清問題的性質(zhì),確定系統(tǒng)的目標和規(guī)模,從技術(shù)、經(jīng)濟和社會因素等方面分析論證本軟件項目的可行性,并最終產(chǎn)生一份可行性分析報告??尚行匝芯?/p>

的結(jié)果是使用部門負責人做出是否繼續(xù)進行這項工程的決定的重要依據(jù)。

2.需求分析和規(guī)格說明階段(簡稱需求分析階段)

在設(shè)計軟件系統(tǒng)之前,首先必須確定用戶究竟要求軟件系統(tǒng)做什么,所以分析階段的基本任務(wù)是理解用戶的需求,并將用戶的需求用書面形式表達出來。這一階段產(chǎn)生的文檔

是需求規(guī)格說明書(簡稱需求說明書),它明確地描述了用戶的要求。需求說明書是以后備階段工作的基礎(chǔ)。用戶和軟件人員雙方都應(yīng)有代表參加這一階段的工作,需求說明書就是

雙方充分討論交流后達成的協(xié)議。

3.設(shè)計階段

在設(shè)計階段,要在需求說明書的基礎(chǔ)上建立軟件系統(tǒng)的“結(jié)構(gòu)",包括數(shù)據(jù)結(jié)構(gòu)和模塊結(jié)構(gòu)。設(shè)計階段一般又可分為兩步:概要設(shè)計(或稱為總體設(shè)計)和詳細設(shè)計,前者主要考慮模塊的分解,后者考慮每個模塊內(nèi)部的細節(jié)。本階段產(chǎn)生的文檔包括模塊說明書、數(shù)據(jù)庫或文件結(jié)構(gòu)說明等。由于軟件產(chǎn)品的質(zhì)量在很大程度上取決于設(shè)計方案的質(zhì)量,所以設(shè)計工作要由經(jīng)驗較豐富的高級軟件人員來完成。

4.編程階段

在編程階段,按模塊說明書的要求為每個模塊編寫程序。相對地說,這個階段是最簡單的,初級程序員可以參加編程階段的工作。

5.測試階段

由于前面三個階段都可能產(chǎn)生各種各樣的錯誤,所以測試階段的任務(wù)就是發(fā)現(xiàn)并排除這些錯誤。靜態(tài)檢驗工作實際上在上述每個階段的最后就必須進行,而測試階段則進行最后的動態(tài)檢驗。測試通常又可分為模塊測試、集成測試和系統(tǒng)測試等幾步。測試應(yīng)該由另一個獨立的部門(如不參加系統(tǒng)的設(shè)計或編程的人員)來完成。經(jīng)過測試就得到了軟件系統(tǒng)

的第一個版本。

zelkowity對一些軟件項目中各階段的工作量進行了統(tǒng)計,圖1.3是他給出的結(jié)果。

圖1.3(a)說明在整個生命期中,開發(fā)期和運行期所占的工作量,可以看出維護工作量要占一半以上。圖1.3(b)說明在開發(fā)期中各階段所占的工作量,可以看出,測試工作量約占其中的一半。

圖1.3告訴我們,編程工作在整個生命期中只占很小的比例,所以“開發(fā)軟件僅僅是編程”的想法顯然是錯誤的。

圖1.3圖1.2的瀑布模型將軟件生命期組織成六個階段,這是比較有代表性的模式。也有人提出其他一些模式,表1.3列出了Freeman、Metzger、Boehm等人的模式,可以看出,各種模式基本上是類似的。由于軟件規(guī)模大、邏輯復(fù)雜,且生命期又長,而人的記憶力是有限的,所以有關(guān)軟件系統(tǒng)的所有資料,必須以書面文檔的形式記錄下來,這樣開發(fā)人員就能以文檔為基礎(chǔ)協(xié)同工作,各階段之間也可通過文檔實現(xiàn)過渡。顯然,文檔健全與否直接影響著最終產(chǎn)品的質(zhì)量。

為了強調(diào)軟件產(chǎn)品除程序之外還必須包括各種文檔資料,Boehm為軟件給出了新的定義:“軟件是程序以及開發(fā)、使用和維護程序所需的所有文檔”,因此,需求說明書、模塊說明書、數(shù)據(jù)庫和文件說明、程序、測試計劃、測試用例、使用手冊、維護手冊……各階段交付文檔的全體就是“軟件”。由此可見,作為一名稱職的軟件開發(fā)人員,光會編程是不夠的,他還必須掌握分析、設(shè)計、測試等方法和工具,學(xué)會編寫上述各種文檔。培養(yǎng)學(xué)生掌握這些技術(shù)就是本書的目的。

與傳統(tǒng)的手工藝開發(fā)方式相比,上述生命期模型有兩個明顯的長處,第一,由于強調(diào)要將每個階段的工作結(jié)果用書面形式描述出來,這就使原來“不可見”的軟件變成了“可見”的文檔資料;第二,開發(fā)過程分階段按步驟進行,以交付某種特定規(guī)格的文檔作為標志某個階段完成的里程碑,這就使原來“難以管理的思考過程”變?yōu)椤翱梢怨芾淼纳a(chǎn)過程”了。顯然,這兩點長處為提高軟件生產(chǎn)率和改進軟件質(zhì)量創(chuàng)造了極為有利的條件。

必須指出的是,實際軟件系統(tǒng)的開發(fā)不可能是理想化地按瀑布模型進行,由于人們理解問題總有一個反復(fù)的過程,所以從后階段回復(fù)到前階段是不可避免的。例如在設(shè)計階段發(fā)現(xiàn)需求說明書有不完整或不正確之處,就必須進行“再分析”,測試階段發(fā)現(xiàn)模塊界面有錯誤,就必須進行“再設(shè)計”,在運行階段為了擴充系統(tǒng)的功能又要進行“再分析”、“再設(shè)計”、“再編程”等。另外,階段之間也沒有明確的界線,如分析階段需要考慮系統(tǒng)的可行性,就一定會涉及一些設(shè)計方面的問題;又由于采用了模塊化的技術(shù),某些模塊的編程有可能與另一些模塊的測試并行進行。軟件工程學(xué)的最終目標是獲得高質(zhì)量的軟件,所以如何評價軟件質(zhì)量是一個重要的問題。以前,對小型程序,人們一般比較強調(diào)程序的正確性和效率,近年來隨著軟件規(guī)模的

增大和復(fù)雜性的上升,對問題的看法已發(fā)生了變化。目前,軟件質(zhì)量的定義還是非常模糊的,人們對此尚未形成一致的看法,但一般說來傾向于從可維護性、可靠性、可理解性和

效率等方面對軟件作較全面的評價,下面分別討論之。1.3軟件質(zhì)量的評價

1.可維護性(Maintainability)

軟件在運行階段尚需不斷“修正”,因為軟件雖經(jīng)測試但不可避免地總還隱含著各種錯誤,這些錯誤在運行階段會逐步暴露出來,因而就要進行排錯。例如1BM公司的0s/360系統(tǒng),據(jù)說每個版本中約有成千個錯誤;又如某軍事系統(tǒng)在運行初期,平均每月發(fā)現(xiàn)900個錯誤,糾正一個錯誤平均需修改l7條指令。軟件在運行階段尚需不斷“完善”,因為系統(tǒng)經(jīng)過一個時期的使用后,用戶必然會逐步提出一些更改或擴充要求,軟件就需要相應(yīng)地不斷作修改。

軟件在運行階段往往還需作“適應(yīng)性”修改,因為近年來計算機業(yè)發(fā)展迅速,一般在3至5年內(nèi),硬件或系統(tǒng)軟件就會出現(xiàn)更新?lián)Q代的新產(chǎn)品,于是應(yīng)用軟件系統(tǒng)也就需要作相應(yīng)的調(diào)整或移植。

在運行期中,對軟件所作的上述修正性、完善性和適應(yīng)性修改,總稱為“維護”,它涉及再分析、再設(shè)計、再編程、再測試等活動??紤]到大型軟件系統(tǒng)的運行期可達10年以上,所以維護的工作量是極大的。另外,維護工作也是相當困難的,由于軟件邏輯上的復(fù)雜性,修改往往會帶來新的錯誤。據(jù)統(tǒng)計,軟件錯誤中有19%是由于修改造成的;有人還統(tǒng)計出,如果一個修改涉及5

至l0個語句,修改成功的可能性是50%,如果一個修改涉及40至50個語句,則修改成功的可能性下降至20%,因此軟件維護是很困難,很冒風險的。圖1.4說明了在計算機軟硬件的總投資中,軟件維護所占的比例??梢钥闯?,維護費用近年正在迅速上升,按這樣的趨勢發(fā)展下去,現(xiàn)有的人力物力將全部被束縛在維護原有

系統(tǒng)上,就可能再也沒有力量去開發(fā)新的系統(tǒng)了。因此軟件維護引起了人們的普遍關(guān)注,人們已意漢到,一個軟件系統(tǒng)即使其他方面都相當理想,但是如果不容易維護,它將不會有什么實際使用價值,所以,“可維護性”應(yīng)該作為評價軟件質(zhì)量的重要準則。圖1.4

“可維護性”通常包括了“可讀性”(Read—ability)、“可修改性”(Modifiability)、“可測試性”(Testability)等含義。為了使軟件具有較好的可維護性,早在開發(fā)期的各個階段就應(yīng)采取一系列技術(shù)措施。這樣做雖然開發(fā)期的工作量也許會大些,但考慮到維護工作在整個生命期中所占的比例,總的看來還是值得的。反之,如果開發(fā)時目光短淺,不考慮長遠利益,就可能在維護時遭受重大挫折,到時就無法挽救了。

本書第七章還要進一步討論軟件維護問題。

2.可靠性(Reliability)

可靠性通常包括正確性(Correctness)和健壯性(Robustness)這兩個相互補充的方面。

正確性是指軟件系統(tǒng)本身沒有錯誤,所以在預(yù)期的環(huán)境條件下能夠正確地完成期望的功能。毋庸置疑,正確性對系統(tǒng)正常發(fā)揮作用是完全必要的。

對于一個小型程序,我們可以希望它是完全正確的,但對長達幾萬行甚至幾十萬行的大型軟件,我們一般不能奢望它是“完全”正確的,而且這一點也是無法證實的。此外,一個大型系統(tǒng)運行時,完全可能遇到一些意外,例如:某部分硬件出現(xiàn)故障,軟件中某個隱含的錯誤暴露出來,或者操作員無意地輸入了一個離奇古怪的數(shù)字或符號。有的系統(tǒng)雖然是正確的,但是它非?!按嗳酢?,一旦發(fā)生上述異常情況,就可能遭到意想不到的破壞。

1972年6月的《計算機世界》刊有一則報導(dǎo):“操作員手指的一滑使稅收損失30萬美元”,據(jù)載,1972年6月美國woonsocket市在用計算機計算稅率時,由于操作員的右手小拇指無意滑到鍵P上,使汽車價格950美元誤為7000950美元,從而導(dǎo)致了巨大的財政損失。這就產(chǎn)生了一個新的概念——“健壯性”,其含義是指:當系統(tǒng)萬一遇到意外時(具體是什么意外,事先是很難預(yù)料的)能按某種預(yù)定的方式作出適當?shù)奶幚恚缒芰⒓匆庾R到異常情況的出現(xiàn),保護起重要的信息,隔離故障區(qū)防止事故蔓延,并能及時通知管理人員請求人工干預(yù),事后從故障狀態(tài)恢復(fù)到正常狀態(tài)亦比較容易,所以健壯的系統(tǒng)應(yīng)該能避免

出現(xiàn)災(zāi)難性的后果。正確性與健壯性是相互補充的,前面計算稅收的系統(tǒng)可能是正確的,但它不是健壯的;而健壯的程序并不一定是絕對正確的,例如一個計算工資的程序,它可能錯誤地計算

了某種罕見的病假折扣值,但它對輸入數(shù)據(jù)以及系統(tǒng)內(nèi)部的數(shù)據(jù)狀態(tài)都進行仔細的查核,因而在絕大多數(shù)情況下能夠可靠地工作。

總的說來,可靠的軟件系統(tǒng)在正常情況下能夠正確地工作,而且在意外情況下,亦能適當?shù)刈鞒鎏幚?,因而不會造成嚴重的損失。當代計算機使用的范圍很廣,有些軟件系統(tǒng)的故障可能造成生命財產(chǎn)的巨大損失,如核反應(yīng)堆泄漏,飛船失事爆炸等,所以,“可靠性"無疑是絕對重要的。人們寧可在開發(fā)時多花些代價,提高系統(tǒng)的可靠性,與發(fā)生事故后造成的損失相比,這些代價還是值得的。

3.可理解性(Understandability)

在相當長一段時間中,人們一直認為程序只是提供給計算機的,而不是給人閱讀的,所以只要它邏輯正確,計算機能按其邏輯正確執(zhí)行就足夠了,至于它是否易于被人理解則是無關(guān)緊要的。

但是隨著軟件規(guī)模的增大,人們逐步看到,在整個軟件生命期中,為進行測試、排錯或修改,開發(fā)人員經(jīng)常需要閱讀本人或他人編寫的程序和各種文檔。如果軟件易于理解,

無疑將提高開發(fā)和維護的工作效率,而且出現(xiàn)錯誤的可能性也會大大下降。所以,可理解性應(yīng)該是評價軟件質(zhì)量的一個重要方面??衫斫庑酝ǔJ侵负唵涡院颓逦裕瑢τ谕挥脩粢?,解決的方案可以有多個,其中最簡單、最清晰的方案往往被認為是最好的方案。

4.效率(Efficiency)

效率是指系統(tǒng)能否有效地使用計算機資源,如時間和空間等。這一點以前一直是非常強調(diào)的,這是過去硬件價格昂貴造成的結(jié)果。由于以下一些原因,目前人們對效率的看法

已有了變化:

首先,硬件價格近年來大幅度下降,所以效率已不像以前那樣舉足輕重了。第二,人們已認識到,程序員的工作效率比程序的效率遠為重要,程序員工作效率的提高不僅能減少開支,而且出錯率也會降低。從匯編語言發(fā)展到高級語言以至超高級語言

就是一個很好的說明。

第三,追求效率同追求可維護性、可靠性等往往是相互抵觸的,例如片面地強調(diào)節(jié)省時間和空間,設(shè)計出來的系統(tǒng)可能結(jié)構(gòu)復(fù)雜,難以理解和修改;又如高度可靠的程序中一

般需要含有冗余,如為一種帳目保存幾個副本等,這就要以一定的時間和空間作代價。所以,效率雖然是衡量軟件質(zhì)量的一個重要方面,但在硬件價格下降、人工費用上升的情況下,人們有時也寧可犧牲效率來換取其他方面的得益。

除了這里討論的可維護性、可靠性、可理解性和效率之外,軟件系統(tǒng)的許多其他性質(zhì)也反映了軟件的質(zhì)量。圖1.5是Boehm提出的軟件質(zhì)量圖,下面只解釋圖中最右邊各因素

的含義,不再作詳細討論。圖1.5

1)設(shè)備獨立性(DeViceindepenl=!ence):不依賴于特定的硬件設(shè)備而能工作的程度。

2)自包含性(self—eontaine(】ness):不依賴于其他程序僅靠自身能實現(xiàn)功能的程度。

3)精確性(AccLtracy):能產(chǎn)生具有必要精確度之正確輸出的程度。

4)完整性(Cornpleteness):所有部分是否齊全。每個部分是否充分。

5)健壯性/合理性(RobLlstness/Integrjty):即使前提條件不符合規(guī)格也能繼續(xù)合理運行的程度。

6)一致性(Cotlsistency):程序和文檔中所用的記號、術(shù)語和表示方式的一致的程度。

7)計測性(ACCOuntabillity):能夠在多大程度上觀察、統(tǒng)計程序的工作狀況。

8)設(shè)備效率(Device—efficiency):使有關(guān)設(shè)備的功能發(fā)揮到什么程度。

9)可訪問性(Accessibility):能夠在多大程度上選擇和使用程序的功能和設(shè)備。

10)通訊性(Communicativeness):輸入輸出的形式,內(nèi)容是否統(tǒng)一,使用是否方便。

11)自我描述性(Self—descriptiyeness):程序中以一目了然的形式記述它的目的、條件和輸入輸出。

12)結(jié)構(gòu)性(StructureneSS):是否結(jié)構(gòu)化,修改是否只涉及局部。

13)簡潔性(Conciseness):以緊湊的方式表達必要的信息,并且沒有多余的東西。

14)明了性(Legibility):程序是否便于閱讀,注解是否充分、妥當。

15)可擴充性(Augmentability):擴充是否方便。綜上所述,一個大型軟件系統(tǒng)的質(zhì)量應(yīng)該從可維護性、可靠性、可理解性、效率等多個方面全面地進行評價。這些目標是既有聯(lián)系又有矛盾的,例如可理解性是可維護性的必要前提,可維護性、可靠性同效率往往有抵觸,效率中時間和空間兩個因素又常常是沖突的……。對于不同的軟件系統(tǒng),各個目標的重要程度是不同的,每個目標要求達到什么程度又受經(jīng)費、時間等因素的限制,例如游戲程序同空中交通控制系統(tǒng)的質(zhì)量要求顯然是不同的。所以在開發(fā)具體軟件系統(tǒng)的過程中,開發(fā)人員應(yīng)該充分考慮各種不同的方案,在各種矛盾的目標之間作權(quán)衡,并在一定的限制條件下(經(jīng)費、時間、可用的軟硬件資源等)使可維護性、可靠性、可理解性和效率等性質(zhì)最大限度地得到滿足。必須強調(diào)的是:為了保證軟件質(zhì)量,在軟件開發(fā)過程的各個階段,尤其是早在分析階段和設(shè)計階段,就應(yīng)該采取多種有效的技術(shù)和一系列質(zhì)量保證措施,精益求精、一絲不茍,絕對不能急于求成,也不能存有僥幸心理,開發(fā)過程中任一環(huán)節(jié)的疏忽,到后期都可能造成無法彌補的缺陷,甚至是終生遺憾。所以,“先苦后甜"、“先憂后樂"可以作為軟件工作者的座右銘。軟件工程學(xué)的最終目標是以較少的投資獲得質(zhì)量較高的軟件產(chǎn)品,也就是說要“高產(chǎn)優(yōu)質(zhì)”。同其他工程學(xué)科一樣,達到這個最終目標的兩個主要途徑是“紀律化”和“自動化”。

研究軟件方法的目的是使開發(fā)過程“紀律化”,就是尋找一些規(guī)范的“求解過程”,使開發(fā)工作能夠有計劃、有步驟地進行。研究軟件工具的目的是使開發(fā)過程“自動”,就是使開發(fā)過程中的某些工作用計算機來完成或用計算機來輔助。方法和工具之間有著密切的聯(lián)系。1.4軟件開發(fā)方法和軟件自動工具下面分別討論軟件開發(fā)方法和軟件自動工具這兩個概念。

1.軟件開發(fā)方法(softwareDevelopmentMethods)

幾十年以來,程序設(shè)計一直是一種個體的、手工藝方式的勞動,對于一個提出的問題,程序員可以任意地“發(fā)明”出一個解答,而沒有任何規(guī)章制度需要遵循。但是當軟件進入大規(guī)模生產(chǎn)時期,軟件就不再是個人的成果而是集體的勞動成果了,所以軟件產(chǎn)業(yè)面臨的第一個問題就是“紀律化”。一項軟件產(chǎn)品的誕生涉及到許多人,包括用戶和軟件人員兩方面。每一方又有許多人,每人對問題的理解可能不同,每人對問題的處理方式也可能不同;軟件產(chǎn)品的開發(fā)周

期又較長,即使是同一個人,在不同的時期,對問題的理解和處理還有可能不一樣;而且隨著計算技術(shù)的發(fā)展,處理問題的選擇余地又更大了。軟件開發(fā)過程中,缺乏強有力的內(nèi)

部紀律,各個可以任意地自行其事,這是造成軟件危機的主要原因。為了使軟件研制走上工程化的軌道,我們必須尋找一些標準的規(guī)程,以便為開發(fā)人員給出指導(dǎo)和約束,使他們遵照一定的方式來理解和處理問題,這是使開發(fā)獲得成功的關(guān)鍵。

軟件方法就是指導(dǎo)研制軟件的某種標準規(guī)程,它告訴人們:“什么時候做什么以及怎么做"。由于軟件研制過程畢竟是相當復(fù)雜的,它涉及的因素很多,所以各種軟件方法又有不同程度的靈活性、試探性。軟件方法不可能像自動售貨機的使用規(guī)程那樣用簡單的幾句話敘述清楚,也不應(yīng)該像機器的操作規(guī)程那樣機械地使用。一般說來,一個軟件方法往往規(guī)定了:明確的工作步驟、具體的描述方式以及確定的評價標準,下面分別說明這三個方面。

1)明確的工作步驟:研制一個軟件系統(tǒng)要考慮并解決許多問題,如果同時處理這些問題,我們將會束手無策,或者造成混亂。正確的方式是將這些問題分成先后次序,每一步

集中精力解決一個問題。像為加工機械產(chǎn)品規(guī)定一道道工序那樣,軟件方法也提出了處理問題的基本步驟,這包括每一步的目的是什么,每一步應(yīng)產(chǎn)生什么工作結(jié)果,每一步需具

備的條件以及要注意的問題等。

2)具體的描述方式:工程化生產(chǎn)必須強調(diào)文檔化,即每人必須將每一步的工作結(jié)果以一定的書面形式記錄下來,以保證開發(fā)人員之間有效地進行交流,也有利于維護工作的順

利進行。軟件方法規(guī)定了描述軟件產(chǎn)品的格式,這包括每一步應(yīng)產(chǎn)生什么文檔,文檔中記錄哪些內(nèi)容,采用哪些圖形、符號等。

3)確定的評價標準:對于同一個問題,其解決方案往往不是唯一的,選取哪一個方案較好呢?有些軟件方法提出了比較確定的評價標準,因而可以指導(dǎo)人們對各個具體方案進

行評價,并從中選取一個較好的方案。在軟件方法的指導(dǎo)和約束之下,面對錯綜復(fù)雜的問題,開發(fā)人員就可按統(tǒng)一的步驟、統(tǒng)一的描述方式,紀律化地開展工作。毫無疑問,這是“高產(chǎn)優(yōu)質(zhì)”的有力保證。

近年來,人們陸續(xù)研究總結(jié)出多種軟件方法。70年代初,出現(xiàn)了編寫程序的一些方法,主要是“結(jié)構(gòu)化程序設(shè)計”;70年代中期人們認識到編程僅僅是軟件開發(fā)的一個環(huán)節(jié),合理地建立軟件結(jié)構(gòu)比編寫程序更為重要,所以研究重點前移到設(shè)計階段,出現(xiàn)了用于設(shè)計階段的“結(jié)構(gòu)化設(shè)計”。和Jackson方法等;70年代后期,人們又意識到在設(shè)計階段之前必須先對用戶的要求進行分析,所以研究重點又前移到分析階段,出現(xiàn)了用于分析階段的“結(jié)構(gòu)化分析”、sADT、sREM等方法。80年代,又出現(xiàn)了面向?qū)ο蟮能浖_發(fā)方法。目前,用什么方法來分析和說明用戶的要求,用什么方法對軟件進行測試和維護,仍是軟件工作者感興趣的問題。各種軟件方法的適用范圍是各不相同的,有的方法適用于實時控制系統(tǒng),如sREM;有的方法適用于數(shù)據(jù)處理系統(tǒng),如結(jié)構(gòu)化分析和Jackson方法。各種軟件方法的風格也是很不相同的,有的方法僅僅是一組指導(dǎo)性的原則,如Parnas的方法;有的方法則有較具體的處理規(guī)則,如Jackson方法;有的方法建立在嚴密的數(shù)學(xué)基礎(chǔ)之上;有的方法則是實際經(jīng)驗的總結(jié)?,F(xiàn)有的軟件方法相當多,在一本書中不可能全面地介紹,本書將以70年代以來在國外軟件界相當流行的“結(jié)構(gòu)化方法”(包括結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計、結(jié)構(gòu)化程序設(shè)計等)為主,配合一些其他方法作較系統(tǒng)的介紹。

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論