軟件工程原理與實踐（碩士）課件 11 軟件研發(fā)效能度量

高級軟件工程

SoftwareEngineering軟件研發(fā)效能度量為什么關注研發(fā)效能在數(shù)字化的時代，研發(fā)效能已經成為一家科技公司的核心競爭力在軟件研發(fā)領域，能夠有助于效能提升的方法論和實踐一直在快速發(fā)展比如，敏捷開發(fā)方法已經誕生了二十年，DevOps也已經發(fā)展了十多年。但是，我們經常遇到的一種現(xiàn)象是，當一個組織或者團隊在消耗了大量的“變革”時間、花費了大量的人力資源和成本后，卻無法有效回答一些看似非?；镜膯栴}：我們的研發(fā)效能到底怎么樣？可否量化？比所在行業(yè)平均水平、比別的公司、比別的團隊更好還是更差？研發(fā)效能的瓶頸點和問題是什么？在采納了敏捷或DevOps實踐之后，有沒有效果？有沒有實質上的提升？下一步應該采取什么樣的行動以繼續(xù)優(yōu)化效能？996Vs955,哪個更能產生效能？……2研發(fā)效能度量軟件工程數(shù)字化，將大數(shù)據(jù)技術用于軟件研發(fā)中。軟件企業(yè)的數(shù)字化轉型讓效能可量化、可分析、可提升，通過數(shù)據(jù)驅動的方式更加理性地評估和改善效能。3研發(fā)效能度量的挑戰(zhàn)軟件研發(fā)過程中的可視性差軟件研發(fā)過程中工作切分的隨意性敏捷研發(fā)過程中工作是并行開展的402-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標504-研發(fā)效能度量的反模式和原則“沒有度量就沒有改進”--PeterDrucker“沒有度量就沒有控制”--TomDemarco6軟件度量的價值認知：認知和理解過程、產品、資源和環(huán)境，建立比較基線；評估：比較同步跟蹤軟件項目的狀態(tài)，管理進展；及時發(fā)現(xiàn)實施和計劃的偏差，評估質量目標的達成情況，以及技術和過程的改進對產品和過程的影響；預測：是建立在適當資源下，達到成本、進度和質量目標的計劃的基礎。也可根據(jù)度量的實證，預測項目發(fā)展的傾向，估計分析風險，做出設計／成本權衡；改進：幫助識別問題根源，判斷可以改進的機會，交流改進的目標和理由等;調整資源分配等。7更好地管理軟件開發(fā)與運維度量的定義度量關注的是在一定規(guī)則下獲取關于實體屬性的信息一個實體可以是一個實物，如軟件產品；或者是一個事件，如軟件測試；屬性是我們所關注的實體的特征或特性．8度量的分類主觀/客觀objective/subjective絕對/相對absolute/relative動態(tài)/靜態(tài)dynamic/static預測/解釋predictive/explanatory過程/產品/項目/資源process/product/project/resource9按度量對象分產品度量，是以某種方式實現(xiàn)軟件過程中所指定的產品指標的合理量化，從而衡量軟件工作產品的規(guī)模、質量和復雜度等屬性，如代碼行數(shù)、McCabe圈復雜度、模塊的耦合度、測試覆蓋率、用戶平均響應時間等。過程度量，是以某種方式實現(xiàn)所指定的過程能力指標的合理量化，從而衡量組織級別上軟件過程的質量、成本、盈利、投資回報率和生產率等屬性，如需求變更率、缺陷的修復成本占總開發(fā)成本的比率、生產率等。項目度量，是以某種方式實現(xiàn)軟件項目指標的合理量化，從而衡量項目的質量、成本、盈利、生產率和進度等屬性，如項目質量目標的達成率、人均開發(fā)效率等。資源度量，是以某種方式實現(xiàn)資源指標的合理量化，從而衡量資源的利用、勝任力、分布合理性等屬性，如程序員的能力、工具的使用效率、庫存周轉率等。10研發(fā)效能是綜合性度量度量模型：GQM11GQM（Goal-Question-Metric）模型是基于這樣的假設：對一個機構而言，度量是應當有目的性的，即它應首先定義其自身或該機構內某個項目的目標，根據(jù)這些目標去跟蹤那些定義這些目標的數(shù)據(jù)，最后提供一個框架用于解釋這些數(shù)據(jù)與所確定的目標之間的關系。GQM度量模型第一層：概念層（目標G）。包含一個目標、目標涉及的度量對象及其屬性等信息。目標所涉及的對象類型有：產品（Product）：軟件生存期中產生、發(fā)布的各種軟件產品、文檔等；過程（Process）：與軟件生產相關的各種活動；資源（Resourse）：被過程所利用，以便產生其輸出產品的所有對象，如人、硬件、軟件、辦公空間等。第二層：運作層（問題Q）。問題是有上一層的目標細化而來，用于描述實現(xiàn)該目標的方式。一個目標能細化出多個問題。第三層：量化層（度量M）。一組以量化的方式回答上層問題的數(shù)據(jù)。這組數(shù)據(jù)可以是：客觀的：若該組數(shù)據(jù)全部是通過對對象的測量獲得的，而不是以什么人的主觀認識取得的；主觀的：若該組數(shù)據(jù)是通過實測和人們的主觀判斷獲得的。舉例目標：分析開發(fā)過程中的軟件錯誤，以便找出降低成本的可能點問題：Q1：在哪些地方出現(xiàn)了錯誤？Q2：這些錯誤的來源在哪里？Q3：發(fā)現(xiàn)的錯誤是否得到更改？Q4：從發(fā)現(xiàn)錯誤、確認錯誤、到更改錯誤所需要的時間？Q5：從過程改進小組的角度看，目前的糾錯、改錯過程是否合理？度量：(Q5得到的度量)M51（錯誤延遲）=M52（糾錯人工）=1302-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標1404-研發(fā)效能度量的反模式和原則軟件度量過程15步驟1確立和維持度量承諾接受度量需求度量的范圍定義為組織單元，可以是單一項目、功能領域、整個企業(yè)、單一場所或多場所的組織。由組織單元確定對度量過程的資源承諾以及維護這種承諾的意愿。分配資源度量發(fā)起者把度量職責分配給有能力勝任的人，勝任力為度量原理，以及數(shù)據(jù)收集、數(shù)據(jù)分析和信息通報等知識。所涉及的角色至少包括度量用戶和度量分析員。度量發(fā)起者應確保資金和人員等資源供給。16步驟2準備度量定義度量策略描述度量組織的特性確定度量的信息需求，例如“如何評價設計過程中的軟件產品質量？”從業(yè)務目標出發(fā)，根據(jù)已確定的信息需求，按GQM確定度量指標定義數(shù)據(jù)收集、分析和報告規(guī)程明確度量評價的準則識別和策劃度量工具評審和批準度量計劃獲取并部署支持技術，包括度量工具和培訓課程等17Metric示例18建議：從研發(fā)工具中自動收集數(shù)據(jù)從項目管理工具、需求管理工具、版本管理工具、IDE和代碼、評審工具、測試工具、持續(xù)集成工具、運維工具等自動收集數(shù)據(jù)采用埋點方式收集數(shù)據(jù)從database/file,trace,log等收集數(shù)據(jù)19數(shù)據(jù)集成，構建軟件工程關聯(lián)數(shù)據(jù)（linkeddata）20步驟3實施度量把數(shù)據(jù)的產生、收集、分析與報告過程與相關的軟件過程進行集成收集、存儲和驗證數(shù)據(jù)分析數(shù)據(jù)，得到度量結果記錄并通報度量結果21分析技術22可視化展示23步驟4評價度量評價度量信息和度量過程通過審核，對度量信息（例如度量指標、數(shù)據(jù)、規(guī)程、方法和工具等）和度量過程進行評價，識別它們的弱項和強項。把通過評價得到的經驗教訓存入度量經驗庫。識別潛在的改進契機例如軟件規(guī)模度量指標從代碼行變?yōu)楣δ茳c，重新分類軟件缺陷等。24建立組織級研發(fā)效能度量體系2502-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標2604-研發(fā)效能度量的反模式和原則3+1度量指標體系27研發(fā)效能度量指標集28阿里巴巴的效能度量指標29阿里巴巴的“2-1-1”愿景目標30螞蟻集團的效能度量31Facebook的效能度量32DevOps全球調查報告中的度量指標StateofDevOpsReport討論：設計軟件度量指標項目組A在最終的系統(tǒng)測試時發(fā)現(xiàn)了384個bug,項目組B則發(fā)現(xiàn)了184個。要決定哪個項目組發(fā)現(xiàn)bug更有效，應采用哪些度量？

代碼評審是軟件質量管理的最佳實踐，現(xiàn)需要設計代碼評審的度量指標，度量目標為：推進代碼評審的實踐，從而提升軟件的質量代碼評審時，評審者每分鐘罵臟話的次數(shù)？34代碼評審的度量指標3502-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標3604-研發(fā)效能度量的反模式和原則古德哈特定律

當某個度量變成了目標，它便不再是一個好的度量。37“千行代碼缺陷率”引發(fā)的“血”案從千行代碼缺陷率來看工程師A屬于正常水平，無功也無過。工程師B會因此受到表揚？不一定！他很有可能會被判定為沒有進行充分的測試，被責令加強測試。工程師C必然會遭受批評，被責令改進代碼質量?；谇写a缺陷率對這三個工程師的評價顯然是有失公允的。38需求變更后…軟件需求發(fā)生了變化……工程師B和工程師C的代碼具有較好的可維護性，可以方便地變更，所以很快完成變更任務，只引入了少量的新缺陷。工程師A的代碼由于缺乏設計模式的支持，大量代碼需要重寫，同時還會引入了很多新缺陷。度量結果：由于代碼量夠大，工程師A的千行代碼缺陷率依舊在平均范圍內，所以依然無功也無過工程師B和工程師C則繼續(xù)得到差評，因為他們的工作看起來太簡單了，明顯工作量“不飽滿”。39結論千行代碼缺陷率的度量體系是失敗的，其所傳達的價值觀與我們所期望的背道而馳從工程師B的遭遇可以看出“我們不相信你能夠寫出高質量的代碼”從工程師C的遭遇可以看出“我們不鼓勵技術提升階段的陣痛”從工程師A那邊看到的是“我們歡迎那些平庸的程序員”40陷入“算法對抗”的窘境程序員：稀釋代碼采取稀釋代碼的方式來降低千行代碼缺陷率，而不是實際去減少缺陷數(shù)量。因為與減少缺陷數(shù)量相比，直接稀釋代碼（比如：一行寫成多行、括弧必須換行、多寫注釋、多加空行等）的難度更低，而且更可控。度量員：改進度量算法，用基于AST的開發(fā)當量代替代碼行數(shù)程序員：通過人為增加開發(fā)當量（比如減少封裝等）來降低代碼缺陷率度量員：再次改進度量算法……41正確的做法是什么呢？研發(fā)效能度量的反模式把度量和KPI進行綁定片面性的度量數(shù)據(jù)采集依賴于人工錄入在沒有任何明確改進目