Glossar glossary

Dieses Glossar listet (alphabetisch) alle lieferbaren Dokumente in der Projektcheckliste auf.

Akzeptanz durch die Interessenträger der Wirtschaft acceptance-from-business-stakeholders

Die Akzeptanz durch die Interessenträger aus der Wirtschaft bestätigt, dass sie als wichtige Interessenträger mit der Lösung in Einklang stehen und ihre Zustimmung dazu gegeben haben, wie die Geschäftsanforderungen dem Geschäftsfall entsprechen.

Akzeptanztests acceptance-tests

Akzeptanztests werden durchgeführt, wenn eine Anwendung produktionsbereit ist. Die Tests werden von einer Gruppe durchgeführt, die die verschiedenen Arten von Endbenutzern darstellt, wobei Echtzeit-Szenarien verwendet werden.

Mithilfe von Akzeptanztests wird Folgendes bestätigt:

Je früher Sie Ihre Akzeptanztests planen und entwerfen, desto einfacher wird die endgültige Implementierung. Sie sollten gemeinsam mit dem Kunden und Ihrem Qualitätssicherungsteam definiert werden.

Auch wenn Sie möglicherweise nicht in der Lage sind, alle Details zu Beginn des Projekts zu definieren, sollten Sie die ersten Definitionen diskutieren und vereinbaren. Die Akzeptanztests basieren wahrscheinlich auf den grundlegenden Anforderungen (funktionale und leistungsbezogene Anforderungen).

Zugriff auf das Testsystem koordiniert access-to-test-system-coordinated

Stellen Sie sicher, dass alle Rollen die erforderlichen Systemzugriffsstufen erhalten haben.

Adobe-Sicherheitscheckliste adobe-security-checklist

Die Adobe-Sicherheitscheckliste ist die offizielle Checkliste, die bereitgestellt wird, um sicherzustellen, dass AEM bei der Installation sicher ist. Sie enthält die Sicherheitsmaßnahmen und Überprüfungsschritte, die erfolgen müssen, um die Integrität Ihrer Instanz zu gewährleisten.

Einrichten von Adobe Support Portal-Projekten adobe-support-portal-project-set-up

Das Adobe Support Portal ermöglicht es Implementierungspartnern und Kunden, die AEM-Implementierung als Projekt im Support-Portal einzurichten.

Details können registriert werden; z. B. über die implementierten Technologien und Versionen. Diese sorgen für Transparenz zwischen dem Kunden und der Adobe.

AEM Administratorschulung aem-administrator-training

Schulung für Verwaltungspersonal der Lösung. Siehe Adobe Training Services für weitere Informationen.

AEM-Autorenschulung aem-author-training

Schulung für Mitarbeiter, die Inhalte für die Lösung erstellen (Authoring). Siehe Adobe Training Services für weitere Informationen.

AEM Zertifizierungsprüfung aem-certification-exam

Stellen Sie sicher, dass die entsprechende Person registriert ist, um die relevanten Zertifizierungsprüfungen.

AEM zertifiziert aem-certified

Stellen Sie sicher, dass die entsprechende Person die entsprechenden Zertifizierungsprüfungen.

AEM technische Schulung aem-technical-training

Bieten Sie technische Schulungen für die gewünschten Rollen an, z. B. für Entwickler, Architekten, Ingenieure und kaufmännische Fachleute.

Vereinbarung über KPIs, die als Ziele für das Projekt definiert wurden agreement-on-kpis-defined-as-goals-for-the-project

Key Performance Indicators (KPIs) helfen einer Organisation, den Fortschritt in Bezug auf organisatorische Ziele zu definieren und zu messen. Sobald eine Organisation ihren Auftrag analysiert und ihre Ziele definiert hat, muss sie die Fortschritte bei der Erreichung dieser Ziele messen. KPIs bieten einen Messmechanismus.

Business- und Performance-KPIs ausrichten align-business-and-performance-kpis

Die Abstimmung Ihrer Geschäfts- und Leistungs-Key Performance Indicators (KPIs) trägt dazu bei, alle beteiligten Personen und Prozesse innerhalb des Unternehmens zusammenzuführen. Dies wiederum trägt dazu bei, die Zeit und den Aufwand zu reduzieren, die zum Erreichen der Geschäftsziele und zur Erfüllung des vorgeschlagenen Zwecks erforderlich sind.

Abstimmung der Inhaltsarchitektur mit KPIs alignment-of-content-architecture-with-kpis

Stellen Sie sicher, dass die vorgeschlagene Inhaltsarchitektur mit den relevanten KPIs (Key Performance Indicators) abgestimmt ist.

Ausrichtung der Kunden-Roadmap an der Projekt-Timeline alignment-of-the-customer-roadmap-with-project-timeline

Die Customer Roadmap besteht aus übergeordneten Meilensteinen und Geschäftszielen. Die Timeline des Projekts muss dieser Strategie entsprechen und sie mit ihr in Einklang bringen, sodass alle potenziellen Risiken und/oder Abweichungen hervorgehoben und verfolgt werden müssen.

Definition der Anwendungsarchitektur application-architecture-definition

Die Anwendungsarchitektur muss das Verhalten der geplanten Anwendungen klar definieren.

Der Schwerpunkt liegt auf Folgendem:

Anwendungsspezifische Wartungsaufgaben definiert application-specific-maintenance-tasks-defined

Neben den standardmäßigen Adobe Experience Manager (AEM)-Wartungsaufgaben müssen Sie auch andere Betriebsaufgaben definieren, die für die laufende Wartung der Lösung ausgeführt werden müssen.

Angemessenes Schulungspersonal appropriately-trained-staff

Stellen Sie sicher, dass Ihr Team aus Mitarbeitern mit entsprechender Schulung besteht. Für Projektteams wird empfohlen, alle folgenden Elemente zu verwenden:

Architekturdiagramm architecture-diagram

Das Architekturdiagramm ist eine grafische Darstellung der Architektur. Er umfasst die Darstellung von:

Architekturentwurf architecture-draft

Dies bietet einen allgemeinen Überblick über die System- und Lösungsarchitektur. In dieser Phase wird der Entwurf zu einem späteren Zeitpunkt überarbeitet und verfeinert.

Abnahme des Architekturüberprüfungsgremiums architecture-review-board-sign-off

Der Architekturüberprüfungsausschuss ist ein organisationsübergreifendes Gremium, das:

Die Überprüfungskommission muss für alle Mitwirkenden an der Architektur repräsentativ sein. In der Regel werden sie aus einer Gruppe von Führungskräften bestehen, die für die Überprüfung und Pflege der Gesamtarchitektur verantwortlich sind.

Automatisierte Test-Suite, die für reale Inhalte und Ergebnisse im Vergleich zu KPIs angepasst ist automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Automatisierungsskripte und grundlegende automatisierte Anwendungsfälle:

Automatisierte Teststrategie automated-testing-strategy

Diese Strategie definiert ein Framework für wiederverwendbare automatisierte Skripte zusammen mit dem vom Qualitätssicherungsteam (QA) geplanten Ansatz. Darin wird der Gesamtplan für Automatisierungstests erläutert, um Folgendes sicherzustellen:

Automatisierte Teststrategie, die mit realistischer und erwarteter Last validiert wurde automated-testing-strategy-validated-against-realistic-and-expected-load

Die automatisierte Teststrategie muss entsprechend dem Inhalt und der erwarteten Belastung der Lösung validiert und angepasst werden.

Automatisierungsstrategie automation-strategy

Die Automatisierung von Bereitstellungen sorgt für eine schnellere und konsistente Bereitstellung. In der Automatisierungsstrategie wird die Konfiguration solcher Automatisierungsmechanismen beschrieben. einschließlich:

Kenntnis des Kommunikationsplans aware-of-communication-plan

Das gesamte Projektteam und alle Interessengruppen müssen bestätigen, dass sie über Folgendes informiert sind:

Kenntnis der Erfolgsdefinitionen und -kriterien aware-of-success-definitions-and-criteria

Das gesamte Projektteam und alle Interessengruppen müssen bestätigen, dass sie über Folgendes informiert sind:

Sicherungs- und Wiederherstellungskonzept backup-and-restore-concept

Das Sicherungs- und Wiederherstellungskonzept beschreibt die technischen Funktionen, die in der Lösung implementiert werden. Es wird von den Sicherungs- und Wiederherstellungsrichtlinien des Unternehmens verlangt.

Testen von Sicherung und Wiederherstellung backup-and-restore-tested

Ein vollständiger End-to-End-Test basierend auf dem Sicherungs- und Wiederherstellungskonzept.

Geschäftsszenario(e) business-case-s

In einem Geschäftsfalldokument werden die Argumente vorgestellt, die im Zusammenhang mit dem Ergreifen der Aktion, dem Ergreifen alternativer Maßnahmen (falls verfügbar) oder dem Nichtergreifen von Maßnahmen stehen. Die Argumente sollten ausgewogen sein, auf konkreten Fakten (wo immer möglich/relevant) beruhen und sowohl Nutzen als auch Risiken für alle Fälle hervorheben.

Ein Falldokument sollte eine klare Definition aller Optionen enthalten und mit einem überzeugenden Argument für die Umsetzung der vorgeschlagenen Lösung schließen.

Business Analyst versteht Projektumfang und Erwartungen business-analyst-understands-scope-of-project-and-expectations

Geschäftsanalyst sollten bestätigen, dass sie Folgendes vollständig verstehen:

Geschäfts-KPIs business-kpis

Unternehmen verwenden Key Performance Indicators (KPIs), um ihren Erfolg bei der Erreichung von Zielen zu bewerten.

Geschäfts-KPIs definieren messbare Werte, die zeigen, wie effektiv ein Unternehmen wichtige Geschäftsziele erreicht. Es ist wichtig, KPIs auszuwählen, die für Ihr Unternehmen/Szenario geeignet sind, mit klaren Definitionen dessen, was sie sind, wie sie gemessen werden, wie sie verwendet werden und von wem.

Dokumentation zu Geschäftsanforderungen business-requirements-documentation

In einem Dokument zu Geschäftsanforderungen (Business Requirements Document, BRD) wird die Geschäftslösung für ein Projekt beschrieben, das die Geschäftsanforderungen und Erwartungen des Kunden klar beschreibt. Die BRD unterscheidet auch zwischen der Geschäftslösung und der technischen Lösung.

Bei der Prüfung der Geschäftslösung sollte dieses Dokument die Frage beantworten: „Was will das Unternehmen erreichen?“

Abnahme der Geschäftsabschlüsse bei allen erforderlichen Anpassungen der identifizierten und an den ROI- und KPI-Erwartungen angepassten Lösung oder Architektur business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

Die Prozesse der Risikobewertung und Penetrationstests können Probleme und Ergebnisse hervorbringen, die in der Architektur oder Entwicklung der Lösung angesprochen werden müssen.

Alle aus diesen Prozessen resultierenden Anpassungen müssen vom Unternehmen überprüft und genehmigt und mit den Gesamtzielen abgeglichen werden.

Caching-Strategie caching-strategy

In der Cachestrategie wird beschrieben, was für den Endbenutzer zwischengespeichert wird. Sie muss mit den Leistungs-KPIs konform sein.

Beispielsweise können Elemente wie Bilder, JavaScript und andere Serverdateien zwischengespeichert werden, um die Leistung einer Lösung zu verbessern.

Codierungsrichtlinien coding-guidelines

Die Kodierungsrichtlinien definieren grundlegende Prinzipien, die die Entwickler bei der Entwicklung der Lösung beachten sollten. Dazu gehören unter anderem:

Kommunikationshandbuch communicate-operations-manual

Stellen Sie sicher, dass alle entsprechenden Rollen das Betriebshandbuch erhalten haben.

Bericht zu Leistungstests für Kommunikation communicate-performance-test-report

Stellen Sie sicher, dass alle entsprechenden Rollen den Leistungstestbericht erhalten haben.

Versionshinweise kommunizieren communicate-release-notes

Stellen Sie sicher, dass alle relevanten Rollen die Versionshinweise erhalten haben.

Dem Team Umfang und Erwartungen kommunizieren communicate-scope-and-expectations-to-team

Stellen Sie sicher, dass das Projekt-Team den Projektumfang und die Bereitstellungsanforderungen vollständig kennt und mit ihnen im Einklang steht.

Kommunizieren von Schulungsmaterial und Benutzerhandbüchern communicate-training-materials-and-user-guides

Stellen Sie sicher, dass alle entsprechenden Rollen die Schulungsmaterialien und Benutzerhandbücher erhalten.

Einhaltung der Kundensicherheitsanforderungen compliance-with-customer-security-requirements

Stellen Sie sicher, dass alle Sicherheitsanforderungen des Kunden erfüllt sind.

Einhaltung des Sicherheitskonzepts compliance-with-security-concept

Stellen Sie sicher, dass das Sicherheitskonzept vorhanden ist.

Beziehungskonzept für Komponenten und Vorlagen components-and-templates-relationship-concept

Die Übersicht über die Vorlagen und Komponenten, die in der neuen Anwendung verwendet werden. Enthält Details wie Vererbungsregeln, Berechtigungen und Beziehungen.

Spezifizierung der Beziehungen zwischen Komponenten und Vorlagen components-and-templates-relationship-specification

Details zum Beziehungskonzept für Komponenten und Vorlagen.

Komponentenspezifikation components-specification

Spezifikationsdetails für jede der zu implementierenden Komponenten.

Konzept für die Nachahmung externer Schnittstellen concept-for-mock-ups-of-external-interfaces

Das Konzept der Entwicklung mit und des Testens externer Schnittstellen, die für Entwicklungs- oder Testumgebungen möglicherweise nicht offen/verfügbar sind.

Planen/implementieren Sie Modelle dieser Schnittstellen, um sicherzustellen, dass Tests dem produktionsähnlichen Verhalten möglichst nahe kommen.

Dokument zur Inhaltsarchitektur content-architecture-document

Dokumentation der vorgeschlagenen Architektur des Inhalts. Die Einzelheiten sollten (unter anderem) Folgendes umfassen:

Für die Migration validierte Inhalte content-validated-for-migration

Der alte Systeminhalt wird geprüft und der ausgewählte Inhalt wird für die Migration zur neuen Lösung validiert.

Vertragsentwurf contract-draft

Ein erster Entwurf des Rechtsvertrags.

Aktuelle Inhaltsstruktur und -format current-content-structure-and-format

Dokumentation der aktuellen Inhaltsarchitektur und -format. Damit wird die zukünftige Inhaltsarchitektur generiert. Es wird auch für das Migrationskonzept verwendet.

Richtlinie zur Kundensicherung und -wiederherstellung customer-backup-and-restore-policy

Richtlinien des Kunden bezüglich:

Richtlinien zur Kundenkodierung customer-coding-guidelines

Alle Richtlinien/Anforderungen des Kunden, wie die Entwicklung erfolgen soll.

Bereitstellungs-/Veröffentlichungsrichtlinien des Kunden customer-deployment-release-policies

Richtlinien des Kunden, die definieren, wie und wann Bereitstellungen/Veröffentlichungen vorgenommen werden können.

Dazu gehören häufig Zeitpläne, Planungs- und Abmeldeanforderungen.

Richtlinien oder Anforderungen für die Kundenüberwachung customer-monitoring-policies-or-requirements

Kundenrichtlinien und -anforderungen zu dem, was überwacht werden soll. Diese Empfehlungen ergänzen alle Empfehlungen, die im Überwachungskonzept festgelegt sind.

Versionsplanung für die Kundenproduktion customer-production-release-schedule

Der Zeitplan, der vom Kunden für Versionen in den Produktionsumgebungen definiert wird.

Richtlinien und Anforderungen für Kundenberichte customer-reporting-policies-and-requirements

Alle Richtlinien und/oder Anforderungen, die der Kunde in Bezug auf die Berichterstellung hat. Dazu können gehören:

Kunden-Roadmap customer-roadmap

Erstellung eines Fahrplans für die wichtigsten technologischen und geschäftlichen Meilensteine. Diese Roadmap wird dann dem Kunden mitgeteilt.

Kundensicherheitsrichtlinien customer-security-policies

Der Kunde (Business und IT) verfügt über Richtlinien, die die erforderlichen Sicherheitsstufen für die Lösung definieren. Dazu können gehören:

Richtlinien für Kundenspezifikationen customer-specification-guidelines

Alle Richtlinien des Kunden bezüglich Format, Lieferung und Abnahme von Spezifikationen.

Kundentestberichte customer-test-reports

Berichte des Kunden an den Qualitätsleiter während des Zeitraums des Benutzerakzeptanztests (UAT).

Dokumentierte Anpassungen und Hotfixes mit Auswirkungen auf Upgrades customizations-and-hotfixes-that-affect-upgrades-documented

Alle angewendeten Anpassungen und/oder angewendeten Hotfixes müssen dokumentiert werden, da sie sich auf zukünftige Upgrades auswirken können:

Täglicher Bericht zum Benutzerakzeptanztest daily-user-acceptance-test-report

Berichte oder Sitzungen, die aus dem Benutzerakzeptanztest (UAT) resultieren. Sie sollten detailliert sein:

Standardsicherheit aktiviert default-security-enabled

Stellen Sie sicher, dass die standardmäßigen Sicherheitseinstellungen für AEM aktiviert/implementiert wurden.

Bereitstellungs-/Veröffentlichungsrichtlinien und -prozesse deployment-release-policies-and-processes

Formalisierte Richtlinien, die sowohl die Bereitstellung als auch die Release(s) Ihres Projekts abdecken. Dazu können gehören:

Bereitstellungsintervall festgelegt deployment-cadence-established

Definieren Sie die erforderliche Häufigkeit von Bereitstellungen in allen Umgebungen.

Entwicklungsmethode development-methodology

Eine Software-Entwicklungsmethodik besteht darin, den gesamten Prozess der Softwareentwicklung in verschiedene Phasen (oder Phasen) zu unterteilen, die jeweils unterschiedliche Aktivitäten aufweisen. Ziel ist es, die Planung und das Management zu verbessern.

Bei der Definition der Methodik sollten Sie bestimmte Lieferziele und Artefakte vordefinieren, die vom Projektteam erstellt und ergänzt werden, um Ihre Anwendung zu entwickeln oder zu pflegen.

Definition der Entwicklungsrolle development-role-definition

Definieren Sie, welcher Entwickler und/oder welche Rolle IT- (Leistungs- oder andere) und/oder Komponententests innerhalb der Lösung ausführt.

Bereit für Entwicklungsumgebung development-environment-ready

Stellen Sie sicher, dass die Entwicklungsumgebung mit den für die Automatisierung von Bereitstellungen erforderlichen integrierten Tools konfiguriert ist.

Entwicklungsteam versteht Projektumfang und Erwartungen development-team-understands-scope-of-project-and-expectations

Das Entwicklungsteam sollte bestätigen, dass es Folgendes vollständig versteht:

Dialogfeldspezifikation dialogs-specification

Details zu den für die Lösung erforderlichen Dialogfeldern.

Einrichten der Dokumententwicklungsumgebung document-development-environment-setup

Dokumentation der Entwicklungsumgebung.

Einrichten der Dokumentproduktionsumgebung document-production-environment-setup

Dokumentation der Produktionsumgebung.

Einrichtung der Dokumenttest-Umgebung document-test-environment-setup

Dokumentation der Testumgebung.

Stabilitätstest durability-test

Der Stabilitätstest zeigt die Leistung der Lösung unter einer bestimmten Belastung an. Anhand der Tests wird gemessen, wie lange die Lösung überlebt, wenn sie der Schwelle ausgesetzt wird, und wie hoch die Leistung ist.

Ausgeführter Stabilitätstest durability-test-executed

Durchführung der Dauerhaltbarkeitsprüfung(en).

Umgang mit Fehlern error-handling-concept

Die Fehlerbehebung bezieht sich auf die Antizipierung, Erkennung und Behebung von Programmierungs-, Anwendungs- und Kommunikationsfehlern.

Dokumentation zur Fehlerbehandlung error-handling-documentation

Detaillierte Dokumentation der vorgeschlagenen Fehlerbehandlung basierend auf dem Fehlerbehandlungskonzept.

Eskalationsprozesse escalation-processes

Definition aller Eskalationsprozesse. Für jede Projektebene gibt es separate Prozesse:

Regelmäßige Qualitätsüberprüfungssitzungen einrichten establish-regular-quality-review-sessions

regelmäßige Treffen zur Qualitätsüberprüfung mit den entsprechenden Teammitgliedern.

Struktur vorhandener Berechtigungen existing-permissions-structure

Dokumentation der vorhandenen Berechtigungssätze und Gruppen, die für die Legacy-Lösung oder innerhalb der Organisation definiert sind.

Vorhandene Systemzuordnung existing-systems-map

Ein Diagramm (oder eine Reihe von Diagrammen) der vorhandenen Systeme und Abhängigkeiten.

Erwartete Erfolgsdefinitionen und -kriterien expected-success-definitions-and-criteria

Der Projektsponsor ermittelt die geschäftlichen Erwartungen in Bezug auf den Projekterfolg. Es ist wichtig, dass zu Beginn eines Projekts alle Erwartungen vorliegen, da diese alle Entscheidungen beeinflussen, die während der Implementierung getroffen werden.

Zu den Ausnahmen zählen:

Anforderungen für Experience Designs experience-designs-requirements

Anforderungen für das gesamte Erlebnis der Lösung. Dabei werden u. a. Faktoren wie Personalisierung, geräteübergreifende Persistenz und Benutzererlebnis berücksichtigt.

Erlebnisspezifikationen experience-specifications

Details zu den Anforderungen an das Experience Design.

Externe System- und Benutzerabhängigkeiten/Systemkontext external-system-and-user-dependencies-system-context

Ein Diagramm (oder eine Reihe von Diagrammen), in dem das gesamte Ökosystem der Lösung beschrieben wird. Dies sollte Elemente wie die externen Integrationen, Schnittstellen, Abhängigkeiten und Netzwerke umfassen.

Ausweichsystem und -verfahren fallback-system-and-procedure

Die Definition des Ausweichsystems:

Ausweichsystem und getestetes Verfahren fallback-system-and-procedure-tested

End-to-End-Test des Ausweichsystems.

Abnahme des Ausweichsystems von den Geschäftspartnern fallback-system-sign-off-from-business-stakeholders

Abonnieren Sie von den Interessenträgern aus der Wirtschaft, dass das Ausweichsystem und die damit verbundenen Verfahren die geschäftskritischen Funktionen gewährleisten.

Machbarkeitsbestätigung für KPIs feasibility-confirmation-on-kpis

Ergebnisse einer Machbarkeitsstudie sowohl für AEM als auch für die allgemeine Lösungskonzeption. Diese sollten anhand der KPIs gemessen werden, um sicherzustellen, dass sie erfüllt werden können.

Fertiggestellter Vertrag finalized-contract

Vor der Fortführung des Projekts ist ein abgeschlossener und unterzeichneter Vertrag erforderlich. Dies basiert auf der Vertragsentwurf.

Funktionalität der von den Interessengruppen akzeptierten Lösung functionality-of-the-solution-accepted-by-stakeholders

Bestätigung, dass die Interessenträger Folgendes vollständig akzeptieren:

Aufrufen des Live-Zeitplans go-live-schedule

Zeitlicher Ablauf und Zeitplan für die erforderlichen Aktivitäten für:

Definierte glückliche Pfade happy-paths-defined

Ein Happy Path ist ein Standardszenario ohne außergewöhnliche oder fehlerhafte Bedingungen. Es besteht aus der Folge von Aktivitäten, die ausgeführt werden, wenn alles wie erwartet funktioniert.

Hardwareschätzungen hardware-estimates

Anfängliche Schätzungen von:

Die Hardware steht zur Erfüllung der Anforderungen zur Verfügung hardware-will-be-available-to-fulfill-requirements

Bestätigung, dass alle Umgebungen über die erforderliche Mindest-Hardware verfügen.

Anforderungen auf hoher Ebene high-level-requirements

Die Definition der allgemeinen Anforderungen bietet eine allgemeine Aufschlüsselung der Anforderungen an das System, die Aspekte wie:

Grundlegende Details zu diesen Funktionen sind in der Regel bekannt, daher sollte dieses Dokument keine Schätzung sein.

Lösungsdesign auf hoher Ebene high-level-solution-design

Der allgemeine Lösungsentwurf erklärt die Architektur, die für die Entwicklung der Lösung verwendet wird. Das Architekturdiagramm bietet einen Überblick über das gesamte System und zeigt die wichtigsten Komponenten, die für das Produkt entwickelt werden, sowie deren Schnittstellen an.

Systemkarte high-level-system-map

Diese Systemkarte sollte ein sehr hohes Diagramm des Systems liefern. Es unterscheidet sich vom Lösungskontext insofern, als es sich um eine allgemeine Karte aller beteiligten Systeme handelt. Es gibt keine Schnittstellen auf diesem Diagramm.

Historische Inhaltsstruktur historical-content-structure

Definition der Inhaltsstruktur des Legacy-Systems. Dies dient als Referenz und auch bei der Vorbereitung der Migrationsstrategie.

Historische Leistungs- und historische Leistungs-KPIs historical-performance-and-historical-performance-kpis

Sie müssen Leistungsstatistiken und Leistungs-KPIs aus dem alten System erfassen und dokumentieren. Diese werden dann als Bezugspunkt und zum Benchmarking der neuen Lösung verwendet.

Identifizieren kritischer Schlüssellösungen/Funktionen identify-critical-key-solutions-functionalities

Eine Liste geschäftskritischer Funktionen.

Implementierung - Änderungen basierend auf den Ergebnissen von Penetrationstests implementation-changes-based-on-penetration-test-results

Implementierung aller erforderlichen Änderungen (die signiert wurden) an der Lösung basierend auf den Ergebnissen der Penetrationstests.

Implementierung - Automatisierte Teststrategie implementation-automated-testing-strategy

Einrichtung der Tools und Prozesse, die zur Unterstützung automatisierter Tests erforderlich sind.

Implementierung - Automatisierungsstrategie implementation-automation-strategy

Einrichtung des Werkzeugsatzes und der Prozesse, die zur Unterstützung der Automatisierung erforderlich sind.

Implementierung - Inhaltsarchitektur implementation-content-architecture

Implementierung der Inhaltsarchitektur, Tagging von Konzepten und Wiederverwendung von Inhalten.

Implementierung - Experience Design implementation-experience-design

Implementierung der Anforderungen zur Unterstützung von Experience Design.

Implementierung - Ausweichsystem und -verfahren implementation-fallback-system-and-procedures

Implementierung des Ausweichsystems und der zugehörigen Verfahren.

Implementierung - Integration implementation-integration

Implementierung von Integrationen in alle erforderlichen externen Systeme.

Umsetzung der Migrationsstrategie implementation-migration-strategy

Migration zusammen mit der Validierung von Inhalten und anderen Artefakten für die neue Lösung.

Implementierung - Rollen und Rechte implementation-roles-and-rights

Implementierung von Rollen und Rechten, Benutzern und Gruppen.

Implementierung - Sicherheitskonzept implementation-security-concept

Umsetzung aller Sicherheitsmaßnahmen, einschließlich der AEM.

Implementierung der Sicherheitssoftware implementation-security-software

Implementierung der Sicherheit der Software-Anwendung.

Implementierung - Sicherheitskonzept für die Systemarchitektur implementation-system-architecture-security-concept

Implementierung der Systemsicherheit.

Implementierung - URL-Verarbeitung implementation-url-handling

Implementierung des URL-Handling-Konzepts.

Implementierung von Workflows implementation-workflows

Implementierung der entworfenen Workflows.

Implementierungskonzept implementation-concept

Das Implementierungskonzept bietet die Leitlinien für die gesamte Implementierung. Dabei sollte Folgendes berücksichtigt werden:

Dieses Konzept kann auch die in der Lösung verwendeten Frameworks, Bibliotheken und anderen Artefakten entwerfen.

Unterstützung von Adoben über den Zeitplan für die Live-Schaltung informieren inform-adobe-support-about-the-go-live-schedule

Wenden Sie sich an den Support, um sicherzustellen, dass jeder erforderliche Support während der Live-Schaltung aktiviert werden kann.

Erste Erlebnis-Designs initial-experience-designs

Vorläufige Konzepte für die Entwürfe der Erlebnisse.

Integrationstests integration-testing

Testen und die sich daraus ergebende Bestätigung aller internen und externen Integrationen.

Dies sollte automatisiert und häufig ausgeführt werden, um die Systemstabilität sicherzustellen.

Problem-Tracking-Prozess issue-tracking-process

Klare Prozesse zeichnen alle aufgetretenen Probleme auf und verfolgen laufende Aktivitäten, um sicherzustellen, dass alle Probleme gelöst werden.

Problem-Tracking-System und -Prozesse issue-tracking-system-and-processes

Ein Tracking-System, das zusammen mit den erforderlichen Prozessen alle aufgetretenen Probleme aufzeichnet und laufende Aktivitäten verfolgt, um sicherzustellen, dass alle Probleme gelöst werden.

Alle Projektbeteiligten sollten Zugang haben, um die Transparenz des Projektstatus zu erleichtern.

Beispiele sind Atlassian JIRA und HP Quality Center.

Problemverfolgungssystemprozess ist eingerichtet und integriert issue-tracking-system-process-is-set-up-and-integrated

Die ausgewählten Tools sind vollständig integriert und bieten allen erforderlichen Rollen Zugriff.

Veraltetes System legacy-system

Für Ihr Projekt ist das veraltete System die bestehende Technologie, das Computersystem oder das Anwendungsprogramm, die durch die neue Lösung ersetzt werden.

Details zum alten System sollten erfasst werden, damit Sie wissen, was zurückgezogen werden kann, wann und welche Auswirkungen dies auf andere Systeme hat.

Liste der zu verwendenden Entwicklungstools list-of-development-tools-to-be-used

einen Überblick über die bei der Implementierung verwendeten Tools; Die Instrumente sollten Folgendes umfassen:

Liste der Benutzer, die Zugriff auf das Adobe Support-Portal benötigen list-of-users-that-require-access-to-adobe-support-portal

Eine Liste aller Benutzer und Rollen, die Zugriff auf das Adobe Support Portal benötigen.

Die Liste besteht normalerweise aus dem Lösungsarchitekten und/oder IT-Personal des Kunden.

Protokolldateianalyse log-file-analysis

Eine Analyse mit den resultierenden Empfehlungen, in der festgelegt wird, was protokolliert werden muss, um die Lösung zu überwachen:

getestete und aktivierte Wartungsaufgaben (AEM spezifisch) maintenance-tasks-aem-specific-tested-and-enabled

Testen und aktivieren Sie AEM Wartungsaufgaben wie:

Migrationsplan migration-plan

die Migration dokumentieren; einschließlich

Migrationsstrategie migration-strategy

Eine vollständige Beschreibung des vorhandenen Inhalts, der Inhaltsarchitektur und der Formate, die der neuen Lösung zugeordnet sind. Sie sollte Folgendes umfassen:

Außerdem sollte empfohlen werden, den Inhalt während des Zeitraums zwischen der Migration und der tatsächlichen Live-Schaltung des neuen Systems auf dem neuesten Stand zu halten (oder so aktuell wie möglich). Dies kann zum Einfrieren von Inhalten, zur doppelten Veröffentlichung oder zur Wartung eines Alpha-Systems führen.

Überwachung - CPU monitoring-cpu

Überwachen der Nutzung der System-CPU durch die Lösung:

Überwachung - Datenträger-E/A monitoring-disk-i-o

Überwachen der Festplatten-Eingabe- und -Ausgaberaten der Lösung:

Überwachung des Festplattenspeichers monitoring-disk-space

Überwachen der Nutzung von Festplattenspeicher durch die Lösung:

Sie sollten die Verwendung überwachen, indem Sie:

Überwachung - Externe Systeme monitoring-external-system-s

Überwachen Sie alle Verbindungen zwischen der Lösung und externen Systemen:

Überwachung der Netzwerkbandbreite monitoring-network-bandwidth

Überwachen Sie die Nutzung der Netzwerkbandbreite durch die Lösung:

Überwachung - Anforderungen monitoring-requests

Überwachen Sie die Anforderungen an die Lösung.

Überwachung - Sicherheitspunkte monitoring-security-points

Überwachen Sie die definierten Sicherheitspunkte.

Überwachung - System monitoring-system

Überwachen des Gesamtsystems; Beispiel:

Überwachung - Schwelle und Intervention monitoring-threshold-and-intervention

Überwachung der definierten Schwelle der Lösung und Implementierung von Interventionsmaßnahmen zur Verringerung der Auslastung.

Überwachungskonzept monitoring-concept

die Überwachungskonzepte, die auf Ihre Lösung angewendet werden sollen; mit:

Überwachung potenzieller Schwachpunkte monitoring-potential-weak-points

Bestimmte Punkte, die für einen Fehler anfällig sein könnten, sollten identifiziert und definiert werden. Die damit verbundenen Überwachungsaufgaben sollten ebenfalls festgelegt werden.

Beispiele sind (unter anderem):

Überwachungspolitik für Systemtechniker monitoring-policy-communicated-to-system-engineer

Stellen Sie sicher, dass die Systemtechniker und Betriebspersonal alle Überwachungsrichtlinien kennen und verstehen.

Überwachungsberichte - Struktur vorhanden monitoring-reports-structure-in-place

Definieren:

Dokumentation zu operativen Aufgaben operational-tasks-documentation

Alle dokumentierten operativen Aufgaben mit festgelegter Häufigkeit.

Betriebshandbuch operations-manual

Handbuch mit allen für den erfolgreichen Betrieb und die Wartung der Lösung erforderlichen Informationen:

Sollte auch die Implementierungskonzepte für Folgendes detailliert beschreiben:

Vorbereitung des Pakets package-prepared

Softwarepaket, das erstellt und bereitgestellt wurde und einsatzbereit ist.

Penetrationstests penetration-tests

Ein Penetrationstest (auch bekannt als Pen-Test) ist ein Angriff auf ein Computersystem, das nach Sicherheitsmängeln sucht und möglicherweise Zugriff auf die Funktionen und Daten des Computers erhält.

Penetrationstests - bestanden penetration-tests-passed

Alle erforderlichen Kriterien werden übergeben.

Penetrationstests - Ergebnisse penetration-tests-results

Für das Unternehmen erstellte Berichte, die die Ergebnisse des Penetrationstests erläutern.

Leistungs- und Skalierbarkeitskonzept performance-and-scalability-concept

Konzeptdokument, wie Sie sicherstellen können, dass Ihre Implementierung die Leistungs-KPIs erfüllt, und wie die Lösung skaliert wird, damit sie diese KPIs weiterhin erfüllt.

Leistungs-Benchmark performance-benchmark

Der Performance-Benchmark wird zur Definition von Leistungstests, Dauerhaltbarkeitstests und -überwachung verwendet. Dies erfolgt durch die Bewertung der Leistungsmerkmale der Lösung und System-Hardware.

Leistungs-KPIs performance-kpis

Diese definieren die Key Performance Indicators (KPIs), die zum Messen der Systemleistung erforderlich sind. Einige Beispiele sind die Seitenladezeit, die Antwortzeit des Servers und die Leistung der Datenbankabfrage.

Leistungstests - Bericht performance-tests-report

Für das Unternehmen erstellte Berichte, in denen die Ergebnisse der Leistungstests detailliert beschrieben werden.

Leistungstests - Ergebnisse stimmen mit Leistungs-KPIs überein performance-tests-results-match-performance-kpis

Die Ergebnisse müssen mit den definierten KPIs und Leistungserwartungen übereinstimmen.

Persona-basiertes Testkonzept persona-based-testing-concept

Persona-basierte Tests sind eine Methode, die auf den verschiedenen in den Experience Designs beschriebenen Rollen basiert. Außerdem werden die Konten und die zugehörigen Berechtigungsstufen getestet.

Dies wird häufig beim Benutzerakzeptanztest (UAT) verwendet.

POC getestet und anhand der Anforderungsdokumentation überprüft poc-tested-and-verified-against-requirement-documentation

Der Machbarkeitsnachweis (POC) wird anhand der Anforderungen gemessen, um sicherzustellen, dass beide aufeinander abgestimmt sind.

Checkliste nach der Bereitstellung post-deployment-checklist

Eine Checkliste zur Definition der Prüfungen und Aufgaben, die nach jeder Bereitstellung durchgeführt werden sollen.

Checkliste für die Vorbereitung pre-deployment-checklist

Eine Checkliste zur Definition der Prüfungen und Aufgaben, die vor jeder Bereitstellung durchgeführt werden sollen.

Grundlegende Leistungstests für die Produktionsumgebung production-environment-baseline-performance-tests

Es ist üblich, einen Basistest für eine Standardinstallation von AEM durchzuführen. Dies wird dann als Benchmark zum Testen der Implementierung und Hardware verwendet.

Produktionsumgebungsbereit production-environment-ready

Vergewissern Sie sich, dass die Produktionsumgebung mit automatisierten Bereitstellungen bereit ist.

Abnahme der Produktion von den Geschäftspartnern production-sign-off-from-business-stakeholders

Vor der Live-Schaltung in die Produktionsumgebung muss die entsprechende Abnahme erfolgen. Dies ist das Ergebnis einer Überprüfung der Version, die in die Produktion geht, zusammen mit allen bekannten Problemen. Die Abmeldung erfolgt im Rahmen des Zeitplans "Go Live".

Prozess zur Abnahme der Produktion und Richtlinie production-sign-off-process-and-policy

Die Richtlinie und der Prozess, die erforderlich sind, um die Produktionsabnahme zu erhalten, bevor das Paket in die Produktionsumgebung verschoben wird.

Projektkommunikationsplan project-communication-plan

Definieren Sie den Kommunikationsplan für die Projektbeteiligten aus der Wirtschaft und das Projektteam.

Projektaufwand - Schlussschätzungen project-efforts-final-estimates

Die Anfangsschätzungen wurden auf hoher Ebene erstellt und entsprechen den allgemeinen Anforderungen für die Implementierung.

Diese werden nun überprüft, verfeinert und erweitert, um die endgültigen Schätzungen zu liefern. Die Schätzungen sollten von jeder geeigneten Projektleitung, einschließlich Projektmanagement, Beratung, Architektur, Tests und Entwicklung, vorgelegt werden.

Diese Schätzungen werden für die Finanzierung und Budgetierung verwendet.

Projektaufwand - Anfangsschätzungen project-efforts-initial-estimates

Die ersten Schätzungen sind allgemein und erfolgen gemäß den allgemeinen Anforderungen für die Implementierung. Dies wird zu einem späteren Zeitpunkt überprüft und präzisiert.

Projektorganisation project-organization

Die erforderliche Dokumentation zur Beschreibung der Organisation und Berichtsstruktur des Projekts und Teams.

Oft nimmt die Form oder enthält eine Grafik, um einen visuellen Überblick über Zeitpläne und Zuständigkeiten zu geben. Es stehen viele Tools zur Verfügung, die Ihnen dabei helfen.

Dokument zum Projektumfang project-scope-document

Im Dokument zum Projektumfang müssen Sie eine Liste der folgenden Elemente identifizieren und dokumentieren:

Es umfasst das, was erreicht werden muss, zusammen mit der notwendigen Arbeit, um das Projekt durchzuführen

Projektstatusberichte in einer definierten Zielgruppe project-status-reports-within-a-defined-cadence

Projektstatusberichte werden gemäß dem vereinbarten Zeitplan und im erforderlichen Format bereitgestellt.

Machbarkeitsstudie (POC) proof-of-concept-poc

Der Machbarkeitsnachweis (POC) implementiert eine begrenzte Anzahl von Funktionen für die Lösung.

Es sollte darauf abzielen, die Machbarkeit der Lösung nachzuweisen, zu überprüfen, ob sie den erforderlichen Zweck erfüllen kann, und nachzuweisen, dass das Potenzial der Lösung besteht.

Regeln bereinigen purge-rules

AEM verwaltet mehrere Versionen von Assets und Inhalten. Bereinigungsregeln sind so konzipiert und konfiguriert, dass ältere Versionen regelmäßig entfernt werden, um den Zustand und die Größe des Repositorys zu gewährleisten.

Format und Zielgruppe von Qualitätsberichten quality-report-format-and-cadence

Definieren Sie den erforderlichen Inhalt und das Format des Qualitätsberichts sowie die Häufigkeit der Bereitstellung.

Release Coordinated release-coordinated

Der Projektmanager koordiniert alle Rollen, die für die Veröffentlichung in der Produktionsumgebung erforderlich sind.

Versionshinweise release-notes

Versionshinweise sind Teil der Dokumentation für die Version. Die Versionshinweise sollten Folgendes umfassen:

Es wird mit dem Runbook verwendet, um die Schritte und Prüfungen vor und nach der Installation auszuführen.

Release in der Produktionsumgebung release-running-on-production-environment

Die endgültige Version wird ausgeführt und ist in der Produktion aktiv.

Relevante Vertragsbedingungen relevant-contract-terms

Sie sollten spezifische Vertragsbedingungen hervorheben, die für die Implementierung des Projekts relevant sind. wie vertragliche Meilensteine, Rechnungszeiträume oder Personalanforderungen.

Berichtsfrequenz reporting-cadence

Definieren Sie gemeinsam mit dem Kunden die Häufigkeit der ihm übermittelten Berichte.

Repository-Optimierung repository-optimization

Daten werden nie in einer Tar-Datei überschrieben. Die Festplattenauslastung steigt auch dann, wenn nur vorhandene Daten aktualisiert werden.

Um der immer größer werdenden Größe des Repositorys entgegenzuwirken, wird eine Optimierungsstrategie eingeführt, um veraltete Daten zu entfernen.

Anforderung zum Einrichten des Projektabschnitts im Adobe Support-Portal request-for-setting-up-project-section-in-adobe-support-portal

Die offizielle Anfrage zum Einrichten Ihres Projekts im Adobe Support-Portal.

Anforderungsdokumentation requirements-documentation

Diese Dokumentation behandelt die funktionalen und nicht funktionalen Anforderungen sowie die geschätzten Anstrengungen.

Verfügbare Ressourcen zur Unterstützung von Go Live resources-available-to-support-go-live

Stellen Sie sicher, dass alle für die Live-Schaltung erforderlichen Rollen besetzt und verfügbar sind.

Risikobewertung risk-assessment

Die Risikobewertung wird von der IT- und/oder Sicherheitsabteilung des Kunden durchgeführt.

In ihr werden die technischen und geschäftlichen Risiken des Projekts bewertet. Die Bewertung ist erforderlich, damit die Lösung die Einhaltung der Sicherheitsrichtlinien sicherstellt.

Risikominimierungsplan risk-mitigation-plan

Der Risikominimierungsplan umfasst die Risikobewertung. Gemeinsam decken sie Folgendes ab:

ROI-Erwartungen roi-expectations

Definieren Sie die mit der Lösung verbundenen ROI-Erwartungen.

Sie sollen die wirtschaftliche Effizienz der Lösung durch Definition des erwarteten Nutzens/Gewinns in Bezug auf die voraussichtliche Investition aufzeigen.

Rollen- und Rechtekonzept roles-and-rights-concept

Detaillierte Beschreibung der für die neue Anwendung erforderlichen Rollen und Zugriffsrechte, einschließlich einer allgemeinen Übersicht über:

Rollen- und Rechtekonzept erfüllt Sicherheitsrichtlinien roles-and-rights-concept-meets-security-guidelines

Überprüfung des Konzepts der Rollen und Rechte, um sicherzustellen, dass es den Sicherheitsrichtlinien entspricht.

Rollen und Berechtigungen - Spezifikation roles-and-rights-specification

Eine detaillierte Spezifikation, die auf dem Rollen- und Rechtekonzept basiert.

Sicherheitsarchitektur Recommendations security-architecture-recommendations

Recommendations bezieht sich auf die Sicherheit der Software- und Hardwarearchitektur.

Sicherheitsbasierte Kodierungsrichtlinien security-based-coding-guidelines

In diesen Richtlinien wird definiert, wie die Entwicklungskodierung auf der Grundlage von Sicherheitsanforderungen durchgeführt werden soll, wie z. B.:

Sicherheitscheckliste security-checklist

Projektspezifische Checkliste der Elemente, basierend auf dem Sicherheitskonzept, zusammen mit zusätzlichen Richtlinien, die zur Gewährleistung der Kompatibilität der Lösung erforderlich sind.

Häufig ist dies auch als Teil der Schritte nach der Bereitstellung im Runbook enthalten.

Sicherheitskonzept security-concept

Definieren und dokumentieren Sie Details der Sicherheitskonfiguration, die für die Anwendung, Architektur und Infrastruktur erforderlich ist.

Sicherheitskonzept - Entwurf security-concept-draft

Eine allgemeine Übersicht über die Sicherheitseinstellungen für:

Aufgeführte und bewertete Sicherheitsprobleme security-issues-listed-and-assessed

alle Sicherheitsprobleme der aufgelisteten und bewerteten Lösung; einschließlich Aufwandsschätzungen.

Sicherheitsabnahme von Geschäftspartnern security-sign-off-from-business-stakeholders

Melden Sie sich von den Stakeholdern ab, um sicherzustellen, dass die Sicherheitsimplementierung mit den Richtlinien und Erwartungen übereinstimmt.

Einrichten von Supportprozessen set-up-support-processes

Legen Sie die erforderlichen Support-Prozesse fest.

SLAs für Drittanbietersysteme slas-for-third-party-systems

Stellen Sie sicher, dass Service Level Agreements (SLAs) verfügbar sind und sowohl den Entwicklungs- als auch den Betriebsteams zur Verwendung während der Implementierung und beim Support übermittelt werden.

Rauchtestkonzept smoke-test-concept

Rauchtests bestehen aus einer Reihe definierter Schritte, mit denen die Schlüsselfunktionen der Lösung getestet werden, um grundlegende Vorgänge und Funktionen der Lösung sicherzustellen.

Sie werden nach der Installation oder Bereitstellung in jeder Umgebung ausgeführt.

Für die Systemvalidierung ausgeführte Rauchtests smoke-tests-executed-for-system-validation

Rauchtests sollten auf allen Systemen durchgeführt werden, um sicherzustellen, dass die grundlegenden Funktionen der Lösung bei der Installation oder Bereitstellung in jeder Umgebung ordnungsgemäß funktionieren.

Software Architecture Strategy software-architecture-strategy

die allgemeine Strategie für die Softwarearchitektur; einschließlich Diensten, Servlets, Frameworks und anderen Implementierungsentscheidungen.

Lösungsüberprüfungsgremium eingerichtet und Sitzungskatalog festgelegt solution-review-board-established-and-meeting-cadence-set

Das Lösungsüberprüfungsgremium besteht in der Regel aus Kunden-Interessengruppen.

Die Kommission hält regelmäßig Sitzungen ab, um die aktuellen Anforderungen und relevanten Spezifikationen laufend zu überprüfen. Ziel ist es, die Abstimmung mit der Erfolgsdefinition und den Erfolgskriterien sicherzustellen und auch einen Beitrag zur Entwicklung der Anforderungen zu leisten.

Solution Runbook solution-runbook

Installationsanweisungen für die Lösung sowie grundlegende Betriebsaufgaben, die bei der Installation ausgeführt werden.

Abnahme der Lösung und Annahme solution-sign-off-and-acceptance-process

Der Abnahmeprozess beschreibt die Kriterien, die erfüllt sein müssen, bevor die Lösung in einer Produktionsumgebung freigegeben werden kann.

Sie kann auch als vertraglicher Meilenstein dienen.

Spezielles Funktionskonzept special-functionality-concept

Das anfängliche Konzept für alle speziellen Funktionen, die außerhalb des normalen Entwicklungsumfangs auf der AEM Plattform betrachtet werden.

Spezifische Funktionsspezifikation special-functionality-specification

Details zu speziellen Funktionen, die außerhalb des normalen Entwicklungsbereichs der AEM Plattform betrachtet werden.

Spezifikationsrichtlinien specification-guidelines

Alle Richtlinien des Kunden zur Durchführung der Spezifikation.

Definierter und kommunizierter Prozess zur Überprüfung und Genehmigung von Spezifikationen specification-review-and-approval-process-defined-and-communicated

Es sollte ein klares Verfahren für die Abnahme der Spezifikationen durch den Kunden eingeführt werden. Dieser Prozess gewährleistet Klarheit und Festigkeit des Umfangs für die Anforderungen.

Auswahl der Mitarbeiter für AEM Administratorschulung staff-selected-for-aem-administrator-training

Interne Mitarbeiter, die zur Verwaltung der Lösung geschult werden müssen.

Für die Autoren- und Endbenutzerschulung ausgewählte Mitarbeiter staff-selected-for-author-and-end-user-training

Interne Mitarbeiter, die für die Bearbeitung der Lösung geschult werden müssen.

Interessenträger stakeholders

Interessenträger sind die wichtigsten Personen und/oder Rollen, die ein erhebliches Interesse an dem Projekt haben. Einige werden zum Projektbudget beitragen.

Die Projektbeteiligten können intern und/oder extern sein.

Interessengruppen sind sich der Erfolgsdefinitionen und -kriterien bewusst stakeholders-are-aware-of-success-definitions-and-criteria

Bestätigung, dass alle Interessengruppen außerhalb des eigentlichen Implementierungsteams über Folgendes informiert sind:

Interessenträger - Projekt und Erwartungen stakeholders-understand-project-and-expectations

Bestätigung, dass alle Interessengruppen außerhalb des eigentlichen Implementierungsteams mit dem Gesamtprojekt und den Erwartungen übereinstimmen, sowohl intern für das Projektteam als auch für den Kunden.

Definition des Status Report Formats status-report-format-definition

Statusberichte sind ein wichtiges Kommunikationsmittel. Das Format sollte mit allen Berichterstellungsanforderungen des Kunden abgestimmt werden.

Erfolgskriterien und Definition success-criteria-and-definition

Der Kunde, der Projektsponsor und der Projektmanager oder Berater sollten Folgendes angeben:

Diese werden verwendet, um sicherzustellen, dass die Erfolgskriterien erfüllt sind:

Unterstützung bei der Validierung gemeldeter Probleme support-in-validation-of-reported-issues

Ein Teil der Verantwortung des Qualitätsleiters besteht darin, sicherzustellen, dass Ressourcen zur Verfügung stehen, um Benutzer beim Testen zu unterstützen. So können Sie beispielsweise den Benutzer beim Testen, beim Reporting von Problemen und bei der Überprüfung der Probleme in der Testumgebung unterstützen.

Support-Prozesse und Zugriff auf das Support-Portal für Adoben support-processes-and-access-to-adobe-support-portal

Der Zugriff auf das Support-Portal für Adoben ist für die Übermittlung von Tickets zu produktbasierten Problemen, die während der Implementierung auftreten können, von entscheidender Bedeutung.

Der Zugriff sollte wichtigen Mitgliedern des Teams gewährt werden.

Definition der Systemarchitektur system-architecture-definition

Ein erster Vorschlag und eine Definition der Architektur für alle Umgebungen der Lösung.

Dokumentation zur Systemarchitektur system-architecture-documentation

Ein Dokument, das die Systemarchitektur detailliert beschreibt; einschließlich Schnittstellen, Netzwerkstandort und Integrationen für alle Umgebungen, einschließlich Informationen.

Sicherheitskonzept der Systemarchitektur system-architecture-security-concept

Eine allgemeine Übersicht darüber, wie Sie die Systemarchitektur mit allen Sicherheitsrichtlinien konform machen. Dies kann Folgendes umfassen:

Identifizierte und überprüfte Systemrisikofaktoren system-risk-factors-identified-and-verified

Jegliche Risikofaktoren, die in der Risikobewertung (oder anderen Überprüfungen) festgestellt werden, werden ermittelt und bewertet:

Das Team ist sich der Erfolgsdefinitionen und -kriterien bewusst team-is-aware-of-success-definitions-and-criteria

Bestätigung, dass dem gesamten Team die Erfolgsdefinitionen und -kriterien bekannt sind.

Das Team ist sich des Kommunikationsplans bewusst team-is-aware-of-the-communication-plan

Bestätigung, dass alle Mitglieder des Teams wissen, wer mit dem Kunden kommunizieren soll, zusammen mit Details zu Wie und Wann.

Team versteht Projekt und Erwartungen team-understands-project-and-expectations

Abstimmung mit dem Gesamtprojekt und den Erwartungen, sowohl intern mit dem Projektteam als auch mit dem Kunden.

Technische Anforderungen technical-requirements

Diese Anforderungen beziehen sich speziell auf die technische Implementierung von Diensten, die die Lösung unterstützen.

Verifizierte technische Risikofaktoren technical-risk-factors-verified

potenzielle technische Risiken ermitteln und überprüfen. Technische Risiken können Folgendes umfassen:

Technische Spezifikation technical-specification

Die technische Spezifikation umfasst (unter anderem):

Vorlagenspezifikation template-specification

Die Spezifikationen für die erforderlichen Vorlagen. Diese sollten u. a. Details wie Parsys, Blueprint und Vererbungs-Mapping umfassen.

Die Spezifikationen basieren auf den Geschäftsanforderungen und den Anforderungen an das Anwendererlebnis.

Testfälle test-cases

In Testfällen werden die detaillierten Schritte beschrieben, die zum Ausführen von Funktionstests der Lösung erforderlich sind.

Inhalt testen test-content

Testinhalte sollten Produktionsinhalten so ähnlich wie möglich sein. Die Auswahl muss groß genug sein, um alle Szenarien testen zu können.

Testumgebung bereit test-environment-ready

Stellen Sie sicher, dass die Testumgebung bereit ist und automatisierte Bereitstellungen vorhanden sind, um sicherzustellen, dass der gesamte Release-Kandidatencode für Tests auf dem neuesten Stand ist.

Testberichte test-reports

Berichte mit detaillierten Angaben zu den Testergebnissen; einschließlich:

Beachten Sie Folgendes:

Testsuite test-suite

Auswahl der Automatisierungs-Suite und -Tools. Diese werden verwendet, um Tests zu automatisieren, auch für Anwendungsfälle.

Test Toolsuite ausgewählt test-tooling-suite-selected

Automatisierungs-Suite und -Tools für die Anwendungsfallautomatisierung und andere Aufgaben zur Testausführung ausgewählt.

Testkonzept testing-concept

Das Testkonzept ist der sehr allgemeine Entwurf für Tests für das Projekt. einschließlich Tests zu Qualitätssicherung, UAT, Leistung, Sicherheit und Integration.

Testpläne testing-plans

In diesen Plänen wird die Durchführung von Tests für jede Entwicklungsphase detaillierter beschrieben; sie basieren auf der Teststrategie.

Testumfang testing-scope

Diese Anforderungen beziehen sich speziell auf die technische Implementierung von Diensten, die die Lösung unterstützen.

Teststrategie testing-strategy

In der Teststrategie wird die allgemeine Strategie für Qualitätssicherung und Benutzerakzeptanztests erläutert. Dazu gehören Zeitpläne, Reporting-Kadenz und Ausführung.

Integrationskonzept für Dritte third-party-integration-concept

Architektur- und Systemkonzept für die Integration mit Drittanbietersystemen.

Spezifikation für Drittanbieterintegration third-party-integration-specification

Details der (funktionalen und nicht funktionalen) Anforderungen an die unterstützte Funktionalität und Integration der Drittanbietersysteme.

Sicherheitskonzept von Dritten third-party-security-concept

Konzept zur Gewährleistung der Sicherheit von Drittanbieterintegrationen. Muss den entsprechenden Sicherheitsrichtlinien entsprechen.

Drittanbietersystem für Integration third-party-system-for-integration

Stellen Sie sicher, dass alle Drittanbietersysteme mit entsprechender Dokumentation für die Integrationsimplementierung verfügbar sind.

Zugriff auf Systeme von Drittanbietern aktiviert third-party-systems-access-enabled

Erforderliche Zugriffsrechte, die den jeweiligen Rollen gewährt werden, die in Verbindung mit Drittanbietersystemen verwendet werden.

Drittanbieter-Testkonzept third-party-testing-concept

Definiert:

Schwellendefinition threshold-definition

Definiert die Schlüsselwerte für Überwachungspunkte im System.

Beispiel:

Zeitleiste und Meilensteine timeline-and-milestones

Dies sollte die Projektzeitpläne und vertraglichen Meilensteine definieren, die für Folgendes verwendet werden sollen:

Gesamtprojektaufwand total-project-efforts

Sämtliche Aufwandsschätzungen, die aus jedem Interessenten des Projekts stammen, sollten konsolidiert werden. einschließlich Kosten-, Entwicklungs-, System-, Architektur- und Testarbeiten.

Ist in der Vereinbarung ein Unterstützungsniveau enthalten, sollten auch Unterstützungs- und Einsatzbemühungen einbezogen werden.

Schulungsmaterial training-materials

Materialien für Schulungssitzungen. Die Materialien sollten speziell für die Lösung erstellt und für die Verwendung in Verbindung mit den Benutzerhandbüchern entwickelt werden.

Versteht den Umfang des Projekts und Erwartungen understands-scope-of-project-and-expectations

Die entsprechende Person sollte bestätigen, dass sie Folgendes vollständig versteht:

URL-Handling-Konzept url-handling-concept

Ihr URL-Behandlungskonzept sollte AEM spezifische URL-Funktionen abdecken, darunter:

Das Konzept sollte auch Folgendes umfassen:

Anwendungsfälle use-cases

Ein Anwendungsfall ist die Liste der Aktionen oder Ereignisschritte, die zum Erreichen eines Ziels erforderlich sind. Normalerweise definieren sie die Interaktionen zwischen einer Rolle und der Lösung. Die Rolle kann ein Benutzer oder ein externes System sein.

In Testszenarien konvertierte Anwendungsfälle use-cases-converted-into-test-scenarios

Testszenarien basieren auf den technischen und geschäftlichen Anwendungsfällen. Sie werden verwendet, um zu testen, ob das Lösungsverhalten erwartungsgemäß ist.

Benutzerhandbücher user-guides

Benutzerhandbücher bieten Informationen und Unterstützung für die Benutzer der Lösung:

Validierter Budgetplan validated-budget-plan

Der Haushaltsplan muss von allen Beteiligten überprüft und validiert werden. Sie müssen Details wie Rechnungsstellung, Beträge und Methoden/Timing der Budgetberichterstellung überprüfen.

White Box-Testergebnisse white-box-test-results

White Box-Tests sind eine Methode, die die internen Strukturen oder das Betriebsverhalten einer Anwendung im Gegensatz zu ihrer Funktionalität testet. Weiße Box-Tests können auf Ebene der Einheit, Integration und des Systems des Softwaretestprozesses angewendet werden.

Workflow-Spezifikationen workflow-specifications

Basierend auf dem Workflow-Konzept sollten diese Spezifikationen die Schritte detailliert definieren, mit denen der gesamte Workflow erstellt wird.

Die Spezifikationen der einzelnen Workflows sollten (mindestens) Folgendes umfassen:

Workflow-Konzept workflows-concept

Workflows ermöglichen die Automatisierung AEM Aktivitäten. Das Workflow-Konzept beschreibt Folgendes: