{"id":70971,"date":"2024-05-16T20:00:20","date_gmt":"2024-05-16T11:00:20","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=70971"},"modified":"2024-06-07T12:26:16","modified_gmt":"2024-06-07T03:26:16","slug":"server-infrastructure-for-system-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development","title":{"rendered":"Hva er juridiske problemer knyttet til server- og infrastruktur i systemutvikling?"},"content":{"rendered":"\n<p>IT-systemer som brukes i bedrifter er p\u00e5 en m\u00e5te laget ved \u00e5 lage spesifikasjoner og design dokumenter, og skrive kildekoden som svarer til dette innholdet. Men et system fungerer faktisk bare n\u00e5r det ikke bare er denne myke siden, men ogs\u00e5 den fysiske datamaskinen, det vil si infrastrukturen. I denne artikkelen vil vi diskutere juridiske problemer som er dypt relatert til infrastrukturomr\u00e5det i systemutviklingsprosjekter.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Hva_er_infrastruktur_i_IT-systemer\" title=\"Hva er infrastruktur i IT-systemer?\">Hva er infrastruktur i IT-systemer?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Hvordan_infrastrukturproblemer_kan_sette_prosjekter_i_brann\" title=\"Hvordan infrastrukturproblemer kan sette prosjekter i brann\">Hvordan infrastrukturproblemer kan sette prosjekter i brann<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Hvordan_feil_serverstorrelse_kan_fore_til_konflikt\" title=\"Hvordan feil serverst\u00f8rrelse kan f\u00f8re til konflikt\">Hvordan feil serverst\u00f8rrelse kan f\u00f8re til konflikt<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Kjernen_i_saken_er_omfanget_av_leverandorens_forpliktelser_til_uklare_spesifikasjoner\" title=\"Kjernen i saken er omfanget av leverand\u00f8rens forpliktelser til uklare spesifikasjoner\">Kjernen i saken er omfanget av leverand\u00f8rens forpliktelser til uklare spesifikasjoner<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Tiltak_for_a_forhindre_problemer_forarsaket_av_feil_serverstorrelse\" title=\"Tiltak for \u00e5 forhindre problemer for\u00e5rsaket av feil serverst\u00f8rrelse\">Tiltak for \u00e5 forhindre problemer for\u00e5rsaket av feil serverst\u00f8rrelse<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Klarhet_i_kontrakten_om_hvem_som_er_ansvarlig_for_serverstorrelse\" title=\"Klarhet i kontrakten om hvem som er ansvarlig for serverst\u00f8rrelse\">Klarhet i kontrakten om hvem som er ansvarlig for serverst\u00f8rrelse<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Fullstendig_spesifisering_og_endringskontroll_av_utviklingskrav\" title=\"Fullstendig spesifisering og endringskontroll av utviklingskrav\">Fullstendig spesifisering og endringskontroll av utviklingskrav<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Velg_en_utviklingsmodell_som_passer_til_prosjektets_natur\" title=\"Velg en utviklingsmodell som passer til prosjektets natur\">Velg en utviklingsmodell som passer til prosjektets natur<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/no\/it\/server-infrastructure-for-system-development\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hva_er_infrastruktur_i_IT-systemer\"><\/span>Hva er infrastruktur i IT-systemer?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Teknikere som utf\u00f8rer systemutvikling kalles systemingeni\u00f8rer (SE). Utviklingsprosjekter starter med oppstr\u00f8msprosesser som \u00e5 lage spesifikasjoner og design dokumenter, og fortsetter med implementering av programvare og utf\u00f8relse av tester. I en bred forstand kan en systemingeni\u00f8r (SE) beskrives som en tekniker som h\u00e5ndterer alle disse n\u00f8dvendige oppgavene. Imidlertid kan det v\u00e6re at bedrifter og arbeidsplasser skiller mer spesifikt mellom navnene basert p\u00e5 arbeidsinnhold og omr\u00e5de. Begrepet infrastruktur ingeni\u00f8r refererer til teknikere som spesielt h\u00e5ndterer fysisk forberedelse av datamaskinens driftsmilj\u00f8 i forbindelse med utvikling og drift av IT-systemer. IT-systemer som brukes i bedrifter og p\u00e5 arbeidsplasser er p\u00e5 en m\u00e5te abstrakte konstruksjoner laget av kombinasjoner av kildekode. Men for at disse systemene skal kunne utf\u00f8re sin forventede rolle, er det n\u00f8dvendig med infrastrukturbygging, inkludert servere og nettverk. Praktisk systemutvikling g\u00e5r fremover med to hjul: implementering av programvare og kildekode, og forberedelse av infrastrukturen som st\u00f8tter driftsmilj\u00f8et. Dette perspektivet anses \u00e5 v\u00e6re viktig for \u00e5 forhindre uforutsette problemer.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvordan_infrastrukturproblemer_kan_sette_prosjekter_i_brann\"><\/span>Hvordan infrastrukturproblemer kan sette prosjekter i brann<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith-law.jp\/wp-content\/uploads\/2019\/10\/shutterstock_1532780735-1024x620.jpg\" alt=\"\" class=\"wp-image-5570\" \/><figcaption class=\"wp-element-caption\">\u00c5 fors\u00f8mme infrastrukturen kan ogs\u00e5 v\u00e6re en \u00e5rsak til &#8220;brann&#8221; risiko.<\/figcaption><\/figure>\n\n\n\n<p>I systemutviklingsprosjekter kan det skje at man fokuserer for mye p\u00e5 abstrakte programmer og kildekodedesign, og overser perspektivet med infrastrukturforberedelse. Men, en situasjon der begge deler ikke er p\u00e5 linje kan noen ganger bli en risiko for prosjektbrann.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvordan_feil_serverstorrelse_kan_fore_til_konflikt\"><\/span>Hvordan feil serverst\u00f8rrelse kan f\u00f8re til konflikt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>For eksempel, etter at all programimplementering og testing er fullf\u00f8rt, kan det vise seg at serverens prosesseringskapasitet til slutt ikke er tilstrekkelig, og systemet kan ikke t\u00e5le praktisk bruk. For \u00e5 forutsi hvor mye belastning systemet kan h\u00e5ndtere i driftsfasen og forberede infrastrukturen i henhold til systemets st\u00f8rrelse, kalles dette &#8220;sizing&#8221;. Det har faktisk v\u00e6rt tilfeller der feil serverst\u00f8rrelse har f\u00f8rt til problemer. (Selv om det til slutt ble l\u00f8st gjennom forlik, kan du referere til denne saken som et kjent eksempel.) For mer informasjon om hvordan konflikter mellom begge parter kan l\u00f8ses gjennom &#8220;forlik&#8221;, se f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/disputes-related-to-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/disputes-related-to-system-development[ja]<\/a><\/p>\n\n\n\n<p>At en konflikt ble l\u00f8st gjennom forlik betyr enkelt sagt at konflikten ble l\u00f8st gjennom &#8220;diskusjon&#8221; mellom begge parter. Derfor, i motsetning til n\u00e5r en dom er utstedt av en domstol, blir innholdet i forliket vanligvis ikke akkumulert som en rettspraksis, og det har en sterk individualitet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Kjernen_i_saken_er_omfanget_av_leverandorens_forpliktelser_til_uklare_spesifikasjoner\"><\/span>Kjernen i saken er omfanget av leverand\u00f8rens forpliktelser til uklare spesifikasjoner<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Imidlertid kan kjernen i slike konflikter ogs\u00e5 betraktes som &#8220;hvor mye ansvar skal leverand\u00f8ren ta for saker som ikke er spesifikt angitt i spesifikasjonene&#8221;. Med dette i betraktning, kan du f\u00e5 mange tips fra innholdet i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/system-development-specs-function\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/system-development-specs-function[ja]<\/a><\/p>\n\n\n\n<p>I artikkelen ovenfor forklarer vi hvor mye skj\u00f8nn leverand\u00f8ren skal ut\u00f8ve og ta ansvar for implementeringen av ting som ikke er oppf\u00f8rt i spesifikasjonene. Her forklarer vi at historien er veldig forskjellig mellom &#8220;skjermsiden&#8221; av saker som lett kan visualiseres i kravspesifikasjoner og grunnleggende design dokumenter (det s\u00e5kalte &#8220;frontend&#8221; -omr\u00e5det) og &#8220;logikksiden&#8221; som databasemigrasjon (det s\u00e5kalte &#8220;backend&#8221;, &#8220;database&#8221; -omr\u00e5det). Med andre ord, det er mer sannsynlig at bestilleren\/brukeren vil bli holdt ansvarlig for &#8220;skjermsiden&#8221; av omr\u00e5det der spesifikasjonsproblemer lett kan bekreftes av bestilleren\/brukeren (som vanligvis ikke har spesialisert kunnskap om systemutviklingsprosjekter). P\u00e5 den annen side, det er mer sannsynlig at &#8220;logikksiden&#8221; av problemet vil bli holdt ansvarlig for leverand\u00f8ren. Med dette i betraktning, siden serverst\u00f8rrelsesproblemet er et omr\u00e5de der det er vanskelig \u00e5 gjenkjenne problemet med mindre du er en teknisk ekspert, er det mer sannsynlig at det vil bli holdt ansvarlig for leverand\u00f8ren. Derfor, hvis du virkelig skal kjempe om dette i retten, med mindre det er noen positive omstendigheter for \u00e5 frita leverand\u00f8ren for ansvar, kan det forventes at dommen ofte vil v\u00e6re ugunstig for leverand\u00f8ren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Tiltak_for_a_forhindre_problemer_forarsaket_av_feil_serverstorrelse\"><\/span>Tiltak for \u00e5 forhindre problemer for\u00e5rsaket av feil serverst\u00f8rrelse<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith-law.jp\/wp-content\/uploads\/2019\/10\/shutterstock_1501344230-1024x717.jpg\" alt=\"\" class=\"wp-image-5572\" \/><figcaption class=\"wp-element-caption\">Vi vil forklare konkrete tiltak for \u00e5 forhindre problemer.<\/figcaption><\/figure>\n\n\n\n<p>For \u00e5 forhindre slike problemer, er det viktig \u00e5 koordinere arbeidet med implementering av programvare og skriving av kildekode med infrastrukturforberedelser. Konkrete tiltak kan inkludere f\u00f8lgende:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Klarhet_i_kontrakten_om_hvem_som_er_ansvarlig_for_serverstorrelse\"><\/span>Klarhet i kontrakten om hvem som er ansvarlig for serverst\u00f8rrelse<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Ikke bare i slike tilfeller, men mange konflikter relatert til systemutviklingsprosjekter oppst\u00e5r ofte fordi det er uklart hvem som har hvilken rolle mellom systemutviklingseksperter og brukere som er kjent med interne forhold. Selv om det er selvsagt at tett samarbeid mellom begge parter er n\u00f8dvendig for en jevn prosjektprogresjon, er det \u00f8nskelig \u00e5 klargj\u00f8re rollefordeling og ansvarsomr\u00e5de s\u00e5 mye som mulig i kontrakter p\u00e5 forh\u00e5nd.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Fullstendig_spesifisering_og_endringskontroll_av_utviklingskrav\"><\/span>Fullstendig spesifisering og endringskontroll av utviklingskrav<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I tillegg, hvis funksjonskravene som skal realiseres i utgangspunktet er vage, \u00f8ker risikoen for slike konflikter. Dette har b\u00e5de aspekter av \u00e5 klargj\u00f8re spesifikasjoner i den opprinnelige kravdefinisjonsfasen og endringskontroll i l\u00f8pet av prosjektet. Hvordan man skal h\u00e5ndtere spesifikasjonsendringer i l\u00f8pet av prosjektet er forklart i detalj i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/howto-manage-change-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/howto-manage-change-in-system-development[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Velg_en_utviklingsmodell_som_passer_til_prosjektets_natur\"><\/span>Velg en utviklingsmodell som passer til prosjektets natur<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I tillegg, og dette er dypt relatert til de to foreg\u00e5ende tiltakene, er det viktig \u00e5 velge en passende utviklingsmodell for systemutviklingsprosjektet basert p\u00e5 dets natur og skala. Generelt, hvis utviklingen av et system av en viss st\u00f8rrelse der serverst\u00f8rrelse kan bli viktig, \u00f8ker fordelene ved \u00e5 adoptere en vannfallsmodell som er egnet for \u00e5 klargj\u00f8re spesifikasjoner og ansvarsomr\u00e5der. For mer informasjon om valg av en passende utviklingsmodell basert p\u00e5 prosjektets natur, se f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith-law.jp\/corporate\/legal-merits-and-demerits-of-development-model\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith-law.jp\/corporate\/legal-merits-and-demerits-of-development-model[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppsummering\"><\/span>Oppsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Problemer som oppst\u00e5r fra infrastrukturforberedelser kan lett bli oversett, men er avgj\u00f8rende for en jevn fremdrift av systemutviklingsprosjekter. Det kan v\u00e6re en betydelig belastning for de som ikke er tekniske eksperter \u00e5 v\u00e6re oppmerksomme p\u00e5 problemer rundt infrastrukturen. Imidlertid kan forebyggende tiltak for slike problemer sies \u00e5 v\u00e6re en forlengelse av grunnleggende tiltak som &#8220;klargj\u00f8ring av spesifikasjoner\/endringskontroll&#8221;, &#8220;klargj\u00f8ring av roller\/ansvarsomr\u00e5der&#8221;, og &#8220;valg av utviklingsmodell som passer til prosjektets st\u00f8rrelse og budsjett&#8221;. Det f\u00f8rste punktet som de som jobber med bedriftsjuridiske saker b\u00f8r forst\u00e5, er at grunnleggende forebyggende juridiske tiltak kan v\u00e6re fullt ut anvendelige selv for infrastrukturproblemer. Videre, for IT-teknikere, er det viktig \u00e5 forst\u00e5 at infrastrukturproblemer kan bli en alvorlig risiko for prosjektbrann, og det er viktig \u00e5 kunne h\u00e5ndtere arbeidet jevnt.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>IT-systemer som brukes i bedrifter er p\u00e5 en m\u00e5te laget ved \u00e5 lage spesifikasjoner og design dokumenter, og skrive kildekoden som svarer til dette innholdet. Men et system fungerer faktisk bare n\u00e5r det [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":72007,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70971"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=70971"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70971\/revisions"}],"predecessor-version":[{"id":72006,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70971\/revisions\/72006"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/72007"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=70971"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=70971"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=70971"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}