***大学校园信息化系统(URP)总结

 

**大学校园信息化系统(URP)总结

从今天开始，项目进入了验收阶段，也难得有空，大家在一起庆祝一下，同时也没有忘记叫上和曾经一起为这个项目奋斗过的同事，在吃饭过程中，大家都比较兴奋，为期三年的项目终于快要结束了，能不兴奋吗？这可是几代人的共同心愿啊！！ 但是在兴奋之余，还有非常 心酸往事…… ：

《一》工作阶段问题

2002 年 7 月项目开始了需求调研。由于以前从来没有从事过教育行业软件的开发，也没有相关的业务经历和经验，导致在项目调研阶段，对需求的把握非常不够，直接导致在项目实施过程和运行中不断的进行需求的补充和重复的开发和修改。

需求调研的面不够广，仅仅对相关业务部门的发起者 ( 部门、角色 ) 或者是学校负责项目招标的部门 ( 如信息化中心 ) 负责人进行了调研，导致在后期项目运行过程中，有很多的业务无法开展和使用，需要重新进行调研、设计、开发、测试、修改等。

2002 年 8 月－ 2002 年 9 月 项目开始就项目规范和整个技术方案进行了充分的讨论。 在此期间，就 项目规范与用户方进行了非常深入的沟通，双方花费了很大的精力希望能说服对方采用本方提出的项目规范。在此规范问题上双方耗费了整整一个月的时间。但是在项目的执行过程中，并没有真正遵守项目规范。从每种意义上说，项目规范并没有给项目带来帮助；对于整个技术方案却一波三折，从最初的基于 J2EE 的整体技术方案到 .net 的整体技术方案再到基于 J2EE 的整体技术方案。增加了基于技术架构的项目整体迁移的风险、提高了项目的各项成本、从根本上打乱了整个项目的计划和对进度的控制。

2002 年 10 月制定项目计划，目标年底系统试运行。在后期的项目开发和计划安排中发现：由于以前从来没有从事过教育行业软件的开发，也没有相关的业务经历和经验，对计划的安排过于理想化。没有考虑到教育行业的特殊性。对于制定的项目计划从总体上讲，是不成功的，在 2003 年 1 月，对计划进行了调整。当然，其不成功的原因是多方面的，也是很复杂的。不能简单的归于计划的制定者，有些也不是他能够预料到和控制到的。

2002 年 11 月－ 2003 年 2 月基于 J2ee 架构下的编码。 在项目编码阶段，整体情况是比较好的。计划也能够受到比较好的执行和控制。但是，由于采用一般项目的开发模式，对后期的维护考虑不够，在 2003 年 2 月提出了采用平台 ( 本公司研发的集成系统 ) 的基于 .Net 的开发方式。对于平台，我有必要解释一下 : 平台是在 ** 项目中成长，从一个原型开始到一个目前较为成熟的平台的，它包含了客户端的开发工具以及对应的服务器端的处理规范。

2003 年 3 月－ 2003 年 6 月采用 .Net 架构 ( 开始使用平台 ) 。为了方便用户在系统运行后，能够独立进行系统的维护和开发。方便公司在以后的项目中能够利用现有资源进行快速开发，开始使用平台进行开发。由于平台不太完善，有很多功能在初期不能实现。同时平台本身隐含有很多的 bug 。可以想象，使用一个不成熟和不稳定的平台工具来进行项目的开发，给整个工程项目的实施会带来多么大的压力。由于采用 .Net 架构和使用平台工具进行开发。对于 2002 年 11 月－ 2003 年 2 月基于 J2ee 架构下的编码工作基本需要重复一遍。可以想象一下增加的工作量有多少 ( 在很长一段时间内，大家都要加班到凌晨 2 － 3 点，虽然有点苦，但是大家很开心，也许那时候的我们都很年轻无忧吧。有时候我很怀念的 ) 。到 2003 年 6 月底，基于 .net 版本的系统开发完毕

2003 年 7 月－ 2003 年 8 月平台技术从 .Net 迁移到 J2EE 。 经过 2003 年 3 月－ 2003 年 6 月的开发，项目基本开发完成。由于 ** 大学校园信息化系统使用了 SuN 公司的 F15K 和 6800 大型机器，同时采用了 Sorlaris 的操作系统。 ** 用户方在系统正式试运行前为了满足跨平台的要求，提出了将现有系统整体迁移到 J2EE 技术架构下实现。为此， 2003 年的暑假期间，首先对平台进行了技术迁移。到 2003 年 8 月底，平台技术从 .Net 迁移到 J2EE 基本完成。由于平台的技术发生了改变，想对应的项目系统也需要进行技术的迁移。

2003 年 9 月基于 J2EE 的版本系统迁移和开发完毕。 由于平台技术在暑期发生了改变，系统从平台技术迁移完毕后，开始了技术的迁移工作。到 2003 年 9 月底，基于 J2EE 的版本系统迁移和开发完毕。

2003 年 10 月－至今系统推广。基于一般项目的认识，在项目开发完成后，一般首先进行试点运行，试点运行成功后，交由客户方使用。对于系统的推广是由客户方负责开发方配合来完成的。开发方仅仅对运行过程出现的一些系统问题做处理 ( 售后服务 ) 。

由于 ** 项目的特殊性，同时也有公司高层的特殊考量。在 ** 项目开发完成后，系统的推广使用工作却由项目团队来承担。从正常得项目角度来说，我认为这是不合理的

前面我也提过，在需求调研阶段，对需求的调研和把握无论是广度还是深度都是很不够的。在项目团队进行推广时，用户和项目组发现与实际的工作需要有很大的出入 ( 用户业务已经发生变更、用户提出添加新的功能、用户认为当初的需求还不够详细 ) 。提出了一系列的修改建议和要求。对模块推广使用前的准备工作量带来了极大的增加。

在系统推广之初，由于系统 (URP) 是个新事物和新概念，用户对系统 (URP) 这个新事物和新概念的认识水平普遍不高，不知道系统 (URP) 为何物，绝大多数教师、学生不知道对他们有什么好处，部分部门甚至有抵触情绪。这给系统在初期的推广工作带来的一定的被动。说明我们在系统推广上的宣传工作做得还不够，同时也说明新概念要被广大师生接受，需要一个过程，需要用户意识的逐步培养。

对于系统中任何一个模块的推广，都需要用户的配合和支持，由于部分最终用户参与力度严重不足， 导致推广工作量极大，但效果不理想，形成恶性循环。

在进行模块推广时，都需要与用户进行若干次的沟通，每次沟通后都会有一系列的新的需求变更。对于比较重要或者是涉及面比较广的模块，需要安排培训，准备培训数据和相关资料等。每一个推广完成的模块，在推广阶段都需要修改或者是重新开发若干次 ( 一般在 5 － 6 次，有的更多 ) ，每一次都需要经过修改、测试，发布等，所提出的需求变更有几十个条目。经常为了推广一个模块，需要给此模块额外开发一些不在原需求中的，但却是推广和使用此业务模块需要的一些辅佐功能模块。无形中给系统添加了更多推广成本。一般来说，推广一个模块 ( 从修改、测试、发布、培训等 ) 需要 1 人 / 月甚至更长的时间。特别的是，一个模块推广完成后，如果用户有新的需要，仍然可以提出要求。由于前期的需求和对用户的控制把握严重不够，导致推广一个模块的代价及其巨大。

由于项目没有一个明确的需求和范围的定义。初期的需求和范围的定义到项目的推广阶段已经不复存在。导致对项目的进度完全的失去了控制。同时也标志整个项目进入了没有结束标志的无底黑洞。终于在 2005 年初，开发方和用户方都认识到有必要对项目的范围进行定义，对项目的无礼需求进行控制。此时，项目的转机出现了，才有了今天的项目验收。

 

《二》团队问题

任何一个项目的成功和失败，与项目团队息息相关。 ** 项目也不例外。

1 、人员配备不合理，始终缺少相应的角色 ( 系统架构师、 UI 设计人员等 )

2 、人员流动过于频繁，始终在培训、适应、了解，到该发力的时候，又走了。 ( 在我离开之前，初步统计了一下， ** 项目一共换了 7 任项目经理；前后参与项目开发的人数有 70 多人，如果算上实习和公司高级管理人员，应该有近 100 人了吧，而最后留下的只有极少数人员。 )

3 、项目组长期出差，成员压力过大，又没有相应的制度进行补偿，让项目组成员感觉得不偿失，缺乏吸引力和凝聚力。更没有有效的激励、约束机制。 ( 我从进入公司后，就一直被派到上海进入此项目，直到我离开，在此期间我在公司的总时间应该不会超过 6 个月，基本上是学校放假了才回公司待一段时间。 )

《三》结束语

虽然 ** 项目有这样那样的问题，它对我的影响是巨大的。

首先 : 它是我第一个接触到的比较大型的一个项目，用到的技术、涉及到的部门和人员、系统的关系复杂程度等都是比较大的；

其次：在 ** 项目的整个过程中，我从一个最底层的开发人员，成长成一个项目骨干，并且在项目的后期担任了项目的管理工作。负责了项目的验收和后期的维护等；

再次：在 ** 项目中遇到的一些问题，对于以后我在做项目和带项目的过程中的作用是不可估量的；

最后：我还是要说声谢谢。因为如果没有在 ** 项目的一些经历，我不可能有如此的成长，我也不可能有今天的发展和成绩。在 ** 项目上，项目虽然可以说是不怎么成功的，但是它却成就了一批人，当然包括了我在内。

对于我来说，也许以后再也没有这样的机会了。

                                                                                                                                                          2005年于上海