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
UML – zastosowanie w biznesie

Po raz kolejny Centrum Promocji Informatyki zorganizowało seminarium związane z wykorzystaniem języka UML w biznesie. W tym przedsięwzięciu miałem swój więcej

Software Project Management GigaCon

Trzecia edycja konferencji Software Project Management GigaCon (25-26 września) to kolejna okazja na wymianę w szerszym gronie zagadnień związanych z więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Modelowanie systemów informatycznych w języku UML 2.1

Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski Seria: W praktyce Wydawnictwo Naukowe PWN Warszawa, 2007 r. ISBN: 978-83-01-15251-2 Wydanie: pierwsze Objętość: więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry