1. 軟件工程發展

• 軟件開發的四大本質難題：不可見性、復雜性、一致性、可變性。
  • 除了不可見性以外，其他三個本質難題因項目而異
  • 四大本質難題互動促進，可以緩解，但是不能徹底解決
• 軟件危機：落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。
• 軟件發展的兩個趨勢：軟件項目規模日益擴大、軟件在整個系統的比重日益增加。
• 軟件發展的三大階段：
• 軟硬件一體化 50年代 到 70年代
• 特點：軟件支持硬件完成計算任務、功能單一、復雜度有限、幾乎沒有需求變更
• 開發方法：線性順序過程、三思而后行(Measure twice, and cut once)、編碼和改錯(Code and Fix)
• 軟件成為獨立的產品 70年代 到 90年代
• 特點：軟件擺脫硬件的束縛(操作系統)、功能強大(個人電腦出現)、需求多變、兼容性要求、來自市場的壓力
• 開發方法：形式化方法、結構化程序設計和瀑布模型
• 網絡化和服務化：90年代中期 至今
• 特點：功能更復雜、規模更大、用戶數量急劇增加、快速演化和需求不確定、分發方式的變化、進一步的服務化和網絡化、盛行開源和共享精神。
• 開發方法：迭代式開發、敏捷開發(XP、Scrum、KanBan)、開源軟件開發方式、DevOps

2. 軟件工程與管理

• 軟件工程是一門研究用工程化的方法構建和維護有效的、實用的和高質量的軟件的學科。
  • 軟件工程的管理視角：能否復制成功？
  • 軟件工程的技術視角：能夠將問題解決得更好？

2.1. 管理

• 管理的三大關鍵要素：目標、狀態、糾偏
  • 軟件項目管理是為了較少各種無謂的損耗來實現本該有的性能。
  • 軟件過程改進是為了達到更好的效能，其中質量(缺陷)是首要目標或限制。
• 軟件項目管理是應用方法、工具、技術以及人員能力來完成軟件項目，實現項目目標的過程。
  • 軟件項目管理的三大目標：成本、質量、工期。
  • 軟件項目管理的對象是各項軟件項目。
  • 軟件項目管理的管理視角可以細分為軟件過程和生命周期模型。
• 軟件過程管理
  • 軟件過程管理的目的是為了讓軟件過程在開發效率、質量等方面有著更好性能績效
  • 軟件過程管理的對象是軟件過程。
  • 軟件過程管理與軟件過程改進
    • 兩者含義接近
    • 軟件過程管理參考模型 CMM/CMMI、SPICE等
    • 軟件過程改進參考元模型 PDCA、IDEAL等

2.2. 軟件過程

• 軟件過程：軟件過程是為了實現一個或者多個事先定義的目標而建立起來的一組實踐(具有一定的先后順序)的集合。

2.2.1. 廣義軟件過程

• 廣義軟件過程(同義詞：軟件開發方法、軟件開發過程)
  • 包括技術、人員及狹義過程。
  • 例子：凈室Clean Room方法、極限編程方法、Scrum方法、Gate方法、敏捷軟件過程/方法、輕量型過程/方法和重量型軟件過程/方法。

2.2.2. 生命周期模型

• 生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法。
• 生命周期模型與軟件過程的區別和聯系
  • 生命周期模型是對軟件過程的一種人為劃分。
  • 生命周期模型是軟件開發過程的框架，是對軟件開發過程的一種粗粒度劃分。
  • 生命周期模型往往不包括技術實踐。
• 如何理解瀑布模型
  • 瀑布模型不是單一模型，是一系列模型，覆蓋最簡單場景(過程元素少)到最復雜的場景(過程元素多)
  • 軟件項目應該結合實際情況選擇合適過程元素的瀑布模型?；驹瓌t是，項目面臨困難和挑戰越多，選擇的模型應該越復雜。
  • 軟件項目團隊往往低估項目的挑戰，選擇了過于簡單的不適用的瀑布模型。

2.2.3. 敏捷軟件開發

• 目的：使軟件開發團隊具有高效工作和快速響應變化的能力
• 特征：小周期迭代、快速響應變更、價值交付、自動化
• 雪鳥會議與敏捷宣言
  • 敏捷軟件開發宣言的4個簡單價值觀
    • 個體和交互 勝過 過程和工具
    • 可以工作的軟件 勝過 面面俱到的文檔
    • 客戶合作 勝過 合同談判
    • 響應變化 勝過 遵循計劃
  • 也就是說，盡管右項有其價值，我們更重視左項的價值
• 具有誤導性的描述
  • 輕量級方法：對XP為代表的的一類方法的誤導，輕量級和重量級沒有具體的區分方法。
  • 擁抱變更、變更驅動：對待變更，所有的軟件工程方法都是限制和管理的態度。所有正式的項目都是計劃驅動的，否則計劃的作用無法體現。
  • 測試驅動開發可以提供更高的開發質量：沒有足夠的證據支持

2.2.4. 敏捷軟件開發方法

• 極限編程方法 XP
  • 將好的開發實踐運用到極致，規定開發人員每周工作時間不超過40小時，連續加班不可以超過2周。
  • 比如客戶作為開發團隊的成員、短交付周期、結對編程、測試驅動開發(TDD)、持續集成、重構
• Scrum：
  • 3個角色：產品負責人、Scrum Master、開發團隊
  • 3個工件：產品訂單(優先級、動態)、沖刺訂單(細化、凍結)、燃盡圖
  • 5個活動：Sprint、Sprint Planning、Sprint Daily Standup、Spring Review、Sprint Retrospective
  • 5個價值觀：Coverage(勇氣)、Openness(開放)、Focus(專注)、Commitment(承諾)、Respect(尊重)
• KanBan方法
  • 精益生產(豐田制造法)的具體實現
  • 活動：可視化工作流、限制WIP、管理周期時間
• Scrum vs. XP
  • 迭代周期不同：Scrum的迭代周期為2-4周，XP的迭代周期為1-2周
  • 迭代中是否允許需求變更：Scrum迭代中需求凍結，XP只要時間資源相同即可變更。
  • 迭代中是否嚴格遵守需求優先級：Scrum比較靈活(可能有需求依賴)，XP嚴格遵守。
  • 過程工程化：Scrum開發過程并未工程化，XP對開發流程嚴格定義。
• Linus 定律：如果有足夠多的beta測試者和合作開發者，幾乎所有問題都會很快顯現，然后自然有人會把它解決。

2.3. 迭代式開發方法

定義：大型軟件系統的開發過程也是一個逐步學習和交流的過程，軟件系統的交付不是一次完成，而是通過多個迭代周期，逐步來交付。

特點和優勢：

2.4. 題目

