Hva er de juridiske fordelene og ulempene ved hver utviklingsmodell for systemutvikling?

Det er en bestemt metodikk for hvordan man skal gå frem i systemutviklingsprosjekter. Vanligvis, når man lærer om juridiske problemer knyttet til systemutvikling gjennom bøker og lignende, er det ofte antatt at den mest klassiske metoden, kjent som vannfallsmodellen, er utgangspunktet. Men, det er ikke bare vannfallsmodellen som er en metodikk eller modell for å drive systemutvikling. For eksempel, har det blitt mer vanlig å velge en metode kjent som den smidige utviklingsmodellen i det siste.

I denne artikkelen vil vi forklare og sammenligne de to metodene, vannfallsmodellen og den smidige utviklingsmodellen, fra et juridisk risiko- og konfliktforebyggende perspektiv.

Hva er en utviklingsmodell?

Hva er vannfallsmodellen?

Den mest vanlige og klassiske metoden for systemutvikling er som følger:

• Kravspesifikasjon: Identifisering av funksjonene systemet skal ha og de nødvendige spesifikasjonene
• Grunnleggende design: Design av systemets helhetlige bilde, hovedsakelig fra brukerens perspektiv, inkludert skjermdesign og skjermoverganger
• Detaljert design: Design av systemets helhetlige bilde, hovedsakelig fra utviklerens perspektiv, inkludert forbindelser mellom programfiler
• Programmeringsimplementering: Koding av programmet i henhold til designspesifikasjonene
• Testing: Verifisering av at produktet er i henhold til spesifikasjonene, og ber om brukerbekreftelse

Denne utviklingsmetoden, som går fremover som en elv fra oppstrøm til nedstrøm, med minimal tilbakegang og omvendt, kalles “vannfallsmodellen”. Denne flyten er ikke nødvendigvis essensiell for å lage et fungerende system. Men i systemutviklingsprosjekter, som ofte involverer mange mennesker og langvarige perioder, blir planlegging viktig. Derfor er det også en tendens til å legge vekt på ting som å dele opp hvert trinn, organisere roller, og klargjøre ansvarsområdene for hver person som er ansvarlig.

Hva er den agile utviklingsmodellen?

På den annen side, er det ikke alltid at en metode som gjennomfører utviklingsarbeidet i en “oppstrøm til nedstrøm” -måte er passende. Selvfølgelig er planlegging og estimeringsteknikker viktige aspekter av jobben, gitt dens natur. Men i arbeid som involverer å lage noe nytt eller lage kunstverk, er det ofte umulig å lage en perfekt plan fra begynnelsen. Hvis vi legger vekt på disse punktene, bør det være en måte å gjøre ting på som ikke bare fremmer arbeid i henhold til en plan, men også gjør det enkelt å fleksibelt håndtere etterfølgende korrigeringer og spesifikasjonsendringer, og øker antall prøvinger og feil. Denne tankegangen reflekteres i utviklingsmetoden kjent som “den agile utviklingsmodellen”. I den agile utviklingsmodellen er det vanlig å minimere tiden brukt på å forberede detaljerte planer og designspesifikasjoner, og i stedet gjentatte ganger implementere og teste veldig små programmer, gradvis endre dem til større programmer og systemer.

Det er enklere å lære om juridiske problemer med vannfallsmodellen

Før vi sammenligner de to utviklingsmodellene, vil vi nevne at det er lettere å samle informasjon og lære om juridiske problemer knyttet til hver utviklingsmodell.

De fleste referansebøker er skrevet basert på vannfallsmodellen

Når det gjelder å samle informasjon og lære om juridiske problemer relatert til systemutvikling, er vannfallsmodellen overlegen. Juridiske bøker som diskuterer systemutvikling er ofte skrevet med utgangspunkt i vannfallsmodellen. Dette skyldes at klassisk og generell systemutvikling følger vannfallsmodellen, og agile utviklingsmetoder er ofte bare nevnt som et supplement. Derfor, når du prøver å få informasjon om juridiske problemer relatert til systemutvikling fra bøker, er det lettere å lære med vannfallsmodellen.

Vannfallsmodellen har også mange akkumulerte rettsavgjørelser

I tillegg, siden vannfallsmodellen er en klassisk og generell metode for systemutvikling, er det også mange akkumulerte tilfeller av faktiske konflikter som har oppstått i fortiden. I juridiske diskusjoner er kunnskap om tidligere rettsavgjørelser like viktig som lovteksten. Selv i saker der det er vanskelig å si om teksten i loven er “hvit” eller “svart”, kan det være mulig å supplere innholdet i loven ved å få innsikt fra tidligere rettsavgjørelser.

Det skal også nevnes at selv om det ikke er en kodifisert lov, kan akkumulerte dommer fra domstolene bli etablert som en standard for dommen, akkurat som loven. Dette kalles “jurisprudens”. Selv i områder som systemutvikling, hvor det allerede er en akkumulering av jurisprudens, kan det være relativt enkelt å forutsi utfallet av en ukjent konflikt. Dette er en av de mange fordelene med systemutvikling basert på vannfallsmodellen.

Fordelene med hver utviklingsmetode

Med ovenstående i tankene, vil vi nå sammenligne og organisere fordelene og ulempene med hver metode. Første del fokuserer hovedsakelig på fordelene med vannfallsmodellen, og jo lenger ned du går, jo mer forståelig blir fordelene med smidig utvikling.

Sammenligning basert på planlegging og forutsigbarhet

Når det kommer til aspekter som planlegging og forutsigbarhet, kan det sies at vannfallsmodellen har en fordel. Uansett hvor stort systemet som skal lages er, vil det alltid bli delt opp i mindre deler som følger en “oppstrøms-til-nedstrøms” sekvens. Ved å sette en frist for hver del, blir det lettere å administrere fremdriften på en relativt planlagt måte.

På den annen side er smidig utvikling en metode som ikke bruker for mye kostnader eller krefter på forhåndsplanlegging eller overordnet konsept, noe som kan føre til en tendens til en ad hoc-tilnærming.

Sammenligning basert på lettheten ved å klargjøre individuelle roller og ansvarsområder

I vannfallsmodellen er det en fordel at prosessene er finjustert og delt opp i mindre deler, noe som gjør det mulig å klargjøre rollene til hvert enkelt prosjektmedlem.

På den annen side, i smidig utvikling, blir prosessinndelingene ofte uklare, noe som kan føre til en tendens til uklarhet om hvem som skal ta ansvar for uforutsette problemer og lignende.

Sammenligning av letthet ved storskala utvikling

Waterfall-modellen, som er fremragende når det gjelder planlegging og rolleklarhet, blir mer fordelaktig jo større utviklingsprosjektet er. Selv med organisering av mange ansatte, kan du redusere kostnadene knyttet til justering av menneskelige relasjoner ved å dele opp prosessen i mindre deler og fremme arbeidsdeling.

På den annen side er det sagt at den smidige utviklingsmodellen ikke er spesielt egnet for storskala utvikling. Fordi det er en tilnærming som prioriterer hastigheten fra starten mer enn planlegging og rolleklarhet, er det vanskelig å anvende den i situasjoner der det er bekymringer for forsinkelser i den endelige leveringstiden.

Sammenligning av hastighet og effektivitet

Agil utvikling starter raskere

Når brukerne har en funksjonsforespørsel, er det agil utviklingsmodell som kommer først i å implementere den. Dette skyldes at i vannfallsmodellen er det vanlig at ansvarlige personer er klart adskilt i oppstrøms og nedstrøms prosesser, noe som ofte fører til mer kommunikasjon innad i leverandøren. Dette kan gjøre det vanskelig å håndtere endringsforespørsler etter spesifikasjonene.

På den annen side kan agil utviklingsmodell forventes å starte og utføre raskt uten å sette opp en mellommann. Dette er tett knyttet til den største fordelen med agil utviklingsmodell, som er at det er lett å håndtere endringer i spesifikasjoner etterpå. Imidlertid, selv i en agil utviklingsmodell, hvis du fortsetter å svare på endrings- og tilleggsutviklingsforespørsler uten å tenke, kan det risikere å “brenne” prosjektet. I denne forstand er nøkkelen til suksess i systemutvikling med agil utviklingsmodell hvordan man håndterer “endringsstyring”. En detaljert forklaring på endringsstyring er gitt i artikkelen nedenfor.

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

Vannfallsmodellen er mindre sannsynlig å mislykkes på veien

På den annen side, når man sammenligner fra et perspektiv av hastighet og effektivitet, er det viktig å vurdere på en lang tidsakse. Når man tenker på risikoen for at prosjektet brenner på veien og fremdriften stopper, er vannfallsmodellen overlegen. Den største risikoen for at et prosjekt mislykkes på veien er mangel på kommunikasjon mellom brukeren og leverandøren. Vannfallsmodellen, som gjør det enkelt å klargjøre rollefordelingen mellom de to, har en fordel i denne forbindelse.

Agil utvikling er lettere å gå jevnt gjennom akseptfasen

Imidlertid, fra perspektivet av hvor lett det er å gå frem i akseptfasen, kan det sies at agil utviklingsmodell har en fordel. Dette skyldes at det forutsettes at brukeren og leverandøren deler informasjon i detalj selv underveis i systemutviklingen. Det kan forventes å redusere risikoen for at en misforståelse mellom de to blir tydelig når de ser det endelige produktet. For en forklaring på aksepttrinnet i systemutvikling og de tilknyttede juridiske problemene, se artikkelen nedenfor.

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

Oppsummering

Når vi sammenligner på denne måten, kan vi generelt organisere det slik at Waterfall-modellen bidrar til grundig styring, mens Agile utviklingsmodellen prioriterer hastigheten fra oppstart til utførelse. For juridiske problemer knyttet til systemutvikling basert på Agile utviklingsmodellen, behandler vi detaljene i følgende artikkel.

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

Hvilken utviklingsmodell som er passende, bør vurderes helhetlig, ikke bare fra et juridisk perspektiv, men også med tanke på prosjektets størrelse, budsjett og mål.