1. 軟件開發(fā)的四大本質難題

1.1. 四大本質難題是什么

不可見性：軟件項目是一個邏輯實體

復雜性：實體數量眾多

可變性

一致性

1.2. 四大本質難題之間的關系

除了不可見性以外，其他三個本質難題因項目而異。

四大本質難題互相促進。

本質難題變化帶動軟件方法（過程）演變。

1.3. 幾個注意點

軟件開發(fā)四大本質難題永遠存在，不可能徹底解決，在不同時期凸顯程度有差異。

軟件開發(fā)本質上是智力勞動，開發(fā)者心理方面的因素不可忽視

1.4. 考試題目

【2020-mid】關于Brooks提及的軟件開發(fā)本質難題，下列說法中不準確的是:(AB)

本質難題總共有四個，分別為復雜、不可見、可變和質量挑戰(zhàn)

既然是本質難題，那就說明是根植于軟件開發(fā)本身，因而是不可能在軟件開發(fā)當中得到緩解.

嚴格來說，只有不可見才是真正的“本質”難題，其他三個因項目而異

四大本質難題貫穿軟件發(fā)展的不同歷史階段，但是在不同歷史階段，相互凸顯程度不一樣

2. 軟件發(fā)展

軟件發(fā)展的兩個趨勢

軟件項目規(guī)模日益擴大：使得軟件越來越難做。

軟件在整個系統中的比重日益增加：將軟件質量問題的影響上升到前所未有的高度。

軟件危機：指落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發(fā)與維護過程中出現一系列嚴重問題的現象。主要體現有：

軟件開發(fā)費用和進度失控

軟件可靠性差

生產出來的軟件難以維護

用戶對“已完成”系統不滿意現象經常發(fā)現

軟件發(fā)展的三大階段

軟硬件一體化階段：軟件完全依附于硬件，軟件作坊（50年代到70年代）

軟件成為獨立的產品（70年代到90年代）

網絡化和服務化（90年代中期至今）

2.1. 軟硬件一體化階段

軟件完全依賴于硬件

軟件應用典型特征：軟件支持硬件完成計算任務、功能單一、復雜度有限、幾乎不需要需求變更。

軟件開發(fā)典型特征：硬件太貴、團隊以硬件工程師和數學家為主。

典型軟件過程和實踐

非常線性

三思而后行（measure twice，cut once）

軟件作坊

軟件應用典型特征：功能簡單、規(guī)模小。

軟件開發(fā)典型特征：很多非專業(yè)領域人員涌入軟件、高級程序語言出現、質疑權威文化盛行。

典型軟件過程和實踐：

Code and Fix

編碼 + 改錯

【2020-mid】下列軟件應用和開發(fā)的典型特征中屬于軟硬件一體化階段的是?(BC)

可以通過引入操作系統，擺脫了硬件束縛：軟件成為獨立的產品

幾乎不需要考慮 需求變更

缺乏科班的軟件工程師

系統兼容對應軟件開發(fā)的成敗非常關鍵：軟件成為獨立的產品

2.2. 軟件成為獨立的產品

軟件應用典型特征：擺脫了硬件的束縛（OS）、功能強大、個人電腦出現 -> 普通人成為軟件用戶 -> 需求多變、兼容性要求、來自市場的壓力

典型軟件過程和實踐

形式化方法：將所有的方法當作數學方法，做數學化的檢驗，主要解決質量和正確性問題。

結構化程序設計和瀑布模型

自頂向下，逐步求精。

問題和不足（效率和質量）

形式化在擴展性和可用性方面存在不足。

瀑布模型成為一個重文檔、慢節(jié)奏的過程。

2.3. 網絡化和服務化

2.3.1. 網絡化和服務化

軟件應用典型特征：功能更復雜、規(guī)模更大、用戶數量急劇增加、快速演化和需求不確定、分發(fā)方法的變化（SaaS）

典型軟件過程和實踐：

迭代式（90年代中后期）大型軟件系統的開發(fā)過程也是一個逐步學習和交流的過程，軟件系統的交付不是一次完成，而是通過多個迭代周期，逐步來交付。

雪鳥會議和敏捷宣言

個體和互動 勝過 流程和工具

可以工作的軟件 勝過 詳盡的文檔

客戶合作 勝過 合同談判

響應變化 勝過 遵循計劃

盡管右項有價值，但是我們更重視左項的價值

XP eXtreme Programming 方法：偏重于一些工程實踐的描述

Scrum：管理框架和管理實踐。

KanBan

精益生產（豐田制造法）的具體實現

可視化工作流、限定WIP、管理周期時間

開源軟件開發(fā)方式：

一種基于并行開發(fā)模式的軟件開發(fā)的組織與管理方式。

Linus 定律：如果有足夠多的beta測試者和合作開發(fā)者，幾乎所有問題都會很快顯現，然后自然有人會把它解決。

“早發(fā)布，常發(fā)布，傾聽用戶的反饋”、“把你的用戶當作開發(fā)合作者對待，如果想讓代碼質量快速提升并有效排錯，這是最省心的途徑”、“設計上的完美不是沒有東西可以再加，而是沒有東西可以再減”

代碼管理：嚴格的代碼提交社區(qū)審核制度、內部開源（inner source）、眾包（Crowdsourcing）

2.3.2. 更深化的網絡化和服務化

軟件應用典型特征

進一步服務化和網絡化（移動是主流）隨處可見（pervasive）

用戶需求的多樣性進一步凸顯

軟件產品和服務的地位變化

錯綜復雜的部署環(huán)境。

近乎苛刻的用戶期望

多：功能豐富，個性化

快：快速使用，及時更新，快速解決問題

好：穩(wěn)定，可靠，安全，可信

省：用戶的獲得成本低，最好免費

軟件開發(fā)的典型特征

空前強大的開發(fā)和部署環(huán)境：XaaS，IaaS、PaaS、SaaS

盛行開源和共享文化

盛行敏捷開發(fā)

軟件工程的潛在支撐力量獲得了長足進步（AI、大數據、云計算）

典型軟件過程和實踐：DevOps

開發(fā)運維一體化

方法論的基礎是軟件敏捷開發(fā)、精益思想和看板KanBan方法

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

大量虛擬化技術的使用

一切皆服務XaaS的理念指導

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

2.4. 考試題目

【2018】軟件發(fā)展三大階段的特點和主流開發(fā)方法

軟硬件一體化

特點：軟件支持硬件完成計算任務、功能單一、復雜度有限、幾乎不需要需求變更

主流開發(fā)方法：三思而后行；Code and Fix；編碼 + 改錯

軟件成為獨立的產品

特點：擺脫了硬件的束縛(操作系統)、功能強大、個人電腦出現、需求多變、兼容性要求、來自市場的壓力

主流開發(fā)方法：形式化方法、結構化程序設計和瀑布模型

網絡化和服務化

特點：功能更復雜、規(guī)模更大、用戶數量急劇增加、快速演化和需求不確定、分發(fā)方式的變化、進一步的服務化和網絡化、盛行開源和共享文化

主流開發(fā)方法：迭代式開發(fā)、敏捷開發(fā)(XP、Scrum、Kanban)、開源軟件開發(fā)方式、DevOps

【2020-mid】請結合軟件發(fā)展的三大階段，描述不同階段的典型軟件開發(fā)方法和實踐

(3’)軟硬件一體化：線性順序過程、事實上是硬件開發(fā)流程，measure twice cut once

(3’)軟件成為獨立產品：結構化程序設計、瀑布聲明周期模型、成熟度運動

(4’)網絡化和服務化：迭代式開發(fā)、敏捷運動

3. 軟件工程

軟件工程是一門研究用工程化的方法構建和維護有效的、實用的和高質量的軟件的學科。

軟件工程的兩大視角

管理視角：能否復制成功？

技術視角：是否可以將問題解決得更好？

3.1. 管理

管理的三大關鍵要素：目標、狀態(tài)(是在接近目標還是在原理目標)和糾偏。

大部分情況下，管理僅僅是視圖復制其他地方(場景)的成功，但是這種復制一般不容易

軟件項目管理是為了降低/減少各種無謂的損耗來實現本該有的性能。

軟件過程改進是為了達到更好的效能，其中質量/缺陷是首要目標或限制。

3.1.1. 軟件項目管理

典型的三大目標：成本、質量和工期。

定義：軟件項目管理是應用方法、工具、技術以及人員能力來完成軟件項目，實現項目目標的過程。

軟件項目管理包括估算、計劃、跟蹤、風險管理、范圍管理、人員管理、溝通管理等等。

軟件項目管理的對象是各類軟件項目

可以細分為兩種管理視角：軟件過程與生命周期模型

【2020-mid】下列哪些項不屬于管理活動應該包含的要素?(ABD)

成本

質量

目標

工期

3.1.2. 軟件過程管理

軟件過程管理的對象是軟件過程。

軟件過程管理的目的是為了讓軟件過程在開發(fā)效率、質量等方面有著更好性能績效（Performance）

3.1.3. 軟件過程管理與軟件過程改進

兩者含義接近

軟件過程管理參考模型 CMM/CMMI，SPICE等。

軟件過程改進參考元模型 PDCA、IDEAL等。

3.1.4. 考試題

【2018】軟件項目管理和軟件過程管理

軟件項目管理是應用方法、工具、技術以及人員能力來完成軟件項目，實現項目目標的過程。

軟件過程管理是為了讓軟件過程在開發(fā)效率、質量等方面有著更好性能績效。

3.2. 軟件過程

軟件過程是為了實現一個或者多個事先定義的目標而建立起來的一組實踐的集合。這一組實踐往往有一定的先后順序，作為一個整體來實現事先定義的一個或者多個目標。

3.2.1. 廣義軟件過程

理論基石：軟件產品和服務的質量，很大程度上取決于生產和維護該軟件或者服務的過程的質量。

包括：技術、人員以及狹義過程。

同義詞：軟件開發(fā)方法、軟件開發(fā)過程。

凈室Clean Room方法、極限編程方法、Scrum方法、Gate方法

clean room工程過程和CMM管理過程互為補充

clean room比cmm更注重質量，更偏向于使用一些數學工具

更一般的，敏捷軟件過程/方法、輕量型過程/方法及重型過程/方法等描述也是恰當的。

3.2.2. 生命周期模型

生命周期模型是對軟件過程的一種人為劃分。

典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等。

3.2.3. 考試題目

【2018】【2020-mid】生命周期模型與軟件過程的區(qū)別和聯系

(3’)生命周期模型是對一個軟件開發(fā)過程的人為劃分。

(3’)生命周期模型是軟件開發(fā)過程的框架，是對軟件開發(fā)過程的一種粗粒度劃分。

(2’)生命周期模型往往不包括技術實踐。

【2020-mid】我們如何理解瀑布模型

(4’)瀑布模型不是單一模型，是一系列模型，覆蓋最簡單場景(過程元素少)到最復雜的場景(過程元素多)

(4’)軟件項目應該結合實際情況選擇合適過程元素的瀑布模型，基本原則是，項目面臨困難和挑戰(zhàn)越多，選擇的模型應該越復雜

(4’)軟件項目團隊往往低估項目的挑戰(zhàn)，選擇了過于簡單的不適用的瀑布模型

【2020-mid】下列名詞和術語中不屬于軟件過程的有哪些?(BD)

SCRUM

CMM/CMMI

GATE方法

IDEAL

軟件過程管理是軟件項目管理應該要實現目標：軟件過程管理和軟件項目管理完全是兩回事，項目過程管理應當有專門的人去做。因此并不是實現目標，錯誤的。

在公司導入敏捷過程是我們今年過程改進的主要目標：過程管理和過程改進是類似的，這個說法在概念上是合適的，但是操作的時候可能存在問題。

XP與CMM/CMMI是對立的兩種軟件開發(fā)方法：

CMM和CMMI并不是軟件開發(fā)方法，而是軟件過程管理和改進，CMM和CMMI是沒有較大區(qū)別的，錯誤的。

XP的觀念確實與嚴格的CMM/CMMI是對立的

XP是軟件開發(fā)方法，敏捷的

CMM/CMMI不適合當今互聯網環(huán)境的項目管理需求：CMM/CMMI是用來做過程管理和改進的，根本不是滿足項目管理需求的手段，正確的。

PDCA和IDEAL不適合在敏捷環(huán)境中使用：PDCA，IDEAL是軟件過程改進參考元模型，因此是適合在敏捷環(huán)境中使用的，錯誤的。

不同的軟件開發(fā)過程應該使用不同的生命周期模型，反之亦如此：生命周期模型是由人類劃分的，不一定，錯誤的，

3.2.4. 軟件過程管理/改進模型：CMM

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

級別：分為五個級別，一級為初始級，二級為可重復級，三級為已定義級，四級為已管理級，五級為優(yōu)化級。

3.2.5. 等級一：初始級 Initial

特點：處于該級別的組織基本上沒有健全的軟件工程管理制度。

每件事情都用特殊的方法去做：如果特定工程遇到有能力的管理員和一個優(yōu)秀的軟件開發(fā)組來做，則可能是成功的。

大多數的行動知識應付危機，而非事先計劃好的任務。通常的情況是，由于缺乏健全的總體管理和詳細計劃，時間和費用經常超支。

軟件過程完全取決于當前的人員配置，具有不可預測性。

要精確地預測產品的開發(fā)實踐和費用之類重要的項目，是不可能的。

3.2.6. 等級二：可重復級 Repeatable

特點：有些基本的軟件項目的管理行為、設計和管理技術是基于相似產品中的經驗。

采取了一些措施，這些措施是實現一個完備過程所必不可缺少的第一步。

典型措施包括：仔細地追蹤費用和進度。

不像第一級那樣，在危機狀態(tài)下才行動，管理人員在問題出現時便可發(fā)現，并立即采取修正行動，防止它們變成危機。

關鍵一點：沒有這些措施，要在問題變得無法收拾前發(fā)現它們是不可能的。在一個項目中財務的措施也可以為未來的項目擬定實現的期限和費用計劃。

3.2.7. 等級三：已定義級 Defined

特點：為軟件生產的過程編制了完整的文檔。

軟件過程管理方面和技術方面已經做了明確的定義，并且按需要不斷地改進過程。

采用評審的方法來保證軟件的質量。

這個級別可以引用CASE環(huán)境來進一步提高質量和產生率。

在第一級的過程中，高技術會使得該危機驅動過程更加混亂。

3.2.8. 等級四：已管理級 Managed

特點：公司對每個項目都設定質量和生產目標。

這兩個量將被不斷地測量，當偏離目標太多時，就采取行動來修正。

利用統計質量控制，管理部門能區(qū)分出隨機偏離和有深刻含義的質量或生產目標的偏離。

統計質量控制措施的一個簡單例子：是每千行代碼的錯誤率，相應的目標就是隨時間推移減少這個量。

3.2.9. 等級五：優(yōu)化級 Optimizing

目標：連續(xù)地改進軟件過程。

使用統計質量和過程控制技術作為指導。

從各方面獲得的知識將被運用在以后的項目中，從而使軟件過程融入正反饋循環(huán)，使生產率和質量得到穩(wěn)步的改進。

3.2.10. 考試題

【2015B】CMM的創(chuàng)始?是哪位_____? ?

Boehm

Juran

Humphrey

Crosby

3.3. 軟件過程管理/改進模型：CMMI Capability Maturity Model Integration 能力成熟度集成模型

刻畫了軟件團隊/組織從不成熟到成熟的每個階段的特征(也就是roadmap)

等級2和等級3關注的是當前狀態(tài)

等級4和等級5是根據結果(未來)來進行管理

3.3.1. 等級一：初始級

開發(fā)相對混亂，依賴個人英雄主義，沒有過程概念，救火文化盛行

軟件組織對項目的目標與要做的努力很清晰，項目的目標可以實現。

由于任務的完成帶有很大的偶然性，軟件組織無法保證在實施同類項目時仍然能夠完成任務，項目實施是否成功主要取決于實施人員。

3.3.2. 等級二：已管理級

項目小組體現出項目管理的特征，有項目計劃和跟蹤、需求管理、配置管理等。

軟件組織對項目有一系列管理程序，避免了軟件組織完成任務的隨機性，保證了軟件組織實施項目的成功率。

軟件組織在項目實施上能夠遵守既定的計劃與流程，有資源準備，權責到人，對項目相關的實施人員進行相應的培訓，對整個流程進行監(jiān)測與控制，并聯合上級單位對項目與流程進行審查。

從2級升級到3級的原因：固化最佳實踐，對小組而言是能夠更快地學習其他的做法。

3.3.3. 等級三：已定義級

公司層面有標準流程和相應的規(guī)范，每個項目小組可以基于此定義自己的過程，使得優(yōu)秀的做法可以在公司內分享。

軟件組織能夠根據自己的特殊情況及自己的標準流程，將這套管理體系與流程予以制度化。

軟件組織不僅能夠在同類項目上成功，也可以在其他項目上成功。

科學管理成為軟件組織的一種文化，成為軟件組織的財富。

3.3.4. 等級四：定量管理級

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

軟件組織的項目管理實現了數字化。

通過數字化技術來實現流程的穩(wěn)定性，實現管理的精度，降低項目實施在質量上的波動。

在這個級別我們希望能夠看到一個預測模型。

3.3.5. 等級五：優(yōu)化級

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

軟件組織能夠充分利用信息資料，對軟件項目在項目實施的過程中可能出現的次品予以預防。

能夠主動地改善流程，運用新技術，實現流程的優(yōu)化。

3.3.6. 一些理解

CMM/CMMI不適用于軟件開發(fā)的原因

CMM/CMMI并不是一種具體的軟件過程或者軟件開發(fā)方法

CMM/CMMI建立了一組有效地描述成熟軟件組織特征的準則。

CMMI是過程改進模型而非軟件過程或者軟件過程模型：CMMI指導軟件過程改進，不指導開發(fā)。

按照CMM/CMMI模型的要求，一個軟件組織應當定義使用本軟件組織特點的軟件過程，并且不斷優(yōu)化該過程，來更好地實現軟件組織的商業(yè)目標。

CMM/CMMI并不能作為檢驗軟件過程優(yōu)劣的標準：過程改進對不同企業(yè)的含義不一樣，成熟度等級無法脫離企業(yè)環(huán)境直接橫向比較。

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

一些誤解：

CMMI模型需要適當裁剪以適應公司的實際情況：需要裁剪的是公司內部定義的組織級開發(fā)流程和開發(fā)規(guī)范。

CMMI模型太重了，不適合互聯網時代的輕量級開發(fā)：這個說法的錯誤之處在于，不一定是CMMI重或者輕，而是，CMMI根本就不是開發(fā)模型。

CMMI模型只適合大公司、大項目，不適合小項目：首先沒人檢驗過；其次，項目的大小衡量本身也缺乏值得信賴的參考依據；最后，接受這種說法的人還是把CMMI當成是一種特殊的開發(fā)模型。

CMMI模型只適合需求不變或者很少變化的場合，不適合需求不確定，變化很多的場合：CMMI不是開發(fā)模型，與需求變化與否無關，談不上適應或者不適應。

CMMI不是過程優(yōu)劣的標準，也不適合用作公司之間的能力比較，說法怎么樣？對的，CMMI本身是有評級。（美國國防部訂單招標要求企業(yè)至少達到CMMI的3級。因為公司的能力需要絕對東西，也就是能力強，能力弱，而CMMI衡量的是相對的水平，CMMI僅僅關注在本公司的目標下的等級

更多討論：試論CMM/CMMI不適合在當前軟件開發(fā)當中應用的原因

3.3.7. 考試題

【2020-mid】請描述CMMI模型的5個等級的特征，并且解釋為何CMMI模型不應該是敏捷方法的對立面：

五個等級的特征

Initial 原始級別：開發(fā)相對混亂，依賴個人英雄主義，沒有過程概念，救火文化盛行

Managed 已管理級別：項目小組體現出項目管理的特征，有項目計劃和跟蹤、需求管理、配置管理等

Defined 已定義級別：公司層面有標準流程和相應的規(guī)范，每個項目小組可以基于此定義自己的過程，使得優(yōu)秀的做法可以在公司共享。

Quantitatively Managed 定量管理級別：構建預測模型，已統計過程控制的手段來管理過程

Optimizing 優(yōu)化級：繼續(xù)應用統計方法識別過程偏差，找到問題根源并消除，避免未來繼續(xù)發(fā)生類似問題。

原因解釋：

CMMI是過程改進模型，刻畫了軟件組織從不成熟到成熟的路線圖。

大部分敏捷方法都是開發(fā)方法

因此兩者是完全不同性質的事物，將兩者對立是不合適的。

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

PDCA模型的步驟：

分析現狀，找出問題

分析影響質量的原因

找出措施

擬定措施計劃

執(zhí)?措施，執(zhí)?計劃

檢查效果，發(fā)現問題

總結經驗，納?標準

遺留問題轉?下期PDCA循環(huán)

【2015B】【2016】請描述PDCA模型的主要步驟（5分）

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

IDEAL模型解決了軟件組織在各種質量改進環(huán)境下的需要。它包括了軟件過程改進周期中的五個階段，IDEAL是代表這五個階段的單詞的?字母。

I: Initiating 初始

D: Diagnosing 診斷

E: Establishing 建?

A: Acting 執(zhí)?

L: Leveraging 調整

3.6. 軟件過程管理模型：ISO/IEC 1504

也叫SPICE（Software Process Improvement and Capability Determination）

過程類別共有五種，分別是

客戶-供應商(CUS)過程

工程（ENG）過程

支持（SUP）過程

管理（MAN）過程

組織（ORG）過程

3.7. 軟件過程框架：RUP

Rational統一過程（Rational Unified Process）

最佳實踐

迭代式開發(fā)

管理需求

使用基于構件的體系結構

可視化建模

驗證軟件質量

控制軟件變更

RUP軟件開發(fā)生命周期

初始階段：建立業(yè)務模型，定義最終產品視圖，并且確定項目的范圍

精化階段：設計并確定系統的體系結構，制定項目計劃，確定資源需

構建階段：開發(fā)出所有構件和應用程序，把它們集成為客戶需要的產品，并且詳盡地測試所有功能

移交階段：把開發(fā)的產品提交給用戶使用

3.8. 軟件過程改進模型

重點關注“過程質量”，強調“持續(xù)改進”

獲得ISO 9000標準認證的企業(yè)應該具有CMM第2~3級的水平

3.9. 軟件質量管理發(fā)展：軟件質量大師的主要觀點和貢獻、工作

描述下述質量管理大師的主要觀點和貢獻，工作對軟件過程和項目管理的借鑒意義

3.9.1. Shewhart

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

提出PDS模型(計劃執(zhí)行檢查Plan-Do-See)，后被戴明進一步發(fā)展為PDCA。

3.9.2. 【2013】【2015B】【2016】Deming

質量改進：提出質量改進的思想，被稱為日本質量管理之父。

PDCA循環(huán)：提出PDCA循環(huán)，被稱為“戴明環(huán)”(Plan、 Do、Check、 Action)，為最基本的質量和管理工具

14條原則：

樹立改進產品和服務的堅定目標，采用新的思維方法

停止依賴檢驗的辦法獲得質量

不再憑價格標簽進貨

堅持不懈地提高產品質量和生產率

崗位培訓制度化

管理者的作用應突出強調

排除畏難情緒

打破部門和人員之間的障礙

不再給操作人員提空洞的口號

取消對操作人員規(guī)定的工作定額和指標

不再采用按年度對人員工件進行評估

創(chuàng)建積極的自我提高計劃制度

讓每個員工都投入到提高產品質量的活動中去

3.9.3. 【2013】【2015B】【2016】Juran

主編質量控制手冊：《質量控制手冊》為當今世界質量控制科學的“圣經”，奠定了“全面質量管理”TQM”的理論基礎(Total Quality Management)

提出適用性質量：

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

質量不僅僅要滿足明確的需求，還要滿足潛在的需求。該思想使得質量管理范圍從生產過程中的控制進一步擴大到產品開發(fā)和工藝設計階段，即挖掘用戶潛在需求。

提出質量三步曲：就是質量計劃->質量控制->質量改進

提出Juran質量螺旋;

提出80/20原則，認為有80%的質量問題是由于領導責任引起的。從而將人力與質量管理結合起來。

3.9.4. 【2013】【2015B】【2016】Crosby

提出零缺陷的概念

零缺陷：第一次就把事情做對

想要做到這一點，就需要把工作放在預防上而不是質量檢驗上;

提出質量管理的絕對性:

質量就是符合要求，而不是“完美”

質量來自于預防，而不是檢驗

質量的標準是“零缺陷”，而不是可接受質量水平

質量的衡量標準是“不符合要求的代價”

提出質量改進的基本要素(6C-變革 管理的六個階段) :

領悟(Comprehension)：理解質量真諦

承諾(commitment)：制定質量策略的決心

能力(capability)：教育與培訓

溝通(communication)：成功的經驗文檔化、制度化

改正(correction)：預防與提高績效

堅持(continuance)：強調質量管理成為一種工作方式

發(fā)展質量成熟度的度量。

3.9.5. 【2015B】【2016】Humphrey 軟件過程之父

采用Crosby的成熟度度量，提出了軟件能力成熟度模型(CMM) ，對于軟件過程管理與改進具有建設性作用。

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

4. 軟件開發(fā)實踐

4.1. 敏捷軟件開發(fā)

敏捷中也有計劃驅動

4.1.1. 敏捷目的

為了使軟件開發(fā)團隊具有高效工作和快速響應變化的能力

4.1.2. 敏捷原則

最重要的是通過盡早和不斷交付有價值的軟件滿足客戶需要

歡迎需求的變化

經常交付可以工作的軟件，從幾星期到幾個月，時間尺度越短越好

業(yè)務人員和開發(fā)者應該在整個項目過程中始終朝夕在一起工作

最好的信息傳達方式是面對面的交談

4.1.3. 敏捷宣言

4.1.3.1. 敏捷宣言內容

敏捷軟件開發(fā)宣言的4個簡單的價值觀:

(1’)個體和交互 勝過 過程和工具

(1’)可以工作的軟件 勝過 面面俱到的文檔

(1’)客戶合作 勝過 合同談判

(1’)響應變化 勝過 遵循計劃

(1’)也就是說，盡管右項有其價值，我們更重視左項的價值

4.1.3.2. 考試題

【2020-mid】請完整描述敏捷宣言

4.1.4. 敏捷軟件開發(fā)方法

4.1.4.1. 極限編程 XP

eXtreme Programming，極限的含義是指把好的開發(fā)實踐運用到極致

極限編程的有效實踐

客戶作為開發(fā)團隊的成員 —— 客戶代表

使用用戶素材

短交付周期

驗收測試

結對編程——結對編程就是由兩名開發(fā)人員在同一臺計算機上共同編寫解決同一個問題的程序代碼，通常一個人編碼，另一個人對代碼進行審查與測試，以保證代碼的正確性與可讀性。結對編程是加強開發(fā)人員相互溝通與評審的一種方式。

測試驅動開發(fā)——極限編程強調“測試先行”。在編碼之前，應該首先設計好測試方案，然后再編程，直至所有測試都獲得通過之后才可以結束工作。

集體所有

持續(xù)集成

可持續(xù)的開發(fā)速度 <=40h/week

開放的工作空間

重構

使用隱喻

4.1.4.2. Scrum

迭代式增量軟件開發(fā)過程：

Scrum中的文檔

產品訂單(product backlog)：整個項目的概要文檔，包含了已劃分優(yōu)先等級的、項目要開發(fā)的系統或產品的需求清單，是動態(tài)的。

沖刺訂單(sprint backlog)：細化了的文檔，包含了團隊如何實現下一個沖刺的需求信息。

哪些產品訂單會加入一次沖刺由沖刺計劃會議決定。會議中，產品負責人告訴開發(fā)團隊他們需要完成產品訂單中的哪些訂單項，開發(fā)團隊決定在下一次沖刺中承諾完成多少訂單項。

在沖刺的過程中，沒有人能夠變更沖刺訂單(sprint backlog)，這意味著在一個沖刺中需求是被凍結的。

燃盡圖(burn down chart)

Scrum中角色

產品負責人，代表利益所有者

產品負責人的職責是將開發(fā)團隊開發(fā)的產品價值最大化。

產品負責人是負責管理產品待辦列表的唯一負責人。產品待辦列表的管理包括：

清晰地表述產品待辦列表項；

對產品待辦列表項進行排序，使其最好地實現目標和使命；

優(yōu)化開發(fā)團隊所執(zhí)行工作的價值；

確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示 Scrum 團隊下一步要做的工作；以及

確保開發(fā)團隊對產品待辦列表項有足夠深的了解。

Scrum Master，類似于項目經理，負責維護過程和任務

促進和支持 SCRUM

幫助每個人理解 SCRUM 理論、實踐、規(guī)則和價值

SCRUM Master 是一位服務型領導。

幫助 SCRUM 團隊之外的人了解如何與 SCRUM 團隊交互是有益的

改變SCRUM 團隊之外的人與 SCRUM 團隊的互動方式來最大化 SCRUM 團隊所創(chuàng)造的價值。

Scrum Master 服務于產品負責人，包括：

確保 Scrum 團隊中的每個人都盡可能地理解目標、范圍和產品域；

找到有效管理產品待辦列表的技巧；

幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項；

理解在經驗主義的環(huán)境中的產品規(guī)劃；

確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；

理解并實踐敏捷性；以及，

當被請求或需要時，引導 Scrum 事件。

Scrum Master 以各種方式服務于開發(fā)團隊，包括

作為教練在自組織和跨職能方面給予開發(fā)團隊以指導；

幫助開發(fā)團隊創(chuàng)造高價值的產品；

移除開發(fā)團隊工作進展中的障礙；

按被請求或需要時，引導 Scrum 事件；以及，

在 Scrum 還未完全采納和理解的組織環(huán)境中，作為教練指導開發(fā)團隊。

Scrum Master 以各種方式服務于組織，包括：

帶領并作為教練指導組織采納 Scrum；

在組織范圍內規(guī)劃 Scrum 的實施；

幫助員工和利益攸關者理解并實施 Scrum 和經驗導向的產品開發(fā)；

引發(fā)能夠提升 Scrum 團隊生產率的改變；以及，

與其他 Scrum Master 一起工作，增強組織中 Scrum 應用的有效性。

開發(fā)團隊

負責在每個 Sprint 結束時交付潛在可發(fā)布并且“完成”的產品增量。

開發(fā)團隊由組織組建并得到授權，團隊自己組織和管理他們的工作。開發(fā)團隊具有下列特點：

他們是自組織的。沒有人（即使是 Scrum Master）有權告訴開發(fā)團隊應該如何把產品待辦列表變成潛在可發(fā)布的功能增量；

開發(fā)團隊是跨職能的團隊，團隊作為一個整體，擁有創(chuàng)建產品增量所需的全部技能；

Scrum 不認可開發(fā)團隊成員的任何頭銜，不管其承擔何種工作（他們都叫開發(fā)人員）。

Scrum 不認可開發(fā)團隊中所謂的“子團隊”，無論其需要處理的領域是諸如測試、架構、運維或業(yè)務分析；同時，

開發(fā)團隊中的每個成員也許有特長和專注的領域，但是責任屬于整個開發(fā)團隊。

Scrum常見活動

Sprint Planning Meeting

Daily standup meeting

review meeting

retrospective meeting

sprint

Empirical Process Control VS. Statistical Process Control，不同于統計過程控制方法（也叫預測式、計劃式）不能解決不可預見的需求變化問題，Scrum采用的實證過程控制承認問題無法完全理解或定義，即用戶可以在項目過程中變更需求，關注于如何使開發(fā)團隊快速推出和響應需求變化的能力最大化

Scrum VS. XP

迭代周期不同。XP迭代周期為1_{2周，而Scrum迭代周期為2}4周

迭代中是否允許需求變更。XP中只要變更需求與原需求所需時間資源相等即可變更，而Scrum在迭代中需求被凍結

迭代中，需求是否嚴格按照優(yōu)先級來實現。XP中務必遵守優(yōu)先級別，Scrum中則比較靈活，原因是可能有需求依賴問題

過程工程化。Scrum開發(fā)過程并未工程化，要求開發(fā)者自覺保證，但XP則對開發(fā)流程定義嚴格，例如TDD，結對編程，重構等

4.1.4.3. Kanban方法

精益生產（豐田制造法）的具體實現

可視化工作流、限定WIP、管理周期時間

馬丁提出了微服務架構

4.1.4.4. 考試題

【2015B】XP規(guī)定開發(fā)?員每周?作時間不超過___?時，連續(xù)加班不可以超過兩周，以免降低?產率？(B)

30

40

50

60

【2020-mid】下列不屬于看板方法典型實踐的是?(BD)

可視化工作流

站立式會議

限定WIP

重構

【2015B】【2016】請結合SCRUM這種敏捷?法論述敏捷?法應該具備的特征？同時解釋為何常見的若?種描述敏捷?法對??的?法的特征（例如，嚴格、重型、計劃驅動等等）并不合適？10’

特征

?周期迭代

快速響應變更

價值交付

?動化

特征解釋：

嚴格：所有優(yōu)秀的?程?法和實踐都是嚴格的。

重型：如上，此外，輕量級和重型其實并沒有刻畫具體?法，何為重型，并沒有嚴格定義；?且，對于變更這件事情，?乎所有?法都是限制，因此，很難說敏捷?法是輕量級?法。

計劃驅動：所有正式的項?都是計劃驅動的，否則計劃的作??法體現

【2015A】敏捷方法的特征有哪些？哪些關于敏捷特征的說法施加于敏捷方法之上是不合適的？為什么？10’

特征：小周期迭代式持續(xù)交付、敏捷宣言

關于敏捷方法的一些特征表述可能帶著一定的誤導，例如:

輕量級方法:這是對以XP為代表的一類方法的誤導，事實上，這類方法對工程規(guī)范有著極為嚴格的要求;

擁抱變更、變更驅動：僅僅是口號，對待變更，所有軟件工程方法都是限制和管理的態(tài)度。

TDD可以提供更高的開發(fā)質量:并沒有足夠的證據支持。

【2014】為何說將“規(guī)范方法”、“計劃驅動方法”等特征作為敏捷方法的對立面帶有很大的誤導性質?如何通過多種維度改進這種對各類開發(fā)過程的理解？10’

敏捷：敏捷目的、敏捷價值觀、敏捷原則

影響敏捷與規(guī)范方法選擇的五個維度

如果只有強有力的規(guī)范而缺乏敏捷，將導致官僚作風，進而停滯不前。團隊將陷入為了測量而測量的處境之中，缺乏創(chuàng)新。

缺乏創(chuàng)新的敏捷則如同一個新創(chuàng)公司在盈利之前的不負責任的狂熱

計劃驅動的開發(fā)人員必須敏捷，敏捷開發(fā)人員必須規(guī)范。

【2016】Devops三個步驟

【2018】Devops的特點，為什么流行？

【2018】什么是云原生？相關的重要的概念

【2018】精益屋的兩大支柱？

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

4.1.4.5. 概念解釋

【2016】CI

【2016】CD/CD

【2016】Pipeline Orchestration

【2016】Container

【2016】Micro Service

【2016】A/B Testing

【2016】GitFlow

4.1.4.6. 描述用途

【2016】Docker

【2016】Jenkins

【2016】JIRA

【2016】SonarQube

【2016】Git

5. PSP 個體軟件過程

5.1. PSP是什么？

PSP是包括了數據記錄表格、過程操作指南和規(guī)程在內的結構化框架。

PSP著重于軟件開發(fā)人員的個人能力提升，體現在估算能力、計劃能力、計劃執(zhí)行以及質量管理等方面

基本的PSP包括策劃、設計、編碼、編譯、單元測試以及總結等階段。

每個階段都有相應的過程操作指南，用來指導該階段的開發(fā)活動。

每個階段，都有相應的過程操作指南，用來指導該階段的開發(fā)活動。

所有的開發(fā)活動都需要記錄相應的時間日志和缺陷日志。

5.2. PSP基本原理（為什么要有PSP）

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

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

軟件工程師應當自己度量、跟蹤自己的工作流程，并建立持續(xù)的自我改進機制（在自己開發(fā)過程的偏差中學習、總結，并將這些經驗教訓整合到自己的開發(fā)實踐），自己管理軟件組件的質量。

上述基本原理除了繼續(xù)肯定“過程質量決定最終產品質量“這一軟件過程改進的之外，更加突出了個體軟件工程師在管理和改進自身過程中的能動性。這就形成了PSP的理論基礎。

5.3. PSP的成熟度級別

5.4. PSP的度量

5.4.1. 基本度量項

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

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

度量規(guī)模：使用PROBE方法

選擇的規(guī)模度量方式必須反映開發(fā)成本

度量規(guī)模必須被精確定義

度量規(guī)模必須有自動化方法統計

有助于早期規(guī)劃

日程（TSP）

5.4.2. 度量的作用

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

度量幫助過程的實踐者了解過程狀態(tài)，理解過程偏差。

5.4.3. 規(guī)模度量標準

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

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

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

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

5.4.4. 規(guī)模的度量的困境

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

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

5.4.5. 考試題

為什么精確的度量方式往往不便于早期規(guī)劃，而有助于早期規(guī)劃的度量往往難以產生精確度量結果？

對比度量方式 LOC 和 FP

LOC

LOC優(yōu)點：LOC是軟件開發(fā)項目的生成品，容易進行計算

LOC缺點

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

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

不適合非過程語言

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

FP

FP優(yōu)點

和程序設計語言無關

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

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

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

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

【2014】解釋過程度量項定義時應當注意的方面，并且據此評價PSP基本度量元的合理之處？6’

【2014】如何對某個軟件產品組件進行產品質量評價?可以選擇哪些度量元，這些度量元如何輔助判斷產品組件的質量? 8’

5.4.6. PROBE方法

估算的目的是給各類計劃提供決策依據

5.4.6.1. 估算原理

設置合理的代理作為精確度量和早期規(guī)劃需要的度量之間的橋梁：相對大小矩陣

相對大小而非絕對大小

5.4.6.2. PROBE方法例子

估算房子面積大小

使用房間相對大小矩陣

使用房間作為代理

估算程序規(guī)模和工作量

使用代碼相對大小矩陣

每個組件都有設定的類型(計算、邏輯或數據)

規(guī)模(非常小、小、中、大、非常大)

假設

如果新建立的組件與以前建立的組件類似，那么新組建所需的工作量與舊組件一樣。

當開始一個新項目時，我們可以將任務劃分為與代碼庫中組件相似的類型和規(guī)模，然后利用線性回歸方法來估算項目的工作量。

具體例子見課本

5.4.6.3. 方法思想

在PROBE估算中，需要建立自己的代碼庫，以跟蹤所有程序的規(guī)模和工作量，而代碼庫中的每個組件都有設定的類型(計算、邏輯或數據等)和規(guī)模(非常小、小、中、大、非常大)。

如果新建立的組件與以前建立的組件類似，那么新組件所需的工作量與舊組件一樣。

當開始一個新項目時，我們可以將任務劃分成與代碼庫中組件相似的類型和規(guī)模，然后利用線性回歸方法來估算項目的工作量。

估算本質上是一種猜測，追求的目標是一致性以及估算結果的使用者對估算結果的信心。

PROBE方法通過定義估算過程和數據收集以及使用的框架，使得估算結果可以盡可能一致，從而使得一些統計方法可以用來調整估算結果，增強用戶對估算結果的信心。

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

5.4.6.4. 通用計劃框架

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

定義需求

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

日程計劃

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

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

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

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

估算框架如上圖

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

5.4.6.5. PROBE估算過程

概要設計

確定產品功能，以及產生這些功能所需的程序組件/模塊

將程序組件/模板與你之前寫的程序相比較，估算它們的規(guī)模

最后將程序組件/模塊估算綜合給出總規(guī)模

估算要點：

盡可能劃分詳細一些：估算多個部件的時候，總的誤差會比各個部件的誤差的總和小

建立對結果的信心

依賴數據

估算要的是過程，而非結果，估算的過程是相關干系人達成一致共識的過程。

5.4.6.6. 注意點1：整理歷史數據

以估算規(guī)模為例，可以假定代理規(guī)模與實際程序規(guī)模之間存在簡單關系映射、正態(tài)分布、對數正態(tài)分布，也可以假定不知道兩者之間的關系，按照線性回歸方法進行計算。

簡單方法

內容：最小值作為VS、最大值作為VL、中值作為M,VS與M均值作為S、VL與M均值作為L

優(yōu)點：計算簡單

缺點：不穩(wěn)定

正態(tài)分布法

內容：均值作為M，計算標準差σ，則S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ

優(yōu)點：相對穩(wěn)定，在歷史數據基本符合正態(tài)分布的情況下，可以給出非常好的相對大小矩陣

對數正態(tài)分布法:

內容：

以e為底計算所有數據的自然對數

取對數之后的值的均值作為M，計算相應標準差σ;S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ

取反對數

優(yōu)點：更加符合人們對于程序的規(guī)模的直觀感覺，因為大多數人習慣寫很多規(guī)模很小的程序，少量規(guī)模較大的程序

線性回歸方法

計算的時候計算了兩組線性回歸的參數，也就是項目所需的資源并不是直接由程序規(guī)模和歷史數據中的生產效率相除得到。程序的復雜度和程序規(guī)之間并不是簡單的正相關關系。

線性回歸方法估算的是一定概率條件下估算值的分布。例如最終實際程序規(guī)模有90%的可能性落在(a,b)區(qū)間內

Range為在一定概率條件下的變化區(qū)間，而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}$$

Plan Size和估算的類數量不呈現45度，是受到了估算誤差和方法外代碼的數量共同影響

該方法沒有使用生產效率進行計算，為什么在PROBE中不使用生產效率？這樣子使用好不好？因為Plan Size是在一個范圍內波動，生產效率也在一個范圍內波動，如果將生產效率作為分母，那么可能會導致更大的誤差，也就違背了誤差的出發(fā)點。

估算能力的強弱關注是多穩(wěn)定，而不是多接近具體的實際情況

5.4.6.7. 注意點2：處理有限的歷史數據

規(guī)模估算

往往可以依據歷史數據來完成，使用代理規(guī)模與實際程序規(guī)模之間的關系。

其原因在于規(guī)模估算結果的偏差產生原因相對客觀，偏差可以用以修正新的估算結果。

估算規(guī)模對歷史數據的要求如下

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

時間估算

使用代理規(guī)模和實際開發(fā)時間的關系。

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

歷史數據中的時間偏差可參考價值不大。

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

5.4.6.8. 注意點3：處理極端數據

極端數據可能造成相關性假象。

5.4.6.9. 考試題

【2013】【2015A】【2018】談談你對項目估算的認識，并簡要解釋應用PROBE方法估算的優(yōu)缺點

【2018】PROBE估算的基本流程

【2020-mid】請描述一下PROBE方法的基本原理（4’）：2點

【2020-mid】請描述一下PROBE方法的過程(4’)：流程圖

【2020-mid】使用PROBE方法估算時間的時候，為什么不使用歷史數據中的生產效率數據？(2’)在估算資源需求(例如，人時)的時候，生產效率一般在分母上，考慮到個體軟件工程師生產效率波動，容易導致估算偏差范圍變大。

【2020-mid】請描述PROBE ABCD方法在估算規(guī)模的時候，對歷史數據的質量有什么要求? 10分)：如上估算規(guī)模圖示

【2014】請解釋規(guī)模估算和資源估算中估算偏差含義之間的差異，并據此簡要列舉對軟件開發(fā)活動的啟發(fā)？

基于風險分析平衡敏捷與規(guī)范

敏捷風險 > 計劃驅動風險，啟用基于風險的計劃驅動方法

計劃驅動風險 > 敏捷風險，啟用基于風險的敏捷方法

不能判斷，則通過架構把敏捷部分封裝起來，在敏捷部分使用基于風險的敏捷方法，在其他地方啟用基于風險的計劃驅動方法。

5.5. PSP的質量管理

5.5.1. PSP質量觀與質量策略

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

什么是軟件質量？

與軟件產品滿足規(guī)定的和隱含的需求能力有關的特征或者特征的全體

PSP中定義質量為滿足用戶需求的程度，需要明確用戶需求的范圍、優(yōu)先級、度量方式

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

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

其內部質量特性不直接面向最終用戶。

軟件質量的不同視角

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

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

5.5.1.1. 面向用戶的質量觀

PSP中也采用了面向用戶的質量觀，定義質量為滿足用戶需求的程度。在這個定義中，就需要進一步明確：

用戶究竟是誰？

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

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

怎樣來度量這種質量觀下的質量水平？

典型用戶質量期望

這款軟件產品必須能夠工作：因此可以使用缺陷管理代替質量管理

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

這款軟件產品最好在安全性、保密性、可用性、可靠性、兼容性、可維護性、可移植性等方面表現優(yōu)異。

指導意義

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

高質量開發(fā)確保DevOps中的價值順暢流動

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

PSP關注提升個體軟件工程師工程技能

5.5.1.2. 質量策略

首先確保基本沒有缺陷，然后再考察其他的質量目標。

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

高質量的產品也就意味著組成軟件產品的各個組件基本無缺陷

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

為什么有效?

提高生產效率，通過關注每個組件的質量，往往可以避免在集成測試和系統測試消除

大量缺陷，減少消除代價，提升生產效率

5.5.1.3. 質量路徑 Quality Journey

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

第一步：各種測試

第二步：進入測試之前的產物質量提升

第三步：評審過程度量和穩(wěn)定

第四步：質量意識和主人翁態(tài)度

第五步：個體review的度量和穩(wěn)定

第六步：訴諸設計

第七步：缺陷預防

第八步：用戶質量關 —— 其他質量屬性

5.5.1.4. 考試題

【2018】什么是面向用戶的質量觀？這對質量管理的策略有什么影響？

【2014】請區(qū)分質量管理和缺陷管理之間的聯系和差異，并解釋為何在軟件開發(fā)中將質量和生產效率兩者進行妥協不合適？6’

【2014】為了追求極高的軟件產品的質量目標，可能有的方法和這些方法的先后順序分別是什么？8’(質量路徑)

質量實踐和質量管理是不一樣的

質量實踐包括測試等等

質量管理是對質量的管理，而不是實踐，管理必須有上面所說的三個要素

5.5.2. 發(fā)現缺陷的幾個示例流程

5.5.2.1. 測試消除缺陷的典型流程

發(fā)現待測程序的一個異常行為

理解程序的工作方式

調試程序，找到出錯的位置，確定出錯的原因：非常耗時，在項目后期可能會消耗數天甚至數周的時間

確定修改方案，修改缺陷

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

5.5.2.2. 評審發(fā)現缺陷的典型流程

在如下的步驟中，每一步消耗的時間都不會太多。盡管評審的技能因人而異，但是，通過適當培訓和積累，有經驗的評審者可以發(fā)現80%左右的缺陷。

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

發(fā)現缺陷的同時，也知道了缺陷的位置和原因

修正缺陷

5.5.3. 評審與測試

5.5.3.1. 評審檢查表

評審檢查表的建立和維護：示例見課本

評審檢查表的使用

5.5.3.2. 評審形式

打印后評審效果更好

單個屏幕可以展現的內容比較有限（評審對象比較復雜的時候，單個屏幕往往不能體現評審對象的整體結構、整體安全、整體性能以及其他整體屬性）

評審人員的注意力：基于屏幕的評審往往容易受到干擾，從而影響評審人員的注意力

5.5.3.3. 評審時機

編譯、評審

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

越來越強大的編譯器一般可以發(fā)現超過90%的拼寫錯誤。

不管怎么努力，評審還有會遺漏約20-50%的語法錯誤。

即便編譯器遺漏了一些類似語法的錯誤，這些錯誤也不難通過單元測試消除。

一些基于解釋執(zhí)行的集成開發(fā)環(huán)境，可以實現消除編譯錯誤。

評審、編譯

為了確保評審的效率，不管在評審之前有沒有編譯，評審的速度是一定的，也就意味著評審所需時間是一定的，那么如果先評審后編譯，在編譯階段就可以節(jié)省較多的時間。

編譯器會大概會遺漏9%左右的缺陷，從前面討論可知，為了有較高的質量，這些缺陷仍然期望通過評審加以消除。

有數據表明，編譯過程中缺陷較多，往往意味著單元測試中缺陷也較多。

即便單元測試也可以發(fā)現一些類似語法的錯誤，但是，畢竟還有些很難發(fā)現，而單元測試之后的一些缺陷消除環(huán)節(jié)的Pahse Yield往往還低于單元測試。

編譯之前評審也是一種自我學習的好機會。

干凈的編譯，即編譯過程沒有缺陷對于軟件工程師來說，也有極大的成就感。

5.5.3.4. 評審的具體形式

個人評審、小組評審

個人評審 -> 小組評審

小組評審的意義

有利于更好地發(fā)現缺陷，預防風險，提高Process Yield進而確保質量。

在個人評審之后安排小組評審，也有利于提升個人的技能。特別是那些個人評審未發(fā)現而個人評審發(fā)現的缺陷，往往都需要引起足夠的注意。軟件工程師通過對這些缺陷的分析，往往可以學到很多東西。

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

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

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

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

5.5.4. PSP質量控制的衍生指標

5.5.4.1. Yield指標

5.5.4.1.1. 基本定義

定義了各個階段在消除缺陷方面的效率

Yield指標越高越好

Process Yield我們期望在80以上

Cannot read properties of undefined (reading 'type')

Yield可用于制定質量計劃并且在項目執(zhí)行階段用于進行風險監(jiān)控、預測、識別以及控制

例子

階段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：最后的測試如果發(fā)現了一個錯誤，那么其中一定還有一個錯誤沒有被發(fā)現（所以最后的Yield的值為50），修改后如下（沒有發(fā)現的也按照原本的比例來分）

階段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的計算是一種事后的質量控制手段，而且除非發(fā)現了所有的缺陷，否則很難非常精確地進行計算。

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

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

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

注入階段注入多少缺陷

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

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

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

歷史數據中的軟件規(guī)模、文檔規(guī)模、開發(fā)人員規(guī)模

步驟

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

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

依照回歸技術進行計算

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

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

上圖第一個消除步驟是需求評審，第二個消除步驟是設計評審，第三個消除步驟是測試評審

改進方案

結果受限于歷史數據在簡單性、可理解性、穩(wěn)定性、可度量性、相關性等方法的質量。因此，維護歷史數據。

影響因子的選擇上面不僅僅需要有關軟件規(guī)模的數據，還需要有關開發(fā)過程、開發(fā)文檔、開發(fā)人員等方面的數據，并且需要將數據可度量化。

反饋模型。即在開發(fā)過程中隨著實際數據的產生，將這些數據作為輸入變量放入模型中以調整回歸參數。

(重要)可能的改進是假設注入水平和消除水平都符合正態(tài)分布，計算均值和標準差，因此，可以用蒙特卡羅方法模擬結果。

5.5.4.2. A/FR

COQ(Cost of Quality)

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

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

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

質檢失效比

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

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

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

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

5.5.4.3. PQI Process Quality Index 過程質量指標

為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)$

用途

判斷模塊開發(fā)質量

規(guī)劃質量活動計劃

過程改進

【2013】【2018】解釋PQI指標，如何計算，如何使用

5.5.4.4. Review Rate

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

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

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

5.5.4.5. DRL Defect-Removal-Leverage 缺陷消除效率比

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

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

發(fā)現的效率：代碼評審 > 設計評審 > 設計檢查 > 代碼檢查 > 單元測試 > 系統測試

5.5.4.6. 考試題

【2015B】請解釋A/FR，PQI的計算?式，并且解釋這兩個指標有什么?途？10’

【2015A】請結合A/FR、PQI、Review Rate、DRL、Yield盡可能具體描述?個軟件項?應該如何從多??來確保開發(fā)的?質量？10’

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

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

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

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

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

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

5.5.5. 考試題

【2013】【2015A】如果對質量的追求是無止境的，在不考慮資源和成本的前提下，有哪些可能有效的策略？

重視測試，并且將測試過程文檔化并且穩(wěn)定化;

重視小組評審，同樣定義評審過程，并且使得評審過程的performance穩(wěn)定化

重視個人評審，提升評審者技能;

重視設計

開展設計驗證

質量策略：參考上面

5.6. PSP的設計

PSP設計過程的關注點并不是具體的設計方法，而是設計的步驟定義以及設計的表現形式

5.6.1. 設計與質量的關系

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

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

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

5.6.2. 設計什么

設計目標程序在整個應用系統中的位置

設計目標程序的使用方式

設計目標程序與其他組件以及模塊之間的關系

設計目標程序外部可見的變量和方法

設計目標程序內部運作機制

設計目標程序內部靜態(tài)邏輯

5.6.3. 設計的過程

5.6.4. 設計內容

動態(tài)信息靜態(tài)信息

外部信息	交互信息(服務、消息等)	功能(繼承、類結構等)
內部信息	行為信息(狀態(tài)機)	結構信息(屬性、業(yè)務邏輯等)

5.6.5. 設計模板

動態(tài)信息靜態(tài)信息

外部信息	OST/FST	FST
內部信息	SST	LST

5.6.5.1. 操作規(guī)格模板 Operational Specification Template

描述系統與外界的交互，用于場景描述：也就是”用戶“與”待設計系統的正常情況和異常情況下的交互。

定義測試場景和測試用例，用來與用戶討論需求的基礎，特別是操作相關的需求描述

與UML比較：用例圖、時序圖

5.6.5.2. 功能規(guī)格模板（Functional Specification Template， 簡稱FST）

描述系統的對外接口，是一種靜態(tài)信息的展現。

提供的典型信息有類和繼承關系、外部可見的屬性和方法等。

用形式化符號等方法描述方法等行為，消除二義性。

與UML對比：UML類圖，但類圖的方法的行為沒有描述

5.6.5.3. 狀態(tài)規(guī)格模板（State Specification Template，簡稱SST）

可以精確定義程序的所有狀態(tài)、狀態(tài)之間的轉換以及伴隨著每次狀態(tài)轉換的動作。

SST模板中，需要描述如下的信息

所有狀態(tài)的名稱

所有狀態(tài)的簡要描述

在SST中需要使用的參數和方法的名稱與描述

狀態(tài)轉換的條件

狀態(tài)轉換是發(fā)生的動作。

與UML對比：UML狀態(tài)圖

5.6.5.4. 邏輯規(guī)格模板（Logical Specification Template，簡稱LST）

可以精確描述系統的內部靜態(tài)邏輯。為了消除描述的二義性，一般建議使用偽代碼配合形式化符號來描述設計結果。

LST模板中，需要描述如下的信息

關鍵方法的靜態(tài)邏輯

方法的調用

外部引用

關鍵數據的類型和定義

與UML對比：沒有對應圖

5.6.5.5. UML

UML圖有用例圖、時序圖、類圖、狀態(tài)機圖

UML的用例圖和時序圖提供了與PSP中OST同樣的信息；

UML中的時序圖和類圖所描述的類之間的關系以及對象之間的交互信息在PSP4個設計模板中沒有對應的內容；

UML類圖中記錄了方法的型構，然而方法的行為沒有描述，這一點在PSP的FST中有相應的內容；

PSP中的LST用以描述程序的靜態(tài)邏輯，這在UML沒有對應的圖示方法；

UML中的狀態(tài)圖與SST描述的狀態(tài)圖類似，但是SST中描述的關于狀態(tài)、狀態(tài)轉換條件以及狀態(tài)轉換中的動作沒有對應的UML圖示方法。

5.6.5.6. 考試題

【2014】請解釋設計的層次的概念和意義，并解釋如何將PSP4個設計模版應用在不同的設計層次之中?8’

5.6.6. PSP設計驗證方法

5.6.6.1. 狀態(tài)機驗證

檢查狀態(tài)機的完整性和正交性

完整性：對于狀態(tài)機中任何一個狀態(tài)，對應的所有條件組合，下一個狀態(tài)的轉換都有定義。

正交性：對于狀態(tài)機中任何一個狀態(tài)，其所有下一個狀態(tài)的轉換條件都不能相同。

驗證步驟

檢查狀態(tài)機，消除死循環(huán)和陷阱狀態(tài)

檢查狀態(tài)轉換，驗證完整性和正交性

評價狀態(tài)機，檢驗是否體現設計意圖

具體驗證方法參見PPT

使用狀態(tài)圖，檢查死循環(huán)和陷阱狀態(tài)

使用真值表來進行分析

【2015B】下述內容在狀態(tài)機驗證中不?以驗證狀態(tài)機本?是否正確的是?

沒有隱藏的陷阱和死循環(huán)

狀態(tài)轉換是否完整

狀態(tài)描述是否完整

狀態(tài)轉換是否正交

5.6.6.2. 符號化驗證

將描述設計的邏輯規(guī)格(一般用偽代碼程序表示)用代數符號來表示是，然后系統地開展分析和驗證

驗證步驟

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

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

分析偽碼程序的行為。

具體示例見PPT：交換兩個變量的值

優(yōu)點

實施簡單，可以給出一般化的驗證結果

適用于不復雜的算法，特別是遺漏系統的改造中，應用這種方法識別和理解原有的設計

缺點：不適合于有復雜邏輯的場合；純手工驗證方法容易引入錯誤。

5.6.6.3. 執(zhí)行表驗證

執(zhí)行表

步驟

識別偽碼程序的關鍵變量

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

初始化被選定的變量

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

優(yōu)點：實施簡單；結果可靠，可用于復雜邏輯的驗證。

缺點：每次只能驗證一個用例；手工驗證比較耗時，容易引入錯誤。

5.6.6.4. 跟蹤表驗證

步驟

識別偽碼程序的關鍵變量

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

初始化被選定的變量

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

定義并且優(yōu)化用例組合

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

跟蹤表應用符號化以及用例識別等方法，對程序的一般化行為進行驗證，是執(zhí)行表驗證的補充，可以每次驗證多個用例，從而提供更加高效地開展驗證工作。

5.6.6.5. 正確性驗證

將偽碼程序當做數字定理，采用形式化方法加以推理和驗證

步驟

分析和識別用例

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

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

While-Do循環(huán)的驗證

條件1：condition 是否最終一定會為"假"，從而使得循環(huán)可以結束。

條件2：condition 為"真"的時候，單獨的循環(huán)結構執(zhí)行結果與循環(huán)體再加一個循環(huán)結構，其執(zhí)行結果是否一致？

條件3：condition 為"假"的時候，循環(huán)體內所有變量是否未被修改？

6. TSP 團隊軟件過程

TSP提供了

一個已經定義的團隊構建過程

一個團隊作業(yè)框架

一個有效的管理環(huán)境

6.1. 團隊工程開發(fā)：需求開發(fā)

需求開發(fā)包含需求獲取、需求匯總、需求驗證

6.1.1. 需求分類

客戶需求描述的是客戶的期望，是客戶解決問題的愿望。

客戶需求可能很簡單，也可能很復雜；可能很清晰，也可能模糊。

比如，客戶希望有一種快速進行數據計算的工具幫助其完成繁瑣的計算工作。

產品需求描述的是開發(fā)團隊所提供的解決?案。即針對上述的客戶需求，開發(fā)團隊設計出?個可以幫助客戶解決?作當中碰到的問題的?案。

產品組件需求描述的是組成產品的各個組件的需求規(guī)格。與產品需求相比，這是更低層次，更為細致的描述了上述解決方案中的某個組件的功能、性能與形式等。

6.1.2. 為什么說“需求是一切工程活動的基礎”

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

產品集成活動中，各個組件之間的接口必須滿足事先確定的接口需求，否則會造成接口不匹配。

驗證(Verification)活動也是檢驗獲得的產品和產品組件能不能滿足各自事先定義好的需求規(guī)格。

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

此外，需求也是項目計劃活動的關鍵輸入。比如，項目的規(guī)模估算、成本估算等必須參考需求來進行。

6.1.3. 需求獲取

需求是采用”誘導“式方法獲取客戶的顯式需求和隱式需求，盡可能的識別客戶的期望與所受到的限制。

“誘導”不僅僅是普通的需求采集，隱含了更加積極地、前瞻性地識別那些客戶沒有明確提供的額外需求。

客戶所受到的限制也應當作為需求開發(fā)過后需要關注的內容。限制包括技術、成本、時間、風險、行業(yè)規(guī)則、法律等等。

6.1.4. 需求匯總

整理各種來源的信息，識別缺失的信息。

解決沖突的需求

需求的整理和轉化：我們需要將客戶的需求轉換為產品需求和產品組件的需求

推導未顯式描述的需求內容，例如采用某項技術的附屬需求

6.1.5. 需求驗證

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

典型活動包括

建立和維護操作概念和相關的場景；場景一般而言是指使用產品時可能發(fā)生的時間順序。

分析需求，以確保其必要性、充分性和平衡性。

確認需求，以確保將要產生的產品能在預期的用戶環(huán)境中運行并且工作正常。

6.1.6. 需求文檔制作

需求開發(fā)工作完成的一個基本標志是形成了一份完整的、規(guī)范的、經過評審的需求規(guī)格說明書。

需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎。

6.1.6.1. 優(yōu)秀需求規(guī)格文檔特征

特征描述

內聚特征	需求規(guī)格描述應當盡可能內聚，即僅僅用以說明一件事情
完整特征	需求規(guī)格描述應當完整，不能遺漏信息
一致特征	需求規(guī)格描述的各個條目和章節(jié)不能互相矛盾，需求規(guī)格描述與所有外部的參考資料之間也應當消除矛盾之處
原子特征	需求規(guī)格描述的過程中，應當盡可能避免連接詞的使用。如果需要描述多項內容，可以分別用簡單語句加以描述
可跟蹤特征	客戶需求、產品需求以及產品組件需求必須可以雙向跟蹤，即客戶需求的任何內容，都應當在產品需求和產品組件需求中得到體現。反之，產品組件需求的每一項描述也要可以跟蹤到客戶需求中的內容
非過期特征	需求描述的內容必須體現相關干系人對于項目的最新認識。即不能包含已經廢棄的需求定義
可行性特征	需求規(guī)格描述的各項內容應該在項目所擁有的資源范圍內可以實現
強制特征	需求規(guī)格描述的內容應當體現強制性，即需求規(guī)格描述的內容的任何一項缺失，都會導致最終產品不能滿足客戶期望。因此，可選的需求內容要么不要出現，要么以明確的方式標注
可驗證特征	需求規(guī)格描述應當便于在后期開發(fā)過程中進行驗證。即實現該需求與否，應該有明確的判斷標準

6.1.6.2. SRS示例

引言

系統定義

應用環(huán)境

功能規(guī)格

性能需求

實現約束

質量描述

其它要求

參考材料

簽字認證

對于需求規(guī)格模板中的功能規(guī)格定義可以用多種方式靈活定義。典型的方式有原型描述、結構化分析方法描述、用例（User Case）描述、可測試需求列表描述等。

6.1.7. 考試題

【2014】請解釋需求開發(fā)中客戶需求和產品需求的差別，并設計一個流程來完成需求開發(fā)工作？6’

【2015B】請給出需求開發(fā)的完整過程，并且解釋客戶需求和產品需求的各?含義以及在需求開發(fā)過程中該如何體現客戶需求和產品需求？8’

6.2. 團隊工程開發(fā)：團隊設計

6.2.1. 團隊智慧

發(fā)揮團隊智慧兩大挑戰(zhàn)

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

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

6.2.2. 設計標準

命名規(guī)范：項目小組應當設計一個統一的命名規(guī)范來命名各個模塊并建立系統詞典

接口標準：組件之間的接口標準和格式也需要作為設計標準的內容之一加以定義

系統出錯信息：系統異常信息和出錯信息往往也需要通過一個規(guī)范加以標準化

設計表示標準：設計表示標準定義了設計工作的產物應當滿足的標準。

6.2.3. 復用性支持

在設計階段必須要充分考慮復用的可能。為了支持復用，軟件項目團隊需要建立一套復用管理流程，具體而言，包括

復用接口標準

復用文檔標準

復用質量保證機制

6.2.4. 可測試性考慮

設計可測試性考慮主要體現在兩方面

要盡可能減少測試代碼的數量

要制作合理的測試計劃。

6.2.5. 可用性考慮

可用性的問題應當在設計階段就開始考慮，而不能推延到實現階段。

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

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

必要時，可以邀請最終用戶參與場景的評審，使用模擬、原型等技術，更好的把握用戶真實意圖。

6.2.6. 設計的文檔化

6.3. 團隊工程開發(fā)：實現策略

6.3.1. 評審的考慮

設計的時候采用的策略是自頂向下、逐層精化，這有利于建立系統的整體觀，

實現的時候為了方便對實現結果評審，建議采用自底向上的方式進行，首先實現底層的內容，然后對這些底層的模塊進行評審，有利于復用策略的應用。

6.3.2. 復用策略

采用自底向上的開發(fā)策略有利于進行復用。

幾個經典的復用策略

編碼注釋的應用：編碼注釋采用統一格式，標明功能，調用方式。異常信息等有利于復用的信息。

站立式會議：在會上，團隊成員可以討論實現計劃，識別可復用組件，了解現有的復用組件庫中的內容

6.3.3. 可測試性考慮

實現計劃必須與測試計劃一致，不能出現集體測試的時候部分模塊未實現的情況。

6.4. 團隊工程開發(fā)：集成策略選擇

6.4.1. 大爆炸集成策略

定義：將所有已經完成的組件放在一起進行一次集成

優(yōu)點：需要很少的測試用例

缺點：需要所有有待集成的組件質量非常高，否則會出現難以定位缺陷位置的問題，從而消耗很多測試時間；另外，系統越復雜，規(guī)模越大，問題越突出

6.4.2. 逐一添加集成策略

與大爆炸集成策略相反，采取一次添加一個組件的方式進行集成

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

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

6.4.3. 集簇集成策略

定義：是對逐一添加集成策略的改進，把有相似功能或者有關聯的模塊優(yōu)先進行集成，形成可以工作的組件，然后以組件為單位繼續(xù)較高層次的集成

優(yōu)點：可以盡早獲得一些可以工作的組件，有利于其它組件測試工作的開展

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

6.4.4. 扁平化集成策略

定義：優(yōu)先集成高層的部件，然后逐步將各個組件、模塊的真正實現加入系統。即盡快構建一個可以工作的扁平化系統

優(yōu)點：可以盡早發(fā)現系統層面的缺陷

缺點：為了確保完成的系統，需要大量的打“樁”（stub），即提供一些直接提供返回值的偽實現。這種方式往往不能覆蓋整個系統應該處理的多種狀態(tài)

6.4.5. 考試題

【2013】【2015A】產品組件集成策略有哪些？請解釋這些策略的優(yōu)缺點。在此基礎上，解釋如果要實現高質量集成，可能需要注意哪些?面。

【2014】請羅列集成測試的典型策略，并且解釋各個集成測試策略的優(yōu)缺點？8’

6.5. 團隊工程開發(fā)：驗證與確認 V&V

6.5.1. 什么是V&V?

驗證(Verification)活動也是檢驗獲得的產品和產品組件能不能滿足各自事先定義好的需求規(guī)格；

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

驗證(Verification)和確認(Validation)都是為了提升最終產品的質量?采取的措施。

6.5.2. V&V的區(qū)別與聯系

驗證和確認的?的不同：

驗證是?的是確保選定的?作產品與事先指定給該?作產品的需求(即產品需求或產品組件需求)?致。

確認的目的則是確保開發(fā)完成的產品或者產品組件在即將要使?該產品或者產品組件的環(huán)境中?作正確，關注的是客戶需求的滿足。

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

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

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

6.5.3. V&V的活動

環(huán)境準備

對于驗證工作，如果是評審，則需要準備文件材料、人員以及會議場所等；如果是測試，需要準備模擬器、場景生成程序、環(huán)境控制以及其他系統接口等

對于確認工作，則需要模擬真實環(huán)境和場景

對象選擇

對于驗證工作，驗證對象往往從工作產品中選擇

對于確認工作，確認對象從產品中選擇

活動實施

確認工作活動包括早期對產品需求評審工作和最后的驗收測試

驗證工作：一般的評審和測試工作

結果分析

對于評審結果，可以根據評審結果反思軟件開發(fā)過程的合理性、以及是否還有隱藏的缺陷

對于驗收測試的結果，則可以關注那些一直遺留到驗收階段才被發(fā)現的缺陷，看看這些缺陷在什么階段被引入，為什么前面未能發(fā)現等

6.5.4. V&V的例子

單元測試：驗證

集成：驗證

需求評審：確認

驗收測試：確認

6.5.5. 考試題

【2015B】請解釋在質量保障活動中的V&V分別是什么含義？兩者之間的關系是什么？5分

【2014】請舉例說明驗證和確認的區(qū)別和聯系? 4分

6.6. 團隊項目規(guī)劃：工作分解結構與范圍管理

6.6.1. 工作分解結構（WBS，Work Breakdown Structure）

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

它歸納和定義了項目的整個工作范圍。

每下降一層代表對項目工作的更詳細定義。

作用/特點

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

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

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

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

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

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

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

表示方式

樹型層次結構

清單型層次結構

6.6.1.1. 創(chuàng)建WBS

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

要將整個項目分解成工作包：

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

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

自上而下逐層細化分解。

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

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

6.6.1.2. 好的WBS的檢查標準

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

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

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

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

6.6.2. 范圍管理

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

WBS為范圍管理提供了基礎

收集需求

定義范圍

創(chuàng)建WBS

核實范圍

控制范圍變更

6.7. 團隊項目規(guī)劃：開發(fā)策略與計劃

定義：是在產品組件需求基礎之上，明確每個產品組件的獲得方式與順序，從而在項目團隊內部建立起大家都理解的產品開發(fā)策略

注意事項：

WBS的使用

產品組件開發(fā)順序的考慮

產品組件獲得方式的考慮

6.8. 團隊項目規(guī)劃：生命周期模型選擇

生命周期模型的各個階段

項目啟動階段

項目策劃階段

需求開發(fā)階段

技術實現階段

集成與測試階段

交付與維護階段

項目總結

6.9. 團隊項目規(guī)劃：計劃

6.9.1. 日程計劃原理和方法

6.9.1.1. 任務計劃和日程計劃

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

日程計劃描述了每個任務在日志上的安排，即每個任務計劃哪天開始和計劃哪天結束。

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

團隊形式的日程計劃考慮

資源平衡：要求項目團隊結合每個團隊成員的工作效率、工作內容以及資源水平，找到一個時間點，讓所有團隊成員幾乎同時完成任務

資源同步：安排日程時必須兼顧某些項目人物之間的依賴關系。

6.9.1.2. 典型計劃流程回顧

估算規(guī)模

估算資源

規(guī)劃日程

6.9.2. 質量計劃原理和方法

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

典型的質量保證活動包括了個人評審、團隊評審、單元測試、集成測試以及驗收測試等。

在質量計劃中需要解決的關鍵問題是該開展哪些活動，以及這些活動開展的程度，如時間、人數和目標是什么。

6.9.3. 風險計劃

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

風險管理是一個持續(xù)的、前瞻的過程，此過程是項目管理的重要部分。有效的風險管理是通過相關干系人的合作與參與，盡快且積極地識別風險，指定項目風險管理計劃。

風險管理需要同時考慮有關成本、進度、績效以及其他風險的內部及外部來源。

在項目初期進行變更或修正的工作負荷，通常比在項目后期來得容易、花費較低且較不具破壞性。

早期且積極的風險偵測是重要的。

風險管理大致分為兩部分，即風險識別和風險應對。

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

6.9.3.1. 風險識別

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

問題：已經發(fā)生的，比如人員調動等。

典型的識別方法

檢查WBS的每個組件以找出相應的風險

使用定義好的風險分類表上來評估風險

訪談相關的領域專家

與類似項目進行比較來審查風險管理

檢查以往項目的總結報告或組織級數據庫

檢查設計規(guī)格和協議書需求。

典型的風險識別活動包括

識別與成本、進度及績效相關的風險

審查可能影響項目的環(huán)境因素

審查工作分解結構的所有組件，作為風險識別的一部分，以協助確保所有的工作投入均已考慮

審查項目計劃的所有組件，作為風險識別的一部分，以確保項目在各方面均已考慮

記錄風險的內容、條件及可能的結果

識別每一風險相關的干系人

利用已定義的風險參數，評估已識別的風險

依照定義的風險類別，將風險分類并分組

排列降低風險的優(yōu)先級

可能性很低，但是發(fā)生影響程度很大：政策變化、領導層大規(guī)模變動、公司倒閉

[P（可能性）, I（影響程度）, T(閾值)]

6.9.3.2. 風險應對

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

典型的策略包括

風險轉嫁

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

比如有的公司采取外包的方式，把一部分有技術風險的產品組建交由其他公司開發(fā)，在放棄部分收益的同時，也規(guī)避了技術風險。

風險解決

指采用一些有效措施，使得風險的來源不再存在。

這往往是一種預防性的手段，比如針對項目面臨的技術風險，采取技術調研或者引進技術專家的手段，使得原有的風險來源不再存在或者存在可能性極低，從而測試解決該風險。

風險緩解

指容忍風險的存在，采取一些措施監(jiān)控風險，不讓風險對項目最終目標的實現造成負面影響。

一般情況下，都需要指定相應的風險緩解計劃：理性對待每個關鍵性的風險，研究可選擇的應對方案，并對每個風險皆制定相應的行動過程，是風險緩解計劃的關鍵內容。

特定風險的風險緩解計劃包括規(guī)避、降低及控制風險發(fā)生可能性的技術和方法，或降低風險法身時遭受的損失程度的方法，或上述兩者。

監(jiān)控風險：

當風險超過設定的閾值時，實施風險緩解計劃，以使受沖擊的部分回歸到可接受的風險等級。

只有當風險結果評定為高或者無法接受時，才相應指定風險緩解計劃和緊急應對計劃，其他情況只需要適當監(jiān)控即可。

6.9.4. 計劃評審與各方承諾

項目各項計劃完成之后，需要與各類計劃的相關干系人開展評審工作，解決工作中相互矛盾與不一致的地方，并獲得參與項目的各方對項目計劃的承諾。

識別每一項計劃所需支持，并與相關干系人協商承諾。

記錄所有的承諾，包括完整的承諾和臨時的承諾，并確保由適當層次的人員簽署。

適當與資深管理人員一起審查承諾。

6.9.5. 考試題

【2020-mid】完成一份完整的項目日程計劃，需要下列哪些信息?(ABD)

任務清單

任務順序

質量要求

人員資源水平

【2013】【2014】【2015A】【2015B】【2016】如何制定一份讓人無法拒絕的計劃，請描述基本步驟和一些注意事項 10’

制定任務計劃和日程計劃：前者描述項目所有的任務清單，任務之間的先后順序、以及每個任務所需時間資源，后者描述了各個任務在日程上的安排，哪天開始哪天結束;

制定資源計劃

這種?程計劃的關鍵是必須?正推的?式來制訂項?計劃。?個典型的項?計劃框架如下圖

在這個過程中，除了概要設計和資源估算之外，其他環(huán)節(jié)盡可能?動化完成。充分參考歷史數據進?估算。

【2014】應對風險的典型策略有哪些?請舉例說明

【2014】為了確保最終軟件產品的質量，在項目計劃階段應該注意哪些問題？4分

6.10. 團隊項目規(guī)劃：TSP項目啟動

6.10.1. TSP的九次會議

• 幾個認識
  • 錯誤的認識：軟件開發(fā)階段理解為注入缺陷的階段，軟件測試階段理解為消除缺陷的階段。
  • 正確的認識：開發(fā)和測試都是既有可能引入缺陷，也有可能消除缺陷的階段
• 項目完成的實際時間由什么決定？最晚完成的工作的人決定的
• 經過平衡的計劃和沒有平衡的計劃有什么不一樣？更有把握去成功。

6.10.2. 考試題

【2020-mid】在TSP的團隊組建過程中，確定軟件開發(fā)策略的是第幾次會議??

第一次

第二次

第三次

第四次

6.11. 團隊項目跟蹤與分析

6.11.1. 項目跟蹤意義

在項目進展過程中開展跟蹤活動的目的在于了解項目進度，以便在項目實際進展和計劃產生嚴重偏差時，可采取適當的糾正措施。

項目進度滯后與是否需要參照物，即項目計劃。

項目跟蹤需要管理偏差而采取的糾偏措施。

團隊項目的跟蹤與管理主要包括進度的跟蹤（利用不同跟蹤方法，例如掙值管理、里程碑評審）、糾偏活動管理

6.11.2. 項目的掙值管理方法（EVM，Earned Value Managerment)

6.11.2.1. 什么是EVM？

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

每項任務實現附以一定價值（credit）

100%完成該項任務，就獲得相應的價值。

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

6.11.2.2. 掙值管理實現

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

實現方式

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

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

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

常用規(guī)則

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

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

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

中級實現

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

典型計算方式有

日程偏差SV = EV – PV

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

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

6.11.2.3. 掙值管理圖解

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

中間的線是預算（每天需要完成多少掙值）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不做了（項目進度落后變?yōu)榱隧椖窟M度正常）

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

6.11.2.4. 掙值管理的度量

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

成本差異CV = EV-AC，表示的是已經完成的工作與所消耗的成本的差異。可以表示為消耗的時間，也可以表示為消耗的資金。

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

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.5. 掙值管理的應用

發(fā)現項目已經滯后

削減功能，使得已經完成的任務的EV值增加

通過加班或加人等手段，有效提升獲取EV值的速度

見課本126頁相關例子

EV值顯示的項目落后可能是假象

分析例子

6.11.2.6. 掙值管理的局限性

一般不能應用軟件項目的質量管理。

需要定量化的管理機制，這就使得在一些探索型項目以及常用的敏捷開發(fā)方法中的應用受到限制。

完全依賴項目的準確估算，然而在項目早期，很難對項目進行非常準確的估算。

6.11.2.7. 另一種掙值管理變形：燃盡圖

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

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

6.11.2.8. 考試題

【2020-mid】下列關于掙值管理方法的描述中錯誤的是??

這是一種可以用來跟蹤項目預算消耗的方法

這種方法高度依賴估算準確性

這種方法可以支持質量管理

這種方法可以用來跟蹤項目進度

6.11.3. 里程碑評審

軟件項目的里程碑往往是指某個時間點，用以標記某些工作的完成或者階段的結束。

典型的里程碑事件：

完成某項工作

獲得干系人簽字認可

完成某產物的評審

修改或交付某產物

里程碑評審的審查內容包括：

項目相關的承諾，如日期、規(guī)格、質量等等；

項目各項計劃的執(zhí)行狀況；

項目當前的狀態(tài)討論；

項目面臨的風險討論等

里程碑評審也可用于質量管理

6.11.4. 其他類型跟蹤方法

日程計劃跟蹤

承諾計劃跟蹤

風險計劃跟蹤

數據收集計劃跟蹤

溝通計劃跟蹤

6.11.5. 糾偏活動的管理

典型的糾偏活動包括：偏差原因分析、糾偏措施定義、糾偏措施管理

偏差原因分析：收集偏差相關的各種信息，基于收集到的信息，開展充分的分析工作，找出偏差的根本原因。

糾偏措施定義：確認偏差的根本原因，就可以有針對性地定義糾偏的措施。

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

6.11.6. 項目審查

審查的內容包括

項目相關的承諾，如日期、規(guī)格、質量等等。

項目各項計劃的執(zhí)行狀況。

項目當前的狀態(tài)討論

項目面臨的風險討論

其他計劃跟蹤

日程計劃跟蹤

承諾計劃跟蹤

風險計劃跟蹤

數據收集計劃跟蹤

溝通計劃跟蹤

6.12. 項目總結

6.12.1. 項目總結的定義

項目總結需要系統化有條理的進行，才能不遺漏重要的內容。

因此往往需要事先定義總結過程，然后就按部就班地開展總結工作。

6.12.2. 一般項目總結流程

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

項目范圍包括產品范圍和項目范圍。對項目范圍管理的總結應當主要關注項目的需求開發(fā)過程與變更管理中的得失，對需求管理實際執(zhí)行情況的差距進行原因分析，找到改進的機會。

時間管理所關注的就是項目的日程計劃以及對日程計劃的跟蹤和管理狀況。因此主要考察計劃的準確程度以及各個里程碑的偏差情況。

成本管理包括對成本進行估算、預算和控制的各個過程，從而確保項目在批準的預算內完工

質量管理包括執(zhí)行組織確定質量政策、目標與職責的各過程和活動，從而使項目滿足其預定的需求。

人力資源管理包括組織、管理與領導項目團隊的各個過程。

溝通管理包括為確保項目信息及時且恰當地生成、收集、發(fā)布、存儲、調用最終處置所需的各個過程

風險管理包括風險管理規(guī)劃、風險識別、風險分析、風險應對規(guī)劃和風險監(jiān)控等各個過程。

采購管理包括從項目組織外部采購或獲得所需產品、服務或成果的各個過程。

整合管理包括為識別、定義、組合、統一與協調項目管理過程組的各過程及項目管理活動而進行的各種過程和活動

6.12.3. TSP項目總結方式

準備階段

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

可以結合典型TSP團隊角色，逐個討論改進領域。如團隊領導力、計劃準確性、過程優(yōu)劣、質量管理能力、開發(fā)環(huán)境以及配置管理等。

此外，也可以就TSP教練的作用進行評價。

過程數據評審階段還要求開發(fā)團隊的所有成員都整理過程改進提案（PIP）：PIP是TSP過程中供開發(fā)人員在日程工作中記錄改進想法的工具。其基本思想是積累小的改進，慢慢形成大的改進。在軟件開發(fā)過程中，重大的改進機會不多，因此，往往需要從小做起，慢慢積累之后，就會形成對原有過程的顯著改進。小的改進機會雖然多，但是容易被遺忘，PIP的作用就在于提供了一個標準表格工具，允許軟件工程師時時記錄改進方案。在項目總結階段，將開發(fā)過程中記錄的所有PIP整理出來，形成整個開發(fā)周期的過程改進提案，供討論，以確定下個開發(fā)周期要實施的過程改進。

人員角色評價階段（角色包括項目組長、計劃經理、開發(fā)經理、質量經理、過程經理和支持經理）：詳見Lec-4

總結報告撰寫階段

6.12.4. 通用項目總結流程

準備階段

總結階段

報告階段

6.12.5. 項目總結的意義

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

6.13. 項目管理支持活動

項目管理支持活動包含：配置管理、度量和分析、決策分析和根因分析。

6.13.1. 配置管理

6.13.1.1. 配置管理的目的

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

6.13.1.2. 配置管理的概念

配置項：

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

典型的可能作為配置項納入配置管理的工作產品包含過程說明文檔、項目開發(fā)計劃文檔、需求規(guī)格說明書、設計規(guī)格說明書、設計圖表、產品規(guī)格說明書、程序代碼、開發(fā)環(huán)境，如特定版本的編譯器等、產品數據文件、產品技術文件、用戶支持文檔

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

發(fā)布一個基線包括該基線所有的配置項以及這些配置項的最新變更，因此，可以將基線作為接下來工作的基礎。

典型的發(fā)布基線時間點為需求分析之后、設計完成之后、單元測試之后以及最終產品發(fā)布。

是配置項持續(xù)演進的穩(wěn)定基礎

6.13.1.3. 配置管理的流程

配置管理是用管理的手段監(jiān)督和指導如下工作的流程[CMMI 2006]

識別和記錄配置項的物理特性和功能特性

控制上述特性的變更；

記錄和報告變更過程和相應的配置項狀態(tài)

驗證配置項是否與需求一致

6.13.1.4. 配置管理活動

識別配置項

建立配置管理系統

創(chuàng)建和發(fā)布基線

跟蹤變更請求

控制配置項變更

建立配置管理記錄

配置審計

配置管理各個活動之間的關系

6.13.1.5. 考試題

【2013】請解釋配置管理中配置項和產品基線的概念，并設計一個流程對單元測試后已經納入配置庫的代碼，修改集成測試中的若干問題后，該如何控制變更

配置項和產品基線的概念如上

如何控制變更

跟蹤變更請求:

啟動變更請求處理程序，將變更情況保存在變更請求數據庫中

分析變更建議和所需進行的修改將對工作產品、進度、日程等造成的影響

如果變更請求影響到其他基線，則與相關的干系人一起審查這些變更請求，并取得他們的同意

跟蹤變更申請直到結項

控制配置項變更:

確認這些修訂已得授權

更新配置項

將舊基線歸檔保存，并獲取新基線

執(zhí)行審查，確保該變更沒有對基線造成意料外的影響

上當記錄配置項的變更內容和變更理由

6.13.2. 度量和分析

6.13.2.1. 度量和分析簡介

意義：在軟件項目管理決策的過程中，基于客觀的數據很重要，這種客觀決策可以顯著消除錯誤決策的風險。而這些客觀數據的獲得，必須依照一定的流程以正確的方式獲得和使用。度量和分析活動就定義了上述客觀數據的獲取與使用方式。

目的：建立與維持度量能力，以支持管理的信息需要。

6.13.2.2. 度量和分析活動

建立度量目標

指定度量方式

指定數據收集和保存的流程

指定分析流程

收集度量數據

分析度量數據

保存數據和結果

交流度量結果

活動組成就是8個圓圈內的內容

6.13.2.3. GQM方法的原理和應用

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

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

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

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

示例：

例子一：PM

G：確保穩(wěn)定性、可預測性的開發(fā)過程來滿足計劃的里程碑

Q：我的項目是否按照計劃的軌跡前進，計劃的里程碑都能實現嘛？

M：軟件項目開發(fā)工作的揮發(fā)性(分支、流、統計變更管理UCM活動)

例子二：QM

G：最大化所有團隊貢獻者的生產力

Q：開發(fā)人員能夠完成分配給他們的任務嗎，或者他們遇到障礙了嗎？

M：由個體或者工作組產生的項目工作的量級

詳見課本153-155頁

6.13.2.4. 考試題目

【2013】請結合GQM思想解釋PSP過程的基本度量元有哪幾個？

【2015B】請描述?下度量和分析活動在?個軟件項?當中的作?，以及應該如何正確開展？10’

可以描述度量和分析活動

也可以描述GQM

6.13.3. 決策分析

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

決策分析往往包含以下活動

建立決策分析指南

建立評價標準

識別候選方案

選擇評價方法

評價候選方案

選擇解決方案

6.13.4. 根因分析

避免類似錯誤反復發(fā)生

一個正式根因分析過程往往包含下列的活動：

識別和選定問題

根因分析

建立改進的行動方案

實施改進，評估效果

6.14. 團隊動力學

軟件開發(fā)的特點

軟件開發(fā)是一項既復雜又富有創(chuàng)造性的知識工作。

軟件開發(fā)：智力勞動，需要處理和討論極其抽象的概念，并把不同的部分（不可見）整合成一個可以工作的系統。

要求從事軟件開發(fā)的工程師

必須全身心地參與工作：知識工作必須是全身心投入的，任務切換一般需要30分鐘才能全身心的投入。

主觀意愿上努力追求卓越。

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

激勵手段

維持激勵手段

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

要自我管理，知識工作者必須(自我管理的前提條件)

有積極性

能做出準確的估算和計劃

懂得協商承諾

有效跟蹤他們的計劃

持續(xù)地按計劃交付高質量產品。

知識工作者實現自我管理：膠凍狀團隊。

知識工作者的管理需要的是領導者，而不是經理，領導者需要誠實、有能力、有遠見、鼓舞人心。

6.14.1. 自主團隊

6.14.1.1. 團隊定義

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

6.14.1.2. 自主團隊的含義

軟件工程師所從事的工作一般稱之為復雜的知識工作。在這種性質的工作中，實現軟件工程師的自我管理往往可以獲得最好的工作效率和質量水平。如果整個團隊的所有成員都實現了自我管理，也就形成了所謂的自主團隊。

6.14.1.3. 自主團隊的特點

自行定義項目的目標

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

自行決定項目的開發(fā)策略

自行決定項目的開發(fā)過程

自行制定項目的開發(fā)計劃

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

6.14.1.4. 自主團隊的必要性

自主團隊可以形成“膠凍態(tài)團隊”。在這樣的團隊中存在一種神奇的力量，這種神奇力量彌漫于該團隊做的所有工作

團隊成員互相支持，更為重要的是，團隊成員在任何時刻都知道應該以怎樣的方式幫助別人;團隊成員相互信任，有強烈的歸屬感

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

6.14.1.5. 自主團隊的形成

自主團隊不是偶然形成的。

大部分情況下，在團隊建立之初，團隊成員往往有著不同的目標;缺乏清晰的角色定義和職責安排。對于待開發(fā)的產品只有模糊的概念;團隊成員也有著不同的工作習慣和工作方法。

經過一段時間的協同工作，團隊成員可以慢慢培養(yǎng)團隊協作方式，從而逐漸演化成自主團隊。

6.14.1.6. 自主團隊的外部環(huán)境

項目啟動階段獲得管理層的支持

項目小組應當表現出已經盡最大的可能在滿足管理層的需求的工作態(tài)度。

項目小組應當在計劃中體現定期需要向管理層報告的內容。

項目小組應當向管理層證明他們所制定的工作計劃是合理的。

項目小組應當在項目中體現為了追求高質量而開展的工作。

項目小組應當在工作計劃中允許必要的項目變更。

項目小組應當向管理層尋求必要的幫助。

在項目進展過程中獲得管理層的支持

項目小組應當嚴格遵循定義好的開發(fā)過程開展項目開發(fā)過程。

項目小組應當維護和更新項目成員的個人計劃和團隊計劃。

項目小組應當對產品質量進行管理。

項目小組應當跟蹤項目進展，并定期向管理層報告。

項目小組應當持續(xù)地向管理層展現優(yōu)異的項目表現。

6.14.2. 激勵方式

威逼：完全依靠不同角色的等級關系，通常是上級強制要求下屬必須完成某些工作。

利誘：通過許諾一定的好處來吸引下屬努力工作

鼓勵承諾：

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

位于馬斯洛需求理論的4級以上，應當是主要的方式，并且最好以團隊為單位做出承諾

6.14.2.1. 交易型領導方式

承諾獎勵激勵

人們通常能找到新的方式來獲得獎勵，同時少做工作。

威逼和利誘屬于交易型領導方式。

6.14.2.2. 轉變型領導方式

用成就激勵

鼓勵承諾屬于轉變型領導方式。

由于交易型領導方式很少能產生成功并且有創(chuàng)造性的團隊，因此轉變型領導方式是首選。

6.14.3. 馬斯洛的需求層次理論

五個層次：生理需求(Physiological)、安全感(Safety)、愛和歸屬感(social)、獲得尊敬(Esteem)、自我實現(Self-Actualization)

注意

自我實現是最高的層次。

激勵來自為沒有滿足的需求而努力奮斗。

低層次的需求必須在高層次需求滿足之前得到充分滿足。

滿足高層次的需求的途徑比滿足低層次的途徑更為廣泛。

威逼利誘比較低層，鼓勵承諾在4-5層，效果比較好

6.14.4. 承諾文化的建立與團隊激勵

在個人級別，承諾有很大差異

有些人對承諾非常認真

有些人對承諾非常輕率。

在滿足以下條件下，團隊承諾比個人承諾的激勵作用更大

所有團隊成員共同參與作出承諾。

團隊依賴于每一位成員履行自己的承諾。

如果有計劃在支撐承諾，那么就更為可信

軟件開發(fā)團隊在制定承諾時

需要保證承諾是自愿的、公開的、可信(行)的，向團隊做出承諾。

承諾需要有詳細計劃支撐

開發(fā)者需要參與承諾的協商和設計。

除了以團隊形式作出承諾以外，承諾文化的建立還要求在項目進行過程中維持承諾水平。

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

反饋信息包括項目進度、更新后的項目計劃以及里程碑實現情況等。

leader和manager的區(qū)別

維持激勵需要及時的績效反饋

績效反饋包括

根據一個詳細計劃衡量進度。

當前計劃不準確時重做計劃，想想為什么？

為漫長而富有挑戰(zhàn)性的項目提供中間反饋，即里程碑，想想為什么？

激勵水平的重要影響因素

回報：回報越大，激勵水平越高

期望：完成這件事情的把握越大，激勵水平越高

6.14.4.1. 海茲伯格的激勵理論

激勵因素（內在因素）：成就感、責任感、晉升、被賞識、認可。

保健因素（外在因素）：工作環(huán)境、薪金、工作關系、安全等。

6.14.4.2. 麥克勒格的 X、Y－理論

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

不喜歡他們的工作并努力逃避工作

缺乏進取心，沒有解決問題與創(chuàng)造的能力

更喜歡經常的指導，避免承擔責任，缺乏主動性

自我中心，對組織需求反應淡漠，反對變革

用馬斯洛的底層需求（生理和安全）進行激勵

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

如果給予適當的激勵和支持性的工作氛圍，會達到很高的績效預期

具有創(chuàng)造力，想象力，雄心和信心來實現組織目標

能夠自我約束，自我導向與控制，渴望承擔責任

用馬斯洛的高層需求（自尊和自我實現）進行激勵

6.14.4.3. 期望理論 Expectancy Theory

人們在下列情況下能夠收到激勵并且產生出大量成果 M = V * E

相信他們的努力很可能會產生成功的結果（V）

相信自己因為成功而得到相應的回報（E）

Motivation = Valence x Expectancy(Instrumentality)，即激發(fā)力量 = 效價 X 期望值

M 表示激發(fā)力量，是指調動一個人的積極性，激發(fā)人內部潛力的強度。

V 表示目標價值（效價），這是一個心理學概念，是指達到目標對于滿足他個人需要的價值。同一目標，由于各個人所處的環(huán)境不同，需求不同，其需要的目標價值也就不同。同一個目標對每一個人可能有三種效價：正、零、負。效價越高，激勵力量就越大

E 是期望值，是人們根據過去經驗判斷自己達到某種目標的可能性是大還是小，即能夠達到目標的概率。目標價值大小直接反映人的需要動機強弱，期望概率反映人實現需要和動機的信心強弱。

6.14.4.4. 提高成功把握的兩種方法

現實扭曲力場(喬布斯傳)

數據

6.14.5. 考試題

【2013】【2015A】【2016】請結合軟件開發(fā)特點介紹軟件項目管理中自主型團隊的必要性

【2014】自主團隊有哪些特點？為什么說這樣的團隊可以滿足軟件開發(fā)對團隊的要求

自主團隊特點如上

軟件開發(fā)?種智?活動，開發(fā)者是智?勞動者，?對于智?勞動者??，管理的第?準則就是智?勞動者不能被管理，只能實現?我管理：

處理和討論?常抽象的概念

把不同的部分整合成?個可以?作的正確的系統

全??地參與

努?做出卓越的?作

【2020-mid】請結合軟件開發(fā)的特點介紹軟件項目管理中自主型團隊的必要性以及自主團隊應該具備的特征?5分

軟件開發(fā)是一項既復雜又富有創(chuàng)造性的知識工作 (1’)

軟件開發(fā)是一種智力勞動 (1’)

處理和討論 極其抽象的概念

把不同的部分(不可見)整合成一個可以工作的系統

自主團隊具備如下的特點: (每兩點1分)

自行定義項目的目標

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

自行決定項目的開發(fā)策略

自行定義項目的開發(fā)過程

自行制定項目的開發(fā)計劃

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

【2014】馬斯洛的“人的需求層次理論”描述的需求層次有哪幾個?這樣分層對軟件開發(fā)有什么啟發(fā)？6’

6.15. TSP的典型角色

6.15.1. 項目組長

項目組長的目標和衡量指標

項目組長應當建設和維持高效率的團隊。

項目組長應當激勵團隊成員積極工作。

項目組長應當合理處理團隊成員的問題。

項目組長應當向管理層提供項目進度相關的完整信息。

項目組長應當充當合格的會議組織者和協調者。

6.15.1.1. 典型技能

你是天生的領導者

你有能力識別問題的關鍵并且做出客觀的決策

你不介意偶爾充當“惡人”

你尊敬你的團隊成員

6.15.1.2. 工作內容

激勵團隊成員努力工作

主持項目周例會

每周匯報項目狀態(tài)

分配工作任務

維護項目資料

組織項目總結

6.15.2. 計劃經理

開發(fā)完整的、準確的團隊計劃和個人計劃

每周準確的報告項目小組狀態(tài)

6.15.2.1. 典型技能

最為重要的一點是，你做事有條理和邏輯

你對于過程數據非常感興趣，期待通過每周輸入的數據來了解項目當前狀況

你認為計劃非常重要，也愿意要求團隊成員跟蹤和度量他們的工作

6.15.2.2. 工作內容

帶領項目小組開發(fā)項目計劃

帶領項目小組平衡計劃

跟蹤項目進度

參與項目總結

6.15.3. 開發(fā)經理

開發(fā)優(yōu)秀的軟件產品

充分利用團隊成員的技能

6.15.3.1. 典型技能

你喜歡創(chuàng)造事物

你愿意成為軟件工程師，并且喜歡帶領團隊開展設計和開發(fā)工作

你具備足夠的背景可以勝任設計師的工作，并且可以領導設計團隊開展工作

你熟悉主流的設計工具

你愿意傾聽和接受其他人的設計思想

6.15.3.2. 工作內容

帶領團隊制定開發(fā)策略。

帶領團隊開展產品規(guī)模估算和所需時間資源的估算。

帶領團隊開發(fā)需求規(guī)格說明。

帶領團隊開發(fā)高層設計。

帶領團隊開發(fā)設計規(guī)格說明。

帶領團隊實現軟件產品。

帶領團隊開展集成測試和系統測試。

帶領團隊開發(fā)用戶支持文檔。

參與項目總結

6.15.4. 質量經理

項目團隊嚴格按照質量計劃開展工作，開發(fā)出高質量的軟件產品

所有的小組評審工作都正常開展，并且都形成了評審報告

6.15.4.1. 典型技能

你關注軟件產品的質量

你有評審方面的經驗，熟悉各種評審方法

你有協調組織有效評審的能力

6.15.4.2. 工作內容

帶領團隊開發(fā)和跟蹤質量計劃

向項目組長警示質量問題

軟件產品提交配置管理之前，對其進行評審，以消除質量問題

項目小組評審的組織者和協調者

參與項目總結

6.15.5. 過程經理

所有團隊成員準確的記錄、報告和跟蹤過程數據。

所有的團隊會議都有相應會議記錄。

6.15.5.1. 典型技能

你對過程定義、過程度量非常感興趣

你對過程改進非常感興趣

6.15.5.2. 工作內容

帶領團隊定義和記錄開發(fā)過程并且支持過程改進。

建立和維護團隊的開發(fā)標準。

記錄和維護項目的會議記錄。

參與項目總結。

6.15.6. 支持經理

項目小組在整個開發(fā)過程中都有合適的工具和環(huán)境

對于基線產品，不存在非授權的變更

項目小組的風險和問題得到跟蹤

項目小組在開發(fā)過程中滿足復用目標

6.15.6.1. 典型技能

你對于各種開發(fā)工具很感興趣，熟悉各類工具的適用場合。

你對版本控制工具很熟悉，也熟悉配置管理流程。

對于本項目所有工具而言，你都是專家。

6.15.6.2. 工作內容

帶領團隊識別開發(fā)過程中所需要的各類工具和設施。

主持配置管理委員會，管理配置管理系統。

維護軟件項目的詞匯表。

維護項目風險和問題跟蹤系統。

支持軟件開發(fā)過程中復用策略的應用。

參與項目總結。

6.15.7. 開發(fā)人員

6.15.8. 考試題題目

【2016】TSP項目經理、過程經理、計劃經理的工作內容、項目總結角度 9’

【2020-mid】下列描述當中，屬于過程經理的工作內容有哪些?(AC)

建立團隊的開發(fā)標準

主持項目周例會

記錄周例會的會議記錄

制定開發(fā)計劃

7. 定量管理與仿真建模

7.1. 高成熟度項目管理

CMMI模型

7.1.1. 一般的項目管理

主要關心

當前狀況（注意：也可能使用數據）

是否需要調整干預

但是，回答不了必須進行預測的問題，例如

維持現狀，項目最后是否能成功？

如果某些方面進行調整，會有什么不同的結果？

7.1.2. 定量的項目管理

基于數據，主要關心

你對當前狀態(tài)理解是否有足夠信心？

對偏差的理解

回答如下典型問題

項目最后是否能成功？多大把握？是否需要預防？

如果某些方面進行調整，會有什么不同的結果？

7.2. 為什么需要理解偏差

有的時候，我們會面臨這樣的問題

客戶希望10周以內交付，但是，歷史數據表明，類似任務是9~11周完成，那這個任務該接受么？

7.3. 定量管理基本范式

構建定量模型

子過程能力基線

過程模型

應用模型：監(jiān)控影響子過程的關鍵因素

7.4. 基本概念

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

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

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

7.5. 定量模型構建的關鍵實踐

基于Yield來構建一個基本的缺陷預測模型，假設

上述階段分別為需求開發(fā)、需求評審、設計、設計評審、編碼、測試；

需要基于該模型也測最終產出物中有多少個缺陷？

討論

需要補充哪些數據？請設計一個可行的數據獲取要求；

上述數據顯然不可能是一個恒定不變的數據，該如何處理？

7.6. 定量模型應用（定量管理）的關鍵實踐

7.7. 常用定量管理技術

定量管理技術通常被分為非統計技術和統計技術，這些技術的使用能夠幫助解決軟件項目管理中多種問題。

7.7.1. 常用非統計技術

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

7.7.1.1. 常用非統計技術：直方圖

直方圖以頻率統計的方式進行顯示，可以描述過程屬性的頻率，例如缺陷修復的時間、每次測試發(fā)現的缺陷的個數、每天無故障工作的時間、計算產品的不合格率等。

一般用于有助于判斷過程是否正常，過程能力是否滿足需要，不良產品是否發(fā)生，分析產品質量問題的原因等。

7.7.1.2. 常用非統計技術：帕累托圖

一種特殊的直方圖

按照由高到低排列的直方圖

7.7.1.3. 常用非統計技術：因果圖

因果圖是用來分析影響產品質量的各種原因的一種有效的定性的分析圖，它將對特性或結果有影響的要素加以分類分析，是一種發(fā)現問題根本原因的方法，可以讓項目組成員通過頭腦風暴、集思廣益的方法從各個方面各種不同的角度找出這些問題的所有原因。

7.7.1.4. 常用非統計技術：散布（點）圖

整理和觀察收集到的數據的常用圖形工具

散布圖表示的是一個變量相對于另一個變量的表現情況，可以假定一個變量是因變量，另一個變量是自變量。散布圖通常表現了5 種相關關系。如圖所示的散布圖中分別表現了兩個變量之間的弱正相關、弱負相關、不相關、強正相關、強負相關。

7.7.2. 常用統計技術

統計思維認識到許多決策是在不確定條件下做出的。統計方法有助于量化這種不確定性并指導采取行動以減少不確定性。

統計分析支持許多類型的決策，在支持過程管理決策的統計分析中，有效的過程管理通常需要兩級決策

實時控制單個活動或子流程

根據當前和已完成的活動對未來和最終過程的結果進行預測

常用的統計技術包括：統計過程控制圖，回歸分析，方差分析，預測區(qū)間，假設檢驗，敏感性分析等

7.7.2.1. 常用統計技術：控制圖

控制圖是根據概率統計原理構造的一種圖，用來監(jiān)測生產過程是否處于控制狀態(tài)。

控制圖是對過程質量數據測定、記錄從而進行質量管理的一種用科學方法設計的圖。

圖上有中心線(CL)、上控制限(UCL)和下控制限(LCL)，并有按時間順序抽取的樣本統計量數值的描點序列。

控制圖可由正態(tài)分布演變而來

正態(tài)分布可用兩個參數即均值μ和標準差σ來決定。正態(tài)分布有一個結論對質量管理很有用，即無論均值μ和標準差σ取何值，產品質量特性值落在μ±3σ之間的概率為99.73%，落在μ±3σ之外的概率為100%-99.73%=0.27%，而超過一側，即大于μ+3σ或小于μ-3σ的概率為0.27%/2=0.135%≈1‰。

以下顯示了不處于受控狀態(tài)的8種典型情況（異常模式）：

兩類錯誤（需要檢驗）：

Ⅰ類錯誤：虛發(fā)警報錯誤，在生產正常的情況下,純粹出于偶然而點子出界的概率雖然很小,但不是絕對不可能發(fā)生。故當生產正常而根據點出界判斷生產異常就犯了虛發(fā)警報錯誤,發(fā)生這種錯誤的概率通常記以α

Ⅱ類錯誤：漏發(fā)警報錯誤,在生產異常的情況下,產品質量的分布偏離典型分布,但總有一部分產品的質量特性值在上下控制界之內。如果抽到這樣的產品進行檢測描點,根據點未出界判斷生產正常就為漏發(fā)警報錯誤,此概率通常記以β。

8. 零散題目

【2015B】為了制定Schedule plan，下述描述中，哪?項是不需要的:(A)

Task size

Task Order

Schedule Hour

Task hour for each task

【2015B】在上題中，還需要補充下述哪?項數據就可以定義Schedule Plan了？(A)

Task List

Plan Value

Earned Value

Nothing

【2020-mid】下列術語描述的技術或者方法是同類型的是?(CD)

CMMI SPICE PDCA：SPICE是軟件過程管理

IDEAL XP SCRUM：IDEAL是軟件過程改進，XP和SCRUM是軟件過程

Cleanroom Gate TSP：軟件過程

Waterfall SCRUM XP：軟件實踐

【2015A】請列出Capture-recapture?法進?缺陷預測的假設條件和相應的模型定義

常見CRC模型定義了兩個參數，即評審者發(fā)現缺陷能?t和缺陷的難度h，t是否?致以及h是否?致都會影響模型。?邊來說，定義如下4個基本模型：

假設h和t都?樣的M0模型

假設h不等?t都?樣的Mh模型

假設t不等?h都?樣的Mt模型

假設t和h都不等的Mth模型

估算與計劃的差異

估算主要用來估算待開發(fā)程序的規(guī)模和所需資源

質量計劃用于保證項目的質量

包含的活動不同等等

總結

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

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