论信息系统项目计划管理

摘要

本文讨论了一个作者参与的软件项目的项目计划制订的若干问题．项目所开发的产品是一种智能电子教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，并可以保存、编辑、打印用户输入的数据，联网的计算机也可以实时观看用户的书写过程，并且用户还可以通过投影在硬件端的PC机画面交互操作PC机．

作者是该项目的软件开发组负责人兼软件架构师．作者针对项目计划的制定采取了：分而治之，逐步求精，经验数据三个主要策略，从而得到较好的效果．

正文

2002年6月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容，联网的计算机也可以实时观看用户的书写过程．另外，用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机．作者有幸全程参与该项目的开发，并且担任了项目PC机软件开发组的负责人兼软件构架师的角色．对于这种实时通信且具有联网功能的软件项目，本人认为首先需要制定一个良好的项目计划，才可以保证项目开发的成功．

总结这次项目的经验，本人认为行之有效的策略有三个，分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。

一、分而治之

将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀，这种方法人类已经采用了几千年．这里本人们也可以用于项目计划的制定．因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力．为了解决这个问题，可以将整个项目分解为一些更小的组织体，逐一进行处理，这项工作也就是项目管理中的WBS（工作分解结构）。

比如针对这次项目中采取的RUP开发过程模型，本人在完成需求管理计划时本人就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定，最后合到一块儿就是完整的需求管理计划．

除了按时间段分解的角度来制定项目计划，本人制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作，根据每个工作流在四个阶段业界通用的工作量估计来制定计划，安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流，本人认为以这种方式分解是合理的．同时因为本项目的特点，本人省略了业务建模工作流，这是因为这次的产品是以硬件为主，软件为辅的消费类产品，所以业务建模不是那么必要了．以不同的方式分解项目，可以从多个不同的角度来制定整个项目计划，有利于全面、深入地了解项目，避免“瞎子摸象”的情况发生．

二、逐步求精

计划工作其实是一种管理未来、管理未知的工作，而未来是变化莫测的，还存在许多自身无法掌握的因素，因此存在很大的难度．而解决这一困难的法宝就是逐步求精．按照先框架后细节，先粗后细地进行项目的计划．

比如在这个项目中，在接受这个项目后就开始了做了一个初步计划，这个计划的内容主要是做出时间上的安排．因为打算在2003年的月需要用这个项目的产品申请国家中小企业创新基金的支持，所以完成时间就定在了2003年4月，预留一个月用于写申请报告．总的时间进度确定后，大概分配了三个时间段：系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结．

等到确定这改项目后的RUP 开发模型后，就可以继续对项目计划进行第二改求精了。其实RUP 过程中出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项目计划的制品．这样本人就可以在这个两个阶段对项目计划逐步求精，比如在初始阶段只是将本人需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划，然后在细化阶段本人再具体地制定每类计划的详细内容．

比如在初始阶段时架构设计考虑以MFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架构设计进一步详细，这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义，这时本人就可以根据所需开发的模块制定计划。比如这时本人就计划了特效界面模块开发分两次迭代，第一次迭代计划一个月时间，第二次迭代两周时间，第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果，第二次迭代的主要任务是根据用户反馈进行修改调整．

三、经验数据

要制定一个良好的计划离不开精确的估算．不过项目计划是在项目开发的早期制定的，而在早期要完成精确的估算是非常困难的．要解决这个问题的关键就在于“经验数据”．由于整个软件产业都还十分年轻，经验数据的积累都普遍不足，才导致这一现象的出现．

但是因为这次项目开发的产品在国内还没有开发过，再加上公司没有积累深厚系统的项目历史数据．针对面临的困难，本人选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了．在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，本人利用软件工程书籍中的“逆火”经验数据，将LOC转换为功能点单位，当然，这里必然导致一些误差。为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整．

Delphi方法是一种集策法，也就是通过多名专家对估计值的不断校正的方法．当然，请专家增加了项目成本，不过最后得到高质量的项目计划还是值得的．比如，在某专家的建议下本人们改变了自行开发网络层组件的计划，而是采购现有的完全可以解决项目需求的成熟的中间件产品，这个策略的调整在后来证明是正确的．一开始犯错误的原因是由于本人们网络开发经验不足把用户需求想复杂了．

最后谈一下使用的工具软件．在制定项目计划过程中本人采用了Microsoft的Project 2003绘制甘特图．因为项目的进度安排是和项目中每个人都是息息相关的，所以在做甘特图前本人首先征集了大家对文字和条形图效果的意见，然后按大家的意见进行了美化，比如用鲜艳的颜色标识关键任务，放大任务摘要信息，突出里程碑信息等．这在有些项目管理者看来似乎是小事，不过本人认为一个赏心悦目的甘特图可以带给观看者好的心情，而好的心情可以大大提高工作效率。

同时，考虑创新基金支持的项目在交互期限上有很大压力，所以在定义甘特图任务的依赖关系时本人采取了业界惯用的“时间盒”的技术，也就是在每个任务的任务信息对话框中“前置任务”一栏中的“延隔时间”本人填入5%-15%，也就是说当任务完成90%左右时就可以结束转而执行下一个任务．因为本项目中的所有人员几乎是全程参与，所以本人不是很担心每个任务遗留的少量问题在下一阶段没有负责人去解诀。

配合Project 2003使用的估算软件是Software Productivity Research的KnowledgePlan.这款工具软件的最新版加强了对Microsoft Project 2003以及RUP开发模型的支持，而且其中的Project Template功能允许用户采用自己定制的WBS来进行估算，这些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助．

在上述三个策略的指导下，以及合适工具的辅助下，使最后形成的计划有效地指导了后期的开发活动。项目开发出来的产品通过了专家的鉴定，获得了国家中小企业创新基金的支持．

项目完成后发现的问题是早期计划的估算结论偏差还是较大，看来还是受到缺乏经验数据或者经验数据不够精确的影响，所以在以后的工作中需要开展有效的度量的工作，为公司积累覆盖面广且尽量精确的经验数据．