Bánsághi Anna Bánsághi Anna 1 of 54

Átírás

1 SZOFTVERTECHNOLÓGIA Bánsághi Anna 2. ELŐADÁS - KÖVETELMÉNY MENEDZSMENT Bánsághi Anna 1 of 54

2 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK V. RENDSZERTERVEZÉS VI. VALIDÁCIÓ, VERIFIKÁCIÓ VII. MINŐSÉGBIZTOSÍTÁS VIII. TESZTELÉS Bánsághi Anna 2 of 54

3 II. KÖVETELMÉNY MENEDZSMENT 1. Funkcionális és nemfunkcionális követelmények 2. Követelményspecifikáció dokumentumai 3. Követelménytervezési folyamat Követelmények felderítése Követelmények specifikálása Követelmények validálása 4. Követelmények kezelése Bánsághi Anna 3 of 54

4 SZOFTVERKÖVETELMÉNYEK a rendszer által nyújtott szolgáltatások és megszorítások kitalálásának, elemzésének, dokumentálásának és ellenőrzésének folyamata a követelményeket különböző absztrakciós szinteken lehet megadni, kezdve a természetes nyelvi leírásoktól egészen a részletes, formális definíciókig a követelményeket a különböző olvasók (megrendelő, felhasználó, üzleti elemző, rendszertervező, fejlesztő, tesztelő) eltérő módon használják, más és más jellegű információközlésre van szükség Bánsághi Anna 4 of 54

5 KÖVETELMÉNY SZINTEK felhasználói követelmények a rendszer végfelhasználói, ügyfélmenedzserek számára készített természetes nyelvi, diagramokkal támogatott leírások a rendszer külső viselkedését érdemes megadni, minél egyszerűbb és világosabb kifejezésekkel rendszerkövetelmények rendszertervezők, szoftverfejlesztők számára készített részletes, pontos, formális specifikációk, rendszermodellek a felhasználói követelmények kibővített változatai, továbbra is kerülve a tervezés és a megvalósítás mikéntjét és hogyanját a két szinten megfogalmazott követelmények között egyértelmű megfeleltetés létezik, a rendszerkövetelmények kiterjesztik, részletezik a felhasználói követelményeket Bánsághi Anna 5 of 54

6 1. FUNKCIONÁLIS ÉS NEM FUNKCIONÁLIS KÖVETELMÉNYEK funkcionális a rendszer által nyújtott szolgáltatások, funkciók nemfunkcionális a szolgáltatásokra és a funkciókra tett megszorítások (teljesítménybeli, időbeli, szabvány) a két típus nem független egymástól, az egyik jelenléte generálhat más típusú követelményt vagy megszorítást egy felhasználói biztonságra vonatkozó nemfunkcionális követelmény maga után vonhatja egy jogosultságkezelő alrendszer beépítésének szükségességét, ami a funkcionális követelmények között fog megjelenni Bánsághi Anna 6 of 54

7 KÖVETELMÉNY SZINTEK ÉS FAJTÁK MÁTRIXA Bánsághi Anna 7 of 54

8 FUNKCIONÁLIS KÖVETELMÉNYEK leírják, hogyan kellene működnie a rendszernek felhasználói szinten absztrakt kívánságok rendszerszinten ki vannak fejtve a bemenetek, kimenetek, kivételek a fejlesztési folyamat későbbi fázisaiban bekövetkező hibák a funkcionális követelményekben lévő pontatlanságokból, ellentmondásokból, többértelműségekből erednek elvben az a cél, hogy a funkcionális követelmények teljesek és ellentmondásmentesek legyenek, a gyakorlatban azonban a megrendelői kívánságok idővel alakulnak, változnak, illetve összetett rendszerek esetén könnyű tévedni vagy kifelejteni Bánsághi Anna 8 of 54

9 NEMFUNKCIONÁLIS KÖVETELMÉNYEK leírják, milyen tulajdonságokkal kellene rendelkeznie a rendszernek (teljesítmény, megbízhatóság, erőforrás megszorítások, szabványoknak való megfelelés) nemcsak a fejlesztendő rendszerre vonatkoznak, hanem felvethetik jogi, adatvédelmi, szervezeti szabályzatoknak való megfelelést, vagy más rendszerekkel való együttműködés igényét is ezen követelmények gyakran kritikusabbak, mint a funkcionális követelmények, mert egy nemfunkcionális követelménynek való megfelelés a rendszerarchitektúrára, a szoftverminőségre kihat szabványok, választott fejlesztési folyamatmodell egy nemfunkcionális követelmény új funkcionális követelményeket generálhat jogosultsági rendszer Bánsághi Anna 9 of 54

