Glossar glossary

Dieses Glossar listet (alphabetisch) alle zu liefernden Dokumente aus der Projekt-Checkliste auf.

Akzeptanz der Projektbeteiligten aus den Geschäftsbereichen acceptance-from-business-stakeholders

Die Akzeptanz der Projektbeteiligten aus den Geschäftsbereichen bestätigt, dass sie als Hauptbeteiligte mit der Lösung einverstanden sind und zustimmen, dass die Geschäftsanforderungen dem Business-Case entsprechen.

Akzeptanztests acceptance-tests

Akzeptanztests erfolgen, wenn eine Anwendung produktionsreif ist. Die Tests werden von einer Gruppe durchgeführt, die die verschiedenen Typen von Endbenutzenden auf Basis realer Szenarien repräsentiert.

Mit Akzeptanztests wird Folgendes bestätigt:

Je früher Sie Ihre Akzeptanztests planen und konzipieren, desto einfacher wird die endgültige Bereitstellung. Sie sollten zusammen mit der Kundin bzw. dem Kunden und Ihrem Qualitätssicherungs-Team definiert werden.

Auch wenn Sie vielleicht nicht alle Details gleich zu Beginn des Projekts definieren können, sollten erste Definitionen besprochen und vereinbart werden. Die Akzeptanztests orientieren sich wahrscheinlich an den grundlegenden Anforderungen (an Funktionen und Leistung).

Koordinierung des Zugriffs auf das Testsystem access-to-test-system-coordinated

Vergewissern Sie sich, dass allen Rollen die erforderlichen Systemzugriffsrechte gewährt wurden.

Sicherheits-Checkliste von Adobe adobe-security-checklist

Die Sicherheits-Checkliste von Adobe ist die offizielle Checkliste, um sicherzustellen, dass Adobe Experience Manager (AEM) bei der Installation sicher ist. Sie enthält die Sicherheitsmaßnahmen und Überprüfungsschritte, die Sie durchführen müssen, um die Integrität Ihrer Instanz zu gewährleisten.

Einrichtung eines Projekts im Adobe-Support-Portal adobe-support-portal-project-set-up

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

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

AEM-Administratorschulung aem-administrator-training

Hierbei handelt es sich um Schulungen für die Mitarbeitenden, die die Lösung verwalten. Weitere Informationen finden Sie unter Adobe-Schulungen.

AEM-Autorenschulung aem-author-training

Hierbei handelt es sich um Schulungen für die Mitarbeitenden, die Inhalte für die Lösung erstellen (Authoring). Weitere Informationen finden Sie unter Adobe-Schulungen.

AEM-Zertifizierungsprüfung aem-certification-exam

Stellen Sie sicher, dass die entsprechenden Rollen für die jeweiligen Zertifizierungsprüfungen angemeldet sind.

AEM-zertifiziert aem-certified

Stellen Sie sicher, dass die entsprechenden Rollen die jeweiligen Zertifizierungsprüfungen bestanden haben.

Technische Schulungen zu AEM aem-technical-training

Bieten Sie technische Schulungen für die entsprechenden Rollen an, z. B. für Entwickelnde, Architektinnen und Architekten, Ingenieurinnen und Ingenieure sowie kaufmännische Fachleute.

Vereinbarung zu den KPIs, die als Projektziele definiert sind agreement-on-kpis-defined-as-goals-for-the-project

Key Performance Indicators (KPIs) helfen einer Organisation, Fortschritte beim Erreichen von Organisationszielen zu definieren und zu messen. Sobald eine Organisation ihre Aufgabenstellung analysiert und Ziele definiert hat, muss sie den Fortschritt mit Blick auf diese Ziele messen. KPIs dienen dabei als Messmechanismus.

Abstimmung von Geschäfts- und Leistungs-KPIs align-business-and-performance-kpis

Die Abstimmung Ihrer Geschäfts- und Leistungs-KPIs hilft, alle beteiligten Personen und Prozesse innerhalb der Organisation zusammenzubringen. Dies wiederum trägt dazu bei, den Zeit- und Arbeitsaufwand zum Erreichen der Geschäftsziele und Erfüllen des angestrebten Zwecks zu verringern.

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

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

Abstimmung der Kunden-Roadmap mit der Projekt-Timeline alignment-of-the-customer-roadmap-with-project-timeline

Die Kunden-Roadmap besteht aus allgemeinen Meilensteinen und Geschäftszielen. Die Projekt-Timeline muss sich an diese Strategie halten und mit ihr in Einklang stehen, sodass mögliche Risiken und/oder Abweichungen aufgezeigt und nachverfolgt werden müssen.

Definition der Anwendungsarchitektur application-architecture-definition

Die Anwendungsarchitektur muss das Verhalten der geplanten Anwendungen klar definieren.

Ihr Fokus liegt auf Folgendem:

Definition anwendungsspezifischer Wartungsaufgaben application-specific-maintenance-tasks-defined

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

Entsprechend geschultes Personal appropriately-trained-staff

Stellen Sie sicher, dass Ihr Team aus Mitarbeitenden mit entsprechender Qualifikation besteht. Zu Projekt-Teams sollten die folgenden Mitglieder zählen:

Architekturdiagramm architecture-diagram

Das Architekturdiagramm ist eine grafische Darstellung der Architektur. Es zeigt Folgendes:

Architekturentwurf architecture-draft

Hierbei handelt es sich um einen allgemeinen Überblick über die System- und Lösungsarchitektur. In dieser Phase ist dies ein Entwurf, der zu einem späteren Zeitpunkt überprüft und präzisiert wird.

Genehmigung durch die Architekturüberprüfungskommission architecture-review-board-sign-off

Die Architekturüberprüfungskommission ist ein abteilungsübergreifendes Gremium mit folgenden Aufgaben:

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

Automatisierte Testsuite, die an reale Inhalte und Ergebnisse im Vergleich zu KPIs angepasst ist automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Automatisierungsskripte und einfache automatisierte Anwendungsfälle:

Strategie für automatisierte Tests automated-testing-strategy

Diese Strategie definiert ein Framework für wiederverwendbare automatisierte Skripte im Zusammenspiel mit dem vom Qualitätssicherungs-Team geplanten Ansatz. Sie skizziert den allgemeinen Plan für Automatisierungstests, um Folgendes sicherzustellen:

Strategie für automatisierte Tests, die mit realistischer und erwarteter Last validiert wurde automated-testing-strategy-validated-against-realistic-and-expected-load

Die Strategie für automatisierte Tests muss validiert und an den Inhalt und die zu erwartende Last der Lösung angepasst werden.

Automatisierungsstrategie automation-strategy

Die Automatisierung von Bereitstellungen sorgt für Beschleunigung und Konsistenz. Die Automatisierungsstrategie beschreibt die Konfiguration von Automatisierungsmechanismen und umfasst u. a. Folgendes:

Kenntnis des Kommunikationsplans aware-of-communication-plan

Das gesamte Projekt-Team und alle Projektbeteiligten müssen bestätigen, dass ihnen Folgendes bekannt ist:

Kenntnis der Definitionen und Kriterien für Erfolg aware-of-success-definitions-and-criteria

Das gesamte Projekt-Team und alle Projektbeteiligten müssen bestätigen, dass ihnen Folgendes bekannt ist:

Sicherungs- und Wiederherstellungskonzept backup-and-restore-concept

Das Sicherungs- und Wiederherstellungskonzept beschreibt die technische Funktionalität, die in der Lösung implementiert wird. Es wird von den Sicherungs- und Wiederherstellungsrichtlinien des Unternehmens verlangt.

Erfolgreicher Test von Sicherung und Wiederherstellung backup-and-restore-tested

Hierbei handelt es sich um einen vollständigen, durchgängigen Test des Sicherungs- und Wiederherstellungskonzepts.

Business-Cases business-case-s

Ein Business-Case-Dokument enthält die Argumente für das Ergreifen der Maßnahme, das Ergreifen alternativer Maßnahmen (falls vorhanden) oder das Nichtergreifen von Maßnahmen. Die Argumente sollten ausgewogen sein, sich auf konkrete Fakten stützen (wo immer möglich/relevant) und für alle Fälle sowohl den Nutzen als auch die Risiken aufzeigen.

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

Vertrautheit der Geschäftsanalystin bzw. des Geschäftsanalysten mit dem Projektumfang und den Erwartungen business-analyst-understands-scope-of-project-and-expectations

Geschäftsanalystinnen und Geschäftsanalysten müssen 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 aufzeigen, wie effektiv ein Unternehmen wichtige Geschäftsziele erreicht. Es ist wichtig, KPIs auszuwählen, die für Ihr Unternehmen/Szenario geeignet sind, wobei klar definiert sein sollte, um was für KPIs es sich handelt, wie sie verwendet werden und von wem.

Dokumentation der Geschäftsanforderungen business-requirements-documentation

Ein Geschäftsanforderungsdokument (Business Requirements Document, BRD) beschreibt die Geschäftslösung für ein Projekt und liefert eine klare Präzisierung der Geschäftsanforderungen und -erwartungen auf Kundenseite. Es unterscheidet auch zwischen der geschäftlichen und der technischen Lösung.

Bei der Prüfung der Unternehmenslösung sollte das Geschäftsanforderungsdokument (BRD) die Frage beantworten:
„Was will das Unternehmen erreichen?“

Genehmigung durch die Geschäftsführung bei allen erforderlichen Anpassungen der Lösung oder Architektur entsprechend den ermittelten ROI- und KPI-Erwartungen 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 zu Problemen und Ergebnissen führen, die in der Architektur oder Entwicklung der Lösung aufgegriffen werden müssen.

Die aus diesen Prozessen resultierenden Anpassungen müssen vom Unternehmen überprüft und genehmigt und an den Gesamtzielen gemessen werden.

Caching-Strategie caching-strategy

Die Caching-Strategie beschreibt, was für Endbenutzende zwischengespeichert wird. Sie muss mit den Leistung-KPIs konform sein.

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

Codierungsrichtlinien coding-guidelines

Die Kodierungsrichtlinien definieren Grundprinzipien, an die sich die Entwickelnden bei der Entwicklung der Lösung halten müssen. Dazu zählen u. a.:

Verteilen des Betriebshandbuchs communicate-operations-manual

Stellen Sie sicher, dass alle relevanten Rollen das Betriebshandbuch erhalten.

Verteilen des Leistungstestberichts communicate-performance-test-report

Stellen Sie sicher, dass alle relevanten Rollen den Leistungstestbericht erhalten.

Verteilen der Versionshinweise communicate-release-notes

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

Informieren des Teams über den Projektumfang und Erwartungen communicate-scope-and-expectations-to-team

Stellen Sie sicher, dass das Projekt-Team den Projektumfang und die Liefererwartungen genau kennt und sich darauf einstellt.

Informieren über Schulungsmaterialien und Benutzerhandbücher communicate-training-materials-and-user-guides

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

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

Stellen Sie sicher, dass alle Sicherheitsanforderungen auf Kundenseite erfüllt sind.

Einhaltung des Sicherheitskonzepts compliance-with-security-concept

Stellen Sie sicher, dass das Sicherheitskonzept eingehalten wird.

Konzept der Beziehungen zwischen Komponenten und Vorlagen components-and-templates-relationship-concept

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

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

Details zum Konzept der Beziehungen zwischen Komponenten und Vorlagen.

Spezifikationen von Komponenten components-specification

Spezifikationsdetails zu allen Komponenten, die implementiert werden sollen.

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

Das Konzept für Entwicklung und Testen von externen Schnittstellen, die für die Entwicklungs- oder Testumgebungen möglicherweise nicht zugänglich bzw. verfügbar sind.

Planen und implementieren Sie Modelle dieser Schnittstellen, um sicherzustellen, dass die Tests so nah wie möglich am produktionsgemäßen Verhalten sind.

Dokument zur Inhaltsarchitektur content-architecture-document

Dokumentation der geplanten Architektur des Inhalts. Die Details sollten u. a. Folgendes umfassen:

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

Die veralteten Systeminhalte werden überprüft und die ausgewählten Inhalte für die Migration in die neue Lösung validiert.

Vertragsentwurf contract-draft

Ein erster Entwurf des rechtsgültigen Vertrags.

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

Dokumentation der aktuellen Inhaltsarchitektur und -format. Mit ihrer Hilfe wird die künftige Inhaltsarchitektur generiert. Sie wird auch für das Migrationskonzept verwendet.

Sicherungs- und Wiederherstellungsrichtlinien der Kundin bzw. des Kunden customer-backup-and-restore-policy

Richtlinien der Kundin bzw. des Kunden bezüglich:

Kodierungsrichtlinien der Kundin bzw. des Kunden customer-coding-guidelines

Richtlinien/Anforderungen der Kundin bzw. des Kunden, wie die Entwicklung erfolgen soll.

Bereitstellungs-/Freigaberichtlinien der Kundin bzw. des Kunden customer-deployment-release-policies

Richtlinien der Kundin bzw. des Kunden, die festlegen, wie und wann Bereitstellungen/Freigaben erfolgen können.

Dazu gehören oft Zeitpläne und Termin- und Abnahmeanforderungen.

Überwachungsrichtlinien oder -anforderungen der Kundin bzw. des Kunden customer-monitoring-policies-or-requirements

Richtlinien und Anforderungen der Kundin bzw. des Kunden, was überwacht werden soll. Diese ergänzen die im Überwachungskonzept genannten Empfehlungen.

Zeitplan für die Produktionsfreigabe der Kundin bzw. des Kunden customer-production-release-schedule

Der Zeitplan, der von der Kundin bzw. vom Kunden für die Freigabe an die Produktionsumgebung definiert wird.

Richtlinien der Anforderungen der Kundin bzw. des Kunden für die Berichterstellung customer-reporting-policies-and-requirements

Richtlinien und/oder Anforderungen, die die Kundin bzw. der Kunde in Bezug auf die Berichterstellung hat. Diese können Folgendes umfassen:

Kunden-Roadmap customer-roadmap

Formulieren Sie eine Roadmap der wichtigsten Meilensteine, die umgesetzt werden müssen, sowohl in technologischer als auch geschäftlicher Hinsicht. Diese Roadmap wird dann der Kundin bzw. dem Kunden übergeben.

Kundenseitige Sicherheitsrichtlinien customer-security-policies

Auf Kundenseite (kaufmännischer und IT-Bereich) sind Richtlinien vorhanden, die die erforderlichen Sicherheitsstufen für die Lösung definieren. Diese können Folgendes umfassen:

Kundenseitige Spezifikationsrichtlinien customer-specification-guidelines

Hierbei handelt es sich um alle kundenseitig vorgegebenen Richtlinien in Bezug auf Format, Lieferung und Abnahme der Spezifikationen.

Kundenseitige Testberichte customer-test-reports

Hierbei handelt es sich um kundenseitige Berichte an die Leitung der Qualitätssicherung im Verlauf der Benutzerakzeptanztests.

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

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

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

Dies umfasst Berichte oder Besprechungen als Folge von Benutzerakzeptanztests (UAT). Sie sollten Details zu Folgendem enthalten:

Aktivierung der Standardsicherheit default-security-enabled

Vergewissern Sie sich, dass die Standardsicherheitseinstellungen für AEM aktiviert bzw. implementiert wurden.

Bereitstellungs-/Freigaberichtlinien und -prozesse deployment-release-policies-and-processes

Hierbei handelt es sich um festgelegte Richtlinien, die sowohl die Bereitstellung als auch die Freigaben Ihres Projekts abdecken. Diese können Folgendes umfassen:

Festlegung des Bereitstellungsrhythmus deployment-cadence-established

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

Entwicklungsmethodik development-methodology

Eine Software-Entwicklungsmethodik sieht vor, den gesamten Prozess der Software-Entwicklungsarbeit in verschiedene Phasen (oder Stufen) mit jeweils unterschiedlichen Aktivitäten aufzuteilen. Ziel ist es, Planung und Verwaltung zu verbessern.

Bei der Definition der Methodik sollten Sie spezifische zu erbringenden Leistungen und Artefakte vordefinieren, die vom Projekt-Team erstellt und ergänzt werden, um Ihre Anwendung zu entwickeln oder zu pflegen.

Definition der Rollen bei der Entwicklung development-role-definition

Definieren Sie, welche Entwicklerin bzw. welcher Entwickler und/oder welche Rolle IT-Tests (leistungsbezogene oder andere) und/oder Unit-Tests innerhalb der Lösung ausführt.

Bereitschaft der Entwicklungsumgebung development-environment-ready

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

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

Das Entwicklungs-Team sollte bestätigen, dass es Folgendes vollständig versteht:

Spezifikation von Dialogfeldern dialogs-specification

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

Dokumentation der Einrichtung der Entwicklungsumgebung document-development-environment-setup

Dokumentation der Entwicklungsumgebung.

Dokumentation der Einrichtung der Produktionsumgebung document-production-environment-setup

Dokumentation der Produktionsumgebung.

Dokumentation der Einrichtung der Testumgebung document-test-environment-setup

Dokumentation der Testumgebung.

Stabilitätstest durability-test

Der Stabilitätstest zeigt die Leistung der Lösung bei einer bestimmten Last. Diese Tests messen, wie lange die Lösung bei einer Last am Schwellenwert mit welchen Leistungsebenen stabil bleibt.

Ausführung des Stabilitätstests durability-test-executed

Ausführung der Stabilitätstests.

Fehlerbehebungskonzept error-handling-concept

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

Dokumentation der Fehlerbehebung error-handling-documentation

Detaillierte Dokumentation der vorgeschlagenen Fehlerbehebung basierend auf dem Fehlerbehebungskonzept.

Eskalationsprozesse escalation-processes

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

Festlegen regelmäßiger Qualitätsüberprüfungssitzungen establish-regular-quality-review-sessions

Legen Sie regelmäßige Qualitätsüberprüfungssitzungen mit den entsprechenden Team-Mitgliedern fest.

Vorhandene Berechtigungsstruktur existing-permissions-structure

Dokumentation der vorhandenen Berechtigungen und Gruppen, die für die Vorgängerlösung oder innerhalb des Unternehmens definiert wurden.

Übersicht vorhandener Systeme 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.

Die Erwartungen können Folgendes umfassen:

Anforderungen an die Gestaltung von Erlebnissen experience-designs-requirements

Anforderungen an das Gesamterlebnis der Lösung. Dabei werden u. a. Faktoren wie Personalisierung, geräteübergreifende Persistenz und Anwendererlebnis berücksichtigt.

Erlebnisspezifikationen experience-specifications

Details zu den Anforderungen an die Gestaltung von Erlebnissen.

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. Dazu gehören Elemente wie die externen Integrationen, Schnittstellen, Abhängigkeiten und Netzwerke.

Ausweichsystem und -verfahren fallback-system-and-procedure

Die Definition des Ausweichsystems:

Testen des Ausweichsystems und -verfahrens fallback-system-and-procedure-tested

Vollständiger Test des Ausweichsystems.

Abnahme des Ausweichsystems von Beteiligten aus den Geschäftsbereichen fallback-system-sign-off-from-business-stakeholders

Abnahme von den Beteiligten aus den Geschäftsbereichen, dass das Ausweichsystem und zugehörige Verfahren geschäftskritische Funktionen sicherstellen.

Machbarkeitsnachweis gemäß KPIs feasibility-confirmation-on-kpis

Ergebnisse einer Machbarkeitsstudie sowohl für AEM als auch für den allgemeinen Lösungsentwurf. Diese sollten an den KPIs gemessen werden, um sicherzustellen, dass diese eingehalten werden können.

Fertiggestellter Vertrag finalized-contract

Ein fertiggestellter und unterschriebener Vertrag ist erforderlich, bevor das Projekt fortgesetzt werden kann. Dieser basiert auf dem Vertragsentwurf.

Projektbeteiligte akzeptieren Funktionalität der Lösung functionality-of-the-solution-accepted-by-stakeholders

Bestätigung, dass die Projektbeteiligten Folgendes vollständig akzeptieren:

Zeitplan für die Live-Schaltung go-live-schedule

Zeitplan für die Aktivitäten, die für Folgendes erforderlich sind:

Definition von Happy Paths happy-paths-defined

Ein Happy Path ist ein Standardszenario ohne Ausnahme- oder Fehlerbedingungen. Es besteht aus der Reihenfolge der Aktivitäten, die erfolgen, wenn alles wie erwartet abläuft.

Hardware-Schätzungen hardware-estimates

Anfangsschätzungen der folgenden Elemente:

Verfügbarkeit der Hardware zum Erfüllen der Anforderungen hardware-will-be-available-to-fulfill-requirements

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

Allgemeine Anforderungen high-level-requirements

Die Definition der allgemeinen Anforderungen bietet eine Aufschlüsselung der Anforderungen an das System und umfasst Aspekte wie:

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

Allgemeiner Lösungsentwurf 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 die Hauptkomponenten, die für das Produkt und seine Schnittstellen entwickelt werden.

Allgemeine Systemübersicht high-level-system-map

Diese Systemübersicht sollte ein allgemeines Diagramm des Systems bieten. Sie unterscheidet sich vom Lösungskontext dadurch, dass sie eine verallgemeinerte Übersicht über alle beteiligten Systeme darstellt, da dieses Diagramm keine Schnittstellen enthält.

Bisherige Inhaltsstruktur historical-content-structure

Definition der Inhaltsstruktur des Vorgängersystems. Diese dient als Referenz und auch zur Vorbereitung der Migrationsstrategie.

Leistung und Leistungs-KPIs des Vorgängersystems historical-performance-and-historical-performance-kpis

Sammeln und dokumentieren Sie Leistungsstatistiken und -KPIs des Vorgängersystems. Diese werden dann als Bezugspunkt und Vergleichsmaßstab für die neue Lösung verwendet.

Ermitteln wichtiger Lösungen und Funktionen identify-critical-key-solutions-functionalities

Hierbei handelt es sich um eine Liste der geschäftskritischen Funktionen.

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

Hierbei geht es um die Implementierung aller erforderlichen (genehmigten) Änderungen an der Lösung basierend auf den Ergebnissen der Penetrationstests.

Implementierung einer Strategie für automatisierte Tests implementation-automated-testing-strategy

Hierbei geht es um die Einrichtung der Tools und Prozesse zur Unterstützung automatisierter Tests.

Implementierung der Strategie für automatisierte Tests implementation-automation-strategy

Hierbei geht es um die Einrichtung der Tools und Prozesse zur Unterstützung der Automatisierung.

Implementierung der Inhaltsarchitektur implementation-content-architecture

Hierbei geht es um die Implementierung der Inhaltsarchitektur, Tagging-Konzepte und Wiederverwendung von Inhalten.

Implementierung der Gestaltung des Anwendererlebnisses implementation-experience-design

Hierbei geht es um die Implementierung der Anforderungen zur Unterstützung der Gestaltung des Anwendererlebnisses.

Implementierung von Ausweichsystem und Verfahren implementation-fallback-system-and-procedures

Hierbei geht es um die Implementierung des Ausweichsystems und der zugehörigen Verfahren.

Implementierung von Integrationen implementation-integration

Hierbei geht es um die Implementierung von Integrationen mit allen erforderlichen externen Systemen.

Implementierung der Migrationsstrategie implementation-migration-strategy

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

Implementierung von Rollen und Berechtigungen implementation-roles-and-rights

Hierbei geht es um die Implementierung von Rollen und Berechtigungen, Benutzenden und Gruppen.

Implementierung des Sicherheitskonzepts implementation-security-concept

Hierbei geht es um die Implementierung aller Sicherheitsmaßnahmen, einschließlich der AEM-Standardeinstellungen.

Implementierung von Sicherheits-Software implementation-security-software

Hierbei geht es um die Implementierung der Software-Anwendungssicherheit.

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

Hierbei geht es um die Implementierung der Systemsicherheit.

Implementierung der URL-Behandlung implementation-url-handling

Hierbei geht es um die Implementierung des URL-Behandlungskonzepts.

Implementierung von Workflows implementation-workflows

Hierbei geht es um die 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 beschreibt zudem die in der Lösung verwendeten Frameworks, Bibliotheken und andere Artefakte.

Informieren des Adobe-Supports über den Zeitplan für die Live-Schaltung inform-adobe-support-about-the-go-live-schedule

Wenden Sie sich an den Adobe-Support, um sicherzustellen, dass der benötigte Support während der Live-Schaltung geboten werden kann.

Anfänglicher Entwurf des Anwendererlebnisses initial-experience-designs

Hierbei geht es um vorläufige Konzepte für Entwürfe der Anwendererlebnisse.

Integrationstests integration-testing

Hierbei handelt es sich um Tests aller internen und externen Integrationen sowie die Bestätigung der Ergebnisse.

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

Prozess der Problemverfolgung issue-tracking-process

In übersichtlichen Prozessen werden alle aufgetretenen Probleme aufgezeichnet und die laufenden Aktivitäten verfolgt, um sicherzustellen, dass alle Probleme gelöst werden.

System und Prozesse zur Problemverfolgung issue-tracking-system-and-processes

Es geht um ein Tracking-System, das zusammen mit den erforderlichen Prozessen alle aufgetretenen Probleme aufzeichnet und die laufenden Aktivitäten verfolgt, um sicherzustellen, dass alle Probleme gelöst werden.

Alle Projektbeteiligten sollten Zugang haben, damit die Transparenz des Projektstatus gewährleistet ist.

Beispiele sind Atlassian JIRA und HP Quality Center.

Der Systemprozess für die Problemverfolgung ist eingerichtet und integriert issue-tracking-system-process-is-set-up-and-integrated

Die ausgewählten Tools sind vollständig integriert und für alle Rollen zugänglich, die Zugriff benötigen.

Veraltetes System legacy-system

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

Details zum alten System sollten gesammelt werden, damit Sie wissen, was stillgelegt werden kann und wann, und welche Auswirkungen dies auf andere Systeme hat.

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

Ein Überblick über die Tools, die bei der Implementierung verwendet werden. Folgende Tools sollten enthalten sein:

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

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

Die Liste besteht normalerweise aus der Lösungsarchitektin bzw. dem Lösungsarchitekten und/oder IT-Personal auf Kundenseite.

Protokolldatei-Analyse log-file-analysis

Eine Analyse sowie die daraus resultierenden Empfehlungen, die definieren, was protokolliert werden muss, um die Lösung zu überwachen:

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

Testen und aktivieren Sie AEM-Wartungsaufgaben wie:

Migrationsplan migration-plan

Dokumentieren Sie die Migration, 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 ist zu empfehlen, 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, zu einer doppelten Veröffentlichung oder zur Wartung eines Alpha-Systems führen.

Überwachung – CPU monitoring-cpu

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

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

Überwachung der Ein- und Ausgaberate des Datenträgers durch die Lösung:

Überwachung – Festplattenspeicher monitoring-disk-space

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

Sie sollten die Nutzung überwachen, indem Sie:

Überwachen der externen Systeme monitoring-external-system-s

Überwachen Sie sämtliche Verbindungen zwischen der Lösung und externen Systemen:

Überwachen der Netzwerkbandbreite monitoring-network-bandwidth

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

Überwachung von Anfragen monitoring-requests

Überwachen Sie die Anfragen, die an die Lösung gerichtet werden.

Überwachen der Sicherheitspunkte monitoring-security-points

Überwachen Sie die definierten Sicherheitspunkte.

Überwachen des Systems monitoring-system

Überwachen Sie das gesamte System. Beispiel:

Überwachen von Schwellenwerten und Eingriff monitoring-threshold-and-intervention

Überwachen des definierten Schwellenwerts der Lösung und Durchführen von Eingriffsmaßnahmen zur Lastreduzierung.

Überwachungskonzept monitoring-concept

Die Überwachungskonzepte, die für Ihre Lösung gelten sollen:

Überwachen möglicher Schwachpunkte monitoring-potential-weak-points

Bestimmte Punkte, die ausfallgefährdet sein könnten, müssen identifiziert und definiert werden. Die damit verbundenen Überwachungsaufgaben müssen ebenfalls definiert werden.

Beispiele sind (unter anderem):

Informieren der Systemtechnikerinnen und -techniker über die Überwachungsrichtlinie monitoring-policy-communicated-to-system-engineer

Stellen Sie sicher, dass die Systemtechnikerinnen und -techniker und das Betriebspersonal alle Überwachungsrichtlinien kennen und verstehen.

Einrichten der Struktur für Überwachungsberichte monitoring-reports-structure-in-place

Definieren Sie:

Dokumentation der Betriebsaufgaben operational-tasks-documentation

Alle Betriebsaufgaben wurden dokumentiert und ihre Häufigkeit wurde festgelegt.

Benutzerhandbuch operations-manual

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

Außerdem sollten Implementierungskonzepte für Folgendes detailliert beschrieben werden:

Vorbereitung des Software-Pakets package-prepared

Das Software-Paket wurde erstellt und einsatzbereit bereitgestellt.

Penetrationstests penetration-tests

Ein Penetrationstest (auch als Pentest bezeichnet) ist ein Angriff auf ein Computer-System zur Suche nach Sicherheitslücken, die den Zugriff auf die Funktionen und Daten des Computers ermöglichen.

Penetrationstests bestanden penetration-tests-passed

Alle erforderlichen Kriterien wurden übergeben.

Penetrationstestergebnisse penetration-tests-results

Hierbei handelt es ich um für das Unternehmen erstellte Berichte, die die Ergebnisse der Penetrationstests erläutern.

Leistungs- und Skalierbarkeitskonzept performance-and-scalability-concept

Dieses Konzeptdokument beschreibt, wie Sie sicherstellen können, dass Ihre Implementierung die Leistungs-KPIs erfüllt, und wie Sie die Lösung so skalieren können, dass sie diese KPIs weiterhin erfüllt.

Leistungs-Benchmark performance-benchmark

Die Leistungs-Benchmark dient zur Definition von Leistungstests, Stabilitätstests und Monitoring. 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 benötigt werden, um die Leistung des Systems zu messen. Einige Beispiele sind die Seitenladezeit, die Antwortzeit des Servers und die Leistung der Datenbankabfrage.

Leistungstestberichte performance-tests-report

Hierbei handelt es sich um für das Unternehmen erstellte Berichte, in denen die Ergebnisse der Leistungstests detailliert beschrieben werden.

Leistungstestergebnisse entsprechen Leistungs-KPIs performance-tests-results-match-performance-kpis

Die Ergebnisse müssen den definierten KPIs und Leistungserwartungen entsprechen.

Rollenbasiertes Testkonzept persona-based-testing-concept

Rollenbasierte Tests sind eine Methode, die auf den verschiedenen Rollentypen basiert, die in den Entwürfen des Anwendererlebnisses beschrieben sind. Außerdem werden die Konten und die damit verbundenen Berechtigungsstufen getestet.

Dieses Konzept wird häufig bei Benutzerakzeptanztests (UAT) verwendet.

Prüfung und Verifizierung des Machbarkeitsnachweises im Abgleich mit der Anforderungsdokumentation poc-tested-and-verified-against-requirement-documentation

Die Machbarkeit (Proof of Concept, POC) wird an den Anforderungen gemessen, um sicherzustellen, dass eine Übereinstimmung vorliegt.

Checkliste für Aufgaben nach der Bereitstellung post-deployment-checklist

Hierbei handelt es sich um eine Checkliste, um die Prüfungen und Aufgaben zu definieren, die nach jeder Bereitstellung durchzuführen sind.

Checkliste für Aufgaben vor der Bereitstellung pre-deployment-checklist

Hierbei handelt es sich um eine Checkliste, um die Prüfungen und Aufgaben zu definieren, die vor jeder Bereitstellung durchzuführen sind.

Basisleistungstests für die Produktionsumgebung production-environment-baseline-performance-tests

Bei einer Standardinstallation von AEM ist es üblich, einen Basisleistungstest durchzuführen. Dieser wird dann als Benchmark verwendet, gemäß der Implementierung und Hardware getestet werden.

Bereitschaft der Produktionsumgebung production-environment-ready

Vergewissern Sie sich, dass die Produktionsumgebung bereit ist und automatisierte Bereitstellungen erfolgt sind.

Abnahme für die Produktion durch die Projektbeteiligten aus den Geschäftsbereichen production-sign-off-from-business-stakeholders

Vor der Live-Schaltung für die Produktionsumgebung muss die entsprechende Abnahme erfolgen. Dies ist das Ergebnis einer Überprüfung der Version, die in der Produktionsumgebung eingesetzt wird, zusammen mit allen bekannten Problemen. Die Abnahme ist Teil des Zeitplans für die Live-Schaltung.

Prozess und Richtlinien bei der Abnahme für die Produktion production-sign-off-process-and-policy

Hierbei geht es um die Richtlinien und den Prozess, die erforderlich sind, um die Abnahme für die Produktion zu erhalten, bevor das Paket in die Produktionsumgebung überführt wird.

Projektkommunikationsplan project-communication-plan

Definieren Sie den Kommunikationsplan für die Projektbeteiligten aus den Geschäftsbereichen und das Projekt-Team.

Projektaufwand: Endgültige Schätzungen project-efforts-final-estimates

Die ersten Schätzungen waren allgemein und erfolgten gemäß den allgemeinen Anforderungen für die Implementierung.

Diese werden nun überprüft, verfeinert und erweitert, um die endgültigen Schätzungen zu erhalten. Die Schätzungen sollten von jeder zuständigen Projektleitung vorgelegt werden, einschließlich Projekt-Management, Beratung, Architektur, Tests und Entwicklung.

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

Projektaufwand: Erste Schätzungen project-efforts-initial-estimates

Die ersten Schätzungen sind allgemein und erfolgen gemäß den allgemeinen Anforderungen für die Implementierung. Sie werden zu späteren Zeitpunkten überprüft und verfeinert.

Projektorganisation project-organization

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

Oftmals in Form eines Diagramms, um einen anschaulichen Ü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 angeben und dokumentieren:

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

Projektstatusberichte in definiertem Rhythmus project-status-reports-within-a-defined-cadence

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

Machbarkeitsstudie (POC) proof-of-concept-poc

Für die Machbarkeitsstudie (Proof of Concept, POC) wird ein begrenzter Funktionsumfang der Lösung implementiert.

Ziel ist es, die Machbarkeit der Lösung nachzuweisen, zu überprüfen, ob sie den geforderten Zweck erfüllen kann, und zu belegen, dass das Potenzial ihrer Nutzung vorhanden ist.

Bereinigungsregeln purge-rules

AEM verwaltet mehrere Versionen von Objekten und Inhalten. Bereinigungsregeln sind so konzipiert und konfiguriert, dass ältere Versionen regelmäßig entfernt werden, um Integrität und Größe des Repositorys im Griff zu behalten.

Format und Rhythmus 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.

Freigabekoordination release-coordinated

Die Projektleitung koordiniert alle Rollen, die für die Freigabe in der Produktionsumgebung erforderlich sind.

Versionshinweise release-notes

Versionshinweise sind Teil der Dokumentation für die Freigabe. Die Versionshinweise sollten Folgendes abdecken:

Dieses Dokument wird zusammen mit dem Runbook verwendet, um vor und nach der Installation Arbeitsschritte und Prüfungen durchzuführen.

In der Produktionsumgebung ausgeführte Version release-running-on-production-environment

Die endgültige Version, die in der Produktion ausgeführt wird.

Relevante Vertragsbedingungen relevant-contract-terms

Heben Sie bestimmte Vertragsbedingungen hervor, die für die Umsetzung des Projekts relevant sind, wie z. B. vertragliche Meilensteine, Abrechnungszeiträume oder Personalbedarf.

Berichterstellungsrhythmus reporting-cadence

Definieren Sie gemeinsam mit der Kundschaft die Häufigkeit der ihnen übermittelten Berichte.

Repository-Optimierung repository-optimization

Daten in einer TAR-Datei werden nie überschrieben, sodass die Festplattenauslastung steigt, auch wenn nur vorhandene Daten aktualisiert werden.

Um der immer weiter zunehmenden Größe des Repositorys entgegenzuwirken, wird eine Optimierungsstrategie zur Entfernung veralteter Daten verfolgt.

Anfrage für das Einrichten eines Projektabschnitts im Adobe Support-Portal request-for-setting-up-project-section-in-adobe-support-portal

Die offizielle Anfrage im Adobe Support-Portal, Ihr Projekt einzurichten.

Dokumentation der Anforderungen requirements-documentation

Diese Dokumentation deckt die funktionalen und nicht funktionalen Anforderungen sowie den geschätzten Aufwand ab.

Für die Live-Schaltung verfügbare Ressourcen resources-available-to-support-go-live

Stellen Sie sicher, dass alle für die Live-Schaltung erforderlichen Rollen besetzt und präsent sind.

Risikobewertung risk-assessment

Die Risikobewertung wird auf Kundenseite von der IT-Abteilung, der Sicherheitsabteilung oder beidem durchgeführt.

In ihr werden die technischen und geschäftlichen Risiken des Projekts bewertet. Die Bewertung ist für die Lösung erforderlich, um die Einhaltung von Sicherheitsrichtlinien zu gewährleisten.

Risikominimierungsplan risk-mitigation-plan

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

ROI-Erwartungen roi-expectations

Definieren Sie die Erwartungen an die Rentabilität (Return on Investment, ROI) der Lösung.

Ziel ist es, die Effizienz der Lösung in wirtschaftlicher Hinsicht aufzuzeigen, indem der erwartete Nutzen/Gewinn im Verhältnis zur geschätzten Investition definiert wird.

Rollen- und Rechtekonzept roles-and-rights-concept

Detaillierte Spezifizierung der Konzepte in Bezug auf Rollen und Zugriffsrechte, die für die neue Anwendung erforderlich sind, einschließlich einer allgemeinen Übersicht der folgenden Elemente:

Erfüllung der Sicherheitsrichtlinien durch das Rollen- und Rechtekonzept roles-and-rights-concept-meets-security-guidelines

Überprüfung des Rollen- und Rechtekonzepts, um sicherzustellen, dass es den Sicherheitsrichtlinien entspricht.

Spezifikation von Rollen und Rechten roles-and-rights-specification

Eine detaillierte Spezifikation basierend auf dem Rollen- und Rechtekonzept.

Empfehlungen für die Sicherheitsarchitektur security-architecture-recommendations

Empfehlungen für die Sicherheit der Software- und Hardware-Architektur.

Sicherheitsbasierte Kodierungsrichtlinien security-based-coding-guidelines

Diese Richtlinien legen fest, wie die Entwicklungskodierung basierend auf den folgenden Sicherheitsanforderungen erfolgen soll:

Sicherheitscheckliste security-checklist

Projektspezifische Checkliste der Elemente, die auf dem Sicherheitskonzept sowie zusätzlichen Richtlinien zur Sicherstellung der Konformität der Lösung basiert.

Diese Liste wird oft auch als Teil der Schritte nach der Bereitstellung in das Runbook aufgenommen.

Sicherheitskonzept security-concept

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

Sicherheitskonzeptentwurf security-concept-draft

Allgemeine Übersicht über die Sicherheitseinstellungen der folgenden Elemente:

Erfasste und eingestufte Sicherheitsprobleme security-issues-listed-and-assessed

Alle erfassten und eingestuften Sicherheitsprobleme der Lösung einschließlich Aufwandschätzungen.

Sicherheitsabnahme der Verantwortlichen aus den Geschäftsbereichen security-sign-off-from-business-stakeholders

Abnahme durch diese Verantwortlichen, um sicherzustellen, dass die Sicherheitsmaßnahmen mit den Richtlinien und Erwartungen übereinstimmen.

Einrichten von Support-Prozessen set-up-support-processes

Richten Sie die erforderlichen Support-Prozesse ein.

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 Betriebs-Teams kommuniziert werden, um während der Implementierung und beim Support verwendet werden zu können.

Feuerprobenkonzept smoke-test-concept

Feuerproben 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 in jeder Umgebung nach der Installation oder Bereitstellung ausgeführt.

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

Feuerproben 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.

Strategie für die Software-Architektur software-architecture-strategy

Die allgemeine Strategie für die Software-Architektur, einschließlich Services, Servlets, Frameworks und anderen Implementierungsentscheidungen.

Bildung einer Lösungsüberprüfungskommission und Festlegen eines Besprechungszeitplans solution-review-board-established-and-meeting-cadence-set

Die Lösungsüberprüfungskommission besteht aus Projektbeteiligten auf Kundenseite.

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.

Runbook der Lösung solution-runbook

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

Lösungsabnahme und zugehöriger Prozess 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.

Konzept für Spezialfunktionalität special-functionality-concept

Das anfängliche Konzept für Spezialfunktionalität, die außerhalb des normalen Entwicklungsumfangs auf der AEM-Plattform liegt.

Spezifikation für Spezialfunktionalität special-functionality-specification

Details zu jeder Spezialfunktionalität, die außerhalb des normalen Entwicklungsumfangs auf der AEM-Plattform liegt.

Spezifikationsrichtlinien specification-guidelines

Alle Richtlinien auf Kundenseite, wie die Spezifikation durchgeführt werden soll.

Definierter und kommunizierter Überprüfungs- und Genehmigungsprozess für die Spezifikation specification-review-and-approval-process-defined-and-communicated

Es sollte ein eindeutiges Verfahren für die Abnahme von Spezifikationen auf Kundenseite vorhanden sein. Dieser Prozess gewährleistet Klarheit und Festigkeit des Umfangs für die Anforderungen.

Auswahl der Mitarbeitenden für die AEM-Admin-Schulung staff-selected-for-aem-administrator-training

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

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

Interne Mitarbeiterinnen und Mitarbeiter, die für Authoring in der Lösung geschult werden müssen.

Projektbeteiligte stakeholders

Projektbeteiligte sind die wichtigsten Personen und/oder Rollen, die ein erhebliches Interesse an dem Projekt haben. Einige tragen zum Projektbudget bei.

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

Die Projektbeteiligten kennen die Erfolgsdefinitionen und -kriterien stakeholders-are-aware-of-success-definitions-and-criteria

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

Die Projektbeteiligten verstehen das Projekt und die Erwartungen stakeholders-understand-project-and-expectations

Bestätigung, dass alle Projektbeteiligten außerhalb des eigentlichen Implementierungs-Teams mit dem Gesamtprojekt und den Erwartungen übereinstimmen, sowohl intern gegenüber dem Projekt-Team als auch gegenüber der Kundschaft.

Definition des Statusberichtformats status-report-format-definition

Statusberichte sind ein wichtiges Kommunikationsmittel. Das Format sollte mit allen Anforderungen der Kundschaft an die Berichterstellung abgestimmt sein.

Erfolgskriterien und -definition success-criteria-and-definition

Die Kundin bzw. der Kunde sowie die Sponsorin bzw. der Sponsor, die Managerin bzw. der Manager oder die Beraterin bzw. der Berater des Projekts sollten Folgendes spezifizieren:

Die Informationen werden verwendet, um sicherzustellen, dass die Erfolgskriterien erfüllt werden, und zwar:

Unterstützung bei der Überprüfung gemeldeter Probleme support-in-validation-of-reported-issues

Zu den Aufgaben der Leitung der Qualitätssicherung gehört es sicherzustellen, dass Ressourcen zur Verfügung stehen, um beim Testen alle Benutzenden zu unterstützen, z. B. beim Testen, Melden von Problemen und Überprüfen der Probleme in der Testumgebung.

Support-Prozesse und Zugriff auf das Adobe-Support-Portal support-processes-and-access-to-adobe-support-portal

Der Zugriff auf das Adobe-Support-Portal ist für die Übermittlung von Tickets zu allen produktbezogenen Problemen unerlässlich, die während der Implementierung auftreten können.

Der Zugriff sollte den wichtigsten Team-Mitgliedern gewährt werden.

Definition der Systemarchitektur system-architecture-definition

Hierbei handelt es sich um einen ersten Vorschlag und eine erste Definition der Architektur für alle Umgebungen der Lösung.

Dokumentation der Systemarchitektur system-architecture-documentation

Hierbei handelt es sich um ein Dokument, das die Systemarchitektur detailliert beschreibt, einschließlich Schnittstellen, Netzwerkadressen und Integrationen für alle Umgebungen sowie anderer Informationen.

Sicherheitskonzept der Systemarchitektur system-architecture-security-concept

Hierbei handelt es sich um einen allgemeinen Überblick darüber, wie sich die Systemarchitektur mit Sicherheitsrichtlinien in Einklang bringen lässt. Dies kann Folgendes umfassen:

Identifizierte und bestätigte Systemrisikofaktoren system-risk-factors-identified-and-verified

Alle bei der Risikobewertung (oder anderen Überprüfungen) gefundenen Risikofaktoren werden identifiziert und bewertet:

Vertrautheit des Teams mit den Erfolgsdefinitionen und -kriterien team-is-aware-of-success-definitions-and-criteria

Hierbei geht es um die Bestätigung, dass das gesamte Team mit den Erfolgsdefinitionen und -kriterien vertraut ist.

Vertrautheit des Teams mit dem Kommunikationsplan team-is-aware-of-the-communication-plan

Hierbei geht es um die Bestätigung, dass alle Mitglieder des Teams wissen, wer mit der Kundin bzw. dem Kunden kommunizieren soll, einschließlich Details zum Wie und Wann.

Vertrautheit des Teams mit dem Projekt und den Erwartungen team-understands-project-and-expectations

Dies bezieht sich auf den Einklang mit dem Gesamtprojekt und den Erwartungen, sowohl intern für das Projekt-Team als auch für die Kundin bzw. den Kunden.

Technische Anforderungen technical-requirements

Diese Anforderungen sind spezifisch für die technische Implementierung von Diensten, die die Lösung unterstützen.

Überprüfen technischer Risikofaktoren technical-risk-factors-verified

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

Technische Spezifikation technical-specification

Die technische Spezifikation deckt (u. a.) Folgendes ab:

Vorlagenspezifikation template-specification

Hierbei handelt es sich um die Spezifikationen für die erforderlichen Vorlagen. Diese sollten Details wie z. B. zum Absatzsystem, Blueprint und Vererbungszuordnung bieten.

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

Testfälle test-cases

Testfälle spezifizieren die detaillierten Schritte, die zur Durchführung von Funktionstests der Lösung erforderlich sind.

Testinhalte test-content

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

Bereitschaft der Testumgebung test-environment-ready

Sorgen Sie dafür, dass die Testumgebung bereit ist und automatisierte Bereitstellungen vorhanden sind, um sicherzustellen, dass der gesamte Freigabekandidaten-Code für Tests aktuell ist.

Testberichte test-reports

Berichte mit den Testergebnissen, einschließlich:

Beachten Sie Folgendes:

Testsuite test-suite

Auswahl der Automatisierungssuite und -tools.  Diese werden zur Automatisierung von Tests, einschließlich für Anwendungsfälle, verwendet.

Auswahl einer Suite mit Test-Tools test-tooling-suite-selected

Automatisierungssuite und -tools für die Automatisierung von Anwendungsfällen und anderen Testausführungsaufgaben.

Testkonzept testing-concept

Das Testkonzept stellt eine allgemeine Übersicht über die Tests für das Projekt dar, einschließlich Tests der Qualitätssicherung, Benutzerakzeptanz, Leistung, Sicherheit und Integration.

Testpläne testing-plans

Diese Pläne beschreiben im Detail die Ausführung von Tests für jede Entwicklungsphase und basieren auf der Teststrategie.

Testumfang testing-scope

Diese Anforderungen sind spezifisch für die technische Implementierung von Diensten, die die Lösung unterstützen.

Teststrategie testing-strategy

Die Teststrategie skizziert die allgemeine Strategie für Qualitätssicherung und Benutzerakzeptanztests.  Dazu gehören Zeitpläne, Berichterstellungsrhythmus und Ausführung.

Konzept für die Integration von Systemen von Drittanbietern third-party-integration-concept

Konzept auf Architektur- und Systemebene für die Integration mit Systemen von Drittanbietern.

Spezifikation der Integrationen von Systemen von Drittanbietern third-party-integration-specification

Details zu den (sowohl funktionalen als auch nicht funktionalen) Anforderungen an die unterstützte Funktionalität und Integration der Systeme von Drittanbietern.

Sicherheitskonzept für Integrationen von Drittanbietern third-party-security-concept

Konzept zur Gewährleistung der Sicherheit von Integrationen von Drittanbietern.  Muss mit den entsprechenden Sicherheitsrichtlinien konform sein.

Systeme von Drittanbietern für die Integration third-party-system-for-integration

Stellen Sie sicher, dass alle Systeme von Drittanbietern mit der entsprechenden Dokumentation für die Implementierung der Integration zur Verfügung stehen.

Aktivieren des Zugriffs auf Systeme von Drittanbietern third-party-systems-access-enabled

Die erforderlichen Zugriffsrechte müssen den jeweiligen Rollen gewährt werden, die in Verbindung mit Systemen von Drittanbietern verwendet werden.

Testkonzept für Drittanbieter third-party-testing-concept

Definiert Folgendes:

Festlegung von Schwellenwerten threshold-definition

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

Beispiel:

Timeline und Meilensteine timeline-and-milestones

Hierin sollten die zu verwendenden Projektzeitpläne und vertraglichen Meilensteine für Folgendes festgelegt werden:

Gesamtprojektaufwand total-project-efforts

Alle Aufwandsschätzungen der einzelnen Projektbeteiligten müssen zusammengeführt werden, einschließlich Gemeinkosten, Entwicklung, Systemtechnik, Architektur und Testaufwand.

Wenn der Vertrag eine Support-Ebene enthält, müssen auch der Support- und Betriebsaufwand einbezogen werden.

Schulungsmaterialien training-materials

In Schulungssitzungen zu verwendende Materialien. Die Materialien müssen speziell für die Lösung erstellt und mit den Benutzerhandbüchern verwendet werden.

Vertrautheit mit dem Projektumfang und Erwartungen understands-scope-of-project-and-expectations

Die entsprechenden Personen müssen bestätigen, dass sie Folgendes vollständig verstehen:

URL-Behandlungskonzept url-handling-concept

Ihr URL-Behandlungskonzept muss die folgenden AEM-spezifischen URL-Funktionen abdecken:

Das Konzept muss auch Folgendes abdecken:

Anwendungsfälle use-cases

Ein Anwendungsfall ist die Liste der Aktionen oder Ereignisschritte, die zur Erreichung eines Ziels ausgeführt werden müssen. In der Regel dienen sie zur Definition der Interaktionen zwischen einer Rolle und der Lösung. Die Rolle kann eine Benutzerin bzw. ein Benutzer oder ein externes System sein.

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

Testszenarien basieren auf den technischen und geschäftlichen Anwendungsfällen. Mit ihnen wird geprüft, ob das Lösungsverhalten den Erwartungen entspricht.

Benutzerhandbücher user-guides

Benutzerhandbücher bieten den Benutzenden der Lösung Informationen und Unterstützung:

Validierter Budgetplan validated-budget-plan

Der Budgetplan muss von allen Projektbeteiligten überprüft und bestätigt werden. Dabei müssen Details wie Fakturierung, Beträge und Methoden/Termine der Budgetberichterstellung überprüft werden.

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. White-Box-Tests können auf Einheits-, Integrations- und Systemebene des Software-Testprozesses erfolgen.

Workflow-Spezifikationen workflow-specifications

Basierend auf dem Konzept von Workflows müssen diese Spezifikationen im Detail die Schritte definieren, mit denen der gesamte Workflow erstellt wird.

Die Spezifikation jedes Workflows sollte (mindestens) Folgendes enthalten:

Konzept von Workflows workflows-concept

Workflows ermöglichen es Ihnen, AEM-Aktivitäten zu automatisieren. Das Workflow-Konzept beschreibt Folgendes: