DSDM

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 28. března 2021; kontroly vyžadují 8 úprav .

Metoda dynamického vývoje systémů (DSDM) je především technika vývoje softwaru založená na konceptu Rapid Application Development (RAD). DSDM je iterativní a inkrementální přístup, který klade důraz na trvalé zapojení uživatele/spotřebitele do procesu.

Cílem metody je dodat hotový projekt včas a v rámci rozpočtu a zároveň řídit změny v požadavcích projektu při jeho vývoji. DSDM je součástí rodiny agilního vývoje softwaru a vývoje neinformačních technologií.

Nejnovější verze DSDM se nazývá DSDM Atern. Jméno Atern je zkratka pro rybák arktický. Rybák arktický je pták, který dokáže cestovat na velké vzdálenosti. Symbolizuje mnoho aspektů metody, jako je stanovení priorit nebo spolupráce, které jsou přirozeným způsobem, jak provozovat pracovní postup.

Předchozí verze DSDM (vydaná v květnu 2003), která je stále platná a široce používaná, je DSDM 4.2, což je mírně rozšířená verze DSDM 4. Rozšířená verze obsahuje návod, jak používat DSDM ve spojení s Extreme Programming.

Přehled DSDM Atern

V roce 2007 tým vytvořený DSDM Consortium zkoumal podstatu metody a rozhodl, že základní mechanismy a struktura byly dobře napsány, ale terminologie a pozornost metody byla zcela zaměřena na oblast informačních technologií. Proto je nutné je zlepšit, aby vyhovovaly potřebám projektů v novém tisíciletí (část metody se od roku 1995 nezměnila). Nová verze byla vydána 24. dubna 2007 v Cafe Royale v Londýně.

Přehled DSDM verze 4.2

Jako rozšíření konceptu rychlého vývoje aplikací se DSDM zaměřuje na projekty informačních systémů vyznačující se napjatými termíny a rozpočty. DSDM obsahuje indikace typických chyb projektů informačních systémů, jako je překročení rozpočtu, pozdní dodací (realizační) termíny, nedostatečné zapojení uživatelů a vrcholových manažerů do práce na projektu. DSDM se skládá z:

Za určitých podmínek je možné do DSDM zahrnout části dalších metodik, jako je Rational Unified Process (RUP), Extreme Programming, PRINCE2. Další flexibilní metodou podobnou DSDM v procesu a koncepci je Scrum .

Metoda DSDM byla vyvinuta ve Velké Británii v 90. letech 20. století konsorciem DSDM. DSDM Consortium je sdružení softwarových vývojářů a expertů založené s cílem „společně vyvíjet a podporovat nezávislý rámec RAD“ spojením osvědčených postupů členů sdružení. DSDM Consortium je nezisková organizace nezávislých vývojářů, kteří vlastní a provozují framework DSDM. První verze frameworku byla dokončena v lednu 1995 a publikována v únoru 1995. V červenci 2006 byla vydána verze DSDM 4.2 s otevřeným zdrojovým kódem a zpřístupněna jednotlivcům k prohlížení a používání. Každý, kdo distribuuje DSDM, však musí být členem tohoto neziskového konsorcia.

DSDM a konsorcium DSDM - začátky

Na počátku 90. let se v odvětví informačních technologií začal šířit nový termín – Rapid Application Development (RAD). Uživatelská rozhraní aplikačního softwaru se vyvinula ze starých zelených obrazovek na grafická uživatelská rozhraní, která se používají dodnes. Na trh začaly přicházet nové nástroje pro tvorbu aplikací, jako je PowerBuilder . Vývojářům usnadnili sdílení jejich plánovaného vývoje se zákazníky – objevilo se prototypování a začala destrukce klasických, sekvenčních (kaskádových) vývojových metod.

Nové hnutí RAD však bylo velmi nestrukturované: neexistoval žádný dohodnutý popis metody a mnoho organizací si k ní vytvořilo vlastní popisy a přístupy. Mnoho velkých korporací se zajímalo o perspektivu, kterou metoda nabízí, ale také se obávaly, aby se v konečném výsledku nesnížila úroveň kvality jejich produktů.

Konsorcium DSDM vzniklo v roce 1994, když se skupina lidí setkala na akci pořádané Butler Group v Londýně. Všichni, kdo na tuto akci přišli, pracovali ve velkých organizacích jako British Airways, American Express, Oracle a Logica (společnosti jako Data Sciences a Allied Domecq byly od té doby převzaty jinými organizacemi).

Na tomto setkání bylo rozhodnuto, že Jennifer Stapleton, tehdy ze společnosti Logica, navrhne komplexní metodu zaměřenou na uživatele s dobrou kontrolou kvality pro iterativní a postupný vývoj. Výsledná architektura byla navržena tak, aby plně vyhovovala normám ISO 9000 a PRINCE2. Když byla architektura připravena (měsíc po schůzce), vytvořilo konsorcium skupiny, které ji distribuovaly ve všech oblastech vývoje softwaru, které zahrnovaly: metody a nástroje projektového řízení, kontrolu a testování kvality, vývojové metody a nástroje. Kontrolní skupina, vedená architektem a složená z vedoucích těchto skupin, měla zajistit, aby byla metoda chápána tak, jak byla původně koncipována.

Navzdory skutečnosti, že mnozí členové konsorcia byli přímými konkurenty, volně sdíleli, jak řeší vzniklé problémy. Praxe ukázala, že nejlepšího výsledku lze dosáhnout pouze prací jako celek. Konsorcium se rozrostlo – v prvním roce z několika organizací na šedesát; popis metody byl stále kompletnější. Verze 1 byla vytvořena v prosinci 1994 a zveřejněna v únoru 1995. Výsledkem je univerzální metoda, která zahrnuje lidi, procesy a nástroje. Vznikla na základě zkušeností organizací, které se liší povahou své činnosti a velikostí.

Metoda DSDM

Principy

Existuje 9 principů, které se skládají ze 4 základních a 5 výchozích bodů.

Předpoklady pro používání DSDM

Chcete-li úspěšně používat DSDM, musí být splněna řada předpokladů. Nejprve je nutné zorganizovat interakci mezi projektovým týmem, budoucími uživateli a vrcholovým managementem. Za druhé by mělo být možné rozdělit projekt na menší části, což umožní iterativní přístup.

Dva příklady projektů, pro které se DSDM nehodí:

Životní cyklus projektu

Přehled: Tři fáze DSDM

Rámec DSDM se skládá ze tří po sobě jdoucích fází, které se nazývají předprojektová fáze, fáze životního cyklu projektu a poprojektová fáze. Fáze životního cyklu projektu je nejpromyšlenější a nejpodrobnější ze všech ostatních. Skládá se z pěti kroků, které tvoří iterativní, postupný přístup k vývoji informačních systémů. Tyto tři fáze a jejich příslušné kroky budou podrobněji popsány v následujících částech. Pro každou fázi nebo fázi budou přezkoumány nejdůležitější funkce a budou prezentovány výsledky.

Fáze 1 - Předprojekt V této fázi jsou identifikovány pravděpodobné projekty, přiděleny finanční prostředky a je identifikován projektový tým. Řešení problémů v této fázi pomůže vyhnout se problémům v pozdějších fázích projektu. Fáze 2 - Životní cyklus projektu Níže uvedený obrázek ukazuje tuto fázi. Ukazuje 5 fází, kterými musí projekt projít, aby se stal informačním systémem. První dvě etapy, studie proveditelnosti a studie ekonomické proveditelnosti, probíhají postupně a vzájemně se doplňují. Po dokončení těchto fází probíhá iterativní a inkrementální vývoj systému ve fázích: vytvoření funkčního modelu, návrh a vývoj, fáze implementace. Iterativní a inkrementální povaha DSDM bude popsána dále. Fáze 3 - Post-projekt V této fázi je zajištěn efektivní provoz systému. Toho je dosaženo udržováním projektu, jeho vylepšováním a opravou chyb podle zásad DSDM. Projekt je podporován neustálým vývojem založeným na iterativní a inkrementální povaze DSDM. Namísto dokončení projektu v jednom cyklu je běžné vracet se k předchozím fázím nebo milníkům za účelem vylepšení produktu.

Níže uvedený diagram ukazuje celý životní cyklus projektu. Tento diagram popisuje iterativní vývoj DSDM. Popis každé fáze bude uveden níže.

Čtyři fáze fáze životního cyklu projektu

Akce Subakce Popis
Studie Studie proveditelnosti V této fázi se zjišťuje, zda projekt spadá do působnosti DSDM. S ohledem na typ projektu, organizační a personální záležitosti se rozhoduje, zda metodu DSDM použít či nikoliv. Tímto způsobem bude získána zpráva o použitelnosti, přijatelný prototyp a přibližný globální plán projektu, který obsahuje plán vývoje a protokol možných rizik.
Studie proveditelnosti V této fázi jsou analyzovány hlavní ekonomické a technologické charakteristiky. Koná se setkání expertů, kde se probírají nejdůležitější aspekty systému a rozhoduje se o prioritách rozvoje. V této fázi je vypracován seznam základních požadavků, popis rozsahu podnikání, popis architektury systému a hrubý plán prototypování.
Vytvoření funkčního modelu Definování funkčního prototypu Definice funkčnosti, která bude v této fázi zahrnuta do prototypu. V této dílčí fázi je vypracován funkční model podle výsledků získaných ve fázi studie ekonomické proveditelnosti.
Koordinace plánů Existuje dohoda o tom, jak a v jakém časovém horizontu by se měla vyvíjet funkčnost prototypu.
Vytvoření funkčního prototypu Vývoj funkčního prototypu, dle plánů a funkčního modelu.
Analýza funkčního prototypu Kontrola stavu vyvíjeného prototypu. Toho lze dosáhnout testováním prototypu koncovým uživatelem a/nebo revizí dokumentace. Výsledkem je dokument obsahující přehled funkčního prototypu.
Návrh a vývoj Definice návrhu prototypu Definice funkčních a nefunkčních požadavků systému. Na základě těchto požadavků by měla být vytvořena implementační strategie. Pokud existuje testovací záznam z předchozí iterace, pak bude také použit k vytvoření implementační strategie.
Koordinace plánů Existuje dohoda o tom, jak a v jakém časovém horizontu mají být stanovené požadavky realizovány.
Vytvoření konstruktivního prototypu Vytvoření systému (konstruktivního prototypu), který může být předán uživatelům k testování.
Strukturální prototypová analýza Zkontrolujte správnost navrženého systému. Tento dílčí krok zahrnuje testování a kontrolu výsledků. Tvorba uživatelské dokumentace a zkušebního protokolu.
Implementace Schválení systému uživatelem Koncoví uživatelé schvalují testovaný systém pro implementaci a vedení.
Školení uživatelů Školení budoucího uživatele pro práci se systémem. Výsledkem dílčí etapy je kontingent vyškolených uživatelů.
Implementace Implementace testovaného systému mezi uživateli.
Systémová analýza trhu Analýza dopadu uvolněného systému na trh. Hlavní otázkou je, zda bylo dosaženo cíle stanoveného při návrhu systému. Na základě toho se projekt přesune do další fáze (postprojekt) nebo se vrátí k předchozí k revizi. Analýza bude uvedena v dokumentu analýzy projektu.

Čtyři fáze životního cyklu projektu

Fáze 1A: Studie proveditelnosti

Během této fáze se kontroluje proveditelnost projektu v rámci DSDM. Předpoklady pro použití DSDM se kontrolují zodpovězením otázek: „Může tento projekt splňovat potřebné ekonomické požadavky?“, „Je projekt vhodný pro použití metody DSDM?“ a „Jaká jsou nejdůležitější rizika v tomto projektu?“. Nejdůležitější metodou v této fázi je využití pracovních skupin.

Výstupem této etapy je zpráva o použitelnosti a přijatelný prototyp, který zvažuje proveditelnost projektu, dále přibližný globální plán projektu a protokol možných rizik popisující nejdůležitější rizika projektu.

Fáze 1B: Studie proveditelnosti

Studie proveditelnosti rozšiřuje a doplňuje etapu studie proveditelnosti. Poté, co je projekt uznán jako proveditelný v rámci DSDM, jsou v této fázi kontrolovány obchodní procesy, jsou zapojeny skupiny uživatelů a analyzovány jejich požadavky a přání. A opět, nejoblíbenější metodou v této fázi je využití pracovních skupin. V rámci pracovních skupin se scházejí účastníci projektu, aby diskutovali o plánovaném systému. Informace získané po těchto událostech jsou shromážděny v seznamu požadavků. Důležitým rysem tohoto seznamu je rozdělení priorit mezi požadavky. Tyto požadavky jsou rozděleny podle metody MoscoW. Na základě obdržené sekvence je vytvořen plán rozvoje, který bude vodítkem pro celý projekt.

K vytvoření tohoto plánu se používá pro projekt velmi důležitá technika - time-boxing. Tato metodika je nezbytná pro dosažení cílů DSDM – dodržení termínů a rozpočtu a zároveň udržení požadované kvality produktu. Architektura systému je dalším pomocníkem při řízení vývoje informačního systému. Výstupem této fáze je popis rozsahu podnikání, který obsahuje kontext projektu v rámci společnosti, popis architektury systému, který poskytuje počáteční globální architekturu pro vyvíjený informační systém, a plán rozvoje, který nastiňuje nejdůležitější kroky vývojový proces. Tyto dva dokumenty vycházejí ze seznamu požadavků. Protokol možných rizik je doplněn o data získaná v této fázi.

Fáze 2: Vytvoření funkčního modelu

Požadavky, které byly definovány v předchozím kroku, jsou převedeny do funkčního modelu. Skládá se z funkčního prototypu a modelů. Prototypování je v této fázi klíčovou projektovou technikou, která umožňuje organizovat zapojení uživatelů do projektu. Vyvinutý prototyp je analyzován různými skupinami uživatelů. Pro dosažení požadované kvality se při každé iteraci používá testování. V této fázi je představena nejdůležitější část testování. Vytvoření funkčního modelu lze rozdělit do následujících dílčích etap:

  • Definice funkčního prototypu: definice funkčnosti, která bude v této fázi začleněna do prototypu.
  • Koordinace plánů: existuje dohoda o tom, jak a v jakém časovém horizontu by měla být vyvinuta funkčnost prototypu.
  • Vytvoření funkčního prototypu: vyvinout prototyp. Prostudujte a upřesněte prototyp v této iteraci podle funkčního prototypu získaného v předchozích iteracích.
  • Analýza funkčního prototypu: kontrola stavu navrženého systému. Tento dílčí krok zahrnuje testování a kontrolu výsledků.

Výstupem této fáze je funkční model a funkční prototyp, které společně představují funkcionalitu získanou v této iteraci, připravenou k uživatelskému testování. Dále se aktualizuje seznam požadavků - již implementované položky jsou z něj odstraněny a pořadí zbývajících položek je opět změněno. Po analýze funkčního prototypu je aktualizován i protokol možných rizik.

Fáze 3: Návrh a vývoj

Hlavním cílem této iterace je spojit funkční komponenty z předchozí fáze do jediného systému, který uspokojí požadavky uživatelů. Zohledňují se zde i nefunkční požadavky. A opět v této fázi probíhá testování. Návrh a vývoj lze rozdělit do následujících dílčích fází:

  • Definování návrhového prototypu: Definování funkčních a nefunkčních požadavků, které by měl systém mít.
  • Koordinace plánů: existuje dohoda o tom, jak a v jakém časovém horizontu mají být stanovené požadavky realizovány.
  • Strukturální prototypování: Vytvoření systému, který lze uživatelům poskytnout pro každodenní použití. Prostudujte a zdokonalte prototyp v této iteraci.
  • Analýza konstruktivního prototypu: zkontrolujte stav navrženého systému. Tento dílčí krok zahrnuje testování a kontrolu výsledků. Protokol o testu a zpětná vazba od uživatelů se používají k vytvoření uživatelské dokumentace.

Výsledkem etapy je vytvoření konstruktivního prototypu pro uživatelské testování. Testovaný systém postoupí do další fáze. V této fázi je vzhled a funkčnost systému obecně připravena. Dalším výsledkem je vytvoření uživatelské dokumentace.

Fáze 4: Implementace

Ve fázi implementace je testovaný systém spolu s uživatelskou dokumentací předán budoucím uživatelům a jsou proškoleni pro práci se systémem. Systém je analyzován z hlediska souladu s požadavky stanovenými v raných fázích projektu. Implementaci lze rozdělit do následujících dílčích kroků:

  • Uživatelská validace systému: Koncoví uživatelé ověřují testovaný systém pro implementaci a vedení.
  • Školení uživatelů: školení budoucího uživatele pro práci se systémem. Výsledkem dílčí etapy je kontingent vyškolených uživatelů.
  • Implementace: implementace testovaného systému mezi uživatele.
  • Analýza trhu systému: analýza dopadu uvolněného systému na trh. Hlavní otázkou je, zda bylo dosaženo cíle stanoveného při návrhu systému. Na základě toho se projekt přesune do další fáze (postprojekt) nebo se vrátí k předchozí k revizi.

Výsledek etapy: kompletní systém vhodný pro použití koncovými uživateli, kontingent vyškolených uživatelů a dokument podrobné analýzy projektu.

Fáze vytvoření funkčního modelu DSDM

Metadatový model

Vztahy mezi koncepty ve fázi tvorby funkčního modelu ukazuje model na obrázku níže.

pojem Popis
Protokol možných rizik Protokol zjištěných rizik. Důležité pro následující fáze, obsahuje problémy, které pravděpodobně nastanou. Měl by být neustále aktualizován.
Seznam požadavků podle priority Seznam požadavků seřazených podle priority. Distribuční proces je založen na metodě MoSCoW, která určuje, které požadavky by měly být implementovány jako první (z ekonomického hlediska)
Seznam nefunkčních požadavků Seznam nefunkčních požadavků, se kterými se bude muset v dalším kroku vypořádat.
Funkční požadavek Tato funkce se používá pro vytváření modelů a prototypování podle priorit.
funkční model Model postavený na základě funkčních požadavků. V dalším dílčím kroku bude použit k vývoji prototypu. Tento model bude použit k vytvoření prototypového plánu.
prototypování Proces rychlého vytvoření funkčního modelu (prototypu) pro testování návrhů, ilustraci nápadů a funkcí a včasné získávání zpětné vazby od uživatelů.
Seznam časových intervalů Seznam časových intervalů pro provedení jednotlivých prací je nutné vejít do harmonogramu realizace celého projektu.
Plán prototypování Plán pro proces prototypování, který má být dokončen v časových úsecích podle plánu.
Provozní řád Soubor prací a čas těchto prací odsouhlasený vývojáři. Používá se při realizaci funkčního prototypu.
funkční prototyp Prototyp, který vám umožní vidět všechny funkce systému a jak bude systém tyto funkce provádět.
Plán implementace Příprava prací na realizaci funkčního prototypu dle harmonogramu prací a seznamu požadavků.
Vylepšená funkce Funkce prototypu, která byla v této iteraci vylepšena a testována, než byla sloučena s ostatními částmi prototypu.
Společná funkce Prototyp funkce, která byla sloučena s funkcemi z předchozích iterací. Nový kombinovaný funkční prototyp bude testován v další fázi.
Protokol o zkoušce Záznam testu, který se skládá z testovacího skriptu, testovací procedury a výsledků testu.
Dokument analýzy funkčního prototypu Skládá se z uživatelských komentářů k aktuální verzi, nezbytných pro práci na následných iteracích. Tento dokument slouží k aktualizaci protokolu možných rizik a seznamu požadavků.

Model vývoje procesu

Úkolem definování funkčního prototypu je definovat funkcionalitu, která bude přítomna v prototypu v dané iteraci. Analýza a programování dokončeno; prototypy jsou sestaveny; a zkušenosti z nich získané jsou využívány ke zdokonalování analytických modelů (a vycházejí rovněž z aktualizovaného seznamu požadavků a protokolu možných rizik). Postavené prototypy se nevyhazují, ale postupně se dostávají do požadované kvality, aby mohly být později zařazeny do hotového systému. K určení, kdy a v jakém časovém rámci bude prototypování implementováno, je zapotřebí dohodnutý pracovní harmonogram; rozšiřuje harmonogram a plán prototypování. A testování, které se provádí v průběhu celého procesu, je také nepostradatelnou součástí této fáze a je zahrnuto do procesu analýzy prototypu ihned po vyrobení prototypu. Zkušební protokol bude také použit k analýze prototypu a vytvoření analytického dokumentu. Níže je schéma tohoto procesu.

Akce Subakce Popis
Definování funkčního prototypu Analýza požadavků Požadavky na aktuální prototyp jsou analyzovány podle seznamu požadavků vytvořených dříve (v předchozí iteraci a/nebo fázi).
Seznam požadavků na aktuální iteraci Výběr funkčních požadavků, které budou implementovány do prototypu v aktuální iteraci, a vytvoření seznamu funkčních požadavků.
Seznam nefunkčních požadavků Vytvoření seznamu nefunkčních požadavků na systém.
Vytvoření funkčního modelu Analýza kódu modelu a prototypu a vytvoření funkčního modelu.
Koordinace plánů Definice času Stanovení možného harmonogramu provádění prototypových prací v souladu s prototypovým plánem a strategií.
Vytvořte si plán rozvoje Vytvořte plán prototypování, který zahrnuje všechny práce na prototypování, které mají být dokončeny v časových úsecích podle plánu.
Koordinace Dohodnutý harmonogram, jak a v jakém časovém rámci budou dokončeny všechny práce na prototypu.
Vytvoření funkčního prototypu Studie Výzkum požadavků; analýza funkčního modelu a na základě analýzy vypracování implementačního plánu. Výsledky budou použity k sestavení prototypu v další dílčí aktivitě.
Zlepšení Implementace funkčního modelu a implementačního plánu na stavbu funkčního prototypu. Tento prototyp bude poté vylepšen, než bude kombinován s dalšími funkcemi. Prototyp je doveden do požadované kvality a následně zařazen do hotového systému.
Sdružení Kombinace vylepšeného funkčního prototypu s prototypem vyvinutým v předchozí iteraci. Výsledný prototyp bude v dalším kroku testován.
Analýza funkčního prototypu Testování prototypů Nepostradatelná součást metody DSDM, která musí být přítomna během celého procesu. Protokol o zkoušce spolu s komentáři uživatelů bude v dalším kroku použit k vytvoření dokumentu analýzy prototypu.
Prototypová analýza Shromažďují se komentáře a dokumentace uživatelů. Budou hrát důležitou roli při vývoji dokumentu o přezkoumání prototypu. Na základě tohoto dokumentu bude aktualizován seznam požadavků a protokol možných rizik a bude rozhodnuto, zda provést další iteraci etapy tvorby funkčního modelu či nikoliv.

Více o DSDM

HlavníTechniky DSDM

  • časový boxTimeboxing je jednou z hlavních technik DSDM. Slouží k dosažení hlavních cílů DSDM – vyvinout informační systém včas, splnit rozpočet a zároveň udržet kvalitu. Hlavní myšlenkou timeboxingu je rozdělit celý projekt na části, z nichž každá má svůj vlastní rozpočet a termíny. Pro každou takovou část jsou vybrány požadavky, které byly rozděleny podle principu MoSCoW. Vzhledem k tomu, že čas a rozpočet jsou pevně dané, jediné, co se může změnit, jsou požadavky. Pokud například projekt zaostává za plánem nebo překračuje rozpočet, požadavky s nejnižší prioritou budou zrušeny. To neznamená, že se objeví nedokončený výrobek. Na základě principu 20/80 pochází 80 % projektu z 20 % požadavků. Jakmile je tedy těchto nejdůležitějších 20 % požadavků v systému implementováno, uspokojuje ekonomické požadavky. Stojí za zmínku, že žádný systém nebyl postaven dokonale napoprvé.
  • MoskvaMetoda MoSCoW poskytuje způsob, jak upřednostňovat objekty. V kontextu DSDM se k upřednostnění požadavku používá metoda MoSCoW. Tato zkratka znamená:
MUSÍ - požadavek MUSÍ odpovídat ekonomickým potřebám. MĚL - Zda by tento požadavek MĚL být splněn, pokud na něm nezávisí úspěch projektu. MOHLO - Zda by tento požadavek MĚL být ponechán, pokud neovlivňuje obchodní potřebu projektu. NEBUDE - Je MOŽNÉ odložit splnění požadavku, pokud je ještě čas.
  • prototypováníTato technika se týká prototypování systému během raného vývoje. Umožňuje identifikovat chyby v systému a umožňuje budoucím uživatelům jej otestovat. Realizuje se tak zapojení uživatele do práce – jeden z klíčových faktorů úspěchu metody DSDM.
  • TestováníTřetím důležitým aspektem dosažení cíle DSDM je vytvoření vysoce kvalitního informačního systému. Aby toho bylo dosaženo, DSDM trvá na testování každé iterace. Projektový tým se může svobodně rozhodnout, jak bude testování řídit.
  • Pracovní skupinaJedná se o jednu z technik DSDM, jejímž účelem je dát dohromady různé účastníky projektu, aby diskutovali o požadavcích, funkčnosti a budovali vzájemné porozumění. Členové každé pracovní skupiny se sejdou, aby o projektu diskutovali.
  • ModelováníTato technika je povinná a používá se k vizualizaci ve formě diagramů samostatné strany systému nebo oblasti činnosti, na které se pracuje. Modelování umožňuje celému projektovému týmu lépe porozumět obchodní oblasti projektu.
  • Správa konfiguraceDobrá implementace techniky správy konfigurace je důležitá kvůli dynamické povaze DSDM. Vzhledem k tomu, že během procesu vývoje systému dochází k mnoha různým událostem a produkty jsou často vydávány poměrně často, produkty vyžadují přísnou kontrolu, aby mohly být úspěšně vyrobeny.

Rolev DSDM

  • Výkonný sponzor/producent nebo jinak Šampion projektu. Velmi důležitá role. Má schopnost a povinnost spravovat finanční prostředky a zdroje. Tato role má také plnou pravomoc rozhodovat.
  • Vizionář je ten, kdo rozjede projekt a najde první základní požadavky. Vizionář nejpřesněji rozumí obchodním cílům systému a projektu.
  • Zástupný uživatel Zastupuje uživatele v projektu. Zodpovědný za zajištění toho, aby vývojáři během procesu vývoje dostávali dostatečnou zpětnou vazbu od uživatelů.
  • Konzultant může být libovolný uživatel, který poskytuje důležitý pohled na projekt a přináší do projektu znalosti o některých aspektech používání produktu.
  • Projektový manažer Může být z komunity uživatelů nebo z oblasti informačních technologií. Poskytuje celkové řízení projektu.
  • Technický koordinátor Zodpovídá za vývoj architektury systému a kontroluje kvalitu projektu.
  • Vedoucí týmu Vede vývojový tým a zajišťuje jeho efektivní fungování.
  • Vývojář analyzuje systémové požadavky a modeluje je. To zahrnuje psaní kódu a prototypování.
  • Tester Kontroluje správnost projektu z technické stránky prováděním testů. Píše komentáře a dokumentaci.
  • Tajemník Zodpovídá za sběr a evidenci požadavků, dohod a rozhodnutí přijatých v každé pracovní skupině.
  • Broker Řídí pracovní skupiny.
  • Další role Obchodní architekt, manažer kvality, systémový integrátor atd.

