Millised on süsteemiarenduse arendusmudelite seaduslikud eelised ja puudused?

Süsteemiarendusprojektide läbiviimiseks on olemas kindlad metoodikad. Tavaliselt eeldatakse, et süsteemiarendusega seotud õiguslike küsimuste õppimisel raamatutest ja muudest allikatest lähtutakse kõige klassikalisemast meetodist, mida nimetatakse juga mudeliks. Kuid süsteemiarenduse läbiviimise metoodika või mudel ei piirdu ainult juga mudeliga. Näiteks on viimasel ajal üha sagedamini valitud agiilse arendusmudeli meetod.

Käesolevas artiklis võrdleme juga mudelit ja agiilset arendusmudelit, arvestades õiguslikke riske ja vaidluste ennetamist.

Mis on arendusmudel?

Mis on vesiputouste mudel?

Süsteemiarenduse lähenemisviisina on kõige tavalisem ja klassikaline järgmine:

• Nõuete määratlemine: funktsioonid, mida süsteem peaks omama, ja vajalike spetsifikatsioonide väljaselgitamine
• Põhiline disain: kasutajaliidese disain ja navigeerimine jne, peamiselt süsteemi kasutaja vaatenurgast
• Detailne disain: programmifailide vahelised seosed jne, peamiselt süsteemi arendaja vaatenurgast
• Programmeerimise rakendamine: programmeerimine vastavalt disainidokumentidele
• Testimine: kontrollimine, kas valminud toode vastab spetsifikatsioonidele, ja kasutaja kinnituse saamine

Seda tüüpi arendusmeetodit, kus protsess liigub ülesvoolust allavoolu, vältides võimalikult palju tagasipöördumist või segadust, nimetatakse “vesiputouste mudeliks”. Selline lähenemisviis ei ole süsteemi loomiseks hädavajalik. Kuid süsteemiarendusprojektid, mis sageli nõuavad suurt hulka inimressursse ja pikka aega, nõuavad planeerimist. Seetõttu on oluline ka tööjaotus, rollide selgitamine ja vastutusalade määratlemine.

Mis on Agile arendusmudel?

Teisest küljest ei pruugi arendustööde läbiviimise viis alati olla “ülesvoolust allavoolu” lähenemine. Kindlasti on planeerimise ja projekteerimise oskused olulised, kuid uute asjade loomise ja loomise töö iseloomu tõttu on sageli võimatu teha täiuslikku plaani algusest peale. Kui me rõhutame neid punkte, peaks olema ka lähenemisviis, mis mitte ainult ei järgi kord tehtud plaani, vaid on ka paindlik muudatuste ja paranduste suhtes ning suurendab katse-eksituse tsüklite arvu. Seda lähenemisviisi kajastavat arendusmeetodit nimetatakse “Agile arendusmudeliks”. Agile arendusmudelis ei kulutata ülemäära aega detailsete plaanide või disainidokumentide koostamisele, vaid luuakse väikesi programme, mida testitakse korduvalt, ja järk-järgult muudetakse need suuremaks programmiks või süsteemiks.

Õigusprobleemide õppimiseks on kõige lihtsam kasutada Waterfall-mudelit

Enne kui võrdleme mõlemat arendusmudelit, tahaksin eelnevalt mainida, et iga arendusmudeli juurde kuuluvate õigusprobleemide puhul on teabe kogumine ja õigusteaduse õppimine lihtsam.

Enamik õpikuid on kirjutatud Waterfall-mudeli põhjal

Süsteemiarendusega seotud õigusprobleemide või õigusteadmiste õppimisel on teabe kogumine Waterfall-mudeli puhul lihtsam. Enamik õigusraamatuid, mis käsitlevad süsteemiarendust, on kirjutatud eeldusel, et kasutatakse Waterfall-mudelit. Kuna klassikaline ja üldine süsteemiarendus toimub vastavalt Waterfall-mudelile, on Agile-arendus seal pigem lisamaterjal ja seda tutvustatakse lühidalt. Seega, kui soovite süsteemiarendusega seotud õigusprobleemide kohta raamatutest teavet saada, on Waterfall-mudeli puhul õppimine lihtsam.

Kohtupraktika on samuti rohkem kogunenud Waterfall-mudeli puhul

Lisaks, kuna Waterfall-mudel on klassikaline ja üldine süsteemiarenduse meetod, on ka minevikus toimunud vaidluste juhtumite kogumine rikkalik. Õigusaruteludes on oluline mitte ainult seaduse sõnastus, vaid ka varasemate kohtuotsuste teadmised. Mõnel juhul, kui seaduse sõnastust lugedes ei saa öelda, kas asi on “valge” või “must”, võib varasemate kohtuotsuste tundmine aidata seaduse sisu täiendada.

Kuigi see ei pruugi olla kirjalikult sõnastatud seadus, võib kohtu poolt tehtud otsuste kogumine olla samamoodi otsustamise aluseks. Selliseid asju nimetatakse “kohtupraktika põhimõteteks”. Kui on olemas kohtupraktika kogum, isegi kui see on tundmatu vaidlus, võib lõpliku vaidluse tulemuse ennustamine olla suhteliselt lihtne. Sellistel põhjustel on süsteemiarendus, mis põhineb Waterfall-mudelil, palju eeliseid.

Iga arendusmeetodi eelised

Arvestades ülaltoodud sisu, võrdleme allpool erinevaid meetodeid, korraldades nende eelised ja puudused. Esimene pool keskendub veebikose mudeli eelistele, mida on allapoole liikudes lihtsam mõista Agile arenduse eeliseid.

Võrdlus planeeritavuse ja prognoositavuse osas

Planeeritavuse ja prognoositavuse osas võib öelda, et Waterfall-mudel on ülekaalus. Ükskõik kui suur on süsteem, mida luuakse, jaguneb see alati “ülemisest otsast allapoole” liikuvateks etappideks. Kui määrate iga etapi jaoks tähtaja, muutub selle edenemise suhteliselt planeeritud haldamine lihtsamaks.

Teiselt poolt, Agile arendus on meetod, mis ei kuluta palju kulusid ega vaeva eelneva planeerimise või üldise kontseptsiooni koostamisele, seega võib see kergesti muutuda ad hoc lähenemiseks.

Võrdlus üksikute rollide ja vastutusalade selgitamise lihtsuse põhjal

Veel üks veemudeli eelis on see, et protsessid on üksikasjalikult jaotatud, mis võimaldab selgelt määratleda iga projekti liikme rolli.

Teiselt poolt, agiilse arenduse puhul on protsesside jaotus sageli ebaselge, mis võib tekitada segadust, kui tekib ootamatu probleem ja on vaja otsustada, kes vastutab.

Võrdlus suurprojektide hõlbustamise osas

Planeerimise ja rollide selgitamise osas silmapaistev Waterfall-mudel muutub suurprojektide puhul veelgi kasulikumaks. Isegi kui peate korraldama suure hulga inimesi, saate tööprotsessi peenestada ja tööjaotust soodustada, vähendades seeläbi inimsuhete korraldamise kulusid.

Teisalt ei peeta Agile arendusmudelit suurprojektidele eriti sobivaks. Kuna see lähenemisviis keskendub rohkem planeerimisele ja rollide selgitamisele kui kiirusele, on see keeruline rakendada olukordades, kus on mure lõpliku tähtaja nihkumise pärast.

Võrdlus kiiruse ja efektiivsuse osas

Agile arendus algab kiiremini

Kui kasutaja soovib mingit funktsiooni, on selle tegeliku rakendamiseni kulgev kiirus Agile arendusmudeli puhul kiirem. See on seetõttu, et Waterfall mudelis on ülesvoolu ja allavoolu protsesside eest vastutavad isikud tavaliselt selgelt eraldatud, mis tähendab, et müüja sisemine suhtlus võib olla aeganõudev. See suhtluse aeganõudvus võib olla seotud ka asjaoluga, et see muudab süsteemi nõrkemaks järelmõjude muudatuste taotlustele.

Teisalt võib Agile arendusmudel alustada ja rakendada kiiresti ilma vahendajat kasutamata. See on tihedalt seotud Agile arendusmudeli suurima eelisega, mis on lihtne kohanemine järelmõjude muudatustega. Siiski, isegi kui tegemist on Agile arendusmudeliga, kui jätkate vastamist muudatuste ja lisatööde taotlustele, võib see põhjustada projekti “põlemise”. Selles mõttes on Agile arendusmudeli abil süsteemi arendamise edu võti “muudatuste haldamine”. Muudatuste haldamise kohta leiate üksikasjalikuma selgituse järgmisest artiklist.

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

Waterfall mudel on vähem tõenäoline, et see katkestatakse poolel teel

Teisalt, kiiruse ja efektiivsuse vaatepunktist võrreldes on oluline kaaluda ka pikemat ajatelge. Kui arvestada projekti “põlemise” riski ja edasise progressi puudumist, on Waterfall mudelil eelis. Suurim risk, mis võib põhjustada projekti katkemist, on kasutaja ja müüja vaheline suhtlusprobleem. Waterfall mudel, mis teeb mõlema osapoole rollide jaotuse selgemaks, on selles punktis eelis.

Agile arendus on vastuvõtmise etapis sujuvam

Kuid vastuvõtmise etapis on arutelu lihtsam Agile arendusmudeli puhul. See on seetõttu, et eeldatakse, et kasutaja ja müüja jagavad süsteemi arendamise käigus pidevalt üksikasjalikku teavet. See vähendab riski, et mõlema osapoole arusaamade erinevused ilmnevad korraga, kui lõpptulemus on valmis. Süsteemi arendamise vastuvõtmise etapi ja sellega seotud õiguslike küsimuste kohta leiate üksikasjalikuma selgituse järgmisest artiklist.

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

Kokkuvõte

Võrreldes neid kahte, võib üldiselt öelda, et juhtimise põhjalikkuse tagab Waterfall mudel, samas kui Agile arendusmudel rõhutab kiirust alustamisest ja teostamiseni. Lisaks käsitleme Agile arendusmudeli põhjal süsteemiarendusega kaasnevaid õigusprobleeme järgmises artiklis üksikasjalikult.

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

Kas valida Waterfall või Agile arendusmudel, sõltub mitte ainult õiguslikust vaatenurgast, vaid ka projekti suurusest, eelarvest ja eesmärkidest. Seega tuleks seda otsust teha terviklikult.