Analityk to nie dyktafon

Dzisiaj żadnych technicznych mądrości ;) [...] Tak więc wymagania na oprogramowanie to minimalna liczba (specyfikacja) warunków, których spełnienie potwierdza przydatność tego oprogramowania do określonego celu. Oznacza to, że przede wszystkim należy określić cele! Jeżeli nie znajdziemy takiego oprogramowania na rynku, wtedy należy wykonać studium wykonywalności projektu dedykowanego oprogramowania. Jak określać cele? Przypadek użycia, wymagana usługa systemu, to nic innego jak właśnie cel. Celem jest możliwość wystawiania dokumentów XXX, celem jest generowanie raportów kontrolnych wykonania planu produkcji i obciążenia maszyn. Jeżeli system jest duży, celem (jednostka opisu wymagań) jest wsparcie procesu obsługi zamówień (i opis tego procesu jako załącznik). Ale nie jest dobrym celem zakupu oprogramowania: "rozwijana lista kontrahentów na ekranie tworzenia nowej faktury" czy "możliwość wprowadzenia nazwy ulicy, kodu i nazwy miasta w kartotece klienta". Jak mam nadzieję widać, nie bardzo ma sens porywanie się na zakup "wielkiego pakietu zintegrowanego", bo jak tu opracować w rozsądnym czasie i koszcie, specyfikację wymagań? Opracować listę celów wszystkich komórek organizacyjnych???? Jak zagwarantować jej niezmienność (zakres projektu), jeżeli taki projekt trwa np. pięć lat? Życzę powodzenia...

Continue ReadingAnalityk to nie dyktafon

Nowy paradygmat systemowy

Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić? Opisać strategie rynkową firmy, Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów), Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych, Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści, Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi. Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA) Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.

Continue ReadingNowy paradygmat systemowy

Modelowanie struktury organizacyjnej

Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe. Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły), na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Z zasady wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa) nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe. projektują oprogramowanie także, z reguły nieprawdą, jest dziedziczenie praw dostępu. Nie przypadkiem w praktyce stosuje metody macierzowe zarządzania prawami dostępu (niewydolne i nie prawdziwe w sensie biznesowym) lub kontekstowe (dużo lepsze).

Continue ReadingModelowanie struktury organizacyjnej

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Kim więc jest dobry analityk? Jest to projektant, który potrafi analizowaną organizację "rozłożyć na elementy składowe". Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie "rysunek". Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia. Analiza Biznesowa to rozłożenie analizowanego "przedmiotu" na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania. Poziomy szczegółowości wymagań to: cele biznesowe (produkty procesów biznesowych) opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania) opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)

Continue ReadingPoziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa