Anbefalinger til offentlige IT-systemer - Versionshistorie

KS: /* Brug åbne standarder */

2017-10-25T18:05:07Z

‎Brug åbne standarder

KS: /* Del systemet op */

2017-10-25T18:04:24Z

‎Del systemet op

KS med 19. apr 2017, 13:14

2017-04-19T13:14:27Z

KS med 19. apr 2017, 13:13

2017-04-19T13:13:27Z

KS med 19. apr 2017, 13:12

2017-04-19T13:12:23Z

KS: Oprettede siden med 'Fagforeningen Prosa og brancheforeninge KLID har de følgende anbefalinger til offentlige IT-systemer Del systemet op De fleste IT-systemer i 100 mio kr-klassen kan deles o...'

2017-04-19T13:08:05Z

Oprettede siden med 'Fagforeningen Prosa og brancheforeninge KLID har de følgende anbefalinger til offentlige IT-systemer Del systemet op De fleste IT-systemer i 100 mio kr-klassen kan deles o...'

Ny side

Fagforeningen Prosa og brancheforeninge KLID har de følgende anbefalinger til offentlige IT-systemer

Del systemet op
De fleste IT-systemer i 100 mio kr-klassen kan deles op i mindre dele. Delene bør være så små, at det ikke er en skandale, hvis enkelte dele fejler og må skrottes. En tommelfingerregel er at dele højst må koste 5 mio kr. Kristian Jensen har allerede været inde på tilsvarende tanker.

· Start med de lavesthængende frugter
Ved først at lave de dele, som kan give den største effekt med mindst muligt arbejde, kan man hurtigt få noget sat i drift. Dette kan så igen medføre, at man høster erfaringer, så man bliver klogere på, hvad systemet egentlig skal kunne.

· Lav ikke en detaljeret kravspecifikation på hele systemet fra start
Dag 1 er den dag, hvor man ved allermindst om, hvad systemet skal kunne. Det giver derfor mening at vente med kravspecifikation så længe som muligt. Så start med kravspecifikation til den første del, og høst erfaringer med den del, før man laver kravspecifikation til næste del.

· Rammearkitekturen skal være på plads
For at kunne opdele store systemer i mindre dele er det nødvendigt at have et overblik hvad systemet overordnet skal kunne for at kunne beslutte snitfladerne mellem de forskellige dele. Det betyder ikke, at man skal kende alle detaljer, men i stedet kun den overordnede ramme.

· Vær ikke bange for at skrotte dele
Hvis hver del i sig selv er lille, så er der ingen skam i at skrotte dele, som viser sig at være fejlskud eller som bliver forældede.

· Kildekoden skal være ejet af det offentlige
Kildekode, hvis udvikling er betalt af det offentlige, skal være ejet af det offentlige. Ved at eje kildekoden giver det køberen mulighed for at genbruge dele fra systemet i andre systemer og man undgår at være låst til én leverandør, men styrker i stedet den fri konkurrence. Det kan betyde besparelse, når nye systemer skal udvikles - selv hvis det nye system udvikles af en anden leverandør.

· Data må ikke ejes af leverandøren
Data må ikke lægges hos leverandøren på en sådan måde, at leverandøren kan kræve betaling for at få adgang til det offentliges data.

· =Brug åbne standarder
=Brug udvekslingsformater som er åbne og veldokumenterede og gerne standardiserede. Så bliver det nemmere at udskifte en forældet del med en ny del uden at skulle skrotte hele systemet.

version 2017-02-27T20:31

←Ældre version		Versionen fra 25. okt 2017, 18:05
Linje 25:		Linje 25:
	Brug udvekslingsformater som er åbne og veldokumenterede og gerne standardiserede. Så bliver det nemmere at udskifte en forældet del med en ny del uden at skulle skrotte hele systemet.		Brug udvekslingsformater som er åbne og veldokumenterede og gerne standardiserede. Så bliver det nemmere at udskifte en forældet del med en ny del uden at skulle skrotte hele systemet.

−	version 2017-02-~~27T20~~:31	+	version 2017-10-25T20:05

@@ Linje 2: / Linje 2: @@
 ==Del systemet op==
-De fleste IT-systemer i 100 mio kr-klassen kan deles op i mindre dele. Delene bør være så små, at det ikke er en skandale, hvis enkelte dele fejler og må skrottes. En tommelfingerregel er at dele højst må koste 5 mio kr. Kristian Jensen har allerede været inde på tilsvarende tanker.
+De fleste IT-systemer i 100 mio kr-klassen kan deles op i mindre dele. Delene bør være så små, at det ikke er en skandale, hvis enkelte dele fejler og må skrottes. En tommelfingerregel er at dele højst må koste 5 mio kr.
 ==Start med de lavesthængende frugter==

@@ Linje 19: / Linje 19: @@
 Kildekode, hvis udvikling er betalt af det offentlige, skal være ejet af det offentlige. Ved at eje kildekoden giver det køberen mulighed for at genbruge dele fra systemet i andre systemer og man undgår at være låst til én leverandør, men styrker i stedet den fri konkurrence. Det kan betyde besparelse, når nye systemer skal udvikles - selv hvis det nye system udvikles af en anden leverandør.
-Data må ikke ejes af leverandøren==
+==Data må ikke ejes af leverandøren==
 Data må ikke lægges hos leverandøren på en sådan måde, at leverandøren kan kræve betaling for at få adgang til det offentliges data.
-Brug åbne standarder==
+==Brug åbne standarder==
 Brug udvekslingsformater som er åbne og veldokumenterede og gerne standardiserede. Så bliver det nemmere at udskifte en forældet del med en ny del uden at skulle skrotte hele systemet.
 version 2017-02-27T20:31

@@ Linje 4: / Linje 4: @@
 De fleste IT-systemer i 100 mio kr-klassen kan deles op i mindre dele. Delene bør være så små, at det ikke er en skandale, hvis enkelte dele fejler og må skrottes. En tommelfingerregel er at dele højst må koste 5 mio kr. Kristian Jensen har allerede været inde på tilsvarende tanker.
-·        ==Start med de lavesthængende frugter==
+==Start med de lavesthængende frugter==
 Ved først at lave de dele, som kan give den største effekt med mindst muligt arbejde, kan man hurtigt få noget sat i drift. Dette kan så igen medføre, at man høster erfaringer, så man bliver klogere på, hvad systemet egentlig skal kunne.
-·        ==Lav ikke en detaljeret kravspecifikation på hele systemet fra start==
+==Lav ikke en detaljeret kravspecifikation på hele systemet fra start==
 Dag 1 er den dag, hvor man ved allermindst om, hvad systemet skal kunne. Det giver derfor mening at vente med kravspecifikation så længe som muligt. Så start med kravspecifikation til den første del, og høst erfaringer med den del, før man laver kravspecifikation til næste del.
-·        ==Rammearkitekturen skal være på plads==
+==Rammearkitekturen skal være på plads==
 For at kunne opdele store systemer i mindre dele er det nødvendigt at have et overblik hvad systemet overordnet skal kunne for at kunne beslutte snitfladerne mellem de forskellige dele. Det betyder ikke, at man skal kende alle detaljer, men i stedet kun den overordnede ramme.
-·        ==Vær ikke bange for at skrotte dele==
+==Vær ikke bange for at skrotte dele==
 Hvis hver del i sig selv er lille, så er der ingen skam i at skrotte dele, som viser sig at være fejlskud eller som bliver forældede.
-·        ==Kildekoden skal være ejet af det offentlige==
+==Kildekoden skal være ejet af det offentlige==
 Kildekode, hvis udvikling er betalt af det offentlige, skal være ejet af det offentlige. Ved at eje kildekoden giver det køberen mulighed for at genbruge dele fra systemet i andre systemer og man undgår at være låst til én leverandør, men styrker i stedet den fri konkurrence. Det kan betyde besparelse, når nye systemer skal udvikles - selv hvis det nye system udvikles af en anden leverandør.
-·        ==Data må ikke ejes af leverandøren==
+Data må ikke ejes af leverandøren==
 Data må ikke lægges hos leverandøren på en sådan måde, at leverandøren kan kræve betaling for at få adgang til det offentliges data.
-·        ==Brug åbne standarder==
+Brug åbne standarder==
 Brug udvekslingsformater som er åbne og veldokumenterede og gerne standardiserede. Så bliver det nemmere at udskifte en forældet del med en ny del uden at skulle skrotte hele systemet.
 version 2017-02-27T20:31