{"id":61450,"date":"2023-12-08T20:55:29","date_gmt":"2023-12-08T11:55:29","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=61450"},"modified":"2024-01-04T21:13:18","modified_gmt":"2024-01-04T12:13:18","slug":"legal-and-contract-issues-of-agile-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development","title":{"rendered":"Hva er juridiske og kontraktsmessige problemer knyttet til smidig utvikling?"},"content":{"rendered":"\n<p>Det finnes metodikker for hvordan systemutvikling skal gjennomf\u00f8res. Den mest klassiske og generelle er vannfallsmodellen, og mange juridiske b\u00f8ker som behandler systemutvikling, diskuterer dette basert p\u00e5 denne modellen. I denne artikkelen vil vi diskutere hvilke juridiske problemer som kan oppst\u00e5 i systemutvikling basert p\u00e5 den agile utviklingsmodellen, som det kan v\u00e6re vanskelig \u00e5 finne informasjon om fra b\u00f8ker og lignende.<\/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\/legal-and-contract-issues-of-agile-development\/#Agil_utviklingsmodell_og_juridiske_forhold\" title=\"Agil utviklingsmodell og juridiske forhold\">Agil utviklingsmodell og juridiske forhold<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development\/#Hva_er_en_modell_i_systemutvikling\" title=\"Hva er en modell i systemutvikling?\">Hva er en modell i systemutvikling?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development\/#Egenskapene_til_den_agile_utviklingsmodellen\" title=\"Egenskapene til den agile utviklingsmodellen\">Egenskapene til den agile utviklingsmodellen<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development\/#Hvordan_handtere_dokument-_og_endringsstyring_i_smidig_utvikling\" title=\"Hvordan h\u00e5ndtere dokument- og endringsstyring i smidig utvikling\">Hvordan h\u00e5ndtere dokument- og endringsstyring i smidig utvikling<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development\/#Viktigheten_av_dokumentstyring\" title=\"Viktigheten av dokumentstyring\">Viktigheten av dokumentstyring<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development\/#Opprettelse_av_kontaktutvalg_er_effektivt_for_dokumenthandtering\" title=\"Opprettelse av kontaktutvalg er effektivt for dokumenth\u00e5ndtering\">Opprettelse av kontaktutvalg er effektivt for dokumenth\u00e5ndtering<\/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\/legal-and-contract-issues-of-agile-development\/#Utnytte_kontaktutvalget_for_endringsstyring\" title=\"Utnytte kontaktutvalget for endringsstyring\">Utnytte kontaktutvalget for endringsstyring<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/no\/it\/legal-and-contract-issues-of-agile-development\/#Forstaelse_av_plikter_som_aerlighet_og_god_tro_blir_utfordret\" title=\"Forst\u00e5else av plikter som \u00e6rlighet og god tro blir utfordret\">Forst\u00e5else av plikter som \u00e6rlighet og god tro blir utfordret<\/a><\/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\/legal-and-contract-issues-of-agile-development\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Agil_utviklingsmodell_og_juridiske_forhold\"><\/span>Agil utviklingsmodell og juridiske forhold<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_321052328-1024x683.jpg\" alt=\"\" class=\"wp-image-5414\" \/><figcaption class=\"wp-element-caption\">Vi vil forklare egenskapene til agil utvikling.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hva_er_en_modell_i_systemutvikling\"><\/span>Hva er en modell i systemutvikling?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I systemutviklingsprosjekter finnes det noe som kalles en utviklingsmodell, som fungerer som en ramme for \u00e5 f\u00e5 en helhetlig forst\u00e5else av fremdriften. Den mest kjente av disse er sannsynligvis &#8220;vannfallsmodellen&#8221;. Det vil si, akkurat som vann som faller fra &#8220;oppstr\u00f8ms&#8221; til &#8220;nedstr\u00f8ms&#8221;, gjennomf\u00f8rer man alle trinnene som kravdefinisjon, design, implementering, testing osv. i en enkelt gjennomgang. M\u00e5let er \u00e5 redusere tilbakevendinger og dobbeltarbeid s\u00e5 mye som mulig, og det er en metode som er egnet for \u00e5 fremme arbeid p\u00e5 en planlagt m\u00e5te.<\/p>\n\n\n\n<p>P\u00e5 den annen side, i den agile utviklingsmodellen, gjentar man prosessen med \u00e5 implementere sm\u00e5 programmer og deretter teste dem. Ved \u00e5 gjenta denne iterative prosessen med \u00e5 implementere og teste sm\u00e5 programmer, bygger man gradvis opp et st\u00f8rre system. For en mer detaljert forklaring av disse systemutviklingsmodellene, og en sammenligning av fordelene og ulempene med begge utviklingsmodellene, se f\u00f8lgende artikkel.<br><\/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<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Egenskapene_til_den_agile_utviklingsmodellen\"><\/span>Egenskapene til den agile utviklingsmodellen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>En stor fordel med utvikling ved hjelp av den agile modellen er at man kan g\u00e5 inn i det faktiske arbeidet med en f\u00f8lelse av hastighet. Fordi &#8220;oppstr\u00f8ms&#8221; arbeid som kravdefinisjon og opprettelse av design dokumenter, og implementering av programvare ikke er adskilt, er det egnet for \u00e5 fleksibelt styre prosessen, inkludert respons p\u00e5 tillegg og endringer i funksjoner, og endringer i spesifikasjoner. Fra et juridisk perspektiv er det spesielt viktig \u00e5 h\u00e5ndtere dokumentstyring og endringsstyring for \u00e5 gj\u00f8re den agile utviklingsmodellen til en suksess. I den agile utviklingsmodellen er ikke roller og ansvar s\u00e5 klart delt som i vannfallsmodellen. I tillegg, siden det er en metode som legger vekt p\u00e5 &#8220;hastighet&#8221; for \u00e5 komme til utf\u00f8relse og igangsetting, snarere enn &#8220;styring&#8221;, kan det lett f\u00f8re til mangelfull gjennomf\u00f8ring av ulike design dokumenter, spesifikasjoner og m\u00f8tereferater.<\/p>\n\n\n\n<p>I tillegg, i forhold til endringsstyring, siden den agile utviklingsmodellen er smidig i \u00e5 h\u00e5ndtere endringer, er det en risiko for at prosjektet kan brenne ut ved \u00e5 svare p\u00e5 foresp\u00f8rsler om spesifikasjonsendringer p\u00e5 bakkeniv\u00e5, uten \u00e5 g\u00e5 gjennom godkjenningsprosessen med beslutningstakere. Hvis dette skjer, kan &#8220;smidighet i \u00e5 h\u00e5ndtere endringer etterp\u00e5&#8221; som er en fordel med utviklingsmodellen, i seg selv bli en risiko for at prosjektet brenner ut.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvordan_handtere_dokument-_og_endringsstyring_i_smidig_utvikling\"><\/span>Hvordan h\u00e5ndtere dokument- og endringsstyring i smidig utvikling<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\/pixta_50106785_M-1024x768.jpg\" alt=\"\" class=\"wp-image-5416\" \/><figcaption class=\"wp-element-caption\">Hva er metoden for \u00e5 h\u00e5ndtere dokumentstyring og spesifikasjonsendringer i en smidig utviklingsmodell?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Viktigheten_av_dokumentstyring\"><\/span>Viktigheten av dokumentstyring<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I utviklingsprosjekter basert p\u00e5 den smidige utviklingsmodellen, er det juridiske bekymringer om at muntlige interaksjoner akkumuleres, noe som f\u00f8rer til mangel p\u00e5 dokumentasjon. For \u00e5 forst\u00e5 hvorfor dokumentstyring er viktig i systemutviklingsprosjekter, har vi forklart dette i detalj i f\u00f8lgende artikkel.<br><\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<p>I nevnte artikkel forklarer vi viktigheten av dokumentstyring i systemutviklingsprosjekter fra to perspektiver: forebygging av konflikter (det vil si &#8220;forebyggende juridisk arbeid&#8221;) og bevaring av bevis i tilfelle konflikt (det vil si &#8220;kriseh\u00e5ndtering&#8221;).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Opprettelse_av_kontaktutvalg_er_effektivt_for_dokumenthandtering\"><\/span>Opprettelse av kontaktutvalg er effektivt for dokumenth\u00e5ndtering<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>N\u00e5r man adopterer en smidig utviklingsmodell, er det ikke forberedt en klar plan p\u00e5 forh\u00e5nd, i motsetning til vannfallsmodellen. Derfor er det ikke nok \u00e5 bare administrere avvik mellom plan og faktiske resultater, det er en bekymring for at kostnadene vil \u00f8ke b\u00e5de \u00f8konomisk og tidsmessig hvis det overlates til feltet.<\/p>\n\n\n\n<p>Derfor er det effektivt at lederen tar initiativ til \u00e5 holde regelmessige kontaktutvalgsm\u00f8ter for \u00e5 sikre en jevn fremdrift av prosjektet. N\u00e5r utviklingsskalaen er liten, er det sant at det ofte foretrekkes \u00e5 samle ansvarlige parter etter behov, i stedet for \u00e5 holde regelmessige kontaktutvalgsm\u00f8ter. Men i tilfelle av smidig utviklingsmodell, er det ogs\u00e5 en st\u00f8rre risiko for \u00e5 overse aktuelle problemer i m\u00f8ter. Derfor kan det sies at det er trygt \u00e5 inkludere regelmessige kontaktutvalgsm\u00f8ter i kontrakter og lignende. Som en m\u00e5te \u00e5 regulere dette p\u00e5, er det vist som f\u00f8lger i modellkontrakten fra det japanske ministeriet for \u00f8konomi, handel og industri (METI):<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Opprettelse av kontaktutvalg)<\/p>\n\n\n\n<p>Artikkel 12 Partene A og B skal, inntil denne tjenesten er fullf\u00f8rt, holde et kontaktutvalg for \u00e5 diskutere n\u00f8dvendige saker for \u00e5 sikre at denne tjenesten kan utf\u00f8res jevnt, som fremdriftsstatus, risikostyring og rapportering, felles arbeid og implementering av individuelle arbeidsoppgaver av begge parter, bekreftelse av innhold som skal inkluderes i systemspesifikasjonene, diskusjon og l\u00f8sning av problemer. <u>Et kontaktutvalg skal holdes<\/u>. Men, (utelatt).<br><\/p>\n\n\n\n<p>2. Kontaktutvalget skal i prinsippet <u>holdes regelmessig med en frekvens bestemt i individuelle kontrakter<\/u>, og i tillegg til dette, <u>skal det holdes n\u00e5r som helst n\u00e5r A eller B anser det som n\u00f8dvendig<\/u>.<br><\/p>\n\n\n\n<p>3. I kontaktutvalget skal <u>ansvarlige personer og hovedansvarlige personer fra begge parter, samt personer som lederen anser som passende, delta<\/u>. I tillegg kan b\u00e5de A og B be den andre parten om \u00e5 f\u00e5 n\u00f8dvendige personer til \u00e5 delta i diskusjonene i kontaktutvalget, og den andre parten skal svare p\u00e5 dette, med mindre det er en rimelig grunn.<br><\/p>\n\n\n\n<p>4. B skal <u>lage og sende inn en fremdriftsrapport i en format som er avtalt mellom A og B i kontaktutvalget<\/u>, bekrefte fremdriftsstatus basert p\u00e5 denne fremdriftsrapporten, og diskutere og bestemme saker som n\u00f8dvendig, som tilstedev\u00e6relse av forsinkede saker, \u00e5rsaker og mottiltak n\u00e5r det er forsinkede saker, behov for endringer i fremdriftssystemet som definert i dette kapittelet (endringer i personell, \u00f8kninger og reduksjoner, endringer i underleverand\u00f8rer, etc.), status for gjennomf\u00f8ring av sikkerhetstiltak, tilstedev\u00e6relse av saker som krever endringer i individuelle kontrakter, innhold n\u00e5r det er saker som krever endringer i individuelle kontrakter, og bekrefte saker som er bestemt, saker som skal vurderes videre, og n\u00e5r det er saker som skal vurderes videre, bekrefte tidsplanen for vurdering og parter som skal utf\u00f8re vurderingen. &nbsp;<br><\/p>\n\n\n\n<p>(Artiklene 5, 6 og 7 er utelatt.)<br><\/p>\n<\/blockquote>\n\n\n\n<p>Det viktigste poenget er at eksistensen av et kontaktutvalg gir en viss legitimitet i kontraktsklausulene, og gir en annen betydning enn m\u00f8ter som holdes ad hoc.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Utnytte_kontaktutvalget_for_endringsstyring\"><\/span>Utnytte kontaktutvalget for endringsstyring<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I Agile-utvikling er det en forutsetning at saker begge parter opprinnelig var enige om, kan endres i ettertid. Derfor er det ogs\u00e5 sv\u00e6rt viktig \u00e5 h\u00e5ndtere situasjoner med etterf\u00f8lgende spesifikasjonsendringer.<\/p>\n\n\n\n<p>Hvis et kontaktutvalg holdes regelmessig, vil endringsstyringen bli sv\u00e6rt smidig. For eksempel, endringsdiskusjoner kan holdes i kontaktutvalget, og hvis det er en foresp\u00f8rsel om endringsdiskusjon fra den ene parten, inkluderer kontrakten en forpliktelse for den andre parten til \u00e5 svare p\u00e5 diskusjonen. (Her er et utdrag fra bestemmelsene i den japanske modellkontrakten fra Ministry of Economy, Trade and Industry.)<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>\uff08Endringsstyringsprosedyre\uff09<\/p>\n\n\n\n<p>Artikkel 37 Part A eller B, n\u00e5r de mottar et endringsforslag basert p\u00e5 (utelatt) fra den andre parten, skal innen <u>\u25cb dager<\/u> fra mottaksdatoen levere et dokument som inneholder f\u00f8lgende punkter (heretter kalt &#8220;endringsstyringsdokumentet&#8221;) til den andre parten, og Part A og B skal diskutere godkjennelsen av endringen i <u>kontaktutvalget<\/u> som definert i Artikkel 12. (Detaljer om hva som skal inkluderes er utelatt.)<\/p>\n<\/blockquote>\n\n\n\n<p>Poengene i ovennevnte bestemmelse kan oppsummeres som f\u00f8lger:<\/p>\n\n\n\n<ul>\n<li>Metoden for \u00e5 akseptere en endringsforesp\u00f8rsel er standardisert med et format kalt &#8220;endringsforslag&#8221;.<\/li>\n\n\n\n<li>Det er en tidsfrist for datoen fra mottak av forslaget til diskusjon om det. \u2192 Selv om det ikke er angitt som &#8220;innen \u25ef dager&#8221;, kan det ogs\u00e5 vurderes \u00e5 erstatte det med ord som &#8220;snarest&#8221;.<\/li>\n\n\n\n<li>Stedet for \u00e5 diskutere godkjennelsen av endringen er standardisert til &#8220;kontaktutvalget&#8221;.<\/li>\n<\/ul>\n\n\n\n<p>Med andre ord, for \u00e5 unng\u00e5 misforst\u00e5elser som &#8220;Jeg foreslo en endring, jeg gjorde det ikke&#8221;, &#8220;Jeg svarte p\u00e5 godkjennelsen av endringen, jeg gjorde det ikke&#8221;, er prosedyren for \u00e5 gj\u00f8re dette klargjort.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Forstaelse_av_plikter_som_aerlighet_og_god_tro_blir_utfordret\"><\/span>Forst\u00e5else av plikter som \u00e6rlighet og god tro blir utfordret<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Vi har s\u00e5 langt introdusert modellkontraktsklausuler relatert til &#8220;Kommunikasjonsr\u00e5d&#8221; og &#8220;Endringsdiskusjoner&#8221;. Imidlertid er det viktig \u00e5 forst\u00e5 essensen av disse, som ligger i saker som &#8220;plikt til \u00e6rlighet&#8221; og &#8220;prinsippet om god tro&#8221;. I utgangspunktet kan det v\u00e6re vanskelig \u00e5 fortsette med den smidige utviklingsmodellen uten et tillitsforhold mellom bestiller og leverand\u00f8r. Dette er fordi det legges vekt p\u00e5 hastigheten p\u00e5 \u00e5 starte det faktiske arbeidet, og prosedyrene som f\u00f8rer til oppstart er vanligvis minimert. Derfor er det ofte i praksis \u00e5 inkludere en klausul som p\u00e5legger den andre parten en &#8220;plikt til \u00e6rlighet&#8221;.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artikkel 4, avsnitt 3: I endringsdiskusjoner skal begge parter \u00e6rlig diskutere om de skal gj\u00f8re endringer, etter \u00e5 ha vurdert m\u00e5let for endringen, muligheten for endring, og effekten av endringen p\u00e5 betaling og leveringstid.<br><\/p>\n<\/blockquote>\n\n\n\n<p>Dette er for \u00e5 forhindre en tiln\u00e6rming som plutselig forr\u00e5der den andre parten med en formell juridisk teori, som &#8220;om man skal godta en kontraktsendring eller ikke, er utelukkende opp til den som mottar foresp\u00f8rselen, og det er ingen plikt til \u00e5 overholde tvang&#8221;, i forhandlinger som har g\u00e5tt frem p\u00e5 grunnlag av et opprinnelig tillitsforhold. Dette reflekterer ogs\u00e5 prinsippene i loven som gjelder for private transaksjoner, ikke bare systemutvikling.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Sivilloven artikkel 1, avsnitt 2<\/p>\n\n\n\n<p>Ut\u00f8velsen av rettigheter og oppfyllelsen av plikter m\u00e5 utf\u00f8res <u>\u00e6rlig<\/u> og i samsvar med <u>god tro<\/u>.<br><\/p>\n<\/blockquote>\n\n\n\n<p>Loven verdsetter ikke n\u00f8dvendigvis bare &#8220;innholdet i kontrakten&#8221; eller &#8220;ordlyden i artikkelen&#8221; som er formell. Spesielt i transaksjoner med den andre parten, b\u00f8r det brukes fleksibelt mens man tar hensyn til den faktiske &#8220;god tro&#8221; og &#8220;\u00e6rlighet&#8221;. For \u00f8vrig, om &#8220;plikter&#8221; som p\u00e5legges i henhold til loven n\u00f8dvendigvis er basert p\u00e5 &#8220;kontrakt&#8221; prosedyren, er det en detaljert forklaring i f\u00f8lgende artikkel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/system-development-unlawful-responsibility\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/system-development-unlawful-responsibility[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>I systemutviklingsprosjekter basert p\u00e5 den agile utviklingsmodellen, er det selvf\u00f8lgelig viktig \u00e5 forst\u00e5 risikoen for at administrative prosedyrer og styringssystemer blir gradvis mer slurvete. Men det er ikke bare det, det er ogs\u00e5 viktig \u00e5 forst\u00e5 de fleksible egenskapene som loven i seg selv har, som er basert p\u00e5 prinsipper som &#8220;god tro&#8221;, og \u00e5 ha en holdning til \u00e5 bruke det i praksis.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Det finnes metodikker for hvordan systemutvikling skal gjennomf\u00f8res. Den mest klassiske og generelle er vannfallsmodellen, og mange juridiske b\u00f8ker som behandler systemutvikling, diskuterer dette base [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":62649,"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\/61450"}],"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=61450"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61450\/revisions"}],"predecessor-version":[{"id":62648,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61450\/revisions\/62648"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/62649"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=61450"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=61450"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=61450"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}