Bugzilla安装。以上这些模块都是我已经安装过的，使用正常。如果希望手动安装，来这里获取这些perl模块。Linux下安装可以参考IBM  devWork上的这篇文章，windows下安装，参考bugzilla.org上的这篇文章。如果还有问题，可以再讨论。

    Bugzilla使用。参考ycw专栏上的Bugzilla简明使用手则。更详细的请参考 王晓昕 梁太平 整理的《BUGZILLA的使用》。开发人员和测试人员（或QA）的使用，只需要作一个简单的学习，Bugzilla权限管理和定制则需要一个摸透Bugzilla的管理员。以上两篇已经讲述得很完全，这里不再赘述。

    Bugzilla扩展。这里所说的扩展，是根据获取实验数据的需要，即统计Bug opened/closed的个数和平均停留时间，这些都是评价一个项目好坏的依据。这里应验了之前提到的选用bugzilla的原因：以mysql数据库作为接口进行编程，你想用什么语言都行。Bugzilla把所有的bug和bug的每一次状态变换都完整的记录在数据中，我用Java编写了程序，不间断地运行在Linux服务器上，每天定时计算和收集以上三类数据，并自动保存到一个电子表格csv文件；这完全是一个自动化的过程，节省我们不少的人工时间和精力。另外，尚有问题等待解决，首要就是对于Reopened的Bug，两次状态变换之间的时间需要去除，不然停留时间不仅仅是误差，而是重大缺陷，会严重影响平均停留时间的大小。

    3、变更控制 

    需求变更被列为项目经历最头痛的事情之一。接受需求可谓是项目开始的标志，需求的改变直接影响整个开发过程。RUP的思想说明，需求也是一个迭代发展的过程。由此，最头痛其实不应该是不可避免的变更，而是变更管理的无序。

    需求变更管理的理论，已经研究得很成熟。主要包含如下内容：

    a.建立需求基线，控制变更范围。需求的基线是指是否容许需求变更的分界线。

    b.制定变更控制流程，从变更申请、评审到最后应用的一个完整流程。

    c.成立变更控制委员会（CCB），负责裁定接受哪些变更。

    关于变更的管理远不止这么简单，我想今后还应该花些时间在研究非常好的的管理方案这方面。

    至于CCB，曾经参与的一个银行个人信用评估系统，人员是这么设置的：项目Leader、需求分析人员、配置管理人员、开发组人员、测试或QA人员，人员各一；可以参考讨论，对于一个小型项目组，可能一个人会身兼数职。

    变更控制流程图，如下：（出自一个RUP的doc）。还有一个更简单明了的，参见《软件开发项目需求变更的管理》。
    
 

    很不幸，我们这次实验（两个小组独立开发同一个实际项目，分别采用传统开发流程和TDD）依然没有很好地控制变更。虽然两个组共享了一个额外的人来集中管理需求的变更，而且需求变更很少，最后还是出现了小规模的混乱，比如说需求文档和界面说明文档版本的不一致。

    能有一个实用的工具来辅助变更控制，自然最好不过，可惜我在这方面的经验尚不能提供很好的帮助。初步的调查，也未能找出很好开源或者商用的工具能马上应用。

    Hansky Butterfly是一套流程管理系统，提供了一整套支持软件开发过程的变更管理流程。同Hansky其它一样，都是收费的，下载了一个试用版，还没来得及使用。“Butterfly预置了“软件变更管理”解决方案，帮助企业管理软件项目开发过程中无处不在的变更。”商用的产品应该还是比较成熟的。