A szoftverfejlesztésben a fejlesztési szakaszokat a szoftvertermékek készenléti fokának leírására használják . Ezenkívül a fejlesztési szakasz tükrözheti a program egy adott verziójához tervezett megvalósított szolgáltatások számát . A szakaszokat hivatalosan bejelenthetik és szabályozhatják a fejlesztők, vagy néha informálisan használják a kifejezést a termék állapotának leírására.
A Béta és az Alfa szakaszok nem jelzik az instabilitást, mivel a fejlesztési rendszertől függően sorozatonként (jelen esetben sorozatonként az első pontig terjedő szám) egyszer vagy egyszer hozzárendelődnek a programhoz. Egymás után több kiadott verzióhoz is hozzárendelhetők.
Az alfa/béta tesztelési terminológia először az IBM -nél jelent meg . Hasonló kifejezéseket használtak a szoftverfejlesztésre az IBM-mel kapcsolatban álló emberek legalább az 1950-es évek óta, de valószínűleg korábban is.
Az "A" teszt egy új termék tesztje volt nyilvános bejelentés előtt.
A "B" teszt egy gyártás előtti ellenőrzés volt .
A "C" teszt volt az utolsó teszt a termék általános elérhetősége előtt.
Mivel a szoftverek az IBM termékeinek fontos részévé váltak, az alfatesztelés terminológiáját használták a bejelentés előtti tesztre, míg a béta teszteléssel jelezték, hogy a termék készen áll az általános elérhetőségre. Martin Belsky, néhány korai IBM szoftverprojekt menedzsere azt állította, hogy ő a terminológia ötletgazdája. Az IBM az 1960-as években felhagyott az alfa/béta terminológiával, de addigra már meglehetősen elterjedt.
A "béta teszt" kifejezés, mint a felhasználók által végzett tesztelés megjelölése, nem az IBM-től származik. Ehelyett az IBM a helyszíni teszt kifejezést használta .
A fejlődés kezdeti szakasza a fejlődés kezdetétől az alfa szakasz felszabadításáig tartó időszak. Így hívják azokat a programokat is, amelyek még nem értek el az alfa vagy a béta szakaszba, de már túljutottak a fejlesztési szakaszon, a működőképesség kezdeti értékeléséhez. Az alfa- és bétaverziókkal ellentétben előfordulhat, hogy a kezdeti szakasz nem tartalmazza a programfunkciók teljes skáláját. Ebben az esetben a program tervezése és fejlesztése során a tesztelésig végrehajtott összes művelet beletartozik. Ezek a tevékenységek a következők:
Az a szakasz, amikor a program egészét tesztelők kezdeményezik, általában nem a szoftvertermék fejlesztői, hanem általában a terméket fejlesztő szervezeten vagy közösségen belül. Ez lehet az új funkciók hozzáadásának szakasza is. Az ebben a szakaszban lévő programok csak a jövőbeli lehetőségek megismerésére használhatók.
Általános szabály, hogy az alfatesztelés a funkciók lefagyásával ér véget, és átlép a béta tesztelésbe.
Az alfateszten (ha van ilyen) átesett program aktív béta tesztelésének és hibakeresésének szakasza . Az ezen a szinten lévő programokat más szoftverfejlesztők is használhatják a kompatibilitás tesztelésére. Ennek ellenére az ebben a szakaszban lévő programok meglehetősen nagy számú hibát tartalmazhatnak.
Mivel a béta termék nem a végleges verzió, és a nyilvános tesztelés a felhasználó saját felelősségére történik, a gyártó nem vállal felelősséget a béta verzió használatából eredő károkért.
Örök bétaA nyílt forráskódú Tim O'Reilly egy speciális programtípust ad ki "perpetual beta" néven, amikor egy program határozatlan ideig béta állapotban van. Egy ilyen mechanizmus megfelelő az interneten, ahol a szoftver a következő tulajdonságokkal rendelkezik:
Jelölt szakasz, hogy stabillá váljon. Az ebben a szakaszban lévő programok átfogó tesztelésen estek át , melynek köszönhetően minden kritikus hibát kijavítottak. Ugyanakkor lehetőség van néhány további hiba feltárására is, amelyeket a tesztelés során nem vettek észre. Ha a beállított időn belül nem találnak nagyobb hibát, akkor az RTM verzió lesz. Példa: Windows 7 RC 7100 .
A kiadást követően a szoftvert általában "stabil kiadásnak" nevezik.
A formális kifejezés gyakran a kiadás módjától függ: fizikai adathordozó, online kiadás vagy webes alkalmazás.
Szoftvertermék replikációs készenlétének kijelölése [1] . Ez a program stabil verziója, amely átment az összes korábbi szakaszon, amelyben a főbb hibákat kijavították. Az RTM megelőzi az általános elérhetőséget (GA), amikor egy terméket kiadnak a nyilvánosság számára.
A kifejezést gyakran használják bizonyos sorozatgyártású szoftver-kiskereskedelmi környezetekben annak jelzésére, hogy a szoftver megfelel egy bizonyos minőségi szintnek, és készen áll a tömeges kiskereskedelmi forgalmazásra. Az RTM más összefüggésben azt is jelentheti, hogy a szoftvert leszállították vagy kiadták egy ügyfélnek vagy vásárlónak telepítés vagy terjesztés céljából a berendezés megfelelő számítógépein vagy végfelhasználói számítógépein.
Ez a kifejezés nem határozza meg a szállítás mechanizmusát vagy terjedelmét; csak azt jelzi, hogy a minőség elegendő a tömeges replikációhoz.
Az általános elérhetőség vagy általános elfogadás ( GA ) az a marketingszakasz, amelyben az összes szükséges kereskedelmi tevékenységet befejezték, és a szoftvertermék megvásárolható, azonban nyelvtől, régiótól, elektronikus vagy média-elérhetőségtől függően. Az értékesítési tevékenységek magukban foglalhatják a biztonsági és megfelelőségi felülvizsgálatokat, valamint a lokalizációt és a világméretű promóciót. A kiadás a gyártás és az általános elérhetőség között eltelt idő egy héttől több hónapig terjedhet. Erre az időre van szükség a GA által megkövetelt összes kereskedelmi tevékenység elvégzéséhez. Ebben a szakaszban a szoftver "élesbe ment".
Az internetes kiadás (RTW) vagy webes kiadás olyan szoftver szállításának eszköze, amely az internetet használja terjesztésére. Ebben az esetben a gyártó nem használ semmilyen fizikai adathordozót. A webes kiadások az internet használatának növekedésével egyre gyakoribbak.
A szoftver támogatott élettartama alatt a szoftverhez szolgáltatási kiadásokat, javításokat vagy szervizcsomagokat bocsátanak ki, amelyeket néha "köztes kiadásoknak" is neveznek.
Például Windows operációs rendszereken a támogatás fő szakasza 5-6 évig tart az általános elérhetőségtől számítva [2] . Az olyan operációs rendszerekben, mint az Ubuntu , léteznek speciális LTS -verziók (Long Time Support), amelyek támogatási ideje 5 év, szemben a normál verziók 9 hónapjával [3] .
Ebben a szakaszban a gyártó bejelenti a termék elavultságát és a további támogatás elutasítását.
Ezt a 7 lépést eredetileg a SourceForge webhelyen használták. Ezt a számozást később a PyPI vette át , amely a Python nyelvhez csomagokat üzemeltet.
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|