Kaskadinis gyvavimo ciklo modelis: privalumai ir trūkumai

2024 Autorius: Howard Calhoun | [email protected]. Paskutinį kartą keistas: 2023-12-17 10:34

Programinės įrangos kūrimas nėra panašus į tradicinę inžineriją. Metodika yra tai, ką kūrėjai naudoja norėdami suskirstyti darbą į valdomus laipsniškus žingsnius, kurių kiekvienas gali būti peržiūrėtas siekiant užtikrinti kokybę. Komandos kartu su klientu kuria gatavą programinės įrangos produktą, naudodamos vieną iš programinės įrangos kūrimo metodikų. Populiariausi iš jų yra spiralinis, krioklys arba kaskadinis modelis (Waterfall); RAD arba Rapid Application Development; Agile Model, arba lankstus ir pasikartojantis, arba pasikartojantis modelis. Yra ir kitų variantų, tačiau šiame straipsnyje apžvelgsime tik krioklio, arba krioklio, projekto gyvavimo ciklo modelį, taip pat išnagrinėsime jo privalumus ir trūkumus. Iš karto paaiškinkime, kad tai tam tikrų žingsnių seka, o jos ypatumas yra tas, kad naujas etapasneįmanoma, kol nebus baigtas ankstesnis.

Krioklio modelio istorija

Tradicinės formos metodika nepalieka vietos netikėtiems pokyčiams. Jei kūrėjų komanda nėra per didelė, o projektai yra nuspėjami, „Waterfall“gali užtikrinti, kad jie bus baigti laiku.

Krioklio plėtros modelis gyvuoja daugiau nei keturiasdešimt metų. Pirmą kartą jis buvo aprašytas 1970 m. W. Royce'o straipsnyje kaip vienas iš pirmųjų oficialių kūrimo proceso modelių. Ji buvo apibūdinta kaip neveiksminga dideliems programinės įrangos kūrimo projektams, tačiau niekas nedraudė jo naudoti mažiems. Praėjus beveik pusei amžiaus nuo atradimo, ši technika vis dar aktuali ir šiandieniniame verslo pasaulyje. Jis buvo vadinamas pasenusiu modeliu ir į jį žiūrima su panieka dėl tradicinio projektų valdymo metodo pasenimo. Tačiau „Waterfall“yra naudingas ir nuspėjamas metodas, jei reikalavimai yra fiksuoti, gerai dokumentuoti ir aiškūs, jei technologija suprantama ir kai projektui įgyvendinti nereikia daug laiko. Šiuo atveju programinės įrangos gyvavimo ciklo krioklio modelis gali užtikrinti labiau nuspėjamą galutinį rezultatą atsižvelgiant į nurodytą biudžetą, laikotarpį ir darbo apimtį.

Koks yra krioklio plėtros modelis?

Waterfall modelį galima apibūdinti kaip linijinį, nuoseklų projekto vystymą, kai procesai nuolat pereina nuo reikalavimų prie projektavimo, tada prie įgyvendinimo, patikrinimo ir diegimo suvėlesnė nuolatinė priežiūra. Manoma, kad kaskadinis gyvavimo ciklo modelis buvo sukurtas W. Royce'o dėka, nors jis pats naudojo kartotinį kūrimo modelį.

Pagrindinis „Waterfall“kūrimo akcentas yra planavimas, laikas, tikslai, biudžetai ir galiausiai visos sistemos kaip vieno subjekto įgyvendinimas. Pagrindiniai pranašumai yra paprastas planavimas ir įgyvendinimas pirmyn ir atgal.

Krioklio modelio aprašymas

Palyginti su kitomis metodikomis, „Waterfall“daugiau nei kitos skiria aiškiam, apibrėžtam žingsnių rinkiniui. Originalų modelį sudarė penki etapai. Jis dažnai apibūdinamas kaip linijinis nuoseklus gyvavimo ciklo modelis. Tai reiškia, kad jis vadovaujasi paprasta fazės struktūra, kai kiekvienos fazės rezultatai pereina į kitą vystymosi lygį. Pagrindiniai žingsniai yra šie:

1. Surinkite reikalavimus ir sukurkite dokumentus.
2. Dizainas ir sistemų inžinerija.
3. Įdiegimas.
4. Testavimas ir diegimas.
5. Palaikymas.

Komandos turi atlikti visą veiksmą prieš pereidamos prie kito, todėl jei kažkas nebus paruošta iki tam tikro termino, tai iškart pastebima. Be to, skirtingai nei Six Sigma ar Scrum, Waterfall nereikalauja sertifikavimo ar specialaus projektų vadovų ar darbuotojų mokymo.

Krioklio modelio kritika

Informacinės sistemos gyvavimo ciklo kaskadinis modelisbuvo kritikuojamas dėl savo nelankstumo atlikus kiekvieną žingsnį ir uždelsimą klientui pateikti grįžtamąjį ryšį. Tačiau ši metodika puikiai tinka mažesniems projektams su ribotu biudžetu. Jis dažnai lyginamas su viena gerai žinoma projekto gyvavimo ciklo metodika PRINCE2, kurią sukūrė JK vyriausybė. Ši metodika vis dar taikoma viešajame sektoriuje. Vienas iš pagrindinių PRINCE2 ir krioklio gyvavimo ciklo modelio skirtumų yra tas, kad pastarasis reikalauja raštiško visų reikalavimų aprašymo nuo pat pradžių, nes vėliau juos gali būti sunku peržiūrėti. Prieš pradedant kurti bet kokį kodą, jie turi būti tiksliai apibrėžti ir užfiksuoti. Tai svarbus krioklio gyvavimo ciklo modelio pranašumas.

Krioklio modelio privalumai ir trūkumai

Kadangi techninė dokumentacija yra būtina pradinio reikalavimų rengimo fazės dalis, tai reiškia, kad visi komandos nariai aiškiai supranta projekto tikslus. Nauji kūrėjai gali greitai perprasti kodo kūrimo taisykles ir be jokių problemų prisijungti prie darbo eigos. Naudojant informacinės sistemos ar projekto gyvavimo ciklo krioklio modelį, laipsniškas vykdymas užtikrina discipliną.

Kiekvienas veiksmas turi aiškiai apibrėžtą pradžios tašką ir pabaigą, todėl lengva stebėti pažangą. Tai padeda sumažinti bet kokį projekto vykdymo nukrypimą nuo sutartų terminų.sistema. Šiame modelyje, priešingai nei spirale, programinė įranga laikoma visuma. Todėl, jei tenkinami visi reikalavimai, jis veikia efektyviau. Jei ir toliau lyginsime kaskadinius ir spiralinius gyvavimo ciklo modelius, galime daryti išvadą, kad pirmasis yra universalesnis ir gali būti taikomas įvairiose srityse.

Derybų dėl reikalavimų etapas

Kitas krioklio gyvavimo ciklo modelio privalumas yra tai, kad sąnaudas galima įvertinti gana tiksliai, kai tik nustatomi visi reikalavimai. Jei jis taikomas, tai reiškia, kad pirmajame etape visi testavimo scenarijai jau yra detaliai aprašyti funkcinėje specifikacijoje, todėl testavimo procesas tampa paprastesnis ir skaidresnis. Ir dar prieš kuriant programinę įrangą, dizainas yra detaliai išdirbtas, todėl poreikiai ir rezultatas tampa aiškūs kiekvienam.

Vienas puikių dalykų naudojant „Waterfall“yra siekti galutinio produkto arba galutinio rezultato nuo pat pradžių. Todėl komandos turi vengti nukrypimo nuo tikslo. Mažesniems projektams, kurių tikslas yra gana aiškus, šis žingsnis leidžia komandai nuo pat pradžių suvokti bendrą tikslą, o tai sumažina galimybę pasiklysti detalėse projektui judant į priekį. „Waterfall“požiūris yra labai metodiškas, todėl pabrėžiama aiškaus bendravimo svarba kiekviename etape. Programinės įrangos kūrimo procese kiekviename naujame žingsnyje atsiranda naujų žmonių. Todėl svarbu stengtisdokumentuoti informaciją per visą projekto gyvavimo ciklą.

Krioklio gyvavimo ciklo modelio trūkumai

Galimas plėtros problemas galima ištirti ir išspręsti projektavimo etape. Taip pat rengiami alternatyvūs sprendimai ir parenkami optimaliausi. Visa tai vyksta prieš projekto pradžią. Daugelis organizacijų nuo pat pradžių vertina dėmesį dokumentacijai, nes tai taip pat reiškia, kad galutiniame produkte neturėtų būti staigmenų. Tačiau praktiškai retai pavyksta išsiversti be pakeitimų. Klientams dažnai sunku suprasti savo poreikius funkcinių specifikacijų požiūriu tik reikalavimų stadijoje. Tai reiškia, kad pamatę galutinį produktą jie gali persigalvoti. Tokią problemą sunku išspręsti. Kartais programa turi būti beveik visiškai perkurta.

Trūksta lankstumo krioklio modelyje

Kitas kaskadinio IP (arba projekto) gyvavimo ciklo modelio trūkumas yra galimas lankstumo trūkumas. Gali kilti klausimų dėl naujų ar reikalavimų pasikeitimų, įvykusių po pirminių konsultacijų.

Planuojant gali būti neatsižvelgta į patikslinimus dėl verslo planų arba rinkos įtakos. Be to, projektai gali užtrukti ilgiau, palyginti su pasikartojančios metodikos, pvz., „Agile“naudojimu.

Svarbūs punktai naudojant krioklio metodiką

Kalbant apie „Waterfall“kūrimą, labai svarbu, kad programinės įrangos kūrėjai galėtų veiksmingai vadovauti ir patarti klientams, kad vėliau išspręstų visas šias problemas. Dažnai svarbiausias krioklio gyvavimo ciklo modelio taikymo aspektas yra tai, kad klientai iš tikrųjų nežino, ko iš tikrųjų nori. Daugeliu atvejų tikroji abipusė kūrėjų ir klientų sąveika nevyksta tol, kol klientas nepamato modelio veikimo.

Palyginimui, Agile kūrime klientas gali matyti darbo kodo fragmentus, kurie buvo sukurti dirbant su projektu. Skirtingai nuo „Scrum“, kuris projektus skirsto į atskirus sprintus, „Waterfall“visada sutelkia dėmesį į galutinį tikslą. Jei jūsų komanda turi konkretų tikslą su aiškia pabaigos data, „Waterfall“pašalina riziką praleisti terminą, kai jį įgyvendinate. Atsižvelgiant į šiuos privalumus ir trūkumus, „Waterfall“plėtra paprastai rekomenduojama projektams, kurie greičiausiai nepasikeis arba kuriems reikės naujos plėtros per visą projekto laikotarpį.