在这里列一些工具供大家参考

　　计划工具：Microsoft Project

　　项目监督和跟踪：Microsoft Project server 2003，SharePoint

　　需求管理：Rational RequisitePro, Borland CaliberRM, SYSBASE POWERDESIGN 11

　　变更管理：Rational ClearQuest

　　Bug跟踪工具：Rational ClearQuest

　　配置管理工具：VSS, CVS, Rational Clearcase

　　一个强有力的执行和守纪律的企业文化，是推广过程改进的保证。一个过程，在试点后，是要推广的，在推广过程中一个强有力的执行力是必然的保证，这个不用多言。而对于守纪律的企业文化本来我并没有太深的感受，直到有个朋友告诉我，他们公司的印度工程师如何的刻板。我突然意识到这也许就是国内软件公司长不大的原因了。是的，严格的遵守企业定出的过程，有时是显得有些刻板。但在相当长的其他时期，也正是这种刻板，保证了公司的过程被严格执行。

　　有人说，什么标准一到中国就变了味了。这虽然不太好听，但你不得不承认，有时我们确实为了省力，为了赶工，确实在破坏公司的过程。毕竟CMM只是软件开发的过程改进的标准，但一个软件项目的成功，并不局限于软件开发。用CMM的模式去改进一些前期项目计划和后期系统实施的过程，将会对组织的软件项目的成功事倍功半。比如说采购管理，实施管理，项目启动的管理。 在这里我想就项目的启动管理着重讨论一下。因为一个一开始就没有处理好的项目，是不会有一个好的结果的。目前签软件合同，大多数的流程是由销售人员和客户接触，然后售前工程师演示程序。然后在销售人员和售前工程师的一连串的承诺中，客户签合同，软件企业得到30%的销售额作为定金。而后就是软件企业进行系统的开发了。客户只有很少可以在软件开发完成前，了解到系统到底会是什么。然后，就是实施中的对于需求的争论，软件企业修改程序。客户忍受不贴身的流程。在这当中，从项目一开始双方就没有一个清晰的共识。这对于双方都是一个隐患。软件企业可能由于后期的变更过多，项目失控。客户可能是买了一个只能完成80%需求的系统。可是若采用下列的一种过程，可能就可以解决这个问题。首先销售人员和客户接触，然后售前工程师演示程序。然后在销售人员和售前工程师的一连串的承诺中，客户签采购意向合同(只是付少部分的意向定金)，而后软件企业提交建议书(提出一个概要的解决方案以及初步的成本、时间估计)。客户若对此无异议，就进入下一个阶段-需求分析并为需求分析付费。若不满意建议书，可以直接结束项目。接着，软件企业开始对客户进行需求的详细分析，并同客户确认。若客户确认后，就再签署开发合同。此时软件企业可以比较精确的估计软件的规模、成本、时间。客户也较清晰的了解未来系统的范围、功能。在这种方式下，整个项目实际上被分成两个独立的项目——一个是进行需求分析，另一个是为满足这些需求而开发的软件。在这种情况下，在项目的第一部分完成后，就可以把需求作为基线保存，而后就是需求的变更管理。这样客户和软件企业都对系统有个清晰的共识，需求变更自然就减少了，项目也更容易控制，软件在合理的进度下质量也容易提高。