1、教材：軟件項目管理 覃征 等 編著,第 1 章 導 論,1.1軟件工程一、軟件工程定義,軟件：是與一個系統(tǒng)，特別是一個計算機系統(tǒng)有關的程序、過程和有關文檔的完整集合。 工程：是科學和數學的應用，通過這一應用，使得自然界的物質和能源的特性通過各種結構、機器、產品、系統(tǒng)和過程成為對人類有用的東西。,軟件工程的定義有多種說法:,fritz bauernav69在nato會議上給出的定義: 軟件工程是建立和使用一套合理的工程原則，從而經濟地獲得可靠的和能在實際機器上高效運行的軟件。,ieeeieee93給出了一個更加綜合的定義： （） 將系統(tǒng)化的、規(guī)范的、可度量的方法應用于軟件的開發(fā)、運行和維護的過程

2、，即將工程化應用于軟件中。 （） （）中所述方法的研究。,本書給出的定義: 軟件工程是一類求解軟件的工程。它應用計算機科學、數學以及管理科學等原理，借鑒傳統(tǒng)工程的原則、方法，創(chuàng)建軟件以達到提高軟件質量、降低成本、按時按量交付的目的。,計算機科學、數學用于構造模型和算法。 工程科學用于制定規(guī)范、設計模式、評估成本及確定權衡。 管理科學用于計劃、資源、質量、成本等管理。,二軟件工程框架,軟件工程目標 軟件工程活動 軟件工程原則,軟件工程框架,軟件工程目標,正確性軟件產品達到預期功能的程 度。 可用性軟件基本結構、實現、文檔為用戶可用的程度。 合算性具有經濟效益，即開發(fā)、運行的開銷滿足用戶要求的程度

3、。,軟件工程活動-生產軟件步驟,問題定義明確要解決的問題 可行性分析即定義的問題是否有解決的辦法 需求分析為解決問題，目標系統(tǒng)必須具備哪些功能 設計總體設計，詳細設計 實現編寫程序代碼 確認測試 支持軟件維護,軟件工程原則,選取適宜的開發(fā)模型 采用合適的設計方法 提供高質量的工程支持 重視開發(fā)過程的管理,三軟件工程模型,所有軟件工程的活動都必須進行管理。 軟件項目管理貫穿于軟件工程的演化過程。 軟件工程的演化過程：,三軟件工程模型,軟件工程模型: 組織軟件工程活動的方法，稱為軟件工程模型。 軟件工程模型是用一定的流程將各個活動連接起來，并可用規(guī)范的方式操作全過程，如同工廠的生產線。 常見模型有

4、線性、快速原型、螺旋、漸增式等模型。,常見的軟件工程模型,線性模型（也稱，瀑布模型，順序模型）,常用的軟件工程模型,螺旋模型可看成是連接的線性模型,常用的軟件工程模型,漸增式模型（增量模型）,常用的軟件工程模型,漸增式模型首先構建系統(tǒng)的基本輪詢回路：,1.2項目管理一項目與項目管理,項目的概念及特點 項目：是指在一定約束條件下具有特定目標的一項一次性任務 共同特點： 一次性，又稱為單件性 目標的明確性：成果性目標（功能性要求），約束性目標 作為管理對象的整體性,2、項目的生命周期,項目的生命周期 項目啟動階段進行可行性分析，若接受項目進行需求確認，項目立項 項目計劃階段建立解決問題方案，向客戶

5、提交各種計劃書 項目實施階段執(zhí)行解決方案，實現項目的目標 工作結束階段正式驗收項目,另一書中對項目周期階段的劃分,生命周期階段 工程階段 初始階段 細化階段 生產階段 構造階段 移交階段,各階段特點,工程階段： 使計劃、需求和構架同時進化，并解決開發(fā)風險，這個階段以一個可執(zhí)行構架基線結束，即工程階段進行設計和綜合活動。 生產階段： 進行構造、測試和實施活動。,各階段特點,借助提高功能的演示使系統(tǒng)能力得以進化。 各種活動同時進化，每個階段都包括一次或多次迭代，一次迭代表示一個活動序列，這些活動有明確的中間事件（里程碑）。,各階段特點,主里程碑： 使用正式版本的評價標準和發(fā)布說明書，一個階段結束產

6、生一個主里程碑。 次里程碑： 使用非正式版本，一次迭代結束產生一個次里程碑。,各階段特點,為實現整個項目的某個特定狀態(tài)，每個階段都要進行足夠次數迭代。 各階段的工作產品（制品，文檔等），同時進化產生，但每個階段都有一個主要焦點： 初始階段需求 （生命周期目標里程碑） 細化階段設計 （生命周期構架里程碑） 構造階段實現 （初始的可操作能力里程碑） 移交階段實施 （產品發(fā)布里程碑） （這里的模型是漸增式（增量式）,項目管理,項目管理定義 pmi（project management institute）定義：在項目活動中運用一系列的知識、技能、工具和技術，以滿足或超過相關利益者對項目的要求。 項目

7、管理又可定義為：在一個確定的時間范圍內，為了完成一個既定的目標，通過特殊形式的臨時性組織運行機制，經有效的計劃、組織、領導和控制，充分利用既定有限資源的一種系統(tǒng)管理方法。,項目管理特點 綜合性 創(chuàng)造性 時間性,項目管理的要素,范圍 、 時間 、成本、 質量、 組織 、客戶滿意度,二項目管理知識體系,集成管理 范圍管理 時間管理 成本管理 質量管理 人力資源管理 溝通管理 采購管理 風險管理,三項目管理學科的發(fā)展,項目管理學科發(fā)展的特點 全球化發(fā)展、多元化發(fā)展、專業(yè)化發(fā)展 項目管理學科在雙向探索中前進 各學科領域的理論、方法應用于項目管理，項目管理的理論、方法應用于各學科領域 項目學發(fā)展的趨勢

8、微觀項目管理，即單一項目的管理 pmbok是當前項目管理學科發(fā)展的重要內容 項目學是知識創(chuàng)新與市場相結合的綜合化發(fā)展 項目學是科學、技術和藝術的綜合,軟件項目管理一軟件項目產品的特點,抽象性 缺陷檢測的困難性 高度的復雜性 缺乏統(tǒng)一規(guī)則,二軟件項目失控的原因,軟件失控項目(p15-16) 是指軟件項目在進行時遇到困難，導致大大超出可控制范圍的項目。 軟件項目失控的原因 七方面原因：需求不明確、計劃不充分和過于樂觀的估計、采用新技術、管理方法缺乏或不恰當、性能問題、團隊組織不當、人際因素,三軟件項目管理的內容,軟件項目管理的定義(p19) 軟件項目管理的過程(p19) 軟件項目管理的內容(p19

9、-20),軟件項目管理的定義,pmi對項目管理定義：在項目活動中運用一系列的知識、技能、工具和技術，以滿足或超過相關利益者對項目的要求。 軟件項目管理的定義：在軟件項目活動中運用一系列的知識、技能、工具和技術，以滿足軟件需求方的整體要求。,軟件項目管理的過程,啟動軟件項目 制定項目計劃 跟蹤及控制項目計劃 評審項目計劃 編寫管理文檔,軟件項目管理的內容,軟件項目需求管理 軟件項目估算與進度管理 軟件項目配置管理 軟件項目風險管理 軟件項目質量管理 軟件項目資源管理,第章軟件項目需求管理,軟件需求一. 軟件需求概念1. 定義,簡單地說，軟件需求就是確定系統(tǒng)需要做什么 嚴格意義上，軟件需求是系統(tǒng)或

10、軟件必須達到的目標與能力,定義軟件需求的五項內容,系統(tǒng)的輸入 系統(tǒng)的輸出 系統(tǒng)的功能 系統(tǒng)的屬性 系統(tǒng)環(huán)境的屬性,2.軟件需求在軟件項目的作用,軟件需求與其他軟件過程的關系,軟件需求類別1.軟件需求的抽象層次,軟件需求分成四個抽象層次 原始問題描述 用戶需求 系統(tǒng)需求 軟件設計描述,軟件需求的抽象層次,原始問題描述是對要解決問題的敘述 用戶需求是用自然語言和圖表給出的關于系統(tǒng)需要提供的服務及系統(tǒng)的操作約束 系統(tǒng)需求用詳細的術語給出系統(tǒng)要提供的服務及受到的約束，因而系統(tǒng)需求文檔也稱為功能描述 軟件設計描述是在系統(tǒng)需求的基礎上加入更詳細的內容構成的，它作為軟件詳細設計和實現的基礎，是對軟件設計活動

11、的概要描述,原始問題描述和用戶需求的抽象層次比較高能幫助我們在較高的抽象層次上進行交流，便于用戶和軟件開發(fā)人員之間的理解和溝通 系統(tǒng)需求和軟件設計描述則是具體的，可以根據它們來進行編碼實現 通常情況下，經常提到的是用戶需求和系統(tǒng)需求,2. 用戶需求,用戶需求從用戶的角度描述系統(tǒng)的需求，以便沒有專業(yè)技術背景的用戶能看懂它只描述系統(tǒng)的外部行為，盡量避免涉及系統(tǒng)內部的設計特性，因而用戶需求就不可能使用任何實現模型來描述，而只能通過自然語言，圖表，圖形等來敘述,使用自然語言可能出現如下問題,描述困難 需求混亂 因此寫需求文檔應遵守一些簡單原則： 標準的格式 使用一致的語言 使用特殊文本 盡量避免專業(yè)術

12、語,3. 系統(tǒng)需求,系統(tǒng)需求是比用戶需求更為詳細和專業(yè)的需求描述，是系統(tǒng)實現的依據一個完整且一致的系統(tǒng)需求描述，是軟件設計的起點 系統(tǒng)需求描述通常采用結構化語言和過程設計語言pdl.,系統(tǒng)需求的描述語言,4系統(tǒng)需求的分類,分為三類 ： 功能需求 非功能需求 領域需求,(1) 功能需求 功能需求描述系統(tǒng)所應提供的功能和服務，包括系統(tǒng)應該提供的服務，對輸入如何響應及特定條件下系統(tǒng)行為的描述 系統(tǒng)的功能需求應該具備全面性和一致性要做到全面和一致幾乎是不可能的原因有二，其一是系統(tǒng)本身固有的復雜性；其二是用戶和開發(fā)人員站在不同的立場上，導致他們對需求的理解有偏頗，甚至出現矛盾 為保證軟件項目的成功，無論

13、在哪個階段，只要發(fā)現問題，都必須修正需求文檔,(2) 非功能需求 非功能需求是指那些不直接與系統(tǒng)的具體功能相關的一類需求，但它們與系統(tǒng)的總體特性相關，如可靠性，響應時間，存儲空間等 非功能需求定義了對系統(tǒng)提供的服務或功能的約束，包括時間約束，空間約束，開發(fā)過程約束及應遵循的標準等,按照非功能需求的起源，可將其分為三大類：產品需求，機構需求，外部需求； 產品需求對產品的行為進行描述；機構需求描述用戶與開發(fā)人員所在機構的政策和規(guī)定；外部需求范圍比較廣，包括系統(tǒng)的所有外部因素和開發(fā)過程,表2.2 非功能需求的類別,(3) 領域需求 領域需求的來源不是系統(tǒng)的用戶，而是系統(tǒng)應用的領域，反應了該領域的特點

14、 領域需求可能是功能需求，也可能是非功能需，其確定需要領域知識,三軟件需求文檔,軟件需求文檔是對軟件系統(tǒng)要求的陳述 包括： 用戶需求 系統(tǒng)需求,三軟件需求文檔1. 需求文檔的編制與作用,編寫需求文檔時，以下幾點是應該注意的： 語句和段落盡量簡短 表達時采用主動語態(tài) 語句要完整，且語法，標點等正確無誤 使用的術語要與詞匯表中的定義保持一致 陳述時要采用一致的樣式 避免模糊的，主觀的術語，如性能優(yōu)越 避免使用比較性的詞匯，盡量給出定量的說明， 含糊的語句表達將引起需求的不可驗證,需求文檔的作用,使用對象 需求文檔的作用 軟件項目客戶 了解軟件項目能夠提供的軟件產品，檢查 軟件需求是否滿足需要 項目

15、管理人員 根據需求文檔制定項目的開發(fā)計劃和軟件過程，初步預測資源的使用 軟件開發(fā)人員 理解要開發(fā)的產品及具體要開發(fā)的內容 軟件測試人員 驗證軟件系統(tǒng)是否滿足了預期的要求 軟件維護人員 使用需求文檔幫助理解軟件系統(tǒng)內在的邏輯關系 軟件發(fā)布人員 在需求文檔的基礎上編寫用戶文檔，如用戶手冊 軟件培訓人員 在需求文檔的基礎上編寫培訓材料,軟件需求規(guī)格說明,(1)基本含義 規(guī)格就是一個預期的或已存在的計算機系統(tǒng)的表示，它可以作為開發(fā)者和用戶之間協(xié)議的基礎來產生預期的系統(tǒng) 軟件需求規(guī)格srs也稱為功能規(guī)格說明，需求協(xié)議或系統(tǒng)規(guī)格說明，精確地闡述一個軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件，是對

16、外部行為和系統(tǒng)環(huán)境（軟件，硬件，通信端口和人）接口的簡潔完整的描述性文檔,軟件項目管理者用srs來對項目進行計劃和管理。 除設計和實現上的限制外，srs一般不包括設計、構建、測試或工程管理的細節(jié)。 srs的基本內容包括功能需求和非功能需求。 功能需求定義系統(tǒng)需要“做什么”,描述系統(tǒng)輸入輸出的映射及其關聯(lián)信息,完整地刻畫系統(tǒng)功能,是整個軟件需求的核心。 非功能需求定義系統(tǒng)的屬性,描述和功能無關的目標系統(tǒng)特性,包括系統(tǒng)的性能、有效性、可靠性、安全性、易維護性及可見性等。,(2) ieee標準830-1998 見: p27p28,(3) srs 大綱 見: p28-p29,四. 軟件需求度量,一個好

17、的需求集應該滿足用戶解決問題需要的功能和服務,而且盡量避免軟件設計與軟件實現的細節(jié). 軟件需求質量度量的九個元素,即正確,無歧義,完備,一致,分級,可驗證,可修改,可跟蹤及可理解,22 需求工程,一 、 產生與發(fā)展 1、 產生 人們逐漸認識到需求分析活動不再僅限于軟件開發(fā)的最初階段，而是貫穿于軟件項目開發(fā)的整個生命周期。 需求工程是一個包括創(chuàng)建和維護需求文檔所必需的所有活動的過程，是將用戶非形式化的軟件需求轉變?yōu)樾问交男枨笠?guī)格說明的過程。 需求規(guī)格說明又是軟件設計、實現、測試直至維護的主要基礎。,2. 發(fā)展 需求工程的發(fā)展趨勢是對象化、形式化和自動化，并將向著縱深發(fā)展和綜合發(fā)展。 （）對象化

18、 需求工程的對象化主要是指需求模型及其構造方法的對象化，面向對象需求模型及需求定義語言是其研究的關鍵。,（ ）形式化 需求規(guī)格描述方法有三種: 形式化方法、非形式化方法和半形式化方法。 形式化方法是具有嚴格數學基礎的描述系統(tǒng)特征的方法，具有準確、無二義性的特點，有助于驗證有效性和完整性。 非形式化方法使用未作任何限制的自然語言，易于理解和使用，但它固有二義性，且難以保證正確性、可維護性，難以用計算機系統(tǒng)提供自動化的支持。 半形式化方法介于上述兩者之間，在宏觀上對語言和語義有較精確的描述，而在某些局部方面則允許使用非形式化的自然語言。,(3) 自動化 在自動化的層次方面，已從實現級、設計級發(fā)展到

19、功能級，并逐漸滲透到需求級。,二. 研究內容,、需求工程的目標 需求工程有兩個主要任務： 其一是通過對問題及其環(huán)境的理解、分析和綜合，建立分析模型; 其二是在完全弄清用戶對軟件系統(tǒng)的確切要求的基礎上，用srs把用戶的需求表達出來。,（）建立需求分析模型 分析模型是描述軟件需求的一組模型。 需求分析模型包含問題及其環(huán)境所涉及的信息流、處理功能、用戶界面、行為模型及設計約束等，是形成需求說明、進行軟件設計及實現的基礎。 （）編寫srs srs的編寫要以需求分析模型為基礎、按照軟件組織定義的srs大綱、采用某種需求描述語言來進行。,、需求工程的層次分解,需求工程可分為需求開發(fā)和需求管理，前者測重于需

20、求的生成，而后者測重于需求變更的控制。,需求開發(fā)和需求管理是有界限的：, 需求管理,一. 需求管理的必要性,、需求供求雙方固有的矛盾 需求過程中，需求的供求雙方經常會遇到雙方不能達成共識或雙方達成共識的內容其實有相當大的出入等情況。 、需求具有易變性和難以表述性 軟件項目中的問題都是在需求分析階段埋下的禍根。 軟件需求還很難以表述。 正是因為需求的易變性和難以表述性，所以需求需要有科學的分析方法和管理方法。,、需求錯誤出現的高頻性和修復的高昂成本需求錯誤是軟件項目開發(fā)中最常見的。,表2.4 軟件缺陷總結 缺陷來源 潛在缺陷 剩余缺陷 排除效率（%）需求 0.2 0.046 77 設計 0.25

21、 0.0375 85 編碼 0.35 0.0175 95 建檔 0.12 0.024 80 修復 0.08 0.024 70 合計 1 0.149 85.1,一個在需求階段出現的錯誤，在維護階段修復它的成本約是需求階段修復成本的倍。 對于軟件缺陷，修復的發(fā)現和修復的越早，則成本越低。 做好需求管理、減少需求錯誤的出現對降低軟件項目的成本是至關重要的。,軟件缺陷修復的成本,二. 目標和原則,、目標(p35-36) 需求管理的目的是在客戶和處理客戶需求的軟件項目組之間建立對客戶需求的共同理解。具體來說,需求管理的目標有二個: (1)使軟件需求受控,并建立供軟件工程和管理使用的需求基線。 (2)使軟

22、件計劃、產品和活動與軟件需求保持一致。,、原則 為進行有效的需求管理，通常要遵循如下五條原則： （）需求一定要分類管理 （）需求必須分優(yōu)先級 （）需求必須文檔化 （）需求一旦變化，就必須對需求變更的影響進行評估 （）需求管理必須與需求工程的其他活動緊密整合,三. 需求管理活動,需求管理規(guī)劃內容包括： 需求識別 變更管理過程 需求跟蹤 自動化工具,需求管理是一個對系統(tǒng)需求變更了解和控制的過程。需求管理的過程是與其他需求工程過程相互關聯(lián)的。初始需求導出的同時就啟動了需求管理規(guī)劃，一旦形成了需求文檔的草稿版本，需求管理活動就開始了。,需求管理活動的具體內容如表所示,2.3.4 需求變更管理,1、需求

