ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen
VEREISTEN ONDERSTEUNENDE PROCESSEN
Pagina 1 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen Inhoud 1
Procesbeheer en Continu verbeteren ............................................................................................. 3
2
Projectmanagement ........................................................................................................................ 4
3
Processen voor softwareontwikkeling ............................................................................................. 5
4
3.1
Requirements Development (RD) ........................................................................................... 6
3.2
Technical Solution (TS) ........................................................................................................... 6
3.2.1
Ontwikkelmethoden ......................................................................................................... 6
3.2.2 2015”
Hulpmiddelen, methoden en omgevingen gerelateerd aan de “Exploitant ICT-contract 6
3.3
Product Integration (PI) ........................................................................................................... 6
3.4
Verificatie en validatie .............................................................................................................. 6
3.4.1
Algemeen ......................................................................................................................... 6
3.4.2
Minimumvereisten voor in beheer name door Exploitant ICT-contract 2015 .................. 7
Overige Ondersteunende processen............................................................................................. 12 4.1
Offertebeheer......................................................................................................................... 12
4.2
Problem management ........................................................................................................... 12
4.2.1
Problemen tijdens ontwikkeling ..................................................................................... 12
4.2.2
Problemen met de ontwikkelde toepassing in productie ............................................... 13
4.3
Configuratiebeheer ................................................................................................................ 13
4.4
“Decision Analysis and Resolution (DAR)” ............................................................................ 13
4.5
“Measurement and Analysis (MA)” ........................................................................................ 13
4.6
Kwaliteitsbeheer .................................................................................................................... 14
4.7
Klachtenbeheer...................................................................................................................... 14
4.8
Contractbeheer ...................................................................................................................... 15
4.9
Relatiebeheer ........................................................................................................................ 15
4.10
Toegangsbeheer.................................................................................................................... 16
Pagina 2 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen De Ondersteunende processen zijn processen die nodig zijn om de in de Service Portfolio beschreven dienstverlening kwalitatief goed en efficiënt te kunnen leveren. Deze processen zullen gebaseerd zijn op de in de ICT-sector gangbare praktijk en op de recentste versie van CMMI-DEV, PRINCE2 en ITIL v3 2011, waar nodig aangepast en aangevuld aan de specifieke vereisten van het Bestuur. De mate waarin deze processen nodig zijn voor de realisatie van de dienstverlening beschreven in de Service Portfolio, is afhankelijk van de vereisten beschreven in de Service Portfolio. De coördinatie en de uitvoering van de Ondersteunende processen gebeurt, tenzij expliciet anders vermeld, door de ICT-Dienstverlener. De ICT-Dienstverlener moet de nodige resources voorzien om deze processen te realiseren. De kost hiervoor dient verrekend te zijn in de Eenheidsprijzen van de betrokken Diensten. De processen moeten de nodige raakvlakken (interfaces) voorzien om te kunnen afstemmen en samenwerken met de processen die gehanteerd worden bij de Klanten, bij e-IB en bij de Exploitant. De ICT-Dienstverlener dient zelf te bepalen welke Ondersteunende processen nodig zijn en hoe ze geïmplementeerd worden. Hierna volgt een niet-limitatieve lijst van Ondersteunende processen die minstens moeten voorzien worden en de vereisten waaraan minstens moet voldaan zijn, naast de vereisten die zijn opgenomen in de andere delen van de Overeenkomst en in het bijzonder de Service Portfolio en het Basiscontract. De hieronder opgenomen verwijzingen naar de procesgebieden uit CMMI-DEV betekent niet dat alle “generic” en “specific practices” van die procesgebieden moeten geïmplementeerd zijn. Er wordt echter wel verwacht dat minstens de procesgebieden die behoren tot het maturiteitsniveau 3 (in het “staged model”) voldoende worden ingevuld. De door de ICT-Dienstverlener uitgevoerde processen worden gedocumenteerd in de Serviceorganisatie.
1 Procesbeheer en Continu verbeteren Hieronder vallen de processen die enerzijds overeenkomen met de volgende procesgebieden uit CMMI-DEV:
“Organizational Process Definition (OPD)”; “Organizational Process Focus (OPF)”; “Organizational Performance Management (OPM)”; “Organizational Process Performance (OPP)”; “Organizational Training (OT)”;
en anderzijds met het proces “Continual Service Improvement” zoals beschreven in ITIL V3 2011 Service operation. De ICT-Dienstverlener zal de nodige processen opzetten om op elk moment tijdens de volledige duur van de Overeenkomst te kunnen garanderen dat de dienstverlening, zoals beschreven in de Service Portfolio, steeds kan geleverd worden:
op een kwaliteitsvolle manier; aangepast aan de evoluerende ICT-dienstverleningsnoden van de Klanten; op een gecoördineerde manier, onafhankelijk van het feit dat bepaalde aspecten door de ICTDienstverlener, dan wel door een Onderaannemer uitgevoerd worden; op een steeds verbeterende, klantgerichte wijze.
Van de processen (met bijbehorende procedures, sjablonen, …) moet steeds een accurate en actuele beschrijving beschikbaar zijn. Zie in dit verband ook de bepalingen in de rubriek “Algemene vereisten met betrekking tot de Serviceorganisatie” in het Basiscontract. Gedurende de looptijd van de Overeenkomst dient de ICT-Dienstverlener op basis van een permanente evaluatie van de ICT-Dienstverlening, van de evoluerende noden (zoals geformuleerd door de Klanten) en van de evoluties op de markt voorstellen te formuleren om de ICT-Dienstverlening te verbeteren. Pagina 3 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen Verbeteringen zijn mogelijk op alle vlakken:
invoeren van nieuwe technologie (bv evolutie naar meer “cloud-enabled” toepassingen of naar meer “mobiele” toepassingen), efficiëntieverhoging door verbeteren / rationaliseren van processen/procedures zodat lagere prijzen kunnen geboden worden voor gelijke resultaten …
Continu verbeteren en innovatie heeft betrekking op een heel gamma van verbeteringen gaande van geleidelijke verbeteringen van de bestaande ICT-Dienstverlening (Continu verbeteren) tot het uitrollen van een volledig nieuwe technologie (innovatie). Het volledige gamma van verbeteringen moet op een samenhangende en gecoördineerde wijze aangepakt en opgevolgd worden. Er dient ook een sterke koppeling te zijn met de processen die enerzijds de evolutie van de (gemeenschappelijke) behoeften van de Klanten detecteren (o.a. Relatiebeheer) en anderzijds de processen die de evolutie van de markt detecteren. Afhankelijk van de omvang en de complexiteit van het Verbetervoorstel zal het voor de uitvoering meest geschikte proces gevolgd worden. Van de ICT-Dienstverlener wordt verwacht dat hij minstens maandelijks de eigen ICT-Dienstverlening evalueert o.b.v.
metrieken en rapporten m.b.t. de performantie van de ICT-Dienstverlening; de resultaten van de onderzoeken in het kader van Problem management; de resultaten van de onderzoeken in het kader van klachtenbeheer; de suggesties en noden van de Klanten die via Relatiebeheer (of andere kanalen) worden doorgegeven; de evolutie op de markt;
Elk onderdeel van de Serviceorganisatie dient in te staan voor de permanente evaluatie van de eigen werking en dient m.b.t. zijn competentiedomein de nodige Verbetervoorstellen in te dienen en uit te voeren. De ICT-Dienstverlener zorgt voor de registratie en opvolging van de Verbetervoorstellen. Alle gegevens m.b.t. deze opvolging moeten vanuit de door de ICT-Dienstverlener vooropgestelde tool geladen worden in het DDC-DWH.
2 Projectmanagement Hieronder vallen de processen die een invulling zijn van de volgende procesgebieden uit CMMI-DEV:
Integrated Project Management (IPM) Project Monitoring and Control (PMC) Project Planning (PP) Quantitative Project Management (QPM) Requirements Management (REQM) Risk Management (RSKM) Supplier Agreement Management (SAM)
Projectmanagement omvat alle activiteiten met betrekking tot het plannen, monitoren, opvolgen en controleren van een Project gedurende de ganse levenscyclus van het Project. Het is van groot belang dat projectbeheer (projectmanagement), terdege en methodisch gebeurt. Om een Project te realiseren zal de ICT-Dienstverlener daarom gebruik maken van een erkende projectmethodologie (PRINCE2 of gelijkwaardig) en van algemeen gangbare beste praktijken (CMMI-DEV). Afhankelijk van de grootte van het Project dient het projectmanagement meer of minder elementen te bevatten. Het is belangrijk dat zowel qua activiteiten als qua resources een projectmanagement op maat van de uit te voeren opdracht en conform de afspraken met de Klanten wordt aangeboden. Naast projectproducten die de eigenlijke oplossing uitmaken die gerealiseerd worden voor benutting door de klant, zijn er ook projectmanagementproducten die bij uitvoering van het project voorzien en Pagina 4 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen gehanteerd moeten worden. De opdrachtnemer/uitvoerder dient een degelijke projectbeheersmethodologie te hanteren, zoals bijv. PRINCE2. De werkproducten van projectbeheer, projectbeheersproducten, maken deel uit van de resultaten van het project. Een belangrijk aspect van een goede projectwerking betreft de organisatie. De klant geeft in eerste instantie zelf aan welke organisatie hij voorstaat en welke klant-gerelateerde rollen en verantwoordelijkheden hij op welke wijze ingevuld wil zien. De klant kan ook aan het projectmanagement bepaalde specifieke vereisten en voorwaarden stellen, waarmee de opdrachtnemer rekening moet houden. Aansluitend zal de opdrachtnemer/uitvoerder, op basis van zijn methodologie, de gepaste verdere organisatorische invulling geven, en dit ook in zijn projectofferte opnemen (bijv. door aan te geven welke standaard organisatie van toepassing is, en welke bijzondere invulling er in voorliggend project specifiek aan wordt gegeven). In het algemeen wordt voor de projectmatige uitvoering van projecten, verwacht dat de principes en de thema’s rond project management volgens PRINCE2, worden gevolgd en op een geschikte manier toegepast. Daarin komen diverse aspecten terug, die verder niet nader worden herhaald in voorliggende proces- en dienstenbeschrijvingen, maar die wel degelijk hun waarde hebben en behoren tot wat in de Vlaamse Overheid als “goede praktijk” wordt beschouwd, zoals de aspecten planning, kwaliteit, wijzigings- en configuratiebeheer, enz. PRINCE2 wordt niet als norm opgelegd, doch een andere projectmanagement methode dient gelijkwaardig en vergelijkbaar te zijn. M.b.t. het “Supplier Agreement Management (SAM)” wordt er in het bijzonder op gewezen dat, tenzij de Klant dit expliciet niet wil, ook de “in productie stelling” (en “in beheer name” door de toekomstige Exploitant) inbegrepen is in het Project. Hiervoor moet de betrokken Exploitant van bij de start van het Project als Onderaannemer betrokken worden. Teneinde een overkoepelende procesbewaking mogelijk te maken, levert elke ICT-Dienstverlener dagelijks de volgende informatie (updates) aan het DDC-DWH:
Status van de projecten: statistiek en overzichtslijst met de status van de bestelde projecten, per periode (maand, jaar). Statussen zijn o.a. besteld (op te starten), in uitvoering, on hold, opgeleverd. Aantal gepresteerde mensdagen per categorie (profielen) per project en ook in totaliteit voor elke personeelscategorie (profielen) per periode (maand, jaar). Rapport softwarekwaliteit: Behaalde softwarekwaliteitsscores (codekwaliteit, op basis van geautomatiseerde testen, test coverage) per ontwikkelopdracht, per periode (maand, jaar) Rapport mijlpalen: Per lopend en uitgevoerd project, een overzicht van de mijlpalen met vermelding van de status en de geplande en de effectieve uitvoeringsdatums. Per lopend en uitgevoerd project: een overzicht van de kengetallen op vlak van kost, tijd en kwaliteit.
3 Processen voor softwareontwikkeling Hieronder vallen de processen die een invulling zijn van de volgende procesgebieden (“engineering process areas”) uit CMMI-DEV:
Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL)
De ICT-Dienstverlener moet minstens voor JAVA- en .Net-ontwikkelingen over de nodige processen en Ondersteunende Systemen beschikken (verrekend in de Profieluurprijzen) om voor deze technologieën op een efficiënte wijze kwaliteitsvolle software te kunnen ontwikkelen. In de Serviceorganisatie dienen de standaard processen en Ondersteunende Systemen in detail beschreven te zijn.
Pagina 5 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen
3.1 Requirements Development (RD) Dit proces heeft betrekking op het verfijnen van de door de Klant via zijn Werkaanvraag opgegeven behoeften en vereisten naar meer gedetailleerde vereisten op het niveau van elk van de te realiseren en aan te leveren Werkproducten. Zie proces “Requirements Development (RD)” in CMMI-DEV.
3.2 Technical Solution (TS) Dit proces heeft betrekking op het selecteren, uittekenen en implementeren van oplossingen in overeenstemming met de vereisten. Zie proces “Technical Solution (TS)” in CMMI-DEV. In het bijzonder dient rekening gehouden te worden met het onderstaande: 3.2.1
Ontwikkelmethoden
Voor wat de bouw van de software betreft, worden geen specifieke methodieken of standaarden vooropgesteld als te volgen norm. Er wordt wel verwacht dat zowel klassieke waterval- als meer agile methoden ingezet kunnen worden, en dat daarbij een degelijke methodologie gehanteerd wordt, die zich bewezen heeft, en die systematisch toegepast wordt. In het bijzonder zal door de uitvoerder toegezien worden op: 3.2.2 -
-
Inspectie van werkdocumenten (met eventuele participatie van de Klant) Continue integratie en testing van ontwikkelde software met meting van code coverage Code kwaliteit, op basis van coding standards en normering, code inspecties en effectieve hulpmiddelen die de controle daarvan systematiseren en automatiseren Versioning van software, gebruik van repositories Applicatie life cycle management … Hulpmiddelen, methoden en omgevingen gerelateerd aan de “Exploitant ICT-contract 2015” In functie van de uiteindelijke goede exploitatie en onderhoud, stelt de Exploitant ICT-contract 2015 een aantal diensten ter beschikking evenals tools en omgevingen, teneinde de ontwikkelaars te ondersteunen bij vlotte ontwikkelings- en testcycli, en ook de overgang naar de exploitatieomgeving zoveel als mogelijk gestandaardiseerd en geautomatiseerd te laten verlopen. De ontwikkelaars worden met het oog op een vlotte en efficiënte “in productie stelling” en “in beheer name” aangemoedigd om maximaal van dit aanbod af te nemen en te benutten waar toepasselijk, door het te incorporeren in hun offertes. Tegelijk wordt van de ontwikkelaar verwacht dat hij ook een aantal tools die in gebruik zijn bij en beschikbaar gesteld worden door de exploitant, benut in functie van zijn ontwikkelingsdiensten. Voorbeeld: benutten van monitoring- en diagnosemogelijkheden voor de toepassingen die in productie worden geplaatst of terwijl ze nog in de testfase zijn op ontwikkel- of testinfrastructuur bij de exploitant.
3.3 Product Integration (PI) Dit proces heeft betrekking op het integreren van de verschillende delen van de uiteindelijk aan te leveren Werkproducten en het aanleveren van een geïntegreerd Werkproduct dat aan de functionele en kwaliteitsvereisten voldoet. Zie proces “Product Integration (PI)” in CMMI-DEV.
3.4 Verificatie en validatie 3.4.1
Algemeen
Zie processen “Verification (VER)” en “Validation (VAL)” in CMMI-DEV. Pagina 6 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen Het doel van de verificatie is het garanderen dat de Werkproducten voldoen aan de gespecificeerde vereisten en het doel van de validatie is het garanderen dat de (finale) Werkproducten voldoen aan hun vooropgestelde functionele behoeften (“fit for use”) wanneer ze in hun productieve omgeving geplaatst worden. Validatie van een nieuwe of gewijzigde software (pakket of bedrijfstoepassing) garandeert dat de software
overeenkomt met de ontwerp-specificaties en voldoet aan de functionele behoeften (“fit for purpose” en “fit for use”);
voldoet aan de niet-functionele vereisten die vooral betrekking hebben op de exploitatie. (“Het is goed gebouwd”). Deze niet-functionele vereisten zijn afhankelijk van de door de Klanten gevraagde Diensten voor exploitatie, maar omvatten voor toepassingen die in beheer moeten genomen worden door de Exploitant ICT-contract 2015 minstens de minimumvereisten zoals beschreven in rubriek “3.4.2 Minimumvereisten voor in beheer name door Exploitant ICT-contract 2015”
3.4.2
Minimumvereisten voor in beheer name door Exploitant ICT-contract 2015
3.4.2.1 Situering en doelstelling Voor toepassingen die in beheer moeten genomen worden door de Exploitant ICT-contract 2015, gelden minimumvereisten voor alle nieuwe of gewijzigde software die in productiebeheer worden genomen. De minimumvereisten betreffen objectieve eisen inzake essentiële aspecten waaraan de software moet voldoen om op een efficiënte en degelijke wijze in productie gesteld te worden en beheerd te worden door de Exploitant ICT-contract 2015. Zonder de invulling van deze kwaliteitselementen wordt de dienstverlening onmogelijk of trager en duurder. Het betreffen dus vooral criteria met als objectief de installeerbaarheid, de onderhoudbaarheid, de stabiliteit, de veiligheid, de beschikbaarheid en volledigheid van essentiële werkproducten. Deze minimumvereisten om een nieuwe of gewijzigde software in productie te stellen bij de Exploitant ICT-contract 2015 zijn dezelfde voor iedere ontwikkelaar. 3.4.2.2 Beheer De Exploitant ICT-contract 2015 onderhoudt deze minimumvereisten, maar elke wijziging ervan moet goedgekeurd worden door e-IB. De Exploitant ICT-contract 2015 stemt bij de inhoudelijke uitwerking van de minimumvereisten vooraf af met alle ontwikkelteams die actief zijn in het kader van het ICT-contract 2015 en dus in het bijzonder met de ICT-Dienstverleners van deze Overeenkomst, met het oog op een haalbare criteria-set. Deze minimumvereisten zijn onderworpen aan configuratiebeheer. Goedgekeurde versies worden tevens gepubliceerd en beschikbaar gesteld voor gebruik ten behoeve van de Klanten. 3.4.2.3 Gebruik In het kader van verificatie- en validatieprocessen, zal nagegaan worden of de software die aangeleverd wordt, voldoet aan de minimumvereisten. Vastgestelde defecten (afwijkingen) t.o.v. de minimumvereisten worden opgenomen in het defect-tracking systeem. Daarbij wordt eenduidig gerefereerd naar de identificatiesleutel van de betreffende vereiste. 3.4.2.4
Minimumvereisten voor bedrijfstoepassingen
3.4.2.4.1 Bijzondere aandachtspunten inzake de documentatie set en de aanlevering Volgende (sets van) documenten moeten worden aangeleverd m.b.t. een toepassing:
Installatiedossier
Exploitatiedossier
Helpdeskdossier
Ontwikkelingsdossier, met o.a. analyses en design-documentatie, architectuur van de applicatie: beschrijving en tekening. Ook te vermelden is de veiligheidsclassificatie. In het bijzonder moet de Pagina 7 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen gevoeligheid expliciet worden aangegeven, en daarbij onder meer of er privacy gevoelige informatie aanwezig is en/of wordt behandeld. Ook volgende (sets van) documenten dienen expliciet onderscheiden en aangeleverd te worden, in functie van een vlot lopend verificatieproces:
Testdossier (testplan, testspecificaties, performantietesten, conformiteit met veiligheidsvereisten, ...)
Codekwaliteitsrapport Codekwaliteit dient te worden afgetoetst t.o.v. te vermelden referenties. Voor Java is dit o.a.:
-
Java code conventions: http://www.oracle.com/technetwork/java/codeconv-138413.html
-
Sonar rapport (http://www.sonarsource.org/)
Projectinformatie van het ontwikkelingsteam
De toepassing zelf (o.a. de broncode) moet worden aangeleverd in een gestandaardiseerde vorm en structuur. Een toepassingsbundel wordt verwacht als een ‘baseline’ te worden aangeleverd in een vorm die toelaat om dit onmiddellijk en eenvoudig op te laden in een code repository (DML) van de Exploitant ICT-contract 2015. 3.4.2.4.2 Lijst van minimumvereisten In de 1e kolom staat het identificatienummer van de vereiste; in kolom 2 staat de minimale vereisten waaraan moet voldaan worden:
Pagina 8 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen
1 Installatiedossier 1.1.1
Bevat benodigde gegevens, scripts, files, parameters voor de doelomgeving (productie en/of acceptatie)
1.1.2
Bevat detailinstructies om de installatie te kunnen uitvoeren
1.2
Bevat een beschrijving van hoe een upgrade van een of meerdere van de modules geïnstalleerd moet worden
1.3
Bevat instructies om de installatie ongedaan te kunnen maken in geval van problemen (roll-back procedure). Bevat een script voor het starten en stoppen van de applicatie
1.4
Bevat benodigde gegevens i.v.m. product releases & upgrades
1.5
Is in het Nederlands of het Engels opgemaakt
2 exploitatiedossier 2.1.1
Bevat alle technische informatie m.b.t. hardware, software en licenties om de gepaste infrastructuur te kunnen opzetten
2.1.2
Bevat beschrijving van de minimale systeemvereisten
2.2.1
Bevat overzicht van de beveiligingsinstellingen en autorisaties (toegangs– en gegevensbeveiliging)
2.2.2
Bevat een beschrijving van de toegangscontroles
2.2.3
Bevat een eenduidige en concrete beschrijving van de gebruikersidentificatiemechanismen
2.2.4
Bevat een eenduidige en concrete beschrijving van de gebruikersauthenticatiemechanismen
2.2.5
Bevat een eenduidige en concrete beschrijving van de gebruikersautorisatiemechanismen
2.2.6
Bevat een eenduidige en concrete beschrijving van de mechanismen voor beheer
2.3
Bevat de beschrijving van het versiebeheer voor de gebruikte middleware (releaseplanning)
2.4
Bevat de veiligheidsvereisten en de daaraan tegemoetkomende veiligheidsmaatregelen
2.5
Is in het Nederlands of het Engels opgemaakt
2.6
Bevat een beschrijving van supplementaire zaken voor batchverwerking (job-flow met aanduiding van input en output, errorcodes en de daaraan gekoppelde uit te voeren acties, tijdstip en frequentie, andere acties)
2.7
Bevat de eisen met betrekking tot I/O : tijdstip en hoeveelheid (via bestanden, via DB, drukwerk)
2.8
Bevat eventuele bijkomende exploitatieaspecten m.b.t. de backup en recovery van de gebruikte database systemen
2.9
Bevat een lijst van verantwoordelijke contactpersonen bij problemen
2.10.1
Bevat een beschrijving van de technische architectuur van de applicatie (web-, applicatie- en database server(s), redundantie, load balancing, clustering)
2.10.2
Bevat een vereenvoudigde technische beschrijving
2.11
Bevat een beschrijving van het veiligheidsniveau (graad van vertrouwelijkheid, integriteit en beschikbaarheid) en in het bijzonder van het feit of er al dan niet persoonsgegevens aanwezig zijn en welke de hiervoor genomen extra controlemaatregelen zijn
2.12
Bevat informatie m.b.t. de vereiste capaciteit en de te verwachten groei
Pagina 9 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen 2.13.1
Bevat een beschrijving van de periodiek uit te voeren controles (oa. output controles, logfiles)
2.13.2
Bevat een beschrijving van de routinematig herhaaldelijk uit te voeren taken met betrekking tot onderhoud en productie gerelateerde zaken
2.14
Bevat back-up procedures
2.15.1
Bevat een lijst van mogelijke foutboodschappen en de bijbehorende acties
2.15.2
Bevat FAQ-lijsten
2.16
Er is een topologietekening in Visio of in bitmap (JPG) van de betrokken infrastructuurcomponenten.
2.17
Bevat een opsomming van alle bibliotheken die door de toepassing gebruikt worden
2.18
Bevat een inventaris van gebruikers en hun gebruikersprofielen
2.19
Bevat een beschrijving van de gegevensuitwisselingen met andere systemen (input- en output)
2.20
Bevat informatie m.b.t. de vereiste performantie
2.21
Bevat de Service afspraken
2.22
Bevat de release planning
2.23
Bevat een risicoanalyse in verband met de uitbating
2.24
Bevat recovery procedures
2.25.1
Bevat escalatieprocedure
2.25.2
Bevat een calamiteitenplan (indien van toepassing)
3 ontwikkeldossier 3.1
Bevat een beschrijving van het netwerk (gelijktijdig actieve netwerkverbindingen, maximale - en gemiddelde transfersnelheid op het netwerk in kbps)
3.2
Bevat een lijst van de te contacteren personen
3.3
Bevat een beschrijving van de toepassing
3.4.1
Bevat een beschrijving van de applicatiearchitectuur
3.4.2
Bevat een beschrijving van de fysische implementatie van de interfaces
3.4.3
Is in het Nederlands of het Engels opgemaakt
3.4.4
Bevat een beschrijving van de data-architectuur (incl. datamodel)
3.4.5
Bevat een beschrijving van de technische architectuur
3.4.6
Bevat een beschrijving van de beveiliging
3.4.7
Bevat een beschrijving van de rollen en verantwoordelijkheden
3.5
Volledige en consistente beschrijving van de ontwikkelingsomgeving (inclusief alle benodigde tools en licenties); dient ter beschikking te staan van de ICT-Dienstverlener en ondersteund te worden door de leverancier ervan
3.6.1
Bevat een beschrijving van de klantvereisten
3.6.2
Bevat een functioneel ontwerp (met context diagram (alle logische interfaces – datastromen in en uit); use cases,
Pagina 10 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen workflow diagrammen, klassediagram of entity relationship diagram, …) 3.7.1
Bevat een beschrijving van de applicatiearchitectuur (gebruikte software componenten), bij voorkeur grafisch voorgesteld
3.7.2
De code is volgens geldende standaarden vastgelegd in het gebruikte source control systeem
3.7.3
De code is voorzien van in-line commentaar.
3.7.4
Bevat een beschrijving van de hardware die nodig is voor de ontwikkelingsomgeving
3.7.5
Bevat een beschrijving van de ontwikkelingssoftware, tools, compilers en de benodigde licenties
3.7.6
Bevat de instructies om de ontwikkelingsomgeving in te richten
4 testdossier 4.1.1
Er zijn testscripts (bij voorkeur geautomatiseerde testen) voor de systeemtesten
4.1.2
Er zijn test-data voor het uitvoeren van de interface testen
4.2
Security testen (minstens een kwetsbaarheidstest voor toepassingen ontsloten naar het internet)
4.3.1
Er zijn testrapporten (resultaten van een set van testen (vb. test-run) zowel voor functionele als niet functionele testen)
4.3.2
Er zijn foutrapporten (met overzicht van de fouten die niet opgelost werden)
4.4
Er zijn testplannen voor het testproces van ontwikkeling (doel, strategie, resources, deliverables, milestones)
4.5
Er zijn test scenario’s (functionele testen) (met beschrijving van gebruikte test-data; input en output; doelstelling van de betreffende test; beschrijving van wat er juist getest wordt; in- en uitvoergegevens; wat gedaan moet worden en wanneer; verwacht resultaat)
5 Helpdeskdossier 5.5.1
Bevat instructies voor de afhandeling van incidenten in de 1e lijn (troubleshooting script, communicatieplan voor communicatie naar 2e lijns-ondersteuning)
5.5.2
Bevat telefoonnummer en emailadres van de eerstelijnsondersteuning, benamingen voor de bedrijfstoepassingen, korte functionele beschrijving
6 Project 6.1
Bevat een lijst van contactpersonen (naam en contactgegevens) bij de leverancier, de klant, de beheergroep
6.2
Bevat een beschrijving van de bestaansreden van de bedrijfstoepassing (functionele doelstelling en kritieke functies)
6.3
Bevat documentatie over de bedrijfstoepassing (benamingen, korte functionele beschrijving, kritieke tijdstippen, beschrijving van de gebruikersgroep)
6.4
Bevat een hoog-niveau overzicht van de bij aanvang gespecificeerde klantvereisten (zowel functionele als nietfunctionele).
Pagina 11 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen
4 Overige Ondersteunende processen 4.1 Offertebeheer Het doel van dit proces is om op vraag van de Klanten en binnen het kader van deze Overeenkomst een goede prijs/kwaliteit offerte op te stellen die een antwoord biedt aan de door de Klant vooropgestelde functionele en niet-functionele vereisten. Het afleveren van goede prijs/kwaliteit-offertes moet blijken uit het binnen halen van een voldoende groot percentage van de bestelde Projecten. Indien dit niet het geval is, zal de ICT-Dienstverlener in overleg met e-IB een verbeteractie opstarten om dit bij te sturen. De Mini-competitie moet immers effectief blijven. De Projectvoorstellen worden door de Klant gelijktijdig aan de verschillende ICT-Dienstverleners gevraagd volgens de in de Service Portfolio beschreven procedure voor Mini-competitie. Daarnaast kan het ondersteunend proces “offertebeheer” ook betrokken zijn bij het behandelen van wijzigingen aan een reeds besteld Project (zie Service Portfolio) Om de overkoepelende kwaliteitsbewaking vanuit e-IB mogelijk te maken dienen de door de Klant ingediende Werkaanvragen en de aan de Klant bezorgde Projectvoorstellen (en eventuele latere wijzigingen hieraan) opgeslagen te worden op een ook voor e-IB toegankelijke locatie en dienen minstens de volgende gegevens dagelijks aangeleverd te worden voor opnamen in DDC-DWH: Een overzicht van alle door de Klanten aangevraagde en aan de Klanten bezorgde Projectvoorstellen met de volgende informatie: o Identificatienummer Werkaanvraag o Identificatie van de Klant (entiteitscode) o Datum aanvraag door de Klant o Datum aanlevering Projectvoorstel aan de Klant o Werd het Projectvoorstel door de Klant als de economisch meest voordelige beschouwd? o Indien ja, werd het Project vervolgens ook besteld? o Datum van de bestelling o Bedrag (incl BTW) van de bestelling (geraamd bedrag in het geval van middelenverbintenis)
4.2 Problem management Het betreft hier het proces “Problem management” zoals beschreven in ITIL V3 2011 Service Operation en het proces “Causal Analysis and Resolution (CAR)” uit CMMI-DEV. . Het Problem management proces is verantwoordelijk voor het beheren van de levenscyclus van alle problemen m.b.t. de ICT-Dienstverlening. Hierbij kan een onderscheid gemaakt worden tussen enerzijds de Problemen die betrekking hebben op de ontwikkeling in het kader van het uitvoeren van de projecten zelf en de Problemen die zich na in productie stelling van nieuwe of gewijzigde software zouden kunnen voordoen. 4.2.1
Problemen tijdens ontwikkeling
Voor de Problemen die zich voordoen tijdens de ontwikkeling zelf, staat de ICT-Dienstverlener volledig zelf in voor het identificeren, analyseren en oplossen van het probleem. De ICT-Dienstverlener rapporteert over volgende indicatoren m.b.t. de Problemen die zich voordoen tijdens de ontwikkeling door de ICT-Dienstverlener: o
De gemiddelde tijdsduur tussen het registreren van het Probleem en het vaststellen van de grondoorzaak (“root cause”);
o
De gemiddelde tijdsduur tussen het vaststellen van de grondoorzaak en het volledig oplossen en afsluiten van het Probleem;
o
De gemiddelde doorlooptijd van de open Problemen;
Pagina 12 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen Volgende rapporteringsgegevens worden dagelijks aangeleverd en ter beschikking gesteld in het DDC-DWH: o 4.2.2
Een overzicht van de open Problemen met hun startdatum, status en (korte) omschrijving van de grondoorzaak (“root cause”) van zodra die gekend is.
Problemen met de ontwikkelde toepassing in productie
Voor de Problemen die zich voordoen in productie, t.t.z. na in beheer name van de bedrijfstoepassing door een Exploitant, is in eerste instantie de Exploitant verantwoordelijk, maar hij moet hierbij een beroep kunnen doen op de ICT-Dienstverlener (als onderaannemer voor de Exploitant) indien blijkt dat het probleem te wijten is aan een fout in de aangeleverde bedrijfstoepassing. Deze fouten worden door de ICT-Dienstverlener geregistreerd in zijn “defect-tracking systeem” Tijdens de waarborgperiode van de betrokken (versie van de) bedrijfstoepassing is deze ondersteuning gratis. Nadien wordt deze ondersteuning verrekend op basis van Profieluurprijzen. De problemen die optreden in productie en die opgelost moeten worden door de ontwikkelaar in kader van waarborg, worden geregistreerd en opgevolgd in een geëigend systeem, zichtbaar voor de betrokken Klant en voor e-IB. Er is tevens een algemene rapportering over alle problemen en hun afhandelingsstatus en –termijn, over de toepassingen in waarborg. Van de ICT Dienstverlener wordt verwacht dat hij de nodige procesmatige afspraken maakt met de Exploitant, teneinde onverwijld op de hoogte te zijn van issues, incidenten of problemen die optreden met door hem ontwikkelde toepassingen. En ook om bij de afhandeling, opvolging en oplossing ervan efficiënt en gepast samen te werken met de Exploitant. Ook de klant (toepassingseigenaar) zal het proces minstens kunnen opvolgen. Daartoe zorgt de ICT Dienstverlener voor de nodige proces- en afsprakendocumentatie inzake de afhandeling van incidenten en problemen tijdens de waarborgperiode, en neemt dit op in de toepassingsdocumentatie.
4.3 Configuratiebeheer Dit luik is gebaseerd op het ‘Service Asset and Configuration Management ’ uit ITIL V3 2011 Service Transition en op “Configuration Management (CM)” uit CMMI-DEV. Alle Werkproducten die gecreëerd worden in het kader van het Project moeten onder configuratiebeheer geplaatst worden. Dit omvat minstens de Werkproducten die moeten aangeleverd worden om de ontwikkelde (versie van de) bedrijfstoepassing in beheer te kunnen laten nemen door de Exploitant ICT-contract 2015 (zie “3.4.2 Minimumvereisten voor in beheer name door Exploitant ICT-contract 2015”). De ICT-Dienstverlener dient in het bijzonder te zorgen voor een goed configuratiebeheer van alle onderdelen van de te ontwikkelen software en van de bijbehorende documentatie (incl. test-scripts) en dit voor de volledige duur van het Project. Hiervoor dienen Ondersteunende Systemen ingezet te worden die toegankelijk zijn voor de betrokken Klant(en) en voor e-IB. Deze informatie moet in een voor de Klanten (voor hun eigen Projecten) en e-IB (voor alle Projecten) online toegankelijke beheeromgeving opgenomen worden.
4.4
“Decision Analysis and Resolution (DAR)”
Dit is een Ondersteunend proces dat er moet voor zorgen dat beslissingen en keuzes genomen worden op basis van een proces waarbij mogelijke alternatieven onderzocht worden en geëvalueerd worden o.b.v. afgesproken criteria. Zie proces “Decision Analysis and Resolution (DAR)” in CMMI-DEV.
4.5
“Measurement and Analysis (MA)”
Dit is een Ondersteunend proces dat er moet voor zorgen dat de dienstverleningsprocessen afdoende gemeten worden zodat de nodige analyses kunnen gemaakt worden en de goede werking van de processen kan bewaakt worden. Pagina 13 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen Zie proces “Measurement and Analysis (MA)” in CMMI-DEV.
4.6 Kwaliteitsbeheer Het kwaliteitsbeheer komt overeen met het proces “Process and Product Quality Assurance (PPQA)” uit CMMI-DEV. M.b.t. het bewaken van de kwaliteit van de ICT-Dienstverlening dient een onderscheid gemaakt te worden tussen enerzijds het bewaken van de kwaliteit van de uitgevoerde processen en anderzijds het bewaken van de kwaliteit van de geleverde Werkproducten. De kwaliteit van de geleverde Werkproducten is in eerste instantie de verantwoordelijkheid van de ICT-Dienstverlener, maar wordt gecontroleerd door de Klanten aan wie die Werkproducten geleverd worden. De ICT-Dienstverlener dient er in het bijzonder voor te zorgen dat de ontwikkelde software kwaliteitsvol is op de volgende vlakken:
conform aan de functionele en niet-functionele vereisten van de Klant;
gemakkelijk onderhoudbaar
performant
veilig
De ICT-Dienstverlener maakt hiervoor maximaal gebruik van Ondersteunende Systemen die toelaten om de kwaliteit op een systematische wijze te bewaken. Het verzekeren van de kwaliteit van de uitgevoerde processen is ook in eerste instantie de verantwoordelijkheid van de ICT-Dienstverlener, maar wordt gecontroleerd door de e-IB. e-IB maakt hiervoor gebruik van alle beschikbare informatie (rapporten, metrieken, rechtstreekse toegang tot ondersteunende systemen, klachten en opmerkingen van Klanten, …). In het kader van deze kwaliteitscontroles moet e-IB ook toegang hebben tot alle informatie (o.a. Werkproducten) die ter beschikking gesteld wordt van de Klanten in het kader van individuele Projecten. Volgende activiteiten in het kader van kwaliteitsbeheer (op procesniveau) zullen door e-IB uitgevoerd worden:
Het plannen van de kwaliteitscontroles en het bepalen van het controlegebied en de kwaliteitscriteria;
Het uitvoeren van de kwaliteitscontroles en het registreren van de vaststellingen;
Het rapporteren van de conclusies van de kwaliteitscontroles, en in gezamenlijk voorafgaandelijk overleg het bepalen van de acties die moeten genomen worden om de dienstverlening bij te sturen of te verbeteren.
De ICT-Dienstverlener voorziet voor wat betreft de kwaliteitsbewaking op procesniveau de resources nodig voor o.a. volgende activiteiten:
De toewijzing en opvolging tot afsluiten van de Correctieve acties die voortvloeien uit de kwaliteitscontroles van e-IB, en die in gezamenlijk voorafgaandelijk overleg bepaald werden;
Deelnemen aan het Overleg ICT-Dienstverlening met e-IB.
4.7 Klachtenbeheer Er wordt algemeen aanvaard dat een effectieve klachtenbehandeling een belangrijk instrument is in het kader van integrale kwaliteitszorg. Een effectieve klachtenbehandeling heeft zowel een preventief effect (de diensten passen zich aan om “Klachten te voorkomen”) alsook een leereffect. Door het analyseren van de Klachten krijgt men immers veel informatie over de gewenste verbeteringen van de ICT-Dienstverlening. Met betrekking tot het klachtenmanagement zal de opvolging en coördinatie aangestuurd worden van de e-IB relatiebeheerders. De ICT-Dienstverlener heeft een heel belangrijke rol in de uitvoering van het klachtenmanagement proces. Pagina 14 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen Het klachtenmanagement van de ICT-Dienstverlener is een onderdeel van het klachtenmanagement bij e-IB. De ICT-Dienstverlener ondersteunt de e-IB m.b.t. Klachten te wijten aan de door de ICTDienstverlener geleverde dienstverlening. Een Klacht is een expliciete, melding van een niet naar wens verlopende ICT-Dienstverlening. De Klant kan een Klacht indienen wanneer hij oordeelt dat de ICT-Dienstverlening structureel niet naar wens verloopt. Via de klachtenafhandeling wordt nagekeken of er geen haperingen zijn in het operationeel proces die moeten opgelost worden en of er geen structurele wijzigingen nodig zijn in het proces of het dienstverleningsaanbod. Een “effectief klachtenbeheer” kan gedefinieerd worden als “het op een systematische en gestructureerde manier erkennen, herkennen en afhandelen van Klachten op een zodanige wijze dat zowel de Klant als de ICT-Dienstverlener hier maximaal rendement van hebben”. Belangrijke voorwaarde voor “effectief klachtenbeheer” is dat de bedrijfscultuur van de “lerende organisatie” moet heersen bij de ICT-Dienstverlener waar bij fouten niet naar een schuldige gezocht wordt maar naar een oplossing. Enkel dan kunnen Klachten constructief aangewend worden.
4.8 Contractbeheer De hoofdverantwoordelijkheid met betrekking tot het contractbeheer, ligt bij de e-IB. Het contractbeheer heeft betrekking op :
het opstellen, opvolgen en bijsturen van de contractuele documenten die deel uitmaken van de Overeenkomst afgestemd op de gemeenschappelijke behoeften van de (potentiele) Klanten zoals gedetecteerd via Relatiebeheer;
Verlenen van advies m.b.t. de interpretatie van de bepalingen van de Overeenkomst;
De modaliteiten voor het wijzigen van de contractuele documenten zijn beschreven in het Basiscontract. De ICT-Dienstverlener voorziet hierbij een aanspreekpunt voor de Contractbeheerder en ondersteuning bij de uitvoering van de processen rond contractbeheer.
4.9 Relatiebeheer Dit luik is gebaseerd op het ‘Business relationship management’ uit ITIL V3 2011 Service Strategy. Het proces dat verantwoordelijk is voor het onderhouden van een positieve relatie met klanten. Relatiebeheer identificeert de gemeenschappelijke behoeften van de (potentiële) klanten op het niveau van de raamovereenkomst als geheel. Het doel van het proces “Relatiebeheer” is om een vinger aan de pols te houden binnen de organisatie van de Klanten teneinde optimaal te kunnen inspelen op de evoluerende ICT-noden, een ondersteuning te bieden bij het optimaal invullen van hun business behoeften, de vlotte uitvoering of de juiste prioriteitstelling van de uitvoering te garanderen. Als onderdeel hiervan kan e-IB ook onafhankelijke klantentevredenheidsonderzoeken laten uitvoeren. De hoofdverantwoordelijkheid met betrekking tot het Relatiebeheer, ligt bij de e-IB die het overzicht behoudt over de verschillende diensten (en contracten) van e-IB. De ICT-Dienstverlener is verantwoordelijk voor operationele vragen, offertes leveren en dergelijke. De ICT-Dienstverlener voorziet hierbij een aanspreekpunt voor het Relatiebeheer en ondersteuning bij de uitvoering van de processen rond Relatiebeheer. De ICT-dienstverlener is verantwoordelijk voor alle “pre-sales” / ”sales” en “after-sales”-activiteiten ten behoeve van de individuele Klanten of potentiële Klanten. Hierbij moet ook rekening gehouden worden met het feit dat ook de lokale besturen deel uitmaken van de doelgroep. Ook de opvolging van de klantentevredenheid op het niveau van individuele Projecten is de verantwoordelijkheid van de ICT-Dienstverlener.
Pagina 15 van 16 Versie: 19/12/2013
ICT Contract 2015 Raamovereenkomst Ontwikkelingsprojecten Vereisten Ondersteunende processen
4.10 Toegangsbeheer Het betreft hier het “Access management proces” zoals beschreven in ITIL V3 2011 Service Operation. Toegangsbeheer is het proces dat verantwoordelijk is voor het toegankelijk maken van toepassingen, gegevens, of andere bedrijfsmiddelen voor gebruikers. Het betreft hier in het bijzonder de ontwikkelings- en testomgevingen van de ICT-Dienstverlener alsook de omgevingen die gebruikt worden voor het configuratiebeheer van de broncode, testscripts, test-date, …. Toegangsbeheer helpt de vertrouwelijkheid, integriteit en beschikbaarheid van bedrijfsmiddelen te beschermen door te garanderen dat alleen geautoriseerde gebruikers ze kunnen bekijken of veranderen. Toegangsbeheer implementeert het beleid m.b.t. het beveiligen van informatie. Binnen het Toegangsbeheer wordt de autorisatie van gebruikers om toepassingen en data te gebruiken geregeld en worden ook de nodige maatregelen genomen om te verhinderen dat nietgeautoriseerde gebruikers Diensten en data kunnen benaderen. De ICT-Dienstverleners maken hiervoor maximaal gebruik van authentieke gegevensbronnen voor zover beschikbaar. Hierbij dient ook rekening gehouden te worden dat ook de lokale besturen deel uit maken van de doelgroep. Binnen het Toegangsbeheer worden van de ICT-Dienstverlener volgende activiteiten verwacht:
Behandelen van vragen voor toegang tot systemen en data;
De verificatie van de vragen voor toegang waarbij wordt nagegaan of de persoon die de vraag stelt wel degelijk de persoon is waarvoor hij/zij zicht uitgeeft en / of de gevraagde toegang wel mag gegeven worden aan de betrokken persoon;
Pagina 16 van 16 Versie: 19/12/2013