• 軟件過程管理是軟件項目管理應該要實現的目標：錯誤
• 在公司導入敏捷過程是我們今年過程改進的目標：正確
• XP與CMM/CMMI是對立的兩種軟件開發方法：正確
• CMM/CMMI不適合當今互聯網環境的項目管理需求：正確
• PDCA和IDEAL不適合在敏捷環境中使用：錯誤
• 不同的軟件開發案過程應該使用不同的生命周期模型，反之亦然：錯誤
• 【2016】Devops三個步驟
• 【2018】Devops的特點，為什么流行？
• 【2018】什么是云原生？相關的重要的概念
• 【2018】精益屋的兩大支柱？
• 【2018】JIT及時生產，價值流和價值拉動的關系

3. 各類模型

3.1. CMM：軟件過程管理/改進模型，Humphrey

CMM是一種用于評價軟件承包能力并幫助其改善軟件質量的方法，側重于軟件開發過程的管理及工程能力的提高與評估。

五個等級

初始級 Initial：幾乎沒有健全的軟件工程管理制度

可重復級 Repeatable：有基本的軟件項目的管理行為，設計和管理技術是基于相似產品中的經驗，復用以前的成功。

已定義級 Defined：為軟件生產的過程編制了完整的文檔。

已管理級 Managed：公司為每個項目都設定質量和生產目標。

優化級 Optimizing：連續地改進軟件過程。

3.2. CMMI：軟件過程管理/改進模型

CMMI刻畫軟件團隊/組織從不成熟到成熟的每個階段的特征

五個等級

初始級 Initial

過程不可預測、項目管理很少、開發相對混亂

個人英雄主義、救火文化

已管理級 Managed

以項目為單位進行管理，相對被動的管理

有項目計劃和跟蹤、需求管理、配置管理等

已定義級 Defined

以公司為單位進行管理，相對主動的管理

公司層面有標準流程和相應規范，每個項目小組可以基于此定義自己的流程

定量管理級 Quantitatively

過程被度量和管理

構建預測模型，用統計過程控制的手段來管理過程

優化級 Optimizing

關注與過程改進

繼續應用統計方法識別過程偏差，找到問題根源并消除，避免未來繼續發生類似問題

3.3. PDCA：軟件過程改進模型

PDCA：Plan、Do、Check、Action

PDCA模型的步驟：

分析現狀，找出問題

分析影響質量的原因

找出措施

擬定措施計劃

執?措施，執?計劃

檢查效果，發現問題

總結經驗，納?標準

遺留問題轉?下期PDCA循環

3.4. IDEAL：軟件過程改進模型

IDEAL模型解決了軟件在各種質量改進環境下的需要。

IDEAL包括了軟件改進過程的五個階段

Initiating 初始

Diagnosing 診斷

Establishing 建立

Acting 執行

Leveraging 調整

3.5. 其他模型

SPICE模型：軟件過程管理模型

ISO/IEC：軟件過程改進模型

RUP Rational Unified Process：軟件過程框架

最佳實踐：迭代式開發、管理需求、使用基于構建的體系結構、可視化建模、驗證軟件質量、控制軟件變更。

RUP軟件開發生命周期：初始階段、精化階段、構建階段、移交階段。

3.6. 模型理解

CMM/CMMI不適合于軟件開發的原因：

CMM/CMMI并不是具體的軟件過程或者軟件開發方法

CMM/CMMI不能作為檢驗軟件過程優劣的標準

CMM/CMMI與其他軟件過程或者軟件開發方法的比較沒有任何意義

判斷：

CMMI模型需要適當裁剪以適應公司的實際情況：錯誤。需要裁減的是公司內部定義的組織級開發流程和開發規范。

CMMI模型太重了，不適合互聯網時代的輕量級開發：錯誤。CMMI根本就不是軟件開發模型。

CMMI只適合大公司、大項目，不適合小項目：錯誤

CMMI只適合需求不變或者很少變化的場合，不適合需求不確定、變化很多的場景：錯誤。

CMMI不是過程優劣的標準，也不適合用作公司之間的能力比較：對的。CMMI衡量的相對水平。

4. 軟件質量管理發展：軟件質量大師的主要觀點和貢獻、工作

Shewhart：

最早將統計控制思想引入質量管理，是質量改進奠基人。

提出PDS(Plan-Do-See)模型，后被戴明發展為PDCA。

Deming：日本質量管理之父

提出質量改進的思想

提出PDCA循環(又稱戴明環)

提出14條原則：停止依賴檢驗的方法獲得質量、崗位培訓制度化、取消對操作人員規定的工作定額和指標等。

Juran

主編質量控制手冊，該手冊被稱為當今世界質量控制科學的"圣經"，奠定了"全面質量管理(TQM, Total Quality Management)"的理論基礎。

提出適用性質量：質量是一種適用性，需要產品在使用期間能夠滿足使用者的要求。

提出質量三部曲：質量計劃、質量控制、質量改進

提出Juran質量循環

提出80/20循環：80%的質量問題由領導責任引起。

Crosby：

提出了"零缺陷"概念：將工作放在預防上，而不是質量檢驗，將事情一次做對。

提出質量管理的絕對性

提出質量改進的基本要素(6C)

發展質量成熟度的度量。

Humphrey：軟件過程之父

采用Crosby的成熟度度量，提出了軟件能力成熟度模型(CMM)

將上述的理論和實踐引入軟件過程

5. PSP個體軟件過程

• PSP是一種個體級用于管理和改進軟件工程師個人工作方式的持續改進過程。是包括數據記錄表格、過程操作指南和規程在內的結構化框架。

5.1. PSP基本原理(為什么有PSP)

軟件系統的整體質量由該系統中質量最差的組件所決定。

軟件組件的質量取決于開發工程師所使用的開發過程。

軟件工程應當自己度量、跟蹤自己的工作流程，并建立持續的自我改進機制，自己管理軟件組件的質量。

5.2. PSP成熟度級別

5.3. PSP質量管理

質量管理是對質量的管理，必須包含管理三要素。

質量實踐包括測試等等

5.3.1. PSP的質量觀與質量策略

軟件項目的日程、成本及質量三大目標統一于質量目標

軟件質量是與軟件產品滿足規定和隱含的需求能力有關的特征或者特征的全體。

軟件質量的內外兩部分的特性

內部質量特性：不直接面向用戶

外部質量特性：面向軟件產品的最終用戶

軟件質量的不同視角

軟件質量為軟件產品可以改變世界，使世界更加美好的程度(用戶滿意度是最為重要的判斷標準)

軟件質量是對人的價值，強調質量的主觀性(對同一款軟件而言，不同的用戶對其質量有不同的體驗)

面向用戶的質量觀

定義需求為滿足用戶需求的程度

這個定義中需要進一步明確：用戶究竟是誰？用戶需求的優先級是什么？用戶的優先級對軟件產品的開發過程產生什么影響？怎么度量這種質量觀下的質量水平？

指導意義：開發在前，運維在后；高質量開發確保DevOps中的價值順暢流動；個體軟件工程師的技能、過程直接影響產品質量；PSP關注提升個體軟件工程師工程技能

質量策略：

使用缺陷管理來代替質量管理

首先確保沒有缺陷，然后再考察其他的質量目標。高質量的產品也就意味著軟件產品的各個組件基本無缺陷。

為什么有效？通過關注每個組件的質量可以避免在測試階段消除缺陷，減少消除代價，提高生產效率。

各個組件的高質量是通過高質量評審來實現的

5.3.2. 質量路徑(8個步驟)

各種測試

進入測試之前的產物質量提升

評審過程度量和穩定

質量意識和主人翁態度

個體review的度量和穩定

訴諸設計

缺陷預防

用戶質量關 —— 其他質量屬性

5.3.3. 評審與測試

測試消除缺陷

發現待測程序的一個異常行為

理解程序的工作方式

調試程序，找到出錯的位置，確定出錯的原因

確定修改方案，修改缺陷

回歸測試，以確認修改有效

評審消除缺陷

遵循評審者的邏輯來理解程序流程

發現缺陷的同時，發現了缺陷的位置和原因

修正缺陷

評審形式：打印后評審效果更好

單個屏幕可以展現的內容比較有限：不能完整展示整體結構、安全、性能等

使用屏幕的評審，評審人員的注意力容易被分散

評審時機

先編譯后評審

對于某些類型的缺陷而言，通過編譯發現并消除缺陷的效率是通過評審發現并消除的數倍。

一些基于解釋執行的集成開發環境，可以消除編譯錯誤。

先評審后編譯

節省編譯階段的時間：評審的速度和時間是一定的。

解決編譯器遺漏的缺陷。

編譯前評審是良好的學習機會，同時干凈的編譯給軟件工程師帶來極大的成就感。

評審的具體形式：先個人評審后小組評審

小組評審有利于更好的發現缺陷，預防風險，提高Process Yield來確保質量。

個人評審后安排小組評審，有利于提升個人技能。

評審預防過程中的缺陷數據選擇

選擇那些在系統測試、驗收測試以及應用環節出現的缺陷，特別是驗收測試和應用環節中的缺陷，這些缺陷往往意味著軟件開發過程本身有不足之處。

選擇那些在出現頻率較高或者消除代價較高的缺陷，這些缺陷如果可以預防，往往可以節省較多開發的代價，從而體現缺陷預防的優勢。

選擇那些預防方法容易識別和實現的缺陷，這樣的策略容易讓軟件工程師迅速看到缺陷預防的好處，鑒定使用缺陷預防策略的信心。

缺陷發現的效率：代碼評審 > 設計評審 > 設計檢查 > 代碼檢查 > 單元測試 > 系統測試

5.4. PSP度量

5.4.1. 基本度量項

度量時間：序號、所屬階段、開始時間、結束時間、中斷時間、凈時間、中斷原因

度量缺陷：序號、發現日期、注入階段、消除階段、消除時間、關聯缺陷、缺陷產生原因

度量規模：使用PROBE估算方法

度量日程(TSP)

5.4.1.1. 規模度量標準

選擇的度量方式必須反映開發成本。

選擇的度量方式必須精確。

選擇的度量方式必須能用自動化方法來統計。

選擇的度量方式必須有助于早期規劃。

5.4.1.2. 規模度量的困境

精確的度量方式往往不便于早期規劃。

有助于早期規劃的度量往往難以生成精確度量結果。

5.4.1.3. 解決方案：PROBE方法

估算原理

設計合理的代理作為精準度量和早期規劃所需要的度量之間的橋梁

使用相對大小而不是絕對大小

方法特點：非常依賴高質量的歷史數據，一旦數據不完整或者缺失，則會導致估算結果有偏差。

估算過程：估算是相關干系人達成一致共識的過程。

概要設計，確認產品功能，明確所需的程序組件/模塊，將這些組件/模塊與之前縮寫的程序比較，估算規模，得到總規模。

估算要點：盡可能劃分詳細一些、建立對結果的信息、依賴數據、估算關注的是過程而不是結果。

估算方法：以估算規模為例

簡單方法

$VS=\min ,S=\frac{VS+M}{2},M=median,L=\frac{M+VL}{2},VL=\max$

計算簡單，但是不穩定

正態分布法

$VS=M?2\sigma ,S=M?\sigma ,M,L=M+\sigma ,VL=M+2\sigma$，均值為$M$，標準差為$\sigma$

相對穩定，在歷史數據基本符合正態分布的情況下，可以給出非常好的相對大小矩陣

對數正態分布法

首先計算所有的數據的自然對數(以e為底)，得到之后的數據的均值$M$，標準差$\sigma$，之后VS、S、M、L、VL計算方法同正態分布法，然后取反對數

優點：符合人們對程序規模的直觀感覺，大多數人習慣寫大量規模小的程序，少量規模大的程序

線性回歸方法

項目所需的資源并不是直接由程序規模和歷史數據中的生產效率相處得到。為什么？因為程序規模和生產效率都在一個范圍內波動，如果直接相除會導致更大誤差。

估算了一定概率條件下的估算值的分布。

Range是一定條件下的變化區間，p為概率

Variance是擾動程度：有時候，歷史數據中的一些極端數據會造成相關性假象，因此需要先進行數據降噪

$$\begin{array}{l}PlanSize={\beta }_{0size}+{\beta }_{1size}(E)\\ PlanTime={\beta }_{0time}+{\beta }_{1time}(E)\\ Range=t(p,df)\delta \sqrt{1+\frac{1}{n}+\frac{(x_k?x_{avg}{)}^2}{\sum _{i=1}^n(x_i?x_{avg}{)}^2}}\\ Variance={\delta }^2=\frac{1}{n?2}\sum _{i=1}^n(y_i?{\beta }_0?{\beta }_1{x}_i{)}^2\end{array}$$

處理有限的歷史數據

為什么可以使用歷史數據完成，使用代理規模與實際程序規模之間的關系完成規模估算？因為規模估算產生偏差的原因相對客觀，偏差可以用來修正新的估算結果。

為什么時間估算的偏差產生原因更加復雜：一方面和規模有關，另一方面和人的主觀能動性有關。

其中r為相關性(兩組數據之間相互關聯的程度，PSP中要求r>= 0.7)，其中S為顯著性(兩組數據的相關關系出現的偶然性，PSP要求s<=0.05)

5.4.2. 衍生度量項

5.4.2.1. Yield指標

定義了每個階段在消除缺陷方面的效率。越大越好，希望在80以上。

Yield指標是一種事后的質量控制手段，很難非常精確地計算。

Cannot read properties of undefined (reading 'type')

例子：

階段InjectedRemovedremainYield

DFD	10	0	10	0
DFD REVIEW	0	4	6	40
CODING	20	2	24	1/13 * 100
CODE REVIEW	0	12	12	50
UNIT	0	12	0	100

IBM：最后的測試如果發現了一個錯誤，那么其中一定還有一個錯誤沒有被發現（所以最后的Yield的值為50）

階段InjectedRemovedremainYield

DFD	10+4	0	14	0
DFD REVIEW	0	4	10	2/7 * 100
CODING	20+8	2	36	2/19 * 100
CODE REVIEW	0	12	24	1/3 * 100
UNIT	0	12	12	50

基于Yield指標構建缺陷預測模型，并列舉該模型的可能改進方案

總體思想：利用回歸技術預測軟件開發過程中各階段的Inject Rate(缺陷注入率)和Yield(缺陷消除率)

Yield指標只能用來估算，不可以用來度量。結合Yield指標和上圖，只需要知道如下指標就可以基于Yield指標構建一個基本的缺陷預測模型：

注入階段注入多少缺陷

缺陷注入的密度（需求每一頁注入多少缺陷）

缺陷注入的速度（每小時注入多少缺陷）

消除階段的缺陷注入密度和速度。

歷史數據中的軟件規模、文檔規模、開發人員規模

步驟

確定納入影響因子的數據以及數據度量方法

從系統歷史庫中收集歷史數據，并進行整理

依照回歸技術進行計算

在項目進行過程中不斷收集數據，與預測數據進行比較，調整回歸參數

項目過程中依據實際數據與預測數據的誤差進行風險的預防、識別和控制

改進方案

維護歷史數據：歷史數據在簡單性、可理解性、穩定性、可度量性、相關性等方面的質量都有影響。

影響因子的選擇：不僅僅有軟件規模的數據，還需要有開發過程、文檔、人員等方面的數據，并將其可度量化。

反饋模型：隨著開發實際數據的產生，將這些數據作為輸入變量放回模型來調整參數。

蒙特卡洛方法：假設注入水平和消除水平都符合正態分布，計算均值和標準差并用蒙特卡洛方法模擬結果。

5.4.2.2. A/FR

COQ(Cost of Quality)

失效成本：分析失效現象、查找原因，做必要的修改所消耗的成本

質檢成本：評價軟件產品，確定其質量狀況所消耗的成本

預防成本：識別缺陷根本原因、采取措施預防其再次發生所消耗的成本

質檢失效比

A/FR = PSP質檢成本 / PSP失效成本

質檢成本 = 設計評審時間 + 代碼評審時間

失效成本 = 編譯時間 + 單元測試時間

理論上，A/FR值越大，意味著質量越高，但A/FR值過大說明評審過多，則開發效率低下，因此PSP中A/FR期望值為2.0

5.4.2.3. PQI

為5個數據的乘積(以基準值作為1，最后結果越接近1，質量越高)

設計質量：設計時間應該大于編碼時間，$\min (\frac{設計時間}{編碼時間},1)$

設計評審質量：設計評審的時間應該大于設計時間的50%，$\min (2?\frac{設計評審時間}{設計時間},1)$

代碼評審質量：代碼評審時間應該大于編碼時間的50%，$\min (2?\frac{代碼評審時間}{編碼時間},1)$

代碼質量：代碼的編譯缺陷密度應當小于10個/千行，$\min (\frac{20}{編譯缺陷密度+10},1)$

程序質量：代碼的單元測試缺陷密度應當小于5個/千行，$\min (\frac{10}{單元測試缺陷密度+5},1)$

用途：判斷模塊開發質量、規劃質量活動、過程改進。

5.4.2.4. Review Rate

評審的速度是一個用以指導軟件工程師開展有效評審的指標

代碼評審速度小于200 LOC(代碼行)/h

文檔評審速度小于4 page(文檔采用頁)/h

###? 5.4.3.2. DRL Defect-Removal-Leverage 缺陷消除效率比

缺陷消除效率比：不同缺陷消除手段消除缺陷的效率

計算方法：以某個測試階段(一般為單元測試)每小時發現的缺陷數為基礎，其他階段每小時發現缺陷數與該測試階段每小時發現的缺陷的比值就是DRL

5.4.2.5. 度量的作用

度量體現著決策者對試圖要實現的目標的關切程度。

度量幫助過程的實踐者了解過程狀態，理解過程偏差。

5.4.3. 考試題

對比度量方式 LOC 和 FP

LOC

LOC優點：LOC是軟件開發項目的生成品，容易進行計算

LOC缺點

LOC測量依賴于程序設計語言，不同語言產生結果存在偏差

對代碼量少但設計精巧的程序產生不利評判

不適合非過程語言

在軟件項目開發前或開發初期估算代碼行數非常困難

FP

FP優點

和程序設計語言無關

面向過程和非過程語言均適合

基于項目開發初期就可能得到的數據

FP缺點：計算基于主觀而非客觀數據

隨著軟件工程產業化分工加劇專門從事軟件下游基礎業務的商業組織增多，使得基于LOC的度量方式逐漸失去意義，而基于FP的度量方式顯得更加符合要求

請結合A/FR、PQI、Review Rate、DRL、Yield盡可能具體描述?個軟件項?應該如何
從多??來確保開發的?質量（本題滿分10分）

這些指標既是開發過程中質量管理的?些參考指標，同時也體現在計劃安排中應該注意的
質量元素。具體如下：

在項?計劃過程中應該安排確保?質量開發結果的活動，例如，按照A/FR、PQI等指標
的要求，安排對各類產物（?檔和代碼）的個?評審和?組評審；

這些評審活動應該滿??定的要求，特別體現在時間??。例如，評審時間應該多于
測試時間的兩倍以上（A/FR）；評審時間應該是相應開放時間的50%以上（PQI）；評
審速度要求（Review Rate）等

充分借鑒質量指標所體現的開發質量狀況，盡早制訂相應的質量補救措施。例如，PQI
所體現的缺陷密度、所有上述指標的參考值等等。?旦超標，往往意味著質量??有
偏差，應當及時補救。

利?yield等指標，構建質量預測模型，更加積極（Proactive）地判定和控制開發質量；

依據PQI和Yield指標所體現的信息，通過過程改進來提升開發質量。

5.5. 通用計劃框架

上述框架中，那些步驟必須人為的干預

定義需求

概要設計：劃分由人為開始，規模劃分好之后估算是自動產生的

日程計劃

這會帶來什么的好處？比較容易扛住別人的質疑。

攻擊點：資源和時間是否被高估了

解決：估算沒有代碼行PROBE只有功能點是大中小。

考試題：【2020-mid】請簡要描述按照通用計劃框架，為了開發合理的項目計劃，應該要做哪些估算？PROBE方法充當什么角色。

估算框架如上圖

虛線框即為PROBE，用來完成規模和資源的評估

5.6. 個體軟件過程的設計

設計 vs. 質量

低劣的設計是導致在軟件開發中返工、不易維護以及用戶不滿的主要原因。

充分設計可以顯著減少最終程序的規模，提升質量

設計本身也是一種排除錯誤的過程。

設計內容：設計目標程序

在整個系統內的位置

使用的方式

與其他組件以及模塊之間的關系

外部可見的變量和方法

內部運作機制

內部靜態邏輯

設計的過程

四種設計模塊

操作規格模板(Operation Specification Template)：描述系統與外界的交互，定義測試場景和測試用例。

功能規格模板(Functional Specification Template)：描述系統的對外接口，用形式化符號描述方法行為，消除二義性。

狀態規格模板(State Specification Template)：精確定義程序的所有狀態、狀態之間的轉換以及伴隨每次狀態轉換的動作。

邏輯規格模板(Logical Specification Template)：精確描述系統的內部靜態邏輯，使用偽代碼配合形式化符號來消除二義性。

動態信息靜態信息

外部信息	交互信息(服務、消息等), OST/FST	功能(繼承、類結構等)，FST
內部信息	行為信息(狀態機)，SST	結構信息(屬性、業務邏輯等)，LST

不同的設計層次

設計驗證方法

狀態機驗證

檢查狀態機，消除死循環和陷阱狀態：使用狀態機

檢查狀態轉換，驗證完整性(任何一個狀態+任何一個條件的組合的下一個狀態轉換都有定義)和正交性(狀態機中任何一個狀態的下一個狀態的轉換條件都不能相同)：使用真值表

評價狀態機，檢驗是否體現設計意圖

符號化驗證：實施簡單，適合不復雜的算法(遺漏系統的改造)；不適合復雜邏輯的場合，純手工驗證方法容易引入錯誤。

識別為偽碼程序中的關鍵變量

將變量使用代數符號表示，重寫偽碼程序

分析偽碼程序的行為

執行表檢查：實施簡單，結果可靠，可用于復雜邏輯的驗證；每次只能驗證一個用例，手工驗證比較耗時，容易引入錯誤。

識別偽碼程序的關鍵變量

構建表格，表格左側填入主要程序步驟，右側填入關鍵變量

初始化被選定的變量

跟蹤被選擇的關鍵變量的變化情況，從而判斷程序行為

跟蹤表驗證：通過符號化、用力識別等方法對程序的一般化行為進行驗證，是執行表驗證的補充，可以每次驗證多個用例。

識別偽碼程序的關鍵變量

構建表格，表格左側填入主要程序步驟，右側填入關鍵變量

初始化被選定的變量

識別將偽碼程序符號化的機會，并加以符號化

定義并且優化用例組合

跟蹤被選擇的關鍵變量的變化情況，從而判斷程序行動

正確性驗證：將偽碼程序作為數字定理，采用形式化方法加以推理和驗證。

分析和識別用例

對于復雜偽碼程序的結構，應用正確性驗證的標準問題逐項加以驗證

對于不能明確判斷的復雜程序結果，使用跟蹤表等輔助驗證

6. TSP 團隊軟件過程

6.1. 需求開發

需求分類

客戶需求：描述客戶的期望，使用戶解決問題的期望。

產品需求：描述開發團隊所提供的解決方案。

產品組件需求：描述組成產品的各個組件的需求規格。

為什么"需求是一切工程活動的基礎"

設計活動一定是依據需求而開展的。

V&V活動也是圍繞需求展開的

驗證(Verification)是檢驗獲得的產品和產品組件能不能滿足事先已經定義好的需求規格。

確認(Validation)是為了確保產品可以滿足客戶的需求以及實際操作場景的要求。

需求也是項目計劃活動的關鍵輸入。

需求開發的活動

需求獲取：采用"誘導"式獲取客戶的顯式需求和隱形需求，盡可能的識別客戶的期望與所受到的限制。

需求匯總：整理各種來源的信息，識別缺失的信息，解決沖突的需求(需求的整理和轉化、推導未顯式描述的需求內容)

需求驗證：對需求進行分析和確認，以確保符合使用者預期

需求文檔制作

完成標志：形成完整的、規范的、經過評審的需求規格說明書。

意義：使得用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，使之成為整個開發工作的基礎。

優秀文檔的特征：內聚、完整、一致、原子、可跟蹤、非過期性、可行性、非二義性、強制性、可驗證性

6.2. 團隊設計

發揮團隊智慧的兩大挑戰

確定整體架構之前很難進行分工

鼓勵團隊成員在討論和評審會議中的參與程度

設計標準：命名規范、接口規范、系統出錯信息、設計表示標準

復用性支持：復用接口標準、復用文檔標準、復用質量保證機制

可測試性支持：盡可能減少測試代碼的數量、制作合理的測試計劃

可用性考慮：

可用性問題需要在設計階段就開始考慮(而不能推遲到實現階段)

針對每一個關鍵功能都定義操作概念和操作場景

分析操作場景以確保軟件系統開發完成后，系統使用者會滿意

必要時，可以邀請最終用戶參與場景的評審

設計的文檔化

6.3. 實現策略

評審的考慮：

設計時采用自頂向下、逐層精化的方法，有利于建立系統的整體觀。

實現時采用自底向上的方法，方便底層模塊的評審和復用。

復用策略

自底向上的開發策略。

編碼注釋的應用：統一規格，標明功能

站立式會議：

可測試性考慮：實現計劃必須與測試計劃一致

6.4. 集成策略選擇

大爆炸集成策略：將所有已經完成的組件放到一起進行一次集成

優點：測試用例很少。

缺點：需要所有有待集成的組件質量比較高，否則難以定位缺陷位置，從而消耗很多測試時間；系統越復雜，規模越大，問題越突出。

逐一添加集成策略：一次添加一個組件的方式進行集成。

優點：容易定義缺陷位置(特別在產品組件質量不高的情況下)，每次集成前都有堅實的質量基礎。

缺點：需要非常多的測試用例；存在大量的回歸測試，測試時間成本大。

集簇集成策略：對逐一添加集成策略的改進，把有相似功能或者有關聯的模塊優先記性集成，形成可以工作的組件，然后以組件為單位進行更高層次的集成

優點：可以盡早獲得可以工作的組件，有利于其他組件測試工作的開展。

缺點：過于關注個別組件，而缺乏系統的整體觀，不能盡早發現系統層面的缺陷。

扁平化集成策略：優先集成高層的部件，然后逐漸將各個組件、模塊的真正實現加入系統，即盡快構建一個可以工作的扁平化系統。

優點：可以盡早發現系統層面的缺陷。

缺點：需要編寫大量的樁程序，往往難以覆蓋系統應該處理的多種狀態。

6.5. 驗證與確認

兩種活動都是為了提升最終產品的質量而采取的措施

驗證(Verification)：檢驗獲得的產品和產品組件能不能滿足事先定義好的需求規格。

確認(Validation)：確保產品可以滿足客戶的需求以及實際操作場景的要求。

V&V的區別與聯系

驗證和確認的目的不同：

驗證的目的是確保工作產品與事先指定給該工作產品的需求一致。

確認的目的是確保開發完成的產品或者產品組件在即將使用該產品或者產品組件的環境中工作正確，關注的是客戶需求的滿足。

驗證和確認又是互相依存、關系緊密的兩個活動

驗證活動的依據來源于確認的目標，即產品組件需求必須與客戶需求一致。

驗證活動為確認活動提供前提條件，在完成產品需求和產品組件需求之前，考慮客戶需求是否滿足是沒有意義的。

V&V的活動

單元測試：驗證

集成：驗證

需求評審：確認

驗收測試：確認

驗證確認

環境準備	評審則準備文件材料等，測試則準備模擬器等	模擬真實環境和場景
對象選擇	驗證對象從工作產品中選擇	確認對象從產品中選擇
活動實施	一般的評審和測試工作	包括早期對產品需求評審工作和最后的驗收測試
結果分析	關注直到驗收階段才被發現的缺陷

6.6. 工作分解結構 WBS Work Breakdown Structure

工作分解結構是以可交付成果為導向對滿足項目目標和開發交付產物的項目相關工作進行的分解。

將復雜的項目逐步分解為一系列明確定義的工作任務并作為隨后計劃活動的指導文檔。

6.6.1. 作用/特點

提供項目范圍基線，是范圍變更的重要輸入。

可以展現項目整體觀，使得團隊成員更加集中注意力實現項目的目標。

為開發項目提供一個整體框架，防止遺漏項目的可交付成果。

使得項目中各個角色職責更明確，幫助項目團隊的建立和獲得下項目項目的承諾。

為評估和分配任務提供具體的工作報告的定義，工作報告可以分配給項目某個成員或者另一個團隊。

是進行估算和編制項目日程計劃的基礎。

可以幫助項目團隊理解工作內容，分析項目的風險。

6.6.2. 創建工作分解結構的步驟

識別和分析可交付成果以及相關工作。

確定工作分解結構的結構與編排方法。

自上而下逐層細化分解。

為工作分解結構組成部分制定和分配標志編碼。

核實工作分解的程度是必要且充分的。

6.6.3. 好的工作分解結構的檢查標準

最底層要素不能重復，即任何一個工作應該在WBS中的一個地方且只應該在WBS中的一個地方出現。

所有要素必須清晰完整定義，即相應的數據詞典必須完整定義。

最底層要素必須有定義清晰的責任人，可以支持成本估算和進度安排。

最底層要素是實現目標的充分必要條件，即項目的工作范圍得到完整體現。

6.6.4. 范圍管理

項目范圍包括確保項目做且只做完成項目所需的全部工作的各過程

工作分解結構為項目范圍管理提供了基礎：收集需求、定義范圍、創建工作分解結構、核實范圍、控制范圍變更。

6.7. 開發策略與計劃

開發策略與計劃是在產品組件需求之上，明確每個產品組件的獲得方式與順序，從而在項目團隊內部建立起大家夠理解的產品開發策略。

6.8. 生命周期模型選擇

6.9. 計劃

任務計劃描述了項目所有的任務清單，任務之間的先后順序以及每個任務所需時間資源。

日程計劃描述了每個任務在日志上的安排，即每個任務計劃哪天開始和計劃哪天結束。需要考慮資源平衡(所有團隊成員幾乎同時完成任務)、資源同步。

質量計劃中應當確定需要開展的質量保證活動。

風險計劃

制定資源計劃，結合任務計劃就可以定義日程計劃

6.9.1. 風險管理

風險管理是一個持續的、前瞻性的過程，需要相關干系人的合作與參與，盡快且積極地識別風險，指定項目風險管理機會。

風險管理的目標是：在風險發生前，識別出潛在的問題，以便在產品或項目的生命周期模型中規劃和實施風險管理活動，以消除潛在問題對項目產生的負面影響。

為什么早期風險偵測是重要的？在項目初期進行變更或修改的工作負荷，通常比在項目后期來得更容易、花費較低且不具破壞性。

風險管理包含

風險識別

風險：沒有發生，有一定概率會發生，發生后有一定影響

問題：已經發生，比如人員調動等

典型識別方法：檢查WBS的每個組件、使用定義好的風險分類表、訪談相關領域專家、與類似項目進行比較、檢查以往項目的總結報告、檢查設計規范和需求

風險應對：識別風險后，就應當制定相應的風險管理策略，以應對各類風險。

風險轉嫁：通過某種安排，在放棄部分利益的同時，將部分的項目風險專家到其他的團隊或者組織。

風險解決：指采用一些有效措施，使得風險的來源不再存在，往往是預防性的手段。

風險緩解：指容忍風險的存在，采用一些措施監控風險，不讓風險對項目最終目標的實現造成負面影響?？梢酝ㄟ^降低發生可能性/損失程度。

6.9.2. 計劃評審與各方承諾

計劃完成后，需要與各類計劃的相關干系人開展評審工作，達成完整或臨時的承諾，由適當層次的人員簽署。

6.10. TSP的九次會議

經過平衡的計劃和沒有平衡的計劃有什么不一樣？更有把握去成功。

開發和測試都是既有可能引入缺陷，也有可能消除缺陷的階段.

6.11. 項目追蹤

項目追蹤的意義：了解項目進度，識別項目實際進展和計劃(參照物)的偏差，并且采取適當的糾正措施。

6.11.1. 掙值管理方法 EVM Earned Value Management

掙值管理方法是用來客觀度量項目進度的一種項目管理方法。

EVM采用進度計劃、成本預算和實際成本三個獨立的變量，進行項目績效測量

EVM不可以支持質量管理

6.11.1.1. 掙值管理實現

簡單實現：僅僅關注進度信息。

實現方式

首先需要建立WBS，定義工作范圍

其次為WBS中每一項工作定義一個計劃價值（PV, Planned Value）

最后按照一定的規則將某一數值賦給已經完成的工作或者正在進行的工作，該值成為掙值(EV, Earned Value)

常用規則

0-100原則：只有當某項任務完成時，該任務的PV值將轉化成EV值

50-50原則：只需要開始某項任務，即可以賦原PV值的50%作為EV值，完成時，再加上另外的50%

實際完成的工作所需成本AC不對EV值產生任何影響

中級實現

在簡單實現的基礎上，加入日程偏差的計算，加入了成本線(AC)

典型計算方式有

日程偏差SV = EV – PV

日程偏差指數SPI = EV/PV；

高級實現：添加預測線（BAC），當任務足夠多的時候，我們就可以讓預測線盡可能平直，同時我們延伸掙值（EV），找到與預測線（BAC）的交點，我們就可以明確項目的落后時間

6.11.1.2. 掙值管理圖解

上面的線是為了獲取這些掙值付出的實際代價，這個線和掙值之間的差異是成本差異。

中間的線是預算（每天需要完成多少掙值）BAC，理想情況下是一條直線。

下面的線是掙值（實際的進展情況）（EV），和owner value有關，對應plan value

實際獲取掙值和預計獲取掙值的差異是進度差異。

例子：

一共100個值（計劃投入時間），第一天需要完成50個值，第二天需要完成20個值，第三天需要完成30個值。

BAC：第一天50，第二天70，第三天100.

超期情況，EV：第二天50值，AC：第二天100值。

這就意味這這兩天投入了100個值完成了原計劃用50個值完成的工作，這就對應著進度落后，成本超支。

CV = 50，SV = 20

有可能出現第二天用戶說，任務B和任務C不做了（項目進度落后變為了項目進度正常）

掙值管理會帶來什么好處？可以很好的適應項目的動態變化。

6.11.1.3. 掙值管理的度量

BAC表示按照PV值的曲線，當項目完成的時候所需預算或者時間

成本差異CV = EV-AC，表示的是已經完成的工作與所消耗的成本的差異?？梢员硎緸橄牡臅r間，也可以表示為消耗的資金。

成本差異指數CPI = EV/AC，表示單位成本創造的價值

CPI<1說明成本超支

CPI=1說明成本與預期一致

CPI>1說明成本低于預期。

日程偏差SV = EV – PV，表示進度偏差。

SV<0表示進度落后；SV=0表示進度正常

SV>0表示進度超前。

日程偏差指數SPI = EV/PV

預計完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的進展已經成本消耗情況，整個項目完成的時候所需消耗的成本。

6.11.2. 燃盡圖：掙值管理的變形

燃盡圖是簡單的掙值管理的變形。

他是剩下的工作占的百分比。

6.11.3. 里程碑評審

軟件項目的里程碑往往是某個時間點，用來標記某些工作的完成或者階段的結束。比如完成某項工作、獲得干系人簽字認可、完成某產品的評審、修改或交付某產物。

里程碑評審的審查內容：項目相關承諾、各項計劃的執行狀況、當前的狀態討論、面臨的風險討論。

6.11.4. 糾偏活動管理

偏差原因分析：收集信息，分析信息，找出偏差的根本原因

糾偏措施定義：確認偏差的根本原因，定義糾偏的措施。

糾偏措施管理：管理糾偏措施直到結項。

6.11.5. 項目審查

6.12. 項目總結

基于PMBOK的總結方式：包含范圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、風險管理、采購管理和整合管理9大知識領域(每個領域具體內容見Lec-4)

基于TSP的項目總結方式

準備階段

過程數據評審階段：由過程經理或質量經理帶領整個團隊分析過程數據，識別過程改進機會。

人員角色評價階段

總結報告撰寫階段

意義：提供一個系統化的方式來總結經驗教訓，防止犯同樣的錯誤、評估項目團隊績效、積累過程數據等，給項目團隊成員持續學習和改進的機會。

6.13. 項目管理支持活動

6.13.1. 配置管理

目的：建立與維護工作產品的完整性。

概念

配置項：在配置管理當中作為單獨實體進行管理和控制的工作集合。

基線：一個或多個配置項及相關的標識符的代表，是一組經正式審查同意的規格或工作產品集合，是未來開發工作或交付的基礎，而且只能經由嚴格的變更控制程序才能改變。

發布時間點：需求分析后、設計完成后、單元測試后、最終產品發布后

配置項持續演進的穩定基礎

配置管理活動：

如何控制變更

跟蹤變更請求：啟動程序、分析影響、審查相關項、跟蹤直到結項

控制配置項變更：確認授權、更新配置項、歸檔舊基線、獲取新基線、執行審查

6.13.2. 度量和分析

目的：支持管理的信息需要。

度量和分析活動

意義：基于客觀的數據對決策很重要，可以顯著消除錯誤決策的風險。而客觀數據的獲取需要按照一定的流程用正確的方式獲得和使用。

6.13.3. GQM方法

GQM(Goal Question Metric)是一種應用非常廣泛的建立軟件度量體系的方法，從管理的目標出發，將目標歸納、分解為度量的指標，并把這些指標提煉成可以測量的值，是一種科學的、系統的思考問題的方式。

概念層(目標)：目標是為某個特定的對象而定義的。這里的對象是指軟件產品、軟件過程以及相關的資源等。定義的目標基于不同原因和不同質量模型,也要參考不同的角色視圖與特定的環境。

操作層(問題)：基于一定的刻畫上述目標是否達成或者目標達成的進展情況的模型，使用一系列的問題來定義所研究的對象, 然后得出評價或評估特定目標達成進展情況。所選擇的問題應當盡量體現質量相關的話題。

量化層(度量)：試圖以量化的方式回答上述操作層識別出來的問題。

6.13.4. 決策分析

決策分析的活動

決策分析的意義：錯誤的決策往往會給項目帶來災難性后果。為了降低這種錯誤決策的風險，往往需要盡可能基于客觀事實和正確的流程來開展決策與分析活動

6.13.5. 根因分析

避免類似錯誤反復發生

6.14. 團隊動力學

軟件開發特點

軟件開發是一項既復雜又富有創造性的知識工作。

軟件開發是智力勞動，需要處理和討論極其抽象的概念，并將不同的部分整合成一個可以工作的系統。

要求從事軟件開發的工程師必須全身心的參與工作、主觀意愿上努力追求卓越。

要求管理者激勵并維持激勵

管理知識工作的關鍵規則：管理者無法管理工作者，知識工作者必須實現并學會自我管理。

6.14.1. 自主團隊

定義：

一個團隊必須包括至少兩個成員，他們為了共同的目標和愿景而努力工作，他們每個人都有明確的角色和相應的職責定義，任務的完成需要團隊成員互相依賴和支持。

如果團隊成員都實現了自我管理，也就形成了所謂的自主團隊。

特點：

自行定義項目的目標

自行決定團隊組成形式以及成員的角色

自行決定項目的開發策略

自行決定項目的開發過程

自行制定項目的開發計劃

自行度量、管理和控制項目工作

形成過程：不是偶然形成的，一開始團隊成員有不同的目標，經過一段時間的協同工作后，團隊成員慢慢適用，演化成自主團隊。

必要性：

自主團隊可以形成膠凍狀團隊

團隊成員互相支持，任何時刻都指導應該以怎樣的方式幫助別人，互相信任有強烈的歸屬感。

團隊在適當的時候會聚集在一起，研究現狀，討論策略。

外部環境：在項目啟動階段、項目進展過程中獲得管理層的支持

6.14.2. 激勵方式

威逼、利誘、鼓勵承諾(位于馬斯洛需求理論的4級以上，最好以團隊為單位)

威逼指完全依靠不同角色的等級關系強制要求下屬必須完成某些工作，滿足生理需求。

利誘是通過許諾一定的好處來吸引下屬努力工作，滿足生理需求和安全感

鼓勵承諾是通過建立承諾文化，利用軟件工程師希望得到別人尊敬的心理，鼓勵他們合理承諾并努力滿足承諾，從而獲得尊敬。

威逼和利誘屬于交易型領導方式，鼓勵承諾屬于轉變性領導方式。

承諾文化建立與團隊激勵

在滿足以下條件下，團隊承諾比個人承諾的激勵作用更大：所有成員參與、團隊依賴于每一位成員履行自己的承諾、有計劃支撐。

制定承諾時需要保證：承諾是自愿的、公開的、可信(行)的，向團隊做出承諾、有詳細計劃支撐，開發者參與。

及時提供各種反饋信息是維持激勵的有效手段。

需求理論

馬斯洛需求理論：勝利需求、安全感、愛和歸屬、獲得尊敬、自我實現

海茲伯格：激勵因素(內在因素，成就感等)、保健因素(外在因素，薪水等)

麥克勒格的X理論：人性本惡，獨裁式的管理風格。

麥克勒格的Y理論：人性本善，民主式的管理風格。

期望理論：Motivation = Valence * Expectancy

M：激發力量，積極性

V：目標價值(效價)，達到目標對于滿足個人需要的價值，有正零負三種，效價越高，激勵力量越大

E：期望值，人們根據過去經驗判斷自己達到某種目標的可能性大小

6.15. TSP的典型角色

自行查看

7. 定量管理與仿真建模

一般的項目管理：CMMI的1-3級

主要關心當前狀態，是否需要調整干預

但是回答不了進行預測的問題。

高成熟度項目管理：CMMI的4、5級，也就是定量管理。

基于數據，主要關心當前狀態理解是否有信心，對偏差的理解

可以回答預測類的問題

為什么需要理解偏差：解決部分問題，比如希望10周以內交付，歷史數據表明類似任務是9-11周完成。

定量管理基本范式：

構建定量模型：子過程能力基線、過程模型

應用模型：監控影響子過程的關鍵因素

概念

(子)過程性能：遵循某個特定（子）過程的之后產生結果的量化描述，既包括（子）過程度量Xi（例如，時間、缺陷消除效率、工時等），也包括產物度量Yi（例如，缺陷密度，相應時間等）。

(子)過程性能基線：上述過程性能的一個定量化的刻畫，一般包括均值和范圍。通常用作過程性能的benchmark。

過程或子過程性能模型：依據子過程的邏輯關系構建相應的數學模型，描述子過程性能基線和整體過程有意義的性能輸出（例如，質量、生產效率、成本等）之間關系。例如過程Yield和Phase Yield。

常用定量管理技術

非統計技術：一般是為了描述數據集整體特征或者關聯關系，從而幫助選擇適用的統計技術以應用于給定的數據集，以及調查通過數據分析檢測到異常的原因。例如，檢查表（或列聯表），帕累托圖，直方圖，因果圖，散點圖等。

統計技術：統計思維認識到許多決策是在不確定條件下做出的。統計方法有助于量化這種不確定性并指導采取行動以減少不確定性。常用的統計技術包括：統計過程控制圖，回歸分析，方差分析，預測區間，假設檢驗，敏感性分析等

8. DevOps

8.1. 精益

精益屋的兩大支柱：

準時化：只在顧客需要的時候，按照顧客所需要的量，生產顧客所需要的產品。

自動化：將人的智慧賦予機器

精益理論：降低批量規模、減少半成品，縮短并增強反饋回路，DevOps是IT價值流中應用精益理論的結果。

精益原則

全局優化：局部優化長期而言對系統整體優化不利

消滅浪費：避免構建錯誤的功能、拒絕學習、輾轉現象

品質為先：如果驗證中總能發現缺陷，那么流程就有問題

不斷學習：規劃工作非常有用，學習必不可少

盡快交付：建立穩定、連貫的工作流

人人參與

不斷提高

8.2. DevOps

Devops：開發運維一體化，是軟件開發、運維和質量保證三個部門之間的溝通、協作和集成所采用的流程、方法和體系的一個集合。

方法論基礎是敏捷軟件開發，精益思想以及Kanban方法

以領域驅動設計為指導的微服務架構方式

大量虛擬化技術的使用(開發、測試環境)

一切皆服務XaaS的理念指導

構建了強大的工具鏈，支持水平自動化

Devops與敏捷的關系

DevOps思想部分起源于一些運維工程師借鑒軟件敏捷開發思想

DevOps的早期活躍分子來自敏捷社區

公認的適用于DevOps的軟件過程方法是敏捷軟件開發，尤其是Kanban

Devops的特點

讓開發和運維共同為業務的成功負責

開發和運維技能一部分融合

Devops化的三個階段

System Thinking

充分理解工作流(從開發到IT運維再到客戶)，完成整體產品

實踐和方法：限制半成品、CI/CD

Amplify Feedback Loop

快速持續反饋，放大其效益，避免問題再次發生，從源頭上保證質量。

實踐和方法：持續改進、適當停止生產線

Culture Of Continual Experiment and Learning

培育不斷嘗試、重復和練習的文化

實踐和方法：營造用于創新、敢于冒險以及高度信任的企業文化。

DevOps與敏捷開發

8.3. 軟件架構

什么是軟件架構

架構是一系列重要決策的集合，包括：軟件的組織，構成系統的結構要素和接口選擇，元素在協作中的行為

架構是計算組件和組件之間的交互：連接件和約束

微服務架構：將單一應用程序開發為一組小型服務的方法。每個服務運行在自己的進程中，將應用拆分成多個小業務單元來開發和部署，使用輕量級協議通信，通過協同工作實現應用邏輯的架構模式。

微服務的理念：分而治之，本質上也是分布式架構(面向服務(SOA)的一種擴展)

特點

應用程序分解為具有明確定義了職責范圍的細粒度組件

完全獨立部署，獨立測試，并可復用

使用輕量級通信協議，HTTP和JSON，松耦合

服務實現可使用多種編程語言和技術

將大型團隊劃分成多個小型開發團隊，每個團隊只負責他們各自的服務

8.4. 一些概念

云計算是一種按量付費的模式，這種模式可以提供可用的、邊界的、按序的網絡訪問，進入可配置的計算資源共享池(資源包括網絡、服務器、存儲、應用軟件、服務)，這些資源能夠被快速提供，只需投入很少的管理工作，或與服務供應商進行很少的交互。

XaaS表示一切皆服務，它是一個統稱(anything as s Service或everything as a Service)

典型的三大XaaS

Software as a Service (SaaS) 軟件即服務，軟件分發方式，中心化，服務供用戶訂閱。

Infrastructure as a Service (IaaS) 基礎設施及服務，虛擬化，用戶需要配置和部署中間件和應用服務。

Platform as a service (PaaS) 平臺即服務，服務供應商提供開發的整體環境。

云原生是一種基于微服務的軟件架構思想以及基于Devops進行軟件開發實踐的一組方法論

容器通常指在一個隔離的環境中運行的進程以及進程所依賴的環境的總稱。

CI/CD：持續集成、持續交付、持續部署。

Docker：容器將一個軟件封裝在一個完整的文件系統中，該文件系統包含它運行所需的一切：代碼、運行時、系統工具、系統庫

Git：分布式版本控制系統，強調速度、數據完整性和對分布式非線性工作流的支持

Jenkins：持續集成工具，配置流水線等

運維主要指軟件系統測試交付后的發布和管理工作，其核心目標是將交付的業務軟件和硬件基礎設施高效合理的整合，轉換為可持續提供高質量服務的產品，同時最大限度降低服務運行的成本，保障服務運行的安全

8.5. 幾個問題

JIT及時生產，價值流和價值拉動的關系

微服務架構對DevOps的影響

總結

以上是生活随笔為你收集整理的软件质量管理-考试复习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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