有一个需求摆在你面前，有一个现成的软件摆在你面前。你是在现有的软件基础上继续改进实现新需求，还是扔开这个现有软件重新做？就这么简单的一个问题，简直能让人——尤其是像我这种本来就有选择障碍的人——挠破头皮。用现成的软件吧，质量不见得好，扩展不见得容易，说不定做起来就发现步步是陷阱；从头做吧，看着别人做好的东西要重新做总是不甘心，更何况还可能有政治压力，没准儿这个软件正是哪个领导的最爱呢。
怎么办？作为一个有选择障碍的体系爱好者，答案自然是：创造一套体系，让体系来给出答案，那么我就不用挠头啦。以下就是我的体系，遗留系统评审我就照着这个套路来。
第一步：需求评估
脱离需求的上下文就很难讲一个软件好还是不好，因此首先要做的不是评估这个软件本身，而是评估要用它来做什么。首先框定需求的上下文，然后你才能说出为了满足这个需求软件应该具备哪些特质。
第二步：功能评估
接下来是评估这个软件现有的功能。当初开发这个软件时考虑的需求上下文与你现在要满足的未必一致，但是要充分了解一个软件，你就不能脱离它本身的上下文来讲它的功能。你还得回到它当初设想的需求当中，在那个上下文里来看，这个软件实现了哪些功能。
第三步：差距分析
这时候才轮到谈现有软件缺少了什么：把已有的功能放到新的需求当中，做个对比，看看已有的功能是否满足新的需求、缺少了什么、偏差了什么。这时候需要把差距一条条列出来，甚至可能需要大致估计如果要弥补这些差距需要多大工作量，因为“继续用现有的软件”始终都会是一个选项。
第四步：技术质量评估
如果继续用现有的软件是一个选项，那么在这个软件基础上修修改改究竟有多难、多快就严重取决于这个软件的技术质量——如果代码质量一团糟，在上面做修改必然会慢很多。技术质量评估可以有很多常见的度量指标，我比较愿意谈可维护性和可扩展性，影响它们的因素就会有代码可读性、模块设计、接口设计等等。
第五步：结论
千万不能说“把这个破软件扔了我们从头做吧”——虽然我知道很多时候我们就是想这么说。我们的评估应该是基于事实的，而且至少得有两个选项让客户来做选择：除了“从头做”之外，至少还得有“继续用现有的软件”这个选项存在。从头做一个符合新需求的软件需要多少成本，未来的总体拥有成本是什么趋势；修修改改现有的软件需要多少成本，未来的总体拥有成本又是个什么趋势；两者有什么好处有什么风险。把这些东西列出来，让客户能基于这些事实做一个明智的决定，就是我们做评估的目标了。
