A Dynamic Systems Development Method (DSDM) elsősorban a Rapid Application Development (RAD) koncepcióján alapuló szoftverfejlesztési technika . A DSDM egy iteratív és inkrementális megközelítés, amely hangsúlyozza a felhasználó/fogyasztó folyamatos részvételét a folyamatban.
A módszer célja, hogy a kész projektet határidőre és a költségvetésen belül teljesítse, ugyanakkor kezelje a fejlesztés során a projektigényekben bekövetkezett változásokat. A DSDM az agilis szoftverfejlesztések és nem információs technológiai fejlesztések családjának része.
A DSDM legújabb verziója a DSDM Atern. Az Atern név a sarkvidéki csér rövidítése. A sarki csér olyan madár, amely nagy távolságokat is megtehet. A módszer számos aspektusát szimbolizálja, például a prioritások meghatározását vagy az együttműködést, amelyek a munkafolyamat futtatásának természetes módja.
A DSDM korábbi (2003 májusában kiadott) változata, amely még mindig érvényes és széles körben használt, a DSDM 4.2, amely a DSDM 4 kissé kibővített változata. A kibővített verzió útmutatást tartalmaz a DSDM Extreme Programming programozással történő használatához.
2007-ben a DSDM Konzorcium által felállított csapat a módszer lényegét kutatva úgy döntött, hogy az alapvető mechanizmusok és struktúra jól meg van írva, de a módszer terminológiája és figyelme teljes mértékben az információs technológia területére összpontosult. Ezért ezeket javítani kell, hogy megfeleljenek az új évezred projektjeinek igényeinek (a módszer egy része 1995 óta nem változott). Az új verzió 2007. április 24-én jelent meg a londoni Cafe Royale-ban.
A gyors alkalmazásfejlesztés koncepciójának kiterjesztéseként a DSDM a szűk határidőkkel és költségvetéssel jellemezhető információs rendszer projektekre összpontosít. A DSDM az információs rendszer projektek tipikus hibáira utaló jeleket tartalmaz, mint például a költségvetés túllépése, késedelmes szállítási (végrehajtási) határidők, a felhasználók és a felsővezetők nem megfelelő bevonása a projekt munkájába. A DSDM a következőkből áll:
Bizonyos feltételek mellett más módszertanok részei is beépíthetők a DSDM-be, mint például a Rational Unified Process (RUP), az Extreme Programming, a PRINCE2. Egy másik, a DSDM-hez hasonló rugalmas módszer folyamatában és koncepciójában a Scrum .
A DSDM módszert az 1990-es években az Egyesült Királyságban fejlesztette ki a DSDM Consortium. A DSDM Konzorcium szoftverfejlesztők és szakértők szövetsége, amelyet azzal a céllal hoztak létre, hogy a szövetség tagjainak legjobb gyakorlatait ötvözve "egy független RAD keretrendszer közös fejlesztése és népszerűsítése". A DSDM Consortium független fejlesztők non-profit szervezete, akik a DSDM keretrendszer tulajdonosai és üzemeltetői. A keretrendszer első változata 1995 januárjában készült el, és 1995 februárjában jelent meg. 2006 júliusában megjelent a DSDM 4.2 nyílt forráskódú verziója, amelyet az egyének megtekinthetnek és használhatnak. Azonban bárki, aki DSDM-et terjeszt, tagjának kell lennie ennek a nonprofit konzorciumnak.
Az 1990-es évek elején egy új kifejezés kezdett elterjedni az információs technológiai iparban - Rapid Application Development (RAD). Az alkalmazásszoftverek felhasználói felületei a régi zöld képernyőkről a ma is használatos grafikus felhasználói felületekké fejlődtek. Új alkalmazásépítő eszközök kezdtek megjelenni a piacon, mint például a PowerBuilder . Megkönnyítették a fejlesztők számára, hogy megosszák tervezett fejlesztéseiket az ügyfelekkel - megjelentek a prototípusok, és megkezdődött a klasszikus, szekvenciális (lépcsőzetes) fejlesztési módszerek lerombolása.
Az új RAD mozgalom azonban nagyon strukturálatlan volt: a módszerről nem volt elfogadott leírás, és sok szervezet saját leírást és megközelítést készített hozzá. Sok nagyvállalat érdeklődött a módszer által kínált kilátások iránt, de attól is tartottak, hogy a végeredményben ne csökkenjen termékeik minőségi szintje.
A DSDM Consortium 1994-ben alakult, amikor egy csoport találkozott a Butler Group által szervezett londoni rendezvényen. Mindenki, aki eljött erre az eseményre, olyan nagy szervezetekben dolgozott, mint a British Airways, az American Express, az Oracle és a Logica (az olyan cégeket, mint a Data Sciences és az Allied Domecq, azóta más szervezetek vették át).
Ezen az ülésen az a döntés született, hogy Jennifer Stapleton, akkor a Logica munkatársa egy átfogó, felhasználó-központú módszert fog kidolgozni, jó minőség-ellenőrzéssel az iteratív és inkrementális fejlesztéshez. Az így létrejött architektúra úgy lett megtervezve, hogy teljes mértékben megfeleljen az ISO 9000 és a PRINCE2 szabványnak. Amikor az architektúra elkészült (egy hónappal a megbeszélés után), a Konzorcium csoportokat alakított ki annak terjesztésére a szoftverfejlesztés minden területén, amely magában foglalta: projektmenedzsment módszerek és eszközök, minőségellenőrzés és tesztelés, fejlesztési módszerek és eszközök. Az építész által vezetett és e csoportok vezetőiből álló kontrollcsoportnak kellett gondoskodnia arról, hogy a módszert úgy értelmezzék, ahogyan eredetileg elgondolták.
Annak ellenére, hogy a Konzorcium számos tagja közvetlen versenytárs volt, szabadon megosztották, hogyan oldják meg a felmerülő problémákat. A gyakorlat azt mutatja, hogy a legjobb eredményt csak teljes munkavégzéssel lehet elérni. A konzorcium bővült - az első évben több szervezetről hatvanra; a módszer leírása egyre teljesebb lett. Az 1-es verziót 1994 decemberében hozták létre, és 1995 februárjában adták ki. Az eredmény egy univerzális módszer, amely magában foglalja az embereket, a folyamatokat és az eszközöket. A tevékenységük jellegében és méretében eltérő szervezetek tapasztalatai alapján alakult.
9 alapelv létezik, amelyek 4 alap- és 5 kiindulópontból állnak.
A DSDM sikeres használatához számos előfeltételnek kell teljesülnie. Először is meg kell szervezni az interakciót a projektcsapat, a jövőbeli felhasználók és a felső vezetés között. Másodszor, lehetővé kell tenni a projektet kisebb részekre bontani, ami lehetővé teszi az iteratív megközelítést.
Két példa azokra a projektekre, amelyekre a DSDM nem megfelelő:
A DSDM keretrendszer három egymást követő szakaszból áll, amelyeket projekt előtti szakasznak, projekt életciklus szakaszának és projekt utáni szakasznak neveznek. A projekt életciklusa a legátgondoltabb és legrészletesebb a többi közül. Öt lépésből áll, amelyek az információs rendszerek fejlesztésének iteratív, inkrementális megközelítését alkotják. Ezt a három fázist és a hozzájuk tartozó lépéseket a következő szakaszok ismertetik részletesebben. Minden szakaszban vagy szakaszban áttekintik a legfontosabb funkciókat, és bemutatják az eredményeket.
1. szakasz – Előprojekt Ebben a szakaszban azonosítják a valószínű projekteket, allokálják a forrásokat és meghatározzák a projektcsapatot. A problémák ebben a szakaszában történő megoldása segít elkerülni a problémákat a projekt későbbi szakaszaiban. 2. szakasz – A projekt életciklusa Az alábbi ábra ezt a szakaszt mutatja. 5 szakaszt mutat be, amelyen egy projektnek át kell mennie ahhoz, hogy információs rendszerré váljon. Az első két szakasz, a megvalósíthatósági tanulmány és a gazdasági megvalósíthatósági tanulmány egymás után halad, és kiegészíti egymást. Ezeknek a szakaszoknak a befejezése után a rendszer iteratív és inkrementális fejlesztése szakaszokban történik: funkcionális modell létrehozása, tervezés és fejlesztés, megvalósítási szakasz. A DSDM iteratív és inkrementális jellegét a következőkben ismertetjük. 3. szakasz – Projekt után Ebben a szakaszban a rendszer hatékony működése biztosított. Ez a projekt karbantartásával, fejlesztésével és a hibák kijavításával érhető el a DSDM elvei szerint. A projektet a DSDM iteratív és inkrementális jellegén alapuló folyamatos fejlesztés támogatja. Ahelyett, hogy egy projektet egy ciklusban fejezne be, gyakran visszatér a korábbi szakaszokhoz vagy mérföldkövekhez a termék javítása érdekében.Az alábbi diagram egy projekt teljes életciklusát mutatja. Ez a diagram a DSDM iteratív fejlesztését írja le. Az alábbiakban bemutatjuk az egyes szakaszok leírását.
| Akció | Alakció | Leírás |
|---|---|---|
| Tanulmány | Megvalósíthatósági tanulmány | Ebben a szakaszban meg kell határozni, hogy a projekt a DSDM hatálya alá tartozik-e. A projekt típusát, a szervezeti és személyi kérdéseket figyelembe véve döntés születik, hogy a DSDM módszert alkalmazzuk-e vagy sem. Így elkészül egy alkalmazhatósági jelentés, egy elfogadható prototípus és egy hozzávetőleges globális projektterv, amely tartalmazza a fejlesztési tervet és a lehetséges kockázatok protokollját. |
| Megvalósíthatósági tanulmány | Ebben a szakaszban a fő gazdasági és technológiai jellemzőket elemezzük. Szakértői értekezletre kerül sor, ahol megvitatják a rendszer legfontosabb szempontjait, és döntés születik a fejlesztési prioritásokról. Ebben a szakaszban elkészül az alapkövetelmények listája, az üzleti hatókör leírása, a rendszerarchitektúra leírása és egy hozzávetőleges prototípus-terv. | |
| Funkcionális modell készítése | Funkcionális prototípus meghatározása | A prototípusnak ebben a szakaszban szereplő funkcióinak meghatározása. Ebben az alszakaszban a gazdasági megvalósíthatóság vizsgálatának szakaszában kapott eredmények alapján funkcionális modellt dolgoznak ki. |
| Tervek egyeztetése | Megállapodás van arról, hogyan és milyen időkeretben kell a prototípus funkcionalitását fejleszteni. | |
| Funkcionális prototípus készítése | Funkcionális prototípus kidolgozása, tervek és funkcionális modell szerint. | |
| Funkcionális prototípus elemzés | A kifejlesztett prototípus állapotának ellenőrzése. Ez a prototípus végfelhasználói tesztelésével és/vagy a dokumentáció átdolgozásával érhető el. Az eredmény egy dokumentum, amely a funkcionális prototípus áttekintését tartalmazza. | |
| Tervezés és fejlesztés | Tervezési prototípus meghatározása | A rendszer funkcionális és nem funkcionális követelményeinek meghatározása. Ezen követelmények alapján meg kell alkotni a megvalósítási stratégiát. Ha létezik egy korábbi iteráció tesztrekordja, akkor ez is felhasználásra kerül a megvalósítási stratégia létrehozásához. |
| Tervek egyeztetése | Megállapodás van arról, hogy a meghatározott követelményeket hogyan és milyen időn belül kell végrehajtani. | |
| Konstruktív prototípus készítése | A felhasználóknak tesztelésre adható rendszer (konstruktív prototípus) létrehozása. | |
| Strukturális prototípus elemzés | Ellenőrizze a tervezett rendszer helyességét. Ez az allépés a tesztelésre és az eredmények áttekintésére vonatkozik. Felhasználói dokumentáció és tesztjelentés készítése. | |
| Végrehajtás | A rendszer jóváhagyása a felhasználótól | A végfelhasználók jóváhagyják a tesztelt rendszer megvalósítását és útmutatást. |
| Felhasználói képzés | A leendő felhasználó betanítása a rendszerrel való munkára. Az alszakasz eredménye egy képzett felhasználókból álló kontingens. | |
| Végrehajtás | A tesztelt rendszer bevezetése a felhasználók körében. | |
| Rendszerpiaci elemzés | A kiadott rendszer piacra gyakorolt hatásának elemzése. A fő kérdés az, hogy megvalósult-e a rendszer kialakításakor kitűzött cél. Ez alapján a projekt a következő szakaszba lép (utóprojekt), vagy visszakerül az előzőhöz felülvizsgálatra. Az elemzés a projektelemzési dokumentumban kerül bemutatásra. |
Ebben a fázisban ellenőrzik a projekt megvalósíthatóságát a DSDM keretében. A DSDM használatának előfeltételeit a következő kérdések megválaszolásával ellenőrizzük: „Megfelel-e ez a projekt a szükséges gazdasági követelményeknek?”, „A projekt alkalmas a DSDM módszer alkalmazására?” és „Melyek a legfontosabb kockázatok ebben a projektben?”. Ebben a szakaszban a legfontosabb módszer a munkacsoportok alkalmazása.
Ennek a szakasznak az eredménye az alkalmazhatóságról szóló jelentés és egy elfogadható prototípus, amely mérlegeli a projekt megvalósíthatóságát, valamint egy hozzávetőleges globális projektterv és a lehetséges kockázatok jegyzőkönyve, amely leírja a projekt legfontosabb kockázatait.
1B szakasz: Megvalósíthatósági tanulmányA megvalósíthatósági tanulmány kiterjeszti és kiegészíti a megvalósíthatósági tanulmány szakaszát. Miután a projektet a DSDM keretében megvalósíthatónak ítélték meg, ebben a szakaszban ellenőrzik az üzleti folyamatokat, bevonják a felhasználói csoportokat, és elemzik igényeiket és kívánságaikat. És ismét a legnépszerűbb módszer ebben a szakaszban a munkacsoportok használata. A munkacsoportok részeként a projekt résztvevői összegyűlnek, hogy megvitassák a tervezett rendszert. Az ezen események után szerzett információkat egy követelménylistában gyűjtjük össze. A lista fontos jellemzője a prioritások elosztása a követelmények között. Ezek a követelmények a Moszkva módszer szerint vannak elosztva. A beérkezett sorrend alapján fejlesztési terv készül, amely útmutató lesz a teljes projekthez.
Ennek a tervnek a létrehozásához a projekt számára egy nagyon fontos technikát használnak - az időkeretet. Ez a módszertan elengedhetetlen a DSDM céljainak eléréséhez - a határidők és a költségvetés betartásához, valamint a termék elvárt minőségének megőrzéséhez. A rendszerarchitektúra egy másik segítség az információs rendszer fejlesztésének kezelésében. Ennek a fázisnak a kimenete egy üzleti hatókör leírása, amely tartalmazza a projekt vállalaton belüli kontextusát, egy rendszerarchitektúra leírás, amely a fejlesztés alatt álló információs rendszer kezdeti globális architektúráját adja meg, valamint egy fejlesztési terv, amely felvázolja a projekt legfontosabb lépéseit. fejlesztési folyamat. Ez a két dokumentum követelménylistán alapul. A lehetséges kockázatok protokollját az ebben a szakaszban nyert adatok egészítik ki.
2. szakasz: Funkcionális modell létrehozásaAz előző lépésben meghatározott követelmények funkcionális modellé alakulnak. Egy működő prototípusból és modellekből áll. A prototípuskészítés kulcsfontosságú projekttechnika ebben a szakaszban, amely lehetővé teszi a felhasználók részvételének megszervezését a projektben. A kifejlesztett prototípust különféle felhasználói csoportok elemzik. A kívánt minőség elérése érdekében minden iterációnál tesztelést végeznek. A tesztelés legfontosabb része ebben a szakaszban kerül bemutatásra. A funkcionális modell létrehozása a következő részszakaszokra osztható:
Ennek a szakasznak a kimenete egy funkcionális modell és egy funkcionális prototípus, amelyek együttesen képviselik az iteráció során kapott funkcionalitást, készen a felhasználói tesztelésre. Ezután a követelmények listája frissül - a már megvalósított elemek eltávolításra kerülnek, és a fennmaradó tételek sorrendje ismét megváltozik. A lehetséges kockázatok protokollja is frissítésre kerül, a funkcionális prototípus elemzése után.
3. szakasz: Tervezés és fejlesztésEnnek az iterációnak a fő célja, hogy az előző szakaszból származó funkcionális komponenseket egyetlen rendszerré egyesítse, amely kielégíti a felhasználók igényeit. Itt figyelembe veszik a nem funkcionális követelményeket is. És ismét ebben a szakaszban zajlik a tesztelés. A tervezés és a fejlesztés a következő részszakaszokra osztható:
A szakasz eredménye egy konstruktív prototípus létrehozása a felhasználói teszteléshez. A tesztelt rendszer a következő szakaszba lép. Ebben a szakaszban a rendszer megjelenése és funkcionalitása általában készen áll. Egy másik eredmény a felhasználói dokumentáció elkészítése.
4. szakasz: MegvalósításA megvalósítás szakaszában a tesztelt rendszert a felhasználói dokumentációval együtt eljuttatják a leendő felhasználókhoz, és kiképezik őket a rendszerrel való együttműködésre. A rendszer elemzése megtörténik, hogy megfelel-e a projekt korai szakaszában meghatározott követelményeknek. A megvalósítás a következő allépésekre osztható:
A szakasz végeredménye: a végfelhasználók általi használatra alkalmas komplett rendszer, képzett felhasználókból álló kontingens és részletes projektelemzési dokumentum.
A funkcionális modell létrehozásának szakaszában a fogalmak közötti kapcsolatokat az alábbi ábra modellje mutatja.
| koncepció | Leírás |
|---|---|
| A lehetséges kockázatok jegyzőkönyve | Az észlelt kockázatok protokollja. Fontos a következő szakaszokhoz, olyan problémákat tartalmaz, amelyek valószínűleg előfordulhatnak. Folyamatosan frissíteni kell. |
| Követelmények listája prioritás szerint | A követelmények listája prioritás szerint rendezve. A disztribúciós folyamat a Moszkva módszerén alapul, amely meghatározza, hogy melyik követelményeket kell először megvalósítani (gazdasági szempontból) |
| A nem funkcionális követelmények listája | A nem funkcionális követelmények listája, amelyekkel a következő lépésben foglalkozni kell. |
| Funkcionális követelmény | Ez a funkció a prioritások szerinti modellépítéshez és prototípus-készítéshez használatos. |
| funkcionális modell | Funkcionális követelmények alapján felépített modell. A következő allépésben a prototípus fejlesztéséhez használják majd fel. Ezt a modellt fogják használni a prototípus-terv elkészítéséhez. |
| prototípus készítés | Egy működő modell (prototípus) gyors felépítésének folyamata a tervek tesztelésére, az ötletek és funkciók illusztrálására, valamint a felhasználói visszajelzések korai összegyűjtésére. |
| Időintervallumok listája | Az egyes munkák végrehajtására vonatkozó időintervallumok listája szükséges ahhoz, hogy illeszkedjen a teljes projekt végrehajtásának ütemtervébe. |
| Prototípuskészítési terv | A prototípus-készítési folyamat terve az ütemezett idősávokban. |
| Működési ütemterv | A fejlesztők által egyeztetett munkák és a munkák időpontja. Funkcionális prototípus megvalósításában használatos. |
| funkcionális prototípus | Egy prototípus, amely lehetővé teszi a rendszer összes funkciójának megtekintését, és azt, hogy a rendszer hogyan fogja ellátni ezeket a funkciókat. |
| Megvalósítási terv | Funkcionális prototípus megvalósításához szükséges munkák előkészítése a munkaterv és a követelménylista szerint. |
| Továbbfejlesztett funkció | Prototípus-funkció, amelyet ebben az iterációban javítottak és teszteltek, mielőtt összevonták volna a prototípus más részeivel. |
| Ízületi funkció | Prototípus-szolgáltatás, amelyet a korábbi iterációk szolgáltatásaival egyesítettek. Az új kombinált funkcionális prototípust a következő fázisban tesztelik. |
| Vizsgálati jelentés | Tesztrekord, amely egy tesztszkriptből, teszteljárásból és teszteredményekből áll. |
| Funkcionális prototípus elemzési dokumentum | Az aktuális verzióra vonatkozó felhasználói megjegyzésekből áll, amelyek a későbbi iterációkhoz szükségesek. Ez a dokumentum a lehetséges kockázatok protokolljának és a követelmények listájának frissítésére szolgál. |
A funkcionális prototípus meghatározásának feladata, hogy meghatározza azt a funkcionalitást, amely egy adott iterációnál jelen lesz a prototípusban. Az elemzés és a programozás befejeződött; prototípusokat állítanak össze; és a belőlük szerzett tapasztalatokat az elemzési modellek fejlesztésére használják fel (és egy frissített követelménylista és a lehetséges kockázatok protokollja is alapul). A megépített prototípusokat nem dobják ki, hanem fokozatosan hozzák a kívánt minőségre, hogy később bekerüljenek a kész rendszerbe. Megállapodott munkatervre van szükség annak meghatározásához, hogy mikor és milyen időkeretben valósítják meg a prototípus-készítést; kiterjeszti a prototípus-készítési ütemtervet és tervet. A tesztelés, amelyet a teljes folyamat során végeznek, szintén nélkülözhetetlen része ennek a szakasznak, és közvetlenül a prototípus elkészítése után bekerül a prototípus elemzési folyamatba. A tesztprotokoll a prototípus elemzésére és elemzési dokumentum létrehozására is szolgál. Az alábbiakban ennek a folyamatnak a diagramja látható.
| Akció | Alakció | Leírás |
|---|---|---|
| Funkcionális prototípus meghatározása | Követelményelemzés | A jelenlegi prototípus követelményeit a korábban (az előző iterációban és/vagy szakaszban) elkészített követelménylista szerint elemezzük. |
| Az aktuális iteráció követelményeinek listája | A prototípusba az aktuális iteráció során implementálandó funkcionális követelmények kiválasztása és a funkcionális követelmények listájának elkészítése. | |
| A nem funkcionális követelmények listája | A rendszer nem funkcionális követelményeinek listájának kialakítása. | |
| Funkcionális modell készítése | A modell és a prototípus kód elemzése és funkcionális modell létrehozása. | |
| Tervek egyeztetése | Az idő meghatározása | A prototípus-készítési munkák elvégzésének lehetséges ütemtervének meghatározása a prototípus-készítési tervnek és stratégiának megfelelően. |
| Készítsen fejlesztési tervet | Hozzon létre egy prototípus-tervezési tervet, amely tartalmazza az összes prototípus-készítési munkát, amelyet ütemezett időrésekben kell elvégezni. | |
| Koordináció | Megállapodott ütemterv arról, hogyan és mennyi időn belül fejeződik be az összes prototípus-készítés. | |
| Funkcionális prototípus készítése | Tanulmány | Követelmények kutatása; a funkcionális modell elemzése és az elemzés alapján megvalósítási terv kidolgozása. Az eredményeket a következő altevékenység során használjuk fel a prototípus elkészítéséhez. |
| Javulás | Funkcionális modell és megvalósítási terv megvalósítása funkcionális prototípus elkészítéséhez. Ezt a prototípust ezután továbbfejlesztik, mielőtt más funkciókkal kombinálnák. A prototípust a kívánt minőségre hozzák, majd beépítik a kész rendszerbe. | |
| Egy egyesület | A továbbfejlesztett funkcionális prototípus kombinálása az előző iteráció során kifejlesztett prototípussal. Az így kapott prototípust a következő lépésben teszteljük. | |
| Funkcionális prototípus elemzés | Prototípus tesztelés | A DSDM módszer nélkülözhetetlen része, amelynek jelen kell lennie a teljes folyamat során. A tesztjelentést a felhasználói megjegyzésekkel együtt a következő lépésben egy prototípus-elemzési dokumentum létrehozására használjuk fel. |
| Prototípus elemzés | A felhasználói megjegyzéseket és dokumentációt összegyűjtjük. Fontos szerepet fognak játszani a prototípus felülvizsgálati dokumentum kidolgozásában. E dokumentum alapján a követelmények listája és a lehetséges kockázatok protokollja aktualizálásra kerül, és döntés születik arról, hogy a funkcionális modell létrehozásának szakaszát megismételjük-e vagy sem. |
A követelmények időbeosztása és prioritása mellett a DSDM iteratív és inkrementális megközelítést is alkalmaz az információs rendszerek kiépítéséhez.
A funkcionális modell fázis, a tervezési és fejlesztési szakasz, valamint a megvalósítási szakasz sokszor áthaladhat a részszakaszokon, mielőtt a következő szakaszba lépne. Minden iteráció új funkciókat fedez fel, és minden jelenlegi iteráció az előzőre épül. És ha szükséges, minden iteráció befejezetlenül hagyható.
Például, ha a fejlesztés során sok új és hasznos funkciót fedeztek fel, de ezek nem valósíthatók meg, akkor a megvalósíthatósági tanulmány szakaszában új követelmények megírásával lehet újrakezdeni a projektet. Vagy fordítva, bizonyos funkciók kimaradhatnak a költségvetés vagy az idő korlátai miatt. A projekt csak akkor léphet át a projekt utáni szakaszba, ha minden követelmény teljesül.
A DSDM iteratív jellegéből adódóan a követelmények és a konfiguráció megfelelő kezelése a projekt során teljesül. Ez biztosítja a projekt korai szakaszában meghatározott összes követelmény megvalósítását.
A DSDM-en belül a következő tényezők befolyásolják a projekt sikerét.
Az információs rendszerek fejlesztésére számos módszert fejlesztettek ki és alkalmaztak a gyakorlatban. Például Strukturált Rendszerelemzési és Tervezési Módszer (SSADM), RAD alkalmazásfejlesztési módszerek, OOP módszerek. A legtöbb ilyen módszer hasonló egymáshoz és a DSDM-hez.
Az Extreme Programming iteratív megközelítést alkalmaz az információs rendszerek fejlesztésére is, a felhasználók bevonásával.
A DSDM-hez leginkább hasonlító Rational Unified Process egy dinamikus információs rendszerfejlesztési módszer is. Ismét iteratív megközelítést igényel a fejlesztés.
Vannak más módszerek is, amelyek hasonlónak tűnhetnek a DSDM-hez, de számos különbség van. Először is biztosítja a szükséges fejlesztési eszközöket és módokat. Ez lehetővé teszi a felhasználók számára, hogy saját módszereiket sajátos módon adják hozzá a fejlesztési folyamathoz, és segítik a döntéshozatalt. Egy másik egyedülálló funkció - nem az időt vagy a fejlesztési eszközöket módosíthatja, hanem a projekt követelményeit. Ez a megközelítés biztosítja a DSDM fő céljainak elérését - a határidő betartását és a költségvetésen belüli tartást. És az utolsó - a kölcsönös megértés és kommunikáció az összes résztvevő között, valamint részvételük a projektben.
| Szoftverfejlesztés | |
|---|---|
| Folyamat | |
| Magas szintű koncepciók | |
| Útvonalak |
|
Fejlesztési módszertanok | |
| Modellek |
|
| Figyelemre méltó alakok |
|