Z uwagi na zainteresowanie moim projektem “demo” stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów.
Projekt Szachy ma na celu pokazanie na prostym przykładzie, toku analizy i produktów jakie tworzę w roli analityka i projektanta. Dokument ten może zawierać pewne braki (brak pewnych szczegółów) gdyż celem tego dokumentu jest zademonstrowanie zawartości tego rodzaju dokumentacji a nie szczegółowe opracowanie realnego projektu, będzie to jednak zaznaczone w treści.
Kliknij i pobierz aktualny plik projektu
Wszelkie pytania i sugestie na temat treści projektu proszę zgłaszać poniżej, będę na nie systematycznie odpowiadał.
Bardzo się cieszę, że coś takiego powstało! 🙂 Dobrze mieć konkretny wzór, z którego można się uczyć o dobrych praktykach. W końcu widać jak wygląda dobra dokumentacja i czy nasza bardzo od niej odbiega 🙂
Przy okazji mam kilka pytań i drobne uwagi.
Pytania:
2.1 Jak dzielić modele pojęciowe w przypadku występowania dużej liczby pojęć? Podzielenie modelu na kilka części powinno być przedstawione w ten sposób, że każde pojęcie posiada powiązanie z wszystkimi pojęciami, z którymi się wiąże? Skutkować to będzie pojawianiem się jednego pojęcia (powiązanego z największą liczbą pojęć) nawet na wielu innych częściach diagramu.
4.2 Powyższe pytanie także do struktury wymagań.
3. Czy model BMM jest zazwyczaj opisywany szerzej (np. wszystkie elementy) czy tylko jednym kluczowym zdaniem, jak w przykładzie?
3. Czy dopuszczalne jest pozostawienie zadania bez mierzalnego kryterium? Np. zysk ma się zwiększyć o x% lub x zł, ale klient nie potrafi odpowiedzieć jaki dokładnie zysk chce.
4.1 Jak rozróżnić wymagania biznesowe od ogólnie ujętych przypadków użycia?
6. Czy wykorzystuje Pan mapy procesów?
6. Czy uwzględnia Pan czynności wykonywane automatycznie przez systemy? Np. wysyłanie ofert klientom wykonuje się automatycznie. W jaki sposób uwzględnić to w procesie? Komu przypisać odpowiedzialność? Czy Działowi Marketingu, jeżeli teoretycznie leży to w jego kompetencjach, ale fizycznie on tej czynności nie wykonuje i nie podejmuje w tym celu żadnej akcji?
6. Co, jeśli czynność może być wykonywana przez dwie jednostki? Czy jest to propozycja do usprawnienia procesu, żeby to ujednolicić?
Co, jeśli proces może wziąć początek z dwóch różnych źródeł (np. zlecony wewnętrznie lub przez inną komórkę)? Czy jest to stan pożądany lub zwyczajny?
Jak zapisać takie warianty bez wchodzenia w zbytnie szczegóły na wykresie i tworzenia procedur?
? Czy nie włącza Pan do analizy organizacji działających w niej systemów? Wspieranych przez nie zadań i realizowanych funkcji. Czy ma to miejsce na etapie szczegółowej analizy wymagań? Wydaje mi się, że to ważna informacja dla potencjalnego wykonawcy z racji konieczności integracji, które wnosza ryzyko do projektu.
9.1 Co z analizą pokrycia zakresu projektu, jeśli projektowane rozwiązanie jest nowością w działalności organizacji (do tej pory nie mieli odpowiadających procesów)?
Uwagi:
1.3 Brak przykładowego zgłoszenia może powodować niejednakowe zrozumienie treści, jakiej spodziewa się autor dokumentu i przekazywania zgłoszeń w różnej formie.
Przykładem nowej treści byłby przykład lub kilka przykładów zgłoszeń w formie zalecanej przez autora.
1.3 Brak uzasadnienia, dlaczego numer strony nie może być identyfikatorem może powodować gorsze zapamiętywanie tego faktu w przypadku nie domyślenia się przyczyny.
Proponowane jest podanie przyczyny wykluczenia numeru strony przy podawaniu uwag.
8. Niedokończony opis – “Kluczowym celem tworzenia”
Szczególnie podobają mi się tabelki z weryfikacją kompletności i spójności. Świetna sprawa 🙂
ad.
2.1 Słownik pojęć, jeżeli się szybko rozrasta, to sygnał że coś jest nie tak z kryterium “kwalifikowania” pojęć do modelu, mechanizmem “kwalifikowania” są fakty (nie powinno być w słowniku niepowiązanych z niczym pojęć). To powinny być kluczowe pojęcia a nie “słownik branżowy”. Jeżeli się jednak coś rozrasta, na osobne diagramy można przenosić “samodzielne drzewa”, zostawiając korzeń drzewa na diagramie głównym. Pojawienie się jednego pojęcia na wielu diagramach nie jest niczym złym, to i tak to samo pojęcie…
4.2 z wymaganiami analogicznie, tu łatwiej, dzielimy jest tematycznie, wg. źródła pochodzenia itp..
3. Model BMM, jego postać i zakres, jest raczej zawsze kwestią potrzeby, umieszczam na nim to co pomaga a nie wszystko co wiem o firmie (to bardzo rzadko i raczej w projektach nieinformatycznych).
4.1 Moje studia nad “wymaganiami” doprowadziły do jednego wniosku: wymagania biznesowe to jest to co biznes uważa za wymagania (i jego językiem). Przypadki użycia pojawiają się dopiero gdy modelowane są “usługi systemu”. Nawet jeżeli “biznes” wyartykułuje z siebie “system ma pozwalać na wystawianie faktu VAT” to na tym etapie jest to nadal wymaganie biznesowe, o przypadkach użycia można mówić dopiero wtedy, gdy znane sa granice systemu, czyli “nieco dalej”.
6. Jeżeli jako mapę procesów rozumiemy diagram o tej nazwie z VP to dość rzadko i tylko na etapie bardzo ogólnych “rozważań”. Bywa, że dokumentuję w ten sposób jakieś specyficzne scenariusze na wysokim poziomie abstrakcji (co widać czasami na blogu :))
Temat automatycznych czynności wymaga ustalenia pewnej pragmatyki (konwencji). Ja z powodzeniem stosuję zasadę: nawet czynność automatyczna jest dziełem kogoś kto ją wcześniej “opisał” i powinna być ona przyporządkowana do osoby odpowiedzialnej za jakość wyników tego automatycznego procesu (zakładam, że jest bo jak nie eskaluje to do sponsora projektu). Przypominam, że analiza procesów to także ich porządkowanie (i porządkowanie wiedzy o nich).
W czasie analizy pierwszy etap to zrozumienie to co i po co się dzieje, dopiero po tym ma miejsce sprawdzanie do czego jakich narzędzi użyto. W przeciwnym wypadku można nie “odkryć” że w banku 90% kredytów jest ocenianych “w locie” automatycznym scoringiem.
9.1 Zakres projektu do model przypadków użycia. Zakres pokrycia wymagań to macierz wymagania biznesowe vs. przypadki użycia.
1.3 W kwestii uwag: mając historyczne uwagi, kilka ich iteracji, prawie na pewno numery stron nie będą się zgadzały z pierwotną wersją, w efekcie nie bezie możliwe odwzorowanie “życia” jakiegoś zapisu. (jakiś przykład zgłoszenia opracuję ;))
8. fakt, dokument jest rozwojowy (moje alibi)
Podobnie jak Hania, cieszę się, że taki dokument powstał. Liczę ponadto, że będzie on systematycznie rozwijany i uzupełniany. Zgodzę się również, że konsekwentne śladowanie wymagań i weryfikacja spójności to świetna sprawa ? niestety praktycznie niewykonalne bez udziału narzędzi takich jak VP.
Poniżej moje pytania i uwagi do zawartości.
2.1 Model pojęciowy
Model, moim zdaniem, zbytnio uproszczony ? nawet jak na ?demo?. Pojęcie ?Książka? nie jest do końca jednoznaczne – w rzeczywistości czytelnik wypożycza konkretny egzemplarz książki. W opisanym modelu dane o książce (wraz ze streszczeniem) zawarte są w jej kartotece – ciężko mi sobie wyobrazić sytuację, w której streszczenie książki zawarte jest w kartotece każdego z jej egzemplarzy. Dlatego też powinny pojawić się w tym miejscu dwa pojęcia, np. ?Publikacja? (identyfikowana przez ISBN, zawierająca dane o książce) oraz ?Książka? rozumiana jako konkretny egzemplarz danej publikacji.
3. Cel biznesowy ? diagram BMM: Ocena możliwości realizacji projektu
– Dlaczego taka nazwa diagramu? BMM to przedstawienie uzasadnienia prowadzonych działań – wskazanie powiązań z przyjętymi celami, które realizacja działań wspiera. Nie rozumiem, jaki to ma związek z oceną możliwości realizacji projektu.
– Skąd tłumaczenia (np. objective -> zadanie)?
– Zadanie: ?Skrócenie procedury wypożyczenia?:
Brzmi jak jednorazowe zadanie, a nie ?stan?, do którego dąży Biblioteka. Ponadto brakuje określenia terminu realizacji. Osobiście zapisałbym bym to np. tak: ?Do końca bieżącego roku obsługiwać wypożyczenia w czasie poniżej 5min?.
– Taktyka: ?Automatyzacja wszystkich czynności nie wymagających decyzji Bibliotekarza?:
Podobnie jak wyżej – brzmi jak jednorazowe zadanie, a nie ?przyjęte podejście? realizujące postawiony cel. Zapisał bym to tak: ?Automatyczna realizacja czynności nie wymagających decyzji Bibliotekarza?.
4.1 Specyfikacja wymagań biznesowych ? zestawienie: Wymaganie biznesowe
– Zakładam, że ?BR? odnosi się do ?business requirement?. Dokument jest w j. polskim, dlatego też odpowiedniejsze było by ?WB?. Ponadto używa Pan ?BR? także do identyfikacji reguł biznesowych, co stwarza ryzyko niejednoznacznej identyfikacji różnych konceptów.
– BR04/BR05: dlaczego używany jest termin ?Klient?, skoro wcześniej zdefiniowane został termin ?Czytelnik??
4.2 Struktura wymagań ? diagram: Wymagania
– Co to za notacja?
4.3 Weryfikacja wymagań biznesowych ? diagram macierzowy: Weryfikacja Wymagań Biznesowych
– Dlaczego nie są wykorzystane wprowadzone wcześniej identyfikatory wymagań?
– Jak by to wyglądało w przypadku większej ilości wymagań, strategii lub taktyk? Czy umieszcza Pan w takich przypadkach diagram w oddzielnym dokumencie?
6.1 Rejestracja czytelnika
– Diagram zawiera zdarzenie końcowe typu ?message? bez wskazania wysyłanej wiadomości. Nie jest to sprzeczne z regułami BPMN, ale wprowadza okazję do odmiennych interpretacji diagramu (?Czy chodzi o potwierdzenie wysłane w poprzedzającym zadaniu, czy też jakaś inna wiadomość jest wysyłana??). Jeżeli żadna inna wiadomość nie jest wysyłana, to zdarzenie powinno być bez typu, tym bardziej, że w ścieżce z przekroczonym okresem oczekiwania na potwierdzenie żadna wiadomość nie jest wysyłana.
– Czy ?Karta czytelnika? to to samo co zdefiniowana wcześniej ?Kartoteka czytelnika??
6.2 Obsługa wypożyczeni
– ?Karta wypożyczeń książki? ? czy to pojęcie nie powinno być zdefiniowane w modelu pojęciowym?
9 Wymagania funkcjonalne
Ewidentnie brakuje usługi ?Wyszukiwanie książki?.
2.1. Tu książka to element księgozbioru (a więc egzemplarz), milcząco jest to ?prosta biblioteka?, czyli każda pozycja wydawnicza ma w niej jeden tylko egzemplarz (co jest często spotykanym przypadkiem). Projekt (jego dalsza część) jest konsekwencją początkowych założeń (kontekst projektu). Jakieś musiałem przyjąć, by projekt nie rozrastał się w niekontrolowany sposób. Ważna rzecz: to treść dokumentu należy interpretować literalnie zgodnie z podanym słownikiem (po to powstaje) ale nie rozważać poprawność danej definicji. Celem słownika jest uzyskanie jednoznaczności dokumentu a nie korekta słownika języka polskiego. Podam przykład: pewien mój klient używał na każde zdanie wewnętrzne terminu ?temat? (np. temat sprzedażowy, temat produkcyjny, temat kontrahenta). Słownik pojęć jaki powstał miał za zadanie doprowadzenie do jednoznaczności tych pojęć a nie walkę z członkiem zarządu który tego niejednoznacznego terminu – temat – używał.
3. Nazwa diagramu odzwierciedla cel w jakim powstał. Typ diagramy to ?model motywacji biznesowej?. Co do tłumaczenia to jest ono raczej efektem analizy metamodelu, długo się nad nim zastanawiałem, być może je kiedyś zmienię ;)) ale ?od góry? mamy: wizja, cel, zadanie. Wizja i misja zostały tu celowo pominięte (może to nadrobię) Jeżeli celem jest Sprawna obsługa klienta to osiągnięcie konkretnego ?rezultatu? jest ?zadaniem do osiągnięcia? i moim zdaniem tak należy odbierać metamodel BMM, to typowe tłumaczenie kontekstu a nie literalne słownikowe (nie twierdze że najlepsze ale na razie… ;)).
Taktyka to ?sposób w jaki coś należy zrobić?, pamiętajmy, że ?strategia? to coś długoterminowego, a taktyka to sposób wcielania strategii w życie (taktyka implementuje strategię, wojnę prowadzimy zgodnie z przyjętą strategią, na poszczególne bitwy opracowujemy konkretną taktykę). Tak więc taktyka to ?zadanie?, polegające na doprowadzeniu stanu obecnego jakiegoś obszaru do stanu zgodnego z przyjętą strategią.
Wpisanie do zadania, ?Do końca roku?? powoduje, że łączymy harmonogram z zadaniem a to nadużycie, zadanie samo z siebie nie determinuje terminu, termin przyjmujemy odrębnie. Np. zlecamy komuś zadanie napełnienia wodą basenu, ale raz możemy ustalić termin na godzinę a innym razem na całą noc, zadanie (napełnienie basenu) nie ulega zmianie. Analogicznie mamy w “trójkącie? projektowym: budżet, zakres (zadanie do realizacji) i termin, to niezależne zmienne (ale jako “trójkąt” mają wzajemne ograniczenia).
4.1. Uwaga słuszna, zmienię.
4.2. Diagram wymagań SysML (profil UML, rozszerzenie UML)
4.3. Identyfikatorem (co przemilczałem) jest także nazwa (z zasady musi być unikalna). Pomyślę co z tym zrobić bo to może być nieoczywiste.
6.1. w BPMN nie jest wymagane wskazywanie adresata komunikatu (z zasady i tak jest w jego treści), tu błąd (poprawiam) to użycie Komunikatu zamiast Sygnału (mój nawyk z BPMN 1,1 gdzie nie było rozróżnienia pomiędzy komunikatem a sygnałem). Proces poprawiony, dodano ?rejestr? i wyjaśniła się kwestia Kartoteki.
6.2. Model pojęciowy nie ma na celu planowanie ?klas? a zdefiniowanie przestrzeni pojęciowej projektu ? zapobieżeniu niejednoznaczności. Tak więc Kartoteka nie jest ?uniwersalnym pojęciem słownikowym? a konkretnym przedmiotem w tym projekcie. Słownik pojęciowy tworzy się w ten sposób, że kolejne pojęcia definiuje się wyłącznie wtedy gdy są kontekstowo powiązane i rodzą ryzyko niejednoznaczności (jaki fakt z dziedziny problemu łączy nowe pojęcie z już istniejącym i jest taki fakt). Pamiętajmy, że systemu pojęć używamy np. w nazwach klas a nie do przekształcania ich w klasy (co jest ogromna różnicą).
9. Wyszukiwanie książki ?wyleciało? bo nie jest wymaganiem funkcjonalnym, wymaganie funkcjonalne to przypadek użycia oprogramowania. W UML Przypadek użycia to usługa systemu świadczona aktorowi, cechuje się tym, że stanowi odrębna wartość dla aktora. Tu nie jest celem ?sponsora? udostępnianie komukolwiek usługi polegającej jedynie na samym stwierdzaniu czy dana pozycja jest w zbiorach (np. sprawdzanie przez konkurentów). To znaczy, że samo wyszukiwanie do niczego nie służy, wyszukiwanie jest elementem ? jeden z pierwszych kroków scenariusza ? rezerwacji książki do wypożyczenia. Bardzo często w projektach widuję klasyfikowanie jako ?funkcjonalności? fragmentów scenariuszy przypadków użycia (np. rozwijana lista kontrahentów). Jest to zresztą nierozstrzygalne, jeżeli nie zdefiniujemy sobie czym jest przypadek użycia. Ja przyjmuje najprostsza wersje bazująca na ?semantic core? w OMG. Znaczy to, że atomowy proces w BPMN mapuje się na przypadek użycia. Jeżeli więc nie planujemy samodzielnego ?działania? jakim mogło by być ?wyszukiwanie? to znaczy, że nie ma takiego przypadku użycia.
Co do zasady przypadki użycia w UML nie są z sobą powiązane (zrezygnowałem z wielu powodów z korzystania konstrukcji Include i Extend bo to próba ?relacyjnej normalizacji? kroków scenariuszy, temat na inny artykuł), to ?aktor? (i proces biznesowy) wie w jakiej kolejności zostaną użyte ?narzędzia? (poszczególne narzędzia w skrzynce narzędziowej nie są z sobą w żaden sposób powiązane, ewentualna konkretna kolejność ich użycia wynika z kontekstu pracy a nie z samych narzędzi).
Dzień dobry,
Odwołanie do pliku PDF z projektem prowadzi w próżnię. Czy mógłby Pan zaktualizować linka ?
Pozdrawiam serdecznie
Grzegorz Wojdyła
Zaktualizowane (na szachy).
Zmieniłem bibliotekę na szachy 🙂 (link w treści artykułu)