字彙表

此辭彙表列出(按不同方式)來自 項目核對表

業務利益相關方的接受

業務利益相關方的接受確認,作為關鍵利益相關方,他們與解決方案保持一致,並已就業務要求如何滿足業務案例給予批准。

接受Test

當申請準備好投產時,執行驗收測試。 test由代表各種類型的最終用戶的組使用真實場景來執行。

接受test用於確認:

  • 項目滿足客戶的要求。
  • 解決方案適合使用。
  • 用戶接受該解決方案,並可以設想使用它。
  • 客戶接受項目。

計畫和設計驗收test越早,最終部署就越容易。 它們應與客戶和您的質量保證團隊一起定義。

儘管您可能無法在項目開始時定義所有詳細資訊,但應討論並商定初始定義。 驗收test可能基於基本要求(功能和效能)。

訪問Test系統

確保已將所需級別的系統訪問權限授予所有角色。

Adobe安全檢查表

Adobe安全檢查表 是為確保安裝時AEM安全而提供的正式核對表。 它包含您需要執行的安全措施和驗證步驟,以確保實例的完整性。

Adobe支援門戶項目設定

Adobe支援門戶使實施合作夥伴和客戶能夠將AEM實施作為支援門戶中的項目進行設定。

細節可以註冊;例如,關於實現的技術和版本。 這為客戶和Adobe提供了透明度。

管理AEM員培訓

為解決方案的行政人員提供培訓。 查看 Adobe培訓服務 的子菜單。

AEM作者培訓

為將為解決方案製作(創作)內容的員工提供培訓。 查看 Adobe培訓服務 的子菜單。

認AEM證考試

確保註冊適當人物以獲取相關 認證考試

認AEM證

確保合適人選已通過相關 認證考試

技AEM術培訓

為適當人物提供技術培訓;例如,開發商、建築師、工程師和企業從業者。

KPI協定定義為項目目標

主要績效指標(KPI)幫助組織定義和衡量在實現組織目標方面的進展。 一旦一個組織分析其使命並確定其目標,它就需要衡量實現這些目標的進展。 關鍵績效指標為測量提供機制。

協調業務和績效KPI

協調您的業務和績效關鍵績效指標(KPI)有助於將組織內所有相關人員和流程匯集到一起。 這反過來又有助於減少實現業務目標和實現擬議目標所需的時間和精力。

內容體系結構與KPI的協調

確保建議的內容體系結構與相關關鍵績效指標(KPI)保持一致。

客戶路線圖與項目時間表的協調

客戶路線圖由高級里程碑和業務目標組成。 項目時間表必須遵守並與此策略保持一致,因此必須突出顯示和跟蹤任何潛在風險和/或可能的偏差。

應用程式體系結構定義

應用架構 應明確定義所建議應用程式的行為。

重點是:

  • 它們如何彼此和用戶交互。
  • 應用程式要使用和生成的資料,而不是其內部結構。

已定義應用程式特定維護任務

除了標準Adobe Experience Manager(AEM)維護任務外,您還需要定義需要執行的任何其他操作任務,以便持續維護解決方案。

經過適當培訓的工作人員

確保您的團隊由經過適當培訓的員工組成。 對於項目團隊,建議應具備以下所有條件:

  • 至少一個經認AEM證的Lead Developer
  • 至少一個認AEM證建築師
  • 至少75%的開發者獲得AEM了認證;這使經過認證的開發人員能夠指導初級開發人員,並確保知識共用和透明度

體系結構圖

體系結構圖是該體系結構的圖形表示。 它包括:

  • 概念
  • 他們的原則
  • 作為體系結構一部分的元素和元件

體系結構草稿

這提供了系統和解決方案體系結構的高級視圖。 現階段將審查和完善草案。

體系結構審閱板註銷

架構審查委員會是一個跨組織機構,它:

  • 監督一項連貫性戰略的實施
  • 確保系統的合規性

審查委員會應代表參與該架構的所有主要利益攸關方。 通常,他們由一組負責審查和維護整個體系結構的執行官組成。

與KPI相比,適用於真實內容和結果的自動Test套件

自動化指令碼和基本的自動化使用案例:

  • 適用於生產內容
  • 按KPI檢查

自動化測試策略

此策略定義了一個可重複使用的自動指令碼框架以及質量保證(QA)團隊規劃的方法。 它概述了自動化測試的總體規劃,以幫助確保:

  • 更高的投資回報(ROI)
  • 更多test覆蓋
  • 提高了test可靠性和質量重複性

針對實際和預期負載驗證的自動測試策略

必鬚根據解決方案上的內容和預期負載來驗證和調整自動測試策略。

自動化策略

部署的自動化可確保部署更快且一致。 《自動化戰略》概述了任何此類自動化機制的配置;包括:

  • 頻率
  • 要使用的工具
  • 要部署到的環境

瞭解通信計畫

整個項目團隊和所有利益相關方必須確認他們瞭解:

  • 報告結構
  • 報告的順序
  • 通信通道

瞭解成功定義和標準

整個項目團隊和所有利益相關方必須確認他們瞭解:

  • 成功定義
  • 成功標準

備份和恢復概念

備份和還原概念概述了將在解決方案中實施的技術功能。 本公司需要備份和還原策略。

已測試備份和恢復

基於備份和恢復概念的完整端到端test。

業務案例

業務案例文檔提供與採取行動、採取替代行動(如果可用)或不採取任何行動相關的參數。 這些論點應基於具體事實(盡可能/相關)加以平衡,並強調所有案件的好處和風險。

業務案例文檔應是所有選項的明確定義,最後應為實施建議的解決方案提供令人信服的理由。

業務分析師瞭解項目範圍和預期

業務分析師應確認他們完全理解:

  • 項目範圍
  • 所有客戶期望
  • 這是每個人、每個階段在項目中做出的所有決定的基礎

業務KPI

組織使用關鍵績效指標(KPI)來評估其在達到目標方面的成功。

業務KPI定義可衡量的價值,以表明公司如何有效地實現關鍵業務目標。 選擇適合您的業務/方案的KPI非常重要,它們的定義明確,包括:KPI是什麼、如何衡量KPI、如何使用KPI以及由誰使用KPI。

業務需求文檔

商業需求檔案(BRD)詳細說明了項目的商業解決方案,為客戶的商業需求和期望提供了明確的規格說明。 BRD還區分商業解決方案和技術解決方案。

在研究商業解決方案時,BRD應該回答以下問題:「企業想做什麼?」

針對已確定並與ROI和KPI期望值相一致的解決方案或體系結構的任何必要調整都由企業簽署

風險評估和滲透測試過程可能產生需要在解決方案架構或開發中處理的問題和結果。

由這些流程產生的任何調整都需要由業務部門審查和批准,並與總體目標進行比較。

快取策略

快取策略概述了將為最終用戶快取的內容。 它必須與效能KPI相容。

例如,可以快取影像、javascript和其他伺服器檔案等元素,以提高解決方案的效能。

編碼准則

編碼指南定義了開發人員在開發解決方案時應遵循的基本原則。 其中包括:

  • 命名約定
  • 服務使用
  • 庫使用

通信操作手冊

確保所有適當的角色/角色都已收到《操作手冊》。

通信效能Test報告

確保所有適當的角色/角色都已收到「效能Test」報告。

通信發行說明

確保所有適當的角色/角色都已收到發行說明。

將範圍和期望與團隊溝通

確保項目團隊充分瞭解項目範圍和交付期望,並與之保持一致。

交流培訓材料和使用手冊

確保所有適當的角色/角色都收到培訓材料和使用手冊。

遵守客戶安全要求

確保客戶的所有安全要求都已到位。

遵守安全概念

確保安全概念已到位。

元件和模板關係概念

將在新應用程式中使用的模板和元件的大綱。 包括繼承規則、權限和關係等詳細資訊。

元件和模板關係規範

元件和模板關係概念的詳細資訊。

元件規範

要實施的每個元件的規格詳細資訊。

外部介面模型的概念

如何針對開發或test環境中可能不開放/不可用的任何外部介面開發和test的概念。

規劃/實施這些介面的模型以確保測試盡可能接近類似生產的行為。

內容體系結構文檔

內容擬議體系結構的文檔。 詳情應包括(其中包括):

  • 內容樹
  • 標籤概念
  • 內容重用策略

已驗證遷移內容

對舊系統內容進行審查,並驗證所選內容以遷移到新解決方案。

合同草稿

法律合同的初稿。

當前內容結構和格式

當前內容體系結構和格式的文檔。 這將用於生成未來的內容體系結構。 它還將用於遷移概念。

客戶備份和恢復策略

客戶的政策:

  • 資料和解決方案的備份過程
  • 備份的儲存
  • 確認備份正按預期運行
  • 恢復,在失敗時

客戶編碼准則

客戶關於如何進行開發的任何指南/要求。

客戶部署/發佈策略

客戶的策略,定義部署/發佈的方式和時間。

這些通常包括時間表、計畫和簽訂要求。

客戶監控策略或要求

