軟件過程與管理_期末複習知識點回顧總結

• 2022 年 5 月 23 日
• 筆記
• 乾貨, 軟件工程, 軟件工程 大三回顧總結

軟件過程與管理知識回顧

兩個大題：

1.關鍵路徑 15

2.掙值分析 15

一、概論

1. 軟件工程的三要素。（每一個的含義）

三要素是方法、工具、過程。

方法：是完成軟件開發的各項任務的技術方法，為軟件開發提供「如何做」的技術。

工具：為運用方法而提供的自動的或半自動的軟件工程的支撐環境。

過程：是為了獲得高質量的軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟，如何將軟件工程方法與軟件工具相結合，合理、及時地進行軟件開發。

2. 軟件過程的定義。

軟件過程是用於軟件開發及維護的一系列活動、方法及實踐。

3. 常見的軟件過程分類（五大類）。常見的軟件過程。

ISO/IEC 15504軟件過程分類（5大類）：客戶-供應商過程，工程過程，支持過程，管理過程，組織過程。

軟件過程模型：瀑布、快速原型、增量、螺旋、形式化方法、基於組件的開發模型

二、軟件質量管理

1. 軟件質量的定義。

軟件質量是軟件產品滿足明確或隱含需要能力的性能和特性的總體。

ISO是一個組織的英語簡稱。其全稱是International Organization for Standardization，翻譯成中文就是「國際化標準組織」。成立於1947年2月23日。ISO負責除電工、電子領域和軍工、石油、船舶製造之外的很多重要領域的標準化活動。

IEC 是國際電工委員會標準（International Electro technical
Commission)的簡稱,IEC負責有關電工、電子領域的國際標準化工作.

2. ISO/IEC 9126的結構、六個一級質量特性（名稱）、一級特性對應的二級特性（選擇題）。

1991年ISO/IEC 9126中，軟件質量度量模型由三層組成：軟件質量特性（即一級質量特性），軟件質量子特性（二級質量特性），軟件質量度量評價準則（使用單位自行規定）。

2001年ISO/IEC 9126中，軟件質量度量模型由四部分組成：質量模型，外部質量度量，內部質量度量，使用質量度量。

六個一級質量特性：

~ 功能性：在指定條件下使用時，軟件產品提供滿足明確和隱含需求功能的能力；

~ 可靠性：在指定條件下使用時，軟件產品維持規定的性能級別的能力(在規定的條件下，在規定的時間內，軟件不引起系統失效的概率)；

~ 易用性：在指定條件下使用時，軟件產品被理解、學習、使用及其吸引用戶的能力；

~ 效率（有效性）：在規定條件下，相對於所用資源的數量，軟件產品可提供適當性能的能力；

~ 可維護性：軟件產品可被修改的能力，修改可能包括修正、改進或者適應環境、需求和功能規約的變化；

~ 可移植性：軟件產品從一種環境遷移到另一種環境的能力。

4個使用質量特性：

~ 有效性：軟件產品在指定使用環境下，使用戶準確、完整地獲得規定目標的能力；

~ 生產率：軟件產品在指定使用環境下，使用戶花費合適的與有效性相關的資源數量的能力；

~ 安全性：軟件產品在指定使用環境下，獲得可接受的損害人類、商務、軟件、財產或環境風險級別的能力；

~ 滿意度：軟件產品在指定使用環境下，使用戶滿意的能力。

3. 朱蘭質量管理三部曲（含義、怎麼做）。

質量計劃 (Quality
Plan)：確定項目應達到的質量標準，以及如何滿足質量標準的計劃安排和方法。

質量保證(Quality
Assurance, QA)：確保項目達到有關標準，而開展的有計劃、有組織的工作活動。」Is it
done right?」

質量控制(Quality
Control, QC)：是確定項目結果與質量標準是否相符，並及時糾正產品缺陷的過程。」Is it right done?」

三、軟件項目管理

1. 基本概念：項目；項目管理；項目管理的五大過程組；項目管理的十大知識領域。

軟件：軟件是計算機程序、規程以及運行計算機系統可能需要的相關文檔和數據

~ 項目：為完成某一獨特的產品、服務或成果所做的一次性努力。

~ 項目管理(PM)：在項目活動中運用相關知識, 技能, 工具和技術滿足項目的要求。

五大過程組：

~ 啟動

~ 計劃

~ 執行

~ 控制

~ 收尾

十大知識領域：

~ 項目集成管理

  Project Integration Management

~ 項目範圍管理

  Project Scope Management

~ 項目時間管理

  Project Time Management

~ 項目成本管理

  Project Cost Management

~ 項目質量管理

    Project Quality Management

~ 項目人力資源管理

   Project Human Resource Management

~ 項目溝通管理

   Project Communications Management

~ 項目風險管理

   Project Risk Management

~ 項目採購管理

   Project Procurement Management

~ 項目利益相關者管理

   Project Stakeholder Management

2. 可行性分析：凈現值的優點（不考計算題）。

凈利潤/回收期/投資回報率在一定程度上忽視了成本和現金流的時限/收益的大小/現金的時限利息和利率。

~ 凈利潤(Net Profit)

~ 回收期(Payback Period)

~ 投資回報率(Return On Investment, ROI) 平均年利潤除以總投入

~ 凈現值(Net Present Value, NPV)

~ 內部回報率(Internal Rate of Return, IRR)

~ 凈現值是指特定方案未來現金流入量的現值和未來現金流出量的現值之間的差額。

優點：1.考慮了貨幣的時間價值（主要有限）增強了投資經濟性的評價
2、考慮了投資風險，風險大則採用高折現率，風險小則採用低折現率。3、凈現值對現金流量進行了合理折現

~ 給定貼現率r,計算公式為：

第t年的凈現值（NPV） = 第t年的值/(1+r)^t

~ 1.0/(1+r)^t為第t年的貼現因子 (Discount Factor);

~ 使得凈現值為0的貼現率稱之為內部回報率。

3. 識別軟件項目的活動：WBS（Work Breakdown
Structure, WBS）。

活動：

~ 應該有明確的開始時間和結束時間

~ 活動需求的資源應該是可以預測的，並且這些資源在整個活動期間都是需要的

~ 活動的周期應該是可以預測的

~ 有些活動可能在開始之前需要先完成其它活動

• 任務分解結構（WBS）：是面向可交付成果的對項目任務的分組，它組織並定義了整個項目範圍。它是一個分級的樹型結構，是對項目由粗到細的分解過程。
• 葉子節點 和 中間節點都是什麼？

            葉子節點（功能-子功能）：只有最底層的葉子節點構成了項目的活動集合。

            中間結點（功能）

4. 軟件工作量估計方法：常見的軟件工作量估計方法，記住名稱，並理解每個方法。

3.1 專家判斷

~ 對應用領域或開發環境有豐富知識的人，對執行一項任務所需的工作量做出估計

3.2 類比估計

根據實例特徵，評價相似程度，利用相似的項目數據得到最終估算值。

需要有經驗的領域，不能在早期規模不確定的時候使用，難以適應約束條件技術，人員等重大變化。

3.3 由底向上

3.4 自頂向下

3.5 Albrecht功能點

三種交易類型：外部輸入類型、外部輸出類型、外部查詢系統

兩種數據類型：內部邏輯文件類型、外部接口文件類型

3.6 Mark II 功能點

邏輯事務

適用於所有項目，尤其適用於MIS類項目. 簡單。MarkII功能點標準操作簡單只需進行簡單的加權計算即可。但標準缺乏對基本元素的識別規則，例如對數據元素、邏輯事務僅採用舉例的方式加以說明，實際操作過程中可能會出現歧義，度量結果的一致性不強。

3.7 COSMIC全功能點

~ 適用於實時系統或嵌入式系統的功能點方法

3.8 COCOMO II：參數化的生產率模型

RCPX  Product reliability and
complexity (產品的可靠性和複雜度)

RUSE  Reuse required (需要的可用性)

PDIF   Platform difficulty (平台難度)

PERS   Personnel
capability (人員的能力)

PREX   Personnel Experience (人員的經驗)

FCIL    
Facilities available (設施的可用性)

SCED  Schedule pressure (進度壓力)

5. 軟件項目的進度安排：甘特圖、關鍵路徑法（大題）、關鍵鏈法、PERT技術。（關鍵路徑法必須全面理解掌握，只需要掌握活動節點，活動箭頭不需掌握；後兩種方法了解，能夠了解計算步驟（選擇題））

  (1) //www.doc88.com/p-5763050345476.html

  (2) //wenku.baidu.com/view/6368fe9e51e79b8968022620.html

  (3) //www.cnitpm.com/pm/5933.html

關鍵路徑–只有等項目中耗時最多最長的活動完成之後，項目才能結束。這條路徑就是關鍵路徑，組成關鍵路徑的活動就是關鍵活動。

總緩衝期：LS – ES (LF – EF)，

分為空閑(free)緩衝期和干預(interfering)緩衝期

空閑緩衝期：一個活動最早的完成日期 — 後續活動最早的開始日期

干預緩衝期：總緩衝期 — 空閑緩衝期

都取正值

關鍵鏈（不考計算題，考定義步驟）與關鍵路徑相比，它既考慮項目活動的緊前關係，又考慮資源衝突，構建網絡圖，得到最長路徑——關鍵鏈；關鍵鏈決定了項目工期。

關鍵鏈法的步驟：

1緊前關係，得到的最長路徑—關鍵路徑    

2考慮緊前關係和資源衝突，得到關鍵鏈（關鍵鏈決定了項目工期）  

3加入項目緩衝和匯入緩衝；項目緩衝：放在關鍵鏈後面；匯入緩衝：放在非關鍵鏈與關鍵鏈的交匯處      

4砍掉所有項目的一半計算緩衝大小

在任務所需的平均時間上增加了一塊”安全時間”（Safety Time，ST）

考慮到任務內在的不確定性，在關鍵鏈的末端附加整塊的安全時間，也就是項目的緩衝時間（Project Buffer，PB）

關鍵鏈方法引入了非關鍵鏈緩衝時間（Feeding Buffer，FB）這一概念。

如圖3所示，任務C、D、E組成了項目的關鍵鏈，而任務A、B為非關鍵任務。由於任務B是任務E的緊前任務，為了防止任務A和B可能發生的延遲導致任務E不能按時開始，因此需要在任務B之後安排一定的緩衝時間，或者說讓任務A和B有一定的提前量。這樣，就可以有效地防止非關鍵任務對關鍵鏈產生負面影響。與項目的緩衝時間類似，非關鍵鏈緩衝時間整合與壓縮了所有非關鍵鏈任務的安全時間。

關鍵鏈方法還引入了資源緩衝（Resource Buffer，RB）的概念，以防止關鍵鏈任務因資源沒有及時到位而發生延誤。

甘特圖又叫橫道圖，它是以圖示的方式通過活動列表和時間刻度形象地表示出任何特定項目的活動順序與持續時間。

甘特圖的優點：

　　圖形化概要，通用技術，易於理解；

　　中小型項目一般不超過30項活動；

　　有專業軟件支持，無須擔心複雜計算和分析。

　　甘特圖的局限：

　　甘特圖事實上僅僅部分地反映了項目管理的三重約束（時間、成本和範圍），因為它主要關注進程管理（時間）；

　　軟件的不足。儘管能夠通過項目管理軟件描繪出項目活動的內在關係，但是如果關係過多，繁雜的線圖必將增加甘特圖的閱讀難度；

• PERT技術（不考計算題，考定義步驟）：全稱：工程評估評審技術。類似於關鍵路徑法。考慮到了進度管理中的風險，將不確定性引入了進度管理中。對活動周期進行三次估計，不再是CPM關鍵路徑中的確定值。

PERT的步驟：

1.估計每個活動的最有可能時間，樂觀時間，悲觀時間，計算活動的期望周期與標準偏差。

2.正向遍歷得到期望達到事件的日期

3滿足目標的可能性

6. 軟件項目的資源管理：資源定義，資源分配直方圖。

資源定義—-資源是執行項目所需要的任何項和人。

資源分配直方圖通過延遲某些活動的開始日期，來平衡化資源直方圖。

資源直方圖是用於管理資源的統計工具。它是一個定義資源分配計劃的歷史條形圖。資源直方圖幫助項目經理進行資源規劃和質量管理。

資源直方圖是堆疊的條形圖，用於項目管理中的資源分配。它基本上是一個資源計劃圖，顯示資源在一段時間內計劃工作的時間量。它還可用於確定資源可用性。

       資源分類：

~ 勞動力 (labor)

~ 設備 (equipment)：計算機、辦公設備等

~ 材料 (material)：打印紙、光盤等

~ 場地 (space)

~ 服務 (service)：網絡、通信等

~ 時間 (time)：可以與其它資源相互彌補

~ 錢 (money)

7. 軟件項目的風險管理：風險的定義，風險管理的框架，風險處理的方法。

~ 風險定義：一個不確定的事件或者情況，若其一旦發生，會對項目的目標，例如，範圍、進度、成本和質量，產生積極或消極的影響。

~ 三要素：事件、事件發生的概率、事件的影響

~ 風險管理的框架—風險識別，風險分析與優先級排序，風險策劃，風險監督

~
風險優先級，風險影響 =
(可能的危害)×(發生概率)

~ 風險處理的方法—接受風險，規避風險，降低風險，轉移風險

~
風險的分類–4大類：參與者，技術，結構，任務

~ 風險管理框架：

8. 軟件項目的監督和控制：掙值分析。（大題）

(1)  //wenku.baidu.com/view/7bcf90280066f5335a81211b.html

(2)  //blog.csdn.net/pmpljp/article/details/19299077

掙值分析—0/100 OR 百分比

計劃價值(已計劃工作的預測成本)—Planned value — PV—–200*5

掙值(已執行工作的預測成本)—Earned value —EV—–200*3.5

實際成本(已執行工作的實際成本)— Actual Cost —AC—-1000

進度偏差(已完成的工作值與計劃的工作值的差)—Schedule Variance– SV —EV-PV—700-1000

成本偏差(已完成工作的預算成本和實際成本的偏差)—Cost Variance –CV –EV-AC—700-1000

進度性能指標(Schedule Performance Index, SPI): SPI =
EV / PV—大於1及比預期好

成本性能指標(Cost Performance Index, CPI): CPI = EV /
AC—-大於1及比預期好

完成時間的估計值(按照當前進度項目的完成時間估計)—TEAC = SAC / SPI (Schedule At Completion, SAC, 項目的計劃周期)——–10/0.7

項目的成本預算(按照當前的進度，項目的總支出的估計)— EAC = BAC / CPI (Budget At Completion, BAC, 計劃的項目預算)—–2000/0.7

出題另有：試畫出項目的PV、AC、EV曲線，並分析項目的狀態。各項任務完成的比例見表3。(完成百分比法分配掙值)

9. 軟件項目的配置管理（定義）：配置管理的任務，配置項。

定義：軟件配置管理(Software
Configuration Management, SCM)是指一套管理軟件開發和維護過程中所產生的各種中間軟件產品的方法和規則。它是控制軟件系統演變的學科。

目標：

~ 標誌變更

~ 控制變更

~ 確保變更正確實現

~ 向受變更影響的組織和個人報告變更

         任務：

    1.標識

    2.版本控制

    3.變更控制

    4.配置審核

    5.配置報告

~ 配置項：軟件配置管理的對象，一個軟件配置項是項目中一個特定的、可文檔化的工作產品集。例如，程序，文檔等

四、經典的軟件過程管理

1. CMM/CMMI（邏輯思路，優缺點）

(1) CMM：出發點，體系結構，關鍵過程域，關鍵實踐活動。

CMM是一種理念，是指導思想，不是過程不是技術不是方法。

CMM—能力成熟度模型

CMM出發點—改善現有軟件開發過程，也可用於其他過程。

CMM體系結構:

~ CMM由5個成熟度級別組成

~ 每個成熟度級別（除級別1）包含了實現該級別的若干個關鍵過程域（KPA）

~ 每一個KPA進一步被分為稱為公共特徵的5個部分：執行約定、執行能力、執行活動、測量和分析、驗證實施

~ 這些公共特徵包括了關鍵實踐（KP），即每一個KPA包括5類KP

~ 實現了這些KP後，就實現了關鍵過程域的目標

CMM由5個成熟度級別組成：

每個成熟度級別（除級別1）包含了實現該級別的若干個關鍵過程域（KPA）

關鍵過程域(Key Process Area)：一系列相互關聯的操作活動，標識了達到某個成熟度級別時所必須滿足的條件。

CMM共有18個KPA，每一級都有自己的KPA。KPA分為三大類：管理過程、組織過程和工程過程。

每一個KPA進一步被分為稱為公共特徵的5個部分：執行約定、執行能力、執行活動、測量和分析、驗證實施

這些公共特徵包括了關鍵實踐（KP），即每一個KPA包括5類KP

實現了這些KP後，就實現了關鍵過程域的目標.

(2) CMMI與CMM的區別和聯繫，CMMI的兩種表示方法（階段式、連續式）。

區別和聯繫：
聯繫：CMMI即CMM集成，是系統工程和軟件工程的集成成熟度模型，CMMI是在CMM基礎上發展起來的，它繼承並發揚了CMM的優良特性，借鑒了其他模型的優點，融入了新的理論和實際研究成果
區別：CMMI共有分屬於4個類別的25個過程哉,覆蓋了4個不同的領域;相對應的CMM共有18個過程域.
CMMI更適合於信息系統集成企業，，它不僅能夠應用在軟件工程領域，而且可以用於系統工程及其他工程領域
CMMI比CMM進一步強化了對需求的重視.在CMM中,關於需求只有需求管理這一個KPA。在CMMI中,3級有一個獨立的KPA叫做需求開發,提出了對如何獲取優秀的需求的要求和方法。

兩種表示方法：
階段式表示法 連續式表示法

階段式表現方法仍然把CMMI 中的若干個過程區域分成了5 個
成熟度級別，幫助實施CMMI 的組織建議一條比較容易實現的過程改進發展道路。

而連續式表現方法則通過將CMMI 中過程域分為四大類： 過程管理 、 項目管理 、工程以及支持。對於每個大類中的過程區域，又進一步分為基本的和高級的。這樣，在按照連續式表示方法實施CMMI的時候，一個組織可以把項目管理或者其他某類的實踐一直做到最好，而其他方面的過程區域可以完全不必考慮。

2. PSP：結構，兩種日誌，評審比測試有效的原因，四個設計模板（對應哪個UML）。

PSP過程由一系列方法、表格、腳本等組成，用以指導軟件開發人員計劃、度量和管理他們的工作。

~ PSP成熟度模型

  
PSP具有4個等級，7個台階組成的成熟度框架 。4個等級分別為個體度量過程、個體計划過程、個體質量管理過程和個體循環過程。

日誌—時間日誌和缺陷日誌

評審比測試有效的原因–在評審時發現的錯誤比測試是發現的多；成本低。缺陷發現的越早，修復的花費越低；且避免缺陷比發現和修復缺陷更有效。

~ 代碼評審：一般來說，利用評審檢查表已經足夠了。

~ 設計評審：單純利用評審檢查表不夠，需要利用驗證方法，驗證設計的邏輯不出錯。

    驗證方法：

~ 狀態機驗證

~ 符號化驗證

~ 執行表驗證

~ 正確性驗證

==============================================

四個設計模板—a操作規格模板，b功能規格模板,c狀態規格模板,d邏輯規格模板

LST邏輯規格模板（無）：用於描述系統中各有機組分（方法，項，算法等）的邏輯實現。

SST狀態規格模板（UML:狀態機圖）：用於描述系統中所有可能發生的狀態的集合，以及狀態之間轉換的條件，伴隨的動作。。

FST功能規格模板（UML:類圖）：描述了系統可以向用戶提供對外部可見的行為說明書，以及與這些功能相關的系統行為，變量和內部關係（繼承關係）。

OST操作規格模板（UML:用例圖、時序圖）。描述了系統與外界的交互。描述了用戶與待設計系統的正常情況下和異常情況下的交互。

3.軟件過程模型：瀑布、原型、增量、螺旋、形式化、組件的優缺點。看PPT

瀑布模型

特點：

開發階段嚴格按照線性方式進行、階段間有因果關係、每個階段需評審確認、

允許反饋、強調文檔

適合場所：需求易於完善定義的軟件

缺點：

各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；開發過程中很難響應客戶的變更要求；

早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來  嚴重的後果

快速原型模型

優點：

加強用戶和軟件人員之間的溝通，明確系統的需求

儘早得到系統可用性的反饋信息，及時修改以獲得完整、正確需求

缺點：

用戶會由於看到的原型系統不完善，而對產品產生懷疑

可能為了快速開發原型系統，而採用未經充分論證的技術（如操作系統平台、主要的算法）導致質量低下

增量模型

優點：

整個產品被分解成若干個構件逐步交付，用戶可以不斷地看到所開發軟件的可運行中間版本；

將早期增量作為原型有助於明確後期增量的需求；

降低開發風險；

重要功能被首先交付，從而使其得到最多的測試

缺點：

需要軟件具備開放式的體系結構，以便各個構件逐步進入

需求難以在增量實現之前詳細定義，因此增量與需求的準確映射以及所有增量的有效集成可能會比較困難，容易退化為邊做邊改方式，使軟件過程的控制失去整體性

螺旋模型

優點：

風險驅動；關注軟件的重用；關注早期錯誤的消除；將質量目標放在首位；將開發階段與維護階段結合在一起；

缺點：需要風險評估的經驗；只適應內部大規模軟件開發；

形式化方法模型

優點：

由於數學方法具有嚴密性和準確性，形式化方法開發過程所交付的軟件系統具有較少的缺陷和較高的安全性

缺點：

開發人員需要具備一定技能並經過特殊訓練；

形式化描述和轉換是一項費時費力的工作,成本高，質量不一定高；

現實應用的系統大多數是交互性強的軟件，但是這些系統難以用形式化方法進行描述；

基於組件的開發模型

優點：充分體現軟件復用的思想、實現快速交付軟件、利用開源組件與軟件

缺點：商業組件的修改受到限制，影響系統的演化。

4.MSF：六個角色；過程模型中的五個階段。

MSF即微軟的解決方案。團隊是微軟作戰最小的基本單元。Microsoft Solution Framework

項目場景中的6個角色：產品管理，程序管理，開發，測試，發佈管理，用戶體驗。

5個階段：構思階段，計劃階段，開發階段，穩定階段，部署階段。

5. RUP：九個 軟件過程（6核心，3輔助），四個階段，六大經驗。

Rational Unified
Process），統一軟件開發過程,面對對象的軟件工程的過程框架。

• 9個過程域：6個是核心3個是輔助：

6個核心過程流：商業建模，需求，分析和設計，實現，測試，部署。

3個輔助過程流：配置和變更管理，項目管理，環境。

• 4個階段：初始，細化，構造，交付。(每個階段做什麼，做完的里程碑，中間產品是什麼？)

六大經驗—

迭代式開發，管理需求，基於組件的體系結構，可視化建模，驗證軟件質量，控制軟件變更

五、敏捷軟件開發

1. 敏捷宣言。

~ 「注重個人及互動勝於過程和工具」

~ 「注重可用的軟件勝於詳盡的文檔」

~ 「注重客戶協作勝於合同談判」

~ 「注重響應變化勝於恪守計劃」

q

q

q

2. 常見的敏捷軟件過程，SCRUM和極限編程（含義思想，簡單描述）。

—極限編程XP

是一種全新而快捷的軟件開發方法。XP團隊使用現場客戶、特殊計劃方法和持續測試來提供快速的反饋和全面的交流。這可以幫助團隊最大化地發揮他們的價值。——現場客戶，計劃遊戲，系統隱喻，簡單設計，代碼集體所有，結對編程，測試驅動，小型發佈，重構，持續集成，每周4小時工作制。

XP特別適合於小型的有責任心的、自覺自勵的團隊開發需求不確定或者迅速變化的軟件

—並行爭球法—Scrum—增量的迭代的開發過程

整個 開發周期包含若干個小的迭代周期，每個小的的迭代周期稱為一個Sprint（2-4周）

—水晶法Crysta—-每一個不同的項目都需要一套不同的策略、約定和方法論

~ 產品負責人 Product Owner：負責維護產品訂單的人，代表利益相關者的利益。

~ Scrum主管 Scrum
Master：為Scrum過程負責的人，確保scrum的正確使用並使得Scrum的收益最大化。一般不翻譯。

~ 開發團隊 Team: 由負責自我管理開發產品的人組成的跨職能團隊。

~ 計劃會 Sprint Planning Meeting：在每個衝刺之初，由產品負責人講解需求，並由開發團隊進行估算的計劃會議。

~ 每日立會 Daily Standup Meeting：團隊每天進行溝通的內部短會，因一般只有15分鐘且站立進行而得名。

~ 評審會 Review Meeting：在衝刺結束前給產品負責人演示並接受評價的會議。

~ 反思會/回顧會 Retrospective
Meeting：在衝刺結束後召開的關於自我持續改進的會議。

~ 產品訂單(product backlog)是整個項目的概要文檔。產品訂單包括所有所需特性的粗略的描述。產品訂單是關於將要創建的什麼產品。

~ 衝刺訂單(sprint backlog)是大大細化了的文檔，包含團隊如何實現下一個衝刺的需求的信息。

~ 燃盡圖(burn down chart)是一個公開展示的圖表，顯示當前衝刺中未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目。

~ XP是以開發符合客戶需要的軟件為目標而產生的一種方法論

~ XP是一種以實踐為基礎的軟件工程過程和思想

~ XP認為代碼質量的重要程度超出人們一般所認為的程度

~ XP特別適合於小型的有責任心的、自覺自勵的團隊開發需求不確定或者迅速變化的軟件

極限編程準則：

~ 溝通

~ 簡單

~ 反饋

~ 勇氣

~ 尊重

~ 謙遜

補充

軟件質量度量模型由三層組成：軟件質量特性，軟件質量子特性，軟件質量度量評價準則

質量成本是為了達到產品或服務的質量而付出的所有努力的總成本，包括三部分：

    預防成本：為防止將缺陷引入軟件而進行的預防工作所消耗的費用。

    評價成本：檢查軟件是否包含缺陷的工作所消耗的費用。

    失效成本：修復缺陷工作所消耗的成本。

缺陷跟蹤：缺陷跟蹤是指從缺陷被發現開始到被改正為止的整個跟蹤流程。

參考：//www.cnblogs.com/Amyheartxy/p/9143977.html