🚀 go-pugleaf

I to mi się  podoba :), zgadzam sie z Tobą. Nieporozumienia to po prostu zła 
komunikacja :)

Ogólnie moim zdaniem jest tak prawie jak napisałeś:

jakieś dane -> czynność (praca np. analityka) -> produkt (np. model UML z 
efektami) -> programista (czyta model i wie co trza zakodować) -> program

do tego kilka iteracji jest luzik, podstawa: unormowane zakres 
odpowiedzialności i narzędzie komunikacji .. tych etapów pośrednich może być 
więcej ..ale sens jest taki



-- 
-- 
Jarek
http://jarek.zelinski.biz.pl/

Użytkownik "DarekM" <darekm@emadar.com> napisał w wiadomości 
news:ehlbc7$e3j$1@node5.news.atman.pl...
> Jarosław Żeliński napisał(a):
>> Użytkownik "DarekM" <darekm@emadar.com> napisał w wiadomości 
>> news:ehiped$10v$1@node5.news.atman.pl...
>>> Jarosław Żeliński napisał(a):
>>>> Tak się tworzy spiskowe teorie dziejów....
>>> To ty zacząłeś rzucając jakąś statystykę bez krzty komentarza. Ja tylko 
>>> chciałem pokazać jak można ją interpretować. Wiem że są to skrajności, 
>>> ale też wiem że nie wszystkie
>>
>> Masz rację, statyska ta dotyczyła projektów "pisania od zera".
>>
>> [...]
>
>> Jeżeli planujemy system od zera to dobrze jest opisać procesy do poziomu 
>> wszytkich czyności jakie są wykonywane w tym obszarze firmy który b ędzie 
>> beneficjentem nowego systemu (bez zbytnich szczegółów ich realizacji). 
>> Wtedy z takiej mapy procesów (po ewentualnej optymalizacji) bardzo łatwo 
>> wyłuskać wszystrkie przypadki użycia systemu.
>
>>
>>
>>> Po analityku może np. wejść sztab systemowców i
>>>> programistów, którzy szybko gotowy obiektowy projekt zakodują, i 
>>>> pierwsza wersja powinna być. Potem oczywiście ewentualne prace nad 
>>>> ulepszeniem.
>>>>
>>> I z tym się nie zgodzę. Takie rzeczy to tylko z gotowymi produktami. 
>>> Program narzuca pewien szkielet, którego musimy się trzymać. Analityk 
>>> musi podjąć 3-5 kluczowych decyzji związanych z dostosowanie programu do 
>>> klienta albo odwrotnie. Żeby nie było, uważam to za naprawdę trudne 
>>> zadanie.
>>>
>> Szkielet narzuca gotowy system, pisany na zamowienie żadnego. Czy źle 
>> zrozumiałem?
>
> No teraz już wiem w czym sie nie zgadzamy. Wg mnie stan jest taki: 
> analityk nie ma pojęcia co ma do zrobienia programista, a ten co analityk. 
> Konsekwencją tego jest umniejszanie roli tego drugiego.
> Dwa cytaty z głowy:
> "po co mi analityk (analiza) jeżeli klient za to nie chce zapłacić"
> "Po analizie programista szybko zakoduje projekt"
> To rodzi duże nieporozumienia, a potem urażona duma itd. (nie mówię że w 
> tej dyskusji się ktokolwiek obraził)
>
>
>
>>
>>
>>>  Jeżeli mówimy o systemach dedykowanych to pierwsza działająca wersja 
>>> będzie po ... latach. Jakaś część analizy się zdezaktualizuje, jakąś 
>>> trzeba będzie uzupełnić (czasami robią to programiści własnymi siłami).
>>> Natomiast oprócz zakodowania modelu należy jeszcze zrobić ten fragment 
>>> programu, który odpowiedzialny jest za funkcjonowanie programu w 
>>> rzeczywistości tak aby dane były wprowadzane sprawnie, pozyskiwane 
>>> informacje wiarygodnej system działał stabilnie przy takich zasobach i 
>>> takiej rzeczywistości jaka jest (a nie taka jak analityk założył, tzn. 
>>> jeżeli analityk nie założył błędów użytkownika to ich nie będzie).
>>>
>>>
>>
>> No to dyskusja raczej inna już dyskusja o sposobie tworzenia 
>> oprogramowanie. Nie zabiorę w niej głosu bo zawodowo nie koduję. Ale to 
>> tworzenie "przez lata" do mnie nie przemawia. No chyba, że siadają 
>> programiści i piszą "na czuja" bez modelu systemu, którego "oni nie 
>> potrzebują". Znam wiele takich projektów programistycznych, faktycznie 
>> mają szanse być "a lata".
> To powiedz mi dlaczego projekty typu Windows, Linux, Sap R3, Płatnik, 
> Poltax powstawały lata. Bynajmniej nie dlatego że nie miały fazy analizy 
> ani że oszczędzali na analitykach.
>>
> Widziałem projekt konsolidacji bilansu dla korporacji, niby poważna 
> sprawa. Projekt się udał i działa ale z punktu widzenia informatycznego to 
> tylko przekształcenie 2000 liczb w 200. Działało bo człowiek+Excel+Akces 
> są w stanie to ogarnąć. Gdyby natomiast chodziło o 20000 liczb, lub co 
> gorsza 2000000 to błędne były fundamentalne założenia. Proszę popatrz jak 
> dławią się aplikacje dla ZUS, Urzędu skarbowego. I kto jest winien 
> programista który nie potrafi spełnić nierealnych życzeń analityka, czy 
> analityk który nie uwzględnił możliwości technologicznych. A może w celu 
> stworzenia dużego systemu informatycznego należy wykonać dogłębną analizę, 
> która stanowi szkielet na którym programiści "dziergają" oczko po oczku 
> każdy element składowy.
>>
>>
>>> Przykro mi ale wg mnie analityk bardzo przypomina mi architekta przy 
>>> budowie domu. Zazwyczaj projekt domu obejmuje elementy zewnętrzne: bryłę
>> [...]
>> Owszem, ale opisałeś tu architekta, który stworzył projekt domu bez 
>> wymagań przyszłego użytkownika tylko na bazie swojego widzimisię. Np. 
>> kuchnia z przejściem przez salon mnie osobiście pasuje, jest ona u mnie 
>> elementem użytkowego parteru. Więc kwestia gustu a to kolejny przyczynek 
>> do wykonania bardzo dokładnej analizy wymagań.
>>
>>> Proszę mnie uświadomić, czy analityk jest w stanie zawrzeć w analizie 
>>> większość istotnych szczegółów koniecznych do zbudowania aplikacji.
>>
>> Czyli jakich? Funkcjonalnych czy kodowych? Posługując się porównaniem do 
>> architekta: architekt powinien umieć zaprojektwac dom wygodny i 
>> akceptowalny dla użytkownika, zaś to czy rurki będą z PCV czy z miedzi to 
>> inna decyzja i to dla inżyniera a nie architeta (może on cos sugerowąć) 
>> ale łazienka i woda w kranie zimna i ciepła musi być.
>
> A kto to ma zrobić jak nie architekt. Przecież inżynier nie będzie 
> montować instalacji. Pamiętaj że to użyte na potrzeby analogii. Jeżeli 
> instalację dobiera inżynier to tworzy on kolejny projekt, kolejną analizę. 
> Przecież programista tylko koduje.
>
> Przykład z życia: zamówiłem projekt schodów tzn. chciałem wygodnie móc 
> wchodzić na piętro, schody miały być w korytarzu w istniejącym budynku. 
> Architekt zrobił projekt a jakże, kilkanaście stron rysunków i obliczeń. 
> Tyle że zupełnie nieprzydatny. Jedyny wymiar który sie zgadzał to była 
> liczba schodów (którą to i tak musiałem wybrać). Reszta łącznie z 
> szerokością, wysokością poręczy, punktem zaczepienia uzgadniałem na 
> bieżąco z wykonawcą. Belka stropowa była grubsza niż krokwie w kościele 
> itd.
>
> Wiem że to był patałach a nie architekt, ale nie mów że ten jest jedynie 
> do policzenia ilości schodów.
>
> Trochę inna analogia to projektant samochodów.  Ten też ma się pytać 
> przyszłego użytkownika o twardość amortyzatorów, czy może inżyniera w 
> montowni.
>>
>>
>>> Kolejne porównanie: czy dobra analiza stanowi coś w stylu partytury, na 
>>> podstawie której można rozpisać nuty dla każdego instrumentu nieomal 
>>> automatycznie. Wg mnie nie, ale może się nie znam.
>>>
>> Partytura to właśnie rozpisane nuty na instrumenty. Rzecz w tym, że to 
>> dyrygent i wykonawcy intepretują utwór napisany przez kompozytora i nie 
>> widze tu żadnej sprzecznosci :). Należy tylko pamiętać, że nawet 
>> najlepszy utwór można spaprać ale najlepszy dyrygent i muzycy nie 
>> naprawią nudnego i niedajacego sie słuchac utworu.
>
> Bardzo dobrze interpretacja jest bardzo blisko implementacji. Pytanie 
> tylko czy nie mamy do czynienia z improwizacją na dużą skalę.
>
>
> Mam wrażenie że obecnie to występują dwa przypadki. Pierwszy analityk po 
> dokonaniu analizy koduje/parametryzuje system. Drugi programista aby 
> system zrealizować wykonuje analizę na własne potrzeby.
> Ustalmy podział pracy pomiędzy analityka i programistę a wtedy można 
> będzie oszacować wkład pracy.
>
>
>
> Darek