Overheid maakt broncode Basisregistratie Personen open source
De overheid heeft de broncode van de meest recente versie van de Basisregistratie Personen (BRP) via GitHub open source gemaakt. De BRP bevat persoonsgegevens van inwoners van Nederland en van personen die Nederland hebben verlaten. Staatssecretaris Knops van Binnenlandse Zaken laat aan de Tweede Kamer weten dat de code voor publicatie op onder andere privacy en veiligheidsrisico's is gecontroleerd.
De broncode is onder de licentievoorwaarden AGPL (Affero General Public License) openbaar gemaakt. Deze voorwaarden zien er op toe dat aanpassingen van de broncode ook weer openbaar worden, zo laat Knops weten. Dit moet het hergebruik verder ondersteunen. "Openbaarmaking vindt plaats zonder kostendoorberekening zodat, in het algemeen belang, een gelijk speelveld ontstaat voor een ieder die deze code wil hergebruiken. Alle partijen kunnen op hetzelfde moment over de ontwikkelde broncode beschikken", stelt de staatssecretaris verder. De broncode van eerdere versies wordt later openbaar gemaakt.
De nu openbaar gemaakte broncode betreft de broncode van de Basisregistratie Personen die in het kader van Operatie BRP is ontwikkeld. Het gaat om programmatuur die was geschreven voor nieuwe centrale ict-systemen voor de BRP. Dit project werd in juli van dit jaar gestopt.
Reacties (24)
29-11-2017, 11:07 door
Anoniem
Brrr... Java met nederlandse methodes, variabelen en comments.
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
29-11-2017, 11:21 door
Anoniem
Het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) heeft de broncode openbaar gemaakt van de programmatuur die was geschreven voor nieuwe centrale ict-systemen voor de basisregistratie personen (BRP). Dit project is in juli 2017 gestopt.
29-11-2017, 11:35 door
Anoniem
Dit is alleen de source code van Operatie BRP, de nieuwe versie die nooit in gebruik is genomen en die in juli gecanceld is.
29-11-2017, 11:44 door
Anoniem
Mooi. Ik heb me al vaak afgevraagd wat er nou precies zo ingewikkeld was aan dat project, en er was niet veel meer over te vinden dan wat de wet voorschrijft dat bijgehouden moet worden, en als je daarop afgaat kom je niet veel verder dan een logisch datamodel met maar liefst één entiteittype: persoon. Dat er meer moest zijn was natuurlijk duidelijk, het is altijd complexer dan je in eerste instantie overziet, maar die algemene constatering vertelt nog niet hoe complex. Nu is er documentatie openbaar gemaakt die een beeld van het systeem geeft.
Ik heb het gedownload en er vluchtig door gekeken, en dat geeft inderdaad al een beter beeld van waar het project over gaat. Eerste indruk: inderdaad een stuk omvangrijker dan ik zonder die informatie overzag, maar ik zie nog in de verste verte niet in hoe ik op basis van mijn automatiseringservaring (die overigens zeker niet allesomvattend is) daar een prijskaartje van 100 miljoen aan zou moeten hangen. Dat is echt een enorme smak geld.
Wat ook opvalt is dat het bestaande systeem, de GBA, in het grote architectuurplaatje dezelfde positie inneemt als het BRP. Men heeft gekozen om in het conversietraject het BRP de oude GBA-interfaces te laten ondersteunen naast de nieuwe BRP-interfaces. Het ligt voor de hand dat het GBA-systeem ook intern overeenkomsten moet vertonen met het BRP, het lost immers grotendeels hetzelfde probleem op. Als je heel ouderwets het datamodel als fundament beschouwt dan zullen ook de datamodellen de nodige overeenkomsten moeten vertonen.
Ook het van scratch af aan opnieuw bouwen van dat kernsysteem is al een big bang-project. Ik vraag me af of het niet mogelijk was geweest om in plaats daarvan het GBA via een reeks kleinere projecten om te bouwen tot het BRP. Dat maakt de kans om je eraan te vertillen aanzienlijk kleiner, kleinere projecten zijn domweg een stuk beheersbaarder dan grote.
Hoe dan ook, het is mooi dat er nu iets is waar mensen met kennis van zaken over kunnen oordelen. Het zou interessant zijn als iemand op basis van de documentatie een functiepuntanalyse uitwerkt en daar ervaringscijfers (uren/kosten per functiepunt) uit een representatief soort projecten tegenaan houdt en zo tot een kostenschatting komt. Voor wie het niet weet: functiepuntanalyse is een techniek die al in een vroeg stadium van een project een heel bruikbaar inzicht in de omvang van het te bouwen systeem oplevert.
Ik ben benieuwd wat deze publicatie aan reacties gaat opleveren van mensen die (beter dan ik) toegerust zijn om dit soort projecten te beoordelen.
Ik heb het gedownload en er vluchtig door gekeken, en dat geeft inderdaad al een beter beeld van waar het project over gaat. Eerste indruk: inderdaad een stuk omvangrijker dan ik zonder die informatie overzag, maar ik zie nog in de verste verte niet in hoe ik op basis van mijn automatiseringservaring (die overigens zeker niet allesomvattend is) daar een prijskaartje van 100 miljoen aan zou moeten hangen. Dat is echt een enorme smak geld.
Wat ook opvalt is dat het bestaande systeem, de GBA, in het grote architectuurplaatje dezelfde positie inneemt als het BRP. Men heeft gekozen om in het conversietraject het BRP de oude GBA-interfaces te laten ondersteunen naast de nieuwe BRP-interfaces. Het ligt voor de hand dat het GBA-systeem ook intern overeenkomsten moet vertonen met het BRP, het lost immers grotendeels hetzelfde probleem op. Als je heel ouderwets het datamodel als fundament beschouwt dan zullen ook de datamodellen de nodige overeenkomsten moeten vertonen.
Ook het van scratch af aan opnieuw bouwen van dat kernsysteem is al een big bang-project. Ik vraag me af of het niet mogelijk was geweest om in plaats daarvan het GBA via een reeks kleinere projecten om te bouwen tot het BRP. Dat maakt de kans om je eraan te vertillen aanzienlijk kleiner, kleinere projecten zijn domweg een stuk beheersbaarder dan grote.
Hoe dan ook, het is mooi dat er nu iets is waar mensen met kennis van zaken over kunnen oordelen. Het zou interessant zijn als iemand op basis van de documentatie een functiepuntanalyse uitwerkt en daar ervaringscijfers (uren/kosten per functiepunt) uit een representatief soort projecten tegenaan houdt en zo tot een kostenschatting komt. Voor wie het niet weet: functiepuntanalyse is een techniek die al in een vroeg stadium van een project een heel bruikbaar inzicht in de omvang van het te bouwen systeem oplevert.
Ik ben benieuwd wat deze publicatie aan reacties gaat opleveren van mensen die (beter dan ik) toegerust zijn om dit soort projecten te beoordelen.
29-11-2017, 11:53 door
Anoniem
Man man man wat een positiviteit weer op dit forum zeg... Ze hadden het ook niet kunnen publiceren...
Door Anoniem:In één woord : BAH
29-11-2017, 12:00 door
Tha Cleaner
Door Anoniem: Brrr... Java met nederlandse methodes, variabelen en comments.
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Doen ze eens wat goed... Is het ook weer niet goed. Ze kunnen het ook nooit goed doen.....
Mocht je niet niet weten. De voertaal bij de NEDERLANDSE overheid is hé wat raar... Nederlands en niet Engels.
Dit is zeuren om te zeuren.
29-11-2017, 12:12 door
Anoniem
Door Tha Cleaner:
Doen ze eens wat goed... Is het ook weer niet goed. Ze kunnen het ook nooit goed doen.....
Mocht je niet niet weten. De voertaal bij de NEDERLANDSE overheid is hé wat raar... Nederlands en niet Engels.
Dit is zeuren om te zeuren.
Door Anoniem: Brrr... Java met nederlandse methodes, variabelen en comments.
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Doen ze eens wat goed... Is het ook weer niet goed. Ze kunnen het ook nooit goed doen.....
Mocht je niet niet weten. De voertaal bij de NEDERLANDSE overheid is hé wat raar... Nederlands en niet Engels.
Dit is zeuren om te zeuren.
Het is anders vrij gebruikelijk om in de IT wereld alles in het engels te doen. zoek jij maar eens een foutmelding op in het nederlands dat is meer moeite dan dat je alles gewoon in het engels doet en ook de engelse foutmeldingen hebt.
29-11-2017, 13:11 door
Anoniem
Door Tha Cleaner:
Doen ze eens wat goed... Is het ook weer niet goed. Ze kunnen het ook nooit goed doen.....
Mocht je niet niet weten. De voertaal bij de NEDERLANDSE overheid is hé wat raar... Nederlands en niet Engels.
Dit is zeuren om te zeuren.
Door Anoniem: Brrr... Java met nederlandse methodes, variabelen en comments.
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Zeker bedoeld om de nederlands sprekende ontwikkelaars van de straat te houden, de rest van de wereld kan er niks mee.
In één woord : BAH
Doen ze eens wat goed... Is het ook weer niet goed. Ze kunnen het ook nooit goed doen.....
Mocht je niet niet weten. De voertaal bij de NEDERLANDSE overheid is hé wat raar... Nederlands en niet Engels.
Dit is zeuren om te zeuren.
Bij debuggen en foutafhandeling (of zelfs bouwen) is het handiger als je Engels als voertaal hanteert in de code. Dan heb je een grotere zoekbron (google) voor de oplossing of achtergrond.
Als je je beperkt tot Nederlands, dan kun je snel nat gaan of zelf moeten gaan vertalen. Niet echt handig.
De meeste programmeurs zijn daarom goed onderlegd in het Engels.
Met Oracle en Cognos werk ik ook altijd met een engelstalige versie. Dat is gewoon veel handiger.
De gebruikers kun je aan de voorkant (de schermen) hoe dan ook Nederlands voorschotelen. Die merken er niets van.
29-11-2017, 13:55 door
karma4
Het gaat om het gefaalde brp project waarvan alles gestopt is.
Geen idee wat de bedoeling is om het openbaar te maken.
Ze hebben ef flink voor betaald dus de keus is aan de eigenaar.
De voertaal bij de overheid.... Engels wegens Europees aanbesteding.
Geen idee wat de bedoeling is om het openbaar te maken.
Ze hebben ef flink voor betaald dus de keus is aan de eigenaar.
De voertaal bij de overheid.... Engels wegens Europees aanbesteding.
29-11-2017, 14:56 door
Anoniem
Ok ik ga het eens controleren wellicht kan ik een bijdrage leveren. Leuke uitdaging.
29-11-2017, 15:09 door
Anoniem
Door karma4: Het gaat om het gefaalde brp project waarvan alles gestopt is.
Geen idee wat de bedoeling is om het openbaar te maken.
De overheid maakt zich er controleerbaar mee. In plaats van alleen een vaag beeld van wat dat ontspoorde project van 100 miljoen inhoudt kunnen we nu in detail zien waar het over gaat, we hebben nu broncode én documentatie, al is het alleen van de laatste stand van zaken. Ik kijk uit naar artikelen die het inhoudelijk beoordelen en een idee geven van hoeveel dit resultaat redelijkerwijs had mogen kosten.Geen idee wat de bedoeling is om het openbaar te maken.
29-11-2017, 15:30 door
Anoniem
Door Anoniem: Bij debuggen en foutafhandeling (of zelfs bouwen) is het handiger als je Engels als voertaal hanteert in de code. Dan heb je een grotere zoekbron (google) voor de oplossing of achtergrond.
Als je je beperkt tot Nederlands, dan kun je snel nat gaan of zelf moeten gaan vertalen. Niet echt handig.
De meeste programmeurs zijn daarom goed onderlegd in het Engels.
Met Oracle en Cognos werk ik ook altijd met een engelstalige versie. Dat is gewoon veel handiger.
De gebruikers kun je aan de voorkant (de schermen) hoe dan ook Nederlands voorschotelen. Die merken er niets van.
Ze gebruikten geen Nederlanstalige versie van Java of 3rd-party libraries of SQL of zo (als dat al zou bestaan), dat is allemaal op Engels gebaseerd. Ze gaven Nederlandse namen aan hun eigen packages, interfaces, classes en variabelen, en schreven Nederlandstalig commentaar. Dat levert geen taalproblemen op met informatie zoeken op het web.Als je je beperkt tot Nederlands, dan kun je snel nat gaan of zelf moeten gaan vertalen. Niet echt handig.
De meeste programmeurs zijn daarom goed onderlegd in het Engels.
Met Oracle en Cognos werk ik ook altijd met een engelstalige versie. Dat is gewoon veel handiger.
De gebruikers kun je aan de voorkant (de schermen) hoe dan ook Nederlands voorschotelen. Die merken er niets van.
29-11-2017, 16:40 door
Anoniem
Ik vraag me af of het niet mogelijk was geweest om in plaats daarvan het GBA via een reeks kleinere projecten om te bouwen tot het BRP. Dat maakt de kans om je eraan te vertillen aanzienlijk kleiner, kleinere projecten zijn domweg een stuk beheersbaarder dan grote.
Het huidige GBA is (volgens de mensen die het mGBA/BRP gestart zijn) niet voldoende genormaliseerd. Waarom dat nu en 10 jaar geleden nog een kritiek probleem was, is mij onduidelijk. De hardware en database software zijn voldoende schaalbaar dat dit niet meer interessant is. Je moet allleen meer data updaten.
Daarnaast hadden ze dat kunnen oplossen door stapsgewijs het logisch ontwerp te moderniseren.
Waarom er in 1994 niet voor gekozen is om de normalisatie goed door te voeren, is nog een andere vraag. Toen bestond die methodiek namelijk ook al geruime tijd.
Verder werd er (10 jaar geleden) nog gebruik gemaakt van tweemaal-daags gerunde jobs om berichten tussen gemeenten uit te wisselen (vraag/antwoord). Daar zijn ondertussen stuf-uitwisseling met oa. het GBA-V en VOA bijgekomen, waardoor e.e.a. al versneld is. Dat had men ook verder kunnen doorontwikkelen.
Waarom het 10 jaar geleden al niet mogelijk was, of nu, om de decentrale GBA-databases van de 380 gemeenten te moderniseren (verder te normaliseren) en via realtime berichtuitwisseling aan elkaar te koppelen (waardoor je geen centrale database bij Binnenlandse Zaken nodig hebt), heb ik nooit begrepen.
Zijn daar veranderingen aan de huidige GBA-software voor nodig? Ja.
Maar het lijkt me dat dat stukken goedkoper en beter onder controle te houden was geweest dan dit ontspoorde mega-project.
29-11-2017, 16:44 door
Anoniem
Door karma4: De voertaal bij de overheid.... Engels wegens Europees aanbesteding.
Wat heeft de taal van een aanbesteding nu met de taal van de software-code te maken?
Het is niet alsof de software-code mee zal gaan doen aan de aanbesteding. :-)
Programmeurs zijn er normaal gesproken aan gewend om in het engels te programmeren, omdat de programmeer-talen op engels gebaseerd zijn. En omdat je dat een groter naslagwerk (het hele internet) tot je beschikking hebt als je iets moet opzoeken.
Waarom dan in het Nederlands gaan programeren is mij onduidelijk?
Misschien dat de ex-projectleden daar licht op kunnen schijnen (als ze deze discussie volgen)?
29-11-2017, 17:47 door
Tha Cleaner
Door Anoniem: Het is anders vrij gebruikelijk om in de IT wereld alles in het engels te doen. zoek jij maar eens een foutmelding op in het nederlands dat is meer moeite dan dat je alles gewoon in het engels doet en ook de engelse foutmeldingen hebt.
Dat hoef je mij niet te zeggen. Ik werk momenteel voor de overheid. En daar is gewoon de standaard voertaal NL, Engelse communicatie is niet toegestaan officieel. Best leuk, als je met India moet werken.
En je op een server draait een gewoon Engelse Windows, maar de desktops zijn gewoon in het Nederlands.
Door Anoniem: Bij debuggen en foutafhandeling (of zelfs bouwen) is het handiger als je Engels als voertaal hanteert in de code. Dan heb je een grotere zoekbron (google) voor de oplossing of achtergrond.
Als je je beperkt tot Nederlands, dan kun je snel nat gaan of zelf moeten gaan vertalen. Niet echt handig.
De meeste programmeurs zijn daarom goed onderlegd in het Engels.
Met Oracle en Cognos werk ik ook altijd met een engelstalige versie. Dat is gewoon veel handiger.
De gebruikers kun je aan de voorkant (de schermen) hoe dan ook Nederlands voorschotelen. Die merken er niets van.
Als je je beperkt tot Nederlands, dan kun je snel nat gaan of zelf moeten gaan vertalen. Niet echt handig.
De meeste programmeurs zijn daarom goed onderlegd in het Engels.
Met Oracle en Cognos werk ik ook altijd met een engelstalige versie. Dat is gewoon veel handiger.
De gebruikers kun je aan de voorkant (de schermen) hoe dan ook Nederlands voorschotelen. Die merken er niets van.
Klopt, maar de voertaal is Nederlands, dus opzich niet gek als men in Nederlands programmerd. Dat is volgens de techniek richtlijnen waardeloos is, is een tweede. Menig keer kan ik een Nederlandse foutmelding omzetten naar Engels voor mijn India collega's. Ik weer er dus alles van...... Je hoeft het mij niet uit te leggen. Ervaring genoeg.... Nederlandse Windows of Office foutmeldingen zijn waardeloos.
Door karma4: De voertaal bij de overheid.... Engels wegens Europees aanbesteding.
Aanbesteding mag ook gewoon in het Engels.... Zolang de eindgebruiker communicatie maar in het Nederlands is. Das vaak wel een regeltje in de aanbesteding. Maar je kan ook prima Nederlands sprekende mensen in Polen, Suriname hebben zitten. Niet te verstaan, maar voldoet wel aan de richtlijnen. Het hangt er wel vanaf, met wie je moet communiceren. Maar de ministeries accepteren niet zomaar Engels als voertaal zeker niet de niet ICT personen.Ervaring genoeg.....
29-11-2017, 18:04 door
karma4
Door Tha Cleaner: ....
Het hangt er wel vanaf, met wie je moet communiceren. Maar de ministeries accepteren niet zomaar Engels als voertaal zeker niet de niet ICT personen.
Ervaring genoeg.....
Idem ditto. Je hebt we gelijk dat de ict nitwits zeg maar Oprachtgevers IM Informatiemanagement en de beoogde vloer ofwel eindgebruikers het in Nederlands willen. Zodra er uitbesteding techneuten specialisten aan de orde is wordt het snel Engels. Het hangt er wel vanaf, met wie je moet communiceren. Maar de ministeries accepteren niet zomaar Engels als voertaal zeker niet de niet ICT personen.
Ervaring genoeg.....
De Indiërs (indianen) moet je begrijpen ze zijn soms uitstekend vaardig soms zoekend. Je moet dat zelf inschatten het enige antwoord wat ze kennen is "ja sahib" . Ja betekent niet dat ze het begrepen hebben of gaan doen. Cultuurverschil.
Prachtig die vertalingen van ze ooit. Google translate is er nog niets bij.
29-11-2017, 18:08 door
karma4
Door Anoniem: .....
Maar het lijkt me dat dat stukken goedkoper en beter onder controle te houden was geweest dan dit ontspoorde mega-project.
De gemeentelijke software is aan de markt over gelaten. Het zijn externe software dienstverleners die de paketten hebben. Dd stuf koppeling is een verplicht te testen iets. Logius toch.Maar het lijkt me dat dat stukken goedkoper en beter onder controle te houden was geweest dan dit ontspoorde mega-project.
De gemeenten hebben als enige optie te dokken wat de markt bepaalt. Veel goedkoper /sarcasm.
29-11-2017, 18:09 door
Anoniem
Tja nu pas komen de mensen die met de broncode gaan stoeien er pas achter dat lang niet alles zo veilig was met de brp voorheen als dat de regering had gesuggereerd.
Misschien is men er nu pas achter dat het veliger moet,en er een nieuw systeem moet komen dat alle gegevens niet zo makkelijk op straat komen te liggen.
Misschien is men er nu pas achter dat het veliger moet,en er een nieuw systeem moet komen dat alle gegevens niet zo makkelijk op straat komen te liggen.
29-11-2017, 18:51 door
Anoniem
Mij ontgaat het doel van het open source maken van deze stopgezette (ongebruikte? Afgekeurde?) overheidssoftware.
30-11-2017, 12:11 door
The FOSS
Door Anoniem: Mij ontgaat het doel van het open source maken van deze stopgezette (ongebruikte? Afgekeurde?) overheidssoftware.
Dat staat er nochtans expliciet en in duidelijk Nederlands bij vermeld! Zie de quote van het betreffende fragment hieronder:
Door reactie: De broncode is onder de licentievoorwaarden AGPL (Affero General Public License) openbaar gemaakt. Deze voorwaarden zien er op toe dat aanpassingen van de broncode ook weer openbaar worden, zo laat Knops weten. Dit moet het hergebruik verder ondersteunen. "Openbaarmaking vindt plaats zonder kostendoorberekening zodat, in het algemeen belang, een gelijk speelveld ontstaat voor een ieder die deze code wil hergebruiken. Alle partijen kunnen op hetzelfde moment over de ontwikkelde broncode beschikken", stelt de staatssecretaris verder.
30-11-2017, 12:54 door
karma4
Door The FOSS:....
Dat staat er nochtans expliciet en in duidelijk Nederlands bij vermeld! Zie de quote van het betreffende fragment hieronder:
Heel duidelijk is ook dat het project gefaald is en niets van deze code nog gebruikt gaat worden waarvoor het bedoeld was.Dat staat er nochtans expliciet en in duidelijk Nederlands bij vermeld! Zie de quote van het betreffende fragment hieronder:
Als je voorbeelden zoekt hoe het niet moet dan heb je genoeg keus. Hoe het wel moet is de vraag.
Jij mag het gratis en voor niets doen. Het geld is al uitgegeven.
Door karma4:
Als je voorbeelden zoekt hoe het niet moet dan heb je genoeg keus. Hoe het wel moet is de vraag.
Door The FOSS:....
Dat staat er nochtans expliciet en in duidelijk Nederlands bij vermeld! Zie de quote van het betreffende fragment hieronder:
Heel duidelijk is ook dat het project gefaald is en niets van deze code nog gebruikt gaat worden waarvoor het bedoeld was.Dat staat er nochtans expliciet en in duidelijk Nederlands bij vermeld! Zie de quote van het betreffende fragment hieronder:
Als je voorbeelden zoekt hoe het niet moet dan heb je genoeg keus. Hoe het wel moet is de vraag.
De beste stuurlui staan weer aan wal! De code van dit project ziet er goed uit en maakt gebruik van moderne software constructies.
Het falen van een project kan allerlei redenen hebben, vaak politieke die niets met de gekozen techniek of de broncode te maken hebben. Delen van (deze) bestaande broncode zijn natuurlijk wel degelijk te hergebruiken want zijn vaak een kant en klaar resultaat van een lang en zorgvuldig denkproces om bepaalde problemen in kaart te brengen en op te lossen.
02-12-2017, 12:40 door
Anoniem
NRC heeft een reconstructie van hoe GBA/BRP zo uit de hand liep:
https://www.nrc.nl/nieuws/2017/12/01/het-systeem-is-niet-beschikbaar-a1583436
https://www.nrc.nl/nieuws/2017/12/01/het-systeem-is-niet-beschikbaar-a1583436
02-12-2017, 13:46 door
Anoniem
Door Anoniem: Mooi. Ik heb me al vaak afgevraagd wat er nou precies zo ingewikkeld was aan dat project, en er was niet veel meer over te vinden dan wat de wet voorschrijft dat bijgehouden moet worden, en als je daarop afgaat kom je niet veel verder dan een logisch datamodel met maar liefst één entiteittype: persoon. Dat er meer moest zijn was natuurlijk duidelijk, het is altijd complexer dan je in eerste instantie overziet, maar die algemene constatering vertelt nog niet hoe complex. Nu is er documentatie openbaar gemaakt die een beeld van het systeem geeft.
Ik heb het gedownload en er vluchtig door gekeken, en dat geeft inderdaad al een beter beeld van waar het project over gaat. Eerste indruk: inderdaad een stuk omvangrijker dan ik zonder die informatie overzag, maar ik zie nog in de verste verte niet in hoe ik op basis van mijn automatiseringservaring (die overigens zeker niet allesomvattend is) daar een prijskaartje van 100 miljoen aan zou moeten hangen. Dat is echt een enorme smak geld.
Wat ook opvalt is dat het bestaande systeem, de GBA, in het grote architectuurplaatje dezelfde positie inneemt als het BRP. Men heeft gekozen om in het conversietraject het BRP de oude GBA-interfaces te laten ondersteunen naast de nieuwe BRP-interfaces. Het ligt voor de hand dat het GBA-systeem ook intern overeenkomsten moet vertonen met het BRP, het lost immers grotendeels hetzelfde probleem op. Als je heel ouderwets het datamodel als fundament beschouwt dan zullen ook de datamodellen de nodige overeenkomsten moeten vertonen.
Ook het van scratch af aan opnieuw bouwen van dat kernsysteem is al een big bang-project. Ik vraag me af of het niet mogelijk was geweest om in plaats daarvan het GBA via een reeks kleinere projecten om te bouwen tot het BRP. Dat maakt de kans om je eraan te vertillen aanzienlijk kleiner, kleinere projecten zijn domweg een stuk beheersbaarder dan grote.
Hoe dan ook, het is mooi dat er nu iets is waar mensen met kennis van zaken over kunnen oordelen. Het zou interessant zijn als iemand op basis van de documentatie een functiepuntanalyse uitwerkt en daar ervaringscijfers (uren/kosten per functiepunt) uit een representatief soort projecten tegenaan houdt en zo tot een kostenschatting komt. Voor wie het niet weet: functiepuntanalyse is een techniek die al in een vroeg stadium van een project een heel bruikbaar inzicht in de omvang van het te bouwen systeem oplevert.
Ik ben benieuwd wat deze publicatie aan reacties gaat opleveren van mensen die (beter dan ik) toegerust zijn om dit soort projecten te beoordelen.
Ik heb het gedownload en er vluchtig door gekeken, en dat geeft inderdaad al een beter beeld van waar het project over gaat. Eerste indruk: inderdaad een stuk omvangrijker dan ik zonder die informatie overzag, maar ik zie nog in de verste verte niet in hoe ik op basis van mijn automatiseringservaring (die overigens zeker niet allesomvattend is) daar een prijskaartje van 100 miljoen aan zou moeten hangen. Dat is echt een enorme smak geld.
Wat ook opvalt is dat het bestaande systeem, de GBA, in het grote architectuurplaatje dezelfde positie inneemt als het BRP. Men heeft gekozen om in het conversietraject het BRP de oude GBA-interfaces te laten ondersteunen naast de nieuwe BRP-interfaces. Het ligt voor de hand dat het GBA-systeem ook intern overeenkomsten moet vertonen met het BRP, het lost immers grotendeels hetzelfde probleem op. Als je heel ouderwets het datamodel als fundament beschouwt dan zullen ook de datamodellen de nodige overeenkomsten moeten vertonen.
Ook het van scratch af aan opnieuw bouwen van dat kernsysteem is al een big bang-project. Ik vraag me af of het niet mogelijk was geweest om in plaats daarvan het GBA via een reeks kleinere projecten om te bouwen tot het BRP. Dat maakt de kans om je eraan te vertillen aanzienlijk kleiner, kleinere projecten zijn domweg een stuk beheersbaarder dan grote.
Hoe dan ook, het is mooi dat er nu iets is waar mensen met kennis van zaken over kunnen oordelen. Het zou interessant zijn als iemand op basis van de documentatie een functiepuntanalyse uitwerkt en daar ervaringscijfers (uren/kosten per functiepunt) uit een representatief soort projecten tegenaan houdt en zo tot een kostenschatting komt. Voor wie het niet weet: functiepuntanalyse is een techniek die al in een vroeg stadium van een project een heel bruikbaar inzicht in de omvang van het te bouwen systeem oplevert.
Ik ben benieuwd wat deze publicatie aan reacties gaat opleveren van mensen die (beter dan ik) toegerust zijn om dit soort projecten te beoordelen.
Op hoeveel schat je de waarde van wat gepubliceerd is?
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.