Ordlista glossary

I den här ordlistan visas (i bokstavsordning) information om alla dokument i slutprodukten som finns i Projektchecklista.

Godkännande från affärsintressenter acceptance-from-business-stakeholders

Godkännande från affärsintressenter bekräftar att de, som viktiga intressenter, är anpassade till lösningen och har gett sitt godkännande av hur affärskraven uppfyller affärsärendet.

Godkännandetester acceptance-tests

Godkännandetester utförs när ett program är klart för produktion. Testerna utförs av en grupp som representerar de olika typerna av slutanvändare, med hjälp av realtidsscenarier.

Godkännandetester används för att bekräfta att

Ju tidigare ni planerar och utformar era godkännandetester, desto enklare blir den slutliga driftsättningen. De bör definieras tillsammans med kunden och ditt kvalitetssäkringsteam.

Även om du kanske inte kan definiera alla detaljer i början av projektet bör de inledande definitionerna diskuteras och godkännas. Godkännandetesterna kommer antagligen att baseras på de grundläggande kraven (funktion och prestanda).

Åtkomst till testsystemkoordinerad access-to-test-system-coordinated

Kontrollera att de nödvändiga nivåerna av systemåtkomst har beviljats för alla roller.

Adobe Security Checklist adobe-security-checklist

The Adobe Security Checklist är den officiella checklista som tillhandahålls för att säkerställa att Adobe Experience Manager (AEM) är säkert vid installationen. Den innehåller de säkerhetsåtgärder och verifieringssteg som du måste utföra för att säkerställa instansens integritet.

Projektinställningar för Adobe supportportal adobe-support-portal-project-set-up

På Adobe Support Portal kan implementeringspartners och kunder ställa in AEM implementering som ett projekt i supportportalen.

Information kan registreras, t.ex. om de tekniker och versioner som implementeras. Dessa ger transparens mellan kunden och Adobe.

Utbildning av AEM aem-administrator-training

Utbildning för administrativ personal i lösningen. Se Adobe Training Services för mer information.

Utbildning av AEM aem-author-training

Utbildning för personal som ska producera (skriva) innehåll för lösningen. Se Adobe Training Services för mer information.

AEM certifieringsprov aem-certification-exam

Se till att rätt personer registreras för att ta relevanta uppgifter certifieringsprov.

AEM Certifierad aem-certified

Se till att rätt person har passerat den relevanta certifieringsprov.

AEM teknisk utbildning aem-technical-training

Erbjuda teknisk utbildning för lämplig personal, t.ex. utvecklare, arkitekter, ingenjörer och yrkesverksamma.

Avtal om nyckeltal definierade som mål för projektet agreement-on-kpis-defined-as-goals-for-the-project

KPI:er (Key Performance Indicators) hjälper en organisation att definiera och mäta framstegen mot organisatoriska mål. När en organisation har analyserat sitt uppdrag och definierat sina mål måste den mäta framstegen mot dessa mål. KPI:er utgör en mätmekanism.

Justera nyckeltal för företag och prestanda align-business-and-performance-kpis

Anpassning av verksamheten och nyckeltal för prestanda hjälper er att samla alla berörda personer och processer inifrån organisationen. Detta bidrar i sin tur till att minska den tid och det arbete som krävs för att uppnå verksamhetsmålen och uppfylla det föreslagna syftet.

Anpassning av innehållsarkitekturen med nyckeltal alignment-of-content-architecture-with-kpis

Se till att den föreslagna innehållsarkitekturen är anpassad till relevanta KPI (Key Performance Indicators).

Justering av kundens färdplan med projekttidslinjen alignment-of-the-customer-roadmap-with-project-timeline

Kundens färdplan består av milstolpar på hög nivå och affärsmål. Projektets tidslinje måste följa och vara anpassad till denna strategi, så alla potentiella risker och/eller eventuella avvikelser måste markeras och spåras.

Programarkitekturdefinition application-architecture-definition

The applikationsarkitektur bör tydligt definiera beteendet hos de föreslagna tillämpningarna.

Den fokuserar på:

Programspecifika underhållsaktiviteter har definierats application-specific-maintenance-tasks-defined

Förutom vanliga underhållsåtgärder för Adobe Experience Manager (AEM) måste du definiera alla andra driftsuppgifter som måste köras för det pågående underhållet av lösningen.

Lämpligt utbildad personal appropriately-trained-staff

Se till att ditt team består av personal med lämplig utbildning. För projektteam är rekommendationen att ha följande:

Arkitekturdiagram architecture-diagram

Arkitekturdiagrammet är en grafisk representation av arkitekturen. Den innehåller följande uppgifter:

Arkitektur - utkast architecture-draft

Detta ger en översikt över system- och lösningsarkitekturen på hög nivå. I det här skedet är det ett utkast som kommer att granskas och förfinas i senare skeden.

Arkitekturens granskningskort - Sign Off architecture-review-board-sign-off

Arkitecture Review Board är ett övergripande organ som

Granskningsnämnden bör representera alla viktiga intressenter som är involverade i arkitekturen. Vanligtvis består de av en grupp chefer som ansvarar för granskning och underhåll av den övergripande arkitekturen.

Automatiserad testsvit anpassad för verkligt innehåll och resultat jämfört med nyckeltal automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Automatiseringsskript och grundläggande automatiserade användningsområden:

Automatiserad testningsstrategi automated-testing-strategy

Denna strategi definierar ett ramverk för återanvändbara automatiserade skript, tillsammans med den strategi som planeras av kvalitetsteamet (QA). Den sammanfattar den övergripande planen för automatiseringstestning för att säkerställa:

Automatiserad testningsstrategi validerad mot realistisk och förväntad belastning automated-testing-strategy-validated-against-realistic-and-expected-load

Den automatiserade testningsstrategin måste valideras och justeras i enlighet med innehållet och den förväntade belastning som kommer att finnas på lösningen.

Automatiseringsstrategi automation-strategy

Automatisering av driftsättningar ger snabbare och enhetligare driftsättning. I automatiseringsstrategin beskrivs konfigurationen av sådana automatiseringsmekanismer, inklusive

