Dynamic System Development Method (DSDM) – metodyka zarządzania projektami, która powstała w 1995 r. i jest uważana za najstarszą zwinną metodykę projektową.

We wczesnych latach dziewięćdziesiątych powstało określenie „” (). Oznacza ono „szybkie tworzenie aplikacji”. Ta ideologia i technika polega zarazem na zapewnieniu programistom dużych ilości gotowych komponentów i dużych możliwości prototypowania. Dzięki temu otrzymuje się możliwość uzyskania efektów w początkowych fazach etapu programowania. Na bazie RAD powstała metodyka .

Podstawowe założenia DSDM opierają się na tym, że zadania, które należy wykonać w celu wykonania danego systemu, zawsze podlegają zmianom.

Pierwsza wersja DSDM była udostępniona w 1995 roku. Krótko po jej wydaniu powstała odświeżona wersja V2, która wprowadzała drobne poprawki. Wersja V3 została opublikowana w 1997 roku, V4 w 2002, a kolejne rozszerzenia do wersji V4, V4.1 oraz V4.2 były dostępne online dla członków konsorcjum DSDM. Jedną z najbardziej rozpoznawalnych wersji była V5 opublikowana w czerwcu 2008 roku, zwana szerzej jako DSDM Atern. Obecna, najnowsza wersja metodyki DSDM została opublikowana w 2014 roku. Jest to wersja 6 metodyki, która nazywana jest .

Role projektowe DSDM wyróżnia 13 ról w procesie tworzenia oprogramowania. Zgrupowane w trzech grupach: poziomu Zarządu Projektu, poziomu Zespołu Rozwoju Rozwiązania oraz poziomu wsparcia Zespołu Rozwoju Rozwiązania. Role te, szczególnie dla mniejszych projektów, mogą być łączone przez jedną osobę np.: Kierownik projektu, może być jednocześnie Kierownikiem Zespołu:

Poziom Zarządu Projektu: (Sponsor Biznesowy) – rola, mająca możliwość i uprawnienia do zatwierdzania zmian w projekcie oraz do pozyskiwania wymaganych zasobów i materiałów; ma decydujący głos w dyskusjach; sponsor projektu. (Wizjoner Biznesowy) – osoba odpowiedzialna za to, aby w miarę wcześnie sprecyzować wymagania, posiada najlepsze rozeznanie w dziedzinie zastosowań produkowanego systemu, nadaje projektowi kierunek rozwoju, często pomysłodawca systemu. (Koordynator Techniczny) – osoba odpowiedzialna za architekturę systemu, kontrolę realizacji oraz techniczną jakość projektu, odpowiedzialny za architekturę i jakość produktu, zarządza zmianami w projekcie. (Kierownik Projektu) – odpowiedzialny za synchronizację pracy zespołów. (Analityk Biznesowy) – osoba ułatwiająca kontakt pomiędzy ludźmi finansów a osobami technicznymi oraz pomiędzy zespołem zarządczym projektu a zespołem rozwoju rozwiązania. Pracuje na styku, dwóch poziomów: Poziomu Zarządu Projektu i Poziomu Zespołu Rozwoju Rozwiązania, stanowi pomost pomiędzy tymi dwoma poziomami. Poziom Zespołu Rozwoju Rozwiązania: (Ambasador Biznesowy) – odpowiedzialny za przekazanie wiedzy od klienta, odpowiedzialny jest za całokształt projektu, zapewnia sprzężenie zwrotne programistom podczas implementacji. (Twórca Rozwiązania, Programista) – implementuje system, interpretuje wymagania systemowe oraz model systemu, dostarcza kod programu i buduje prototypy. (Tester Rozwiązania) – testuje poprawność techniczną produktu, pisze testy, dodaje odpowiednie komentarze i tworzy dokumentację. Jest to tester techniczny (np. inne programista), które nie przeprowadza testów UAT. (Lider Zespołu) – dowodzi zespołem ludzi i zapewnia im stale możliwość efektywnej pracy. Charakteryzuje go tzw. podejście przywództwa służebnego. (Doradca Techniczny) – rolę tę pełni osoba techniczna wyznaczona do reprezentowania danego punktu technicznego budowanego rozwiązania, są przedstawicielami architektów, zewnętrznych konsultantów, ekspertów technicznych etc. (Doradca Biznesowy) – rolę tę pełni użytkownik (użytkownicy) wyznaczeni do reprezentowania danego punktu widzenia na projekt, są przedstawicielami użytkowników, ma wgląd w realizowany projekt, a w miarę potrzeb potrafi dostarczyć programistom odpowiedniej wiedzy na dany temat – za który jest odpowiedzialny. Poziom Wsparcia Zespołu Rozwoju Rozwiązania: (Facylitator Warsztatów, Ułatwiacz) – kieruje procesem warsztatu, stanowi motor do przygotowań do warsztatu, a także jest odpowiedzialny za sprawny oraz efektywny przebieg warsztatu, jest niezależny od wyniku warsztatu. (Korepetytor, Trener DSDM) – wspiera zespoły projektowe w procesie DSDM (odpowiednik Agile Coach’a w innych metodykach)

Techniki obecne w DSDM (dwa warianty) – umiejętne rozdzielenie realizacji produktu na nieprzekraczalne czasowo zakresu czasu. Jest to bliski odpowiednik Sprintu w Scrumie, jednak istnieją pewne różnice między Scrum a DSDM. MoSCoW M – – musi mieć tę funkcjonalność S – – jeśli jest to możliwe to powinno mieć tę funkcjonalność, C – – ta funkcjonalność jest potrzebna, pod warunkiem że nie wpłynie negatywnie na inne i efektywność systemu W – – nie tym razem, ale w przyszłości tę funkcjonalność można by dołożyć Modelowanie Prototypowanie Warsztaty Facylitowane Codzienne Zbiórki Rozwój Iteracyjny

Skład procesu DSDM Inspekcja zastosowalności – jest wykonywana zawsze na początku projektu jednokrotnie w celu potwierdzenia zasadności stosowania metody DSDM, w trakcie wykonywania inspekcji zastosowalności wstępnie określa się ryzykowne punkty w projekcie, jeśli to niezbędne buduje się prototypy, ilość prac, jaką przeznacza się na tę fazę, daje się zrealizować w kilka tygodni. Badania biznesowe służą rozpoznaniu kluczowych dla projektu lub jego części zagadnień i osób po stronie odbiorcy, w późniejszym okresie osoby te są włączane w proces opracowywania systemu; efektem działań w tej fazie są wysokopoziomowy opis systemu (), specyfikacja zakresu systemu, zarys architektury systemu () oraz Plan prototypowania (). Iteracyjne opracowanie modelu funkcjonalnego () – jest to etap budowy modelu funkcjonalnego, składa się naprzemiennie z procesów analizy i budowy prototypów, wyniki prototypowania służą do poprawienia i uszczegółowienia modeli analitycznych; w miarę możliwości prototypy są udoskonalane w taki sposób, by można było je włączyć do produktu końcowego, efektem końcowym tej fazy jest model funkcjonalny oraz kod prototypów, prototypowanie jest często traktowane jako forma testowania modelu funkcjonalnego.

W każdej pętli iteracji tworzone są następujące dokumenty: lista funkcji do opracowania wraz z ich priorytetami, uwagi i komentarze użytkowników na temat prac w aktualnym cyklu (), wymagania niefunkcjonalne, analiza ryzyka pod kątem dalszych prac, iteracyjne projektowanie i implementacja ()

Model funkcjonalny opracowany w poprzednim etapie jest przekształcany w kod źródłowy właściwego produktu, prototypy powstałe w trakcie prac nad modelem funkcjonalnym mogą być w tej fazie adaptowane do kodu aplikacji, wynikiem tej fazy jest przetestowany produkt zawierający uzgodniony wcześniej zestaw funkcjonalności, Wdrożenia

Praktyki wprowadzane przez DSDM Użytkownik jest aktywny w całym procesie tworzenia oprogramowania, Zespoły biorące udział w DSDM są uprawnione do podejmowania decyzji (w ograniczonym zakresie), Duży nacisk na częste dostarczanie nowych wersji oprogramowania, Każda nowa wersja jest oceniana pod kątem przydatności i odpowiedniości w zastosowaniach biznesowych, Iteracyjne tworzenie oprogramowania, Inkrementalne dostarczanie oprogramowania, Prowadzenie kontroli wersji, aby zmiany mogły być wycofywane, Testowanie jest integralną częścią każdego etapu w projekcie,

Podstawową zaletą DSDM jest to, że produkt jest oceniany przez twórców i przyszłych użytkowników na każdym etapie projektowania i budowy. Uwagi powstałe w danej iteracji są oceniane i opracowywane w kolejnych iteracjach.

Przypisy

Linki zewnętrzne

Interaktywna, darmowa mapa myśli obrazująca metodykę DSDM

Kategoria:Procesy tworzenia oprogramowania Kategoria:Zarządzanie projektami