企業軟體發行管理

軟體工具、過程以及專案管理規程的使用。

在過去的幾十年裡我們看到了企業架 構的演變過程，這種演變從單塊整合電路的架構（運行在主機上的基於 COBOL 程式）到基於組件的架構（Java EE 和 NET 應用）和趨於面向服務的架構（將企業轉變為一個能高度互操作的和可重複利用的服務集合，它使企業更好地適應不斷變化的業務需求）。

隨 著構架方法逐漸朝著人們關心的更多重用和分離的方向發展，公司專屬應用程式軟體開發也不斷要求明確已定義流程和更多層次架構的技術。因此，公司專屬應用程式軟體開發的一些 領域增加了複雜度。在企業級開發（JavaEE 、.NET 等等）中，軟體供應商們已經通過提供先進的代碼產生和過程自動化工具大幅度降低了這種複雜性，並且通過使用已被證實的設計模式和最佳實務簡化了企業開發的 複雜方面。

然而，在企業級開發的外圍，其中一個方面卻可能經常被忽略，這就是軟體發布的管理。軟體發行管理員所面臨的挑戰包括對以下幾方面的管理：

• 軟體缺陷
• 問題
• 風險
• 軟體變更請求
• 新開發請求（額外的特性和功能）
• 部署和打包
• 新開發工作單位

由於當你集中在孤立軟體應用程式的單一軟體發布時，這些似乎是合情合理的，但是……

考 慮到要進行高度複雜的事務性自訂開發應用軟體，軟體應用Team Dev要能夠開發新的特性或功能，並像往常一樣一年六次地向使用者發布（主要的版本）。軟體應用 Team Dev還需要發布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 提供的定義相類似的內容。

範圍管理提供了一個指南，這個指南確保這個項目包括了成功完成項目所必需的工作，並且只包括這些工作。

品質管理組件括了執行決定品質方針、目標和職責的組織的所有活動，這樣項目將會滿足它所承擔的所有需求。

溝通管理使用許多過程，以確保溝通的及時以及合適的產生、收集、分發、儲存、修改以及最終的部署。

風險管理包含的過程，關注於引導風險管理計劃、識別、分析、響應和監控。

那麼在所有已構建的和有用的行業驗收定義之後，什麼是軟體發布記錄呢？

軟體發布記錄是一個基於狀態的記錄類型。它擷取資料元素，比如發布經理的姓名、發布號、發布類型（順應性或者任意性）、生產環境部署日期（軟體部署到一個應用程式伺服器的時間）以及生產日期（軟體通常可用的時間）。

圖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.日誌和報告

回頁首

經驗教訓:經驗教訓：

• 確保Team Dev理解發布記錄的益處和整合軟體工具，過程和專案管理學科的方法。
• 溝通、溝通還是溝通。發布日曆是一個很有用的工具。是保證人們使用了發布資料的主要資源之一。
• 如果可能的話使用標準，不要複製標準。比如如果有一個軟體發布編號方式的標準方法，那就可以使用。
• 結合現有的實體或者建立一個Governance Board for Software Tools和Processes。
• 確保你的工具管理員有先見之明，能夠理解你的業務環境和局限性

回頁首

結論：

通過使用軟體工具、過程和討論的專案管理原則，軟體發布經理可以：

• 有一個針對時間架構（天，星期，月，年）的單獨預定發布視圖。
• 追究基於管理需求和產品矩陣的相關複雜的疑問。
• 有權訪問絕大多數當前的發布資訊。
• 對特定發布的問題、風險、缺陷、部署請求和變更請求有更詳細的見解
• 產生一個發布日曆
• 逐漸向更成熟的軟體組態管理程式發展
• 通過追蹤、曆史收集、簽名機制以及其他的工具編程和定製功能，支援並使能夠實現像 Sarbanes-Oxley Act 2002 (SOX)一樣的法規需求。
• 通過標準流程和度量採集，支援並能夠使用像 整合的能力成熟度等級模型(CMMI)一樣的過程
• 擁有他或者她的相關資料的支援觀點，而無論什麼是時間什麼地點

無論你在企業開發項目中擔任的什麼角色，不管是發布經理、專案經理、分析師、構架師、開發測試員、部署經理或管理層，一個強大的專案管理基礎和整合在整合式開發環境(IDE)的軟體，軟體組態管理 (SCM) 系統和專案管理工具以及開發方法論都是所必須的。