|
| |
| Sun Java Enterprise System 2005Q1 部署規劃指南 | |
第 2 章
業務分析在解決方案生命週期的業務分析階段期間定義業務目標，方法是透過分析業務問題以及找出達成該目標的業務需求和業務限制。
本章包含以下各節：
關於業務分析業務分析始於陳述業務目標。接著您要分析業務問題，您必須解決並找出要達到業務目標必須完成的業務需求。同時考慮任何限制您達成目標的業務限制。根據業務需求和限制的分析可產生一組業務需求文件。
您可以將這組業務需求文件作為技術需求階段中產生技術需求的基礎。在整個解決方案生命週期間，您可以根據業務分析階段中執行的分析，來衡量部署規劃的可行性以及解決方案最終的可行性。
定義業務需求業務需求定義並沒有簡單的公式。業務需求的決定應根據與軟體解決方案利害關係人的合作、您對業務網域的相關知識以及實用的創意思考。
本節提供定義業務需求時應考慮的幾個因素。
設定業務目標
業務分析應該說明部署專案的目標。清楚的目標有助於集中設計判斷，亦可避免專案偏離主題。用目前的作業對照業務目標可協助決定設計的判斷。
範圍
業務需求應該要陳述部署專案的範圍。確定您定義的範圍可以被處理，並且避免「無限制」的敘述使目標不清楚或無法達成。不清楚的定義範圍會導致部署設計無法充分滿足業務需求或是浪費資源。
優先性
排出目標的優先順序，來確保部署最重要的層面可以最先達成。如果資源有限時，則可能需要延遲或修改某些目標。一般而言，大型複雜的部署需要階段性實作解決方案。透過確定優先性，您可以提供決策 (可能需要為您的部署設計建立以便獲得利害關係人承認) 的指導。
關鍵特性
找出成功的關鍵領域，以便利害關係人和設計者可以將重心放在在最重要的標準。
成長因素
設定業務目標時，您不只要考慮組織目前的需要，也要預估這些需求長期下會如何變更和成長。您應該避免決定一個很快就不適用的解決方案。
安全空間
解決方案的設計以業務分析階段期間所做的假設為基礎。有許多原因可能造成這些假設不正確，例如，資料不足、判斷錯誤，或是未預期的外部事件。請確保您同時在業務目標和整個規劃中進行安全空間規劃，如此，您所設計的解決方案才能處理未預期的事件。
瞭解使用者需求
進行必要的研究，以瞭解解決方案鎖定的使用者類型、他們的需求以及他們的預期利益。例如，下列清單提供一個分類使用者的方法：
清楚指出使用者的預期利益可幫助促成設計決定。例如，這裡是解決方案可提供給使用者的一些好處：
開發作業需求
將作業需求以一組包含明確目標的功能需求來表示。一般而言，您會為下列的區域建立作業需求，例如：
以所有利害關係人都能瞭解的適當術語來表達作業需求。避免含糊不清的語言，例如「適當的一般使用者回應時間」。作業需求的範例如下所示：
支援現有的使用模式
以可清楚評量的目標表示現有的使用模式。下列問題可協助決定此類的目標。
研究會存取服務的使用者。使用者何時會存取現有的服務及存取時間長度，此類的因素是識別目標的關鍵。如果組織的經驗無法提供這些模式，請研究類似組織的經驗。
瞭解公司文化
需求分析應該將公司文化和政策的各種層面考慮在內。如果不注意公司文化會導致解決方案不容易被接受，或是難以實作。
利害關係人
確認在提議解決方案的成功當中具有既得利益的個人和組織。所有的利害關係人都應該主動參加業務目標和需求的定義。如果利害關係人沒有參加或是對規劃的變更一無所知，則規劃可能會有很嚴重的缺失。此類的利害關係人甚至會阻礙部署的實作。
標準和策略
確定您瞭解組織要求解決方案的標準和策略。這些標準和策略可能會影響設計、產品選項和部署方法的技術面。
一個範例是人事資料的機密性，這可能是由人事資源組織或部門主管所擁有或控制的資訊。另一個範例則是改變經營的公司程序。改變經營的公司程序可能會嚴重地影響解決方案的接受度、實作方法和時間表。
規管需求
規管需求有很大的程度是取決於業務的特性。研究和瞭解可能會影響部署的規管需求。許多公司和政府機構需要遵循存取標準。部署全球性解決方案時，亦需考慮到外國的法律和法規。例如，許多歐洲國家對儲存個人資訊有嚴格的控制。
安全性
您之前確認的目標，可能有需要特別注意的潛在安全性問題。調出部署所需的特定安全性目標。例如：
站點分散
站點間的地理分散與頻寬會影響設計決定。此外，某些站點可能需要本機管理。
這些地理考量會提高專案的訓練成本和複雜性等等。清楚指出站點地理分散造成的需求。強調哪些站點是設計成功的關鍵。
使用遞增方式
通常您會將軟體解決方案視為一個全體、廣泛的系統。然而，您經常以評量步驟逐步達成完整系統的部署。
當採用遞增方式時，您通常會設計藍圖來提供引導到最終、廣泛解決方案的重大事件。此外，您可能要考慮延遲到後期實作的廣泛解決方案層面的短期規劃。
遞增方式提供這些優點：
瞭解服務層級合約
服務層級合約 (SLA) 指定最低的效能需求以及依據達成那些需求造成的失敗指定必須提供的客戶支援的層級和範圍。服務層級合約 (SLA) 是以業務分析期間定義的業務需求為基礎，稍後會將這些需求指定為技術需求階段期間的服務層級需求。SLA 會在專案核准 (也就是部署設計階段) 期間簽訂。
您應該以下列項目為中心開發 SLA，例如正常執行時間、回應時間、訊息傳送時間和損壞修復。SLA 應該考慮這些項目，例如，系統概觀、支援組織的角色和責任、如何衡量服務層級、改變要求等等。以系統可用性為中心來識別組織的預期是決定 SLA 範圍的關鍵。
定義業務限制業務限制在決定部署專案的特性中扮演重要的角色。成功的部署設計關鍵在於在已知業務限制中找到符合業務需求的最佳方式。業務限制可以是財務限制、實體限制 (例如網路容量)、時間限制 (例如完成重大事件 (如下次年度會議) 之前)，或是任何其他限制 (您預期會對完成業務目標造成影響的因素)。
本節提供定義業務限制時要考慮的幾個因素。
遷移問題
通常，部署專案會取代或補充現有的軟體基礎架構和資料。任何新的解決方案必須能夠將資料和程序從現有基礎架構遷移到新的解決方案，通常會保留與現有應用程式的互通功能。需要目前基礎架構分析，才能決定遷移問題在提議解決方案中的影響範圍。
排程指定作業
解決方案的實作排程會影響設計決定。積極的排程可以會導致目標的縮小、改變優先性或是採取遞增的解決方法。在排程中，可能也有重要的重大事件值得考慮。重大事件可以以內部事件 (例如排程的服務建置)，或是外部事件 (例如學校學期的開學日) 來設定。
預算限制
大部分的部署專案必須依附預算。考慮建立提議解決方案的成本，還有在特定的使用期間內維護專案需要的資源包括下列項目：
所有權成本
除了維護、管理和支援，請分析其他可能會影響所有權成本的因素。可能需要的硬體和軟體升級，對電源供應網上的解決方案的影響，電信成本和其他影響暫墊費用的因素。指定解決方案可用性層級的服務層級合約也會因為要求較多的備援而影響所有權的成本。
解決方案的實作應該提供投資利潤。投資利潤的分析通常包含資金支出獲得的經濟利益。
估計解決方案的經濟利益包含要達成的目標與達成目標的替代方案相比較，或是與甚麼都不做的成本相比較的詳細分析。