10 NEMFUNKCIONÁLIS KÖVETELMÉNYEK TÍPUSAI termékkövetelmények meghatározzák a termék viselkedését (használhatóság, hatékonyság, megbízhatóság, hordozhatóság) szervezeti követelmények a megrendelő és a fejlesztő szervezeti szabályzataiból fakadnak (telepítési, implementációs, szabvány) külső követelmények a rendszeren és annak fejlesztési folyamatán kívül esnek (együttműködési, etikai, jogi, adatvédelmi, biztonsági) Bánsághi Anna 10 of 54

11 NEMFUNKCIONÁLIS KÖVETELMÉNYEK MEGADÁSA probléma, hogy nehéz verifikálni őket, mert általános célokként fogalmazzák meg őket, pl. gyors válaszidő Mit jelent, hogy gyors? a mérhető követelményeket érdemes mennyiségileg, objektíven tesztelhető metrika segítségével kifejezni a gyakorlatban azonban nehéz az elképzeléseket mennyiségi követelményekre váltani, mert a megrendelők nem tudják igényeiket íly módon kifejezni ha mégis vannak mérhető követelmények, azok verifikációs költsége igen magas lehet a követelmények ütköznek egymással gyors műveletek, viszont kevés memóriahasználat Bánsághi Anna 11 of 54

12 sebesség méret NEMFUNKCIONÁLIS KÖVETELMÉNYEK METRIKÁI tranzakciók/mp, felhasználói esemény válaszideje kódméretek, memóriaméretek, skálázhatóság használhatóság képzési idő, különféle help-ek megbízhatóság hibák bekövetkezési aránya, hibák átlagos bekövetkezési ideje, rendelkezésre nem-állás valószínűsége robusztusság leállás utáni újraindítási idő, hibát okozó események aránya, hiba okozta adatmeghibásodás valószínűsége hordozhatóság célrendszerek száma, célrendszer függő és független utasítások aránya Bánsághi Anna 12 of 54

13 2. KÖVETELMÉNYSPECIFIKÁCIÓ DOKUMENTUMAI a követelményespecifikáció szó két jelentéssel bír: 1. az a folyamat, amely során mind a felhasználói, mind a rendszerkövetelmények, rendszermodellek definiálásra kerülnek 2. a folyamat során előálló dokumentumok Bánsághi Anna 13 of 54

14 KÖVETELMÉNYSPECIFIKÁCIÓ DOKUMENTUMAI hivatalos leírása annak, amit meg kell valósítani tartalmazza a felhasználói és a rendszerkövetelményeket egyaránt, ha szükséges több dokumentumba szervezve mivel a dokumentum olvasói igen változatosak, ezért kompromisszumot kell képezni a következők között: megrendelők tákékoztatása fejlesztőknek, tesztelőknek szóló tervek továbbfejlesztési lehetőségek Bánsághi Anna 14 of 54

15 A SPECIFIKÁCIÓBAN HASZNÁLHATÓ NYELVEK természetes nyelv jól definiált szakterületi fogalmakkal, világos mondatszerkesztéssel operál struktúrált természetes nyelv sablonokat használ szabványos űrlapokat, tervező nyelv programozási nyelvre hasonlít, a rendszer működési modelljeinek leírására grafikus jelölések BPMN folyamatmodellező, az UML használati esetei, aktivációs és szekvenciadiagramjai matematikai specifikációk véges állapotú automaták Bánsághi Anna 15 of 54

16 KÖVETELMÉNYDOKUMENTUMOK SZABVÁNYAI számos szabvány és ajánlás létezik arra, hogy mit és milyen szerkezetben tartalmazzon a dokumentum a szoftverfejlesztésben használt folyamatmodell nagy mértékben befolyásolja, hogy milyen típusú, milyen részletezettségű dokumentumokra van szükség külső vállalkozó alkalmazása vagy nagy rendszerek évekig tartó evolúciója esetén lényeges, hogy legyen egy - az összes fél által elfogadott és aláírt - dokumentum gyorsan változó követelmények vagy pár hónapos projektek esetén hiábavaló a dokumentumírásra pazarolt energia, inkább pár napos vagy hetes léptékű egységekben érdemes tervezni Bánsághi Anna 16 of 54

17 NAGY RENDSZEREK DOKUMENTUMAI érdemes a következőket megfontolni, és a szükségeseket alkalmazni előszó, bevezetés, szójegyzék felhasználói követelmények definíciói a rendszer felépítése, rendszer követelmények definíciói és specifikációi, rendszermodellek rendszerevolúció függelékek, tárgymutató Bánsághi Anna 17 of 54

18 AGILIS FEJLESZTÉS DOKUMENTUMAI folyamatosan karbantartott product backlog, mely a fejlesztendő funkciók (user story-k) prioritásos listája azonosító egy user story felépítése megnevezés Mint adott típusú felhasználónak szükségem van a funkcióra azon okból, hogy magyarázat prioritás típus minél fontosabb, annál nagyobb szám új / továbbfejlesztés / hibajavítás sprint azonosítója becsült ráfordítás leírás ha már elkészült általában időbeni szabad szöveges információ Bánsághi Anna 18 of 54

19 3. KÖVETELMÉNYTERVEZÉSI FOLYA MAT a folyamat célja a követelményekhez kapcsolódó dokumentumok létrehozása és karbantartása három tevékenység sorozata, melyek iteratívan ismétlődnek követelmények feltárása követelmények specifikálása követelmények validálása a folyamat tevékenységei, a ráfordítások és a keletkező dokumentumok függnek a választott fejlesztési folyamatmodelltől, a fejlesztendő rendszertől Bánsághi Anna 19 of 54

20 KÖVETELMÉNYTERVEZÉS FOLYAMATA az első iterációban a magasszintű üzleti, nemfunkcionális és felhasználói követelmények megértése történik, majd a következő iterációkban finomodnak a rendszerkövetelmények és modellek specifikáció Bánsághi Anna 20 of 54

21 MEGVALÓSÍTHATÓSÁGI TANULMÁNYOK az üzleti követelmények kezdeti vázlata, hogyan illeszkedne és támogatná a tervezett rendszer a meglévő üzleti folyamatokat támogatja-e rendszer az üzleti célokat, milyen üzleti értékkel bírna, ha adott technológiával és költséggel elkészülne a válaszokat a leendő felhasználók, üzemeltetők körében folytatott interjúk adják meg, illetve a piacon lévő hasonló rendszerekkel való összehasonlítások a tanulmány javaslatot is tartalmaz, hogy érdemes-e folytatni a munkát kockázatelemzés és -kezelési javaslat is tarthozhat hozzá Bánsághi Anna 21 of 54

22 KOCKÁZATI KATEGÓRIÁK KOCKÁZATELEMZÉS üzleti kockázat szervezeti szintű kockázat, pl. a konkurens egy hasonló szoftverterméket vezet be projektkockázat folyamat szintű kockázat, kihatással lehet a projekt ütemezésére, az erőforrásokra, pl. csapattagokkal kapcsolatos, az erőforrások becsléséből vagy a megrendelő követelményeinek változásaiból adódó kockázatok termékkockázat a fejlesztett szoftver minőségére vagy teljesítményére gyakorol hatást, pl. a használt technológiákból vagy eszközökból adódó kockázatok Bánsághi Anna 22 of 54

23 KOCKÁZATKEZELÉS FOLYAMATA kockázat azonosítása a fenti kategóriák és alkategóriák alapján a kockázatok azonosítása kockázat elemzése a beazonosított kockázatok bekövetkezési valószínűségének (kicsi, közepes, nagy) és hatásának (nem jelentős, mérsékelt, súlyos) becslése kockázat tervezése a kulcsfontosságú kockázatok kezelési stratégiájának meghatározása kockázat figyelése a bekövetkezési valószínűség és a hatás rendszeres újraértékelése, és ha szükséges, a kezelési stratégia módosítása Bánsághi Anna 23 of 54

24 KOCKÁZATI MÁTRIX a beazonosított kockázatok jelölése a mátrixban Bánsághi Anna 24 of 54

25 KOCKÁZATKEZELÉSI STRATÉGIÁK elkerülés kis bekövetkezési valószínűségű, de súlyos hatású kockázatok esetén érdemes a megelőzésen fáradozni, vagy a bekövetkezési valószínűséget még jobban csökkenteni minimalizálás nagy bekövetkezési valószínűségű, de jelentéktelen hatású kockázatok esetén érdemes inkább a bekövetkező károkat csökkenteni vészhelyzeti terv ha mind a két tényező nagy, akkor érdemes alternatív forgatókönyvekkel felkészülni a kritikus helyzetekre Bánsághi Anna 25 of 54

26 KOCKÁZATI MÁTRIX a kezelés módjának jelölése a mátrixban Bánsághi Anna 26 of 54

27 KÖVETELMÉNYEK FELTÁRÁSA Bánsághi Anna 27 of 54

28 KÖVETELMÉNYEK FELTÁRÁSA a megrendelők és az üzleti elemzők együtt dolgoznak, ekkor történik a szakterületi fogalomrendszer tisztázása is Bánsághi Anna 28 of 54

29 A FELTÁRÁS FOLYAMATA felderítés végfelhasználókkal, szakterületi szakértőkkel, kereskedelmi képviselőkkel való együttműködésből derül ki, mit is szeretnének osztályozás a kapcsolódó és az összefüggő követelmények csoportosítása, jövőbeni részrendszerek megalapozása priorizálás a fontossági sorrend minden esetben szükséges, különösen akkor, amikor a rendszernek különböző érdekű felhasználói vannak dokumentálás informális vagy formális dokumentáció Bánsághi Anna 29 of 54

30 A FELTÁRÁS ESZKÖZEI interjúk kérdések a fejlesztendő és a már meglévő rendszerekről, a jelenlegi és a jövőbeni üzleti folyamatokról forgatókönyvek a valós életbeli példák alapján könnyebb elképzelni, részletezni, illetve kritizálni a rendszert használati esetek forgatókönyv-alapú diagramok, az UML szabvány egyik diagramtípusa, a rendszer funkcióit, az aktorokat és a közöttük lévő kommunikációt ábrázolják etnográfia megfigyelésen alapuló technika, a fejlesztendő rendszert használó társadalmi, szervezeti és munkakörnyezet felderítése Bánsághi Anna 30 of 54

31 FAJTÁK zárt előre definiált kérdéshalmaz INTERJÚK nyílt nincs megadott kérdéssorozat, hanem minél szélesebb körű problémákat vizsgálnak át HÁTRÁNY minden képviselő a saját szakterületi terminológiáját használja, ezért az is célja az interjúnak, hogy a követelménytervező megismerje a különféle terminológiákat bizonyos szakterületi ismeretek olyan evidensek a képviselők számára, hogy talán nem is említik meg, így azok nem kerülnek be a követelmények közé Bánsághi Anna 31 of 54

32 HATÉKONY INTERJÚK kerülik az előítéleteket, hatalmi vagy befolyási viszonyoktól mentesek, bármilyen meglepő ötlettel álljon is elő egy képviselő, azt megfontolás alá veszik a követelménytervezők a rendszer egy prototípusával készülnek, így a végfelhasználóra nem hárul akkora felelősség, a beszélgetés egy konkrét dologról történik, könnyebb kapcsolódni Bánsághi Anna 32 of 54

33 FORGATÓKÖNYVEK szerves részei az agilis módszertanoknak interakció-sorozatok leírásai informális leírás a követelménytervezők és a felhasználók együtt dolgoznak a forgatókönyvek azonosításán és a részletek megragadásán, készíthetők diagramok, képernyőtervek formális leírás struktúráltabb, űrlapokon, kártyákon megírt esemény-sorozatok vagy használati esetek Bánsághi Anna 33 of 54

34 FORGATÓKÖNYVEK ELEMEI induló feltétel mit vár a rendszer, és mit vár a felhasználó a forgatókönyv kezdetén normális működés ami elromolhat egyéb tevékenységek mehetnek végbe az interakciók normális menetének leírása és azt hogyan kezeli a rendszer amelyek ugyanebben az időben rendszerállapot befejezéskor az események lezajlása után milyen állapotban marad a rendszer Bánsághi Anna 34 of 54

35 az UML jelölés egyik diagramja HASZNÁLATI ESETEK üzleti vagy rendszer szempontú, magasszintű áttekintése a rendszer funkcióinak, az aktorok és a funkciók közötti interakcióknak a rendszerrel szemben támasztott követelmények lényegét ragadják meg, nem vesznek el a részletekben a rendszer fejlesztésében résztvevő összes szereplő számára hasznosak, mert megadják a végső célt Bánsághi Anna 35 of 54

36 A DIAGRAM ÉPÍTŐKÖVEI aktor a rendszerrel interakcióba lépő személy, szervezet vagy külső rendszer használati eset az aktor számára értéket előállító funkció (valamely művelet-együttes), melynek végrehajtása a rendszer és egy külső aktor közötti üzenetváltást kíván kapcsolat aktorok, használati esetek közötti kapcsolatok (társítás, azaz asszociáció, öröklődés, függőség) rendszer határoló keret a kereten belüli használati esetek a rendszer részei, amelyek azon kívül vannak, azok nem Bánsághi Anna 36 of 54

37 társítás (asszociáció) közötti kapcsolat KAPCSOLAT FAJTÁK aktorok és használati esetek általánosítás aktorok közötti vagy használati esetek közötti öröklődési kapcsolat tartalmazás tekinthetjük úgy. mint egy alprogramhívást, felbontjuk a használati esetet alfunkciókra (al-használati esetekre) kiterjesztés tekinthetjük úgy, mint egy hardver megszakítást, valamilyen feltételtől függően végrehajtott funkció, nem tudjuk, hogy be fog-e következni, és azt sem, hogy mikor Bánsághi Anna 37 of 54

38 HASZNÁLATI ESET TERVEZÉSE 1. beazonosítjuk az összes lehetséges aktort megadjuk az aktorok és a használati esetek közötti társításokat: ha egy aktor részt vesz egy használati eset inicializálásban, információt szolgáltat vagy kap attól, akkor van közöttük kapcsolat észrevesszük az aktorok közötti hasonlóságokat, és a használati esetek közötti hasonlóságokat (származtatás) 4. megadjuk az aktorok közötti kapcsolatokat (általánosítás) 5. megadjuk a használati esetek közötti kapcsolatokat (általánosítás, függőség) Bánsághi Anna 38 of 54

39 ÜZLETI HASZNÁLATI ESET Bánsághi Anna 39 of 54

40 RENDSZER HASZNÁLATI ESET Bánsághi Anna 40 of 54

41 ETNOGRÁFIA az elemző elmélyed a munkakörnyezetben, ahol a rendszert majd használni fogják, megfigyeli a munkát, a munkafolyamatokat, a résztvevők aktuális tevékenységeit felderíti az implicit rendszerkövetelményeket, melyek az embereket érintő tényleges folyamatokat érintik felfedezi a nem nyilvánvaló társadalmi, szervezeti csoportdinamikát, a formális és az informális szerepek közötti különbségeket felfedi a feltételezett és a tényleges munka közötti különbségeket Bánsághi Anna 41 of 54

42 HATÉKONY ETNOGRÁFIA az emberek tényleges munkavégzési módja a résztvevők elbeszéléséből általában nem derül ki, hogy a valóságban hogyan zajlanak a munkafolyamatok, hogyan szeretnék azt optimalizálni, hol lehetne automatizálni együttműködés a különböző szervezeti szinteken, különböző fogalmi rendszerrel rendelkező résztvevők közötti kapcsolatok, a bürokrácia vagy a káosz mértéke más emberek tevékenységeinek számon tartása fel kell deríteni és közös megoldást kell találni a tisztázatlan felelősségi és homályos feladatköröket illetően Bánsághi Anna 42 of 54

43 KÖVETELMÉNYEK SPECIFIKÁLÁSA Bánsághi Anna 43 of 54

44 KÖVETELMÉNYEK SPECIFIKÁLÁSA a rendszer modellezése különböző absztrakciós szinteken történik a különféle olvasók számára (üzleti oldal, végfelhasználók, tervezők, fejlesztők, tesztelők) általában grafikus reprezentációk, melyek leírják: az üzleti folyamatokat a megoldandó problémát a kifejlesztendő rendszert Bánsághi Anna 44 of 54

45 külső (környezeti) modellezük A RENDSZER SZEMSZÖGEI a rendszer kontextusát vagy környezetét interakciós a rendszer és környezete vagy a rendszer komponensei közötti együttműködés modellezése szerkezeti a rendszer statikus tulajdonságait, felépítését, struktúráját és az előforduló adatszerkezeteket modellezük viselkedési a rendszer dinamikus tulajdonságait, a kiváltott és bekövetkező eseményeket, és az azokra való reakciókat modellezük Bánsághi Anna 45 of 54

46 KÖVETELMÉNYEK VALIDÁLÁSA Bánsághi Anna 46 of 54

47 KÖVETELMÉNYEK VALIDÁLÁSA a rendszert leíró követelmények valóban a megrendelő akaratát fejezik ki? cél, hogy megtaláljuk a követelményekkel kapcsolatos problémákat egy szekvenciális folyamatban ezek az ellenőrzések utólag történnek meg, míg egy agilis folyamatban interaktívan, azonnal visszacsatolva Bánsághi Anna 47 of 54

48 ELLENŐRZÉSEK validitás a rendszer profilját alkotó funkciók maguk után vonhatnak számos segédfunkciót, melyekkel a megrendelő kezdetben nem számolt ellentmondás általában ellentmondóak a követelmények, ekkor tudnunk kell, hogy milyen lemondások árán történt a kompromisszum teljesség se többet, se kevesebbet ne tudjon a rendszer, mint amit a követelmények és a megszorítások leírnak megvalósíthatóság realitások technológiai, költségvetési, ütemezési verifikálhatóság úgy kell megírni a követelményhalmazt, hogy azzal bizonyítani lehessen, hogy a rendszer teljesíti az összes követelményt Bánsághi Anna 48 of 54

49 VALIDÁLÁSI TECHNIKÁK felülvizsgálat a követelményhalmaz rendszeres ellenőriztetése a megrendelővel, az elemezőkkel, és a problémák beazonosítása prototípus készítés a rendszer egy végrehajtható modelljét ellenőrzi a megrendelő és a végfelhasználók, mely bemutatja a fő koncepciókat, a tervezési lehetőségeket teszteset készítés ha a tesztet nehéz vagy lehetetlen megtervezni, az általában azt jelzi, hogy a követelményekben probléma van, tanácsos azokat újragondolni Bánsághi Anna 49 of 54

50 4. KÖVETELMÉNYKEZELÉS a rendszerek javulnak, mert a működtetés és a használat során felmerülő hibák karbantartásra kerülnek a rendszerek változnak, mert új megrendelői, végfelhasználói igények jelennek meg a rendszerek fejlődnek, mert a használt módszertanok, technológiák, technikák, szabványok javulnak, fejlődnek a rendszerek bővülnek, mert más rendszerekkel integrálódhatnak, vagy szolgáltatásokat nyújthatnak / vehetnek igénybe Bánsághi Anna 50 of 54

51 KÖVETELMÉNYKEZELÉS TERVEZÉSE követelmények azonosítása minden követelményt egyértelműen azonosítani kell, hogy hivatkozni lehessen rá, illetve a nyomonkövethetőség érdekében változtatáskezelési folyamat költségét becslő eljárás a változtatások hatását és nyomon követhetőség elemei a követelmények közötti, a követelmények és a rendszerterv közötti, illetve a követelmények és az implementáció közötti kapcsolatok követése eszköz támogatás táblázatkezelőkig a bonyolult rendszerektől kezdve az egyszerű Bánsághi Anna 51 of 54

52 NYOMONKÖVETHETŐSÉG források és követelmények között a követelményt indítványozó résztvevő hozzárendelése, és a követelmény szükségességének magyarázata követelmények között függőségi kapcsolatok, egy változtatás mely más követelményekre lesz hatással követelmények és tervek között a rendszertervek, a komponensek, a megvalósított modulok közötti kapcsolatok, a változtatás hogyan fut végig az implementációig Bánsághi Anna 52 of 54

53 VÁLTOZTATÁSKEZELÉS ajánlott minden változtatást azonos módon, egy formális folyamatban kezelni előnye, hogy minden változtatási szándék kezelése konzisztens és ellenőrzött módon történik hátránya, hogy ha sürgősen kell javítani, akkor előbb történik az implementáció, majd utána kell igazítani a követelmény dokumentumokat Bánsághi Anna 53 of 54

54 VÁLTOZTATÁSKEZELÉS FŐ SZAKASZAI problémaelemzés a változtatási szándék és indítvány vizsgálata, validálása, finomítása változtatáselemzés és költségfelmérés a tervezett változtatás hatásának becslése a nyomon követhetőségi információra támaszkodva változtatás implementálása a változtatás végigvezetése kezdve a követelményspecifikációval, a rendszerterveken át, befejezve az implementációval, teszteléssel Bánsághi Anna 54 of 54