軟件工具、過程以及項目管理規程的使用
在過去的幾十年里我們看到了企業架構的演變過程，這種演變從單塊集成電路的架構(運行在主機上的基于 COBOL 程序)到基于組件的架構(Java EE 和 NET 應用)和趨于面向服務的架構(將企業轉變為一個能高度互操作的和可重復利用的服務集合，它使企業更好地適應不斷變化的業務需求)。
隨著構架方法逐漸朝著人們關心的更多重用和分離的方向發展，企業應用軟件開發也不斷要求明確定義的過程和更多層次架構的技術。因此，企業應用軟件開發的一些領域增加了復雜度。在企業級開發(JavaEE 、.NET 等等)中，軟件提供商們已經通過提供先進的代碼產生和過程自動化工具大幅度降低了這種復雜性，并且通過使用已被證實的設計模式和佳實踐簡化了企業開發的復雜方面。
然而，在企業級開發的外圍，其中一個方面卻可能經常被忽略，這是軟件發布的管理。軟件發布管理員所面臨的挑戰包括對以下幾方面的管理：
1.軟件缺陷
2.問題
3.風險
4.軟件變更請求
5.新開發請求(額外的特性和功能)
6.部署和打包
7.新開發任務
由于當你集中在孤立軟件應用程序的單一軟件發布時，這些似乎是合情合理的，但是……
考慮到要進行高度復雜的事務性自定義開發應用軟件，軟件應用開發團隊要能夠開發新的特性或功能，并像往常一樣一年六次地向用戶發布(主要的版本)。軟件應用開發團隊還需要發布40-50個小版本(具有代表性的 Enterprise Archive 文件或者 .ear，或者.jar 等等)，這些是沒有在計劃之內或者預定之中的任何修改、更新或者應用軟件的部署等等。
此外，應用軟件會對在企業中的其它軟件應用軟件具有依賴和相互依賴(在產生一個成功的構建中)。
軟件發布經理應該做些什么呢?
這篇文章將介紹了一種實現方法，使用 IBM Rational ClearQuest 作為一個基本組件來克服軟件發布經理所面臨的一些挑戰。
文章的意圖不是說這個新的挑戰或者 Rational 是要緊的事情，但是這個挑戰隨著全球交付、時間壓力和系統集成的需要變得越來越復雜。這種解決方案更多關注的是把 Rational 看作一個激活器，而不僅僅是把它看作一個工具。
軟件發布經理可以將 Rational 工具作為像“項目管理協會的項目知識體系指南”(PMBOK)一樣的標準項目管理方法的激活器。PMBOK 確定了九大知識領域：
1.集成管理
2.范圍管理
3.時間管理
4.成本管理
5.質量管理
6.人力資源管理
7.溝通管理
8.風險管理
9.采購管理
這篇文章將說明這個方法和工具是怎樣幫助軟件發布經理來實現九個知識領域中的四個領域。這四個領域是范圍管理、質量管理、溝通管理和風險管理。這個過程將貫穿一個眾所周知的軟件發布記錄(Software Release Record) 的概念。軟件發布記錄是 Rational ClearQuest 內部的一個自定義的記錄類型，它在這篇文章中將作為一個部分詳細進行描述。
剩下的五個領域和另外四個領域的某些部分將由工具集成來處理，它們不會被涉及到。這些集成工具包括 Rational Portfolio Manager (RPM) 或者 Microsoft Project 等。
在我們進入發布記錄(Release Record)和兩個緊密相關的基于狀態的記錄類型之前，首先應該搞清楚一些與 PMBOK 提供的定義相類似的內容。項范圍管理提供了一個指南，這個指南確保這個項目包括了成功完成項目所必需的工作，并且只包括這些工作。
質量管理包括了執行決定質量方針、目標和職責的組織的所有活動，這樣項目將會滿足它所承擔的所有需求。
溝通管理使用許多過程，以確保溝通的及時以及合適的產生、收集、分發、存儲、修改以及終的部署。
風險管理包含的過程，關注于引導風險管理計劃、識別、分析、響應和監控。
那么在所有已構建的和有用的行業驗收定義之后，什么是軟件發布記錄呢?
軟件發布記錄是一個基于狀態的記錄類型。它獲取數據元素，比如發布經理的姓名、發布號、發布類型(順應性或者任意性)、生產環境部署日期(軟件部署到一個應用程序服務器的時間)以及生產日期(軟件通常可用的時間)。
