2011新版軟件工程自學筆記

1、一. 前言<1>. 軟件危機：20世紀60年代，隨著計算機的廣泛應用，軟件生產率，軟件質量越來越難以滿足社會發(fā)展的需求，成為制約社會、經濟的制約因素，人們把這一現象稱為軟件危機；<2>. 軟件的發(fā)展歷史：20世紀60年代末至80年代初，軟件系統(tǒng)規(guī)模，復雜性以及在關鍵領域的廣泛應用促進了軟件的工程化開發(fā)和管理；這一時期主要圍繞軟件項目開展了有關開發(fā)模型，開發(fā)方法和支持工具的研究；20世紀80年代以來，基于已開展的大量軟件工程實踐，圍繞對軟件工程過程的支持，開展了大量有關軟件生產技術特別是軟件復用技術和軟件生產管理的研究和實踐；<3>. 軟件工程：軟件工程是應用

2、計算機理論與技術，工程管理的原則和方法，按照預算和進度實現滿足用戶要求的軟件的工程，或以此為研究的學科；<4>. 軟件，軟件的本質：軟件是對特定問題域的抽象，是被開發(fā)出來的一個邏輯實體，而不是一個有形的物理部件；軟件的本質是實現問題域中的術語和處理邏輯到解空間的術語和邏輯的映射；<5>. 所要做的工作：一是如何實現映射，這是技術層面的問題，又可分為過程方向，即求解軟件的開發(fā)邏輯，如各種模型；和過程途徑，即求解軟件的開發(fā)手段，如結構化方法，面向對象方法等；二是如何管理這些映射，這是管理層面的問題；系統(tǒng)建模是運用所掌握的知識，經過抽象，給出系統(tǒng)的一個結構系統(tǒng)模型；<6

3、>. 基本途徑：求解一個問題的基本途徑是系統(tǒng)建模；所謂系統(tǒng)建模，是根據已掌握的知識，通過抽象給出系統(tǒng)的一個結構系統(tǒng)模型；模型是一個抽象，該抽象是在意圖所確定的視角和抽象層上對物理系統(tǒng)的描述，描述其中的成分以及各成分之間所具有的特殊語義關系，還包括對系統(tǒng)邊界的描述；在軟件設計領域，系統(tǒng)模型分為概念模型和軟件模型；概念模型描述了軟件是什么；軟件模型描述了實現概念模型的軟件解決方案；軟件模型又可分為設計模型，實現模型和不熟模型等；OUTLINE:二. 軟件需求分析1. 需求（1）. 需求的定義：一個需求是一個有關要予構造的陳述，它描述了待開發(fā)產品/系統(tǒng)功能上的能力，性能參數或其它性質；（2）.

4、 需求的屬性：必要性：該需求用戶所要求的；無歧義性：該需求只能用一種方式解釋；可測性：該需求是可進行測試的；可測量性：該需求是可測量的；可跟蹤性：該需求可以從一個開發(fā)階段跟蹤到另一個階段；（3）. 需求的分類：功能需求：規(guī)約了系統(tǒng)或系統(tǒng)構件必須執(zhí)行的功能；性能需求：規(guī)約了系統(tǒng)或系統(tǒng)構件在性能方面必須具有的一些特性；外部接口需求：規(guī)約了系統(tǒng)或系統(tǒng)構件必須與之交互的用戶、硬件、軟件或數據庫元素；設計約束：是一種需求，它限制了軟件系統(tǒng)或軟件系統(tǒng)構件設計方案的范圍；質量屬性：規(guī)約了軟件產品所具有的一個性質必須達到其質量方面所期望的一個水平；（4）. 需求發(fā)現技術：自悟；交談；觀察；小組會；提煉；在使用

5、以上技術時，還都可以輔以諸如原型構造等其它方法；在實際使用中，往往組合地使用以上技術；執(zhí)行需求發(fā)現這項活動的人，其技能水平對這項活動的成功具有重大影響；2. 需求規(guī)約：（1）. 需求規(guī)約的定義：需求規(guī)約是一個軟件項/產品/系統(tǒng)所有需求陳述的正式文檔，它表達了一個產品/系統(tǒng)的概念模型；（2）. 需求規(guī)約的性質：重要性和穩(wěn)定性程度；可修改的；完整的；一致的；（3）. 需求規(guī)約的作用：需求規(guī)約是軟件開發(fā)小組同用戶之間一份事實上的技術合同書，是產品功能和環(huán)境的體現；對產品/系統(tǒng)開發(fā)，需求規(guī)約是一個正式的受控的起始點；對于項目的其余大多數工作，需求規(guī)約是一個管理控制點；需求規(guī)約是創(chuàng)建產品驗收測試計劃和用

6、戶指南的基礎；（4）. 需求規(guī)約的表達方式：非形式化的需求規(guī)約；半形式化的需求規(guī)約；形式化的需求規(guī)約；OUTLINE:三. 結構化方法基本思想：一切信息系統(tǒng)都是由信息流構成的，每一信息流都有自己的起點信息源，有自己的歸宿信息潭，有驅動信息流動的加工，所謂信息處理主要體現為信息的流動；缺點是：依然沒有擺脫馮諾依曼體系結構的影響，所捕獲的數據和功能恰恰是客觀事物的異變性質，由此所構建的系統(tǒng)結構很難與客觀實際系統(tǒng)的結構保持一致；基本術語系統(tǒng)模型過程指導內部聯系：1. 主體為上面圖所示，基本術語，過程指導，系統(tǒng)模型；2. 由基本術語聯系到過程指導，因為過程指導要涉及到基本術語中的元素，如：建立系統(tǒng)環(huán)境

7、圖，確定系統(tǒng)語境，則對應基本術語中的數據源，數據流，加工，和數據潭；建立系統(tǒng)的層次數據流圖，主要對應基本術語中的數據流，數據存儲和加工；定義數據字典，對應基本術語中的數據流和數據存儲；描述加工，則對應基本術語中的加工；3.結構分析與結構設計的聯系，設計準備，確定邊界，對應確定系統(tǒng)邊界；第一次，第二層分解，對應建立系統(tǒng)的層次數據流圖；精化設計，對應定義數據字典；詳細設計，對應描述加工；1. 結構化分析（1）. 基本術語：支持表達分析中所要使用的說明；l 數據流：用于表達分析中所要使用的，用于表達客體的信息；l 加工：用于表達分析中所要使用的，用于表達計算的信息；l 數據存儲；用于表達分析中所要使

8、用的，用于表達結構化客體的信息；l 數據源和數據潭：用于表達分析中所要使用的，用于表達系統(tǒng)邊界的信息；（2）. 數據流圖DFD：表達系統(tǒng)模型的工具，支持表達系統(tǒng)功能；l 數據流起著連接其它實體的作用；l 處理之間可以包含多個數據流；l 對于一個大型的系統(tǒng)，往往需要采用多層次的數據流圖；（3）. 建模過程：給出過程指導，支持如何系統(tǒng)的使用相關信息來構造系統(tǒng)模型；<1>. 建立系統(tǒng)環(huán)境圖，確定系統(tǒng)語境；<2>. 自頂向下，逐步求精，建立系統(tǒng)的層次數據流圖；l 將父圖中的每一個加工按照功能分解為若干個子加工；l 將父圖中的輸入流和輸出流分派到相關的子加工上；l 在子加工之間建

9、立合適的聯系，必要時引入數據存儲，使之形成一個有機的整體；<3>. 定義數據字典，依據系統(tǒng)的數據流圖，定義其中包含的數據流和數據存儲的數據結構，知道給出構成以上數據的數據項的基本數據類型；數據結構定義符：順序結構+，選擇結構|，重復結構，定義=；數據流條目，數據存儲條目，數據項條目；<4>. 描述加工，依據系統(tǒng)的數據流圖，給出加工的小說明，一般式最底層的加工的輸入/輸出數據流之間的關系；l 結構化自然語言（外層控制結構+內層自然語言）；l 判定表；l 判定樹；2. 結構設計定義滿足需求所需要的結構（1）. 總體設計任務是將系統(tǒng)的功能需求放入一個特定的軟件體系結構中；目標

10、是給出系統(tǒng)的模塊結構；<1>. 初始設計：A. 系統(tǒng)數據流圖的分類：變換型數據流圖：分為輸入，變換，輸出；事務型數據流圖：分為輸入，分析并確定，選擇一條分支；B. 設計步驟：設計準備，復審并精化系統(tǒng)模型；確定輸入，變換，輸出的邊界；/確定事務處理中心；第一級分解，系統(tǒng)模塊結構圖的頂層和第一層的設計；主模塊，輸入，變換，輸出模塊；第二級分解，從頂向下，逐步求精；<2>. 精化設計，模塊化和啟發(fā)式規(guī)則A. 模塊化把待建的軟件分解為若干簡單的高內聚低耦合的模塊，這一過程稱為模塊化；B. 內聚與耦合內聚是指模塊內部各成分之間相互關聯程度的度量：主要有偶然，時間，順序，通信，邏輯

11、，過程，功能等類型；耦合是指不同模塊之間相互依賴程度的度量；主要有內容，公共，數據，控制，標記等類型；C. 啟發(fā)式規(guī)則改進軟件設計，提高軟件的獨立性；力求模塊規(guī)模適中；力求深度，寬度，扇入，善出適中；盡力使模塊的作用域在控制域之內；力求模塊功能可以預測；盡力降低模塊接口的復雜性；（2）. 詳細設計目標是給出系統(tǒng)模塊結構中各個模塊的內部描述過程，即模塊內部的算法設計；詳細設計的表格有：l 程序流程圖；l 盒圖N-S圖；l PAD圖；l 類程序設計語言；結構圖：抽象建立系統(tǒng)環(huán)境圖，確定系統(tǒng)語境；自頂向下，逐步求精；定義數據字典；描述加工；3.1 數據流起著連接其它實體的作用；3.2 兩個加工之間可

12、以有多個數據流；3.3 對于比較大的軟件系統(tǒng)，往往需要建立多層次的數據流圖；1. 基本術語3. DFD圖2. 過程指導描述系統(tǒng)模型的工具自頂向下，逐步求精數據流加工數據存儲數據源，數據潭1. 變換型2. 事務型1. 模塊化；2. 內聚與耦合；3. 啟發(fā)式規(guī)則；1. 模塊結構圖；2. 層圖；3. HIPO圖1. 總體設計2.詳細設計1.1初始設計1. 復審和精化系統(tǒng)概念模型2. 確定三部分之間的邊界；3. 第一級分解；4. 第二級分解；1. 程序流程圖；2. N-S圖3.PAD圖4. 類程序設計語言；1.2 精化設計軟件設計四. 面向對象設計UML基于的理論是：世界是由客體組成的，客體都有自己的

13、屬性和習慣操作?？腕w之間的相互依賴和相互作用構成了世界的各個系統(tǒng)。面向對象設計是根據客體之間的相互關系來建立系統(tǒng)模型的系統(tǒng)工具。類，對象主動類包接口協(xié)作用況構件制品節(jié)點關聯（聚合，組合）依賴（引入，擴展）泛化精化訪問引入類圖順序圖用況圖狀態(tài)圖名稱定義作用圖例1. 表達客觀事務的術語<1>. 類和對象A. 類，對象；B. 類是一組具有相同屬性，操作，關系和語義的對象的描述。對象是類的實例。C. 圖示：l 名稱：類：中間對齊，黑體字/斜體字，首字母大寫； 屬性：左對其，正常/下劃線，首字母小寫；操作：左對齊，正常/斜體字/下劃線，首字母小寫，大寫；l 格式：類： 類域：類；對象：類；屬

14、性：±Name:=操作：±Name():,(in/out Name:=)l 圖示：類名/對象名屬性操作l 可見性：+：public,公有的；#：protect,保護的；-：private,私有的；：包內的；D. 作用：模型化問題域中的概念；建立系統(tǒng)的職責分布模型；模型化建模中使用的基本類型；<2>. 主動類A. 主動類：Active Class；B. 主動類是一種至少具有一個進程或線程的類；C. 圖例：D. 模型化系統(tǒng)中的并發(fā)行為；<3>. 包A. 包，B. 定義C. 圖例：D. 作用：控制信息組織復雜性；<4>. 接口A. 接口，Int

15、erface；B. 接口是操作的一個集合，其中每個操作描述了類，構件，子系統(tǒng)所提供的一個服務；C. 圖例：interfaceuseD. 模型化系統(tǒng)/產品中的接縫；<5>. 協(xié)作A. 協(xié)作B. 協(xié)作是一個交互，包括交互各方、交互內容和交互方式；C. 圖列：D.E.F. 用于表達由一組特定元素參與的具有特定行為的結構，抽象協(xié)作性行為；<6>. 用況A. 用況，Use CaseB. 用況是對一組動作序列的描述，系統(tǒng)執(zhí)行這些動作應產生對特定參與者有值的可觀察的結果；C. 圖例：D. 模型化系統(tǒng)中的并發(fā)行為；<7>. 構件A. 構件，Component；B. 構件是系

