Niemalże każde spotkanie projektowe, na którym omawiane są modele UML, na każdym szkoleniu na temat UML, pojawia się problem o którym pisze Ron Ross (wytłuszczenia moje): Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That?s wrong. A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It?s about communication. A logical data model is about how you organize what you think you know about the world…
W toku niejednej analizy można spotkać się z sytuacją gdy standardowe podejście polegające na badaniu dokumentów i analizie zstępującej (od ogółu do szczegółu, ang. top-down) może być trudne lub wręcz nie możliwe. Dotyczy to analizy systemów słabo udokumentowanych lub wręcz nieudokumentowanych, gdzie jedyne dostępne dane to obserwacja lub relacja obserwatora (uczestnika, itp. czyli relacja z drugiej ręki). Jest to sytuacja podobna to serii (pakietu) zebranych "user story" (w nomenklaturze metodyk zwinnych historyjki użytkownika), nieformalnych relacji. Jak ugryźć taką sytuację? Z pomocą przychodzi pojęcie specyfikacji instancji w UML, zapewne brzmi to…
Dbałość o jednoznaczność i spójność dokumentacji to kluczowa cecha analityka, pisałem o tym między innymi w artykule o tępieniu niejednoznaczności. Uznawanie, że to nie ważne, dopuszczanie do nieprecyzyjnych definicji, uznawanie pewnych pojęcia za bliskoznaczne czy wręcz synonimy, prowadzi do nie tylko do emocji w rozmowach ale to nieprzydatności tworzonych dokumentów.
Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. [...] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.
Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.
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.
Wiele firm ma problemy zarządcze nie dlatego, że są źle zarządzane, ale dlatego, że stopień złożoności tych firm jest zbyt duży by podejmować je na wyczucie. W obecnych czasach decyzje muszą być podejmowane w relatywnie krótkim czasie bo rynek nie czeka, jednak jakość tych decyzji nie powinna być zła. Dlaczego bywa zła? Bo decyzje są nie raz podejmowane z niepełnym zrozumieniem sytuacji. Podejmowana decyzja, by była możliwie najlepsza, wymaga pełnego zrozumienia, tego czego dotyczy (co chyba nie jest dziwne). Jeżeli dotyczy firmy, nie powinno się podejmować decyzji bez pełnego zrozumienia potencjalnego wpływu tej decyzji na firmę. W przeciwnym wypadku skutki są dość losowe, czyli nie zarządzamy a staramy się zarządzać.[...] Analiza biznesowa organizacji poprzedzająca np. wdrożenie nowego oprogramowania, powinna polegać na wykonaniu audytu i uporządkowaniu reguł decyzyjnych oraz opracowaniu modeli procesów biznesowych by je zweryfikować. Drugi krok to ocena, jakiej wiedzy oczekujemy od ludzi (ich umiejętności i wiedza). Dokumentujemy ją z obawy przed "błędem ludzkim". Tu zwracam uwagę na to, że wymaganiem na oprogramowanie może być tablica decyzyjna, jeżeli planujemy automatyzację jakiejś czynności. Proces biznesowy nie jest wymaganiem, to co najwyżej kontekst wykonywanych czynności.
Model organizacji to: opis motywacji jej działania, opis ludzi, jacy realizują wewnętrzne zadania, opis reguł jakie regulują ich zachowaniami. Całość (model) powinna być na tyle uporządkowana, by model był w 100% jednoznaczny, czyli kluczowe pojęcia w nim użyte powinny być zebrane w jeden wewnętrzny, spójny biznesowy słownik tej organizacji. To wszystko dopiero pozwoli stworzyć model procesów biznesowych, czyli wewnętrzne scenariusze zachowania.Samo utworzenie map (bo nie modeli) w postaci diagramów procesów z pomocą wywiadów, sesji warsztatowych i obserwacji, da produkt podobny do zdjęcia lotniczego rzeki: wiemy którędy płynie, ale kompletnie nie rozumiemy dlaczego akurat tak. Mamy jedynie udokumentowany stan obecny.Ingerencja w ten stan rzeczy, bez zrozumienia reguł rządzących tym jak i którędy płynie woda, kończy się nie raz katastrofami jakie znamy z doniesień o powodziach i zalaniach ostatnich lat. Bez poznania zasad rządzących zachowaniem się organizacji można "nie uniknąć problemów przy wprowadzaniu zmian".Każda reorganizacja, a w szczególności jest nią wdrażanie nowego oprogramowania, jest taką zmianą. Ta książka jest o modelowaniu organizacji.
