本辭彙表列出項目核對表中所有交付項文檔的詳細資訊。
業務利益相關方的接受確認,作為關鍵利益相關方,他們與解決方案保持一致,並已就業務需求如何滿足業務案例給予批准。
當應用程式可供生產時,就會執行驗收測試。 測試是由代表各種類型使用者的群組使用實際案例來執行。
驗收測試用於確認:
您規劃和設計驗收測試的時間越早,最終部署就越輕鬆。 應與客戶和您的品質保證團隊一起定義。
雖然您可能無法在專案開始時定義所有詳細資訊,但應討論並同意初始定義。 驗收測試可能會以基本要求(功能和效能)為基礎。
確保系統訪問權限的必要級別已授予所有角色。
Adobe安全性檢查清單是提供的正式檢查清單,以確保AEM在安裝時安全無虞。 它包含您需要執行的安全措施和驗證步驟,以確保實例的完整性。
Adobe支援入口網站可讓實作合作夥伴和客戶將AEM實作設定為支援入口網站中的專案。
可以註冊細節;例如,關於實作的技術和版本。 這可讓客戶和Adobe之間透明。
針對解決方案的行政人員進行培訓。 如需詳細資訊,請參閱Adobe訓練服務。
針對將要製作(編寫)解決方案內容的員工進行培訓。 如需詳細資訊,請參閱Adobe訓練服務。
請確定已註冊適當的人員,以參加相關的認證測驗。
請確定適當的人物已通過相關認證測驗。
為適當人物提供技術培訓;例如,開發人員、建築師、工程師和商業從業者。
關鍵績效指標(KPI)可協助組織定義並衡量邁向組織目標的進度。 一旦一個組織分析其使命並確定其目標,就需要衡量實現這些目標的進展。 KPI提供測量機制。
業務與績效的協調關鍵績效指標(KPI)有助於將組織內所有相關人員和流程匯集在一起。 這進而有助於減少實現業務目標和實現建議目標所需的時間和精力。
確保建議的內容體系結構與相關的關鍵績效指標(KPI)一致。
客戶路線圖由高級別里程碑和業務目標組成。 項目時間表必須遵守並符合此策略,因此必須強調和追蹤任何潛在風險和/或可能的偏差。
應用程式架構應清楚定義建議應用程式的行為。
重點是:
除了標準Adobe Experience Manager(AEM)維護工作外,您還需要定義任何其他作業工作,以便執行解決方案的持續維護。
確保您的團隊由擁有適當培訓的員工組成。 對於項目團隊,建議您具備下列所有功能:
至少有一名AEM認證的Lead Developer
至少有一位AEM認證架構師
您至少有75%的開發人員取得AEM認證;
這可讓經認證的開發人員指導初級開發人員,並確保知識分享和透明度
體系結構圖是體系結構的圖形表示。 它包括:
這提供了系統和解決方案體系結構的概要視圖。 在現階段,這是一項草案,將在後期階段加以審查和改進。
架構審查委員會是跨組織機構,負責:
審查委員會應代表參與該架構的所有關鍵利益攸關方。 通常,他們將由一組負責審查和維護整體架構的主管組成。
自動化指令碼和基本的自動化使用案例:
此策略定義了可重複使用的自動化指令碼框架,以及質量保證(QA)團隊規劃的方法。 它概述自動化測試的整體計畫,以協助確保:
必鬚根據解決方案的內容和預期負載來驗證和調整自動化測試策略。
部署的自動化可確保部署更快速且一致。 《自動化戰略》概述了任何此類自動化機制的配置;包括:
整個項目團隊和所有利益相關方必須確認他們瞭解:
整個項目團隊和所有利益相關方必須確認他們瞭解:
「備份和還原概念」概述了將在解決方案中實施的技術功能。 公司備份和恢復策略需要此選項。
基於備份和恢復概念的端到端完整測試。
業務案例文檔提供與採取操作、採取替代操作(如果可用)或不採取任何操作相關的參數。 這些論點應當基於具體事實(盡可能/相關)進行平衡,並強調所有案例的益處和風險。
商業案例檔案應是所有選項的明確定義,並以建議解決方案實施的令人信服的論據作為結論。
業務分析師應確認他們完全瞭解:
組織使用關鍵績效指標(KPI)來評估其在達到目標時的成功。
商業KPI可定義可衡量的價值,以展現公司如何有效地達成關鍵業務目標。 請務必選擇適合您業務/藍本的KPI,並清楚定義KPI的內容、如何衡量、如何使用及由誰使用。
業務需求文檔(BRD)詳細說明了項目的業務解決方案,為客戶的業務需求和期望提供了明確的規格。 BRD還區分了商業解決方案和技術解決方案。
在審查商業解決方案時,BRD應該回答以下問題:「企業想做什麼?」
風險評估和滲透測試過程可能產生需要在解決方案架構或開發中解決的問題和結果。
這些程式所造成的任何調整都需要由企業審查和批准,並根據總體目標進行衡量。
「快取策略」概述將要快取給使用者的內容。 它必須與效能KPI相容。
例如,可快取影像、javascript和其他伺服器檔案等元素,以改善解決方案的效能。
編碼准則定義開發人員在開發解決方案時應遵循的基本原則。 其中包括:
確保所有適當的角色/角色都收到了《操作手冊》。
確保所有適當的角色/角色都收到效能測試報告。
請確定所有適當的角色/角色都收到發行說明。
確保項目團隊充分瞭解並符合項目範圍和交付期望。
確保所有適當的角色/角色都能收到培訓教材和使用指南。
確保客戶的所有安全要求都到位。
確保安全性概念已生效。
將用於新應用程式的模板和元件的大綱。 包括繼承規則、權限和關係等詳細資訊。
元件和範本關係概念的詳細資訊。
要實施的每個元件的規範詳細資訊。
如何針對開發或測試環境無法開啟/使用的任何外部介面進行開發和測試的概念。
規劃/建置這些介面的模型,以確保測試盡可能接近類似生產的行為。
內容建議架構的檔案。 詳情應包括(其中包括):
對舊系統內容進行審查,並驗證所選內容以遷移到新解決方案。
法律合同的初稿。
目前內容架構與格式的檔案。 這將用於產生未來的內容架構。 它也將用於遷移概念。
客戶有關:
客戶對如何進行開發的任何准則/要求。
定義部署/發行方式及時間的客戶政策。
這些通常包括時間表、排程和簽署要求。
客戶對應監控的政策和要求。 這些是「監控概念」中指定的任何建議之外的。
由客戶為向生產環境發放而定義的計畫。
客戶在報告方面的任何政策及/或要求。 這些可能包括:
制定要實施的主要里程碑的路線圖,包括技術和業務。 然後,將此路線圖傳達給客戶。
客戶(業務和IT)將制定策略來定義解決方案所需的安全級別。 這些可能包括:
客戶有關規格格式、交付和簽署的任何准則。
在用戶驗收測試(UAT)期間,從客戶向質量線索報告。
所套用的任何自訂和/或套用的修補程式都必須記錄在案,因為它們可能會影響未來的升級:
AEM可大量自訂,以符合商業需求。 任何可能影響升級的自訂項目都必須完整記錄。 例如,對AEM的使用者介面(UI)所做的任何重大變更。
目前解決方案所需的任何更新都必須完整記錄;這些可包括:
使用者接受測試(UAT)產生的報表或會議。 他們應該詳細說明:
請確定已啟用/實作AEM的預設安全性設定。
涵蓋專案部署和發行的正規化政策。 這些可能包括:
定義跨環境部署的所需頻率。
軟體開發方法包括將軟體開發工作的整個過程分解為不同的階段(或階段),每個階段都有不同的活動。 其目的在於改進規劃和管理。
在定義方法時,您應預先定義項目團隊為開發或維護應用程式而建立和完成的特定交付項和對象。
定義在解決方案內執行IT(效能或其他)和/或單元測試的開發人員和/或角色。
確保開發環境已配置為自動化部署所需的整合工具。
開發團隊應確認他們完全瞭解:
解決方案所需對話方塊的詳細資訊。
開發環境的檔案。
生產環境的說明檔案。
測試環境的檔案。
耐久性測試顯示瞭解決方案在特定負載下的效能。 測試會評估提交至臨界負載時解決方案的存活時間,以及效能等級。
執行耐久性測試。
錯誤處理是指程式設計、應用程式和通訊錯誤的預期、偵測和解決方式。
根據錯誤處理概念,詳細說明建議的錯誤處理。
所有呈報程式的定義。 每個專案層級都會有不同的程式:
與適當的團隊成員定期舉行質量審查會議。
說明為舊版解決方案或組織內部定義的現有權限和群組集。
現有系統和從屬關係的圖(或一組圖)。
專案發起人會收集與專案成功相關的商業期望。 在項目開始時,必須有一整套期望,因為這些期望應影響整個實施過程中作出的所有決定。
預期可包括:
對解決方案完整體驗的需求。 這包括個人化、跨裝置永續性和使用者體驗等因素。
體驗設計需求的詳細資訊。
概述解決方案完整生態系統的圖表(或一組圖表)。 這應包括外部整合、介面、相依性和網路等元素。
備援系統的定義:
備援系統的端對端測試。
從業務利益相關方處簽署備援系統和相關程式,以確保關鍵業務功能。
對AEM和高級解決方案設計的可行性研究結果。 應根據KPI來衡量這些指標,以確保這些指標能夠得到滿足。
在繼續進行項目之前,需要已完成並簽署的合同。 這是基於合同草稿。
確認利益相關方完全接受:
下列活動所需的時間表和排程:
快樂路徑是預設藍本,沒有例外或錯誤條件。 它由當一切如預期般進行時執行的活動序列組成。
下列各項的初步估計:
確認所有環境都將有最低要求的硬體。
對高級別需求的定義提供了對系統需求的廣義劃分,涵蓋以下方面:
這些函式的基本細節通常已知,因此本檔案不應是估計。
高階解決方案設計說明將用來開發解決方案的架構。 體系結構圖提供了整個系統的概述,確定了將為產品及其介面開發的主要元件。
此系統地圖應提供系統的高層圖。 它與「解決方案上下文」不同,它是所有涉及系統的廣義映射,此圖上沒有介面。
舊系統的內容結構定義。 這將在準備遷移策略時用於參考。
您需要從舊式系統收集並記錄績效統計資料和績效KPI。 然後,這些參數將用作參考點,並用於對新解決方案進行基準測試。
關鍵業務功能的清單。
根據滲透測試結果,對解決方案實施所有必要的變更(已簽署)。
設定支援自動化測試所需的工具和程式。
設定支援自動化所需的工具集和流程。
實施內容架構、標籤概念及重複使用內容。
實作支援體驗設計的需求。
備援系統及相關程式的實作。
與所有必要外部系統整合的實作。
移轉,並驗證新解決方案的內容和其他工件。
角色和權限、使用者和群組的實作。
實作所有安全性措施,包括AEM預設值。
軟體應用程式安全性的實作。
系統安全的實現。
URL處理概念的實作。
設計工作流程的實作。
實施理念為整個實施提供了指導原則。 它應該考慮到:
此概念也可說明解決方案中使用的架構、程式庫和其他工件。
請連絡Adobe支援,以確保在上線時可啟用所需的支援。
體驗設計的初步概念。
測試所有整合(包括內部和外部),以及產生的確認。
這應該是自動的,並經常運行,以確保系統穩定性。
明確的流程記錄了所遇到的所有問題,並跟蹤正在進行的活動,以確保所有問題都得到解決。
一個跟蹤系統,連同所需的程式,記錄所遇到的所有問題並跟蹤正在進行的活動,以確保所有問題都得到解決。
所有項目利益攸關方都應有權訪問,以便促進項目狀況的透明度。
範例包括Atlassian JIRA和HP Quality Center。
所選工具已完全整合,並授予所有必要角色訪問權限。
對於您的專案,舊版系統是現有的技術、電腦系統或應用程式,將會由新解決方案取代。
應收集舊式系統的詳細資訊,以便您知道哪些系統可以退役,何時退役以及對任何其他系統的影響。
實施中將使用的工具概要;工具應包括:
需要存取Adobe支援入口網站的所有使用者和角色清單。
該清單通常由解決方案架構師和/或客戶IT人員組成。
分析以及產生的建議,定義需要記錄哪些項目才能監控解決方案:
測試並啟用AEM維護工作,例如:
記錄移轉;包括
完整說明對應至新解決方案的現有內容、內容架構和格式。 它應涵蓋:
它還建議如何在移轉和新系統實際上線期間,讓內容保持最新(或盡可能保持最新)。 這可能意味著內容凍結、雙重發佈或維護alpha系統。
監控解決方案對系統CPU的使用:
監控解決方案的磁碟輸入和輸出速率:
監控解決方案對磁碟空間的使用:
您應監控使用者:
監控解決方案與外部系統之間的任何連接:
監控解決方案對網路頻寬的使用:
監控對解決方案提出的要求。
在定義的安全點監控。
監控整個系統;例如:
監控解決方案定義的閾值,並實施干預步驟以減少負載。
將監控概念應用到您的解決方案;合併:
應確定和界定可能容易發生故障的具體點。 還應定義與這些任務相關的任何監視任務。
範例包括(其中包括):
確保系統工程師和操作人員瞭解並瞭解任何監控策略。
定義:
記錄了所有操作任務,並定義了其頻率。
手動提供解決方案成功運行和維護所需的所有資訊:
還應詳細說明下列項目的實施概念:
建立並提供的軟體套件可供部署。
滲透測試(非正式稱為筆式測試)是對電腦系統的攻擊,它會尋找安全性弱點,可能會存取電腦的功能和資料。
會傳遞所有必要的條件。
為企業建立的報表,說明滲透率測試結果。
概念性檔案,說明如何確保您的實作符合效能KPI,以及如何擴充解決方案,以持續符合這些KPI。
效能基準用於定義效能測試、耐久性測試和監控。 它通過評估解決方案和系統硬體的效能特性來實現。
這些指標定義了衡量系統效能所需的關鍵績效指標(KPI)。 例如頁面載入時間、伺服器回應時間和資料庫查詢效能。
為業務建立的報告,詳述效能測試的結果。
結果必須符合已定義的KPI和績效預期。
基於角色的測試是以「體驗設計」中概述的不同角色為基礎的方法。 它也會測試帳戶及其相關權限層級。
這常用於使用者接受測試(UAT)。
概念證明(POC)根據要求進行評估,以確保兩者一致。
一個檢查清單,用來定義每次部署後要執行的一系列檢查和任務。
一個檢查清單,用來定義在每次部署前要執行的一系列檢查和任務。
對AEM的標準安裝執行基準測試通常很常見。 然後,這將用作測試實施和硬體的基準。
確認生產環境已就緒,並已部署自動化。
在「上線」至生產環境之前,必須先授與「生產簽署」(PSO)。 這是對即將投入生產的版本以及任何已知問題的審查的結果。 「上線」排程會提供「登出」。
在將套件移至生產環境之前,先取得生產簽名所需的政策和程式。
為業務利益相關方和項目團隊定義溝通計畫。
初始估計數是高水準的,根據執行的高水準要求作出。
現在,對這些項目進行審查、改進和擴大,以提供最終估計。 估計應由每個適當的項目負責人提供,包括項目管理、咨詢、體系結構、測試和開發。
該等估計乃用作資源及預算。
初步估計是高水準的,根據執行的高水準要求作出。 這將在後期階段進行審查和改進。
概述項目和團隊的組織和報告結構所需的文檔。
通常以圖表的形式或包含圖表來呈現時間軸和責任的視覺化概述。 有許多工具可協助您完成這項工作。
項目範圍文檔要求您確定並記錄以下清單:
它涵蓋了交付項目必須取得的成果以及必須完成的工作
根據商定的時間表和所需格式提供項目狀態報告。
概念證明(POC)為解決方案實施了有限的功能範圍。
該方案應旨在論證其可行性,驗證其能夠達到預期目的,並證明其有應用潛力。
AEM維護多個版本的資產和內容。 清除規則的設計和配置是定期刪除舊版本,以維護儲存庫的運行狀況和大小。
定義品質報表的必要內容和格式,以及必須傳送的頻率。
項目經理負責協調發放到生產環境所需的所有角色。
版本注意事項是本版本檔案的一部分。 發行說明應涵蓋:
它可與Runbook搭配使用,以執行安裝前和安裝後步驟及檢查。
如需範例,請參閱AEM發行說明。
最終版本正在運行,並在生產中處於活動狀態。
您應強調與項目實施相關的特定合約條款;例如合約里程碑、發票期間或員工要求。
與客戶一起定義傳送給他們的報表頻率。
tar檔案不會覆寫資料,即使僅更新現有資料,磁碟使用量也會增加。
為了抵消儲存庫不斷增大的規模,制定了一種優化策略來刪除過時資料。
在Adobe支援入口網站中設定專案的正式要求。
本組檔案包括功能和非功能需求以及估計的工作。
確保所有上線所需的角色都配備了人員,而且可用。
風險評估由客戶的IT和/或安全部門執行。
它評估項目的技術和業務風險。 解決方案需要進行評估,以確保符合安全策略。
風險緩解計畫包括風險評估。 它們共同涵蓋:
定義與解決方案相連的投資回報(ROI)預期。
它們旨在通過界定與估計投資有關的預期收益/利潤,從經濟角度說明解決方案的效率。
詳細說明與新應用程式所需角色和訪問權限相關的概念,包括以下內容的高級概述:
審查角色和權利概念,以確保符合安全政策。
基於角色和權限概念的詳細規範。
與軟體和硬體架構的安全性相關建議。
這些准則定義了如何根據安全性需求(例如:
根據安全概念以及確保符合解決方案要求的任何其他策略,對項目進行專案檢查清單。
這通常也會包含在操作手冊的部署後步驟中。
定義並記錄應用程式、架構和基礎架構所需安全性組態的詳細資訊。
高級概述,涵蓋以下安全性設定:
列出並評估解決方案的所有安全問題;包括工作量估計。
從利益相關方簽署,以確保安全性實作符合政策與期望。
設定所需的支援流程。
確保服務級別協定(SLA)可供開發和運營團隊在實施和支援期間使用,並與之溝通。
煙霧測試包括一組定義的步驟,這些步驟可測試解決方案的主要功能,以確保解決方案的基本操作和功能。
在安裝或部署後,在任何環境上執行這些動作。
應在所有系統上運行煙霧測試,以確保解決方案在安裝或部署到任何環境時的基本功能正確運行。
軟體架構的高層次策略;包括服務、servlet、框架和其他實施決策。
解決方案審查委員會通常由客戶利益相關方組成。
董事會定期舉行會議,以持續檢討現行規定及相關規格。 目的是確保符合成功定義和標準,並為制定要求提供投入。
解決方案的安裝說明,以及在安裝時執行的基本操作任務。
簽署和接受程式概述了在解決方案發佈到生產環境中之前必須滿足的標準。
它也可以做為合約上的里程碑。
AEM平台上任何被視為超出正常開發範圍之特殊功能的初始概念。
AEM平台上任何被視為超出正常開發範圍的特殊功能的詳細資訊。
客戶關於如何執行規格的任何准則。
客戶簽署規格的明確程式應當到位。 此程式可確保要求的範圍清晰和堅定。
需要培訓以管理解決方案的內部員工。
需要培訓才能編寫解決方案的內部人員。
利益相關方是對項目有重大興趣的主要人員及/或角色。 有些人將為項目預算捐款。
利益相關者可以是內部和/或外部。
確認實際實施團隊以外的所有利益相關者都瞭解:
確認實際實施團隊以外的所有利益相關者都符合整體專案和預期,包括專案團隊內部和客戶。
狀態報告是溝通的重要工具。 格式應與客戶的任何報告要求一致。
客戶、項目贊助商和項目經理或顧問應指定:
這些用於確保滿足成功標準:
Quality Lead的部分職責是確保在測試時有資源可支援任何使用者。 例如,在測試時協助使用者,在報告問題時協助使用者,並協助根據測試環境驗證問題。
存取Adobe支援入口網站對於提交有關實施期間可能發生之任何產品問題的票證至關重要。
存取權應分配給團隊的主要成員。
解決方案所有環境體系結構的初步建議和定義。
詳細描述系統架構的檔案;包括所有環境的介面、網路位置和整合等資訊。
概要說明如何使系統體系結構與任何安全策略相容。 這可涵蓋:
在風險評估(或其他審閱)中發現的任何風險因素均予以識別及評估:
確認整個團隊都瞭解成功定義和准則。
確認團隊的所有成員都知道應該與客戶進行溝通的人員,以及有關方式和時間的詳細資訊。
符合整個專案和預期,既包括專案團隊內部,也包括客戶。
這些需求是針對支援解決方案之服務的技術實作。
識別並驗證潛在的技術風險。 技術風險可包括:
技術規範涵蓋(其中包括其他資訊):
所需範本的規格。 這些應涵蓋詳細資訊,包括parsys、blueprint和繼承對應等。
規格以業務需求和體驗需求為基礎。
測試案例會詳細說明執行解決方案功能測試所需的詳細步驟。
測試內容應盡可能接近生產內容。 它必須具備足夠廣泛的選擇範圍,才能測試所有藍本。
確保已準備好測試環境,並已部署自動化部署,以確保所有版本候選代碼都是最新的測試代碼。
詳細列出測試結果的報告;包括:
應當指出:
選擇自動化套件和工具。 這些將用於自動化測試,包括使用案例的測試。
為使用案例自動化和其他測試執行工作選取的自動化套件和工具。
測試概念是項目測試的高層次概要;包括QA、UAT、效能、安全性和整合測試。
這些計畫更詳細地概述了每個開發階段的測試執行情況,並基於測試策略。
這些需求是針對支援解決方案之服務的技術實作。
測試策略概述了質量保證和用戶驗收測試的高級策略。 這包括時間軸、報告順序和執行。
與協力廠商系統整合的架構和系統層級概念。
協力廠商系統支援功能與整合的需求(功能與非功能)詳細資訊。
確保任何第三方整合安全性的概念。 必須符合適當的安全性原則。
確保所有協力廠商系統都可供使用,並提供適當的檔案,以進行整合實作。
授予與第三方系統一起使用之各角色的必要存取權。
定義:
定義系統中監控點的關鍵值。
例如:
這應該定義項目時間表和用於以下項目的合同里程碑:
所有努力估計,應當從項目上的每個線索中加以匯總;包括開銷、開發、系統工程、建築和測試工作。
如果協定中包括支助級別,也應包括支助和業務工作。
用於培訓課程的教材。 資料應專為解決方案建立,並與使用指南搭配使用。
適當的角色應該能夠確認他們完全理解:
您的URL處理概念應涵蓋AEM特定URL功能,包括:
該概念還應涵蓋:
使用案例是達到目標所需動作或事件步驟的清單。 通常,它們會定義角色與解決方案之間的互動。 角色可以是用戶或外部系統。
測試藍本是以技術和商業使用案例為基礎。 他們用來測試解決方案的行為是否如預期。
使用者指南為解決方案的使用者提供資訊與協助:
預算計畫必須由所有利益攸關方審查和驗證。 他們需要檢查詳細資訊,例如開立發票、金額和預算報告的方法/時間。
白色方塊測試是測試應用程式內部結構或運作方式的方法,而非其功能。 白盒測試可以應用於軟體測試過程的單元、整合和系統級。
這些規格應根據「工作流概念」詳細定義建立完整工作流的步驟。
每個工作流的規範應包括(至少):
工作流程可讓您自動化AEM活動。 Workflows Concept概述: