漫谈企业应用项目的软件开发过程 -一个PRM系统实施的经验与教训
本文以一个PRM项目为例， 探讨了目前国内软件开发企业在软件开发过程中，尤其是企业应用系统 项目开发中，面临的问题以及如何利用敏捷软件开发方法的解决方案。
一、 项目与公司背景
该项目是一个PRM (Partner Relationship Management)系统，为世界著名的快速消费品品牌在中国大陆的合作伙伴提供订单管理以及其它辅助功能。该系统原来是基于PHP 实现的，已经运行将近2年的时间，但是由于系统功能问题，需要对系统进行重新开发，新的系统基于J2EE 框架实现。
项目预期情况如下：
| 项目开始 http://www.csai.cn | 2002年7月1日 |
| 预期交付 http://www.csai.cn | 2002年9月1日 |
| 项目金额： | 70万RMB |
项目开发商是亚洲领先的电子商务 解决方案供应商，在J2EE架构的项目执行方面有丰富的经验，结合RUP与Web Software Engineering形成了自己的一套电子商务项目实施方法论，并在多个项目中成功进行实施。
二、 项目实施情况
项目由于客户预算等原因，原有的软、硬件系统继续使用，同时，应用系统平台 也采用开源项目。
项目部署时的系统情况如下：
| 硬件： | |
| 操作系统 ： | Solaris |
| 主频： | 400M |
| 内存： | 1G |
| 硬盘： | 20G |
| 应用平台： | |
| Web服务器： | Apache 1.3.21 |
| 应用服务器： | Tomcat 4.0.6 |
| 数据库服务器： | Oracle 8.1.7 |
项目人员配置与项目规模：
| 项目团队 | |
| 项目经理 ： | 1 |
| 技术经理： | 1（兼） |
| 客户经理： | 1 |
| 开发人员 | 4 |
| 测试人员 | 2 |
| HTML 人员 | 1（兼） |
| 项目规模 | |
| Use Case： | 32 |
| 代码行数： | 65000 |
| JSP 页面： | 198 |
项目真实执行情况：
| 开始日期： | 2002/7/1 |
| 交付日期： | 2002/9/2 |
| 验收日期： | 2003/5/8 |
| 维护 http://www.csai.cn | 230 人小时 |
| 目前项目盈利： | 20000 |
目前，项目由于性能问题，仍然没有验收，维护时间日益增长，目前仍然有30万左右的尾款没有收到；更为严重的是，目前项目开发商正在投标的另一快速消费品行业著名客户的合作伙伴与该客户有很大的重叠，因此，对于潜在项目的招标造成一定的影响。
三、 经验与教训
从项目规模中可以看出，该项目的时间还是比较紧张的；另外一方面，项目交付是在合同规定日期之前完成，而且通过了所有的功能测试。从一定意义上的讲，项目的开发是取得了一定的成功的。
3.1 经验
在项目开发前，项目开发商已经通过其它项目，实施了以XP为代表的敏捷软件开发方法的部分最佳实践，并取得了很大的成功。因此，在该项目的执行过程中，项目开发商继续采用了XP的部分实践以及其它软件开发方法中的推荐做法：
每日晨会：在项目实施过程中，每天早晨开发小组都要参加一个持续15分钟左右的会议 ，由项目经理主持，听取每个成员的进度，并根据进展情况，对于进度和资源 进行调整。
由于会议是每天进行的，PM很容易从中获得真实的项目情况－"掀开地毯下面的东西"，从而对风险 有了较好的控制。
交叉审核：项目组在最初的时候原本是想采取"成对编程"的实践，但是没有获得物理和管理上的支持，因此，只能采取交叉审核的方式进行。
需求获取：由PM和一名对于原有系统较熟悉的开发人员进行需求获取和SRS (Software Requirement Specification) 的撰写。技术经理和其它开发人员进行需求的审核。
分析与设计：由一名开发人员进行系统框架的设计，其它人员进行审核；在系统框架设计进行过程中，由于系统去除订单处理以外的其它部分比较独立，因此，将 其它模块分配给开发人员，而将核心部分交与技术经理进行分析与设计。开发人员在每个迭代周期内，都会在分析与设计做完后，每2人一组进行审核。
编码：每天下班前，2人一组，对对方的代码进行Review，发现问题及时解决。代码Review的时候，语法与规则的检查，通过Check Style的工具进行；开发人员将审查的重点放在功能实现与性能优化等方面。
测试：在需求文档形成以后，2个测试人员分布编写分配模块的Test Case；而在具体测试的时候，两人交叉测试对方的模块和更新文档。
在系统开发Verification的各个阶段，都有Check List，详细的信息请查看参考文献。
测试先行：测试在软件开发中的重要作用已经得到了越来越多的重视，但是，由于习惯势力的影响和对于"Test-Driven Development"的不熟悉，开发小组并没有实施完全意义上的测试先行。
对于系统框架的核心类设计过程中，项目小组采取了TDD的方式进行开发。在后续的系统开发中，每个开发人员在进行开发前，首先要完成一个功能测 试 ( Function Test ) 列表，将要完成的Use Case中的主要业务逻辑以及关联逻辑都要罗列出来，在提交测试人员进行集成测试之前，开发人员需要保证完成Function List中的所有选项。
在每个开发人员的模块完成并通过个人的功能测试后，测试人员进行集成测试，同时编写测试脚本，并通过自动测试工具 (Rational Robot) 进行记录。每天下班之前，测试人员会启动测试工具，进行回归测试。在第二天向PM和技术经理提交测试报告并将Bug提交至Bug Trace系统（Rational Clear Quest），由PM进行Bug的分发。每个开发人员需要在下一个迭代周期完成前，修正前一个迭代内分配的Bug。
持续集成：在测试先行的基础上，开发一组平均每天都会进行已经完成模块与以后系统的集成。集成由专门的人员，在开发人员将已经通过功能测试的源码Check in到源码控制系统 (ClearCase) 中以后进行，在部署应用结束以后，通知测试人员进行集成测试。
小步发布：项目有专门的测试与发布服务器，每天都有集成的系统在运行和接受测试。由于没有现场客户，对于已经发布的系统，是由"客户领域专家"（这个项 目是由Business Development人员来充当这个角色）来进行审查的。他对于系统的意见和发现的问题，在经过PM和技术经理审核后，进入ClearQuest，分配 给开发人员进行修改。
由于项目一开始就注意组织内部以及与客户的沟通 和交流，同时采用了很多敏捷软件开发过程的实践，项目如期交付使用。
3.2 教训
项目在交付以后，最初的两个订货季节没有出现功能与性能上的问题。但是，由于合同中有数据迁移的条款，在项目交付2月后，项目开发商将旧应用系 统中的数据导入新系统以后，在下一个大的订货季节中，持续的出现性能上的问题。在代码修改和硬件环境提高以后，系统性能目前获得了一定的改善。 从项目验收日期的日益推迟中，我们可以看出，该项目还是有很多地方做的不够，例如： 系统二次开发效应："第二个系统效应"是Brooks在《人月神话》中提出的一个普遍的问题，一般而言，第二个系统会倾向于过分设计[4]。
对于这个项目而言，没有犯这个错误，却发生了另外一种情况：旧系统中，对于订单信息以及产品信息的展示，不管是多是少（系统页面最多显示上千条 记录），都是在一个页面中显示。这对于没有明显的层次结构，直接在Script中调用数据库记录的PHP来说，性能还是可以接受的。但是，新系统的设计中 客户提出考虑系统用户习惯一致性的问题，就照搬了旧系统的页面设计；同时，在架构设计上，对于这种页面显示大量数据的情况，也没有给予充分的考虑，为后来 的性能问题，埋下了伏笔。
教训一：没有考虑新平台的影响，照搬旧系统的功能以及页面设计。
非功能性需求： 项目合同中主要描述的是系统功能性的需求，而没有非功能性需求的规定；同时，在需求获取解决，也没有明确的了解系统的性能指标等非功能性需求。主要原因在 于项目开发商之前没有大规模业务系统开发的经验，对于非功能性需求没有足够的重视；同时，在测试阶段，也没有对于系统负载和性能做过测试。
因此，在项目交付以后，由于旧系统数据迁移后，数据量有了很大的增长，同时，在秋季的定购高峰中，有大量的并发用户访问，出现了下列问题：
数据库死锁；
大量数据计算与显示页面速度很慢，页面要经过5～10分钟才能够完全显示；
上述两种情况在少量负载的单元测试和集成测试中是不可能出现的。
教训二：对于企业应用系统，尤其是业务系统，没有切实注意负载、性能等非功能性需求。
效率与设计：在J2EE中，已经成功的运用了很多设计模式的思想，为系统的开发提供了一个很好框架。但是，在项目的架构设计中，除了考虑可维护性、可复用性等问题以外，还要考虑代码执行效率的问题[5]。
随着计算机硬件技术的发展，"莫尔定律"被一再的验证，系统硬件的价格逐渐降低。对于很多使用J2EE架构或者JAVA技术的项目来说，解决性能与效率问题的解决方案就是增加硬件方面的投入。而实际上，软件开发过程中优劣算法之间的差距是靠硬件的投入平衡不了的。
该项目在系统维护期间，对代码进行走查，修改了很多对于性能有影响的语句；同时，在框架设计中，尤其是数据库操作方法，利用Cache原理，从一定程度上解决了性能的问题。
教训三：系统框架设计只考虑面向对象和可维护性，没有在完美的设计与高效率的代码之间做出权衡。
数据库设计：JAVA是 纯粹的面向对象语言，利用J2EE开发的项目，也强调首先进行OOAD的分析，首先有对象，然后再有数据库的设计。DBA在项目中的作用，已经远远没有传 统的结构性编程中重要。而实际情况却是远非如此：大部分的业务系统，如果要对系统的性能做出优化，对数据库层或者SQL语句进行优化是关键的步骤之一。
对于这个PRM系统，在数据库的设计上并没有经过DBA的审查就开始进行开发；而在性能问题出现以后，客户增加了512M的内存，也没有请求 DBA对Oracle的参数做相应的调整，造成了很大的资源浪费。 在项目维护过程中，依靠DBA的帮助，开发商对于数据库系统参数、索引、存储过程和SQL语句都做了一定的调整，这对于系统性能的提高起了很大的作用。
教训四：在面向对象的软件系统构建中，忽视数据库设计以及DBA的重要作用。
客户参与：在传统的软件开发过程中，一般情 况下，客户在签订合同后，项目交付前是很少有机会看到系统的，这样就造成了系统交付后，客户抱怨很多的情况；而在以XP为代表的敏捷软件开发方法中，强化 了客户在软件开发中的重要作用，XP更是提出了"现场客户"的实践，将客户作为项目小组的一员，客户对于项目的发布计划、内容和优先级等方面有绝对的控制 权。 对于这个PRM项目，由于客户的原因，不可能采取"现场客户"的实践，但是，开发商的BD对于该客户十分熟悉，完全可以作为客户代表参与到项目中来，因 此，开发商将客户经理作为项目组的一员。
实际情况是：开发过程中，客户经理由于业务拓展的原因，并没有在项目上分配多少时间进行审查；而客户在交付前也没有花费很多的时间研究系统，也 没有提交很多的反馈报告。在系统交付出现性能等问题后，客户经理与开发人员一起对于系统需求进行审查，提出了很多有参考性的意见。如果从一开始，就强化" 现场客户"的最佳实践，就可以很早发现问题。
教训五：客户或者客户经理对于项目的参与力度不够。
四、 结论
在基于J2EE的企业应用项目开发中，要注意以下问题：
权衡系统设计与性能指标，关注非功能性需求；
采取敏捷软件开发过程，关注人（客户和开发人员）在项目实施中的重要作用，如果可以的话，联合实施XP的所有实践；