1. 演化成本控制原则

• Evolution Cost Control （ECC）原则
• 解释：
  • 演化成本要控制在预期的范围之内
  • 即，演化成本要明显小于重新开发成本
• 用途：
  • 判断架构演化的成本是否在可控范围内
  • 用户是否可接受
• 度量方案： CoE << CoRD

说明：

• CoE：演化成本
• CoRD：为重新开发成本

2. 进度可控原则

• Schedule Control 原则
• 解释：
  • 架构演化要在预期时间内完成
  • 即，时间成本可控
• 用途：
  • 根据该原则规划每个演化过程的任务量
  • 体现一种迭代、递增的演化思想
• 度量方案： ttask=|Ttask-T’task|] （对照书上确认公式）

  说明：

  • Ttask：某个演化任务的实际完成时间
  • T’task：预期完成时间
  • ttask：二者时间差（该值越小越好）

3. 风险可控原则

• Risk Control 原则
• 解释：架构演化过程中的经济风险、时间风险、人力风险、技术风险、环境风险等必须在可控范围内。
• 用途：于判断架构演化过程中各种风险是否易于控制
• 度量方案：分别检验

说明：时间风险、经济风险、人力风险、技术风险应不存在

4. 主体维持原则

• 解释：软件系统的演化过程中，应尽量保持软件主体结构和核心功能的稳定性和连贯性。

教材原文的解释：对称稳定增长 (the Average Incremental Growth,AIG) 原则所有其他因素必须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，从而达到令人满意的演化。因此，软件演化的平均增量的增长须保持平稳，保证软件系统主体行为稳定。

• 用途：判断架构演化是否导致系统主体行为不稳定
• 度量方案：AIG=主体规模的变更量/主体的规模

说明：根据度量动态变更信息(类型、总量、范围)来计算

5. 系统总体结构优化原则

• Optimization of Whole Structure 原则
• 解释：架构演化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理
• 途：判断系统整体结构是否合理，是否最优。
• 度量方案：检查系统的整体可靠性和性能指标

6. 平滑演化原则

• Invariant Work Rate（IWR）原则

• 解释：在软件系统的生命周期里，软件的演化速率趋于稳定

  如，相邻版本的更新率相对固定

• 用途：用于判断是否存在剧烈架构演化

• 度量方案：IWR=变更总量/项目规模

说明：根据度量动态变更信息(类型、总量、范围等)来计算

7. 目标一致原则

• Objective Conformance 原则
• 解释：架构演化的阶段目标和最终目标要一致
• 用途：
  • 判断每个演化过程是否达到阶段目标
  • 所有演化过程结束是否能达到最终目标
• 度量方案： otask=|Otask-O’task|

说明：

• Otask：阶段目标的实际达成情况
• O’task：预期目标
• Otask：二者的差（越小越好）

8. 模块独立演化原则

• 或称为修改局部化原则 (Local Change)
• 解释：软件中各模块自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小
• 用途：判断每个模块自身的演化是否相互独立
• 度量方案：检查模块的修改是否是局部的

说明：可以通过计算修改的影响范围来进行度量。

9. 影响可控原则

• Impact Limitation 原则
• 解释：软件中一个模块如果发生变更，其给其他模块带来的影响要在可控范围内，也就是影响范围可预测
• 用途：用于判断是否存在对某个模块的修改导致大量其他修改的情况
• 度量方案：检查影响的范围是否可控

10. 复杂性可控原则

• Complexity Controllability 原则
• 解释：架构演化必须保障软件的复杂性在可控范围内
• 用途：用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等
• 度量方案： CC < 某个阈值

11. 有利于重构原则

• Useful for Refactoring 原则
• 解释：架构演化要遵循有利于重构原则，使得演化之后的软件架构更便于重构。
• 原则用途：用于判断架构易重构性是否得到提高
• 度量方案：检查系统的复杂度指标

说明：系统越复杂越不容易重构

12. 有利于重用原则

• Useful for Reuse 原则
• 解释：架构演化最好能维持甚至提高整体架构的可重用性
• 用途：判断整体架构可重用性是否遭到破坏
• 度量方案：检查模块自身的内聚度、模块之间的耦合度

说明：模块的内聚度越高，该模块与其他模块之间的耦合度越低，越容易重用

13. 设计原则遵从性原则

• Design Principles Conformance 原则
• 解释：架构演化最好不能与架构设计原则冲突。
• 用途：判断架构设计原则是否遭到破坏
• 度量方案： RCP=ICDP//DP| （对照书上确认公式）

说明：

• CDP：冲突的设计原则集合
• DP：总的设计原则集合
• RCP越小越好

14. 适应新技术原则

• Technology Independence 原则
• 解释：软件要独立于特定的技术手段，这样才能够让软件运行于不同平台
• 用途：判断架构演化是否存在对某种技术依赖过强的情况
• 度量方案： TI=1-DDT

说明：

• DDT：依赖的技术集合用到的技术合集
• 根据演化系统对关键技术的依赖程度进行度量

15. 环境适应性原则

• Platform Adaptability 原则
• 解释：架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境
• 用途：用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置
• 度量方案：硬件/软件兼容性

16. 标准依从性原则

• Standard Conformance 原则
• 解释：架构演化不会违背相关质量标准

如：国际标准、国家标准、行业标准、企业标准等

• 原则用途：用于判断架构演化是否具有规范性，是否有章可循
• 度量方案：需要人工判定

17. 质量向好原则

• Quality Improvement 原则
• 解释：通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意
• 用途：用于判断架构演化是否导致某些质量指标变得很差
• 度量方案：（对照书上确认公式）

说明：演化之后的质量 (EQI) 比原来的质量 (SQ) 要好。

18. 适应新需求原则

• New Requirement Adaptability 原则
• 解释：
  • 架构演化要很容易适应新的需求变更
  • 架构演化不能降低原有架构适应新需求的能力
  • 架构演化最好可以提高适应新需求的能力
• 用途：用于判断演化之后的架构是否降低了架构适应新需求的能力
• 度量方案： RNR=|ANR//NR|

说明：

• ANR：适应的新需求集合
• NR：实际新需求集合
• RNR：以上二者比较的比较， 越小越好

---