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 […]
  • Dlaczego warto używać metod Agile? Metody Agile skupiają się na krótszych iteracjach, w których to oprogramowanie dość często jest doprowadzane do takiego poziomu jakości, który pozwala na jego wydanie, zazwyczaj trwa to od […]
  • MSF for Agile Software Development v5.0 Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż […]
  • Demonstracja czyli o ważności informacji zwrotnej Jednym z moich zaleceń, związanych z nurtem Agile, jest: “Pokazuj to co zbudowałeś tak często jak się tylko da”. Należy zastosować to podejście, aby uzyskać informację zwrotną na temat […]
  • KILKA PORAD DLA MODELOWANIA WYMAGAŃ METODĄ AGILE Chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymogów metodą agile (i nie tylko). 1. "Niezwykle […]
Reklama

Zostaw komentarz

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