Checklist - Verdere referentie the-checklist-further-reference
Deze pagina bevat nadere gegevens voor de uitwerking en/of de aanvulling van de documenten en beginselen die onder de Projecten beheren - Checklist voor aanbevolen procedures.
AEM - Wat gaat u gebruiken? aem-what-will-you-be-using
Functies binnen AEM features-within-aem
Bij het implementeren van AEM (met name voor de eerste keer) moet u de mogelijkheden en workflows van AEM om te controleren welke gebieden u wilt/nodig hebt.
Houd rekening met de functies van AEM die u gebruikt en met de invloed op uw ontwerp. bijvoorbeeld:
Controleer bovendien de Opmerkingen bij de release, voor de verschillende versies van AEM, om te zien wanneer nieuwe functies zijn toegevoegd.
Integrations integrations
AEM kunnen worden geïntegreerd met andere producten van de Adobe en/of diensten van derden. Deze kunnen de macht en de functionaliteit verhogen tot uw beschikking.
Zie Oplossingsintegratie voor volledige informatie.
Migreren of upgraden? migrate-or-upgrade
Een belangrijke overweging is of u:
- De bestaande installatie upgraden.
- De inhoud van het huidige systeem migreren naar een nieuwe, nieuwe installatie.
Bij de overgang van een vorige versie naar de huidige versie zijn er twee opties:
- Gebruik de Pakketbeheer om alle inhoud en toepassingscode van het oude systeem naar het nieuwe te exporteren.
- Upgrade het oude systeem. Dit is in de meeste gevallen de aanbevolen keuze.
Basisgrondregels basic-ground-rules
Net als bij elk project is het van cruciaal belang dat er zo snel mogelijk grondregels worden opgesteld. Deze omvatten:
-
Rollen
Deze moeten duidelijk worden omschreven en aan alle bij het project betrokken partijen worden meegedeeld. Daarnaast is het raadzaam de aandacht te vestigen op:
- Beslissingsmakers
- Contactpunten
-
Verantwoordelijkheden
- Voor elke rol helpt een duidelijke definitie van de verantwoordelijkheden met betrekking tot uw project verwarring te voorkomen.
-
Betrokkenheid
Door de betrokken partijen zo snel mogelijk bij de zaak te betrekken, kunt u hen aanmoedigen om belanghebbenden in het kader van het project , waardoor zij zich meer inzetten voor het welslagen ervan .
- Aan de kant van de klant staan onder andere de auteurs - die dagelijks met het systeem moeten werken.
- Binnen uw eigen projectteam omvat dit ook de personen die verantwoordelijk zijn voor kwaliteitsborging. Hoe meer zij de vereisten van de klant begrijpen, hoe beter zij de tests kunnen plannen.
-
Paden van communicatie
- Hoewel deze niet buitensporig moeten worden geformaliseerd, moeten specifieke definities ervoor zorgen dat de belangrijkste personen altijd op de hoogte worden gebracht en dus worden bijgewerkt. Er moet bijzondere aandacht worden besteed aan de communicatie met externe partijen.
-
Processen
De te bepalen processen zullen van uw individueel project afhangen. Probeer deze nog eens eenvoudig te houden, waarbij u rekening moet houden met:
- het definiëren van processen (en communicatiepaden) voor interactie met derden; bijvoorbeeld ontwerpbureaus en andere softwareleveranciers.
- Vaak heeft de klant zijn eigen procedures en tools voor projectbeheer en -rapportage.
-
Trackinggereedschappen
Er zijn vele hulpmiddelen beschikbaar voor het volgen van informatie over insecten, taken, en andere aspecten van uw project - zie Overzicht van mogelijke gereedschappen voor meer informatie .
- Het belangrijkste punt om hier nota van te nemen is slechts één exemplaar van de informatie te houden en de informatie (en daarom toegang tot het hulpmiddel te delen dat wordt gebruikt) te delen. Hierdoor wordt onderhoud eenvoudiger en kunnen verschillen worden voorkomen.
-
Scope
Duidelijk bepalen wat op verschillende niveaus onder het project moet vallen:
- de individuele versies (als een iteratief versieproces wordt gebruikt, en ongeacht of zij aan klanten of uw intern testteam worden geleverd).
- het AEM project.
- het gehele project; met inbegrip van software van derden, de gevolgen ervan voor tests, organisatorische problemen en vele andere.
- Voor bepaalde aspecten kan het ook nuttig zijn te vermelden wat niet binnen het toepassingsgebied van het project. Dit kan helpen verwarring en onjuiste veronderstellingen te voorkomen, maar moet beperkt blijven tot essentiële kwesties.
-
Rapportage
Duidelijk bepalen welke informatie u zult melden, in welke vorm, hoe vaak en aan wie.
-
Terminologie
- Bepaal om het even welke te gebruiken afkortingen en/of klant-specifieke terminologie.
-
Aannames
- Bepaal om het even welke veronderstellingen die worden gemaakt.
Deze informatie kan binnen een Handboek van het Project worden bepaald; het gebruik van een Wiki kan er ook toe bijdragen dat lopende veranderingen efficiënt worden afgehandeld. Waar deze worden gedefinieerd, zijn de belangrijkste factoren:
- Informatie wordt gedefinieerd en onderhouden
- De informatie wordt duidelijk meegedeeld aan alle betrokken personen. Hoewel de standaardpraktijk van het Projectbeheer, het niet vaak genoeg kan worden herhaald dat de duidelijke roldefinitie en de goede mededeling een project kunnen maken of breken.
- Er wordt slechts één versie bijgehouden van informatie die wordt bijgehouden; bijvoorbeeld het bijhouden van fouten, het bijhouden van problemen, enz.
Belangrijkste prestatie-indicatoren en streefcijfers key-performance-indicators-and-target-metrics
Organisaties gebruiken de Belangrijkste Indicatoren van Prestaties (KPIs) om hun succes bij het bereiken van doelstellingen te evalueren. Deze indicatoren zijn meetbare waarden die kunnen worden gebruikt om aan te tonen hoe effectief specifieke doelstellingen worden verwezenlijkt.
Deze indicatoren kunnen zijn:
-
Zakelijk:
- Wordt gebruikt om belangrijke bedrijfsdoelstellingen te meten.
- Het is belangrijk om KPIs te kiezen aangewezen aan uw zaken/scenario met duidelijke definities van wat zij zijn, hoe zij zullen worden gemeten, hoe zij zullen worden gebruikt en door wie.
-
Prestaties:
- Bepaal hoe u de prestaties van het systeem kunt meten.
- Voorbeelden hiervan zijn laadtijd van de pagina, responstijd van de server en queryprestaties van de database.
Sommige, maar niet alle, indicatoren kunnen op de doelmetriek worden gebaseerd die u identificeert en bepaalt.
Doelwaarden target-metrics
Metriek worden gebruikt om kwantitatieve metingen voor de kwaliteit van uw website te definiëren. Het zijn in feite een definitie van de prestatiedoelen die u wilt bereiken en kunnen worden gebruikt om uw KPI's (belangrijkste prestatie-indicatoren).
Veel metriek kunnen worden gedefinieerd, maar vaak worden de meeteenheden die u definieert, gebruikt voor uw doelstellingen op het gebied van prestaties en gelijktijdige uitvoering. Met name factoren die moeilijk te kwantificeren zijn en die vaak vatbaar zijn voor emotioneel beoordeling:
-
" onze website is veel te langzaam vandaag" - wanneer traag kwalificeren?
-
" alles tot stilstand komt wanneer mijn collega zich aanmeldt" - hoeveel gelijktijdige gebruikers kunnen het systeem ondersteunen?
-
"Wanneer ik zoek, het systeem tot stilstand komt " - welk soort zoekverzoeken heeft invloed op het systeem?
-
" het gaat om pagina om het bestand te downloaden" - wat zijn acceptabele downloadtijden (onder normale netwerkomstandigheden)?
De Metriek van het doel worden bepaald bij het begin van een project aan:
- Geef de verwachte afmetingen van de website aan die u wilt aanbieden
- geeft de minimale kwaliteit aan die u wilt bereiken
- bepalen hoe deze factoren daadwerkelijk zullen worden gemeten
- worden gebruikt als basis voor de Belangrijkste prestatie-indicatoren
Zoals altijd zorgvuldig moet worden omgesprongen met de definitie van de doelwaarden:
- als ze te hoog zijn , kunnen ze totaal onbereikbaar zijn
- indien te lage fluctuaties zijn ingesteld, wordt deze mogelijk niet gemarkeerd
- om ervoor te zorgen dat zij herhaaldelijk en consequent kunnen worden gemeten
- om een evenwicht te verschaffen tussen de verschillende factoren die worden gemeten
- bepaalde meetwaarden hebben betrekking op een testomgeving, maar sommige moeten levensechte scenario's weerspiegelen omdat ze meetbaar en reproduceerbaar moeten zijn op uw productiewebsite
- de metriek prioriteren op basis van hun betekenis voor de website
- de meetgegevens beperken tot een set die op realistische wijze kan worden bewaakt
Tijdens de ontwikkeling van het project kunnen zij waar nodig worden bijgewerkt en aangepast. Nadat het project met succes is uitgevoerd, kunnen zij worden gebruikt om u te helpen uw installatie controleren en de vereiste niveaus van de dienst voor aan de gang zijnde verrichting controleren/handhaven.
Als deze gegevens correct worden gebruikt, kunnen ze een nuttig hulpmiddel zijn; als ze onverantwoord worden gebruikt, kunnen ze een tijdverspillende afleiding zijn. Zoals altijd moet u begrijpen wat u meet, hoe u het meet en waarom.
Alles is afhankelijk van uw projectontwerp everything-rests-on-your-project-design
Alle meetgegevens die moeten worden gemeten, worden op een of andere manier beïnvloed door het ontwerp van uw project. Omgekeerd kunnen veel problemen het best worden opgelost door ontwerpwijzigingen.
Daarom zou u uw doelmetriek moeten bepalen voor beslissingen nemen over uw ontwerp. Op deze manier kunt u uw ontwerp optimaliseren op basis van deze factoren. Als uw project eenmaal is ontwikkeld, zal het moeilijk zijn om wijzigingen aan te brengen in de basisontwerpbeginselen.
Wanneer u de structuur voor de website maakt, volgt u de aanbevolen structuur voor AEM websites. Zorg ervoor dat u de volgende problemen en/of principes begrijpt:
- Inhoud van websites structureren.
- Hoe sjablonen en componenten werken.
- Hoe caching werkt.
- De effecten van gepersonaliseerde inhoud.
- Hoe de zoekfunctie werkt.
- Hoe u CSS en verwante technologieën kunt gebruiken om compacte, niet overtollige HTML code tot stand te brengen.
Als u van mening bent dat uw ontwerp de richtlijnen niet volgt, of als u over sommige implicaties onzeker bent, verheldeer deze kwesties alvorens u of de programmeringsfase begint of de inhoud vult.
Infrastructuur infrastructure
Om de infrastructuur te bepalen of te beoordelen zal het helpen doelwaarden zoals bepalen:
- bezoekers/dag; zowel gemiddelde als piekwaarde
- treffers/dag; zowel gemiddelde als piekwaarde
- aantal webpagina's dat beschikbaar wordt gesteld
- volume van webinhoud
Afhankelijk van uw situatie en de strategische betekenis van de website, helpt dit u om uw infrastructuur te beoordelen en te kiezen:
- aantal servers
- aantal AEM (auteur en publicatie)
Prestaties performance
Er zijn verschillende prestatiefactoren die kunnen worden geëvalueerd:
-
responstijden voor afzonderlijke pagina's, rekening houdend met:
- reactietijden voor een auteursomgeving
- responstijden voor de publicatieomgeving
-
antwoordtijden voor zoekverzoeken
Deze sectie kan in combinatie met Optimalisatie van prestaties dat de technische details van het daadwerkelijk meten van de prestaties uitbreidt.
Responstijden voor afzonderlijke pagina's response-times-for-individual-pages
Een belangrijk probleem is de tijd die uw website nodig heeft om te reageren op bezoekersverzoeken.
Hoewel deze waarde voor elke aanvraag zal variëren, kan een gemiddelde doelwaarde worden bepaald. Zodra deze waarde zowel haalbaar als houdbaar is, kan deze worden gebruikt om de prestaties van de website te controleren en de ontwikkeling van potentiële problemen aan te geven
Verschillende doelen voor auteur- en publicatieomgevingen
De responstijden die u wilt bepalen, verschillen per auteur- en publicatieomgeving en weerspiegelen het doelpubliek:
-
Auteursomgeving
Deze omgeving wordt gebruikt door auteurs die inhoud invoeren en bijwerken, zodat deze:
- Zorg voor een klein aantal gebruikers die een groot aantal verzoeken genereren bij het bijwerken van inhoudspagina's en de afzonderlijke elementen op die pagina's
- zo snel mogelijk zijn om hun productiviteit te maximaliseren voor het ophalen van uw inhoud op uw website
-
Publicatie-omgeving
Deze omgeving bevat inhoud die u beschikbaar maakt voor uw gebruikers:
-
snelheid is nog steeds van vitaal belang , maar is vaak trager dan een auteursomgeving
-
er worden vaak aanvullende mechanismen voor prestatieverbetering toegepast :
- de inhoud is in cache geplaatst
- taakverdeling wordt toegepast
-
Doelresponstijden instellen setting-target-response-times
Dus hoe kan je beslissen over haalbare (gemiddelde) responstijden? Dit is vaak een kwestie van ervaring:
- ervaring met uw website
- ervaring met AEM
- complexe pagina's herkennen die boven de gemiddelde responstijden liggen (deze moeten zo mogelijk individueel worden geoptimaliseerd)
Onder gecontroleerde omstandigheden kunnen echter de volgende richtsnoeren worden toegepast:
- 70% van de aanvragen voor pagina's moet in minder dan 100 ms reageren.
- 25% van de aanvragen voor pagina's moet in minder dan 100 ms-300 ms reageren.
- 4% van de aanvragen voor pagina's moet in minder dan 300 ms-500 ms reageren.
- 1% van de aanvragen voor pagina's moet in minder dan 500 ms-1000 ms reageren.
- Geen pagina's mogen langzamer reageren dan 1 seconde.
De bovenstaande getallen voldoen aan de volgende voorwaarden:
- gemeten bij publicatie (geen ontwerpomgeving en/of CFC-overhead)
- gemeten op de server (geen netwerkoverhead)
- niet in cache geplaatst (geen AEM-uitvoercache, geen Dispatcher-cache)
- alleen voor complexe items met veel afhankelijkheden (HTML, JS, PDF, …)
- geen andere belasting op het systeem
U kunt de reactietijden op verschillende manieren controleren:
-
De reactietijden van de controle met AEM request.log
Een goed uitgangspunt voor prestatiesanalyse is het verzoeklogboek. U kunt dit bijvoorbeeld gebruiken om de responstijden van afzonderlijke aanvragen te zien. Zie Optimalisatie van prestaties voor meer informatie .
-
Reactietijden controleren met HTML-opmerkingen
*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
Zoekverzoeken search-requests
Zoekverzoeken kunnen een aanzienlijke invloed hebben op uw website, zowel wat betreft:
-
Responstijd van de eigenlijke zoekopdracht
- Een snelle zoekfunctie is een kwaliteitsdoel voor uw website
-
Gevolgen voor de algemene prestaties
- Aangezien een zoekfunctie (potentieel grote) gedeelten van de inhoud moet scannen, of een speciaal uitgenomen index, kan dit de prestaties van het gehele systeem beïnvloeden als dit niet wordt geoptimaliseerd
Het vaststellen van doelen voor zoekverzoeken is ook hier een kwestie van ervaring, afhankelijk van:
- AEM
- een beoordeling van de frequentie waarmee de zoekopdracht zal worden gebruikt in vergelijking met andere doelstellingen
- uw persistentiemanager
- uw zoekindex
- de complexiteit van uw zoekfunctie; een basiszoekfunctie waarmee slechts één zoekterm kan worden ingevoerd, is sneller dan een geavanceerd zoeken waarmee de gebruiker complexe zoekinstructies kan opbouwen met behulp van AND/OR/NOT.
Deze moeten vanaf het begin van uw project worden gepland en geïntegreerd. De volgende controlemechanismen zijn beschikbaar:
-
De zoekreactietijden van de controle met AEM request.log
Nogmaals kan request.log worden gebruikt om de reactietijden voor onderzoeksverzoeken te controleren; zie Optimalisatie van prestaties voor meer informatie .
-
Geprogrammeerde mechanismen voor het meten van zoekresponstijden
Om de informatie aan te passen u over onderzoeksverzoeken, en hun prestaties verzamelt, adviseert men om informatieinzameling in uw projectbroncode te omvatten; zie Optimalisatie van prestaties voor meer informatie .
Gelijkend concurrency
Uw website wordt beschikbaar gesteld aan een aantal gebruikers/bezoekers, zowel in de auteur- als in de publicatieomgeving. De getallen zijn vaak hoger dan bij het testen, maar ook fluctuerend en moeilijk te voorspellen. Uw website moet worden ontworpen voor een gemiddeld aantal gelijktijdige gebruikers/bezoekers zonder dat dit negatieve gevolgen heeft voor de prestaties. Opnieuw request.log kunnen worden gebruikt om valutatests te verrichten; zie Optimalisatie van prestaties voor meer informatie .
De doelstellingen voor het aantal gelijktijdige gebruikers zijn afhankelijk van het milieutype:
-
Auteursomgeving
- Gewoonlijk kan het aantal gelijktijdige gebruikers nauwkeurig worden geschat. U weet hoeveel auteurs u in totaal hebt, hoewel (waarschijnlijk) niet alle tegelijkertijd actief zullen zijn.
-
Publicatie-omgeving
- Dit is moeilijker te voorspellen, zodat moet u een doelwaarde selecteren. Ook dit moet gebaseerd zijn op de ervaring van uw huidige website en realistische verwachtingen ten aanzien van uw nieuwe website.
- Speciale evenementen (bijvoorbeeld wanneer u nieuwe, zeer populaire inhoud publiceert) kunnen de verwachtingen of zelfs de mogelijkheden overtreffen (zoals soms in de pers wordt gemeld wanneer tickets voor bepaalde evenementen te koop worden aangeboden).
Capaciteit en volume capacity-and-volume
Voordat u de gerelateerde metriek gaat bespreken, geeft u een snelle definitie van de termen:
-
Volume
- De hoeveelheid output die door het systeem wordt verwerkt en geleverd.
-
Capaciteit
- De capaciteit van het systeem om het volume te leveren.
- Bij elke stap worden de capaciteit en het volume anders gemeten, zoals in de onderstaande tabel wordt aangegeven. Voor de beste prestaties, zorg ervoor dat de capaciteit het volume bij elke stap aanpast, en dat zowel capaciteit als volume over alle stappen worden gedeeld. U kunt bijvoorbeeld de navigatie op de clientcomputer berekenen of in het cachegeheugen plaatsen, in plaats van deze voor elke aanvraag op de server te berekenen.
-
Capaciteit en volume
table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 6-row-3 7-row-3 Wat/waar Capaciteit Volume Client Rekeningvermogen van de computer van de gebruiker. Complexiteit van de pagina-indeling. Netwerk Netwerkbandbreedte. Grootte van de pagina (code, afbeeldingen enzovoort). Verzendcache Servergeheugen van de webserver (hoofdgeheugen en vaste schijf). Webserver (hoofdgeheugen en vaste schijf). Aantal en formaat van de pagina's in de cache. Uitvoercache Servergeheugen van de AEM (hoofdgeheugen en vaste schijf). Aantal en grootte van de pagina's in de uitvoercache, het aantal afhankelijkheden per pagina. Dit volume wordt verlaagd door de verzendercache. Webserver De computermacht van de server van het Web. Hoeveelheid verzoeken. Dit volume wordt verlaagd door caching. Sjabloon De computermacht van de server van het Web. Complexiteit van de sjablonen. Bewaarplaats Prestaties van de opslagplaats. Aantal pagina's dat vanuit de gegevensopslagruimte is geladen.
Overige cijfers other-metrics
In de voorgaande secties worden de belangrijkste metriek beschreven die moet worden gedefinieerd.
Afhankelijk van uw specifieke vereisten kan het handig zijn om extra maatstaven te definiëren, afzonderlijk of met inachtneming van de bovenstaande classificaties.
Het is echter aan te raden om een kleine set nauwkeurige, basismeetgegevens te hebben die eenvoudig en betrouwbaar werken, in plaats van te proberen elk aspect van uw website te meten en te definiëren. Door zijn aard, zal uw website beginnen te veranderen en zich te ontwikkelen zodra het aan uw gebruikers wordt overgedragen.
Beveiliging security
Veiligheid is cruciaal en een steeds groter wordende uitdaging. IT moet worden overwogen en gepland vanaf de vroegste stadia van uw project.
De Beveiligingscontrolelijst detailstappen die u zou moeten nemen om ervoor te zorgen dat uw AEM installatie wanneer opgesteld veilig is. Andere veiligheidsaspecten vallen onder Beveiliging (bij ontwikkeling) en Gebruikersbeheer en beveiliging.
Parallelle en interactieve taken parallel-and-iterative-tasks
- Biedt een overzicht met betrekking tot de first uitvoering van een AEM project.
- is bedoeld als abstract overzicht; zie Projectchecklist voor specifieke fasen/mijlpalen/taken.
- Elke tijdschaal is theoretisch.
Voor een nieuwe implementatie van een standaard AEM project zult u taken zoals moeten overwegen:
- Overhandigen van het verkoopproces.
- Implementatie van de klantentoepassing (Ontwikkeling).
- Installatie en configuratie van de infrastructuur (en bijbehorende processen) op de locatie van de klant (Infrastructuur).
- Het maken (of migreren) van de inhoud (Inhoud).
- Overdracht van concrete acties (Onderhoud/ondersteuning).
- Follow-upreleases.
Voor alle aspecten wordt aanbevolen een iteratieve benadering te gebruiken:
Voor elke categorie zijn enkele punten die moeten worden vermeld:
-
Ontwikkeling
-
Definieer eerst de basisarchitectuur.
-
Verschillende herhalingen (sprints) gebruiken voor ontwikkeling:
- Eerste sprint komt overeen met de eerste volledige ontwikkelingscyclus.
- Eerste sprint resulteert in de eerste implementatie in uw testomgeving.
- Elke sprint heeft een runable resultaat.
- Elke sprint krijgt een klantentekens (minimum van gestructureerde test met terugkoppelen).
-
Plan voor de eventualiteit van een update van de beschikbare AEM versie tijdens het project.
-
Plan voor tests en optimalisatie tijdens sprints.
-
Plan voor stabilisatie- en optimalisatiefasen.
-
Maak een logboek met items die u wilt plannen voor verdere releases.
-
Plan voor partnerbetrokkenheid en overdracht.
-
-
Infrastructuur
-
Definieer eerst de basisarchitectuur:
- Geef prestatievereisten op.
- Bepaal prestatiedoelstellingen (dat wil zeggen duidelijk verwachtingen bepalen).
- Vaststellen van hardware- en infrastructuurarchitectuur; inclusief grootte.
- Implementatie definiëren.
-
Gebruik verschillende herhalingen; voor de eerste sprint en de eerste configuratie:
- Ontwikkelomgeving.
- Ontwikkelingsproces.
- Testomgeving.
- Implementatieproces (inclusief configuratiebeheer).
-
Plan voor verschillende belastingstests.
-
Plan voor tests en optimalisatie tijdens sprints.
-
Plan voor een stabilisatie- en optimalisatiefase.
-
Implementeer zo vroeg mogelijk naar de productieomgeving (laat het bewerkingsteam het systeem instellen om ervaring op te doen).
-
Gebruik benoemde gebruikers en gedefinieerde rollen zo vroeg mogelijk.
-
Plan voor opleiding (bijvoorbeeld, beheerder opleiding).
-
Overdracht naar bewerkingen is gepland.
-
-
Inhoud
-
De basisarchitectuur:
- Hiermee wordt de inhoudshiërarchie geactiveerd.
- Hiermee kunt u het inhoudsconcept definiëren.
- Bepaalt het gebruik MSM en lay-out.
- Definieert rollen, groepen, workflows en machtigingen.
-
Overweeg of het maken van offlinepagina nuttig is.
-
Plan voor de vroege verwezenlijking van eerste pagina's en inhoud (voor gebruik in tests en terugkoppelen).
-
Plan voor de migratie van bestaande inhoud.
-
Plan voor "in-sprint-migratie" na refactoring.
-
Plan 'content burndown' (sitemap voor go-live content).
-
Schatting van tijd en inspanningen estimating-time-and-effort
Afhankelijk van uw resulterende takenlijst kunt u dan eerste schattingen maken van tijd en moeite voor (high-level) taakdefinities. Deze zouden een aanwijzing moeten omvatten van wie (klant of partner) wat en wanneer zal doen.
De volgende lijst bevat standaardbenaderingen en onderlinge relaties van de betrokken inspanningen, en dus kosten:
De gedetailleerde planning kan dan beschikbare of vereiste middelen met termijnen en kosten in verband brengen.
Referentiearchitectuur reference-architecture
De verwijzingsarchitectuur wordt gegeven om een malplaatjeoplossing voor de AEM architectuur te verstrekken. De referentiearchitectuur biedt oplossingen voor problemen die veel voorkomen bij bedrijfssystemen, zoals schalen, betrouwbaarheid en beveiliging.
De volgende sitemetriek moet worden gedefinieerd:
Overzicht van mogelijke gereedschappen overview-of-potential-tools
De volgende lijst bevat informatie over de gereedschappen die u kunt gebruiken. Het is bedoeld als inleiding, niet als een uitgebreide lijst met aanbevelingen, en mag u zeker niet beletten andere instrumenten te gebruiken die u liever hebt.
Meer informatie further-reading
Daarnaast zijn de volgende punten van bijzonder belang:
Best practices voor best-practices
Adobe verstrekt verdere Beste praktijken voor alle fasen en publiek: