项目文档知多少（二）

 十、《uml设计说明》

   这个文档不常用，我一般会在两种情况下要求项目做业务模型设计：

1、 业务相当复杂的时候。

         功能规格书更多的是从模块界面，操作方式上去阐述模块的功能，至于底层的数据模型还得用uml图来辅助说明。uml图有很多种，我们一般也只常用几种，包括：用例图，类图，时序图，其中类图又最为重要。

2、 对原有系统进行重构的时候。

         原有系统由于种种原因〔业务了解不透，工期紧张，人员能力不具备〕在做开发之前没有对复杂的业务进行模型设计，开发出来的系统虽然能用，但漏洞百出，开发人员时常处于救火的状态。随着时间推移，开发人员对业务有了更深入的了解，慢慢的不满足在现有的代码基础上修补，产生了强烈的重构的愿望。就这样，再作第二个类似系统的时候，很自然的就操起uml工具对现有的代码进行重构。

    有很多的朋友不理解为什么要建模，直接用代码说话不是更好么？我举个项目中的例子：我曾经带队实施过一个有2000人企业的信息管理系统，有14个子系统，600来个功能模块。其中有一个物资子系统，做过类似项目的朋友应该知道，物资子系统流程复杂还要嵌套〔大流程中嵌套小流程〕，模块众多。刚开始没有进行业务建模，功能规格书设计完毕后，直接数据库设计报告，然后上手编码。整个子系统设计花了2人月，编码用了4人月。等进入到测试阶段后，bug满天飞，真是按下葫芦起来瓢，原定与1个月的稳定期最后又延迟了1个月才总算表面上稳定下来。在客户那里上线后，需求一旦发生变更，开发人员就心惊胆颤，生怕出现牵一发而动全身。究其根本原因就是在面对如此复杂的业务系统面前，没有用建模的手段将业务逻辑的全局勾勒出来，每个人只关注自己的一块，导致数据的交互出了很多的问题。最后，在项目总结会上，大家一致认为下一个物资系统，要想办法从根本上解决这些问题。结果，下一个物资系统，我们做了充分的设计，用uml对业务建模，使每个开发人员既能清晰的看到业务的整体轮廓，又能深入细致的了解到每个类之间的交互以及提供的接口。这样开发出来的系统才有底气，面对客户的需求变更我们也能知道动哪个位置、影响到哪个地方，做到心中有数。

         所以，在以后的项目里，只要是碰见业务复杂的系统，都会要求进行建模。多花些功夫在前面，后面肯才不会被拖累。

十一、《项目开发进度报告》

    这份文档由项目经理编制，作为项目的定期〔一周一份〕文档提交给公司领导审阅。文档主要包括以下几方面的内容：

  1、总体开发进度
  2、现场实施进度
  3、项目组现有人员
  4、本周工作完成情况
  5、下周的工作计划
  6、项目存在的问题及解决方案
  7、需要协调的资源
  8、功能特性变更说明
  9、重大缺陷列表
有数字，有比例，有详情，能让领导快速的掌握项目目前的进展。

    我做开发部经理时，部门经常会同时开展多个项目。我要求每周五上午，每个项目经理在11点之前向我提交《项目进度报告》。我会在11点到12点这一个小时内去浏览这些进度报告，从中发现问题。下午两点准时召开周项目会议，人员不要太多，由每个项目组长及测试部所有人员〔测试开发比例是1:5〕参加。会议的主要目的其一是让各小组之间对所有的项目进展都相互有所了解，便于资源的调配。其二是由测试人员强调目前项目中存在的问题，对共性问题制定统一的解决方案，达到知识共享。其三，确定下周任务的重点及难点，是否需要协调其他的外部资源。

    会议时间控制在1小时内，由于事先都提交了项目进度报告，各项目组长都是带着思考来的，因此沟通比较顺畅。在会议上对需要的、属于我职责范围内的事情拍板，超出能力范围的，请示公司领导后再作决策。会议结束后，我会综合项目组长提交的进度报告的内容，同时也会附上自己的一些思考编写一份开发部本周工作情况汇报提交给公司领导审查。

十二、《项目版本说明》

    在项目进展的过程中，我们规定了一旦项目进入实际代码阶段必须执行每日构建〔每日构建是心跳〕，然后直到项目处于非活动状态为止。我们用的版本控制工具是cvs。项目组成员每日下午5点之前提交代码，5点钟开始构建代码，构建成功就给项目打上标签，并将标签的信息登记在《版本控制说明》文档里。主要记录的信息有：打标的人，打标时间，标签名称，标签类型〔普通标签，内部测试标签，客户发布标签，补丁标〕，标签说明〔该标签中新增了哪些内容，解决了哪些bug等等〕。测试部每天6点根据《版本控制说明》下最新的标签执行自动化构建，第二天早上针对昨晚构建好的系统进行测试。

    每日构建的工作由项目组长安排组员轮流构建。在项目多的情况下，由于都规定在5点钟从服务器上下载代码执行构建会导致服务器负载过大，相应较慢的现象。后来，我们做了制度上的调整不再硬性规定必须5点构建，处在活动状态的项目只要每天构建一次，有一个标签就行了。倘若6点钟某个测试人员来告诉我某个项目没有标签，那么项目组长必须有一个非常合适的理由对我解释，当日负责构建的人员会受到考核，很显然，这样的问题会导致测试人员第二天只能在旧版本上工作，测试任务无法完成，影响项目进度。

十三、《项目会议纪要》

    分内部和客户的。项目组内部开会时必须要有会议纪要，现场实施人员与客户在一起开会同样也需要会议纪要，打印出来双方各执一份，以便日后好对会议中所做的决议能有所追溯。如在会议中做了对项目影响重大的决定，还需要客户负责人签名确认。最后，临项目验收时，整理所有的会议纪要作为验收文档的一部分提交给客户。