軟件工程考點

1、軟件是程序和所使程序正確運行所需的相關(guān)文檔和配置信息。軟件有可能是針對某一特定用戶開發(fā)的，也有可能是面向一般市場開發(fā)的。軟件系統(tǒng)包括：獨立程序、配置文件（設(shè)置程序）、系統(tǒng)文檔（描述系統(tǒng)結(jié)構(gòu)）、用戶文檔（如何使用系統(tǒng)）、Web站點（告知用戶下載最新產(chǎn)品信息）【分類】通用軟件產(chǎn)品：為一系列不同用戶開發(fā)的，在市場上公開銷售的如PC軟件Excel或者Word。 定制軟件產(chǎn)品（客戶軟件產(chǎn)品）：受特定的客戶委托，由軟件承包商專門為這類客戶開發(fā)。 新軟件可以通過開發(fā)新的項目程序、配置通用軟件系統(tǒng)或重用現(xiàn)有的軟件來創(chuàng)建。軟件工程是一門工程學科，涉及軟件生產(chǎn)的各個方面。軟件工程師既能恰當?shù)貞?yīng)用理論、方法和工具，

2、又能有選擇地利用它們，即使在沒有可用的 理論和方法的情況下，也力求找出解決問題的方法。計算機科學研究的是構(gòu)成計算機和軟件系統(tǒng)基礎(chǔ)的有關(guān)理論和方法，而軟件工程則是研究軟 件制作中的實際問題。計算機科學仍不能作為軟件工程的堅實的基礎(chǔ)。系統(tǒng)工程研究由軟件起主導(dǎo)作用、有關(guān)復(fù)雜系統(tǒng)的開發(fā)和進化的各個方面，包括軟硬件開發(fā)， 過程設(shè)計等。軟件工程是系統(tǒng)工程中的關(guān)于開發(fā)軟件基礎(chǔ)設(shè)施，控制，應(yīng)用和系統(tǒng)數(shù)據(jù)庫 的部分。系統(tǒng)工程師參與了系統(tǒng)描述，體系設(shè)計，集成和部署。軟件過程是指制作軟件產(chǎn)品的一組活動及其結(jié)果。軟件過程的基本活動有：軟件描述-客戶和工程師定義所要生產(chǎn)的軟件以及對其操作的一些約束軟件開發(fā)-軟件得以設(shè)計

3、和編程實現(xiàn)軟件有效性驗證-軟件經(jīng)過檢查以保證它就是客戶所需要的軟件進化-軟件隨不同的客戶和變化的市場需求而修改。軟件過程模型：是從一特定角度提出的軟件過程的簡化描述。幾種軟件過程模型：工作流模型（描述軟件過程中各種活動的序列及其輸入輸出和相互依賴型）數(shù)據(jù)流或活動模型（把軟件過程描述成一組活動，每個活動都完成一定的數(shù)據(jù)轉(zhuǎn)換）、 角色/動作模型（誰描述了參與軟件過程的人員的不同角色和各自負責的活動）軟件開發(fā)模型：瀑布模型（包含軟件過程各個活動并將其描述成獨立的過程階段）進化式開發(fā)（軟件描述、開發(fā)和有效性驗證活動交替進行的開發(fā)方法）基于組件的軟件工程（假定系統(tǒng)的各個組件已經(jīng)存在，并把組件集成到新 系

4、統(tǒng)中，而非從頭開始）瀑布模型過程：需求分析和定義；系統(tǒng)和軟件設(shè)計；實現(xiàn)和單元測試；集成和系統(tǒng)測試；運行和維護瀑布模型主要缺點是難以適應(yīng)過程中進行的變化。上一個階段完成，下一個階段才能啟動。適用性：將項目分成不同階段，使人們難以應(yīng)付不斷變化的客戶需求；因此，當需 求十分明確，且在軟件開發(fā)中只做有限修改時才適合使用該模型；然而很少有業(yè)務(wù)系統(tǒng)有穩(wěn) 定的需求；所以瀑布模型主要是用于大型系統(tǒng)工程項目，且軟件項目是大型工程項目的一部 分時尤為適用。進化式開發(fā)包括：探索式開發(fā)：其目標是與客戶一起工作，共同探索系統(tǒng)需求，直到最后交付系統(tǒng)，這類 開發(fā)是從需求較清楚的一部分開始，根據(jù)用戶的建議逐漸向系統(tǒng)中添加功能

