010

Vlaamse Overheid

Departement Leefmilieu, Natuur en Energie Koning Albert II-laan 20 bus 8 1000 Brussel

Bestek nr.: MMIS/2007/SDB/010

ALGEMENE OFFERTEAANVRAAG VOOR DE LEVERING VAN DIENSTEN met betrekking tot de ontwikkeling van een gebruikersbeheer toepassing.

INHOUDSTAFEL: Deel 1: Administratieve en contractuele bepalingen................................................... 3 1.1 Identificatie van de opdracht ....................................................................................... 3 1.1.1 Aanbestedende overheid – Leidende dienst – Leidend ambtenaar.............. 3 1.1.2 Aard van de opdracht:........................................................................................... 3 1.1.3 Gunningwijze.......................................................................................................... 3 1.1.4 Voorwerp van de opdracht ................................................................................... 3 1.1.5 Duur van de opdracht. .......................................................................................... 3 1.1.6 Ontvangst van de offertes .................................................................................... 4 1.2 Bepalingen die de uitvoering van de opdracht regelen .......................................... 4 1.3 Offertes ........................................................................................................................... 4 1.3.1 Opstellen van de offertes ..................................................................................... 4 1.3.2 Taal van de offerte................................................................................................. 5 1.3.3 Indienen van de offerte ......................................................................................... 5 1.3.4 Gestanddoeningstermijn....................................................................................... 6 1.3.5 Vrije varianten ........................................................................................................ 6 1.3.6 Formuleren van de prijzen ................................................................................... 6 1.4 Gunning van de opdracht ............................................................................................ 6 1.4.1 Kwalitatieve selectie.............................................................................................. 6 1.4.2 Regelmatigheid van de offertes........................................................................... 7 1.4.3 Technische bekwaamheid.................................................................................... 7 1.4.4 Gunningscriteria..................................................................................................... 7 1.5. Opvolging van de uitvoering van de opdracht......................................................... 7 1.5.1 Plaats van tewerkstelling...................................................................................... 7 1.5.2 Borgtocht................................................................................................................. 8 1.5.3 Onderaannemers................................................................................................... 8 1.5.4 Oplevering............................................................................................................... 8 1.5.5 Betalingsmodaliteiten............................................................................................ 9 1.5.6 Veiligheid en vertrouwelijkheid ............................................................................ 9 Deel 2: Technische bepalingen ....................................................................................... 10 2.1 Inleiding ........................................................................................................................ 10 2.2 Functionele omschrijving van de toepassing.......................................................... 10 2.2.1 Profiel 1: ................................................................................................................ 10 2.2.2 Profiel 2: ................................................................................................................ 12 2.2.3 Profiel 3: ................................................................................................................ 12 2.3 Lijsten beheer .............................................................................................................. 12 2.4 Technische randvoorwaarden................................................................................... 13 BIJLAGE 1 : MODEL VAN INDIENING (inschrijvingsformulier) .............................. 16 BIJLAGE 2: INVENTARIS................................................................................................... 18

2

Deel 1: Administratieve en contractuele bepalingen 1.1 Identificatie van de opdracht 1.1.1 Aanbestedende overheid – Leidende dienst – Leidend ambtenaar 1.1.1.1 Aanbestedende overheid Vlaamse Overheid Departement Leefmilieu, Natuur en Energie Afdeling Centraal Databeheer Koning Albert II-laan 20 bus 8 1000 Brussel De aanbestedende overheid is verantwoordelijk voor de gunningprocedure voor deze opdracht. 1.1.1.2 Leidend ambtenaar Leidend ambtenaar: Dirk Vyverman Contactpersoon: Steven De Bock (tel.: 02/5531153) [email protected] De leidende ambtenaar is verantwoordelijk voor de uitvoering van deze opdracht. 1.1.2 Aard van de opdracht: Opdracht van diensten 1.1.3 Gunningwijze. Deze opdracht van diensten wordt gegund bij wijze van algemene offertevraag. De aanbestedende overheid behoudt zich het recht voor om de opdracht niet of niet in zijn geheel te gunnen, zonder dat de aannemer aanspraak kan maken op enig schadevergoeding. 1.1.4 Voorwerp van de opdracht Voorwerp van deze opdracht is de ontwikkeling van een webgebaseerd registratieen gebruikersbeheer toepassing met delegatievoorzieningen, die localiseerbaar is voor de verschillende eigen ontwikkelde toepassingen, waarvan de gegevens worden opgeslagen in een sun one directory server (5.2). 1.1.5 Duur van de opdracht. Uitvoering binnen de 6 maanden vanaf datum van toewijzing, timing verder te bepalen na onderhandeling.

3

1.1.6 Ontvangst van de offertes De offerte en de bijhorende documenten worden onder dubbele omslag gericht aan dhr. Steven De Bock op het adres: Vlaamse overheid Departement Leefmilieu, Natuur en Energie Afdeling Centraal Databeheer T.a.v.: Steven De Bock Koning Albert II-laan 20 bus 8 1000 Brussel en dit vóór de opening van de offertes op de vastgestelde datum en het vastgestelde uur. 1.2 Bepalingen die de uitvoering van de opdracht regelen De opdracht is onderworpen aan de reglementering betreffende overheidsopdrachten voor zover deze niet wordt gewijzigd door de hierna vermelde bijzondere aannemingsvoorwaarden van het bestek. Reglementering - Wet van 24 december 1993 (B.S. van 22.1.1994 en errata in B.S. van 25.2.1997) betreffende de overheidsopdrachten en sommige opdrachten voor de aanneming van werken, leveringen en diensten. - Koninklijk besluit van 8 januari 1996 (B.S. van 26.1.1996 en errata in B.S. van 25.2.1997) betreffende de overheidsopdrachten voor de aanneming van werken, leveringen en diensten en de concessies voor openbare werken. - Koninklijk besluit van 26 september 1996 (B.S van 18.10.1996) tot de bepaling van de algemene uitvoeringsregels van de overheidsopdrachten en van de concessies voor openbare werken. - De bijlage bij het voorgaand Koninklijk besluit van 26 september 1996, de zogenaamde Algemene Aannemingsvoorwaarden. - Alle wijzigingen aan de wet en de voornoemde besluiten, die van kracht zijn de dag van de opening van de offertes Documenten eigen aan de opdracht - Het bestek; - de offerte van de inschrijver met inventaris 1.3 Offertes 1.3.1 Opstellen van de offertes 1.3.1.1 Inhoud van de offerte De inschrijvers stellen hun offertes op volgens het model bijgevoegd in bijlage 1 van het bestek. De documenten gevraagd door het bestek moeten aan de offerte toegevoegd (KB,

4

Art. 90 § 2), aangevuld, gedateerd en ondertekend worden door de aannemer. De inschrijver moet de structuur voor de voorstelling van zijn offerte zoals opgelegd door de Vlaamse overheid volgen. De offerte van de inschrijver moet worden opgemaakt in twee delen: Deel 1: administratief gedeelte - inschrijvingsformulier (bijlage 1) Deel 2: financieel gedeelte - antwoorden op de kostprijs van het voorstel: detailleer en vat de kostprijs samen (bijlage 2 - inventaris) 1.3.1.2 Verbintenissen van de partijen Door het indienen van zijn offerte verzaakt de inschrijver automatisch aan zijn algemene of bijzondere verkoopsvoorwaarden, zelfs wanneer deze op een of andere bijlage van zijn offerte voorkomen. De inschrijvers zijn verplicht zich uitdrukkelijk aan alle administratieve en contractuele bepalingen van het bestek te houden. Elk voorbehoud of het afwijzen van één van deze bepalingen kan de onregelmatigheid van de offerte tot gevolg hebben. 1.3.2 Taal van de offerte De offerte moet verplicht in het Nederlands. 1.3.3 Indienen van de offerte De offerte zal in twee exemplaren worden ingediend, waarvan één origineel. De offerte wordt geschoven in een “definitief” gesloten omslag waarop zijn vermeld: de datum van de zitting waarop de offertes worden geopend, de verwijzing naar het bestek. Bij inzending per post, wordt die omslag geschoven in een tweede omslag met opgave van het adres van het bestuur en met de vermelding “offerte”. De offerte dient verstuurd aan: Vlaamse Overheid Departement Leefmilieu, Natuur en Energie Afdeling Centraal Databeheer T.a.v.: Steven De Bock Koning Albert II-laan 20 bus 8 1000 Brussel De inschrijving dient verplicht te gebeuren met het bij het bestek horende inschrijvingsformulier. De inschrijving dient duidelijk naam, datum, hoedanigheid en handtekening te bevatten van de inschrijver.

5

Plaats en dag van de opening der offertes: (art. 2 KB 26.09.1996) De opening der offertes zal plaats hebben op donderdag 31 januari om 11u in lokaal 2P20 van het Ferrarisgebouw, Koning Albert II-laan 20 bus 8 1000 Brussel. Alle, buiten de termijn ingediende offertes, worden uitgesloten. 1.3.4 Gestanddoeningstermijn De gestanddoeningstermijn van de offerte mag niet minder zijn dan 90 dagen. Deze termijn vangt aan op de uiterste datum die voor het indienen van de offerte werd bepaald. 1.3.5 Vrije varianten Varianten zijn niet toegelaten. 1.3.6 Formuleren van de prijzen 1.3.6.1 Voorstelling van de prijzen De inventaris is de getrouwe weergave, post per post, van de hoeveelheden die nodig zijn om het project tot stand te brengen. 1.3.6.2 Prijsbepaling De opdracht is een opdracht tegen een globale prijs ; een forfaitaire prijs dekt het geheel van de prestaties. 1.3.6.3 Clausules van prijsherziening Alle prijzen mogen naar beneden toe herzien worden, in functie van de evolutie van de markt. 1.4 Gunning van de opdracht De opdracht kan maar worden gegund na een evaluatie van de offertes, bestaande uit verschillende stappen: 1. De aanbestedende overheid onderzoekt de bekwaamheid van de inschrijvers in overeenstemming met de kwalitatieve selectieregel. 2. De aanbestedende overheid gaat de regelmatigheid van de offertes na. 3. De opdracht wordt gegund op basis van de regelmatige offerte die het interessantst bevonden is. 1.4.1 Kwalitatieve selectie De aanbestedende overheid verricht de kwalitatieve selectie van de inschrijvers (KB 8 januari 1996, Art 110 §1).

6

De kwalitatieve selectie van de inschrijvers gebeurt volgens de artikelen 68 tot 74 van het KB van 8 januari 1996 houdende de overheidsopdrachten voor aanneming van werken, leveringen en diensten en de concessies van openbare werken. 1.4.1.1 Regelmatigheid van de toestand van de inschrijvers - uitsluitingscriteria Voor de Belgische inschrijver vraagt de aanbestedende overheid het RSZ-attest via elektronische weg op conform art. 72, §5. De buitenlandse inschrijver voegt bij zijn offerte een attest of een verklaring volgens de bepalingen van art. 69bis, §2. 1.4.2 Regelmatigheid van de offertes De offertes van de geselecteerde kandidaten zullen onderzocht worden naar regelmatigheid volgens de artikelen 89 en volgende van het Koninklijk Besluit van 8 januari 1996 en de bepalingen van het bestek. Elk financieel voorstel of kostprijs die onvolledig is, tegenstrijdigheden of significant onjuistheden bevat of die de in het bestek vermelde vereisten op het vlak van kostprijs niet respecteert, kan onregelmatig worden verklaard. 1.4.3 Technische bekwaamheid Er wordt de inschrijver gevraagd zijn technische bekwaamheid te bewijzen door bij zijn offerte de volgende informatie te voegen: een lijst van de voornaamste diensten die hij gedurende de afgelopen drie jaar heeft verricht, hun bedrag, data en de publiek- of privaatrechtelijke instanties waarvoor zij bestemd waren. 1.4.4 Gunningscriteria De gunning van de opdracht zal gebeuren op basis van de regelmatige offerte die de aanbestedende overheid het voordeligst lijkt en rekening houdend met de volgende criteria: • •

Prijs 50% Techniek 50%, de technische waarde zal gebaseerd zijn op de technische specificaties van het bestek

1.5. Opvolging van de uitvoering van de opdracht 1.5.1 Plaats van tewerkstelling Werkzaamheden op de infrastructuur van het Bestuur moeten steeds in de kantoren van het Bestuur doorgaan in aanwezigheid van één van de systeembeheerders. Hiervoor wordt minimaal één dag op voorhand een afspraak gemaakt met de betrokken systeembeheerder. Toegang van op afstand (SSH login access) is niet toegelaten zonder voorafgaandelijk akkoord van de systeembeheerder. Bij overtreding hierop heeft het Bestuur het recht over te gaan tot het in gebreke stellen van de dienstverlener zoals bepaald in artikel 22.

7

1.5.2 Borgtocht Artikel 5 van de Algemene Aannemingsvoorwaarden wordt aangevuld met de volgende bepalingen: 1.5.2.1 Bedrag van de borgtocht De borgtocht wordt door de aannemer betaald per opdracht of deelopdracht. Het bestelbedrag van de opdracht of deelopdracht wordt door het opdrachtgevende bestuur berekend op basis van het geraamde aantal mensdagen van de benodigde kwalificatie(s). Het bedrag van de borgtocht wordt vastgesteld op 5 (vijf) % van het bestelbedrag van de toegekende opdracht(en) of deelopdracht(en), afgerond naar het hogere tiental. 1.5.2.2 Bewijs van borgstelling Het bewijs van borgstelling dient binnen de 30 dagen na de bestelling van de opdracht(en) of deelopdracht(en) overgemaakt te worden aan het opdrachtgevende bestuur. Als bewijs geldt hetzij het ontvangstbewijs van de Deposito en Consignatiekas of het debetbericht van het Bestuur der Postchecks, hetzij het depositobericht van de Rijkskassier, hetzij de originele akte van solidaire waarborg of het origineel van de bestemmingsakte geviseerd door de Deposito en Consignatiekas. 1.5.2.3 Vrijgave van borgtocht Het bedrag van de borgtocht zal vrijgegeven worden na de definitieve keuring van de opdracht of de deelopdracht. De aannemer zal het verzoek tot vrijmaking van de borgtocht indienen samen met een kopie van het borgstellingbewijs. 1.5.3 Onderaannemers Het feit dat de aannemer het geheel of een deel zijn verplichtingen aan derden toevertrouwt bevrijdt hem niet van zijn verantwoordelijkheid jegens de Administratie. Deze erkent geen enkele contractuele band met deze derden (A.A.V, art. 10). Wanneer de inschrijver een deel van de prestaties van de opdracht toekent aan derde,, dient hun naam vermeld te worden in de offerte. De inschrijver geeft aan voor welke prestatie de onderaannemer tussenkomt. 1.5.4 Oplevering De oplevering van de opdracht bestaat in de verificatie door de aanbestedende overheid van de conformiteit van de door de aannemer uitgevoerde prestaties volgens de regels van de kunst alsook volgens de clausules en de voorwaarden van de opdracht. De prestaties worden maar opgeleverd nadat ze voldoen aan de verificaties (A.A.V. art.10). Alle kosten verbonden aan de oplevering zijn ten laste van de aannemer.

8

1.5.5 Betalingsmodaliteiten De prestaties van de opdracht zijn te betalen na het vervallen van de termijn (50 kalenderdagen) voor zover de aanbestedende overheid in het bezit is van alle bewijsdocumenten. Voor elk verschuldigd bedrag zal de aannemer een factuur opstellen vergezeld van een PV van oplevering en dit op de datum waarop het bedrag betaalbaar is. De facturen worden toegestuurd naar volgend adres: Vlaamse overheid Departement Leefmilieu, Natuur en Energie Afdeling Centraal Databeheer T.a.v.: Steven De Bock Koning Albert II-laan 20 bus 8 1000 Brussel De betalingen zullen gedaan worden volgens de reglementering op de Rijkscomptabiliteit. 1.5.6 Veiligheid en vertrouwelijkheid De aannemer verbindt zich ertoe om, alle gegevens en informatie, van welke aard dan ook, die hem zullen meegedeeld worden of waarvan hij tijdens zijn taak kennis zal krijgen, vertrouwelijk te houden en dit zowel tijdens als na de uitvoering van de opdracht. De aannemer waarborgt dat zijn personeel en zijn onderaannemers de vertrouwelijkheid van de gegevens eerbiedigen. Hij zal aan zijn personeelsleden en aan die van zijn onderaannemers die rechtstreeks bij de opdracht zijn betrokken zijn slechts die gegevens bekend maken die noodzakelijk zijn voor de uitvoering opdracht. Alle inlichtingen die aan het personeel van de aannemer worden verstrekt, alle documenten die hem worden toevertrouwd, alle gesprekken waaraan zij deelnemen, worden als strikt vertrouwelijk beschouwd.

9

Deel 2: Technische bepalingen 2.1 Inleiding Voorwerp van deze opdracht is de ontwikkeling van een webgebaseerd registratieen gebruikersbeheertoepassing met delegatievoorzieningen, die localiseerbaar is voor de verschillende eigen ontwikkelde toepassingen en waarvan de gegevens worden opgeslagen in een sun one directory server (5.2). De toepassing moet de verschillende gebruikers toelaten op een webgebaseerde wijze hun registratie, gebruikersbeheer, groepsbeheer en applicatiebeheer te realiseren. Er zijn 5 rollen binnen deze toepassing : anonieme gebruiker, gewone gebruiker, applicatiebeheerder, groepsbeheerder en superbeheerder. Een gebruiker kan in meerdere rollen zitten. Verder moet het exporteren en importeren van gebruikersdata in ldif en csv formaat via een scheduler mogelijk zijn. In de export moet het mogelijk zijn te kiezen welke delen van de ldap boom en welke attributen en objecten in de export mogen zitten. De toepassing moet modulair opgebouwd zijn zodat later uitbreiding mogelijk is. Belangrijk is dat deze toepassing voor authenticatie/identificatie gebruik maakt van de ACDauthenticatie module gebaseerd op het acegi framework en verweven wordt met de reeds bestaande saml redirector web toepassing Wat lay-out betreft wordt de stijl van www.milieuinfo.be gevolgd en voldoet de toepassing aan de voorwaarde van het toegankelijk web initiatief (http://www2.vlaanderen.be/ned/sites/toegankelijkweb/waarom_toeweb.htm) 2.2 Functionele omschrijving van de toepassing 2.2.1 Profiel 1: Een eindgebruiker wil gebruik maken van toepassing x. Hierbij zijn er 2 mogelijke scenario's. a) Het is een toepassing die werkt met enkel de ACD ldap of databank om authentictie, identificatie en authorisatie af te handelen. b) De toepassing werkt met eID of token voor authentictie, identificatie en met ldap of databank voor de authorisatie af te handelen. In geval a) komt de gebruiker ofwel na een mislukte aanmeldpoging of nadat hij/zij op een link geklikt heeft op een applicatie-specifieke pagina in de nieuwe toepassing terecht. Indien het om een ldap-authenticatie gaat, krijgt de gebruiker de kans om zich te registreren/toegang aan te vragen door zijn/haar mailadres in te vullen en een cijfer/letter combinatie in te vullen dat je afleest van een gifje dat random bij elke request een andere cijfer/letter code genereerd. Het emailadres wordt opgezocht en

10

indien het niet wordt gevonden, moet de gebruiker zich registreren (uid/wachtwoord telefoon zijn standaardvelden). Indien het emailadres gevonden wordt, wordt een wachtwoord-mail met een tijdelijk geldige link (30 minuten), opgestuurd naar het emailadres. Deze link leid je naar een pagina waarop je je wachtwoord kan aanpassen en leid je naar een pagina die je meldt dat je toegangsaanvraag doorgestuurd is naar de applicatiebeheerder (indien je nog geen toegang had). Het moet mogelijk zijn om een verantwoording te vragen voor de reden van toegang. Het moet ook mogelijk zijn om voor een toepassing te bepalen dat geen bijkomende goedkeuring voor toegang noodzakelijk is waardoor een aanvraag ineens resulteert in toegang tot de toepassing. Het moet voor de eindgebruiker duidelijk zijn dat hij/zij direct toegang heeft (door bv. direct te redirecten naar de toepassing zelf. Eens de toegang goedgekeurd (voor die toepassingen waar goedkeuring noodzakelijk is), krijgt de eindgebruiker een mail met de url van de toepassing waartoe hij/zij toegang heeft. Indien bepaalde ldap attributen verplicht zijn voor de toepassing waar toegang tot gevraagd wordt, moet ervoor gezorgd worden dat die tijdens de toegangsaanvraag verplicht invulbaar zijn . In geval b (eID of token voor authenticatie en identificatie; ldap of databank voor authorisatie)wordt de eindgebruiker doorgestuurd naar een applicatiespecifieke pagina waar gebruikmakende van de reeds geauthenticeerde status van de gebruiker de nodige info opgezocht wordt om een aanvraag voor toegang mogelijk te maken. Hiertoe moet de generieke acegi module aangepast worden zodat aangemelde gebruikers zonder rechten doorgestuurd worden naar de applicatiespecifieke pagina voor toegangsaanvraag. M.a.w. het rijksregisternummer wordt opgezocht in de ACD-ldap en indien aanwezig wordt er ineens een aanvraag voor toegang doorgestuurd naar de applicatiebeheerder. Indien het rijksregisternummer niet gekend is in de ACD-ldap wordt het emailadres (en naam, wachtwoord uid en telefoonnummer) gevraagd en wordt het rijksregisternummer uit de header (immers reeds geauthenticeerd) automatisch ingevuld in de ACD-ldap bij de usercreatie. Indien het emailadresreeds bestaat, maar andere persoonsgegevens ontbreken, dan worden die hier opgevraagd. In één stap wordt ook toegang tot de toepassing aangevraagd aan de applicatiebeheerder. Een aangemelde gebruiker moet ten allen tijde zijn eigen gegevens kunnen beheren. De basislijst van eigen te beheren gegevens (attributen) wordt bepaald door de superbeheerder, is voor alle gebruikers hetzelfde en wordt mogelijk uitgebreid met verplichte attributen die applicatiespeciek zijn en niet noodzakelijk door de gebruiker zelf te beheren. Het kan ook de applicatiebeheerder zijn die het beheer van bepaalde attributen moet doen. Dit moet instelbaar zijn. Het rijksregisternummer wordt versleuteld opgeslagen in de ldap. Het hashing mechanisme dat gebruikt wordt, wordt ter goedkeuring voorgelegd aan de opdrachtgever. De versleuteling dient gebruik te maken van een symmetrisch open source hashing mechanisme, zodat alle gegevens met uitzondering van het wachtwoord geprovisoneerd kunnen worden (cf, ldif en csv export).

11

2.2.2 Profiel 2: Een applicatiebeheerder wil zijn/haar gebruikers beheren. De applicatiebeheerder krijgt een mail voor elke aanvraag voor toegang tot zijn toepassing. Aanmelden door een applicatiebeheerder gebeurd steeds met eID/token. De applicatiebeheerder krijgt een overzicht van alle aanvragen (lijst) als eerste pagina. Die aanvragen kunnen daar goed of afgekeurd worden en er kan bij de afkeuring indien gewenst een reden gegeven worden die gemaild wordt naar de eindgebruiker. Bij registratie kan het mogelijk zijn dat ook bepaalde attributen toegevoegd moeten worden per gebruiker bv. voor de goede werking van de toepassing waartoe toegang aangevraagd werd. Het toekennen of valideren van de waarden van deze attributen moet, tijdens de toelatingsstap voor de toepassing in kwestie, gebeuren door de applicatiebeheerder. Een applicatie beheerder moet een mail kunnen sturen naar zijn gebruikers of naar een specifieke gebruiker van zijn/haar toepassing. 2.2.3 Profiel 3: Een superbeheerder. z

z z z z z z z

Kan nieuwe toepassingen definieëren en bijhorende toepassingsspecifieke attributen definiëren(apart object dat toegewezen wordt per gebruiker van die toepassing). Gebruikers creëren en alle velden hiervoor een waarde geven en het type veld bepalen (numeriek, string, verplicht ....), gebruikers toepassingsbeheerder maken, Algemene attributen definiëren en bijmaken. Lijsten en lijstbeheerders definiëren en bijhorende lijst specifieke attributen definieëren. Aanduiden of een toepassing met ldap dan wel met eID/token werkt. Rollen per toepassing definiëren. De url van de applicatiespecifieke aanmeldpagina definieren.

Geneste delegatie moet mogelijk zijn zodat rollenbeheer gedelegeerd kan worden. Een superbeheerder moet een mail kunnen sturen naar gebruikers in een bepaalde rol of naar een specifieke gebruiker en naar alle applicatiebeheerders. 2.3 Lijsten beheer Het beheren van lijsten heeft enkel tot doel om groepen van mensen te kunnen aanleggen en daar bepaalde lijst specifiek attributen van te beheren. Een voorbeeld kan zijn het beheer van alle erkende MER-deskundigen met bv. start en eind-datum van erkenning. Vraag is of dit a.d.h.v. een specifiek attribuut en met cos, dan wel een a.d.h.v. een groep met unique members moet gebeuren. Dit is verder uit te klaren met de opdrachtgever.

12

Van alle mails die verstuurd worden moet de tekst aanpasbaar zijn in de toepassing 2.4 Technische randvoorwaarden Extra informatie over de generiek aanmeld module en de saml redirector toepassing waarover even terug in de tekst sprake is terug te vinden op: http://documentatie.milieuinfo.be/ontwikkeling%20maatsoftware/projecten/samlredirector/ Bijkomende randvoorwaarden zijn terug te vinden op : http://documentatie.milieuinfo.be/ontwikkeling%20maatsoftware/gewenstewerkwijze/omgevings-specifiek-eisen Hierbij de inhoud van de pagina op bovenvermelde url. De wijze van implementatie van functionaliteiten hoe klein ook, wordt altijd eerst afgecheckt met het technische en inhoudelijke team van de opdrachtgever voor ook maar één letter code geschreven wordt. Dit geldt ook voor het toevoegen van menu items, scherm enz. Met betrekking tot naamgeving van datasources, tabellen, velden, scripts, zaken die in de databank gestoken worden, wordt steeds de goedkeuring van het technische team van het ACD gevraagd indien de geleverde richtlijnen niet duidelijk zijn. Zie ook verder in dit document. Authenticatie voor toepassingen gebeurt steeds via ldap, de federale token de elektronische identiteitskaart of de vlaamse acm (afhankelijk van de gevraagde functionaliteit), waarbij gebruik gemaakt wordt van de bestaande authenticatie module van de opdrachtgever. Indien in een toepassing andere dan naamloze gebruikerprofielen bestaan worden deze profielen a.d.h.v. rollen in de ldap gedefinieerd. Connecties naar de databank gebeuren steeds en enkel via de connectionpool van de applicatieserver. Alle toepassingen zijn volledig webgebaseerd en alle workflows en handelingen zijn mogelijk via de web- of xml interface. M.a.w. alles verloopt via http of https. Uitgaande request van de toepassing naar diensten buiten het netwerk van de opdrachtgever moeten passeren via een forward proxy Alle toepassingen zijn volledig clusterbaar wat betekent dat er bij het falen van één van de applicatieservers in de cluster zelfs geen sessie verlies plaats vindt. De volledige 'fail-over' moet transparant voor de eindgebruiker plaats vinden (serialisatie van de code over de hele lijn). In de sessie wordt zo weinig mogelijk informatie bewaard. Alle data moet uit de databank op te halen zijn. Precompilatie is verplicht voor alle toepassingen in productie en verboden voor toepassingen op de ontwikkel en de oefen omgeving.

13

Opvolging van bugs gebeurt via het bugopvolgings-systeem van de opdrachtgever (bugs.milieuinfo.be). De te volgen procedure m.b.t. de melding en afhandeling van bugs is hier beschreven. Alle documentatie gaande van technische handleiding over installatie handleiding tot eindgebruikers handleiding worden in de projectsite in het cms van de opdrachtgever gestoken. m.b.t. communicatie wordt per project een mailinglist opgezet door de opdrachgever waar de betrokken personen lid van zijn. Alle communicatie met de opdrachgever en zijn partners dient via deze mailinglist te verlopen. In de titelbalk van de toepassing verschijnt steeds het versienumer van de toepassing achter de naam van de toepassing. De versienummer in de balk is identiek aan de versienummer in het cvs. Elke toepassing voldoet aan de criteria van het Toegankelijk Web-initiatief van de Vlaamse overheid. Nergens in de toepassing mag naam of logo van de aannemer vermeld staan (ook niet in commentaarvelden of handleidingen). Het logo van de opdrachtgever beperkt zich tot de vlaamse leeuw. Engelstalige termen zoals 'username', 'inloggen', 'paswoord', ... mogen niet gebruikt worden. De toepassing moet volledig nederlandstalig zijn. De toepassing moet gebruik maken van internationalistatie. Waarbij alle tekst minimaal in een apart tekst bestand terecht komt en optimaal in de databank. Gebruik van javascript wordt zoveel mogelijk vermeden. Elk gebruik ervan wordt overlegd met technische team van de oprdachtgever. Logging gebeurt steeds met log4j. Webservices die ontwikkeld worden zijn steeds rpc-doc-literal. Een ander type is niet aanvaardbaar. Indien adressen ingevuld moeten worden, wordt steeds gebruik gemaakt van de CBB straten webservice. Ook terugkoppeling bij ingave van nieuw straten plus een bijwerking na validatie ervan, gebeurt via deze webservice. Indien er spraken is van het handtekenen van documenten dient bij gebruik van de token het rijksregisternummer bijgehuiden te worden, indien de gebruiker aanmeldt met de eID dient het rijksregister bij gehouden te worden en dient een echte handtekening met het singneer certificaat gezet te worden op het document. Continues integration wordt gerealiseerd via continuum. Configuratie van continuum gebeurd a.d.h.v. de maven pom file. Er wordt steeds met earfiles gewerkt. De contextroot van de toepassing moet aanpasbaar zijn en wordt na de build eventueel aangepast.

14

Omgevings specifieke settings worden bij het starten van de toepassing geladen uit een propertyfile. SVN van de opdrachtgever wordt gebruikt als code repository. Verder technische randvoorwaarden m.b.t. de te programmeren toepassing: -

De gebruikte directory server is een sun one ldap 5.2 De gebruikte applicatie server jboss 4.0.5.GA Java versie 1.5.10 De te gebruiken frameworks en hulpprogramma's zijn o,a, jsf referrence implementation, hibernate, spring, spring webflow, maven 2, continuum

Voor meer info kan steeds contact worden opgenomen met Tom Van Gulck tel.: 02/553 11 51 of email: [email protected]

15

BIJLAGE 1 : MODEL VAN INDIENING (inschrijvingsformulier)

1. ONDERWERP VAN DE INDIENING 1.1 Bestek: MMIS/2007/SDB/010 1.2 Onderwerp van de opdracht : Ontwikkeling van een gebruikersbeheer toepassing. 2.IDENTIFICATIE VAN DE INSCHRIJVER 2.1. Vennootschappen 2.1.1. Firmanaam of benaming: 2.1.2. Juridische vorm : 2.1.3. Nationaliteit : 2.2. Hoofdzetel: Straat : Nr : Bus : Plaats : Postcode : Land : Telefoonnummer : Faxnummer : BTW-nummer : Contactperso(o)n(en) en telefoonnummer(s) : 3. GELDIGHEIDSDUUR VAN DE OFFERTE Deze offerte blijft geldig tot :……………………………………. (minimum 90 dagen) 4. BETALINGEN Nummer en benaming van de rekening waarop betalingen moeten uitgevoerd worden:……………….

5. AANVULLENDE INLICHTINGEN Naam en nationaliteit van de eventuele onderaannemers waarop de inschrijver een beroep doet om de opdracht uit te voeren.

6. AAN DE ONDERHAVIGE OFFERTE TOE TE VOEGEN DOCUMENTEN de inventaris (volledig ingevuld, gedagtekend, ondertekend) referenties van gelijkaardige gerealiseerde projecten Deze stukken moeten op straffe van uitsluiting bij de offerte gevoegd worden.

16

7. HANDETEKENING(EN) VAN DE GEVOLMACHTIGDE(N) 7.1 De inschrijver werd gemachtigd door :

Door het feit van deze offerte, aanvaard ik expliciet alle voorwaarden van het bestek en verzaak ik aan alle andere beschikkingen zoals ook aan mijn eigen verkoopsvoorwaarden.

Anderzijds, verbind ik mij op mijn roerende en onroerende goederen ertoe om overeenkomstig de bepalingen van het bestek, de diensten te leveren die gedetailleerd worden opgenomen in het overzicht dat bij de offerte is gevoegd, en dit overeenkomstig de tarieven die er in bepaald zijn.

Bovendien, sta ik de aanbestedende overheid toe om alle nuttige informatie (bijvoorbeeld van financiële aard) over mijn onderneming bij andere instanties in te winnen. Gedaan te: Datum: Naam: Handtekening1: De afwezigheid van de handtekening houdt de absolute nietigheid van de offerte in.

1 De offerte moet door de inschrijver of zijn gevolmachtigde ondertekend worden. Alle doorhalingen, overschrijvingen, bijvoegingen en de wijzigingen, zowel van de offerte als van zijn bijlagen, die de basisvoorwaarden van de offerte kunnen beïnvloeden, met name de prijs, de technische specificaties, moeten eveneens getekend worden door de inschrijver of door zijn gevolmachtigde.

17

BIJLAGE 2: INVENTARIS BESTEK MMIS/2007/SDB/010 - Ontwikkelen van een gebruikersbeheer toepassing. Omschrijving

Hoeveelheid

Eenheidsprijs

Totaal

Totaal: 21% BTW: Algemeen Totaal: Gezien, onderzocht en aangevuld met de eenheidsprijzen, Gedaan te

, de

De inschijver (naam en handtekening)

18