第一節 質量管理基本策略

為什么要了解并且掌握個體軟件過程(PSP)

DevOps"開發在前，運維在后"

高質量開發對于價值流動的意義—The Three Ways

個體軟件工程師的技能、過程直接影響產物質量

PSP是極少數專注于提升個體軟件工程師工程技能的方法

為什么在DevOps語境之下，仍然需要關注PSP？ 下屬說法中正確的有哪些？

A.這是提升開發質量，確保價值順暢流動得看需要

B.軟件開發是有系統可以運維的前提

C.不學習PSP，就不知道應該如果開發軟件

D.個體軟件工程師的開發對最終產品乃至整個系統的質量至關重要

正確答案：A、B、D你選對了

質量是什么？

軟件質量為“與軟件產品滿足規定的和隱含的需求能力有關的特征或者特性的全體”。[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你選對了

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的第二章 个体软件过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。