Dynamic Systems Development Method

Dynamic System Development Method – metodyka projektowania zaproponowana 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 (Business 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 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.

Linki zewnętrzne

• Główna strona konsorcjum DSDM. dsdm.org. [zarchiwizowane z tego adresu (2016-10-02)]. (ang.)
• Interaktywna, darmowa mapa myśli obrazująca metodykę DSDM (ang.)