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
- 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.
- 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.
- Wykonywalne specyfikacje. Wymagania są określane w formie wykonywalnych „testów klienckich” zamiast niewykonywalnej „statycznej” dokumentacji.
- 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
- 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 .
- 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ć.
- Narzędzia integracyjne. Preferuj narzędzia do modelowania, takie jak tablice i papier, z którymi łatwo się pracuje (są one dołączone).
- 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.
- 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.
- 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 .
- Modelowy szturm. Krótka, często improwizowana, zwinna sesja modelowania. Sesje burzy modeli odbywają się w celu zbadania szczegółów wymagania lub aspektu projektu.
- 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.
- Priorytetowe wymagania. Nad wymaganiami należy pracować w kolejności priorytetów.
- 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.