{"id":60396,"date":"2024-03-05T21:12:13","date_gmt":"2024-03-05T12:12:13","guid":{"rendered":"https:\/\/monolith.law\/da\/?p=60396"},"modified":"2024-03-18T16:56:06","modified_gmt":"2024-03-18T07:56:06","slug":"server-infrastructure-for-system-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/da\/it\/server-infrastructure-for-system-development","title":{"rendered":"Hvad er de juridiske problemer forbundet med server- og infrastruktur i systemudvikling?"},"content":{"rendered":"\n<p>IT-systemer, der anvendes i virksomheder, er p\u00e5 en m\u00e5de skabt ved at lave specifikations- og design-dokumenter og skrive kildekode, der svarer til indholdet. Men et system fungerer faktisk kun med den fysiske computer, det vil sige infrastrukturen, ikke kun denne bl\u00f8de side. I denne artikel vil vi diskutere juridiske sp\u00f8rgsm\u00e5l, der er dybt relateret til infrastrukturomr\u00e5det i systemudviklingsprojekter.<\/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\/da\/it\/server-infrastructure-for-system-development\/#Hvad_er_infrastrukturen_i_et_IT-system\" title=\"Hvad er infrastrukturen i et IT-system?\">Hvad er infrastrukturen i et IT-system?<\/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\/da\/it\/server-infrastructure-for-system-development\/#Hvad_er_de_konkrete_situationer_hvor_infrastrukturproblemer_kan_saette_et_projekt_i_brand\" title=\"Hvad er de konkrete situationer, hvor infrastrukturproblemer kan s\u00e6tte et projekt i brand?\">Hvad er de konkrete situationer, hvor infrastrukturproblemer kan s\u00e6tte et projekt i brand?<\/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\/da\/it\/server-infrastructure-for-system-development\/#Hvad_er_de_sager_hvor_fejl_i_serverstorrelse_kan_forarsage_konflikter\" title=\"Hvad er de sager, hvor fejl i serverst\u00f8rrelse kan for\u00e5rsage konflikter?\">Hvad er de sager, hvor fejl i serverst\u00f8rrelse kan for\u00e5rsage konflikter?<\/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\/da\/it\/server-infrastructure-for-system-development\/#Essensen_af_sagen_er_omfanget_af_leverandorens_forpligtelser_over_for_uklare_specifikationer\" title=\"Essensen af sagen er omfanget af leverand\u00f8rens forpligtelser over for uklare specifikationer\">Essensen af sagen er omfanget af leverand\u00f8rens forpligtelser over for uklare specifikationer<\/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\/da\/it\/server-infrastructure-for-system-development\/#Foranstaltninger_til_at_forhindre_problemer_forarsaget_af_fejl_i_serverstorrelsesbestemmelse\" title=\"Foranstaltninger til at forhindre problemer for\u00e5rsaget af fejl i serverst\u00f8rrelsesbestemmelse\">Foranstaltninger til at forhindre problemer for\u00e5rsaget af fejl i serverst\u00f8rrelsesbestemmelse<\/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\/da\/it\/server-infrastructure-for-system-development\/#Klarlaeg_ansvar_for_serverstorrelsesbestemmelse_i_kontrakten\" title=\"Klarl\u00e6g ansvar for serverst\u00f8rrelsesbestemmelse i kontrakten\">Klarl\u00e6g ansvar for serverst\u00f8rrelsesbestemmelse i kontrakten<\/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\/da\/it\/server-infrastructure-for-system-development\/#Specificer_udviklingskravene_fuldt_ud_og_handter_aendringer_effektivt\" title=\"Specificer udviklingskravene fuldt ud og h\u00e5ndter \u00e6ndringer effektivt\">Specificer udviklingskravene fuldt ud og h\u00e5ndter \u00e6ndringer effektivt<\/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\/da\/it\/server-infrastructure-for-system-development\/#Vaelg_en_udviklingsmodel_der_passer_til_projektets_karakter\" title=\"V\u00e6lg en udviklingsmodel, der passer til projektets karakter\">V\u00e6lg en udviklingsmodel, der passer til projektets karakter<\/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\/da\/it\/server-infrastructure-for-system-development\/#Opsummering\" title=\"Opsummering\">Opsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvad_er_infrastrukturen_i_et_IT-system\"><\/span>Hvad er infrastrukturen i et IT-system?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Teknikere, der udf\u00f8rer systemudvikling, kaldes systemingeni\u00f8rer (SE). Udviklingsprojekter starter med opstr\u00f8msprocesser som oprettelse af specifikationer og design dokumenter, og forts\u00e6tter med implementering af programmer og udf\u00f8relse af tests. I en bredere forstand kan en systemingeni\u00f8r (SE) beskrives som en tekniker, der h\u00e5ndterer alle de opgaver, der er n\u00f8dvendige for disse processer. Afh\u00e6ngigt af virksomheden eller arbejdspladsen kan der dog v\u00e6re yderligere specifikke betegnelser baseret p\u00e5 de opgaver og omr\u00e5der, de er ansvarlige for. Betegnelsen infrastruktur ingeni\u00f8r refererer til teknikere, der specifikt h\u00e5ndterer opgaver relateret til udvikling og drift af IT-systemer, is\u00e6r ved at forberede det fysiske computerdriftsmilj\u00f8. IT-systemer, der bruges i virksomheder og p\u00e5 arbejdspladser, er p\u00e5 en m\u00e5de abstrakte konstruktioner, der best\u00e5r af kombinationer af kildekode. Men for at disse systemer kan udf\u00f8re deres forventede roller, er det afg\u00f8rende at opbygge infrastrukturen omkring servere og netv\u00e6rk. Praktisk systemudvikling skrider frem p\u00e5 to hjul: implementering af programkildekode og forberedelse af infrastrukturen, der underst\u00f8tter dens driftsmilj\u00f8. Dette perspektiv anses for at v\u00e6re vigtigt for at forhindre uforudsete problemer.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvad_er_de_konkrete_situationer_hvor_infrastrukturproblemer_kan_saette_et_projekt_i_brand\"><\/span>Hvad er de konkrete situationer, hvor infrastrukturproblemer kan s\u00e6tte et projekt i brand?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/10\/shutterstock_1532780735-1024x620.jpg\" alt=\"\" class=\"wp-image-5570\" \/><figcaption class=\"wp-element-caption\">At fors\u00f8mme vedligeholdelsen af infrastrukturen kan ogs\u00e5 v\u00e6re en \u00e5rsag til &#8216;brand&#8217; risiko.<\/figcaption><\/figure>\n\n\n\n<p>I systemudviklingsprojekter kan det ske, at man fokuserer for meget p\u00e5 abstrakte programmer og kildekode design, og overser vedligeholdelsen af infrastrukturen. Men hvis disse to aspekter ikke er i sync, kan det potentielt f\u00f8re til en risiko for internetflammer for projektet.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvad_er_de_sager_hvor_fejl_i_serverstorrelse_kan_forarsage_konflikter\"><\/span>Hvad er de sager, hvor fejl i serverst\u00f8rrelse kan for\u00e5rsage konflikter?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>For eksempel, efter at alle programmerings- og testopgaver er afsluttet, kan det vise sig, at serverens ydeevne ikke er tilstr\u00e6kkelig, og systemet kan ikke h\u00e5ndtere den praktiske anvendelse. Dette kaldes &#8220;sizing&#8221;, hvor man forudser, hvor meget belastning systemet vil v\u00e6re under i driftsfasen, og tilpasser infrastrukturen til systemets st\u00f8rrelse. Der har v\u00e6ret tilf\u00e6lde, hvor fejl i serverst\u00f8rrelsen har f\u00f8rt til problemer. (Selvom det blev l\u00f8st gennem forlig, kan du referere til denne sag som et kendt eksempel.) For mere information om l\u00f8sning af konflikter mellem parterne gennem &#8220;forlig&#8221;, se nedenst\u00e5ende artikel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/disputes-related-to-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/disputes-related-to-system-development[ja]<\/a><\/p>\n\n\n\n<p>At en konflikt er blevet l\u00f8st gennem forlig betyder simpelthen, at konflikten er blevet l\u00f8st gennem &#8220;diskussion&#8221; mellem parterne. Derfor, i mods\u00e6tning til n\u00e5r en dom er afsagt af en domstol, bliver indholdet af forliget normalt ikke akkumuleret som en pr\u00e6cedens, men er mere individuelt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Essensen_af_sagen_er_omfanget_af_leverandorens_forpligtelser_over_for_uklare_specifikationer\"><\/span>Essensen af sagen er omfanget af leverand\u00f8rens forpligtelser over for uklare specifikationer<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Imidlertid kan essensen af s\u00e5danne konflikter ogs\u00e5 ses som &#8220;hvor meget ansvar skal leverand\u00f8ren b\u00e6re for ting, der ikke er specificeret i specifikationerne&#8221;. Med dette i tankerne, kan du f\u00e5 mange tips fra indholdet af nedenst\u00e5ende artikel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/system-development-specs-function\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/system-development-specs-function[ja]<\/a><\/p>\n\n\n\n<p>I ovenst\u00e5ende artikel forklarer vi, hvor meget sk\u00f8n leverand\u00f8ren skal ud\u00f8ve og p\u00e5tage sig implementeringsforpligtelsen for ting, der ikke er angivet i specifikationerne. Her forklarer vi, at historien er meget forskellig mellem &#8220;sk\u00e6rm-siden&#8221; emner, der let kan visualiseres i kravspecifikationer og grundl\u00e6ggende design dokumenter (det s\u00e5kaldte &#8220;frontend&#8221; omr\u00e5de), og &#8220;logik-siden&#8221; som data migration (det s\u00e5kaldte &#8220;backend&#8221;, &#8220;database&#8221; omr\u00e5de). Det vil sige, jo mere &#8220;sk\u00e6rm-siden&#8221; omr\u00e5det, hvor specifikationsproblemer let kan bekr\u00e6ftes af ordregiveren\/brugeren (som normalt ikke har specialiseret viden om systemudviklingsprojekter), jo mere tilb\u00f8jelig er ordregiveren\/brugeren til at blive holdt ansvarlig. P\u00e5 den anden side, &#8220;logik-siden&#8221; problemer er mere tilb\u00f8jelige til at blive holdt ansvarlig af leverand\u00f8ren. Med dette i tankerne, kan serverst\u00f8rrelsesproblemer, som er sv\u00e6re at genkende, medmindre man er en teknisk ekspert, betragtes som et omr\u00e5de, hvor leverand\u00f8ren er mere tilb\u00f8jelig til at blive holdt ansvarlig. Derfor, hvis dette punkt skulle blive seri\u00f8st bestridt i retten, kan det forventes, at dommen ofte vil v\u00e6re ugunstig for leverand\u00f8ren, medmindre der er overbevisende omst\u00e6ndigheder for at fritage leverand\u00f8ren for ansvar.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Foranstaltninger_til_at_forhindre_problemer_forarsaget_af_fejl_i_serverstorrelsesbestemmelse\"><\/span>Foranstaltninger til at forhindre problemer for\u00e5rsaget af fejl i serverst\u00f8rrelsesbestemmelse<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/10\/shutterstock_1501344230-1024x717.jpg\" alt=\"\" class=\"wp-image-5572\" \/><figcaption class=\"wp-element-caption\">Vi vil forklare konkrete foranstaltninger til forebyggelse af problemer.<\/figcaption><\/figure>\n\n\n\n<p>For at forhindre de tidligere n\u00e6vnte problemer er det vigtigt at koordinere arbejdet med implementering af programmer, skrivning af kildekode og infrastrukturel forberedelse. Konkrete foranstaltninger kan omfatte f\u00f8lgende:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Klarlaeg_ansvar_for_serverstorrelsesbestemmelse_i_kontrakten\"><\/span>Klarl\u00e6g ansvar for serverst\u00f8rrelsesbestemmelse i kontrakten<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Ikke kun i disse tilf\u00e6lde, men mange konflikter omkring systemudviklingsprojekter opst\u00e5r ofte, n\u00e5r rollefordelingen mellem systemudviklingseksperter og brugere, der er bekendt med interne forhold, er uklar. Selvom det er selvf\u00f8lgeligt, at t\u00e6t samarbejde mellem begge parter er n\u00f8dvendigt for en gnidningsl\u00f8s projektudvikling, er det \u00f8nskeligt at g\u00f8re rollefordelingen og ansvarsomr\u00e5det s\u00e5 klart som muligt i kontrakten p\u00e5 forh\u00e5nd.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Specificer_udviklingskravene_fuldt_ud_og_handter_aendringer_effektivt\"><\/span>Specificer udviklingskravene fuldt ud og h\u00e5ndter \u00e6ndringer effektivt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Desuden, hvis de funktionelle krav, der skal realiseres, er vage, \u00f8ges risikoen for konflikter. Dette involverer b\u00e5de klarl\u00e6ggelse af specifikationer i den oprindelige kravdefineringsfase og \u00e6ndringsstyring i l\u00f8bet af projektet. Hvordan man skal h\u00e5ndtere specifikations\u00e6ndringer i l\u00f8bet af projektet er detaljeret forklaret i f\u00f8lgende artikel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/howto-manage-change-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/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=\"Vaelg_en_udviklingsmodel_der_passer_til_projektets_karakter\"><\/span>V\u00e6lg en udviklingsmodel, der passer til projektets karakter<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Desuden, og dette er dybt forbundet med de to ovenst\u00e5ende foranstaltninger, er det vigtigt at v\u00e6lge en passende udviklingsmodel for systemudviklingsprojekter baseret p\u00e5 deres karakter og skala. Generelt, hvis det er udviklingen af et system af en vis st\u00f8rrelse, hvor serverst\u00f8rrelsesbestemmelse kan blive vigtig, kan det v\u00e6re fordelagtigt at anvende vandfaldsmodellen, der er velegnet til at klarl\u00e6gge specifikationer og ansvarsomr\u00e5der. For en detaljeret forklaring p\u00e5 valg af en passende udviklingsmodel baseret p\u00e5 projektets karakter, se f\u00f8lgende artikel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/legal-merits-and-demerits-of-development-model\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/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=\"Opsummering\"><\/span>Opsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Problemer, der opst\u00e5r fra infrastrukturens milj\u00f8forberedelse, kan let blive overset i bestr\u00e6belserne p\u00e5 at sikre en gnidningsl\u00f8s fremdrift af systemudviklingsprojekter. Det kan v\u00e6re en betydelig byrde for ikke-tekniske eksperter at skulle v\u00e6re opm\u00e6rksomme p\u00e5 problemer omkring infrastrukturen. Dog kan forebyggende foranstaltninger mod s\u00e5danne problemer ses som en forl\u00e6ngelse af grundl\u00e6ggende tiltag som &#8216;klar specifikation \/ grundig \u00e6ndringsstyring&#8217;, &#8216;klar rolle \/ ansvarsomr\u00e5de&#8217; og &#8216;valg af udviklingsmodel tilpasset projektets st\u00f8rrelse og budget&#8217;. Det f\u00f8rste, som folk involveret i virksomhedens juridiske anliggender b\u00f8r forst\u00e5, er, at grundlaget for forebyggende jura kan v\u00e6re fuldt ud anvendeligt p\u00e5 infrastrukturproblemer. Desuden, for IT-teknikere, er det vigtigt at forst\u00e5, at infrastrukturproblemer kan blive en alvorlig risiko for projektets nedbr\u00e6nding, og at det er vigtigt at styre arbejdet effektivt.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>IT-systemer, der anvendes i virksomheder, er p\u00e5 en m\u00e5de skabt ved at lave specifikations- og design-dokumenter og skrive kildekode, der svarer til indholdet. Men et system fungerer faktisk kun med den [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":61614,"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\/da\/wp-json\/wp\/v2\/posts\/60396"}],"collection":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/comments?post=60396"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts\/60396\/revisions"}],"predecessor-version":[{"id":61615,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts\/60396\/revisions\/61615"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/media\/61614"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/media?parent=60396"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/categories?post=60396"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/tags?post=60396"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}