CMMI常见提问（二）

Question：当完成需求评审以后做什么？

Answer：评审后的需求文档（一般称：需求规格书），是作为工程和管理的基线（基础）。

1、在《需求规格书》评审通过后，需求跟踪责任人应创建【需求跟踪矩阵】(RTM)，RTM作为一个独立的文档来用于跟踪、维护客户的需求是否在设计、编码、测试等阶段是否被正确地实现。 每个需求都会贯穿生命周期地被跟踪直到完成。

2、《需求规格书》评审、修改和验证后，作为配置项应纳入基线库受控，此过程称为基线化。
CMO在需求基线化、纳入基线库后，应发布“配置状态报告”，让所有受影响的组或个人都收到基线化的需求。

3、当基线化后的需求规格发生变更时，CMO需要重新发布“配置状态报告”，将变更说明、和变更后的需求给所有受影响的组和个人。

Question：如何使用【RTM需求跟踪矩阵】跟踪需求？

Answer：RTM--Requirement Track Matrix ,【需求跟踪矩阵】用以跟踪需求到设计、设计到编码、编码到测试的映射过程。项目组可以根据实际情况裁剪模板的格式来满足项目的要求。

更新矩阵最简单的方式是在相关阶段评审结束后更新它。

《需求跟踪矩阵》需要遵循的检查和步骤：
1、浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏。通过对需求编号进行排序，然后对照检查需求数目是否与需求文档中的数目一致，可以很容易地达到这个目标。

2、为确保在矩阵中列出的所有程序在最终的软件中都是必要的，并且没有冗余的代码，必须在矩阵中指出每个程序、类和其他单元。

3、通过确保功能需求没有空白列来检查需求的实现。对其他需求，如果设计和程序域是空白的，需要仔细检查和验证这些需求对程序有没有直接的影响。

4、对每个性能需求，都应该设计一些测试用例。使用矩阵，可以很容易地检查测试用例是否适合检测这项性能需求。

5、集成和系统测试用例可以和矩阵一起进行交*检查，以此来保证需求的所有条件都包含在系统测试用例中。

Question：需求变更怎样控制？

Answer：1、当对已基线化的需求变更时，由变更申请人填写《需求变更申请表》对工作量、相关模块等进行评估后，提交给CMO发起变更申请；

2、项目经理组织SCCB对变更请求进行评审，如果评审通过，则修改相应的需求规格、相关的设计或编码等工作产品；

3、修改后的工作产品重新提交CMO更新基线，CMO发布“配置状态报告”，确保将最新的需求变更信息、和相关工作产品发布给相关受影响的人员。

Question：需求管理我们都度量那些数据？

Answer：如下：
1、 RTM统计需求实现数、未实现数、实现百分比；

2、需求管理阶段所花费的工作量；

3、需求文档评审时识别的缺陷数，缺陷密度；

4、缺陷密度＝评审发现的缺陷数÷需求文档的总页数

5、处理变更请求的总数。

6、变更需求的返工的工作量；

Question：为什么做同行评审？

Answer：同行评审Peer review

同行评审旨在及早地发现工作产品中的缺陷，并去除缺陷。

同时可以提高对工作产品的了解,以期获得高质量的产品。

降低开发成本，提高系统质量。

Question：项目中哪些工作产品需要经过同行评审？
Answer：项目工作过程中，有以下的相关对象，需要做同行评审：

1、售前：合同、项目建议书、答标书等；

2、开发/实施：各种计划、需求规格、规范、设计规格、代码、测试用例、测试报告、用户文档等；

3、售后：升级需求、修改设计、修改的代码、测试用例、版本升级说明书等；

项目中将要经过同行评审的工作产品以及采用的同行评审方式在制定《PDSP--项目定义的软件过程》时

做出选择。注意：《PDSP》是在项目售前实施完成后才启动的，因此《PDSP》只定义“开发/实施”阶段哪

些东西需要同行评审。如果项目组采用OSSP中的同行评审或四眼评审以外的评审方式，请在PDSP中阐述清

楚，并经过SEPG审批；适当时，项目组采用的评审方式将被纳入OSSP，进一步在公司范围内推广。