8. Specifikációs prototípus-készítés

1. A technika célja

A specifikációs prototípus-készítés nem arra irányul, hogy a rendszernek vagy bármely részének egy végsõ változata elkészüljön, hanem arra, hogy bemutassa, melyek azok a részek a rendszerben, amelyek megvalósíthatók, és melyek azok, amelyek nem. A prototípuskészítés célja az, hogy azonosítsa és megfogja a hibákat a felhasználói követelmények specifikációjában és kijavítsa õket még a részletes logikai tervezés megkezdése elõtt.

2. A technika rövid leírása

• a prototípuskészítésbe bevont dialógusok és jelentések kiválasztása
• a menü és parancs szerkezetek prototípusainak elkészítése
• a menük, képernyõk és jelentések mûködési együttesét bemutató prototípusok megtervezése és elkészítése a választott dialógusokhoz és jelentésekhez
• a prototípusok bemutatása és felülvizsgálata
• a prototípusok tartalmára vonatkozó módosítások elvégzése
• a támogató SSADM dokumentációra vonatkozó módosítások elvégzése
• a specifikációs tartalom megerõsítése

Prototípus-bejárási utak

Prototípus-bemutatási célkitûzések

Prototípus-bemutatási eredménynapló

3. Termékek

Parancsszerkezetek

Menüszerkezetek

Prototípus értékelése

Követelményjegyzék

Dialógus elemek logikai csoportjai

Prototípus-bemutatási célkitûzések

Prototípus-bejárási utak

Prototípus-bejárási eredménynapló

Képernyõ formátumok

Adatjegyzék

Egyed-élettörténetek

Funkcióleírások

B/K adatszerkezetek

Igényelt rendszer logikai adatmodellje

Felhasználói szerepkör/funkció mátrix

4. A specifikációs prototípus készítésének kérdései

4.1. Eszközháttér kiválasztása

A prototípusokat a munkához legjobban illeszkedõ eszközzel kell megvalósítani, amely nem feltétlenül a rendszer esetleges megvalósítási környezete (hardver és szoftver), mivel az ezen a ponton valószínûleg még nem ismert.

A specifikációs prototípus elkészítéséhez ajánlott eszköznek rendelkeznie kell képernyõk, menük és jelentések kinézetét elõállító lehetõségekkel, interaktív mozgási lehetõséggel és aktív adatszótárral. További hasznos képességeket jelent az alkalmazás logikájának szimulálása, az alkalmazás adattárolásának szimulálása és a verzió ellenõrzés.

Mivel a specifikációs prototípus néhány ábraszerkezetet tartalmazó termékre alapul (pl. igényelt rendszer logikai adatmodellje), ha ezeket a termékeket egy CASE eszköz segítségével állították elõ, akkor kívánatos lenne, hogy a prototípus készítésének eszköze legalább kapcsolódni tudjon ehhez a CASE eszközhöz.

A támogató eszköz kiválasztásának a projekt életében a lehetõ legkorábban meg kell történnie, azaz amint a prototípus készítésének kérdése eldõlt, a vezetésnek el kell kezdenie vizsgálni a prototípus készítésének kiterjedését és a megvalósítás eszközét.

4.2. A prototípuskészítés szükségességének megállapítása

Egy projekt kezdetén el kell dönteni azt, hogy szükség van-e a fejlesztési tevékenységen belül prototípust készíteni. Egy sor feltételt meg kell vizsgálni ahhoz, hogy eldöntsék, van-e valamilyen haszna a prototípus készítésének.

4.2.1. Prototípuskészítésre alkalmas projektek

Minden projektben meg kell vizsgálni, hogy mennyire igazak a következõ kijelentések:

• a felhasználó követelményeit megfelelõen értelmezték, konkrétabban, a logikai adatmodell és a funkcióleírások hitelesen tükrözik a rendszer által kiszolgált felhasználók közösségének jelenlegi üzleti/mûködési igényeit,
• a rendszernek sokféle adatot kell tudnia kezelni,
• a felhasználói telephelyek földrajzilag szétszórtak, ami helytõl függõ egyedi követelményeket is jelenthet,
• a nem megfelelõ tervezésbõl eredõ szervezeti/mûködési vagy technikai kockázatok magasak,
• a rendszer kifejlesztése és megvalósítása nagy pénzügyi befektetést igényel,
• a felhasználói szervezetek struktúrájának jelentõs átalakítása várható,
• a felhasználók munkamódszereiben nagy változások várhatók
• sok lehetséges változata van a tervezett megoldásoknak,
• a felhasználóknak hiányosak a számítógépes rendszerekkel kapcsolatos tapasztalataik, ami miatt a követelmények specifikálását nehéznek találhatják,
• a projekt elemzõinek hiányos a tudása az üzleti/mûködési területrõl.

Képernyõ prototípusok

A képernyõk prototípusainál meg kell vizsgálni a következõket:

• a rendszeren belül azoknak az interaktív tevékenységeknek a szintjét, melyek valószínûleg bekerülnek a rendszerbe. Ha sok képernyõn keresztüli forgalom várható, akkor hasznos lehet a követelmények specifikációjának ellenõrzése prototípus készítésével.
• a képernyõn belüli adatkezelés szintjét. Ahol egy adott funkció interaktív tevékenységeinek mennyisége nagy, a prototípus elkészítése segít ellenõrizni a felhasználó igényeinek érvényességét.
• a gyenge szolgáltatást nyújtó interaktív tevékenységhez kapcsolódó üzleti/mûködési kockázatokat. Ha egy funkció hibás vagy lassan hozza létre a szükséges választ, akkor befolyásolja ez a mûködést? Azokban az esetekben, amikor a szolgáltatás kritikus, ajánlatos a funkcióhoz vagy funkciókhoz prototípust készíteni, hogy a követelményeket a lehetõ legjobban ellenõrizni lehessen.

A jelentések kimenetének prototípusaihoz meg kell vizsgálni a következõket:

• Jelentés kimeneti formátumának ellenõrzése a kimenet más rendszerbeli felhasználása miatt. Ha egy adott kimenet formátumának meg kell felelnie egy másik rendszer bemeneti igényeinek, akkor hasznos lehet a prototípus a szükséges követelményeket elérõ kimenetek meghatározásában.
• Jelentés kimeneti formátumának ellenõrzése a külsõ elõírások betartása miatt. Bizonyos kimeneteknek, például adózással kapcsolatos információknak, meg kell felelniük egyedi külsõ elõírásoknak és egy prototípus segíthet ennek az ellenõrzésében.
• A felhasználói követelmények meghatározásának helyessége. Ha a követelmények homályosak vagy nehezen megvalósítható igényeket tükröznek, a prototípus készítése segíthet.

4.2.2. Prototípuskészítésre nem alkalmas projektek

Az SSADM-en belül általában nem használható a prototípuskészítés a következõ projektekben:

• az igényelt rendszer a meglévõ rendszer átalakítása az új rendszerre. Ez általában akkor történhet meg, ha a jelenlegi rendszer támogatja a szervezet mûködését, és a rendszer újrafejlesztése a jelenlegi szoftver és/vagy hardver változása miatt szükséges
• a projekt nem viseli el a prototípus készítésével kapcsolatos további fejlesztési kiadásokat.

4.2.3. Projektek, amelyeknél nincs jelenlegi rendszer

Nem szükséges egy jelenlegi rendszer ahhoz, hogy prototípust készítsenek. Sõt, ahol nincs jelenleg mûködõ rendszer, ott a prototípus fontosabb szerepet játszik, segít a felhasználóknak a követelményeik megfogalmazásában és az elemzõknek az igények és a lényeg megragadásában.

4.3. Prototípuskészítés irányítása

A prototípus készítésének egyik nagy kozkázata, hogy tervezés és irányítás hiányában a prototípusok készítésének eljárása végtelen ismétlésekbe torkollhat, az elérhetõ haszon figyelembevétele nélkül. Bár a prototípusok készítése kevésbé szigorú ellenõrzést igényel, mint más SSADM technikák, fontos néhány alapvetõ ajánlást figyelembe venni.

A prototípus készítésének kiterjedését a vezetõségnek elõre meg kell határoznia. A kiterjedésnek nemcsak a prototípus készítésének terjedelmét kell meghatároznia (azaz azt, hogy a specifikáció mely részeit kell bevonni), hanem egy ütemezést is adnia kell a tevékenységhez, pontos célokat kell megfogalmaznia és meg kell határozni az erõforrás felhasználást, emberi/szakmai és hardver/szoftver értelemben.

A prototípust készítõ csoport

A csoportnak egy vezetõbõl és legalább két elemzõbõl kell állnia. A vezetõ felelõs a következõkért:

• a prototípus kezdeti kiterjedésének átvétele a vezetõségtõl
• a választott dialógusok/jelentések elfogadása
• a prototípusokat bemutató összejövetelek visszajelzéseinek átvétele és elfogadása
• a visszajelzéseken alapuló döntések meghozatala, azaz további bemutatók engedélyezése vagy a prototípus készítésének lezárása
• a megfelelõ támogató SSADM termékekre vonatkozó változtatási igények eljuttatása a megfelelõ személyekhez
• jelentés készítése a vezetés felé, jelezve az elért és a kihagyott célkitûzéseket és összefoglalva a munka eredményét

A prototípuskészítési ciklus

A prototípusok elkészítése a következõ tevékenységek ismétlésébõl áll:

Meghatározás/újra meghatározás

megvalósítás

bemutatás

felülvizsgálat.

4.4. Prototípus készítésének elõnyei és hátrányai

A prototípus készítésének lehetnek elõnyei és hátrányai. A legnyilvánvalóbb hatása az, hogy a felhasználók tevékenyebb szerepet vállalnak mint egyébként, nélkülük a prototípusok készítésének folyamata értelmetlen.

4.4.1. Prototípus készítésének elõnyei:

• felhasználói követelmények megerõsítése,
• a lehetõségek fokozottabb megértése a felhasználók részérõl,
• felhasználói elkötelezettség növekedése,
• bizalom növekedése.

4.4.2. Prototípus készítésének hátrányai:

• felfokozott felhasználói elvárások,
• a prototípuskészítési eszközbõl eredõ hiányosságok megjelenése,
• a projekt határainak megváltoztatása,
• túl sok prototípus-készítési ciklus,
• nem szabványos tervezés,
• dokumentáció hiánya.

5. A követelmény-specifikációs prototípus

• A prototípuskészítés kiterjedésének meghatározása
• Kezdeti menüszerkezetek prototípusainak elkészítése
• Menük, képernyõk és jelentések prototípusainak elkészítése
• Prototípus-bejárási utak létrehozása
• Prototípus-bejárási utak megvalósítása
• Felkészülés a prototípus bemutatására
• Prototípusok bemutatása és felülvizsgálata

5.1. A prototípuskészítés kiterjedésének meghatározása

A prototípus készítésének kiterjedését leíró anyagot a vezetõség készíti el, leírva a prototípus készítésének határait és célkitûzéseit. A csoport elsõ feladata a modellezésre kijelölt részhalmaz rendszeren belüli kiterjedésének megállapítása.

A 330. lépésben minden funkcióhoz létrehoztak egy B/K adatszerkezetet, valamint egy Felhasználói szerepkör/funkció mátrixot, amelybõl a kritikus dialógusok azonosíthatók. A kritikusként megjelölt dialógusokra meg kell vizsgálni a prototípuskészítés lehetõségét. A felhasználók további dialógusokat jelölhetnek ki, amelyeket el kell fogadni, ha az idõ- és költségkeretekbe beleférnek.

Ezen felül hasznos lehet a jelentések kimenetének modellezése is, ha léteznek olyan külsõ vagy belsõ elõírások, amelyeknek meg kell felelni.

5.2. Kezdeti menüszerkezetek prototípusainak elkészítése

A megállapított kiterjedésnek megfelelõen ki kell alakítani a menü- és parancsszerkezeteket és meg kell valósítani õket a támogató eszközben.

A létrejött menü prototípusokat be kell mutatni az illetékes felhasználóknak, jelezve a csoport vezetõjének a felmerülõ változtatási igényeket. Ilyenkor meg kell vizsgálni, hogy van-e mögöttes probléma (pl. a felhasználói szerepkör/funkció mátrix kialakításában) vagy egyszerû felhasználói igényrõl van csak szó. Az elfogadott változtatásokat a kísérõ dokumentációba (menüszerkezetekbe) is át kell vezetni, módosítva szükség esetén a követelményjegyzéket és a felhasználói szerepkör/funkció mátrixot is.

5.3. Menük, képernyõk és jelentések prototípusainak elkészítése

Minden kijelölt dialógust vagy jelentést egy prototípus-bejárási út formájában kell meghatározni, ami felhasználói szerepkörönként mutatja a dialógus vagy jelentés útját a prototípuson belül. Az út tartalmazza az összes felhasználói felületre vonatkozó követelményt, a rendszer kiindulópontjától a dialógus vagy jelentés végrehajtásának befejezéséig. Ez egy olyan munkaanyag, amely magas szinten leírja, hogy a menük, dialógusok és jelentések hogyan kapcsolódnak egymáshoz a prototípuson belül.

A képernyõk komponenseinek azonosításához a dialóguselemek logikai csoportjait kell felhasználni, amelyeket a B/K adatszerkezetek alapján lehet kialakítani.

A jelentések kimenetét alkotó komponenseket a B/K adatszerkezetek kimenõ adatelemei alapján lehet azonosítani.

5.4. Prototípus-bejárási utak létrehozása

A képernyõ és jelentés komponenseinek azonosítása után ezeket a komponenseket össze kell illeszteni a meglévõ menükkel, létrehozva a prototípus-bejárási utakat. Egy ilyen út leírása szögletes dobozokból és a dobozokat összekötõ függõleges vonalakból áll. Minden doboz egy menüt, képernyõt vagy jelentést jelöl.

5.5. Prototípus-bejárási utak megvalósítása

Menük prototípusai

A menük prototípusai már készen vannak ezen a ponton, így keretként használhatók a képernyõk és jelentések komponenseinek megvalósításánál.

Képernyõk és jelentések prototípusai

A képernyõk terveit kezdetben a megvalósítók önállóan alakítják ki, bár a szervezetszintû környezeti útmutató segíthet. A feladat az, hogy a lehetõ legkönnyebbé tegyék a képernyõk kezelését, hogy a felhasználók a helyességre tudjanak koncentrálni. Általános elvek:

• áttekinthetõ és jól strukturált legyen
• az adatok bevitelét felülrõl lefelé és balról jobbra haladó sorrendben engedje
• tartalmazza az összes adatot a feldolgozáshoz

A jelentések prototípusainál az azonosított kimenõ adatelemeket meg kell feleltetni a prototípus kimeneteinek.

Képernyõk és jelentések prototípusainak ellenõrzése

A képernyõk és jelentések prototípusainak adatelemeit össze kell hasonlítani az igényelt rendszer logikai adatmodelljével és az adatelemek leírásaival. A származtatott vagy számolt adatelemeket külön adatelemként le kell írni. A kiszámítás módját le lehet írni az adatelemek leírásában, vagy le lehet írni mint közös használatú feldolgozási folyamatot a funkciók leírásához. Az elemi folyamatok leírásaira szükség esetén hivatkozni lehet.

5.6. Felkészülés a prototípus bemutatására

A bemutatás elõtt minden prototípus-bejárási úthoz el kell készíteni egy prototípus-bemutatási célkitûzéseket tartalmazó dokumentumot, amely felsorolja minden menühöz, képernyõhöz és/vagy jelentéshez a feltételezéseket és a feltevésre váró kérdéseket (a bejárási út leírásában azonosított komponensekhez).

5.7. Prototípusok bemutatása és felülvizsgálata

A prototípusok modelljeit egy vagy több olyan felelõs felhasználónak kell bemutatni, aki az adott prototípus-bejárási útban meghatározott felhasználói szerepkört tölti be. A bemutató során két dokumentumot kell használni:

• Protípus-bemutatási célkitûzések, amely minden komponensehez tartalmazza a megbeszélendõ kérdéseket.
• Prototípus-bemutatási eredménynapló, amelyben a bemutató eredményeit rögzítik.

Az eredménynaplóba rögzíteni kell a felhasználó által felvetett igényeket, komponensenként. A bemutató után az eredménynaplót ki kell egészíteni az eredményekhez tartozó változtatási igény típusával.

A bemutató után a csoport vezetõjének el kell döntenie a következõ kérdéseket:

• Elérte a prototípuskészítés az észerû hasznosság határait, vagy további bemutatók hasznosak lehetnek még?
• Szükséges az eredeti idõzítést meghosszabbítani, vagy további erõforrásokat bevonni? Ha igen, engedélyt kell kérni a vezetéstõl.
• Vannak olyan problémák, amiket a vezetés felé kell továbbítani?

A csoport vezetõjének biztosítania kell, hogy minden szükséges változtatás a támogató dokumentációban át legyen vezetve.

6. SSADM termékek módosítása

A prototípus-készítési ciklus minden ismétlése újabb változtatási igényekkel járhat az SSADM más termékeire nézve is, például az igényelt rendszer logikai adatmodelljénél. Ezeket a változtatásokat meg kell valósítani, és a prototípust újra be kell mutatni, megerõsítvén azt, hogy a változtatás a gyakorlatban kivitelezhetõ, és ez az, amit a felhasználó akar.

Az ellenõrzés után a csoport vezetõjének el kell juttatnia a változtatási igényeket az elemzõkhöz, akik helyezetüknél fogva jobban fel tudják mérni a változtatások hatásait. Az elemzõk ezek után tájékoztatják a 3. szakasz szakmai irányítóját, aki elfogadja vagy visszautasítja a változtatásokat. Ösztönözni kell a megjelenõ változtatási igények korai felvetését, mivel megvalósításuk elõre nem látható jelentõséggel bírhat, rámutathat például az elemzés hiányosságaira. Az is elõfordulhat, hogy a prototípuskészítés közben jó ötletként elfogadott dolgok a szélesebb környezetben megvizsgálva nem tûnnek praktikusnak.

Ha új követelményeket azonosítanak és fogadnak el a felhasználókkal együtt, akkor ezeket a csoport vezetõje felveheti közvetlenül a követelményjegyzékbe a prototípuskészítés lezárása után.

7. Végsõ módosítások és vezetõi jelentés

A bemutatók végeztével minden végsõ változást fel kell venni a kísérõ dokumentációba, valamint a követelményjegyzéket ki kell egészíteni bármely új vagy módosított követelménnyel, ami a prototípus-készítési tevékenységbõl eredt.

A csoport vezetõjének jelentést is kell készíteni a vezetés számára. A következõ kérdésekre kell válaszolni:

• Megmaradt a prototípuskészítés a vezetés által eredetileg meghatározott kiterjedés keretein belül?
• Elérte a prototípuskészítés a kiterjedést leíró dokumentumban megfogalmazott célkitûzéseket? Ha nem, miért nem? (Lehet, hogy ez inkább a célkitûzésekre vonatkozó reagálás és nem a prototípuskészítés minõsítése, azaz a célkitûzések voltak értelmetlenek vagy rosszul meghatározottak. Az erre vonatkozó értékelés hasznos lehet a jövõben.)
• Milyen változtatások történtek a követelmény-specifikációban, azaz milyen új követelmények keletkeztek, melyek változtak, mely SSADM termékek módosultak a prototípuskészítés eredményeképp?
• Hasznos volt-e a prototípuskészítés mint tevékenység, vagy nem hozott hasznot? Van-e valami, amit másképp lehetett vagy kellett volna csinálni?

8. Formalapok

8.1. Prototípus-bejárási út

Verzió	Itt a prototípus-bejárási út verziószámát jelenti. Ha elõzõ bemutatók változtatási igényeket támasztottak a bejárási úttal szemben, akkor ezeket a változtatásokat meg kell valósítani és a verziószámot növelni kell eggyel. Ha a változtatási igények nem érintik a bejárási utat, akkor a verziószám változatlan marad.
Funkció neve	A funkció neve, amelyhez a prototípus-bejárási út készült.
Szerepkör	A felhasználói szerepkör, akinek a prototípus-bejárási út készült.
Prototípus-bejárási út száma	Minden prototípus-bejárási útnak egyedi azonosítót kell adni.

8.2. Prototípus-bemutatási célkitûzés

Verzió	A prototípus-bejárási út verziószáma. Bõvebben lásd ott.
Dokumentum száma	Adott prototípus-bejárási úthoz létrehozott összes prototípus-bemutatási célkitûzésnek egyedi számot kell adni. Így a prototípus-bejárási út száma és a dokumentum száma egyedileg azonosít minden prototípus-bemutatási célkitûzést tartalmazó dokumentumot.
Prototípus-bejárási út száma	A prototípus-bejárási út száma.
Funkció neve	A funkció, amelyre a prototípus-bejárás vonatkozik.
Szerepkör	A felhasználói szerepkör, akinek a prototípus-bejárási út készült
Napirend	A protípus bemutatásának elérendõ céljai. Ez hasonló egy összejövetel napirendjéhez.
Komponens száma	A prototípus-bejárási út egy elemének száma, ami lehet egy menü, képernyõ vagy jelentés.
Komponensre vonatkozó kérdések	Összefoglalása azoknak a kérdéseknek, amelyeket meg kell válaszolni a bemutató során, minden egyes menü, képernyõ vagy jelentés esetén.

8.3. Prototípus-bemutatási eredménynapló

Verzió	A prototípus-bejárási út verziószáma. Bõvebben lásd ott.
Dokumentum száma	Adott prototípus-bejárási úthoz létrehozott összes prototípus-bemutatási célkitûzésnek egyedi számot kell adni. Így a prototípus-bejárási út száma és a dokumentum száma egyedileg azonosít minden prototípus-bemutatási célkitûzést tartalmazó dokumentumot.
Prototípus-bejárási út száma	A prototípus-bejárási út száma.
Funkció neve	A funkció, amelyre a prototípus-bejárás vonatkozik.
Szerepkör	A felhasználói szerepkör, akinek a prototípus-bejárási út készült
Napirend	A protípus bemutatásának elérendõ céljai. Ez hasonló egy összejövetel napirendjéhez.
Komponens száma	A prototípus-bejárási út egy elemének száma, ami lehet egy menü, képernyõ vagy jelentés.
Komponensre vonatkozó kérdések	Összefoglalása azoknak a kérdéseknek, amelyeket meg kell válaszolni a bemutató során, minden egyes menü, képernyõ vagy jelentés esetén.