【正文】 解它的數(shù)據(jù)內(nèi)容。其轉(zhuǎn)換過程必定經(jīng)歷輸入、加工數(shù)據(jù)和產(chǎn)生結(jié)果數(shù)據(jù)等步驟。?用戶是否審查了初步的用戶手冊。?所有圖表是否清楚，在不補(bǔ)充說明時能否理解。同時，為了確切表達(dá)用戶對軟件的輸入輸出要求，還需要制定數(shù)據(jù)要求說明書及編寫初步的用戶手冊，著重反映被開發(fā)軟件的用戶界面和用戶使用的具體要求。最終綜合成系統(tǒng)的解決方案，給出目標(biāo)系統(tǒng)的詳細(xì)邏輯模型。問題識別的另一項(xiàng)工作是建立分析所需要的通信途徑，以保證能順利地對問題進(jìn)行分析。一旦需要時，就比較容易進(jìn)行補(bǔ)充和修改。應(yīng)當(dāng)把這方面的需求恰當(dāng)?shù)刈龀鲆?guī)定，以便對所開發(fā)的軟件給予特殊的設(shè)計，使其在運(yùn)行中其安全方面的性能得到必要的保證。?性能需求:給出所開發(fā)軟件的技術(shù)性能指標(biāo)，包括存儲容量限制、運(yùn)行時間限制、安全保密性等。需求分析階段的工作，可以分成以下4個方面:對問題的識別、分析與綜合、制定規(guī)格說明和評審。分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，明確目標(biāo)系統(tǒng)統(tǒng)到底要“做什么”，從當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型。（1）獲得當(dāng)前系統(tǒng)的物理模型。對于那些無法實(shí)現(xiàn)的要求應(yīng)向用戶做充分的解釋，以求得諒解。需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計的限制和軟件同其他系統(tǒng)元素的接口細(xì)節(jié)。它同時也給出了整個軟件生命周期的基本成本預(yù)算的進(jìn)度安排。軟件計劃由兩項(xiàng)任務(wù)組成:分析和估算。技術(shù)可行性的估計，需要有經(jīng)驗(yàn)的人員去完成。并不是所有問題都有簡單明顯的解決辦法，事實(shí)上，許多問題不能在預(yù)定的系統(tǒng)規(guī)模之內(nèi)解決。因此，問題定義的來源是用戶。有許多大、中型項(xiàng)目都采用了這種方法進(jìn)行開發(fā)并取得了顯著的成果。同時，軟件開發(fā)方法的有效應(yīng)用也必須得到相應(yīng)工具的支持，否則方法將難以有效的實(shí)施。有的適用于并發(fā)軟件系統(tǒng)，如PETRI網(wǎng)方法。但是70年代中期，軟件工作者認(rèn)識到編寫程序僅僅是軟件開發(fā)的一個環(huán)節(jié)，而合理地建立系統(tǒng)結(jié)構(gòu)比編定程序更為重要。（二） 軟件開發(fā)模型為了指導(dǎo)軟件的開發(fā)，用不同的方式將軟件生存周期中的所有開發(fā)活動組織起來，形成不同的軟件開發(fā)模型。引起修改軟件的原因主要有三種:一是在軟件運(yùn)行過程中發(fā)現(xiàn)了軟件中隱藏的錯誤而修改軟件。設(shè)計階段產(chǎn)生的文檔有設(shè)計規(guī)約（design specification），也稱為設(shè)計說明書，它也可分為概要設(shè)計說明書和詳細(xì)設(shè)計說明書。需求分析階段的參加人員有用戶、項(xiàng)目負(fù)責(zé)人系統(tǒng)分析員。（1）系統(tǒng)分析這里講的系統(tǒng)是指計算機(jī)系統(tǒng)，包括計算機(jī)硬件、軟件和使用計算機(jī)的人。此外，由于軟件開發(fā)時缺少好的方法指導(dǎo)和工具輔助，同時又缺少有關(guān)的文檔，使得大量已有的軟件難以維護(hù)。軟件工程自從1968年首次提出軟件工程一詞以來，軟件工程已成為計算機(jī)軟件的一個重要分支和研究方向。上述這些問題嚴(yán)重地阻礙了軟件的發(fā)展，20世紀(jì)60年代中期，人們把上述軟件開發(fā)和維護(hù)中的各種問題稱為“軟件危機(jī)”。系統(tǒng)分析的任務(wù)是確定待開發(fā)軟件的總體要求和適用范圍，以及與之有關(guān)的硬件、支撐軟件的要求。該階段產(chǎn)生的文檔有需求規(guī)約（requirements specification），習(xí)慣上稱它為需求規(guī)格說明書。根據(jù)需要還可產(chǎn)生數(shù)據(jù)說明書和模塊開發(fā)卷宗。二是為了適應(yīng)變化了的環(huán)境而修改軟件。常見的軟件開發(fā)模型有瀑布模型、演化模型、螺旋模型、噴泉模型等。所以研究的重點(diǎn)前移到設(shè)計階段，出現(xiàn)了設(shè)計階段的結(jié)構(gòu)化設(shè)計（SD）方法和JACKSON等方法，到了70年代后期，人們又發(fā)現(xiàn)事先對用戶的要求進(jìn)行分析更為重要，故又把重點(diǎn)前移到分析階段。作為90年代代表作的面向?qū)ο蠓椒ǎ鋺?yīng)用已幾乎遍布各個領(lǐng)域。工具的完善和發(fā)展將促進(jìn)軟件開發(fā)的進(jìn)步和完善。瀑布模型的的軟件生命周期可劃分七個階段:系統(tǒng)需求分析、軟件需求分析、概要分析、詳細(xì)設(shè)計、編碼、測試和運(yùn)行維護(hù)。通過問題定義階段的工作，系統(tǒng)分析員應(yīng)該提出關(guān)于問題性質(zhì)、工程目標(biāo)和規(guī)模的書面報告。如果問題沒有可行的解，那么花費(fèi)在這項(xiàng)開發(fā)工程上的任何時間、資源、人力和經(jīng)費(fèi)和都是無謂的浪費(fèi)。（3）操作可行性。分析是對系統(tǒng)內(nèi)各軟件功能的界限的劃定。（二） 軟件需求分析軟件需求分析工作是軟件生存期中重要的一步，也是決定性的一步。定義軟件的其他有效性需求。準(zhǔn)確地表達(dá)所接受的用戶要求，是需求分析的另一個重要方面。當(dāng)前系統(tǒng)可能是需要改進(jìn)的某個已在計算機(jī)運(yùn)行的數(shù)據(jù)處理系統(tǒng)，也可能是一個人工的數(shù)據(jù)處理過程。（4）為了對目標(biāo)系統(tǒng)做完整的描述，還需要對得到的邏輯模型做一些補(bǔ)充。（1）問題識別首先系統(tǒng)分析人員要研究計劃階段產(chǎn)生的可行性分析報告（如果有的話）和軟件項(xiàng)目實(shí)施計劃。?環(huán)境需求:這是對軟件系統(tǒng)運(yùn)行時所處環(huán)境的要求。?用戶界面需求:軟件與用戶界面的友好性是用戶能夠方便、有效、愉快地使用該軟件的關(guān)鍵之一。?功能性需求是人們普遍關(guān)注的，但常常忽視對非功能性需求的分析。分析員必須與用戶、軟件開發(fā)機(jī)構(gòu)的管理部門、軟件開發(fā)組的人員建立聯(lián)系。在這個步驟中，分析和綜合工作反復(fù)地進(jìn)行。此外，依據(jù)在需求分析階段對系統(tǒng)的進(jìn)一步分析，從目標(biāo)系統(tǒng)的精細(xì)模型出發(fā)，可以更確切地估計所開發(fā)項(xiàng)目的成本與進(jìn)度，從而修改、完善與確定軟件開發(fā)的實(shí)施計劃。?主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明。?軟件開發(fā)計劃中的估算是否受到了影響。對于計算機(jī)程序處理的數(shù)據(jù)，其數(shù)據(jù)域應(yīng)包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)即各種數(shù)據(jù)項(xiàng)的邏輯組織。但如果繼續(xù)分解，把某些子功能又分解為小的子功能，某個小的子功能又分解為更小的功能，這就屬于縱向分解了。需求分析方法由對軟件的數(shù)據(jù)域和功能域的系統(tǒng)分析過程及其表示方法組成。所有的方法都直接或間接地涉及到數(shù)據(jù)流、數(shù)據(jù)內(nèi)容或數(shù)據(jù)結(jié)構(gòu)域的屬性。例如，無論使用哪種分析方法，都能表示“計算職工每月工資”之類的功能，并在這個抽象層次上操縱這個功能?；蛘呖梢哉J(rèn)為，系統(tǒng)模型在分析員頭腦中形成，直接由分析員寫成規(guī)格說明。系統(tǒng)模型的建立是對現(xiàn)實(shí)世界中存在的有關(guān)實(shí)體和活動的抽象和精化，其建立過程包括觀察分析、模型表示和模型檢查3個階段。例如，結(jié)構(gòu)化分析與設(shè)計技術(shù)（Structured Analysis and Design Technique，SADT）、面向?qū)ο蠹夹g(shù)（ObjectOreinted Technique，OOT）、IDEF方法等。數(shù)據(jù)流圖從數(shù)據(jù)傳遞和加工的角度，以圖形的方式刻畫數(shù)據(jù)流從輸入到輸出的移動變換過程。文件在數(shù)據(jù)流圖中起保存數(shù)據(jù)的作用，因而稱為數(shù)據(jù)存儲（Data Store）。為表達(dá)稍為復(fù)雜的實(shí)際問題需要按照問題的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系。僅以DF/2為例，其中的4個加工的編號均可聯(lián)系到其上層圖中的子系統(tǒng)2。中間層流圖則表示對其上層父圖的細(xì)化。③在圖的邊上畫出系統(tǒng)的外部實(shí)體。⑤在數(shù)據(jù)流圖中，需按層給加工框編號。⑨初畫時可以忽略瑣碎的細(xì)節(jié)，以集中精力于主要數(shù)據(jù)流。①數(shù)據(jù)流詞條描述數(shù)據(jù)流是數(shù)據(jù)結(jié)構(gòu)在系統(tǒng)內(nèi)傳播的路徑。其描述需要以下信息:數(shù)據(jù)元素名類型:數(shù)字（離散值，連續(xù)值），文字S（編碼類型）。對于文字型，需給予編碼類型，文字值需加以定義。存儲方式:順序，直接，關(guān)鍵碼。輸入數(shù)據(jù)流。有關(guān)數(shù)據(jù)流。這種定義方法是自頂向下，逐級給出定義式，直到最后給出基本數(shù)據(jù)元素為止。在寫基本加工邏輯的說明時，應(yīng)滿足如下的要求。結(jié)構(gòu)化英語的詞匯表由英語命令動詞、數(shù)據(jù)詞典中定義的名字、有限的自定義詞和控制結(jié)構(gòu)關(guān)鍵詞IFTHENELSE、WHELEDO、REPEATUNTIL、CASEOF等組成。下面以“檢查發(fā)貨單”為例，說明判定表的構(gòu)成。顯然，判定表中列出了多少個條件取值的組合，也就有多少條規(guī)則，即條件項(xiàng)一動作項(xiàng)有多少列。（3）判定樹判定樹也是用來表達(dá)加工邏輯的一種工具。使用的手段，應(yīng)當(dāng)以結(jié)構(gòu)化英語為主，對存在判斷問題的加工邏輯，可輔之以判定表和判定樹。其中PSL是用來描述系統(tǒng)的形式語言，它可以對系統(tǒng)需求的一致性進(jìn)行檢查，并可根據(jù)開發(fā)者的需要，隨時生成需求文檔。有的設(shè)計方法不區(qū)分概要設(shè)計和詳細(xì)設(shè)計，統(tǒng)稱為軟件設(shè)計。過程抽象是指任何一個完成明確功能的操作都可被使用者當(dāng)作單個的實(shí)體看待，盡管這個操作實(shí)際上可能由一系列更低級的操作來完成。一個模塊有它的外部特征和內(nèi)部特征。模塊獨(dú)立是指每個模塊完成一個相對獨(dú)立的特定子功能，并且與其他模塊之間的聯(lián)系簡單。（1）耦合兩個模塊之間的耦合方式通常有如下7種，下面按它們的耦合度從低到高的次序依次作介紹。例如FORTRAN語言中的COMMON語句，C語言中的external數(shù)據(jù)類型，一個磁盤文件等都是全局?jǐn)?shù)據(jù)區(qū)。例如，產(chǎn)生與類型無關(guān)的全部輸出的模塊。（1）滿足信息隱蔽原則（2）盡量使得模塊的內(nèi)聚度高，模塊間的耦合度低。（6）設(shè)計單入口和單出口的模塊。物理產(chǎn)品在出廠前都要進(jìn)行嚴(yán)格的檢驗(yàn)，軟件產(chǎn)品也不例外。例如，一個需要3個16位字長的整型輸入數(shù)據(jù)的程序，輸入數(shù)據(jù)的所有組合情況大約有310 14 種，若每組數(shù)據(jù)的測試時間為1ms，那么即使一年365天，每天24小時地測試，也大約需要1萬年的時間。（2）程序員應(yīng)避免測試自己的程序，程序設(shè)計機(jī)構(gòu)不應(yīng)測試自己的程序。（5）檢查程序是否做了應(yīng)做的事是成功的一半，另一半是看程序是否做了不該做的事。它根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例，檢查程序中的邏輯通路是否都按預(yù)定的要求正確地工作。驅(qū)動模塊的功能是向被測試模塊提供測試數(shù)據(jù)，驅(qū)動（即調(diào)用）被測模塊，并從被測模塊中接受測試結(jié)果。漸增式集成又可分成自頂向下集成和自底向上集成。如果一個軟件是為某個客戶定制的，那么最后由客戶來實(shí)施驗(yàn)收測試（acceptance testing），以便客戶確認(rèn)該軟件是否他所需要的。（三） 白盒測試的測試用例設(shè)計白盒測試是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例，常用的技術(shù)是邏輯覆蓋，即考察用測試數(shù)據(jù)運(yùn)行被測程序時對程序邏輯的覆蓋程度。判定/條件覆蓋是指選擇足夠的測試用例。然而，條件組合覆蓋還不能保證程序中所有可能的路徑都被覆蓋。無效的輸入數(shù)據(jù)是指不符合規(guī)格說明要求的不合理或非法的輸入數(shù)據(jù)，它主要用來檢驗(yàn)程序是否做了規(guī)格說明以外的事。由于邊值分析方法所設(shè)計的測試用例，更有可能發(fā)現(xiàn)程序中的錯誤，因此經(jīng)常把邊值分析方法與其他設(shè)計測試用例方法結(jié)合起來使用。改正性維護(hù)就是在使用過程中發(fā)現(xiàn)了隱藏的錯誤后，為了診斷和改正這些隱藏錯誤而修改軟件的活動。（1）要維護(hù)一個軟件，首先要理解它。即使原先的開發(fā)人員還在，也可能因?yàn)橄喔魰r間太久而遺忘了實(shí)現(xiàn)的細(xì)節(jié)。（三） 可維護(hù)性軟件可維護(hù)性是指理解、改正、改動、改進(jìn)軟件的難易程度。如果修改程序時稍有考慮不周，就會出現(xiàn)上述顧此失彼的情況。維護(hù)活動的第一步是確定維護(hù)的類型，若是改正性維護(hù)，則要估計錯誤的嚴(yán)重程度，對嚴(yán)重的錯誤，則馬上分派人員執(zhí)行維護(hù)任務(wù)。就目前軟件開發(fā)中的問題，更多的是管理問題。接口又可分為硬件、軟件和人三類:（1）硬件指執(zhí)行該軟件的硬件，如中央處理機(jī)和外部設(shè)備，以及由該軟件控制的各種間接設(shè)備，如各種機(jī)器和顯示設(shè)備等。軟件工程各個階段對人員有不同的要求。②目標(biāo)機(jī)運(yùn)行所開發(fā)軟件的計算機(jī)叫目標(biāo)機(jī)，其中也包括有關(guān)的外部設(shè)備，在很多情況下，宿主機(jī)與目標(biāo)機(jī)是統(tǒng)一的。在編碼和單元測試階段，有動態(tài)調(diào)試程序、交叉匯編程序/編譯程序和宏處理程序。如果在與系統(tǒng)結(jié)合起來之前需要作某些修改，那就必須特別小心，因?yàn)樾薷默F(xiàn)有軟件所需費(fèi)用有時會大于開發(fā)同等軟件的費(fèi)用。若能夠及時地確定對軟件資源的要求，則可以較好地對各種方案進(jìn)行技術(shù)評價，并能盡早地獲得所需的方案。恰當(dāng)?shù)厥褂弥С周浖?，可以大大地提高軟件開發(fā)的生產(chǎn)率和軟件的質(zhì)量。（3）軟件和硬件一樣，也是一種軟件開發(fā)工具。高級技術(shù)人員同樣如此。（3）人指通過終端或輸入/輸出設(shè)備使用該軟件的操作人員。（一） 確定工作范圍和資源軟件計劃的第一個任務(wù)就是確定軟件的工作范圍，即軟件的用途及對軟件的要求。若是適應(yīng)性維護(hù)或完善性維護(hù)，則要根據(jù)其優(yōu)先級來決定維護(hù)的先后次序，優(yōu)先級高的維護(hù)則馬上開始。在軟件設(shè)計中我們介紹的那些設(shè)計準(zhǔn)則都是影響可修改性的因素，如信息隱蔽原則、模塊獨(dú)立、模塊間聯(lián)系的低耦合高內(nèi)聚等等?？蓽y試性是指測試和診斷軟件（主要指程序）中錯誤的難易程度。對那些缺乏模塊獨(dú)立性和非結(jié)構(gòu)化的程序來說，更是如此。（2）需要維護(hù)的軟件往往缺少合格的文檔，或者文檔資料不齊，甚至沒有文檔。適應(yīng)性維護(hù)就是為了適應(yīng)變化了的環(huán)境而修改軟件的活動。這種方法沒有機(jī)械的執(zhí)行步驟，主要依靠直覺和經(jīng)驗(yàn)。反之，如果一個輸入數(shù)據(jù)不能檢測出某個錯誤，那么等價類中其他輸入數(shù)據(jù)也不能發(fā)現(xiàn)這一錯誤（除非這個等價類的某個子集還屬于另一等價類）。路徑覆蓋實(shí)際上是考慮了程序中各種判定結(jié)果的所有可能組合，但它并未考慮判定中的條件結(jié)果的組合，因此它是一種比較強(qiáng)的覆蓋標(biāo)準(zhǔn)，但并不能代替條件覆蓋和條件組合覆蓋。顯然，滿足判定/條件覆蓋標(biāo)準(zhǔn)的測試用例一定也滿足判定覆蓋、條件覆蓋和語句覆蓋標(biāo)準(zhǔn)。為了提高測試的效率，應(yīng)選擇最少的測試用例來滿足指定的覆蓋標(biāo)準(zhǔn)。大多數(shù)軟件生產(chǎn)者使用一種Alpha測試和Beta測試的過程，來揭露僅由最終用戶才能發(fā)現(xiàn)的錯誤。由于測試下層模塊時它的上層模塊已測試過，所以可以用其上層模塊作為它的驅(qū)動模塊，而不必另編驅(qū)動模塊。在模塊結(jié)構(gòu)圖中，頂層模塊測試時不需要驅(qū)動模塊，最底層的模塊測試時不需要樁模塊。它根據(jù)規(guī)格說明書規(guī)定的功能來設(shè)計測試用例，檢查程序的功能是否符合規(guī)格說明的要求。因?yàn)樵诟恼e誤或程序維護(hù)后還要進(jìn)行重新測試。此外，開發(fā)程序是一項(xiàng)建設(shè)性的工作，而測試則是一項(xiàng)破壞性的工作（證明程序有錯），這對開發(fā)人員或機(jī)構(gòu)來說在心理上是難以容忍的。在測試時將實(shí)際的輸出結(jié)果與預(yù)期結(jié)果比較，若不同則表示發(fā)現(xiàn)了錯誤，因此測試用例是由測試數(shù)據(jù)和預(yù)期結(jié)果構(gòu)成的。軟件測試代表了需求分析、設(shè)計、編碼的最終復(fù)審。模塊的作用域是指受該模塊內(nèi)一個判定影響的所在模塊的集合。（4）模塊的調(diào)用深度不宜過大。例如初始化模塊。?一個模塊不通過正常入口轉(zhuǎn)到另一模塊的內(nèi)部。② 數(shù)據(jù)耦合:數(shù)據(jù)耦合是指兩個模塊借助于參數(shù)表傳遞簡單數(shù)據(jù)。耦合是指模塊之間聯(lián)系的緊密程度。調(diào)用一個模塊只需知道它的外部特征，而不必了解其內(nèi)部特征。例如函數(shù)、子程序。抽象是指忽視一個主題中與當(dāng)前目標(biāo)無關(guān)的那些方面，以便更充分地注意與當(dāng)前目標(biāo)有關(guān)的方面。半手工方式是利用正文編輯程序及其他實(shí)用程序輔助手工方式來生成文