MONOLITH LAW OFFICE+81-3-6262-3248Hverdage 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Hvad er de juridiske fordele og ulemper ved hver udviklingsmodel for systemudvikling?

IT

Hvad er de juridiske fordele og ulemper ved hver udviklingsmodel for systemudvikling?

Der er en bestemt metodologi for at gennemføre systemudviklingsprojekter. Normalt, når man studerer juridiske spørgsmål relateret til systemudvikling gennem bøger og lignende, er det ofte antaget, at den mest klassiske metode, kendt som vandfaldsmodellen, er grundlaget. Men, metoder og modeller for at fremme systemudvikling er ikke begrænset til kun vandfaldsmodellen. For eksempel, er det blevet mere almindeligt at vælge en metode kendt som den agile udviklingsmodel i nyere tid.

I denne artikel vil vi forklare og sammenligne de to modeller, vandfaldsmodellen og den agile udviklingsmodel, fra et juridisk risiko- og konfliktforebyggelsesperspektiv.

Hvad er en udviklingsmodel?

Hvad er vandfaldsmodellen?

Hvad er en udviklingsmodel i forbindelse med systemudvikling?

Den mest almindelige og klassiske tilgang til systemudvikling er som følger:

  • Kravspecifikation: Identifikation af de funktioner og specifikationer, som det kommende system skal have
  • Grundlæggende design: Design af det overordnede billede af systemet, primært fra brugerens perspektiv, herunder skærmdesign og skærmovergange
  • Detaljeret design: Design af det overordnede billede af systemet, primært fra udviklerens perspektiv, herunder forbindelser mellem programfiler
  • Programmeringsimplementering: Kodning af programmet i overensstemmelse med designspecifikationerne
  • Test: Verifikation af, at det færdige produkt overholder specifikationerne, og anmodning om bekræftelse fra brugeren

Denne udviklingsmetode, hvor man forsøger at undgå tilbageskridt og omvendt rækkefølge så meget som muligt, mens man bevæger sig fra opstrøms til nedstrøms i en flod, kaldes “vandfaldsmodellen”. Selvom denne proces ikke er nødvendig for at skabe et fungerende system, er planlægning vigtig i systemudviklingsprojekter, som ofte involverer mange mennesker og langvarige perioder. Derfor er det også vigtigt at overveje ting som opdeling af processer, rolleafklaring og klarlægning af ansvarsområder for hver person.

Hvad er den agile udviklingsmodel?

På den anden side er det ikke altid passende at gennemføre udviklingsarbejde på en måde, der strækker sig fra “opstrøms til nedstrøms” i et enkelt træk. Selvfølgelig er planlægning og estimeringsteknikker vigtige aspekter af arbejdet, givet dets natur. Men i arbejde, der involverer skabelsen af noget nyt eller et kunstværk, er det ofte umuligt at lave en perfekt plan fra starten. Hvis man tager højde for disse aspekter, bør der også være en tilgang, der vægter ikke kun at følge den oprindelige plan, men også at være fleksibel i forhold til efterfølgende korrektioner og ændringer i specifikationer, samt at øge antallet af forsøg og fejl. Denne tankegang afspejles i den “agile udviklingsmodel”. I den agile udviklingsmodel er det almindeligt at minimere tiden brugt på detaljerede planer og designspecifikationer, og i stedet gentage implementering og test af meget små programmer, gradvist ændre og opbygge større programmer og systemer.

Det er nemmere at lære om juridiske problemer med vandfaldsmodellen

Inden vi sammenligner de to udviklingsmodeller, vil vi først berøre, hvor let det er at indsamle information og lære om de juridiske problemer, der er forbundet med hver udviklingsmodel.

De fleste referencebøger er skrevet på basis af vandfaldsmodellen

Når det kommer til at indsamle information og lære om juridiske problemer relateret til systemudvikling, er vandfaldsmodellen overlegen. Juridiske bøger, der diskuterer systemudvikling, er ofte skrevet med vandfaldsmodellen som forudsætning. Traditionel og generel systemudvikling følger vandfaldsmodellen, og agile udviklingsmetoder er ofte kun nævnt som en tilføjelse, og introduktionen til dem er ofte kort. Derfor, når du forsøger at få information om juridiske problemer relateret til systemudvikling fra bøger, er det lettere at fortsætte med at lære med vandfaldsmodellen.

Vandfaldsmodellen har også mange akkumulerede retssager

Desuden, da vandfaldsmodellen er en traditionel og generel metode til systemudvikling, er der også mange akkumulerede sager om konflikter, der faktisk er opstået i fortiden. I juridiske diskussioner er kendskab til tidligere retssager lige så vigtigt som lovens bestemmelser. Selv i sager, hvor det er svært at sige, om det er “hvidt” eller “sort” bare ved at fortolke ordlyden af loven, kan der være tilfælde, hvor indholdet af loven kan suppleres ved at få indsigt fra tidligere retssager.

Desuden, selvom det ikke er en kodificeret lov, kan akkumuleringen af domstolsafgørelser undertiden etablere sig som en standard for dom, ligesom lovens bestemmelser. Dette kaldes “jurisprudence”. Selv i områder, hvor der allerede er en akkumulering af retspraksis, som ikke er begrænset til diskussioner om systemudvikling, kan det være relativt let at forudsige det endelige udfald af en konflikt, selvom det er en ukendt konflikt. På denne måde er der mange fordele ved systemudvikling baseret på vandfaldsmodellen.

Fordele ved hver udviklingsmetode

Hvad er fordelene og ulemperne ved henholdsvis vandfaldsmodellen og agil udvikling?

Med ovenstående i tankerne vil vi nu sammenligne og organisere fordele og ulemper ved hver metode. Første del fokuserer primært på fordelene ved vandfaldsmodellen, og jo længere ned du kommer, jo mere forståelige bliver fordelene ved agil udvikling.

Sammenligning baseret på planlægning og forudsigelighed

I forhold til planlægning og forudsigelighed er vandfaldsmodellen generelt at foretrække. Uanset hvor stort et system der skal bygges, vil det altid blive opdelt i mindre dele, der følger en “opstrøms-til-nedstrøms” proces. Ved at sætte deadlines for hver del bliver det relativt nemt at styre fremdriften planmæssigt.

På den anden side er agil udvikling en metode, der ikke kræver meget tid eller omkostninger til forudgående planlægning eller overordnet konceptualisering, hvilket kan føre til en mere ad hoc-tilgang.

Sammenligning baseret på klarhed i individuelle roller og ansvarsområder

Vandfaldsmodellen har også den fordel, at den gør det nemt at definere de enkelte projektmedlemmers roller, da processen er opdelt i mindre, mere håndterbare dele.

I modsætning hertil kan det i agil udvikling være svært at definere hvem der har ansvaret for hvad, især når uforudsete problemer opstår, da processerne ofte er mere uklart definerede.

Sammenligning baseret på håndtering af store udviklingsprojekter

Vandfaldsmodellen, som er stærk på planlægning og rolledefinition, bliver endnu mere fordelagtig, jo større et udviklingsprojekt er. Selv med mange medarbejdere involveret, kan opdeling af processen i mindre dele fremme arbejdsdeling og minimere omkostningerne ved at håndtere menneskelige relationer.

Agil udvikling, derimod, anses generelt ikke for at være velegnet til store udviklingsprojekter. Da denne tilgang prioriterer hastighed over planlægning og rolledefinition, kan det være svært at anvende den i situationer, hvor der er bekymring for forsinkelser i den endelige levering.

Sammenligning baseret på hastighed og effektivitet

Agil udvikling starter hurtigere

Når det kommer til hastigheden fra brugerens anmodning om en funktion til dens faktiske implementering, er agil udvikling at foretrække. Dette skyldes, at i vandfaldsmodellen er det almindeligt, at forskellige personer håndterer opstrøms og nedstrøms processer, hvilket kan føre til mere intern kommunikation og dermed mere tid. Dette kan gøre modellen mere sårbar over for anmodninger om ændringer i specifikationer efterfølgende.

Agil udvikling, derimod, kan forventes at starte og udføre hurtigt uden at skulle gå gennem en mægler. Dette er tæt forbundet med den største fordel ved agil udvikling, nemlig at det er nemt at håndtere ændringer i specifikationer efterfølgende. Dog, selv i agil udvikling, hvis du fortsætter med at imødekomme anmodninger om ændringer i specifikationer og yderligere udvikling på en ad hoc-basis, kan det føre til risikoen for at “brænde” projektet. I denne forstand er nøglen til succes med agil systemudvikling, hvordan man håndterer “ændringsstyring”. En detaljeret forklaring på ændringsstyring findes i følgende artikel.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Vandfaldsmodellen er mindre tilbøjelig til at falde fra hinanden undervejs

På den anden side, når man sammenligner fra et perspektiv af hastighed og effektivitet, er det vigtigt at overveje på en langtidshorisont. Hvis man tager højde for risikoen for, at et projekt “brænder” midtvejs og derefter stopper med at gøre fremskridt, er vandfaldsmodellen at foretrække. Den største risiko for, at et projekt falder fra hinanden midtvejs, er manglende kommunikation mellem brugeren og leverandøren. Vandfaldsmodellen, som gør det nemt at definere roller mellem de to parter, har en fordel i denne henseende.

Agil udvikling er nemmere at håndtere i acceptfasen

Men når det kommer til at lette diskussioner i acceptfasen, har agil udvikling en lille fordel. Dette skyldes, at det forudsætter, at brugeren og leverandøren deler information detaljeret, selv midt i systemudviklingen. Dette kan forventes at minimere risikoen for, at forskelle i opfattelse mellem de to parter pludselig bliver tydelige, når de ser det endelige produkt. En detaljeret diskussion om accepttrinnet i systemudvikling og de juridiske problemer, der følger med det, findes i følgende artikel.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Opsummering

Når vi sammenligner på denne måde, kan vi generelt organisere det således, at vandfaldsmodellen bidrager til en grundig styring, mens agil udviklingsmodel prioriterer en følelse af hastighed fra start til udførelse. For yderligere detaljer om juridiske problemer forbundet med systemudvikling baseret på den agile udviklingsmodel, se artiklen nedenfor.

https://monolith.law/corporate/legal-and-contract-issues-of-agile-development[ja]

Valget af udviklingsmodel bør ikke kun baseres på juridiske overvejelser, men også tage højde for projektets størrelse, budget og formål. Det er vores opfattelse, at dette bør være en omfattende vurdering.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Tilbage til toppen