第一節(jié) 質(zhì)量管理基本策略

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

DevOps"開發(fā)在前，運維在后"

高質(zhì)量開發(fā)對于價值流動的意義—The Three Ways

個體軟件工程師的技能、過程直接影響產(chǎn)物質(zhì)量

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

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

A.這是提升開發(fā)質(zhì)量，確保價值順暢流動得看需要

B.軟件開發(fā)是有系統(tǒng)可以運維的前提

C.不學(xué)習(xí)PSP，就不知道應(yīng)該如果開發(fā)軟件

D.個體軟件工程師的開發(fā)對最終產(chǎn)品乃至整個系統(tǒng)的質(zhì)量至關(guān)重要

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

質(zhì)量是什么？

軟件質(zhì)量為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求能力有關(guān)的特征或者特性的全體”。[ANSI/IEEE STd 729]

軟件質(zhì)量為內(nèi)外兩部分的特性：其外部質(zhì)量特性面向軟件產(chǎn)品的最終用戶，其內(nèi)部質(zhì)量特性則不直接面向最終用戶?！洞a大全》

軟件質(zhì)量為軟件產(chǎn)品可以改變世界，使世界更加美好的程度。從用戶的角度考察軟件質(zhì)量，用戶滿意度是最為重要的判斷標準。

[Tom Demarco]

軟件質(zhì)量為對人(用戶)的價值。這一定義強調(diào)了質(zhì)量的主觀性即對同一款軟件而言，不同的用戶對其質(zhì)量有不同的體驗。

[Gerald Weinberg]

面向用戶的質(zhì)量觀

定義質(zhì)量為滿足用戶需求的程度。在這個定義中，就需要進一步明確：

用戶究竟是誰？

用戶需求的優(yōu)先級是什么？

這種用戶的優(yōu)先級對軟件產(chǎn)品的開發(fā)過程產(chǎn)生什么樣的影響？

怎樣來度量這種質(zhì)量觀下的質(zhì)量水平？

典型用戶的期望

這款軟件產(chǎn)品必須能夠工作；

這款軟件產(chǎn)品最好有較快的執(zhí)行速度；

這款軟件產(chǎn)品最好在安全性、保密性、可用性、可靠性、兼容性、可維護性、可移植性等方面表現(xiàn)

優(yōu)異；

PSP質(zhì)量策略

用缺陷管理來替代質(zhì)量管理；

高質(zhì)量產(chǎn)品也就意味著要求組成軟件產(chǎn)品的各個組件基本無缺陷；

第二節(jié) PSP基本流程

什么是PSP(personal software process)？

• PSP是包括了數(shù)據(jù)記錄表格、過程操作指南和規(guī)程在內(nèi)的結(jié)構(gòu)化框架。
• 一個基本的PSP流程包括策劃、設(shè)計、編碼、編譯、單元測試以及總結(jié)等階段。
• 在每個階段，都有相應(yīng)的過程操作指南，用以指導(dǎo)該階段的開發(fā)活動
• 所有的開發(fā)活動都需要記錄相應(yīng)的時間日志與缺陷日志。

一個典型的PSP過程

PSP不同級別包含了不同過程元素

PSP過程度量

PSP基本度項

• 規(guī)模
• 時間
• 缺陷
• 日程(TSP)

PSP時間度量(時間日志)

時間日志示例

PSP缺陷度量(缺陷日志)

規(guī)模度量的意義和困境

規(guī)模度量是鏈接其他度量項的紐帶，是估算的基礎(chǔ)

規(guī)模度量的困境

??? 精確的度量方式往往不便于早期規(guī)劃；

??? 有助于早期規(guī)劃的度量往往難以產(chǎn)生精確度量結(jié)果；

??? LOC VS.FP(功能點)？

間接估算

??? 基于代理的估算(PROBE)

??? 模糊邏輯和相對大小估算

PROBE原理示例

相對大小矩陣

某一個相對大小矩陣(C++語言)

??? 行數(shù)??? 僅供參考??????? 軟件估算追求什么樣的結(jié)果

為什么要度量？

·關(guān)于度量的爭議

? 度量體現(xiàn)著決策者對試圖要實現(xiàn)的目標的關(guān)切程度(特別重要，就去度量)

·“高質(zhì)量的開發(fā)是計劃出來的"

·如何構(gòu)建度量體系—GQM方法

第三節(jié) PSP質(zhì)量路線圖

質(zhì)量路徑 Quality Journey

為了追求極高的質(zhì)量，你有哪些手段？

Step 1：各種測試

Step 2：進入測試之前的產(chǎn)物質(zhì)量提升??? (如果你扔給測試人員是一堆垃圾，那測完了改完了還是一堆垃圾。)

Step 3：評審過程度量和穩(wěn)定

Step 4：質(zhì)量意識和主人翁態(tài)度

Step 5：個體工程師review過程的度量和穩(wěn)定化

Step 6：訴諸設(shè)計

Step 7：缺陷預(yù)防

Step 8：用戶質(zhì)量觀其他質(zhì)量屬性

不同缺陷消除方式消除缺陷的效率

設(shè)計、代碼評審

關(guān)于PSP質(zhì)量策略，下面各種說法當中，哪一種不恰當：

A.用缺陷管理替代質(zhì)量管理

B.重點是關(guān)注模塊(即個體軟件工程師工作范圍)的質(zhì)量

C.應(yīng)該進行充分的測試來保障質(zhì)量

D.通過高質(zhì)量評審來保障質(zhì)量

正確答案：C你選對了

測試消除缺陷的典型流程

• 發(fā)現(xiàn)待測程序的一個異常行為；
• 理解程序的工作方式；
• 調(diào)試程序，找出出錯的位置，確定出錯原因；
• 確定修改方案，修改缺陷；
• 回歸測試，以確認修改有效；

評審發(fā)現(xiàn)缺陷典型流程

• 遵循評審者的邏輯來理解程序流程；
• 發(fā)現(xiàn)缺陷的同時，也知道了缺陷的位置和原因；
• 修正缺陷；

PSP質(zhì)量策略續(xù)

·用缺陷管理來替代質(zhì)量管理；

·高質(zhì)量產(chǎn)品也就意味著要求組成軟件產(chǎn)品的各個組件基本無缺陷；

·各個組件的高質(zhì)量是通過高質(zhì)量評審來實現(xiàn)的；

如何開展有效的評審

·評審檢查表

·質(zhì)量控制指標

·其他因素

評審檢查表

·基于一個共識

??? “軟件工程師未經(jīng)提醒，會反復(fù)犯類似的錯誤"

·具體做法

• 將歷史項目當中的缺陷整理分析，找出改進機會
• 整理形成檢查表
• 使用檢查表輔助開展個人評審
• 定期更新檢查表

質(zhì)量控制指標之一

·PQI(5個數(shù)據(jù)乘積)

設(shè)計質(zhì)量：設(shè)計的時間應(yīng)該大于編碼的時間

設(shè)計評審質(zhì)量：設(shè)計評審的時間應(yīng)該大于設(shè)計時間的50%

代碼評審質(zhì)量：代碼評審時間應(yīng)該大于編碼時間的50%

代碼質(zhì)量：代碼的編譯缺陷密度應(yīng)當小于10個/千行

程序質(zhì)量：代碼單元測試缺陷密度應(yīng)當小于5個/千行

PQI與集成測試缺陷之間的關(guān)系

關(guān)于時間日志，下述說法中比較貼切的是：

A.時間日志精確程度(例如：天、小時或者分鐘)應(yīng)當依據(jù)項目需要而定。

B.時間日志只能幫助我們知道每個開發(fā)活動消耗的時間。

C.時間日志是幫助工程師判斷工程能力的手段之一。

D.每一個工程活動(設(shè)計、編碼、UT等等)在時間日志中只能有唯一的一條記錄。

正確答案：C你選對了

質(zhì)量控制指標之二

評審的速度

• 評審的速度(Review Rate)是一個用以指導(dǎo)軟件工程師開展有效評審的指標
• 高質(zhì)量的評審需要軟件工程師投入足夠的時間進行評審
• 在PSP的實踐中，代碼評審速度小于 200LOC/小時，文檔評審速度小于 4Page/小時

評審的其他因素

·環(huán)境

·評審時機

·個人評審和小組評審

·缺陷預(yù)防

本講小結(jié)

·為了確保DevOps中價值順暢流動，個人級別的軟件

??? 開發(fā)質(zhì)量起著至關(guān)重要的作用；

·PSP為高質(zhì)量開發(fā)提供了良好基礎(chǔ)

??? ·度量、估算和計劃

質(zhì)量管理策略

高質(zhì)量策略補充

·評審目標是發(fā)現(xiàn)所有錯誤

·先做好，再做快

·無缺陷編程(The Third Way)??? 編程就如同是在石頭上雕刻，你應(yīng)該要小心謹慎。

下述各個說法中，哪一種說法描述是在缺陷日志的缺陷描述中應(yīng)該出現(xiàn)的。

A.系統(tǒng)藍屏了。

B.程序沒有響應(yīng)了。

C.運行結(jié)果錯誤。

D.循環(huán)控制變量沒有初始化。

正確答案：D你選對了

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。