Dieses Glossar listet (alphabetisch) alle lieferbaren Dokumente in der Projektcheckliste auf.
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 der Wirtschaftlichkeitsbetrachtung entsprechen.
Akzeptanztests erfolgen, wenn eine Anwendung produktionsreif ist. Die Tests werden von einer Gruppe durchgeführt, die die verschiedenen Arten von Endanwendern basierend auf realen 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 den Kunden und Ihrem Qualitätssicherungsteam 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 vermutlich an den grundlegenden Anforderungen (an Funktionen und Leistung).
Vergewissern Sie sich, dass allen Rollen die erforderlichen Systemzugriffsrechte gewährt wurden.
Die Sicherheits-Checkliste von Adobe ist die offizielle Checkliste, 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.
Das Adobe Support-Portal ermöglicht es Implementierungspartnern und 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 Kunden und Adobe.
Schulungen für das Verwaltungspersonal der Lösung. Unter Adobe Training Services finden Sie weitere Informationen.
Schulung für Mitarbeiter, die Inhalte für die Lösung erstellen. Unter Adobe Training Services finden Sie weitere Informationen.
Stellen Sie sicher, dass die gewünschten Rollen für die jeweiligen Zertifizierungsprüfungen registriert sind.
Stellen Sie sicher, dass die gewünschten Rollen die jeweiligen Zertifizierungsprüfungen bestanden haben.
Bieten Sie technische Schulungen für die gewünschten Rollen an, z. B. für Entwickler, Architekten, Ingenieure und kaufmännische Fachleute.
KPIs (Key Performance Indicators, Leistungsindikatoren) helfen einem Unternehmen, Fortschritte bei der Erreichung von Unternehmenszielen zu definieren und zu messen. Sobald ein Unternehmen seine Aufgabenstellung analysiert und Ziele definiert hat, muss es den Fortschritt mit Blick auf diese Ziele messen. KPIs dienen als Messmechanismus.
Die Abstimmung Ihrer Geschäfts- und Leistungs-KPIs hilft, alle beteiligten Personen und Prozesse innerhalb des Unternehmens zusammenzubringen. Dies wiederum trägt dazu bei, den Zeit- und Arbeitsaufwand zur Erreichung der Unternehmensziele und zur Erfüllung des angestrebten Zwecks zu verringern.
Stellen Sie sicher, dass die vorgeschlagene Inhaltsarchitektur auf die relevanten Key Performance Indicators (KPIs) abgestimmt ist.
Die Kunden-Roadmap besteht aus allgemeinen Milestones und Geschäftszielen. Der Projektzeitplan 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.
Die Anwendungsarchitektur muss das Verhalten der geplanten Anwendungen klar definieren.
Ihr Fokus liegt auf Folgendem:
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.
Stellen Sie sicher, dass Ihr Team aus Mitarbeitern mit entsprechender Qualifikation besteht. Zu Projektteams müssen die folgenden Mitglieder zählen:
Mindestens ein AEM-zertifizierter Entwicklungsleiter
Mindestens ein AEM-zertifizierter Architekt
mindestens 75 % Ihrer Entwickler AEM zertifiziert sind;
Dies ermöglicht es den zertifizierten Entwicklern, Nachwuchsentwickler zu betreuen und sorgt für Wissensaustausch und Transparenz
Das Architekturdiagramm ist eine grafische Darstellung der Architektur. Es zeigt Folgendes:
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.
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.
Automatisierungsskripts und einfache automatisierte Anwendungsfälle:
Diese Strategie definiert ein Framework für wiederverwendbare automatisierte Skripts im Zusammenspiel mit dem vom Qualitätssicherungsteam geplanten Ansatz. Sie skizziert den allgemeinen Plan für Automatisierungstests, um Folgendes sicherzustellen:
Die Testautomatisierungsstrategie muss validiert und an den Inhalt und die zu erwartende Last der Lösung angepasst werden.
Die Automatisierung von Bereitstellungen sorgt für Beschleunigung und Konsistenz. Die Automatisierungsstrategie regelt die Konfiguration von Automatisierungsmechanismen und umfasst Folgendes:
Das gesamte Projektteam und alle Projektbeteiligten müssen bestätigen, dass ihnen Folgendes bekannt ist:
Das gesamte Projektteam und alle Projektbeteiligten müssen bestätigen, dass ihnen Folgendes bekannt ist:
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.
Ein vollständiger durchgängiger Test des Sicherungs- und Wiederherstellungskonzepts.
Ein Dokument mit einem Geschäftsszenario 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 Geschäftsszenario sollte eine klare Definition aller Optionen enthalten und mit einem überzeugenden Argument für die Umsetzung der vorgeschlagenen Lösung schließen.
Geschäftsanalysten müssen bestätigen, dass sie Folgendes vollständig verstehen:
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 zu wählen, die zu Ihrem Unternehmen/Szenario passen, mit klaren Definitionen dessen, was sie sind, wie sie gemessen werden, wie sie verwendet werden und von wem.
Ein Geschäftsanforderungsdokument beschreibt die Geschäftslösung für ein Projekt und liefert eine klare Präzisierung der Geschäftsanforderungen und -erwartungen des Kunden. Es unterscheidet auch zwischen der geschäftlichen und der technischen Lösung.
Bei der Prüfung der Geschäftslösung sollte dieses Dokument die Frage beantworten: „Was will das Unternehmen erreichen?“
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.
Die Cachingstrategie beschreibt, was für Endanwender zwischengespeichert wird. Sie muss mit den Leistung-KPIs konform sein.
Beispielsweise können Elemente wie Bilder, JavaScript und andere Serverdateien zwischengespeichert werden, um die Leistung einer Lösung zu verbessern.
Die Kodierungsrichtlinien definieren Grundprinzipien, an die sich die Entwickler bei der Entwicklung der Lösung halten müssen. Dazu zählen u. a.:
Stellen Sie sicher, dass alle relevanten Rollen das Betriebshandbuch erhalten.
Stellen Sie sicher, dass alle relevanten Rollen den Leistungstestbericht erhalten.
Stellen Sie sicher, dass alle relevanten Rollen die Versionshinweise erhalten.
Stellen Sie sicher, dass das Projektteam den Projektumfang und die Liefererwartungen genau kennt und sich darauf einstellt.
Stellen Sie sicher, dass alle relevanten Rollen die Schulungsmaterialien und Benutzerhandbücher erhalten.
Stellen Sie sicher, dass alle Sicherheitsanforderungen des Kunden eingehalten werden.
Stellen Sie sicher, dass das Sicherheitskonzept eingehalten wird.
Die Übersicht über die Vorlagen und Komponenten, die in der neuen Anwendung verwendet werden. Enthält u. a. Details zu Vererbungsregeln, Berechtigungen und Beziehungen.
Details des Konzepts der Beziehungen zwischen Komponenten und Vorlagen.
Details zu allen Komponenten, die implementiert werden sollen.
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.
Dokumentation der geplanten Architektur des Inhalts. Die Details sollten u. a. Folgendes umfassen:
Die Inhalte des Altsystems werden überprüft und die ausgewählten Inhalte für die Migration in die neue Lösung validiert.
Ein erster Entwurf des rechtsgültigen Vertrags.
Dokumentation der aktuellen Inhaltsstruktur und des Formats. Mit ihrer Hilfe wird die künftige Inhaltsarchitektur generiert. Sie wird auch für das Migrationskonzept verwendet.
Richtlinien des Kunden für:
Richtlinien/Anforderungen des Kunden, wie die Entwicklung erfolgen soll.
Richtlinien des Kunden, die festlegen, wie und wann Bereitstellungen/Freigaben erfolgen können.
Dazu gehören oft Zeitpläne, Termin- und Abnahmeanforderungen.
Richtlinien und Anforderungen des Kunden, was überwacht werden soll. Diese ergänzen die im Überwachungskonzept genannten Empfehlungen.
Der Zeitplan, der vom Kunden für die Freigabe an die Produktionsumgebung definiert wird.
Richtlinien und/oder Anforderungen, die der Kunde in Bezug auf die Berichterstellung hat. Diese können Folgendes umfassen:
Formulieren Sie eine Roadmap der wichtigsten Milestones, die umgesetzt werden müssen, sowohl in technologischer als auch geschäftlicher Hinsicht. Diese Roadmap wird dann dem Kunden übergeben.
Der Kunde (kaufmännischer und IT-Bereich) verfügt über Richtlinien, die die erforderlichen Sicherheitsstufen für die Lösung definieren. Diese können Folgendes umfassen:
Alle vom Kunden vorgegebenen Richtlinien in Bezug auf Format, Lieferung und Abnahme der Spezifikationen.
Berichte des Kunden an den Qualitätsleiter im Verlauf des Benutzerakzeptanztests.
Anpassungen und/oder angewendete Hotfixes müssen dokumentiert werden, da sie sich auf künftige Upgrades auswirken können:
AEM kann weitgehend an die jeweiligen Geschäftsanforderungen angepasst werden. Alle Anpassungen, die sich auf Upgrades auswirken können, müssen vollständig dokumentiert werden. Zum Beispiel alle wichtigen Änderungen an der Benutzeroberfläche (UI) von AEM.
Alle Updates, die für die aktuelle Lösung erforderlich sind, müssen vollständig dokumentiert werden. Dazu zählen:
Berichte oder Meetings als Folge von Benutzerakzeptanztests. Müssen Details zu Folgendem enthalten:
Vergewissern Sie sich, dass die Standardsicherheitseinstellungen für AEM aktiviert bzw. implementiert wurden.
Festgelegte Richtlinien, die sowohl die Bereitstellung als auch die Freigaben Ihres Projekts abdecken. Diese können Folgendes umfassen:
Definieren Sie die erforderliche Häufigkeit von Bereitstellungen in Umgebungen.
Eine Softwareentwicklungsmethodik sieht vor, den gesamten Prozess der 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 Ergebnisse und Artefakte vordefinieren, die vom Projektteam erstellt und ergänzt werden, um Ihre Anwendung zu entwickeln oder zu pflegen.
Definieren Sie, welcher Entwickler und/oder welche Rolle IT- (Leistungs- oder andere) und/oder Unit-Tests innerhalb der Lösung ausführt.
Vergewissern Sie sich, dass die Entwicklungsumgebung mit den für die Automatisierung von Bereitstellungen erforderlichen integrierten Tools konfiguriert ist.
Das Entwicklungsteam muss bestätigen, dass es Folgendes vollständig versteht:
Informationen zu den für die Lösung erforderlichen Dialogfeldern.
Dokumentation der Entwicklungsumgebung.
Dokumentation der Produktionsumgebung.
Dokumentation der Testumgebung.
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 Leistungsgraden stabil bleibt.
Stabilitätstests müssen erfolgen.
Die Fehlerbehebung bezieht sich auf die Antizipation, Erkennung und Behebung von Programmier-, Anwendungs- und Kommunikationsfehlern.
Detaillierte Dokumentation der geplanten Fehlerbehebung basierend auf dem Fehlerbehebungskonzept.
Definition aller Eskalationsprozesse. Es gibt für jede Projektebene separate Prozesse:
Legen Sie regelmäßige Qualitätsüberprüfungssitzungen mit den entsprechenden Teammitgliedern fest.
Dokumentation der vorhandenen Berechtigungen und Gruppen, die entweder für die Vorgängerlösung oder innerhalb des Unternehmens definiert wurden.
Ein oder mehrere Diagramme der vorhandenen Systeme und Abhängigkeiten.
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.
Erwartungen können sich auf Folgendes beziehen:
Anforderungen an das gesamte Anwendererlebnis der Lösung. Dies umfasst u. a. Faktoren wie Personalisierung, geräteübergreifende Persistenz und Anwendererlebnis.
Details zu den Anforderungen an die Gestaltung des Anwendererlebnisses.
Ein oder mehrere Diagramme, die das gesamte Ökosystem der Lösung veranschaulichen. Dazu gehören Elemente wie die externen Integrationen, Schnittstellen, Abhängigkeiten und Netzwerke.
Die Definition des Ausweichsystems:
Vollständiger Test des Ausweichsystems.
Abnahme von den Beteiligten aus den Geschäftsbereichen, dass das Ausweichsystem und zugehörige Verfahren geschäftskritische Funktionen sicherstellen.
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.
Ein fertiggestellter und unterschriebener Vertrag ist erforderlich, bevor das Projekt fortgesetzt werden kann. Dieser basiert auf dem Vertragsentwurf.
Bestätigung, dass die Projektbeteiligten Folgendes vollständig akzeptieren:
Zeitplan für die Aktivitäten, die für Folgendes erforderlich sind:
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.
Anfangsschätzungen der folgenden Elemente:
Bestätigung, dass alle Umgebungen über die erforderliche Mindest-Hardware verfügen.
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.
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.
Diese Systemübersicht sollte ein sehr allgemeines Diagramm des Systems bereitstellen. Sie unterscheidet sich vom Lösungskontext dadurch, dass sie eine verallgemeinerte Übersicht über alle beteiligten Systeme darstellt, da dieses Diagramm keine Schnittstellen enthält.
Definition der Inhaltsstruktur des Vorgängersystems. Diese dient als Referenz und auch zur Vorbereitung der Migrationsstrategie.
Sie müssen Leistungsstatistiken und -KPIs des Vorgängersystems sammeln und dokumentieren. Diese werden dann als Bezugspunkt und Vergleichsmaßstab für die neue Lösung verwendet.
Eine Liste der geschäftskritischen Funktionen.
Implementierung aller erforderlichen Änderungen (die abgezeichnet wurden) an der Lösung basierend auf den Ergebnissen der Penetrationstests.
Einrichtung der Tools und Prozesse zur Unterstützung automatisierter Tests.
Einrichtung der Tools und Prozesse zur Unterstützung der Automatisierung.
Implementierung der Inhaltsarchitektur, Tagging-Konzepte und Wiederverwendung von Inhalten.
Erfüllen der Anforderungen zur Unterstützung der Gestaltung des Anwendererlebnisses.
Implementierung des Ausweichsystems und der zugehörigen Verfahren
Implementierung von Integrationen mit allen erforderlichen externen Systemen.
Migration zusammen mit der Validierung von Inhalten und anderen Artefakten für die neue Lösung.
Implementierung von Rollen und Berechtigungen, Benutzern und Gruppen.
Umsetzung aller Sicherheitsmaßnahmen, einschließlich der AEM-Vorgaben.
Implementierung der Software-Anwendungssicherheit.
Implementierung der Systemsicherheit.
Umsetzung des URL-Behandlungskonzepts.
Implementierung der entworfenen Workflows.
Das Implementierungskonzept bietet die Leitlinien für die gesamte Implementierung. Folgendes sollte berücksichtigt werden:
Dieses Konzept kann auch die in der Lösung verwendeten Frameworks, Bibliotheken und andere Artefakte beschreiben.
Wenden Sie sich an den Adobe Support, um sicherzustellen, dass der benötigte Support während der Live-Schaltung geboten werden kann.
Vorläufige Konzepte für Entwürfe der Anwendererlebnisse.
Testen aller internen und externen Integrationen und Prüfen der Ergebnisse.
Dieser Prozess sollte automatisiert und häufig ausgeführt werden, um Systemstabilität zu gewährleisten.
In übersichtlichen Prozessen werden alle aufgetretenen Probleme aufgezeichnet und die laufenden Aktivitäten verfolgt, um sicherzustellen, dass alle Probleme gelöst werden.
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, um den Projektstatus einfach prüfen zu können.
Beispiele sind Atlassian JIRA und HP Quality Center.
Die ausgewählten Tools sind vollständig integriert und allen benötigten Rollen wurde Zugriff gewährt.
Das Vorgängersystem für Ihr Projekt ist die bestehende Technologie, das Computersystem oder Anwendungsprogramm, die bzw. das durch die neue Lösung ersetzt wird.
Details des Vorgängersystems müssen ermittelt werden, damit Sie wissen, was wann ausrangiert werden kann und welche Auswirkungen dies auf andere Systeme hat.
Ein Überblick über die Tools, die bei der Implementierung verwendet werden. Folgende Tools sind erforderlich:
Eine Liste aller Benutzer und Rollen, die Zugriff auf das Adobe Support-Portal benötigen.
Die Liste enthält in der Regel den Lösungsarchitekten und/oder das IT-Personal des Kunden.
Eine Analyse, die zusammen mit den daraus resultierenden Empfehlungen definiert, was protokolliert werden muss, um die Lösung zu überwachen:
Testen und aktivieren Sie AEM-Wartungsaufgaben wie beispielsweise:
Dokumentieren Sie die Migration, einschließlich
Eine vollständige Beschreibung des vorhandenen Inhalts, der Inhaltsarchitektur und der Formate, die der neuen Lösung zugeordnet sind. Folgendes muss abgedeckt sein:
Empfohlen werden sollte auch, wie die Inhalte in der Zeit zwischen der Migration und der tatsächlichen Live-Schaltung des neuen Systems aktuell (oder so aktuell wie möglich) gehalten werden können. Dies kann ein Einfrieren der Inhalte, eine doppelte Veröffentlichung oder die Wartung eines Alphasystems bedeuten.
Überwachung der Verwendung der System-CPU der Lösung:
Überwachung der Ein- und Ausgabegeschwindigkeiten der Datenträger der Lösung:
Überwachung der Belegung von Festplattenspeicher durch die Lösung:
Überwachen Sie die Belegung durch:
Überwachen Sie sämtliche Verbindungen zwischen der Lösung und externen Systemen:
Überwachen Sie die Nutzung der Netzwerkbandbreite der Lösung:
Überwachen Sie die Anforderungen, die an die Lösung gerichtet werden.
Überwachen Sie die definierten Sicherheitspunkte.
Überwachen Sie das gesamte System. Beispiel:
Überwachung des definierten Schwellenwerts der Lösung und Durchführung von Eingriffsmaßnahmen zur Lastreduzierung.
Die Überwachungskonzepte, die für Ihre Lösung gelten sollen:
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):
Stellen Sie sicher, dass die Systemtechniker und das Betriebspersonal alle Überwachungsrichtlinien kennen und verstehen.
Definiert werden muss Folgendes:
Alle Betriebsaufgaben wurden dokumentiert, ihre Häufigkeit festgelegt.
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:
Softwarepaket wurde erstellt und einsatzbereit ausgeliefert.
Ein Penetrationstest ist ein Angriff auf ein Computersystem zur Suche nach Sicherheitslücken, die den Zugriff auf die Funktionen und Daten des Computers ermöglichen.
Alle erforderlichen Kriterien wurden erfüllt.
Für die Geschäftsverantwortlichen erstellte Berichte, die die Ergebnisse der Penetrationstests erläutern.
Konzeptdokument, 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.
Der Leistungsbenchmarktest dient zur Definition von Leistungstests, Stabilitätstests und Überwachung. Dies erfolgt durch die Bewertung der Leistungsmerkmale der Lösung und System-Hardware.
Definieren die wichtigen Leistungsindikatoren (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.
Für Geschäftsverantwortliche erstellte Berichte, in denen die Ergebnisse der Leistungstests detailliert dargelegt werden.
Die Ergebnisse müssen den definierten KPIs und Leistungserwartungen entsprechen.
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 bei Benutzerakzeptanztests häufig verwendet.
Die Machbarkeit (Proof of Concept, POC) wird an den Anforderungen gemessen, um sicherzustellen, dass eine Übereinstimmung vorliegt.
Eine Checkliste, um die Prüfungen und Aufgaben zu definieren, die nach jeder Bereitstellung durchzuführen sind.
Eine Checkliste, um die Prüfungen und Aufgaben zu definieren, die vor jeder Bereitstellung durchzuführen sind.
Bei einer Standardinstallation von AEM ist es üblich, einen Basisleistungstest durchzuführen. Dieser wird dann als Maßstab verwendet, gemäß dem Implementierung und Hardware getestet werden.
Vergewissern Sie sich, dass die Produktionsumgebung bereit ist und automatisierte Bereitstellungen erfolgt sind.
Vor der Live-Schaltung in 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.
Richtlinie und Prozess, die erforderlich sind, um die Abnahme für die Produktion zu erhalten, bevor das Paket in die Produktionsumgebung überführt wird.
Definieren Sie den Kommunikationsplan für die Projektbeteiligten aus den Geschäftsbereichen und das Projektteam.
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. Schätzungen sollten von jedem zuständigen Projektleiter abgegeben werden, einschließlich Projektmanagement, Beratung, Architektur, Test und Entwicklung.
Diese Schätzungen werden für Beschaffung und Kostenplanung verwendet.
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.
Die benötigte Dokumentation zur Darstellung der Organisation und Berichtsstruktur des Projekts und des Teams.
Oftmals in Form eines Diagramms, um einen anschaulichen Überblick über Zeitpläne und Zuständigkeiten zu geben. Hierfür stehen viele Tools zur Verfügung.
Im Dokument zum Projektumfang müssen Sie eine Liste der folgenden Elemente angeben und dokumentieren:
Beschreibt die Ziele sowie die zu erbringenden Leistungen, die für die Verwirklichung des Projekts nötig sind.
Projektstatusberichte werden gemäß dem vereinbarten Zeitplan und im gewünschten Format geliefert.
Für den Machbarkeitsnachweis 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.
AEM verwaltet mehrere Versionen von Objekten und Inhalten. Bereinigungsregeln sind so konzipiert und konfiguriert, dass die älteren Versionen regelmäßig entfernt werden, um Integrität und Größe des Repositorys im Griff zu behalten.
Definieren Sie den gewünschten Inhalt und das Format des Qualitätsberichts sowie die Häufigkeit seiner Bereitstellung.
Der Projektleiter koordiniert alle für die Freigabe in der Produktion notwendigen Rollen.
Versionshinweise sind Teil der Dokumentation der Version. 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.
Ein Beispiel finden Sie in den AEM-Versionshinweisen.
Die endgültige Version, die in der Produktion ausgeführt wird.
Sie sollten bestimmte Vertragsbedingungen hervorheben, die für die Umsetzung des Projekts relevant sind, wie z. B. vertragliche Milestones, Abrechnungszeiträume oder Personalbedarf.
Legen Sie gemeinsam mit dem Kunden die Häufigkeit der an ihn gelieferten Berichte fest.
Daten in einer TAR-Datei werden nicht überschrieben, sodass die Festplattenbelegung 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.
Die offizielle Anforderung, Ihr Projekt im Adobe Support-Portal einzurichten.
Diese Dokumentation deckt die funktionalen und nicht funktionalen Anforderungen sowie den geschätzten Aufwand ab.
Stellen Sie sicher, dass alle für die Live-Schaltung erforderlichen Rollen besetzt und präsent sind.
Die Risikobewertung wird durch die IT- und/oder Sicherheitsabteilung des Kunden 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.
Der Risikominimierungsplan umfasst die Risikobewertung. Gemeinsam decken sie Folgendes ab:
Definieren Sie Erwartungen an die Rentabilität 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.
Detaillierte Spezifizierung der für die neue Anwendung erforderlichen Rollen- und Zugriffsrechte, einschließlich einer allgemeinen Beschreibung der folgenden Elemente:
Überprüfung des Rollen- und Rechtekonzepts, um sicherzustellen, dass es den Sicherheitsrichtlinien entspricht.
Eine detaillierte Spezifikation basierend auf dem Rollen- und Rechtekonzept.
Empfehlungen für die Sicherheit der Software- und Hardwarearchitektur.
Diese Richtlinien legen fest, wie die Entwicklungskodierung basierend auf den folgenden Sicherheitsanforderungen erfolgen soll:
Projektspezifische Checkliste der Elemente, die auf dem Sicherheitskonzept sowie zusätzlichen Richtlinien zur Sicherstellung der Konformität der Lösung basiert.
Oft wird diese Liste auch als Teil der Schritte nach der Bereitstellung in das Runbook aufgenommen.
Definieren und dokumentieren Sie Details der Sicherheitskonfiguration, die für die Anwendung, Architektur und Infrastruktur erforderlich ist.
Ein allgemeiner Überblick über die Sicherheitsstruktur der folgenden Elemente:
Alle erfassten und eingestuften Sicherheitsprobleme der Lösung einschließlich Aufwandschätzungen.
Abnahme durch diese Projektbeteiligten, um sicherzustellen, dass die Sicherheitsmaßnahmen mit den Richtlinien und Erwartungen übereinstimmen.
Richten Sie die erforderlichen Unterstützungsprozesse ein.
Stellen Sie sicher, dass Servicevereinbarungen (SLAs) verfügbar sind und sowohl dem Entwicklungs- als auch dem Betriebsteam für die Implementierung und den Support zur Verfügung stehen.
Feuerproben bestehen aus einer Reihe von vordefinierten Schritten, die die Schlüsselfunktionalitäten der Lösung testen, um grundlegende Vorgänge und die Funktionalität der Lösung sicherzustellen.
Sie erfolgen in jeder Umgebung nach der Installation oder Bereitstellung.
Feuerproben sollten auf allen Systemen erfolgen, um die ordnungsgemäße grundlegende Funktionalität der Lösung für die Installation bzw. Bereitstellung in allen Umgebungen zu gewährleisten.
Die allgemeine Strategie für die Softwarearchitektur, einschließlich Implementierungsentscheidungen zu u. a. Diensten, Servlets und Frameworks.
Die Lösungsüberprüfungskommission besteht meist 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 Kriterien sicherzustellen und auch bei der Entwicklung der Anforderungen mitzuwirken.
Installationsanweisungen für die Lösung sowie grundlegende betriebliche Aufgaben, die bei der Installation auszuführen sind.
Der Abnahmeprozess beschreibt die Kriterien, die erfüllt sein müssen, bevor die Lösung in einer Produktionsumgebung freigegeben werden kann.
Kann auch als Vertragsmilestone dienen.
Das anfängliche Konzept für jegliche Spezialfunktionalität, die als nicht zum normalen Entwicklungsumfang auf der AEM-Plattform gehörig gilt.
Details zu Spezialfunktionalität, die als nicht zum normalen Entwicklungsumfang auf der AEM-Plattform gehörig gilt.
Etwaige Vorgaben des Kunden, wie die Spezifikation erfolgen soll.
Ein klarer Prozess für die Abnahme der Spezifikationen durch den Kunden ist erforderlich. Dieser Prozess sorgt für Klarheit und Beständigkeit der Anforderungen.
Interne Mitarbeiter, die für die Verwaltung der Lösung geschult werden müssen.
Interne Mitarbeiter, die für die Erstellung von Inhalten in der Lösung geschult werden müssen.
Projektbeteiligte sind die Schlüsselpersonen und/oder Rollen, die ein erhebliches Interesse am Projekt haben. Einige von ihnen wirken am Projektbudget mit.
Die Projektbeteiligten können intern und/oder extern sein.
Bestätigung, dass alle Projektbeteiligten außerhalb des eigentlichen Implementierungsteams über Folgendes Bescheid wissen:
Bestätigung, dass alle Projektbeteiligten außerhalb des eigentlichen Implementierungsteams mit dem Gesamtprojekt und den Erwartungen in Einklang stehen, sowohl intern für das Projektteam als auch für den Kunden.
Statusberichte sind ein wichtiges Kommunikationsinstrument. Das Format muss auf die Berichtsanforderungen des Kunden abgestimmt sein.
Der Kunde, Projektsponsor und Projektleiter oder Berater müssen folgende Fragen beantworten:
Die Antworten werden verwendet, um sicherzustellen, dass die Erfolgskriterien erfüllt werden:
Zu den Aufgaben des Qualitätsleiters gehört es sicherzustellen, dass Ressourcen zur Verfügung stehen, um beim Testen jeden Anwender zu unterstützen. Zum Beispiel, um dem Anwender beim Testen, bei der Meldung von Problemen und bei der Überprüfung der Probleme in der Testumgebung zu helfen.
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 muss den wichtigsten Mitgliedern des Teams gewährt werden.
Ein erster Vorschlag einer Definition der Architektur für alle Umgebungen der Lösung.
Ein Dokument, das die Systemarchitektur detailliert beschreibt, einschließlich Schnittstellen, Netzwerkstandort und Integrationen für alle Umgebungen und andere Informationen.
Ein allgemeiner Überblick, wie sich die Systemarchitektur mit allen Sicherheitsrichtlinien in Einklang bringen lässt. Dies kann Folgendes umfassen:
Alle bei der Risikobewertung (oder anderen Überprüfungen) gefundenen Risikofaktoren werden identifiziert und bewertet:
Bestätigung, dass das gesamte Team mit den Erfolgsdefinitionen und -kriterien vertraut ist.
Bestätigung, dass alle Mitglieder des Teams wissen, wer mit dem Kunden kommunizieren soll, mit Details zu Art und Zeitpunkt.
Einklang mit dem Gesamtprojekt und den Erwartungen, sowohl intern für das Projektteam als auch für den Kunden.
Diese Anforderungen sind spezifisch für die technische Implementierung von Diensten, die die Lösung unterstützen.
Identifizieren und überprüfen Sie potenzielle technische Risiken. Technische Risiken können Folgendes umfassen:
Die technische Spezifikation deckt (u. a.) Folgendes ab:
Die Spezifikationen der erforderlichen Vorlagen. Diese sollten u. a. Details wie z. B. zu parsys, Blueprint und Vererbungszuordnung bieten.
Die Spezifikationen basieren auf den Geschäftsanforderungen und den Anforderungen an das Anwendererlebnis.
Testfälle spezifizieren die detaillierten Schritte, die zur Durchführung von Funktionstests der Lösung erforderlich sind.
Testinhalte sollten Produktionsinhalten so ähnlich wie möglich sein. Die Auswahl muss groß genug sein, um alle Szenarien testen zu können.
Stellen Sie sicher, dass die Testumgebung bereit ist und automatisierte Bereitstellungen vorhanden sind, um sicherzustellen, dass der gesamte Release-Candidate-Code für Tests aktuell ist.
Berichte mit den Testergebnissen einschließlich:
Beachten Sie Folgendes:
Auswahl der Automatisierungssuite und -tools. Diese werden verwendet, um Tests zu automatisieren, auch für Anwendungsfälle.
Automatisierungssuite und -tools für die Automatisierung von Anwendungsfällen und anderen Testausführungsaufgaben.
Das Testkonzept stellt einen sehr allgemeinen Überblick über die Tests für das Projekt dar, einschließlich Tests der Qualitätssicherung, Benutzerakzeptanz, Leistung, Sicherheit und Integration.
Diese Pläne beschreiben im Detail die Durchführung von Tests für jede Entwicklungsphase und basieren auf der Teststrategie.
Diese Anforderungen sind spezifisch für die technische Implementierung von Diensten, die die Lösung unterstützen.
Die Teststrategie skizziert die allgemeine Strategie für Qualitätssicherung und Benutzerakzeptanztests. Dazu gehören Zeitpläne, Berichtsrhythmus und Ausführung.
Konzept auf Architektur- und Systemebene für die Integration mit Systemen von Drittanbietern.
Details zu den (sowohl funktionalen als auch nicht funktionalen) Anforderungen an die unterstützte Funktionalität und Integration der Systeme von Drittanbietern.
Konzept zur Gewährleistung der Sicherheit von Integrationen von Drittanbietern. Muss mit den entsprechenden Sicherheitsrichtlinien konform sein.
Stellen Sie sicher, dass alle Systeme von Drittanbietern mit entsprechender Dokumentation für die Implementierung der Integration zur Verfügung stehen.
Die erforderlichen Zugriffsrechte müssen den jeweiligen Rollen gewährt werden, die in Verbindung mit Systemen von Drittanbietern verwendet werden.
Definiert Folgendes:
Definiert die Schlüsselwerte für Überwachungspunkte im System.
Beispiel:
Hierin sollten die zu verwendenden Projektzeitpläne und vertraglichen Milestones für Folgendes festgelegt werden:
Alle Aufwandsschätzungen der einzelnen Projektbeteiligten mit Leitungsfunktion müssen zusammengeführt werden, einschließlich Gemeinkosten, Entwicklung, Systemtechnik, Architektur und Testaufwand.
Wenn der Vertrag eine Support-Stufe enthält, müssen auch der Support- und Betriebsaufwand einbezogen werden.
In Schulungssitzungen zu verwendende Materialien. Die Materialien müssen speziell für die Lösung erstellt und zusammen mit den Benutzerhandbüchern verwendet werden.
Die entsprechenden Mitarbeiter müssen bestätigen, dass sie Folgendes vollständig verstehen:
Ihr URL-Behandlungskonzept muss die folgenden AEM-spezifischen URL-Funktionen abdecken:
Das Konzept muss auch Folgendes abdecken:
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 ein Benutzer oder ein externes System sein.
Testszenarien basieren auf den technischen und geschäftlichen Anwendungsfällen. Mit ihnen wird geprüft, ob das Lösungsverhalten den Erwartungen entspricht.
Benutzerhandbücher bieten den Benutzern der Lösung Informationen und Unterstützung:
Der Budgetplan muss von allen Projektbeteiligten überprüft und bestätigt werden. Dabei müssen Details wie Fakturierung, Beträge und Methoden/Termine der Budgetberichterstattung überprüft werden.
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 Unit-, Integrations- und Systemebene des Softwaretestprozesses erfolgen.
Basierend auf dem Workflowkonzept müssen diese Spezifikationen im Detail die Schritte definieren, mit denen der gesamte Workflow erstellt wird.
Die Spezifikation jedes Workflows sollte (mindestens) Folgendes enthalten:
Workflows ermöglichen es Ihnen, AEM-Aktivitäten zu automatisieren. Das Workflowkonzept beschreibt Folgendes: