Więcej wskazówek dotyczących modelowania Agile
Kilkanaście dni temu opublikowałem 5 porad dotyczących analizy AGILE autorstwa Scotta Amblera. Teraz chciałbym je uzupełnić o dalsze spostrzeżenia. Tym razem głównie o modelkach.
1. Modele ewoluują w czasie
Możesz zacząć od podstawowego przypadku, ale szybko zdecyduj się na przekształcenie go w kilka systemowych przypadków użycia. Możesz także opracować diagram obiektu ról (ORM) tablicy ustawiony jako dane wejściowe do diagramu klas UML, który z kolei zamieni się w kod źródłowy.
2. Modele analityczne muszą być tylko wystarczająco dobre
Utrzymuj swoje modele tak proste i suplementkie, jak to tylko możliwe. Skoncentruj się na zrozumieniu, a nie na dokumentacji. Korzystaj z najprostszych i najbardziej ogólnych dostępnych narzędzi. Uświadom sobie, że Twoje modele nie muszą być idealne.
3. Każdy model może być używany do wielu celów
Diagramy przepływu danych mogą być wykorzystywane zarówno jako technika analizy do badania istniejących procesów biznesowych, jak i jako technika projektowania do ich redefinicji. Podobnie modele Class Commitment Collaboration (CRC) mogą być wykorzystywane zarówno do celów analizy, jak i projektowania, a także przypadków użycia do wymagań, analizy, a czasem nawet projektowania.
4. Linie modelowania są często rozmyte
Tradycyjna koncepcja faz rozwoju oprogramowania – wymagania, analiza, projektowanie, kodowanie, testowanie i implementacja – sprawiła, że wiele osób uwierzyło, że musimy dokonać rozróżnienia między różnymi typami modelowania. Jeśli jednak zainteresowana osoba przedstawi nam opis wymagania, np. konieczność uzyskania adresu domowego studenta, często przechodzimy przez te fazy w kilkusekundowych odstępach. Zaczniemy myśleć o tym, jak powinien wyglądać interfejs użytkownika, o różnych elementach danych, które należy pozyskać, o potrzebie klasy Addresses, o możliwości wykorzystania wzorca Contact Point, o potrzebie stworzenia Tabeli Adresów w bazy danych i jak napisać kod do tego wszystkiego w Javie. tym samym odejście od wymagania przez analizę i projektowanie do pisania kodu bez zatrzymywania się w celu stworzenia kompletnego modelu wymagań lub kompletnego modelu analizy itp. Ponieważ ważne jest zadawanie pytań typu: czego potrzebujesz (wymagania), co to oznacza (analiza) i jak zamierzamy to zbudować (projekt), często będziemy to robić w sposób iteracyjny, a nie seryjny.
5. Używaj tej samej terminologii, co interesariusze
- Nie zmuszaj interesariuszy projektu do używania sztucznego, technicznego żargonu. To dla nich tworzony jest system; dlatego powinieneś używać ich terminologii w swoim modelu systemu.
- Technorati Tagi: agile, zwinne modelowanie, modelowanie, UML, Unified Modeling Language
Podobne wpisy - BPMN vs diagramy aktywności
Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście bardziej
5 wskazówek dotyczących analizy AGILE
Scrott Ambler kilka miesięcy temu opublikował 5 wskazówek, które powinny poprawić analizę pod kątem AGILE. Oto one: 1. Aktywny udział więcej
Specyfikacja komponentów i interfejsów w Enterprise Architect
Projektując systemy na poziomie komponentów, ważne jest właściwe określenie kanałów komunikacji pomiędzy komponentami. Więcej informacji poniżej
Co nowego w UML 2.2
Kilka tygodni temu pisałem o specyfikacji UML w wersji 2.2. Obiecałem wtedy, że kiedy będę to recenzował, napiszę o zmianach. jeszcze