Dynamic Systems Development Method

Dynamic System Development Method – metodyka 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ó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 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 do zatwierdzania zmian w projekcie oraz do pozyskiwania wymaganych zasobów i materiałów; 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
  • 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 (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 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 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.

Linki zewnętrzne