第一篇：《軟件項目管理》期末復習知識點總結

西南交通大學軟件項目管理期末復習

第一章、第二章（略）第三章

1、軟件過程模型的特征：

原型模型：創新性項目；技術攻關；快速驗證。線性模型：一般性的軟件開發過程（可定量管理）增量模型：軟件產品。（可定量管理）

2、軟件過程的選擇依據 ? 軟件需求的確定性程度 ? 似軟件項目的開發經驗

? 軟件項目的性質（項目類型/產品類型）? 客戶的時間要求。

3、軟件管理與工程的區別

工程：專注于事，專注于過程，專注于實施 管理：專注于人，專注于結果，專注于協調

4、軟件管理要解決的問題

? 目標問題? 范圍問題? 資源問題? 組織問題? 計劃問題? 實施控制

第四章

1、管理的地位

低于決策層而高于執行層

2、管理的基本職能

領導、組織、計劃、指揮（控制）、協調

3、管理的過程

分析、計劃、實施控制、總結檢查 戴明環：計劃、執行、檢查、改進

第五章 組織+流程=業務

項目是一種旨在創造某種獨特產品或服務的臨時性努力。2 項目的內容

? 項目目標 ? 項目范圍

? 項目時間 ? 項目投入 ? 項目質量 ? 項目風險 項目管理：是通過項目經理和項目組織的努力，運用系統 理論和方法對項目及其資源進行計劃、組織、協調、控制，旨在實現項目的特定目標的管理方法體系。4 項目管理的內容

? 定義項目 ? 制定項目計劃 ? 項目組織實施 ? 項目控制 ? 項目的結束 5 項目管理的特點

? 項目管理是一項復雜的工作。? 項目管理具有創造性。? 項目管理需要集權領導和建立專門的項 目組織。? 項目負責人在項目管理中起著非常重要 的作用。6 項目管理的理解

? 項目管理是一種管理方法體系。

? 項目管理對象是項目，目的是更好地實現項目目標。? 項目管理的任務、職能：對資源進行計劃、組織與控制。

? 項目管理職能主要是由項目經理執行的。

第六章 1 項目管理的核心內容

? 項目范圍管理? 項目時間管理? 項目成本管理 2 項目的基本目標

– 技術目標（內容、質量）– 經濟目標（成本、利潤）

– 時間目標（完成時間、交付時間）3 項目目標的概括

? 項目的基本目標：在規定的時間內，在規定的經費預算內，保證項目 任務符合質量地完成。

? 項目 基本目標中，包括了范圍、時間與經費的要求。對應這三項基本 目標三大管理領域：項目范圍管理、項目時間管理、項目成本管理。

第七章項目的啟動與組織

1、立項申請。

2、組建項目組

2.1組織設計原理

? 組織設計的目的是解決勞動分工的問題。

? 組織設計的任務是提供組織結構圖和編制職務說明書。

? 組織設計要點： – 職務設計與分析 – 部門劃分 – 結構的調整與平衡

? 組織設計的原則 – 因事設職與因人設職相結合 – 權責對等的原則 – 命令統一的原則

2.2項目的組織模式

職能式、項目式、矩陣式、混合式

軟件項目組的角色 – 項目經理 – 架構設計師（總工/技術負責人）– 設計人員 – 程序員 – 配置人員 – 測試人員 2.3項目經理應具備的素質

領導能力 溝通能力 談判能力 問題解決能力 影響組織能力

3、策劃/制作任務書

項目任務書：描述、里程碑、評價標準、假設與約束條件、利益干系人

4、項目開工會

第八章 范圍管理

1、范圍管理的三大工作：項目范圍的識別、安排、控制

2、一個思維——自頂向下，逐步細化 一個分析工具——層次方框圖

3、軟件生命周期與項目生命周期的區別

4、軟件產品的結構

? 軟件產品結構是用戶需求的概覽；

? 需求分析是軟件產品范 圍核定的主要方法，由 需求規格說明書進行描述。? 需求規格書的主要內容： – 功能要求 – 性能要求 – 運行環境要求

? 需求規格決定了產品范圍

5、軟件項目的工作結構——WBS

? 軟件生命周期、項目生命 周期決定了軟件的工作結構；工作結構決定了項目 范圍。

? 項目范圍是指交付具有規定特征和功能的產品或服務所必須完成的工作。

? WBS的用途 – 項目范圍控制 – 工作任務分配 – 資源分配 – 計劃制定 – 費用估算 ? WBS分解原則：可執行、全覆蓋、80小時原則

6、項目范圍的安排：項目計劃

? 項目計劃的內容：任務安排、時間安排、資源安排

? 任務的先后順序及時間需求是項目時間、資源計劃的基礎。

? 注意可平行執行的任務與具有先后順序的任務。

第九章 時間管理

1、三大工作：項目活動的時間分析、項目時間的計劃、項目進度的控制

2、時間管理的五個主要過程

2.1活動定義

--確定為完成各種項目可交付成果所必須進行的諸項具體活動

2.2活動順序

--確定活動之間的依賴關系，并形成文檔；

2.3活動時間估算

--估算完成單項活動所需要的工作時段數；

2.4制定進度計劃

--分析活動順序、活動歷時和資源需求，編制進度 計劃；

2.5進度計劃控制

--控制項目進度計劃的變化。

3、項目活動圖

項目活動圖是項目活動及其邏輯關系（依賴關系）的圖解表示。

3.1箭頭圖 基本符號：

活動（任務），箭線表示，箭尾i表示作業開始，箭頭表示作業結束。事件，用 “○”表示，“○”是兩條或兩條以上箭線的交結點，又稱為結點。

路徑，自活動始點開始，順著箭線的方向，經過一系列連續不斷的作業和事件直至網絡終點的通道。

一條路線上各項作業的時間之和是該路線的總長度（路長）。

關鍵路徑，在一個網絡圖中有很多條路線，其中總長度最長的路線稱為“關鍵路線”，關鍵路線上的各事件為關鍵事件，關鍵時間的周期等于整個工程的總工期。

3.2前導圖

?基本符號：

? 項目任務，由矩形節點表示。? 箭頭，代表任務之間的依賴關系。? 節點的描述

? 最早開始時間（ES）? 最遲開始時間（LS）? 最早結束時間（EF）? 最遲結束時間（LF）。

浮動時間性是關于活動的機動性的術語，它是一個活動在不影響項目完成時間下可以延遲的時間量。

浮動時間的計算

PLOAT TIME=LS-ES=LF-EF ? 關鍵路徑

是決定項目歷時的一系列活動，是項目整個過程中最長的路徑。浮動時間小于或等于某指定值（通常是0）的活動來確定關鍵路徑，關健路徑上的任何活動延遲，都會導致整個項目完成時間的延遲，代表可以完成項目的最短時間量。關健活動，關健路徑上的任一個活動均是關健活動。

4、進度計劃 4.1進度計劃表 4.2進度計劃圖

5、資源分配

5.1資源是指人員、設備和材料

5.2 資源分配是向一個項目的活動指派資源 5.3資源表：將所需每種資源的多少量化。

5.4資源甘特圖：類似于甘特圖，確定一個活動所用資源的時間段。5.5 資源柱狀圖： 也稱資源負荷圖，用于表明所需資源的總數。

6、兩類不同計劃方法的項目：受資源約束的進度計劃與受時間約束的進度計劃

6.1 基于資源的方法（也稱受資源約束的進度計劃）：將可利用的資源分 配到活動，根據所識別的資源的可利用性，允許改變網絡進度計劃，歷時可能會延長。

6.2受時間約束的進度計劃：網絡進度是固定的。缺少活動所需的資源用 負的浮動時間表示，浮動時間可能會變成負值。

7、進度控制 7.1進度記載

基于網絡計劃的進度記載

1、各活動實際作業時間記載

2、各活動實際開始、結束日期記載

3、已完活動記載

4、繪制實際網絡圖

7.2計劃檢查

檢查關鍵路徑的情況；

? 檢查其它路徑的情況，查看是否有新的關鍵路徑；

7.3計劃調整 ? 調整方法

– 采取組織措施或技術措施縮短關鍵路徑上的后繼作業時間； – 重新安排活動次序，調整力量，重新編制網絡計劃。?歷時壓縮：如何縮短進度計劃

? 趕工：采取措施壓縮項目總歷時，在成本與進度間權衡，向關鍵活動增加資源，趕工經常會增加成本。

? 快速跟進：通常按順序進行的活動，如設計和施工，因為要壓縮項目進度，而將其重疊安排。快速跟進常常要重新返工，通常會增加風險。

? 趕工與快速跟進，首先均是在關鍵路徑上進行，一旦壓縮了歷時，就要重新檢查關健路徑。歷時壓縮后，可能出現新的關健路徑。

?資源利用：如何提高資源使用率或生產率

?

加班工作：增加勞動力費用，可能會降低生產率。?

倒班工作：提高設備使用率。?

學習曲線：重復的工作可以提高生產率。

第十講 成本管理

1、三大工作

項目成本分析與估算、項目成本計劃（財務預算）、項目成本控制

2、成本管理與范圍界定

項目范圍是項目成本估算的依據，項目成本估算反作用于項目范圍，如根據估算結果更改項目范圍。

3、項目成本估算過程 3.1估算依據

? WBS ? 資源需求 ? 活動工期 ? 估算資料

? 歷史信息 ? 成本會計科目 ? 已識別風險 3.2 成本估算 ? 類比估算法

以過去類似活動的參數值或規模指標為基礎，估算未來活動。

? 參數估算法

利用歷史數據（如軟件的代碼行數）之間的統計關系來估算范圍、成本，計劃工作量ⅹ歷史單位成本=活動成本

? 自下而上估算法

對工作組成部分進行估算，最后匯總得到整個工作的總投入。

? 三點估算法

?最可能的時間（Tm）、最樂觀時間(To)、最悲觀時間（Tp），按公式（To+4Tm+Tp)/6 3.3成本計劃

?成本管理計劃（財務預算）

4、財務管理工具 4.1資產負債表 4.2現金流量表 4.3利潤表 4.4會計科目

5、項目融資

股權融資+債券融資= 項目融資

6、項目成本控制

6.1項目成本控制涉及對于各種能夠引起項目成本變化因素的控制（事前控制），項目實施過程的成本控制（事中控制）和項目實際成本變動的控制（事后控制）三個方面。6.2控制依據： ? 項目成本基線；

? 項目的成本管理績效報告； ? 項目的變更請求； ? 項目成本管理計劃。

6.3項目成本控制的關鍵是項目不確定性成本的控制。項目不確定性成本控制的根本任務是識別和消除不確定性事件，從而避免不確定性成本發生。6.4項目不確定性成本的成因：

? 項目具體活動本身的不確定性（可發生或不發生）； ? 活動規模及其所耗資源數量的不確定性；

? 項目活動所耗資源價格的不確定性（價格可高可低）。

第十一章 軟件項目計劃管理

1、計劃階段任務 工作分解結構-活動排序-資源工期成本估算-進度計劃-風險溝通計劃-項目計劃

2、工作分解結構 2.1分解原則 完全窮盡，彼此獨立 2.2最底層的特征

一個清晰的任務完成，一個清晰的責任人，能夠估算工作量和工期，長度小于80小時

2.3 WBS與責任落實

3、活動排序 3.1 方法

按照客觀規律排序、按照目標要求排序、按照輕重緩急排序、按照項目內在關系。3.2技巧

利用WBS，由低到高 3.3工期

4、前導圖（PDM）資源、工期和成本估算

4.1資源類型：人員、物資、技術

4.2 考慮因素：我需要什么？什么時候需要？需要多少？由誰拍板？ 4.3 估算方法：

參照第十章3.2+專家判斷法

5、進度計劃

5.1 進度計劃：根據WBS、活動排序、工期估算和所需資源的結果進行分析，制定出項目計劃。5.2 工具 甘特圖法與關鍵路徑法（參照第九章3.1）

6、風險溝通計劃 6.1識別風險 頭腦風暴法 6.2評估風險等級

用高、中、低評價考慮發生的可能性、對項目產生的影響。6.3制定風險響應計劃 規避、轉移、減輕、接受 6.4溝通計劃

“四個適當”—適當時間將適當信息通過適當的渠道發送給適當的利益干系人。溝通原則：及時準確，信息量恰到好處

7、項目計劃 7.1關鍵點：

明確項目范圍、全面的風險識別、各關鍵干系人的識別和溝通計劃 7.2常見問題： 對任務的分解不充分

風險防范意識不強和沒有溝通計劃 計劃通常由個人制定，沒有達到團隊共識

第十二章 質量管理1、2、三個過程：質量計劃編制-質量保證-質量控制 PDCA循環（By戴明）

計劃(Plan)→實施(Do)→檢查(Chick)→行動(Act)→計劃(Plan)

3、質量計劃編制

3.1 輸入：關于質量的組織政策、特定的項目范圍 說明書、產品描述、相關標準和準則。

3.2 輸出：質量管理計劃和為確保整個項目生命周期質量的各種檢查表 3.3 IT項目中影響質量的范圍部分包括

– 功能性 – 特色 – 系統輸出 – 性能 – 可靠性 – 可維護性

4、質量保證

4.1 質量保證包括與滿足一個項目相關的質量標準有關的所有資源與活動。4.2 工具

? 實驗設計：也可以用來幫助保證和提高產品質量

? 基準比較分析法：是用于質量改進的技術，它是將具體項目時間或產品特性與那些在項目執行組織內部或外部的其他項目或產品的相應特性進行比較，從而產生質量改進的思想。

? 質量審計：是對特定質量管理活動的結構化審查，找出教訓，改進現在或將來項目的執行。

5、質量控制

5.1質量控制：指監視項目的具體結果，確定其是否符合相關 的質量標準，并判斷如何杜絕造成不合格結果的根源。質量控制應貫穿于項目的始終。5.2輸入：接受決策、返工和過程調整。

– 接受決策：作為項目一部分而生產的產品或服務是否被接受或拒 絕。– 返工：指采取行動，是拒收事項達到和滿足產品需求或規范或干 系人的其他期望。返工非常昂貴，要盡量避免。– 過程調整：是指在質量控制度量的基礎上，糾正或防止進一步質 量問題的發生。

5.3 質量控制工具 5.3.1帕累托圖：

5.3.2 6σ標準：

標準差在質量控制上很重要，因為它是一個決 定有缺陷個體的可接收數據的關鍵因素。6σ很常用。

5.3.3 測試

– 單元測試 – 綜合測試 – 系統測試 – 用戶驗收測試

6、CMM/CMMI 6.1 CMM:軟件能力成熟度模型

CMMI:綜合能力成熟度模型 6.2基本原理

CMM強調連續的軟件過程改進。該連續的改進基于多個演化步驟。CMM將這些演化步驟劃分成五個級別。這種分級結構的理論依據是軟件質量原理。每一級別都包括若干目標。當滿足某一目標后，軟件過程的相應部分便確定下來。五級成熟度定義了一個標準，用以度量機構的軟件過程成熟度和評價其軟件過程能力。

6.3基本內容

? 機構和資源的管理：涉及機構本身的責任，人員和其它資源設施。

? 軟件工程過程及其管理：涉及軟件工程過 程，即軟件過程的深度、范圍和完整性以 及如何度量、管理和改進這樣的過程。

? 工具和技術：軟件工程過程中使用的開發 工具和技術。

6.4CMM的五個成熟度級別

? 初始級 : 混沌

? 可重復級：有規章、經過訓練的過程

? 定義級：標準化、一致的過程

? 管理級：可預測過程

? 優化級：可持續改進的過程 6.5關鍵實施KP ? 關鍵過程域KPA(Key Process Areas)

一組相關聯的活動；通過執行這些活動可以實現既定的過程能力。

? 關鍵實施KP（Key Practices）

使關鍵過程域得以有效實現和制度化的最大的基礎設施和活動。

除第一級外，SW-CMM的每一級都是按完全相同的結構組 成的。每一級包含了實現這一級目標的若干關鍵過程域(KPA)，每個KPA進一步包含若干關鍵實施活動(KP)，無論 哪個KPA，它們的實施活動都統一按五個公共屬性進行組織。

1、目標

每一個KPA都確定了一組目標，若這組目標在每一個項目都能實現，則 說明企業滿足了該KPA的要求。若滿足了一個級別的所有KPA要求，則表明達到了這個級別 所要求的能力。

2、實施能力

實施能力一般包括資源保證、人員培訓等內容。它是企業實施KPA的前提條件。企業必須采取措施，在滿足了這些條件后，才有可能執行KPA的活動。

3、執行活動

執行過程描述了執行KPA所需求的必要角色和步驟，一般包括計劃、執行的任務、任務執行的跟蹤等。在五個公共屬性中，執行活動是唯一與項目執行相關的屬性，其余四個屬性則涉及企業CMM能力基礎設施的建立。

4、度量分析

描述了過程的度量和度量分析要求。典型的度量和度量分析的要求是確定執行活動的狀態和執行活動的有效性。

5、實施驗證

驗證執行活動是否與建立的過程一致。實施驗證涉及到管理的評審和審計以及質量保證活動

6.6 五個公共屬性

第十三章 軟件項目的實施、監控與收尾

1、實施、監控階段任務 溝通--項目監控--變更管理

2、溝通 2.1組內溝通

溝通需求：職責、授權、協調、狀態。

會議：項目開工會、成員進度匯報、項目進展回（及時公開恰到好處）2.2 與高層、客戶溝通

誰？為什么需要信息？需要什么樣的信息？何種詳盡程度？頻度如何？你的目標？什么樣的方法？ 2.3 項目溝通要點

全體成員達成共識、溝通項目計劃、規則，互相尊重，主動傾聽，雙贏。

3、項目監控 3.1 監控要點--高風險的任務

--與項目里程碑有關的進展--使用的資源和費用--人員的表現 3.2監控的方法和工具

項目進度計劃表、會議、觀察檢查、跟蹤行動計劃、定期反饋及報告

4、變更管理 4.1變更源頭

委托人：新的想法和欲望 團隊：沖突

優先級：市場、其他項目影響 其他：法規、環境、企業變革等

4.2變更過程

提交變更申請-申請影響分析-評審分析結果-批準-實施變更，跟蹤及發布動態

5、項目收尾 5.1評估與驗收

財務、時間、質量、人力資源、環境、項目計劃、項目控制 5.2 項目總結 5.3文件歸檔

第十四講

企業人才類型與素質結構

高級技術人才：預備程序員-初級程序員-中級程序員-高級程序員-設計員-分析員-架構師 高級管理人才：預備程序員-配置經理-SQA經理-產品經理-研發部經理

高級綜合人才：預備程序員-項目組長-項目負責人-項目經理-項目總監-技術總監

第二篇：軟件測試期末復習知識點總結

1.軟件測試：是由“驗證（verrificatione）”和“有效性確認（validation）”活動構成的整體： “驗證”是檢驗軟件是否已正確地實現了產品規格書所定義的系統功能和特性。驗證過程提供證據表明軟件相關產品與所有生命周期活動的要求（如正確性、完整性、一致性、準確性等）相一致。相當于以軟件產品設計規格說明書為標準進行軟件測試的活動。

“有效性確認”是確認所開發的軟件是否滿足用戶真正需求的活動。一切從客戶出發，理解客戶的需求，對軟件需求定義、設計的懷疑，發現需求定義和產品設計中的問題。這主要通過各種軟件評審活動來實現，包括讓客戶參加評審、測試活動。

軟件測試過程：（1）測試組織和管理（2）測試計劃（3）測試用例實際（4）測試實施（5）測試結果分析（6）測試評審與報告 軟件測試方法：白盒測試方法、黑盒測試方法、靜態測試與動態測試、主動測試與被動測試、形式化測試方法、基于風險的測試、模糊測試方法、ALAC測試和隨機測試方法

2.單元測試：是對軟件基本組成單元進行的測試，而且軟件單元是在與程序的其他部分相隔離的情況下進行獨立的測試。

靜態測試就是靜態分析，對模塊的源代碼進行研讀，查找錯誤或收集一些度量數據，并不需要對代碼進行編譯和仿真運行。

動態測試是通過真正運行程序發現錯誤，通過觀察代碼運行過程，來獲取系統行為、變量實時結果、內存、堆棧、線程以及測試覆蓋度等各方面的信息，來判斷系統是否存在問題，或者通過有效的測試用例，對于的輸入輸出關系來分析被測程序的運行情況，來發現缺陷。靜態測試、動態測試的區別：1.靜態測試用于預防，動態測試用于矯正；2.多次的靜態測試比動態測試的效率高；3，靜態測試綜合測試程序代碼；4.在相當短的時間里，測試的覆蓋率能達到100%，而動態測試經常只能達到50%測試左右；5.動態測試比靜態測試更花時間； 6.靜態測試比動態測試更能發現bug；7.靜態測試的執行可以在程序編碼編譯前，動態是中能在編譯后才能執行。

3.功能測試：一般須在完成集成測試后進行，而且是針對應用系統進行測試是根據產品規格說明書，來檢驗被測試的系統是否滿足各方面功能的使用要求。

集成測試：也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模塊按照設計要求，組裝成為子系統或系統，進行集成測試，其主要目的是檢查軟件單位之間的接口是否正確。集成測試包括非增量測試和增量測試兩種方式，集成測試的策略主要有自頂向下和自底向上兩種。

功能測試、集成測試區別：

4.回歸測試：目的是在程序有修改的情況下，保證原有功能正常的一種測試策略和方法。程序在發現嚴重軟件缺陷要進行修改或版本升級要新增功能，這時需要對軟件進行修改，修改后的程序要進行測試，這時要檢驗軟件所進行的修改是否正確，保證改動不會帶來新的嚴重錯誤。

5.樁程序（Stub），也稱樁模塊：用以模擬被測模塊工作過程中所調用的下層模塊。樁模塊由被測模塊調用，它們一般只進行很少的數據處理,例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口。驅動程序（Driver），也稱驅動模塊：用以模擬被測模塊的上級模塊，能夠調用被測模塊。在測試過程中，驅動模塊接受測試數據，調用被測模塊并把相關的數據傳送給被測模塊。

軟件缺陷：軟件缺陷是指計算機系統或者程序中存在的任何一種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷、瑕疵，其結果會導致軟件產品在某種程度上不能滿足用戶的需求。標準定義，從產品內部看，軟件缺陷是軟件產品開發或維護過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統所需要實現的某種功能的失效或違背。

軟件測試步驟： 即單元測試、集成測試、確認測試和系統測試。

1.開始是單元測試，集中對用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。2.集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。3.確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。4.系統測試把已經經過確認的軟件納入實際運行環境中，與其它系統成份組合在一起進行測試。

軟件測試流程：需求分析和定義、系統設計、詳細功能設計、編碼、單元測試、功能測試、系統測試、驗收測試

軟件測試涉及的關鍵問題：1.測試過程和開發過程是同時開始，同時結束的，兩者保持同步的關系；2.測試過程是對開發過程中階段性成果和最終產品進行驗證的過程，所以兩者相互依賴；3.測試過程中的工作重點和開發工作的重點可能不一樣，兩者有各自的特點

黑盒測試的特點：1.不基于對系統內部的設計和實現。2.用例設計基于功能的定義和需求說明書。3.關注于測試數據的選擇和測試結果的分析。

