Projecten beheren - Controlelijst met best practices

Het beheren van een project om Adobe Experience Manager (AEM) uit te voeren vereist planning en begrip om u bewust te zijn van de kwesties en (verwante) besluiten die u (zowel vóór als tijdens het uitvoeren van uw project) moet maken.

Om u te helpen, bestaan de beste praktijken uit:

Projectkopslagdashboard

Het Werkblad van het Project Heartbeat verstrekt een grafisch overzicht van kritieke metriek voor uw project:

  • Fasekwaliteit

  • Fasegezondheid

    • Een statusindicator op hoog niveau voor uw project; Dit is handig als u gebieden wilt markeren die mogelijk risico lopen.

  • Volledige fase

    • Op om het even welk ogenblik tijdens het project wijst dit erop hoeveel reeds voor elke fase van uw project is voltooid.

Status op rol

In het werkblad Status op rol worden gedetailleerde uitsplitsingen van Gezondheid, Kwaliteit en Volledigheid naar Fase en Persona weergegeven.

Fasen en mijlpalen

Het projectplan wordt opgesplitst in afzonderlijke (hoge) fasen.

Elke fase bevat zijn eigen mijlpalen. Voor elke persona (of rol), zijn de relevante mijlpalen vermeld, samen met de documenten die worden vereist om de bepaalde te produceren producten.

OPMERKING

Er is geen directe 1:1-relatie tussen de afzonderlijke vereiste documenten en te leveren items.

Voorbereiding

De voorbereiding van uw project vormt de basis van het hele project. U moet zeer belangrijke vereisten samen met duidelijke doelstellingen en verwachtingen voor bepalen:

  • Zakelijke motivering

    • De fundamentele redenen en rechtvaardiging voor de uitvoering van het project.

  • Toepassingsgebied en schema

    • Er moet een basisbereik en een ruw tijdschema beschikbaar worden gesteld om te bepalen wat vereist is en binnen welk tijdsbestek. als het de situatie helpt te verduidelijken , kunt u ook bepalen wat buiten het toepassingsgebied ligt .

De manier waarop u uw project voorbereidt, plant en uitvoert en uw oplossing implementeert, wordt beïnvloed door de beperkingen die u uitvoert onder bijvoorbeeld een vast budget, een vast tijdschema, de hoeveelheid inhoud en de vereiste kwaliteit.

Zoals altijd zal het aanpassen van de factoren van invloed zijn op de andere. Als u bijvoorbeeld de tijd verkort, maar hetzelfde kwaliteitsniveau nodig hebt, wordt de prijs waarschijnlijk verhoogd en wordt de hoeveelheid inhoud die u wilt verwerken, verminderd. Begroting is vaak een sleutelfactor, dus dergelijke relaties kunnen niet worden vergeten.

De vier factoren:

projectphase_fourphase

Mijlpalen

  • Validatie

    In deze fase moet u de doelstellingen voor het project bevestigen en bevestigen; bijvoorbeeld:

    • Wat wilt u bereiken/verstrekken?
    • Wie heeft er baat bij?
    • Wat is het toepassingsgebied?
      • Als het de situatie verduidelijkt, kunt u ook bepalen wat buiten het werkingsgebied ligt.
    • Hoe definieert u succes?
    • Hoe zal je succes meten?
      • Wat zijn de vereisten, het bedrijfsleven en de techniek?
      • Zijn er oudere systemen die moeten worden vervangen en zo ja, moeten er gegevens worden gemigreerd?
      • Wie zal daarbij betrokken zijn?
      • Hoe gaat u de voortgang meten?
      • Hoe vaak zult u de vooruitgang tijdens de duur van het project evalueren?

  • Begroting

    Voordat u een project start, hebt u een betrouwbare, realistische schatting nodig van de kosten van de implementatie:

    • Gebruik van informatie uit de valideringsmijlpaal als basis voor de schattingen.
    • Wees realistisch in uw schattingen.
    • Alle richtlijnen, processen of beperkingen waaraan de cliënt onderworpen kan zijn, in overweging nemen en in acht nemen.
    • Nagegaan moet worden of er nood- en herzieningsprocessen zijn als in een later stadium een herziening of verfijning van de begroting vereist is.
    • Bedenk dat de kosten in vele vormen ontstaan. aankopen, gebruik van middelen en vergoedingen.

Planning

De planning van uw project consolideert de voorbereiding. Hier moet u beginnen de doelstellingen en de verwachtingen om te zetten in een duidelijk omschreven routekaart die uit concrete taken bestaat, gebonden door duidelijke communicatie, met strenge evaluaties om vooruitgang te meten.

Mijlpalen

  • Handover

    Een schone overdracht zorgt ervoor dat de juiste persoon/groepen zich bewust zijn van hun verantwoordelijkheden binnen het project.

    Er moeten volledige details worden verstrekt/gegenereerd om ervoor te zorgen dat zij een volledig inzicht hebben in alle relevante aspecten, waaronder het stappenplan, het toepassingsgebied, de doelstellingen, de vereisten en de KPI's.

  • Risicobeoordeling

    Om onaangename verrassingen te voorkomen, gebruikt u een risicobeoordeling om mogelijke risico's samen met hun effect en waarschijnlijkheid te identificeren en te kwantificeren.

    Dit moet vroeg in de levenscyclus van het project worden gedaan om ervoor te zorgen dat eventuele kwetsbaarheden worden geïdentificeerd en geëvalueerd. Op basis van de bevindingen kunt u aan uw belanghebbenden verslag uitbrengen over de vraag of de volledige vereisten kunnen worden toegepast en, indien nodig, of het mogelijk is te plannen dat passende maatregelen worden genomen en gevolgd.

  • Communicatie

    Communicatie is altijd essentieel voor het succes van elk project. U moet duidelijk en efficiënt communiceren om ervoor te zorgen dat iedereen:

    • Werken aan dezelfde basisdoelstellingen
    • Uit dezelfde informatiebasis
    • Met dezelfde kanalen

  • Kick off

    De vergadering Kick Off wordt gebruikt om het bewustzijn te verhogen dat het project begint. Het is een goede gelegenheid om:

    • Alle belanghebbenden (of ten minste vertegenwoordigers van groepen) uitnodigen.
    • Belangrijke feiten over het project presenteren.
    • Beantwoord vragen.
    • Ervoor zorgen dat iedereen dezelfde kennisbasis heeft.
    • Neem de betrokkenheid van iedereen die erbij betrokken zal zijn - dat moet verdiend worden.
      • Door de hoofdrolspelers (inclusief potentiële auteurs) bij het begin van het project te betrekken, verhoogt u de kans dat ze zich voor het project engageren.

Voorbereiding van ontwikkeling

De planning van de ontwikkeling is zeer belangrijk om ervoor te zorgen dat uw project op een stevig ontwerp door een team wordt voortgebouwd dat de vereiste kennis heeft.

Mijlpalen

  • Ontwikkelingsteam met personeel en opleiding

    Voordat u met een project begint, moet u ervoor zorgen dat uw ontwikkelingsteam over voldoende personeel beschikt en dat alle teamleden zijn opgeleid voor de taak in kwestie.

  • Inhoudsarchitectuur

    De inhoudsarchitectuur definieert en beschrijft de toekomstige architectuur van de inhoud. met inbegrip van:

    • De inhoudsstructuur; inclusief activa
    • basisstructuren; inclusief campagnes, enz.
    • Structuren voor meerdere sites en talen (MSM, vertaling, enz.)
    • Ondersteunende inhoud (inclusief tags en coderingsconcepten)
    • Strategieën voor hergebruik van inhoud in cache plaatsen

  • Systeemarchitectuur

    De systeemarchitectuur bepaalt de conceptuele mening van uw systeem; inclusief (onder meer):

    • Systeemstructuur voor alle vereiste omgevingen
    • Subsystemen
    • Systemen van derden
    • interfaces; hardware, software en menselijke interactie
    • Servers voor elke omgeving; zie Technische vereisten en Richtlijnen voor hardwaregrootte
    • processen voor elke omgeving; bijvoorbeeld vereisten inzake implementatie en onderhoud
    • Onderhoudsactiviteiten (GC voor datastore, optimalisatie voor TarPM, enz.)
    • 🔗 Verzending
    • 🔗 ClusteringPubliceren/delen van auteur
    • Prestaties voor de client-side (JS minify, concat, css sprites, totaal aantal http-aanvragen, enzovoort)

  • Toepassingsarchitectuur

    De toepassingsarchitectuur bepaalt en beschrijft het gedrag van de voorgestelde toepassingen.

    Het is gericht op:

    • Hoe zij met elkaar en met gebruikers zullen in wisselwerking staan.
    • De gegevens die door toepassingen moeten worden verbruikt en geproduceerd, in plaats van hun interne structuur.

    De definities moeten betrekking hebben op:

    • Basiscodestructuur voor het project
    • Codeartefacten (bundels, pakketten, enz.)
    • Uitsplitsingen van de templates/componenten en hun relaties
    • Details op hoog niveau van vereiste aanpassingen (specifieke overlays volgen later)
    • Ontwerp van de workflows die voor de oplossing vereist zijn (bijvoorbeeld het maken van inhoud, goedkeuring, publiceren, transformaties, importeren, exporteren, enz.)
    • Speciale aandacht voor alle complexe modules, zoals MSM, Commerce, integratie van derden

  • Systeemintegratie

    De integratie van het systeem vereist u om te plannen (dan uit te voeren):

    • Hoe alle subsystemen en oplossingsintegratie zullen worden samengebracht om als één samenhangend systeem te werken
    • de wijze waarop systemen van derden worden geïntegreerd; samen met eventuele speciale overwegingen, zoals offline/online, client/browser of fallover-verwerking wanneer een systeem van een derde buiten bedrijf is

  • Concept testen

    Voordat u de ontwikkeling start, moet u een diepgaand en uitgebreid concept opstellen van alle testvereisten voor uw project.

    Dit omvat onder meer:

    • Bijzonderheden van alle uit te voeren tests
    • Bereiding van alle voor die tests vereiste inhoud
    • Informatie over eventueel te gebruiken testinstrumenten
    • vermelding op hoog niveau van wie bij het testen betrokken zal zijn; vooral groepen buiten het team QA
    • details van de testautomatisering; bijvoorbeeld met de modus Selenium of AEM Developer

  • Ervaar ontwerp

    Het Ontwerp van de ervaring (XD) impliceert het ontwerpen van de gebruikerservaring voor uw oplossing.

    De gebruikerservaring moet worden geanalyseerd en ontwikkeld voor zowel uw auteurs als de eindgebruikers van uw website.

  • Ondersteuningsinstelling

    Vóór de ontwikkeling moeten alle supportprocessen worden ingesteld die nodig zijn om problemen op te stellen, vrij te geven, te testen en te melden.

    Zie ook Adobe Support Portal.

Planning en activiteiten

Op een vergelijkbare basis moeten de bewerkingen correct worden gepland om ervoor te zorgen dat u beschikt over de omgevingen die u nodig hebt - voor alle fasen van de levenscyclus van het project. U hebt ook de aangewezen processen nodig om hen te handhaven.

Mijlpalen

  • Machtigingen

    U moet een Concept van Rollen en van Rechten voor alle gebruikers/groepen plannen en dan uitvoeren die de oplossing zullen gebruiken.

    Bijvoorbeeld:

    • Een lijst van rollen (d.w.z. groepen) met read/ write toegangsdefinities voor elk
    • Definitie van het gebruik van bevoegdheden die van invloed zijn op de publicatieomgeving; bijvoorbeeld replicate
    • Voor gebruikers met minimale bevoegdheden moeten workflows worden gedefinieerd
    • Gebruikers in de groep editor mogen geen admin rechten hebben en mogen geen deel uitmaken van de groep administrators

    Voor meer informatie, zie Gebruikersbeheer en Veiligheid.

  • Toezicht en onderhoud

    Bewaking en onderhoud zijn belangrijke aspecten om ervoor te zorgen dat uw oplossing probleemloos werkt zodra deze actief is. Hiervoor moet u definiëren:

    • Wat moet er worden gecontroleerd?
    • onderhoudstaken; zowel regelmatig als in bijzondere gevallen

    Zie ook Bewaking en onderhoud voor meer informatie.

  • Migratie

    Alle inhoud van het oudere systeem moet worden gecontroleerd en gevalideerd voor migratie.

  • Herstelplan

    Zorg ervoor dat u een herstelplan hebt. In een noodsituatie moet dit beschikbaar zijn om het productiegebruik van AEM te waarborgen. Dit moet situaties bestrijken zoals back-up, terugzetten, omvergooien en andere.

Ontwikkeling

Ontwikkeling is een cruciale fase die meer vereist dan alleen codering.

Mijlpalen

  • Ontwikkelingsomgeving

    Plan en documenteer uw ontwikkelomgeving, met inbegrip van:

    • Architectuur
    • Ontwikkelingsinstrumenten
      • Een typische omgeving bestaat uit:
        • een systeem voor het volgen van de problemen; zoals Jira
        • een IDE; zoals Eclipse
        • een instrument voor het beheer van bouwwerken; zoals Maven
        • een instrument voor continue integratie; zoals Jenkins
        • een instrument voor versiebeheer; zoals GIT/SVN
        • een beheerder van een constructiegegevensopslagplaats; zoals Archiva/Nexus
    • Integratie/afhankelijkheden van software van derden
    • Integratie/afhankelijkheid van oplossingen
    • Implementatiecadade

  • Testsysteem

    Plan en documenteer uw testomgeving, met inbegrip van:

    • Architectuur
    • afhankelijkheden van ontwikkelingsgebouwen; inclusief nachtelijke builds
    • De mogelijkheden voor of beperkingen van het testen van softwareintegratie/afhankelijkheden van derden
    • Testgereedschappen
    • Geautomatiseerde teststrategie

  • Productiesysteem

    Plan en documenteer uw productieomgeving, met inbegrip van:

    • Architectuur
    • Implementatiecadade
    • Integratie/afhankelijkheden van software van derden
    • Beveiligingsinstelling
    • Basislijnprestaties geverifieerd door de Tough Day-tests uit te voeren bij het instellen van de productie
    • Voorschriften voor prestatietests zie Aanbevolen werkwijzen voor kwaliteitsborging

  • Integratie

    Plan, documenteer en test alle aspecten van het systeem en oplossingsintegratie, met inbegrip van:

  • Migratie

    Plan, documenteer en test alle aspecten van de inhoudsmigratie; met inbegrip van:

    • Inhoudsarchitectuur
    • Migratiestrategie

  • Communicatie

    Zorg ervoor dat alle teamleden en projectmedewerkers indien nodig worden bijgewerkt.

  • Documentatie

    De oplossing volledig documenteren; met inbegrip van:

    • Handboek
    • Alle aanpassingen die invloed kunnen hebben op upgrades
    • Opmerkingen bij de release

Prestaties en tests

Zodra de nieuwe toepassing beschikbaar is, moet deze streng worden getest, zowel voor functionaliteit als voor prestaties.

OPMERKING

Elk testteam moet neutraal kunnen blijven en de testresultaten kunnen leveren.

Het is de verantwoordelijkheid van de projectbeheerder om de gevolgen van de resultaten te beoordelen en een besluit te nemen over passende maatregelen.

Mijlpalen

  • Acceptatietest eindgebruiker

    Het testen van gebruikersacceptatie (UAT) is van cruciaal belang om ervoor te zorgen dat:

    • De oplossing voldoet aan de vereisten van de gebruiker/klant
    • De klant/gebruikers accepteren de oplossing (functie, ontwerp en prestaties)

    Er zou een geformaliseerde controlelijst voor klantenoverdracht moeten zijn; ideaal geautomatiseerd en elke avond tegen een momentopname. De resultaten moeten naar de projectmanager en het ontwikkelingsteam worden verzonden

  • Prestatietests en belastingtests

    Prestatie- en belastingstests worden gebruikt om ervoor te zorgen dat de oplossing bij gemiddelde en piekbelastingen aan de vereiste prestatieniveaus voldoet.

    Zie voor meer informatie over het testen van prestaties:

    OPMERKING

    Dit proces moet worden voortgezet bij normaal gebruik van AEM, maar deze eerste fasen zijn het meest cruciaal.

Uitrol

De introductie van uw nieuwe toepassing moet zorgvuldig worden gepland om ervoor te zorgen dat Go Live probleemloos wordt uitgevoerd. Dit omvat het bevestigen van een hoog niveau van veiligheid, het opleiden van alle potentiële gebruikers en het maken van meerdere droogteperioden om te bevestigen dat alle kwesties zijn opgelost.