16、統(tǒng)/產品設計中的一種模塊化部件，通過外部接口隱藏了內部實現；C. 圖例：D. 表達解空間中可獨立標識的成分；<8>. 制品A. 制品，ArtifactB. 制品是包含物理信息的可替代的物理部件；C. 圖例：artifactD. 通常用于表達有關源代碼信息或運行時信息的一個物理打包，抽象工作產品；<9>. 節(jié)點A. 節(jié)點，NodeB. 節(jié)點是運行時存在的物理元素；NodeC. 圖例：D. 通常用于表達一種具有處理能力或存儲能力的計算機資源，抽象計算單元；2. 用于表達關系的術語<1>. 關聯A. 關聯（Association）；B. 對具有相同語義，結構的關系

17、的描述；C. D. 抽象結構關系；E. 其它：<2>. 依賴A. 依賴（Dependency）B. ；C. ；D. 抽象使用關系；<3>. 訪問A. 訪問（Access）；B. ；C. ；D. 抽象包之間信息的訪問關系；<4>. 引入A. 引入（Import）；B. ；C. ；D. 抽象包之間的使用關系；<5>. 泛化A. 泛化（Generalization）；B. ；C. ；D. 抽象一般特殊關系；<6>. 細化A. 細化（Realization）B. ；C. ；D. 抽象細化關系；3. 建模工具結構圖：表達系統(tǒng)靜態(tài)結構模型，說明信

18、息；類圖，構建圖，部署圖等；行為圖：表達系統(tǒng)動態(tài)結構模型，行為信息；狀態(tài)圖模型化生命周期，用況圖模型化功能，順序圖模型化交互等；<1>. 類圖A. 類圖是可視化表達系統(tǒng)靜態(tài)結構模型的工具；B. 主要由類，接口，關聯，依賴，泛化關系等組成；C. 建造過程：l 模型化待建系統(tǒng)中的概念，形成類圖中的各個元素；l 模型化待建系統(tǒng)中的各種關系，形成系統(tǒng)的初始類圖；l 模型化系統(tǒng)中的交互，給出系統(tǒng)的最終類圖；l 模型化邏輯數據庫模式；Idel<2>. 狀態(tài)圖A. 狀態(tài)圖是顯示一個狀態(tài)機的圖，其中主要強調從一個狀態(tài)到另一個狀態(tài)的控制流；B. 組成元素及其圖形表示：l 狀態(tài)：被延遲事件

19、，進入/退出效應，do動作或活動；l 事件：信號，調用，時間，變化事件；l 狀態(tài)轉換：源狀態(tài)，目標狀態(tài)，轉換觸發(fā)器，監(jiān)護條件，效應；C. 主要用于：l 創(chuàng)建一個系統(tǒng)的動態(tài)模型；l 創(chuàng)建一個場景的模型；<3>. 用況圖A. 表達系統(tǒng)功能模型的圖形化工具；B. 組成元素及其圖形表示：l 參與者l 用況l 主題，用大矩形表示；l 關聯，泛化，依賴；C. 建造過程：l 語境的模型化：得到參與者，主題；將參與者分類，泛化，與用況建立關聯；l 需求的模型化：得到用況；并將用況泛化泛化，包含，擴展；<4>. 順序圖A. 順序圖是一種交互圖，即包含一組對象和按時序組織的對象之間的關系，

20、還包含對象之間發(fā)送的消息；B. 組成元素及其圖形表示：l 對象生命線；用于表達一個對象在一個時間段內的存在；l 聚焦控制；用于表達執(zhí)行一個動作的時間段；l 消息；用于表達交互內容的術語；l 控制控制子：選擇（Opt），條件（alt），迭代（loop），并發(fā)（par）執(zhí)行操作子；x=1Class1Class2Opt五. RUPRUP的特點：以用況為驅動，以體系結構為中心，迭代，增量式開發(fā)；其中每一個特點中都包含需求，分析，設計，實現，測試階段；迭代中分為初始階段，精化階段，構造階段，移交階段；基本術語系統(tǒng)模型過程指導1. 基本模型2. 每個階段的大概輪廓，包括橫向三項，每項又縱向3層基本術語分析

21、活動分析模型的表達分析類用況細化分析包實體類控制類邊界類類的分析用況分析包的分析體系結構分析3. 所有活動的規(guī)律的整理：發(fā)現并描述參與者和用況確定用況的優(yōu)先級精化用況構造用戶界面原型用況模型的結構化標識分析包標識重要的實體類用況分析類的分析包的分析處理分析類之間的共性標識服務包定義分析類之間的依賴標識公共特定需求表示節(jié)點和網絡配置標識有意義的設計類用況設計類的設計子系統(tǒng)設計表示子系統(tǒng)和接口標識一般性的設計機制獲取體系結構用況基本元素分析設計系統(tǒng)模型<1>. 對獲取階段，主要表現為需求的收集，精化和結構化；<2>. 在分析階段，把用況分成大塊并表示大塊之間的關系，再細分成

22、小塊，詳細描述小塊；<3>. 在設計階段，把大塊轉化成子系統(tǒng)，并層次化成軟件體系，之間的關系轉化為接口；小塊進一步細化，方向上是從上層和左邊進化，即依照上層中同列的用況進化，按照左邊大塊中的情況進化；4. 詳細的過程：如需求獲取包括：詳細每個表格參看課本；RUP使用用況技術來獲取需求；其目的是使用UML中的用況，參與者以及依賴等術語來抽象客觀實際問題，創(chuàng)建系統(tǒng)需求獲取模型，以及在該模型下的體系結構描述。用況模型是系統(tǒng)的一種概念模型，是對系統(tǒng)功能的抽象，包括系統(tǒng)參與者，系統(tǒng)用況以及他們之間的關系。階段產生制品1.列出候選需求特征列表2.理解系統(tǒng)語境領域模型和業(yè)務模型3.捕獲系統(tǒng)功能需

23、求用況模型4.捕獲非功能需求其它需求或針對特定需求的用況其中捕獲系統(tǒng)需求階段的活動又可分為：輸入活動人員輸出特征表，領域模型和業(yè)務模型，補充需求1.發(fā)現和描述參與者系統(tǒng)分析人員用況模型概述，術語表2.發(fā)現和描述用況用況模型概述，術語表，補充需求3.確定用況優(yōu)先級體系設計者體系結構描述用況模型視角用況模型概述，術語表，補充需求4.精化用況用況描述者用況精化用況精化，用況模型概述，術語表，補充需求5.構造用戶界面原型人機接口設計者人機接口用況精化，用況模型概述，術語表，補充需求6.用況模型的結構化系統(tǒng)分析員用況模型精化六. 軟件測試軟件測試軟件測試模型軟件測試技術：3個軟件測試步驟：3個1. 軟件

24、測試<1>. 軟件測試：按照特定規(guī)程發(fā)現軟件錯誤的過程；<2>. 軟件測試過程模型：環(huán)境對象素質環(huán)境模型對象模型錯誤模型測試執(zhí)行NOYES比較2. 軟件測試技術；<1>. 路徑測試技術；A. 控制流程圖；過程塊，判定，節(jié)點，鏈；B. 測試策略；語句覆蓋（P1）分支覆蓋（P2）條件和條件組合覆蓋路徑覆蓋（PX）；C. 路徑選擇和用例設計；l 選擇最簡單的、具有一定功能含義的入口、出口路徑；l 在已選擇的基礎上，選擇沒有循環(huán)的路徑，選擇短路徑，簡單路徑；l 選擇沒有明顯功能含義的路徑，并考慮這樣的路徑為什么能夠存在，為什么沒有通過功能上合理的路徑得到覆蓋；<

25、;2>. 事務流測試技術；A. 事務流程圖；操作，分支，節(jié)點，鏈；B. 與控制流程圖的區(qū)別：l 基本模型元素所表達的語義不同；l 一個事務不同于路徑測試中的一個路徑；l 事務流程圖中的分支和節(jié)點可能是一個更加復雜的過程：分支，匯集；并生，吸收；絲分裂，結合；C. 測試步驟：l 獲得事務流程圖；l 瀏覽、復審；l 用例設計；l 測試執(zhí)行；<3>. 等價類劃分；A. 劃分等價類；有效對無效：一對一，一對多，多對一；B. 設計測試用例：l 為每一個等價類規(guī)定一個唯一的編號；l 設計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步直到所有等價類都被覆蓋；l 設計

26、一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，知道所有無效等價類都被覆蓋；3. 軟件測試過程；A. 單元測試；l 關注單個模塊的結構和功能，還要建立驅動模塊和承接模塊；l 模塊接口：測試穿過模塊接口的控制流；l 局部數據結構：執(zhí)行數據結構測試；l 重要的執(zhí)行路徑：執(zhí)行執(zhí)行路徑選擇測試；l 錯誤的執(zhí)行路徑：邊界測試；B. 集成測試；l 從頂向下的集成測試，需要編制承接模塊；l 從底向上的集成測試，直到放上最后一個模塊程序才成為一個對立的整體；C. 有效性測試；l 發(fā)現軟件實現的功能與需求規(guī)格說明書不一致的錯誤；D. 系統(tǒng)測試；七. 軟件生存周期12207-2008過程組分類

27、和關系過程描述：6個生存周期模型5個過程建立過程監(jiān)控1. ISO/IEC 12207-2008 系統(tǒng)/軟件工程-軟件生存周期模型<1>. 背景ISO/IEC 12207-1995： 最早的軟件生存周期模型，過程分為基本過程，支持過程，組織過程；ISO/IEC 15288：系統(tǒng)生存周期模型； ISO/IEC 12207-2008，系統(tǒng)/軟件工程-軟件生存周期模型，由上兩種結合而來；<2>. 過程分類及其內在關系：協(xié)議過程組項目過程組技術過程組組織上項目使能軟件實現過程組軟件復用過程組軟件支持過程組系統(tǒng)語境過程類支持軟件開發(fā)的過程類驅動，支持：保障：對項目的執(zhí)行提供基本保障

28、；特殊化為：支持：提升能力：<3>. 過程描述：l 軟件實現過程：活動：軟件實現策略任務1：選擇并建立適合項目的生存周期模型；任務2：建立輸入文檔并置于配置管理過程之下，按配置管理的過程執(zhí)行變更；任務3：選擇，裁剪和使用組織為執(zhí)行或支持此過程而建立的標準、方法、工具或計算機編程語言；任務4：計劃該活動過程；任務5：確保交付的軟件產品的運行和維護不依賴非交付項；l 軟件需求分析過程活動：軟件需求分析；任務1：建立軟件需求和文檔；任務2：評估軟件需求，并建立相應的評估結果文檔；任務3：按軟件評審過程評審軟件需求；l 軟件體系結構設計活動：軟件體系結構設計；任務1：將軟件項的需求轉化為一

29、種體系結構，描述其頂層構架并表示其中的軟件構件，建立相應的文檔；任務2：為軟件項的外部接口和軟件構件之間的接口開發(fā)頂層設計，并建立相關的文檔；任務3：為數據庫開發(fā)頂層設計，并建立相關的文檔；任務4：開發(fā)用戶文檔的初始版本；任務5：定義初始測試需求和系統(tǒng)集成進度，并建立相關的文檔；任務6：評估軟件項的體系機構設計，接口設計，數據庫設計，并建立相關的文檔；任務7：按評審過程進行評審；l 軟件驗證過程活動1：過程實現；任務1.1：確定項目是否需要一項驗證過程以及獨立程度；任務1.2：如果項目承當驗證過程，則應為驗證軟件產品建立相關的驗證過程；任務1.3：如果項目需要獨立的驗證過程，則應選擇一個有資格

30、的組織執(zhí)行驗證；任務1.4：確定需要驗證的生存周期活動和軟件產品，并選擇合適的驗證過程和任務以及執(zhí)行這些任務相關的方法，技術和工具；任務1.5：計劃驗證過程，并建立相關的文檔；任務1.6：實現驗證過程；活動2：驗證過程；任務2.1：需求驗證；任務2.2：設計驗證；任務2.3：代碼驗證；任務2.4：集成驗證；任務2.5：文檔驗證；l 軟件確認活動活動1：過程實現；任務1.1：確定項目是否需要一項確認工作以及獨立程度；任務1.2：如果項目承擔確認工作，則應為確認軟件產品建立相應的確認過程，并定義確認任務以及相關聯的方法、技術和工具；任務1.3：如果項目需要獨立的確認工作，則應選擇一個有資格的組織負

31、責該工作；任務1.4：開發(fā)確認計劃，并建立相應的文檔；任務1.5：實現確認計劃；活動2：確認；任務2.1：編制選擇的測試需求、測試案例和測試規(guī)格說明，以分析測試結果；任務2.2：確保這些測試需求、測試案例和測試規(guī)格說明反映特定期望所使用的特殊需求；任務2.3：按照任務1和2執(zhí)行測試；任務2.4：確定軟件產品是否滿足所期望的使用；任務2.5：測試軟件產品是否適合所選擇的目標環(huán)境；l 剪裁過程任務1：標識并記錄剪裁可能造成的影響；任務2：考慮與系統(tǒng)關鍵特征相關的維度和生存周期結構；任務3：從剪裁過程所影響的所有各方獲得輸入；任務4：按照決策管理過程做出剪裁決定；任務5；選擇生存周期過程，剪裁并刪除

32、所選擇的結果、活動和任務；2. 軟件生存周期模型l 瀑布模型：把軟件生存周期各項活動規(guī)定為按固定順序連接的若干階段工作，形成瀑布流水，最終得到軟件產品；系統(tǒng)需求，軟件需求，需求分析，設計，編碼，測試，運行；對支持結構化開發(fā)，控制軟件開發(fā)的復雜性，促進軟件開發(fā)的工程化起著重要的作用；l 增量模型：將需求分組，形成一個個增量，對每一個增量實施瀑布式開發(fā)；前提是需求可結構化；l 演化模型：基于核心需求開發(fā)核心系統(tǒng)，根據用戶反饋實施開發(fā)的迭代過程；主要用于事先不能完整定義需求的軟件開發(fā)；l 螺旋模型：制定計劃，風險分析，實施工程，客戶評估；在瀑布模型和演化模型的基礎上，增加了他們所忽略的風險分析；l

33、噴泉模型：體現了軟件創(chuàng)建所固有的迭代和無間隙的特征；主要用于支持面向對象技術的軟件開發(fā)；3. 過程規(guī)劃和管理；在組織上項目使能過程組中有過程創(chuàng)建，過程評估，過程改進等過程，強調了PDCA，即過程規(guī)劃，過程執(zhí)行，過程檢測，過程調整；<1>. 關于過程創(chuàng)建；A. 選擇軟件生存周期模型：第一步：標識項目可用的SLCM；第二步：在預期的最終系統(tǒng)或開發(fā)環(huán)境中，標識影響選擇SLCM的屬性；第三步：標識所有為選擇SLCM而需要的約束；第四步：基于以往的經驗和組織能力，評估第一步中所標識的SLCM；第五步：選擇最能滿足項目屬性和約束的SLCM；B. 細化所選擇的軟件生存周期模型：依據所選擇的軟件生

34、存周期模型的需求和項目的需求，執(zhí)行剪裁過程，表示需要的活動和不需要的活動；C. 為每一個各活動或任務表示合適的實例數目；D. 確定活動的時序關系，并檢查信息流；<2>. 關于軟件生存周期監(jiān)控過程A. 軟件生存周期監(jiān)控過程；l 進度和進展的跟蹤；l 質量數據趨勢的檢查；l 設計、編碼和測試計劃的復審記錄和動作的檢查；l 變更要求和測試異常報告趨勢的檢查；l 關鍵資源的有效使用；l 與項目組成員的交談；B. 軟件生存周期活動變更的影響的評估；考慮的因素：l 所要求的返工；l 資源需求；l 實施時間；l 對項目和用戶的益處；l 員工情緒；可采用的動作；l 什么都不做；l 強化過程；l 調

35、整過程；l 替換過程；l 以上方式的組合；C. 改變的實施：l 規(guī)劃改變；l 實施改變；八. 能力和成熟度模型過程過程過程改善過程制度化CMMICMMI前身概念分類CMMI模型能力、熟度等級CMMI模型結構CMMI模型術語概念各級特征各級目標和實踐1. 過程：<1>. 過程：l 過程是一種手段，通過該手段可將人員，規(guī)程和方法，工具和設備進行集成，以開發(fā)所期望的系統(tǒng)，生產所期望的產品，提供所期望的服務；<2>. 過程改善：l 過程改善是人為設計的一個活動程序，其目的是改進組織的過程性能和成熟度，并改進這一程序的結果；<3>. 過程制度化：l 過程制度化是過程被

36、滲透到所執(zhí)行工作的方式中，執(zhí)行的工作有一定的承諾，并且在組織范圍內是一致的；2. CMMI概述：<1>. 前身：l 軟件能力成熟度模型，SW-CMM，SEI；l 系統(tǒng)工程能力模型，SECM，EIA；l 集成產品開發(fā)能力成熟度模型，IPD-CMM，SEI；<2>. CMMIl CMMI集成化能力成熟度模型是針對系統(tǒng)產品開發(fā)的能力成熟度模型，它包含一些最佳實踐，覆蓋了產品從概念到交付和維護的整個生存周期，強調了構造和維護當今產品所必要的工作；<3>. CMMI分類：l 針對獲?。籰 針對開發(fā)；l 針對服務；3. CMMI模型：A. 模型構成：子實踐過程域專用目標

37、共用目標意圖陳述簡介性注釋專用實踐共用實踐共用實踐的精化子實踐典型工作產品相關過程域B. 概念：l 過程域：是一個業(yè)務域一束相關的實踐，當他們一起得以實現時，就滿足被認為對該過程域的改善具有重要作用的一組條件；分為項目管理類，工程類，支持類，過程管理類；l 專用目標：用來描述滿足該過程域必須呈現的一些獨有特征；l 共用目標：用來描述實現制度化的該過程必須呈現的特征；C. 能力等級的應用：GG/GP 原句；補充中將“該過程”替換成應用的過程；如項目規(guī)劃過程應用于能力等級2：把該過程制度化為一個已管理的過程；制度化項目管理過程，使其成為一個已管理的過程；D. 各能力等級，成熟度等級所應達到的共有目

38、標和專有目標的對應：GG/GP獨立，能力等級是各GG/GP的向下遞歸；SG/SP獨立，成熟度是SG/SP的向下遞歸后過程域的能力等級；4. CMMI的能力等級和成熟度等級<1>. 能力等級；A. 定義：能力等級是一種過程改善路徑，該路徑使組織針對單一過程域不斷改進該過程域；指的是在單一過程域中達到的過程改善；B. 各等級基本特征：l 未完成級：該過程是一個沒有執(zhí)行或部分執(zhí)行的過程，沒有滿足任何一個或多個過程目標；l 已執(zhí)行級：該過程是一個已執(zhí)行的過程，即該過程達到了該過程域的專用目標；l 已管理級：該過程是一個已管理的過程，存在支持該過程的基本基礎設施；具體來說，該過程有計劃，并按

39、策略執(zhí)行；執(zhí)行該過程的人員為了生產受控輸出，具有一定的技能并具有充分的資源；該過程有相關利益攸關方的參與；該過程得以監(jiān)視，執(zhí)行，審查；并對其是否符合過程描述進行了評估；l 已定義級：該過程是一個已定義的過程，該過程是依據組織的過程剪裁指南從一個標準過程集剪裁而來的，并且該過程對組織的過程資產提供了有意義的工作產品，測量和其它過程改善信息；l 已定量管理級：該過程是一個已定量管理的過程；通過統(tǒng)計技術和其它定量技術控制過程性能；建立了有關質量和過程性能的量化目的，并作為管理過程的準則；在整個過程期間，采用統(tǒng)計術語的質量和過程性能的定量表達，是可理解并得以管理的；l 持續(xù)優(yōu)化級：該過程是一個已持續(xù)優(yōu)

40、化的過程；基于對該過程中內在偏差的共性原因的理解，通過增強，技術改進，不斷改進過程性能的程度；C. 各級別的共用目標和共用實踐：GG1.達到專用目標：該過程通過將認同的輸入工作產品轉化為認同的輸出工作產品，支持該過程域并使其達到其專用目標；GP1.執(zhí)行專用實踐：執(zhí)行該過程域的專用實踐，以開發(fā)工作產品，并為達到該過程域的專用目標服務；GG2.把該過程制度化為一個已管理的過程：制度化該過程，使其成為一個已管理的過程；GP2.1建立組織策略：為規(guī)劃和執(zhí)行該過程，建立并維護組織策略；GP2.2 規(guī)劃該過程：建立并維護執(zhí)行該過程的計劃；GP2.3 提供資源：為執(zhí)行該過程，以開發(fā)工作產品，并為該過程提供服務，提供充足的資源；GP2.4 指定責任：為執(zhí)行該過程，開發(fā)工作產品，并為該過程提供服務，指定責任和權利；GP