Cikkjelölt:Változások hatáselemzése
Ez egy olyan cikkjelölt, ami kevés vagy ellenőrizetlen információt tartalmaz, ezért vagy más minőségvédelmi okból nem a cikkek között van, de a témája miatt feljavításra érdemes lehet. A vitalapon le van írva, hogy miben segíthetsz konkrétan ebben az esetben, a Wikipédia:Feljavításra váró cikkjelöltek lapon pedig az, hogy általában miben. |
Ezt a cikkjelöltet feljavítás hiányában hamarosan törölhetik, a törlés tervezett dátuma: 2024. szeptember 6., 00:00 (CEST). Ha meg szeretnéd tartani, építsd tovább. A feljavítás után szólj a járőröknek, hogy már cikké tehető. Bővebben a cikkjelöltekről ide kattintva olvashatsz. |
Ez a szócikk láthatóan fordítás eredménye (valószínűleg gépi fordítás). Segíts te is átnézni, hogy ne maradjanak benne magyartalan megfogalmazások, hibás linkek és téves hivatkozások. Ha ezeket kijavítottad, bátran távolítsd el a sablont. Ha a sablonnal nem a jelöltek között találkozol, nevezd át, vagy értesítsd a járőröket! |
A változások hatáselemzése (IA) vagy hatáselemzés a telepített termék vagy alkalmazás változásainak elemzése és lehetséges következményeik elemzése.[1][2]
Bohnner és Arnold meghatározza a változás hatáselemzését[3] úgy, mint "a változás potenciális következményeinek azonosítása, vagy becslése arról, hogy mi módosulhat, hogy végrehajtsunk egy változást", és ők az IA-t a tervezés részleteiben bekövetkező változások hatáskörének meghatározására összpontosítanak. Ellentétben Pfleeger és Atlee[4] azonosítják a változásokkal járó kockázatokat és kijelentik, hogy az IA: "a változással kapcsolatos sok kockázat értékelése, beleértve az erőforrásokra, erőfeszítésekre és ütemtervre gyakorolt hatások becslését is". A tervezési részletek és a módosításokkal kapcsolatos kockázatok mind kritikusak az IA végrehajtásához a változáskezelési folyamatokon belül. Ebben a kontextusban néha említik egy technikai szakkifejezést is, a függőségi bonyodalom.
A hatáselemzési technikák típusai
szerkesztésAz IA technikák három típusba sorolhatók:[5]
- Nyom
- Függőség
- Tapasztalati
Bohner és Arnold[6] az IA két osztályát azonosítják: nyomkövethetőségi és függőségi IA. A nyomkövethetőségi IA esetében a követelmények, specifikációk, tervezési elemek és tesztek közötti kapcsolatokat rögzítik, és ezeket a kapcsolatokat elemzik annak meghatározása érdekében, hogy egy kezdeményező változás milyen terjedelmű.[7] A függőségi IA során az alkatrészek, változók, logika, modulok stb. közötti kapcsolatokat értékelik annak érdekében, hogy megállapítsák egy kezdeményező változás következményeit. A függőségi IA részletesebb szinten történik, mint a nyomkövethetőségi IA. A függőségi IA részletesebb szinten történik, mint a nyomkövethetőségi IA.. A szoftvertervezésen belül statikus és dinamikus algoritmusok futtathatók a kódon, hogy végrehajtsák a függőségi IA-t.[8][9] A statikus módszerek a program struktúrájára összpontosítanak, míg a dinamikus algoritmusok információkat gyűjtenek a program viselkedéséről futási időben.
Az irodalom és a mérnöki gyakorlat is javasol egy harmadik típusú IA-t, azaz a tapasztalati IA-t, mivel a változások hatását gyakran a szakértői tervezési tudás alapján határozzák meg. Felülvizsgálati értekezleti protokollok,[10] az informális csapatmegbeszélések és az egyéni mérnöki ítélőképesség[11] mind használhatók annak meghatározására, hogy milyen következményekkel jár egy módosítás.
Csomagkezelés és függőségi IA
szerkesztésA szoftvert gyakran csomagokban szállítják, amelyek függőségeket tartalmaznak más szoftvercsomagokra, amelyek szükségesek a telepített szoftver futtatásához. Ezeknek a függőségeknek a visszafelé követése kényelmes módja annak, hogy azonosítsuk egy szoftvercsomag tartalmának megváltoztatásának hatását. Példák olyan szoftverekre, amelyek segítenek ebben:
Forráskód és függőségi IA
szerkesztésA metaadatok segítségével meg lehet érteni a függőségeket statikus elemzés útján. Az ilyen függőségek megjelenítését támogató eszközök közé tartoznak:
- Integrated development environment
- FindBugs
- JRipples
- AppDyynamics
- CodeLogic
- Visual Expert
Vannak olyan eszközök is, amelyek teljes szövegű keresést alkalmaznak különböző tárolókban tárolt forráskódokon. Ha a forráskód webböngészőből elérhető, akkor a klasszikus keresőmotorok használhatók. Ha a forrás csak a futásidejű környezetben érhető el, akkor bonyolultabbá válik, és szakosodott eszközök lehetnek segítségünkre.[13]
Követelmények és nyomon követhetőség a forráskódban
szerkesztésA legújabb eszközök gyakran stabil linkeket használnak a függőségek nyomon követésére. Ez minden szinten elvégezhető, köztük specifikáció, vázlatterv, hibák, és commitok. Ennek ellenére, a keresőoptimalizálásból ismert visszalépések ellenőrzésének használata nem elterjedt. Kutatások folynak ezen a területen is, csak hogy néhány példát említsünk: használati eset térképek.[14]
Ezen a területen a kereskedelmi eszközök közé tartozik a Rational DOORS
Hivatkozások
szerkesztés- ↑ Change Impact Analysis - Introduction (angol nyelven). ktern.com, 2021. december 29. [2022. január 27-i dátummal az eredetiből archiválva]. (Hozzáférés: 2022. január 27.)
- ↑ Change Impact Analysis | SMS Tools (angol nyelven). www.aviationsafetyplatform.com. (Hozzáférés: 2022. január 27.)
- ↑ Bohner and Arnold, 1996, pg.3
- ↑ Pfleeger and Atlee, 2006, pg.526
- ↑ Kilpinen, 2008
- ↑ Bohner and Arnold, 1996
- ↑ Eisner, 2002, pg.236-237
- ↑ Rajlich, 2000
- ↑ Ren et al., 2005
- ↑ Endres and Rombach, 2003, pg.17
- ↑ Ambler, 2002, pg. 244
- ↑ whatrequires. www.pixelbeat.org . [2006. április 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2022. január 27.)
- ↑ ohloh, discover, track, and compare open source.. [2011. január 12-i dátummal az eredetiből archiválva]. (Hozzáférés: 2022. január 27.)
- ↑ Change Impact Analysis for Requirement Evolution using Use Case Maps Archiválva 2016. március 5-i dátummal a Wayback Machine-ben., Jameleddine Hassine, Juergen Rilling, Jacqueline Hewitt, Department of Computer Science, Concordia University, 2005.
Fordítás
szerkesztésEz a szócikk részben vagy egészben a Change impact analysis 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.
További irodalom
szerkesztés- Ambler, S. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. New York, New York, USA, John Wiley & Sons.
- Bohner, S.A. and R.S. Arnold, Eds. (1996). Software Change Impact Analysis. Los Alamitos, California, USA, IEEE Computer Society Press.
- Eisner, H. (2002). Essentials of Project and Systems Engineering Management. New York, New York, USA, John Wiley & Sons.
- Endres, A. and D. Rombach (2003). A Handbook of Software and Systems Engineering: Empirical Observations, Laws and Theories. New York, New York, USA, Addison-Wesley.
- Kilpinen, M.S. (2008). The Emergence of Change at the Systems Engineering and Software Design Interface: An Investigation of Impact Analysis. PhD Thesis. University of Cambridge. Cambridge, UK.
- Pfleeger, S.L. and J.M. Atlee (2006). Software Engineering: Theory and Practice. Upper Saddle River, New Jersey, USA, Prentice Hall.
- Rajlich, V. (2000). "A Model and a Tool for Change Propagation in Software." ACM SIGSOFT Software Engineering Notes 25(1):72.
- Ren, X., F. Shah, et al. (2005). Chianti: A Tool for Change Impact Analysis of Java Programs. International Conference on Software Engineering (ICSE 2005), St Louis, Missouri, USA.