三、 经验与教训
从项目规模中可以看出，该项目的时间还是比较紧张的；另外一方面，项目交付是在合同规定日期之前完成，而且通过了所有的功能测试。从一定意义上的讲，项目的开发是取得了一定的成功的。
3.1 经验
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
在项目开发前，项目开发商已经通过其它项目，实施了以XP为代表的灵敏软件开发方法的部分最佳实践，并取得了很大的成功。因此，在该项目的执行过程中，项目开发商继续采用了XP的部分实践以及其它软件开发方法中的推荐做法[1][2]：
每日晨会：在项目实施过程中，天天早晨开发小组都要参加一个持续15分钟左右的会议，由项目经理主持，听取每个成员的进度，并根据进展情况，对于进度和资源进行调整。
由于会议是天天进行的，PM很轻易从中获得真实的项目情况－"掀开地毯下面的东西"[4]，从而对风险有了较好的控制。
交叉审核：项目组在最初的时候原本是想采取"成对编程"的实践，但是没有获得物理和治理上的支持，因此，只能采取交叉审核的方式进行。
需求获取：由PM和一名对于原有系统较熟悉的开发人员进行需求获取和SRS (Software Requirement Specification) 的撰写。技术经理和其它开发人员进行需求的审核。
分析与设计：由一名开发人员进行系统框架的设计，其它人员进行审核；在系统框架设计进行过程中，由于系统去除订单处理以外的其它部分比较独立，因此，将其它模块分配给开发人员，而将核心部分交与技术经理进行分析与设计。开发人员在每个迭代周期内，都会在分析与设计做完后，每2人一组进行审核。
编码：天天下班前，2人一组，对对方的代码进行Review，发现问题及时解决。代码Review的时候，语法与规则的检查，通过Check Style的工具进行；开发人员将审查的重点放在功能实现与性能优化等方面。
测试：在需求文档形成以后，2个测试人员分布编写分配模块的Test Case；而在具体测试的时候，两人交叉测试对方的模块和更新文档。
在系统开发Verification的各个阶段，都有Check List，具体的信息请查看参考文献[3]。
测试先行：测试在软件开发中的重要作用已经得到了越来越多的重视，但是，由于习惯势力的影响和对于"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的所有实践；进入讨论组讨论。