Iterativnía inkrementální povaha DSDM

Kromě časového boxu a stanovení priorit požadavků využívá DSDM také iterativní a inkrementální přístup k budování informačních systémů.

Fáze funkčního modelu, fáze návrhu a vývoje a fáze implementace mohou mnohokrát projít svými dílčími fázemi, než přejdou do další fáze. Každá iterace zkoumá nové funkce a každá aktuální iterace navazuje na předchozí. A pokud je to nutné, každá iterace může zůstat nedokončená.

Pokud bylo například během vývoje objeveno mnoho nových a užitečných funkcí, které však nelze implementovat, je možné zahájit projekt znovu sepsáním nových požadavků ve fázi studie proveditelnosti. Nebo naopak některé funkce mohou být vynechány z důvodu rozpočtu nebo časového omezení. Projekt může přejít do postprojektové fáze pouze tehdy, když jsou splněny všechny požadavky.

Vzhledem k iterativní povaze DSDM existuje správná správa požadavků a konfigurace v celém projektu. Tím je zajištěna realizace všech požadavků stanovených v raných fázích projektu.

Faktory potřebné pro úspěch metody DSDM

V rámci DSDM existují následující faktory, které ovlivňují úspěšnost projektu.

  • Prvním je přijetí metodiky DSDM vedením a všemi zaměstnanci. Tím je zajištěna motivace všech účastníků již od spuštění projektu a jejich následné zapojení.
  • Z prvního vyplývá druhý faktor – ochota vedení zajistit zapojení koncových uživatelů do práce na projektu. Proces prototypování vyžaduje velké zapojení uživatelů do testování a hodnocení funkčních prototypů.
  • Třetí je projektový tým. Mělo by se skládat ze zkušených členů a časem se stát stálým sdružením. Důležitým problémem je důvěra a vzájemné porozumění v projektovém týmu. To znamená, že tým má právo a schopnost činit důležitá rozhodnutí o projektu bez formálního souhlasu vedení, což může zabrat spoustu času. Aby tým mohl úspěšně pracovat na projektu, potřebuje potřebné nástroje – vývojové prostředí, nástroje pro řízení projektů atp.
  • Čtvrtý. DSDM znamená pozitivní vztah mezi vývojářem a zákazníkem. Týká se to projektů, které jsou vyvíjeny v rámci samotných společností, stejně jako s využitím dodavatelů třetích stran.

Srovnání s jinými metodami vývoje informačních systémů

Mnoho metod pro vývoj informačních systémů již bylo vyvinuto a aplikováno v praxi. Například metoda SSADM (Structured Systems Analysis and Design Method), metody vývoje aplikací RAD, metody OOP. Většina z těchto metod je podobná jak jedna druhé, tak DSDM.

Extrémní programování také využívá iterativní přístup k vývoji informačních systémů se zapojením uživatelů.

Rational Unified Process, nejpodobnější DSDM, je také dynamickou metodou rozvoje informačních systémů. Opět to vyžaduje iterativní přístup k vývoji.

Existují další metody, které se mohou zdát podobné DSDM, ale mají řadu rozdílů. Za prvé poskytuje potřebné vývojové nástroje a způsoby. To umožňuje uživatelům přidávat své vlastní metody do procesu vývoje speciálním způsobem a pomáhat při rozhodování. Další unikátní funkce - můžete změnit nikoli čas nebo vývojové nástroje, ale požadavky na projekt. Tento přístup zajišťuje dosažení hlavních cílů DSDM – dodržení termínu a dodržení rozpočtu. A poslední - vzájemné porozumění a komunikace mezi všemi účastníky a jejich zapojení do projektu.

Viz také

Odkazy