客戶對應監控的策略和要求。 這些是《監測概念》中指定的任何建議之外。

客戶生產發放計畫

由客戶為生產環境的版本定義的計畫。

客戶報告策略和要求

客戶在報告方面的任何政策和/或要求。 這些可能包括:

  • 具體報告的提交頻率
  • 特定報告的格式
  • 特殊要求

客戶路線圖

制定要實施的主要里程碑的路線圖,包括技術和業務。 然後將此路線圖傳達給客戶。

客戶安全策略

客戶(業務和IT)將制定策略來定義解決方案所需的安全級別。 這些可能包括:

  • 通過風險評估的要求。
  • 通過滲透test的要求。
  • 任何具體的安全要求;例如轉義所有輸入欄位、加密使用(SSL)、證書以及身份驗證和標識。

客戶規格指南

客戶對規格的格式、交付和簽訂有任何指導。

客戶Test報告

在「用戶接受Test」(UAT)期間從客戶報告至「質量線索」。

已記錄影響升級的自定義和修補程式

必須記錄所應用的任何自定義和/或應用的修補程式,因為它們可能會影響將來的升級:

  • 可AEM以根據業務需求進行大量定製。 必須完整記錄可能影響升級的任何自定義。 例如,對的用戶介面(UI)的任何主要更AEM改。

  • 必須完整記錄當前解決方案所需的任何更新;這些包括:

    • 累積固定包(CFP)
    • 服務包(SP)
    • 修補程式
    • 升級

每日用戶接受Test報表

由用戶接受測試(UAT)生成的報告或會議。 他們應詳細說明:

  • 報告的問題
  • 優先處理這些問題

已啟用預設安全性

確保已啟用/實施AEM的預設安全設定。

部署/發佈策略和流程

涵蓋項目部署和發佈的正式策略。 這些可能包括:

  • 發行時間
  • 假日規劃
  • 頻率
  • 而且可以依賴相關環境

已建立部署卡

定義跨環境部署的所需頻率。

開發方法

軟體開發方法涉及將軟體開發工作的整個過程分解為不同的階段(或階段),每個階段都有不同的活動。 目的是改善規劃和管理。

在定義方法時,您應預先定義項目團隊為開發或維護應用程式而建立和完成的特定交付項和對象。

開發角色定義

定義在解決方案內執行IT(效能或其他)和/或設備test的開發人員和/或角色。

開發環境就緒

確保使用部署自動化所需的整合工具配置開發環境。

開發團隊瞭解項目範圍和期望

開發團隊應確認他們完全瞭解:

  • 項目範圍
  • 所有客戶期望
  • 這是每個人、每個階段在項目中做出的所有決定的基礎

對話框規範

有關解決方案所需對話框的詳細資訊。

文檔開發環境設定

開發環境的文檔。

文檔生產環境設定

生產環境的文檔。

文檔Test環境設定

test環境的文檔。

耐久性Test

「耐用性」(Durability)Test顯示瞭解決方案在特定負載下的效能。 test將評估提交到閾值負載時解決方案的存活時間以及效能級別。

已執行耐用性Test

執行耐用test。

錯誤處理概念

錯誤處理是指對寫程式、應用和通信錯誤的預期、檢測和解決。

錯誤處理文檔

基於錯誤處理概念,詳細記錄建議的錯誤處理。

上報流程

所有升級流程的定義。 每個項目級別將有單獨的流程:

  • 項目團隊
  • 客戶
  • Adobe

建立定期質量審查會議

與適當的團隊成員定期舉行質量審查會議。

現有權限結構

為舊式解決方案或組織內定義的現有權限和組集的文檔。

現有系統映射

現有系統和依賴項的圖(或一組圖)。

預期成功定義和標準

項目發起人收集與項目成功相關的業務期望值。 在項目開始時必須有一整套期望,因為這些期望應影響整個實施過程中作出的所有決定。

預期可包括:

  • 指標,例如所服務頁面的增加百分比
  • 發佈內容的時間較短
  • 更高級別的目標,如易於使用的介面

體驗設計要求

對解決方案的整個體驗的要求。 這包括個性化、跨設備持久性和用戶體驗等因素。

體驗規格

體驗設計要求的詳細資訊。

外部系統和用戶依賴項/系統上下文

概述解決方案全部生態系統的圖(或一組圖)。 這應包括外部整合、介面、依賴項和網路等元素。

回退系統和過程

回退系統的定義:

  • 關鍵業務功能,在出現嚴重故障時必須保持運行
  • 回退時所需的進程

已測試回退系統和過程

回退系統的端到端test。

從業務利益相關方註銷備用系統

從業務利益相關方處簽署,備用系統和相關程式將確保關鍵業務功能。

KPI的可行性確認

對高級解設計AEM進行可行性研究。 應根據關鍵績效指標衡量這些指標,以確保這些指標得到滿足。

最終合同

在進行項目之前,需要最後確定並簽訂合同。 這基於 合同草稿

利益相關方接受的解決方案的功能

確認利益相關方完全接受:

  • 解決方案功能
  • 解決方案中的任何已知問題

開始即時計畫

以下項目所需活動的時間表和計畫:

  • 為go live做準備
  • 實際的直播

已定義快樂路徑

快樂路徑是預設方案,沒有異常或錯誤情況。 它由在一切按預期進行時執行的活動序列組成。

硬體估計

初步估計:

  • 基本安裝所需的硬AEM件
  • 任何附加要求,基於高級解決方案設計

硬體將可滿足要求

確認所有環境都將擁有所需的最低硬體。

高級要求

對高級別需求的定義對系統的需求進行了全面細分,涵蓋以下方面:

  • 業務流程
  • 主要系統功能

有關這些函式的基本詳細資訊通常已知,因此本文檔不應是評估。

高級解決方案設計

高級解決方案設計說明了用於開發解決方案的體系結構。 體系結構圖提供了整個系統的概述,確定了將為產品及其介面開發的主要元件。

高級系統圖

本系統地圖應提供系統的高級圖。 它與解決方案上下文不同,即它是涉及的所有系統的廣義映射,此圖上沒有介面。

歷史內容結構

舊式系統的內容結構的定義。 這供參考,在準備遷移策略時也使用。

歷史績效和歷史績效KPI

您需要從舊式系統收集和記錄效能統計資訊和效能KPI。 然後,將這些內容用作參考點並對新解決方案進行基準測試。

確定關鍵解決方案/功能

關鍵業務功能清單。

實施 — 根據滲透Test結果進行更改

根據滲透test的結果,對解決方案實施所有必要的更改(已經簽署)。

實施 — 自動化測試策略

設定支援自動化測試所需的工具和流程。

實施 — 自動化戰略

設定支援自動化所需的工具集和流程。

實施 — 內容體系結構

內容體系結構的實現、內容的標籤概念和重用。

實施 — 體驗設計

實施支援經驗設計的要求。

實施 — 回退系統和過程

回退系統的實現及相關步驟。

實施 — 整合

實施與所有所需外部系統的整合。

實施 — 遷移戰略

遷移以及對新解決方案的內容和其他對象的驗證。

實施 — 角色和權利

實現角色和權限、用戶和組。

實施 — 安全概念

執行所有安全措施,包括AEM預設值。

實施 — 安全軟體

軟體應用程式安全的實現。

實施 — 系統體系結構安全概念

系統安全的實現。

實施 — URL處理

URL處理概念的實現。

實施 — 工作流

設計工作流的實施。

實施概念

實施概念為整個實施提供了指導原則。 它應考慮:

  • 運作
  • 維護
  • 相容性
  • 可重用性
  • 安全性
  • 可擴充性

此概念還可以概述解決方案中使用的框架、庫和其他工件。

通知Adobe支援有關Go Live時間表

聯繫Adobe支援,確保在上線期間啟用所需的任何支援。

初始體驗設計

經驗設計的初步概念。

整合測試

測試所有整合(內部和外部)並進行確認。

這應該是自動的,並且應經常運行,以確保系統穩定。

問題跟蹤流程

明確的進程記錄所遇到的所有問題,跟蹤正在進行的活動,以確保解決所有問題。

問題跟蹤系統和流程

一個跟蹤系統,連同所需程式,記錄所遇到的所有問題和跟蹤正在進行的活動,以確保所有問題都得到解決。

所有項目利益攸關方都應有權訪問,以便提高項目狀況的透明度。

示例包括Atlassian JIRA和HP Quality Center。

問題跟蹤系統流程的建立與整合

所選工具被完全整合併授予所有必需角色的訪問權限。

舊系統

對於您的項目,舊式系統是現有技術、電腦系統或應用程式,將由新解決方案取代。

應收集舊式系統的詳細資訊,以便您知道哪些系統可以停用、何時停用以及對任何其他系統的影響。

要使用的開發工具清單

將用於實施的工具概要;工具應包括:

  • 文檔工具
  • 問題跟蹤工具
  • 部署工具
  • 構建工具

需要訪問Adobe支援門戶的用戶清單

需要訪問Adobe支援門戶的所有用戶和角色的清單。

