论软件项目的进度管理2-综合业务信息系统的开发

论软件项目的进度管理
摘要
2001年 10 月，我参与 x  x 市农村信用联社综合业务信息系统的开发工作，该系统面向
交易、以客户为中心、采用大会计模式，并以会计核算为核心，实现本外币合一，将柜员管
理与柜面业务有机地结合起来，以业务种类码来划分整个业务系统。该项目分为二期：第一
期为柜面业务,为期 14 个月，已于 2002 年底完成；第二期为卡业务，为期一年，尚在开发
中。
在该系统的开发中，我主要担任可行性分析、需求分析、概要设计和第一期项目的项目
管理工作。我采用 PERT 计划评审技术，标识关键任务的同时，允许一些任务并行进行；着
重考虑人员在整个项目开发过程中的安排；重视文档规范、命名规范，为减少员工之间的通
讯障碍，还启用了 Notes 系统；跟踪和控制项目计划的执行等措施，保证了项目按期完成。
但是，由于对人员流动估计不足，复用力度不够，给项目的进度管理带来了一定的困难。在
以后的项目中，我们把限制人员流动率将作为一项合同约束。
正文
2001年 10 月，我参加了 XX 市农村信用联社综合业务信息系统（以下简称 XX 系统）的
分析和开发，该系统由我联社与乙集团公司联合开发，系统采用 C/S体系结构，主机采用两
台 IBM RISC/6000  S 系列机，操作系统为 IBM 的AIX 4.3.3，数据库选用 IBM 的 DB2  UDB
6.1 ，磁盘阵列选用 IBM 的7133  SSA 串行存储体系结构，前台为 SCO  UNIX  5.0.5，中间件
采用 IBM  Txseries  CICS，编程语言采用 SQL 和 C。
XX 系统面向交易、以客户为中心、采用大会计模式，以县级联社为单位设立一个帐务
系统，改变原来的储蓄、对公等总帐分开的做法，并以会计核算为核心，把整个帐务系统融
合在一起，实现本外币合一，将柜员管理与柜面业务有机地结合起来，以业务种类码来划分
整个业务系统，打破传统的业务品种和业务部门的界限。
XX 系统分两期实现，第一期为期 14 个月，已于 2002 年年底完成并投入运行，主要完
成农村信用社柜面业务，包括储蓄（对私） 、对公、信贷、系统内电子联行、通存通兑、与
人行的天地对接、中间业务等；目前系统内共设机构 87 个，柜组 415 个，业务操作员三千
余名。第二期为期一年，尚在开发中，主要为卡业务（包括与人行的一卡通、自办农信卡业
务等）及客户自助业务（包括 ATM、电话银行、网上银行等） 。
在 XX 项目中，作为联合开发的甲方主要代表，我担任项目的可行性分析、需求分析、
概要设计和一期项目的项目管理，跨地区通存通兑接口模块的详细设计与实现等工作。
软件开发项目进度管理是软件开发项目管理的一个重要内容， 有效的进度管理是保证软
件开发项目如期完成的重要环节。在 XX 一期项目软件的开发过程中，为保证软件按时完成，
我采用 PERT 计划评审技术及一系列的方法和策略。
1、采用 PERT 计划评审技术标识关键任务
采用 PERT 计划评审技术标识关键任务。XX 项目计划中规定了一期项目的的交付期限为
2002 年年底。整个一期项目长达 14 个月。在一期项目的开发过程中，采用的是 “改进型
瀑布模型” ，我们从可行性分析结果出发，使用快速原型方法来补充和完善需求说明，还对
信贷部分的需求进一步细化。从设计阶段起的各阶段基本采用了传统的开发方法，各阶段的
结束标志比较明显。所以在软件的开发过程中，我采用了 PERT 计划评审技术对开发过程中
的各关键任务加以标识，允许关键任务以外的其他任务在机动期内伸缩。而关键任务的伸缩
不得超过一周。当遇到关键任务延期时，我召集大家寻找原因，并由主要责任人签字。把这
种责任作为业绩考核的一部分与收入挂钩。
在标识关键任务的同时, 根据 PERT 图，允许某些任务的并行。在概要设计阶完成并通
过评审后，允许各子系统在详细设计阶段及实现阶段任务上的并行进行。我把系统划分成储
蓄对公、信贷、联行三个子系统，在概要设计阶段的任务一完成，就将开发人员分成三个小
组，分别进行上述三个子系统的详细设计与实现。实现了在这两个阶段上任务的并行，也确
保了项目的如期完成。
2、着重考虑人员在整个项目开发过程中的安排
着重考虑人员在整个项目开发过程中的安排。我从各县联社抽调业务骨干，作为业务分
析人员， 提出并确认需求。 考虑到本项目完成后的维护需要， 在乙方开发人员大部分撤离后，
维护任务将主要由我社一方承担，所以从概要设计阶段开始，我方派出了三名高级程序员，
分别参与储蓄对公、信贷、联行子系统的设计，继而参与详细设计、编码实现，也为后来的
维护作准备。
3、减少开发人员之间的通讯障碍，提高生产率
减少开发人员之间的通讯障碍，提高生产率为了确保项目的如期完成，我们事先规定了
文档编写规范、命名规范，重视文档的编写、保管等工作。重视文档与设计的一致性，先修
改文档，再修改程序，不至于因为文档与设计的不一致而影响工期，对跨越里程碑的文档修
改设置严格评审。为了减少开发人员之间的通讯障碍，还启用了 Notes 系统，开发人员可以
通过内部 Mail 进行交流，及时沟通，减少误解。
4、跟踪和控制项目计划的执行
跟踪和控制项目计划的执行。为确保本项目的如期完成，在项目开始后，我们定期召开
各组长会议，让组长们报告各自小组的进展情况及遇到的问题。通过交流开发过程中遇到的
问题，共同探讨解决方法。我对照计划，跟踪实际执行情况，如果项目进展顺利，在预算范
围内，我会适当放松一些控制；但只要一有问题，我会尽可能帮助排解。例如，在编码及单
元测试时，因为时间比较紧，尤其信贷组，按揭贷款和跨社多头贷款控制的编码过程中遇到
些阻挠，测试也不够充分，加之个别人员流动，我只好调整计划，适当调整人员，还让信贷
组开发人员加班加点。有时我也找个别开发人员交谈，以了解他们对开发进展情况的评价，
以及他们个人遇到的一些问题。尽我所能帮他们解决问题。
在本项目的开发过程中，所有由于以上采取了以上的技术和方法，在很大程度上保证了
项目的如期交付（一期项目按计划已于 2002 年年底交付并投入运行） 。其中采用 PERT 计划
评审技术，标识各阶段的关键任务，允许一些任务的并行执行是比较成功的，划分的储蓄对
公、信贷、联行三个组在详细设计与编码阶段的并行执行，缩短了整个项目的开发周期。重
视文档的编写，效果也比较好，内部 Notes 的启用减少了通讯障碍，提高了生产率。安排本
系统员工的积极参与也是成功的一面， 参与过需求分析和确认测试的我方人员在系统上点过
程中对培训辅导帮助很大， 而参与概要设计起各阶段任务的三名高级程序员更为系统投入运
行后的维护提供了方便。一方面，这些人员参与了从概要设计阶段起的各个阶段，熟悉了整
个的实现过程；另一方面，这些员工熟悉业务，在后来的改正性、完善性维护方面起了很大
的作用。
但是对人员的流动把握不足，尤其对乙方人员的流动更显得无可奈何。很大程度上带走
了经验，也影响了进度。同时，也没有充分考虑到本系统内参与设计人员的流动。项目初期，
本想增加候补人员的，但考虑到那样做还得培训，同时也增加通讯、交流的时间，担心反而
会影响进度，所以未安排充分的候补人员。致使人员离去时只好再作调整，显得有些被动。
所以对于人员的流动，现已作为一项约束，限制人员流动率不得高于某个百分点而在二期的
开发合同中明确规定，相信会带来好处。
另外，在项目设计过程中未充分考虑代码的复用，复用程度比较低，三个组间复用的只
是本项目公用的如记帐部分等，还有就是各自组内的代码积蓄了。开发效率比较低，也正因
如此，不但延长了编码时间，而且还必须加强测试。如果能加大复用力度，在保证项目的进
度和系统的质量方面会更完善些。