prototípus modell

a korábbi modellek (waterfall és spirál) legjelentősebb hátránya, hogy az alkalmazás kifejlesztése után sok ügyfél elutasításra került, és az ügyfelek nem vettek részt a projekt között.

ezért kezdték el az új megközelítést, amelyet prototípus-modellnek neveznek. Ebben összegyűjtjük a követelményeket az ügyféltől, és elkészítjük a prototípust (mintát), és az ügyfél felülvizsgálja és jóváhagyja. És csak akkor, ha elégedettek, elkezdünk dolgozni az eredeti projekteken, hogy ne legyen ügyfél elutasítás.

a prototípus csak a szükséges szoftver termék mintája vagy próbabábuja. Ha az összes említett modul jelen van, akkor csak a fejlesztő és a tesztelő végez prototípus tesztelést.

amikor a prototípus modellt használjuk

általában ezt a modellt választjuk a következő okok miatt:

  • amikor az ügyfél új a szoftveriparban, vagy amikor nem tudja, hogyan adja meg a követelményeket a vállalatnak.
  • amikor a fejlesztők újak a domainben.

Megjegyzés:
a tesztelés és a prototípus tesztelés közötti különbség az, hogy – a tesztelés során a funkcionalitáson dolgozunk, ami némi bemenetet és kimenetet ad.
és a prototípus tesztelésnél csak a kinézetet és az érzést teszteljük, ami azt jelenti, hogy az UI és a frontend.

prototípus modell folyamat

prototípus modell különböző fázisok, amelyek a következők:

  • követelmény elemzés
  • megvalósíthatósági tanulmány
  • prototípus létrehozása
  • prototípus tesztelés
  • ügyfél felülvizsgálata és jóváhagyása
  • tervezés
  • kódolás
  • tesztelés
  • telepítés és karbantartás

prototípus modell

követelményelemzés

ez a modell az ügyfelek követelményeinek összegyűjtésével kezdődik. A projekt ezen követelményeinek pedig részleteknek kell lenniük. Ezeket a részleteket az üzleti elemző és a Termékelemző kapja meg. Ahol az üzleti elemzőt a szolgáltatásalapú szoftvercégekhez, a Termékelemzőt pedig a termékalapú szoftvercégekhez rendelik.

megvalósíthatósági tanulmány

a következő szakaszban a BA, a HR, az építészet és a pénzügyi csapatok vezetője együtt ül, és beszél a termék költségeiről, melyik erőforrásra lesz szükség, mely technológiát használják a termék fejlesztésére, és mennyi időre van szükség a termék befejezéséhez és szállításához.

hozzon létre egy prototípust

a megvalósíthatósági tanulmány befejezése után a következő szakaszba lépünk, ahol az ügyféltől gyűjtött adatok alapján elkészítjük a prototípust (minta vagy próbabábu), és a webfejlesztő megtervezi a prototípust.

itt van a következő típusú prototípus:

  • statikus prototípus
  • dinamikus prototípus

statikus prototípus

a statikus prototípusban a követelmények teljes prototípusát egy word dokumentumban tartottuk, az összes iránymutatással, képernyőképpel és a szoftver felépítésének leírásával, a kész termék kinézetével és működésével stb.

dinamikus prototípus

a dinamikus prototípus párhuzamos a böngészővel, de itt nem tudunk részleteket megadni, csak a funkcionalitás van ott az adatok megadása nélkül. Ez olyan, mint egy dummy oldal készült a html, amelynek címkéket és linkeket a különböző oldalak kifejező jellemzői A termék.

prototípus tesztelés

miután elkészítettük a prototípust, a BA teszteli a prototípust, és elvégzi a prototípus tesztelését.

Megjegyzés:
a prototípus tesztelése tesztelés, ahol csak a megjelenést teszteljük, ami azt jelenti, hogy az UI és a frontend.

ügyfél felülvizsgálata és jóváhagyása

miután a prototípus tesztelése megtörtént, átadják az ügyfélnek felülvizsgálatra és jóváhagyásra. Ha a Megrendelő nem elégedett az adott mintával, a megrendelő útmutatásai és visszajelzései alapján megváltoztatjuk a prototípust. Ez a folyamat addig folytatódik, amíg az ügyfél jóváhagyja és elégedett a prototípussal. Ez egy kicsit időigényes, mert újra és újra el kell végeznünk a változtatásokat a prototípusban.

tervezés

a jóváhagyott prototípus megszerzése után megkezdjük a végtermék magas szintű és alacsony szintű tervezését, és figyelembe vesszük az ügyfél által a végső prototípus idején adott összes javaslatot.

kódolás

miután a tervezési szakasz sikeresen befejeződött, áttérünk a kódolási szakaszra, ahol az érintett Fejlesztő programozási ismeretei alapján megkezdi a termék fejlesztését.

tesztelés

a fejlesztési szakasz összeállítása után átadják a tesztmérnöknek. A tesztmérnök pedig teszteli az alkalmazás funkcionalitását, valamint az összes bemenetet és kimenetet.

telepítés és karbantartás

miután a végterméket kifejlesztettük és teszteltük a végső prototípus szerint, a gyártásba kerül. A termék időről időre karbantartást végez, hogy csökkentse a megszakításokat, ami segít elkerülni a jelentős hibákat.

Megjegyzés:

  • a Követelménygyűjtéstől az ügyfél-áttekintésig a dokumentált formátum prototípus formátummá alakul, mivel ez egy kiterjesztett követelménygyűjtési szakasz, a tényleges tervezés pedig a tervezési fázistól kezdődik.
  • korábban a prototípus fejlesztését a fejlesztők végezték. Ennek ellenére most tartalomfejlesztők vagy webes tervezők végzik, ahol néhány eszköz segítségével fejlesztik a termék prototípusát.
  • ebben, az ügyfél kap egy esélyt a kezdő maga kérni változások a követelmény, mivel könnyen csinálni követelmények változások a prototípus helyett a tényleges alkalmazás. Ezért a költségek csökkennek, és az elvárások teljesülnek.

a prototípus modell előnye és hátránya

a prototípus modell előnyei és hátrányai a következők:

előny hátrány
könnyen észlelhetjük a hiányzó funkciókat. ez egy időigényes folyamat, mert ha az ügyfél megváltoztatja a prototípust.
és azzal is pazarolja az időnket, hogy újra és újra megváltoztatja a próbabábut (prototípust), ami késlelteti a valódi projekt működését.
ebben a fejlesztőcsapat és az ügyfél egyértelmű kommunikációt folytat a termék követelményeivel és eredményével kapcsolatban. nincs követelmény felülvizsgálat, de a prototípus felülvizsgálat van.
ebben az ügyfél-elégedettség létezik. Nincsenek párhuzamos eredmények, ami azt jelenti, hogy a két csapat nem működhet együtt.
a prototípust újra felhasználhatjuk a tervezési fázisban és hasonló alkalmazásokhoz. előfordulhat, hogy a részleges alkalmazás miatt a szoftvert nem használják, mivel a teljes rendszert tervezték.
ebben a modellben az ügyfél elutasítása kisebb, mint a többi modellnél. elégtelen vagy részleges problémaelemzés.
a problémák a korai szakaszban azonosíthatók. az ügyfelek figyelmét is elveszíthetjük, ha nem elégedettek a végtermékkel vagy az eredeti prototípussal.

Leave a Reply