Temat: Analiza obiektowa
Waldemar Faliński:
Wdrożyłem niejeden system SAP ERP, ale muszę przyznać, że się w tej dyskusji gubię.
Cóż Pan Jarek, próbuje uzasadniać odwołując się do rozwiązań o których mam zdanie, że to co przywołane radzi sobie nie z tym co sugerowane. :-(
Z całym szacunkiem - o jakich systemach tu dyskutujecie?
O
dowolnym dla biznesu nie z pudełka (wszak pojawiły się faktury) - czyli dedykowany, taki który się wdraża, .. czyli SAP ERP też. ;-) Pomieszanie z poplątaniem? ;-( Zgadzam się. ;-)
Przypomina mi się tez znajomy, który się chwalił, że ustalił cenę za wykafelkowanie łazienki a potem okazało się, że chce takie drobniutkie drewniane kafle (?) których przyklejenie metra zabiera cały dzień. bardzo był dumny, że w ten sposób zrobił w balona kafelkarza.
A ja odnoszę wrażenie, że Pan Jarek zaliczył "wpadkę" jako analityk reprezentujący klienta. Dostał to co zamówił, ale jego klient stwierdził, że nie jest to to czego potrzebuje i teraz rozpaczliwie próbuje oczyścić się z winy, starając się na tę okoliczność udowodnić, że za pomocą określania tylko wymagań klient narażany jest na ogromne niebezpieczeństwo nie dostania tego co zamówił i najwłaściwszym postępowaniem jest stawianie wymagań nie tylko co, ale i jak wykonawca ma pracować oraz z czego ma korzystać. Dodatkowym usprawiedliwieniem dla takiego postępowania ma być potrzeba? chęć? ukrywania przed wykonawcą pewnych informacji wrażliwych? klienta?.
Nie mam pojęcia, czy w rzeczywistości "wpadka" była z jego udziałem tak/nie i czy na okoliczność "wpadki" zawinił analityk biznesowy czy wykonawca, nieistotne, ale z postawioną przez niego tezą nie zgadzam się.
Nie wdając się w jednoznaczność rozumienia i wytyczenia podziału czarna / biała skrzynka, kiedy do wykonawcy przekazuje się część wymagań i fragment kodu, który ma użyć, w miejsce nie przekazanych wymagań bo ich wykonawca ma nie znać, to jest to rozmywanie odpowiedzialności.
Rozumiem, że mogą istnieć wymagania, o których nie wiadomo
a priori czy się sprawdzą w praktyce. Ale to można przewidzieć przed rozpoczęciem prac i potrzebę uwzględnienia doświadczeń
a posteriori uwzględnić jako etap powstawania projektu. To jest typowe dla otaczającej nas rzeczywistości sprzężenie zwrotne pokazujące, że niektórych rozwiązań nie potrafimy realizować liniowo, za to iteracyjnie drogą kolejnych przybliżeń już tak. Od tego analityk ma być analitykiem aby takie rzeczy rozumiał i prawidłowo prace organizował.
Czy takie podejście jest zgodne z prawem (np. kodeksem handlowym albo ustawą o rachunkowości jeżeli to, o czym jest dyskusja ma oczywiście z nią związek)?
Też mam wątpliwości, bo jedynym wymaganiem, które nasuwa mi się jako nie nadające się do upublicznienia to to, że już wiadomo kto ma zadanie realizować i wtedy cała reszta to folklor.
Jeżeli działania analityka to nie bullshit, to przekazywanie fragmentu kodu być może pomoże początkującemu, być może pomoże w realizacji małego projektu. Ale w przypadku adaptacji do potrzeb klienta dużych systemów, np. SAP, Microsoft, .., także z małych firm IT, przekazywanie fragmentu kodu jest działaniem co najmniej śmiesznym, niepoważnym. Oprogramowanie, które powstawało latami, tworzone często przez finalistów, laureatów olimpiad informatycznych, matematycznych, czy ludzi którzy uczyli się latami i przepracowali lata w branży, nagle staje się przedmiotem uczniowskiego traktowania?
Nawet jeżeli znane są przypadki błędnych wdrożeń, to przecież nie oznacza to, że na okoliczność kolejnego wdrożenia, właściwym jest pouczanie producenta jaki kawałek kodu ma wykorzystać. Ponadto dla dużych systemów błędne wdrożenie zapewne obciąża wdrożeniowców, a nie producenta, którzy pomylili się używając dostępne uniwersalne narzędzia, a dostarczanie im jakiegokolwiek zbioru definicji klas jest bezprzedmiotowe. Dlaczego tłumaczył Mateusz Kurletko.
Takie postępowanie wcale nie przesądza ani czy wymagania są kompletne, ani czy są właściwie zdefiniowane, ani czy będą właściwie zrozumiane. Nie ma innej drogi wiodącej do opracowania dobrego oprogramowania, jak zdefiniować wszystkie wymagania i je wyartykułować w sposób jednoznaczny upewniwszy się, że są właściwie zrozumiane.
Jeżeli coś ma być ukryte przed wykonawcą to zapewne nie funkcjonalności do zrealizowania, bo to nierealizowalnym. Poufne mogą być przetwarzane dane, sposób użytkowania, użytkownicy, .., a to już obszar wdrożenia i eksploatacji. Każda "wpadka" w tym zakresie to dowód na nie znalezienie wzajemnego zrozumienia, brak lub błędne podzielenie prac na etapy częściowego odbioru i/lub niewłaściwy nadzór. Tego dostarczenie kawałka kodu źródłowego nie załatwi.
Przytoczona przez Pana Jarka argumentacja, to na pewno nie jest działanie zabezpieczające przed nie zamówieniem tego czego się potrzebuje.
пропозиції роботи
