＋设为首页 ＋添加到收藏夹
增量迭代
自从有软件工程一说开始,大大小小出现了许多方法,其中一些还常常被我们挂在嘴边.这些软件方法中最著名的生命周期模型包括waterfall,它是由royce于1970年首先提出来的.一般来说,waterfall方法把软件开发的过程严格地分为几个阶段,包括： 【相关文章:层遇到select框时】 【扩展阅读:设计模式c#语言描述——合成（Compo】requirement phase、specification phase、design phase、implementation phase、integration phase，要注意测试并非一个独立的阶段，几乎在每个阶段都需要检查与测试。 【扩展信息:.NET – 深入系统编程 - Part】应当说，waterfall模型由它自己的很多优点。waterfall强制每一阶段都必须产生所有的产品，只有当这些产品通过相关的审核后才能开始下一阶段的工作，而这些产品中相当重要的一部分就是每一阶段的详细文档。specification文档、design文档、code文档与其他相关的文档，如数据库手册、用户指南等等是维护产品基本工具。有研究指出，大约70%的软件预算用于维护阶段。而waterfall模型强制每一阶段必须有详细文档，所以，看起来waterfall能使用这些文档大大削减这方面的开销。
但是，waterfall模型受文档驱使的方式也可能成为一个缺点。waterfall起始于需求阶段，一旦需求报告被用户承认，你就开始起草specification文档，它指出了软件需要做什么东西。specification文档通常很长、很详细、很直白，因此很容易让人看着生厌。用户通常都很难完全看懂软件的specification文档，他几乎不可能判断你讲得是否正确，但通常他还是会签字的。
这里的问题是人与人之间的交流是否能够完全使用文档来实现，即使你能够使用更加高级的图形如uml图。对于这个问题，生物学家maturana与varela在生物系统中进行了研究，下面是他们在«the tree of life»一书中的答案：
。。。。交流的现象不依赖于被传递的内容，而是依赖于在接收者身上发生了什么。并且这是一件与"传递信息"极不相同的事情。alistair cockburn在他2001年的新书«agile software development»解释说，你可以想象人被一层薄膜所包围，在接受到外部刺激，被重构翻译成内部信号，从而引发内部活动。所以人真正所接受的信息取决于内部而不是外部。更浅显的例子也有cockburn给出，他说：
考虑一个具体的例子，某人冲进一个房子，用日文大叫"着火了！"。一个能讲日语的人接收到许多信息，并且立刻冲向出口。他身旁的另一个日本人，正好在睡觉，因此根本没有接收到任何信息。外部刺激没有转化成内部信号。一个不懂日语的人注意到有个人进来大叫，但是却没有从他的话语中接收到任何特别的信息。每一个人从大叫接收到的东西端依赖于他的内部条件。在对这一声大喊的翻译过程中，一个日本人能够接受到大量信息而非日本人却不知所云的重要原因是大喊的人与那个在房间里的日本人有一个共同的经验：日语。软件需求获取者、specification撰写者与用户之间往往不可能有这样的共同经验。
同样，如果光光依靠设计文档想使得设计者与开发人员之间能够达到很好的交流也是不可能的。文档有助于增进理解，但是它不可能达到完整的理解。waterfall试图依赖非常详细的文档来接近交流的完美。事实上，对文档的理解并不依赖于文档的详细程度。而是依赖于文档的编写者与文档阅读者之间的共同经验。
... 下一页