Dynamic Systems Development Method

Dynamic System Development Method jest metodyką projektowania zaproponowaną przez brytyjskie konsorcjum DSDM.

DSDM należy do zwinnych metodyk programowania. We wczesnych latach dziewięćdziesiątych powstało określenie "Rapid Application Development" (RAD). 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 Dynamic System Development Method.

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ótki po jej wydaniu powstała odświeżona wersja V2, które wprowadział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. Jedna 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 AgilePF - Agile Project Framework.

Role projektowe

DSDM wyróżnia 12 ról w procesie tworzenia oprogramowania. Najważniejsze i najistotniejsze z nich to:

• Business Sponsor (Project Champion) - rola, mająca możliwość i uprawnienia zatwierdzać zmiany w projekcie oraz zdobywać potrzebne zasoby, materiały; ma decydujący głos w dyskusjach; sponsor projektu.
• Business Visionary - 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.
• Business Advisor - 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.
• Technical Advisor - 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.
• Project Manager - kierownik projektu odpowiedzialny za synchronizację pracy zespołów.
• Technical Coordinator - osoba odpowiedzialna za architekturę systemu, kontrolę realizacji oraz techniczną jakość projektu, odpowiedzialny za architekturę i jakość produktu, zarządza zmianami w projekcie.
• Business Ambassador - odpowiedzialny za przekazanie wiedzy od klienta, odpowiedzialny jest za całokształt projektu, zapewnia sprzężenie zwrotne programistom podczas implementacji.
• Team Leader - dowodzi zespołem ludzi i zapewnia im stale możliwość efektywnej pracy. Charakteryzuje go tzw. podejście przywództwa służebnego.
• Solution Developer - implementuje system, interpretuje wymagania systemowe oraz model systemu, dostarcza kod programu i buduje prototypy.
• Solution Tester - 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.
• Workshop Facilitator - 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
• DSDM Coach - wspiera zespoły projektowe w procesie DSDM (odpowiednik Agile Coacha w innych metodykach)

Techniki obecne w DSDM

• Timeboxing (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 - MUST have this - musi mieć tę funkcjonalność
  • S - SHOULD have this if at all possible - jeśli jest to możliwe to powinno mieć tę funkcjonalność,
  • C - COULD have this if it does not affect anything else - ta funkcjonalność jest potrzebna, pod warunkiem że nie wpłynie negatywnie na inne i efektywność systemu
  • W - WON'T have this time but WOULD like in the future - nie tym razem, ale w przyszłości tę funkcjonalność można by dołożyć
• Modelowanie
• Prototypowanie
• Warsztaty Facylitowane
• Codzinne 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 (Businnes Area Definition), specyfikacja zakresu systemu, zarys architektury systemu (System Architecture Definition) oraz Plan prototypowania (Outline Prototyping Plan).
• Iteracyjne opracowanie modelu funkcjonalnego (Functional model iteration) - 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 (Functional prototyping review documents),
• wymagania niefunkcjonalne,
• analiza ryzyka pod kątem dalszych prac,

• iteracyjne projektowanie i implementacja (Design and build iteration)

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 organiczonym 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 itworzenie oprogramowania,
• Inkrementalne dostarczania 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.

Link zewnętrzny

• Główna strona konsorcjum DSDM (ang.)
• Interaktywna, darmowa mapa myśli obrazująca metodykę DSDM (ang.)