软件体系结构复习指南

前言

作为一个热心学长（好的其实是要凑这个月的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六步曲	第三篇	需求前奏问题定义	P202
SMART实践	第三篇	愿景定义	P208
Pareto需求依赖分布	第三篇	需求分析	P235
AHP	第三篇	需求分级方法	P239
Boehm原型定律	第三篇	需求确认	P265
Davis用户反馈定律	第三篇	参与者与需求过程	P294
Chaos用户两面性定律	第三篇	参与者与需求过程	P296
Jones架构定律	第四篇	架构设计	P334
Kruchten架构模型	第四篇	架构模型	P341
RW十大交叉视角	第四篇	架构模型	P342
Zachman通用框架	第四篇	架构模型	P343
Krucheten架构模板	第四篇	架构模板	P344
Liskov替换法则	第四篇	OO设计法则	P366
Kurg可用性三法则	第四篇	用户界面设计	P383
SBN双峰螺旋模型	第四篇	软件设计与需求工程	P435
Constantine模块化定律	第四篇	模块化设计	P443
Simon层次化定律	第四篇	层次化设计	P445
Parnas模块封装定律	第四篇	信息隐藏	P449
DMW	第五篇	编程法则	P518
Dijkstra之Goto有害论	第五篇	编程法则	P518
Davis编程法则	第五篇	编程法则	P519
Martin编程实践	第五篇	编程实践	P525
Hetzel-Myers组合定律	第六篇	质量控制	P550
Pareto缺陷分布定律	第六篇	缺陷七定律	P572
FIRST规则	第六篇	单元测试	P592
Jones测试效能定律	第六篇	测试效能	P597
Myers不充分测试定律	第六篇	测试核心知识	P600
Fagan评审定律	第六篇	软件评审	P615
Gilb质量五法则	第六篇	质量控制	P628
Boehm变更定律	第七篇	维演核心知识	P685