Ugrás a tartalomhoz

Követelmények nyomon követése

A Wikipédiából, a szabad enciklopédiából

A követelmények nyomon követhetősége a követelménykezelés egyik aldiszciplínája a szoftverfejlesztés és rendszermérnöki tevékenységek során. A nyomon követhetőség általános értelemben az IEEE Systems and Software Engineering Vocabulary[1] szerint az alábbiak szerint definiálható: (1) az a fok, amelyben kapcsolat hozható létre a fejlesztési folyamat két vagy több terméke között, különösen azok a termékek között, amelyek előd-utód vagy elsődleges-alárendelt viszonyban vannak egymással;[2] (2) a származási utak (felfelé) és a kiosztási vagy lefutási utak (lefelé) azonosítása és dokumentálása a munkatermékek hierarchiájában;[3] (3) az a mérték, amelyben minden egyes elem egy szoftverfejlesztési termékben igazolja a létezésének okát; és (4) észlelhető kapcsolatok kialakítása két vagy több logikai entitás között, mint például követelmények, rendszerelemek, ellenőrzések vagy feladatok.

A követelmények nyomon követhetősége különösen az alábbiak szerint definiálható: "az a képesség, amely leírja és követi egy követelmény életútját mind előre, mind visszafelé irányban (azaz az eredetétől kezdve, a fejlesztésén és specifikálásán keresztül, az azt követő bevezetéséig és használatáig, valamint ezen fázisok bármelyikében történő folyamatos finomításig és iterációig)".[4][5] A követelménymérnöki területen a nyomon követhetőség arra irányul, hogy megértsük, miként alakulnak át a magas szintű követelmények – célkitűzések, célok, törekvések, elvárások, üzleti igények – fejlesztésre kész, alacsony szintű követelményekké. Ezért elsősorban az információrétegek közötti kapcsolatok kielégítésére összpontosít (más néven műtermékek).[6] A nyomon követhetőség azonban dokumentálhatja a különböző fejlesztési artefaktumok közötti kapcsolatokat is, mint például követelmények, specifikációs állítások, tervek, tesztek, modellek és kifejlesztett komponensek.[7] Például bevett gyakorlat az ellenőrzési kapcsolatok rögzítése annak bizonyítására, hogy egy követelményt egy bizonyos tesztműtermék igazol.

A nyomon követhetőség különösen fontos a biztonság szempontjából kritikus rendszerek fejlesztésekor, ezért azt olyan biztonsági irányelvek írják elő, mint a DO178C, ISO 26262 és IEC61508 . Ezen iránymutatások általános követelménye, hogy a kritikus követelményeket ellenőrizni kell, és ezt az ellenőrzést nyomon követhetőségen keresztül kell igazolni.[8]

Nyomon követés a követelmények felé és túl[szerkesztés]

Előkövetelmények nyomon követése.[4] követelmények különböző forrásokból származnak, mint például az üzleti személy, aki a terméket megrendeli, a marketing menedzser és a tényleges felhasználó. Ezek az emberek mind különböző követelményeket támasztanak a termékkel szemben. A követelménykövetés segítségével egy megvalósított szolgáltatás visszavezethető ahhoz a személyhez vagy csoporthoz, aki a követelményfelismerés során azt kívánta. Ez felhasználható a fejlesztési folyamat során a követelmény rangsorolására, meghatározva, hogy a követelmény mennyire értékes egy adott felhasználó számára. Emellett a bevezetés után is használható annak megértésére, hogy miért voltak bizonyos, felhasználói vizsgálatok során nem használt funkciók eredetileg szükségesek.

Utókövetelmények nyomon követése.[4] Nem csak a követelményeket kell nyomon követni, hanem azok kapcsolatait is minden hozzájuk kapcsolódó artefaktummal, mint például modellek, elemzési eredmények, tesztesetek, teszteljárások, teszteredmények és mindenféle dokumentáció. Még az embereket és felhasználói csoportokat is, amelyek a követelményekhez kapcsolódnak, nyomon kell követni. A követelmények megvalósulnak a tervezési artefaktumokban, a megvalósításban, és végül ellenőrzésre kerülnek. Az utóbbi szakaszokhoz kapcsolódó artefaktumokat is vissza kell vezetni a követelményekhez. Ez általában egy követelménykövetési mátrixon keresztül történik.

A nyomon követhetőség megteremtése a követelményeken túlmenően a tervezési, megvalósítási és ellenőrzési műtermékekig nehézzé válhat.[9] Például szoftverkövetelmények megvalósítása során a követelmények egy követelménykezelő eszközben lehetnek, míg a tervezési artefaktumok egy tervezési eszközben találhatók. Továbbá a megvalósítási artefaktumok valószínűleg forrásfájlok formájában lesznek, amelyek különböző módokon és különböző szinteken kapcsolhatók össze. Az ellenőrzési artefaktumok, mint például a belső tesztek vagy formális ellenőrző eszközök által generált artefaktumok is nyomon követhetők.

A repository vagy eszközköteg integrációja jelentős kihívást jelenthet a nyomon követhetőség fenntartása terén egy dinamikus rendszerben.

Nyomon követhetőségi információk használata[szerkesztés]

A nyomon követhetőség alkalmazása, különösen, ha a követelményeken túlmenően a eszközáncban található összes műterméket követi, számos előnnyel járhat:[10][11]

  • Változások hatáselemzése – ha egy követelmény megváltozik, a nyomkövetési linkek tájékoztatnak a kapcsolódó és függő artefaktumokról. Ezek az artefaktumok könnyen ellenőrizhetők, és szükség esetén módosíthatók. Ez csökkenti annak valószínűségét, hogy kapcsolódó artefaktumok figyelmen kívül maradnak.
  • Lefedettség-elemzés – a nyomon követhetőség biztosítja, hogy egyetlen követelmény se maradjon figyelmen kívül. Különösen a biztonságkritikus termékek tanúsítása során szükséges igazolni, hogy minden követelmény megvalósult.
  • Projektállapot elemzés – a projekt állapotának nyomon követése lehetséges: a nyomon követhetőségi adatok elemzése lehetővé teszi a követelmények teljesítési állapotának megtekintését. A linkek nélküli vagy hiányos nyomkövetési lánccal rendelkező követelmények (például megvalósítási követelmények, de tesztek nélkül) azt jelzik, hogy további munkára van szükség. A hiányzó linkek megmutatják, hogy mely konkrét artefaktumok hiányoznak és melyeket kell megvalósítani.
  • Termékelemek újrafelhasználása – lehetőség van a követelmények és a hozzájuk kapcsolódó artefaktumok csomagokba rendezésére. Ezek a csomagok különböző termékekhez használhatók.
  • Kapcsolatok megőrzése – gyakran egy projekt vagy termék ismerete bizonyos személyek fejében van. A nyomon követhetőség használatával ez a tudás megőrződik azáltal, hogy vizualizáljuk a különböző artefaktumok közötti kapcsolatokat. Ez a tudás megmarad, még akkor is, ha egy személy elhagyja a projektet.
  • Tesztoptimalizálás – a követelmények, a forráskód, a tesztesetek és a teszteredmények összekapcsolásával könnyen azonosítható a forráskód érintett részei, ha a tesztek sikertelenek. Továbbá a redundáns tesztesetek azonosíthatók és kiküszöbölhetők.

A nyomon követhetőség által támogatott fejlesztési tevékenységekről és azok relevanciájáról teljesebb áttekintést adunk[12] .

A nyomon követhetőségi információk gyakorlati felhasználása[szerkesztés]

Kiterjedt tanulmányok dokumentálják a nyomon követhetőségi információk rögzítésének hatékonyságát, de nehézségeit is:

  • A nyomon követhetőség felgyorsítja és javítja a fejlesztési tevékenységeket - Egy 71 résztvevővel végzett tanulmány, amelyben forráskód változtatásokat hajtottak végre nyomon követhetőség támogatással és anélkül, kimutatta a nyomon követhetőség előnyeit. A fejlesztők 24%-kal gyorsabban és 50%-kal pontosabban teljesítették a feladatokat nyomon követhetőség támogatással.[13]
  • A teljesebb nyomon követhetőség segít elkerülni a szoftverhibákat - 24 közepes és nagy méretű nyílt forráskódú projekt fejlesztési adatainak elemzése során statisztikailag szignifikáns kapcsolatot találtak a rögzített nyomon követhetőségi információk teljessége és a fejlesztett forráskód hibaaránya között. A teljesebb nyomon követhetőséggel rendelkező komponensek kevesebb hibát (azaz bogarat) mutattak.[14]
  • A megfelelő nyomon követhetőség elérése nehéz – Az Egyesült Államok Élelmiszer- és Gyógyszerügyi Hatóságánál (FDA) 2013-ban az orvostechnikai eszközök szoftvereinek forgalomba hozatal előtti tesztelésének elemzése jelentős hiányosságokat tárt fel az előírt és a benyújtott nyomon követhetőségi információk között.[8] A szabványnak megfelelő nyomon követhetőség felé való törekvés gyakran "nagy befagyasztást" eredményez. Nagy befagyasztás, mivel a cégek célja, hogy elkerüljék a további fejlesztéseket, mert az újratanúsítás óriási erőfeszítéssel jár.[15]

A nyomon követhetőségi információk megjelenítése[szerkesztés]

A nyomon követhetőség egyik célja a műtermékek közötti kapcsolat vizualizálása. A nyomkövetési hivatkozások számának és összetettségének növekedésével a nyomon követhetőség vizualizációs technikáira van szükség. A vizualizáció tartalmazhat információkat a műtermékekről (pl. műtermék típusa, metaadatok, attribútumok) és hivatkozások (pl. link típusa, metaadatok, link erőssége).[16]

A nyomon követhetőségi információk gyakori megjelenítései a mátrixok, grafikonok, listák és hiperhivatkozások .

  • Nyomon követhetőségi mátrix – A nyomon követhetőségi mátrix egy táblázatszerű ábrázolás, amely az oszlopokban ábrázolt egyik típusú műtermékeket (pl. követelmények) leképezi a sorokban ábrázolt másik típusú műtermékekre (pl. forráskód). A cellák két műtermék közötti nyomot jelenítenek meg, ha kitöltöttek, vagy nem nyomot, ha üresen hagyják.[16] A nyomon követhetőségi mátrixok előnye, hogy a műtermékek közötti összes kapcsolat egy pillantással látható. A szűrők segítenek csökkenteni a megjelenített információk mennyiségét. A nyomon követhetőségi mátrixok alkalmasak menedzsment feladatokra.[16] Az iparban azonban a projektek gyakran több ezer műtárgyból állnak: a táblázatok nagyon nagyokká és zavaróvá válhatnak.[17]
  • Nyomon követhetőségi gráf – A nyomon követhetőségi gráfban a műtermékek csomópontokként jelennek meg. A csomópontokat élek kötik össze, ha létezik nyomkövetési kapcsolat a műtermékek között. A grafikonok különösen alkalmasak fejlesztési feladatokra. Lehetővé teszik a hivatkozások feltáró jellegű áttekintését, és magas információértési arány jellemzi őket.[16] A grafikonon való navigálással könnyen azonosíthatóak a hiányzó hivatkozások, ami a szükséges műtermékek létrehozásához szükséges.
  • Lista – A listák egy bejegyzésben ábrázolják a nyomon követési linkeket. Ez a bejegyzés tartalmazhat információkat a forrás és a cél artefaktumról, valamint attribútumokról. Különösen alkalmasak, amikor több különböző artefaktumra vonatkozó tömeges műveleteket kell végrehajtani. Szűrők és rendezési mechanizmusok lehetővé teszik a megjelenített információk kezelését. Azonban a fent leírt vizualizációkhoz képest a listák kevésbé alkalmasak projektmenedzsment, fejlesztési és tesztelési feladatok végrehajtására.[16]
  • Hiperhivatkozás – A hiperlinkek összekapcsolják a kapcsolódó artefaktumokat, és lehetővé teszik a "ugrást" egy forrás artefaktumtól egy kapcsolódó artefaktumig. Ez a vizualizáció akkor alkalmas, ha részletes információkra van szükség egy artefaktumról, mivel lehetővé teszi az artefaktumok natív környezetben való navigálását.[16] A hiperlinkek önálló használatának hátránya, hogy sok navigációs erőfeszítést igényel a linkek állapotának áttekintése, mivel a kapcsolódó artefaktumok nem kompakt módon vannak vizualizálva.

A vizualizációk kombinálhatók sajátos korlátaik leküzdésére.

Műszaki megvalósítás[szerkesztés]

Kézi nyomon követhetőség[szerkesztés]

A nyomon követhetőség úgy valósul meg, hogy teljesen manuálisan vagy eszközökkel, például táblázatként a Microsoft Excelben rögzíti a nyomokat. Bár széles körben alkalmazzák, ez a folyamat nehézkes, hibás, és gyakran olyan nyomon követhetőségi információkhoz vezet, amelyek a különféle fejlesztési eszközök és a nyomon követendő műtermékek jellemzően nagyon magas száma miatt nem megfelelő minőségűek.[18]

Eszköz által támogatott nyomon követhetőség[szerkesztés]

Az eszköztámogatott nyomon követhetőség megköveteli, hogy a fejlesztési információkat, amelyek egy teljes fejlesztőeszköz-lánc mentén szóródnak szét, homogenizálják és összesítsék. Az alábbi megközelítések léteznek ennek az állapotnak az eléréséhez:

A szoftvereszköz-környezet homogenizálása ALM- eszközzel – Az ALM -eszközláncok lefedik a szoftverfejlesztési életciklust, és kezelik a szoftverfejlesztési folyamat összes műtermékét. Sok vállalat a legjobb megoldások alkalmazását választja a feladatkezeléshez, a kódkezeléshez és számos tesztautomatizálási eszközhöz. Azok a vállalatok, amelyek a legjobb megoldások megközelítést választják, a nyomon követhetőségi kihívást olyan követelménykezelő (RM) eszközökkel oldják meg, amelyek teljes nyomon követhetőségi modellt és integrációkat biztosítanak a legjobb eszközökhöz. Egyetlen ALM eszköz, amely lefedi a követelményeket, kockázatelemzést, rendszertervezést, feladatkezelést, kódrepozitóriumokat, integrációt, tesztelést és egyebeket, egy klasszikus kompromisszum a legjobb képességek és egy korlátozottabb funkciókészletű, közös platform között.

Az adatok homogenizálása helyettesítő követelmények segítségével – a követelménykezelő (RM) eszközök lehetővé teszik a rendszer specifikációinak összes követelményének tárolását, rendszerezését és kezelését, és jellemzően egy specifikációs fába rendezik azokat, amelyek minden követelményt a magasabb specifikáció szülőkövetelményéhez kapcsolnak. . A rögzített nyomon követhetőségi információk alapján végzett tipikus elemzési funkciók például a teljesség ellenőrzése (azaz minden rendszer szintű követelmény lemegy-e a berendezés szintjére módosítással vagy anélkül), a követelmények eltéréseinek értékelése minden szinten és a minősítési státusz bemutatása. Annak érdekében, hogy a követelményeken túli artefaktumtípusokra is biztosítsák a nyomon követhetőséget, az RM eszközök gyakran lehetővé teszik más artefaktumok importálását helyettesítő követelményeként, amelyeket aztán az eszköz követelménykövetési módszereivel lehet nyomon követni. Ennek a megközelítésnek a hátránya, hogy különböző adapterek vagy konverterek szükségesek a különböző artefaktumtípusokhoz, amelyeknek egységes verzióval és adatformátummal kell rendelkezniük. Az ALM eszközökkel ellentétben ezt a konzisztenciát magunknak kell fenntartani.

Az adatok homogenizálása dedikált nyomkövetési eszközzel – a dedikált nyomon követési eszközök alapkoncepciója három alapvető lépésből áll:

  • Az adatmodell, más néven nyomon követhetőségi információs modell (TIM) meghatározása. Ez a modell meghatározza, hogy mely műterméktípusok (pl. érdekelt felek követelményei, szoftverkövetelmények, integrációs tesztek, rendszermodell-elemek) és hogyan kapcsolódnak egymáshoz.
  • A fejlesztői eszközlánc részét képező összes eszköz összes releváns adatából származó leképezések meghatározása, valamint az adatok TIM-hez való leképezésének módja.
  • A mérőszámok és az elemzési funkciók a TIM-en vannak definiálva – nem egy adott eszközben található adatokon.

Ez a megközelítés egyesíti a fent említett megközelítések előnyeit: átfogó módon lefedi az összes eszközt és artefaktumot, homogenizálja az adatokat, és elkerüli az elavult helyettesítők által okozott inkonzisztenciák kockázatát. A hátránya, hogy ez a megközelítés azt jelenti, hogy az eszközláncot egy további (nyomon követési) eszközzel kell bővíteni.

Nyomon követési eszközök[szerkesztés]

Sok projektben az emberek irodai eszközöket, például táblázatokat használnak a nyomon követés kezelésére. Ezek az eszközök hajlamosak a hibákra, ha több száz követelmény és több felhasználó dolgozik egy projekten. Speciális nyomon követési eszközöket is használhat a projektjei hatékony irányításához.

Hivatkozások[szerkesztés]

  1. ↑ Systems and software engineering -- Vocabulary. Iso/Iec/IEEE 24765:2010(E), 1–418. o.. DOI: 10.1109/IEEESTD.2010.5733835 (2010. december 1.). ISBN 978-0-7381-6205-8 
  2. ↑ IEEE Guide for Developing System Requirements Specifications. 1998 Edition IEEE STD 1233, 1–36. o.. DOI: 10.1109/IEEESTD.1998.88826 (1998. december 1.). ISBN 978-0-7381-1723-2 
  3. ↑ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. IEEE STD 1362-1998, 1–24. o.. DOI: 10.1109/IEEESTD.1998.89424 (1998. december 1.). ISBN 978-0-7381-1407-1 
  4. ↑ a b c Gotel, O.C.Z.. An analysis of the requirements traceability problem, Proceedings of IEEE International Conference on Requirements Engineering (amerikai angol nyelven), 94–101. o.. DOI: 10.1109/icre.1994.292398 (1994. április 1.). ISBN 978-0-8186-5480-0 
  5. ↑ Gotel, Orlena.szerk.: Cleland-Huang: Traceability Fundamentals, Software and Systems Traceability (angol nyelven). Springer London, 3–22. o.. DOI: 10.1007/978-1-4471-2239-5_1 (2012. január 1.). ISBN 9781447122388 
  6. ↑ Hull, Elizabeth. Requirements Engineering, Second, Springer, 9–13, 131–151. o. (2005). ISBN 978-1-85233-879-4 
  7. ↑ Pinheiro F.A.C. and Goguen J.A., "An object-oriented tool for tracing requirements", IEEE Software 1996, 13(2), pp. 52-64
  8. ↑ a b Mäder (2013. május 1.). „Strategic Traceability for Safety-Critical Projects”. IEEE Software 30 (3), 58–66. o. DOI:10.1109/MS.2013.60. ISSN 0740-7459.  
  9. ↑ Li, Yin. Requirement-Centric Traceability for Change Impact Analysis:A Case Study. Springer Berlin/Heidelberg, 100–111. o. (2008). ISBN 978-3-540-79587-2 
  10. ↑ Wiegers: Requirements Traceability: Links in the Requirements Chain, Part 1. jama, 2013 (Hozzáférés: 2016. december 14.)
  11. ↑ Wiegers, K.. Software Requirements. Microsoft Press (2013) 
  12. ↑ Bouillon, Elke.szerk.: Doerr: A Survey on Usage Scenarios for Requirements Traceability in Practice, Requirements Engineering: Foundation for Software Quality, Lecture Notes in Computer Science (angol nyelven). Springer Berlin Heidelberg, 158–173. o.. DOI: 10.1007/978-3-642-37422-7_12 (2013. április 8.). ISBN 9783642374210 
  13. ↑ Mäder (2015. április 1.). „Do developers benefit from requirements traceability when evolving and maintaining a software system?” (angol nyelven). Empirical Software Engineering 20 (2), 413–441. o. DOI:10.1007/s10664-014-9314-z. ISSN 1382-3256.  
  14. ↑ Rempel (2016. január 1.). „Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality”. IEEE Transactions on Software Engineering PP (99), 777–797. o. DOI:10.1109/TSE.2016.2622264. ISSN 0098-5589.  
  15. ↑ open-DO | Toward a cooperative and open framework for the development of certifiable software (amerikai angol nyelven). www.open-do.org. (Hozzáférés: 2017. április 15.)
  16. ↑ a b c d e f Li, Y.. Which Traceability Visualization Is Suitable in This Context? A Comparative Study.. Springer, 194–210. o. (2012) 
  17. ↑ Lerche: 5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH, 2019
  18. ↑ Kannenberg (2009). „Why Software Requirements Traceability Remains a Challenge”. CrossTalk Magazine - the Journal of Defense Software Engineering.  

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Requirements traceability 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.

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Követelmények_nyomon_követése&oldid=27157109”