Medveten om kommunikationsplanen aware-of-communication-plan

Hela projektgruppen och alla intressenter måste bekräfta att de är medvetna om följande:

Medveten om framgångsrika definitioner och kriterier aware-of-success-definitions-and-criteria

Hela projektgruppen och alla intressenter måste bekräfta att de är medvetna om följande:

Koncept för säkerhetskopiering och återställning backup-and-restore-concept

Koncept för säkerhetskopiering och återställning anger de tekniska funktioner som kommer att implementeras i lösningen. Det krävs av företagets policy för säkerhetskopiering och återställning.

Säkerhetskopiering och återställning har testats backup-and-restore-tested

Ett komplett test som bygger på konceptet för säkerhetskopiering och återställning.

Affärsärenden business-case-s

I ett affärsdokument presenteras argument som gäller att vidta en åtgärd, vidta alternativa åtgärder (om sådana finns) eller inte vidta några åtgärder. Argumenten bör vara balanserade på grundval av konkreta fakta (där det är möjligt/relevant) och framhäva både fördelar och risker i samtliga fall.

Ett affärsdokument bör vara en tydlig definition av alla alternativ och avslutas med ett övertygande argument för att implementera den föreslagna lösningen.

Affärsanalytiker förstår omfattningen av projekt och förväntningar business-analyst-understands-scope-of-project-and-expectations

Affärsanalytikerna bör bekräfta att de till fullo förstår:

KPI:er för företag business-kpis

Organisationer använder nyckeltal (KPI:er) för att utvärdera hur de lyckades uppnå sina mål.

Affärs-KPI:er definierar mätbara värden som visar hur effektivt ett företag når viktiga affärsmål. Det är viktigt att välja nyckeltal som är lämpliga för ert företag/scenario med tydliga definitioner av vad de är, hur de mäts, hur de används och av vem.

Dokumentation för affärskrav business-requirements-documentation

Ett dokument med affärskrav (BRD, business requirements document) innehåller en detaljerad beskrivning av affärslösningen för ett projekt och en tydlig specifikation av kundens behov och förväntningar. BRD skiljer också mellan affärslösningen och den tekniska lösningen.

När BRD undersöker affärslösningen bör det svara på frågan:"Vad vill företaget göra?"

Business Sign Off on any required adjustments to the Solution or Architecture Identified and Alignment Against ROI and KPI Expectations business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

Processerna för riskbedömning och penetrationstestning kan ge problem och resultat som måste behandlas i lösningens uppbyggnad eller utveckling.

Alla justeringar som följer av dessa processer måste granskas och godkännas av företaget och vägas mot de övergripande målen.

Cachelagring caching-strategy

Cachningsstrategin visar vad som kommer att cachas för slutanvändaren. Den måste vara kompatibel med nyckeltal för prestanda.

Exempelvis kan element som bilder, JavaScript och andra serverfiler cachelagras för att förbättra prestanda i en lösning.

Riktlinjer för kodning coding-guidelines

I riktlinjerna för kodning definieras grundläggande principer som utvecklarna bör följa när de utvecklar lösningen. Dessa kan bland annat vara:

Kommunicera drifthandbok communicate-operations-manual

Se till att alla lämpliga personer/roller har tagit emot drifthandboken.

Rapport om prestandatestning communicate-performance-test-report

Se till att alla lämpliga personer/roller har fått prestandatestrapporten.

Kommunicera versionsinformation communicate-release-notes

Kontrollera att alla lämpliga roller har tagit emot versionsinformationen.

Kommunicera omfattning och förväntningar till teamet communicate-scope-and-expectations-to-team

Se till att projektteamet är fullt medvetet om och anpassat till projektets omfattning och förväntningarna på leverans.

Kommunicera utbildningsmaterial och användarhandböcker communicate-training-materials-and-user-guides

Se till att alla lämpliga personer/roller får utbildningsmaterialet och användarhandböckerna.

Efterlevnad av kundsäkerhetskrav compliance-with-customer-security-requirements

Se till att alla kundens säkerhetskrav är uppfyllda.

Efterlevnad av säkerhetskoncept compliance-with-security-concept

Kontrollera att säkerhetskonceptet är på plats.

Relationskoncept för komponenter och mallar components-and-templates-relationship-concept

Konturen med de mallar och komponenter som används i det nya programmet. Innehåller bland annat information om arvsregler, behörigheter och relationer.

Relationsspecifikation för komponenter och mallar components-and-templates-relationship-specification

Information om relationskonceptet för komponenter och mallar.

Komponentspecifikation components-specification

Specifikationsdetaljer för var och en av de komponenter som ska implementeras.

Concept for Mock-ups of External Interfaces concept-for-mock-ups-of-external-interfaces

Konceptet för att utveckla mot och testa externa gränssnitt som kanske inte är öppna/tillgängliga för utvecklings- eller testmiljöerna.

Planera/implementera dummies av dessa gränssnitt för att säkerställa att testningen är så nära produktionsliknande beteende som möjligt.

Innehållsarkitekturdokument content-architecture-document

Dokumentation om innehållets föreslagna arkitektur. Detaljerna bör bland annat omfatta följande:

Innehållet har validerats för migrering content-validated-for-migration

Det gamla systeminnehållet granskas och det valda innehållet valideras för migrering till den nya lösningen.

Kontraktsutkast contract-draft

Ett första utkast till det rättsliga kontraktet.

Aktuell innehållsstruktur och format current-content-structure-and-format

Dokumentation om aktuell innehållsarkitektur och format. Detta används för att generera den framtida innehållsarkitekturen. Det kommer också att användas för migreringskonceptet.

Policy för säkerhetskopiering och återställning av kund customer-backup-and-restore-policy

Kundens policyer rörande:

Riktlinjer för kundkodning customer-coding-guidelines

Eventuella riktlinjer/krav från kunden om hur utvecklingen ska ske.

Principer för kunddistribution/frisläppning customer-deployment-release-policies

Principer från kunden som definierar hur och när distributioner/releaser kan göras.

Dessa omfattar ofta tidslinjer, schemaläggning och krav på godkännande.

