PSP
PSP
- 基本概念
- PSP---Personal Software Process,個體軟件過程。是一種個體級用于管理和改進軟件工程師個人工作方式的持續改進過程
- PSP中的基本度量項
- 時間
- 采用時間日志的方式
- 番茄工作法（Pomodoro Technique）
確定你想要干什么
設定一個25分鐘的定時器
工作，直到定時器時間到：這就是一個"番茄鐘"
休息5分鐘，繼續下一個番茄鐘
每4個番茄鐘做一次長時間的休息
- 缺陷
- 任何會引起交付產物所必要的修改。包括文檔描述錯誤，拼寫錯誤，語法錯誤，邏輯錯誤等
- 缺陷類型標準，10個典型的缺陷類型
Documentation
- 注釋、提示信息等
Syntax
- 拼寫錯誤，指令格式錯誤等
Build Package
- 組件版本，調用庫方面的錯誤
Assignment
- 申明、變量影響范圍等方面的錯誤
Interface
- 調用接口錯誤
Checking
- 出錯信息，未充分檢驗等錯誤
Data
- 數據結構，內容錯誤
Function
- 邏輯錯誤，指針，循環，計算，遞歸等方面的錯誤
System
- 配置，計時，內存方面的錯誤
Environment
- 設計，編譯，測試或其他支持系統的錯誤
- 缺陷日志記錄
方便地統計出缺陷在整個開發階段引入和消除的狀況
為提升過程質量，更加有效地消除缺陷提供參考
PSP中有專門的度量指標用于幫助軟件工程師了解缺陷注入和消除狀況
- 規模
- 規模度量方式的選擇參考標準
選擇的規模度量方式必須反應開發成本
選擇的度量方式必須精確定義
選擇的度量方式必須能用自動化方法來統計
選擇的度量方式必須有助于早期規劃
- 常用的規模度量方式
代碼行（LOC）
- 可以精確地度量軟件產品的規模，也方便開發相應的規模統計工具，但是在項目初始階段，很難直接估算出程序的代碼行
功能點（FP）
- 在項目早期容易識別，但是功能點的度量也比較粗略且對于功能點的粒度缺乏一致的理解，不存在可以對功能點進行自動化統計的方法
PROBE:PROxy Based Estimation,基于代理的估算
- 尋找一種便于早期規劃的規模度量的代理，建立這種代理與精確度量之間的關聯關系
- 時間
- PROBE估算的流程
- PROBE估算方法主要用來估算待開發過程程序的規模和所需資源
- 一個典型的PROBE流程
- 概要設計
- 代理識別
類
方法/函數
過程
數據庫表格
- 估算并調整程序規模
代理規模和程序規模的區別
由于估算本質上是一種主觀判斷，因此難免出現偏差，這種偏差不能簡單地根據上一次的偏差進行補償修正
PSP：通常采用線性回歸方法對估算結果進行調整，使得估算結果盡可能準確
使用線性回歸調整規模估算
使用線性回歸調整時間估算
- 計算預測區間
- 顯著性
- 描述的是上述兩組數據的相關關系出現的偶然性。如果顯著性接近1，說明出現這樣的相關性是非常偶然的
- 相關性
- 相關性描述的是兩組變化的數據之間相互關聯的程度，通過用字母r來表示。相關性越大越好
- 使用線性回歸方法估算程序規模和資源
- 線性回歸調整規模估算
- 線性回歸調整時間估算
- 相對大小矩陣
- 簡單方法
- 特點：計算簡單，但不穩定，隨著新數據的加入會造成相對大小矩陣數據的大幅度調整
- 方法
將每個方法的代碼行數進行排序
選擇最小值作為VS
選擇最大值作為VL
選擇中值作為M
選擇VS與M的均值作為S
選擇VL與M的均值作為L
- 正態分布
- 相對穩定，在歷史數據基本符合正態分布的情況下，可以給出非常好的相對大小矩陣，但實際上程序規模的分布并不是正態分布的
- 對數正態分布
- 更加符合人們對于程序規模的直觀感覺，PSP中大部分情況下使用對數正態分布法來對歷史數據進行整理，進而獲得相對大小矩陣；需要經常維護和更新相對大小矩陣
- 簡單方法
- 常用的PSP過程質量的度量指標
- Yield
- Yield指標用以度量每個階段在消除缺陷方面的效率
- Phase Yield=100*(某階段發現的缺陷個數)/（某階段注入的缺陷個數+進入該階段前遺留的缺陷個數）
- Process Yield=100*(第一次編譯前發現的缺陷個數)/（第一次編譯前注入的缺陷個數）
- 典型的缺陷注入階段
設計階段
編碼階段
- 典型的缺陷消除階段
設計評審
代碼評審
編譯
單元測試(修改缺陷的過程中有可能引入新的缺陷)
- Yield是一種事后質量控制手段
- Yield可以直接通過缺陷日志統計得到，可以清楚地了解缺陷在整個開發過程中被注入和消除的狀況，Yield指標越高越好，整個過程的Process Yield，期望值在80以上。
- Yield估算
缺陷總數不可知
指導質量管理
如果有歷史數據，應當充分使用歷史數據
無歷史數據估算
- 將單元測試階段的Phase Yield設定為50
- 在測試中每發現一個缺陷，往往意味著還有一個缺陷沒有被發現
- A/FR（Appraisal to Failure Ratio）質檢失效比
- A/FR=PSP質檢成本/PSP失效成本
PSP中定義的失效成本為編譯時間和單元測試時間之和
PSP中定義的質檢成本為設計評審時間與代碼評審時間之和
- 理論上，A/FR的值越大，往往意味著越高的質量，過高的A/FR往往意味著做了過多的評審，反而會導致開發效率的下降。作為指南，在PSP中A/FR的期望值為2.0.為了確保較高的質量水平，軟件工程師應當花費兩倍于編譯加測試的時間進行評審工作，評審的對象為設計和代碼
- COQ（Cost Of Quality）質量成本
- 用來量化質量問題所帶來的成本消耗
- 由三個主要的組成部分
失效成本
- 失效分析現象，查找原因，做必要的修改所消耗的成本
質檢成本
- 評價軟件鏟平，確定其質量狀況所消耗的成本
預防成本
- 識別缺陷根本原因，采取措施預防其再次發送所消耗的成本
- PQI（Process Quality Index）過程質量指標
- 用以度量PSP過程的整體質量
- PQI用來全面刻畫軟件過程質量
- 它是五個過程質量指標的乘積
設計質量
- 設計時間應該大于編碼的時間
設計評審質量
- 設計評審時間應該大于設計時間的50%
代碼質量
- 代碼評審時間應該1大于編碼時間的50%
代碼評審質量
- 代碼的編譯缺陷密度應當小于10個/千行
程序質量
- 代碼的單元測試缺陷密度應當小于5個/千行
- PQI超過0.4，組件質量往往比較高
- （Review Rate）評審速度
- 評審速度是一個用以指導軟件工程師開展有效評審的指標
- 高質量的評審需要軟件工程師投入足夠的時間進行評審
- 大量統計數據表明，代碼評審速度小于200LOC/小時，文檔評審速度小于4Page/小時
- DRL缺陷消除效率比（Defect-Removal Leverage）
- 度量的是不同缺陷消除手段消除缺陷的效率
- 其計算方式是以某個測試階段（一般為單元測試）每小時發現的缺席數為基礎，其他階段每小時發現的缺陷書與該測試階段每小時發現的缺陷的比值就是DRL
- Yield
- PSP四大設計模式
- 操作規格模板（Operational Specification Template簡稱OST）
- 描述系統與外界的交互情形。具體而言，是描述"用戶"與特定設計系統的正常情況下的交互。OST可以用來定義測試場景和測試用例，也可以作為和系統用戶討論需求的基礎，特別是操作相關的需求描述
- UML
用例圖
順序圖
- 功能規格模板（Functional Specification Template簡稱FST）
- 描述了系統對外的靜態接口。軟件設計人員可以通過FST來定義軟件產品的功能
- UML
類圖
- 狀態規格模板（State Specification Template簡稱SST）
- 描述系統的狀態信息。SST可以精確定義程序的所有狀態，狀態之間的轉換以及伴隨著每次狀態轉換的動作
- UML
狀態機圖
- 邏輯規格模板（Logical Specification Template簡稱LST）
- 描述了系統的靜態邏輯。
- 操作規格模板（Operational Specification Template簡稱OST）
- UML與PSP設計模板的關系
- UML的用例圖和順序圖提供了與PSP與OST同樣的信息
- UML中的順序圖和類圖所描述的類之間的關系以及對象之間的交互信息在PSP4個設計模板中沒有對應的內容
- UML類圖中記錄了方法的型構，然而方法的行為沒有描述，這一點在PSP的FST中有相應的內容
- PSP中的LST用以描述程序的靜態邏輯，這在UML沒有對應的圖示方法
- UML中的狀態機圖與SST描述的狀態圖類型，但是SST中描述的關于狀態、狀態轉換條件以及狀態轉換中的動作沒有對應的UML圖示方法
總結
- 上一篇： 存储墙
- 下一篇： 《算法导论》第四版 电子版 全网第一时间