該清單通常由解決方案架構師和/或客戶IT員工組成。

日誌檔案分析

分析,連同生成的建議,定義監控解決方案所需記錄的內容:

  • 要記錄的活動
  • 粒度級別
  • 記錄每個活動的資訊

已測試並啟AEM用維護任務(特定)

Test並啟AEM用維護任務,如:

  • 壓實
  • 系統清潔
  • 工作流清除

遷移計畫

記錄遷移;包括

  • 遷移時間表
  • 內容維護計畫,根據遷移策略

遷移策略

對映射到新解決方案的現有內容、內容體系結構和格式的完整描述。 它應包括:

  • 技術詳細資訊(如果可能)
  • 煙霧test以在遷移後執行,以驗證遷移的內容

它還應建議如何在遷移到新系統實際運行期間使內容保持最新(或盡可能保持最新)。 這意味著內容凍結、雙重發佈或Alpha系統的維護。

監視 — CPU

監視解決方案對系統CPU的使用:

  • 平均

監視 — 磁碟I/O

監視解決方案的磁碟輸入和輸出速率:

  • 平均

監視 — 磁碟空間

監視解決方案對磁碟空間的使用:

  • 平均
  • 隨著時間的推移而增長

您應通過以下方式監視使用:

  • 儲存庫
  • 日誌檔案

監視 — 外部系統

監視解決方案與外部系統之間的任何連接:

  • 流量率
  • 穩定

監視 — 網路頻寬

監控解決方案對網路頻寬的使用:

  • 平均流量
  • 穩定

監視 — 請求

監視對解決方案的請求。

監視 — 安全點

在定義的安全點進行監視。

監視 — 系統

監控整個系統;例如:

  • 可用性
  • 平均效能
  • 效能峰
  • 警報

監控 — 閾值和干預

監控解決方案定義的閾值以及實施干預步驟以減少負載。

監控概念

要應用於您的解決方案的監控概念;合併:

  • AEM標準監控
  • 系統監控
  • 客戶特定監控需求

監控潛在弱點

應確定和定義可能容易失敗的具體點。 還應定義與這些任務相關的任何監視任務。

例如(其中包括):

  • 關鍵工作流
  • 事務處理
  • 整合點

向系統工程師傳達監控策略

確保系統工程師和操作人員瞭解並瞭解任何監控策略。

監視報告 — 就地結構

定義:

  • 何時生成監視報告
  • 他們應該送給

操作任務文檔

記錄了所有操作任務,並定義了其頻率。

操作手冊

手動提供成功運行和維護解決方案所需的所有資訊:

  • 所有操作任務
  • 關鍵聯繫人
  • 部署計畫
  • 部署前/部署後核對清單
  • 其他關鍵任務

還應詳細說明以下方面的實施概念:

  • 滿足效能KPI
  • 擴展解決方案以繼續滿足這些KPI

已準備包

已構建並交付軟體包以便部署。

滲透Test

滲透test(非正式地稱為筆test)是對電腦系統的攻擊,該攻擊會查找安全缺陷,從而可能獲得對電腦功能和資料的訪問。

滲透Test — 通過

所有必需的條件都已通過。

滲透Test — 結果

為業務建立的報告,解釋滲透test結果。

效能和可擴充性概念

概念性文檔,介紹如何確保實施滿足效能KPI要求,以及如何擴展解決方案以使其繼續滿足這些KPI要求。

效能基準

效能基準用於定義效能測試、耐久性測試和監控。 它通過評估解決方案和系統硬體的效能特性來做到這一點。

效能KPI

這些指標定義衡量系統效能所需的主要績效指標(KPI)。 一些示例包括頁面載入時間、伺服器響應時間和資料庫查詢效能。

效能Test — 報告

為業務建立的報告,詳細列出效能test的結果。

效能Test — 結果匹配效能KPI

結果必須與定義的KPI和績效預期相匹配。

基於個人的測試概念

基於角色的測試是基於經驗設計中概述的不同角色的方法。 它還test帳戶及其相關權限級別。

這通常用於用戶驗收測試(UAT)。

根據要求文檔測試和驗證POC

概念驗證(POC)將根據要求進行評估,以確保兩者一致。

部署後核對表

一個核對表,用於定義每次部署後要執行的一系列檢查和任務。

部署前核對表

一個核對表,用於定義在每次部署前要執行的一系列檢查和任務。

生產環境基準效能Test

通常在的標準安裝上運行基線testAEM。 然後,將它用作test實現和硬體的基準。

生產環境就緒

確認已準備好生產環境,並部署了自動部署。

