第一節 質量管理基本策略
爲何要了解而且掌握個體軟件過程（PSP）
DevOps"開發在前，運維在後"編程
高質量開發對於價值流動的意義—The Three Ways安全
個體軟件工程師的技能、過程直接影響產物質量框架
PSP是極少數專一於提高個體軟件工程師工程技能的方法運維
爲何在DevOps語境之下，仍然須要關注PSP？ 下屬說法中正確的有哪些？單元測試
A.這是提高開發質量，確保價值順暢流動得看須要學習
B.軟件開發是有系統能夠運維的前提測試
C.不學習PSP，就不知道應該若是開發軟件編碼
D.個體軟件工程師的開發對最終產品乃至整個系統的質量相當重要url
正確答案：A、B、D你選對了spa
質量是什麼？
軟件質量爲「與軟件產品知足規定的和隱含的需求能力有關的特徵或者特性的全體」。[ANSI/IEEE STd 729]
軟件質量爲內外兩部分的特性：其外部質量特性面向軟件產品的最終用戶，其內部質量特性則不直接面向最終用戶。《代碼大全》
軟件質量爲軟件產品能夠改變世界，使世界更加美好的程度。從用戶的角度考察軟件質量，用戶滿意度是最爲重要的判斷標準。
[Tom Demarco]
軟件質量爲對人（用戶）的價值。這必定義強調了質量的主觀性即對同一款軟件而言，不一樣的用戶對其質量有不一樣的體驗。
[Gerald Weinberg]
面向用戶的質量觀
定義質量爲知足用戶需求的程度。在這個定義中，就須要進一步明確：
用戶到底是誰？
用戶需求的優先級是什麼？
這種用戶的優先級對軟件產品的開發過程產生什麼樣的影響？
怎樣來度量這種質量觀下的質量水平？
典型用戶的指望
這款軟件產品必須可以工做；
這款軟件產品最好有較快的執行速度；
這款軟件產品最好在安全性、保密性、可用性、可靠性、兼容性、可維護性、可移植性等方面表現
優異；
PSP質量策略
用缺陷管理來替代質量管理；
高質量產品也就意味着要求組成軟件產品的各個組件基本完好陷；
第二節 PSP基本流程
什麼是PSP（personal software process）？
- PSP是包括了數據記錄表格、過程操做指南和規程在內的結構化框架。
- 一個基本的PSP流程包括策劃、設計、編碼、編譯、單元測試以及總結等階段。
- 在每一個階段，都有相應的過程操做指南，用以指導該階段的開發活動
- 全部的開發活動都須要記錄相應的時間日誌與缺陷日誌。
一個典型的PSP過程
PSP不一樣級別包含了不一樣過程元素
PSP過程度量
PSP基本度項
- 規模
- 時間
- 缺陷
- 日程（TSP）
PSP時間度量（時間日誌）
時間日誌示例
PSP缺陷度量（缺陷日誌）
規模度量的意義和困境
規模度量是連接其餘度量項的紐帶，是估算的基礎
規模度量的困境
精確的度量方式每每不便於早期規劃；
有助於早期規劃的度量每每難以產生精確度量結果；
LOC VS.FP（功能點）？
間接估算
基於代理的估算（PROBE）
模糊邏輯和相對大小估算
PROBE原理示例
相對大小矩陣
某一個相對大小矩陣（C++語言）
行數 僅供參考 軟件估算追求什麼樣的結果
爲何要度量？
·關於度量的爭議
度量體現着決策者對試圖要實現的目標的關切程度（特別重要，就去度量）
·「高質量的開發是計劃出來的"
·如何構建度量體系—GQM方法
第三節 PSP質量路線圖
質量路徑 Quality Journey
爲了追求極高的質量，你有哪些手段？
Step 1：各類測試
Step 2：進入測試以前的產物質量提高 （若是你扔給測試人員是一堆垃圾，那測完了改完了仍是一堆垃圾。）
Step 3：評審過程度量和穩定
Step 4：質量意識和主人翁態度
Step 5：個體工程師review過程的度量和穩定化
Step 6：訴諸設計
Step 7：缺陷預防
Step 8：用戶質量觀其餘質量屬性
不一樣缺陷消除方式消除缺陷的效率
設計、代碼評審
關於PSP質量策略，下面各類說法當中，哪種不恰當：
A.用缺陷管理替代質量管理
B.重點是關注模塊（即個體軟件工程師工做範圍）的質量
C.應該進行充分的測試來保障質量
D.經過高質量評審來保障質量
正確答案：C你選對了
測試消除缺陷的典型流程
- 發現待測程序的一個異常行爲；
- 理解程序的工做方式；
- 調試程序，找出出錯的位置，肯定出錯緣由；
- 肯定修改方案，修改缺陷；
- 迴歸測試，以確認修改有效；
評審發現缺陷典型流程
- 遵循評審者的邏輯來理解程序流程；
- 發現缺陷的同時，也知道了缺陷的位置和緣由；
- 修正缺陷；
PSP質量策略續
·用缺陷管理來替代質量管理；
·高質量產品也就意味着要求組成軟件產品的各個組件基本完好陷；
·各個組件的高質量是經過高質量評審來實現的；
如何開展有效的評審
·評審檢查表
·質量控制指標
·其餘因素
評審檢查表
·基於一個共識
「軟件工程師未經提醒，會反覆犯相似的錯誤"
·具體作法
- 將歷史項目當中的缺陷整理分析，找出改進機會
- 整理造成檢查表
- 使用檢查表輔助開展我的評審
- 按期更新檢查表
質量控制指標之一
·PQI（5個數據乘積）
設計質量：設計的時間應該大於編碼的時間
設計評審質量：設計評審的時間應該大於設計時間的50%
代碼評審質量：代碼評審時間應該大於編碼時間的50%
代碼質量：代碼的編譯缺陷密度應當小於10個/千行
程序質量：代碼單元測試缺陷密度應當小於5個/千行
PQI與集成測試缺陷之間的關係
關於時間日誌，下述說法中比較貼切的是：
A.時間日誌精確程度（例如：天、小時或者分鐘）應當依據項目須要而定。
B.時間日誌只能幫助咱們知道每一個開發活動消耗的時間。
C.時間日誌是幫助工程師判斷工程能力的手段之一。
D.每個工程活動（設計、編碼、UT等等）在時間日誌中只能有惟一的一條記錄。
正確答案：C你選對了
質量控制指標之二
評審的速度
- 評審的速度（Review Rate）是一個用以指導軟件工程師開展有效評審的指標
- 高質量的評審須要軟件工程師投入足夠的時間進行評審
- 在PSP的實踐中，代碼評審速度小於 200LOC/小時，文檔評審速度小於 4Page/小時
評審的其餘因素
·環境
·評審時機
·我的評審和小組評審
·缺陷預防
本講小結
·爲了確保DevOps中價值順暢流動，我的級別的軟件
開發質量起着相當重要的做用；
·PSP爲高質量開發提供了良好基礎
·度量、估算和計劃
質量管理策略
高質量策略補充
·評審目標是發現全部錯誤
·先作好，再作快
·完好陷編程（The Third Way） 編程就如同是在石頭上雕刻，你應該要當心謹慎。
下述各個說法中，哪種說法描述是在缺陷日誌的缺陷描述中應該出現的。
A.系統藍屏了。
B.程序沒有響應了。
C.運行結果錯誤。
D.循環控制變量沒有初始化。
正確答案：D你選對了