Bevezetés a vízesés modelljébe

Az építőiparból és a gyártóiparból származó, erősen strukturált fizikai környezet, amelyet tervezési és fejlesztési folyamatokhoz szántak. A vízesés modellt szoftverfejlesztési életciklus-modellként is ismertek. Ez volt az első folyamatmodell, amelyet lineáris-szekvenciális életciklus-modellként mutattak be. A vízesés modell egyszerűen azt mondja a jelenségről, hogy az egy fázist teljes mértékben be kell fejezni, mielőtt az új fejlesztési fázist megkezdené, így nincs fázis átfedés. A szoftverfejlesztés területén a vízesés modelljét először SDLC megközelítésként alkalmazták. A vízesés modelljének kidolgozásához meg kell értenünk annak alkalmazási megközelítését, mind belső, mind külső tényezők alapján, amelyek a következők lehetnek:

  • Az alkalmazásban nincsenek egyértelmű követelmények.
  • A termékmeghatározás stabilitása
  • Ez a technológia érthető
  • Nem dinamikus
  • A termék támogatásához nagy források és megfelelő szakértelem áll rendelkezésre
  • Vey rövid hosszúságú projekt
  • Jó dokumentum, világos és rögzített követelmények.

A vízesés modell történetével kezdve azt szeretném mondani, hogy a vízesés modelljének első mintáját Winston w Royce 1970-ben vezette be egy cikkben. Azóta a vízesés modellje szerint az embernek csak akkor kell átváltania egy másik fázisra, amikor az előző fázisokat teljes mértékben tesztelik, felülvizsgálják és ellenőrzik. Hangsúlyozza a fázislépések logikus haladását. Funkcionálissága hasonló a szikla szélén átfolyó vízhez. A szoftverfejlesztésnek ezt a megközelítését vízesésnek nevezték, mert szisztematikusan fejlődik egyik fázisból a másikba lefelé. A Winston W. Royce 1970-es kiadása óta a vízesés modelljét széles körben alkalmazzák a szoftverfejlesztés területén. A szoftverfejlesztési folyamat ciklusában a programozási modelleket használják az alkalmazás fejlesztésének különféle szakaszaira. Az egyik ilyen modell a vízesés.

A vízesés modell fázisai

Most beszéljünk a vízesés modell fázisairól, amelyek egyértelműen megmagyarázhatók ezzel a demo infographic segítségével.

A fenti infographics segítségével megérthetjük, hogy a vízesés modellje összesen 7 tervezési és fejlesztési szoftverciklusból áll, amelyek a következők:

  1. követelmények
  2. Elemzés
  3. Tervezés
  4. Kódolás / megvalósítás
  5. Tesztelés
  6. Művelet / telepítés
  7. Karbantartás

Tehát láthatjuk, hogy a vízesési modell felülről lefelé működik, és az egyik fázis teljes ellenőrzéssel befejeződik, majd átvált egy másik fázisra, beleértve a fázisfolyamatokat is, mint például a koncepció, az inicializálás, az elemzés, a tervezés, az építés, a tesztelés, a gyártás / megvalósítás és a karbantartás. Annak érdekében, hogy rövidebb ismereteket szerezzünk a vízesés modelljéről, meg kell értenünk minden folyamatát, mélyen a munka modelljével. Van egy alapvető előfeltétel, amelyet meg kell érteni a tudás mély fázisának megkezdése előtt. A szoftver termék megvalósíthatósági tanulmányáról szól. A projekt követelményeinek pénzügyi és technikai szempontjaival foglalkozik. Ez a szakasz az intézkedések javításával foglalkozik az elemzett előnyök és hátrányok alapján. Így a legjobb megoldást választják.

  1. Követelmények: Mivel szavakkal specifikus, tudnunk kell és meg kell értenünk, mit kell megterveznünk, mit kell kifejlesztenünk, a folyamatait, mi lesz a funkcionalitása stb. Bemeneti anyagot szolgáltat a készítendő termékhez, és így a következő termékhez megvizsgálják, véglegesítik és megjelölik. Ez kiterjesztést is ad arra, hogy eldöntsük a termék hardver- vagy szoftverkövetelményeit, amelyeket minden szakaszban megtervezünk, fejlesztünk és rögzítünk.
  2. Elemzés: Ennek eredményeként modelleket, sémákat és üzleti szabályokat tervezünk. Ez a követelmény nem csak két részre oszlik:
  • Követelmények összegyűjtése és elemzése: Először a termékfejlesztéshez szükséges összes információt és követelményt összegyűjtik a vásárlótól, majd elemzés céljából feldolgozzák. Ennek a résznek a fő szerepe a szoftvertermékek fejlesztésével kapcsolatos hiányosságok és következetlenségek felszámolása.
  • Követelmény-specifikáció: Ezután a fent elemzett követelményeket egy SRS (szoftverkövetelmény-specifikáció) dokumentumban dokumentálják. Útként szolgál az ügyfél és az SRS fejlesztő csapata között. A jövőben felmerülő minden vitát csak ez az SRS dokumentáció kezel és kezel.
  1. Tervezés: Az első szakasz befejezése és ellenőrzése után ez a következő legfontosabb tanulmányozandó szakasz, mivel a rendszer tervezéséhez használják. Segít a termék-tervezéshez szükséges szoftver- és hardverkövetelmények meghatározásában. Ez a rendszer tervezésének általános architektúrájában is segít. Tehát ebben a szakaszban a követelmény-specifikációt többnyire megvizsgálják és ellenőrzik. Hasznos az SRS dokumentum átalakításában a szoftvertermék funkcionális tervezésévé és fejlesztésévé. Tehát mondhatjuk, hogy a tervezési szakaszban elkészítjük a szoftverfejlesztési projekt általános architektúráját.
  2. Végrehajtás: A rendszer tervezésének teljes ellenőrzése után a végrehajtási szakasz sorba kerül. Ebben a fázisban a rendszer tervezéséből származó bemeneteket veszik át, és először egységekként ismert kis programokban fejlesztik ki, amelyeket a következő szakaszban tesztelnek és valósítanak meg. A megvalósítási szakaszban minden egység fejlesztésen megy keresztül, és teljes funkcionalitását tesztelik, amelyet egységtesztnek is hívnak. Tehát ebben a fázisban a rendszer kialakítását forráskódrá alakítják át teljesen működőképes programmodulokkal. Ez magában foglalja a szoftver fejlesztését, bebizonyítását és integrálását.
  3. Integráció és tesztelés: Az egyes egységek tervezését és a korábbi szakaszokban kifejlesztett elemeket a megvalósítási fázisból építették be, amelyet egy modul vagy rendszerbe integrálnak egy különféle teszthez, például terhelésteszthez, vezetékteszthez stb., Az egyes egységek tesztelése után. A tesztelési környezet folyamatos szoftver-ellenőrzésen megy keresztül, hogy kiderüljön-e áramlás vagy hiba a tervben vagy a kódban. A tesztelés célja a szoftver stabilitásának és megvalósíthatóságának fenntartása, hogy az ügyfél a gyártása során ne kerüljön semmilyen zavarra vagy hibára. Tehát ebben a szakaszban a megvalósítás után az egész rendszert alaposan tesztelik minden hiba és hiba szempontjából. A rendszer tesztelése háromféle tevékenységet foglal magában, amelyeket az alábbiak szerint lehet megmagyarázni:
  • Alfa (α) tesztelés: Ez a tesztelés, amelyet a fejlesztői csapat végez.
  • Béta (β) tesztelés: Ez a tesztelés, amelyet az ügyfelek és a felhasználók barátságos csapata végez.
  • Elfogadási tesztelés: az alfa- és a béta-tesztelés után is elvégzik. Alapvetően ezt a tesztelést az ügyfelek kézbesítése után végzik el. Az ügyfél által végzett tesztelés után döntenek arról, hogy elfogadható-e ez a szoftver, vagy elutasítja azt. Tehát ebben a fázisban alapvetően a hibák kijavítására kerül sor.
  1. A rendszer üzembe helyezése / műveletek: Miután elvégezték a nem funkcionális, funkcionális, alfa és béta tesztelést, a szoftver termékét telepítik a felhasználói vagy az ügyfél rendszerbe, vagy pedig a piacra engedik. A telepítési szakasz magában foglalja a teljes rendszer telepítését, áttelepítését és támogatását a felhasználói vagy az ügyfélkörnyezetbe.
  2. Karbantartás: Ez az utolsó, de a legfontosabb szakasz a vízesés munkafolyamat-modelljében. Ez a lépés közvetlenül a telepítés után jön, és magában foglalja a termék vagy rendszer megfelelő módosítását, vagy a rendszerhez kapcsolódó teljesítményproblémához kapcsolódó attribútumok fejlesztését, módosítását vagy módosítását. fő feladata a rendszer teljesítményének javítása a szoftver kimenetének maximális pontosságú eredménye alapján. Ezek a karbantartási szakaszban felmerült változások nagyrészt azokkal a változásokkal kapcsolatosak, amelyeket az ügyfél vagy a felhasználók a telepítés és a tesztelés után indítanak el, és amelyek olyan hibákat tartalmaznak, mint a rendszer élő használata során feltárt hibák vagy az ügyfelek által felvetett kérések. Tehát az ügyfél időben és ütemezett módon karbantartást és támogatást kap a kifejlesztett termékhez. Nagyon meg fog lepődni, hogy tudomásul veszi, hogy a szoftver termék tervezési és fejlesztési szakaszában tett erőfeszítés csak a 60% -os erőfeszítés a karbantartási szakaszban tett erőfeszítésekhez képest. Alapvetően háromféle karbantartás létezik, amelyeket az alábbiakban magyarázunk:
  • Javító karbantartás: A tervezési és fejlesztési szakaszban néhány hibát nem fedeznek fel, csak akkor veszik figyelembe, amikor az ügyfél használja. Ez csak a korrekciós karbantartás, azaz olyan problémák vagy hibák kijavítását jelenti, amelyeket a fejlesztési szakaszban nem fedeztek fel.
  • Tökéletes karbantartás: Az ilyen típusú karbantartást az ügyfél kérésére végzik a rendszer vagy a szoftver funkcionalitásának növelése és továbbfejlesztése érdekében.
  • Adaptív karbantartás: a karbantartásra van szükség a rendszerkörnyezet váltásához. Általában a meglévő rendszer egy új környezetbe vagy új számítógépre vagy rendszerre, vagy esetleg egy új operációs rendszerre való átviteléhez szükséges. Ez a szakasz túl fontos, mivel ez jobb rendszerteljesítményhez vezet.

Tehát a fenti beszélgetés során megismertük a vízesés modell minden szakaszát, teljes specifikációval. Tehát azt mondhatjuk, hogy a vízesés modellje a szoftver területén is nagyon fontos a mechanikai iparágakhoz képest, mivel minden fázisnak megvan a maga jelentőssége, ez eredményesebb és stabilabb szoftvert eredményez.

Előnyök

Ez a vízesésmodell nemcsak a szoftverfejlesztési életciklusban sokkal több előnnyel rendelkezik, amelyeket az alábbiakban tárgyalhatunk:

  • Lehetővé teszi osztályozást és ellenőrzést.
  • Az ütemtervet határidőkkel lehet meghatározni az egyes fejlesztési szakaszokra, és egy termék egyesével eljuthat a fejlesztési folyamat modellfázisaiba.
  • Mivel könnyen érthető és érthető szakaszokon megy keresztül, sok kérdést legyőz, így nagyon könnyen használható.
  • A munkafolyamat-modell merevsége miatt ezt nagyon könnyű kezelni, mivel a vízesés-modell minden szakaszában külön felülvizsgálati és szállítási folyamatok vannak.
  • A vízesésmodell jól működik kisebb projekteknél, ahol a követelmények nagyon jól érthetők.
  • Az ütemtervet határidőkkel lehet meghatározni az egyes fejlesztési szakaszokra, és egy termék a fejlesztési folyamat modellfázisaival egyenként haladhat tovább.
  • Világosan meghatározott szakaszok.
  • Jól érthető mérföldkövek.
  • Könnyen elrendezhető feladatok.
  • A folyamat és az eredmények jól dokumentáltak.
  • Megerősíti a jó szokásokat: a tervezés előtti meghatározás,
  • Tervezze-before-kódot.
  • A modell jól működik kisebb projekteknél és olyan projekteknél, ahol a követelmények jól érthetők.

Hátrány

Mivel tudjuk, hogy minden érmenek két oldala van, tehát a vízesésmodell előnyeinek széles körű hozzáférése révén a vízesésmodellnek vannak bizonyos hátrányai, vagy elmondhatják az alább tárgyalt hátrányokat:

  • Nem jó modell komplex és objektum-orientált projektekhez.
  • Nem alkalmas azoknak a projekteknek a számára, ahol a követelmények változásának közepes vagy magas kockázata áll fenn.
  • Nehéz becsülni az időt és a költségeket a fejlesztési folyamat egyes szakaszaira.
  • Nem jó modell komplex és objektum-orientált projektekhez.
  • Az életciklus későig egyetlen szoftver sem készül.
  • Nem alkalmas a változó követelményekre.
  • Nehéz mérni az előrehaladást szakaszonként.
  • Magas kockázat és bizonytalanság.
  • Rossz modell hosszú és folyamatban lévő projektekhez.
  • A hatókörnek az életciklus során történő módosítása befejezheti a projektet.
  • Nincs visszajelzési út
  • Nincs átfedés a fázisokban
  • Nehéz beilleszteni a változási kérelmeket.
  • a kockázat és a bizonytalanság ebben a folyamatmodellben magas.

Hol használható vízesési modell

Az összes forgatókönyvet körülvéve, eljutunk egy ponthoz, ahol meg akarjuk tudni, hogy hol kell használni a vízesés modelljét.

  • A védelmi projektekben főként vízesési modellt alkalmaznak, mivel ott a követelmény egyértelmű, mivel a fejlesztési szakaszba lépés előtt jól elemzik azt.
  • Ezt olyan migrációs projektekben is lehet használni, ahol a követelmények ugyanaz lesznek, csak a platform vagy a nyelvek változhatnak / változhatnak.

Következtetés

Tehát összességében elmondhatom, hogy a vízesésmodell a legmegfelelőbb egy kis szoftverfejlesztési projekthez, mint a nagy projektekhez, mert a kisprojektnél a vízesésmodellnél dolgozva könnyebb a tervezés, fejlesztés és megvalósítás, mivel ebben a modellben minden korábbi szakaszra szükség van be kell fejezni, ha a következő szakaszokra megy. Tehát a nagyprojektben a problémák és hibák gyakran előfordulnak, mivel nagy modellje van, tehát a tesztelési fázist minden alkalommal folytatják, ha a vízesésmodell segítségével valósítják meg, ami kevesebb optimalizálást és pontosságot eredményez a szoftverben.

Ajánlott cikkek

Ez egy útmutató a Vízesés modellhez. Itt megvitassuk a vízesés modell fázisait, előnyeit és hátrányait. A további javasolt cikkeken keresztül további információkat is megtudhat -

  1. Mi az AWS?
  2. Mi az a Bootstrap?
  3. Mi a kaptár?
  4. Mi az Unix?
  5. Scrum vs vízesés Összehasonlítás

Kategória:

Szoftverfejlesztés