Autor: Jacek Sałacki

Przypadki użycia – przykład

 

W jednym ze wcześniejszych wpisów 1, przedstawiłem moje uwagi dt. przypadków użycia. Na końcu obiecałem, że dodam jeszcze trochę praktycznych przykładów. I właśnie tym chciałbym się dziś zająć. Chciałem, aby przedstawione przykłady były „wzięte z życia”, dlatego są oparte na pewnym projekcie, który realizowałem. Przedstawię w skrócie problem, tak aby można było uchwycić o co w nim chodzi, a jednocześnie opis nie był zbyt angażujący. W oparciu o te informacje, przeprowadzę skróconą wersję analizy wymagań, efektem której będzie przypadek użycia, zapisany w formie szkicu Czytaj dalej Przypadki użycia – przykład

  1. Poniższy wpis przeleżał dłuższy czas w poczekalni na ostateczny szlif, dlatego pojawia się dopiero teraz. Spodziewajcie się dalszych wpisów wyciągniętych z archiwum. Trochę się tego zebrało. ↩

Lista życzeń

Projekty informatyczne, przynajmniej te prowadzone w naszym kraju, cierpią często na trudną przypadłość którą określam jako „lista życzeń”. Dotyczy to przede wszystkim projektów, które mają być realizowane przez zewnętrznych dostawców a przez to muszą mieć zdefiniowany w sposób formalny zakres. W założeniu – tego typu oficjalny opis powinien definiować przedmiot zamówienia w sposób ścisły i na tyle szczegółowy, że możliwe będzie oszacowanie pracochłonności i kosztów. To w teorii. Niestety w praktyce, często tego rodzaju dokumenty pt. Opis Przedmiotu Zamówienia nie są zbyt szczegółowe, a nawet więcej – ich forma i treść są problematyczne.

Czytaj dalej Lista życzeń

Ilustrowana instrukcja oddychania w 10 krokach

Znacie to? Dostajecie do zapoznania się Bardzo Ważną Dokumentację ver. 20 Kluczowego Systemu. Otwieracie dokument, patrzycie się na ilość stron jakie zostały wyprodukowane („no, no… 150 stron, to musi być masa informacji”) . Więc z zapałem zabieracie się do czytania. I..? I porażka – okazuje się, że dokument jest tak naprawdę pusty – połowa „treści” to rysunki, które nic nie wnoszą, reszta to wygenerowany z automatu opis tych rysunków, najczęściej całkowicie pusty lub też zaprezentowane diagramy są banalne, informacje się powtarzają. Nie dość że nie ma z nich żadnego pożytku to jeszcze wprowadzają chaos informacyjny: zaciemniają inne, potencjalnie ważne dane, powodują że w masie nieistotnych danych ginie to co jest kluczowe.

Czyli tym razem będzie o jakości dokumentacji. O tym co można zrobić źle pisząc dokumentację, ze wskazaniem na możliwe przegięcia – tak co za dużo to niezdrowo. I o tym jak sobie poradzić z tym tematem.

Czytaj dalej Ilustrowana instrukcja oddychania w 10 krokach

Nasz TLA jest dobry na wszystko

Dziś będzie o chorobie zwanej przeze mnie toolizmem informatycznym 12. Czyli o cudownych rozwiązaniach.

Czytaj dalej Nasz TLA jest dobry na wszystko

  1. od tool – czyli narzędzia; oczywiście inne branże nie są wolne od tej przypadłości, jednak to najbardziej u nas się objawia, bo w końcu wszystko w informatyce kręci się wokół narzędzi – robimy narzędzia, przy pomocy narzędzi, zrobionych innymi narzędziami ↩
  2. tak, tak, ten -izm dobrze się wam kojarzy ↩

Węgierski diagram

Zdarzyło mi się uczestniczyć ostatnio w dyskusji o kierunkach rozwoju zawodowego analityka. Dyskusja, jak to dyskusja na forum internetowym, nie doprowadziła do żadnych sensownych wniosków, tylko swobodnie odpłynęła. Jednym z kierunków, którym podążyli dyskutanci, były rozważania o wyższości BPMNa nad UML (a właściwie nad czymkolwiek innym). BPMN jest ostatnio w modzie, więc szybko ujawniła się grupa wiernych fanów i kibiców, rzucająca całą litanią zalet tego języka. Dziwnym trafiem prawie wszystkie brzmiały bardzo podobnie do marketingowych haseł, reklamujących BPMNa w różnego rodzaju whitepaperach. W szczególności spodobała mi się takie hasło:

BPMN jest łatwy, prosty i intuicyjny. Każdy go rozumie.

Czyli bierzemy pierwszego lepszego człowieka z ulicy (dobra, niech będzie – dowolnego klienta dla którego robimy system informatyczny), rzucamy mu dowolny diagram BPMNa z procesami, a on na to: „Aha – tak o to chodzi, ten proces idealnie obrazuje wszystkie niuanse naszego sposobu pracy”. BPMN odwalił za nas całą robotę – narysowaliśmy diagramik i wszystko już dla każdego jest jasne i oczywiste: doskonałe zrozumienie wymagań i oczekiwań klienta, doskonałe i pełne zrozumienie produktu który wykonawca dostarczy. Analityczna nirvana.

Czytaj dalej Węgierski diagram

Jaką metodykę pan woli?

Ostatnio, na pewnej rozmowie, w pewnej ważnej sprawie, dostałem takie właśnie pytanie: „A jaką metodykę pan woli, agile czy ciężką?”. Chyba jednak nie udzieliłem oczekiwanej odpowiedzi, bo powiedziałem mniej-więcej: „a taką, która działa”. Co prawda, moja wypowiedź była trochę dłuższa i trochę bardziej łagodna, ale sens był właśnie taki. Dziś więc będzie o tym co jest lepsze, agile czy ciężkie metodyki, a w zasadzie o tym, że takie porównanie nie ma sensu bez określenia kontekstu w którym działamy.

Czytaj dalej Jaką metodykę pan woli?

Reaktywacja

Nawet nie zauważyłem kiedy minęło 2,5 roku od ostatniej publikacji. Troszkę się ten blog przykurzył, jednak postaram się go odświeżyć, wrzucić materiały które siedzą od dawna w poczekalni i utrzymywać w miarę stabilne tempo publikacji. W najbliższym czasie będzie m.in o tym która metodyka prowadzenia projektów jest najlepsza, kontynuacja tematu przypadków użycia, BPMNie.

Biznesowe przypadki użycia

Przez książki, tutoriale, blogi dotyczące inżynierii oprogramowania przewijają się różne epitety 1, określające przypadki użycia. W szczególności dwa określenia pojawiają się często – systemowe lub biznesowe przypadki użycia. Przeważnie jednak, autorzy używający tych sformułowań nie wspominają co właściwie przez nie rozumieją. Niestety, podobnie jak w przypadku wielu innych pojęć IT, tak i tu każda osoba używająca tego określenia może mieć coś innego na myśli. Jak więc odróżnić systemowy od biznesowego i kiedy ma sens stosowanie takich określeń? Czytaj dalej Biznesowe przypadki użycia

  1. w znaczeniu przymiotnik opisujący cechę ↩

Agile Development. Filozofia programowania zwinnego

Okładka książkiPrzyszedł czas na poruszenie tematów bardziej związanych z samym tworzeniem oprogramowania a nie tylko z samym opisem(modelowaniem) wymagań. Zaczniemy od omówienia książki „Agile Development. Filozofia programowania zwinnego”. Dotyczy, jak tytuł wskazuje, modnych ostatnio zwinnych procesów wytwarzania oprogramowania. Autorzy opisują metodyki agile w wydaniu Extreme Programming, chociaż opowiadają także ogólnie o filozofii agile. Czytaj dalej Agile Development. Filozofia programowania zwinnego

Przypadki użycia

Kilka postów wcześniej wspomniałem o tym, że nie cierpię diagramów przypadków użycia. Skrytykowałem to narzędzie m.in. za, ukrywanie tego czym przypadki użycia naprawdę są. Nie wspomniałem jednak czym właściwie są te przypadki użycia. Pojęcie jest znane od przynajmniej kilkunastu lat (1994?), czy jednak wszyscy używający tego pomysłu wiedzą o co chodzi? Postaram się w skrócie opowiedzieć jak ja posługuję się przypadkami użycia. Dziś skupię się raczej na tym jak zastosować przypadki użycia, jak je rozumieć. Do tego jak je opisać wrócę, mam nadzieję, w którymś z kolejnych wpisów. Czytaj dalej Przypadki użycia