Auf dieser Seite finden Sie weitere Details, um die Dokumente und Prinzipien von Verwalten von Projekten - Checkliste mit Best Practices auszuarbeiten bzw. zu ergänzen.
Die Listen in diesem Unterabschnitt sind nicht erschöpfend, sondern als Einführung gedacht.
Bei der Implementierung von AEM (insbesondere zum ersten Mal) müssen Sie die Funktionen und Workflows von AEM überprüfen, um sicher zu sein, welche Bereiche Sie benötigen.
Beachten Sie die Funktionen von AEM, die Sie verwenden werden, und die Auswirkungen auf Ihr Design, zum Beispiel:
Überprüfen Sie außerdem die Versionshinweise für die verschiedenen Versionen von AEM, um zu sehen, wann neue Funktionen hinzugefügt wurden.
AEM kann mit anderen Adobe-Produkten und/oder Dienstleistungen von Drittanbietern integriert werden. Diese können die Ihnen zur Verfügung stehende Leistung und Funktionalität steigern.
Siehe Lösungsintegration für ausführliche Informationen.
Es ist wichtig, dass Sie sich klar machen welche der beiden Alternativen Sie nutzen möchten:
Beim Wechsel von einer Vorgängerversion zur aktuellen Version gibt es zwei Möglichkeiten
Wie bei jedem Projekt ist es wichtig, so schnell wie möglich Grundregeln festzulegen. Dazu gehören:
Diese Punkte sind allgemein gehalten, die Checkliste mit Best Practices behandelt Besonderheiten in Bezug auf AEM.
Rollen
Diese sollten klar definiert und allen Projektbeteiligten bekannt gemacht werden. Darüber hinaus ist es ratsam, Folgendes hervorzuheben:
Verantwortlichkeiten
Mitwirkung
Indem Sie Interessenten so schnell wie möglich einbinden, können Sie sie ermutigen, Projektbeteiligte zu werden und so ihr Engagement für dessen Erfolg erhöhen.
Kommunikationwege
Prozesse
Die zu definierenden Prozesse hängen von Ihrem individuellen Projekt ab. Versuchen Sie auch hier, die Umstände einfach zu halten hinsichtlich:
Tracking-Werkzeuge
Es gibt viele Tools, um Informationen über Fehler, Aufgaben und andere Aspekte Ihres Projekts zu verfolgen - siehe Übersicht der möglichen Tools für weitere Details.
Umfang
Definieren Sie klar, was das Projekt auf verschiedenen Ebenen abdecken soll:
Reporting
Definieren Sie klar, welche Informationen Sie in welcher Form, wie oft und an wen melden werden.
Terminologie
Annahmen
Diese Informationen können in einem Projekthandbuch definiert werden; die Verwendung eines Wikis kann auch dazu beitragen, dass laufende Änderungen effizient behandelt werden. Wo immer diese definiert sind, sind die Schlüsselfaktoren:
Unternehmen verwenden Key Performance Indicators (KPIs), um ihren Erfolg bei der Erreichung von Zielen zu bewerten. Diese Indikatoren sind messbare Werte, die zeigen, wie effektiv bestimmte Ziele erreicht werden.
Diese Indikatoren können sein:
Business:
Leistung:
Einige, aber nicht alle Indikatoren können auf den Zielmetriken basieren, die Sie identifizieren und definieren.
Metriken werden verwendet, um quantitative Messungen für die Qualität Ihrer Website zu definieren - sie sind im Wesentlichen eine Definition der Leistungsziele, die Sie erreichen wollen, und können zur Definition der Key Performance Indicators (KPIs) verwendet werden.
Sie können eine Vielzahl von Metriken definieren, die meisten decken jedoch die Ziele für Leistung und Gleichzeitigkeit ab. Insbesondere Faktoren, die schwer zu quantifizieren sind und gefühlte Wahrnehmung beinhalten:
„Unsere Website ist heute viel zu langsam“ - wie qualifiziert sich langsam?
„Alles kommt zum Stillstand, wenn sich mein Kollege einloggt“ - wie viele gleichzeitige Benutzer unterstützt das System?
„Wenn ich eine Suchanfrage starte, kommt das System zum Stillstand“ - welche Art von Suchanfragen wirken sich auf das System aus?
„Es dauert ewig, die Datei herunterzuladen“ - was sind akzeptable Downloadzeiten (unter normalen Netzwerkbedingungen)?
Zielmetriken werden zu Beginn eines Projektes definiert:
Wie immer ist bei der Definition der Zielmetriken Vorsicht geboten:
Während der Entwicklung des Projekts können sie aktualisiert und entsprechend angepasst werden. Nachdem das Projekt erfolgreich umgesetzt wurde, können sie Ihnen helfen, Ihre Installation zu steuern und die erforderlichen Servicelevel für den laufenden Betrieb zu überwachen und aufrechtzuerhalten.
Bei richtiger Anwendung können diese Metriken ein nützliches Werkzeug sein; bei unverantwortlicher Anwendung können sie eine zeitraubende Ablenkung darstellen. Wie immer müssen Sie verstehen, was Sie messen, wie Sie es messen und warum.
In diesem Abschnitt werden die Grundprinzipien und Fragen behandelt, die zu berücksichtigen sind. Jede Installation ist anders beschaffen, sodass sich die tatsächlich zu messenden Werte unterscheiden
Alle zu messenden Metriken werden auf irgendeine Weise durch den Entwurf des Projekts beeinflusst. Umgekehrt lassen sich viele Probleme am besten durch Entwurfsänderungen lösen.
Deshalb sollten Sie Ihre Zielmetriken definieren, bevorSie sich für Ihr Design entscheiden.
So können Sie Ihr Design auf Basis dieser Faktoren optimieren. So können Sie Ihr Design auf Basis dieser Faktoren optimieren. Sobald Ihr Projekt entwickelt ist, wird es schwierig, Änderungen an den grundlegenden Entwurfsprinzipien vorzunehmen.
Wenn Sie die Struktur für die Website erstellen, folgen Sie der empfohlenen Struktur für AEM Sites. Stellen Sie sicher, dass Sie die folgenden Punkte und/oder Prinzipien verstehen:
Wenn Sie der Meinung sind, dass Ihr Design nicht den Richtlinien entspricht, oder wenn Sie sich über einige der Auswirkungen unsicher sind, klären Sie diese Fragen, bevor Sie entweder mit der Programmierphase beginnen oder den Inhalt ausfüllen.
Um die Infrastruktur zu definieren oder zu bewerten, hilft es, Zielwerte zu definieren, wie z. B.:
Abhängig von Ihrer Situation und der strategischen Bedeutung der Website hilft Ihnen dies bei der Bewertung und Auswahl Ihrer Infrastruktur:
Es gibt mehrere Leistungsfaktoren, die ausgewertet werden können:
Antwortzeiten für einzelne Seiten unter Berücksichtigung von:
Antwortzeiten für Suchanfragen
Dieser Abschnitt kann in Verbindung mit dem Abschnitt Leistungsoptimierung gelesen werden, in dem die technischen Details der eigentlichen Leistungsmessung näher erläutert werden.
Ein wichtiger Faktor ist die Zeit, die Ihre Website benötigt, um auf Anforderungen durch Besucher zu reagieren.
Obwohl dieser Wert für jede Anforderung anders ist, kann ein durchschnittlicher Zielwert definiert werden. Sobald sich gezeigt hat, dass dieser Wert längerfristig erreichbar ist, kann er verwendet werden, um die Leistung der Website zu überwachen und auf potenzielle Probleme hinzuweisen
Unterschiedliche Ziele für Autoren- und Veröffentlichungsumgebung
Die Antwortzeiten, die Sie anstreben, sind je nach Autoren- und Veröffentlichungsumgebung unterschiedlich und spiegeln die Zielgruppe wider:
Autorenumgebung
Diese Umgebung wird von Autoren benutzt, die Inhalte eingeben und aktualisieren, also muss sie:
Veröffentlichungsumgebung
Diese Umgebung enthält Inhalte, die Sie Ihren Benutzern zugänglich machen:
Geschwindigkeit ist auch hier wichtig, darf aber gewöhnlich langsamer sein als in der Autorenumgebung.
häufig werden zusätzliche leistungssteigernde Mechanismen eingesetzt:
Wie können Sie die erreichbaren (durchschnittlichen) Antwortzeiten bestimmen? Dies ist häufig eine Frage der Erfahrung:
Allerdings können (unter kontrollierten Umständen) die folgenden Richtlinien angewendet werden:
Bei den obigen Zahlen gelten die folgenden Bedingungen:
Es gibt verschiedene Möglichkeiten, die Sie verwenden können, um die Antwortzeiten zu überwachen:
Überwachung der Antwortzeiten mit dem AEM request.log
Ein guter Ausgangspunkt für Leistungsanalysen ist das Anforderungsprotokoll. Hier können Sie u.a. die Antwortzeiten einzelner Anfragen einsehen. Siehe Leistungsoptimierung für weitere Informationen.
Überwachen von Antwortzeiten mit HTML-Kommentaren
*HTML comments* can be used to include response time information within the source of each page:
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
Suchanfragen können im Hinblick auf folgende Bereiche einen erheblichen Einfluss auf Ihre Website haben:
Antwortzeit der eigentlichen Suche
Auswirkungen auf die allgemeine Leistung
Das Setzen von Zielen für Suchanfragen ist wiederum eine Frage der Erfahrung:
Diese sollten von Anfang des Projekts an geplant und integriert werden. Für die Überwachung stehen u.a. folgende Mechanismen zur Verfügung:
Überwachung der Suchantwortzeiten mit request.log von AEM
Auch hier kann request.log verwendet werden, um die Antwortzeiten für Suchanfragen zu überwachen; siehe Leistungsoptimierung für weitere Details.
Programmierte Mechanismen zur Messung der Suchantwortzeiten
Um die von Ihnen gesammelten Informationen über Suchanfragen und deren Leistung anzupassen, wird empfohlen, die Informationssammlung in Ihren Projekt-Quellcode aufzunehmen; siehe Performanceoptimierung für weitere Details.
Ihre Website wird einer Reihe von Benutzern/Besuchern zur Verfügung gestellt, sowohl in der Autoren- als auch in der Veröffentlichungsumgebung. Die Zahlen sind oft höher als beim Testen, aber auch schwankend und schwer vorhersehbar. Die Website muss für eine durchschnittliche Anzahl von gleichzeitigen Benutzern/Besuchern konzipiert sein, ohne dass dabei eine negative Auswirkung auf die Performance auftritt. Auch hier kann request.log
verwendet werden, um Parallelitätstests durchzuführen; siehe Performanceoptimierung für weitere Details.
Ziele für die Anzahl der gleichzeitigen Benutzer sind abhängig von der Art der Umgebung:
Autorenumgebung
Veröffentlichungsumgebung
Bevor wir die entsprechenden Metriken besprechen, eine schnelle Definition der Begriffe:
Volumen
Kapazität
Kapazität und Volumen
Was/Wo | Kapazität | Volumen |
---|---|---|
Client | Rechenleistung des Computers des Benutzers. | Komplexität des Seiten-Layouts. |
Netzwerk | Netzwerkbandbreite. | Größe der Seite (Code, Bilder usw.). |
Dispatcher-Cache | Server-Speicher des Webservers (Hauptspeicher und Festplatte). | Webserver (Hauptspeicher und Festplatte). Anzahl und Größe der zwischengespeicherten Seiten. |
Ausgabe-Cache | Server-Speicher des AEM-Servers (Hauptspeicher und Festplatte). | Anzahl und Größe der Seiten im Ausgabe-Cache, die Anzahl der Abhängigkeiten pro Seite. Der Dispatcher-Cache verringert dieses Volumen. |
Webserver | Rechenleistung des Webservers. | Anzahl der Anfragen. Der Cache verringert dieses Volumen. |
Vorlage | Rechenleistung des Webservers. | Komplexität der Vorlagen. |
Repository | Leistung des Repositorys. | Anzahl der aus dem Repository geladenen Seiten. |
In den vorhergehenden Abschnitten werden die wichtigsten zu definierenden Metriken beschrieben.
Je nach Ihren spezifischen Anforderungen kann es sinnvoll sein, zusätzliche Metriken zu definieren, entweder isoliert oder unter Berücksichtigung der oben genannten Klassifizierungen.
Es ist jedoch besser, einen kleinen Satz von genauen, zentralen Metriken zu haben, die einfach und zuverlässig funktionieren, als zu versuchen, jeden Aspekt Ihrer Website zu messen und zu definieren. Durch ihre schiere Natur beginnt sich Ihre Website zu verändern und zu entwickeln, sobald sie Ihren Benutzern übergeben wird.
Sicherheit ist entscheidend und eine immer größere Herausforderung. Sie muss von Anfang an berücksichtigt und geplant werden.
Die Sicherheits-Checkliste beschreibt die Schritte, die Sie unternehmen sollten, um sicherzustellen, dass Ihre AEM-Installation bei der Bereitstellung sicher ist. Weitere Sicherheitsaspekte werden unter Sicherheit (bei der Entwicklung) und Benutzerverwaltung und Sicherheit behandelt.
Das Folgende:
Für eine Neuimplementierung eines Standard-AEM-Projekts müssen Sie u.a. folgende Aufgaben berücksichtigen:
Für alle Aspekte wird ein periodischer Ansatz empfohlen:
Teilen Sie den Projektstart in Soft Launch (reduzierte Verfügbarkeit, mehrere Iterationen) und Hard Launch (volle Verfügbarkeit - Live) auf, um eine Abstimmung, Optimierung und Anwenderschulung unter realistischen Bedingungen in der Produktionsumgebung zu ermöglichen.
In der Projekt-Checkliste finden Sie Beispiele für Aufgaben, die Sie während des Lebenszyklus Ihres Projekts durchführen (oder bewerten) sollten.
Einige Punkte, die für jede Kategorie zu beachten sind:
Entwicklung
Definieren Sie zunächst die Basisarchitektur.
Verwenden Sie mehrere Durchgänge (Sprints) für die Entwicklung:
Planen Sie den Fall eines Updates der verfügbaren AEM-Version während des Projekts mit ein.
Planen Sie Tests und Optimierungen während des Sprints mit ein.
Planen Sie Stabilisierungs- und Optimierungsphasen.
Erstellen Sie ein Protokoll der zu planenden Positionen für weitere Releases
Planung der Partnerbeteiligung und -übergabe.
Infrastruktur
Definieren Sie zunächst die Basisarchitektur:
Verwenden Sie mehrere Durchgänge; bereiten Sie für den ersten Sprint und die erste Konfiguration Folgendes vor:
Planen Sie mehrere Belastungstests.
Planen Sie Tests und Optimierungen während des Sprints mit ein.
Planen Sie eine Stabilisierungs- und Optimierungsphase.
Stellen Sie das System so früh wie möglich in der Produktionsumgebung bereit (lassen Sie das Betriebsteam das System einrichten, um Erfahrungen zu sammeln).
Verwenden Sie benannte Benutzer und definierte Rollen so früh wie möglich.
Planen Sie das Training (z. B. Administrator-Training).
Planen Sie die Übergabe an den Betrieb.
Inhalt
Abhängig von Ihrer resultierenden Aufgabenliste können Sie dann erste Schätzungen des Aufwands für (hochrangige) Aufgabendefinitionen vornehmen. Diese sollten einen Hinweis enthalten, wer (Kunde oder Partner) was und wann tun wird.
Die folgende Liste zeigt Standardannäherungen und Zusammenhänge des Aufwands und damit der Kosten:
Diese Zahlen können nur für erste Schätzungen verwendet werden. Ein erfahrener AEM-Entwickler muss die detaillierte Analyse durchführen.
Phase | Aufwand |
---|---|
Entwicklung | Eine grobe Schätzung von 2 – 4 Stunden für jeden Komponentenknoten deckt alle Entwicklungsanforderungen ab. |
Entwicklertests | 15 % der Entwicklung |
Folgemaßnahmen | 10 % der Entwicklung |
Dokumentation | 15 % der Entwicklung |
JavaDoc-Dokumentation | 10 % der Entwicklung |
Fehlerbehebung | 15 % der Entwicklung |
Projekt-Management | 20 % der Projektkosten für laufende Projektverwaltung und Nutzerrechte |
Die Detailplanung kann dann verfügbare oder benötigte Ressourcen mit Terminen und Kosten verknüpfen.
Die Referenzarchitektur dient als Vorlage für die AEM-Architektur. Die Referenzarchitektur adressiert Probleme, die bei Unternehmenssystemen häufig auftreten, einschließlich Skalierung, Zuverlässigkeit und Sicherheit.
Die folgenden Site-Metriken sollten definiert werden:
Klassifizierung | Definition |
---|---|
Anzahl der Websites | |
Anzahl der Intranet-Sites | |
Anzahl der Code-Basen (z. B. wenn Internet und Intranet unterschiedlich sind) | |
Anzahl der einzelnen Seiten | |
Anzahl der Site-Besuche/Tag | |
Anzahl der Seitenaufrufe/Tag | |
Umfang der Datenübertragung (in GB)/Tag | |
Anzahl gleichzeitiger Benutzer (geschlossene Benutzergruppe) | |
Anzahl gleichzeitiger Besucher (Veröffentlichung) | |
Anzahl gleichzeitiger Autoren | |
Anzahl registrierter Autoren | |
Anzahl der Seitenaktivierungen/Arbeitstag | |
Anzahl der Seitenaktivierungen während der Bereitstellung |
Die folgende Liste informiert Sie über die verwendbaren Werkzeuge. Sie ist als Einführung gedacht, nicht als umfangreiche Empfehlungsliste, und sollte Sie sicherlich nicht davon abhalten, andere Tools zu verwenden, die Sie bevorzugen.
Produkt | Beschreibung |
AEM | AEM bietet eine Reihe von Mechanismen, mit denen Sie Ihre Anwendung überwachen, testen, untersuchen und debuggen können, darunter folgende: |
Selenium | Selenium ist ein Open Source-Test-Tool. Die Tests laufen direkt im Browser ab und emulieren, wie Ihre Benutzer arbeiten. |
Microsoft Project | Ein häufig verwendetes Projekt-Management-Tool. |
Jira | Jira ist ein Open Source-Tool zum Verfolgen und Verwalten von Details Ihrer Softwarefehler. Workflows können bei Bedarf auf die Fehlerdetails angewendet werden. |
Git | Git ist eine Software für die Revisionskontrolle. |
Eclipse | Eclipse ist eine Open Source-IDE, die aus verschiedenen Projekten besteht. Diese konzentrieren sich auf den Aufbau einer offenen Entwicklungsplattform, die aus erweiterbaren Frameworks, Tools und Laufzeiten für die Erstellung, Bereitstellung und Verwaltung von Software über den gesamten Lebenszyklus besteht. Weitere Informationen finden Sie unter Entwickeln von AEM-Projekten mit Eclipse. |
IntelliJ | Eine professionelle (und damit lizenzkostenpflichtige) IDE mit einem umfassenden Funktionsumfang. Weitere Informationen finden Sie unter Entwickeln von AEM-Projekten mit IntelliJ IDEA. |
Maven | Maven ist ein Softwaretool für Projekt-Management und Analysen, das den Build-Prozess eines Projekts (Software und Dokumentation) verwalten kann. |
Darüber hinaus sind die folgenden Abschnitte von besonderem Interesse:
Adobe bietet weitere Best Practices für alle Phasen und Zielgruppen: