Prototípus-készítés

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. ^[6]

Á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. 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

A prototípuskészítési folyamat a következő lépésekből áll: 

1. Á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.

2. 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 )

3. 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.

4. 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. ^[7]

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. ^[8]

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:

1. Előzetes követelményeket megírása
2. Prototípus megtervezése
3. Felhasználói tapasztalatok/a prototípus használata, új követelményeket határoz meg
4. Ha szükséges, megismétlés
5. 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.” ^[5]

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. ^[9]

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.” ^[7]

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.

A kockázat minimalizálása érdekében a fejlesztő nem valósítja meg a rosszul megértett szolgáltatásokat. A részleges rendszert eljuttatjuk az ügyféloldalakhoz. Amint a felhasználók a rendszerrel dolgoznak, felfedezik az új funkciók lehetőségeit, és kéréseket adnak a fejlesztőknek ezekről a szolgáltatásokról. A fejlesztők ezután ezeket a fejlesztési kérelmeket a saját magukéval együtt elvégzik, és a megfelelő konfigurációkezelési gyakorlatok használatával módosítják a szoftver-követelmények specifikációját, frissítik a tervezést, újra kódolják és újra tesztelik. ^[10]

Inkrementális prototípus

A készterméket külön prototípusokként építik fel. Végül a különálló prototípusokat összevonják egy átfogó tervben. Inkrementális prototípus révén az időrés a felhasználó és a szoftverfejlesztő között csökkenthető.

Extrém prototípus

Az extrém prototípuskészítést mint fejlesztési folyamatot elsősorban a webes alkalmazások fejlesztésére használják. Alapvetően a webfejlesztést három szakaszra bontja, amelyek mindegyike az előzőre épül. Az első szakasz egy statikus prototípus, amely főleg HTML oldalakból áll. A második szakaszban a képernyőket programozzák amik teljesen működőképesek egy szimulált szolgáltatási réteg segítségével. A harmadik szakaszban a szolgáltatásokat valósítják meg.

„A folyamatot Extrém Prototípuskészítésnek hívják, hogy felhívják a figyelmet a folyamat második szakaszára, ahol egy teljesen működőképes felhasználói felületet fejlesztenek ki, nagyon kevés figyelmet fordítva a szerződésükön kívüli szolgáltatásokra.”

A prototípusok előnyei

Számos előnye van annak, hogy a prototípuskészítést használják a szoftverfejlesztésben – néhány kézzelfogható, más elvont. ^[11]

Csökkentett idő és költségek : A prototípusok javíthatják a fejlesztők számára biztosított követelmények és specifikációk minőségét. Mivel a változások végrehajtása exponenciálisan nagyobb költségeket igényel, mert később észlelik őket a fejlesztésben, a korai meghatározása annak, hogy mi az amit elhasználó valóban akar, gyorsabb és olcsóbb szoftvereket eredményezhet. ^[8]

Javult és fokozott felhasználói bevonás : A prototípuskészítéshez a felhasználók bevonása szükséges, és lehetővé teszi számukra a prototípus megismerését és az azzal való interakciót, lehetővé téve, hogy jobb és teljesebb visszajelzést és specifikációkat adjanak. ^[7] A felhasználó által megvizsgált prototípus megléte sok félreértést és téves kommunikációt megakadályoz, amelyek akkor fordulnak elő, amikor mindkét oldal úgy gondolja, hogy a másik fél megérti az általuk mondottakat. Mivel a felhasználók jobban ismerik a problématerületet, mint bárki a fejlesztői csapatban, a fokozott interakció eredményeként olyan késztermék keletkezik, amely kézzelfoghatóbb és immateriális minőséggel rendelkezik. A késztermék valószínűbben elégíti ki a felhasználó megjelenés, érzés és teljesítmény iránti vágyát.

A prototípusok hátrányai

A prototípusok használata vagy esetleges rossz használata hátrányokkal is járhat.

Nem elegendő elemzés: A korlátozott prototípusra való összpontosítás elvonhatja a fejlesztőket a teljes projekt megfelelő elemzéséről. Ez a jobb megoldások figyelmen kívül hagyásához, hiányos specifikációk elkészítéséhez vezethet vagy a korlátozott prototípusok átalakításai rosszul megtervezett végprojektekké válhatnak, amiket nehéz karbantartani. Ezenkívül, mivel a prototípus korlátozott funkcionalitással bír, lehet, hogy nem méretezhető jól, ha a prototípust használják a végleges eredmény alapjául, ami lehet nem tűnik fel, ha a fejlesztők túlzottan összpontosítanak egy prototípus modellként való felépítésére.

A prototípus és a kész rendszer felhasználói összetévesztése: A felhasználók elkezdhetik azt gondolni, hogy a kidobásra szánt prototípus valójában egy végleges rendszer, amelyet csupán be kell fejezni vagy csiszolni. (Például gyakran nincsenek tudatában a hibaellenőrzés és biztonsági szolgáltatások hozzáfűzéséhez szükséges erőfeszítésekkel, amelyekkel egy prototípus lehet, hogy nem rendelkezik.) Ez arra vezetheti őket, hogy azt várják a prototípustól, hogy az pontosan modellezze a végső rendszer teljesítményét, mikor a fejlesztőknek ez nem szándéka. A felhasználók ragaszkodhatnak azokhoz a funkciókhoz is, amelyeket figyelembe vettek a prototípusban, majd eltávolítottak a végleges rendszer specifikációjából. Ha a felhasználók megkövetelhetik, hogy az összes javasolt funkció bekerüljön a végső rendszerbe, az konfliktushoz vezethet.

Fejlesztők félreértik a felhasználói célkitűzéseket: A fejlesztők feltételezhetik, hogy a felhasználók megosztják célkitűzéseik (pl. Az alapvető funkciók időben és költségvetésen belüli biztosítása érdekében) anélkül, hogy megértenék a szélesebb körű kereskedelmi problémákat. Például az Enterprise szoftver (pl A PeopleSoft ) eseményeken részt vevő felhasználói képviselők láthatták a „tranzakció-ellenőrzés” bemutatóit (ahol a változások naplózása és megjelenítése egy különböző rács nézetben jelenítődik meg) anélkül, hogy elmondták volna, hogy ez a szolgáltatás kiegészítő kódolást és gyakran további hardvereket igényel az extra adatbázis-hozzáférések kezeléséhez. A felhasználók azt gondolhatják, hogy minden területen követelhetnek ellenőrzést, míg a fejlesztők azt gondolhatják, hogy ez a szolgáltatás kúszás, mert már feltételezéseket tettek a felhasználói igények mértékéről. Ha a fejlesztő a felhasználói igények áttekintése előtt elvégezte a szállítást, akkor nagyon nehéz helyzetbe kerülnek, különösen akkor, ha a felhasználói menedzsmentnek valamilyen előnye származik a követelmények végrehajtásának elmulasztása miatt.

A fejlesztői ragaszkodik a prototípushoz: A fejlesztők is ragaszkodhatnak a prototípusokhoz, amelyekbe nagy erőfeszítéseket tettek a gyártás céljából; ez olyan problémákhoz vezethet, mint például megkísérelni átalakítani egy korlátozott prototípust egy végleges rendszerré, mikor annak nincs megfelelő mögöttes architektúrája. (Ez arra utalhat, hogy az evolúciós prototípusok helyett az eldobható prototípusokat kellene használni.)

A prototípus túlzott fejlesztési ideje : A prototípusnak egyik fő tulajdonsága az, hogy azt várhatóan gyorsan el kell készíteni. Ha a fejlesztők elfelejtik ezt a tényt, akkor könnyen megpróbálhatnak egy túl bonyolult prototípust kifejleszteni. A prototípus eldobásakor az általa előírt pontosan kidolgozott követelmények nem eredményezhetik a termelékenység kellő növekedését ahhoz, hogy a prototípus kidolgozásához szükséges időt pótolják. A felhasználók elakadhatnak a prototípus részleteivel kapcsolatos vitákban, feltartva a fejlesztői csoportot és késleltetve a készterméket.

A prototípusok költségei: A prototípusokra összpontosító fejlesztőcsoport felépítésének indulási költségei magasak lehetnek. Számos vállalatnak van fejlesztési módszertana, és ezek megváltoztatása átképzést, átcsoportosítást vagy mindkettőt jelenthet. Sok vállalat hajlamos a prototípusok készítésének elkezdésre anélkül, hogy azzal fáradozna, hogy átképzi a munkavállalóit, amennyire csak szükséges.

A prototípuskészítési technológia bevezetésével kapcsolatos általános probléma a magas termelékenységi elvárás, elégtelen erőfeszítésekkel a tanulási görbe mögött. A prototípuskészítési technikák alkalmazására való képzésen túlmenően gyakran figyelmen kívül hagyják a vállalati és a projekt-specifikus mögöttes struktúra fejlesztésének szükségességét a technológia támogatása érdekében. Ha ezt az alapul szolgáló struktúrát kihagyják, gyakran alacsonyabb termelékenységet eredményezhet. ^[13]

A legjobb projektek a prototípusok használatához

Vitatják, hogy folyamatosan alkalmazni kellene-e a prototípusokat valamilyen formában. A prototípuskészítés azonban azokban rendszerekben a leghasznosabb, amelyek sok interakciót igényelnek a felhasználókkal.

Megállapítást nyert, hogy a prototípuskészítés nagyon hatékony az on-line rendszerek elemzésében és tervezésében, különösen tranzakciók feldolgozásnál, ahol a képernyő-párbeszédek használata sokkal inkább nyilvánvalóbb. Minél több az interakció a számítógép és a felhasználó között, annál nagyobb az előnye annak, ha egy gyors rendszert építünk fel és hagyjuk, hogy a felhasználó játsszon vele. ^[7]

A kevés felhasználói interakcióval rendelkező rendszerek, mint például a kötegelt feldolgozás, vagy olyan rendszerek, amik leginkább számításokat végeznek, kevés előnyt jelentenek a prototípuskészítés szempontjából. Időnként a rendszer funkcióinak végrehajtásához szükséges kódolás túlságosan intenzív lehet, és a prototípuskészítés által nyújtott potenciális előnyök túl kicsik. ^[7]

A prototípuskészítés különösen jó az ember-számítógép interfészek tervezéséhez. A gyors prototípuskészítésnek egyik legtermékenyebb felhasználása eddig a felhasználói igények iteratív tervezésének és az ember-számítógép interfész tervezésének eszköze volt. ^[8]

Dinamikus rendszerek fejlesztési módszere

A dinamikus rendszerek fejlesztési módszere (DRFM) ^[18] egy keretrendszer az üzleti megoldások szállítására, amely nagymértékben függ a prototípuskészítéstől mint alapvető módszer, és maga is ISO 9001-es jóváhagyással rendelkezik. Bemutatja a prototípus leginkább érthető definícióit. A DRFM szerint a prototípus lehet diagram, üzleti folyamat vagy akár egy üzembe helyezett rendszer. A DRFM prototípusoknak növekményesnek kell lenniük, az egyszerű űrlapoktól fejlődve sokkal széleskörűbbekké.

A DRFM prototípusai lehetnek néha eldobhatók vagy evolúciósak. Az evolúciós prototípusok kialakíthatók vízszintesen (szélesség, majd mélység) vagy függőlegesen (az egyes szakaszokat részletesen felépítjük, további iterációkkal, amelyek részletezik a következő szakaszokat). Az evolúciós prototípusok végül kialakulhatnak végső rendszerekké.

A DRFM által ajánlott prototípusok négy kategóriája a következő:

• Üzleti prototípusok – az automatizált üzleti folyamatok megtervezésére és bemutatására szolgálnak.
• Használhatósági prototípusok – a felhasználói felület használhatóságának, elérhetőségének, megjelenésének és érzetének meghatározására, finomítására és demonstrálására szolgál.
• Teljesítmény- és kapacitási prototípusok – a rendszerek csúcsterhelés melletti teljesítményének meghatározására, demonstrálására és előrejelzésére, valamint a rendszer egyéb nem funkcionális szempontjainak (tranzakciós arányok, adattárolási mennyiség, válaszidő stb.) demonstrálására és értékelésére szolgálnak.
• Kapacitás/technika prototípusok – a tervezési megközelítés vagy koncepció kidolgozásához, demonstrálásához és értékeléséhez használják.

A prototípus DRFM életciklusa a következő:

1. Prototípus megállapítása
2. Megállapodni egy tervben
3. Prototípus létrehozása
4. Prototípus átvizsgálása

Operatív prototípuskészítés

Az operatív prototípuskészítést Alan Davis javasolta az átmeneti és az evolúciós prototípuskészítésnek a hagyományos rendszerfejlesztésbe történő integrálásának egyik módjaként. „Észszerű módon a legjobbat kínálja mind a gyors és piszkos, mind a hagyományos fejlesztés világából. A tervezők csak jól érthető tulajdonságokat fejlesztenek ki az evolúciós alapvonal felépítéséhez, miközben az eldobható prototípusokat a rosszul megértett tulajdonságok kísérletezésére használják.” ^[5]

Davis meggyőződése, hogy a „minőség egy gyors prototípusra való utólagos áttervezésének” megpróbálása nem megfelelő módszer a két megközelítés kombinálására. Ötlete az, hogy egy evolúciós prototípuskészítési módszertant alkalmaz, és minden evolúció után gyorsan prototípusozza a rendszer jellemzőit.

A speciális módszertan a következő lépéseket követi: ^[5]

• Egy evolúciós prototípust a hagyományos fejlesztési stratégiák felhasználásával készítenek el és teszik alapvonallá, csak a jól érthető követelményeket meghatározva és végrehajtva.
• Az alapvonal másolatait több ügyféloldalra küldik el, egy képzett prototípuskészítő mellett.
• A prototípuskészítő minden helyszínen figyeli a felhasználót a rendszernél.
• Ha a felhasználó problémát tapasztal, vagy új funkciót vagy követelményt talál ki, a prototípuskészítő ezt naplózza. Ez megszabadítja a felhasználót attól, hogy rögzítenie kelljen a problémát, és lehetővé teszi számára, hogy tovább dolgozzon.
• Miután a felhasználói munkamenet lejárt, a prototípuskészítő elkészít egy eldobható prototípust az alapvonal-rendszer tetejére.
• A felhasználó most használja az új rendszert, és kiértékeli. Ha az új változtatások nem hatékonyak, a prototípuskészítő eltávolítja azokat.
• Ha a felhasználó kedveli a módosításokat, akkor a prototípuskészítő funkciójavító kéréseket ír és továbbítja azokat a fejlesztői csapatnak.
• A fejlesztőcsoport az összes helyszínen a változási igényekkel együtt új evolúciós prototípust állít elő hagyományos módszerekkel.

Nyilvánvaló, hogy ennek a módszernek a kulcsa az, hogy jól képzett prototípuskészítőkkel rendelkezzenek, akik mehetnek a felhasználói oldalakra. Az operatív prototípuskészítési módszertan számos előnnyel rendelkezik olyan rendszerekben, amelyek összetettek és kevés ismert feltétellel rendelkeznek előre.

Evolúciós rendszerek fejlesztése

Az evolúciós rendszerek fejlesztése azon módszertanok osztálya, amelyek megkísérelik hivatalosan megvalósítani az evolúciós prototípuskészítést. Az egyik típus, a Systemscraft, amit John Crinnion ír le az Evolutionary Systems Development című könyvében.

A Systemscraft „prototípus” módszertanként került kialakításra, amelyet módosítani és adaptálni kell annak a környezetnek a figyelembevételével, amelyben megvalósították.

A Systemscraft-ot nem egy merev „szakácskönyves” megközelítésként fejlesztették ki a fejlesztési folyamathoz. Manapság általánosan elismert, hogy egy jó módszertannak elég rugalmasnak kell lennie, hogy mindenféle környezethez és helyzethez igazítható legyen ^[7]

A Systemscraft alapja – az evolúciós prototípuskészítés kialakításával ellentétben – egy működő rendszer létrehozása a kezdeti követelményekből, és a fejlesztések sorozatán alapulva. A Systemscraft nagy hangsúlyt fektet a hagyományos elemzésekre, amelyeket a rendszer fejlesztése során alkalmaznak.

Evolúciós gyors fejlesztés

Az evolúciós gyors fejlesztést (EGYF) ^[12] a Software Productivity Consortium fejlesztette ki, amely a Védelmi Fejlesztési Kutatási Projektek Ügynökségének (DARPA) Informatikai Irodájának technológiai fejlesztési és integrációs ügynöke.

Az ERD szempontjából alapvető a szoftver rendszerek összeállításának fogalma amely az összetevők újrafelhasználására, a szoftver sablonok használatára és egy építészeti sablonra épül. A rendszer képességeinek folyamatos fejlődését a változó felhasználói igényekre és technológiákra reagálva a fejlett architektúra hangsúlyozza, amely a megoldások egy osztályát képviseli. A folyamat a kézművesalapú, a szoftver- és rendszerfejlesztési tudományágakat integráló, kézművesalapú csapatok használatára összpontosít, amelyek több, gyakran párhuzamos, rövid időtartamú idődobozban működnek, gyakori ügyfél-interakcióval.

Az ERD-alapú projektek sikerének kulcsa a funkciók, infrastruktúrák és alkatrészek párhuzamos feltáró elemzése és fejlesztése, a legmodernebb technológiákat felhasználva, amelyek lehetővé teszik a gyors reagálást a technológiák, a piac vagy az ügyfelek igényeinek változásaira. ^[9]

Az ügyfelek és a felhasználók bevonásának megkönnyítése érdekében rendszeresen ütemezett és alkalmi/rögtönzött találkozókat tartanak az érdekelt felekkel. A rendszer képességeinek demonstrációját visszajelzések kérésére tartják, mielőtt a tervezési/megvalósítási döntések megszilárdulnának. A gyakori kiadásokat (pl. Béta verziók ) rendelkezésre bocsátják, hogy betekintést nyújtsanak abba, hogy a rendszer miként tudná jobban támogatni a felhasználók és az ügyfelek igényeit. Ez biztosítja, hogy a rendszer a meglévő felhasználói igényeket kielégítve fejlődjön.

A rendszer tervezési kerete a meglévő közzétett vagy de facto szabványok használatán alapul. A rendszer úgy van felépítve, hogy lehetővé tegye egy sor olyan képesség fejlesztését, amely figyelembe veszi a teljesítményt, a kapacitásokat és a funkcionalitást. Az architektúrát, a szolgáltatásokat és azok megvalósítását (például COTS-alkalmazásokat) körülvevő absztrakt interfészek alapján határozzák meg. Az architektúra sablonként szolgál a rendszer egynél több példányának fejlesztésének irányításához. Ez lehetővé teszi több alkalmazás-összetevő felhasználását a szolgáltatások megvalósításához. A funkciók alapvető készletét, amelyek valószínűleg nem változnak, szintén azonosítják és létrehozzák.

Az ERD folyamata a bemutatott funkcionalitásra, nem pedig a papírtermékek felhasználására épül fel, hogy az érintettek kommunikálhassák az igényeiket és elvárásaikat. A gyors kézbesítés célkitűzésének központi eleme az „idődoboz” módszer használata. Az idődobozok olyan rögzített időszakok, amelyek során meghatározott feladatokat (pl. Egy sor funkcionalitás kifejlesztése) kell elvégezni. Ahelyett, hogy hagynánk időt valamilyen homályos célok kielégítése érdekében, az idő rögzített (mind a naptári hetek, mind az órák szempontjából), és meghatározzuk azokat a célokat, amelyek reálisan elérhetők ezen a korlátokon belül. Annak elkerülése érdekében, hogy a fejlődés degenerálódjon „véletlenszerű sétává”, hosszú távú terveket határoztak meg az iterációk irányítására. Ezek a tervek áttekintést nyújtanak az egész rendszerre, és meghatározzák a projekt határait (pl. korlátok). A folyamaton belüli minden iterációt a hosszú távú tervek tekintetében hajtanak végre.

Miután létrehozták az architektúrát, a szoftvert naponta integrálják és tesztelik. Ez lehetővé teszi a csapat számára az előrehaladás objektív felmérését és a lehetséges problémák gyors azonosítását. Mivel kis mennyiségei vannak a rendszernek egyszerre integrálva, a hiba diagnosztizálása és eltávolítása gyors. A felhasználói bemutatókat rövid időn belül meg lehet tartani, mivel a rendszer általában mindig készen áll a gyakorlatra.

Eszközök

A prototípuskészítés hatékony felhasználása megköveteli, hogy a szervezet rendelkezzen a megfelelő eszközökkel és az eszközök használatához kiképzett személyzettel. A prototípuskészítéshez használt eszközök az egyes eszközöktől függően változhatnak, például a gyors prototípuskészítéshez használt 4. generációs programozási nyelvektől a komplex integrált CASE eszközökig. A 4. generációs vizuális programozási nyelveket, mint például a Visual Basic és a ColdFusion gyakran használják, mivel ezek olcsók, jól ismertek, viszonylag egyszerűek és gyorsak. A CASE eszközöket, amelyek támogatják a követelmények elemzését, mint például a „Követelményeket Tervező Környezet” (lásd alább), gyakran a katonai vagy a nagy szervezetek fejlesztik vagy választják ki. Objektum-orientált eszközöket is fejlesztenek, mint például a LYMB- t a GE Kutatási és Fejlesztési Központból. A felhasználók maguk is prototipizálhatják az elemeit egy alkalmazásnak egy táblázatkezelőben .

Mivel a webalapú alkalmazások népszerűsége folyamatosan növekszik, ezért az ilyen alkalmazások prototípuskészítéshez szükséges eszközöknek növekedniük kell . Az olyan keretrendszerek, mint a Bootstrap, az Foundation és az AngularJS biztosítják azokat az eszközöket, amelyek a koncepció igazolásának gyors felépítéséhez szükségesek. Ezek a keretrendszerek általában vezérlőelemekből, interakciókból és tervezési irányelvekből állnak, amelyek lehetővé teszik a fejlesztők számára a gyors prototípuskészítést a webes alkalmazásokhoz.

Képernyőgenerátorok, tervező eszközök és szoftvergyárak

Képernyőgeneráló programokat is gyakran használnak, és lehetővé teszik a prototípuskészítők számára, hogy megmutassák a felhasználó rendszereit, melyek nem működnek, de megmutatják, hogy a képernyőknek hogyan kellene kinézniük. Az Emberi-Számítógép Interfészek fejlesztése néha a fejlesztési erőfeszítések kritikus része lehet, mivel a felhasználók számára az interfész alapvetően maga a rendszer.

A szoftvergyárak a használatra kész moduláris összetevők kombinálásával generálhatnak kódot. Ez ideálissá teszi őket alkalmazások prototípuskészítéséhez, mivel ez a megközelítés gyorsan képes a kívánt viselkedésű programokat elkészíteni, minimális mennyiségű kézi kódolással.

Alkalmazásdefiníció vagy szimulációs szoftver

Egy új szoftvertípus, amit alkalmazásdefiníciónak vagy szimulációs szoftvernek hívnak lehetővé teszi a felhasználók számára, hogy gyorsan építsenek könnyűsúlyú, animált szimulációkat egy másik számítógépes programról, kód írása nélkül. Az alkalmazás-szimulációs szoftver lehetővé teszi mind a műszaki, mind a nem műszaki beállítottságú felhasználók számára, hogy megtapasztalják, teszteljék, együttműködjenek és validálják a szimulált programot, és olyan jelentéseket nyújtanak, mint kommentárok, képernyőképek és vázlatok . Mint megoldás-specifikációs módszer, az alkalmazás-szimuláció az alacsony kockázatú, de korlátozott szöveg- vagy rajzalapú makett (vagy drótváz ), amelyeket néha papíralapú prototípuskészítésnek hívnak, és időigényes, nagy kockázatú kódalapú prototípusok közé esik, lehetővé téve az informatikusok számára, hogy a követelményeket és a tervezési döntéseket korán érvényesítsék, még a fejlesztés megkezdése előtt. Ezzel drasztikusan csökkenthetők a szoftver megvalósításával járó kockázatok és költségek.

Az alkalmazások szimulálására olyan szoftvert is használhatunk, amely utánozza a valós számítógépes programokat számítógép-alapú képzéshez, demonstrációhoz és ügyfélszolgálathoz, például egy képernyőmegjelenítő szoftvert, mivel ezek a területek szorosan kapcsolódnak egymáshoz.

Követelményeket Tervező Környezet

„A Római Laboratóriumban 1985 óta kidolgozás alatt álló Követelményeket Tervező Környezet (KTK) integrált eszközkészletet biztosít a komplex rendszerek kritikus szempontjainak modelljeinek gyors ábrázolására, felépítésére és végrehajtására.” ^[15]

A Követelményeket Tervező Környezet jelenleg az Amerikai Egyesült Államok Légiereje használja rendszerek fejlesztésére. Ez:

egy integrált eszközkészlet, amely lehetővé teszi a rendszerelemzők számára, hogy gyorsan felépítsék a rendszer összetevőinek funkcionális, felhasználói felületét és teljesítménymintáját. Ezeket a modellezési tevékenységeket úgy hajtják végre, hogy jobban megértsék a komplex rendszereket, és csökkentsék a pontatlan követelmény-specifikációk költségét és ütemezését a rendszerfejlesztési folyamat alatt. A modellek könnyen elkészíthetők, és az absztrakció vagy a részletesség különböző szintjein, az alkalmazott modell sajátos viselkedési szempontjaitól függően. ^[15]

A KTK három részből áll. Az első, az úgynevezett proto egy CASE eszköz, amelyet kifejezetten a gyors prototípuskészítés támogatására terveztek. A második részt Rapid Interface Prototyping System-nek vagy RIP-nek hívják, amely olyan eszközök gyűjteménye, amelyek megkönnyítik a felhasználói felületek létrehozását. A KTK harmadik része a RIP és a proto felhasználói felülete, amely grafikus és könnyen használható.

A Római Laboratórium, a KTK fejlesztője arra törekedett, hogy támogassa belső igényeik gyűjtésének módszertanát. Módszerük három fő részből áll:

• Közzététel különböző forrásokból (felhasználók, interfészek más rendszerekből), specifikáció és konzisztencia ellenőrzés
• Annak elemzése, hogy a különféle felhasználók igényei együttesen nem ütköznek egymással, és technikailag és gazdasági szempontból megvalósíthatók
• Annak igazolása, hogy az így leírt követelmények pontosan tükrözik a felhasználói igényeket. ^[15]

1996-ban a Római Labor a Software Productivity Solutions-al (SPS) szerződött a KTK továbbfejlesztése érdekében, hogy „kereskedelmi minőségű KTK-t hozzon létre, amely támogatja a követelmények meghatározását, a szimulációt, a felhasználói felület prototipizálását, a hardveres architektúrákra vonatkozó követelmények feltérképezését és a kódgenerálást ...” ^[16] A rendszer neve Advanced Requirements Engineering Workstation vagy AREW.

Nem relációs környezetek

Az adatok nem relációs meghatározása (pl. Caché vagy asszociatív modellek ) elősegítheti a végfelhasználói prototípuskészítésnek termelékenységét azáltal, hogy késlelteti vagy elkerüli az adatok normalizálásának szükségességét a szimuláció minden iterációjában. Ez elősegítheti az üzleti követelmények korábbi/nagyobb egyértelműségét, bár nem kifejezetten erősíti meg, hogy a követelmények műszaki és gazdasági szempontból megvalósíthatók a céltermelési rendszerben.

PSDL

A PSDL egy valósidejű szoftver leírására szolgáló prototípusleíró nyelv. A társított eszközkészlet a CAPS (Computer Aided Prototyping System). A nehéz valósidejű követelményekkel rendelkező szoftverrendszerek prototípus-készítése kihívást jelent, mivel az időzítési korlátok bevezetik a megvalósítást és a hardverfüggőségeket. A PSDL ezeket a problémákat úgy kezeli, hogy vezérlő absztrakciókat vezet be, amelyek deklaratív időbeli korlátozásokat tartalmaznak. A CAPS ezt az információt használja fel, hogy automatikusan létrehozza a kódot és a hozzá tartozó valós idejű ütemezéseket, monitorozza az időzítési korlátozásokat a prototípus végrehajtása során, és szimulálja a végrehajtást valós időben, a parametrizált hardvermodellek halmazához viszonyítva. Ezenkívül alapértelmezett feltételezéseket is tartalmaz, amelyek lehetővé teszik a hiányos prototípusleírások végrehajtását, integrálják a prototípus felépítését egy szoftver újrafelhasználási adattárolóval a hatékony megvalósítások gyors felismeréséhez, valamint támogatást nyújtanak a követelmények és a tervek gyors fejlődéséhez.

Források

• C. Melissa Mcclendon, Larry Regot, Gerri Akers: The Analysis and Prototyping of Effective Graphical User Interfaces. October 1996. [1]
• D.A. Stacy, professor, University of Guelph. Guelph, Ontario. Lecture notes on Rapid Prototyping. August, 1997. [2]
• Stephen J. Andriole: Information System Design Principles for the 90s: Getting it Right. AFCEA International Press, Fairfax, Virginia. 1990. Page 13.
• R. Charette, Software Engineering Risk Analysis and Management. McGraw Hill, New York, 1989.
• Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
• Todd Grimm: The Human Condition: A Justification for Rapid Prototyping. Time Compression Technologies, vol. 3 no. 3. Accelerated Technologies, Inc. May 1998 . Page 1. [3] Archiválva 2022. május 17-i dátummal a Wayback Machine-ben
• John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 18.
• S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.
• Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.
• Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp. 104–118
• Adapted from C. Melissa Mcclendon, Larry Regot, Gerri Akers.
• Adapted from Software Productivity Consortium. PPS 10–13.
• Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.
• Paul W. Parry. Rapid Software Prototyping. Sheffield Hallam University, Sheffield, UK. [4] Archiválva 2019. február 13-i dátummal a Wayback Machine-ben
• Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994. [5]
• Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996. [6]
• GE Research and Development. https://web.archive.org/web/20061013220422/http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html
• Dynamic Systems Development Method Consortium. https://web.archive.org/web/20060209072841/http://na.dsdm.org/
• Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale; Human-Computer Interaction, Third edition

Fordítás

Ez a szócikk részben vagy egészben a Software prototyping című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.