为什么需要仿真装置？
- 使用场景: 目标机器是新产品时, 需要目标机器的逻辑仿真装置, 在生产出新机器之前就有辅助调试平台;
- 新机器出现后仍需要: 仿真装置继续提供可靠的调试平台;
- 关键区分: 可靠并不等于精确--仿真机器在某些方面无法精确达到新机器的实现, 但它的实现是稳定的, 而新硬件不是;
- 问题所在: 实验室研制和试制的模型产品与早期硬件不会像定义的那样运行, 不会稳定工作, 甚至每天都不一样; 缺陷发现时所有机器拷贝（包括软件编程小组使用的）都会发生修改;
- 更糟的情况: 硬件失败通常是间歇性的, 不确定性是所有情况中最糟糕的, 因为它剥夺了开发人员查找 bug 的动力--可能根本就没有问题;
- 结论: 一套运行在稳定平台上的可靠仿真装置, 提供了远大于期望的功用;
- 配套: 编译器和汇编软件应运行在可靠的辅助平台上为目标机器编译目标代码, 然后可在仿真器上立刻开始调试;
程序库分成哪些子库？
- 载体实例: OS/360 中由 W. R. Crowley 带领开发, 连接两台 7010 机器共享一个很大的磁盘数据库, 同时提供 System/360 汇编程序;
- 内容: 所有经过测试或正在测试的代码, 包括源代码和汇编装载模块;
- 子库划分:
- 开发库（playpen）: 每个组或编程人员分配区域, 存放程序拷贝、测试用例和单元测试辅助例程和数据; 无限制规定, 开发人员是拥有者;
- 系统集成子库: 开发人员准备把软件单元集成到更大部分时, 向集成经理提交拷贝; 原作者不可以再改变代码, 除非得到集成经理批准;
- 当前版本子库: 某个被广泛应用的系统版本被提升到此; 拷贝不可更改, 除非有重大缺陷; 可用于所有新模块的集成和测试;
- 跟踪机制: 程序目录对每个模块的每个版本进行跟踪, 包括状态、用途和变更;
程序库管理的两个重要理念是什么？
- 理念一（受控）: 程序的拷贝属于经理, 他可以独立地授权程序的变更;
- 理念二（正式分离）: 使发布的进展变得正式, 以及开发库与集成、发布的正式分离;
- 集成经理的职责: 系统合并在一起时开始进行所有系统测试工作, 识别和修补 bug;
- 作者评价: 这是 OS/360 工作中最优秀的成果之一, 实际上是管理技术的一部分;
- 独立性: 很多大型项目（Bell 试验室、ICL、剑桥大学等）都独立地发展了这些技术;
- 推广: 同样适用于文档, 是一种不可缺少的技术;
受控拷贝和变更控制如何配合？
- 需要的三种拷贝: 供构件单元测试的最终锁定版本、用于缺陷修复的测试版本拷贝、供其他人开发的安全版本;
- 与集成子库的关系: 集成子库对应"测试版本"和"锁定版本"的正式化, 安全版本对应开发库;
- 与阶段化变更的关系: 直到下一次定期发布前使用快速补丁, 发布时把通过测试并文档化的修补整合到系统平台（见 060-测试与集成）;