Dinamikus rendszerfejlesztés folyamata

A DSDM Atern projektmenedzsment módszerének modellje.

A dinamikus rendszerfejlesztési módszer ( DSDM – Dynamic systems development method) egy agilis projekt-megvalósításhoz használt keretrendszer, amelyet eredetileg szoftverfejlesztési módszerként használtak. A DSDM 1994-ben jelent meg először, azonban igyekezett minél több figyelmet fordítani a gyors alkalmazásfejlesztési (RAD – Rapid Application Development) módszer alkalmazására is. A későbbi verziókban viszont felülvizsgálták a DSDM Agilis Projekt Keretrendszerét (DSDM Agile Project Framework), és arra a következtetésre jutottak , hogy a projektmenedzsment és a megoldások szállítása helyett, inkább összpontosítsanak a szoftverfejlesztésre és a kód létrehozására valamint arra is ,hogy mindez felhasználható legyen a nem informatikai projekteknél is. A DSDM Agilis Projekt Keretrendszer a tevékenységek széles körét fedi le a projekt teljes életciklusa során, ezen kívül magában foglalja az alapokat és az irányítást is, amelyek különböznek más Agilis módszerektől. A DSDM Agilis Projekt Keretrendszer egy iteratív és növekvő megközelítés, amely magában foglalja az agilis fejlesztés alapelveit, beleértve a folyamatos felhasználói / vevői részvételt is.

A DSDM rögzíti a költségeket, a minőséget és az időt, ezenkívül használja a MoSCoW prioritást (MoSCoW prioritisation) ,ami az alkalmazási körének rangsorolása alapján a must (kell), shoulds (kellett volna), coulds (lehetett volna) és will not haves (nem lesz) kifejezéseket használja ,hogy a projekt a megadott időn belül átadható, és a vevő igényeinek megfelelő legyen. A DSDM a sok Agilis módszer egyike a szoftver és a nem informatikai megoldások fejlesztéséhez, ezenfelül az Agilis Szövetség (Agile Alliance) részét képezi.

2014-ben a DSDM kiadta a módszerének legújabb verzióját a 'DSDM Agilis Projekt Keretrendszer' -hez. Ugyanakkor az új DSDM kézikönyv megalkotása során felismerték annak szükségességét, hogy a szolgáltatásoknak más keretrendszerekkel is képesnek kell lenniük együttműködni mint a (különösen ITIL ) PRINCE2, mert ez a sikeres programok kezelésének és a PMI (Project Management Institute) módszere. Az előző verzió (DSDM 4.2) csak útmutatásokat tartalmazott a DSDM extrém programozás során történő használatáról.

A DSDM története

Az 1990-es évek elején a gyors alkalmazásfejlesztés (RAD) nagyon elterjedt az informatikai iparban. A szoftveralkalmazások felhasználói felületei a régi zöld képernyőkről a ma használt grafikus felhasználói felületekre cserélődtek. Új alkalmazásfejlesztő eszközök kerültek a piacra, mint a PowerBuilder . Ez lehetővé tette a fejlesztők számára, hogy a javasolt megoldásokat sokkal könnyebben megtudják osztani az ügyfeleikkel – a prototípuskészítés is valósággá vált, és a klasszikus, egymást követő fejlesztési módszerek mint például a (Vízesés – model) frusztrációit félre lehetett tenni.

A RAD mozgalom azonban nagyon strukturálatlan volt: a megfelelő folyamatoknak nem voltak közösen elfogadott meghatározásai, ezért sok szervezet kidolgozta a saját meghatározását és megközelítését. Sok nagyvállalat érdeklődött a lehetőségek iránt, ugyanakkor attól is tartottak, hogy milyen arányban romlik a végtermék minősége, amit a szabad áramlásos fejlesztés (free-flow development) befolyásol.

A DSDM konzorciumot 1994-ben a szoftverfejlesztés területén működő gyártók és szakértők szövetsége alapította, és azzal a céllal hozták létre, hogy a független RAD-keretrendszert együttesen fejlesszék és kiegészítsék a legjobb gyakorlati tapasztalataik ötvözésével. A kezdet egy Londonban szervezett Butler Group nevezetű esemény volt. Az eseményen résztvevők mind a blue-chip szervezeteinél dolgoztak, mint például a British Airways, az American Express, az Oracle és a Logica (Az olyan társaságok, mint a Data Sciences és az Allied Domecq, azóta már más szervezetekkel egyesültek).

2006 júliusában megjelenő DSDM 4.2 nyilvános verzióját az egyének is megtekinthették és szabadon felhasználhatták. Azonban a DSDM-et viszonteladóknak továbbra is a nonprofit konzorcium tagjának kellett lennie.

2014-ben a DSDM kézikönyvét online és nyilvánosan is elérhetővé tették. Ezenkívül letölthetővé tették a DSDM sablonjait is.

2016 októberében a DSDM Konzorcium átalakult és Agile Business Consortium néven folytatta tevékenységét. Az Agile Business Consortium egy nonprofit, gyártótól független szervezet, amely a DSDM keretrendszer tulajdonosa és igazgatója is egyben.

DSDM Atern

Az Atern egy eladó-független megközelítés, amely felismeri, hogy több projekt lesz sikertelen az emberek problémái miatt mint a technológiai problémák miatt. Ezért az Atern arra összpontosít, hogy segítse az embereket abban, hogy hatékonyan tudjanak együttműködni az üzleti célok elérésében. Az Atern független az olyan eszközöktől és technikáktól is, amelyek lehetővé tesznek bármilyen üzleti és műszaki környezetben történő felhasználást anélkül, hogy az üzletet egy adott eladóhoz kötnék.

Alapelvek

A DSDM Atern nyolc alapelvből áll. Ezek az alapelvek irányítják a csapatot a magatartás terén is, amelyeket be kell tartaniuk, és amelyeket alkalmazniuk kell a következetes teljesítéshez.

1. Összpontosíts az üzleti igényekre
2. Időben készülj el
3. Működj együtt
4. Soha ne veszélyeztesd a minőséget
5. Fejlessz fokozatosan az alapoktól kezdve
6. Fejlessz iteratívan
7. Folyamatosan és tisztán kommunikálj
8. Mutasd be az irányítást

Alapvető technikák

• Idődobozolás : ez a megközelítés a projekt fokozatos befejezéséhez kapcsolódik oly módon, hogy az adott projektet részekre bontják, és mindegyik részhez rögzített költségvetés és kézbesítési dátum tartozik. Mindegyik részhez számos követelményt rangsorolnak és választanak ki. Mivel az idő és a költségvetés rögzített, az egyetlen fennmaradó változó a követelmények listája. Tehát, ha egy projektnek nincs ideje vagy pénze, akkor a legalacsonyabb prioritással bíró követelményeket nem veszik figyelembe. Ez nem azt jelenti, hogy befejezetlen terméket adnak át, mert a Pareto-elv szerint a projektek 80%-a a rendszerkövetelmények 20%-ból származik, mindaddig, amíg a követelmények legfontosabb 20% -át a rendszerbe be nem építik, a rendszer ezért megfelel az üzleti igényeknek, ezért az első próbálkozás során egyetlen rendszer sem épül fel tökéletesen.
• MoSCoW : a munkadarabok vagy követelmények rangsorolására szolgáló technika. Ez egy rövidítés, amely a következőket jelenti:
  • Kell
  • Kellett volna
  • Lehetett volna
  • Nem lesz

• Prototípuskészítés: a fejlesztés alatt álló rendszer prototípusainak elkészítésére utal a projekt korai szakaszában. Lehetővé teszi a rendszer hiányosságainak korai felismerését, és lehetővé teszi a jövőbeli felhasználók számára a rendszer „tesztelését” is. Ily módon megvalósul a felhasználói bevonás, amely a DSDM, vagy az ehhez kapcsolódó bármely Rendszerfejlesztési Projekt egyik legfontosabb sikertényezője.
• Tesztelés: segít biztosítani a jó minőségű megoldást, a DSDM a tesztelést minden iteráció során támogatja. Mivel a DSDM eszköztől és technikától független módszer, a fejlesztőcsapat szabadon választhatja meg saját tesztmenedzsment módszerét.
• Műhely (Workshop): összehozza a projekt érdekelt feleit, hogy megvitassák a követelményeket, a funkciókat és a kölcsönös megértést.
• Modellezés : elősegíti az üzleti domain megjelenítését és javítja a megértését. A kidolgozandó rendszer vagy üzleti terület sajátos aspektusainak vázlatos ábrázolását foglalja magában.
• Konfiguráció kezelés: mivel több kézbesítés is folyamatban van egyidejűleg, és az egyes időtartamok végén fokozatosan kerülnek átadásra, a teljesítéseket a teljesítésig jól kell kezelni.

Szerepek

DSDM környezetben megkülönböztetünk néhány szerepkört. Ugyanis fontos, hogy a projekt tagjait a projekt megkezdése előtt különféle szerepekbe osszuk be. Természetesen mindegyik szerep saját felelősséggel jár. A szerepek az alábbiak:

• Végrehajtó szponzor (Executive Sponsor) : Az úgynevezett „projekt bajnok”. Fontos szerepet játszik a felhasználói szervezetben, amely képes és felelős a megfelelő alapok és források biztosítására. Ez a szerep végső döntési képességgel rendelkezik.
• Látomásos (Visionary) : Az, aki felelõs a projekt elindításáért azáltal, hogy az alapvető követelményeket már korán megismerteti a fejlesztőcsapattal. A látomásos pontosan felismeri és érzékeli a rendszer és a projekt üzleti céljait. Egy másik feladata a fejlesztési folyamat felügyelete és megfelelő irányban tartása.
• Közvetítő (Ambassador User) : Az aki, beépíti a projektbe a felhasználói közösség ismereteit, biztosítja, hogy a fejlesztők elegendő felhasználói visszajelzést kapjanak a fejlesztési folyamat során.
• Tanácsadó (Advisor User) : Bármely olyan felhasználó lehet, aki fontos szempontot képvisel és napi ismereteket hoz a projektről.
• Projektmenedzser (Project Manager) : Bárki lehet a felhasználói közösségből vagy az informatikai személyzetből, aki általában irányítja a projektet.
• Műszaki koordinátor (Technical Co-ordinator) : A rendszer architektúrájának megtervezéséért és a projekt műszaki minőségének ellenőrzéséért felelős személy.
• Csapatvezető (Team Leader) : Vezeti a csapatot, és gondoskodik arról, hogy a csapat teljes egészében hatékonyan dolgozzon.
• Megoldásfejlesztő (Solution Developer) : Értelmezi a rendszerkövetelményeket és modellezi azokat, beleértve az átadandó kódok fejlesztését és a prototípusok felépítését is.
• Megoldás-tesztelő (Solution Tester) : Néhány vizsgálat elvégzésével ellenőrzi a szoftver helyességét műszaki szempontból, jelzi a hibákat, és a javítás után újra vizsgálatot végez. A tesztelőnek be kell nyújtania néhány megjegyzést és dokumentációt is.
• Írnok (Scribe) : Felelős minden műhelyben a követelmények, megállapodások és döntések összegyűjtéséért és rögzítéséért.
• Közreműködő (Facilitator) : A műhelyek előrehaladásának irányításáért felelős, ösztönzőként szolgál az előkészítéshez és a kommunikációhoz.
• Speciális szerepek (Specialist Roles) : üzleti építész, minőségmenedzser, rendszerintegrátor stb.

Kritikus siker tényezők

A DSDM-en belül számos tényezőt fogalmaztak meg a sikeres projektek biztosítása érdekében.

• 1. tényező: Először is a DSDM-et elfogadják a felső vezetők és más alkalmazottak is. Ez biztosítja, hogy a projekt különböző szereplői motiváltak legyenek a kezdetektől fogva, és továbbra is részt vegyenek a projekt során.
• 2. tényező: A második tényező a vezetőség elkötelezettsége a végfelhasználók bevonásának biztosítása érdekében. A prototípus-megközelítés megköveteli a végfelhasználó erőteljes és elkötelezett részvételét a funkcionális prototípusok tesztelésében és megítélésében egyaránt.
• 3. tényező: A fejlesztőcsapat. Ennek a csapatnak ügyes tagokból kell állnia, amelyek stabil uniót alkotnak. Fontos kérdés a projektcsoport felhatalmazása. Ez azt jelenti, hogy a csoportnak (vagy egy vagy több tagjának) hatalommal és lehetőségekkel kell rendelkeznie a projekttel kapcsolatos fontos döntések meghozatalához anélkül, hogy hivatalos javaslatokat kellene írni a felső vezetés számára, ami nagyon időigényes lenne. Annak érdekében, hogy a fejlesztőcsapat sikeres projektet tudjon futtatni, megfelelő technológiára van szükségük a projekt végrehajtásához. Ez fejlesztési környezetet és projektmenedzsment eszközöket jelent.
• 4. tényező: Végül, a DSDM azt is kijelenti, hogy támogató kapcsolat szükséges az ügyfél és az eladó között. Ez vonatkozik a projektekre, amelyeket vállalaton belül, vagy külső vállalkozókon belül valósítanak meg. A támogató kapcsolat biztosításában segíthet az ISPL (Information Services Procurement Library).

Összehasonlítás más keretrendszerekkel

A DSDM az iteratív és inkrementális fejlesztési keretrendszerek széles körének tekinthető, amelyek támogatja az agilis és objektumorientált módszereket. Ezek magukba foglalják (de nem korlátozódnak ezekre) a súrlódást, az extrém programozást (XP), a fegyelmezett agilis kézbesítést (DAD – Disciplined Agile Delivery) és a racionalizált egységes folyamatot (RUP – Rational Unified Process ).

A DSDM-hez hasonlóan ezek a következő jellemzőkkel rendelkeznek:

• Mindegyikük rangsorolja a követelményeket, ismételten működik, és a rendszert vagy a terméket lépésekben építi fel.
• Ezek eszközfüggetlen keretrendszerek. Ez lehetővé teszi a felhasználók számára, hogy elvégezzék a folyamat egyes lépéseit a saját technikáikkal és a választott szoftveres segédeszközökkel.
• A fejlesztésben szereplő változó nem az idő vagy az erőforrás, hanem a követelmények listája. Ez a megközelítés biztosítja a DSDM fő céljait, nevezetesen a határidő betartást és a pénzügyi kereten belül maradást.
• Erősen összpontosít a kommunikációra és az összes érdekelt fél bevonására a rendszerbe. Habár ezzel már más módszerek is foglalkoznak, de a DSDM erősen hisz a projekt iránti elkötelezettségben a sikeres eredmény biztosítása érdekében.

Lásd még

• Lean szoftverfejlesztés
• Agilis szoftverfejlesztés

További irodalom

• Coleman és Verbruggen: Minőségi szoftverfolyamat a gyors alkalmazásfejlesztéshez, Szoftverminőség-folyóirat, 7. o.   107-1222 (1998)
• Beynon-Davies és Williams: Az információs rendszerek fejlesztési módszereinek terjesztése, Journal of Strategic Information Systems 12 p.   29–46 (2003)
• Sjaak Brinkkemper, Saeki és Harmsen: Összeszerelési technikák módszertanra, fejlett információs rendszerek tervezésére, a CaiSE'98 kiadványai, Springer Verlag (1998)
• Abrahamsson, Salo, Ronkainen, Warsta Agile szoftverfejlesztési módszerek: áttekintés és elemzés, VTT Publikációk 478, p.   61-68 (2002)
• Tuffs, Stapleton, West, Eason: A DSDM interoperabilitása a Rational Unified Process-szel, DSDM Consortium, 1. kiadás, p.   1-29 (1999)
• Rietmann: DSDM madártávlatból, DSDM Consortium, p.   3-8 (2001)
• Chris Barry, Kieran Conboy, Michael Lang, Gregory Wojtkowski és Wita Wojtkowski: Információs rendszerek fejlesztése: kihívások a gyakorlatban, az elméletben és az oktatásban, 1. kötet
• Keith Richards: Agilis projektmenedzsment: PRINCE2 projektek futtatása a DSDM Atern-rel, TSO (2007) Archiválva 2021. január 23-i dátummal a Wayback Machine-ben
• DSDM Atern kézikönyv (2008)
• A DSDM Agile Project Framework kézikönyve (2014)
• DSDM Agile Project Management Framework (v6, 2014) interaktív elmetérkép

Külső linkek

• Az Agile Business Consortium (korábban DSDM Consortium)
• AgilePM wiki