既然软件发布记录、事件记录和工作请求记录是相互关联的，那么系统在两个方面可以做一些确认。当一个事件记录要进入 Resolved 状态时，系统核查会确保所有与这个事件相关的工作请求关闭，直到那些请求已经关闭才会允许这个记录事件记录进入 Resolved 状态。类似的一个确认是发生在当事件记录进入 Closed 状态的时候，因为质量保证小组可能创建一个新的工作请求来跟踪他们工作进度。另一个确认发生在软件发布记录即将进入 Deployed 状态的时候。允许软件发布记录进入 Deployed 状态之前，系统将确认所有相关事件的记录关闭。
为了进一步举例说明事件记录概念的重要性，下面详细介绍了一个简单的用例在 Rational Application Developer (IDE)，Rational Clearcase (SCM) 以及 Rational Clearquest （问题跟踪）中进行完全集成练习的情况。
图6. Rational Clearcase (SCM) 和 Rational Clearquest （问题跟踪）
正如上图的描述所示，事件记录是将事件概念（缺陷）、事件决议（缺陷修复）和发布跟踪联系在一起的激活器。
用例如下：
- 通过测试，一个软件缺陷已经被确定，并作为一个 ClearQuest 事件进行输入。
- 通过 ClearQuest，缺陷管理人员将这个缺陷分配给一个应用软件开发者作进一步分析。
- 开发人员分析这个缺陷，并继续对缺陷位置进行定位。他访问并调试来自 RAD IDE 的代码。
- 对话框提示开发人员将代码调试和事件记录联系起来，开发人员确定合适的事件记录，将潜在的缺陷修复和软件缺陷联系起来。
- 在缺陷位置被确定在 Clearcase 后，这个项目经理或者缺陷管理人员就可以在 Clearcase 运行报告来对进度、缺陷状况和发布进行控制。
- 部署和打包
- 新的部署任务
由这种方法产生的一个工件是软件发布日历，这个日历可被归类为 PMI 沟通管理激活器。这个简单的发布日历产品透过 Rational ClearQuest 通过查询发布记录的特定时间（天，星期，月，年），来提供一个单独的预定发布视图。其它的沟通工件包括但不仅仅局限于日志（问题，风险等等）和报告（缺陷，变更，请求等等）。
图7.日志和报告
- 确保开发团队理解发布记录的益处和集成软件工具，过程和项目管理学科的方法。
- 沟通、沟通还是沟通。发布日历是一个很有用的工具。是保证人们使用了发布数据的主要资源之一。
- 如果可能的话使用标准，不要复制标准。比如如果有一个软件发布编号方式的标准方法，那就可以使用。
- 结合现有的实体或者建立一个Governance Board for Software Tools和Processes。
- 确保你的工具管理人员有先见之明，能够理解你的业务环境和局限性
通过使用软件工具、过程和讨论的项目管理原则，软件发布经理可以：
- 有一个针对时间框架（天，星期，月，年）的单独预定发布视图。
- 追究基于管理需求和产品矩阵的相关复杂的疑问。
- 有权访问绝大多数当前的发布信息。
- 对特定发布的问题、风险、缺陷、部署请求和变更请求有更详细的见解
- 生成一个发布日历
- 逐渐向更成熟的软件配置管理程序发展
- 通过追踪、历史收集、签名机制以及其他的工具编程和定制功能，支持并使能够实现像 Sarbanes-Oxley Act 2002 (SOX)一样的法规需求。
- 通过标准过程和度量采集，支持并能够使用像 集成的能力成熟度模型(CMMI)一样的过程
- 拥有他或者她的相关数据的支持观点，而无论什么是时间什么地点
无论你在企业开发项目中担任的什么角色，不管是发布经理、项目经理、分析师、构架师、开发测试员、部署经理或管理层，一个强大的项目管理基础和集成在集成开发环境(IDE)的软件，软件配置管理 (SCM) 系统和项目管理工具以及开发方法论都是所必须的。
文章来源于领测软件测试网 https://www.ltesting.net/
