Poprzednia

ⓘ Dynamic Systems Development Method




                                     

ⓘ 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.

                                     

1. 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.
  • 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.
  • Project Manager – kierownik projektu odpowiedzialny za synchronizację pracy zespołów.
  • Solution Developer – implementuje system, interpretuje wymagania systemowe oraz model systemu, dostarcza kod programu i buduje prototypy.
  • 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.
  • DSDM Coach – wspiera zespoły projektowe w procesie DSDM odpowiednik Agile Coacha w innych metodykach
  • Team Leader – dowodzi zespołem ludzi i zapewnia im stale możliwość efektywnej pracy. Charakteryzuje go tzw. podejście przywództwa służebnego.
  • 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.
  • 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.
  • 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.
                                     

2. Techniki obecne w 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ść,
  • 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ć
  • 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
  • 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.
  • Prototypowanie
  • Rozwój Iteracyjny
  • Codzienne Zbiórki
  • Modelowanie
  • Warsztaty Facylitowane
                                     

3. 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:

  • uwagi i komentarze użytkowników na temat prac w aktualnym cyklu Functional prototyping review documents,
  • wymagania niefunkcjonalne,
  • lista funkcji do opracowania wraz z ich priorytetami,
  • 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


                                     

4. Praktyki wprowadzane przez DSDM

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

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.

                                     
  • ekstremalne, scrum, Dynamic Systems Development Method Adaptive Software Development Crystal Clear, Feature Driven Development Pragmatic Programming
  • metoda abstrakcji ang. Abstraction Method Metoda rozwoju systemów dynamicznych ang. Dynamic Systems Development Method i inne, zaprojektowane dla zapewnienia
  • Programming Scrum Feature Driven Development Test - driven development Lean Software Development Dynamic Systems Development Method Agile Waterfall Methodologies
  • description, International Journal of Neuroscience, vol.107, 2001, 173 - 184. Dynamic systems theory approach to consciousness, International Journal of Neuroscience
  • Equipment DCO Device Configuration Overlay DCOM Distributed COM DDE Dynamic Data Exchange DDoS Distributed Denial of Service DDR Double Data Rate
  • Herwald, Recolections of the Early Development of Servomechanism and Control Systems November 1984, IEEE Control Systems Magazine. N.A. Kheir, K.J. Åström