Doelstelling is het ontwikkelen van een programma voor het vooruitberekenen van de bevolking naar leeftijd en geslacht van een stad, en tevens van de wijken, etnische groepen en huishoudens binnen deze stad, voor een variabel te bepalen periode in de toekomst.
De eisen, die aan een nieuw prognosemodel worden gesteld, kunnen in de volgende groepen worden ingedeeld:
1. Voor welke indelingen van de bevolking moet het model een prognose kunnen opstellen?
2. Volgens welke methode moet het model vooruitrekenen?
3. In welke modules is de applicatie ingedeeld.
4. Aan welke eisen moet de te realiseren applicatie voldoen?
5. Welke algemene applicatie-eisen zijn van belang?
Het model en de applicatie zal gebouwd worden voor een gebruiker met minimaal enige demografische kennis: het produceren van een enigszins betrouwbare prognose is alleen realiseerbaar wanneer de gebruiker enige of liever behoorlijk wat demografisch inzicht heeft en zijn stad en de ontwikkelingen daarin goed kent. Toch biedt het model via default waarden de mogelijkheid om zonder enige kennis een prognose te maken. De waarde van de uitkomsten hiervan mag echter betwijfeld worden.
Verder moet de applicatie ook bruikbaar zijn voor kleinere gemeenten.
1. Voor welke indelingen van de bevolking moet het model een prognose kunnen opstellen?
Voor de volgende kenmerken/indelingen moet het mogelijk zijn om met het model een vooruitberekening op te stellen:
1. minimaal zijn in de prognose leeftijden en geslacht opgenomen
leeftijden in 1 jaarsgroepen.
2. de indeling van verschillende categorieën moet door de gebruiker zelf te bepalen zijn:
? indeling en aantal etnische groepen; hierbij moet het op wijkniveau mogelijk zijn clusters van wijken te gebruiken omdat het aantal per etnische groep anders te laag is.
? indeling en aantal huishoudenscategorieën; ook hiervoor geldt op wijkniveau dat clustering van wijken mogelijk moet zijn. Verder worden als output zowel de aantallen huishoudens als aantal personen berekend (zie A?dams model).
p.s.: bovenstaande indelingen zijn uiteraard afhankelijk van de input die in de applicatie gestopt is: als er bijvoorbeeld alleen maar een indeling van A en B-landen is ingevoerd, kun je geen prognose maken voor het aantal Marokkanen in 2010. De input is meteen randvoorwaarde voor wat mogelijk is.
2. Volgens welke methode moet het model vooruitrekenen?
1. Prognose hele stad en aparte groepen: Het model maakt een berekening voor de bevolking van de hele stad naar leeftijd en geslacht. In aparte modules wordt de bevolking per etnische groep, wijk en/of huishoudenscategorie berekend.
2. Consistentie deelprognoses: De berekeningen voor bovenstaande deelgroepen moeten consistent zijn met de vooruitberekening voor de hele stad: de aantallen naar leeftijd en geslacht gesommeerd voor de deelgroep(en) moeten overeenkomen met de totalen voor de hele stad.
3. Input: De input van het model bestaat in hoofdzaak uit
- demografische gegegevens: stand en stroomgegevens van de laatste 3 of meer jaar
kanttekeningen hierbij:
+ bij de gegevens over etnische groepen hoort ook etnische generatie
+ binnenlandse en buitenlandse vestiging (naar leeftijd en geslacht)afzonderlijk als input opnemen: de binnenlandse vestiging berekend op basis van bijv. een regressievergelijking, buitenlandse vestiging op basis van bijv. CBS gegevens of een default waarde uit tijdreeks vestiging; de buitenlandse vestiging moet ook weggelaten kunnen worden, wanneer die in een (kleinere) gemeente een beperkte rol speelt.
- woningvoorraad
- woningbouwprogrammering
- sloop en leegstand
Deze gegevens zijn primair bepalend voor de prognose. Wat je er niet instopt, kun je er ook niet uitkrijgen: de mate van gedetailleerdheid van de input bepaalt hoe gedetailleerd de output kan zijn.
4. Gemiddelde woningbezetting : De gemiddelde woningbezetting is een resultante, geen input.
5. Nieuwbouwwijk: De berekening van de bevolking in een nieuwbouwwijk is een geïntegreerd onderdeel van de wijkmodule. In deze wijkmodule is voorzien in de mogelijkheid om een prognose te maken voor een wijk die in de toekomst gerealiseerd wordt. Bij nieuwbouw ga je uit van het woningbouwprogramma; een referentielokatie/wijk (uit de eigen gemeente of een vergelijkbare gemeente) bepaalt de leeftijdsverdeling (en de gemiddelde woningbezetting?); bij een referentiewijk moet er een keuze zijn uit verschillende types referentiewijken (bijv. binnenstadswijk of buitenwijk).
3. Indeling model/applicatie
1. Aparte modules: De applicatie moet bestaan uit aparte modules, die naar keuze aangeschaft/gebruikt kunnen worden. De basis is 1 module stad&wijken met als onderdelen invoer tijdreeksen, stadsprognose en wijkprognose. Daarnaast is er een afzonderlijke module met onderdelen etniciteit en huishoudens.
2. Analyse- en prognosedeel: Elke module kent een analysedeel- en een prognosedeel. In het analysedeel worden gegevens uit het verleden ingevoerd. Hieruit komen dan gegevens, die vervolgens als invoer voor het prognosedeel gebruikt kunnen worden. Het moet echter ook mogelijk zijn eigen gegevens als invoer voor het prognosedeel te gebruiken, bijvoorbeeld vooronderstellingen van het CBS. Dit moet handmatig kunnen of door een reeds bestaand bestand te importeren.
Meer in concreto betekent dit dat men vruchtbaarheids-, sterfte- en vertrekkansen invoert op basis van bijv. een tijdreeks van de laaste 5 jaar of op basis van gegevens van het CBS. Voor beide mogelijkheden moet de applicatie voorzien. Verder moet het mogelijk zijn deze kansen voor toekomstige jaren constant te houden of te laten toe of afnemen(bijv. per 5 jaarsperiode)
4. Aan welke eisen moet de te realiseren applicatie voldoen?
1. Default waardes: Het programma moet op verschillende momenten diverse keuzeopties aangeven: in het model zit altijd een default waarde (?geleid scenario?) die voorgesteld wordt, maar die kan door de gebruiker zelf aangepast worden (verondersteld wordt dat de gebruiker enige kennis van de materie heeft). Deze vooronderstellingen/kansen - die de gebruiker invoert - moeten door het systeem bewaard blijven, zodat ze later weer gebruikt en/of aangepast kunnen worden.
Via default waarden kan men snel en relatief eenvoudig een prognose maken; de waarde van de uitkomsten mag echter betwijfeld worden!
2. Geen black box: Het systeem kan per onderdeel gevuld worden. Per onderdeel kunnen controles plaatsvinden: het systeem is geen grote black box.
3. Benaming categorien: De benaming van de verschillende groepen binnen categorieen (wijken, huishoudens, etn. groepen etc.), moet je zelf kunnen bepalen. Door middel van de invoer in het prognosemodel moet je de benamingen van de groepen kunnen meegeven.
4. Cyclisch: Het model is cyclisch: wanneer je een of meerdere stappen terug wil, moet dit mogelijk zijn, zonder dat je eerder gedaan werk verliest. Dit kan bijvoorbeeld het geval zijn, wanneer je ziet dat bepaalde uitkomsten niet helemaal logisch zijn en je in een eerdere fase je vooronderstellingen wil aanpassen. Kortom: zowel de gegevens input als gemaakte keuzes (o.a.kansen) moeten bewaard blijven en zonodig bijgesteld kunnen worden.
Ook moet het mogelijk zijn de uitkomsten van eerder gemaakte keuzes te bewaren en te kunnen vergelijken met uitkomsten van nieuwe ingestelde keuzes, zodat je achteraf bekijkt welke je uiteindelijk gaat gebruiken.
5. Alles binnen de applicatie: Alle bewerkingen moeten in de applicatie plaatsvinden: er moeten geen bewerkingen buiten het model om meer nodig zijn (er wordt vanuit gegaan dat de invoer op eenzelfde eenduidige wijze door elke gebruiker wordt aangeleverd, zoals de tijdreeksen uit het GBA).
6. Waarschuwingssysteem: De applicatie bevat een waarschuwingssysteem: wanneer de gebruiker een bepaalde categorie-indeling kiest, waarvoor zijn populatie eigenlijk te klein is, moet het systeem een waarschuwing geven. Ook geldt dit voor 0-waarden die voorkomen in bepaalde leeftijdscategorieën en problemen opleveren voor de werking van het model. Hetzelfde moet gebeuren wanneer een bepaalde parameter/vooronderstelling niet logisch is of strijdig met andere parameters/vooronderstellingen. Hetzelfde geldt voor de uitkomsten: wanneer deze bijv. meer dan 10% afwijken van een vorig jaar, moet dit in een rapport komen te staan.
7. Rapportage vooronderstellingen: de eerder gemaakte keuzes moeten via een rapportage opvraagbaar zijn.
5. Algemene applicatie-eisen
- het platform waarop de applicatie kan draaien is in principe een van de moderne varianten van windows (98, 2000, NT, XP).
- gebruikersvriendelijk
- invoer helder en eenvoudig: via bestanden, bijvoorbeeld SPSS output via excel direct in het systeem, geen verdere bewerkingen
- invoer van eerder jaar blijft staan, zodat de tijdreeksen maar een keer ingevoerd hoeven te worden; het jaar erop schuiven ze op.
- uitvoer flexibel en eenvoudig in excel in te voeren (of excel spreadsheet als uitvoer),
- uitvoer moet ook bruikbaar zijn als input voor leerlingen-prognose-applicaties zoals bijv. G4Pro
- zowel eenvoudig te hanteren als complexer door gebruik maken van scenarios (finetuning),
- het programma moet geoptimaliseerd zijn voor gebruik, zodanig, dat de performance goed is. De doorrekening van een prognose op een doorsnee systeemopstelling mag niet te lang duren.
- software en broncode zijn niet toegankelijk voor gebruiker: wanneer bepaalde zaken aangepast moeten worden, gebeurt dit na overleg binnen de gebruikersgroep door de softwareleverancier/bouwer.
- de aanwezigheid van een gebruikers- en beheershandleiding: Er moet een overzichtelijke, Nederlandstalige gebruikers- en beheerdershandleiding aanwezig zijn. Liefst ook in elektronische vorm en eventueel on-line.
- schermlay-out en uitvoerlijsten: De schermlay-out en uitvoerlijsten dienen uniform en overzichtelijk te zijn.
- gebruikersgroep: Er dient een gebruikersgroep ingesteld te worden.
- Aanwezigheid interactieve helpfaciliteiten: Er dienen contextgevoelige en aanpasbare helpfaciliteiten aanwezig te zijn, op alle niveaus (menu, scherm, veld, trefwoord).
- Support(helpdesk)faciliteiten op afstand: Er moeten support(helpdesk)faciliteiten op afstand aanwezig zijn,
- Gebruikersopleiding: De volgende soorten gebruikersopleidingen moeten beschikbaar zijn: applicatiebeheer, technisch beheer, eindgebruikers (per module).
- Aanwezigheid standaardfunctietoetsen: Over applicaties/modules heen dient een uniform gebruik van functietoetsen te worden gehanteerd. Verder dient er veel met toetsencombinaties in plaats van met de muis gedaan te kunnen worden.
- Foutendetectie: Het systeem moet juiste en begrijpbare/duidelijke foutboodschappen tonen (signalering/blokkering).
- Toekomstige aanpassing functionaliteit: Het moet mogelijk zijn om de functionaliteit van het systeem in de toekomst aan te passen aan de wensen van de gebruiker (maatwerk).
- Documentatie: Elke aanpassing en/of uitbreiding van het systeem moet worden vastgelegd in de gebruikers- en de systeemhandleiding.