5、。拋棄式原型：目標是理解用戶需求，然后再給出系統(tǒng)的一個較好的需求定義。存在問題：過程不可見；系統(tǒng)結(jié)構(gòu)通常較差；需要專業(yè)技能（如快速原型語言等）。適用性：小型或中型的交互系統(tǒng)；大型系統(tǒng)的某部分（如用戶接口）；生命周期短的系統(tǒng)基于組件的軟件工程基于可復(fù)用的系統(tǒng)，這些系統(tǒng)是現(xiàn)成的組件或者是商業(yè)現(xiàn)成產(chǎn)品系統(tǒng)COTS過程：組件分析（給出需求描述，然后搜尋能滿足需求的組件）需求修改（根據(jù)得到的組件信息來分析需求，然后修改需求以反映可得到的組件）使用復(fù)用的系統(tǒng)設(shè)計（開發(fā)設(shè)計系統(tǒng)框架或重復(fù)使用一個已存在的框架）開發(fā)和集成（組件不能買到時需自己開發(fā)，再集成自己開發(fā)的或現(xiàn)成的組件形成整體） 基于組件的軟工特點：減

6、少了需要開發(fā)的軟件數(shù)量，降低了風險和成本，使軟件可以快速交 付。然而需求妥協(xié)不可避免，可能導(dǎo)致系統(tǒng)不符合用戶真正需求；對系統(tǒng)進化的控制也不起 作用。隨著組件標準的出臺，這種方法得到越來越廣泛的使用。需求被視為對系統(tǒng)應(yīng)提供的服務(wù)或?qū)ο到y(tǒng)的約束的一個高層抽象描述，被定義為對系統(tǒng)功能 的詳細的、用數(shù)學方法的形式化描述。需求可以作為一個合同競標的基礎(chǔ)，也可以作為合同自身的基礎(chǔ)，這兩種文件描述都被稱為 需求文檔。需求類型：用戶需求：是用自然語言加圖表的形式，給出的關(guān)于系統(tǒng)需要提供哪些服務(wù)以及 系統(tǒng)操作受到哪些約束的聲明。系統(tǒng)需求：詳細精確地給出系統(tǒng)的服務(wù)和約束。系統(tǒng)需求文檔也稱為功能描述。 軟件系統(tǒng)分為

7、功能需求、非功能需求和領(lǐng)域需求。功能需求對系統(tǒng)應(yīng)提供的服務(wù)、如何對輸入做出反應(yīng)及系統(tǒng)在特定條件下的行為的描述。 非功能需求對系統(tǒng)提供的服務(wù)或功能給出的約束。時間約束、開發(fā)過程的約束、標準等。 領(lǐng)域需求來自系統(tǒng)的應(yīng)用領(lǐng)域的需求，反應(yīng)該領(lǐng)域的特點?！竟δ苄枨蟆棵枋鱿到y(tǒng)所預(yù)期提供的功能或服務(wù)，取決于開發(fā)的軟件類型、軟件未來的用戶 以及開發(fā)的系統(tǒng)類型。軟件需求分析的三個層次是：業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它們在項目視圖與范 圍文檔中予以說明。用戶需求文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)。功能需求定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足 了業(yè)務(wù)

8、需求。圖書館系統(tǒng)圖書借閱管理子系統(tǒng)中，業(yè)務(wù)需求：完成校園圖書的借閱，為大學的學生和 教職員工提供圖書借閱的服務(wù)。用戶需求有三類用戶：讀者（本科學生、碩士生、老師）：查詢圖書信息、進行借閱。圖書管理員：讀者信息的管理、圖書信息的管理、借閱活動的操作。 系統(tǒng)管理員：圖書管理員信息的管理、數(shù)據(jù)庫的維護、日志維護和系統(tǒng)安全維護。 系統(tǒng)功能需求具有全面（用戶所需的所有服務(wù)都應(yīng)該給出描述）、一致性（在對系統(tǒng)功能需 求進行描述時，不能前后矛盾）。【非功能需求】定義了系統(tǒng)的屬性和約束，指那些不直接與系統(tǒng)具體功能相關(guān)的一類需求。 與系統(tǒng)總體特性相關(guān)（如可靠性、反應(yīng)時間和存儲空間），定義了系統(tǒng)的約束（如I/O設(shè)備

9、 的能力、系統(tǒng)界面中數(shù)據(jù)的表示）。非功能需求不只與軟件系統(tǒng)本身有關(guān)，還與系統(tǒng)開發(fā)過 程有關(guān)。非功能需求分類：產(chǎn)品需求（敘述產(chǎn)品行為的需求，包括系統(tǒng)運行速度和內(nèi)存消耗等性能需求）機構(gòu)需求（過程標準、實現(xiàn)要求、交付需求）外部需求（所有系統(tǒng)外部因素和開發(fā)過程）領(lǐng)域需求一般包括專用性很強的領(lǐng)域術(shù)語或是涉及領(lǐng)域概念。是一個新的特有的功能需求、 對已存在功能需求的約束或是需要實現(xiàn)的一個特別計算。領(lǐng)域需求問題：不易理解性、含蓄性【用戶需求】是從用戶角度來描述系統(tǒng)功能和非功能需求，以便讓用戶能看懂。用自然語言、 圖表和直觀的圖形來定義，以便讓用戶理解?！鞠到y(tǒng)需求】比用戶需求相比，系統(tǒng)需求是對系統(tǒng)功能、服務(wù)和約

10、束更詳細的描述。它們被 用來作為系統(tǒng)設(shè)計的技術(shù)，可以作為有關(guān)系統(tǒng)實現(xiàn)合同的一部分。幾種需求表達形式的比較：用自然語言描述（二義性、隨意性太大、缺乏模塊化）結(jié)構(gòu)化語言描述（所有的需求都要以一種標準的方式進行書寫，對使用的詞匯進行了限制） 標準格式的描述（實體或功能、輸入及來源、輸出及輸出趨向、其他被引用的實體等的描述） 表格描述（用來補充自然語言，在有多個可能情形時尤其有用）計算的表格描述圖形模型（當需知狀態(tài)是如何改變或需要描述一個動作序列時，圖形模型是最為有用的工具） 序列圖（顯示了在與一個系統(tǒng)進行用戶交互的過程中，事件所發(fā)生的順序。自上而下地讀一 個序列圖，可以從中看出動作所發(fā)生的順序）AT

11、M機中提取現(xiàn)金的序列：驗卡；處理請求；完成交易。體系結(jié)構(gòu)設(shè)計的產(chǎn)品是一個體系結(jié)構(gòu)設(shè)計文檔內(nèi)容包括：靜態(tài)結(jié)構(gòu)模型：給出子系統(tǒng)或組件，將其作為一個個獨立的單元來開發(fā)動態(tài)過程模型：給出系統(tǒng)在運行時的過程組成。它可能不同于靜態(tài)模型接口模型：定義每個子系統(tǒng)從它們的公共接口能得到的服務(wù)關(guān)系模型：給出如子系統(tǒng)間的數(shù)據(jù)流這樣的模型分布模型：給出子系統(tǒng)在多臺計算機上是如何分布的體系結(jié)構(gòu)設(shè)計的步驟：1.系統(tǒng)概述A AA2.設(shè)計約束AAA3.設(shè)計策略AAA4.系統(tǒng)總體結(jié) WAA5,子系統(tǒng)N的結(jié)構(gòu)與功能AA6,開發(fā)環(huán)境的配置AAA7,運行環(huán)境的配置AA8,測試 環(huán)境的配置AA9,其他系統(tǒng)組成反映的是系統(tǒng)組織所采用的基

12、本策略。時間上分為概要和詳細。系統(tǒng)組成類型三個：共享數(shù)據(jù)容器類型（全部共享數(shù)據(jù)放在一個中央數(shù)據(jù)庫中，所有子系統(tǒng)都能從中存取數(shù)據(jù)， 每個子系統(tǒng)與其他子系統(tǒng)間數(shù)據(jù)交互通過消息傳遞來實現(xiàn)）優(yōu)點：它是共享大量數(shù)據(jù)的一個高效方法;子系統(tǒng)不必關(guān)心數(shù)據(jù)是如何集中進行的這些活動， 如、例如備份、信息安全性等；共享模型能通過容器模式而看得見。缺點：子系統(tǒng)一定要與容器數(shù)據(jù)模型一致，不可避免地，每個專用的工具之間要做出妥協(xié)； 數(shù)據(jù)進化變得很困難和昂貴；容器模型迫使所有的子系統(tǒng)使用相同的策略；很難將容器有效 的分配到多臺機器上。共享服務(wù)和服務(wù)器類型（一組給其他子系統(tǒng)提供服務(wù)的單擊服務(wù)器；一組向服務(wù)器請求服 務(wù)的客戶機

13、；一個連接客戶機和服務(wù)器的網(wǎng)絡(luò)）優(yōu)點：數(shù)據(jù)的分布式最直接的；可以更有效地使用網(wǎng)絡(luò)系統(tǒng)，從而降低了對硬件的要求；很 容易就添加一臺新的服務(wù)器或更新現(xiàn)有的服務(wù)器。缺點：沒有共享數(shù)據(jù)模型，子系統(tǒng)以不同的方式組織它們的數(shù)據(jù)。數(shù)據(jù)交換效率就可能很低; 每個服務(wù)器上出現(xiàn)冗余數(shù)據(jù)管理；沒有中央寄存器的名字和服務(wù)，這可能很難找出哪個服務(wù) 器和哪些服務(wù)可用。抽象機或分層類型（把系統(tǒng)組織成一系列層次，每一層提供一組服務(wù)，）分層的方法支持系統(tǒng)的增量式開發(fā)。當一層的接口改變的時候，只有毗鄰的層受影響。然而，用這種方法構(gòu)成系統(tǒng)可能是困難的。快速軟件開發(fā)特性：1.描述、設(shè)計和實現(xiàn)過程是并發(fā)的。沒有詳細的系統(tǒng)描述，設(shè)計文檔

14、得到了最少化。系統(tǒng)通過一系列增量開發(fā)出來。最終用戶和其他系統(tǒng)信息持有者都參與了每個增量 的定義和評估。系統(tǒng)用戶界面通常是采用交互開發(fā)系統(tǒng)開發(fā)的增量式開發(fā)的優(yōu)點：客戶服務(wù)的加速移交：系統(tǒng)的每個增量可以移交高優(yōu)先級的功能給用戶。客戶的參與：系統(tǒng)用戶必須參與到增量開發(fā)過程中來，他們的參與不僅僅意味著系統(tǒng)更容 易達到他們的需求，它是也意味著系統(tǒng)的最終用戶對系統(tǒng)承擔了義務(wù)。增量式開發(fā)的缺點：管理問題：很難評價系統(tǒng)的進程，很難發(fā)現(xiàn)問題，因為增量式開發(fā)無法有效地產(chǎn)生大量的 系統(tǒng)文檔。合同問題：一般的合同可能包括一個系統(tǒng)描述；沒有系統(tǒng)描述，人們就不得不用不同形式 的合同。有效性證明問題：沒有一個描述，系統(tǒng)正在

15、被證明的是什么呢？維護問題：連續(xù)的變更將使得任何軟件系統(tǒng)的結(jié)構(gòu)變壞，導(dǎo)致軟件改變的代價更高，從而 也演變成新的需求。增量式開發(fā)的目標是向最終用戶移交一個可用的系統(tǒng)。原型構(gòu)造開始于用戶需求，這些需求 被理解得最好。拋棄式原型構(gòu)造的目標是驗證或者導(dǎo)出系統(tǒng)需求。原型構(gòu)造開始于那些不好理解的需求。敏捷方法特點：關(guān)注代碼而不是設(shè)計；以軟件開發(fā)的迭代方法為基礎(chǔ)；迅速完成和移交可用軟件給用戶，客 戶提出新的變化了的需求，有軟件開發(fā)人員在下一個循環(huán)中實現(xiàn)。敏捷方法很可能最適合于開發(fā)小型或中等規(guī)模的業(yè)務(wù)系統(tǒng)和個人計算機產(chǎn)品。敏捷（極限）方法的問題：很難將興趣保持在參與到開發(fā)的客戶身上。團隊成員個人可能從性格上不

16、太適應(yīng)激烈的投入，這是敏捷方法的典型特征。對變更做出優(yōu)先級排序可能是極困難的，尤其是對那些有很多參與者的系統(tǒng)。維護簡潔性需要額外的工作。隨著其他迭代方法的發(fā)展，合同可能也是極限方法的一個問題。極限編程可能是最為人所熟知也是流行最廣的一種敏捷方法。極限編程采用“極限”方法到迭代開發(fā)中。新的軟件版本每天之中構(gòu)造好幾次；移交給用戶的增量大約是每兩周一次；所有測試必須執(zhí)行于每次構(gòu)造中，且只當所有測試成功執(zhí)行后軟件的新版本才是可接受的。XP （極限編程）和敏捷方法的原則：增量式開發(fā)是通過系統(tǒng)的小的頻繁開發(fā)的版本來支持的；客戶的參與是通過全時雇傭到開發(fā)團隊的方式；人（而不是過程）是通過結(jié)對編程、集體對系統(tǒng)

17、代碼的所有權(quán)、可以忍受的開發(fā)過程而無需 超額的工作小時來運作的；變更是通過經(jīng)常性的系統(tǒng)版本來支持的；通過持續(xù)的再分解來維護系統(tǒng)的簡潔性。極限編程的經(jīng)驗：增量式規(guī)劃：需求記錄在腳本卡片上，將包含在版本中的腳本取決于可用時間和它們的 相對優(yōu)先級，開發(fā)者將這些腳本分解為開發(fā)額“任務(wù)”。小版本：首先開發(fā)能提供業(yè)務(wù)價值的一個最小有用集合。不斷地增量式的往第一個版本 中添加功能形成新的版本系統(tǒng)。簡單設(shè)計：只進行有限的能滿足當前需求的設(shè)計，不追求太多。測試優(yōu)先的開發(fā)：在功能本身實現(xiàn)之前，采用一個自動單元測試框架來書寫此新功能的 測試重構(gòu)：只要發(fā)現(xiàn)有可能改善的代碼存在，便更期待所以的開發(fā)人員都能連續(xù)的對代碼重

18、 構(gòu)。這樣才能保持代碼簡單和可維護性。結(jié)對編程：開發(fā)人員成對工作，檢查彼此的工作并提供支持圓滿完成任務(wù)。集體所有：配對開發(fā)人員參與系統(tǒng)的所有方面的工作，所以不會存在技術(shù)孤島，所有的 開發(fā)者都享有代碼。任何人都可以修改任何地方。連續(xù)集成：大量超時是不能接受的，因為它的后果通常就是降低代碼的質(zhì)量和中期的生 產(chǎn)率在場客戶：系統(tǒng)最終用戶的代表應(yīng)該是全程滿時配合XP團隊。在極限編程過程中，客 戶是開發(fā)團隊的一分子，有責任將系統(tǒng)需求帶給開發(fā)團隊。測試優(yōu)先的開發(fā)：在代碼闡明所要實現(xiàn)的需求之前，先書寫這些代碼的測試。測試應(yīng)該被寫為程序而不是數(shù)據(jù)，這樣，它們就可以自動地執(zhí)行。測試包括一個已經(jīng)正 確執(zhí)行的檢查。在

19、有新的功能添加進系統(tǒng)時，所有以前的和新的測試都要自動地運行，因此，由新功能 所引入的問題能夠馬上檢查出來?！緳z驗和有效性驗證的區(qū)別與聯(lián)系】檢驗：“我們是否在正確地構(gòu)造一個產(chǎn)品”。軟件應(yīng)該符合設(shè)計規(guī)格。有效性驗證：”我們是否在構(gòu)造一個正確的產(chǎn)品”。軟件應(yīng)該滿足用戶所需要的。兩者對所開發(fā)的程序進行檢查，以確保程序符合描述并能移交為此軟件付費的客戶所需的 功能。兩個主要目標：發(fā)現(xiàn)系統(tǒng)中的缺陷；評估在操作情況下系統(tǒng)可用性與有用性缺陷測試和調(diào)試是兩個不同的過程檢驗和有效性驗證關(guān)心的是確定程序中存在缺陷。調(diào)試關(guān)心的是錯誤出現(xiàn)的地方和如何改正這些錯誤。調(diào)試包括對程序行為提出假設(shè)，并通過驗證這些假設(shè)來發(fā)現(xiàn)系統(tǒng)

20、的錯誤。最終目的:要確立軟件系統(tǒng)達到設(shè)計目標的信心.這并不意味著完全沒有缺陷.相反，它必 須足夠用于其預(yù)定用途和根據(jù)所使用類型確定所需要的信任程度.測試過程：組件測試：單個程序組件的測試;通常是組件的開發(fā)商的責任（除了某些關(guān)鍵系統(tǒng)外）;測 試是源于開發(fā)人員的經(jīng)驗.系統(tǒng)測試：由一組組件組合而成的系統(tǒng)或子系統(tǒng)的測試;一個獨立的測試團隊的責任;測 試是基于系統(tǒng)描述的系統(tǒng)測試的內(nèi)容：包括組件集成后的系統(tǒng)或子系統(tǒng)?？赡苌婕皽y試一個增量交付給客戶。系統(tǒng)測試兩個階段:集成測試-測試小組可以深入到系統(tǒng)的源代碼。發(fā)布測試-發(fā)布給用戶的系統(tǒng)進行測試，如黑盒測試。組件測試：組件或單元測試是測試系統(tǒng)中單個組件的過程，

21、這是個缺陷測試過程。組件可能是哪些：對象內(nèi)的單個函數(shù)或者方法；有多個屬性和方法的對象類；由多個不同對 象或函數(shù)組成的復(fù)合組件。對象類測試：覆蓋對象的所有特征；對對象相關(guān)的所有操作進行獨立測試；設(shè)置并審查 與對象相關(guān)的所有屬性；在所有可能額狀態(tài)下使用對象。繼承讓對象類測試更加困難，原因是要測試的數(shù)據(jù)沒有被定位。接口測試：目標是為了檢測由于接口的錯誤或無效的接口假設(shè)所造成的故障。這在面向?qū)ο箝_發(fā)中尤為重要，原因是對象由接口定義。接口類型：參數(shù)接口：數(shù)據(jù)從一個過程傳到另外一個過程。共享內(nèi)存接口：內(nèi)存塊為過程或函數(shù)所共享。程序接口：子系統(tǒng)封裝一組程序，這些程序為其他子系統(tǒng)調(diào)用。消息傳遞接口：子系統(tǒng)通過

22、傳遞消息請求其他子系統(tǒng)上的服務(wù)接口錯誤：接口誤用：調(diào)用者組件在調(diào)用其他組件時因接口使用不當而發(fā)生接口錯誤，如參數(shù)的傳遞順 序不當?shù)取＝涌谡`解：調(diào)用者組件誤解了被調(diào)用組件的接口描述而產(chǎn)生錯誤，對唄調(diào)用組件進行了錯誤 的假設(shè)。計時錯誤：調(diào)用和被調(diào)用組件以不同的速度運行，中間過時的數(shù)據(jù)無法得到正確的處理。接口測試準則：檢查要測試的代碼并明確地列出對外部組件的每個調(diào)用。當有指針從接口傳遞時，總用空指針參數(shù)來測試接口。當通過程序接口調(diào)用組件時，設(shè)計一些容易引起組件失敗的測試。在消息傳遞系統(tǒng)中進行強度測試。當組件間通過共享內(nèi)存來交互時，可以設(shè)計一種測試，使其對激活組件的次序有所改變。缺陷測試所設(shè)計的測試用

23、于發(fā)現(xiàn)系統(tǒng)中的缺陷一個成功的測試能揭示系統(tǒng)缺陷的出現(xiàn)有效性測試目的是為了證明軟件滿足了設(shè)計要求一個好的測試是能證明每一個功能都被很好地實施的測試。測試用例設(shè)計設(shè)計測試用例（輸入和預(yù)計的輸出）來測試系統(tǒng)。測試用例設(shè)計的目標是建立一組用例集合，它們能有效發(fā)現(xiàn)程序缺陷并能證明系統(tǒng)能滿足它 的需求。設(shè)計方法：基于需求的測試；劃分測試；結(jié)構(gòu)化測試。基于需求的測試：需求工程的一個總的原則是需求應(yīng)該是可測試的?；谛枨蟮臏y試是一種有效性測試手段，我們考慮每一個需求并得到它的一組測試。劃分測試：程序的輸入數(shù)據(jù)和輸出結(jié)果總是落在幾個不同的類中，這些類中的數(shù)據(jù)有著公共的特征。由于類中成員的這些等價行為，這些類通常

24、叫做等價劃分或者域。測試用例應(yīng)從每個劃分中選擇。搜索例程-輸入劃分輸入數(shù)據(jù)符合前提條件。輸入數(shù)據(jù)不符合前提條件。輸入數(shù)據(jù)是序列中的一個元素。輸入數(shù)據(jù)不是序列中的一個元素。測試準則侑序測試）：用一個只有單個值的序列來測試軟件。在不同的測試中使用不同規(guī)模的多個序列。導(dǎo)出一個測試，讓序列的第一個、中間一個和最后一個元素得到測試。測試序列的長度為零。路徑測試：路徑測試的目標是要練習組件或者程序中的每一條執(zhí)行路徑，保證每個獨立的程序路徑執(zhí)行 一次。路徑測試的起點是程序流圖，程序流圖包含了代表選擇的節(jié)點和表示控制流的邊。程序中的可執(zhí)行語句都是流圖中的節(jié)點。測試用例應(yīng)能使所有的路徑都被執(zhí)行過。動態(tài)程序分析器

25、能用于檢查所有的路徑是否都被執(zhí)行過。COCOMO模型：COCOMO 2內(nèi)嵌了一些進行增量式詳細估算的子模型。COCOMO 2的子模型有：應(yīng)用組合模型：軟件是由現(xiàn)有的部分組成的時候使用。早期設(shè)計模型：當需求明確但是還沒進行設(shè)計的時候使用。復(fù)用模型：用于計算集成可重用軟件的成本。后體系結(jié)構(gòu)模型：一旦系統(tǒng)的體系結(jié)構(gòu)設(shè)計好且系統(tǒng)的更多信息明確時使用。過程改善過程分類：非正式過程：過程沒有嚴格定義的的過程模型。已管理過程：過程背后都有定義好了的過程模型，用來驅(qū)動開發(fā)過程。有方法的過程：過程有很多定義好了的方法。改善中的過程：過程有自動CASE工具箱的支持。過程選項：過程的使用應(yīng)取決于正在開發(fā)的產(chǎn)品的類型

26、對于大型系統(tǒng)，管理通常是主要的問題，所以您需要一個嚴格的管理過程；對于較小的系統(tǒng)，可以更隨意。應(yīng)該在一個組織中有統(tǒng)一適用的過程標準，但目前沒有如果你強迫開發(fā)團隊遵循不當過程，可能會產(chǎn)生偏高的成本；不適當?shù)姆椒ㄒ部赡茉黾映杀?，?dǎo)致質(zhì)量下降。過程度量：產(chǎn)品質(zhì)量數(shù)據(jù)必須要收集然而，在機構(gòu)沒有明確規(guī)定的過程標準，這是非常困難，因為你不知道用什么來度量。在 度量進行前，過程就必須要定義好。過程度量本身就能用于評估改善后的過程的效率但是，這并不意味著度量應(yīng)推動改善。組織的目標應(yīng)該是改善驅(qū)動過程。過程度量的分類：完成某一特定的過程所花的時間：如日歷時或者是個別工程人員花在過程中的時間。某個特定的過程需要的資

27、源：如以人數(shù)度量的總的工作量。某個特定事件發(fā)生的次數(shù)：如缺陷發(fā)生的次數(shù)等。過程變更：包括對以存在的過程進行修改，目標驅(qū)動過程變更。包括：引入新的練習、方法和過程；改變過程活動的優(yōu)先級；引入或者移除交付； 引入新的角色或責任。過程變更的階段：改善識別；改變優(yōu)先級；過程變更引入；過程變更培訓(xùn)；變更微調(diào)CMMI模型是一個集成了軟件和系統(tǒng)工程能力評估的能力模型。模型有兩個實例：階段性的；連續(xù)性的。CMMI模型組成：過程域：CMMI識別24個與軟件過程能力和改善相關(guān)的過程域。目標：目標是對一個機構(gòu)要達到的期望狀態(tài)的抽象描述。實踐：CMMI中的實踐是對達到目標的方法的描述。CMMI評估：基于6點等級為過程

28、指派的級別有：未執(zhí)行級；已執(zhí)行級；已管理級；已定義級；已量化管理級；優(yōu)化級。CMMI階段模型與軟件CMM的比較。每個成熟度級別都有相關(guān)的一組過程域和通用目標，如與模型的第二及（已管理級）相關(guān)的 過程域定義有：需求管理；項目規(guī)劃；項目監(jiān)控；供應(yīng)商協(xié)議管理；度量和分析；過程和產(chǎn) 品質(zhì)量保證。連續(xù)CMMI模型：它是一種考慮單個或一組以及評估每個實踐的使用的細粒度模型。成熟度評估不是單一的值，而且是一個展示機構(gòu)的域成熟的值的集合。每個過程域賦值由1到5。主要的優(yōu)點是機構(gòu)可以根據(jù)他們的愿望來挑選要改善的過程。配置管理：四種主要的配置管理活動：配置管理規(guī)劃、變更管理、版本和發(fā)布管理、系統(tǒng)構(gòu)建 配置管理規(guī)劃

29、所有產(chǎn)品都要進行管理：描述、設(shè)計、程序、測試數(shù)據(jù)、用戶手冊 CM規(guī)劃：定義要管理的文檔類型和命名方案；定義誰要負責CM過程和建立基線；為變更 控制和版本管理定義政策；定義必須保持的CM紀錄；描述應(yīng)當用于協(xié)助CM過程的任何 工具和它的使用限制；定義工具的使用過程；定義用于記錄配置信息的CM數(shù)據(jù)庫；可能 包括諸如外部軟件的CM、過程審計等信息。配置項識別：大型項目中可能包含數(shù)以千計的文檔，它們的配置中一定要唯一標志；很多文 檔是要貫穿軟件的生命周期的;應(yīng)該定義文檔的命名規(guī)則，以便相同類型的文檔命名也類似； 分層的命名規(guī)則是最靈活的方法。配置數(shù)據(jù)庫：所有的CM信息都要存儲在CM數(shù)據(jù)庫中；配置數(shù)據(jù)庫必須能夠?qū)Ω鞣N系統(tǒng) 配置查詢做出應(yīng)答；CM數(shù)據(jù)庫最好與被管理的軟件相鏈接。CM數(shù)據(jù)庫實現(xiàn)：可能是一個綜合環(huán)境的一部分，以支持軟件開發(fā)；軟件系統(tǒng)集成了 CASE 工具，因此CASE工具和CM工具的關(guān)系就更加密切了；更一般的是，CM數(shù)據(jù)庫是獨立管 理的，這種管理方式更加便宜和方便。變更管理：需求不斷發(fā)生變化，系統(tǒng)也相應(yīng)作出變更；變更管理關(guān)注的是對變化保持跟蹤， 并確保它們用最具成本效益的方式實施變更請求表：定義變更申請表是CM規(guī)劃過程的一部分。該表記錄了變更