Forskel mellem versioner af "Anbefalinger til offentlige IT-systemer"
KS (diskussion | bidrag) (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...') |
KS (diskussion | bidrag) |
||
| Linje 1: | Linje 1: | ||
| − | Fagforeningen Prosa og | + | Fagforeningen Prosa og brancheforeningen KLID har de følgende anbefalinger til offentlige IT-systemer |
| − | Del systemet op | + | ==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. 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. | 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. | 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. | 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. | 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. | 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. | 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. | + | 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-02-27T20:31 | ||
Versionen fra 19. apr 2017, 14:12
Fagforeningen Prosa og brancheforeningen 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
