项目说事——信不信反正我信了（合作开发总结之文档）

   信不信反正我信了。这句话让我很无耐啊，是啊经历过合作开发的程序猿应该都有着同感——无耐。项目开发应该是件高兴的事，挣钱嘛、工作经验啊谁不高兴，可是问题又来了，以前只是个人开发项目啊，文档好歹写写，图好歹画画，自己能看懂就得了，最主要是软件赶快写代码，把软件设计完成就可以万事大吉了。饿，想的倒美，项目开发哪有那么简单，每个环节都要精雕细琢，因为现在是合作开发，不是你个人的项目，要知道你好坏谁管啊，最主要是你这个枢纽，中间环节一定要做好，上有项目经理下有软件代码，你要兼顾哪个？

   有人跳出来说了，那当然是项目经理喽，项目经理和小菜的命运息息相关，要多和项目经理交流交流，让他给我分个轻点的活，这样项目开发起来简单小菜负责的那部分也能漂亮的完成。饿，典型的小人形象。要知道合作开发哪一部分的内容都不简单啊，想要偷懒还不如退出项目组。可恶，为了能得到工作经验，当然更要为了小菜的Money，要硬着头皮上了。

一、可行性分析

   开始要对软件做需求分析，啊？你把可行性分析放到哪儿去做啦，要做完软件在写吗，要不你试试吧，软件开发完后再写可行性文档。有你这么做的吗，开发完后在编写可行性文档，有木有啊，软件做完了再给客户一个可行性文档，说这个软件确实可行，瞧我们已经开发出来啦，您要不用用看看。噗，我喷出来了，喝的水喷出来啦。当然不能这么写啦，软件开发伊始就应该进行可行性分析，生成可行性分析文档，虽然这个文档在现在的开发过程中可以不写，但是对于真正项目开发的文档来说，他并不是不写，只是这部分内容可能集成到其它文档内了，另一方面对于现阶段的我们来说这部分的文档也不是程序猿该考虑的事，这部分文档应该属于公司上层领导编写，至少也应该是项目经理的级别。当然对于我们这种需求已经很明确的小项目来说，这个文档就可以不用写了，直接跳到需求分析吧。

二、需求分析

   到了需求分析，小菜摸摸大脑心想需求分析我写过没有啊，似乎好像确实写过（有木有啊这么多形容词），最后拍拍脑门，啊，这个要写（这个真要写）。就算是需求已经很明确的软件，我们也要写，因为这个文档更是桥梁作用，上连接着客户（那是上帝啊）、老板，下兼顾着设计人员、编码人员，这部分文档一定要写好啊。于是之旗帜飘扬，信心满满、敲着锣打着鼓的编写起来了。这边描述、描述软件的功能，那边说说软件设备的支持，接口的定义，中间再说说用户的特点，描述描述软件的一些特性，输入输出的要求，就差不多了吧。似乎好像又很简单的样子啊，恩，是的啊。这部分说简单也简单，说难也很难。最主要是要把软件描述清楚，客户看到文档就知道软件是不是符合自己的要求，是否拥有自己想要的功能，这部分最好也能够把系统的数据结构描述一番，建立数据库的物理模型以便能在以后环节中设计出完美的数据库。啊，当然了，如果这部分写详细了，那么下面的概要设计说明书就很简单了。

   说和做是两码事，需求分析文档在悄无声息中写完了，经过验证小菜写的需求文档还是有说服力的，老板看了后说，恩，写的不错，拿着去让客户看下，看看软件是否符合他们的要求。说完后，小菜顿时精神气爽，全身充满了力量，小菜明白这是老板对小菜的无比信任。人逢喜事精神爽啊，下班时小菜一路哼着小曲一路狂奔到家，等到了家后摸摸自己的口袋，差点没哭出来，有木有啊房屋钥匙没带。

   为了赶快完成上级交代给的任务，小菜第二天就拿着文档去找客户，客户看到了文档后高兴的拍拍小菜的肩膀说，恩，不错我要的就是这个东西，赶快做吧我们着急用。得到客户的认可后，小菜第一时间报告给了上司，说客户对需求很满意，我们连夜加班还是值得的。老板听后笑了笑，“色眯眯”的对小菜说，好的小菜，去做吧，要快哦客户着急用呢。小菜听到后是神清气爽，顿时感觉无比的清爽，但心里似乎又有点沉重，又有一座大山压在了小菜的背上啊（上面的故事纯属虚构，使用需求文档和客户沟通时会有很多问题，上面只是为了总结需要，不涉及到故事情节）。

三、概要设计

   要写概要设计说明书了，小菜拍拍自己的脑瓜说，这个还写不写啊，需求已经很明确了，各阶段的设计也很清晰，要不就不用写了？为什么我顿时有种想揍小菜的感觉，不要偷懒好不好，概要设计当然要写啦，需求虽然明确，但是概要设计的内容和需求分析是不一样的。概要设计主要是规划整个系统的总体组成结构、子系统或模块边界、协作方式、数据分布、部署模型等内容，把系统简单化，对系统的内部结构及外部结构进行分析，设计出数据模型，架设好数据库系统，可以说它在需求文档上更进一步对系统进行了描述，设计出系统主要的包图结构，数据要求，数据结构。这部分的文档读者广泛系统架构师、系统编码人员等都有可能会看这部分内容。可以说概要设计文档是连接具体（客户对系统的描述）和抽象（系统本身）的一座桥梁。哦，好吧，小菜决定写啦。

   对于概要设计文档小菜知道的还不是很多，不过经过小菜爬山涉水、翻山越岭这番折腾后，概要设计文档还是很圆满的写完了（这中间的细节就不细说了，概要设计的基本要求上面已经有说明）。写完了概要设计小菜终于舒了一口气，不过要想休息还早着呢。概要设计完了要编写详细设计，这时候才是真正考验小菜的时候，小菜挠挠脑袋说，好吧。

四、详细设计

   又一座大山压在了小菜身上，这次这座大山不比从前，这次要把整个软件描述一遍啊，我的天，现在小菜对这个软件的设计还没有清醒的认识，以前的文档不需要太多的专业知识，按照规范格式写就没问题啊，现在肿么去写啊，更何况小菜以前就写过代码，没有画过流程图，没有研究过算法，更不懂怎么使用UML了，从哪里下手。啊，小菜幡然悔悟……我还是不当项目经理啦，乖乖的做我的程序猿吧。

   哎，小菜啊小菜，这次山穷水尽了吧，谁让你以前不好好学来着，现在知道文档难写了吧。还是我来告诉你详细说明文档书写规范吧，详细说明文档在概要设计基础上更进一步，首先要阐明系统的总体设计，给出软件系统的结构图，对类图进行详细说明；其次并对程序进行详细的描述，这部分最好逐个模块给出有关系统的功能、性能、输入和输出，并详细说明模块所用的算法，内部结构有了，还要对程序逻辑进行详细的描述，详细描述模块实现的算法，可采用：标准流程图；PDL语言；N-S图；判定表等描述算法的图表。当然还要考虑接口及后期的测试要点，要知道哪有这么容易编写啊。

五、幡然悔悟

   小菜最后决定了，归隐山林做一个程序猿，但是好事似乎一直都和他无缘，信不信反正我信了，他不去惹事，但是坏事总是去招惹他。

（以上故事纯属虚构，因为在合作开发中看到大多数人用几天时间就完成了前期几个文档的编写，虽然是编写完成了，但是在以后的开发中却遇到了很多问题，对于这种现象小小的吐下槽，并以一种幽默的方式来说下项目中前期几个文档编写的规范和要求，对合作开发中的文档编写进行回顾。）