Kolejne wskazówki dotyczące modelowania w ujęciu Agile

Kilkanaście dni temu  opublikowałem 5 wskazówek dla analizy w ujęciu AGILE Scotta Amblera. Chciałbym je teraz uzupełnić o kolejne spostrzeżenia. Tym razem dotyczące przede wszystkim modeli.

1. Modele z czasem ewoluują
Możesz zacząć od podstawowego przypadku, ale szybko postanowisz przekształcić go w kilka systemowych przypadków użycia. Możesz również postanowić opracować zbiór diagramów Object-Role Model (ORM) umieszczone na białej tablicy jako wkład w diagram klas UML, który z kolei przekształci się w kod źródłowy.

2. Modele analiz muszą być jedynie wystarczająco dobre

Staraj się, aby twoje modele były jak najbardziej proste i o lekkiej konstrukcji. Skup się na zrozumieniu, nie na dokumentacji. Użyj najprostszych i najbardziej ogólnych z dostępnych narzędzi. Zdaj sobie sprawę z tego, że Twoje modele nie muszą być doskonałe.

3. Każdy model może zostać użyty dla wielu celów

Diagramy przepływu danych można użyć zarówno jako techniki analizowania w celu zbadania istniejących procesów biznesowych jaki i jako techniki projektowania, aby je zdefiniować na nowo. Podobnie, modele Klasa Zobowiązanie Współpraca (CRC) mogą być użyte zarówno dla celów analizy i projektowania jak i dla przypadków użycia dla wymagań, analiz, a czasem nawet projektowania.

4. Linie modelowania są często niewyraźne
Tradycyjna koncepcja faz tworzenia oprogramowania – wymagania, analiza, projekty, kodowanie, testowanie i wdrażanie – pozostawiło u wielu osób przekonanie, że musimy dokonać rozróżnienia pomiędzy różnymi rodzajami modelowania. Ale jeśli osoba zainteresowana poda opisze nam jakiś wymóg, jak na przykład potrzebę zdobycia adresu domowego studenta, to często przejdziemy przez te fazy w odstępach kilku sekund. Zaczniemy myśleć o tym, jak powinien wyglądać interfejs użytkownika, o różnych elementach danych, jakie mają zostać zdobyte, o potrzebie klasy Adresy, możliwości zastosowania wzoru Contact Point, potrzebie stworzenia tabeli Adresowej w bazie danych, i jak napisać kod dla tego wszystkiego w javie, tym samym odchodząc od wymogu poprzez analizę i projektowanie do pisania kodu bez zatrzymywania się aby stworzyć kompletny model wymagań, czy też kompletny model analiz, itd. Jako że istotnym jest zadawać pytania takie jak czego potrzebujesz (wymogi), co to oznacza (analiza) i jak zamierzamy to zbudować (projekt), często będziemy to robić w sposób iteracyjny, nie seryjny.

5. Używaj tej samej terminologii co udziałowcy

Nie zmuszaj udziałowców Twojego projektu do używania sztucznego, technicznego żargonu. To dla nich system jest tworzony; dlatego też w modelu systemu powinieneś użyć ich terminologii.

Technorati Tagi: agile,agile modeling,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 więcej

5 wskazówek dla analizy w ujęciu AGILE

Scrott Ambler kilkanaście miesięcy temu opublikował 5 wskazówek, które powinny usprawnić analizę w ujęciu AGILE Oto one: 1. Aktywny udział więcej

Specyfikacja komponentów i interfejsów w Enterprise Architect

W trakcie projektowania systemów na poziomie komponentów istotnym jest aby dobrze wyspecyfikować kanały komunikacji pomiędzy komponentami. Poniżej w tekście tym, więcej

Nowości w UML 2.2

Kilka tygodni temu pisałem o specyfikacji UML w wersji 2.2. Obiecałem wtedy, że jak ją przejrzę to napiszę o zmianach. więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry