Na stronie portalu analizawymagań.pl ukazał się bardzo interesujący i wartościowy wpis: wywiad z prawnikiem, Łukaszem Węgrzynem. Zaczyna się tak: Jakie są najczęstsze przyczyny problemów w umowach wdrożeniowych i jakie są ich…
Od czasu do czasu w zakresie wymagań biznesowych pojawiają się (coraz częściej) potrzeby z obszaru szeroko rozumianego kontrolingu, który polega na zbieraniu danych w celu tworzenia wyrafinowanych raportów, bazujących na…
Niestety i w literaturze i w materiałach szkoleniowych, czy nawet dydaktycznych na uczelniach (o zgrozo) można się spotkać z takimi “antywzorcami” jak wyżej. Jednym z najbardziej kuriozalnych jest obecnie modelowanie danych z użyciem diagramu klas, nanosząc na nie np. jeszcze klucze główne. Niestety bardzo często autorzy tych materiałów, wykładowcy i trenerzy, zamiast korzystać ze źródeł, przepisują jeden od drugiego pogłębiając marazm w tej dziedzinie, a pierwowzorem wielu tych herezji są niestety materiały publikowane przez firmę SPARX (producent oprogramowania Enterprise Architect) jak choćby mój ulubieniec: czas jako Aktor systemu
Większość książek z dziedziny analizy biznesowej i projektowania to traktaty o UML, "zbieraniu wymagań" itp., czasem o wzorcach projektowych (wzorce analityczne nie pojawiają się w tytułach, napiszę o tym innym…
11 go czerwca wygłosiłem referat inaugurujący targi IT Future Expo, dla tych którzy nie mogli być wtedy na sali :): http://www.slideshare.net/zelinski/j-elinski-rezygnujemy-z-waterfall Więcej o targach: II edycja IT Future Expo już…
Wyznaczenie granicy (pod)systemu to rola analityka i architekta systemów. Szkoda, że tak rzadko się korzysta z tej specjalności. Być może nie zlikwidowany by tak wielu lokalnych połączeń kolejowych uznając, że stanowią one razem system a w pojedynkę są niesamodzielne. Pewnie uznanie, że nie sam Zakład Komunikacji Miejskiej a właśnie miasto i jego infrastruktura razem stanowi system, który należy oceniać i rozwijać. “Darmowe autobusy mają pomóc odkorkować Bełchatów” czyli może jednak łączymy jakimś związkiem w jeden system dostępność komunikacji miejskiej, liczbę prywatnych samochodów osobowych, koszty zanieczyszczenia atmosfery, koszt budowy parkingów i poszerzania ulic.
Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje:
– sama struktura to nie model,
– tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury,
– dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]),
– bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.
(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).
Niestety wiele systemów ERP i i nie tylko, powstało w latach 90’tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i “nad nią” funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie – jak to zachwalają ich dostawcy – zaletą…
