规模控制

• 指定总体规模的预算

• 指明模块有多大的同时，确切定义模块的功能

• 培养开发人员从系统整体出发、面向用户的态度

空间技能

• 用功能交换尺寸。设计人员必须决定用户可选项目的粗细程度

• “空间——时间”的折中

• 编程需要技术积累

数据的表现形式是编程的根本

计算机产品的文档

• 目标：定义待满足的目标和需要,定义迫切需要的资源、约束和优先级。

• 技术说明:计算机手册加性能规格说明。它是在计划新产品时第一个产生,并且最后完成的文档。

• 进度

• 预算:预算不仅仅是约束。对管理人员来说,它还是最有用的文档之一。预算的存在会迫使其制定技术决策,否则,技术决策很容易被忽略。更重要的是,它促使和澄清了策略上的一些决定

报价、预测、价格：这三个因素互相牵制，决定了项目的成败

软件项目的文档

• 内容：目标

• 内容：产品技术说明

• 时间：进度

• 资金：预算

• 地点：工作空间分配

• 人员：组织图

为什么要有正式的文档

• 只有记录下来，分歧才会明朗，矛盾才会突出

• 文档能够作为同其他人的沟通渠道

• 项目经理的文档可以作为数据基础和检查列表

不变只是愿望，变化才是永恒——斯威夫特

普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的方法。不管怎么样，重要的是先去尝试——富兰克林·罗斯福

• 试验性工厂和增大规模

• 唯一不变的就是变化本身

• 为变更设计系统

• 为变更计划组织架构

程序维护中的一个基本问题是——缺陷修复总会以固定（20%~50%）的几率引入新的bug。所以，整个过程是前进两步，后退一步

前进一步，后退一步

Lehman和Blay研究了大型操作系统的一系列发布版本的历史。他们发现模块总数量随版本号的增加呈线性增长,但是受到影响的模块数量随版本号的增加呈指数增长。所有修改都倾向于破坏系统的架构,增加了系统的混乱程度(熵)。用在修复原有设计上瑕疵的工作量越来越少,而早期维护活动本身所引起的漏洞的修复工作越来越多。随着时间的推移,系统变得越来越无序,修复工作迟早会失去根基。每一步前进都伴随着一步后退。尽管系统在理论上一直可用,但实际上,整个系统已经面目全非,无法再成为下一步进展的基础。而且,机器在变化,配置在变化,用户的需求在变化,现实系统不可能永远可用。崭新的、基于原有系统的重新设计是完全必要的。

系统软件开发是减少混乱度(减少熵)的过程,所以它本身是处于亚稳态的。软件维护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。