ROMAN WILK:

Piotr Likus:

ROMAN WILK:
Znam C, C++, PHP (dawno temu),średnio Java (wcale nie tak uniwersalny i skalowalny kompilator, w każdym razie "iluzją jest stwierdzenie, że platforma nie ma znaczenia") i oczywiście DELPHI wcześniej Pascal. Nie widzę "poważnych braków" w kompilatorze DELPHI 2010.

A są jakieś "poważne zalety"? Np. w stosunku do Delphi 7 czy Lazarus Pascal.
Pytam bez złośliwości, bo w sumie nie znam (D2010)...

Nie raczej nie ma jakiś "poważnych zalet", ale zapytam czego brakuje np. w Delphi 2007. Biorąc pod uwagę projekt klasy ERP pisany w Delphi.

Owszem, w warstwie prezentacji Delphi jest bardzo użyteczne,
ale z mojej perspektywy swiat oprogramowania ulega podzieleniu na kilka warstw:
- serwer SQL
- logika aplikacji
- warstwa prezentacji

Warstwa prezentacji to albo desktop albo www.
Z tego co wiem w WWW Delphi nie zdominowalo rynku.

W dzialce desktop (client/serwer lub wielowarstwowo) jest jeszcze Java, C# i kilka tanszych rozwiazan -
dla oszczednych: Lazarus Pascal, C++/Qt, C++/wxWidgets.
Dlaczego więc akurat Delphi?

Od kilku lat czytam listę nowosci dla kolejnych wersji Delphi i naprawde nie potrafie
sie doszukac uzasadnienia dla stosowania nowszej wersji, zwlaszcza ze nie jest tania,
do nowych projektow.

Powazne wady?
- cena IDE
- problem z kupieniem starszej wersji (second hand ponoć nie dziala)
- brak kompilatora x64
- jednoplatformowość
- topniejąca dynamika rynku komponentów

Piotr Likus:

Powazne wady?
- cena IDE

no cóż piszesz programy, chcesz zarabiać, wolny rynek, skoro działają już jakieś kilkanaście lat i dalej utrzymują kompilator, znaczy zarabiają :)

- problem z kupieniem starszej wersji (second hand ponoć nie dziala)

Nie działa i sens ma utrzymywania kodu w bieżącej wersji kompilatora

- brak kompilatora x64

zgadzam się, ale podobno pracują nad tym

- jednoplatformowość

zgadzam się, choć np. Java z wieloplatformością, to też tak nie do końca, trzeba instalować soft w zależności od platformy (jeszcze zazwyczaj w określonej wersji),ale zgoda kod jest niezależny

- topniejąca dynamika rynku komponentów

Tu bym dywagował, ale nie śledzę tego. Prawda jest taka, że jeśli masz komercyjne wersje swojego (tzn. sprzedajesz pod swoim szyldem) softu to raczej unikasz komponentów innych producentów (z moich do świadczeń opłaca się napisać jak najwięcej swojego kodu, aby później nie być niemiło zaskoczonym, ale to następne koszty)

ROMAN WILK:
Jarek, postaram się sprawdzić "co są warte referencję z Twojej strony" :)

przywykłem.... :)

No właśnie, tak by można podsumować :) Tak w nawiasie, książkę można wydać w dowolnym języku (równie dobrze w chińskim co angielskim), czy to zmienia jej treść ?

są języki, które pewnych treści nie są w stanie przenieść z powodu ubogiej semantyki i syntaktyki, np. w niektórych rejonach świata ludzie nie używają czasów innych niż teraźniejszy, w naszych oczach mają problem z opisem historii ale oni żyją dniem dzisiejszym i nie potrzebują tej cechy języka...

ps.
Sorry, że się nie rozpisuje, ale jedną z podstawowych cech "dobrego analityka" (absolutnie się nie pozycjonuje) powinno być oszczędne i zrozumiałe gospodarowaniem treścią, którą chce przekazać.

oszczędność w treści nie jest w moich oczach zaletą, zaletą analityka jest "wystarczająco dobrze" wiec jakość się liczy a nie ilość bo ktoś może nieopatrznie dostrzec "wielkość" albo "małość" treści....;)

ROMAN WILK:

- topniejąca dynamika rynku komponentów

Tu bym dywagował, ale nie śledzę tego. Prawda jest taka, że jeśli masz komercyjne wersje swojego (tzn. sprzedajesz pod swoim szyldem) softu to raczej unikasz komponentów innych producentów (z moich do świadczeń opłaca się napisać jak najwięcej swojego kodu, aby później nie być niemiło zaskoczonym, ale to następne koszty)

z tym twierdzeniem byłbym ostrożny, jest wiele bibliotek i całych komponentów dostępnych na otwartych licencjach bardzo wysokiej jakości, w szczególności multimedialnych od galerii zdjęć i viewerów począwszy... one jednak są najczęściej w java'ie lub php... najtrudniej samemu pisać komponenty multimedialne... to nie wszystko, także bardzo przydatne do manipulowania dokumentami w repozytorium... itp...Jarek Żeliński edytował(a) ten post dnia 19.10.10 o godzinie 18:27

Jarek Żeliński:

osobiście stawiam nie tyle na błędy korporacji SAP czy IFS a na ludzi, paradoksalnie wszystkie te firmy mają jakieś metodyki analizy i opracowania koncepcji wdrożenia, mniej lub bardzie ale wszystkie bazują na analizach, jednak tam gdzie padło wdrożenie prawie zawsze okazuje się, ze firma wdrażająca bardzo uprościła a bywa, ze zaniechała etapu przedwdrożeniowego, ewentualnie (i to jest w zasadzie norma) po protu zrezygnowała z najlepszych praktyk korporacyjnych (byłem zaskoczony jak zobaczyłem czym SAP dysponuje do przeprowadzenia analiz, niestety polskie firmy tego nie stosują)

Mam podobne doswiadczenia. Niestarannie przeprowadzona analiza przedwdrozeniowa moze byc i czesto bywa glowna przyczyna niepowodzenia projektu.

Roznimy sie w jednym. Ja uwazam ze po wyborze dostawcy i narzedzi dostawca ma prawo i obowiazek przeprowadzic od nowa wlasna analize (z mojej praktyki dla systemow BI to 20-25% ogolnego czasu trwania wdrozenia). Uwzgledniajac uwarunkowania techniczne, dostepnosc zasobow i metody realizacji.

Nie wierze w opisy systemow niezalezne od narzedzi. Teoretycznie jest to mozliwe.
W praktyce taka analiza albo bedzie ignorowana albo bedzie zmuszac wykonawce do produkowania technicznych absurdow - tylko po to zeby spelnic wymagania formalne. Potem np. firma panstwowa stawia dwa (DEV/TST + PRD) dodatkowe, w zasadzie niepotrzebne serwery. Bo taki 'pejzaz' sobie pan XY, wykladowca z powaznej uczelni wczesniej wymyslil.
No ale zaplacone to trzeba postawic :)) )To nie sa zarty - mialem taki przypadekAdam Kalinowski edytował(a) ten post dnia 19.10.10 o godzinie 22:06

Adam Kalinowski:
Nie wierze w opisy systemow niezalezne od narzedzi. Teoretycznie jest to mozliwe.
W praktyce taka analiza albo bedzie ignorowana albo bedzie zmuszac wykonawce do produkowania technicznych absurdow - tylko po to zeby spelnic wymagania formalne. Potem np. firma panstwowa stawia dwa (DEV/TST + PRD) dodatkowe, w zasadzie niepotrzebne serwery. Bo taki 'pejzaz' sobie pan XY, wykladowca z powaznej uczelni wczesniej wymyslil.
No ale zaplacone to trzeba postawic :)) )To nie sa zarty - mialem taki przypadekAdam Kalinowski edytował(a) ten post dnia 19.10.10 o godzinie 22:06

To tylko dowodzi, że spieprzona analiza jest jeszcze gorsza niż jej brak - przynajmniej wtedy, kiedy dostawca analizę robi.
Niestety w wielu przypadkach dostawca zamiast robić analizę lobbuje swoje gotowce, jak ktoś już wcześniej ładnie to zobrazował próbując przepchnąć sześcian okrągłym otworem - co nie zawsze jest możliwe, zwykle niewygodne, chyba, że dziura dużo większa.

Mateusz Kurleto:

Adam Kalinowski:
Nie wierze w opisy systemow niezalezne od narzedzi. Teoretycznie jest to mozliwe.
W praktyce taka analiza albo bedzie ignorowana albo bedzie zmuszac wykonawce do produkowania technicznych absurdow - tylko po to zeby spelnic wymagania formalne. Potem np. firma panstwowa stawia dwa (DEV/TST + PRD) dodatkowe, w zasadzie niepotrzebne serwery. Bo taki 'pejzaz' sobie pan XY, wykladowca z powaznej uczelni wczesniej wymyslil.
No ale zaplacone to trzeba postawic :)) )To nie sa zarty - mialem taki przypadek

To tylko dowodzi, że spieprzona analiza jest jeszcze gorsza niż jej brak - przynajmniej wtedy, kiedy dostawca analizę robi.

W tym przypadku przyczyna problemow nie byl dostawca, tylko niezalezny analityk wynajety przez korporacje

Niestety w wielu przypadkach dostawca zamiast robić analizę lobbuje swoje gotowce

Bylo odwrotnie. Podam wiecej szczegolow:

Niezalezny analityk zapisal w swojej koncepcji zainstalowanie standardowego, katalogowego modulu SAP. Nie byl to ewidentny blad, bo bez problemu mozna bylo w ten sposob zrealizowac wymagania klienta. Chodzilo tylko o koszty i czas.

To czego klient naprawde potrzebowal stanowilo moze 5% funkcji instalowanego modulu. Gdybysmy wykonanie tych funkcji zlecili programiscie koszt rozwiacania bylby kilkakrotnie nizszy i podprojekt trwalby krocej. Juz nie mowie o koszach pozniejszej ekspoatacji, bo to przepasc
Instalujac 'gotowca' musielismy zatrudnic w projekcie dodatkowych specjalistow, wykonac interfejsy ktore nie bylyby potrzebne gdyby zostalo to wykonane w ramach zintegrowanego systemu i oczywiscie postawic te nieszczesne serweryAdam Kalinowski edytował(a) ten post dnia 20.10.10 o godzinie 09:03

Adam Kalinowski:

Zdarza się i tak. Niemniej jednak wydaje się być rzadkością. Ja zakładając ten wątek przede wszystkim chciałem się dowiedzieć, dlaczego zapytania ofertowe są na dostarczanie jakiegoś wybranego narzędzia a nie realizację wyznaczonych celów i wymagań, gdzie ja, jako potencjalny dostawca mogę zaproponować rozwiązanie zgodnie z moją najlepszą wiedzą.

Według mnie klient oczekuje że dostając narzędzie (aplikację) dostanie razem z nią pewien know-how na temat tego w jaki sposób powinny zostać zorganizowane procesy których to narzędzie dotyczy. Żeby napisać dobre wymagania klient musi posiadać dobrze zorganizowane procesy lub wiedzę jak te procesy powinny być zorganizowane. Analityk powinien pomóc klientowi w organizacji procesów i stworzeniu odpowiednich wymagań co do systemów informatycznych, na których klient nie musi się znać, a analityk powinien. W typowych sytuacjach klientowi wydaje się że prościej jest wziąć gotowe rozwiązanie. Jednak musi on się liczyć w takich przypadkach że będzie on działał według takich samych lub podobnych reguł jak inni użytkownicy tego oprogramowania i może to zmniejszyć jego konkurencyjność. Chociaż z drugiej strony zawsze bardziej efektywna jest praca z wykorzystaniem dobrych narzędzi niż praca bez nich.Arkadiuszy Figurny edytował(a) ten post dnia 20.10.10 o godzinie 09:45

Wojciech Gardziński:

To co... stawiając dom zaczyna Pan od kupienia okien, czy drzwi? W końcu wiadomo jaki dom:) jednorodzinny:)

Wojciech Gardziński:

Analizy są potrzebne jak koncepcje projektowe domów - zgadza się - budując coś absolutnie nowego, itp.
Ale tam, gdzie już jest plan zagospodarowania już jest, gdzie klient wie co budować, gdzie nawet czasami kupił sobie projekt typowy - to Wy się upieracie, że analiza, a potem się dziwicie,

Dokladnie o to chodzi. Klientowi podoba sie nowy dom znajomego wiec prosi o telefon do architekta i majstrow ktorzy ten dom budowali.
Potem mowi: chce miec podobny tylko wjazd musi byc z lewej, a nie z prawej bo akurat z tej mam ulice
W trakcie budowy majster radzi: ja bym tu polozyl dodatkowa warstwe abstrakcji, bo jak u Kowalskiego dalem jedna to mu przeciekalo

Nikt tu nie mowi o zadnej koncepcji i analizach. Wszyscy wiedza co maja robic i niestety specjalista od feng-shui na tym projekcie nie zarobi ani grosza. Jasne, ze to przykre. Z drugiej strony nigdy nie jest za pozno zeby nauczyc sie machac kielnia
Sa tez projekty wielkich bibliotek, katedr i mostow nad gorskimi przeleczami. To jest pole dzialania dla gigantow achitektury, tylko zeby to robic trzeba wielokrotnie udowodnic swoja wartosc w rzeczach mniejszych

--
Systemy ERP i BI dla firm sa typowe. Jak domy, autostrady i biurowce.

Po drugiej stronie sa nieszablonowe systemy takie jak ten dla ZUS. To podroz w nieznane i do tego potrzebne sa dobre mapy

Wojciech Gardziński:

Adam Kalinowski:

>

Systemy ERP i BI dla firm sa typowe. Jak domy, autostrady i biurowce.

Ha! I kto to mówi? ;)
Ale, co do meritum, to ma Pan, oczywiście, rację.
I teraz w drugą stronę: "I kto to mówi?" ;)

Typowe nie znaczy proste :-)
To Pan mocno przesadza mowiac ze uzytownik jak mu sie da narzedzia to jest w stanie sam zbudowac sobie system BI. Moze cos malego to tak. Niestety gdzies przy trzynastej kostce najtwardsi straca zapal

Ja tam klepie te kostki bo przywyklem. Gdyby jednak jakis analityk kazalby mi je jeszcze rysowac to bym rzucil to i tez chyba wybiegl z krzykiem :)) - Aaaaaa!!Adam Kalinowski edytował(a) ten post dnia 20.10.10 o godzinie 11:06

Adam Kalinowski:
Typowe nie znaczy proste :-)
To Pan mocno przesadza mowiac ze uzytownik jak mu sie da narzedzia to jest w stanie sam zbudowac sobie system BI. Moze cos malego to tak. Niestety gdzies przy trzynastej kostce najtwardsi straca zapal

Adamie, zanim rozpocznie się kolejna kanonada pana Wojtka wiedz, że zgodnie najlepszym BI jest excel z jego markami a w zasadzie to w ogóle jest najlepszy system do wszystkiego z obsługą elektrowni...

Ja tam klepie te kostki bo przywyklem. Gdyby jednak jakis analityk kazalby mi je jeszcze rysowac to bym rzucil to i tez chyba wybiegl z krzykiem :)) - Aaaaaa!!Adam Kalinowski edytował(a) ten post dnia 20.10.10 o godzinie 11:06

Chodzi o to, że Ty klepiąc kostki powinieneś mieć jasno i wyraźnie wyznaczone cele i konkretne, mierzalne wymagania które Twój system ma spełniać. A nie żebyś tworzył tony zbędnej dokumentacji i robił komentarze do każdego faktu i wymiaru:)

Adam Kalinowski:
Nie wierze w opisy systemow niezalezne od narzedzi. Teoretycznie jest to mozliwe.

przede wszystkim, czym jest taki projekt? Jeżeli zapisze w wymaganiach ze system ma pozwalać na wystawienie faktury VAT, ma obsługiwać częściowe płatności oraz płatności zbiorowe (jeden przelew wiele tytułów płatności) ale także napisze, że faktura ma być redundantnym agregatem a nie raportem z relacyjnej bazy, i opisze na modelach logikę dziedziny, kojarzenia płatności i faktur to mam to prawo to napisać jako analityk bo widzę w tym korzyści dla klienta. Nie napisze jak to zaimplementować bo to problem wykonawcy ale też nie pozwolę w trybie nadzoru autorskiego uprościć agregatu faktury tylko dlatego, ze klepania kodu dużo a mendejsy się kończą wykonawcy bo wygrał ceną, i w czym tu widzisz problem?

