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

  • 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ł osób zainteresowanych jest najbardziej istotny […]
  • Kanban w Enterprise Architect 13 część 2 W poprzednim tygodniu pisałem o kanban w Enterprise Architect (Kanban w Enterprise Architect 13 część 1). Dziś postaram się przedstawić mechanizmy raportowania a dokładniej wykresy w […]
  • 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 modelowania procesów biznesowych i systemowych (patrz […]
  • Kiedy nie działa zwinne modelowanie? Czy zwinne modelowanie działa zawsze? Otóż nie. Zazwyczaj z podejściem Agile są problemy gdy opisujemy procesy w dużych firmach, gdzie istnieje: duża ilość procesów problemy są oparte o […]
  • Planowanie w projekcie w nurcie Agile Planując pracę  swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one: Plan szczegółowy buduję jedynie dla najbliższych zadań. Moim zadaniem użyteczne są plany […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry