2025年軟件工程自學關鍵考點與解題難點深度解析

《軟件工程》串講講義應考指導《軟件工程》是全國高等教育自學考試計算機及應用(獨立本科段)的一門專業(yè)課。新版教材與相比，無論是內容還是內容的組織，均有了很大的變化。整個知識體系、章節(jié)基于對軟件開發(fā)本質的認識，講解軟件工程的兩大技術問題：一是開發(fā)開發(fā)邏輯波及軟件生存周期過程、軟件生存周期模型(有關過程、活動和任務的組織框架)本課程共有8章：第1章：回答什么是軟件開發(fā)的本質第2章：軟件需求與軟件需求規(guī)約第3章：構造化措施第4章：面向對象措施-UML第5章：面向對象措施-RUP第6章：軟件測試。第7章：軟件生存周期過程及管理第8章：集成化能力成熟度模型CMMI1.歷年真題的分布狀況由于教材剛剛通過改版，新教材剛通過10月、01月、10月三次考試。通過對10月、01月這年份章名、題型一、緒論(單項、填空題)3分3分二、軟件需求與軟件需求規(guī)約9三、構造化措施(單、填、簡答、綜合)25分25分四、面向對象措施-UML(單、填、簡答)11分11分五、面向對象措施-RUP(單、填、簡答)12分12分六、軟件測試(單、填、簡答、綜合)25分23分10分10分八、集成化能力成熟度模型CMMI55從上面的記錄數(shù)據(jù)可以看出：重要的分值分布在第3章和第6章，分別占到總分的25%左右。第1章和第8章的考核知識點相對較少。2.題型分析(1)單項選擇題，共15小題，每題2分，共30分(2)填空題，共20個空，每空1分，共20分(3)簡答題，共6小題，每題5分，共30分(4)綜合應用題，共2題，每題10分，共20分3.復習措施(1)以教學大綱為準繩。自學考試的原則是：考試范圍既不超過大綱又不超過教材范圍。因此考生一定根據(jù)教學大綱規(guī)定的考試內容和考核規(guī)定，認真學習教材，要(3)注意學習措施，理論聯(lián)絡實際，重視理解重視理論聯(lián)絡實際，訓練并逐漸提高運用所學理論分析和處理實際案例的能力。考生應當注意在全面系統(tǒng)學習教材的基礎上，盡量多地理解和分析實際案例，以便更深刻地領會教材的(4)合理安排時間，抓住學習重點根據(jù)實際狀況自己安排，運用平時空余時間觀看網(wǎng)絡課件，形成基本的理解。接下來認真地做某些練習題，不清晰的地方再回過頭去看看書，并注意對不一樣的知識點進行比較，加深第一章緒論復習提議：考試題目類型重要是單項選擇題、填空題，題量在3%~5%之間。第一節(jié)軟件工程概念的提出與發(fā)展(1)20世紀60~80年代(2)20世紀80年代~今(3)近幾年(1)必要的軟件=程序+文檔2.軟件開發(fā)的本質：“映射”,即實現(xiàn)問題空間的概念和處理邏輯到解空間的概念和處理邏輯之間的映射。運用所掌握的知識，通過抽象，給出系統(tǒng)的一種構造。模型是一種抽象。模型是在特定意圖下所確定的角度和抽象層次上對物理系統(tǒng)的描述，一般包括對該系統(tǒng)邊界的描述、對系統(tǒng)內各模型元素以及它們之間關系的語義描述。(1)概念模型：描述軟件是什么(2)軟件模型：實現(xiàn)概念模型的軟件處理方案。包括設計模型、實現(xiàn)模型和布署模型。第二章需求獲取復習提議：(2)無歧義的(3)可測的(4)可跟蹤的(5)可測量的(1)顧客接口(2)硬件接口(3)軟件接口(4)通信接口(5)內存約束(6)運行(7)地點需求(1)法規(guī)政策(2)硬件限制(3)與其他應用的接口(4)并發(fā)操作(5)審計能力(6)控制功能(7)高級語言規(guī)定(8)握手協(xié)議(9)應用的關鍵程度(1)可靠性(2)存活性(3)可維護性(4)顧客友好性(1)自悟(2)交談(3)觀測(4)小組會(5)提煉第二節(jié)需求規(guī)約(SRS)(2)可修改的(3)完整的：沒有被遺漏的需求(4)一致的：不存在互斥的需求1.1產(chǎn)品的目的1.2文檔約定1.3風險承擔者1.4產(chǎn)品的范圍2.1產(chǎn)品的前景2.2產(chǎn)品的功能2.3用戶類和特征2.4運行環(huán)境2.5設計和實現(xiàn)上的限制2.6假設和依賴3.1用戶界面需求3.2硬件接口3.3軟件接口3.4通信接口5.5業(yè)務規(guī)則5.6用戶文檔附錄A:術語表附錄B:分析模型(1)非形式化的需求規(guī)約(2)半形式化的需求規(guī)約(3)形式化的需求規(guī)約(1)需求規(guī)約是軟件開發(fā)組織和顧客之間一份實際上的技術協(xié)議書，是產(chǎn)品功能及其環(huán)境的體現(xiàn)(2)需求規(guī)約是一種管理控制點(3)對于產(chǎn)品/系統(tǒng)的而設計，需求規(guī)約是一種正式的、受控的起始點(4)需求規(guī)約是創(chuàng)立產(chǎn)品驗收計劃和顧客指南的基礎第三章構造化措施復習提議：本章是整個課程的重點內容，其基本思想、基本原理和基本措施是軟件工程理論體系中最經(jīng)典的內容，考核題型波及單項選擇題、填空題、簡答題、綜合應用題所有題目類型，占分值25%左右。第一節(jié)構造化需求分析(2)人與人之間的通信，“有效溝通”(4)數(shù)據(jù)源和數(shù)據(jù)潭4.建模過程(繪制流程圖的過程)(1)建立系統(tǒng)環(huán)境圖(2)0層圖：從0層圖開始對流程圖中的要素編號(1)基本信息管理：教務管理人員輸入或修改學期教學執(zhí)行計劃、學生名單和教師名單；(2)學生選課：學生根據(jù)教學執(zhí)行計劃進行選課；(3)分派任課教師：教務管理人員為符合開課條件的課程分派教師，并打印任課告知單給教師；(4)成績管理：每門課程的教師在考試評分結束后將考試成績交給教務管理人員，教務管理人員輸入、維護成績，系統(tǒng)可生成成績單(發(fā)給學生)、成績記錄分析表(發(fā)給教務管理人員)。請根據(jù)規(guī)定畫出該問題的分層數(shù)據(jù)流圖(規(guī)定畫出頂層和0層數(shù)據(jù)流圖)。學生頂層圖成績單教師學生選課信息成績單0層圖⑤數(shù)據(jù)流必須起于且/或止于處理，即每一種數(shù)據(jù)流必須有一種處理與之有關，數(shù)據(jù)流貯且止于一種數(shù)據(jù)源/數(shù)據(jù)潭或另一種數(shù)據(jù)存貯；也不能起于某個實體且止于另一種數(shù)據(jù)源/數(shù)據(jù)潭或數(shù)據(jù)存5.數(shù)據(jù)字典次序構造：+反復構造：{}6.加工的描述★c)右上限代表每一種條件的取值(用Y和N來表達)d)右下限用X表達所對應的條件組合所產(chǎn)生的成果決策規(guī)則號12345678條件條件1YYYYNNNN條件2YYNNYYNN條件3YNYNYNYN應采取的行動XXXXXXXX銷售商在給顧客的折扣時，要考慮付款日期和交易額這兩個原因。若付款日期在10天以內(含10天),則當交易額超過￥10,000時，予以5%的折扣；當交易額在￥5,000到￥10,000之間(含￥5,000)時，予以3%的折扣；當交易額低于￥5,000時，沒有折扣。若付款日期超過10天，則無論交易額多少，均不給任何折扣。決策規(guī)則號1234條件付款日期≤10YYYN交易額≥10000YNN—交易額<5000NNY—應采取的行動XX無折扣XXθ?交易額≥10,000交易額≥10,000———折扣5%交易額<5,000—折扣0%折扣規(guī)則<當交易額超過￥10,000時，予以3%的折扣；當IF付款日期在10日以上折扣=0折扣=3%折扣=2%第二節(jié)構造化設計1.總體設計的任務(1)模塊構造圖(2)層次圖構造圖(StructureChart)是對軟件總體構造的一種圖形描述，它顯示了軟件的層次構造、組織和通訊。也就之間通過什么接口聯(lián)絡在一起。②⑤B⑤owxmULEA⑥F③①④(1)模塊符號(2)模塊調用關系(3)模塊間的數(shù)據(jù)傳遞(4)模塊間的控制信息傳遞(6)選擇調用構造4.層次圖層次圖中一種矩形框代表一種模塊，框間的連線表達調用關系(位于上方的矩形框所代表的模塊調用位于下方的矩形框所代表的模塊)。輸入輸出修改HIPO圖是美國IBM企業(yè)發(fā)明的“層次圖加輸入/處理/輸出圖”的英文縮寫。為了使HIPO圖具有可追蹤性，在H圖(即層次圖)里除了頂層的方框之外，每個方框都加了編號。舊的主文件1.校驗2.校驗輸出將DFD圖映射為設計層面的模塊及模塊調用。(1)變換流(TransformFlow)。基于變換流的數(shù)據(jù)流程圖是一種線性的次序構造，由輸入臂、輸出臂和變換中心三部分構成。其中變換中心使系統(tǒng)數(shù)據(jù)發(fā)生本質的變化，輸入臂將物理輸入變換成邏輯輸入，而輸出臂則將邏輯輸出變換成物理輸出。3.更新噩(2)事務流(TransactionFlow)。事務流的數(shù)據(jù)流程圖中有一種事務處理中心，它將輸入分為許多互相平行的加工途徑，然后根據(jù)輸入的屬性，選擇某一加工途徑。如下圖所示。業(yè)務中心完畢如下任務：>(1)接受事務(即輸入數(shù)據(jù));>(2)分析每個事務并確定它的類型；(3)根據(jù)事務的類型選用一條活動通路?？側蝿照{度判斷業(yè)務類型【例題】控制構造圖的繪制根據(jù)數(shù)據(jù)計算的數(shù)據(jù)流圖：輸入數(shù)據(jù)輸入數(shù)據(jù)數(shù)據(jù)求解打印輸出畫出以轉換為中心的控制構造圖?！窘馕觥窟@是一種經(jīng)典的以“轉換為中心”構造的分解，可以轉化為：數(shù)據(jù)計算輸入數(shù)據(jù)數(shù)據(jù)求解打印輸出總結：任何處理都可以劃分為兩種轉換類型之一：以轉換為中心的分解和以業(yè)務為中心構造的分解。【例題】產(chǎn)生固定資產(chǎn)資料數(shù)據(jù)流程圖如下，做出以業(yè)務為中心的模塊控制構造圖。固定資產(chǎn)明細表報表制作主管部門這是以業(yè)務為中心的處理，根據(jù)模板，可以轉化為：報表制作報表制作報表類型報表調度固固定資產(chǎn)明細表折舊匯總表資產(chǎn)變動表固定資產(chǎn)卡片8.模塊化是指一種模塊內部個成分之間互相關聯(lián)程度的度量。也就是說，凝聚是對模塊內各處(1)偶爾凝聚可維護性最差(2)邏輯凝聚(4)過程內聚(5)通信內聚(6)次序凝聚(7)功能凝聚可維護性最佳10.模塊耦合很顯然，為了使軟件具有很好的可維護性和可修改性，模塊間的關聯(lián)程度即耦合程度應越小越好。由于耦合程度越小，表明模塊間的獨立程度越大，這樣在修改一種模塊時，對其他模塊的影響程度就越小(1)內容耦合(2)公共耦合(3)數(shù)據(jù)耦合(4)控制耦合(5)標識耦合11.啟發(fā)式規(guī)則(1)改善軟件構造，提高軟件獨立性。模塊分解(2)模塊規(guī)模適中(3)力爭深度、寬度、扇出、扇入適中。(4)盡量使模塊的作用域在其控制域內。(5)竭力減少模塊接口的復雜度(6)力爭模塊功能可以預測13.構造化程序設計措施一種基于構造的編程措施，即采用次序構造、選擇構造和反復構造進行編程，其中每一構造只容許一種AAB或三種基本的控制構造：(a)次序構造，先執(zhí)行A再執(zhí)行B;(c)DO-WHILE型循環(huán)構造14.詳細設計工具(1)程序流程圖程序流程圖：程序流程圖又稱為程序框圖，它是歷史最悠久使用最廣泛的描述過程設計的措施，然而它也是用得最混亂的一種措施。出于要有一種不容許違反構造程序設計精神的圖形工具的考慮，Nassi和Shneiderman提出了盒圖，又稱值1值2…部分部分部分定程度的推廣。它用二維樹形構造的圖來表達程序的控制流，將PAD圖的基本符號。PnOdef第一個任務第二個任務第三個任務F條件T第一個任務第二個任務第三個任務F條件T部分部分PDL也稱為偽碼，它是用正文形式表達數(shù)據(jù)和處理過程的設計工具。言，它使用一種語言(一般是某種自然語言)的詞匯，同步卻使用另一種語言(某種構造化的程序設計語言)(1)概要設計規(guī)約>模塊描述>文獻構造和全局數(shù)據(jù)文獻的邏輯構造測試需求(2)詳細設計規(guī)約>各處理過程的算法>算法所波及的所有數(shù)據(jù)構造的描述AADCDCBEB輸入流變換中心輸出流題40圖輸出模塊G變換模塊輸入模塊變換口變換E變換F輸輸入入變換ABc【解析】這是一種經(jīng)典的變換型數(shù)據(jù)流程圖，將其轉換為模塊控制圖時，第一層可以分解為三個模塊：輸入模塊、變換模塊、輸出模塊。每一模塊還可以繼續(xù)分解。復習提議：以不變應萬變。統(tǒng)一建模語言(UnifiedModelingLanguage,UML)UML是目前流行的建模語言，尤其是在網(wǎng)站開發(fā)中廣泛應用。UML波及諸多的圖，每一種圖均有不一樣的圖形符號、作用，在什么狀況下用何種圖來描述是本章的重點內容?？己祟}目類型包括單項選擇題、填空題、簡答題，分值在10%~15%之間。需要考生掌握多種UML圖的作用。面向對象建模過程的環(huán)節(jié)：(1)需求獲取a)建立用況(usecase)模型和用況場景(2)需求分析a)建立活動圖和狀態(tài)圖b)類圖(建立域模型)c)次序圖(實現(xiàn)用況)(3)編寫需求規(guī)格闡明書(4)需求驗證對象(object)是系統(tǒng)中用來描述客觀事物的一種實體。一種對象由一組屬性和對這組屬性進行操作的一類(Class)是具有相似屬性、操作、關系和語義的一組對象的集合，它為屬于該類的所有對象提供了同類有超類(Superclass)和子類(Subclass)之分。(相對而言)對象與類的關系如同程序設計語言中變量和類型的關系。對象是類的實例(Instance)。類在類圖上使用包括三個部分的矩形來描述，如下圖4-1所示。最上面的部分顯示類的名稱，中間部分包括類的屬性，最下面的部分包括類的操作(或者說"措施")。圖4-1:類圖中的示例類對象對象或類的屬性(attributes)描述了對象的詳細特性。屬性有屬性名和屬性值(或稱屬性狀態(tài))?？梢娦裕簆ublic(+)、protected(#)、private(-)、包內的(~)4.類的操作一般也被稱為功能，不過它們被約束在類的內部，只能作用到該類的對象上。操作名、返回類型和參數(shù)可見性操作名(參數(shù)表):返回類型{性質串}例如：+取客戶地址(客戶名：字符串):字符串(1)采用品有分欄和關鍵字<interface>的矩形符號來表達(2)采用小圓圈和半圓圈來表達8.積極類至少具有一種進程或線程的類。可以啟動系統(tǒng)的控制A10.制品11.節(jié)點12.關聯(lián)(Association)(5)多重性：多重性(Multiplicity)定義了與一種對象/類相聯(lián)絡的對象/類出現(xiàn)一次，該對象/類也許汽車訂單訂單條目(10)約束13.泛化/繼承繼承：特殊類(子類)的對象擁有其一般類(超類)的所有屬性與服務，稱作特殊類對一般類的繼承 (Inheritance)。運用繼承(inheritance),子類可以繼承父類的屬性和措施。子類╱父類也可分別叫做特殊類/一般類、子類╱超類、派生類╱基類等。由某些存在多繼承關系的類形成的構造又稱作網(wǎng)格構造(Latt是指一般類中定義的屬性或服務被特殊類繼承之后，可以具有不一樣的數(shù)據(jù)類型或體現(xiàn)出不一樣的行為。這使得同一屬性或服務名在一般類及其各個特殊類中具有不一樣的語義。多態(tài)是指用同一界面形式表達不一樣對象類中的不一樣實現(xiàn)的能力。多態(tài)性的實現(xiàn)基于兩個基本原理：封裝和泛化。多態(tài)性實現(xiàn)的措施：(1)泛化15.細化細化是類目之間的語義關系，其中一種類目規(guī)約了保證另一類目執(zhí)行的契約。用空心三角形的虛線表達。16.依賴依賴是一種使用關系，用于描述一種類目使用另一類目的信息和服務。用有向虛線段表達。17.包包是模型元素的一種分組，一種包自身可以被嵌套在其他包中，并且可以具有子包和其他類型的模型元(一)構造圖(1)對象構造建模—類圖和對象圖(2)應用構造建?！鼒D、構件圖、布署圖、組合構造圖(二)行為圖對象交互建?！涡驁D、協(xié)作圖(通信圖、交互綜述圖、定期圖)、狀態(tài)圖(狀態(tài)機)分析活動圖設計狀態(tài)圖用況圖類圖類圖順序圖協(xié)作圖任何系統(tǒng)都需要從兩方面進行描述：構造信息和行為信息。系統(tǒng)的構成體現(xiàn)了系統(tǒng)各構成要素之絡，稱為構造；這些構成要素的執(zhí)行邏輯稱為行為。在面向對象措施中，系統(tǒng)的構造信息是通過類圖(classdiagram)來描述的；而系統(tǒng)行為信息則通過用況圖、交互圖(包括次序圖和協(xié)作圖)和狀態(tài)圖來描述的。也就是說，前者闡明了系統(tǒng)的構成部分是什么,而后者則闡明了系統(tǒng)做什么。類圖(classdiagram)體現(xiàn)了系統(tǒng)的靜態(tài)(1)系統(tǒng)中有哪些需要關懷的類?(2)這些類是怎樣描述的?(3)這些類之間的聯(lián)絡是什么?(5)泛化類名-屬性1-屬性2+操作1()+操作2()+操作n()訂單-訂單編號-訂貨日期-客戶編號+計算訂單總額)屬性操作(1)主題(2)用況(3)參與者：(4)關聯(lián)關聯(lián)擴展→用例泛化一般用例的特性并增加了新的特性包括→基用例3.狀態(tài)圖對象或者類的整體行為的某些規(guī)則所能適應的對象或類的狀況、狀況、條件、形式或生存周期。僅當對在由對象的所有屬性的屬性值集合所構成的笛卡兒乘積中的每一種等價集合(即，使對象的服務展現(xiàn)相似行為規(guī)則的屬性值的集合)稱之為對象的一種狀態(tài)。狀態(tài)圖(statechartdiagram)使用狀態(tài)、事件和轉換來記錄對象在其生命周期中所歷經(jīng)的狀態(tài)序列。①對象的初始狀態(tài)是圖中任何事件都未對該對象起作用時的狀態(tài)。②狀態(tài)代表對象生命周期中的某一瞬間。③轉換表明作為對事件的響應成果，對象將從一種狀態(tài)轉換到另一種狀態(tài)并執(zhí)行某個動作。④觸發(fā)狀態(tài)轉換的事件在狀態(tài)轉換字符串中命名。雙擊一種狀態(tài)轉換，除事件簽名以外，還可用字符串為其加注臨界條件、動作體現(xiàn)式等標簽。partialpaymentpaymentpartialpaymentpayment4.次序圖次序圖(sequencediagram)表達了對象之間傳送消息的時間次序，也就是對象之間的交互次序，這些交互是指在場景或用況的事件流中發(fā)生的。每一種對象(類)用一條生命線來表達——即用垂直線代表整個交互過程中對象的生命期。生命線之間的箭頭連線代表消息。次序圖中的基本元素包括：①活動者，指用況中的活動者。②對象，指在用況中的內部對象。③生命線：在次序圖中的一種對象下面的豎線，用以顯示這個對象的生命期。時間從上到下流過。生命線實際上顯示了消息的次序，在生命線之上的消息比在它之下的消息先發(fā)生。在生命線中的棒形方框表達的是活動生命線，用以強調一種對象只有在一種場景的部分中處在活動狀態(tài)。④消息，指場景內由事件流定義的內部事件成為在對象和活動者或其他對象之間的消息。2.管理需求·同步消息——返回消息。同步消息假定有一種返回消息。同步消息用有實心的箭頭表達；返回消息用虛線、箭頭也不是實心來表達。·反身消息——消息的發(fā)送方和接受方是同一種對象。·異步消息——沒有返回值的消息。用非實心箭頭表達?！ざㄆ谙ⅰ獙ο⒏郊訒r間約束條件，包括：發(fā)送時間、接受時間、已用時間等。objectName:cassNameobjectName:cassNamedassName1復習提議：RUP(RationalUnifiedProcess,統(tǒng)一軟件開發(fā)過程)。掌握RUP在處理下列三個問題的基本措施。(1)體現(xiàn)基本信息的術語(2)用于組織基本信息的體現(xiàn)格式(3)在不一樣抽象層之間進行“映射”的過程指導。本章考核題目類型包括單項選擇題、填空題、簡答題，分值在10%~15%之間。重點要掌握基本概念、基本原理。1.迭代式開發(fā)在軟件開發(fā)的初期階段就想完全、精確的捕捉顧客的需求幾乎是不也許的。實際上，我們常常碰到的問題是需求在整個軟件開發(fā)工程中常常會變化。迭代式開發(fā)容許在每次迭代過程中需求也許有變化，通過不停細化來加深對問題的理解。迭代式開發(fā)不僅可以減少項目的風險，并且每個迭代過程都可以執(zhí)行版本結束，可以鼓舞開發(fā)人員。3.體系構造4.可視化建模5.驗證軟件質量6.控制軟件變更以用況驅動的、以體系構造為中心的迭代、增量式開發(fā)。1.用況驅動(2)用況獲取的是功能需求(1)迭代是反復的部分(2)增量是增長的部分一種迭代是一種完整的開發(fā)循環(huán)，產(chǎn)生一種可執(zhí)行的產(chǎn)品版本，是最終產(chǎn)品的一種子集，它增量式地發(fā)展，從一種迭代過程到另一種迭代過程到成為最終的系統(tǒng)。需求需求計劃環(huán)境測試實施部署二維開發(fā)模型：RUP軟件開發(fā)生命周期是一種二維的軟件開發(fā)模型。橫軸通過時間組織，是過程碑(Milestone);縱軸以內容來組織為自然的邏輯活動，括活動(Activity)、產(chǎn)物(Artifact)、工RUP中的軟件生命周期在時間上被分解為四個次序的階段，分別是：初始階段(Inception)、細化階段 (Elaboration)、構造階段(Construction)和交付階段(Transition)。每個階段結束于一種重要的里程碑(Major圖5-2:RUP二維開發(fā)模型(1)初始階段初始階段的目的是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了到達該目的必須識別所有與系統(tǒng)交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義進行中的業(yè)務和需求方面的重要風險。對于建立在原有系統(tǒng)基礎上的開發(fā)項目來講，初始階始階段結束時是第一種重要的里程碑：生命周期目的(LifecycleObjective)里程碑。生命周期目的里程碑評價細化階段的目的是分析問題領域，建立健全的體系構造基礎，編制項目計劃，淘汰項目中最高風險的元素。為了到達該目的，必須在理解整個系統(tǒng)的基礎上，對體系構造作出性能等非功能需求。同步為項目建立支持環(huán)境，包括創(chuàng)立開發(fā)案例，創(chuàng)立模結束時第二個重要的里程碑：生命周期構造(LifecycleArchitecture)里程碑。生命周期構造里程碑為系統(tǒng)的構造建立了管理基準并使項目小組可以在構建階段中進行衡量。此刻，要檢查詳細(3)構造階段在構建階段，所有剩余的構件和應用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細測測試環(huán)境中進行布署。此刻，要確定軟件、環(huán)境、顧客與否可以開始系統(tǒng)的運作。此時的產(chǎn)品版本也常被稱交付階段的重點是保證軟件對最終顧客是可用的。交付階段可以跨越幾次迭代，包括為公布做準備的產(chǎn)品測試，基于顧客反饋的少許的調整。在生命周期的這一點上，顧客反饋應重要集中在產(chǎn)品調整，設置、安裝和可用性問題，所有重要的構造問題應當已經(jīng)在項目生命周期的初期階段處理了。在交付階段的終點是第四個里程碑：產(chǎn)品公布(ProductRelease)里程碑。此時，要確定目的與否實現(xiàn)，與否應當開始另一種開發(fā)周期。在某些狀況下這個里程碑也許與下一種周期的初始階段的結束重疊。第二節(jié)關鍵工作流RUP中有9個關鍵工作流，分為6個關鍵過程工作流(CoreProcessWorkflows)和3個關鍵支持工作流(CoreSupporingWorkflows)。盡管6個關鍵過程工作流也許使人想起老式瀑布模型中的幾種階段，但應注意迭代過程中的階段是完全不一樣的，這些工作流在整個生命周期中一次又一次被訪問。9個關鍵工作流在項目中輪番被使用，在每一次迭代中以不一樣的重點和強度反復。商業(yè)建模(BusinessModeling)工作流描述了怎樣為新的目的組織開發(fā)一種設想，并基于這個設想在商業(yè)用況模型和商業(yè)對象模型中定義組織的過程，角色和責任。需求(Requirement)工作流的目的是描述系統(tǒng)應當做什么,并使開發(fā)人員和顧客就這一描述到達共識。為了到達該目的，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統(tǒng)所處理問題的定義分析和設計(Analysis&Design)工作流將需求轉化成未來系統(tǒng)的設計，為系統(tǒng)開發(fā)一種強健的構造并調整設計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設計的成果是一種設計模型和一種可選的分析模型。設計模型是源代碼的抽象，由設計類和某些描述構成。設計類被組織成具有良好接口的設計包(Package)和設計子系統(tǒng)(Subsystem),而描述則體現(xiàn)了類的對象怎樣協(xié)同工作實現(xiàn)用況的功能。設計活動以體系構造設計為中心，體系構造由若干構造視圖來體現(xiàn)，構造視圖是整個設計的抽象和簡化，該視圖中省略了某些細節(jié)，使重要的特點體現(xiàn)得愈加清晰。體系構造不僅僅是良好設計模型的承載媒介，并且在系統(tǒng)的開發(fā)中能提高被創(chuàng)立模型的質量。實現(xiàn)(Implementation)工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織構造；以組件的形式(源文獻、二進制文獻、可執(zhí)行文獻)實現(xiàn)類和對象；將開發(fā)出的組件作為單元進行測試以及集成由單個開發(fā)者(或小組)所產(chǎn)生的成果，使其成為可執(zhí)行的系統(tǒng)。測試(Test)工作流要驗證對象間的交互作用，驗證軟件中所有組件的對的集成，檢查所有的需求已被對的的實現(xiàn)，識別并確認缺陷在軟件布署之前被提出并處理。RUP提出了迭代的措施，意味著在整個項目中進行測試，從而盡量早地發(fā)現(xiàn)缺陷，從主線上減少了修改缺陷的成本。測試類似于三維模型，分別從可靠性、功能性和系統(tǒng)性能來進行。布署(Deployment)工作流的目的是成功的生成版本并將軟件分發(fā)給最終顧客。布署工作流描述了那些與保證軟件產(chǎn)品對最終顧客具有可用性有關的活動，包括：軟件打包、生成軟件自身以外的產(chǎn)品、安裝軟件、為顧客提供協(xié)助。在有些狀況下，還也許包括計劃和進行beta測試版、移植既有的軟件和數(shù)據(jù)以及正式驗收。配置和變更管理工作流描繪了怎樣在多種組員構成的項目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準則來管理演化系統(tǒng)中的多種變體，跟蹤軟件創(chuàng)立過程中的版本。工作流描述了怎樣管理并行開發(fā)、分布式開發(fā)、怎樣自動化創(chuàng)立工程。同步也論述了對產(chǎn)品修改原因、時間、人員保持審計記錄。軟件項目管理(ProjectManagement)平衡多種也許產(chǎn)生沖突的目的，管理風險，克服多種約束并成功交付使顧客滿意的產(chǎn)品。其目的包括：為項目的管理提供框架，為計劃、人員配置、執(zhí)行和監(jiān)控項目提供實用的準則，為管理風險提供框架等。(9)環(huán)境環(huán)境(Environment)工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項目過程中所需要的活動，同樣也支持開發(fā)項目規(guī)范的活動，提供了逐漸的指導手冊并簡介了怎樣在組織中實現(xiàn)過程。工作指南蓬角色工具向導工件報告模板工件指南檢查點活動RUP運用用況(UseCase)技術來獲取需求。(1)列出候選的需求：特性列表(2)理解系統(tǒng)語境：領域模型或業(yè)務模型(3)捕捉功能需求：用況模型(4)捕捉非功能需求：補充需求或針對某些特定的用況特性：是一種新的項(Item)及其簡要描述。(1)業(yè)務對象(2)實在對象(3)事件(1)工作人員(2)業(yè)務實體(3)工作單元(1)發(fā)現(xiàn)并描述參與者(2)發(fā)現(xiàn)并描述用況(3)確定用況的優(yōu)先級(4)精化用況(5)構造顧客界面原型(6)用況模型的構造化(1)實體類活動者類?；顒诱哳惔沓瞿壳坝脹r模型中的活動者。(2)邊界類也稱界面類(UI類),是構成系統(tǒng)顧客界面的屏幕顯示、菜單和報表。例如，訂單處理系統(tǒng)中客戶登邊界類位于系統(tǒng)與外界的交界處。如：窗體類、報表類、描述通信協(xié)議的類、(3)控制類邊界類實體類控制類分析包：分析包體現(xiàn)了“局部化”、“問題分離”等軟件設計原理。分析包把某些變化限制到一種業(yè)務過程、一種參與者的行為或一組緊密有關的用況，形成某些不一樣的分析包。服務包和共享包。用況細化：(2)分析模型的體現(xiàn)(3)分析的重要活動活動1:體系構造分析活動2:用況分析定義滿足需求規(guī)約所需要的軟件構造。RUP的設計目的：定義滿足系統(tǒng)/產(chǎn)品分析模型所規(guī)約需求的軟件構造。(1)設計類(2)用況細化(3)設計子系統(tǒng)(4)接口(1)設計模型(2)布署模型(3)體系構造描述活動1:體系構造設計(1)標識節(jié)點和它們的網(wǎng)絡配置(2)標識子系統(tǒng)和它們的接口(4)標識一般性的設計機制活動2:用況的設計活動3:類的設計(1)概括描述設計類(2)標識操作(3)標識屬性(4)標識關聯(lián)和聚合(5)標識泛化(6)描述措施(7)描述狀態(tài)活動4:子系統(tǒng)設計(1)維護子系統(tǒng)依賴(2)維護子系統(tǒng)所提供的接口(3)維護子系統(tǒng)內容(2)對構成進行單元測試(1)實現(xiàn)體系構造(2)集成系統(tǒng)(3)實現(xiàn)子系統(tǒng)(4)實現(xiàn)類(5)完畢單元測試(1)計劃測試(2)設計測試(3)實現(xiàn)測試(4)執(zhí)行集成測試(5)執(zhí)行系統(tǒng)測試(6)評價測試第六章軟件測試復習提議第一節(jié)軟件測試目的與軟件測試過程模型1.軟件測試的對象軟件=程序+文檔(1)一種觀點是通過測試暴露出軟件中所包括的故障和缺陷(從顧客的角度);(2)另一種是但愿測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件中已對的地實現(xiàn)了顧客的顯然，第二種觀點對完善和提高軟件質量和可靠性毫無價值，因此測3.軟件測試的定義GlenfordJ.Myers把這一觀點歸納為：4.錯誤的類型(1)功能錯誤：處理功能闡明不完整或不確切，致使編程時對功能有誤解而產(chǎn)生的錯誤。(2)系統(tǒng)錯誤：與外部接口錯誤、子程序調用錯誤、參數(shù)使用錯誤等。5.軟件測試過程模型(1)測試設計(2)測試執(zhí)行(3)測試成果比較第二節(jié)軟件測試技術軟件測試人工測試機器測試個人復查走查會審黑盒測試白盒測試1.黑盒(Black-boxTestin定義域中有代表性的元素構成測試集，這些數(shù)據(jù)應包括對程序殊的數(shù)據(jù)元素。因此，黑盒測試法是從外界來檢查模塊或程序的功能，也即根據(jù)模塊的輸入和輸出得成果得差異。這種測試不必懂得模塊的內部邏輯，而是給定一輸入，檢查與否會得到2.白盒法(White-boxTesting):白盒法也稱之為構造測試或邏輯覆蓋法。它是根據(jù)對軟件內部邏輯構造的分析，選用測試數(shù)據(jù)集(即測試用例：TestingCase),而測試數(shù)據(jù)集對程序邏輯的覆蓋程度決定了測試完【答案】功能測試3.途徑測試技術(白盒測試)(1)控制流程圖(2)測試方略a)途徑覆蓋：執(zhí)行所有也許穿過程序控制流程的途徑。最強的測試度量。b)語句覆蓋：至少執(zhí)行程序中所有語句一次。最低的測試度量。c)分支覆蓋：至少將程序中的每個分支執(zhí)行一次。d)條件覆蓋與條件組合覆蓋【例題】根據(jù)下列程序流程圖，設計不超過2組的測試用例，使之滿足語句覆蓋，規(guī)定給出每組測試數(shù)據(jù)的執(zhí)行途徑、輸入值、輸出值及兩個鑒定(3)和(5)的鑒定成果。11入口F土F8返回TT3465【解析】此類題目屬于綜合應用題(每題10分),考核知識點為途徑測試技術。74.途徑選用的一般原則(2)在已選用的基礎上，選擇無循環(huán)的途徑，選用短途徑、簡樸途徑(1)事務與事務流程圖事務的含義(2)事務流測試的環(huán)節(jié)a)獲得事務流程圖b)瀏覽、復審c)用例設計d)測試執(zhí)行6.等價類法是根據(jù)程序的I/O特性，將程序的輸入劃分為有限個等行的測試等價于該區(qū)段內任何數(shù)據(jù)的測試。對于每個輸入條件存在著程序有誤輸入的無效等價類。例如，某實數(shù)X的取值范圍假設為a<X<b,7.邊值分析法是一種根據(jù)I/O邊界等價類上或緊靠邊界的條件，選擇測試用例的更有效的措施。例如，給定三個點，【例題】有一種學生選課系統(tǒng)：程序的輸入條件為：每個學生可以選修1至3門課程，試用黑盒測試法完畢(1)等價類法：課程門數(shù)<1課程門數(shù)>3課程門數(shù)1~3(2)邊界值分析法課程門數(shù)=1課程門數(shù)=38.因果圖法是通過從用自然語言書寫的功能闡明表中找出因—輸入條件和果—輸出成果，通過因第三節(jié)軟件測試環(huán)節(jié)單元測試(UnitTesting)又稱模塊測試(ModuleTesting),或模塊分調，用于測試單個程序模塊，確定模(1)模塊接口(2)局部數(shù)據(jù)構造(3)重要的執(zhí)行途徑(4)錯誤執(zhí)行途徑2.集成測試(1)自頂向下的集成測試：需要設計承接模塊(2)自底向上的集成測試：需求設計驅動模塊3.有效性測試第七章軟件生存周期過程與管理復習提議題目類型包括單項選擇題、填空題、簡答題，分值在10%左右。(1)獲取過程(2)供應過程(3)開發(fā)過程(4)運行過程(5)維護過程(1)過程實現(xiàn)(2)系統(tǒng)需求分析(3)系統(tǒng)體系構造設計(4)軟件需求分析(5)軟件體系構造設計(6)軟件詳細設計(7)軟件編碼和測試(8)軟件集成(9)軟件合格性測試(10)系統(tǒng)集成(11)系統(tǒng)合格性測試(12)軟件安裝(13)軟件驗收支持(1)選擇合適的生存周期模型(3)制定實行開發(fā)計劃(1)建立系統(tǒng)需求規(guī)格闡明(2)對系統(tǒng)需求進行評估(1)建立系統(tǒng)的頂層體系構造(2)對體系構造及每一項的需求進行評估(1)建立軟件需求規(guī)格闡明(2)對軟件需求進行評估(3)聯(lián)合復審(3)進行數(shù)據(jù)庫的頂層設計(4)編制顧客文檔的最初版本(1)文檔過程(2)配置管理過程(3)質量保證過程(4)驗證過程(5)確認過程(6)聯(lián)合評審過程(7)審計過程(8)問題處理過程(2)配置標識(3)配置控制：標識并記錄變更祈求(5)配置評價(6)公布管理和交付(1)管理過程(2)基礎設施過程(3)培訓過程(4)改善過程(1)啟動與范圍定義(2)規(guī)劃(3)測量(4)執(zhí)行與控制(5)評審與評價(6)結束處理(1)協(xié)議過程組(1)協(xié)議過程組(2)項目過程組(2)項目過程組(3)技術過程組(3)技術過程組(4)組織上項目使能過程組(4)組織上項目使能過程組(5)軟件實現(xiàn)過程組(5)軟件實現(xiàn)過程組(6)軟件支持過程組(6)軟件支持過程組(7)軟件復用過程組(7)軟件復用過程組第二節(jié)過程描述1.過程描述活動1:機遇標識活動2:供應方投標任務1:需求評審任務2:做出有關投標或接受協(xié)議的決定任務3:準備一份提案活動3:協(xié)議協(xié)商任務1:與獲取方就提供的軟件產(chǎn)品或服務，協(xié)商協(xié)議條文任務2:祈求對協(xié)議的修改，作為變更控制機制的一種成分?；顒?:協(xié)議執(zhí)行任務1:進行獲取需求評審任務2:定義或選擇一種適合項目范圍、粒度和復雜性的生存周期模型。任務3:3.軟件實現(xiàn)過程任務1:開發(fā)人員選擇合適的生存周期模型任務2:實行人員任務3:實行人員選擇合適的原則、措施、工具和編程語言任務4:開發(fā)進行該過程活動的計劃任務5:對不用交付的軟件項的處理。4.軟件需求分析過程5.軟件體系構造設計6.軟件驗證過程7.軟件確認過程第三節(jié)應用闡明2.與《ISO/IEC系統(tǒng)生存周期15288》的關系3.組織層和項目層4.過程之間的時序關系5.過程分解把過程劃分為某些小的“片段”6.生存周期模型和階段7.剪裁第四節(jié)軟件生存周期模型★1.瀑布模型(1)在決定系統(tǒng)怎樣做之前存在一種需求階段，它鼓勵對系統(tǒng)做什么有一種規(guī)約。(2)在系統(tǒng)構造之前有一種設計階段，它鼓勵規(guī)劃系統(tǒng)構造(3)每一階段均有評審，容許獲取方和顧客的參與(4)前一步作為下一步被承認的、文檔化的基線(1)規(guī)定客戶可以完整、對的和清晰地體現(xiàn)他們的需求，并規(guī)定開發(fā)人員一開始就理解這一應用。(2)由于需求的不確定性，使設計、編碼和測試階段都也許發(fā)生延期，并且當項目靠近結束時，出現(xiàn)了大量的集成和測試工作。(3)在開始的階段中，很難評估真正的進度狀態(tài)，并且直到項目結束之前都不能演示系統(tǒng)的功能。(4)在一種項目的初期階段，過度地強調了基線和里程碑處的文檔，并也許需要花費更多的時間用于建立某些用處不大的文檔。增量模型融合了瀑布模型的基本成分(反復應用)和原型實現(xiàn)的迭代特性，該模型采用伴隨日程時間的進展而交錯的線性序列，每一種線性序列產(chǎn)生軟件的一種可公布的“增量”。當使用增量模型時，第1個增量往往是關鍵的產(chǎn)品，即第1個增量實現(xiàn)了基本的需求，但諸多補充的特性還沒有公布。客戶對每一種增量的使用和評估都作為下一種增量公布的新特性和功能，這個過程在每一種增量公布后不停反復，直到產(chǎn)生了最終的完善產(chǎn)品。增量2分析設計編碼測試增量模型合用于“技術驅動”的軟件產(chǎn)品開發(fā)。長處：采用增量模型的長處是人員分派靈活，剛開始不用投入大量人力資源。假如關鍵產(chǎn)品很受歡迎，則可增長人力實現(xiàn)下一種增量。當配置的人員不能在設定的期限內完畢產(chǎn)品時，它提供了一種先推出關鍵產(chǎn)品的途徑。這樣即可先公布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用。此外，增量可以有計劃地管理技術風險。增量模型存在如下缺陷：1)由于各個構件是逐漸并入已經(jīng)有的軟件體系構造中的，因此加入構件必須不破壞已構造好的系統(tǒng)部分，這需要軟件具有開放式的體系構造。2)在開發(fā)過程中，需求的變化是不可防止的。增量模型的靈活性可以使其適應這種變化的能力大大優(yōu)于瀑布模型和迅速原型模型，但也很輕易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。3)假如增量包之間存在相交的狀況且未很好處理，則必須做全盤系統(tǒng)分析，這種模型將功能細化后分別開發(fā)的措施較適應于需求常常變化的軟件開發(fā)過程。演化模型是一種全局的軟件(或產(chǎn)品)生存周期模型。屬于迭代開發(fā)措施。該模型可以表達為：第一次迭代(需求->設計->實現(xiàn)->測試->集成)->反饋->第二次迭代(需求->設計->實現(xiàn)->測試->集成)->反饋->……即根據(jù)顧客的基本需求，通過迅速分析構造出該軟件的一種初始可運行版本，這個初始的軟件一般稱之為原型，然后根據(jù)顧客在使用原型的過程中提出的意見和提議對原型進行改善，獲得原型的新版本。反復這一過程，最終可得到令顧客滿意的軟件產(chǎn)品。采用演化模型的開發(fā)過程，實際上就是從初始的原型逐漸演化成最終軟件產(chǎn)品的過程。演化模型尤其合用于對軟件需求缺乏精確認識的狀況。演化模型重要針對事先不能完整定義需求的軟件開發(fā)。顧客可以給出待開發(fā)系統(tǒng)的關鍵需求，并且當看到關鍵需求實現(xiàn)后，可以有效地提出反饋，以支持系統(tǒng)的最終設計和實現(xiàn)。軟件開發(fā)人員根據(jù)顧客的需求，首先開發(fā)關鍵系統(tǒng)。當該關鍵系統(tǒng)投入運行后，顧客試用之，完畢他們的工作，并提出精化系統(tǒng)、增強系統(tǒng)能力的需求。軟件開發(fā)人員根據(jù)顧客的反饋，實行開發(fā)的迭代過程。第一迭代過程均由需求、設計、編碼、測試、集成等階段構成，為整個系統(tǒng)增長一種可定義的、可管理的子集。在開發(fā)模式上采用分批循環(huán)開發(fā)的措施，每循環(huán)開發(fā)一部分的功能，它們成為這個產(chǎn)品的原型的新增功能。于是，設計就不停地演化出新的系統(tǒng)。實際上，這個模型可看作是反復執(zhí)行的多種“瀑布模型”?！把莼Ｐ汀币?guī)定開發(fā)人員有能力把項目的產(chǎn)品需求分解為不一樣組，以便分批循環(huán)開發(fā)。這種分組并不是絕對隨意性的，而是要根據(jù)功能的重要性及對總體設計的基礎構造的影響而作出判斷。有經(jīng)驗指出，每個開發(fā)循環(huán)以六周到八周為合適的長度。演化模型的長處：(1)任何功能一經(jīng)開發(fā)就能進入測試以便驗證與否符合產(chǎn)品需求。(2)協(xié)助導引出高質量的產(chǎn)品規(guī)定。假如沒有也許在一開始就弄清晰所有的產(chǎn)品需求，它們可以分批獲得。而對于已提出的產(chǎn)品需求，則可根據(jù)對現(xiàn)階段原型的試用而作出修改。(3)風險管理可以在初期就獲得項目進程數(shù)據(jù)，可據(jù)此對后續(xù)的開發(fā)循環(huán)作出比較切實的估算。提供機會去采用初期防止措施，增長項目成功的機率。(4)大大有助于初期建立產(chǎn)品開發(fā)的配置管理，產(chǎn)品構建(build),自動化測試，缺陷跟蹤，文檔管理。均衡整個開發(fā)過程的負荷。(5)開發(fā)中的經(jīng)驗教訓能反饋應用于本產(chǎn)品的下一種循環(huán)過程，大大提高質量與效率。(6)假如風險管剪發(fā)現(xiàn)資金或時間已超過可承受的程度，則可以決定調整后續(xù)的開發(fā)，或在一種合適的時刻結束開發(fā)，但仍然有一種具有部分功能的，可工作的產(chǎn)品。(7)心理上，開發(fā)人員早日見到產(chǎn)品的雛型，是一種鼓舞。(8)使顧客可以在新的一批功能開發(fā)測試后，立即參與驗證，以便提供非常有價值的反饋。(9)可使銷售工作有也許提前進行，由于可以在產(chǎn)品開發(fā)的中后期獲得包括了重要功能的產(chǎn)品原型去向客戶作展示和試用。演化模型的缺陷：(1)假如所有的產(chǎn)品需求在一開始并不完全弄清晰的話，會給總體設計帶來困難及減弱產(chǎn)品設計的完整性，并因而影響產(chǎn)品性能的優(yōu)化及產(chǎn)品的可維護性。(2)假如缺乏嚴格的過程管理的話，這個生命周期模型很也許退化為一種原始的無計劃的“試一錯一(3)心理上，也許產(chǎn)生一種影響盡最大努力的想法，認為雖然不能完畢所有功能，但還是造出了一種有部分功能的產(chǎn)品。(4)假如不加控制地讓顧客接觸開發(fā)中尚未測試穩(wěn)定的功能，也許對開發(fā)人員及顧客都產(chǎn)生負面的影響。4.螺旋模型螺旋模型(SpiralModel)采用一種周期性的措施來進行系統(tǒng)開發(fā)。這會導致開發(fā)出色多的中間版本。使用它，項目經(jīng)理在初期就可以為客戶實證某些概念。該模型是迅速原型法，以進化的開發(fā)方式為中心，在每個項目階段使用瀑布模型法。這種模型的每一種周期都包括需求定義、風險分析、工程實現(xiàn)和評審4個階段，由這4個階段進行迭代。軟件開發(fā)過程每迭代一次，軟件開發(fā)又前進一種層次。采用螺旋模型的軟件過程如軟件過程螺旋模型基本做法是在“瀑布模型”的每一種開發(fā)階段前引入一種非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一種個小項目。每個小項目都標識一種或多種重要風險，直到所有的重要風險原因都被確定。螺旋模型強調風險分析，使得開發(fā)人員和顧客對每個演化層出現(xiàn)的風險有所理解，繼而做出應有的反應，因此尤其合用于龐大、復雜并具有高風險的系統(tǒng)。對于這些系統(tǒng)，風險是軟件開發(fā)不可忽視且潛在的不利原因，它也許在不一樣程度上損害軟件開發(fā)過程，影響軟件產(chǎn)品的質量。減小軟件風險的目的是在導致危害之前，及時對風險進行識別及分析，決定采用何種對策，進而消除或減少風險的損害。評審累計成本風險分析風險分析軟件產(chǎn)編碼單元軟件產(chǎn)編碼單元測試組裝開發(fā)計劃與需求圖7-螺旋模型(1)制定計劃：確定軟件目的，選定實行方案，弄清項目開發(fā)的限制條件；(2)風險分析：分析評估所選方案，考慮怎樣識別和消除風險；(3)實行工程：實行軟件開發(fā)和驗證；(4)客戶評估：評價開發(fā)工作，提出修正提議，制定下一步計劃。螺旋模型很大程度上是一種風險驅動的措施體系，由的方式工作，而不是項目經(jīng)理的方式。螺旋模型中存在眾5.噴泉模型噴泉模型是一種以顧客需求為動力，以對象為驅動的模型，重要用于采模型認為軟件開發(fā)過程自下而上周期的各階段是互相迭代和無間隙的特性。軟件的某個部分常常被反復多次，有關對象在每次迭代中隨之加入漸進的軟件成分。無間隙指計活動之間沒有明顯的界線，由于對象概念的引入，體現(xiàn)分析、設計、實現(xiàn)等圖7-噴泉模型噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結該模型的各個階段沒有明顯的界線，開發(fā)人員可以同步進行開發(fā)。其長處是可以提高省開發(fā)時間，適應于面向對象的軟件開發(fā)過程。由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外第五節(jié)過程規(guī)劃與管理過程規(guī)劃(P)過程執(zhí)行(D)(1)選擇軟件生存周期模型(4)確定活動的時序關系，并檢查信息流2.過程監(jiān)控(2)過程變化所產(chǎn)生的影響的評估(4)實現(xiàn)變化復習提議：軟件過程的改善問題。本章內容圍繞CMMI的構成和等級，簡介能力等級和成熟度等級，重要以概念和原理為主，考核題型為單項選擇題和填空題，分值在5%左右。第一節(jié)背景和原理全稱是CapabilityMaturityModelIntegration,即軟件能力成熟度模型集成，是由美國國防部與卡內基-梅隆大學和美國國防工業(yè)協(xié)會共同開發(fā)和研制的，其目的是協(xié)助軟件企業(yè)對軟件工程過程進行管理和改善，增強開發(fā)與改善能力，從而能準時地、不超預算地開發(fā)出高質量的軟件。其所根據(jù)的想法是：只要集中精力持續(xù)努力去建立有效的軟件工程過程的基礎構造，不停進行管理的實踐和過程的改善，就可以克服軟件開發(fā)中的困難。CMMI為改善一種組織的多種過程提供了一種單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減少了模型間的反復，增長透明度和理解，建立了一種自動的、可擴展的框架。因而可以從總體上改善組織的質量和效率。成本效益、明確重點、過程集中和靈活性四個方面。過程改進過程制定過程實施過程度量CMMI是一套融合多學科的、可擴充的產(chǎn)品集合，其研制的初步動機是為了運用兩個或多種單一學科的模型工程的關鍵問題，50數(shù)年來計算機的發(fā)展使人們認識到要高效率、高質量和低成當?shù)亻_發(fā)軟件，必須改善軟件生產(chǎn)過程?；赌Ｐ偷倪^程改善是指用采用能力模型來指導組織的過程改善，CMM的成功促使其他學科也相繼開發(fā)類似的過程改善模型，例如系統(tǒng)工程、需求工程、人力資源、集 不過，在同一種組織中多種過程改善模型的存在也許會引起沖突和混淆。CMMI就是為了處理怎麼保持這些(1)軟件能力成熟模型(SW-CMM)(2)軟件工程能力模型SECM(3)集成產(chǎn)品開發(fā)能力成熟度模型IPD-CMM每一種CMMI模型均有的基本模塊叫做“過程域”。一種過程域并不對怎樣執(zhí)行一種有效的過程(例如進入原則和離開原則、參與者任務、資源)做出描述，而是要對那些使用了有效過程的人做了什么(實踐)以及他們?yōu)楹巫鲞@些事(目的)做出描述。1.過程改善(ProcessImprovement)2.CMMI的模型部件 (2)每個專用目的和公共目的的實現(xiàn)，分別依賴某些實踐。(3)每個專用實踐有自己的子實踐和確定的經(jīng)典工作產(chǎn)品，符號：O