W praktyce taka analiza albo bedzie ignorowana albo bedzie zmuszac wykonawce do produkowania technicznych absurdow - tylko po to zeby spelnic wymagania formalne.

w moim przypadku (tak mam skonstruowaną umowę) żeby zignorować mój projekt musiał byś się z klientem pisemnie zrzec jego użycia.

jeżeli to będą absurdy to znaczy, że to zły projekt a nie o tym mówimy. Jak jest to jednak zły projekt to się to zgłasza grzecznie klientowi, na poparcie tezy że zły żąda audytu lub ekspertyzy (a najlepiej na początek autora projektu!)

Potem np. firma panstwowa stawia dwa (DEV/TST + PRD) dodatkowe, w zasadzie niepotrzebne serwery. Bo taki 'pejzaz' sobie pan XY, wykladowca z powaznej uczelni wczesniej wymyslil.
No ale zaplacone to trzeba postawic :)) )To nie sa zarty - mialem taki przypadek

jak ktoś nie radzi sobie z zarządzaniem .... każdy sensowny projekt ma procedurę zarządzania zmianą, w czym problem? Po drugie jeśli coś ustaliłem z klientem to nie muszę tłumaczyć tego wykonawcy, ten jest wykonawcą a nie projektantem. Dodam także, że bywają projekty w których zamawiający dzieli system na podsystemy i realizację zleca kilku wykonawcom po to by żaden nie ukradł pomysłu na całość bo żaden wykonawca nie ma kontaktu z całością logiki systemu a kradzieże pomysłów jest nagminna.

I dalej: wykonawca jako autor analizy i projektu ma prawa do niego, nie raz potem sprzedaje takie oprogramowanie wykonane w całości pod swoja nazwą konkurentom pierwszego klienta, klient który widzi takie ryzyko zleca opracowanie analizy i projektu komuś z zewnątrz a osobno zleca implementację w efekcie wykonawca nie nabywa żadnych praw do pomysły na system i jego logikę, więcej, jak go użyje to oberwie w sądzie.

Adam Kalinowski:
W tym przypadku przyczyna problemow nie byl dostawca, tylko niezalezny analityk wynajety przez korporacje

no to kiepściuchny był, ja nie raz widziałem projekt zwalony przez niezależnych wynajętych programistów i co?

Niestety w wielu przypadkach dostawca zamiast robić analizę lobbuje swoje gotowce

Bylo odwrotnie. Podam wiecej szczegolow:

Niezalezny analityk zapisal w swojej koncepcji zainstalowanie standardowego, katalogowego modulu SAP. Nie byl to ewidentny blad, bo bez problemu mozna bylo w ten sposob zrealizowac wymagania klienta. Chodzilo tylko o koszty i czas.

To czego klient naprawde potrzebowal stanowilo moze 5% funkcji instalowanego modulu.

no to obawiam się, że z tą niezależnością analityka był problem :) albo po protu nie potrafił zaprojektować dedykowanego modułu

Gdybysmy wykonanie tych funkcji zlecili programiscie koszt rozwiacania bylby kilkakrotnie nizszy i podprojekt trwalby krocej.

ano jak wyżej...dobra analiza zawiera alternatywne rozwiązania ryzykownych lub kosztownych komponentów...ale tu potrzebna jest analiza w tym wykonywalności... bez niej kupno "czegoś takiego co mają inni bo robią to samo" jest jak widać jednak ryzykiem...Jarek Żeliński edytował(a) ten post dnia 20.10.10 o godzinie 18:08

Mateusz Kurleto:

Adam Kalinowski:

Zdarza się i tak. Niemniej jednak wydaje się być rzadkością. Ja zakładając ten wątek przede wszystkim chciałem się dowiedzieć, dlaczego zapytania ofertowe są na dostarczanie jakiegoś wybranego narzędzia a nie realizację wyznaczonych celów i wymagań, gdzie ja, jako potencjalny dostawca mogę zaproponować rozwiązanie zgodnie z moją najlepszą wiedzą.

i jak sam kolega Kalinowski zauważył "taniej i lepiej niż gotowiec SAPa".