Powszechnym błędem jest więc "zamawianie" oprogramowania metodą specyfikowania wymagań, jako wielu przypadkowo, lub nawet systematycznie, opisanych reakcji na bodźce, bez zrozumienia mechanizmu ich powstawania. Implementacja tak opisanych wymagań bardzo często jest realizowana jako bardzo rozbudowany system pokazujący co sekundę kolejny obraz tarczy zegara zamiast implementacji prostego mechanizmu zmieniającego położenie wskazówek na nieruchomej tarczy zegara. Większość znanego mi oprogramowania jest bardziej złożona niż mogła by być...
Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :). Niedawno napisałem: Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te…
Są książki nieśmiertelne. Polowanie na tę trwało ponad rok. Zastanawia mnie to, że nie ma dodruków takich książek, bo pewne osiągnięcia nauki się nie starzeją. Piękna pozycja opisująca metody analizowania i modelowania przedsiębiorstw. Książka wydana w 1975 roku przez Państwowe Wydawnictwo Naukowe. Abstrahując od antycznych :) notacji użytych do stworzenia bardzo jednak dobrze opisanych schematów blokowych, nie straciła nic na aktualności. Książka opisuje to, jak metodami systemowymi prowadzić analizy przedsiębiorstw i ich modelowanie. Pierwsza kluczowa teza, która wiele powinna wyjaśnić: To między innymi przesłanka do tego, by w toku analizy…
praca grupowa,
Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być). Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często ;) ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność. Wprowadzenie Ludzie i ich praca…
W recenzji książki Ogólna Teoria Systemów pisałem między innymi, że: Systemy społeczne spotykane wokół nas to z reguły systemy z pamięcią, kolejne reakcje systemu to efekt bodźca jaki się pojawi i wcześniejszych zapamiętanych reakcji (historii). Jak widać takie same bodźce mogą wywoływać inne reakcje w przypadku systemu z pamięcią. Tak działamy my (uczymy się), tak działa większość aplikacji biznesowych (zbiera dane). Systemów bez pamięci także mamy wokół sobie wiele. Od zegarka czy prostego kalkulatora (wyniki podstawowych operacji matematycznych nie zależą historii obliczeń) do robotów kuchennych i wielu podobnych, nawet nie raz bardzo…
Tym razem książka na która polowaniem długo w antykwariatach ale warto (nadal można od czasu do czasu upolować, w razie co polecam biblioteki). Analiza systemowa - podstawy i metodologia. Praca zbiorowa pod redakcją Władysława Findejsena, Warszawa 1985, PWN. Jest to bardzo dobre kompletne opracowanie. Same tytuły rozdziałów aż "proszą się" o ich czytanie: Analiza systemowa możliwości i ograniczenia Dziedziny i przykłady zastosowań Metodologia ogólna Budowa modeli Użytkowanie modeli Oceny i decyzje Ty wybrane rozdziały i części. Gorąco polecam upolowanie tej książki.
"Requirements must be based on facts and real-life scenarios." (wymagania muszą być oparte na faktach i realnych scenariuszach). Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.
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…
Od czasu do czasu spotykam się w projektach z pojęciem "cynefin". Najpierw typowy opis z jakim można się zetknąć w sieci: Cynefin jest swoistą teorią, którą można wykorzystać do opisu działania skomplikowanych systemów takich jak różnego rodzaju przedsięwzięcia czy nawet relacje i problemy międzynarodowe. Jako model tłumaczy i próbuje pomóc w wyborze strategii działania, wskazując jednocześnie wzorce postępowania, które powinny być zdecydowanie inne w zależności od tego w jakiej sytuacji się znajduje się firma. W praktyce można korzystać z Cynefin jako narzędzia wspierającego zarządzanie projektem, zespołem lub nawet organizacją. Od…
Wstęp Temat wynagrodzeń dyskutowany jest od pewnego czasu, na ich zbyt niski poziom narzeka wielu. Pracodawcy i szeroko pojęci liberałowie, bronią się przed zarzutami o wyzysk [[machiawelizmem]]: "wolno wszystko to co nie jest zabronione" i dodają, że przecież ludzie się na niskie wynagrodzenia godzą, nikt ich nie zmusza, więc w czym problem? Czy aby na pewno nikt lub nic ich nie zmusza? Bardzo ciekawa ocena zjawiska w Forbes: Wiadomo bowiem nie od dziś, że na etapie negocjowania wynagrodzenia między zatrudniającym a zatrudnionym, istotne znaczenie ma różnica miedzy tym, co pierwszy…
Wprowadzenie Niedawno pisałem o pewnej innej książce, jej autor opisał systemowe podejście do analizy przedsiębiorstwa. Napisałem między innymi wtedy, że: Rzecz w tym, że pojęcie ?analiza systemowa? jest używane najczęściej (jak obserwuję, prawie zawsze) w znaczeniu analizy i projektowania oprogramowania (systemy IT) co jest błędem.Tak zwane ?całościowe myślenie? (holistyczne) to uznanie, że system to nie tylko oprogramowanie. (Źródło: Systems Thinking czyli analiza systemowa organizacji | Jarosław Żeliński IT-Consulting) Tak więc pora na ciąg dalszy. Ogólna Teoria Systemów Książka ta, Ogólna Teoria Systemów , czekała u mnie na swój czas, i…
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.
