MONOLITH LAW OFFICE+81-3-6262-3248Hétköznapokon 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

A rendszerfejlesztés jogi előnyei és hátrányai fejlesztési modell szerint

IT

A rendszerfejlesztés jogi előnyei és hátrányai fejlesztési modell szerint

A rendszerek fejlesztésének projektjeinek előrehaladásához bizonyos módszertan szükséges. Általában, amikor a rendszerfejlesztéssel kapcsolatos jogi kérdéseket tanulmányozzuk könyvekből és más forrásokból, gyakran a legklasszikusabb módszert, a vízesés modellt (Waterfall modell) veszik alapul. Azonban a rendszerfejlesztés előrehaladásához szükséges módszertanok és modellek nem korlátozódnak kizárólag a vízesés modellre. Például manapság egyre gyakrabban választják az agilis fejlesztési modellt (Agile fejlesztési modell).

Ebben a cikkben a vízesés modellt és az agilis fejlesztési modellt hasonlítjuk össze, jogi kockázatok és viták megelőzése szempontjából.

Mi az a fejlesztési modell?

Mi az a vízesés modell?

Mi a fejlesztési modell a rendszerfejlesztés előrehaladásában?

A rendszerfejlesztés előrehaladása a legáltalánosabb és legklasszikusabb módon a következőképpen néz ki:

  • Követelmények meghatározása: a készítendő rendszernek milyen funkciókkal kell rendelkeznie, milyen specifikációkra van szükség
  • Alapvető tervezés: a felhasználói oldal nézőpontjából, például a képernyőtervezés és a képernyőváltások, a rendszer teljes képének tervezése
  • Részletes tervezés: a programfájlok közötti kapcsolatok stb., a rendszer teljes képének tervezése a fejlesztői oldal nézőpontjából
  • Programozás megvalósítása: a tervezési dokumentumoknak megfelelő programozás
  • Tesztelés: ellenőrizzük, hogy a specifikációknak megfelelő-e a rendszer, és kérjük a felhasználókat is, hogy ellenőrizzék

Ezt a fejlesztési módszert, amely a folyó folyását követi a felsőbb szakaszoktól az alsóbb szakaszokig, és amelyben a lehető legkevesebb visszalépés és visszatérés történik, “vízesés modell”-nek hívják. Ez a folyamat nem feltétlenül szükséges egy működő rendszer létrehozásához. Azonban a rendszerfejlesztés gyakran nagyszámú munkaerőt és hosszú időt igénylő projekt, ezért a tervezés fontos. Ezért a munkafázisok felosztása, a szerepek tisztázása, a felelősök hatáskörének egyértelműsítése stb. is fontos szempontok.

Mi az az agilis fejlesztési modell?

Másrészről, a fejlesztési munka előrehaladása nem mindig alkalmas arra, hogy “felsőbb szakasztól az alsóbb szakaszig” egyetlen lépésben haladjon. Természetesen a munka jellegéből adódóan a tervezés és a becslés technikája fontos, ez magától értetődő. Azonban, mivel ez alapvetően új dolgok és művek létrehozásával foglalkozó munka, gyakran lehetetlen tökéletes tervet készíteni a kezdetektől fogva. Ha ezt a szempontot fontosnak tartjuk, akkor nem csak a terv szerinti munkavégzés, hanem a rugalmas reagálás a módosításokra és a specifikációk változásaira, valamint a próbálkozások és hibák számának növelése is fontos lehet. Ezt a gondolkodásmódot tükrözi az “agilis fejlesztési modell”. Az agilis fejlesztési modellben általában nem fordítanak sok időt a részletes tervek és tervezési dokumentumok elkészítésére, hanem kis programokat implementálnak és tesztelnek ismétlődően, fokozatosan nagyobb programokká és rendszerekké alakítva őket.

A jogi kérdések tanulásának könnyebb módja a Waterfall modell

Mielőtt összehasonlítanánk a két fejlesztési modellt, először érintenünk kell a hozzájuk kapcsolódó jogi kérdéseket, különös tekintettel az információgyűjtés és a jogtanulás könnyedségére.

A legtöbb szakirodalom a Waterfall modellt veszi alapul

Amikor a rendszerfejlesztéssel kapcsolatos jogi kérdéseket vagy jogi ismereteket szeretnénk tanulmányozni, az információgyűjtés könnyebb a Waterfall modell esetében. A rendszerfejlesztésről szóló jogi könyvek többsége a Waterfall modellt veszi alapul. A klasszikus és általános rendszerfejlesztés a Waterfall modell szerint történik, így az agilis fejlesztés csak kiegészítő szerepet játszik, és gyakran csak rövid bemutatásra kerül sor. Ezért, ha a rendszerfejlesztéssel kapcsolatos jogi kérdésekről szeretnénk információt szerezni könyvekből, a Waterfall modell tanulmányozása könnyebb lehet.

A bírósági esetek gyűjteménye is nagyobb a Waterfall modell esetében

A Waterfall modell, mint a klasszikus és általános rendszerfejlesztési módszer, gazdag gyűjteményt kínál a múltban ténylegesen bekövetkezett vitás esetekből. A jogi vitákban nem csak a törvényi rendelkezések, hanem a korábbi bírósági esetek ismerete is fontos. Nem csak a törvényi szöveg értelmezése segíthet a “fehér” vagy “fekete” kérdésekben, hanem a korábbi bírósági esetekből származó ismeretek is segíthetnek a törvényi rendelkezések kiegészítésében.

Még ha a törvény nem is rögzíti kifejezetten, a bíróságok által hozott döntések gyűjteménye ugyanúgy meghatározó lehet, mint a törvényi rendelkezések. Ezeket “precedens jogelvének” nevezik. Ha már van precedens jogelv egy adott területen, például a rendszerfejlesztésben, akkor még ismeretlen viták esetén is viszonylag könnyen előre jelezhető lehet a vita végkimenetele. Ebben a tekintetben a Waterfall modellen alapuló rendszerfejlesztés számos előnnyel járhat.

Az egyes fejlesztési módszerek előnyei

Milyen előnyökkel és hátrányokkal jár a vízesés modell és az agilis fejlesztés?

A fentiek figyelembevételével az alábbiakban összehasonlítjuk az egyes módszereket, és rendszerezzük előnyeiket és hátrányaikat. Az első rész a vízesés modell előnyeire összpontosít, míg az alábbiakban egyre inkább az agilis fejlesztés előnyei kerülnek előtérbe.

Összehasonlítás a tervezhetőség és a kilátások alapján

A tervezhetőség és a kilátások szempontjából elmondható, hogy a vízesés modell előnyösebb. Akármilyen nagy méretű is a rendszer, amit létrehozunk, azt mindig részekre bontják a ‘felsőbb szintekről az alsóbb szintek felé’ haladva. Ha minden egyes fázisra határidőt állítunk be, akkor annak előrehaladását viszonylag könnyen tervezhetővé és kezelhetővé tehetjük.

Másrészről az agilis fejlesztés, mivel nem igényel túl sok költséget és erőfeszítést az előzetes tervezésre és a teljes koncepcióra, hajlamos lehet a helyzet szerinti megközelítésre.

Egyéni szerepkörök és felelősségi körök tisztázásának összehasonlítása

A Vízesés modellben a folyamatok részletes felosztása lehetővé teszi, hogy az egyes projekttagok szerepköreit egyértelműen meghatározzuk. Ez jelentős előnyt jelent.

Viszont az Agile fejlesztés során a folyamatok felosztása gyakran homályos, ami hajlamos arra, hogy a váratlan problémák esetén is homályos legyen, hogy ki vállalja a felelősséget.

Nagy volumenű fejlesztések összehasonlítása a megvalósíthatóság szempontjából

A tervezhetőség és a szerepek tisztázottsága terén kiemelkedő Waterfall modell nagy volumenű fejlesztések esetén jelent nagy előnyt. Akár nagyszámú személyzet szervezése mellett is, ha a munkafolyamatokat részletekre bontjuk és elősegítjük a munkamegosztást, az emberi kapcsolatok kezelésével járó költségeket csökkenteni tudjuk.

Ezzel szemben az Agile fejlesztési modellt általában nem tartják alkalmasnak nagy volumenű fejlesztésekre. Mivel ez az megközelítés a tervezhetőségnél és a szerepek tisztázottságánál inkább a projektbe való gyors belevágásra helyezi a hangsúlyt, nehezen alkalmazható olyan helyzetekben, ahol a végső határidők eltolódása okozhat aggodalmat.

Összehasonlítás a sebesség és hatékonyság szempontjából

Az agilis fejlesztés gyorsabban kezdődik

Ha a felhasználók valamilyen funkcióra vonatkozó igényt fogalmaznak meg, és azt ténylegesen megvalósítják, az agilis fejlesztési modell gyorsabb. Ennek oka, hogy a vízesés modellben általában világosan elkülönülnek a felelősök a felső és alsó folyamatokban, és a szolgáltató belső kommunikációja gyakran időigényes. Ez a sok kommunikációs idő gyakran összefügg azzal, hogy gyengébben reagál a specifikációk utólagos módosítására.

Másrészről, az agilis fejlesztési modellben várható, hogy közvetítő nélkül gyorsan elkezdhető és végrehajtható a munka. Ez szorosan összefügg az agilis fejlesztési modell legnagyobb előnyével, hogy könnyen kezelhetők a specifikációk utólagos módosításai. Mindazonáltal, még az agilis fejlesztési modell esetében is, ha folyamatosan engedünk a specifikációk módosításának és a további fejlesztési igényeknek, az a projekt “kiégéséhez” vezethet. Ebben az értelemben, az agilis fejlesztési modell szerinti rendszerfejlesztés sikerének kulcsa a “változáskezelés”. A változáskezelésről részletesen a következő cikkben olvashat.

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

A vízesés modell kevésbé valószínű, hogy közben megszakad

Másrészről, a sebesség és hatékonyság szempontjából történő összehasonlításban fontos a hosszú távú időkeret is. Ha azt a kockázatot vesszük figyelembe, hogy a projekt közben “kiég”, és nincs további haladás, a vízesés modell a nyerő. A projekt közbeni megszakadás legnagyobb kockázata a felhasználók és a szolgáltató közötti kommunikációs zavar. A vízesés modell, amely könnyen tisztázza a felek szerepeit, ebben a tekintetben előnyös.

Az agilis fejlesztés könnyebben halad az átvételi szakaszban

Ugyanakkor, ha az átvételi szakaszban történő előrehaladás könnyedségét nézzük, az agilis fejlesztési modell előnyben van. Ennek oka, hogy a felhasználók és a szolgáltató között a rendszerfejlesztés közbeni folyamatban is részletes információcserére van szükség. Várható, hogy csökkenthető a kockázat, hogy a végleges termék megtekintésekor a felek közötti nézeteltérések hirtelen nyilvánvalóvá válnak. A rendszerfejlesztés átvételének lépéseiről és a hozzájuk kapcsolódó jogi kérdésekről részletesen olvashat a következő cikkben.

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

Összefoglalás

Összehasonlítva, általánosságban elmondható, hogy a menedzsment alapos végrehajtását a Vízesés modell szolgálja, míg a gyorsaságot és végrehajtást az Agile fejlesztési modell preferálja. Az Agile fejlesztési modell alapján végzett rendszerfejlesztéssel kapcsolatos jogi kérdéseket a következő cikkben tárgyaljuk részletesen.

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

Az, hogy melyik fejlesztési modell a legalkalmasabb, nem csak a jogi szempontokat kell figyelembe venni, hanem a projekt méretét, költségvetését, céljait stb. is, és átfogóan kell dönteni.

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:

Vissza a tetejére