软件工程师展开的问题求解工程（下）

　　其实，我们在分析审查时,应用域模型通过与客户实际情况的对比,这一评审结果反过来也会促使该模型发生变化。在设计审查时解答域模型要参照项目目标进行评估。

　　然而在测试过程中,系统的验证要与解答域模型进行对比,解答域模型可能因为新技术的引入和使用而发生改变。在项目管理中,项目经理将其开发的过程模型(即项目进度和预算)与实际情况(即即提交的工作产品和使用的资源)相对比知识获取软件工程师和管理者常犯的错误是认为开发一个系统所需知识的获取过程是线性的。

　　并不是只有软件管理者才犯此类错误,其他领域的人也会犯此类错误。例如,在17世纪出版的一本书里,就描述了试图在6小时内将所有德国诗歌用像漏斗那样的工具灌入学生头脑。使用漏斗学习的想法是基于我们的头脑如同一个桶的假设,这个“桶”一开始是空的,因此可以用线性的方法装填:学习材料通过我们的知觉藻输进来,积聚起来并被我们消化Popper把这种线性的知识获取模式称为“大脑桶式理论”。

　　在这一理论的诸多错误中(见Popper,1992]描述),有一种错误就是认为知识是由可装在桶里的东西构成的:即“桶”越满,我们的知识就越多知识获取是一个非线性的过程。对一个系统的理解,一条新信息的获得可能使我们为了理解系统而获取的所有知识变得无效。即使我们已经在文档和编码中证明了这种理解(“这一系统已经完成了90%的代码,我们下周就完工了”),我们必须作好从零开始的心理准备。这一点对于我们定义的用于开发软件系统的活动集合及其交互有重要含义。

　　大脑桶式理论相当于软件开发过程的线性瀑布模型,其中工程方法的每一步都是有序地完成的。有一些软件过程,通过避免瀑布模型所固有的线性依存性来处理知识获取这一问题基于风险的开发试图通过找出高风险构件来预测一个项目后期的意外。基于问题开发试图完全摆脱线性特征。因为为在线性瀑布模型中的任何一种开发活动分析、系统设计、对象设计、实现、测试或交付一一都可能影响其他活动。

　　小编结语：其实，我们都在基于问题的开发中,所有这些活动都是并行执行的。使用非线性开发模型的困难则是开发过程难于管理。