无痛苦的软件维护——被遗忘的需求
先说一个小笑话。有一个生产队队长，他对专家说：“现在我们生产队的地越来越多，牛越来越忙不过来了。我想要这么一种牛，他吃的草和普通牛一样多，但是干的活是普通牛的十倍。”专家说：“这种牛是可以造出来的，现在有基因工程。”队长说：“好吧，你给这造几头这样的牛。”于是专家找到了生物实验室，让生物实验室的人搞一个基因工程，把牛造出来。于是工程浩大，投资无法保证，合作多半是不愉快的收场。
现实世界里很多人分析需求的过程就类似于这位专家，他们把注意力放在用户提出的功能点上，而对用户的实际需求没有兴趣。有不少软件公司和程序员，其实都在做类似的基因工程。如果这个专家把注意力放在生产队长的业务需求上，而不是太在乎他提出的功能点，他会说：“我认识一个卖拖拉机的，可以带你去看看。”
软件的维护为什么这么痛苦，一个很重要的原因在于：需求已经被遗忘了。
需求是对用户具有直接商业价值的活动，而不应该牵涉到任何的功能实现方式。实现同一个需求可以使用多个方案，每个方案有自己的功能方式，在某个方案中至关重要的功能点，也许在另一个方案中根本无关紧要。
瀑布式的开发过程，首先是由一批懂得用户业务的专家去调查用户的需求，分析出这个系统应该具有哪些功能，形成一个非常重要的文件——《xxx系统需求规格说明书》。客户认可了这个《说明书》，在上面签字盖章，加入合同附件，到时候项目验收就以此为准。这时候，需求就已经分解成了一个个功能点，从这时候开始，需求本身就渐渐被人们遗忘。设计人员围绕着这些功能点进行工作，考虑用什么样的技术手段把功能点制造出来。功能点的制作细节形成了另外一份重要的文件——《xxx项目设计规格说明书》。这个《设计规格说明书》交给程序员去进行编码。
这样的做法在开发中已经形成了很大的问题。
首先，面对这样的《需求规格说明书》，设计人员已经无法知道最初的需求是什么。假如这个《需求规格说明书》中的功能点没有出现互相矛盾的情况，而他们串起来却和用户的需求不同，设计人员没办法发现这样的情况，编码人员也无法发现。假如测试也是根据这个《需求规格说明书》来做的，测试人员也发现不了。直到最后客户看见这个程序展现在他们面前。需求的分析需要在随后的过程中不断得到反馈，传统的过程不是没有反馈，而是反馈的时间太长了。
其次，由于设计人员已经无法知道基本的需求是什么，也就无法对业务进行建模。这样的需求分析是以开发人员的需要为核心的，可是结果恰恰妨碍了开发人员对需求的理解。如果开发人员对用户的业务过程不甚了解，他们只有一种选择：不要试图去了解需求了，直接按照这些功能点做吧。于是，他们建立的对象模型就不是以需求为核心的，而是以功能、界面为核心的。我见到过很多这样的系统，开发者确实有很高的抽象思维水平，程序中设计了非常巧妙的控制器和界面，可以很方便的进行开发和变更。唯独业务层的对象非常简陋，一旦发生实际业务的变更，仍然十分辛苦。
更大的困难发生在维护程序的时候。
假设有一个移动通信公司需要制造一个系统，用来解决手机用户入网的问题。这个需求有下面几个要点：
1：用户付钱，得到一个SIM卡和一个号码，把这个SIM卡装到手机里就可以通话。
2：营业员收的钱要记录下来，提供给稽核人员，现金和帐目必须是平的。
3：用户付的话费要划入他自己的帐户，可以打印票据。
4：用户要在入网合同上签字，然后营业员把合同归档。
这几个要点都是和通信公司的商业利益直接相关的，没有牵涉到任何系统实现方式。如果不考虑通信公司内部的业务规范，实现方案可以有几十种，下面列举两种：
1：SIM卡发给营业员，用户入网的时候，选择一个号码，然后付钱。营业员把SIM卡号码和电话号码输入系统，在交换网络上进行注册，这个SIM卡就可以通话了。然后各种费用记入各人帐户，合同归档。
2：SIM卡在下发给营业员之前，先在交换网络上和注册，并且已经预先设置了一定的话费。用户选择了这个号码，付钱之后直接SIM卡拿走就可以打电话了。营业员事后再输入用户的合同资料，费用计入各人帐户，合同归档。
这两种方案在实现过程上是不同的，因此具有不同的功能点。比如第二种方案中的SIM卡在出售之前是可以进行通话的，所以必须对这样的号码的通话费用进行监控，这个功能在第一种方案中是根本不需要的。并且两种方案在帐目的核对方式上区别也是比较大的。这两种方案是不同的功能点的集合，他们完成的是同一个业务需求。
系统在开发阶段如果没有保留用户的业务需求情况，而是只留下一个功能点的列表，会给维护人员带来成很大的困难。维护人员无法从这样一堆功能点中发现最初的需求是什么样子。各位可以试试，假设我们忘记上面的四个需求要点，只看下面的某个实现方案，从这个复杂的实现过程中，我们很难知道用户现在的需求到底是什么。一旦需求发生了变化，这些功能点就会出错，或者是功能点的时序发生意料不到的错误，也许帐目核对不上了，也许是用户拿走的SIM卡不能打电话了。
看不见需求在哪里，不知道手里这段代码会触动需求的哪根神经。维护人员的痛苦大部分来源于此。
“不要紧，客户记得自己的需求。”但是客户通常不懂技术，即使他们懂技术，他们也不知道系统是如何实现的。如果开发人员依靠客户提出新需求的解决方案，结果就是让软件工程变成“生物工程”。到最后是钱基本花光，人基本累死，甲乙双方感情基本破裂。
软件开发必须划分成几个过程，但是各个步骤应该有一个统一的核心——业务需求。
在需求调查阶段要搞清楚用户的业务需求，为了达到这个目的，可以提问回答，可以对用户进行跟踪采访，或者做一个demo给用户看看，最终的目的是为了搞清楚用户在做什么事，遇到了什么问题，程序应该去解决什么问题，这就是这一阶段的工作。
然后开始进行设计，设计系统的逻辑结构和物理结构，逻辑结构要符合需求的概念，各个对象互相调用要能够实现需求中的业务过程，同时物理结构划分合理，符合实际的分布状况，可以达到要求的的性能，业务过程的物理运行方式合理高效。这一阶段仍然是以业务需求为核心。
接下来是编码。首先是编写一些基础设施，比如网络通信、数据库、文件的读写、分布式计算，这些基础设施和业务需求没有什么关系，有很多现成的框架，借助这些框架我们可以尽快度过这个黑暗的阶段。然后编写业务对象，这时候业务需求中的一些概念逐步出现在代码中。接着这些业务对象串接起来，实现业务过程，现在业务需求又回到了人们的视野当中。业务需求是什么，如何实现，在这里一目了然。最后将这些过程在UI或者接口中调用，将功能提供给用户或者别的系统。
测试更是要围绕着业务需求来进行，正常的业务流程应该产生正常的结果，如果缺少某个资源，或者输入了不合适的数据，应该出现业务含义明确的异常。并且系统的业务对象是处在一个独立的层次上，与UI和基础设施没有很大的关联，这样可以方便的采用自动化的测试方法。
这样的系统维护起来一定少很多痛苦。
posted on 2006-11-13 12:08 小陆 阅读(1074) 评论(11) 编辑 收藏 引用 网摘 所属分类: 软件工程实践
2006-11-13 12:27 zhh007's Bolg
hao!
2006-11-13 12:41 Ricktroy[匿名]
作者的分析确实很正确
但是在外包软件工程中很多情况下是无法和客户直接沟通的
这也是外包服务一直以来的弊病
2006-11-13 12:44 yzx110[匿名]
首先说，说的有道理
但是：
1：用户付钱，得到一个SIM卡和一个号码，把这个SIM卡装到手机里就可以通话。
2：营业员收的钱要记录下来，提供给稽核人员，现金和帐目必须是平的。
3：用户付的话费要划入他自己的帐户，可以打印票据。
4：用户要在入网合同上签字，然后营业员把合同归档。
需求规格说明书是弄成这样的么？如果弄成这样那还真是不好说，太不确定了
1：SIM卡发给营业员，用户入网的时候，选择一个号码，然后付钱。营业员把SIM卡号码和电话号码输入系统，在交换网络上进行注册，这个SIM卡就可以通话了。然后各种费用记入各人帐户，合同归档。
2：SIM卡在下发给营业员之前，先在交换网络上和注册，并且已经预先设置了一定的话费。用户选择了这个号码，付钱之后直接SIM卡拿走就可以打电话了。营业员事后再输入用户的合同资料，费用计入各人帐户，合同归档。
我认为，这两点还是需求，并不是单纯的功能点(实现方式)，因为这已经涉及到运营方式了。
2006-11-13 13:06 新型报表工具 xdesigner
楼上的钻牛角尖啊，楼主只是列出个简单的例子，只是帮助说明文章思想。
2006-11-13 13:30 aspnetx
客户认可了这个《说明书》，在上面签字盖章，加入合同附件，到时候项目验收就以此为准。
-----这一点,相信国内很多中小软件公司的项目还是有困难的,因为客户的需求往往只是"你先做着"
于是，他们建立的对象模型就不是以需求为核心的，而是以功能、界面为核心的。
-----说的好
另我想起以前关于"秋千"的那个漫画
2006-11-13 13:45 freeman[匿名]
钱基本花光，人基本累死，甲乙双方感情基本破裂。
2006-11-13 16:42 ∈鱼杆
钱基本花光，人基本累死，甲乙双方感情基本破裂。这句很经典
2006-11-13 17:02 寞人
本来就是,现在很多软件的某些模块的功能简直是垃圾.完全为了炫耀.
2006-11-13 21:07 Kyle[匿名]
The situations addressed by the author exist in the reality definitely. But there is a problem with the system analysis process in the case above.
When the analyst does the system analysis, the functional points are not only listed one by one. With the help of modeling tools, the entire business process could be represented. Most of these tools are leveled diagram, such as Data Flow Diagram, Behavior Trees, etc. Data Flow Diagram is a modeling tool used in traditional business area. Sometimes, it could be used to refine the business process, removing defects and inconsistency from the functional requirements provided by the customer.
The system analyst should represent the business process with these modeling tools from top to bottom. Additionally, these diagrams would become the basis of further design activities. The designer would know the requirements and the complete business process clearly.
Thanks:)
2006-11-14 08:59 newman0816[匿名]
同感！分析的透彻。
2006-11-14 09:26 老翅寒暑
我觉得定需求不是定做什么，而是去确定“不做什么”这个确定下来之后，基本需求边界也出来了，而且客户很容易知道自己不需要什么，知道自己确切需要什么的人真是太少了。
这里有装修过房子的程序员吗？问问他们就知道了