本人从事软件这个行业将近八年，虽然没有练就过硬的编程功底，也没有成长为一名合格的系统分析师，但是毕竟我一直把这个行业当成我的一项兴趣爱好，而不仅是个谋生的手段，所以不停的总结，不停的进步，也是我的生活乐趣之一。

最近我们部门正在紧锣密鼓地进行着一个热线老版本的升级改造。因为原来的主程序是用VB写的，现在要改用DotNet开发，所以从代码角度来说几乎是所有程序全部重新开发了。而且项目工期也非常紧张，留给我们的时间也仅够我们做语言迁移（即：用DotNet语言实现原来系统的所有功能，不考虑系统构架的完善，也不考虑系统的可扩充性，更不考虑对原来系统的弊端进行根本性的修正）。当然，语言迁移只是我们对热线第一个版本的目标，我们将在2.0版本中考虑以上的问题。

现在，我就以这个系统为背景，站在一个系统分析师的角度来谈一点我的体会。

1：要重视对原型系统的开发

         开发原型系统的必要性我这就不多说了，随意翻开一本软件工程的书，上面或多或少都有描述。我要说的是，当在软件开发初期，客户提出要来看看我们的软件设计的怎么样了，我们拿什么给人家看。一：给客户演示一下还满是Bug错误框的软件。二：给客户放一段我们精心制作的PPT.三：当场运行已经经过美化的原型程序。

方法一肯定不可取，因为会给客户留下一个非常不好的印象，认为我们前期的工作没有做好。方法二只能看到死的图片，客户往往只能提出界面上的一些美化问题，而不能深入到系统设计内部。方法三解决了以上的问题。所以，如果我们的市场人员和领导拿着原型系统给客户汇报工作情况，效果将是最好的。因为我们已经非常清楚地告诉客户，你们要的咚咚就是这个样子的，如果你们有哪些地方不满意，现在就提出来。毕竟在项目初期做修改的成本比较低。

同时原型系统也是我们的试验田。对于一些功能，我们可以先在原型系统中搭建，确认没有问题了，再移植到产品中去。这种方法至少有以下两个好处：一：因为原型的功能比较纯粹简单，调试和修改BUG的效率都比产品要高。二：能保证加入到产品中的功能都是经过测试的。加快的产品开发的成熟度。

2：如何来开发这个原型

         原型系统一定要早于产品进行开发。原型系统应该涵盖了我们要开发的所有界面，这里清大家注意，我用的是界面二字。而不是功能。如果我们前期的需求分析，系统分析由于时间原因或者能力问题没有很好地去做，在系统设计阶段不能生产出一个高质量的详细设计报告，那么开发这个原型多少能够弥补一点损失。

         设计这个原型不需要深入到复杂的逻辑中去，有时几个界面和几个界面提示就足可以达到原型的设计目的了。没有必要在原型中加入具体的功能。甚至有些界面可以通过贴图的方式来完成。只要保证这个原型可以运行，就可以随时演示给客户看。

3：如何向客户特别是客户领导介绍我们的系统

         当市场人员或公司领导向客户或者客户领导描述我们的系统的时候，往往会用以下的话语：我们的系统实现了这个功能，实现了那个功能。我认为功能一词还是太过专业和抽象。很多客户有时会搞不清楚我们实现这个功能到底有什么用。所以我认为我们应该这样来介绍我们的软件系统：我们的程序帮您解决了这个问题，也帮您解决了那个问题。请大家比较一下两句话“我们的系统实现了实时自动统计话务的功能”。 “我们的系统解决了您原来不能看到当天话务数据的问题”。我相信后面那句话对于客户领导而言更通俗易懂。

4：开发的初期最好只有核心的优秀的程序员参与。避免一拥而上的开发模式。

         Brooks博士在他的《人月神话》书中阐述了这样一个观点：需要协作沟通的人员数量影响着开发成本。因为成本的主要组成部分是相互的沟通和交流，以及更正沟通和交流不当所引起的不良结果。所以我认为如果在开发初期，就投入大量的人力一拥而上的开发方法是高成本的，速度缓慢的，低效的。

         下面我通过一个不是很恰当的例子来阐述这个问题。

如果我们要建造一个软件园，里面有很多各式各样的楼房。我们可以这样来开始建设这个项目：优秀的建筑师负责高楼大厦的建设。较差的建筑师负责小房子的建设。根据能力好坏分配难易程度不同的工作，这似乎很合理。但是各个楼房之间并不是孤立存在的，得要建设各种走廊来连通这些楼宇，这时候，这些效率高的效率低的建筑师就要一一互相讨论这些走廊的建设问题。如果有五栋楼房，那么就要建设 5*4/2 ＝ 10 个走廊，也就是说每个建筑师要和其他的四个建筑师共沟通四次。加上能力的高低，理解力水平的不同，沟通的成本非常高。因为大家都各自建造楼宇，所以如果沟通失败，最坏的结果就是中间的走廊根本就不能走人。

         怎么办？也许我们可以换一种分配任务的方式。项目初期，只有两三个人甚至一个人参与。这些人都是项目的骨干，可以说是经验非常丰富的建筑师。他们共同讨论出建设方案，包括走廊怎么设计，由于人少，沟通的成本将大大降低。此时就靠这两三个人来建造这个软件园的水泥框架。因为人数少，沟通充分，这些框架的风格非常统一，而且接口也非常的一致。而且不用考虑建筑的细节的问题，框架可以在非常短的时间内搭建完毕。接下来那些能力相对较差的建筑师进场。他们的任务就是负责把一块块砖头填到框架中去。同时那些能力相对较差的建筑师之间并不需要很多的沟通，因为他们的任务是互相独立的，最多也只需要向设计框架的人询问一下该用什么砖的问题。

         这种分步骤的实施方法，把程序员之间的交流成本降到最低。也就是降低了项目失败的风险系数。