測試方法有：等價類劃分、邊界值分析法、判定表方法、因果圖法、正交實驗法、功能圖法、錯誤推測法

黑盒測試缺點：1.對用例設計人員的經驗要求較高，包括數據的選擇，對潛在錯誤的敏感性；2.對于內部實現的bug不容易發現；3.不能提供直觀的測試覆蓋率。

白盒測試的特點：1.需要了解系統的整體設計和實現；2.對源代碼進行審查；3.在單元測試階段發現大量的缺陷；4.關注于系統的控制流和數據流；

測試方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、路徑覆蓋、基本路徑測試法

白盒測試缺點：1.不能確保系統是否完全符合需求說明書；2.白盒測試的代價會大于黑盒測試；3.需要源代碼首先完成才能進行測試；

集成測試中自頂向下和自底向上方法

自頂向下法：從主控模塊（主程序）開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊結合起來。具體步驟是：1.對主控模塊進行測試，測試時用樁程序代替所有直接附屬于主控模塊的模塊；2.根據選定的結合策略，每次用一個實際模塊代替一個樁程序；3.在結合下一個模塊的同時進行測試；4.為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試。優點：不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統的主要功能，而且能在早期發現上層模塊的接口錯誤。缺點：需要樁程序，可能遇到與此相聯系的測試困難，低層關鍵模塊中的錯誤發現較晚，而且用這種方法在早期不能充分展開人力

自底向上法：從“原子”模塊（即在軟件結構最底層的模塊）開始集成以進行測試，具體策略是：1.把底層模塊組合成實現某個特定的軟件子功能的族；2.寫一個驅動程序，協調測試數據的輸入輸出；3.對由模塊組成的子功能族進行測試；4.去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能族。優缺點：剛好和自頂向上相反

簡述增量式集成測試的自頂向下和自底向上兩種測試方法：自頂向下增量式測試的主要優點在于它可以自然地做到逐步求精，一開始便能讓測試者看到系統的框架。它的主要缺點是

需要提供被調用模擬子模塊，被調用模擬子模塊可能不能反映真實情況，因此測試有可能不充分。自底向上測試的優點在于，由于驅動模塊模擬了所有調用參數，即使數據流并未構成有向的非環狀圖，生成測試數據也沒有困難。它的缺點在于，直到最后一個模塊被加入進去之后才能看到整個程序（系統）的框架

集成測試自底向上和自頂向下集成方法優缺點是什么？

自底向上集成方法盡早的對底層實用歷程進行測試，可以避免編寫眾多的樁模塊，使得系統底層的眾多問題及早得到解決。缺點是在一些頂層構件非常重要的情況下，卻將其放到了最后集成。

自頂向下集成方法則盡早進行了頂層控制模塊的測試和集成，使得系統整體上得到驗證，但卻將底層實用歷程的測試放到了最后。某些具有關鍵性能或作用的底層模塊的問題將在最后才可能被發現。

簡述系統測試過程的主要步驟及每個步驟的測試依據。

功能測試：測試依據是系統功能需求；

性能測試：測試依據是其他軟件需求；

驗收測試：測試依據是客戶需求規格說明書；

安裝測試：測試依據是用戶環境

第三篇：軟件項目管理知識點總結

第一章概述

1項目是指在一定約束條件下具有特定目標的一項一次性任務。

2.項目的特點

一次性；有確定的起點和終點

目標明確性：成果性目標，約束性目標；

整體性：開展的活動密切相關

獨特性：每個項目都是唯一的不可逆轉性：無論結果如何，項目結束，結果確定。

3.項目的生命周期：項目啟動、項目計劃、項目實施、項目結束。

4.項目管理的要素：客戶滿意度、工作范圍、組織、時間、質量、成本

TQC：時間質量成本成功因素：TQC+范圍

5軟件項目管理的定義

根據PMI項目管理的定義總結：在軟件項目活動中運用一系列的知識、技能、工具和技術，以滿足軟件需求方的整體要求。

6.項目管理特點：綜合性、創造性、時間性第二章軟件項目需求管理

1軟件需求的抽象層次：原始問題空間（原始問題描述、用戶需求）；解決方案空間（系統需求、軟件設計描述）

2軟件需求：用戶需求和系統需求：

①用戶需求：從用戶角度描述系統的需求，只描述系統的外部行為，并且只通過自然語言、圖表、圖形等敘述

②系統需求：從開發人員角度描述系統的需求，是系統實現的依據，通常采用結構化語言、PDL過程設計語言等描述。

系統需求：功能需求、非功能需求、領域需求

3、需求工程的組成：需求開發和需求管理

需求開發：需求的獲取、需求分析、規格說明和需求驗證

需求管理：變更管理、版本控制、需求跟蹤和版本狀態

4需求管理的必要性

①需求供求雙方固有的矛盾

②需求具有易變性和難以表達性

③需求錯誤出現的高頻性和修復的高昂成本

5需求管理的目標：是在客戶與項目組織之間建立對客戶需求的共同理解。

①使軟件需求受控，并建立供軟件工程和管理使用的需求基線；

②使軟件計劃、產品和活動與軟件需求保持一致。

6、需求變更的原因

①在項目的早期所有的問題不可能完全定義；

②隨著軟件項目的進行，開發人員對問題的理解發生變化，這些變化反饋到需求中；

③大型系統的需求可能是沖突或是矛盾的，系統需求是它們之間的妥協，這種妥協可能發生變化；④系統購買者和最終用戶很少是同一人；

7、需求變更管理過程

首先要建立變更控制委員會，分析、討論、評審、執行。

第三章軟件項目的成本管理

1軟件項目的成本：為完成軟件項目而支付的貨幣量

2軟件項目的時間估算點：客戶需求產品定義系統設計系統實現系統運行

3對軟件規模的估計要從軟件的分解開始。軟件的分層結構對應工作分解結構（WBS）4軟件規模的度量標準：LOC代碼行和FP功能點

5成本估算方法：專家判定、類比、自頂向下、自底向上、算法模型（cocom(自底向上)、cocomoⅡ、putnam（自頂向下））

6、三層次的產品分級結構：模塊、子系統、系統

7、估算的時機和精度是相互矛盾的。第四章軟件配置管理

1軟件項目配置管理：是識別定義系統中的配置項，在軟件生命周期中控制他們的變更，記錄并報告配置項和變更請求的狀態，并驗證他們的完整性和正確性的一個過程。2軟件配置項：SCI出于配置管理的目的而為軟件要素設置的單位。

3基線：開發過程的里程碑，以一個或多個軟件配置項的交付為標準；基線由通過正式評審的軟件配置項組成，是進一步開發的基礎；基線只有通過正式的變更控制過程才能改變。4基線的兩個基本功能：①對基線進行適當控制，禁止任何來源的交互②為程序員提供靈活的服務，確保他們能夠比較容易地對自己的代碼進行修改測試

5軟件配置管理主要功能：配置標識、配置控制、配置狀態報告及配置審核

6配置控制委員會：CCB 負責評審和批準對基線的變更

7軟件的配置項組成：正確性、一致性、完備性、有效性、可追蹤性。

8確定變更是否正確的措施:正式技術審核和軟件配置審核.9配置審核的種類：過程審核、功能審核、物理審核、質量系統審核

第五章人力資源管理

1、軟件項目中的人力資源管理包括：所有的項目干系人：資助者、客戶、項目組成員、支持人員及供應商等。

人力資源管理就是有效地發揮每個項目干系人作用的過程。

2軟件開發中人員與時間具有非線性替換關系。第六章質量管理

1軟件質量六大特性：功能性、可靠性、可用性、效率、可維護性、可移植性

2、過程質量控制是主動的、系統的、先期的；

產品質量控制是被動的、個體的、后期的；兩者都要重視。

3.CMM的5個等級：初始級、可重復級、已定義級、已管理級、優化級

4.CMMI的兩種表示方式：連續性表示和分階表示

5軟件過程能力等級（連續性表示法）：不完備級、已執行級、收管理級、已定義級、定量管理

級、持續優化級。

第七章風險管理

1.風險的定義：損失的可能性

2.風險的屬性：可能性損失

3軟件風險：就是有關軟件項目風險、軟件開發過程風險和軟件產品風險。

4.風險管理過程：風險識別、風險分析、風險計劃、風險跟蹤、風險應對（風險最小化，機會最大化）

5.風險應對策略包括：避免、轉移、緩解、接受、研究、儲備以及退避。

6軟件項目管理的主要風險類別：①資源風險②需求風險③項目接口風險④設計風險⑤管理風險⑥開發過程風險⑦項目集成風險。

第四篇：軟件項目管理知識點總結

中原工學員信息商務學院

P1項目的特征：1.目標性2.相關性3.周期性4.獨特性5.約束性6.不確定性

P2 軟件項目是一種特殊的項目，他創造的唯一產品或者服務是邏輯載體，沒有具體的形狀和尺寸，只有邏輯的規模和運行的效果。P3 軟件項目要素組成：軟件開發的過程、軟件開發的結果、軟件開發賴以生存的資源以及軟件客戶。項目目標成功實現的制約因素：項目范圍、成本、進度計劃、客戶滿意度。項目管理分為：戰略管理、運作管理、項目管理。

P4 項目管理定義：是指一定的主體，為了實現其目標，利用各種有效的手段，對執行中的項目周期的各階段工作進行計劃、組織、協調、指揮、控制，已取得良好經濟效益的各項活動的總和。

P5 軟件項目管理和其他管理相比有相當的特殊性：1.軟件是純知識產品，其開發進度和質量很難估計和度量，生產效率也難以保證。2.項目周期長，復雜度高，變數多。3.軟件需要滿足一群人的期望。

P6 軟件項目管理的根本目的是為了讓軟件項目尤其是大型軟件項目的整個軟件生命周期都能在管理者的控制之下，已預定成本按期、按質的完成軟件并交付用戶使用。

項目管理的五要素：技術、方法、團隊建設、信息、溝通。P7 軟件項目管理的四大變量：范圍、質量、成本、交期。

P24 投標文件有兩種：1.建議書（乙方根據甲方提出的產品的性質、目標、功能等，提交的完整的技術方案和報價）2.報價單（乙方根據甲方提出的產品的特定型號、標準、數量等要求提交必要的報價材料等）P26 項目經理的職責：1.開發計劃2.組織實施3.項目控制

項目經理的權利：1.制定項目有關決策2.挑選項目成員的權利3.對項目獲得的資源進行再分配。（其中 職責>權利）P27 生存期模型：V模型、瀑布模型、原型模型、增量模型、螺旋模型，漸進式階段模型等。

瀑布模型優點：適用于項目簡單，規模小，要求項目所有的活動都嚴格按照順序執行，一個階段的輸出時下一階段的輸入。V模型：強調測試的重要性，它將開發活動與測試活動緊密地聯系在一起。（及時發現錯誤）原型模型：設計符合客戶需求的頁面，達成共識再編程。

增量模型：可以避免一次投資太多帶來的風險，將主要的功能或風險大的功能首先實現，然后逐步完善。（適用于開始時，明確了大部分的需求，但是需求可能會發生變化的項目）

螺旋式模型：是針對風險比較大的項目設計的模型，應對變化的靈活性上很有優勢。

P44 軟件需求：指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達到什么樣的性能。P45 軟件需求包括三個層次：1.業務需求2.用戶需求3.功能需求

P47 進行需求獲取的時候應該注意什么問題：1.識別真正的客戶2.正確理解客戶的需求3.具備較強的忍耐力和清晰的思維4.說服和教育客戶5.需求獲取階段建立分析小組，進行交流，相互學習。

P48 需求分析完成的標志是提交一份完整的軟件需求規格說明書。P53 需求管理主要的工作如下：（自己看）

P53 項目管理的第一法則是：“做正確的事，其次是正確的做事。” P54 解決復雜問題不二法門：化繁為簡，分而治之。

P57 任務分解的方法：類比、自頂向下（采用演繹推理法，從一般到特殊的方向進行）、自底向上（采用發揮創造力的解決問題的方法，從特殊到一般的方向進行）等。

P59 如果對項目人員來說，這個項目是一個嶄新的項目，采用自底向上的方法。

P67 項目進度計劃的主要過程：首先根據任務分解的結果（WBS）再進一步分解出主要的任務，確立任務之間的關聯關系，然后估算出每個任務需要的資源、歷時，最后編制出項目的進度計劃。

P66 任務關聯關系：開始->結束；開始->開始；結束->結束；結束->開始。

任務關聯關系的依據：1.強制性依賴關系（因為客觀規律和物質條件的限制造成的）2.軟邏輯關系（是認為主觀的，自己的偏好進行的）3.外部依賴關系（是項目活動與非項目活動之間的依賴關系，例如：環境測試依賴于外部提供的環境設備）

P67 進度管理圖示1.甘特圖2.網絡圖（PDM（優先圖或節點法）ADM箭線法 CDM（條件箭線圖，很少用））3.里程碑圖4.資源圖

P80 資源平衡方法是通過調整任務的時間來協調資源的沖突，這個方法的主要目的是形成平穩連續的資源需求，最有效的利用資源，使資源閑置時間最小化，同時，盡量避免超出資源能力。

P97 自下而上估算法是利用任務分解圖，對各個具體工作包進行詳細的成本估算，然后將結果累加起來得出項目總成本。

計科122班

P98 參數模型估算法的進本思想是：找到軟件工作量的各種成本影響因子，并判定它對工作量所產生影響的程度是可加的、乘數的還是指數的，以期望得到最佳的模型算法表達式。當某個因子只影響系統的局部時，我們一般說它是可加的；當某個因子對整個系統具有全局性的影響時，我們則說它是乘數的或指數的。

P112 國際ISO定義：質量是產品或者服務滿足明確和隱含需要能力的性能特性的總體。P112 一個項目的主要內容是成本、進度、質量。

P116 質量控制是確定項目結果與質量標準是否相符，同時確定消除不符的原因和方法，控制產品的質量，及時糾正缺陷的過程。質量控制是對階段性的成果進行檢測、驗證，為質量保證提供參考依據；軟件質量控制主要就是發現和消除軟件產品的缺陷。

P117 質量成本包括預防成本和缺項成本。（其中，預防成本>缺陷成本）預防成本是為確保項目質量而進行預防工作所耗費的費用。缺陷成本是為確保項目質量而修復缺項工作所耗費的費用。

P127 團隊成員包括：企業內部的人、供應商、承包商、客戶等。

項目管理中的組織結構可以總結為三種類型：職能型、項目型、矩陣型。矩陣型溝通最復雜，項目型在項目收尾時，團隊成員和項目經理壓力比較大。

P135 溝通管理的基本原則是：及時性、準確性、完整性、可理解性。

P141 風險定義：軟件風險是指軟件開發過程中及軟件產品自身可能造成的傷害或者損失。

P142 風險的類型：商業風險、管理風險、人員風險、技術風險、開發環境風險、客戶風險、過程風險、產品規模風險等。P143 風險的基本性質：客觀性、不確定性、不利性、可變性、相對性、風險和利益相對性。

P145 風險識別是試圖系統化地確定對項目計劃的威脅，識別已知和可預測的風險，只有識別出這些風險，項目管理者才有可能避免這些風險，且當必要時控制這些風險。

風險識別的方法：德爾菲方法、頭腦風暴法、情景分析法、風險條目檢查表。

P152 定性風險評估：只要是針對風險概率及后果進行定性的評價。（歷史資料法、概率分布法、風險后果估計法）

P153 定量風險分析：是在定性分析的了邏輯基礎上，給出各個風險源的風險量化指標及其發生概率，再通一定的方法合成，得到系統風險的量化值。（訪談、盈虧平衡分析法、敏感性分析、決策樹分析、模擬法等）

P156 風險應對計劃：回避風險（是通過分析找出發生風險事件的原因，對可能發生的風險盡可能的規避，采取主動放棄或拒絕使用導致風險的方案）、轉移風險、損失控制（損失預防、損失抑制、）、自留風險、風險規劃的結果。P161 風險管理過程包括：風險識別、風險評估、風險規劃、風險控制等。

P166 軟件外包：其實質是軟件開發過程從企業內部部分或全部延伸到外部的管理規范與管理技術。

P173 基線是一個或者多個配置項的集合，他們的內容和狀態已經通過技術的復審，并在生存期的某一階段被接受了。基線配置項可能包括所有的設計文檔和源程序等；非基線配置項可能包括項目的各類計劃和報告等。

P180 配置審計的只要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現。P185 配置管理包括三個只要的要素：人、規范、工具。

P194 項目集成計劃定義是指，通過使用其他專項計劃過程所生成的結果（項目的各種專項計劃），運用整體和綜合平衡的方法制定出的，用于指導項目實施和管理的整體性、綜合性、全局性、協調統一的整體計劃文件。

集成計劃的編寫過程：1.項目信息收集2.確定項目計劃初步方案3.項目計劃的綜合平衡4.項目計劃最終方案編制5.軟件項目計劃評審、批準。P207 變更控制的目的就是為了防止配置項被隨意修改而導致混亂。

P214 掙值分析也稱以獲取價值分析，是對項目實施的進度、成本狀態進行績效評估的有效方法，是計算實際花在一個項目上的工作量，以及預預 P223 代碼走查是在代碼編寫階段，開發人員檢查自己代碼的過程，代碼走查是非常有效的方法，它可以檢查到其他測試方法無法檢測的錯誤，好多的邏輯錯誤是無法通過測試手段發現的，很多的項目證明這是一個很好地質量控制方法。P226 質量度量方法：1.尺度度量（定量度量，直接度量）2.二元度量（定性度量，間接度量）P230 項目成員的激勵：薪酬激勵、機會激勵、環境激勵、情感激勵 P233 團隊的建設包括：組建階段、磨合階段、規范階段、執行階段。

P235 團隊管理過程中已改主意的方面：1.創建有實際存在感的項目團隊2.建立獎勵機制3.確立良好人際關系4.設置工作授權系統 P236 按照評審的時間屬性，可以將項目評審分為：定期評審、階段評審、事件評審等。

P260 項目管理的經驗和建議1.平衡關系2.高效原則3.分解原則4.實時控制原則5.分類管理原則6.簡單有效原則7.規模管理原則

第五篇：《軟件系統分析與設計》期末復習知識點總結

一、方法論模型。

1、BOOCH、OMT、OOSE、Coad-Yourdon（前三者組成UML）

2、UML包括9種圖，分別為用例圖、靜態圖（包圖、類圖、對象圖）、實現圖（構件圖、部署圖）、行為圖（活動圖、狀態圖、交互圖(順序圖、協作圖)）基本規范，泛化關聯，包含關聯，擴展關聯

3、基本模型——類圖、需求模型——用例圖、輔助模型——其他各種圖

4、兩大工具：Rose、PowerDesigner

5、方法三要素：模型、工具和過程

6、結構化分析三視圖模型E-R、DFD、STD

7、OMT方法的三大模型：對象模型、功能模型、動態模型

8、Coad/Yourdon方法的五大層次：對象-類、結構、主題、屬性、服務

二、基本建模（類圖與對象圖）

1、類之間的關系：關聯關系、依賴關系、泛化關系。

2、抽象類與接口：抽象類有些方法可以提供實現代碼，接口所有的方法都沒有提供實現代碼。抽象類只能被繼承，接口只能被實現。

3、類的版型：實體類（數據庫、文件等）、邊界類（如窗體、對話框）、控制類（協調交互）

三、需求建模（用例圖）

1、參與者指系統以外的、需要使用系統或與系統交互的外部實體。可以分為：人、外部設備、外部系統。

2、參與者之間的關系：泛化關系，參與者與用例之間的關系：關聯關系。用例之間的關系：泛化關系，包含關系，擴展關系。包含關系和擴展關系都是依賴關系的特例。

3、用例是對一個參與者使用系統的一項功能時所進行的交互過程的一個文字描述序列。是參與者可以感受到的系統服務或功能單元。

4、用例描述是一個關于參與者與系統如何交互的規范說明（包含用例用例名稱、用例描述、基本事件流、參與者、前置后置條件等）

5、用例的進一步描述：活動圖、順序圖（通信圖）

四、行為建模（狀態圖與活動圖）

1、行為模型包括：狀態模型（狀態圖，單對象）、活動模型（活動圖，多對象）、交互模型（順序圖，多對象）。

2、調用事件表示的是對操作的調用，變化事件一個布爾表達式變量的值發生變化。時間事件滿足某一時間表達式的情況的出現。信號事件就是由一個對象異步地發送、并由另一個對象（即狀態圖所對應的對象）接收的已命名的實體。調用事件狀態圖內對象和外部對象都能發起，信號事件只能由外部發起。

3、對象處于不同的狀態，導致后續要執行不同的操作。這些操作可能歸屬于不同的用例。一個用例的執行對應一個順序圖。順序圖刻畫了多個對象之間的消息發送關系。需要多個用例的順序圖，來融合地描述一個對象的完整狀態圖。

4、活動表示的是某流程中的任務的執行，它可以表示某算法過程中語句的執行。

5、分叉表示的是一個控制流被兩個或多個控制流代替，經過分叉后，這些控制流是并發進行的。匯合正好與分叉相反，表示兩個或多個控制流被一個控制流代替。

6、泳道（swimlane）是活動圖中的區域劃分，根據每個活動的職責對所有活動進行劃分，每個泳道代表一個責任區。關心的是其所代表的職責。

7、活動圖用途：對業務過程進行建模。對某個方法具體過程建模。

8、狀態與活動的區別：狀態是一個對象所處的境況。通常是執行了一個（或多個）活動后的結局。活動是一段程序代碼的執行，對應于若干個步驟的集成。不同的狀態會導致不同的功能（對應于若干個活動）的執行。一個方法可能需要多個（也可以是一個）活動來完成。一個活動只能屬于一個方法。一個用例對應于若干個活動。

五、交互建模（順序圖和協作圖）

1、靜態結構使用類圖，動態結構使用順序圖、協作圖、狀態圖、活動圖。

2、對象：同類圖中的對象，是類的實例

生命線：從對象圖標向下延伸的一條虛線，表示對象存在的生命期 控制焦點（激活期）：對象執行一個動作的時間段 消息：對象間的一次通信

調用消息的發送者把控制傳遞給消息的接收者，然后停止活動，等待消息接收者放棄或返回控制。調用消息可以用來表示同步的意義。

3、順序圖一般對應一個用例。一個類中的職責對應該對象執行一個動作。

4、對象：同類圖中的對象，是類的實例 ；鏈：對象之間的連接關系；消息：對象間的一次通信；對象生命周期：對象名稱之后標以{new}約束表示創建對象，標以{destroy}約束表示銷毀對象

5、協作圖的建模同順序圖的建模，或者：可以從順序圖直接變換過來，或者：根據類圖，畫出對應的對象圖。在鏈上附著消息。

6、順序圖和協作圖的聯系：都用于描述系統中對象之間的交互協作完成一項功能，彼此可以相互轉換。區別：順序圖強調的是消息的時間順序；協作圖強調的是對象的空間位置關系。順序圖中有對象生命線和控制焦點；協作圖中有路徑，消息必須要有消息順序號。順序圖可以表示生命線的分叉；協作圖可以表示多對象、主動對象。