Zwinne modelowanie

Agile modeling ( AM ) to metodologia modelowania i dokumentowania systemów oprogramowania oparta na najlepszych praktykach. Jest to zbiór wartości i zasad, które można zastosować w (zwinnym) projekcie tworzenia oprogramowania. Ta metodologia jest bardziej elastyczna niż tradycyjne metody modelowania, dzięki czemu lepiej pasuje do szybko zmieniającego się środowiska. Jest częścią do zwinnego tworzenia oprogramowania .

Modelowanie zwinne jest uzupełnieniem innych zwinnych metodologii programistycznych, takich jak Scrum , Extreme Programming (XP) i Rational Unified Process (RUP). Jest wyraźnie uwzględniony jako część zdyscyplinowanej zwinnej dostawy (DAD). Według statystyk z 2011 r. modelowanie zwinne stanowiło 1% całego zwinnego tworzenia oprogramowania.

Modelowanie zwinne to jedna z form inżynierii opartej na modelach Agile (Agile MDE), która została przyjęta w kilku obszarach zastosowań, takich jak tworzenie aplikacji internetowych, finanse i systemy motoryzacyjne

Podstawowe praktyki

Istnieje kilka podstawowych praktyk:

Dokumentacja

  1. Dokumentuj w sposób ciągły. Dokumentacja tworzona jest przez cały cykl życia, równolegle z tworzeniem pozostałej części rozwiązania.
  2. Dokument spóźniony. Dokumentacja jest tworzona tak późno, jak to możliwe, unikając spekulacyjnych pomysłów, które prawdopodobnie zmienią się na korzyść stabilnych informacji.
  3. Wykonywalne specyfikacje. Wymagania są określane w formie wykonywalnych „testów klienckich” zamiast niewykonywalnej „statycznej” dokumentacji.
  4. Informacje z jednego źródła. Informacje (modele, dokumentacja, oprogramowanie) są przechowywane w jednym i tylko jednym miejscu, aby zapobiec pytaniom o to, jaka jest „poprawna” wersja / informacja.

Modelowanie

  1. Aktywny udział interesariuszy. Interesariusze modelowanego rozwiązania/oprogramowania powinni być w to aktywnie zaangażowani. Jest to rozszerzenie praktyki obsługi klienta na miejscu z programu Extreme Programming .
  2. Wizja architektury. Zespół wykonuje lekkie modelowanie na wysokim poziomie, które jest ledwie wystarczająco dobre (JBGE) na początku projektu oprogramowania, aby zbadać strategię architektury, która według zespołu będzie działać.
  3. Narzędzia integracyjne. Preferuj narzędzia do modelowania, takie jak tablice i papier, z którymi łatwo się pracuje (są one dołączone).
  4. Modelowanie iteracyjne. Kiedy wymaganie/element pracy nie został wystarczająco szczegółowo zbadany za pomocą modelowania wyprzedzającego, zespół może zdecydować się na przeprowadzenie tej eksploracji podczas sesji planowania iteracji/sprintu. Konieczność zrobienia tego jest ogólnie postrzegana jako objaw tego, że zespół nie wykonuje wystarczającego modelowania wyprzedzającego.
  5. Ledwo wystarczająco dobre (JBGE). Wszystkie artefakty, w tym modele i dokumenty, powinny wystarczyć do danego zadania. JBGE ma charakter kontekstualny, w przypadku modelu jest określany przez połączenie złożoności tego, co opisuje model, oraz umiejętności odbiorców tego modelu.
  6. Modelowanie z wyprzedzeniem. Zwinny zespół przejrzy swoje zaległości o jedną lub więcej iteracji/sprintów do przodu, aby upewnić się, że wymaganie/element pracy jest gotowy do pracy. Nazywany również „uporządkowaniem zaległości” lub „udoskonalaniem zaległości” w Scrumie .
  7. Modelowy szturm. Krótka, często improwizowana, zwinna sesja modelowania. Sesje burzy modeli odbywają się w celu zbadania szczegółów wymagania lub aspektu projektu.
  8. Wiele modeli. Modelarze Agile powinni wiedzieć, jak tworzyć różne typy modeli (takie jak historie użytkowników, mapy historii, modele danych, diagramy UML i inne), aby zastosować najlepszy model w danej sytuacji.
  9. Priorytetowe wymagania. Nad wymaganiami należy pracować w kolejności priorytetów.
  10. Przewidywanie wymagań. Zespół wykonuje lekkie modelowanie wysokiego poziomu, czyli JBGE na początku projektu oprogramowania w celu zbadania wymagań interesariuszy.

Ograniczenia

Istnieje znaczna zależność od komunikacji osobistej i współpracy z klientem. Dyscypliny modelowania Agile mogą być trudne do zastosowania [ potrzebne źródło ] :

  • W dużych zespołach (powiedzmy 30 lub więcej) bez odpowiedniego wsparcia narzędziowego
  • Gdzie członkowie zespołu nie są w stanie dzielić się i współpracować nad modelami (co generalnie utrudniałoby zwinne tworzenie oprogramowania )
  • Gdy umiejętności modelowania są słabe lub ich brakuje.

Zobacz też

Linki zewnętrzne