準則: 部署計劃
這個準則提供開發部署計劃的其他指引。
關係
相關元素
主要說明

識別相容性、轉換和移轉策略

如果系統將取代現有的系統,就必須處理相容性、轉換和移轉問題。明確地說,便是:

  • 現有系統的資料必須進入新系統(可能要轉換格式)。
  • 新系統必須支援現有的使用者介面(畫面格式、指令等)。
  • 必須維護所有現有的應用程式設計介面 (API)。
  • 從現有系統移轉到新系統造成使用者服務混亂的時間,不能超出預定的時間量(這會隨企業而不同)。
  • 在移轉期間,新系統必須能夠與舊系統平行運作。
  • 在作業的前兩星期內,必要的話,必須能夠返回舊系統。
  • 舊的保存資料可能需要在新系統中處理過。如果它受密碼保護,當移轉時,加密金鑰就需要特殊考量。

選擇來處理這些問題的策略,需要系統架構和設計的適當支援

決定部署時程表

將系統轉換到正式作業環境需要規劃和準備。必須考量的技術因素包括:

  • 系統的使用者可能需要受訓。
  • 正式作業支援環境必須準備好,正式作業支援人員必須受訓,且必須完成支援系統的準備。
  • 必須建立正式作業支援程序,其中包括備份、回復和問題解析。

影響部署時程表的商業因素包括:

  • 可能會有明確的商業目標需要在特定日期部署系統;當不符合這個日期時,可能會大幅削減系統的價值。(附註:這類需求的存在,會帶來工作成果:風險清單所應識別的風險,如果開發的話,應該在工作成果:風險管理計劃中加以緩和。系統的成本和好處可能發生的變化,應該寫在工作成果:商業案例中。)
  • 在某些時段裡,系統有可能因商業或作業狀況而無法部署,其中包括(但不限於)財務報告期間已告結束,或系統在某些期間無法關係。 

    工作量尖峰以及現有系統和流程的其他因素,有可能在某些時間造成無法部署。 例如:

    • 處理量較大:每週、每月或每年的尖峰
    • 硬體或軟體定期的維護周期 - 系統可用性和人員都會受到影響
    • 尖峰假期時段
    • 因硬體升級或引進新系統而出現的計劃性單次毀壞
    • 計劃性重組
    • 機能變更。
  • 有些系統絕不能關閉(如網路和電話系統交換機);這些系統有可能需要在舊版執行時部署新版本。升級高可用性系統通常需要特殊的架構考量,它必須寫在工作成果:軟體架構文件中。

判斷部署順序

有些系統的部署會因為定時或可用性問題,而必須以漸進方式,分段進行。如果系統無法一次部署完成,就必須決定元件的安裝順序及要安裝元件的節點。一般部署排程型樣包括:

  • 地理 - 依區域
  • 功能 - 依應用程式
  • 組織 - 依部門或工作功能

當應用程式部署超過某段時間之後,必須解決的問題包括:

  • 軟體必須能夠在局部配置中執行
  • 不同版本的軟體必須能夠共存
  • 當偵測到新系統有問題時,必須能夠回復到舊版的系統

實現這些功能需要在架構上,集中焦點下工夫,它們應該寫在工作成果:軟體架構文件中。

判斷使用者訓練需求

對於每個使用者種類(包括管理、操作員和使用者),請識別下列項目:

  • 他們目前使用哪些類型的資訊技術系統。如果這個系統是組織內外的任何使用者最初使用的資訊技術,請將這一點標示為特殊需求,值得特別注意。
  • 這個系統將為他們帶來什麼新功能。
  • 明白地說,他們需要什麼訓練。
  • 有哪些國家語言支援 (NLS) 需求。