軟體體系結構複習指南
阿新 • • 發佈：2019-02-08
前言
作為一個熱心學長（好的其實是要湊這個月的4篇文章了），發一下李大牛同志的課程複習幫助指南，這裡有《軟核》上冊的一些總結，相信靠這個可以保你及格了，如果要高分請把書本的結構梳理清楚
一、軟體工程定義集合
| 定義 1.1（軟體） | 軟體是一組通過整合而獲得特定功能和屬性的計算機程式，及相關應用資料和輔助文件；簡寫為軟體=程式+資料+文件…… | P10 |
|---|---|---|
| 定義 2.1 軟體危機 | 軟體危機原指低下的軟體生產率難以滿足快速增長的現實需要的現象，後泛指以下“令人不滿意”的常見現象：軟體生產率低、成本高、質量低、風險高和失敗率高等 | P30 |
| 定義 2.2 軟體工程 | 軟體工程(SE)指科學知識和工程方法在軟體開發、維護和演化過程中的系統應用，即軟體的工程化 | P34 |
| 定義 2.3 軟體工程學科 | 軟體工程學科是一門以創造和應用軟體工程知識和方法為主要任務的、獨特的、摻雜藝術和工藝特徵的、各學科交叉的（尚未成熟的）工程學科 | P44 |
| 定義 3.1 軟體質量 | 軟體的質量是它滿足使用者需要和系統需求的程度，常表示為一組質量屬性的集合 | P56 |
| 定義 5.1 軟體生命期 | 軟體的生命期是指軟體從開發伊始，經成功交付和使用之後，至被“凍結”和“淘汰”的整個過程 | P86 |
| 定義 6.1 軟體原型 | 軟體原型是描述或模擬待開發軟體產品的部分或全部功能（主要是使用者介面和重要外部行為）的工作版本 | P106 |
| 定義 6.2 關注點 | 軟體的關注點是從權益人的角度對待解顯示問題的面描述，是軟體需求的更抽象形式 | P110 |
| 定義 6.3橫切型關注點 | 橫切型關注點是指需要獲得多個關注點支援或通過與其他關注點互動才能實現的關注點 | P111 |
| 定義 6.4 切面 | 切面是軟體的一類組成元素，是關注點的實現形態；一個切面封裝了實現一個關注點的所需功能 | P111 |
| 定義 8.1 軟體產品線 | 軟體產品線（SPL）是一個共享領域核心功能的，又能“更好地”，滿足各細分領域獨特需求的軟體產品集。 | P150 |
| 定義 9.1 模型 | 模型是客觀資訊體在某個特定視角上的抽象檢視。 | P162 |
| 定義 10.1 軟體需求 | 軟體需求是對軟體所應具備的功能和所應滿足的約束的抽象描述，也是對軟體權益人的現實需要和期望的正式表述 | P176 |
| 定義 11.1 需求工程 | 需求工程是所有旨在獲得、分析、描述或管理目標軟體的亟待實現的需求的活動的統稱 | P190 |
| 定義 13.1 需求獲取 | 需求獲取是定義目標軟體產品的使用者和客戶需要及相關約束，並將之描述為初始軟體需求的過程 | P214 |
| 定義 13.2 用例 | 軟體的用例是描述“參與者”（主要是使用者）所期望見到和參與的、與軟體互動的過程的 | P220 |
| 定義 14.1 需求分析 | 需求分析是從軟體產品開發的角度，針對來自於需求獲取環節的初始需求展開的進一步分析和求精 | P230 |
| 定義 14.2 需求分簇 | 需求分簇是將需求集劃分為多個需求簇的過程，一個需求簇是一個具有“簇內強關聯而簇間弱關聯”的需求子集 | P230 |
| 定義 14.3 需求依賴關係 | 需求依賴關係泛指存在於需求項之間所有關聯關係（包括各類約束關係） | P234 |
| 定義 16.1 需求確認 | 需求確認就是確認需求的正確性和完備性，即確認需求是否包含清晰、完整和可理解的資訊，是否一致於權益人（主要是使用者和客戶） | P258 |
| 定義 17.1 需求管理 | 需求管理是從軟體產品和專案的角度，針對需求過程及其下游的需求實現過程開展的規劃、監督和控制 | P270 |
| 定義 17.2 需求蔓延 | 需求蔓延是指在實現需求的過程中（如設計、構造和測試階段）中不斷湧現出的新需求的現象。 | P276 |
| 定義 17.3 需求基線 | 需求基線是為軟體產品的某待開發版本而選定的、待實現的需求集，通常是產品需求總集的一個子集 | P277 |
| 定義 18.1 需求錯誤與缺陷 | 需求錯誤是指需求工程師造成的“需求未準確表達現實需要或約束”的事實，其產出就是需求缺陷 | P287 |
| 定義 18.2 需求“缺失” | 需求“缺失”是一類需求缺陷，指缺失了“不應該缺失”的需求（進而導致軟體產品缺失了“不應該缺失”的功能或質量） | P290 |
| 定義 20.1 軟體設計 | 軟體設計是定義軟體的各層級結構元素（包括架構、構件、使用者介面和資料庫），及其屬性和行為 | P315 |
| 定義 20.2 設計模式 | 軟體的設計模式是對某類普遍問題的通用軟體解決方案的抽象描述 | P327 |
| 定義 21.1 軟體架構 | 軟體的架構是軟體的組成構件、構件之間的互動關係，以及兩者的外部可見屬性的統一表示體 | P332 |
| 定義 21.2 架構風格 | 軟體的架構風格描述一類應用領域和功能相似的軟體產品的慣用架構，常表示為一組設計規則或約束 | P345 |
| 定義 22.1 軟體構件 | 軟體的構件是架構的基本組成單元，是一類具有相對獨立功能的邏輯實體 | P361 |
| 定義 22.2 構件設計模式 | 軟體構件的設計模式描述一類構件應用所慣用的結構，常表示為一組構件設計規則或約束 | P363 |
| 定義 23.1 使用者介面 | 使用者介面是軟體的一部分，支援使用者與軟體進行互動，以滿足使用者的現實需要，最終實現軟體的真正價值 | P376 |
| 定義 27.1 軟體構造 | 軟體構造是依據既定設計方案，以編寫計算機程式的形式，實現既定需求的過程 | P482 |
| 定義 27.2 技術債 | 技術債是指在軟體開發過程中因低質量地倉促完成產品設計、構造和測試，而被透支的維演成本和時間。 | P491 |
| 定義 28.1 軟體除錯 | 軟體除錯是程式設計師在程式設計過程因發現潛存缺陷而定位和修復缺陷的過程 | P498 |
| 定義 31.1 軟體確認與驗證 | 軟體確認是指認定軟體是否滿足使用者實際需要和業界相關標準的過程；軟體驗證則是指認定軟體的設計方案和程式碼基是否實現既定需求的過程 | P546 |
| 定義 32.1 軟體缺陷 | 軟體的缺陷是指各類軟體製品（包括需求、設計、程式碼和測試文件等）中的不正確的軟體描述和實現 | P556 |
| 定義 33.1 軟體測試 | 軟體測試是以執行目標軟體（或其部分程式碼段）的方式發現它的潛在缺陷的過程 | P580 |
| 定義 33.2 測例 | 一個測例包括一段以執行待測軟體或程式碼段的程式，一個既定輸入，及其正確輸出；常簡單表示為後兩者的配對 | P581 |
| 定義 33.3 測試套件 | 一個測試套件是為實現針對待測軟體或程式碼段的特定測試目的而選定的測例集 | P582 |
| 定義 33.4 測試計劃 | 軟體的測試計劃描述了待測軟體的所有測試套件的規劃和執行過程，及相關輔助資訊 | P583 |
| 定義 33.5 單元測試 | 單元測試，又稱模組測試，是指測試一個程式碼單元，以發現其中的邏輯、演算法和資料結構方面的缺陷 | P591 |
| 定義 33.6 整合測試 | 整合測試就是測試當多個程式碼模組整合為子系統（甚至是系統）之後所表現出的整體功能 | P593 |
| 定義 33.7 系統測試 | 系統測試就是依據既定需求規約文件驗證軟體系統的功能特徵、特別是它的質量屬性 | P594 |
| 定義 33.8 驗收測試 | 驗收測試就是測試使用者接收目標軟體的程度，即測試軟體的使用者滿意度 | P595 |
| 定義 34.1 軟體審查 | 軟體審查是組織相關權益人合力找出軟體製品的缺陷，進而評估製品質量，批准和驗收製品的過程 | P612 |
| 定義 34.2 軟體評審 | 軟體評審是以正式會議的形式，由與會者分工協作，從不同角度審查同一軟體製品，以發現缺陷或違例，或批准缺陷或違例移除行動的過程 | P614 |
| 定義 37.1 軟體維護 | 軟體維護是指軟體在投入執行之後的缺陷修復或小規模功能增強，以保證其能按照既定現實需求持續運行於使用者端 | P642 |
| 定義 37.2 軟體演化 | 軟體演化是對成品軟體的大規模的功能增強或結構重整，以版本更新的方式保證軟體能夠持續滿足頻變的現實需求 | P642 |
| 定義 37.3 遺蹟危機 | 遺蹟危機是指組織歷史的遺蹟程式碼規模過於龐大，其維護和演化需要耗費絕大部分軟體預算投入，使得新軟體的開發因缺少足夠投入而被大面積地取消或嚴重拖滯的現象 | P646 |
| 定義 38.1 軟體老化 | 軟體老化是指在軟體維護和演化過程出現的使用者滿意度逐漸下降、質量逐漸降低、變更成本逐漸上升的現象 | P653 |
| 定義 39.1 軟體再工程 | 軟體的再工程是通過考察和變更軟體的結構，並實現更高質量的新結構的過程 | P670 |
二、軟體工程常識集合
| 常識1.1 軟體複雜性 | 軟體必然是十分複雜的，且還將變得更加複雜。故而，軟體開發必須採取有效的複雜性處理策略，那就是“分而治之” | P14 |
|---|---|---|
| 常識1.2 軟體頻變性 | 軟體必然會持續變更，且還將更加頻繁。變更的影響範圍必須得到有效控制，以避免對軟體整體造成不必要的負面影響 | P20 |
| 常識1.3 軟體商品性 | 大多數軟體產品都是商品，所需的投入成本高且成功風險大，但在獲得商業成功之後的價值回報也高 | P24 |
| 常識 3.1 質量價值 | 低質量產品無法創造出足額價值 | P59 |
| 常識 5.1 階段化生命期 | 軟體的生命期通常包括三大階段：開發、維護和演化。這三個階段構成了軟體工程實踐、教育和研究的主要目標域 | P88 |
| 常識 5.2 開發 vs 維演 | 相比於軟體的開發，軟體的維護和演化通常需要耗費更多的時間和更高成本，但所創造的價值也通常更多 | P89 |
| 常識 5.3 維護 VS 演化 | 相比於軟體的維護，軟體的演化通常需要耗費更高成本，但所創造的價值通常也更多 | P91 |
| 常識 6.1 階段化開發 | 軟體開發過程通常包括四大階段（即四類主要活動）：需求工程、設計、構造和質量控制階段（主要是測試和審查）。 | P94 |
| 常識 6.2 先設計後測試 | 程式設計之前先設計，程式設計之後再測試 | P104 |
| 常識 6.3 原型非產品 | 原型不是正式產品，也不能替代正式產品 | P107 |
| 常識 8.1 複用效應 | 複用的層級越高，規模就越大，積極效應也越明顯 | P140 |
| 常識 9.1 萬能模型 | 在軟體領域，不存在隨處可用的所謂“萬能“模型 | P162 |
| 常識 9.2 模型的兩面性 | 任何軟體模型皆有利有弊（即侷限性）；軟體實踐既不應誇大其利，更不應該忽視其弊 | P165 |
| 常識 9.3 模型的專案敏感性 | 軟體模型具有專案敏感性：能有效用於專案甲的模型不一定能同等有效地用於專案乙 | P166 |
| 常識 11.1 “不完美”需求 | 對於絕大多數軟體開發專案而言，其需求工程階段都不可能獲得“完美”的需求（即需求完整齊備且有高質量描述） | P192 |
| 常識 11.2 需求過程迭代並行 | 需求過程各階段（需求獲取、分析、描述和確認）相對獨立缺又緊密相連，既可多次迭代，又可部分並行。 | P195 |
| 常識 11.3 需求邊學邊做 | 需求過程是需求工程師引導各方權益人一起學習待解問題及其領域相關知識的複雜過程 | P196 |
| 常識 11.4 需求創造兼複用 | 需求過程是一個集創造新需求和複用舊需求於一體的過程。 | P197 |
| 常識 12.1 問題定義 | 軟體問題的定義是一個由表及裡、逐步尋真求全的漸進過程，也是一個與問題解決過程彼此依賴和相互“纏繞”的過程 | P200 |
| 常識 12.2 可行性分析 | 軟體專案的可行性旨在確定目標軟體產品能否較大可能地實現既定目標（例如，以既定成本收穫預期價值） | P204 |
| 常識 12.3 願景宣告 | 願景宣告必須描述待開發產品的技術目標，包括它應當具有的核心功能，必須滿足的主要約束，和應當遵守的重要建議 | P207 |
| 常識 14.1 重要需求優先 | 有潛在重大價值的需求應當給予高優先順序 | P237 |
| 常識 14.2 需求優先順序角力 | 需求分級是各方權益人為確保各自權益而角力的過程 | P238 |
| 常識 15.1 需求成文 | 將軟體需求編寫成具有合理結構的技術文件 | P246 |
| 常識 15.2 默用自然語言 | 使用客戶和使用者所熟悉的自然語言、文字、常用概念及術語描述軟體需求（特別是客戶和使用者需求） | P247 |
| 常識 15.3 慎用形式化語言 | 慎重選用形式化語言描述軟體需求 | P248 |
| 常識 15.4 需求編號並分類 | 在需求規約文件中為每個需求項編號，並將需求分類，再以需求分類為單位組織描述 | P255 |
| 常識 16.1 確認即糾錯 | 需求確認實則就是一個發現並糾正需求缺陷的過程；發現和糾正的時間越晚，其成本、難度和負面影響就越大 | P259 |
| 常識 17.1 需求入庫 | 選用合適的需求管理系統或工具，並定義良好的需求庫結構，以支援大規模需求的有效儲存、訪問和管理 | P271 |
| 常識 18.1 兼聽則明 | 任何事物都有多面性，應當從多個角度分別予以審視，方能獲得更準確而全面的認識 | P293 |
| 常識 18.2 使用者是上帝 | 使用者是軟體產品的直接服務物件；軟體開發必須儘可能地滿足使用者的現實需要 | P294 |
| 常識 19.1 需求工程師 | 需求工程師既應是掌握和擅長應用需求工程知識和技能的“專才”，又應是善於交流、合作、管理和寫作的“通才” | P304 |
| 常識 20.1 按需設計 | 軟體設計方案必須對映既定需求，適合既定開發團隊在既定專案上下文中實現目標軟體產品 | P317 |
| 常識 20.2 設計技術抉擇 | 軟體設計應優先採用適合既定產品，團隊和專案的、成熟而廣泛有效的技術，不要刻意求新 | P318 |
| 常識 20.3 創新設計 | 軟體設計是設計師通過理解目標問題及相關約束，運用專業知識、經驗和技能，創造出個性化設計方案的複雜創新過程 | P320 |
| 常識 20.4 不完美設計 | 軟體設計無法完全滿足各方權益人的全部權益，故無法創造出所謂“完美”的設計方案 | P322 |
| 常識 20.5 質量設計 | 軟體設計必須重視並周密考慮產品質量；設計一經完成，軟體質量就已經基本定性和定型（之後再難有大幅度變更） | P323 |
| 常識 26.1 軟體設計師 | 軟體設計師既應是掌握和擅長應用軟體開發知識和技能的“專才”，又應是善於技術決策、交流、合作和寫作的“通才” | P466 |
| 常識 33.1 Dijkstra測試 | 測試只能用於發現軟體的潛存缺陷，卻不能用於證明軟體不存在缺陷 | P584 |
| 常識 33.2 測試與使用者滿意度 | 測試員不能代表使用者，軟體測試也不能保證它的使用者滿意度 | P585 |
| 常識 33.3 測試階段順序 | 階段化測試的一般實施順序是：單元測試->整合測試->系統測試->驗收測試 | P591 |
| 常識 36.1 服務生 | 測試員是服務生，要服務好程式設計師 | P636 |
| 常識 36.2 客戶代表 | 測試員是客戶的技術代表，先行驗收產品 | P636 |
三、軟體工程理念集合
| 理念 1.1 分而治之 | 將軟體的複雜目標問題分解為多個彼此相對獨立且又易於解決的子問題，然後分別解決每個子問題 | P18 |
|---|---|---|
| 理念 1.2 擁抱變更 | 開發具有良好可變性的軟體，既要保證變更易於實現，又要保證變更不易於破壞軟體的整體結構和屬性 | P23 |
| 理念 1.3 提高價值/成本比 | 所有軟體實踐都應關注它的成本、風險和價值，著力於降低成本、控制風險和創造價值 | P25 |
| 理念 2.1 四角天平 | 軟體實踐必須折中地滿足如下四方關鍵權益人的核心權益：“客戶”，“使用者”，“工程方”，“工程師”（四者次序部分先後） | P43 |
| 理念 7.1 增量-迭代開發 | 將軟體開發過程分為若干次迭代（子）過程。完成一次迭代就交付一個版本，或實現新需求，或求精已實現的需求。 | P121 |
| 理念8.1 批量定製 | 基於領域平臺，快速開發出高質量的、面向細分使用者群體的系列產品 | P153 |
| 理念 9.1 模型定製 | 結合經驗，依據專案上下文（包括專案特徵、團隊經歷、組織文化等），定製所需的軟體模型 | P166 |
| 理念 11.1 適度需求工程 | 保證適度的需求工程：組建專業需求團隊，並投入軟體開發總預算成本和時間的15%至30% | P193 |
| 理念 17.1 全程需求管理 | 持續地管理軟體需求，覆蓋軟體產品的整個生命期，甚至更長時間 | P270 |
| 理念 17.2 可持續開發 | 制訂具有可持續性的需求版本計劃，以保證軟體版本系列的持續競爭力，並實現總價值收益的最大化。 | P280 |
| 理念 20.1 常態設計 | 合理地使用設計模式進行軟體設計 | P328 |
| 理念 23.1 面向使用者的統和介面 | 軟體產品介面必須面向使用者，統和功能、情感、環境、社會和個性元素，具備全功能、可用且美觀等特徵 | P377 |
| 理念 24.1 演化型資料庫開發 | 以迭代的方式，逐步完成資料庫設計和實現，保持資料庫與程式之間的“和諧同步”開發 | P416 |
| 理念 24.2 資料驅動設計 | 基於軟體應用資料的特徵，設計資料庫。 | P420 |
| 理念 25.1 SBN雙峰螺旋模型 | 需求過程與設計過程既相互影響又相互滲透，以迭代和部分並行的螺旋方式逐步定義出軟體需求和設計方案 | P436 |
| 理念 29.1 人本主義程式設計 | 程式碼應著重服務於它的讀者群體，其次才是它所處的目標系統的軟硬體系統 | P512 |
| 理念 29.2 簡潔程式設計 | 編寫簡單明瞭的程式碼 | P513 |
| 理念 29.3 質量程式設計 | 一如既往地自覺編寫高質量的程式碼 | P515 |
| 理念 33.1 全程測試 | 軟體測試應始於需求階段，並貫穿於整個開發過程 | P586 |
| 理念 33.2 階段化測試 | 分階段地實施測試，每個測試階段確立並實現相對獨立而不重複（或較少重複）的測試目標 | P590 |
| 理念 34.1 階段化審查 | 在軟體開發的各主要階段，針對各類軟體製品（包括需求、設計、測試和程式碼製品），有計劃地組織階段性審查 | P613 |
四、軟體工程定律集合
| （額外） 摩爾定律 | 整合電路板上的電子晶體數目每24個月翻一番，且效能也隨之翻一番。當前流行的說法是同樣造價的計算機效能每18個月翻一番 | P32註釋 |
|---|---|---|
| 定律 2.1 DeRemer規模 | 能有效用於小型軟體產品和專案的工程技術和經驗都不能同等有效地應用於大型軟體產品和專案 | P38 |
| 定律 2.2 Brooks“銀彈” | 軟體開發沒有“銀彈”，即不存在能夠在短時間內顯著改善軟體生產率和質量的技術、過程、語言和工具。 | P39 |
| 定律 2.3 Mills生產率定律 | 軟體的生產率與質量存在緊密關聯關係；一般的，低質量軟體的生產率的生產率肯定不高 | P40 |
| 定律 3.1 適度質量 | 滿足現實需要的軟體質量能有效減免開發投入 | P41 |
| 定律 6.1 Royce模型的低效性 | Royce模式不能有效適應極其複雜而頻變的軟體開發環境，Royce型專案的成功率低於其他常用模型。 | P105 |
| 定律 6.2 原型“病” | 工程師在開發原型的過程中付出的“功“越多，就越不願意主動拋棄或替換它 | P110 |
| 定律 7.1 敏捷方法的高效性 | 相比於Royce模型、普通增量-迭代模型，敏捷方法更適合於（當前）複雜、頻變且苛刻的軟體開發大環境 | P132 |
| 定律 8.2 平臺複用效應 | 領域平臺在複用有限次（如3-4次）之後，就能使得系列產品的平均成本和時間低於單件工程所需的平均成本和時間 | P154 |
| 定律 10.1 Glass需求不足定律 | “需求不足”是導致軟體開發專案失敗、失控或失效的最主要原因 | P182 |
| 定律 10.2 需求的變增性 | 成熟的軟體產品的需求必然會經歷頻繁的變更，且通常會越變越多；專案所需的時間越長，需求增長的幅度就會越大 | P184 |
| 定律 10.3 需求的價值不均性 | 一小部分需求對目標軟體產品所貢獻的價值遠大於其他大部分需求所貢獻的價值 | P186 |
| 定律 10.4 需求的技術鈍性 | “需求難”無法通過技術革新而得到解決 | P187 |
| 定律 13.1 需求獲取不到位 | “需求獲取不到位”是“需求不足”的主因 | P219 |
| 定律 14.1 Pareto需求依賴分佈 | 超90%的需求與其他需求存在依賴關係；約20%的需求涉及約80%依賴關係 | P235 |
| 定律 16.1 使用者優於專家 | 關於需求正確性的判定，使用者反饋遠比所謂的專家分析更權威和可行 | P260 |
| 定律 16.2 Boehm介面原型 | 開發目標軟體產品的介面原型能顯著減少最終產品中的、與使用者介面相關的缺陷 | P265 |
| 定律 17.1 需求蔓延 | 蔓延需求可佔總需求的一半，甚至更多 | P276 |
| 定律 18.1 需求標準不普適 | 在當前需求工程實踐中，尚不存在真正能夠“放之四海而皆準的“需求過程標準 | P286 |
| 定律 18.2 Glass需求缺失 | 在所有需求缺陷中，“需求缺失”的負面影響最大，最難被發現和修復，且修復成本極高 | P290 |
| 定律 18.3 需求缺陷與修復成本 | 超50%的程式碼缺陷源於需求缺憾，其修復工作量可佔總工作量的80%，可耗費20%-40%的軟體開發總成本 | P291 |
| 定律 18.4 需求缺陷與軟體規模 | 待開發軟體的規模越大，需求缺陷的密度就越大，且移除率越低，導致最終交付數顯著增大 | P291 |
| 定律 18.5 需求文件完整性與軟體規模 | 待開發軟體的規模越大，“需求缺失”就越多，需求規約文件的完整性也就越低 | P292 |
| 定律 18.6 Davis使用者反饋 | 使用者對需求認識越深入，其反饋就越具有“指導需求質量改善”的價值 | P295 |
| 定律 18.7 Chaos使用者兩面性 | 於需求工程師而言，使用者既是最佳合作伙伴，又是最可怕的敵人，使用者“是敵是友”取決於他自身的質量 | P296 |
| 定律 21.1 Jones架構重要性 | 待開發軟體的規模越大，複雜度或風險越高，它的架構設計也越重要 | P334 |
| 定律 23.1 介面使用者滿意度 | 軟體介面的使用者滿意度主要受制於它的可用性和美觀程度，而不是它的功能完整性 | P378 |
| 定律 23.2 可用性之感 | 軟體產品及其介面的可用性只有在投入實際應用之後才可能被有效度量。而此時任何改善可用性的行為都已十分昂貴 | P380 |
| 定律 25.1 設計之需求條件 | 獲取“完整的”需求僅是設計師創造高質量設計方案的必要條件，不是充分條件 | P437 |
| 定律 25.2 Constantine模組化 | 高內聚和低耦合的模組結構具有良好的穩定性，即不易因變更而遭破壞 | P443 |
| 定律 25.3 Simon層次化 | 設計良好的層級結構具有相對較低的複雜度（以層級間和模組間互動數為依據） | P445 |
| 定律 25.4 Parnas 模組封裝 | 發生在封裝模組之內的變更所產生的風險遠小於跨模組變更的風險 | P449 |
| 定律 27.1 程式語言與軟體成本 | 軟體程式設計所用的語言數量越多，開發成本就會相應增加，維護成本還會顯著增加 | P490 |
| 定律 29.1 DMW定律 | 相比於非結構化的程式碼，結構化的程式碼具有較少的缺陷，且更適宜於閱讀、理解和維護 | P518 |
| 定律 30.1 程式設計師效率的差異性 | 優秀程式設計師的程式設計效率是一般程式設計師的三倍以上，可達十倍，甚至更高 | P537 |
| 定律 30.2 程式設計效率與任務複雜度 | 程式設計的效率與任務的複雜度成正比 | P538 |
| 定律 30.8 程式設計效率與語言和工具 | 程式設計的效率會因程式語言和工具而表現出顯著差異 | P538 |
| 定律 31.1 Hetzel-Myers技術組合 | 組合使用多種測試和審查技術比單獨使用某一種技術更有效、也更高效 | P550 |
| 定律 32.1 缺陷成本增長 | 缺陷的發現和修復成本隨軟體生命期的推進而呈快速（甚至指數級）增長趨勢 | P570 |
| 定律 32.2 Pareto缺陷分佈 | 約80%的缺陷密集地分佈於約20%的軟體程式碼和模組中 | P572 |
| 定律 32.3 缺陷持久密集 | 程式碼模組的缺陷密集性傾向於在軟體的多個連續版本中都保持不變 | P573 |
| 定律 32.4 Adams缺陷影響力 | 一小部分缺陷對軟體可靠性的影響遠遠超出其他大部分缺陷的影響 | P573 |
| 定律 32.5 故障頻繁再現 | 50%至90%的使用者域軟體系統執行故障都不只出現過一次 | P574 |
| 定律 32.6 單模組型缺陷 | 75%至95%的程式碼缺陷都是單模組型缺陷，即僅存於單個模組，其修復也僅需其所在模組發生必要的變更 | P575 |
| 定律 32.7 進十退一 | 缺陷修復會以約10%的機率引入新的缺陷，另有約10%的缺陷得不到完全修復 | P575 |
| 定律 33.1 Jones測試效能 | 在軟體開發過程中，測試一般能發現約85%的缺陷，能修復約80%的缺陷；任何單個測試方法或階段都很難發現逾35%的缺陷 | P597 |
| 定律 33.2 測試效能與產品規模 | 測試效能隨待測軟體規模的增大而降低，即：待測軟體的規模越大，測試路徑的覆蓋率和缺陷發現率就會越低 | P599 |
| 定律 33.3 Myers不充分測試 | 基於不充分測試的隨機缺陷發現，包含較多已知缺陷的程式碼段更有可能包含較多未知缺陷 | P600 |
| 定律 34.1 Fagan評審 | 軟體評審能有效提高產品的開發效率、質量和專案過程穩定性 | P615 |
| 定律 35.1 質量固型 | 軟體的質量隨開發程序而逐漸穩固，在設計（特別是構造）完成之後就很難以低成本方式實現大幅度改善 | P626 |
| 定律 35.2 質量加速 | 就單個軟體產品或整條產品線而言，質量的改善和惡化都呈現出加速的趨勢 | P627 |
| 定律 38.1 軟體老化時態 | 軟體老化是一類時態現象。從全域性來看，它是不可避免的；但在區域性時段和範圍內，它又是可抵制和可逆轉的 | P653 |
| 定律 38.2 軟體老化常態 | 軟體老化是一類正常的維演現象。它能創造價值，但更能增加成本；它主要與程式碼的可維護性相關，同時影響軟體的功能和使用者滿意度 | P654 |
| 定律 40.1 Lehman持續變增 | 軟體必須不斷地變更，以滿足變化著的現實需求；此時，軟體的規模、功能和複雜度都會隨之逐漸增長 | P683 |
| 定律 40.2 Lehman質量漸降 | 軟體的質量會隨著程式碼的不斷更新而呈現出整體逐漸降低的趨勢 | P684 |
| 定律 40.3 Boehm變更 | 在軟體維演階段，程式碼變更的規模越大，它的一次通過率就越低 | P685 |
五、軟體工程法則集合
| 法則 3.1 質量第一 | 依據現實需求和產品目標，定義並實現軟體質量 | P61 |
|---|---|---|
| 法則 6.1 向下資訊傳遞，DIT | 上游資訊表現體所包含的資訊必須是完全傳遞至下游資訊表現體 | P100 |
| 法則 6.2 向上資訊恢復，UIR | 上游資訊表現體所包含的資訊必須能從下游資訊表現體中完全恢復（或析出） | P100 |
| 法則 6.3 快速原型開發 | 依據專案需要，及早而快速地開發出原型 | P108 |
| 法則 8.1 構件組裝開發 | 首先定義模組化的架構；然後購買、複用和剪裁成品構件，或定製新構件；最終基於架構組裝構件以得到目標軟體 | P146 |
| 法則 8.2 構件複用優先 | 優先複用本組織的已有構件，其次是購買商業成品構件（COTS）；只在當無法複用或購買構件之時才選擇自行開發 | P147 |
| 法則 8.3 構件組裝優先 | 如果構件組裝的條件能獲滿足，那就應當依據構件組裝模式開發軟體，而不應該選擇從“零”開始 | P148 |
| 法則 8.4 構件可複用 | 在構件組裝開發模式中，確保架構所定義的構件和所購買或定製的構件都是可替換的、可擴充套件和可組合的 | P149 |
| 法則 10.1 需求內涵 | 軟體的需求主要描述它“該做什麼”，同時不要忌諱描述它“該怎麼做”（以必要、正確和適度為準則） | P177 |
| 法則 12.1 關注點分離 | 基於待開發軟體產品的目標（常見於願景宣告），定義待解問題的若干關注點 | P211 |
| 法則 15.1 編寫高質量需求項 | 儘可能保證需求規約文件中的每項需求都是可行的、有效的、完整的、無二義的、可驗證的、一致的和可追蹤的 | P250 |
| 法則 16.1 使用者確認需求 | 由使用者主導需求確認決策，工程師輔之 | P261 |
| 法則 18.1 保障話語權 | 需求實踐必須保障所有權益人的話語權。既要尊重權益人代表的話語“特權”（代表主流民意）也要直通“底層民意”（尤其是非主流民意），杜絕出現阻斷底層“民意”的權益人“超級”代表 | P293 |
| 法則 21.1 基於架構開發 | 以架構為中心，通過構件複用和組裝，快速地開發出低成本高質量的軟體產品 | P339 |
| 法則 22.1 單一職責 | 保證每個類都有且只有一項“職責”。 | P364 |
| 法則 22.2 開閉 | 保證每個類都是可擴充套件的，而不是可修改的。 | P365 |
| 法則 22.3 Liskov替換 | 保證每個子類都能替換它的夫類 | P336 |
| 法則 22.4 介面隔離 | 依據使用者所需的服務，定義類的介面，保證使用者僅依賴於它們所需要的介面服務 | P367 |
| 法則 22.5 依賴倒置 | 高層模組不應該依賴於底層模組，兩者都應依賴於抽象；細節也應該依賴於抽象（而非反之） | P368 |
| 法則 23.1 一目瞭然的介面 | 軟體介面應當一目瞭然，或能自解釋 | P383 |
| 法則 23.2 不經思考的點選 | 軟體介面上的“點選”操作應當不需要使用者的過多事前思考 | P384 |
| 法則 23.3精簡文字的介面 | 軟體介面應當依據使用者所需，刪減不必要的文字或圖形資訊 | P384 |
| 法則 23.4 以使用者為中心的介面設計 | 軟體介面設計應支援使用者以舒適的方式、高效地完成既定功能。 | P387 |
| 法則 23.5 介面一致 | 保持介面內各元素之間、同一軟體的不同介面之間、不同軟體的介面之間的一致性 | P395 |
| 法則 23.6 個性化介面 | 軟體介面設計應在遵循相關領域標準、行業規則和常識的同時，充分挖掘介面的個性美 | P397 |
| 法則 24.1 保證資料獨立性 | 保證資料庫的物理獨立性和邏輯獨立性 | P421 |
| 法則 24.2 控制資料冗餘度 | 控制資料庫的資料冗餘度，慎重處理冗餘資料的“增查改刪” | P421 |
| 法則 24.3 最少使用者資料收集 | 僅收集必要的使用者資料，且資料收集和釋出過程都必須遵守政府規定、行業條文、社會道德和法律等相關約束 | P422 |
| 法則 25.1 溯源設計 | 深究源問題以獲得更真實和完整的設計認知，不要單憑需求文件草率完成設計 | P438 |
| 法則 25.2 簡單設計 | 在保證設計方案適合於目標軟體及其開發專案的前提之下，儘可能地簡化，使之足夠簡單且直接 | P439 |
| 法則 25.3 模組化設計 | 對於由若干功能模組組裝而成的軟體，保證每個模組都是高內聚的而模組之間又是低耦合的。 | P441 |
| 法則 25.4 層次化設計 | 設計清晰的軟體層級結構，位於上層的功能模組通過下層多個（子）模組的鬆散耦合而實現 | P445 |
| 法則 25.5 抽象化設計 | 軟體設計應聚焦於並突出描述軟體開發所必需的重要資訊，而不是其他次要或無關資訊。 | P447 |
| 法則 25.6 資訊隱藏 | 軟體設計應封裝模組的實現細節，僅以“介面”的形式實現模組間“通訊” | P448 |
| 法則 25.7 最小規劃設計 | 在設計階段準確制訂核心設計決策，然後在後續開發中而逐步制訂外圍設計決策，最終完成產品設計方案 | P451 |
| 法則 25.8 適度設計 | 軟體設計應以“滿足軟體實現之需求”為適度，設計方案既不應過分具體以至“李代桃僵”（即設計師代行程式設計師之職），也不應過分抽象以至“形同虛設”（即方案不具“指導程式設計”之能） | P452 |
| 法則 25.9 確保概念完整性 | 設計應確保概念內容完整且形式一致 | P452 |
| 法則 25.10 複用優先的射界 | 軟體設計應優先採用“整體複用”模式，其次是“部分複用”，最後才是“零複用”（即“純定製”） | P453 |
| 法則 25.11 面向變更的設計 | 軟體設計應面向未來變更，從結構上確保軟體產品可持續地易於變更 | P456 |
| 法則 25.12 多維設計 | 設計是多維度的，應當從多個、互用互補的視角描述同一個設計方案 | P458 |
| 法則 25.13 不重複自己的設計 | 所設計的每一項軟體功能都應是唯一的，即各功能模組不應具有相同的軟體功能或特徵 | P458 |
| 法則 25.14 自頂向下設計 | 從架構設計開始，逐步細化、修正和確認設計方案，直至每個構件的設計都足夠細緻和清晰 | P459 |
| 法則 27.1 程式語言選擇 | 依據產品、專案和團隊特徵，選擇合適的程式語言；儘可能地減少客戶對程式語言的選擇的“無理”干預 | P489 |
| 法則 27.2 儘早還債 | 依據現實需要，儘早償還技術債 | P492 |
| 法則 29.1 程式碼結構化 | 按照合理而統一的規則，將程式碼結構化 | P517 |
| 法則 29.2 不重複自己變成 | 不要重複編寫相同的程式碼 | P519 |
| 法則 30.1 蓄意程式設計 | 程式設計師應堅持學習程式設計知識，並在程式設計實踐中自覺培養和提升程式設計技能，以實現自我超越 | P535 |
| 法則 31.1 面向使用者的質量評估 | 軟體質量的評估應面向使用者，以使用者的評估結論為主，以獨立第三方的結論為輔 | P548 |
| 法則 31.2 雙管齊下保質量 | 在軟體開發初期就開始實施質量保證並規劃質量控制，既要防止缺陷的出現，也要及時發現和移出潛存缺陷 | P552 |
| 法則 33.1 重點測試 | 集中主要測試資源（包括測試人力、成本和時間）於缺陷密集型程式碼模組 | P602 |
| 法則 33.2 優先測試 | 優先測試軟體內實現核心功能的、或具有極大變更風險的程式碼模組 | P602 |
| 法則 33.3 Weinberg測試 | 程式設計師應避免測試由自己編寫的程式 | P603 |
| 法則 33.4 Weinberg擴充套件測試 | 程式設計師團隊應避免測試由本團隊編寫的程式 | P603 |
| 法則 35.1 質量瀑布 | 首次開發力爭獲得高質量，儘可能地規避專案返工和二次開發 | P628 |
六、軟體工程最佳實踐集合
| 最佳實踐 6.1 篩選原型需求 | 依據專案目標，篩選軟體原型的需求。 | P109 |
|---|---|---|
| 敏捷建模法 | 十三項建模法則，十八項最佳實踐 | P168 |
| 最佳實踐 12.1 | SMART目標定義 採用SMART標準定義軟體產品的目標，即保證目標是具體的、可度量的、可達的、問題相關的和及時的 | P208 |
| 最佳實踐 12.2 願景宣告撰寫 | 精簡願景宣告的內容（僅描述主要技術目標），保證其能有效置於半頁A4紙張空間之內 | P209 |
| 最佳實踐 12.3 確認願景宣告 | 由客戶（代表）和工程方高層就願景宣告簽字，以表示他們正式同意了願景宣告所給定的產品技術目標。 | P210 |
| 最佳實踐 13.1 多法並用獲取需求 | 基於專案、產品、過程和權益人（尤其是關鍵權益人）的相關特徵，搭配使用多種需求獲取方法 | P216 |
| 最佳實踐 13.2 基於用例獲取需求 | 基於用例，獲取和求精軟體需求，尤其是關鍵功能需求 | P222 |
| 最佳實踐 13.3 客戶高管參加 | 邀請至少一名客戶方的高層管理者參與主要的需求獲取行動 | P222 |
| 最佳實踐 13.4 攀附“貴人” | 找尋能夠幫助獲取或細化需求的權益人，並與他們保持良好的需求協作關係。 | P223 |
| 最佳實踐 13.5 幫助使用者認清需要 | 需求工程師應幫助使用者認清現實問題及自身需要，特別是核心需要 | P224 |
| 最佳實踐 13.6 控制會議規模 | 控制需求獲取工作會議的規模，與會人數一般不超過6至8人，開會時長也不宜超過兩小時 | P224 |
| 最佳實踐 13.7 定義軟體環境 | 在需求獲取環節，定義目標軟體的應用環境和技術環境 | P225 |
| 最佳實踐 13.8 記錄“源”資訊 | 為每項需求收集並記錄它的源資訊，尤其是它的獲取來源和理由 | P225 |
| 最佳實踐 14.1 合理需求分簇 | 選擇合理的分簇依據，完成需求分簇 | P233 |
| 最佳實踐 14.2 基於依賴關係的變更影響分析 | 基於需求間依賴關係，分析需求變更對需求、設計、程式碼、測例等製品的潛在影響 | P236 |
| 最佳實踐 14.3 多依據分級 | 首先選取多個依據並分別定義需求集的優先順序佇列，然後通過綜合與權衡，形成最終的需求優先順序序列。 | P241 |
| 最佳實踐 15.1 輔以自然語言的形式化描述 | 在必須使用正式模型或形式化語言描述某些需求之前，先嚐試採用自然語言進行完整描述 | P249 |
| 最佳實踐 15.2 需求模板定製 | 根據專案上下文，基於組織行業或國際標準模板 | P252 |
| 最佳實踐 15.3 建立需求術語表 | 為需求規約文件建立術語表，並以此實現術語在整個文件中的一致化使用 | P255 |
| 最佳實踐 16.1 需求會議評審 | 控制需求評審會議的規模、限制待審需求量、向所有與會者提供相同的需求資訊、尊重各方權益人的評審結果 | P263 |
| 最佳實踐 16.2 需求優於審查 | 優先審查具有以下某些特徵的需求：高價值、高抽象級、高優先順序、高風險、強影響力、與使用者相關 | P263 |
| 最佳實踐 16.3 基於清單審查需求 | 基於一份記錄著常見需求缺陷的清單，快速排查需求規約文件 | P264 |
| 最佳實踐 16.4 基於原型確認介面需求 | 快速開發目標軟體產品的使用者介面原型，並基於此完成使用者介面需求確認 | P266 |
| 最佳實踐 16.5 簽訂需求承諾書 | 在需求確認完成之後，客戶方和工程方共同簽訂需求承諾書，以正式啟動需求實現過程 | P266 |
| 最佳實踐 17.1 定義需求追溯鏈 | 從需求獲取至需求實現的整個過程中，建立並維護有效的需求追溯鏈（特別是“從需求回溯”和“從需求追蹤”） | P275 |
| 最佳實踐 17.2 保守的需求基線定義 | 軟體版本的需求基線不宜超過可在50%至90%計劃時間內實現的最大需求量 | P277 |
| 最佳實踐 17.3 市場部主導需求遴選 | 組織關鍵權益人特別是代表客戶權益的市場部人員主導目標軟體產品或版本的需求遴選活動。 | P278 |
| 最佳實踐 17.4 基於時限遴選需求 | 依據版本開發迭代的嚴格時限，遴選出屬於當次迭代的基線需求（應用砍半法） | P279 |
| 最佳實踐 17.5 看兩步走一步 | 為多個連續版本指定需求計劃大略，至少要為當前版本及其下一版本遴選出基線需求 | P281 |
| 最佳實踐 17.6 蔓延需求統一分配 | 組建“需求變更控制委員會”，統一分配蔓延需求至各軟體版本或其開發迭代過程中 | P281 |
| 最佳實踐 18.1 標準需求過程“本地化” | 針對具體軟體開發專案，適當“裁剪”某標準需求過程，以切合專案的實際需要 | P287 |
| 最佳實踐 18.2 使用者分組 | 將使用者群體細分為若干子群體，在每個子群體內選定若干”高質量“使用者代表，然後與他們進行充分交流 | P297 |
| 最佳實踐18.3 協商需求衝突 | 需求工程師應與客戶和使用者一起協商解決需求衝突，保證各方的核心權益都能獲得滿足 | P298 |
| 最佳實踐 19.1 精簡需求團隊 | 軟體開發專案的需求工程團隊規模一般不超過6至8人，以經驗豐富，熟悉應用領域的需求工程師為主體 | P307 |
| 最佳實踐 19.2 聰明的無知人 | 需求團隊應包含一個或限量個不熟悉應用領域的“聰明的無知人” | P308 |
| 最佳實踐 21.1 全息架構設計 | 針對大型軟體產品的架構設計，應當定義完整的Kruchten4+1架構模型 | P343 |
| 最佳實踐 22.1 保持介面的健壯性 | 構建介面的設計應使之能夠易於正確使用而難於錯誤使用 | P370 |
| 最佳實踐 23.1 多屬性度量介面可用性 | 採用合適方法分別度量介面的可用性屬性；綜合多個屬性的度量結果，得出介面可用性整體評估結論 | P382 |
| 最佳實踐 23.2 介面支援使用者控制 | 軟體介面設計應儘可能地支援使用者高效地控制介面的所有功能和操作流程 | P387 |
| 最佳實踐 23.3 人性化的介面設計 | 軟體介面設計應符合大部分使用者的認知特性，思維和動作習慣，同時也可針對特殊使用者群設計特定介面 | P388 |
| 最佳實踐 23.4 介面鼓勵和幫助使用者 | 軟體介面設計應能鼓勵使用者使用介面的各種操作，併為使用者提供實時幫助資訊 | P389 |
| 最佳實踐 23.5 簡單而令人愉悅的介面 | 控制介面組成元素的數量，降低元素認知難度，並優化介面整體佈局，使之具有審美愉悅感 | P391 |
| 最佳實踐 23.6 最短互動 | 軟體介面設計應簡化人機互動過程，減少互動次數，以最直接的方式實現互動的既定目標 | P392 |
| 最佳實踐 23.7 有效互動 | 保證每個人機互動步驟都是有效的，即互動的人機雙方都能有效地互相傳達和接收資訊 | P394 |
| 最佳實踐 23.8 介面元素一致 | 軟體介面內各元素之間應保持一致，體現為各元素所採用的概念和行為方式的一致性 | P395 |
| 最佳實踐 23.9 介面風格一致 | 保證單個介面的及多個介面之間的風格一致性，涉及介面佈局、元素形狀和顏色、字型及大小等。 | P396 |
| 最佳實踐 23.10 介面互動一致 | 軟體介面應與使用者保持互動過程的一致性，體現為互動過程中使用者認知和操作方式的一致性 | P396 |
| 最佳實踐 23.11 共通介面設計 | 保證使用者的已有介面操控知識和技能都能有效地複用至當前介面的操作過程中 | P397 |
| 最佳實踐 24.1 先約束後資料 | 在給資料表加入實際資料之前，先定義好與該表相關的完整性約束 | P417 |
| 最佳實踐 24.2 應用層資料准入 | 依據資料庫的既定約束，在應用層實現一致的資料准入機制，保證所有能成功錄入的資料都能成功存入資料庫 | P417 |
| 最佳實踐 25.1 縮控架構範圍 | 縮控架構的功能範圍，摒棄所有缺乏“真實”需求依據的架構組成元素及相關功能 | P440 |
| 最佳實踐 25.2 高內聚低耦合設計 | 模組設計力爭實現通訊內聚或更高級別的內聚方式，而模組間耦合應儘可能地使用資訊或資料耦合，少用控制耦合，堅決避免內容耦合 | P443 |
| 最佳實踐 25.3 架構層次設計 | 定義合理的架構層級：小型架構以三層為宜，大型架構以三到五層為宜，不宜超過七層 | P446 |
| 最佳實踐 52.4 面向複用的設計 | 在保證設計方案可用於當前產品、團隊和專案的前提下，提升各層各類設計元素的可複用性 | P454 |
| 最佳實踐 25.5 預測需求變更 | 在軟體設計過程中應充分預測未來需求變更，並將之落實到具體設計方案中· | P457 |
| 最佳實踐 26.1 向建築師學習 | 架構師應向建築師學習，不僅要稱為技術“達人”，而且要成為優秀的管理者，權益協調人和使用者學家 | P471 |
| 最佳實踐 26.2 美工稽核介面 | 由資深軟體設計師擔綱完成使用者介面設計，並由專業美工稽核介面 | P473 |
| 最佳實踐 26.3 合力設計資料庫 | 由資深軟體設計師擔綱，輔以資料庫管理員的建議和意見，合力完成資料庫設計 | P474 |
| 最佳實踐 26.4 多樣的設計師團隊 | 組成團隊的設計室成員應具有多樣性，典型地體現為多樣的教育背景、領域和實踐經歷 | P475 |
| 最佳實踐 26.5 培養新人的設計團隊 | 在設計師團隊中加入新晉設計師，並由資深設計師以“師授徒”的傳統形式培養新人 | P476 |
| 最佳實踐 27.1 程式碼及早重構 | 如本輪程式設計不得已欠下了技術債，就應在本輪結束之後立即採用程式碼重構技術予以償還 | P494 |
| 最佳實踐 28.1 編寫可調式的程式碼 | 編寫易讀易排查的程式碼，新增必要的除錯用程式碼（主要用於輸出或列印相關除錯資訊） | P504 |
| 最佳實踐 28.2 剖析記憶體 | 剖析併力求縮小程式的實際記憶體佔有量 | P505 |
| 最佳實踐 28.3 靜態程式碼排查 | 用靜態分析工具排除程式碼的潛在缺陷 | P506 |
| 最佳實踐 28.4 黃燈即紅燈 | 重視編譯器給出的“警告”，並將之視為“錯誤”，並及時排除指 | P507 |
| 最佳實踐 28.5 使用多編譯器進行編譯 | 使用多個編譯器分別編譯程式碼，確保編譯結果一致 | P507 |
| 最佳實踐 29.1 重寫程式碼 | 多次重寫程式碼，力求足夠簡潔 | P513 |
| 最佳實踐 29.2 寫少碼 | 在保證程式碼功能和質量（特別是可讀性和可理解性）的前提下，儘可能的少寫程式碼 | P514 |
| 最佳實踐 29.3 童子軍軍規 | 在每一次向程式碼庫檢入程式碼之前，確保它的質量高於它上次從程式碼庫檢出之時 | P516 |
| 最佳實踐 29.4 慎用Goto語句 | 慎重使用GOTO語句，控制使用次數，規避GOTO巢狀 | P518 |
| 最佳實踐 29.5 字面程式設計 | 用有實際意義的字詞作為程式元素（如變數和函式）的名稱，並準確表達它們的實際含義 | P521 |
| 最佳實踐 29.6 慎重程式設計 | 以維護程式碼的慎重態度編寫程式 | P522 |
| 最佳實踐 29.7 結對程式設計 | 兩個程式設計師組隊，一起程式設計 | P522 |
| 最佳實踐 29.8 標準化程式設計 | 遵守組織和團隊的既定程式設計標準，並使用合適工具實現程式碼庫的自動標準化 | P523 |
| 最佳實踐 29.9 程式碼審查 | 所有程式碼，特別是核心程式碼，都要接受創作者特別是非創作者的審查 | P524 |
| 最佳實踐 30.1 蓄意程式碼品讀 | 程式設計師應蓄意地頻繁品讀自己和他人編寫的程式碼，從中學習和提升程式設計技能 | P535 |
| 最佳實踐 30.2 蓄意參與設計 | 程式設計師應積極地參與軟體設計，既幫助設計師改進設計質量，又學習如何設計 | P536 |
| 最佳實踐 33.1 白盒單元測試 | 單元測試應當以白盒策略為主，以灰盒策略為輔，一般無需使用黑盒策略 | P593 |
| 最佳實踐 33.2 灰盒整合測試 | 整合測試應當以灰盒策略為主，輔以白盒和黑盒策略 | P594 |
| 最佳實踐 33.3 黑盒系統測試 | 系統測試應當以黑盒策略為主，以灰盒策略為輔，一般不使用白盒策略 | P595 |
| 最佳實踐 33.4 獨立Beta測試 | 軟體開發方委託專業而獨立的測試機構，組織軟體使用者群體（或其代表）實施Beta測試。 | P596 |
| 最佳實踐 33.5 極限測試 | 在程式設計之前寫編寫測例 | P604 |
| 最佳實踐 33.6 迴歸測試 | 在每次程式碼變更之後，都要進行迴歸測試 | P605 |
| 最佳實踐 33.7 測試報告編寫 | 測試報告要準確、全面而清晰地描述缺陷本身及其表徵，不要包含任何批評工程師的文字（即“對事不對人”） | P605 |
| 最佳實踐 33.8 報告微缺陷 | 測試員應報告微缺陷，避免因積小成大而影響軟體的質量和使用者滿意度 | P606 |
| 最佳實踐 33.9 善用自覺、控制偏見 | 測試員應利用自覺以找到測試突破口，同時應控制自覺和偏見對測試的負面影響 | P607 |
| 最佳實踐 34.1 基於清單的審查 | 在軟體審查過程中參考使用“常見缺陷清單”，以幫助找出常見缺陷 | P620 |
| 最佳實踐 34.2 自審結合他查 | 程式設計師不僅應自行審查所編寫的程式碼，而且應邀請同行審查自己的程式碼 | P621 |
| 最佳實踐 34.3 可維護性審查 | 從可維護性的角度審查程式碼，以改善程式碼的整體可維護性 | P621 |
| 最佳實踐 34.4 回審 | 在交付軟體之後，繼續審查軟體質量 | P622 |
| 最佳實踐 39.1 擇時再工程 | 選準再工程的時機 | P676 |
| 最佳實踐 39.2 雙驅動重構 | 以程式碼和測試聯合驅動的方式，規劃和部署高質量的程式碼重構 | P677 |
| 最佳實踐 39.3 果斷重寫程式碼 | 如果程式碼模組需要修改超過25%的原有程式碼，則應該果斷重寫整個程式碼模組 | P678 |
| 最佳實踐 40.1 定期剪枝 | 為軟體定期剪枝，消除無用的功能和死碼 | P686 |
| 最佳實踐 41.1 維護員參與軟體開發 | 維護工程師應及早參與軟體的開發工作，為後續維演工作打下良好基礎 | P693 |
七、軟體工程英文知識點索引
| Redwine-Riddle技術成熟論 | 導讀 | P2 | |
|---|---|---|---|
| Gartner技術成熟度曲線 | 導讀 | P3 | |
| Brooks難度論 | 第一篇 | 軟體複雜度 | P15 |
| DeRemer定律 | 第一篇 | 規模挑戰 | P38 |
| Brooks銀彈定律 | 第一篇 | 生產率和質量 | P39 |
| Mills生產率定律 | 第一篇 | 生產率和質量 | P40 |
| Royce模型（瀑布） | 第二篇 | 開發模型 | P103 |
| AOSD模型 | 第二篇 | 開發模型 | P110 |
| 瑞理統一過程RUP模型 | 第二篇 | 開發模型 | P122 |
| Mcllroy複用定律 | 第二篇 | 軟體複用 | P141 |
| CBSD模型框架 | 第二篇 | 軟體模型框架 | P143 |
| FURPS分類法 | 第三篇 | 需求分類 | P179 |
| Kano分類法 | 第三篇 | 需求分類 | P180 |
| Xerox六步曲 | 第三篇 | 需求前奏問 |