Miért kell megértenie a szoftverkövetelményeket mint szoftvermérnök?

Ebben a cikkben mindent megtudhat a szoftverkövetelményekről. Vázlatot kap a tématerületről, a folyamatról, és ami a legfontosabb: milyen felelősségei vannak ezen a területen, mint szoftvermérnök.

Érdemes betekintést nyernie a szerepkörébe és a tevékenységeibe a szoftverkövetelményekkel együtt. Ha van valami, a következő stand-up után lesz miről megbeszélnie a kollégákkal?

Ez a cikk nagymértékben kölcsönkér az IEEE SWEBOK útmutatójától. Megpróbálja lepárolni e tudás egy részét, tömörebben újra felhasználva. Ha kíváncsi rá, a SWEBOK az IEEE Számítógépes Társaság által fenntartott Szoftvertechnikai Tudásanyag rövidítése.

Először, miért fontos ez?

Tévhit van azoktól, akik nem a szoftvertervezésben élnek, miszerint a szoftvermérnök feladata csupán "kódot írni".

Igen, technológusok vagyunk, akik általában imádják a programozást. A valóságban ez egy leegyszerűsített nézet, amely alulértékeli azt, amit egy szoftvermérnök szakember valójában tesz a mindennapi munkájában és karrierjében. Csak átfogó felelősségük egy szeletére összpontosít.

A szoftvermérnök szerepe az üzleti megoldások vállalati szintű kiépítése. Ez számos olyan felelősséget tartalmaz, amelyek nem kapcsolódnak az általuk létrehozott kódhoz.

A professzionális szoftvermérnökök egyik felelősségi köre a szoftverkövetelmények területe.

Mik a szoftverkövetelmények?

A felületre vonatkozó szoftverkövetelmények egyszerűen hangzanak. A szoftvernek X-et kell tennie Y-ért, hogy Z. Gondoljon rá elég sokáig minden olyan problémára, amelyet a szoftver megoldhat (vagy a meglévő szoftverre, amely már megoldja a problémát), és valószínűleg számos követelményt meggondolhat. Könnyű, igaz?

Nos, valójában a legtöbb vállalati szoftver esetében.

Hogyan gyűjted össze a követelményeidet? Figyelembe veszi az érintettek igényeit és prioritásait? Ez valóban követelmény a szoftver felhasználói számára? Vannak-e technikai korlátai a szempontoknak? Honnan tudod, hogy ez elkészült? A követelmény megvalósítása megfelel-e egy meghatározott kritériumnak? Stb...

Amikor elkezdi vizsgálni a Szoftverkövetelmények ötletét, azt tapasztalja, hogy ezek nagy és mélyebb tudásterületet rejtenek.

Milyen mély és nagy tudásterület? A SWEBOK meghatározza, hogy a szoftverkövetelmények területe "a szoftverkövetelmények előhívásával , elemzésével, specifikációjával és validálásával, valamint a követelmények kezelésével foglalkozik a szoftver teljes életciklusa alatt ".

Ennek a területnek a mérete, mint például a tevékenységek száma és az egyes részvételi lehetőségek, elegendő hitelt adott ahhoz, hogy a " követelménytervezés " néven ismert mérnöki ágat kizárólag a követelmények folyamatára összpontosítsák.

Bizonyos szervezetek alkalmazhatnak kifejezetten követelménymérnök szerepét. Ezt gyakrabban láthatja például a rendszerszintű megoldásokat kínáló, valóban nagy szervezeteknél, ahol az ügyfelek problémáira javasolt megoldásaik olyan teljes megoldást foglalnak magukban, amelynek a szoftver csak egyetlen összetevője.

Jellemzően a szervezetek hajlamosak megosztani a követelmények mérnöki felelősségét olyan tevékenységek révén, amelyeket a különböző projekt-szerepkörök között osztanak ki, például tervezők, üzleti elemzők, terméktulajdonosok, ajánlat- vagy ügyfélkezelés, műszaki írók, szoftverépítészek / mérnökök stb.

Általában nehéz a követelmények folyamatát lineáris folyamatban megvalósítani a gyakorlatban, például a vízesés módszertanához. Ehhez meg kellene követelni a szoftverkövetelményeket az érdekelt felektől, osztályozniuk, kiosztaniuk, és végül átadniuk őket a szoftverfejlesztő csapat végrehajtására. Ez gyakran nem valósítható meg hosszú távú, nagyszabású sikeres megoldások esetén.

Az ilyen nagy szoftverprojektekkel szemben támasztott követelményeket soha nem értik és nem határozzák meg tökéletesen. Ehelyett általában csak annyi minőségi és részletességi szintet ismételnek, amely lehetővé teszi a tervezési és beszerzési döntések meghozatalát.

A követelménytervezés abban különbözik a szoftvertechnikától, amelyre összpontosít.

Fontos, hogy megértse a követelmények folyamatával való kapcsolatát, mivel valószínűleg valamikor részt vesz valamilyen követelménytevékenységben.

Mi jár a szoftvermérnök szoftverkövetelményeivel?

Szervezete követelményeinek folyamatától és / vagy a szoftvermérnök által végzett követelményaktivitásoktól függően részt vehet bármelyik szakaszban vagy az összes szakaszban. Ez a követelmények összegyűjtésétől a végrehajtásuk ellenőrzéséig terjedhet.

Azok a területek, ahol érintett lehet:

  • Elicitation - a szoftver követelményeinek összegyűjtése
  • Osztályozás - a követelmény kategorizálása
  • Validálás - a követelmény megerősítése az érdekelt felekkel
  • Fejlesztés és megvalósítás - a szoftver kiépítése a követelményeknek való megfelelés érdekében
  • Tárgyalás - az érdekeltek összeférhetetlenségének kezelése
  • Ellenőrzés - a szoftverfunkció kiértékelése kielégíti a követelményt

Érdemes megjegyezni, hogy ez nem a követelménytervezési folyamat másolata. Ezek mélyebb szintű részvételt és tevékenységtípusokat igényelnek bizonyos területeken, például a követelmények kezelésében és dokumentálásában.

A követelmények kezelése és dokumentálása általában nem az Ön felelőssége. Valószínűleg ez lesz a másik szerepkör, amely megosztja a felelősséget.

Fontos, hogy tudja, hogyan férhet hozzá a követelmények irányítási rendszeréhez, és hogyan használhatja fel a követelmények változásainak és a hatáselemzés értékelésére.

Hm, nincs a követelmények irányítási rendszere ...

Bizonyos esetekben előfordulhat, hogy a követelmények rögzítése és kezelése nem speciális rendszerben történik. Rögzíthetők más típusú rögzítési rendszerekben is, például kiadáskövető szoftverben, projektmenedzsment eszközökben vagy akár a verziókezelő rendszerben.

Más esetekben a szervezetek vagy a projektcsoportok nem dolgoznak ki eszközt a követelmények dokumentálására és kezelésére. Ehelyett támaszkodhatnak a vezetés jövőképére (egyén vagy csapat, amelynek általános példája a cégalapító), és / vagy korlátozott erőforrásokkal rendelkeznek. Ellenérvelhetnek azzal, hogy a követelmények rögzítése vagy kezelése nem szükséges.

A követelmények nem rögzítése és kezelése komoly kockázatot jelenthet a szervezetre és a szoftveres megoldás folyamatára.

Például az ügyfél igényeinek megfelelő megoldásokat kidolgozó szervezetének teljesítenie kell bizonyos jogi kötelezettségeket. Azt fogják állítani, hogy az Ön szoftverkomponense bizonyos funkcionalitások biztosítására épül, és képes egy meghatározott szintű szolgáltatás nyújtására.

De ha konfliktus merül fel (jogi vagy egyéb), esetleg hiányzik a funkció, egy nem funkcionális követelmény nem a várakozásoknak megfelelően működött, vagy akár a nem kívánt funkciókra fordított idő / költségvetés, hogyan mutathatja meg, hogy mi valósult meg az érdekelt felek szükség szerint és szükség szerint megállapodtak?

Szervezetének képesnek kell lennie bemutatni a magas szintű megoldási követelmények (amire az ügyfélnek megoldásként szüksége van) és az érvényesített szoftverkövetelmények (amit az érdekeltek egyetértettek a megoldás funkcionális szükségleteinek kielégítésében) feltérképezését, nem feltétlenül 1) a dokumentált dokumentáció megvalósításáig és az elfogadás vagy a szolgáltatási szintű tesztek rögzítéséig, amelyek bemutatják a nyújtott funkcionalitást.

Egy másik gyakoribb (és kevésbé mesterkélt) példa a hatás értékelése. Ahogy a szervezete vagy a projekt csapata növekszik és fejlődik, az Ön által létrehozott szoftver is növekszik. Hacsak a szoftvert nem kívánják kiadni, elképzelni kell róla, hogy egy ideig működni fog, ezért frissítéseket, új szolgáltatásokat és karbantartást igényel.

Ez az új munka érvénytelenítheti, befolyásolhatja vagy megváltoztathatja a meglévő funkciókat, amelyeket úgy terveztek, hogy különböző módon kielégítsék a történelmi követelményeket (például megváltoztathassák a szoftver architektúráját vagy egy alkatrész tervét).

Ha igen, akkor újra meg kell vizsgálnia a régi követelményeket, hogy jobban megértse az ezt megalapozó motivációkat. Például miért hajtották végre ilyen módon? Meg kell változtatni a jelenlegi munkát? A régi követelmény továbbra is releváns? stb.

Szoftverigények előhívása

A követelmények előhívása arra a tevékenységre utal, amely leírja a követelmények összegyűjtését vagy összegyűjtését. Nem minden követelmény van "összegyűjtve" az ügyféltől, és származhat abból a rendszerből vagy tartományból, amelyben a szoftver működik (például a kritikus rendszerek működőképessége és megbízhatósága).

Projektmenedzsment szempontból az előhívás kritikus fontosságú a projekt hatókörének és az ügyfél vagy a felhasználó igényei szempontjából fontos teljesítések levezetéséhez, előbb a legfontosabb igényeket rangsorolva.

Mi jár a szoftverkövetelmények felkeltésével?

Attól függően, hogy szerepe milyen mértékben vesz részt a követelmények folyamatában, előfordulhat, hogy a követelményeket a forrásból kell átvennie.

A követelmények előhívása elősegíti a teljes megoldás tervezésének és felépítésének megismerését. Fontos, hogy megértse, honnan származnak a követelmények és milyen technikákat alkalmaznak.

Honnan származnak a szoftverkövetelmények?

A követelményeknek számos forrása van, például:

  • Célok (más néven üzleti gond, kritikus sikertényező stb.)
  • Tartományismeret
  • Az érdekelt felek
  • Üzleti szabályok
  • Működési környezet

Ha részt vesz a forrásokból történő kiváltásban, akkor:

  • Fordítson különös figyelmet a célokra.
    • Ezek gyakran általában homályosak, például: "A szoftvert a bevált gyakorlatok alkalmazásával kell megvalósítani" vagy "A szoftver felhasználóbarátnak kell lennie"
    • Mérje fel a megoldás prioritáshoz viszonyított relatív értékét. Tanulmányozza az elérés viszonylag olcsó módjait.
  • Szerezzen vagy rendelkezzen rendelkezésre álló ismeretekkel az alkalmazás tartományáról
    • Ez megadja azokat a háttérinformációkat, amelyek megértik a követelmények mögött meghúzódó okokat.
    • A valós problémamodellek - például az entitáskapcsolati modellek - kidolgozása kulcsfontosságú a jó szoftverigény-elemzés szempontjából. Próbáljon ontológiai megközelítéssel gondolkodni.
  • Azonosítsa, képviselje és kezelje sokféle érdekelt fél nézőpontját
    • A követelmények ellentmondásosak, átfedésben lehetnek, vagy részben más motivációt igényelhetnek, mint a különböző érdekeltek igényei.
    • Fontos, hogy felismerje a különböző igényeket, különösen a megvalósítás előzetes tervezésében, ahol az igények beépülnek a tervezésbe.
  • Mutasson érzékenységet a megoldás működési környezete iránt
    • A működési környezetet a szervezet szerkezete, kultúrája és belpolitikája fogja befolyásolni.
    • Általános elv, amelyre a szoftverének törekednie kell, hogy nem vezet be nem tervezett vagy kényszerű változásokat a szervezet üzleti folyamatába.

Hogyan érhetem el a szoftverkövetelményeket?

Néhány fő technika, amellyel részt vehet (műszaki szakértelem biztosítása):

  • érdekelt felekkel folytatott interjúkat
  • forgatókönyvek felvázolása
  • prototípusok építése
  • megfigyelés a problémás területen
  • felhasználói történetek

A prototípusok építésénél egy általános elv, amelyet meg kell próbálnia, az, hogy alacsonyabb hűségű prototípusokat gyakrabban használjon ezekben a korábbi szakaszokban.

Ezeket előnyben részesítik, hogy elkerüljék az érdekelt felek kisebb vagy véletlenszerű jellemzőinek rögzítését. A jobb minőségű prototípus nem szándékos módon korlátozhatja a tervezési rugalmasságot.

A szoftverkövetelmények osztályozása

Ha a szoftverkövetelmények felmerültek, akkor azokat a projektcsoport számos kategóriába sorolhatja.

Ez sokféle módon segít, például a projekt erőfeszítéseinek becslésében, a megoldás tervezéséhez szükséges összetevők azonosításában vagy akár egyszerű megvalósítási szempontokban is.

Az osztályozási típusok a következők lehetnek:

  • Funkcionális / nem funkcionális
    • A funkcionális követelmények leírják azokat a funkciókat, amelyeket a szoftvernek végre kell hajtania. Például kommunikációs csatorna biztosítása a felhasználó számára vagy adatok átvitele egyik formátumból a másikba. A termék jellemzői vagy képességei néven is ismertek.
    • A nem funkcionális követelmények a megoldás bizonyos korlátozásainak érvényesítésére szolgálnak, gyakran a minőség szempontjából. Ezek tovább osztályozhatók a sokféle " segédprogram " kategóriájába, például elérhetőség, megbízhatóság, helyreállíthatóság, karbantarthatóság, skálázhatóság, teljesítmény, biztonság stb.
  • Származtatott / kiszabott / megjelenő
    • Más követelményekből ered-e a követelmény?
    • A követelményt kifejezetten az érdekelt felek írják elő?
    • A követelmény feltörekvő tulajdonság? Más szavakkal, egyetlen összetevővel nem lehet megoldani, hanem attól függ, hogy az összes szoftverkomponens hogyan működik együtt.
  • Folyamat / termék
    • A követelmény termékhez kötött? (egy példa: " A szoftvernek igazolnia kell egy személy alkalmasságát ")
    • A követelmény folyamathoz kötött? (egy példa: " A szoftvert fokozatosan kell fejleszteni, és folyamatos integrációs és telepítési munkafolyamatokat kell használnia )
  • Kiemelten fontos
    • A fejlesztés és a megvalósítás költségeinek kiegyenlítése a szállítás szükségességével szemben.
    • Használhat olyan rögzített címkés skálát, amely kötelező, nagyon kívánatos, kívánatos és választható.
  • Hatály
    • A szoftver architektúrára és az alkatrésztervekre gyakorolt ​​hatás mérlegelésére szolgál.
    • A nem funkcionálisoknak gyakran globális hatókörük van.
  • Volatilitás / stabilitás
    • A szoftver életciklusa során megváltozik a követelmény lehetősége.
    • Ez elősegíti a változtatásokat toleráns tervek megvalósítását

Szoftverkövetelmények érvényesítése

Miután kiválasztották és besorolták a szoftverkövetelményeket, azokat az érdekelt felekkel ellenőrizni kell a pontosság érdekében, és hogy valóban megfelelnek-e igényeiknek. Azok a követelmények, amelyeket nem lehet érvényesíteni, valójában csak az érdekeltek "kívánságai".

Ha egy iteratív fejlesztési módszert követ, akkor a követelmények ellenőrzése rendszeresen elvégezhető, hatókörrel elválasztva az egyes megoldási területek körül, vagy darabokban, vagy más logikai értelemben vett szétválasztás lehet.

A követelmények érvényesítése általában azt jelenti, hogy a megoldási csoport visszajátszja az érdekelt feleknek a követelmény megértését. Ez magában foglalhat egy kezdeti tervet (üzleti vagy műszaki, vagy mindkettőt), amely megmutatja, hogyan valósulnak meg az érintettek igényei.

Ezek a megértések iteratív módon jönnek létre a tervezési szakaszokban, és általában egy keresztfunkcionális csapat (tervezők, üzleti elemzők, műszaki szakértők) véleményéből állnak.

Bizonyos esetekben a tervezéshez szükség lehet végrehajtás előtti munkára, hogy jobban bemutassa a csapat megértését, általában funkcionális prototípus formájában.

Az érvényesítés során előfordulhat, hogy csapata nem képes tökéletesen kielégíteni minden érdekelt fél követelményeit. Az Ön felelőssége, mint műszaki szakértő, a korlátoknak megfelelő kompromisszumok bemutatása és tárgyalása lesz. A fő érdekeltek számára elfogadhatónak kell lennie, ugyanakkor költségvetési, technikai, szabályozási és egyéb intézkedéseken belül is.

Funkcionális prototípusok használata

A funkcionális prototípusok hasznosak, mivel lehetővé teszik:

  • a követelmények megértésének igazolása
  • a mérnök feltételezéseinek könnyebb értelmezése
  • visszajelzés, amely új követelményeket támaszt

Figyelembe kell vennie, hogy az érdekelt feleket kozmetikai vagy minőségi problémák zavarhatják. Ezt enyhítheti, ha következetesen közli a demonstráció valódi fontosságát - az alapvető mögöttes funkcionalitást.

A prototípus felépítését a projekt csapata határozza meg. Egyes szószólók olyan prototípusokat részesítenek előnyben, amelyek teljesen elkerülik a szoftvert (hasonlóan a követelmények kiváltásakor építettekhez). Mások inkább valamilyen típusú szoftveres megjelenítést részesítenek előnyben tervezőeszköz-készletek vagy a szoftver gyorsan felépített vázlatos iterációjának köszönhetően a funkciókontroll mögött.

Bármelyik választás mellett is dönt a csapata, vegye figyelembe a prototípus felépítésének sebességét és az alapvető funkcionalitás bemutatásának hatékonyságát.

Szoftverkövetelmények kidolgozása és megvalósítása

Ha a követelményt az érdekelt felekkel validálták, elkezdheti a követelmény kidolgozását / megvalósítását.

Sok esetben szoftverarchitektorként fogsz eljárni, mert a követelmények elemzésének és kidolgozásának folyamata megköveteli, hogy azonosítsák azokat az architektúra / tervező összetevőket, amelyek felelősek lesznek a követelmények teljesítéséért.

Szervezete számára kulcsfontosságú érdek, hogy profitáljon a szoftveres megoldásból. Az Ön felelőssége, hogy megpróbáljon olyan módszereket használni, amelyek csökkentik a fejlesztés és a karbantartás költségeit.

Ezt megteheti például az alkatrészek újbóli felhasználásával (belső vagy más termékekből), jól definiált minták felhasználásával, és jól tesztelt és jól dokumentált eszközökkel / keretekkel dolgozva.

A speciális követelmények, különösen a korlátozások, hatalmas hatással lehetnek a szoftver költségeire. Például, ha a megvalósításban lévő készségei gyengék, vagy a követelmény esetleg ellentétes, vagy nem felel meg a jelenlegi architektúrának. Az ilyen követelmények között fontos kompromisszumokat kell meghatározni a projekt csapatának.

A követelmények folyamata során fontos megérteni azt a várakozást, hogy a követelmények jelentős része megváltozik. Ismerje fel a változások elkerülhetetlenségét, és próbáljon meg lépéseket tenni a tervezésében annak lehetővé tétele érdekében.

A felhasználói történet

Egy szoftvermérnök gyakran dolgozik egy felhasználói sztori megvalósításának kontextusában. A felhasználói történet természetes szóval reprezentálja az adott felhasználói típusnak a szoftverrel való interakcióját és a számukra nyújtandó funkcionalitást. Általában a következő formátumot követi:

Ahogy szeretném, úgy

Egy példa:

Tanfolyamadminisztrátorként szeretném látni a tanfolyamra beiratkozottak számát, hogy lássam az aktuális tanfolyamkapacitást

Bizonyos esetekben a felhasználói történethez terv vagy prototípus tartozik, ha ezekre az érvényesítés szakaszában szükség volt.

Lehetséges, hogy a felhasználói történet nem felhasználóközpontú, hanem egy kialakuló tulajdonság vagy nem funkcionális követelményből ered. Ezekben az esetekben a követelményt más teljesítési kontextusban (például specifikációban vagy forgatókönyvkészletben) kaphatja meg.

A felhasználói történeteknek csak annyi információt kell tartalmazniuk, hogy a mérnöki csapat ésszerű becslést tudjon készíteni a megvalósításának erőfeszítéseiről. Ha csapata nem képes ésszerű becslést készíteni, ez a tudás / készségek, az egyéni magabiztossági szint, az illesztési vagy függőségi korlátok gyenge egyezésének jele lehet, vagy döntően az, hogy a felhasználói sztori minősége nem megfelelő.

A szoftvermérnököket (szükségszerűen) korlátozzák a projektmenedzsment-tervek, ezért meg kell próbálnia lépéseket tenni annak ellenőrzésére, hogy a rendelkezésre álló erőforrásokra tekintettel a követelmények minél magasabbak-e.

A felhasználói sztori bevezetése előtt ellenőrizze:

  • egy megfelelő elfogadási kritériumhoz, amelyet az érdekelt felekkel írtak vagy egyeztek meg, amely meghatározza, hogy a felhasználói sztori céljai hogyan teljesülhetnek a megvalósítással.
    • Ez képezi majd az alapját a jellemző elfogadási tesztjeinek (más szóval, azok a tesztek, amelyek bizonyítják, hogy a követelmény teljesül).
    • Ez részét képezheti a "kész" vagy a teljes csapat definíciójának is.
  • a prototípus kialakítása (ha elkészült) megvalósítható és illeszkedik a projektben jóváhagyott jelenlegi architektúrához, mérnöki készségekhez és eszközökhöz.
  • minden feltételezés, amely alátámasztja a követelményt.
    • Ez rávilágíthat a tudás hiányosságaira, a potenciális problémákra, vagy más, nem figyelembe vett forgatókönyvekre / éles esetekre, amelyek további tisztázást igényelnek az érdekelt felektől.

Szoftverkövetelmények tárgyalása

Egy követelmény végrehajtása során lehetséges, hogy nem minden érdekelt fél elégedettsége teljesül tökéletesen. Ez történhet például funkcionális és nem funkcionális követelmények között, vagy ha az egyik követelmény végrehajtása hatással van egy másik érdekelt fél érdekére.

A legtöbb esetben nem ésszerű egyoldalú döntést hoznia.

Ehelyett Ön felelős a probléma felméréséért, az egyszerű kommunikációért és a fő érdekelt felek számára elfogadható kompromisszumok tárgyalásáról, miközben a költségvetési, műszaki, szabályozási és egyéb korlátok között marad.

A szoftverkövetelmények ellenőrzése

Minden szoftverkövetelmény megköveteli, hogy ellenőrizhető legyen, mint jellemző vagy funkcionális követelmény, vagy globális szinten, mint nem funkcionális követelmény. A követelményeket ellenőrizni kell a kész termékkel szemben.

Fontos feladat az Ön számára az egyes követelmények ellenőrzésének megtervezése.

A szoftvermérnök elfogadási teszt segítségével ellenőrzi a követelményeket. Az elfogadási teszt bemutatja, hogy a követelmény hogyan teljesült (teljesítve az elfogadási kritériumokat), bemutatva a végfelhasználói magatartást, amely a követelmény által meghatározott szoftverrel folytatja az üzleti tevékenységet.

Azokban a követelményekben, ahol az igazolást nehezebb bizonyítani, például nem funkcionális követelmények esetén épített szimulációra lehet szükség. Például a beviteli folyamatot megvalósító szoftver teljesítményterhelésének teszteléséhez tesztszoftvert lehet létrehozni, hogy több száz vagy ezer alkalmazást szimuláljanak a rendszerhez egy fekete dobozos elfogadó teszten.

Mivel a szoftver az idő előrehaladtával fejlődik, egy új követelmény megvalósítása akaratlanul is befolyásolhatja a korábban bevezetett követelmények teljesülését. Ezt a regressziót az átvételi tesztek automatizálásával lehet megvédeni. Számos olyan eszközt és könyvtárat találhat, amelyek a vállalatok által általánosan használt programozási nyelvekhez használhatók, és amelyek lehetővé teszik az elfogadási tesztek automatizálását.

Ne tévessze össze az elfogadási tesztet, mint az egyetlen tesztelési felelősséget. Megfelelően próbálja lefedni a megvalósítást az elfogadáson kívül más tesztekkel, például egység vagy integrációs tesztekkel.

Az elfogadási tesztek bonyolultsági szintjükben változnak az elfogadási kritériumoktól függően. A különböző szervezetek különböző terminológiát és gyakorlatot is használhatnak, ami azt jelenti, hogy összetéveszthető más típusú tesztekkel, vagy más néven hivatkozhatnak rájuk, például végpontok közötti tesztelésre, funkcionális tesztelésre vagy forgatókönyv-tesztelésre. Szervezetének szigorú kritériumai vagy formátumai is lehetnek, amelyekben az elfogadási teszteket bizonyítják.

Ne feledje, hogy minden elfogadási teszt lényege csupán annak hivatalos ellenőrzése, hogy a megvalósított megoldás megfelel-e a szoftver követelményeinek azáltal, hogy a futó alkalmazás felhasználói viselkedését megismétli a végtermékkel.

Dióhéjban ennyi

Sikerült. Dicséret neked!

Remélem, hogy ez a cikk némi előnnyel járt abban, hogy elismerte a szoftverkövetőként betöltött szoftvermérnöki szerepét.

Több cikkemet elolvashatja a blogomon.

Ezt a cikket szabadon osztják meg, és a szerző nem kapott semmilyen hozzájárulást vagy nyereséget, amint azt a SWEBOK szerzői jogi és újranyomási engedélyei előírják. Bármelyik vélemény vagy vélemény nem tükrözi az IEEE-t vagy bármely olyan testületet / szervezetet, amelyhez csatlakozom, amelyet az IEEE nem támogat, és kizárólag a saját véleményemet és véleményemet képviselik.