《軟件工程》是全國高等教育自學考試計算機及應用（獨立本科段）的一門專業課。任務，以及這些活動和任務的組織、實施和管理。械工業出版社出版，2011年版。系、章節安排、內容選取都不一樣，這是考生一定要注意的。新版教材的內容組織特點主要體現在：基于對軟件開發本質的認識，講解軟件工程的兩大技術問題：一是開發邏輯，二是開發途徑。以及項目軟件生存周期的規劃與監控。開發途徑涉及結構化方法和面向對象方法，以及支持軟件評估所需要的軟件測試技術等。本課程共有8章：第6章：軟件測試。9四、面向對象方法-UML（單、填、簡55右。第1章和第8章的考核知識點相對較少。本課程的考試題型分為：（1）以教學大綱為準繩。自學考試的原則是：考試范圍既不超出大綱又不超出教材范圍。所以考生一定根據教學大綱規定的考試內容和考核要求，認真學習教材，要全面、系統了解教材中的基本概念、基本知識。抓重點，對重點內容要進行深入細致的學習。重視理論聯系實際，訓練并逐漸提高運用所學理論分析和解決實際案例的能力。考生應當注意在全面系統學習教材的基礎上，盡可能多地了解和分析實際案例，以便更深刻地領會教材的內容，提高分析和解決實際問題的能力。根據實際情況自己安排，利用平時空余時間觀看網絡課件，形成基本的了解。接下來認真地做一些練習題，不清楚的地方再回過頭去看看書，并注意對不同的知識點進行比較，加深印象。復習建議：本章內容較少，主要是讓大家了解軟件工程的提出的背景-軟件危機以及軟件工程研究的內容。考試題目類型主要是單項選擇題、填空題，題量在3%~5%之間。軟件開發的速度、軟件制品的質量、軟件開發成本是軟件工程的三個軟件復用技術：構件技術、平臺技術、需求工程技術、領域分析技術、應用集成技術等。輯之間的映射。運用所掌握的知識，通過抽象，給出系統的一個結構。模型是一個抽象。模型是在特定意圖下所確定的角度和抽象層次上對物理系統的描述，通常包含對該系統邊界的描述、對系統內各模型元素以及它們之間關系的語義描述。復習建議：正確定義問題，是解決問題的基礎。需求獲取是軟件開發的第一步，它的工作質量決定了整個軟件開發工作的成的重點內容。考核的題目類型主要有：單項選擇題、填空題、簡答題，分值在10%左右。內容以基本概念、基本原理為主。一個需求是有關一個“要予構造”的陳述，描述了待開發產品/系統功能能力、性能參數或其它性質。（1）功能需求，是整個需求的主體。（2）非功能需求：性能需求、外部接口需求、設計約束和質量屬性需求。能夠區分哪些是功能需求，哪些是性能需求。IEEE標準830-1998(IEEE（1）需求規約是軟件開發組織和用戶之間一份事實上的技術復習建議：本章是整個課程的重點內容，其基本思想、基本原理和基本方法是軟件工程理論體系中最經典的內容，建議考生在牢記基本概念、基本原理的基礎上，對綜合應用題多下工夫，多做練習。用于建立系統功能模型。是一種描述數據變換的圖形化工具，其中包含的元素可以是數據流、數據存儲、加工、數據源和數據潭等。4.建模過程（繪制流程圖的過程）（1）建立系統環境圖（4）??（1）基本信息管理：教務管理人員輸入或修改學期教學執行計劃、學生名單和教師名單；（2）學生選課：學生根據教學執行計劃進行選課；（3）分配任課教師：教務管理人員為符合開課條件的課程分配教師，并打印任課通知單給教師；（4）成績管理：每門課程的教師在考試評分結束后將考試成績交給教務管理人員，教務管理人員輸入、【解析】任課安排任課安排學期教學執行計劃學生名單學生選課結果教師信息定義數據流程圖中所有數據流和數據存儲的數據結構。順序結構：+選擇結構：|子界：m..nc)右上限代表每一種條件的取值(用Y和N來表示)d)右下限用X表示所對應的條件組合所產生的結果【例題】畫出顧客購貨的折扣政策的決策表。銷售商在給顧客的折扣時，要考慮付款日期和交易額這兩個因素。若付款日期在10天以內(含10天則當交易額超過￥10,000時，給予5％的折扣；當交易額在￥5,000到￥10,000之間(含￥5,0【解析】判斷樹(DecisionTree)也稱為決策樹，是用來描述在一組不同的條件下，決策的行動是根據不同條件及其取值來選擇的處理過程。業務規則的描述通常可以使用判斷樹這一過程描述工具。【例題】畫出顧客購貨的折扣政策的決策樹。銷售商在給顧客的折扣時，要考慮付款日期和交易額這兩個因素。若付款日期在10天以內(含10天則當交易額超過￥10,000時，給予5％的折扣；當交易額在￥5,000到￥10,000之間(含解析：【例題】用結構化語言表達：顧客購貨的折扣政策。當交易額超過￥10,000時，給予3％的折扣；當交易額在￥5,000到￥10,000折扣；當交易額低于￥5,000時，沒有折扣。若付款日期超過10天，則無論交易額多少，均不給任何折扣。把系統的功能需求分配到一個特定的軟件體系結構中。結構圖(StructureChart)是對軟件總體結構的一種圖形描述，它顯示了軟件的層次結構、組織和通訊。也就是說，在結構圖中，顯示了軟件是由哪些模塊組成的，這些模塊按照什么樣的層次結構組織在塊之間通過什么接口聯系在一起。結構圖也稱之為控制結構圖、模塊結構圖或系統結構圖。層次圖中一個矩形框代表一個模塊，框間的連線表示調用關系（在H圖(即層次圖)里除了頂層的方框之外，每個方框都變換中心三部分組成。其中變換中心使系統數據發生本質的變化，輸入臂將物理輸入變換出臂則將邏輯輸出變換成物理輸出。行的加工路徑，然后根據輸入的屬性，選擇某一加工路徑。如下圖所示。業務中心完成以下任務：【例題】控制結構圖的繪制根據數據計算的數據流圖：畫出以轉換為中心的控制結構圖。【解析】這是一個典型的以“轉換為中心”結構的分解，可以轉化為：【例題】產生固定資產資料數據流程圖如下，做出以業務為中心的模塊控制結構圖。【解析】這是以業務為中心的處理，根據模板，可以轉化為：固定資產卡片資產變動表固定資產明細表固定資產卡片資產變動表固定資產明細表折舊匯總表執行一個特殊任務的一個過程以及相關的數據結構。模塊通常由兩部分組成：模塊接口和模塊體。“分而治之”和“抽象”。把一個待開發的軟件分解成若干個簡單的、具有高內聚低耦合的模塊，這一過程稱為模塊化。模塊化是系統設計基本原理/原則之一。是指一個模塊內部個成分之間相互關聯程度的度量。也就是說，凝聚是對模塊內各一種度量。很顯然，一個模塊的內聚越大越好。（1）偶然凝聚可維護性最差反之，模塊間的依賴程度越小，則其耦合程度也就越小。很顯然，為了使軟件具有較好的可維護性和可修改性，模塊間的關聯程度即耦合程度應越小越好。因為耦合程度越小，表明模塊間的獨立程度越大，這樣在修改一個模塊時，對其它模塊的影響程度就越小，從而使模塊的修改工作局限于一個最小范圍之內。原則是：盡量用數據耦合，少用控制耦合，限制公共耦合的范圍，避免使用內容耦合。11.啟發式規則高內聚、低耦合。（3）力求深度、寬度、扇出、扇入適中。深度：表示其控制的層數。寬度：同一層次上模塊總數的最大值。扇出：一個模塊直接控制的下級模塊的數目。扇入：有多少個上級模塊直接調用它。（4）盡量使模塊的作用域在其控制域內。模塊的控制域：這個模塊本身以及所有直接或間接從屬它的模塊的集合。模塊的作用域：受該模塊內一個判斷所影響的所有模塊的集合。具體描述模塊結構圖中的每一模塊，即給出實現模塊功能的實施機制，包括一組例程和數據結構。一種基于結構的編程方法，即采用順序結構、選擇結構和重復結構進行編程，其中每一結構只允許一個入口和一個出口。三種基本的控制結構：(b)IF-THEN-ELSE型選擇(分支)結構；①程序流程圖：程序流程圖又稱為程序框圖，它是歷史最悠久使用最廣泛的描述過程也是用得最混亂的一種方法。為N-S圖。(a)順序；(b)IF-THEN-ELSE型分支；(c)CASE型多分支；PAD是問題分析圖(ProblemAnalysisDiagram)的英文縮寫，自1973年一定程度的推廣。它用二維樹形結構的圖來表示程序的控制流，將這種圖翻譯成程序代碼PDL也稱為偽碼，它是用正文形式表示數據和處理過程的設計工具。的語法。★可以作為注釋工具直接插在源程序中間。完整準確地描述滿足需求規約所要求的所有功能模塊，以及伴隨功能模塊而出現的非功能機制。設計規約包括概要設計規約和詳細設計規約。指明高層軟件體系結構。【例題】根據下列變換型的數據流圖，設計出初始軟件結構圖。【答案】AABDCFE【解析】這是一個典型的變換型數據流程圖，將其轉換為模塊控制圖時，第一層可以分解為三個模塊：輸入模塊、變換模塊、輸出模塊。每一模塊還可以繼續分解。復習建議：以不變應萬變。UML是目前流行的建模語言，特別是在網站開發中廣泛應用。內容。考核題目類型包括單項選擇題、填空題、簡答題作用。面向對象建模過程的步驟：a)建立用況（usecase）模型和用況場景a)建立活動圖和狀態圖（4）需求驗證組方法組成。對象只描述客觀事物本質的與系統目標有關的特征。對象之間通過消息通信，一個對象通過向另一個對象發送消息激活某一個功能。一的抽象描述，其內部包括屬性和服務兩個主要部分。類有超類（Superclass）和子類（Subclass）之分。類在類圖上使用包含三個部分的矩形來描述，如下圖4-1所示。最上面每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UML規定類的屬性的語法為：通常也被稱為功能，但是它們被約束在類的內部，只能作用到該類的對象上。操作表組成操作界面。例如：+取客戶地址（客戶名:字符串）：字符串接口是操作的一個集合，其中每個操作描述了類、構件或子系統的一個服務。協作是一個交互，涉及交互的三要素：交互各方、交互方式以及交互內容。對一組動作序列的描述，系統執行這些動作應產生對特定參與者有值的、可觀察的結果。至少具有一個進程或線程的類。能夠啟動系統的控制活動，并且其對象的行的。表示方法：兩條豎線。系統設計中的一種模塊化部件，通過外部接口隱藏了它的內部實現。系統中包含物理信息的、可替代的物理部件。節點是在運行時存在的物理元素，通常表示一種具有記憶能力和處理能力的計算機資源。關聯反映了類和類之間的靜態關系。關聯在模型中，特別是在永久業務對象模型中是最基本的關系。鏈（link）是對象之間具有特定語義關系的抽象。現的最小和最大的數目。13.泛化/繼承繼承：特殊類（子類）的對象擁有其一般類（超類）的全部屬性與服務，稱作特殊類對一般類的繼承（Inheritance）。利用繼承（inheritance子類可以繼承父類的屬性和方法。子類／父類也可分別叫做特殊類／一般類、子類／超類、派生類／基類等。繼承反映了類之間的一種聯系或結構:一般-特殊結構，也稱分類結構（ClassificationStructure是由一組具有繼承關系的類所組成的結構。僅由一些單繼承關系的類形成的結構又稱作層次結構（Hierarchy是指一般類中定義的屬性或服務被特殊類繼承之后，可以具有不同的數據類型或表使得同一屬性或服務名在一般類及其各個特殊類中具有不同的語義。多態是指用同一界面形式表示不同對象類中的不同實現的能力。多態性的實現基于兩個基本原理：封裝和泛化。多態性實現的方法：（2）定義一個抽象類——接口類細化是類目之間的語義關系，其中一個類目規約了保證另一類目執行的契約。用空心三角形的虛線表示。16.依賴依賴是一種使用關系，用于描述一個類目使用另一類目的信息和服務。用有向虛線段表示。包是模型元素的一個分組，一個包本身可以被嵌套在其它包中，并且可以含有子包和其它類型的模型元素。圖形化工具。（1）對象結構建模—類圖和對象圖（2）應用結構建模—包圖、構件圖、部署圖、組合結構圖任何系統都需要從兩方面進行描述：結構信息和行為信息。系統的組成表達了系統系，稱為結構；這些組成要素的執行邏輯稱為行為。在面向對象方就是說，前者說明了系統的組成部分是什么，而后者則說明了系統做什么。類圖顯示系統各個部分以及怎樣將它們組裝起來;但卻不能模擬組裝后系統的工作情況。構造類圖的三個關鍵問題是：（1）模型化待建系統中的概念，形成類圖（2）模型化待建系統中的各種關系，形成該系統的初始關系。（3）模型化系統中的協作，給出該系統的最終類圖。用況是對一個參與者（actor）使用系統的一項功能時所進行的交出現異常的動作序列。況之間關系的一種圖。6個模型元素：（3）參與者：系統用戶:是最常見的一種角色。是直接使用系統的人。另一個系統：如DSS可作為MIS的一個活動者。補貨系統可作為定單處作。（4）關聯對象或者類的整體行為的某些規則所能適應的對象或類的狀況、情況、條件、形式或生存周期。僅當對象的行為規則不同時，才稱對象處于不同的狀態。在由對象的全部屬性的屬性值集合所構成的笛卡兒乘積中的每一個等價集合（即，使對象的服務呈現相同行為規則的屬性值的集合）稱之為對象的一種狀態。y為其加注臨界條件、動作表達式等標簽。UnpaiUnpaid partialpayment>PartlyPaid par partialpayment partialpaymentFullyPaid互是指在場景或用況的事件流中發生的。每一個對象（類）用一條生命線來表示——即用互過程中對象的生命期。生命線之間的箭頭連線代表消息。順序圖中的基本元素包括：線實際上顯示了消息的順序，在生命線之上的消息比在它之下的消息先發生。在生命線中的棒形是活動生命線，用以強調一個對象只有在一個場景的部分中處于活動狀態。?同步消息——返回消息。同步消息假定有一個返回消息。同步消息用有實心的箭頭表示；返回消息用虛線、箭頭也不是實心來表示。?反身消息——消息的發送方和接收方是同一個對象。?異步消息——沒有返回值的消息。用非實心箭頭表示。?定時消息——對消息附加時間約束條件，包括：發送時間、接收時間、已用時間等。掌握RUP在解決下列三個問題的基本方法。（3）在不同抽象層之間進行“映射”的過程指導。本章考核題目類型包括單項選擇題、填空題、簡答題，分值在10%~15%之間。重點要掌握基本概念、基本原理。1．迭代式開發在軟件開發的早期階段就想完全、準確的捕獲用戶的需求幾乎是不可能的。實際上，我們經常遇到的問題是需求在整個軟件開發工程中經常會改變。迭代式開發允許在每次迭代過程中需求可能有變化細化來加深對問題的理解。迭代式開發不僅可以降低項目的風險，而且每個迭代過程都可以執行版本結束，可以鼓舞開發人員。2．管理需求確定系統的需求是一個連續的過程，開發人員在開發系統之前不可能完全詳細的說明一個系能性需求的有效方法。3．體系結構組件使重用成為可能，系統可以由組件組成。基于獨立的、可替換的、模塊化的軟件體系結構。4．可視化建模RUP往往和UML聯系在一起，對軟件系統建立可視化模型幫助人們提告訴我們如何可視化的對軟件系統建模，獲取有關體系結構于組件的結構和行為信息。5．驗證軟件質量樣可以及早發現軟件中的缺陷。6．控制軟件變更變更，以此為每個開發人員建立安全的工作空間。第一節RUP的特點1.用況驅動在系統的生存周期中，以用況作為基礎，驅動系統有關人員對所要建立系統的功能需求進系統分析、設計、實現和測試等活動，包括制定計劃、分配任務、監控執行和進行組織在一起，使各個階段中都可以回溯到用戶的實際需求。2.以體系結構為中心系統體系結構：是對系統語義的概括描述，對所有項目有關人員都是可以理解的。3.迭代與增量一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。二維開發模型：RUP軟件開發生命周期是一個二維的軟件開發模型。橫軸通過時間組織，是過程展開的生命周期特征，碑(Milestone縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包Milestones每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。圖5-2：RUP二維開發模型（1）初始階段初始階段的目標是為系統建立商業案例并確定項目的邊界。為了達到該目的必須識別所有與系統交外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個進行中的業務和需求方面的主要風險。對于建立在原有系統基礎上的開發項目來講，初始階段可能很短始階段結束時是第一個重要的里程碑：生命周期目標（LifecycleObjective）里程碑。生命價項目基本的生存能力。（2）細化階段細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其范圍、主要性能等非功能需求。同時為項目建立支持環境，包括創建開發案例，創建模板、準則并準備工具結束時第二個重要的里程碑：生命周期結構（LifecycleArchitecture）里程碑。生命周期結構建立了管理基準并使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和的選擇以及主要風險的解決方案。（3）構造階段在構建階段，所有剩余的構件和應用程序功能被開發并集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個制造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。測試環境中進行部署。此刻，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版為“beta”版。（4）交付階段交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發布做準備的產品測試，基于用戶反饋的少量的調整。在生命周期的這一點上，用戶反饋應主要集中在產品調整裝和可用性問題，所有主要的結構問題應該已經在項目生命周期的早期階段解決了。在交付階段期。在一些情況下這個里程碑可能與下一個周期的初始階段的結束重合。第二節核心工作流RUP中有9個核心工作流，分為6個核心過程工作流（CoreProcessWorkflows）和3個核心支持工作流意迭代過程中的階段是完全不同的，這些工作流在整個生命周期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重復。（1）商業建模用況模型和商業對象模型中定義組織的過程，角色和責任。（2）需求需求（Requirement）工作流的目標是描述系統應該做什么，并使開發人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統所解決和范圍。（3）分析和設計整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析子系統（Subsystem而描述則體現了類的對象如何協同工作實現用況的功能。設計活動以體系結中心，體系結構由若干結構視圖來表達，結構視圖是整個設重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被創建模型的質量。（4）實現文件、二進制文件、可執行文件）實現類和對象；將開發出的組件作為單元進行測試以及集成由（或小組）所產生的結果，使其成為可執行的系統。（5）測試功能性和系統性能來進行。（6）部署部署（Deployment）工作流的目的是成功的生成版本并將軟件分發給最終用戶。部署工作流 （7）配置和變更管理配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟件創建過程中的版本。工作流描述了如何管理并布式開發、如何自動化創建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。軟件項目管理（ProjectManagement）平衡各種可能產生沖突的付使用戶滿意的產品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執行和監控項目提供的準則，為管理風險提供框架等。（9）環境環境（Environment）工作流的目的是向軟件開發組織提供軟件開發環境，包括過程和工具。環境工作流集中于配置項目過程中所需要的活動，同樣也支持開發項目規范的活動，提供了逐步的指導手冊并介紹何在組織中實現過程。RUP運用用況（UseCase）技術來獲取需求。創建系統用況模型的活動和任務：在系統用況模型的基礎上，創建系統分析模型以及在該分析模型視角下的體系結構描述。分析類：是類的一種衍型，很少有操作和特征標記，而用責任來定義其行為，并且其屬性和關系也是概念性的。存在三種不同類型的類：實體類、邊界類和控制類。實體類描述要保存到持久存儲體中的信息。如：數據庫、各種形式的數據文件中的信息。包括：活動者類。活動者類代表出現在用況模型中的活動者。活動者是現實世界中與系統交互的人和/或機構。例如，訂單處理系統中客戶是一個活動者類。業務類描述業務的地點、物品、概念和事件。例如訂單處理系統中的訂單、商品等都是業務類。也稱界面類（UI類是組成系統用戶界面的屏幕顯示、菜單和報表。例如，訂單處理系統中客戶登錄系統的界面、顯示和編輯訂單的屏幕等都屬于UI類。邊界類位于系統與外界的交界處。如：窗體類、報表類、描述通信協議的類、直接與外接與外部系統交互的類。控制類是主要負責其它類工作的類。如：主程序類、主窗體類。分析包把一些變化限制到一個業務過程、一個參與者的行為或一組緊密相關的用況析包。服務包和共享包。用況細化：定義滿足需求規約所需要的軟件結構。RUP的設計目標：定義滿足系統/產品分析模型所規約需求的軟件結構。4個術語：兩個角度：了解設計類的主要特征：操作、屬性、關系、方法、實現需求、是否為主動類。RUP實現的目標：包括：內部測試、中間測試和最終測試。RUP測試包括的主要活動：錯誤是不可避免的，我們要做的就是發現它，并改正它。軟件測試是保證軟件過程質量和軟件產品質量的基礎。因此軟件測試本章既有基本概念，也有綜合應用，要求考生多做練習。測試對象：各個階段產生的源程序和文檔。基于不同的立場，對軟件測試的目的存在著兩種完全對立的觀點。（2）另一種是希望測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件中已正確地實現了用戶的要求，因此，它們傾向于選取導致程序失敗概率最小的測試實例和數據。顯然，第二種觀點對完善和提高軟件質量和可靠性毫無價值，因此測試的目的應該地發現并改正軟件種存在的錯誤。GlenfordJ.Myers把這一觀點歸納為：測試法分為黑盒法和白盒法。定義域中有代表性的元素組成測試集，這些數據應包括對程序是有效的和無效的輸入，極端的、殊的數據元素。因此，黑盒測試法是從外界來檢查模塊或程序的功能，也即根據模塊的輸入和輸得結果得差異。這種測試無須知道模塊的內部邏輯，而是給定一輸入，檢查是否會得到所期望的測試法又具體分為等價類法，邊值分析法，因果圖法和錯誤猜測法等。【例題.填空題】黑盒法又稱為＿＿＿＿＿＿＿法，黑盒測試法是從外界來檢查模塊或程序的功能，也即根據模塊的輸入和輸出，得出所得結果得差異。依據的是程序的邏輯結構。基本元素：過程塊、節點、判定。鏈、路徑的概念。a)路徑覆蓋：執行所有可能穿過程序控制流程的路徑。最強的測試度量。b)語句覆蓋：至少執行程序中所有語句一次。最低的測試度量。c)分支覆蓋：至少將程序中的每個分支執行一次。最小的強制性測試需求是語句覆蓋率。【例題】根據下列程序流程圖，設計不超過2組的測試用例，使之滿據的執行路徑、輸入值、輸出值及兩個判定（3）和（5）的判定結果。在本題中，要求設計測試用例，滿足語句覆蓋，即所有語句都必須執行一遍。7是根據程序的I/O特性，將程序的輸入劃分為有限個等價區段，使得從行的測試等價于該區段內任何數據的測試。對于每個輸入條件存在著程序有效輸入的有效等價類是一種根據I/O邊界等價類上或緊靠邊界的條件，選擇測試用例的更有效的方法。例如，給定三個點，判定能否構成三角形，可選取兩邊之和等于第三邊的實例作為邊值分析法的測試用例。測試。(1)按等價類劃分法，設計測試用例(要求列出設(2)按邊界值分析法，設計測試用例。【解析】（1）等價類法：是通過從用自然語言書寫的功能說明表中找出因—輸入條件和果—輸出結果，通過換成一張判定表，然后為每種輸出條件的組合設計測試用例。錯誤推測法是根據測試人員的經驗和直覺推測程序種可能存在的各種錯誤。試和系統測試。單元測試（UnitTesting）又稱模塊測試（ModuleTesting或模塊分調，用于測試單模塊的邏輯和功能是否正確。單元測試采用白盒測試技術。驅動模塊和承接模塊。試是與單元測試平行進行的。集成測試采用黑盒測試技術。開發邏輯，是獲取正確軟件的關鍵！圍繞生命周期的階段劃分，掌握每一階段的任務、內容、工作方法、工作成果。題目類型包括單項選擇題、填空題、簡答題，分值在10%左右。是軟件的產生直到報廢的生命周期，周期內有問題定義、可行性分析、總體描述、但隨著新的面向對象的設計方法和技術的成熟，軟件生命周期設計方法的指導意義正在逐步減少。一般來說，軟件生存周包括計劃、開發、運行三個時期，每一時期又可分為的主要任務是分析用戶要求，分析新系統的主要目標以及開發該系統的可行性。開發時期兩大任務具體。具體分為需求分析、概要設計、詳細設計、編碼、測試。其中編碼和測試指那些與軟件生產直接相關的活動集。軟件開發者所從事的一系列活動和任務。將一組需求轉換為一個軟件產品或系統。（4）可以使用一些非交付的軟件項。（1）建立系統的頂層體系結構是指有關各方按他們的目標所從事的一系列支持活動集。支持活動有助于提高系統或軟件產品的質量。應用管理上、技術上的規程來支持整個軟件生存周期的過程。與軟件生產組織有關的活動集。 軟件是整個系統的組成部分。區分系統需求分析和軟件需求分析。沒有明確過程、活動、任務之間的時間依賴的序列。支持活動之間的迭代和再現。把過程劃分為一些小的“片段”系統需求——每一階段的輸入，即工作對象以及本階段的工作成果，作為輸出傳送到下一階段。瀑布模型的貢獻：（1）在決定系統怎樣做之前存在一個需求階段，它鼓勵對系統做什么有一個規約。瀑布模型存在的問題：（1）要求客戶能夠完整、正確和清晰地表達他們的需求，并要求開發人員一開始就理解這一應用。（2）由于需求的不確定性，使設計、編碼和測試階段都可能發生延期，并且當項目接近結束時，出現了大量的集成和測試工作。（3）在開始的階段中，很難評估真正的進度狀態，并且直到項目結束之前都不能演示系統的功能。（4）在一個項目的早期階段，過分地強調了基線和里程碑處的文檔，并可能需要花費更多的時間用于建立一些用處不大的文檔。增量模型融合了瀑布模型的基本成分（重復應用）和原型實現的迭代特征，該模型往往是核心的產品，即第1個增量實現了基本的需求，但很多補充的特征還沒有發使用和評估都作為下一個增量發布的新特征和功能，這個過程在每一個增量發布后不斷重復，直到產生了最終的完善產品。增量模型適用于“技術驅動”的軟件產品開發。優點：采用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源。如果核心產品很受歡加人力實現下一個增量。當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核徑。這樣即可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。此外，增量能夠有計劃地管理技術風險。缺點：增量模型存在以下缺陷：這需要軟件具備開放式的體系結構。2）在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。開發的方法較適應于需求經常改變的軟件開發過程。3.演化模型演化模型是一種全局的軟件（或產品）生存周期模型。屬于迭代開發方法。即根據用戶的基本需求，通過快速分析構造出該軟件的一個初始可運行版本，這個為原型，然后根據用戶在使用原型的過程中提出的意見和建議對原型進行改進，獲得原型一過程，最終可得到令用戶滿意的軟件產品。采用演化模型的開發過程，實際上就是從初成最終軟件產品的過程。演化模型特別適用于對軟件需求缺乏準確認識的情況。演化模型主要針對事先不能完整定義需求的軟件開發。用戶可以給出待開發系統的核心需求到核心需求實現后，能夠有效地提出反饋，以支持系統的最終設計和實現。軟件開發人員根據用戶的需求，首先開發核心系統。當該核心系統投入運行后，用戶試用之，完成他們的工作，并提出精化系統能力的需求。軟件開發人員根據用戶的反饋，實施開發的迭代過程。第一迭代過程均由需求、設計、編碼、辦法，每循環開發一部分的功能，它們成為這個產品的原型的新增功能。于是，設計就不斷地演統。實際上，這個模型可看作是重復執行的多個“瀑布模型”。“演化模型”要求開發人員有能力把項目的產品需求分解為不同組，以便分批循環開發。這種分組并不是絕對隨意性的，而是要根據功能的重要性及對總體設計的基礎結構的影響而作出判斷。有發循環以六周到八周為適當的長度。演化模型的優點：（1）任何功能一經開發就能進入測試以便驗證是否符合產品需求。得。而對于已提出的產品需求，則可根據對現階段原型的試用而作出修改。會去采取早期預防措施，增加項目成功的機率。（4）大大有助于早期建立產品開發的配置管理，產品構建（build自動化測試，缺陷跟蹤，文檔管理。均衡整個開發過程的負荷。（5）開發中的經驗教訓能反饋應用于本產品的下一個循環過程，大大提高質量與效率。時刻結束開發，但仍然有一個具有部分功能的，可工作的產品。（7）心理上，開發人員早日見到產品的雛型，是一種鼓舞。（8）使用戶可以在新的一批功能開發測試后，立即參加驗證，以便提供非常有價值的反饋。客戶作展示和試用。演化模型的缺點：性，并因而影響產品性能的優化及產品的可維護性。（2）如果缺乏嚴格的過程管理的話，這個生命周期模型很可能退化為一種原始的無計劃的“試－錯－改”模式。部分功能的產品。螺旋模型（SpiralModel）采用一種周期性的方法來進行系統開發。這會導致開發出眾多的中用它，項目經理在早期就能夠為客戶實證某些概念。該模型是快速原型法，以進化的開發方式為由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的素都被確定。螺旋模型強調風險分析，使得開發人員和用戶對每個演因此特別適用于龐大、復雜并具有高風險的系統。對于這些系統，風險是軟件開發不可忽視且潛及時對風險進行識別及分析，決定采取何種對策，進而消除或減少風險的損害。（1）制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件；（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；（3）實施工程：實施軟件開發和驗證；（4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之的方式工作，而不是項目經理的方式。螺旋模型中存在眾多變量，并且在將來會有更大幅度的增長，該體系正良好運作著。噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，模型認為軟件開發過程自下而上周期的各階段是相互迭代和無間隙的特性。軟件的某個部分常常多次，相關對象在每次迭代中隨之加入漸進的軟件成分。無間隙指在各項活動之間無明顯邊界，計活動之間沒有明顯的界限，由于對象概念的引入，表達分析、設計、實現等活動可以較為容易地實現活動的迭代和無間隙，使其開發自然地包括復用。噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開省開發時間，適應于面向對象的軟件開發過程。由于噴泉模型在各個開發階段是重疊的，因此在需要大量的開發人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難其是面對可能隨時加入各種信息、需求與資料的情況。復習建議：軟件過程的改善問題。單項選擇題和填空題，分值在5%左右。第一節背景和原理全稱是CapabilityMaturityModelIntegration，即軟件能力成熟度模型集成，梅隆大學和美國國防工業協會共同開發和研制的，其目的是幫助軟件企業對軟件工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。其所依據的想法是：只要集中持續努力去建立有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟件中的困難。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，新的集成模型模型的不一致性，減少了模型間的重復，增加透明度和理解，建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。成本效益、明確重點、過程集中和靈活性四個方面。CMMI核心理念：過程管理3.CMMI核心理念：過程管理CMMI是一套融合多學科的、可擴充的產品集合，其研制的初步動機型實現一個組織的集成化過程改進。CMMI的本質是軟件管理工程的一個部分管理工程的核心問題，50多年來計算機的發展使人們認識到要高效率、高質量改善軟件生產過程。基於模型的過程改進是指用采用能力模型來指導組織的過程改進，使之過程進行改善，該組織也能變得更加成熟。CMM的成功促使其他學科也相繼開發類似的過程改進模型，例如系統工程、需求不過，在同一個組織中多個過程改進模型的存在可能會引起沖突和混淆。CMMI就模式之間的協調。第二節C