業務利益相關方的生產簽約

在生產環境上實現之前,必須授予生產簽名(PSO)。 這是對即將投入生產的版本以及任何已知問題的審查的結果。 註銷是「開始即時」計畫的一部分。

生產簽出流程和策略

在將軟體包移至生產環境之前獲取生產簽名所需的策略和流程。

項目通信計畫

為業務利益相關方和項目團隊定義溝通計畫。

項目工作 — 最終估計

初始估計 是按照實施的高要求而制定的。

現在對這些項目進行審查、改進和擴大,以提供最終估計數。 估計應由每個適當的項目負責人提供,包括項目管理、咨詢、架構、測試和開發。

該等估計用於資源籌措和預算編製。

項目工作 — 初始估計

初步估計數是高水準的,根據執行工作的高水準要求作出。 在稍後階段將審查和改進這一情況。

項目組織

概述項目和團隊的組織和報告結構所需的文檔。

通常採用表格或包含圖表來顯示時間表和責任的可視概覽。 有許多工具可幫助解決此問題。

項目範圍文檔

項目範圍文檔要求您標識並記錄以下清單:

  • 特定項目目標
  • 交付項
  • 功能
  • 函數
  • 任務
  • 截止時間
  • 計畫的工作

它涵蓋為實施項目必須取得的成果以及必須完成的工作

定義的目錄中的項目狀態報告

按商定時間表和所需格式交付的項目狀態報告。

概念驗證(POC)

概念驗證(POC)為解決方案實現了有限範圍的功能。

該方案應旨在驗證方案的可行性,驗證方案是否滿足要求,並證明其有潛力。

清除規則

維護AEM多個版本的資產和內容。 清除規則的設計和配置是定期刪除舊版本,以保持儲存庫的運行狀況和大小。

質量報表格式與Cadence

定義質量報告所需的內容和格式,以及必須交付的頻率。

發佈協調

項目經理將協調發放至生產所需的所有角色。

發行說明

發行說明是發行文檔的一部分。 發行說明應包括:

  • 先決條件
  • 包括
  • 已解決
  • 版本中的已知問題

它與Runbook一起用於執行安裝前和安裝後步驟和檢查。

注意

有關示例,請參見 發AEM行說明

在生產環境上運行的版本

最終版本正在運行並在生產中處於活動狀態。

相關合同條款

您應強調與項目實施相關的具體合同條款;例如合同里程碑、發票期或工作人員要求。

報告Cadence

與客戶一起定義向他們提交報告的頻率。

儲存庫優化

資料從不被tar檔案中覆蓋,即使只更新現有資料,磁碟使用率也會增加。

為了抵消儲存庫不斷增大的規模,我們制定了優化策略來刪除過時的資料。

請求在Adobe支援門戶中設定項目部分

在Adobe支援門戶中設定項目的正式請求。

要求文檔

這套檔案包括功能和非功能需求以及估計的工作。

可用於支援的資源投入使用

確保投入使用所需的所有角色都配備了人員並可用。

風險評估

風險評估由客戶的IT和/或安全部門執行。

它評估項目的技術和業務風險。 該解決方案需要進行評估以確保符合安全策略。

風險緩解計畫

風險緩解計畫包括風險評估。 它們一起覆蓋:

  • 已識別風險
  • 可能解決實施中出現的風險

ROI預期

定義附加到解決方案的投資回報(ROI)預期。

它們旨在通過界定與估計投資有關的預期收益/利潤,從經濟角度表明解決方案的效率。

角色和權利概念

詳細說明與新應用程式所需的角色和訪問權限相關的概念,包括以下內容的高級概述:

  • 角色
  • 個群組
  • 個使用者
  • 權限
  • 以及用戶管理和資源調配

角色和權限概念符合安全准則

審查「角色和權利」概念,以確保它符合安全策略。

角色和權限規範

基於「角色和權限」概念的詳細說明。

安全架構Recommendations

Recommendations與軟體和硬體架構的安全性相關。

基於安全性的編碼准則

這些准則根據安全要求定義了開發編碼應如何完成,例如:

  • 命名約定
  • 框架指南
  • API使用

安全核對表

項目特定項目核對表,基於安全概念以及確保符合解決方案所需的任何附加策略。

這通常也作為Runbook中部署後步驟的一部分包含。

安全概念

定義並記錄應用程式、體系結構和基礎架構所需安全配置的詳細資訊。

安全概念草案

包含以下安全設定的高級大綱:

  • 應用
  • 體系結構
  • 基礎

列出和評估的安全問題

列出並評估解決方案的所有安全問題;包括精力估計。

業務利益相關方的安全簽名

從利益相關方處簽收,以確保安全實施符合策略和期望。

設定支援流程

設定所需的支援流程。

第三方系統的SLA

確保在實施和支援期間提供服務級別協定(SLA)並將其傳達給開發和運營團隊。

煙霧Test概念

煙霧test由一組定義的步驟組成,這些步驟test瞭解決方案的關鍵功能,以確保解決方案的基本操作和功能。

在安裝或部署後,在任何環境上執行這些操作。

為系統驗證執行的煙霧Test

應在所有系統上運行煙霧Test,以確保解決方案在安裝或部署到任何環境時的基本功能正確運行。

軟體體系結構策略

軟體架構的高級策略;包括服務、servlet、框架和其他實施決策。

已建立解決方案審查委員會並會議禮賓集

解決方案審查委員會通常由客戶利益相關方組成。

董事會定期舉行會議,以持續檢討現時範圍之規定及相關規範。 目的是確保符合成功定義和標準,並為制定要求提供投入。

解決方案Runbook

解決方案的安裝說明,以及安裝時要執行的基本操作任務。

解決方案簽收和驗收流程

簽署和接受過程概述了在解決方案能夠發佈到生產環境中之前必須滿足的標準。

它也可以作為合同上的里程碑。

特殊功能概念

任何被認為超出平台正常開發範圍的特殊功能的初始AEM概念。

特殊功能規範

任何被視為超出平台正常開發範圍的特殊功能的詳細AEM資訊。

規範指南

客戶關於規範應如何執行的任何指導原則。

定義並傳遞規範審核和審批流程

應制定客戶簽署規格的明確流程。 這一過程確保了要求的明確性和穩固性。

為管理員培訓選AEM擇的員工

需要培訓以管理解決方案的內部員工。

為作者和最終用戶培訓選擇的員工

需要培訓的內部員工編寫解決方案。

利益相關方

利益相關方是與項目有重大利害關係的關鍵人員和/或角色。 有些將為項目預算捐款。

利益相關方可以是內部和/或外部。

利益相關方瞭解成功定義和標準

確認實際實施小組以外的所有利益相關方都瞭解:

  • 成功定義
  • 成功標準

利益相關方瞭解項目和期望

確認實際實施團隊之外的所有利益相關方都與整個項目和預期保持一致,無論是項目團隊內部還是客戶內部。

狀態報表格式定義

狀態報告是通信的關鍵工具。 格式應與客戶的任何報告要求相一致。

成功標準和定義

客戶、項目贊助商和項目經理或顧問應指定:

  • 為項目定義成功結果的內容。
  • 滿足成功定義所需的具體標準。

這些標準用於確保滿足成功的標準:

  • 作為KPI的基礎。
  • 在整個實施過程中做出決策時。

支援驗證報告的問題

Quality Lead的部分職責是確保在測試時有可用資源支援任何用戶。 例如,在測試時幫助用戶報告問題,並幫助根據test環境驗證問題。

支援流程和訪問Adobe支援門戶

訪問Adobe支援門戶對於提交有關實施過程中可能出現的任何基於產品的問題的票證至關重要。

訪問權應分配給團隊的關鍵成員。

系統體系結構定義

針對解決方案所有環境的體系結構的初步建議書和定義。

系統體系結構文檔

詳細描述系統架構的文檔;包括所有環境的介面、網路位置和整合,以及其他資訊。

系統體系結構安全概念

如何使系統體系結構符合任何安全策略的高級概述。 這可以包括:

  • 防火牆和防火牆規則
  • 安全區
  • 本地和一般交通管理員
  • Web伺服器
  • 代理和反向代理

確定和驗證系統風險因素

在風險評估(或其他審閱)中發現的任何風險因素均予識別及評估:

  • 每個風險中隱含的風險水準
  • 以及解決這些問題所需的任何實施更改的估計工作量。

團隊瞭解成功定義和標準

確認整個團隊都瞭解成功定義和標準。

團隊瞭解溝通計畫

確認團隊的所有成員都知道應該與客戶進行溝通的人員,以及有關方式和時間的詳細資訊。

團隊瞭解項目和期望

與整個項目和預期保持一致,既包括項目團隊內部,也包括客戶內部。

技術要求

這些要求是針對支援該解決方案的服務的技術實施而提出的。

已驗證技術風險因素

確定和驗證潛在的技術風險。 技術風險可包括:

  • 跨站點指令碼
  • 面向最終用戶的輸入欄位
  • 基礎
  • 技術時代
  • 整合數
  • 和依賴

技術規格

《技術規範》包括(除其他資訊外):

  • 介面
  • 配置
  • API
  • 支援解決方案要求的服務

模板規範

所需模板的規範。 這些應涵蓋細節,包括parsys、藍圖和繼承映射等。

規格基於業務要求和經驗要求。

Test案例

Test案例具體說明了執行解決方案功能測試所需的詳細步驟。

Test內容

test內容應盡可能接近生產內容。 它必須具有足夠大的選擇範圍,以便能夠測試所有方案。

Test環境就緒

確保test環境已準備就緒,並部署了自動化部署,以確保所有發佈候選代碼都是最新的以便進行測試。

Test報告

詳細列出測試結果的報告;包括:

  • 缺陷
  • 已執行的test案件狀態
  • 其他與質量相關的主題

應當指出:

  • 應允許任何測試團隊保持中立並提供測試結果。
  • 項目經理有責任評估結果的任何影響並決定採取適當行動。

Test套件

選擇自動化套件和工具。 這些功能將用於自動化test,包括用於使用案例的自動化。

Test工具套件已選擇

為用例自動化和其他test執行任務選擇的自動化套件和工具。

測試概念

測試概念是項目測試的高層次概要;包括QA 、 UAT 、效能、安全性和整合測試。

測試計畫

這些計畫更詳細地概述了為每個發展階段執行test的情況,並以 測試策略

測試範圍

這些要求是針對支援該解決方案的服務的技術實施而提出的。

測試策略

測試策略概述了質量保證和用戶驗收測試的高級策略。 這包括時間表、報告順序和執行。

第三方整合概念

用於與第三方系統整合的體系結構和系統級概念。

第三方整合規範

第三方系統支援的功能和整合要求(功能和非功能)的詳細資訊。

第三方安全概念

用於確保任何第三方整合的安全性的概念。 必須符合相應的安全策略。

第三方整合系統

確保所有第三方系統都可用並提供相應的文檔,以便進行整合實施。

已啟用第三方系統訪問

授予與第三方系統一起使用的各個角色的必需訪問權限。

第三方測試概念

定義:

  • 用於測試整合的使用案例
  • 與任何第三方應用程式相關的功能

閾值定義

定義系統中監控點的關鍵值。

例如:

  • 未發送日誌的千位元組(KB)在主伺服器實例上生成警告
  • 在主伺服器上生成警告之前允許的每個事務的平均延遲毫秒數

時間軸和里程碑

這應定義項目時間表和合同里程碑,用於:

  • 開票。
  • 與成功定義、成功標準和KPI相協調。

項目工作總量

應合併項目每個線索的所有努力估計數;包括開銷、開發、系統工程、建築和測試工作。

如果協定中包括支助級別,也應包括支助和行動工作。

培訓材料

培訓課程中使用的材料。 材料應專門為解決方案建立,並設計為與「使用手冊」一起使用。

瞭解項目範圍和期望

適當的角色應確認他們完全理解:

  • 項目範圍
  • 所有客戶期望
  • 這是每個人、每個階段在項目中做出的所有決定的基礎

URL處理概念

您的URL處理概念應包括AEM特定URL功能,包括:

  • 虛榮URL
  • 連結外部化
  • 錯誤頁
  • 映射

該概念還應包括:

  • 任何重寫規則
  • Web伺服器上的虛擬主機
  • SEO注意事項,如robots.txt
  • 站點地圖

使用案例

用例是實現目標所需的操作或事件步驟的清單。 通常,它們定義角色和解決方案之間的交互。 角色可以是用戶或外部系統。

已轉換為Test方案的使用案例

Test方案基於技術和業務使用案例。 它們用於test解決方案行為與預期一致。

使用手冊

使用手冊為解決方案的用戶提供資訊和幫助:

  • 作者
  • 超級用戶
  • 管理員

已驗證預算計畫

預算計畫必須由所有利益攸關方審查和驗證。 他們需要檢查詳細資訊,如開票、金額和預算報告的方法/時間。

白框Test結果

白盒測試是一種test應用程式內部結構或工作方式的方法,而不是其功能。 白盒測試可以在軟體測試過程的單元、整合和系統層面進行。

工作流規範

根據「工作流概念」,這些規範應詳細定義建立完整工作流的步驟。

每個工作流的規範應包括(至少):

  • 用例
  • 角色
  • 步驟
  • 結果
  • 錯誤處理

工作流概念

工作流允許您自動AEM執行活動。 「工作流概念」概述:

  • 需要自動化的流程
  • 將影響的AEM服務和角色

本頁內容