兔八哥笔记6：XX管理系统项目笔记

 

我从2002年10月－2003年3月30日参与开发了《XX器材管理系统》，在这半年里参与了前期调研，需求分析，概要设计和详细设计的工作，并且开发了主要的业务流程模块。现在这个项目接近尾声，在这期间遇到了一系列的问题，有些问题是经历过后才体会到的，但有些当时虽然体会到了，但不知如何解决。下面是这个项目实施过程中发生的一些事情。

我在2002年的10月10日左右被指派到XX所的XX室和XX所的技术人员一起开发这个系统，当时的合作模式是XX所和我们公司一起联合开发，由我们公司派出2个人和他们一起用Visual Foxpro 6.0一起开发这个系统，当时的期限是2002年12月25日前完成，在2002年的12月底给领导演示。当时XX所底技术人员说他们的系统已经完成了70－80％，但我和JS技术部的另一个同事参加进去后，发现他们完成的最多只有30％，并且没有文档，没有确切的需求，两个开发人员做到哪里，就问到哪里。由于使用的开发工具不适合开发C/S结构的系统，所以从开发进度看是事倍功半。半个月后他们发现按照他们的做法已经不可能在预期时间内完成了，然后将除计划部分外的功能全部委托我们公司开发，并签订了合同，大致达成的协议是在2002年12月底完成一个能够给领导演示的版本。

在随后的一个月里（大概到2002年的11月20日左右止），XX所的2位技术人员到公司为开发人员讲述了他们了解的最终用户需求、将要开发的系统和计划部分的接口和他们对将要开发的这个系统的大致的外观。

       当时一切似乎都很顺利，中间虽然有过几次客户急于开发人员立刻编码的要求，但最后客户同意了做完需求后再编码的决定。这个系统从业务实体分为3个实体，分别是：供应站、仓库、申请单位。当时需求分析和详细设计主要放在了供应站部分，申请单位和仓库部分的详细设计只用了半天。申请单位的业务功能非常少，但仓库部分的业务除财务部分其他的相同业务均比供应站复杂。由于当时很多业务和JS技术部的其他系统的业务差不多，所以按照其他系统的业务模式设计了这个系统的仓库的业务处的出入库部分和对帐部分。但后来证明仓库的出库和对帐部分和已有系统的业务是不一致的。仓库部分的多个界面和处理流程变更了多次。

       2002年11月23日左右正式开始编码，当时的目标是在2002年12月底开发出一个能给领导演示底版本，当时的开发人员12人。

       从需求分析到编码阶段采用的软件生命期模型是“瀑布型”，但要达到的目的恰恰是“渐进交付”非常适用的范围。这是我后来才意识到的。

       很快我就遇到了麻烦：仓库对帐部分的对帐条件是什么？这在需求分析和详细设计阶段都没有讨论，开发时我参照JS技术部的其他系统的对帐模块做了这个模块的界面，关于对帐的条件我问过JS技术部的一个和我一组的开发人员，问过这个项目的项目经理，问过部门经理，但三个人的对帐条件完全不同。后来和部门经理和项目经理讨论后确定了一个对帐条件，我把这个条件写到了注释里面，并按照这个条件完成了这部分的代码。我承担的任务中有2个套打单据部分（后来我又承担了供应站部分的调拨单的套打），这部分遇到了一些技术问题，有硬件问题，也有开发工具的问题。用了一周的时间解决了这部分。其余部分用了3周时间也结束了，用了一周的时间进行单元测试，又联调了3天。这是已经是12月底了，这个系统主要业务流程可以演示了。后来因故没有演示。

       最终用户对于已经完成的部分和进度不是很满意，由于这个系统当时已经有10多万行代码，用了一个月的时间完成了主要部分，对于开发速度可以说是成功的，但由于时间太紧，没有经过严格测试，所以不时会报错。既然演示推迟了，而客户看到了最终的雏形，他们认为有些地方的业务完全不符合他们的习惯，这是必须改的地方，但他们说的这个地方却是在需求分析时候没有明确提出的，所以这部分是按照已有系统的相似业务做的。由于采用的“瀑布型”生命期模型，在开发结束前客户看不到最终的实现，所以也造成了对这个主要业务的修改。这部分的编码在后来的开发过程中完全重做的。客户对界面的控件的摆放和大小都非常挑剔，这些都作为最终意见提出并和其他一些变更需求都写入了《对器材系统修改意见最终稿》。这时已经是2003年的1月10号左右了。在第一阶段的开发过程中，开发人员进行了大量的加班工作，在第一阶段结束后和客户提出最终意见之前这阶段这个项目甚至有短暂的失控。随着厚厚的最终意见和人事变动，整个团队士气低落。

       春节后，这个项目重新启动，和客户协商完成最终意见的最后期限是2003年的3月20日。由于人事变动，原来12个人的工作落到了7个人的身上，我和另一个同事分担了离开公司的第三个人的工作任务。原计划3月5日联调，不知什么原因3月12日才开始联调。3月23日才完成联调。但这个版本的质量如何不好评论，因为这个系统从开发到3月23日都没有经过测试部的测试。问题应该还是有的。

       在这个系统的实施过程中，我看到了一系列的问题，这些问题大部分都是小型项目中遇不到或不会产生严重后果的，但在稍大一些的项目中，它们产生的后果是影响了开发进度。

1．  需求调研和分析中的问题。这个项目的实施结果证明需求调研和分析中遗漏了一些重要的需求。主要是XX所的技术人员不是最终用户，当时我们掌握了他们的需求，但不是最终用户的全部需求，另外这个系统实施中，最终用户很少参与。这是造成这个问题的一个关键所在。这引起了“变更需求”

2．  软件的交付模式（软件的生命期模型的选择）。在这个项目中，客户基本是在软件开发完后才看到，于是他们对和他们业务流程和不符合造作习惯的部分极力反对。

于是产生了“变更需求”（客户认为他们的需求从来没有改变，但对我们却是产生了改变）。   

3．  客户的“需求镀金”。客户希望这个系统能得到领导的好评，于是提出了一些对于业务的实用性不是很强但很花俏的功能和性能的需求。这当然造成了我们开发任务量的加大，同时开发周期延长。

4．  项目实施进度的监控。这个项目实施过程中，没有一个完全了解业务的人指导和跟踪监控，这也是造成一些模块需要修改甚至重新开发的原因之一。

5．  文档与代码处理流程不同步，没有人做文档更新。使项目实施过程中没有一个完整的依据和标准。

6．  前期设计有遗漏。在3月18号，项目经理要求开发人员将所有的状态编码全部改为新加入的常量，几乎与业务相关的每个函数都用到了，这是编码已经完成，单元测试已经完成，如果此时修改，至少要推迟一周进行修改和修改后的测试。最终没有修改。

7．  接口不统一。在编码开始时仓库部分的数据库就设计了器材类型的字段，并定义了状态值及意义，供应站没有加入这个字段，到了项目后期，客户要求加入这个字段。供应站部分的数据库加入了这个字段，但状态值定义的与仓库不一致。项目经理要求仓库修改完成的代码与供应站保持一致。开发人员拒绝修改，最后供应站部分的状态值的意义与仓库保持一致。

8．  开发人员对配置工具SourceSafe不熟悉，致使多次使用旧版本覆盖新版本。

9．  软件复用的问题。对于能够公用的模块没有及时更新或推出不及时，致使增加了后期的修改工作量。

10．              需求模糊，开发人员无据可依。

11．              客户影响。客户是技术人员，总是希望系统采用他们的开发经验和模式开发。如果和他们的不同，有可能造成变更。在这个项目中，对于界面的摆放和Lable在Edit的左侧还是上侧产生争论。

12．              系统风格统一的问题。这个系统的界面的窗体和Button的风格在项目初期就确定下来了，但对于DBGrid的颜色和其他控件的颜色没有定义，结果是12个开发人员的界面“百花齐放”。

13．              第三方控件使用问题。由于一个模块中用到LMD中的一个打开文件夹的控件，结果每个人都必须安装LMD控件才能编译。实际上这个系统中规定使用的第三方控件有2套，一个是DBGridEh，另一个是RxLib。这个控件完全可以用Rxlib中的一个控件来解决。与此类似的还有非标准控件的使用。

14．              系统可维护性问题。仓库部分由3个人来开发，第三个人离开公司后，接手开发人员发现他的代码使用的数据集控件是不常用的ADODataSet，而后由于这部分的变动很大，结果不得不更换控件，甚至有些代码都重新编写。还有一个就是详细的注释问题。有些代码通篇没有注释，或很少注释。阅读困难。

15．              数据库脚本的生成问题。这个项目中的数据库脚本维护不是从最新的数据库中自动产生，而是从一个维护的文档中生成。这可能造成与最新的脚本不同。

16．              视图和存储过程使用的问题。有些视图是可以公用的，应该尽早定义。存储过程使用起来非常有效率，但应有详细的注释，另外调试不易。

17．              联调中的问题。联调中共用一个数据库会造成一个人用到的数据被另一个人修改或删除，影响联调进度，可以采用数据库复制的办法，先使用公用的数据进行单元测试，没问题后在使用同一个数据库进行整体测试。测试出Bug后继续使用联调数据库的备份数据来进行调试。

18．              数据库设计中命名规范的问题。应该有一个全面的、易于区分的命名规范。

19．              项目进度的可视性问题。本项目没有采用最小里程碑等证实有效的强化项目可视性等方法。所以对监控人员和客户而言，谁也不能准确预计完成了多少，大概该有多少任务要完成。

20．              开发人员功能镀金。由于客户需求不明确，概要设计没有提及，于是到了开发人员的手里，可能就会产生“功能镀金”，也就是用其他的技术可以实现，但为了更花哨，或体验一下新技术而进行的一些带有试验或研发性质的开发。这对于进度紧的项目是有害的。在这个项目中我接手了一部分其他人员的模块，由于客户对界面和执行效率不满意，提出改进，但没有提出界面怎样改进，效率达到什么样。又由于原代码没有注释，而且使用了不标准的控件，于是我把这个模块重新写了，结果效率非常令人满意，界面仿照瑞星杀毒的界面也还算漂亮，同时也间接的解决了一个困扰其他开发人员的器材树刷新速度的问题。但我承认我犯了“功能镀金”的错误。我为了仿照瑞星杀毒的界面进行了2天的试验才作出来。而在那2天里，我不知道这个试验能否成功，如果不成功那么这两天的时间就是浪费的。如果没有充裕的时间，一个理智的开发不应该这样进行。

 

以上是我从这个项目重总结出的经验和教训。同时我也还有很多问题找不到答案。如：

1．  在与客户签订的合同里应该怎样写才能避免客户的“需求蔓延”和“需求镀金”？

2．  对于客户的变更需求是否应该全部满足，怎样是我们的底线？

3．  怎样做需求调研和分析才能保证重要的需求不被遗漏？

4．  一个大型项目应该怎样监控才能获得最好的效果？

5．  怎样设计一个变更适应性强的系统？

6．  怎样才能精确估算出一个系统所需的期限？

7．  怎样排除客户不切合实际的需求？

8．  开发过程中是否应该使用更多的CASE工具，如Rose、PowerDesigner等？

 

 

 期待和大家共同讨论！

E-mail：ltf_ty@163.net