Aanpak, richtlijnen en vereisten gesteld aan VMM-maatsoftware

Transcriptie

1 Aanpak, richtlijnen en vereisten gesteld aan VMM-maatsoftware 1 Situering Het project Windows Desktop Migratie betekent dat applicaties in een andere omgeving moeten draaien. Het vorige client operating systeem (Windows NT4.0) speelde nogal laks om met systeemzaken (o.a. veiligheid en stabiliteit). Het nieuwe client operating systeem (Windows XP SP2) is een stuk strenger wat systeem-instellingen en componenten betreft en is daardoor veel robuuster en veiliger. Zowel de bestandenstructuur als het centrale register (registry) zijn extra beveiligd. Niettemin is het evengoed mogelijk alles te laten werken mits de inachtname van bepaalde regels. De strengere regels kunnen problemen veroorzaken voor oude applicaties (of applicaties gebaseerd op oude regels wat betreft plaats in bestandenstructuur en registergebruik). Er wordt bij de VMM uitgegaan van een situatie waarin de gebruiker, met gewone permissies (zoals voorzien door Microsoft), de applicaties moet kunnen gebruiken! De gelijktijdige overgang naar een meer gecentraliseerde omgeving (Citrix MPS 4.0 op Windows 2003 SP1) stelt daarbij nog extra multi-user eisen aan de applicaties. In het kader van de migratie moeten alle applicaties in MSI-formaat gepackaged ( verpakt ) worden. Een pakket kan daarmee automatisch geïnstalleerd worden op zowel Windows XP (met GPO s) als op Citrix (met ingebouwde installer). 2 Indeling applicaties Voor de volledigheid van dit document wordt de aanpak beschreven dat het dvp SYS/HD aanhoudt voor alle applicaties. De applicaties worden ingedeeld in hoofdcategoriën naargelang afkomst en functie: 1. Commerciëel algemeen : samenvoeging van applicaties met dezelfde functies. Waar mogelijk vervalt het pakket, van de overblijvende wordt zoveel als mogelijk de meest recente versie ingezet. Er wordt rekening gehouden met reeds aanwezige bestandstypes. Enkele gebruikers ( key-users ) worden gecontacteerd over de noodzaak of het nut ervan en het dvp SYS/HD doet een voorstel. De beslissing over welk pakket het uiteindelijk wordt gebeurt in samenspraak met de gebruikers (functioneel) en met het dvp LOG (budgettair). Zoveel als mogelijk komen de applicaties op Citrix, en zoveel als mogelijk worden de pakketten voorbereid voor automatische installatie (tenzij heel beperkt aantal installaties). De voorkeur voor Citrix houdt in dat applicaties gevalideerd moeten worden op multiuser-gedrag (zie verder). Ook bij aankoop moet daarmee rekening mee gehouden worden. 2. Commerciëel dev-tools : hier gaat het over de ontwikkelingstools die aangekocht werden voor het dvp ASW of sommige andere programmeurs. Door het dvp SYS/HD worden geen voorstellen gedaan, de applicaties zullen enkel op de desktops komen. De inspanning voor repackaging (automatische installatie) zal hier minimaal zijn, gezien het beperkte aantal installaties en de meestal hogere complexiteit ervan. De ontwikkelsoftware zal dus meestel manueel geïnstalleerd moeten worden. 3. Commerciëel technical : software die bij bepaalde toestellen hoort, meestal direct aan de computer gekoppeld. Overschakeling naar andere versies worden niet voorgesteld door het dvp SYS/HD aangezien het toestel hier bepalend is welk programma er gebruikt moet worden. De installatie van de pakketten zal meestal enkel op de desktops/portables gebeuren, zoveel als mogelijk zal automatische installatie voorzien worden. 4. VMM-maatsoft ASW : deze applicaties zijn kritisch voor de VMM en vereisen een aparte aanpak. Weinig applicaties kunnen vervallen en samenvoegen is ook niet mogelijk. Applicaties die extern ontwikkeld geweest zijn maar naderhand door ASW te onderhouden zijn komen ook in deze categorie. Deze applicaties dienen altijd op Citrix te werken, met automatische installatie. De keuze voor Citrix houdt in dat applicaties gevalideerd moeten worden op multiuser-gedrag (zie verder). Ook bij het opmaken van lastenboeken en beoordeling van offertes van aannemers moet daarmee rekening mee gehouden worden! 5. VMM-maatsoft non-asw : applicaties specifiek van VMM maar niet aangeleverd of onderhouden door ASW. De applicaties kunnen zowel bij de VMM (niet-asw) ontwikkeld geweest zijn maar evengoed bij externe bedrijven. In deze categorie komen de belangrijkste bij de VMM ontwikkelde VB(A)-, Filemakeren Access-applicaties. Andere applicaties van externe bedrijven zijn bijv. de Cevi-, Cipal- en Adifoapplicaties. Platform 1 ste keus is altijd Citrix, pas in 2 de instantie kunnen ze op desktop (pc s) komen. De voorkeur voor Citrix houdt in dat applicaties gevalideerd moeten worden op multiuser-gedrag (zie verder). Bij ontwikkeling van nieuwe applicaties moet daarmee rekening gehouden worden. Altijd 1

2 automatische installaties (dus alles moet in MSI-formaat geplaatst worden, tenzij er niets op het Windows XP-toestel moet komen). 6. VMM-Middleware : alles wat, in ruime zin, met middleware te maken heeft werd hier bijeengebracht. Het gaat dus om meer dan enkel de componenten voor toegang tot databanken, ook bepaalde VB-dll s, client-managers, common ini-files,. Een uitvoerige beschrijving van de aanpak is terug te vinden in een apart document (VMM middleware-framework). De benaming van de applicaties bestaat steeds uit 3 delen: <org-name>-<product-name>-<version>: - <org-name>: firma, organisatie of maker programma (bij VMM-apps is dat steeds VMM ) - <product-name>: de naam van het programma (bijv. emissie-afvalwater) - <version>: de versie. Opmerking: de heel specifieke applicaties op labo-toestellen komen voor het migratieproject niet in aanmerking. Wegens het (meestal) afwijkende merk en type, stuurprogramma s, taalkwesties en heel specifieke toepassingen kan er te weinig aan geautomatiseerd worden. 3 Aanpak VMM-maatsoftware (al of niet van ASW) 3.1 Algemeen Alle applicaties dienen vooreerst opgelijst te worden, met telkens de erbij horende dependencies (1). Dat kan gaan over bepaalde dll s, middleware, plug-in s,.... Dat is niet altijd even vanzelfsprekend. Sommige componenten (dll s, ocx-en, ) staan bijv. wel al op de computer van programmeurs (want meegekomen met andere pakketten of de ontwikkelsoftware) maar daarom nog niet op de computers waarop het ontwikkelde programma uiteindelijk moet werken. Die dependencies moeten zoveel als mogelijk in één document komen en aan dvp SYS/HD bezorgd worden. Een reeds bestaand document per applicatie voor de eindgebruiker (bijv. een installatie- of gebruikershandleiding) is daarvoor niet voldoende. Het moet gaan om een specifiek document waarin beschreven wordt wat het platform extra moet bieden aan de applicatie. Na dat werk dient de ontwikkelaar het pakket enigszins voor te bereiden op de nieuwe omgeving (2). Zoals eerder gesteld is Windows XP (en Windows 2003 met Citrix) een stuk strenger en dienen bepaalde richtlijnen ( Windows XP Logo Program ) in acht genomen te worden (zie verder). Tenslotte dient de applicatie getest te worden in een zo representatief mogelijke omgeving (3). Een applicatie dient altijd te kunnen werken op Windows XP, wat altijd een eerste test zou moeten zijn. Op Terminal Server (Citrix) moet de applicatie getest worden op multi-user gedrag Oplijsting van applicaties + beschrijving van dependencies (1) Delphi/Omnis (ASW) Het dvp SYS/HD verwacht van ASW dat alle Delphi/Omnis-applicaties overzichtelijk opgesomd worden in één document. Er dient telkens een vermelding van de dependencies te komen, waaronder vooral ook de middleware. Het is noodzakelijk dat de middleware nauwkeurig vermeld wordt, aangezien dvp SYS/HD voor die installatie zal instaan. Enkele voorbeelden van het vereiste detailniveau: 1) applicatie GWIP : - dependent runtime: OMNIS 73 v7.0.2 runtime - middleware software: MDAC 2.8 SP1 + Informix 2.81 TC2 - middleware db -configuratie: ODBC 0applicaties, 0water, 4applicaties en 4water 2) applicatie HeffingenGV : - dependent app: Microsoft Word 2000 of dependent hardware: handscanner op seriële poort - middleware software: MDAC 2.8 SP1 + Informix 2.81 TC2 + Microsoft Jet Microsoft XML4 EN SP2 + Barcode-fonts - middleware db-configuratie: ODBC...; BDE 0Heffingen, BDE 2Heffingen,... Let op, informatie als xlkjd.dll is benodigd voor het correct draaien van de applicatie kan niet worden getolereerd. Dergelijke bibliotheken zijn bevat in middleware pakketten en dienen als dusdanig te worden bekeken. De Delphi/Omnis-applicaties zullen allemaal gerepackaged moeten worden, wat een opdracht van het dvp SYS/HD is. De repackager haalt uit de legacy-setup eventueel sommige componenten uit omdat die apart geïnstalleerd dienen te worden of gewoon overbodig zijn. De middleware-componenten (drivers + configuratie) zijn altijd apart te installeren (zie specifiek document). De opmerkingen komen in een 2

3 documentje. Het dvp SYS/HD zal na packaging en installatie zelf instaan voor een beperkte test: de opstart van de applicatie en de logon (op test en productie). De verdere testen (functionele) moeten door ASW en key-users gebeuren. De repackaging verandert eigenlijk niets aan de software zelf, daardoor kan het resultaat van de testen gedeeltelijk voorspeld worden Web (van ASW of andere oorsprong) Het dvp SYS/HD verwacht van ASW dat ook de web-gebaseerde maatsoftware overzichtelijk opgesomd worden in één document. Er dient eveneens telkens melding gemaakt te worden van de dependencies. Sommige vereisen bijv. een Java-runtime of Excel, Word,. Indien een plug-in een specifieke versie moet zijn moet dat ook vermeld worden. Ook specifieke browserinstellingen kunnen de werking beïnvloeden en dienen daarom vermeld te worden Applicaties van andere oorsprong Grosso-modo worden dezelfde eisen gesteld, dus zoveel mogelijk detail van vereiste dll s, achtergrondapplicaties, plug-in s, instellingen,.... De applicatie kan aangeleverd worden in afzonderlijke componenten (dll s, ocx en,...) of in de vorm van een legacy-setup (in niet MSI-formaat) Voorbereiden maatsoftware op de nieuwe omgeving (2) Men zou al onmiddellijk kunnen beginnen testen met de applicaties op Windows XP of Windows 2003 van zodra die omgeving beschikbaar is. Echter, een betere strategie is vooraf een analyse te maken van het pakket. Het pakket moet getoetst worden aan wat de nieuwe omgeving zal bieden (en niet zal bieden). Het dvp SYS/HD stelt een aantal extra zaken ter beschikking: - Roaming-profiles: het dvp SYS/HD zal het gebruik van roaming profiles op beperkte wijze invoeren. Daarmee kunnen instellingen (in registry, ini-files, ) en bestanden (shortcuts, ) meegaan naar de computer(s) waarop de gebruiker werkt. Dat zal zowel binnen de Citrixomgeving gebeuren (tussen de servers onderling) en op de Windows XP-computers. De beperkte wijze houdt in dat er slechts een aantal zaken in roaming komen, bijv. internet favorieten, cookies, instellingen van Outlook,. - Een L-schijf: dezelfde schijfletter zal er zijn voor Windows XP als onder Citrix (wat standaardisatie toelaat), maar de inhoud ervan zal gescheiden zijn! - Middleware-omgeving: de middleware komt uitgebreid aan bod in een specifiek document (VMM Middleware-framework-vx.y). Het beheer van de middleware ligt bij het dvp SYS/HD, aangezien dit een basis is voor alle programma s die bij de VMM moeten (samen) werken Het dvp SYS/HD verwacht dat het dvp ASW en andere programmeurs ook een zekere uniformiteit hanteert i.v.m. benamingen: - in het register wordt (onder software altijd de hoofdkey VMM (zonder punten ertussen!) gehanteerd, zowel onder HKLM als onder HKCU. Onder HKLM komen zaken die op de gehele computer betrekking hebben (bijv. applicatie-versie), onder HKCU komen zaken die betrekking hebben op de aangemelde gebruiker (bijv. een pad naar een map waar het laatst een document opgeslaan werd, een printerkeuze of papierlade,. - idem voor het wegschrijven onder de verschillende folderstructuren (dus niet vmmware maar vmm ). - in tijdelijke bestanden, lokale tabellen of het register altijd en overal de eigen globalisatieregels respecteren. Bijv. nergens nog oppervlaktewater maar steeds immissieoppervlaktewater. Een afkorting daarvan kan ook (bijv. imm-oppl ), maar dan steeds dezelfde. - Gezien het standaard strengere beleid op Windows XP/2003 dient er daar vooraf al mee rekening gehouden te worden. Microsoft heeft een specifiek document gepubliceerd met te volgen richtlijnen om programma s goed te laten werken, meer bepaald het document Designed for Microsoft Windows XP. Het document is algemeen van aard en bedoeld voor (commerciële) software-leveranciers. Een kopie staat ter beschikking in de AOP-map voor alle programmeurs. Het dvp SYS/HD gaat ervan uit dat de richtlijnen gevolgd worden. Ter informatie: de meeste problemen vloeien voort uit ondertussen totaal achterhaalde en verkeerde gewoontes uit de Windows 3.1-wereld! Hierna volgt een opsomming van de meest bekende problemen: gebruik van hard-coded paden: paden dienen altijd relatief te zijn, en indien er moet naartoe geschreven worden dan moet ook de verwijzing daarmee rekening houden. Ook het programma zelf mag 3

4 niet verwachten in een specifieke map te zitten. Bijv. mag de applicatie emissie-afvalwater niet verwachten in de map te staan onder c:\vmmware\.... Ter info: op Windows XP-computers komen de programma s onder C:\Program Files\VMM\<appname> te staan. Op Citrix-servers komen de programma s onder F:\Apps\VMM\<appname> te staan. Enkel ter info dus, de programmeur mag deze paden niet vast in de programma s verwerken! onmogelijkheid te werken met lange padnamen. Meestal is de oorzaak een gehele of gedeeltelijke aanwezigheid van 16bit-code, deze applicaties worden zo mogelijk geweigerd wegens diverse moeilijkheden) het niet gebruiken van environment variables : tal van environment variables staan al langer ter beschikking om het gebruik van absolute paden te kunnen vermijden. Die set variabelen is onder Windows XP (en Citrix-servers) uitgebreider dan onder Windows NT4. Het gebruik ervan zou maximaal moeten zijn, daarom volgt hieronder een lijstje met de meest interessante ervan voor programmeurs: - CommonProgramFiles : verwijst naar C:\Program Files\Common Files, voor het wegschijven van gemeenschappelijjke files van een specifiek bedrijf of organisatie. Wegschrijven gebeurt enkel bij installatie van programma s. Het dvp SYS/HD zal voorzien in een subfolder VMM voor VMM-specifieke zaken (bijv. middleware-configuratie). Deze componenten zijn niet uniek per programma en zullen daarom altijd blijven staan na een uninstall van een programma. - appdata : voor applicatie-specifieke bestanden (wegschrijven wijzigbare tijdelijke data behorend bij een applicatie). Verwijst naar een specifieke plaats per gebruiker (C:\Documents and Settings\<username>\Application Data) waar verder een structuur kan opgebouwd worden per softwareleverancier. Alle VMM-maatsoftware dient onder de naam VMM te komen. Enkel te gebruiken voor heel kleine hulpbestanden, want deze lokatie zal mee opgenomen worden in de roaming!. - homedrive en homepath : via centrale instellingen zal de verwijzing van homedrive steeds gebeuren naar P:, en homepath steeds naar \. Dat zal zowel het geval zijn op Windows XP als op Citrix!. - clientname : hier staat steeds de (NETBIOS) name van de computer. Bij de VMM is dat bijv. steeds GAS voor computers van de Gasthuisstraat, begint de naam met MAIN dan draait het programma op een Citrix-server. - sessionname : hierop kan een detectie gebeuren of de applicatie in multi-user mode moet werken of niet. Op Windows XP-computers is dat altijd Console, binnen een Terminal Serversessie begint dat steeds met RDP-... en binnen een Citrix-sessie is dat steeds beginnend met ICA-. - temp (of tmp ): voor wegschrijven op de lokale hard-disk van tijdelijke bestanden. Er kan absoluut geen gebruik meer gemaakt worden van C:\temp, dat bestaat niet meer! De bestanden die tijdelijk naar %temp% weggeschreven worden mogen redelijk groot zijn, aangezien deze folder niet mee gaat roamen. De door het programma gecreëerde files moeten na afsluiten van het programma steeds verwijderd worden! De programma s mogen niet verwachten dat bij de volgende opstart er daar nog iets van een vorige keer teruggevonden kan worden. - verkeerd gebruik van de registry-keys HKLM en HKCU : die keys hebben een specifiek doel en moeten correct gebruikt worden. HKLM dient vooral voor algemene gegevens m.b.t. het programma, zoals versie-info, standaard-instellingen,.... HKCU dient voor user-gebonden zaken, zoals gemaakte menukeuze s, kleurinstellingen, laatste keer opgestart, pad naar lokatie van data, ladekeuze van een printer voor bijv. speciaal papier,.... Een gewone gebruiker heeft geen schrijfrechten op HKLM, wat ook zo hoort te zijn. verkeerd gebruik van de bestandenstructuur: nogal wat programma s proberen zaken weg te schrijven die niet toegankelijk zijn voor een gebruiker met normale gebruiksrechten. Bijv. de logging voorzien naar het pad c:\ is niet mogelijk verkeerd gebruik van de bestandenstructuur: applicaties proberen soms output-data weg te schrijven naar een vast gecodeerd pad in een submap van de applicatie. De applicatie moet er steeds in voorzien de gebruiker de vrije keuze te geven waar gegevens terecht moeten komen (op een map naar keuze op server). Deze keuze kan weggeschreven worden in de HKCU. het veelvuldig en/of verkeerd gebruik van ini-files: het gebruik ervan is te vermijden. Het gebruik ervan moet dan wel correct zijn, ttz. (systeem-) instellingen die eerder bij de installatie of de computer horen moeten in een andere ini-file terechtkomen dan voor gebruikersinstellingen. Gebruikersinstellingen moeten terechtkomen in een ini-file die weggeschreven wordt op een plaats waarop de gebruiker schrijfrechten heeft (profiel van de gebruiker). 4

5 het wegschrijven naar Windows Protected zone s : Windows XP laat niet meer toe dat er tal van dll s weggeschreven worden naar de system-folder (c:\windows\system32). Deze zone is beschermd om een oplossing te bieden aan de zogenaamde Dll-hell. In de plaats moeten dll s die bij programma s horen terecht te komen onder de eigen folder of een andere gemeenschappelijke folder (zoals bijv. C:\Program Files\Common Files\Borland Shared voor de gemeenschappelijke zaken van Borland) Applicaties testen op een zo representatief mogelijke omgeving (3) De testen dienen te gebeuren op een zo representatief mogelijke omgeving. Het moet vooral een systeem zijn waarop de ontwikkelsoftware, of delen ervan, niet aanwezig zijn. Het dvp SYS/HD kan op dit moment al een vrij goede testomgeving onder Windows XP beschikbaar stellen aan programmeurs. Daarop kunnen alvast alle applicaties al getest worden. Een testomgeving met Terminal Server en Citrix is moeilijker te bezorgen. De extra eisen gesteld door Terminal Server zijn multi-user gedrag, een goede werking op Windows XP en de inachtname van de multi-user - regels zullen het testwerk kunnen beperken. Belangrijke opmerkingen: 1. veel programmeurs beschikken over de verhoogde gebruikersrechten om het programmeerwerk te verrichten. Sommige beschikken zelfs (al of niet tijdelijk) over installatierechten en hebben de neiging dan daarmee te testen. Die testen zijn zo goed als waardeloos om eerder vermelde redenen. Het testen dient het best zelfs te gebeuren met een gewone gebruikers-account die nog nooit eerder installatierechten verkregen heeft! Daarom heeft het dvp. SYS/HD voorzien in testaccounts met de naam test-v.achternaam. Alle testen van ASW-maatsoftware dienen daarmee te gebeuren. 2. het dvp SYS/HD doet slechts een heel beperkte test van applicaties. Het dvp doet slechts het volgende: - gewone applicaties: opstarten en enkele menu s doorlopen, eventueel openen van een bestand - applicaties met aanlogprocedure op een database: opstarten + uitvoeren aanlogprocedure. Het logon-test zal gebeuren op de verschillende db s (voor zover er een logon+paswoord ter beschikking gesteld werd). Daar stopt het testwerk van het dvp SYS/HD. Het verdere testen wordt beschouwd als zijnde functionele testen en dient uitgevoerd te worden door andere mensen (key-users, applicatieverantwoordelijken, referentie-gebruikers,...). In geen geval kan van het dvp SYS/HD een inhoudelijke kennis van de applicaties verwacht worden! 4 MSI achtergrond info (begeleidende info voor lastenboeken) Het dvp SYS/HD wil zoveel als mogelijk automatische installaties kunnen uitvoeren. Het installatiesysteem werkt enkel op basis van MSI-pakketten, een Microsoft-techniek die ingevoerd werd sinds het jaar Een MSI-file is in feite een database in de vorm van een bestand die alle elementen bevat (of kan bevatten) die nodig zijn om een pakket op een computer te krijgen. In een lastenboek zou er aan leveranciers van maatsoftware kunnen gevraagd worden om het pakket te bezorgen in de vorm van een MSI-file. Komt het pakket zo van huis uit (een zogenaamde native MSI ), dan is het relatief eenvoudig voor het dvp SYS/HD daar nadien een zogenaamde MSI Transform (MST) voor te maken. In zo n transform zitten dan de keuzes die normaal in dialoog verschijnen bij een manuele installatie, het is dus een soort answer file. Omdat de installaties meestal net iets anders moeten gebeuren naargelang het platform (bijv. installatiepad van op Windows Server 2003 is steeds F:\apps ) zijn er soms meerdere MST s van toepassing op éénzelfde MSI. Belangrijke opmerkingen: - de applicatie-leverancier moet steeds bij inschrijving al melding maken van alle dependencies (zie ook eerder). In de regel is alles wat geen eigen code is een dependency! - de applicatie-leverancier mag absoluut geen redistributables in een eigen native MSI verwerken. Eventuele redistributables moeten steeds apart geleverd worden. Bij de VMM zijn die er meestal al, al of niet in een afwijkende versie (bijv..net Framework 1.1). - de MSI mag absoluut geen extra scripts of andere installatie-hulpmiddelen zoals ISScript nodig hebben of bevatten. - De Installer-property INSTALLDIR moet steeds correct gebruikt worden om de VMM toe te laten de applicatie op een pad naar keuze te installeren. 5

6 Andere installatietechnieken (zogenaamde legacy setups ) vereisen aanzienlijk meer voorbereidingswerk, dan moet nl. het MSI-pakket volledig zelf gemaakt worden (taak van dvp SYS/HD). De aanmaak van een MSI-pakket kan vrij ingewikkeld zijn. Veel applicatie-leveranciers zijn trouwens zelf niet in staat dat tot een goed einde te brengen. Ofwel besteden ze dat dan zelf uit of hebben ze de neiging af te komen met een half-afgewerkt pakket (met een ellenlange manuele installatieprocedure. Elk binnenkomend pakket met (maat-)software dat bij de VMM binnenkomt (via het dvp ASW maar evengoed via anders dvp s!) dient daarom aan een evaluatie-onderzoek onderworpen te worden. De kwaliteit van dat pakket is mede bepalend voor acceptie van de applicatie. Opgelet: een installatiepakket die native MSI aangeleverd werd zal nooit in een nieuw MSI-pakket gestoken worden door het dvp SYS/HD. Want op eigen aangemaakte MSI s zijn latere updates van de leverancier daarop niet meer mogelijk. Het belang van kwaliteitsvolle MSI-pakketten aangeleverd door leveranciers kan daarom niet genoeg benadrukt worden in lastenboeken. Daarnaast, eigenlijk los van het MSI-verhaal, kunnen wij als VMM-opdrachtgever bepaalde normen eisen (in het bijzonder voor applicaties in de categorie VMM-maatsoft ASW en VMM-maatsoft non-asw ). Het dvp SYS/HD zal die normen niet zelf beschrijven maar verwijst daarvoor logischerwijze naar publiekelijk beschikbare documenten op het internet (Microsoft website). Eerder werd al zo n document vermeld, nl. het document Windows XP Logo Program. Dat document staat centraal beschikbaar onder de map Z:\AOP\Migratie Windows XP-Citrix\documenten voor ontwikkelaars. Gezien het standaard platform voor applicaties bij de VMM Terminal Server/Citrix server is, dienen zeker de VMM-applicaties multi-user te zijn. Een document met richtlijnen betreffende het optimaliseren van applicaties voor Citrix-servers kan onder dezelfde map teruggevonden worden. Ook dat document moet als input gebruikt worden voor lastenboeken. Tenslotte zijn er op het internet talrijke document met richtlijnen voor software-ontwikkelaars beschikbaar. Het dvp SYS/HD verwacht dat de ontwikkelaars zich op eigen initiatief informeren over de nieuwe ontwikkelingen en daarmee maximaal rekening mee houden. 6