A prototípus-készítés az a tevékenység, ahol a szoftveralkalmazásokhoz prototípusokat hozunk létre, azaz a befejezetlen verzióit a fejlesztés alatt álló szoftvernek. Ez előfordulhat a szoftverfejlesztésben és összehasonlítható a prototípus-készítéssel ahogy más területeken ismert, mint például a gépiparban vagy a gyártásban.
A prototípus a végterméknek tipikusan csak néhány szempontját szimulálja, és az is lehet, hogy teljesen különbözik attól.
A prototípus-készítésnek számos előnye van: a szoftverfejlesztő értékes visszajelzést kaphat a felhasználóktól a projekt elején. Az ügyfél és a vállalkozó összehasonlíthatja, hogy a készített szoftver megfelel-e a szoftver specifikációjának, amely szerint a szoftver épül. Ezenkívül lehetővé teszi a programozó számára, hogy betekintést nyújtson a kezdeti projektbecslések pontosságába, és hogy a javasolt határidők és mérföldkövek sikeresen teljesíthetők-e. A prototípuskészítés megvalósítása és módszerei az 1970-es évekbeli megjelenésük óta fejlesztés alatt állnak és folyamatos vita tárgyát képezik.
Áttekintés A prototípus célja, hogy lehetővé tegye a szoftver felhasználóinak, hogy úgy értékelhessék a fejlesztők javaslatait az esetleges termék terveivel, hogy azt valójában kipróbálják, ahelyett, hogy leírások alapján kellene értelmezniük és értékelniük azokat. A prototípus-alapú programozás segít megérteni a szoftver funkcióit és a lehetséges veszélyeket vagy problémákat. A prototípuskészítést a végfelhasználók is felhasználhatják a figyelembe nem vett követelmények leírására és igazolására, amelyek kulcsfontosságúak lehetnek a fejlesztők és ügyfeleik közötti kereskedelmi kapcsolatban.Smith MF Software Prototyping: Adoption, Practice and Management. McGraw-Hill, London (1991). Az interakció-tervezés különösen nagymértékben használja a prototípuskészítést e céllal.
Ez a folyamat ellentétben áll az 1960-as és 1970-es évek monolitikus fejlesztési ciklusával, amikor először a teljes programot felépítették, majd kiküszöbölték a tervezés és a megvalósítás közötti esetleges ellentmondásokat, ami így magasabb szoftverköltségeket, valamint az idő és költség rossz becsléseit eredményezett. A monolitikus megközelítést a „(szoftver) sárkány megölése” technikának nevezték el, mivel azt feltételezi, hogy a szoftver tervezője és fejlesztője egyetlen hős, akinek egyedül kell az egész sárkányt megölnie. A prototípuskészítéssel elkerülhetők a kész szoftvertermék cseréjének nagy költségei és nehézségei is.
A prototípuskészítés az egyik szempont, amelyet Frederick P. Brooks említ 1975-ös The Mythical Man-Month című könyvében és a 10. évfordulós „No Silver Bullet” cikkében.
A nagyszabású prototípus-alapú programozás korai példája volt az New York-i Egyetem Ada/ED fordítójának az implementálása az Ada programozási nyelvhez . SETL- ben hozták létre azzal a szándékkal, hogy végrehajtható szemantikai modellt állítson elő az Ada nyelv számára, hangsúlyozva a tervezés és a felhasználói felület tisztaságát a gyorsaság és hatékonyság felett. A New York-i Egyetem Ada/ED rendszere volt az első validált Ada megvalósítás, amelyet 1983. április 11-én tanúsítottak.
A prototípuskészítési folyamat vázlata bélyegkép|475x475px A prototípuskészítési folyamat a következő lépésekből áll: Állapítsuk meg az alapvető követelményeket Határozzuk meg az alapvető követelményeket, beleértve a kívánt bemeneti és kimeneti információkat. Az olyan részleteket, mint például a biztonság, általában figyelmen kívül lehet hagyni. Dolgozzuk ki a kezdeti prototípust Dolgozzuk ki a kezdeti prototípust, amely csak a felhasználói felületeket tartalmazza. (Lásd alább a vízszintes prototípust ) Felülvizsgálat Az ügyfelek, beleértve a végfelhasználókat, megvizsgálják a prototípust, és visszajelzést adnak a lehetséges kiegészítésekről vagy változásokról. Vizsgáljuk felül és fejlesszük a prototípust A visszajelzések felhasználásával javítható mind a specifikáció, mind a prototípus. Szükség lehet tárgyalásokra, hogy mik tartoznak a szerződés/termék hatálya alá. Ha változtatásokat vezettünk be, akkor a 3. és a 4. lépés megismétlésére lehet szükség.
A prototípusok méretei Nielsen a prototípusok különféle dimenzióit foglalja össze Usability Engineering című könyvében:
Vízszintes prototípus A felhasználói felület prototípusának általános fogalma a vízszintes prototípus . Széles képet nyújt egy teljes rendszerről vagy alrendszerről, felhasználói interakcióra összpontosítva nem pedig az alacsony szintű rendszerfunkciókra, mint például az adatbázis-hozzáférés. A vízszintes prototípusok hasznosak:
A felhasználói felület követelményeinek és a rendszer hatókörének megerősítéséhez, A rendszer próbaverziója az üzleti beszerzéshez, Előzetes becslések készítéséhez a fejlesztési időről, költségről és erőfeszítésről.
Függőleges prototípus A vertikális prototípus egyetlen alrendszer vagy funkció továbbfejlesztett, teljes kidolgozása. Hasznos, hogy megszerezzük egy adott funkció részletes követelményeit, a következő előnyökkel:
Finomítási adatbázis kialakítása, Információkat szerezhet az adatmennyiségekről és a rendszer interfész igényeiről a hálózati méretezéshez és a teljesítménytervezéshez, Tisztázza az összetett követelményeket adatlefúrással az aktuális rendszer funkcionalitásig.
A prototípusok típusai A prototípusoknak számos változata van. Ugyanakkor az összes módszer valamilyen módon a prototípusok két fő formáján alapul: az eldobható prototípusok és az evolúciós prototípusok.
Eldobható prototípus Zártvégű prototípusnak is nevezik. Az eldobható vagy gyors prototípus egy olyan modell létrehozására utal, amely végül eldobásra kerül, és nem válik a véglegesen szállított szoftver részévé. Miután az előzetes követelmények összegyűjtését befejezték, elkészítik a rendszer egy egyszerű, működő modelljét, hogy megmutassák a felhasználóknak, a követelményeik hogy nézhetnek ki, mikor beépítik őket egy kész rendszerbe. Ez egy gyors prototípuskészítés.
A gyors prototípuskészítés magában foglalja a rendszer különböző részeinek működő modelljének létrehozását egy nagyon korai szakaszban, egy viszonylag rövid vizsgálat után. Az építkezés során alkalmazott módszer általában meglehetősen informális, a legfontosabb tényező a sebesség, amivel a modellt ellátják. Ezután a modell lesz a kiindulási pont, ahonnan a felhasználók újra megvizsgálhatják elvárásaikat és tisztázhatják igényeiket. Amikor ezt a célt elérték, a prototípus modellt „eldobják”, és a rendszert hivatalosan kidolgozzák az azonosított követelmények alapján.
Az eldobható prototípus használatának legkézenfekvőbb oka az, hogy gyorsan elvégezhető. Ha a felhasználók gyors visszajelzést kapnak a követelményeikről, akkor képesek lehetnek finomítani őket a szoftver fejlesztésének korai szakaszában. A fejlesztési életciklus korai szakaszában a változtatások rendkívül költséghatékonyak, mivel ebben a pillanatban nincs mit átalakítani. Ha egy projektet jelentős munka elvégzése után megváltoztatnak, akkor a kisebb változtatások végrehajtásához nagy erőfeszítésekre lehet szükség, mivel a szoftver rendszereknek sok függősége van. A sebesség döntő jelentőségű az eldobható prototípusoknál, mivel korlátozott idő- és pénzköltség mellett keveset lehet költeni egy prototípusra, amit később eldobnak.
Az eldobható prototípus másik erőssége az, hogy képes felületek létrehozására, amelyeket a felhasználók tesztelhetnek. A felhasználói felület az, amit a felhasználó rendszernek tekint, és ha előtte látja, sokkal könnyebb megérteni a rendszer működését.
… azt állítják, hogy a forradalmi gyors prototípuskészítés hatékonyabb módszer a felhasználói igényekkel kapcsolatos kérdések kezelésére, és ennélfogva nagyobb fejlesztése a szoftver termelékenységének általánosságban. A követelmények sokkal gyorsabban és olcsóbban azonosíthatók, szimulálhatók és tesztelhetők, ha figyelmen kívül hagyják a fejleszthetőség, a karbantarthatóság és a szoftver felépítésének kérdéseit. Ez viszont a követelmények pontos meghatározásához és a felhasználó szempontjából egy érvényes és használható rendszer későbbi felépítéséhez vezet a hagyományos szoftverfejlesztési modelleken keresztül.
A prototípusok osztályozhatóak azon hűség alapján, amellyel megjelenésük, interakciójuk és időzítésük szerint hasonlítanak a tényleges termékhez. Az kicsit valósághű prototípus létrehozásának egyik módszere a papír prototípus . A prototípust papírokkal és ceruzákkal valósítják meg, így utánozzák a tényleges termék funkcióját, de nem hasonlítanak rá. A nagyon valósághű eldobható prototípusok egyszerű előállításának másik módja egy GUI Builder használata és egy kattintással létrehozott próbabábu létrehozása, amely prototípus úgy néz ki, mint a célrendszer, de nem nyújt semmilyen funkcionalitást.
A forgatókönyvek, az animációk vagy a rajzok használata nem pontosan ugyanaz, mint az eldobható prototípusé, de minden bizonnyal ugyanabba a családba tartozik. Ezek nem funkcionális megvalósítások, de megmutatják, hogyan fog kinézni a rendszer.
Összesítve: Ebben a megközelítésben a prototípust azzal a gondolattal építik fel, hogy azt el fogják dobni, és a végső rendszert a semmiből építik fel. Ennek a megközelítésnek a lépései a következők:
Előzetes követelményeket megírása Prototípus megtervezése Felhasználói tapasztalatok/a prototípus használata, új követelményeket határoz meg Ha szükséges, megismétlés Végső követelmények leírása
Evolúciós prototípus Az evolúciós prototípus (más néven breadboard prototípus) meglehetősen különbözik az eldobható prototípustól . Az evolúciós prototípus használatakor a fő cél az, hogy egy nagyon robusztus prototípust építsenek strukturált módon és folyamatosan finomítsák. Az oka ennek a megközelítésnek, hogy az evolúciós prototípus, amikor felépül, az új rendszer szívét alkotja, és a fejlesztéseket és a további követelményeket csak ekkor építik fel.
Mikor egy rendszert evolúciós prototípust használva fejlesztenek, a rendszert folyamatosan finomítják, és átalakítják.
„... az evolúciós prototípuskészítés elismeri, hogy nem értjük meg az összes követelményt, és csak azokat építjük fel, amelyeket jól értünk.”
Ez a technika lehetővé teszi a fejlesztőcsoport számára olyan funkciók hozzáadását vagy olyan változtatások végrehajtását, amelyeket a követelmények és a tervezési szakasz során nem tudtak elképzelni.
Ahhoz, hogy egy rendszer hasznos legyen, a felhasználásnak a tervezett működési környezetben kell fejlődnie. Egy termék sosincs „kész”; Mindig érik, amint a felhasználási környezet megváltozik… gyakran próbálunk egy rendszert a legismertebb referenciakeretünk segítségével meghatározni – hol vagyunk most. Feltételezéseket teszünk arról, hogy az üzlet hogyan fog lefolyni, és a technológiai alapról, amelyen az üzlet megvalósul. Terv kerül kidolgozásra a képesség fejlesztésére, és előbb vagy utóbb valami az elképzelt rendszerhez hasonlót leszállítódik.
Az evolúciós prototípusok azzal az előnnyel rendelkeznek az eldobható prototípusok felett, hogy funkcionális rendszerek. Bár nem biztos, hogy rendelkeznek minden olyan funkcióval, amelyet a felhasználók terveztek, átmenetileg is használhatják őket, amíg a végső rendszert ki nem szállítják.
„A prototípuskészítési környezetben nem szokatlan, hogy a felhasználó egy kezdeti prototípust gyakorlati használatba tesz, miközben vár egy fejlettebb verziót. A felhasználó döntheti el, hogy a 'hibás' rendszer jobb-e, mint egyáltalán nem lenne rendszer.”
Az evolúciós prototípuskészítésben a fejlesztők a teljes rendszer kifejlesztése helyett arra koncentrálhatnak, hogy fejlesszék a rendszer azon részeit, melyeket értenek.