企业软件发布管理.docxVIP

企业软件发布管理级别： 中级David Lipien (lipien@), 高级管理顾问, IBMJennifer Haines (jen.haines@), IBM ClearQuest 管理员, IBMPatrick Gan (patgan@), 高级信息技术专家, IBM Global Services2006 年 11 月 27 日软件工具、过程以及项目管理规程的使用。在过去的几十年里我们看到了企业架构的演变过程，这种演变从单块集成电路的架构（运行在主机上的基于 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. 软件发布记录这个时候值得一提的是软件发布的编号方式。它值得一提是因为虽然它看起来似乎是一件微不足道的小事，但是我见过很多对这个话题的猜想和争论。作为发布经理，标准和过程是你整个成功的关键因素，尽管本文的目的不是介绍一个有效率的发布经理所必需的所有标准和和方法