23、變更的原因 軟件項目的需求總是在變化著,一般原因有二: (1)在項目的早期所有的問題不可能被完全定義,軟件需求是不完全的,注定了需求需要變更。 (2)隨著軟件項目的進行,軟件開發(fā)人員對問題的理解會發(fā)生變化,這些變化也要反饋到需求中去。,大型軟件系統(tǒng)還可能存在如下導致需求變更的原因: (1)不同類型的用戶的需求可能是沖突的或是矛盾的,最后的系統(tǒng)需求是它們之間的一個妥協(xié).這種妥協(xié)的程度在項目進行過程中有可能發(fā)生改變,從而導致系統(tǒng)需求的改變。 (2)系統(tǒng)購買者或系統(tǒng)最終用戶很少是同一人,有的系統(tǒng)客戶對系統(tǒng)提出的一些需求可能和最終用戶需求不一致。,2、變更管理過程 變更管理過程分為變更描述、變更分析和

24、變更實現三個階段。,(1)變更描述 變更描述階段要對需求問題或變更提議進行分析以檢查它的有效性，進而產生一個更明確的需求變更提議。 (2)變更分析 變更分析階段對被提議的變更產生的影響進行評估。一旦分析完成，就有了對此變更是否執(zhí)行的決策意見。,(3)變更實現 實現變更時，需求文檔及系統(tǒng)設計和實現都要做修改。一個容易出現的錯誤，一定要注意：先對系統(tǒng)做變更然后再回頭修改需求文檔的想法，這幾乎不可避免地導致需求描述和系統(tǒng)實現不同步。需求文檔應該有一個很好的形式，使得變更不會帶來大量文字的修改。對于程序文檔的可變性則通過最小化外部引用和盡量使之模塊化來實現。,3、變更影響分析 進行需求變更影響分析,應

25、評估每項選擇的需求變更,以確定它對項目計劃安排和其他需求的影響,同時明確與變更相關的任務并評估完成這些任務需要的工作量。變更影響分析有助于做出信息量充分的變更決策,確定對變更是修改還是拋棄,或者創(chuàng)建新系統(tǒng)以及評估每個任務的工作量.,如果一個處于關鍵路徑的任務因變更而延期,則項目肯定趕不上預定進度,但如果能避免變更影響關鍵任務,則變更不會影響項目的進度表 影響分析報告的模板,用來報告進行需求變更的影響分析,變更控制委員會僅需要影響分析的總結.,需求變更影響分析模板,4、變更控制流程需求變更控制的流程如圖所示,2.3.5需求文檔版本,如果沒有很好的需求文檔版本管理,就容易造成資源浪費. 需求文檔版

26、本控制是需求管理的一個必要方面.,做好需求文檔版本控制,必須保證如下幾點: 統(tǒng)一確定需求文檔的每一個版本,保證每個成員都能得到當前的需求版本; 清楚地將變更寫成文檔,并及時通知項目開發(fā)所涉及的人員; 為盡量減少困惑、沖突、誤傳，應只允許指定的人來更新需求文檔。,版本控制的最簡單方法是在每一個公布的需求文檔的版本應該包括一個修正版本的歷史情況，即已作變更的內容、變更日期、變更人的姓名以及變更的原因，并根據標準約定手工標記軟件需求規(guī)格說明的每一次修改。,2.3.6需求狀態(tài),1、需求的屬性 需求還有一些相關的屬性,這些屬性的定義及更新是需求管理的重要內容.需求的屬性為需求提供了背景資料和上下文關系。

27、,需求要考慮的屬性如下,(1)需求的創(chuàng)建時間 (2)需求的版本 (3)需求的創(chuàng)建者 (4)需求的批準者 (5)需求的狀態(tài) (6)需求的原因或根據 (7)需求涉及的子系統(tǒng) (8)需求涉及的產品版本 (9)需求的驗證方法或測試標準 (10)需求的優(yōu)先級 (11)需求的穩(wěn)定性,需求的優(yōu)先級,即從實現需求所涉及的代價、收益、成本、風險四個方面考察需求的優(yōu)先級 需求的穩(wěn)定性，表示將來需求可能變更的程度，穩(wěn)定性越差，意味著需求越容易發(fā)生變更，因而應給予較多的關注。,2、需求狀態(tài) 需求狀態(tài)是需求的一項重要屬性,跟蹤需求的狀態(tài)是需求管理的一個重要方面。 何謂需求狀態(tài)? 狀態(tài)是一種事物或實體在某一個時間點或某一

28、階段的情況的反映。需求狀態(tài)是指某時間點需求的一種情況反映。,客戶的需求可分為四種情況: 客戶可以明確且清楚地提出的需求. 客戶知道需要做些什么,但卻不能確定的需求. 需求可以由客戶得出,但需求的業(yè)務不明確,還需要等待外部信息. 客戶本身也說不清楚的需求.,需要與客戶溝通或確認的需求有兩種情況: 其一是確認雙方達成共識 其二是還需要再進一步的溝通 可把需求狀態(tài)分為如下8種 已建議 已批準 已拒絕 已設計 已實現 已驗證 已交付 已刪除,2.3.7需求跟蹤,1、需求跟蹤的必要性 進行需求跟蹤的目的是建立和維護從用戶需求開始到測試之間的一致性與完整性,確保所有的實現都以用戶需求為基礎,而實現的需求也

29、全部覆蓋了預期的需求,同時確保所有的輸出與用戶需求的符合性. 跟蹤能力信息使得變更影響分析十分便利,有利于確認和評估實現某個建議的需求變更所必須的工作.,2、可追溯性信息 進行需求跟蹤,就要對需求和需求之間以及需求和系統(tǒng)設計之間的許多關系進行追溯。當需求變更發(fā)生的時候,必須追蹤這些變題對其他需求和系統(tǒng)設計的影響。可追溯性是需求描述的一個總體特性,反映了反映相關需求的能力。,需要維護的可追溯性信息有三類: (1) 源可追溯性信息,指連接需求到提出需求 的項目相關人員和產生需求的原因. (2) 需求可追溯性信息,指連接需求文檔中彼此依賴的需求. (3) 設計可追溯性信息,指連接需求到其實現的設計模

30、塊.,3、需求跟蹤的實現 需求跟蹤有兩種方式,正向跟蹤和逆向跟蹤： (1) 正向跟蹤以用戶需求為切入點,檢查用戶需求說明書或需求規(guī)格說明中的每個需求是否都能在后繼工作產品中找到對應點。 (2) 逆向跟蹤檢查設計文檔、代碼、測試用例等工作產品是否都能在需求規(guī)格說明中找到出處。,需求跟蹤的雙向模式可以通過需求鏈來表示,過程元素之間的關系有如下三種 一對一，如一個代碼模塊應用一個設計元素。 一對多，如多個測試實例驗證一個功能需求。 多對多，如一個測試實例導致多個功能性需求，而其中一些功能性需求又擁有多個使用實例。,需求跟蹤矩陣,4、需求跟蹤的作用,在需求驗證中的作用 有助于需求變更影響分析 便于需求

31、的維護 便于測試時找出問題所在 便于項目跟蹤 減小項目的風險 簡化了系統(tǒng)的再設計 易于軟件重用,2.4 需求管理質量保證,2.4.1 需求驗證,1.需求驗證過程 審查需求文檔 依據需求編寫測試用例 編寫用戶手冊 確定合格的標準,2.驗證的內容 在需求驗證過程中,要對需求文檔中定義的需求執(zhí)行多種類型的檢查： 有效性檢查 一致性檢查 完備性檢查 現實性檢查 可檢驗性檢查 可跟蹤性檢查 可調節(jié)性檢查 可讀性檢查,2.4.2 需求評審,1.方式 評審有兩類方式:一類是正式技術評審, 另一類是非正式技術評審。 2.注意事項 嚴格控制每一次評審的文檔規(guī)模及持續(xù)時間 評審工作要分段進行 對討論的問題進行控制

32、 避免無謂的爭吵,第3章 軟件項目估算與進度管理,主要內容： 3.1 軟件項目估算 3.2 軟件規(guī)模 3.3 軟件項目成本估算 3.4 軟件項目進度管理,3.1 軟件項目估算,1. 項目估算的意義： 包括工作量估算和成本估算兩個方面。 估算是指通過預測構造軟件項目所需要的工作量的過程，初步的估算用于確定軟件項目的可行性，詳細的估算用于指導項目計劃的制定。 進度計劃是從時間的角度對項目進行規(guī)劃，而成本估算則是從費用的角度對項目進行規(guī)劃。,2.項目估算的問題：,1.項目人員對軟件開發(fā)盲目樂觀，對費用估計過低； 2.系統(tǒng)分析員對軟硬件權衡不準確，造成軟件成本增幅過大； 3.項目經理對各個階段的工作進

33、度沒有可靠的依據，難以控制開發(fā)過程。,3.估算的時機,軟件項目估算不是一勞永逸的活動，而是隨項目的進行而進行的一個逐步求精的過程。 對任何一種估算方法來說，估算的時機和精度都是一種矛盾。 選擇合適的時間點進行估算是估算中必須考慮的一個問題。,軟件產品生命周期及需要進行估算的五個時間點：e1,e2,e3,e4,e5,估算的時機,客戶需求：e1 客戶需求階段列出客戶需要的基本軟件功能。時間點e1的估算可以為軟件組織提供初步信息，否則需要重新考慮項目的可行性。 產品定義：e2 產品定義階段完成對項目的規(guī)格說明，進一步細化系統(tǒng)功能。 系統(tǒng)設計：e3 系統(tǒng)設計階段給出產品的完整軟件體系結構和各個子系統(tǒng)及

34、模塊的說明；,系統(tǒng)實現：e4 設計通過審查之后，系統(tǒng)的實現工作就開始了。該階段結束時，前面各項活動中消耗的資源（時間及人力等）和軟件工作量均可獲得，從而可對原有的估算進行調整，后期需要的工作則按此估算進行計劃。 系統(tǒng)運行：e5 當所有的工作都已完成并得到了驗證后，系統(tǒng)就可以投入運行了。估算工作實際上是對估算過程的評價，即用實際的消耗與各個階段估算值進行比較，為下一項目積累寶貴的經驗。,3.2 軟件規(guī)模,1.工作分解結構 傳統(tǒng)的wbs結構,軟件規(guī)模的估計步驟：,1.在技術允許的條件下，應從最詳細的wbs開始； 2.精確定義度量的標準； 3.估計底層每一模塊的規(guī)模，匯總以得到總體估計； 4.適當考

35、慮偶然因素的影響。,常用的軟件規(guī)模度量標準： 代碼行 doc: 功能點 fp:,代碼行： 代碼行l(wèi)oc是常用的源代碼程序長度的度量標準。 代碼行可分為：無注釋的代碼行（ncloc）和注釋的源代碼行（cloc） 實際工作中，也常常使用kloc（千代碼行）來表示程序長度。 一代碼行（1loc）價值和人月均代碼行數可以體現一個軟件生產組織的生產能力。,功能點： 功能點度量是在需求分析階段基于系統(tǒng)功能的一種規(guī)模估計方法，常應用需求來確定各種輸入、輸出、查詢、外部文件和內部文件的數目，從而確定功能點數量。,計算功能點數的步驟： （1）計算所需要的輸入、輸出、查詢、外部文件、內部文件的數量。,計算功能點數

36、的步驟：,（2）有了以上五個功能項的數量后，再由估計人員對項目的復雜性作出判斷，大致分成簡單、一般、復雜三種情況。然后根據下表求出功能項的加權和。,功能點fp是由未調整的功能點數ufc與技術復雜度因子（tcf）相成得到。,從上表計算出： tcf=0.65+0.01*(sum(aj) tcf的取值范圍為0.651.35， 分別對應著組成部分aj都取值0和5， 得到功能點fp的計算公式： fp=ufc*tcf,功能點度量在以下情況下特別有用： （1）估計新的軟件開發(fā)項目； （2）應用軟件包括很多輸入輸出或文件活動； （3）擁有經驗豐富的功能點估計專家； （4）擁有充分的數據資料，可以相當準確地將功

37、能點轉化為loc。,3.3 軟件項目成本估算,3.3.1 成本估算方法,一.算法模型,二.專家判定,對于由多個專家得到的多個估算值合成一個最終的估算值。可采用的方法有： （1）求中值或平均值 （2）召開小組會議,（3）delphi技術 （4）wideband delphi 技術,三.類比,四.自頂向下,推算出項目的總體成本或工作量，然后按比例分配到各個組成部分中去。 其缺點是難以識別較低級別上的技術性困難。,五.自底向上,自底向上估算是把待開發(fā)的軟件逐步細化，直到能明確工作量，由負責該部分的人給出工作量的估算值，然后把所有部分相加，就得到了軟件開發(fā)的總工作量。 易于忽略許多與軟件開發(fā)有關的系統(tǒng)

38、級成本。,六 計劃指南,默認工作量和進度在各階段的分布,七.成本和進度估計過程,自項向下的方法計劃序列 軟件項目經理(和其他人)開發(fā)出項目所需的規(guī)模、過程、環(huán)境、人員和質量的全局描述。 使用軟件成本估計模型，在宏觀級別上估計整體工作量和制定進度。 軟件項目經理使用如表1中的指南，將估計的工作量分配到第一級工作分解結構中。軟件項目經理又使用表2中的指南，將進度分成主里程碑日期、并將工作量分配給各級人員。 此刻，子項目經理負責將每一個工作分解結構元素劃分到更低的級別，而使其滿足頂層分配、人員結構和主里程碑日期的限制。,由底向上的方法計劃序列 最低級別的工作分解結構元素被細化成細節(jié)任務，相關的工作分

39、解結構元素的管理人員根據這些任務估計預算和進度。 在較高級別預算和里程碑中結合并集成了估計。 與自頂向下的預算和進度里程碑進行比較。評估總的區(qū)別并進行校正，以取得自頂向下和自底向上估計的協(xié)調。,3.4 軟件項目進度管理,3.4.1制定項目計劃一. 制定項目計劃的原則,項目計劃在項目開始的時候制定，并隨著項目的進展不斷發(fā)展。 考慮的重點要放在需要更多知識的地方及如何去獲取這些知識。,二. 軟件項目計劃的要素,軟件項目計劃的要素包括目標、合理的概念設計、工作分解結構、規(guī)模估計、工作量估計和項目進度安排。,三.軟件項目計劃的邏輯要點,需求分析： 項目計劃的第一步就是把模糊的需求準確化。 項目的概念設

40、計：一般要定義工作分解結構。 資源配置和進度安排,需求足夠清晰時，應進行詳細設計，制定實現策略并納入計劃之中。 充分理解項目各部分后，確定實施細節(jié)并在下次計劃更新時形成文檔。 在整個項目周期中，項目計劃為各種資源的配置提供框架。,四.軟件項目計劃周期,五.項目計劃的內容,項目的目標 工作分解結構wbs 資源配置 進度安排,一.必要性,制定項目計劃時，項目的交付最好采用按階段交付的形式。 軟件組織最好的做法是在早期只對基本功能進行約定，其余問題的約定則推遲。 軟件功能按照其重要程度的順序進行交付，最重要的功能最先交付。,二.分階段交付的過程,三. 如何分階段,定義每一個階段的主題，然后就主題和用

41、戶進行商榷，再根據主題把軟件特征分配到各階段。,3.4.3 進度安排,一.進度安排的整體過程,項目整體進度安排的過程如下： （1） 根據項目總體進度目標，編制人員計劃 （2） 將各階段所需要的資源和可以取得的資源進行比較，確定各階段的初步進度，然后確定整個項目的初步進度。,（3） 對初步進度計劃進行評審，確保該計劃滿足要求，否則就要重復上面的步驟。一般都需要多次調整。,二.進度中的并行性,軟件開發(fā)過程中設置了若干里程碑。 當一個軟件任務成功地通過了評審并產生了相應文檔之后，就完成了一個里程碑。 軟件項目的并行性提出了一系列進度要求。,三.進度安排的方法,采用圖示方法。常用的有甘特圖和網絡圖,（

42、1） 甘特圖 甘特圖（gantt chart），又稱橫道圖，是各種任務活動與日歷表的對照圖。,每一個任務的完成不以能否繼續(xù)下一階段的任務為標準，其標準是是否交付相應的文檔和通過評審。,（2）網絡圖 用網絡分析的方法編制的進度計劃成為網絡圖。,第4章 軟件項目配置管理,4.1 配置管理概念,4.1.1 基本概念軟件項目配置管理就是作為變更控制機制而引入到軟件項目中的,相關概念 （1）軟件 配置管理中的軟件是指由邏輯和功能特性構建的信息。 （2）配置 配置由部件表和部件分解圖組成。部件分解圖定義了基線中包含的所有要素以及如何將它們安裝在一起。,（3）標識 識別產品的結構、產品的構件及其類型，為其分

43、配惟一的標識符，并以某種形式提供對它們的存取。 （4）軟件配置項 軟件配置項sci是為了配置管理的目的而作為一個單位來看待的軟件要素的集合。,軟件部件表1,軟件部件表2,軟件部件分解圖,軟件配置項,（5）版本 版本是一個基線或一個軟件配置項的特例。 （6）基線 基線是開發(fā)過程的里程碑，以一個或多個軟件配置項的交付為標準；基線由通過正式評審的軟件配置項組成，是進一步開發(fā)的基礎；基線只有通過正式的變更控制過程才能改變。,（7）控制 通過建立產品基線，控制軟件產品的發(fā)布和整個軟件生命周期中對軟件產品的修改。 （8）狀態(tài)統(tǒng)計 記錄并報告構件和修改請求的狀態(tài)，并收集關于產品構件的重要統(tǒng)計信息。,（9）審

44、核 確認產品的完整性并維護構件間的一致性，即確保是一個嚴格定義的構件集合。 （10）生產 對產品的生產進行優(yōu)化管理。 （11）過程管理 確保軟件組織的規(guī)程、方針和軟件周期得以正確貫徹執(zhí)行。,（12）小組協(xié)作 控制開發(fā)統(tǒng)一產品的多個開發(fā)人員之間的協(xié)作。 （13）配置控制委員會 配置控制委員會ccb負責評審和批準對基線的變更，通常由項目選出的代表組成。,4.1.2 軟件配置管理,1.定義 軟件配置管理是軟件項目運作的一個支撐平臺。這種支撐是貫穿項目的整個生命周期的。,scm作為支撐平臺,配置管理cm是在系統(tǒng)生命周期中對系統(tǒng)中的配置項進行標識和定義的過程。該過程是通過控制配置項的發(fā)布及后續(xù)變更、記錄

45、并報告配置項的狀態(tài)及變更請求、確保配置項的完整性和正確性來實現的。,軟件配置管理scm是應用于由軟件組成的系統(tǒng)的配置管理，通過一套工程規(guī)范，在整個軟件生命周期中跟蹤、記錄軟件，保證全部變更都記錄在案，并保證軟件的當前狀態(tài)是已知的和可重復的。,2.軟件配置管理過程 根據ieee定義,軟件配置管理過程分為四步。 （1）計劃配置管理 確定scm組織和責任，明確cm的過程、工具、技術及方法論，知道何時及如何進行。,（2）開發(fā)cm方案 定義了一個配置標識方案cis對軟件產品進行跟蹤，包括建立各個階段的cm基線、進行配置標識。cis貫穿于整個軟件生存周期中。 （3）配置控制 建立軟件配置控制委員會，對基線

46、的變更只有得到ccb的同意才能進行；對變更進行跟蹤，確保任何時候軟件配置都是已知的；在軟件生存周期的整個過程中都要清楚基線狀態(tài)的變更歷史，以便于下一步的狀態(tài)審計。,（4）狀態(tài)審計 對狀態(tài)進行報告，明確到目前為止改變的次數及最新版本等。,軟件配置管理過程,4.2 配置管理組織和職責4.2.1 cmm二級體系,軟件能力成熟度模型scmm分為5個級別:初始級、可重復級、已定義級、已管理級和優(yōu)化級。每個成熟度級別都包含若干個關鍵過程域kpa。,可重復級（二級）cmm包含6個：軟件配置管理、軟件質量保證、軟件子合同管理、軟件項目跟蹤和監(jiān)督、軟件項目策劃及需求管理。軟件配置管理作為二級cmm的一個kpa，

47、是保證軟件項目生成的產品在軟件生存周期中完整性的重要手段。,實施cmm二級體系的組織結構圖,從組織結構圖中可以看出，scm在整個體系中的位置及其與其他部分的關系。圖中各組成部分的說明見p96。,4.2.2 scm的職責,軟件配置管理的基本職責有配置經理、模塊主管、變更控制委員會。 1、配置經理 配置經理的基本職責是對代碼開發(fā)和測試進行支持和保護，是變更管理的控制中心。,配置經理具有如下職能： 制定scm規(guī)程，形成文檔并分發(fā)給有關人員 建立系統(tǒng)基線，包括備份規(guī)定 確保對基線的變更都經過授權人員的批準 確保對基線的所有變更都進行充分細致的記錄，以便可以重新生成或回退 確保所有基線變更都經過回歸測試

48、 規(guī)定解決異常問題的關注焦點,2、模塊主管 每一個模塊配備一個主管的開發(fā)人員作為模塊主管，其主要職責是： 把握模塊的設計 為參與模塊及其接口工作的人員提供建議 控制模塊的所有更改 評審模塊的變更和定期進行回歸測試，確保模塊的完整性,3、變更控制委員會ccb 軟件變更控制委員會sccb是大中型軟件項目中協(xié)調變更的集中控制機制，是對每個變更進行評審，做出相關決策的實體。 sccb是一個常設組織，項目經理指定sccb的主席，scm經理一般擔任sccb的秘書，sccb成員般由各個功能組的技術或管理代表組成，包括從事開發(fā)、文檔編寫、測試、維護、發(fā)布等方面的人員。,4.2.3 scm文件體系與過程活動,1

49、、scm文件體系 文件體系是實施scm的依據，它將標準的scm要求映射為項目實施scm所需的方針、程序和作業(yè)規(guī)范等文件,文件體系的構架,（1）方針 在金字塔頂層的方針文件中，描述了scm的目標、方法、途徑和方針的責任人。本文件一般由scm經理編制、項目經理審核、規(guī)劃經理批準。 （2）過程定義 過程定義是圖中第二層次的文件，支撐了頂層方針，是整個文件體系的核心，它將scm所有共同特性的關鍵實踐予以文件化和制度化。過程定義文件一般包括：范圍、目的、引用標準、術語和定義、過程活動描述等幾個方面，可以按照下面的八項指標描述過程活動。,目的： scm過程活動的目的。 角色及職責： 完成一個過程活動的個人

50、或小組的職責。 入口準則： 觸發(fā)一個過程活動的必要的條件。 控制： 約束或調節(jié)一個過程活動。 輸入： 一個過程活動執(zhí)行的數據。 過程活動： 采取行動把輸入轉變成預定的輸出。 輸出： 一個過程活動產生或導出的數據。 出口準則： 結束一個過程活動的必要條件。,一般由scm經理組織人員編制過程定義文件，然后由項目經理審核、規(guī)劃經理批準。,（3）規(guī)程或模板 規(guī)程或模板是第三層次的文件，支撐了上兩個層次的文件，為具體執(zhí)行活動提供作業(yè)規(guī)范或模板。 規(guī)程或模板一般包含記錄格式的表單，記錄是開展scm活動的有效工具。 規(guī)程或模板文件一般由從事這項具體工作的工作人員編制，由scm經理審核，由項目經理批準。 編制

51、scm文件體系，需要將開展過程活動的各種scm要素包含進去，包含組織結構、資源、工具等。,2、scm過程活動 scm過程包括管理scm和執(zhí)行scm兩項活動。 scm過程活動如圖所示：,4.3 配置管理功能,軟件配置管理是涉及組織和管理各種軟件產品及文檔、控制其變化的一系列活動，貫穿整個軟件生命周期。軟件配置管理有四個主要功能：配置標識、配置控制、配置狀態(tài)報告及配置審核。,4.3.1 配置標識,配置標識惟一的標識軟件配置項 1、要注意的問題 配置標識功能論述了與基線中包含的軟件配置項的標識以及基線本身的標識有關的問題?！皹俗R”用來確定如何識別產品的所有部件和由部件建造的產品基線。要考慮的關鍵點見

52、p100,2、配置標識框架 配置標識的框架如下所示： item is belongto provides roperties requires version_link contentponiter指向初版內容 end,(1)配置項名稱 配置項名稱是一字符串,為該配置項命名。 （2）文檔類別名 文檔類別名指配置項屬于哪一工程、哪類文檔。,（3）資源 資源指配置項向外供應什么、向外要求什么，實際上就是表達與其他配置項的關系、變化/版本信息。 （4）供應資源特性 供應資源特性采用非過程化的、獨立于完成語言的方式說明數據的類型、功能、接口形式及其他一些限定特征。,（5）版本鏈 版本鏈指版本的演化過程

53、。 （6）指針 指針是一個指示符，用于版本溯源。根據指針，可以找到當前版本的初始源頭。,4.2.3 配置控制,配置控制是在軟件生存周期中控制軟件產品的變更和發(fā)布,其目標是建立有助于確保軟件質量的機制。,1、版本控制 在軟件產品中開發(fā)中以及產品發(fā)布以后可靠地建立和重新創(chuàng)建版本是軟件配置管理的一個必備功能。 當軟件項目的參加人員多于是2個人時，他們的工作就存在潛在的沖突，表現見p101p102 為了支持并行開發(fā)，軟件配置管理必須具有支持分支、文件比較和合并的功能，版本控制提供了這種功能機制。,分支是使軟件配置項同時沿著兩個或多個分支展開，新版本獨立地添加到各自的分支中。文件比較用來比較兩個或多個分

54、支（或基線）中具有相同名字的文件，并識別不同的文件。合并是有選擇地將分支中對源文件所做的修改與主分支中相應的源文件對應起來或者同一分支的兩次修改對應起來的過程，分為水平合并和垂直合并兩種形式。,分支、文件比較與合并,2、變更管理 （1）模塊變更管理 對于同一軟件模塊，有時候有不同功能需求問題。此時模塊大部分代碼相同，只是為實現不同功能，代碼有局部差異。通常的做法是作為模塊的變更管理。模塊變更管理分為差異代碼管理和條件代碼管理。,（1）差異代碼管理 差異代碼管理把基本的代碼部分和差異代碼分開。對基本代碼進行維護時，只要不涉及與差異代碼的接口，補充簡要的防止誤用說明后就可以直接進行變更。同樣，也可

55、以單獨對差異代碼進行維護，但不能涉及到基本代碼部分。,差異代碼管理的缺點是： 為使差異代碼能方便的產生，基本代碼部分可能很復雜； 基本代碼與差異代碼組成的變更鏈中，一旦某個元素丟失或損壞，則重建整個鏈條將非常困難； 由于部分模塊的生命周期很長，相關的差異代碼要維持很長時間，因而差異代碼可能會逐漸變大。,實用的解決方案是，是對臨時性變更采用差異代碼管理，而對于與大量代碼無關的永久變更，可以通過將模塊分成兩個或多個部分來代理，公共元素作為一個支持所有使用的相同模塊，每個變更都通過增加獨立模塊來實現,條件代碼管理 條件代碼管理面對的問題是從幾種可供選擇的模塊中選擇一種，以實現特定功能。此時所有情況下

56、的模塊都在模塊庫中，但每次只使用一個。使用條件代碼時，只有一個模塊，差異表現在條件代碼中。,（2）基線管理 基線是軟件開發(fā)過程中的特定點，其作用是使軟件項目各個階段的劃分更加明確，使本來連續(xù)的工作在這些點上斷開，以便于檢查和肯定階段成果?；€由軟件配置項組成，是軟件配置管理的基礎。隨著軟件配置項的建立，產生了一系列基線。對這些基線必須進行管理和控制。,在初始基線建立、下一個基線產生之前，所有變更都必須記錄下來并文檔化?；€建立的時間要視具體情況而定，只要各個開發(fā)模塊相對獨立，相互關聯(lián)不多，就不需要基線。但一旦項目各模塊聯(lián)系較多，開始集成，就必須建立基線，進行正式的控制。,基線管理應具有兩個基本

57、功能。 對基線進行適當控制，禁止任何未經批準的變更。確定新基線前，必須用新基線的試行版本對每個建議的變更進行測試，通常還需要一個綜合的回歸測試規(guī)程。 基線管理的第二個功能是為程序員提供靈活的服務，確保他們能夠比較容易地對自己的代碼進行修改和測試。準備將工作結果并入基線并形成新的基線時，必須確保新的變更和其他部分兼容，確保新代碼不會導致回歸現象，即沒有丟失以前的功能。,基線管理過程,概括起來，對基線變更控制機制的需求如下： 對基線提出的變更必須經過一定層次的評審。 必須確定和理解提出的變更對經費、進度、軟件開發(fā)和生產造成的影響。 變更必須獲得相關組織的批準。 必須正確實施被批準的變更。 一旦變更

58、被批準，必須通知所有受影響的部門。,4.3.3 配置狀態(tài)報告,配置狀態(tài)報告的目的是提供軟件開發(fā)過程的歷史記錄。內容包括軟件配置項當前的狀態(tài)及何時因何故發(fā)生了變更，使相關人員了解配置狀態(tài)報告。配置狀態(tài)報告主要描配置項的狀態(tài)、變更的執(zhí)行者、變更時間和對其他工作有何影響。,配置狀態(tài)報告的結果存入數據庫中，可以查詢變更信息并對為更進行評估。 在配置狀態(tài)報告中，必要的文檔記錄是不可缺少的。其中配置項狀態(tài)報告、變更請求、變更日志、變更測試是重要的幾種記錄文檔。表4.3、表4.4、表4.5、表4.6分別給出了這些文檔的樣例。見p105106,4.3.4 配置審核,1、配置審核概念 配置審核根據需求標準或合同協(xié)議檢驗軟件產品配置，驗證每個軟件配置項的正確性、一致性、完備性、有效性、可追蹤性，以判定系統(tǒng)是否滿足需求。,確定變更是否正確有正式技術審核和軟件配置審核兩種措施。正式技術審核在軟件交付用戶前實施。正式技術審核關注已變更的配置對象的技術正確性、審核者評估軟件配置項的一致性、遺漏及潛在的副作用。軟件配置審核關注的是正式技術審核中未考慮的因素，作為技術審核的補充措施，確保軟件變更被正確地實施。 軟件配置審核關注的因素見p106,2、配置審核內容 配置審核包括兩方面的內容，即配置管理活動審核與基線審核。配置管理活動審核用于確保項目組成員的所有配置管理活動