第五种 谨惕在已有的系统中的开发和测试
在许多软件开发项目中，已经存在的但缺少或没有保存需求文档的软件产品，会基于这些产品的体系结构进行重新设计和平台升级。在这种情况下，许多公司会认为新的软件系统可以完全的在对已经存在的项目进行进一步的调研的基础上做开发和测试，而没有花时间去分析和文档化软件的功能。按照推测认为已经存在的项目其本身就已经显示出了必需的需求，而没有必要把精力和时间浪费在对已经存在的软件项目进行需求的再设计或者分析和文档化，表面上，这样做似乎可以提前交付日期，其实不然。
不幸的是，在几乎所有的小型项目中，使用已经存在的项目作为需求基线的策略里，都会伴随着许多缺陷和经常导致很少的需求文档、不适当的功能和不完善的测试。
虽然项目功能的许多方面都是能够说明其功能，开发人员很容易理解许多专业的领域知识，但是还是会很容易的忽略依赖于已经提供的数据基础上的业务逻辑。并且通常这是很难通过对已有项目进行各种数据输入就能确定的，而且很有可能使项目的一些功能丢失。在许多情况下，对一定的输入产生相应的输入的原因是很困惑的，而且软件开发人员会想象出最好的猜想来回答软件为什么会表现出这样的做法。一旦实际的业务逻辑确定后而没有文档化，会事情变得更糟糕；相应的，对新系统进行直接的编程会引起无限的猜测周期。
除了业务逻辑方面的问题，用户界面或许也是一个很有可能错误理解的地方，或者遗漏完整的用户界面的一部分。
许多时候，已有项目的基线仍然存在并且在开发过程中，或许使用完全不同的体系结构和过时的技术；它还存在产品和不断的维护中，包括缺陷的修改和添加到产品的每个新版本中的新功能。这就呈现出一个目标迁移的问题：更新和新特性已经应用在项目中，就会被认为是新产品的需求基线，甚至会被开发人员和测试人员认为是新产品的重新设计。结果是新项目就已有项目不同时期的混合物，而已有项目还在其自身的开发生命周期中。
最终，在目标迁移的情况下，在整个软件开发生命周期中进行分析，设计，开发和测试活动，并对其进行合理的时间，预算和人员评估是非常困难的。没有可以利用的需求来说明我们构造什么和测试什么，项目组很难有效的预测需要投入的精力。大部分的评估都是依据在对功能的偶然的理解基础上的，而这些功能很可能是很不正确的，或者在已有项目升级时需要飞跃性的修改。在以需求的完美的陈述基础上，评估任务就变得非常简单，但是当所谓的需求是嵌入在已有的或者目标迁移的项目中的时候，评估任务几乎是不可能的。
表面上，项目构造在已有项目基础上的一个显然的好处是：如果输出被认为是一样的，测试人员可以不断的对比旧项目的输出和新实现的项目的输出。然而，这是不安全的：如果旧项目的输出在某些场景下暂时的出错，而没有人会知道它呢？如果新项目执行是正确的，但是旧项目执行是错误的，测试人员就会报告无效的缺陷，修改的结果是新项目和旧项目存在相同的错误。
如果测试人员确定他们不能依赖已有项目进行对比输出结果和已有问题。或者如果他们执行了测试流程并且两个项目的输出结果不一致，也无法确认哪一个结果是正确的。如果需求说明书没有文档化，测试人员如何确定哪一个输出结果是正确的？应当在需求阶段确定预期输出结果，这种分析应在测试人员的控制范围内。
虽然在已有项目的基础上进行新的软件项目的开发是非常困难的，但是也存在一些方法来解决这种情形。第一步是进行期望管理。团队成员应知道新开发的项目是基于已有项目的基础上开发的。下面列举了应当注意的几点内容：
1 使用已经成功的软件版本。所有风险承担者都必须明白为什么新项目必须建立在已有项目的一个特定版本的基础上的，而且必须认同这种情况。团队必须选择已有项目的一个版本作为新项目的基础，并且仅仅使用这个版本作为开发的开始。
可以直接的在已有成功的项目版本上进行缺陷跟踪，可以确定在已经选择的已有项目的版本中的缺陷是否存在新的项目中，不用考虑已有项目的编码的更新和正确性。还有一点是必须确定的，那就是已有项目实际上是正确的，使用专业的领域知识，还必须认识到当已有项目存在缺陷时，新项目却是正确的。
2 对已有项目进行文档化。下一步是拥有一些领域或者项目的专家对已有项目进行文档化，至少写出每个特性的说明，提供不同的测试场景和它们的预期输出。更好的是对已有项目进行充分的分析，但是在实践中这需求花费很多的时间和员工投入很多的努力，这就变得不可行或者缺乏资金。一个非常理想的做法是将特性写成段落的形式，仅仅对一些复杂的需要文档详细说明的交互关系进行详细的需求分析。
通常当前项目的用户界面是不需要进行详细的文档化的。如果界面功能不能显示出软件内部功能实现的复杂性，并且这种复杂性与用户界面相交互，这种文档是不够详细的。
3 文档化已更新的已有项目。更新是增加或者改变需求，当新项目准备进行升级时，对已有项目的基线也应从现在往后升级并将其进行文档化。这样做可以对已有项目的功能做稳定的分析和适当的进行设计和测试文档。如果可能的话，两个产品能够使用需求，测试流程和其它测试产物。
如果升级没有进行文档化，新产品的开发就会产生连锁反应：已有项目和新项目的矛盾会变得很零散；一个项目中已经修改了，而另一个没有修改；一些缺陷可能预先知道，而另外一些缺陷却在测试过程中被发现或者更严重的是在发布后才发现。
4 在前进的过程中实现开发流程的有效性。即使已经开发出来的系统没有相应的需求说明文档，设计文档或测试文档或任何系统开发的流程，无论怎样，一个新特性是在先前项目还是在新项目中被开发，开发人员都应确保已经定义一个良好的，相互交流的，可遵循的和可调整的系统开发流程，这是必需的，可以避免软件工程实践无休止的错误。
通过这些步骤的学习，项目开发过程中的一系列特性都被概括和量化了，涉及到了良好的组织，计划，跟踪和测试的每一个特点。
