Hvis jeg gætter på at netop CPR registeret, som den mest central partner i samspillende offentlige IT systemer, ligger foran, må resten se sløjt ud...
Ogg....... jeg tror du har ret, til dels baseret på viden.
menu close Teknologiens Mediehus
Der dukkede et interessant spørgsmål op i efterdønningerne fra POLSAG: Kender folk i branchen forskel på en kravspecifikation og et Interface Control Document ?
Hvis man f.eks skal bygge en GPS modtager, findes der et glimrende ICD der fortæller præcis hvad man får i hovedet fra satellitterne.
Ideen i et ICD er at beskrive grænsefladen og kun grænsefladen. Så længe de overholder ICD'en, kan USAF for den sags skyld producere GPS signalerne med trænede aber og morsenøgler hvis de har lyst og deres kravspecifikation til satellit-producenten kan derfor koncentrere sig om det væsentlige uden at producenterne af GPS modtagere behøver at tænke på hvilken model satellit der sender hvilket signal.
På CPR's hjemmeside ligger der noget der mindre ret meget om en ICD for "CPR Direkte"
Men det er ikke nogen god ICD.
For det første er det en fejl at man henviser til en specifik IBM implementering af TLS/SSL standarden, her burde man have henvist til de relevante standarder i stedet, så man ikke bliver nødt til at ændre ICD'en hvis man en dag skifter mainframen ud med anden teknologi.
For det andet har deres "standard-klient" intet at gøre i et ICD, den skal naturligvis have sit eget dokument for den har intet med definitionen af interfacet at gøre.
For det tredje er der utroligt meget der er dårligt defineret. F.eks felttyperne "A" og "N", det er sikkert "Alfanumerisk" og "Numerisk", men hvor er der en klar definition af hvad det dækker over ? Hvilket tegnsæt ? Oktale eller floating-point tal ? Det ville være fint at henvise til et andet dokument for definitionen, men jeg kan ikke få øje på hverken definition eller henvisning.
Endelig bekymrer det mig at der dukker feltnavne som "BRUDER_ID" op, det tyder ikke på at dokumentet checket særlig godt.
Jeg havde egentlig forventet bedre af Danmarks mest centrale register-facilitet.
Hvis jeg gætter på at netop CPR registeret, som den mest central partner i samspillende offentlige IT systemer, ligger foran, må resten se sløjt ud...
phk
Hvis jeg gætter på at netop CPR registeret, som den mest central partner i samspillende offentlige IT systemer, ligger foran, må resten se sløjt ud...
Ogg....... jeg tror du har ret, til dels baseret på viden.
BRUDER_ID er en god en. Eller at man bruger faste ip-adresser i stedet for navne. Hvis man så ville skifte til IPv6 på et tidspunkt. Svaret på A og N findes sikkert ved at se på COBOL itself (som er det CPR er implementeret i, hvis jeg husker det rigtigt). COBOL har jo ingen andre datatyper end alphanumerisk og numerisk + nogle angivelser af længde/pattern. Men enig, at man lige kunne have henvist til det.
Ad offentlige ICD'er: EU plejer at levere ganske glimrende ICD'er med datatyper, valideringsregler, stub-webservices til test, beskrivelsen af godkendelsesproceduren før tilslutning, eksempler, mv.
Jeg tror A/N problematikken måske er noget IBM legacy, jeg sidder p.t. med et andet IBM system, hvor kravspecifikationen også referer til A og N som datatyper, men aldrig hvad disse må indeholde. (Spec. skrevet tilbage i midt 80'erne)
Denne specifikation indeholder i øvrigt også referencer til "Epson maskinen", måske et spørgsmål om alderen på dokumentet?
På CPR's hjemmeside ligger der noget der mindre ret meget om en ICD for "CPR Direkte"
Men det er ikke nogen god ICD.
Er der nogen der har et link til en god ICD?
Ideen i et ICD er at beskrive grænsefladen og kun grænsefladen
Tænker du på sådan noget som OIO-XML? Der er da grænsefladedefinitioner ad libitum.
Ellers fik dit indlæg tankerne til at falde på gamle standat, der benyttes til at udveksle data mellem miljøaktører. Det blev vist startet op et sted nede i firserne og er et råtekstformat i tre dele: Headeren, der indeholder metadata om standatversion, tegnsæt, datoformat osv; definitionen, som fortæller hvilke data der kommer og i hvilken rækkefølge og til sidst datadelen, der så gerne skulle leve op til det foregående.
GPS ICD'en som jeg linkede til er faktisk en af de bedste jeg kender, prøv at kigge lidt i det.
Mit ukvalificerede gæt er, at der for hver indianer der gerne vil lave en ICD, står 10(+/-) høvdinge der synes at det er noget overflødigt pjat at bruge tid på, "da vi jo aldrig kommer til at skifte et delsystem ud med dresserede aber."
Det er da smart, hvis man kan logge på ved at oplyse, hvem ens tyske bror er :-P
Nu er du er ved spørgsmålene, hvad er så forskellen på et ICD og et IRD (Interface Requirements Document)?
Et IRD siger hvilke krav du stiller til et andet systems interface, ofte til et system der ikke existerer (i den ønskede form) endnu.
Et ICD siger hvilket interface andre systemer kan forvente fra dit system.
Forskellen er lidt hvilken vej pilen vender og hvem der har magt til at få hvem til at skrive under på hvad.
Ellers fik dit indlæg tankerne til at falde på gamle standat, der benyttes til at udveksle data mellem miljøaktører. Det blev vist startet op et sted nede i firserne og er et råtekstformat i tre dele: Headeren, der indeholder metadata om standatversion, tegnsæt, datoformat osv; definitionen, som fortæller hvilke data der kommer og i hvilken rækkefølge og til sidst datadelen, der så gerne skulle leve op til det foregående.
Og det har Miljøstyrelsen så ødelagt, i hvert fald fsva. affaldsområdet - nu skal der indberettes i komma separeret format, baseret på Excel skabeloner!
Der er vel ingen grund til at fortælle at det nu sejler.
