软件工具、过程以及项目管理规程的使用。
在过去的几十年里我们看到了企业架 构的演变过程，这种演变从单块集成电路的架构（运行在主机上的基于 COBOL 程序）到基于组件的架构（Java EE 和 NET 应用）和趋于面向服务的架构（将企业转变为一个能高度互操作的和可重复利用的服务集合，它使企业更好地适应不断变化的业务需求）。
随 着构架方法逐渐朝着人们关心的更多重用和分离的方向发展，企业应用软件开发也不断要求明确定义的过程和更多层次架构的技术。因此，企业应用软件开发的一些 领域增加了复杂度。在企业级开发（JavaEE 、.NET 等等）中，软件提供商们已经通过提供先进的代码产生和过程自动化工具大幅度降低了这种复杂性，并且通过使用已被证实的设计模式和最佳实践简化了企业开发的 复杂方面。
然而，在企业级开发的外围，其中一个方面却可能经常被忽略，这就是软件发布的管理。软件发布管理员所面临的挑战包括对以下几方面的管理：
- 软件缺陷
- 问题
- 风险
- 软件变更请求
- 新开发请求（额外的特性和功能）
- 部署和打包
- 新开发任务
由于当你集中在孤立软件应用程序的单一软件发布时，这些似乎是合情合理的，但是……
考 虑到要进行高度复杂的事务性自定义开发应用软件，软件应用开发团队要能够开发新的特性或功能，并像往常一样一年六次地向用户发布（主要的版本）。软件应用 开发团队还需要发布40－50个小版本（具有代表性的 Enterprise Archive 文件或者 .ear，或者.jar 等等），这些是没有在计划之内或者预定之中的任何修改、更新或者应用软件的部署等等。
此外，应用软件会对在企业中的其它软件应用软件具有依赖和相互依赖（在产生一个成功的构建中）。
软件发布经理应该做些什么呢？
这篇文章将介绍了一种实现方法，使用 IBM Rational ClearQuest 作为一个基本组件来克服软件发布经理所面临的一些挑战。
文章的意图不是说这个新的挑战或者 Rational 是最要紧的事情，但是这个挑战随着全球交付、时间压力和系统集成的需要变得越来越复杂。这种解决方案更多关注的是把 Rational 看作一个激活器，而不仅仅是把它看作一个工具。
软件发布经理可以将 Rational 工具作为像“项目管理协会的项目知识体系指南”（PMBOK）一样的标准项目管理方法的激活器。PMBOK 确定了九大知识领域：
- 集成管理
- 范围管理
- 时间管理
- 成本管理
- 质量管理
- 人力资源管理
- 沟通管理
- 风险管理
- 采购管理
这 篇文章将说明这个方法和工具是怎样帮助软件发布经理来实现九个知识领域中的四个领域。这四个领域是范围管理、质量管理、沟通管理和风险管理。这个过程将贯 穿一个众所周知的软件发布记录（Software Release Record） 的概念。软件发布记录是 Rational ClearQuest 内部的一个自定义的记录类型，它在这篇文章中将作为一个部分详细进行描述。
剩下的五个领域和另外四个领域的某些部分将由工具集成来处理，它们不会被涉及到。这些集成工具包括 Rational Portfolio Manager (RPM) 或者 Microsoft Project 等。
在我们进入发布记录（Release Record）和两个紧密相关的基于状态的记录类型之前，首先应该搞清楚一些与 PMBOK 提供的定义相类似的内容。
范围管理提供了一个指南，这个指南确保这个项目包括了成功完成项目所必需的工作，并且只包括这些工作。
质量管理包括了执行决定质量方针、目标和职责的组织的所有活动，这样项目将会满足它所承担的所有需求。
沟通管理使用许多过程，以确保沟通的及时以及合适的产生、收集、分发、存储、修改以及最终的部署。
风险管理包含的过程，关注于引导风险管理计划、识别、分析、响应和监控。
那么在所有已构建的和有用的行业验收定义之后，什么是软件发布记录呢？
软件发布记录是一个基于状态的记录类型。它获取数据元素，比如发布经理的姓名、发布号、发布类型（顺应性或者任意性）、生产环境部署日期（软件部署到一个应用程序服务器的时间）以及生产日期（软件通常可用的时间）。
图1. 软件发布记录
这 个时候值得一提的是软件发布的编号方式。它值得一提是因为虽然它看起来似乎是一件微不足道的小事，但是我见过很多对这个话题的猜想和争论。作为发布经理， 标准和过程是你整个成功的关键因素，尽管本文的目的不是介绍一个有效率的发布经理所必需的所有标准和和方法。基本标准之一是发布的编码约定。发布编码应该 跟随一个行业标准，比如国际标准组织（ISO）。在下面的图表中提供了一个编码和发布命名的标准，它可以灵活处理绝大部分软件交付状态。
图2. 发布编码标准
软件发布记录有一个清楚的基本工作流来跟踪软件开发生命周期中的过程。
下面是软件发布记录的工作流
图3. 软件发布记录的工作流
软件发布记录是其它基于状态的记录类型的一个父记录，它向发布经理提供了发布的一个全局的视图，但是我确信，你正在问自己，怎样管理一个详细视图呢？
更深入一步进入过程，我们可以产生两个额外的基于状态的记录类型，事件（Incident） 和工作请求（Work Request）记录。
事件记录类型可被规类为缺陷、问题、风险、变更请求等等，由于这些不同的分类，事件记录类型有一个相当复杂的状态转换矩阵：
图4. 事件记录
事件记录类型获取描述信息、标题（一个简短描述）、所有人名称、优先级、严重度，以及相关软件发布记录、相关事件记录和相关工作请求。
当一个事件记录进入了 Slotted 状态，那么它一定跟软件发布记录是相关联的。
经 常从用户那里听到的一个抱怨是，他们什么时候需要重新创建一个记录，因为把当前记录拷贝和粘贴到新的记录上是十分单调乏味的工作，虽然工作很简单但是很可 能出错，比如粘贴一个值到一个错误的字段或者忘记将值从原始记录拷贝到新的记录。解决这个问题的办法是给用户一个不用拷贝和粘贴就可以克隆记录的方法。这 样不仅创建了一个记录，并用来自原始记录的数据在板上进行组装，同时还在两个记录之间创建了一个链接。这个克隆记录的代码可以通过下面参考资源部分中 Shmuel Bashan 的 developerWorks 文章中得到。
developerWorks 上的代码必须分散到不同脚本中与各种事件类型一起操作。第一个脚本 clone_record.zip)是确定用户想要克隆的事件记录类型，它然后将执行适当的附加脚本来克隆这个记录。
使 用 ClearCase/UCM/ClearQuest 实现集成的一个局限性就是一个记录只能分配到一个项目/流程/视图，并且一次只能一个人对它进行操作。然而，很可能有同时有好几个人操作一个变更或者他们 可能在世界的不同地方，在不同的工作流程中对同一个变更进行操作。
为了克服这种局限性，你可以执行工作请求记录类型。工作请求记录类型是一个可以运用统一变更管理(UCM)包的基于状态的记录类型。
这 个工作请求记录的创建必须来自于事件记录内部，因为许多数据元素是直接从事件记录拷贝到这个工作请求记录的，并且这两个记录后来是相互连接的。这个工作请 求记录几乎是可任意使用的，它内部有一个非常短的生命周期，因为用户不需要输入很多数据，这个工作请求就可以很容易地被创建、分配、继续操作，然后关闭。 一旦开发者完成了编码变更，通过了代码评审，单元测试变更的记录就将结束。它将提醒事件管理者，这个记录即将进入下一个状态。
这个工作请求记录的状态转换矩阵非常简单：
图5. 工作请求记录的状态转换矩阵
既 然软件发布记录、事件记录和工作请求记录是相互关联的，那么系统在两个方面可以做一些确认。当一个事件记录要进入 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) 系统和项目管理工具以及开发方法论都是所必须的。
扫一扫
511
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
