此辭匯表列出了項目清單中所有可交付項文檔的詳細資訊。
業務利害關係人的接受確認,作為關鍵的利害關係人,他們與解決方案保持一致,並已就業務要求如何滿足業務案例給予他們批准。
當應用程式準備好投入生產時,會執行驗收測試。 這些測試由代表各種類型的最終用戶的組執行,使用真實情況。
接受測試用於確認:
您越早規劃和設計驗收測試,最終部署就越輕鬆。 應與客戶和您的品質保證團隊一起定義。
雖然您可能無法在項目開始時定義所有詳細資訊,但應討論並商定初始定義。 驗收測試可能以基本要求(功能和效能)為基礎。
確保將所需的系統訪問級別授予所有角色。
Adobe安全性檢查清單是為確保AEM在安裝時安全而提供的官方檢查清單。 它包含您執行以確保執行個體完整性所需的安全措施和驗證步驟。
Adobe支援入口網站可讓實作合作夥伴和客戶在支援入口網站中將AEM實作設定為專案。
可以註冊詳細資訊;例如,關於實作的技術和版本。 這為客戶和Adobe提供了透明度。
為解決方案的行政人員提供培訓。 如需詳細資訊,請參閱Adobe培訓服務 。
為將為解決方案製作(製作)內容的員工提供培訓。 如需詳細資訊,請參閱Adobe培訓服務 。
確保註冊相應角色以參加相關的認證考試。
確保適當角色通過相關的認證考試。
為適當人員提供技術培訓;例如,開發人員、建築師、工程師和業務從業人員。
關鍵績效指標(KPI)可協助組織定義及衡量邁向組織目標的進度。 一旦一個組織分析其任務並確定其目標,它就需要衡量實現這些目標的進展。 KPI提供測量機制。
協調您的業務和績效關鍵績效指標(KPI)有助於將組織內所有相關人員和流程集中起來。 這反過來又有助於減少實現業務目標和實現擬議目標所需的時間和精力。
確保建議的內容架構與相關關鍵績效指標(KPI)保持一致。
客戶路線圖由高級別里程碑和業務目標組成。 項目時間表必須遵守並符合此策略,因此必須強調和跟蹤任何潛在風險和/或可能的偏差。
應用程式架構應明確定義建議應用程式的行為。
重點在於:
除了標準Adobe Experience Manager(AEM)維護任務外,您還需要定義任何其他需要執行的操作任務,以便持續維護解決方案。
確保您的團隊由員工組成,並接受適當的培訓。 若為專案團隊,建議您具備下列所有條件:
至少一個AEM認證的主要開發人員
至少一個AEM認證架構師
至少75%的開發人員獲得AEM認證;
這可讓經過認證的開發人員指導初級開發人員,並確保知識共用和透明
架構圖是架構的圖形表示。 包括:
這可提供系統和解決方案架構的概觀。 在現階段,將在以後階段審查和完善這一草案。
架構審核委員會是一個跨組織機構,它可:
審查委員會應代表與該架構有關的所有主要利益攸關方。 通常,他們將由一組負責審查和維護總體架構的高管組成。
自動化指令碼和基本的自動化使用案例:
此策略定義了可重複使用的自動化指令碼的框架,以及品質保證(QA)團隊規劃的方法。 它概述了自動化測試的總體計畫,以幫助確保:
必鬚根據解決方案上的內容和預期負載來驗證和調整自動測試策略。
部署的自動化可確保部署更快且一致。 《自動化戰略》概述了任何此類自動化機制的配置;包括:
整個項目團隊和所有利益相關方必須確認他們了解:
整個項目團隊和所有利益相關方必須確認他們了解:
「備份和還原概念」概述了將在解決方案中實施的技術功能。 公司備份和還原策略需要此策略。
基於備份和還原概念的完整端到端測試。
業務案例文檔介紹了與採取行動、採取替代行動(如果可用)或不採取任何行動相關的論點。 辯論應根據具體事實(盡可能/相關)進行平衡,並強調所有案件的好處和風險。
商業案例檔案應是所有選擇的明確定義,最後應有令人信服的理由來實施擬議的解決方案。
業務分析人員應確認他們完全了解:
組織使用關鍵績效指標(KPI)來評估其達到目標時的成功。
業務KPI定義可衡量的價值,以展示公司如何有效地實現關鍵業務目標。 請務必以清楚的定義選擇適合您的業務/情境的KPI,以判斷KPI是什麼、如何衡量、如何使用以及由誰使用。
業務需求檔案(BRD)詳細說明了項目的業務解決方案,為客戶的業務需求和期望提供了明確的規格說明。 BRD也區分商業解決方案與技術解決方案。
在審查商業解決方案時,BRD應該回答以下問題:「企業想做什麼?」
風險評估和滲透測試過程可能產生需要在解決方案的架構或開發中處理的問題和結果。
由這些流程產生的任何調整都需要由企業審查和批准,並根據總體目標進行評估。
快取策略概述將快取給一般使用者的內容。 它必須符合效能KPI。
例如,可快取影像、javascript和其他伺服器檔案等元素,以改善解決方案的效能。
編碼准則定義了開發人員在開發解決方案時應遵循的基本原則。 其中包括:
確保所有適當的角色/角色都收到《操作手冊》。
請確定所有適當的角色/角色均已收到效能測試報告。
確認所有適當的角色/角色皆已收到發行說明。
確保項目團隊充分了解並符合項目範圍和交付期望。
確保所有適當的角色/角色都獲得培訓材料和使用手冊。
確保客戶的所有安全要求都到位。
確保安全概念已就緒。
將用於新應用程式的模板和元件的大綱。 包括繼承規則、權限和關係等詳細資訊。
元件和範本關係概念的詳細資訊。
要實施的每個元件的規格詳細資訊。
如何針對開發或測試環境可能無法開啟/使用的任何外部介面進行開發和測試的概念。
規劃/實作這些介面的模型,以確保測試盡可能接近生產型行為。
建議內容架構的檔案。 詳情應包括(其中包括):
會審查舊版系統內容,並驗證所選內容以便遷移到新解決方案。
法律合同的初稿。
目前內容架構和格式的檔案。 這將用於產生未來的內容架構。 此外也會用於移轉概念。
客戶的政策:
客戶關於如何開發的任何准則/需求。
客戶提供的原則,定義部署/發行的方式和時機。
這些通常包括時間表、排程和簽核要求。
客戶應監控的政策和要求。 這些是「監控概念」中指定的任何建議之外。
由客戶定義的發行至生產環境的排程。
客戶在報告方面的任何政策和/或要求。 這些包括:
制定技術和業務上要實施的主要里程碑的路線圖。 然後,此路線圖將傳達給客戶。
客戶(業務和IT)將制定策略來定義解決方案所需的安全級別。 這些包括:
客戶有關規格格式、交付和簽核的任何准則。
在用戶接受測試(UAT)期間從客戶報告到質量銷售線索。
所套用的任何自訂和/或套用的Hotfix都必須記錄下來,因為它們可能會影響未來的升級:
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和效能預期。
以人設為基礎的測試是以Experience Designs中概述的不同角色為基礎的方法。 它也會測試帳戶及其相關權限層級。
這通常用於使用者接受測試(UAT)。
概念驗證(POC)根據要求進行測量,以確保兩者保持一致。
一個核對清單,用於定義每次部署後要執行的一系列檢查和任務。
一個核對清單,用於定義要在每個部署之前執行的一系列檢查和任務。
通常在標準安裝AEM上執行基線測試。 然後,這會作為測試實作和硬體的基準。
確認生產環境已就緒,並部署自動化部署。
上線至生產環境之前,必須授予生產簽核(PSO)。 這是將投入生產的版本審查結果,以及任何已知問題。 「上線」排程會提供「註銷」功能。
在將套件移至生產環境之前,取得生產簽核所需的政策和程式。
為業務利害關係人和項目團隊定義溝通計畫。
初步估計數為高水準,根據執行的高水準要求作出。
現在,對這些項目進行審查、改進和擴大,以提供最終估計。 估計應由每個適當的項目主管提供,包括項目管理、咨詢、架構、測試和開發。
這些估計數用於資源籌措和預算編製。
初步估計數是高水準的,是根據執行方面的高水準要求作出的。 將在後期審查和完善這一機制。
概述項目和團隊的組織和報告結構所需的檔案。
通常會以圖表的形式或包含,以呈現時間表和責任的視覺概覽。 有許多工具可協助您完成此作業。
項目範圍文檔要求您標識並記錄以下清單:
它涵蓋了交付項目必須達到的目標以及必須完成的工作
根據商定的時間表和所需格式傳送項目狀態報告。
概念證明(POC)為解決方案實施了有限的功能範圍。
它應旨在演示該解決方案的可行性,驗證其能夠滿足所需目的,並證明其有可能被使用。
AEM會維護多個資產和內容版本。 清除規則的設計和配置用於定期刪除舊版本以保持儲存庫的運行狀況和大小。
定義品質報表的必要內容和格式,以及必須傳送的頻率。
專案管理員負責協調發行至生產環境所需的所有角色。
發行說明是此版本檔案的一部分。 發行說明應涵蓋:
它與Runbook一起使用,以執行安裝前和安裝後步驟和檢查。
如需範例,請參閱AEM發行說明。
最終版本正在運行且在生產中處於活動狀態。
您應強調與實施項目相關的具體合同條款;例如合同里程碑、發票期或工作人員要求。
與客戶一起定義傳送給他們的報表頻率。
若tar檔案中的資料不會被覆寫,即使僅更新現有資料,磁碟的使用量也會增加。
為了抵消儲存庫不斷增大的規模,我們制定了優化策略以刪除過時的資料。
在Adobe支援入口網站中設定專案的官方請求。
這套檔案包括功能和非功能需求,以及估計的工作。
確保上線所需的所有角色都配備了人員,並且可供使用。
風險評估由客戶的IT和/或安全部門執行。
它評估項目的技術和業務風險。 解決方案需要進行評估,以確保符合安全策略。
風險緩解計畫包括風險評估。 它們共同覆蓋:
定義附加至解決方案的投資回報(ROI)預期。
它們旨在通過界定與估計投資有關的預期收益/利潤,從經濟角度說明解決方案的效率。
詳細說明與新應用程式所需的角色和訪問權限有關的概念,包括以下內容的高級概述:
審查角色和權利概念,確保其符合安全策略。
基於角色和權限概念的詳細說明。
Recommendations與軟體和硬體架構的安全性相關。
這些准則根據安全性需求(例如:
項目特定項目清單,基於安全概念,以及確保符合解決方案要求的任何其他策略。
這通常也包括在Runbook中部署後步驟中。
定義並記錄應用程式、架構和基礎架構所需安全配置的詳細資訊。
涵蓋以下安全設定的高級大綱:
列出並評估解決方案的所有安全問題;包括工作估計。
從利益相關方簽收,以確保安全性實施符合政策和期望。
設定所需的支援流程。
確保服務級別協定(SLA)可用並傳達給開發和運營團隊,以便在實施和支援期間使用。
煙霧測試由一組定義的步驟組成,這些步驟可測試解決方案的關鍵功能,以確保解決方案的基本操作和功能。
在安裝或部署後,會在任何環境上執行。
應在所有系統上運行煙霧測試,以確保在安裝或部署到任何環境時正確操作解決方案的基本功能。
軟體架構的高級策略;包括服務、servlet、框架和其他實作決策。
解決方案審查委員會通常由客戶利益相關方組成。
董事會定期舉行會議,以持續檢討目前範圍之規定及相關規格。 其目的是確保符合成功定義和標準,並為制定要求提供投入。
解決方案的安裝說明,以及要在安裝時執行的基本操作任務。
簽核和接受程式概述了必須滿足的標準,才能將解決方案發佈到生產環境中。
它也可作為合約里程碑。
任何特殊功能的初始概念,在AEM平台上的正常開發範圍之外。
任何特殊功能的詳細資訊,這些功能被視為不在AEM平台正常開發範圍之內。
客戶關於如何進行規範的任何指導。
應為客戶簽署規格制定明確的流程。 這一過程確保了要求的明確性和牢固性。
需要培訓以管理解決方案的內部人員。
需要培訓的內部員工,以編寫解決方案。
利益相關方是對項目有重大利益的關鍵人士和/或角色。 有些將為項目預算捐款。
利益相關方可以是內部和/或外部。
確認實際實施團隊以外的所有利害關係人都了解:
確認實際實施團隊以外的所有利害關係人,無論是在專案團隊內部還是在客戶內部,都符合整體專案和期望。
狀態報告是溝通的關鍵工具。 格式應與客戶的任何報表需求一致。
客戶、項目發起人、項目經理或顧問應當指定:
這些用於確保符合成功標準:
Quality Lead的部分職責是確保有可用資源支援任何用戶進行測試。 例如,協助使用者進行測試時、回報問題時,以及協助根據測試環境驗證問題。
存取Adobe支援入口網站對於提交實施期間可能發生之任何產品相關問題的票證至關重要。
應將存取權分配給團隊的關鍵成員。
解決方案所有環境的初步建議書和體系結構定義。
詳細說明系統架構的文檔;包括所有環境的介面、網路位置和整合,以及其他資訊。
概述如何使系統體系結構符合任何安全策略。 這可涵蓋:
在風險評估(或其他審閱)中發現的任何風險因素均予以識別及評估:
確認整個團隊都了解成功定義和條件。
確認團隊的所有成員都知道應該與客戶溝通的人員,以及溝通方式和時間的詳細資訊。
符合整體專案和期望,包括專案團隊內部和客戶內部。
這些要求特定於支援該解決方案的服務的技術實施。
識別和驗證潛在的技術風險。 技術風險可包括:
《技術規範》包括(其中包括資訊):
所需範本的規格。 這些內容應涵蓋詳細資訊,包括parsys、blueprint和繼承對應等。
規格以業務需求和體驗需求為基礎。
測試案例具體說明了執行解決方案功能測試所需的詳細步驟。
測試內容應盡可能接近生產內容。 它的選擇範圍必須足夠廣,以允許測試所有情況。
確保測試環境已就緒,並部署自動化部署,以確保所有發行候選程式碼都為測試的最新版本。
詳細說明測試結果的報告;包括:
應當指出:
選擇自動化套件和工具。 這些功能將用於自動化測試,包括用於使用案例的測試。
為使用案例自動化和其他測試執行任務選擇的自動化套件和工具。
「測試概念」是項目測試的非常高級的概要;包括QA、UAT、效能、安全性和整合測試。
這些計畫更詳細地概述了每個開發階段的測試的執行情況,並基於測試策略。
這些要求特定於支援該解決方案的服務的技術實施。
測試策略概述了質量保證和用戶接受測試的高級策略。 這包括時間表、報告順序和執行。
整合協力廠商系統的架構和系統層級概念。
協力廠商系統支援功能及整合需求(功能及非功能)的詳細資訊。
確保任何協力廠商整合安全性的概念。 必須符合適當的安全策略。
確保所有協力廠商系統皆可使用,並附上適當的檔案,以進行整合實作。
授予與協力廠商系統一起使用之個別角色的必要存取權限。
定義:
定義系統中監控點的關鍵值。
例如:
這應該定義要用於以下項目的時間表和合同里程碑:
應綜合從項目的每個領導中得出的所有努力估計;包括開銷、開發、系統工程、架構和測試工作。
如果協定中包含支助級別,也應包括支助和業務工作。
用於培訓課程的材料。 材料應專為解決方案建立,並設計為與使用手冊搭配使用。
適當的角色應確認他們完全了解:
您的URL處理概念應涵蓋AEM的特定URL功能,包括:
該概念還應包括:
使用案例是達成目標所需的動作或事件步驟清單。 通常會定義角色與解決方案之間的互動。 角色可以是使用者或外部系統。
測試案例以技術和業務使用案例為基礎。 它們用來測試解決方案行為是否如預期般運作。
使用手冊為解決方案的使用者提供資訊和協助:
預算計畫必須由所有利益攸關方審查和驗證。 他們需要檢查詳細資訊,例如開具發票、金額和預算報告的方法/時間。
白盒測試是一種測試應用程式的內部結構或工作方式的方法,而不是其功能。 白盒測試可以應用於軟體測試過程的單元、整合和系統級。
這些規範應根據工作流程概念詳細定義將建立完整工作流程的步驟。
每個工作流的規範應包括(至少):
工作流程可讓您自動執行AEM活動。 工作流程概念概述: