April 2013 – JZ IT Consulting Ltd

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Post author:Jaroslaw Zelinski
Post published:27 April 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Na konferencjach i forach toczą się stale dyskusje na ten temat. Większość firm doradczych, informatycznych i ich analitycy bronią tezy, że celem analizy jest zebranie informacji w postaci dokumentów i zestawień. Niestety takie dokumenty są kompletnie nieprzydatne, mają wartość nagrania (patrz wyżej zdjęcie lotnicze), nie da się na ich postawie wyciągać żadnych pozwalających na dowodzenie ich słuszności, wniosków nie licząc może oceny estetyki edytorskiej. Niewątpliwą "zaletą takiej analizy" jest to, że nie wymaga ona absolutnie żadnych kompetencji poza umiejętnością komunikacji. Takim analitykiem może być niemalże każdy (łatwa rekrutacja, niski koszt), ale czy taki jest cel analiz poprzedzających projekty, warte setki tysięcy złotych a nie raz miliony? Na zakończenie dodam, że najgorszym sposobem jaki znam i jaki niestety często spotykam, na modelowanie struktury organizacyjnej, jest użycie diagramu klas lub diagramu przypadków użycia i modelowanie z zastosowaniem dziedziczenia (klas lub aktorów).

Sabotaż dokumentacyjny

Post author:Jaroslaw Zelinski
Post published:24 April 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Dwa lata temu cytowałem: Jakie są najczęstsze problemy w nieudanych projektach? [...] 83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania…

Inżynieria wymagań

Post author:Jaroslaw Zelinski
Post published:16 April 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Wymagania interesariuszy. Moja definicja interesariusza (jedna z wielu): osoba (podmiot) zainteresowana zaistnieniem produktu, na którą pojawienie się produktu ma wpływ. Nie raz jestem pytany czy interesariusz ma prawo zgłaszania wymagań. Jeżeli ma coś do powiedzenia podczas odbioru produktu to znaczy, że ma wymagania. One mogą być jednak niejawne czyli taki interesariusz nie zgłasza wymagań ale ma wpływ na odbiór produktu, należy go koniecznie zidentyfikować. Jeżeli zaś ktoś nie ma nic do gadania przy odbiorze produktu nie jest interesariuszem (ang. stakeholder, kluczem jest tu 'holder' czyli dysponent mający coś do powiedzenia, mający wpływ). Tak wiec interesariusz to ktoś kto, na swoim poziomie ogólności, także musi umieć określić, kiedy uzna, że produkt spełnia jego wymagania. Jak nie potrafi, ktoś musi mu pomóc...analityk :)). I tu rola analityka. Interesariusz spisuje co mu przyjdzie do głowy swoim językiem, analityk upewnia się, że zrozumiał, doprowadza je do postaci testowalnej i klasyfikuje "wymagania" jako "źródło: konkretny interesariusz" (bo każde wymaganie musi mieć właściciela). Proszę zwrócić uwagę, że interesariuszem jest także użytkownik jeżeli tylko ma coś go powiedzenia w projekcie :).

Semiotic/Semantic Triangle in SBVR Terms

Semantic Core czyli bat na szczegóły

Post author:Jaroslaw Zelinski
Post published:14 April 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem? Ten artykuł polecam "biznesowi" który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo "takie są fakty". [...] Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia "opinia prawna" oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).

Pojęcia, reguły i fakty czyli o czym oni mówią…

Post author:Jaroslaw Zelinski
Post published:9 April 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Słownik pojęć (często występuje w dokumentach jako czysto polskie słowo glossariusz ;)) bywa często przedmiotem burzliwych negocjacji, bo nie raz (a w zasadzie zawsze ;)) biznes stosuje slang, w którym to samo słowo ma różne znaczenie, zależnie od kontekstu użycia. Może to mieć sens w języku mówionym gdy pełna treść wypowiedzi daje ten kontekst, ale na poziomie analizy i projektu każde pojęcie musi mieć jedno unikalne znacznie mimo braku kontekstu (tym bardziej, że np. nazwy klas nie są elementami pełnych zdań ani opowieści :)).[...] Biznes także musi zrozumieć, że ma dwa różne elementy opisu swoich działań: praca z dokumentami i tworzenie dokumentów. Jednak uznanie tego faktu to jedno, nie wierzę w to, że biznes się tego nauczy, bo nie nauczył się formalnego opisu lub modelowania procesów podczas wdrożeń ISO, jednak uważam, że biznes nie ma takiej potrzeby. Moim zdaniem od dobrego analityka nie ma ucieczki, to inna kompetencja. Nie ma ucieczki od projektantów mody mimo istnienia kobiet chcących mieć ładne sukienki i bardzo dobrych krawców. Nikt tu nikogo nie zastąpi.