Mijlpalen

  • Voorbereiding

    De voorbereiding en planning zullen helpen een vlotte implementatie verzekeren.

  • Training

    Ervoor zorgen dat alle betrokken personeelsleden zijn opgeleid.

    Zie Adobe Experience Manager in de cursuscatalogus.

  • Beheerders getraind

    Zorg ervoor dat uw oplossingsbeheerders:

    • Opgeleid
    • Het juiste trainingsmateriaal ontvangen
    • De juiste documentatie ontvangen

  • Training voor gebruikers

    Zorg ervoor dat de auteurs beschikken over:

    • Opgeleid
    • Het juiste trainingsmateriaal ontvangen
    • de passende documentatie heeft ontvangen; bijvoorbeeld de Handboek

  • Penetingtests

    De tests van de penitentie simuleren een aanval op een computersysteem om potentiële veiligheidstekortkomingen te identificeren.

  • Penetratie-/beveiligingstests

    Om de veiligheid van uw oplossing te verzekeren, voer specifieke penetratietests, samen met een bredere waaier van veiligheidstests uit.

    Zie Beveiligingschecklist voor meer informatie.

Live gaan

Je wilt dat je Go Live zo vloeiend mogelijk wordt. De laatste stappen moeten opnieuw worden gepland voor een schone uitvoering.

Mijlpalen

  • Voorbereiding

    De voorbereiding en planning zullen helpen een vlotte Go Live verzekeren.

  • Beveiliging

    Bevestig de veiligheid van uw oplossing voor zowel interne als externe gebruikers en hun inhoud.

  • Fallback

    Ervoor zorgen dat alle systemen, procedures en mechanismen die vereist zijn voor het terugvallen, aanwezig zijn voordat ze in gebruik worden genomen.

  • Ondersteuning

    Ervoor zorgen dat de supportservices op hun plaats zijn en klaar zijn.

  • Overgang

    Plan en voer de overgang naar uw productieomgeving en gebruikers uit.

  • Uitrollen

    Bereid en voer uw rooktests uit.

Persona

De checklists zijn ontworpen door personen. Dit zijn de rollen met significant betrokken bij de cyclus van het projectleven.

Er zijn ook sommige andere persona die bij specifieke taken betrokken zijn.

Projectsponsor

De projectsponsor is:

  • Verantwoordelijk voor het verstrekken/presenteren van de bedrijfscase voor het project.

  • Sleutel tot de vormgeving en omschrijving van het toepassingsgebied van het project; met inbegrip van:

    • de definitie van en criteria voor succes
    • de belangrijkste KPI's

  • Geef de belangrijkste mijlpalen op basis van de routekaart van de klant.

Projectbeheer

De projectmanager is:

  • Verantwoordelijk voor de algemene uitvoering van het project op basis van de vereisten (bv. toepassingsgebied, KPI's, succescriteria en definitie) die door de projectsponsor zijn verstrekt.
  • Verantwoordelijk voor de vaststelling van de begroting en de financiering van het project op basis van die begroting.
  • Het belangrijkste communicatiepunt voor alle bij het project betrokken personen.

Architect

De oplossingsarchitect:

  • is verantwoordelijk voor het ontwerp op hoog niveau van de oplossing en het systeem.
  • Hiermee kunt u de implementatiestrategie voor AEM definiëren. Bijvoorbeeld, of om een gegroepeerde installatie, of een koude reserve uit te voeren, of wanneer een netwerk van de inhoudslevering (CDN) nodig is.
  • Bepaal ook de AEM oplossingsarchitectuur die op de cliëntvereisten wordt gebaseerd. Dit kan het concept voor gebruikersrollen (met verwante rechten), het verband tussen malplaatjes en componenten omvatten, of wanneer om multi-plaatsbeheer te gebruiken.

Business Analyst

De bedrijfsanalist:

  • is primair verantwoordelijk voor het verzamelen en analyseren van de vereisten op hoog niveau en zet deze vervolgens om in specificaties:

    • voor de projectmanager om te gebruiken wanneer het plannen van de ontwikkeling
    • voor het ontwikkelingsteam om van tijdens ontwerp en ontwikkeling te werken.

  • Werkt nauw samen met de klant om de vereisten te analyseren. Ze komen overeen met:

    • De definitie van succes.
    • De criteria voor succes.
    • KPI's (zowel zakelijk als op basis van prestaties).

Ontwikkelingslood

De ontwikkelingsleiding:

  • is verantwoordelijk voor de technische uitvoering van het project.

  • Is verantwoordelijk voor het selecteren van een ontwikkelingsmethodologie die aan cliëntvereisten voldoet.

  • stelt de ontwikkelingsstrategie op:

    • ervoor zorgen dat het op de zaken en prestaties KPIs gericht is
    • rekening houdend met de succescriteria en -definitie

  • Werkt nauw samen met de architect (met name bij het opstellen van de ontwikkelingsstrategie voor AEM) om aspecten zoals de verhouding tussen malplaatjes en componenten, de integratiestrategie voor derdetoepassingen en om het even welke gespecialiseerde functionaliteit te bepalen.

Kwaliteitslead

De uitsprong van de kwaliteit:

  • is verantwoordelijk voor de kwaliteit van de levering; ervoor te zorgen dat het voldoet aan de criteria voor succes en eventuele door de cliënt gedefinieerde KPI's.
  • Hiermee definieert u de kwaliteitsmaatstaven, lijnt u deze af op alle betrokkenen, stelt u de testplannen op en zorgt u ervoor dat deze worden uitgevoerd.
  • Creeert en levert rapporten aan projectbelanghebbenden.

Systeemengineer

De systeemtechnicus:

  • Is verantwoordelijk voor het toezicht op de projectinfrastructuur.

  • is verantwoordelijk voor:

    • het opzetten van interne ontwikkelings- en testomgevingen
    • voor de aansluiting van deze systemen op de clientsystemen

  • Verstrekt hardwareaanbevelingen, controleert de diverse implementaties en verstrekt verrichtingensteun zowel voorafgaand om live en daarna te gaan.

Beveiligingslead

De beveiligingsleiding:

  • Is verantwoordelijk voor het algemene veiligheidsconcept van de oplossing, die ervoor zorgt dat het met om het even welke vereisten en beleid van de cliënt wordt gericht.
  • Levert een veiligheidsconcept, veiligheidsverrichtingen en aanbevelingen voor om het even welke hardware gebaseerde veiligheidsconcepten; zoals zones en firewalls.

Andere persoon

  • Belanghebbenden

    • Personen (vaak uit het bedrijf) die belang (belang) hebben bij het welslagen van het project. Zij dragen vaak bij aan de begroting.

  • Juridisch

    • Juridisch advies is vereist bij de onderhandelingen over contracten.

  • Leerlingen

    • Afhankelijk van de omvang en de aard van het project kunnen gespecialiseerde opleiders worden gebruikt voor het ontwikkelen en presenteren van trainingssessies voor de relevante groepen.

  • Technisch schrijvers

    • Afhankelijk van de omvang en de aard van het project kunnen gespecialiseerde technische schrijvers worden gebruikt om richtsnoeren en handleidingen voor specifieke groepen te schrijven; bv. een onderhoudshandleiding voor systeembeheerders of een gebruikershandleiding voor de auteurs.

  • Systeembeheerders

    • Verantwoordelijk voor de doorlopende werking van het systeem.

  • Auteurs en eindgebruikers

    • De personen die het systeem zullen gebruiken om uw website-inhoud te maken en te onderhouden.

Vereiste documenten en te leveren

De controlelijsten bestrijken de Vereiste documenten en Te leveren items voor elke mijlpaal.

  • Er is geen 1:1-relatie tussen deze twee; een groep van vereiste documenten kan bijvoorbeeld tot één leverbaar leiden.
  • Een leverbaar van één persoon kan een vereist document zijn voor een ander persoon tijdens dezelfde mijlpaal.

Vereiste documenten

De Vereiste documenten zijn nodig door de aangewezen persoon wanneer het produceren van hun te leveren voorwerpen.

Voor elk Vereist document moet de persoon aangeven:

  • Y/N: of zij is ontvangen.
  • 1-3: een aanduiding van de kwaliteit van het ontvangen document.

Te leveren items

Voor elke mijlpaal is de juiste persoon verantwoordelijk voor het afleveren van specifieke documenten en dus voor het realiseren van zijn verantwoordelijkheden voor een specifieke mijlpaal.

Voor elke Deliverable moet de persoon aangeven:

  • Y/N: of zij is voltooid.

De te leveren producten worden vaak gebruikt als Vereiste Documenten voor of huidige of een recentere mijlpaal.

Voor beste praktijken bij het opstellen, het beheren, het ontwikkelen, of het ontwerpen, zie het volgende:

Belangrijke documentatiegebieden

Op deze pagina