Principer eller krav för kundövervakning customer-monitoring-policies-or-requirements

Kundpolicyer och krav för vad som ska övervakas. Dessa är utöver eventuella rekommendationer som anges i övervakningskonceptet.

Kundproduktionsreleaseplan customer-production-release-schedule

Det schema som definieras av kunden för releaser till produktionsmiljöerna.

Principer och krav för kundrapportering customer-reporting-policies-and-requirements

Alla policyer, eller krav, eller båda, som kunden har för rapportering. Dessa kan vara:

Kundöversikt customer-roadmap

Utforma en färdplan för de viktigaste milstolparna som ska genomföras, både när det gäller teknik och affärsverksamhet. Den här färdplanen skickas sedan till kunden.

Kundsäkerhetsprinciper customer-security-policies

Kunden (företag och IT) kommer att ha policyer som definierar de säkerhetsnivåer som krävs för lösningen. Dessa kan vara:

Riktlinjer för kundspecifikationer customer-specification-guidelines

Alla riktlinjer som kunden har som rör format, leverans och godkännande av specifikationer.

Kundtestrapporter customer-test-reports

Rapporter från kunden till kvalitetsledaren under UAT-perioden (User Acceptance Test).

Anpassningar och snabbkorrigeringar som påverkar dokumenterade uppgraderingar customizations-and-hotfixes-that-affect-upgrades-documented

Alla anpassningar och/eller tillämpade snabbkorrigeringar måste dokumenteras eftersom de kan påverka framtida uppgraderingar:

Testrapport om användarantagande per dag daily-user-acceptance-test-report

Rapporter eller möten som är resultatet av UAT (User Acceptance Testing). De ska beskriva:

Standardsäkerhet aktiverat default-security-enabled

Kontrollera att standardsäkerhetsinställningarna för AEM har aktiverats/implementerats.

Distributions-/versionsprinciper och processer deployment-release-policies-and-processes

Formaliserade profiler som omfattar både driftsättning och releaser av ditt projekt. Dessa kan vara:

Distributionscentret har upprättats deployment-cadence-established

Definiera hur ofta distributionen ska ske i olika miljöer.

Utvecklingsmetod development-methodology

En metod för programvaruutveckling innebär att hela processen för programvaruutveckling delas upp i olika faser (eller faser), var och en med distinkta aktiviteter. Syftet är att förbättra planeringen och förvaltningen.

När du definierar metoden bör du fördefiniera specifika produkter och artefakter som skapas och slutförs av projektteamet för att utveckla eller underhålla programmet.

Definition av utvecklingsroll development-role-definition

Definiera vilken utvecklare och/eller roll som kör IT (prestanda eller andra) och/eller enhetstester i lösningen.

Utvecklingsmiljö klar development-environment-ready

Se till att utvecklingsmiljön är konfigurerad med de integrerade verktyg som krävs för automatisering av distributioner.

Utvecklingsteamet förstår omfattningen av projekt och förväntningar development-team-understands-scope-of-project-and-expectations

Utvecklingsgruppen bör bekräfta att de till fullo förstår:

Dialogrutespecifikation dialogs-specification

Information om dialogrutorna som krävs för lösningen.

Installation av dokumentutvecklingsmiljö document-development-environment-setup

Dokumentation om utvecklingsmiljön.

Inställningar för dokumentproduktionsmiljö document-production-environment-setup

Dokumentation av produktionsmiljön.

Inställningar för dokumenttestmiljö document-test-environment-setup

Dokumentation av testmiljön.

Hållbarhetstest durability-test

Hållbarhetstestet visar lösningens prestanda under en specifik belastning. Testen mäter hur länge lösningen överlever när den utsätts för tröskelbelastning och vid vilka prestandanivåer.

Varaktighetstestet har körts durability-test-executed

Utförande av hållbarhetstester.

Felhanteringskoncept error-handling-concept

Felhantering avser att förutse, identifiera och lösa programmerings-, applikations- och kommunikationsfel.

Felhantering av dokumentation error-handling-documentation

Detaljerad dokumentation om den föreslagna felhanteringen, baserad på konceptet Felhantering.

Eskaleringsprocesser escalation-processes

Definition av alla eskaleringsprocesser. Det kommer att finnas separata processer för varje projektnivå:

Fastställa vanliga sessioner för kvalitetsgranskning establish-regular-quality-review-sessions

Håll regelbundna kvalitetssemöten med rätt teammedlemmar.

Befintlig behörighetsstruktur existing-permissions-structure

Dokumentation av den befintliga behörighetsuppsättningen och grupper som definierats för den äldre lösningen eller inom organisationen.

Karta över befintliga system existing-systems-map

Ett diagram (eller en uppsättning diagram) över befintliga system och beroenden.

Definitioner och kriterier för lyckade resultat förväntades expected-success-definitions-and-criteria

Projektsponsorn samlar in de affärsförväntningar som är förknippade med projektets framgång. Det är viktigt att ha alla förväntningar tillgängliga i början av ett projekt, eftersom dessa bör påverka alla beslut som fattas under hela genomförandet.

Förväntningarna kan vara:

Krav för Experience Designs experience-designs-requirements

Krav för hela upplevelsen av lösningen. Detta omfattar bland annat faktorer som personalisering, enhetsoberoende och användarupplevelse.

Experience Specifications experience-specifications

Information om kraven för Experience Design.

Externa system- och användarberoenden/systemkontext external-system-and-user-dependencies-system-context

Ett diagram (eller en uppsättning diagram) över hela ekosystemet i lösningen. Detta bör omfatta element som externa integreringar, gränssnitt, beroenden och nätverk.

Reservsystem och -procedur fallback-system-and-procedure

Definitionen av reservsystemet:

Reservsystem och procedur som testats fallback-system-and-procedure-tested

Fullständigt test av reservsystemet.

Inloggning av reservsystem från affärsintressenter fallback-system-sign-off-from-business-stakeholders

Godkänn, från affärsintressenter, att reservsystemet och relaterade procedurer säkerställer de kritiska affärsfunktionerna.

Förberedande bekräftelse på nyckeltal feasibility-confirmation-on-kpis

Resultat av en genomförbarhetsstudie för både AEM och konstruktion av högnivålösningar. Dessa bör mätas mot nyckeltal för att säkerställa att dessa kan uppfyllas.

Slutet kontrakt finalized-contract

Ett slutfört och signerat kontrakt krävs innan du fortsätter med projektet. Detta baseras på Kontraktsutkast.

Funktionaliteten i lösningen som accepteras av intressenter functionality-of-the-solution-accepted-by-stakeholders

Bekräftelse på att berörda parter till fullo godtar

Go Live Schedule go-live-schedule

Tidslinje och tidsplan för de aktiviteter som krävs för:

Happy Paths defined happy-paths-defined

En bra sökväg är ett standardscenario som inte innehåller några exceptionella eller felförhållanden. Den består av den sekvens av aktiviteter som utförs när allt blir som förväntat.

Maskinvaruuppskattningar hardware-estimates

Ursprungliga uppskattningar av:

Maskinvara är tillgänglig för att uppfylla kraven hardware-will-be-available-to-fulfill-requirements

Bekräftelse på att all miljö har den maskinvara som krävs.

Krav på hög nivå high-level-requirements

Definitionen av kraven på hög nivå ger en generaliserad uppdelning av systemkraven, som omfattar aspekter som:

Grundläggande information om dessa funktioner är vanligtvis kända, så det här dokumentet bör inte vara en uppskattning.

Lösningsdesign på hög nivå high-level-solution-design

Den högnivåbaserade lösningen förklarar arkitekturen som används för att utveckla lösningen. Arkitekturen ger en översikt över hela systemet och identifierar de viktigaste komponenterna som har utvecklats för produkten och deras gränssnitt.

Systemöversikt high-level-system-map

Den här systemkartan bör innehålla ett diagram på hög nivå av systemet. Den skiljer sig från lösningssammanhanget genom att det är en generaliserad karta över alla system som ingår, det finns inga gränssnitt i det här diagrammet.

Struktur för historiskt innehåll historical-content-structure

Definition av innehållsstrukturen i det äldre systemet. Detta används som referens och även när migreringsstrategin förbereds.

Historiska nyckeltal för prestanda och historik historical-performance-and-historical-performance-kpis

Samla in och dokumentera statistik om prestanda och KPI:er från det gamla systemet. Dessa används sedan som referenspunkt och för att testa den nya lösningen.

Identifiera viktiga lösningar/funktioner identify-critical-key-solutions-functionalities

En lista över affärskritiska funktioner.

Implementering - Ändringar som baseras på resultaten av penetrationstester implementation-changes-based-on-penetration-test-results

Implementering av alla nödvändiga ändringar (som har undertecknats) av lösningen baserat på resultaten av penetrationstesterna.

Implementering - automatiserad testningsstrategi implementation-automated-testing-strategy

Inställning av de verktyg och processer som krävs för automatiserad testning.

Implementering - automatiseringsstrategi implementation-automation-strategy

Inställning av de verktyg och processer som krävs för automatisering.

Implementering - Innehållsarkitektur implementation-content-architecture

Implementering av innehållsarkitekturen, taggningskoncept och återanvändning av innehåll.

Implementering - Experience Design implementation-experience-design

Implementering av kraven för Experience Design.

Implementering - Reservsystem och förfaranden implementation-fallback-system-and-procedures

Implementering av reservsystemet och tillhörande förfaranden.

Implementering - integrering implementation-integration

Implementering av integrering med alla nödvändiga externa system.

Genomförande - Migrationsstrategi implementation-migration-strategy

Migrering tillsammans med validering av innehåll och andra artefakter för den nya lösningen.

Implementering - roller och rättigheter implementation-roles-and-rights

Implementering av roller och rättigheter, användare och grupper.

Implementering - säkerhetskoncept implementation-security-concept

Implementering av alla säkerhetsåtgärder, inklusive AEM.

Implementering - säkerhetsprogramvara implementation-security-software

Implementering av programsäkerhet.

Implementering - säkerhetskoncept för systemarkitektur implementation-system-architecture-security-concept

Implementering av systemsäkerheten.

Implementering - URL-hantering implementation-url-handling

Implementering av URL-hanteringskonceptet.

Implementering - arbetsflöden implementation-workflows

Implementering av designade arbetsflöden.

Implementeringskoncept implementation-concept

Implementeringskonceptet innehåller riktlinjer för hela implementeringen. Den bör beakta följande:

Detta koncept beskriver också ramverk, bibliotek och andra artefakter som används i lösningen.

Informera Adobe support om Go Live Schedule inform-adobe-support-about-the-go-live-schedule

Kontakta supporten på Adobe för att säkerställa att allt stöd som behövs kan aktiveras när du är på språng.

Inledande upplevelsedesign initial-experience-designs

Preliminära koncept för utformningen av upplevelserna.

Integrationstestning integration-testing

Testning och den resulterande bekräftelsen av alla integreringar, både interna och externa.

Detta bör automatiseras och köras ofta för att säkerställa systemets stabilitet.

Ärendespårningsprocess issue-tracking-process

Tydliga processer registrerar alla problem som påträffats och håller reda på pågående aktiviteter i syfte att se till att alla frågor behandlas.

System och processer för ärendeuppföljning issue-tracking-system-and-processes

Ett spårningssystem, tillsammans med de processer som krävs, för att registrera alla problem som påträffas och spåra pågående aktiviteter i syfte att säkerställa att alla problem hanteras.

Alla projektintressenter bör ha tillgång till informationen för att underlätta insynen i projektets status.

Exempel är Atlassian JIRA och HP Quality Center.

Processen för ärendespårning är inställd och integrerad issue-tracking-system-process-is-set-up-and-integrated

Den valda verktygen är helt integrerad och ger åtkomst till alla nödvändiga roller.

Äldre system legacy-system

För ditt projekt är det äldre systemet den befintliga tekniken, datorsystemet eller det befintliga programmet som kommer att ersättas av den nya lösningen.

Information om det äldre systemet bör samlas in så att du vet vad som kan tas ur bruk, när och hur det påverkar andra system.

Lista över utvecklingsverktyg som ska användas list-of-development-tools-to-be-used

En översikt över de verktyg som används vid implementeringen; verktygen ska omfatta:

Lista över användare som behöver åtkomst till Adobe supportportal list-of-users-that-require-access-to-adobe-support-portal

En lista över alla användare och roller som behöver åtkomst till supportportalen i Adobe.

Listan består normalt av Solution Architect och/eller kundens IT-personal.

Loggfilsanalys log-file-analysis

En analys, tillsammans med de rekommendationer som blir resultatet, som definierar vad som måste loggas för att övervaka lösningen:

Underhållsaktiviteter (AEM specifika) Testade och aktiverade maintenance-tasks-aem-specific-tested-and-enabled

Testa och aktivera AEM underhållsuppgifter som:

Migreringsplan migration-plan

dokumentera migreringen, inklusive

Migreringsstrategi migration-strategy

En fullständig beskrivning av det befintliga innehållet, innehållsarkitekturen och de format som är mappade till den nya lösningen. Den ska omfatta följande:

Det bör även rekommendera hur innehållet ska hållas uppdaterat (eller så uppdaterat som möjligt) under perioden mellan migreringen och det faktiska användningstillfället i det nya systemet. Detta kan betyda att innehållet fryser, publiceras två gånger eller att ett alfavärde upprätthålls.

Övervakning - CPU monitoring-cpu

Övervaka hur lösningen använder systemets CPU:

Övervakning - disk-I/O monitoring-disk-i-o

Övervaka lösningens diskingång och utdatahastighet:

Övervakning - diskutrymme monitoring-disk-space

Övervaka hur diskutrymmet används:

Du bör övervaka användningen genom att:

Övervakning - externa system monitoring-external-system-s

Övervaka alla anslutningar mellan lösningen och externa system:

Övervakning - nätverksbandbredd monitoring-network-bandwidth

Övervaka hur nätverkets bandbredd används:

Övervakning - begäranden monitoring-requests

Övervaka förfrågningar som görs till lösningen.

Övervakning - säkerhetspunkter monitoring-security-points

Övervaka vid de definierade säkerhetspunkterna.

Övervakning - system monitoring-system

Övervaka det övergripande systemet, till exempel:

Övervakning - tröskelvärde och intervention monitoring-threshold-and-intervention

Övervakning av lösningens definierade tröskelvärde och genomförande av interventionsåtgärder för att minska belastningen.

Övervakningskoncept monitoring-concept

De övervakningskoncept som ska tillämpas på din lösning, inklusive:

Övervakning av potentiella läckagepunkter monitoring-potential-weak-points

Specifika punkter som kan vara felbenägna bör identifieras och definieras. Alla övervakningsuppgifter som rör dessa bör också definieras.

Exemplen är bland annat:

Övervakningsprincip som kommunicerats till systemingenjör monitoring-policy-communicated-to-system-engineer

Se till att systemingenjörer och driftspersonal känner till och förstår eventuella övervakningsprinciper.

Övervakningsrapporter - Struktur på plats monitoring-reports-structure-in-place

Definiera:

Dokumentation om operativa uppgifter operational-tasks-documentation

Alla operativa uppgifter dokumenteras, med definierad frekvens.

Drifthandbok operations-manual

Handbok som innehåller all information som krävs för att lösningen ska kunna användas och underhållas:

Ska även innehålla en detaljerad beskrivning av implementeringskoncept för

Förberett paket package-prepared

Programvarupaketet är byggt och levereras klart för driftsättning.

Genomstrykningstester penetration-tests

Ett penetrationstest (kallas vanligen penntest) är en attack på ett datorsystem som söker efter säkerhetsbrister och som kan få tillgång till datorns funktioner och data.

Genomstrykningstester - godkända penetration-tests-passed

Alla obligatoriska villkor har skickats.

Genomstrykningstester - resultat penetration-tests-results

Rapporter som skapats för företaget och som förklarar resultatet av penetrationstestet.

Prestanda och skalbarhet performance-and-scalability-concept

Konceptdokument om hur ni ser till att implementeringen uppfyller nyckeltal för prestanda och hur ni skalar lösningen så att den fortsätter att uppfylla dessa nyckeltal.

Prestandatest performance-benchmark

Prestandatestet används för att definiera prestandatestning, hållbarhetstestning och övervakning. Det gör man genom att utvärdera prestandaegenskaperna för lösningen och systemmaskinvaran.

KPI:er för prestanda performance-kpis

Dessa definierar de KPI:er (Key Performance Indicators) som krävs för att mäta systemets prestanda. Några exempel är sidinläsningstid, svarstid för servern och prestanda för databasfrågor.

Prestandatester - rapport performance-tests-report

Rapporter som skapats för företaget, med detaljerad information om resultaten av prestandatesterna.

Prestandatester - Resultatmatchning av nyckeltal för prestanda performance-tests-results-match-performance-kpis

Resultatet måste matcha definierade nyckeltal och förväntningarna på prestanda.

Personabaserad testning persona-based-testing-concept

Personabaserad testning är en metod som bygger på de olika personligheter som beskrivs i Experience Designs. Dessutom testas konton och deras relaterade behörighetsnivåer.

Detta används ofta i UAT (User Acceptance Testing).

POC-testad och verifierad mot kravdokumentation poc-tested-and-verified-against-requirement-documentation

Konceptbeviset (POC) mäts mot kraven för att säkerställa att båda är justerade.

Checklista efter distribution post-deployment-checklist

En checklista som definierar antalet kontroller och uppgifter som ska utföras efter varje distribution.

Checklista före distribution pre-deployment-checklist

En checklista som definierar antalet kontroller och uppgifter som ska utföras före varje distribution.

Prestandatester för produktionsmiljöns baslinje production-environment-baseline-performance-tests

Det är vanligt att köra ett baslinjetest på en standardinstallation av AEM. Detta används sedan som riktmärke för att testa implementeringen och maskinvaran mot.

Produktionsmiljö klar production-environment-ready

Bekräfta att produktionsmiljön är redo med automatiserad driftsättning.

Production Sign Off från Business Intressentors production-sign-off-from-business-stakeholders

Innan Go Live lanseras i produktionsmiljön måste man bevilja Production Sign-off (PSO). Detta är resultatet av en granskning av den release som kommer att bli aktuell, tillsammans med alla kända problem. En del av Go Live-schemat ger dig rätt att anmäla dig.

Processen för produktionssignering och policy production-sign-off-process-and-policy

Den policy och process som krävs för att få Production Sign av innan paketet flyttas till produktionsmiljön.

Plan för projektkommunikation project-communication-plan

Definiera kommunikationsplanen för både affärsintressenter och projektteamet.

Projektansträngningar - slutliga uppskattningar project-efforts-final-estimates

The ursprungliga uppskattningar var höga och gjordes i enlighet med de höga kraven för genomförandet.

Dessa granskas, förfinas och utökas för att ge den slutliga uppskattningen. Beräkningar ska levereras av varje lämplig projektledare, inklusive projektledning, konsulttjänster, arkitektur, testning och utveckling.

Dessa uppskattningar används för att finansiera och budgetera.

Projektansträngningar - Initiala uppskattningar project-efforts-initial-estimates

Inledande uppskattningar är höga och görs i enlighet med de höga kraven för genomförandet. Detta kommer att granskas och förfinas i senare faser.

Projektorganisation project-organization

Den dokumentation som krävs för att ge en översikt över projektets och teamets organisation och rapporteringsstruktur.

Tar ofta formen, eller inkluderar, ett diagram för att visa en visuell översikt över tidslinjer och ansvarsområden. Det finns många verktyg som kan hjälpa dig med detta.

Projektets omfattningsdokument project-scope-document

I projektomfångsdokumentet måste du identifiera och dokumentera en lista med:

Det omfattar det som måste uppnås, tillsammans med det arbete som måste utföras, för att genomföra projektet

Projektstatusrapporter inom en angiven gräns project-status-reports-within-a-defined-cadence

Projektstatusrapporter levereras enligt överenskommet schema och i föreskrivet format.

Konceptbevis (POC) proof-of-concept-poc

Proof of Concept (POC) implementerar ett begränsat antal funktioner för lösningen.

Det bör syfta till att visa att lösningen är genomförbar, verifiera att den kan uppfylla det avsedda ändamålet och bevisa att den kan användas.

Rensa regler purge-rules

AEM har flera versioner av resurser och innehåll. Rensa regler är utformade och konfigurerade för att regelbundet ta bort de äldre versionerna för att upprätthålla databasens hälsa och storlek.

Kvalitetsrapportformat och Cadence quality-report-format-and-cadence

Definiera önskat innehåll och format för kvalitetsrapporten, tillsammans med hur ofta den ska levereras.

Frigör koordinerat release-coordinated

Projektledaren koordinerar alla roller som krävs för frisläppningen till produktion.

Versionsinformation release-notes

Versionsinformation är en del av dokumentationen för releasen. Versionsinformationen ska omfatta följande:

Den används med Runbook för att köra för- och efterinstallationssteg och -kontroller.

Utgåva som körs i produktionsmiljö release-running-on-production-environment

Slutversionen körs och är aktiv i produktion.

Relevanta avtalsvillkor relevant-contract-terms

Framhäv specifika avtalsvillkor som är relevanta för projektets genomförande, t.ex. avtalsenliga milstolpar, faktureringsperioder eller personalkrav.

Rapporteringsgräns reporting-cadence

Tillsammans med kunden kan du definiera hur ofta rapporter skickas till dem.

Databasoptimering repository-optimization

Data skrivs aldrig över i en tjärfil, diskanvändningen ökar även om bara befintliga data uppdateras.

För att motverka den ständigt ökande storleken på databasen har en optimeringsstrategi införts för att ta bort föråldrade data.

Begäran om att konfigurera projektavsnitt i supportportalen för Adobe request-for-setting-up-project-section-in-adobe-support-portal

Den officiella förfrågan om att konfigurera ditt projekt i Adobe supportportal.

Krav - dokumentation requirements-documentation

Denna uppsättning dokumentation omfattar de funktionella och icke-funktionella kraven, tillsammans med de beräknade insatserna.

Resurser som finns tillgängliga för support på Go Live resources-available-to-support-go-live

Se till att alla roller som krävs för live-publicering är bemannade och tillgängliga.

Riskbedömning risk-assessment

Riskbedömningen görs av kundens IT-avdelning, säkerhetsavdelning eller båda.

Den bedömer projektets tekniska och affärsmässiga risker. Bedömningen krävs för att lösningen ska uppfylla säkerhetsprinciperna.

Riskminimeringsplan risk-mitigation-plan

I riskhanteringsplanen ingår riskbedömningen. Tillsammans täcker de

avkastningsförväntningar roi-expectations

Definiera förväntningarna på avkastning på investering (ROI) som är kopplade till lösningen.

De syftar till att ange lösningens effektivitet i ekonomiska termer genom att definiera de förväntade fördelarna/vinsterna i förhållande till den beräknade investeringen.

Roller och rättigheter roles-and-rights-concept

Detaljerad specifikation av de begrepp som gäller roller och åtkomsträttigheter som krävs för den nya tillämpningen, inklusive en översikt på hög nivå över

Roller och rättighetskoncept uppfyller säkerhetsriktlinjerna roles-and-rights-concept-meets-security-guidelines

Granska rollerna och rättighetskonceptet för att säkerställa att det uppfyller säkerhetsprinciperna.

Roller och rättighetsspecifikation roles-and-rights-specification

En detaljerad specifikation baserad på konceptet Roller och rättigheter.

Security Architecture Recommendations security-architecture-recommendations

Recommendations för säkerhet för programvaran och maskinvaruarkitekturen.

Riktlinjer för säkerhetsbaserad kodning security-based-coding-guidelines

Dessa riktlinjer definierar hur utvecklingskodningen ska göras, baserat på säkerhetskrav som:

Säkerhetschecklista security-checklist

Projektspecifik checklista för objekten, baserat på säkerhetskonceptet tillsammans med eventuella ytterligare policyer som krävs för att säkerställa att lösningen är kompatibel.

Detta ingår ofta som en del av stegen efter distributionen i runbook.

Säkerhetskoncept security-concept

Definiera och dokumentera information om den säkerhetskonfiguration som krävs för programmet, arkitekturen och infrastrukturen.

Utkast av säkerhetskoncept security-concept-draft

En översikt på hög nivå som täcker säkerhetsinställningarna för

Säkerhetsproblem listade och utvärderade security-issues-listed-and-assessed

Alla säkerhetsfrågor i den listade och bedömda lösningen, inklusive uppskattningar av fiskeansträngningen.

Säkerhetssignering från affärsintressenter security-sign-off-from-business-stakeholders

Signera från intressenter för att se till att säkerhetsimplementeringen följer policyer och förväntningar.

Konfigurera supportprocesser set-up-support-processes

Ställ in de supportprocesser som krävs.

SLA för tredjepartssystem slas-for-third-party-systems

Se till att servicenivåavtal (SLA) är tillgängliga och kommunicerade med både utvecklings- och verksamhetsteamen för användning under implementering och support.

Röktestskoncept smoke-test-concept

Röktest består av en uppsättning definierade steg som testar lösningens viktigaste funktioner för att säkerställa att lösningen fungerar som den ska.

De körs i alla miljöer efter installation eller distribution.

Röktester som utförts för systemvalidering smoke-tests-executed-for-system-validation

Röktest ska köras på alla system för att säkerställa att lösningens grundläggande funktioner fungerar korrekt vid installation eller driftsättning i alla miljöer.

Software Architecture Strategy software-architecture-strategy

Den övergripande strategin för programvaruarkitekturen, inklusive tjänster, serverar, ramverk och andra implementeringsbeslut.

Konferensgruppen för lösningsgranskning har inrättats och möteskonferenser har angetts solution-review-board-established-and-meeting-cadence-set

Översynsnämnden för lösningar består av kundintressenter.

Styrelsen har regelbundna möten för att fortlöpande se över de krav och specifikationer som för närvarande gäller. Målet är att säkerställa att de överensstämmer med definitionen och kriterierna för framgång och även ge underlag för utvecklingen av kraven.

Solution Runbook solution-runbook

Installationsanvisningar för lösningen, tillsammans med grundläggande operativa uppgifter som ska utföras vid installationen.

Signering och godkännandeprocess för lösningen solution-sign-off-and-acceptance-process

Signerings- och godkännandeprocessen beskriver de kriterier som måste uppfyllas innan lösningen kan släppas ut i en produktiv miljö.

Den kan också fungera som en avtalsmässig milstolpe.

Specialfunktionskoncept special-functionality-concept

Det inledande konceptet för specialfunktioner som inte omfattas av den normala utvecklingsnivån på den AEM plattformen.

Speciell funktionsspecifikation special-functionality-specification

Uppgifter om eventuella specialfunktioner som inte omfattas av den normala utvecklingsnivån på den AEM plattformen.

Riktlinjer för specifikationer specification-guidelines

Eventuella riktlinjer från kunden om hur specifikationen ska göras.

Processen för granskning och godkännande av specifikationer har definierats och kommunicerats specification-review-and-approval-process-defined-and-communicated

En tydlig process för kundens godkännande av specifikationer bör införas. Denna process garanterar tydlighet och ett fast utrymme för kraven.

Personal som valts ut för AEM administratörsutbildning staff-selected-for-aem-administrator-training

Intern personal som behöver utbildning för att kunna administrera lösningen.

Personal som valts ut för författarutbildning och slutanvändarutbildning staff-selected-for-author-and-end-user-training

Intern personal som behöver utbildning så att de kan utveckla lösningen.

Intressenter stakeholders

Intressenter är de viktigaste personer och/eller roller som har ett betydande intresse för projektet. Vissa kommer att bidra till projektbudgeten.

Intresset kan vara internt och/eller externt.

Intressenter är medvetna om framgångsrika definitioner och kriterier stakeholders-are-aware-of-success-definitions-and-criteria

Bekräftelse på att alla intressenter utanför det faktiska implementeringsteamet är medvetna om:

Intressenter förstår projekt och förväntningar stakeholders-understand-project-and-expectations

Bekräftelse på att alla intressenter utanför det faktiska implementeringsteamet är i linje med det övergripande projektet och förväntningarna, både interna för projektteamet och kunden.

Formatdefinition för statusrapport status-report-format-definition

Statusrapporter är ett viktigt kommunikationsverktyg. Formatet bör anpassas till eventuella rapporteringskrav från kunden.

Kriterier och definition för lyckade försök success-criteria-and-definition

Kunden, projektsponsorn och projektledaren eller konsulten ska specificera

Dessa används för att säkerställa att kriterierna för framgång uppfylls:

Stöd för validering av rapporterade problem support-in-validation-of-reported-issues

En del av ansvaret för kvalitetsledaren är att se till att det finns resurser som kan stödja alla användare vid testning. Detta kan till exempel hjälpa användaren vid testning, vid rapportering av problem och vid validering av problemen mot testmiljön.

Supportprocesser och åtkomst till Adobe supportportal support-processes-and-access-to-adobe-support-portal

Tillgång till Adobe Support Portal är avgörande för att skicka in biljetter om produktrelaterade problem som kan uppstå under implementeringen.

Nyckelmedlemmar i teamet bör tilldelas åtkomst.

Definition av systemarkitektur system-architecture-definition

Ett första förslag och en definition av arkitekturen för alla miljöer i lösningen.

Systemarkitekturdokumentation system-architecture-documentation

Ett dokument som beskriver systemarkitekturen, inklusive gränssnitt, nätverksplats och integreringar för alla miljöer, bland annat information.

Systemarkitekturens säkerhetskoncept system-architecture-security-concept

En översikt på hög nivå över hur du gör systemarkitekturen kompatibel med andra säkerhetsprofiler. Detta kan omfatta:

Identifierade och verifierade systemriskfaktorer system-risk-factors-identified-and-verified

Alla riskfaktorer som påträffas i riskbedömningen (eller i andra granskningar) identifieras och bedöms:

Teamet är medvetet om framgångsrika definitioner och kriterier team-is-aware-of-success-definitions-and-criteria

Bekräftelse på att hela teamet känner till framgångens definitioner och kriterier.

Teamet är medvetet om kommunikationsplanen team-is-aware-of-the-communication-plan

Bekräftelse på att alla medlemmar i teamet är medvetna om vem som ska kommunicera med kunden, tillsammans med information om hur och när.

Team förstår projekt och förväntningar team-understands-project-and-expectations

Anpassning till det övergripande projektet och förväntningarna, både internt för projektteamet och kunden.

Tekniska krav technical-requirements

Dessa krav är specifika för det tekniska genomförandet av tjänster som stöder lösningen.

Verifierade tekniska riskfaktorer technical-risk-factors-verified

Identifiera och verifiera potentiella tekniska risker. Tekniska risker kan omfatta:

Teknisk specifikation technical-specification

Den tekniska specifikationen omfattar (bland annat) följande:

Mallspecifikation template-specification

Specifikationerna för de mallar som krävs. Dessa bör bland annat omfatta detaljer som parsys, övertryckning och arvsmappning.

Specifikationerna baseras på Business Requirements och Experience Requirements.

Testfall test-cases

Testfall är specifika de detaljerade steg som krävs för att utföra funktionstestning av lösningen.

Testa innehåll test-content

Testinnehållet ska vara så nära produktionsinnehållet som möjligt. Den måste vara tillräckligt bred för att kunna testa alla scenarier.

Testmiljö klar test-environment-ready

Se till att testmiljön är klar, med automatiserade driftsättningar på plats, så att all releasekod är aktuell för testning.

Testrapporter test-reports

Rapporter med detaljerad information om testresultaten, inklusive

Det bör noteras att

Test Suite test-suite

Val av automatiseringsserie och verktyg. Dessa används för att automatisera tester, inklusive de som används.

Test Tooling Suite Selected test-tooling-suite-selected

Automatiseringssvit och verktyg som valts ut för fallautomatisering och andra testkörningsuppgifter.

Testningskoncept testing-concept

Testkonceptet är en översikt på hög nivå över testningen av projektet, inklusive QA-, UAT-, prestanda-, säkerhets- och integrationstestning.

Testningsplaner testing-plans

I dessa planer beskrivs utförligare testerna för varje utvecklingsfas och de bygger på Testningsstrategi.

Testomfång testing-scope

Dessa krav är specifika för det tekniska genomförandet av tjänster som stöder lösningen.

Testningsstrategi testing-strategy

Teststrategin bygger på en övergripande strategi för kvalitetssäkring och testning av användarnas acceptans. Detta inkluderar tidslinjer, rapportstängsel och körning.

Integreringskoncept från tredje part third-party-integration-concept

Koncept på arkitektur- och systemnivå för integrering med tredjepartssystem.

Tredjepartsintegreringsspecifikation third-party-integration-specification

Uppgifter om kraven (både funktionella och icke-funktionella) på funktionalitet och integrering av tredjepartssystem.

Tredjeparts säkerhetskoncept third-party-security-concept

Koncept för att säkerställa säkerheten för alla tredjepartsintegreringar. Måste vara kompatibelt med lämpliga säkerhetsprofiler.

Tredjepartssystem för integrering third-party-system-for-integration

Se till att alla tredjepartssystem finns tillgängliga, med lämplig dokumentation, för implementering av integrering.

Åtkomst till system från tredje part har aktiverats third-party-systems-access-enabled

Nödvändiga åtkomsträttigheter som beviljas respektive roller som används i tredjepartssystem.

Testkoncept från tredje part third-party-testing-concept

Definierar:

Tröskeldefinition threshold-definition

Definierar nyckelvärdena för övervakningspunkter i systemet.

Till exempel:

Tidslinje och milstolpar timeline-and-milestones

Detta bör definiera projekttidslinjer och avtalsenliga milstolpar som ska användas för

Totalt antal projektansträngningar total-project-efforts

Alla insatsuppskattningar, från varje lead i projektet, bör konsolideras, inklusive allmänna, utvecklingsrelaterade, systemtekniska, arkitektoniska och testrelaterade insatser.

Om avtalet innehåller en stödnivå bör även insatser för stöd och insatser ingå.

Utbildningsmaterial training-materials

Material som ska användas i utbildningstillfällen. Materialet ska skapas specifikt för lösningen och utformas för att användas med användarhandböckerna.

Förstå projektets och förväntningarnas omfattning understands-scope-of-project-and-expectations

Lämplig person bör bekräfta att de till fullo förstår

URL-hanteringskoncept url-handling-concept

URL-hanteringen ska omfatta AEM URL-funktioner som:

Begreppet bör även omfatta

Användningsexempel use-cases

Ett användningsfall är en lista över åtgärder eller händelsesteg som krävs för att uppnå ett mål. Vanligtvis definierar de interaktionen mellan en roll och lösningen. Rollen kan vara en användare eller ett externt system.

Använd fall som konverterats till testscenarier use-cases-converted-into-test-scenarios

Testscenarierna bygger på tekniska och affärsmässiga användningsfall. De används för att testa att lösningsbeteendet är som förväntat.

Användarhandböcker user-guides

Användarhandböckerna ger information och hjälp för användarna av lösningen:

Validerad budgetplan validated-budget-plan

Budgetplanen måste granskas och valideras av alla intressenter. De måste kontrollera detaljer som fakturering, belopp och metoder/tidpunkt för budgetrapportering.

Testresultat för textruta white-box-test-results

Testning av vita rutor är en metod som testar interna strukturer eller funktioner i ett program, i motsats till dess funktioner. Testning av vita kartonger kan utföras på enhet-, integrerings- och systemnivå i programtestningsprocessen.

Arbetsflödesspecifikationer workflow-specifications

Baserat på arbetsflödeskonceptet bör dessa specifikationer i detalj definiera de steg som skapar det fullständiga arbetsflödet.

Specifikationen för varje arbetsflöde bör omfatta (minst):

Löpande begrepp workflows-concept

Med arbetsflöden kan ni automatisera AEM. Konturer för arbetsflöden: