🚀 go-pugleaf

On Sun, 8 Oct 2006 13:12:35 +0000 (UTC), " Krzys"
<zhang_guolao.SKASUJ@gazeta.pl> wrote:
 
>Nie chce na razie przebijac sie przez 800-stronicowe cegly itd. Po porostu
>chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
>jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.

Bo to sa cegly. I nie prowadza do niczego.

A.L.

> >Nie chce na razie przebijac sie przez 800-stronicowe cegly itd. Po porostu
> >chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
> >jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
> 
> Bo to sa cegly. I nie prowadza do niczego.
> 
> A.L.

Dzieki za pomoc.. Nie trzeba bylo.

Wiem, ze czesto denerwujace i totalnie nie na miejscu sa pytania ludzi o
broszurke, z ktorej moglbym/moglabym sie nauczyc danego jezyka programowania,
bo takie cos jest niemozliwe i zawsze trzeba przebranac przez kilka ksiazek,
jeszcze wiecej przykladow itp. itd.
Aczkolwiek, zeby sie zainteresowac dana dziedzina i zaczac w niej drazyc
zawsze znajdzie sie jakis prosty (czyt. pokazowy) przyklad zastosowania danego
zagadnienia. (a potem jest czas na wgryzanie sie w temat)

Ale widac mialem pecha.. Na "dzien dobry" trafilem na osobe, ktora najpierw
przeczytala dziesiec 800 stronicowych ksiazek o programowaniu w jakims tam
jezyku (aczkolwiek jeszcze nie byla gotowa..), trzeba by bylo tu jeszcze
zrozumiec jak jezyki programowania w ogole moga dzialac - tak wiec krotkie
studia nad lingwistyka matematyczna... Potem jeszcze podstawy elektroniki..
(tak zeby nie bylo za latwo i zeby wiedziec jak to wszystko dziala) i
ostatecznie po (prawdopodobnie) wielu latach ciezkich studiow na ekranie
monitora pojawilo sie upragnione:
Hello world!

Gratuluje!!!
Krzysiek


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Sun, 8 Oct 2006 14:13:54 +0000 (UTC), " Krzysiek"
<zhang_guolao.WYTNIJ@gazeta.pl> wrote:

>> >Nie chce na razie przebijac sie przez 800-stronicowe cegly itd. Po porostu
>> >chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
>> >jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
>> 
>> Bo to sa cegly. I nie prowadza do niczego.
>> 
>> A.L.
>
>Dzieki za pomoc.. Nie trzeba bylo.
>
>Wiem, ze czesto denerwujace i totalnie nie na miejscu sa pytania ludzi o
>broszurke, z ktorej moglbym/moglabym sie nauczyc danego jezyka programowania,
>bo takie cos jest niemozliwe i zawsze trzeba przebranac przez kilka ksiazek,
>jeszcze wiecej przykladow itp. itd.

Nieprawda. 

>Aczkolwiek, zeby sie zainteresowac dana dziedzina i zaczac w niej drazyc
>zawsze znajdzie sie jakis prosty (czyt. pokazowy) przyklad zastosowania danego
>zagadnienia. (a potem jest czas na wgryzanie sie w temat)
>

Ale akurat jezykow programowania nie da sie uczyc "na
przykladzie"... Przynajmniej niektorych aspektow sie nei da.

>Ale widac mialem pecha.. Na "dzien dobry" trafilem na osobe, ktora najpierw
>przeczytala dziesiec 800 stronicowych ksiazek o programowaniu w jakims tam
>jezyku (aczkolwiek jeszcze nie byla gotowa..), trzeba by bylo tu jeszcze
>zrozumiec jak jezyki programowania w ogole moga dzialac - tak wiec krotkie
>studia nad lingwistyka matematyczna... Potem jeszcze podstawy elektroniki..
>(tak zeby nie bylo za latwo i zeby wiedziec jak to wszystko dziala) i
>ostatecznie po (prawdopodobnie) wielu latach ciezkich studiow na ekranie
>monitora pojawilo sie upragnione:
>Hello world!
>
>Gratuluje!!!

Gratulujesz czego? Ja napisalem nie wprost ze uwazam ze a) wszystkie
ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
kasy autorom, b) UML jako taki jest g.... warty.

A.L.

>Ja napisalem nie wprost ze uwazam ze a) wszystkie
> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
> kasy autorom, b) UML jako taki jest g.... warty.
> 
> A.L.

Jesli UML jest g..... warty, to co nie jest ? Jakie rozwiazania polecasz ?

A co do ksiazek.. no coz.. z nimi zle, bez nich tez niedobrze. Sa lepsze i
gorsze - ale generalnie dobrze, ze sa :-)

/Krzysiek

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On 2006-10-08, A.L wrote:
>>Gratuluje!!!
> Gratulujesz czego? Ja napisalem nie wprost ze uwazam ze a) wszystkie
> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
> kasy autorom, b) UML jako taki jest g.... warty.
Co do b) istnieje jakieś sensowne uzasadnienie?

-- 
Damian Szuberski

On Sun, 8 Oct 2006 14:32:12 +0000 (UTC), " Krzysiek"
<zhang_guolao.WYTNIJ@gazeta.pl> wrote:

>>Ja napisalem nie wprost ze uwazam ze a) wszystkie
>> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
>> kasy autorom, b) UML jako taki jest g.... warty.
>> 
>> A.L.
>
>Jesli UML jest g..... warty, to co nie jest ? Jakie rozwiazania polecasz ?
>
>A co do ksiazek.. no coz.. z nimi zle, bez nich tez niedobrze. Sa lepsze i
>gorsze - ale generalnie dobrze, ze sa :-)
>

Uzywam BON - Busines Object Notation: "Seam;ess Obejct-Oriented
Software Architecture: Analysis and Design of Reliable Systems", Kim
Wallden, & Jean-Marc Nerson, Prentice Hall, 1995. BON bazuje na
jezyku programwoania a nie obrazkach (chociaz obrazki mzoan uzyc do
ilustracji), albowiem jezyk programowwania jest jedynym jezykiem
ktory jest dostatecznie ekspresywny i precyzyjny zeby opisac systemy
ktoer sa bardziej zlozone niz "database front end".

Detale mozna znalezc tutaj

http://www.bon-method.com/index_normal.htm

tamze do sciagniecia ksiazka o ktorej pisze powyzej.

Natomiast jak juz musisz UML, to polecam ksiazke "UML Distilled: A
Brief Guide to the Standard Object Modeling Language", Martin
Fowler, Addison Wesley 2003. Wydanie ktore mam na polce nosi dumny
napis "Third Edition", ale chyba to nie jest wydanei ostatnie.
Ksiazka ma tylko 160 stron i objasnia szybko i dokladnie czym UML
jest a czym nie jest. 

Polecam etz "UNL in a Nutshell: A Desktop Quick Reference", Sinan Si
Albir, O'Reilly 1998, ale na pewno nowsze wydania sa.

Zupelnei zas najlepsza to "UML Pocket Reference", 

http://www.oreilly.com/catalog/uml2pr/

136 stron. 0 36 za duzo.

Natomiast ksziaki "gurus" wypada miec na polce tak jak Encyclopedia
Britannica - zeby zadziwic Krewnych i Znajomych. Ale w zadnym
wypadku nei czytac

A.L.

On Sun, 8 Oct 2006 14:33:55 +0000 (UTC), Damian 'legion' Szuberski
<elegion@tlen.-nospamplz-pl> wrote:

>On 2006-10-08, A.L wrote:
>>>Gratuluje!!!
>> Gratulujesz czego? Ja napisalem nie wprost ze uwazam ze a) wszystkie
>> ksiazki (no, z wyjatkiem broszurek) o UML to "hucpa" i nabijanie
>> kasy autorom, b) UML jako taki jest g.... warty.
>Co do b) istnieje jakieś sensowne uzasadnienie?

O uzasadnienei nalzey zapytac autorow. Moze cos meili na mysli...

A.L.

On Sun, 08 Oct 2006 10:14:00 -0500, A.L. <alewando@fala2005.com>
wrote:
 
>Uzywam BON - Busines Object Notation: "Seam;ess Obejct-Oriented
>Software Architecture: Analysis and Design of Reliable Systems"
[....]

Zapomnialem dopisac... Uzywam tez nagminnie notacji zwanej Z i
Object-Z oraz CSP-Z

A.L.

A.L. <alewando@fala2005.com> writes:

> On Sun, 08 Oct 2006 10:14:00 -0500, A.L. <alewando@fala2005.com>
> wrote:
>  
>>Uzywam BON - Busines Object Notation: "Seam;ess Obejct-Oriented
>>Software Architecture: Analysis and Design of Reliable Systems"
> [....]
>
> Zapomnialem dopisac... Uzywam tez nagminnie notacji zwanej Z 
> i Object-Z oraz CSP-Z

A język naturalny?

On 2006-10-08, A.L wrote:
>>> kasy autorom, b) UML jako taki jest g.... warty.
>>Co do b) istnieje jakieś sensowne uzasadnienie?
> O uzasadnienei nalzey zapytac autorow. Moze cos meili na mysli...
Jednak to Pańskie stwierdzenie więc prosiłbym o jaki(e)ś argument(y).

-- 
Damian Szuberski

On Sun, 8 Oct 2006 19:11:26 +0000 (UTC), Damian 'legion' Szuberski
<elegion@tlen.-nospamplz-pl> wrote:

>On 2006-10-08, A.L wrote:
>>>> kasy autorom, b) UML jako taki jest g.... warty.
>>>Co do b) istnieje jakieś sensowne uzasadnienie?
>> O uzasadnienei nalzey zapytac autorow. Moze cos meili na mysli...
>Jednak to Pańskie stwierdzenie więc prosiłbym o jaki(e)ś argument(y).

Albowiem nei jest ani uniwersalny ani nie jest jezykiem.

Dyskusja na ten temat toczyla sie na tej grupie periodyccznie przez
ostatnie 6 lat. Proponuje zajzrec do googli. Nie chce mi sie
powtarzac argumentow.

A.L.

> Po porostu
> chcialbym na jakims przykladzie zobaczyc, ze UML do czegos tam prowadzi... do
> jakiegos konkretnego zastosowania i ze dzieki niemu osiagamy jakis rezultat.
> 
> /Krzysiek

Abstrahujac od toczacej sie dyskusji o tym, ktore narzedzie jest lepsze/gorsze
od tego gorszego/lepszego czy znajdzie sie ktos kto da mi przyklad stosowania
owych narzedzi w projektowaniu aplikacji tak.. "od pomyslu do przemyslu" ? 
Z jednej strony rozumiem, ze stoswanie tak.. "poteznych" narzedzi do
malutkich, pokazowych projekcikow moze mijac sie z celem, ale z drugiej strony
ciezko mi uwiezyc, ze ktos kto nie ma w ogole doswiadczenia czy to z UML czy z
innym narzedziem od razu jest rzucany na gleboka wode i tak bez zadnego
doswiadczenia od razu projektuje i realizuje potezne aplikacje.

Pytam sie na grupie, gdyz nie udalo mi sie znalezc na googlach konkretnego,
rzeczywistego przykladu. Ciagle tylko jakies wydumane kawalki projektow, gdzie
nastepny krok w projektowaniu nijak sie nie ma do poprzedniego (juz nie mowiac
jak z tego mialby powstac kiedys realny kod i dzialajacy system).

Pozdrawiam,
Krzysiek


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

A.L. wrote:

> UML jako taki jest g.... warty.

UML jako taki (czyli oderwany od konkretnego języka programowania) jest 
OK, natomiast z mojego punktu widzenia problemem jest to, że większość 
jego propagatorów (i w rezultacie większość jego użytkowników) skupia 
się na jego wykorzytaniu w trybie "jeden prostokącik <-> jedna 
niskopoziomowa konstrukcja w kodzie źródłowym danego języka".
To faktycznie jest słabe.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Witam

Maciej Sobczak napisał(a):
> A.L. wrote:
>
> > UML jako taki jest g.... warty.

Tak ostro się nie wypowiadam, ale ten trend potrzymuję, bo ... (patrz
dalej)

> UML jako taki (czyli oderwany od konkretnego języka programowania) jest
> OK, natomiast z mojego punktu widzenia problemem jest to, że większość
> jego propagatorów (i w rezultacie większość jego użytkowników) skupia
> się na jego wykorzytaniu w trybie "jeden prostokącik <-> jedna
> niskopoziomowa konstrukcja w kodzie źródłowym danego języka".
> To faktycznie jest słabe.

Dodam, że jest wiele konstrukcji programistycznych związanych z
projektem klas,
których nie ma szans zapisać w UML. To powoduje, że np. genratory
kodu oparte o
schematy UML generują nie efektywny kod, albo go nie są wstanie
wygenerować.
Albo schemat narysowany nie jest efektywnie wykorzystany, ostatecznie
np. nie
ma zaznaczonych istotnych związków pomiędzy klasami, które są
istotne z punktu
widzenia programisty posługującego się schematem UML.
Co powoduje, że nie ma sensu jako tako rysować nic w UML, bo i tak
nie będzie 
można efektywnie rysunku wykorzystać.

Pozdrawiam.

Seweryn Habdank-Wojewódzki wrote:

> Co powoduje, że nie ma sensu jako tako rysować nic w UML, bo i tak
> nie będzie 
> można efektywnie rysunku wykorzystać.

Bez przesady. Eksportujesz UML do XMI (jeśli dane narzędzie tego nie 
umie, to je spuść z wodą) i zapinasz pasy.

Jak już pisałem, problemem jest zbytnie przywiązanie się do prostego 
mapowania UML na niskopoziomowe konstrukcje jakiegoś języka. Jeśli 
tekstowe wyklepanie klasy z kilkoma deklaracjami metod zajmuje mi 
kilkadziesiąt sekund i tyle samo zajmuje mi wyklikanie prostokącika na 
ekranie z sygnaturami tych samych metod, to zysku z zamiany edytora 
tekstu na program rysunkowy nie ma żadnego. Ale jeśli jesteś w stanie 
wykorzystać model (np. XMI) do generacji kodu na wyższym poziomie 
złożoności, to reszta jest ograniczona tylko Twoją wyobraźnią. UML jest 
wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby 
pokryć całkiem spory kawałek procesu produkcyjnego. Ale nie przy 
tradycyjnym, niskopoziomowym mapowaniu "prostokącik <-> klaska". 
Oczywiście, wymaga to inwestycji w generatory kodu, ale tam gdzie się to 
nie opłaca UML jest zwykle w ogóle do niczego nie potrzebny.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Witam

Maciej Sobczak napisał(a):
> Seweryn Habdank-Wojewódzki wrote:
>
> > Co powoduje, że nie ma sensu jako tako rysować nic w UML, bo i tak
> > nie będzie
> > można efektywnie rysunku wykorzystać.
>
> Bez przesady. Eksportujesz UML do XMI (jeśli dane narzędzie tego nie
> umie, to je spuść z wodą) i zapinasz pasy.

Nie to miałem na myśli. Oczywiście, że jak masz UML i możesz
przerzucić
to na XMI, a dalej na kod i to jest super.

> Jak już pisałem, problemem jest zbytnie przywiązanie się do prostego
> mapowania UML na niskopoziomowe konstrukcje jakiegoś języka. Jeśli
> tekstowe wyklepanie klasy z kilkoma deklaracjami metod zajmuje mi
> kilkadziesiąt sekund i tyle samo zajmuje mi wyklikanie prostokącika na
> ekranie z sygnaturami tych samych metod, to zysku z zamiany edytora
> tekstu na program rysunkowy nie ma żadnego.

Właśnie.

> Ale jeśli jesteś w stanie
> wykorzystać model (np. XMI) do generacji kodu na wyższym poziomie
> złożoności, to reszta jest ograniczona tylko Twoją wyobraźnią.

Lub możliwościami XMI albo UML.

> UML jest
> wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby
> pokryć całkiem spory kawałek procesu produkcyjnego.

Hmm... Jakoś nie dotarłem do tak obszernego kursu UML, czy coś
polecasz?

Kłopot polega na tym jak np. zaznaczyć, żeby genrator stworzył
pewną ilość
specjalizacji szablonu w C++.

W druga stronę ładne rysunki robi doksygen, czyli kiedy mam kod z
szablonami
i masz pewną ilość specjalizacji i konkretyacji, to w wyniku pracy
doxygena masz
do tego rysunek. Czyli doksygen sam znajduje w pewnym sensie pokrycie
klas.

Dzięki temu można sprawdzić jak się ma rzeczywisty kod w stosunku
do UML.
Ale UML nie ma opcji wskazywania na konkretyzacje czy specjalizacje.

A druga sprawa. jak ładnie można pokazać np.: Javowe

class Foo < ? extends Bar >
{}

To jest relatywnie silny kontrakt. I zapis ten dość mocno wpływa na
wygląd klasy
Foo i łączy ją z wyglądem klasy Bar, jaki on by nie był.
Oczywiście z punktu widzenia
konwersji UML -> Kod moge poprostu w << >> wpisać << ? extends Bar >>
i powinien
mi kod powstać dobry, bo generator powinien po prostu przepisać to co
jest w << >>. Ale na rysunku jakby coś ginie. Poza wpiszem w << >> nie
jest odnotowana żadna relacja.

Już nie mówię o C++ konstrukcjach typu:

// -- if construct ------------------------------------------------
// Proposed by Krzysztof Czarnecki and Ulrich Eisenecker

template <bool If, class Then, class Else> struct IF { typedef Then
RET; };

template <class Then, class Else> struct IF<false, Then, Else> {
  typedef Else RET;

};

Takie kwiatki w kodzie bardzo wiele potrafią zrobić. I to jest
robione z czasie konpilacji,
czyli to nie sa dynamiczne konstrukcje. To są bardzo silne
zależności pomiędy klasami
i typami. Tego UML nie potrafi "narysować". Zauważ, że relacje
tworzące sie przy użyciu
tego IF powodują związki pomiędzy klasami.

Zauważ, że _nie_ mówię tu o UML jako o sposobie rysowania klas.
Sugeruję, że jest
cienki do zaznaczania związków pomiędzy klasami. Wręcz sugeruję,
że potrafi robić tylko
podstawowe sprawy, takie, które sa statystycznie wykorzystaywane w
średnich
projektach biznesowych.

Nie wspominam tu żadnych skomplikowanych projektów bibliotek, bo UML
przy nich mięknie.
Zobacz jak bardzo różny jest obraz kodu kiedy masz po prostu klasy A,
B a inaczej jest
kiedy gdzieś masz IF < condition , A, B >

Oczywiście moja znajomość UML jest na poziomie UML 2.0. Rozszeżeń
nie znam wiele
albo nie jestem ich świadomy. Tak więc jeśli możesz wskazać na
jakieś opracowania
w których podjęte jest wyzwanie narysowania takich konstrukcji jak
"boost::" to chętnie
poczytam. Narazie jednak moja praca z projektem sprowadza się do
kartki papieru
i ołówka, czasem wspomagam się jakimś programikiem UML, ale w
zasadzie to korzystam
z tego co wypluwa z siebie doxygen. Czasami w kontekście wstecznego
reprojektowania
używam narzędzi typu gcov, aby zaznaczyć związki pomiędzy
obiektami, które nie są jawne,
np. użycie singletonów w klasach.

Pozdrawiam, Seweryn Habdank-Wojewódzki

Seweryn Habdank-Wojewódzki wrote:

>> UML jest
>> wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby
>> pokryć całkiem spory kawałek procesu produkcyjnego.
> 
> Hmm... Jakoś nie dotarłem do tak obszernego kursu UML, czy coś
> polecasz?

No nie wiem. Cokolwiek - chociaż i tak ostatecznym ograniczeniem będą 
możliwości danego programu rysunkowego. Większość z nich jest raczej 
sztywna w tym temacie.

> Kłopot polega na tym jak np. zaznaczyć, żeby genrator stworzył
> pewną ilość
> specjalizacji szablonu w C++.

Dobre pytanie. W ogólym podejściu rozwiązaniem może być komentarz 
przyczepiony do szablonu, w formacie rozpoznawanym przez generator 
(zakładam, że taki komentarz i jego relacja z szablonem będą zaznaczone 
w XMI - jeśli nie, to jest problem).

W wersji najbardziej wypasionej program rysunkowy mógłby umożliwiać 
rozszerzenie metamodelu UML - wtedy mogłbyś dodać sobie nowe elementy do 
składni UML a z drugiej strony nauczyć generator ich obsługi.
Ale nie słyszałem o takich cudach.
(Oczywiście, nie mam na myśli samodzielnego hackowania open-source'owego 
programu UML, tylko rozszerzalność metamodelu przewidzianą przez 
projektantów tego programu. :-) )

> A druga sprawa. jak ładnie można pokazać np.: Javowe
> 
> class Foo < ? extends Bar >
> {}
> 
> To jest relatywnie silny kontrakt. I zapis ten dość mocno wpływa na
> wygląd klasy
> Foo i łączy ją z wyglądem klasy Bar, jaki on by nie był.
> Oczywiście z punktu widzenia
> konwersji UML -> Kod moge poprostu w << >> wpisać << ? extends Bar >>
> i powinien
> mi kod powstać dobry, bo generator powinien po prostu przepisać to co
> jest w << >>. Ale na rysunku jakby coś ginie. Poza wpiszem w << >> nie
> jest odnotowana żadna relacja.

Można to << >> przykleić nie do klasy Foo, ale do relacji pomiędzy Foo i 
Bar. Wtedy będzie widać, że jest to cecha relacji a nie cecha jednej klasy.

> Już nie mówię o C++ konstrukcjach typu:
> 
> // -- if construct ------------------------------------------------
> // Proposed by Krzysztof Czarnecki and Ulrich Eisenecker
> 
> template <bool If, class Then, class Else> struct IF { typedef Then
> RET; };
> 
> template <class Then, class Else> struct IF<false, Then, Else> {
>   typedef Else RET;
> 
> };
> 
> Takie kwiatki w kodzie bardzo wiele potrafią zrobić.

A ja bym tego nie modelował w UML tylko raczej potraktował jako element 
języka. Obecność czegoś takiego na diagramie kompletnie niczego nie 
wnosi, bo ostatecznie struct IF jest tylko narzędziem do wyrażania 
relacji pomiędzy tymi typami, które są właściwą domeną dla 
analityka/projektanta. Dlatego posłużyłbym się raczej pojęciem IF w 
stereotypach albo innych dekoracjach w relacjach pomiędzy tymi 
właściwymi typami, zakładając, że IF jest już częścią języka 
programowania (dotyczy to wszystkich konstrukcji typu MPL).
Odpowiedni generator potrafiłby taką iluzję stworzyć.

> Tak więc jeśli możesz wskazać na
> jakieś opracowania
> w których podjęte jest wyzwanie narysowania takich konstrukcji jak
> "boost::" to chętnie
> poczytam.

Nie znam żadnych takich opracowań. :-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

UML to nie jest język programowania, jednego celem jest wsparcie procesu 
analizy, modelowanie i opracowanie koncepcji systemu oraz zebranie np. 
wymagań na system.

Jeżeli jakieś narzędzie pozwala wyeksportować model w tai sposób, że możliwe 
jest wygenerowanie nawet części kodu to mamy dodatkowo zmniejszenie 
pracochłonności.

Literatura podaje: dobre i udane projekty IT:
- 50% czasu na analizę i modelowanie
- 30% kodowanie
- 20% testy i oddanie do użytku.




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

Użytkownik "Maciej Sobczak" <no.spam@no.spam.com> napisał w wiadomości 
news:egvfml$4nf$1@cernne03.cern.ch...
> A.L. wrote:
>
>> UML jako taki jest g.... warty.
>
> UML jako taki (czyli oderwany od konkretnego języka programowania) jest 
> OK, natomiast z mojego punktu widzenia problemem jest to, że większość 
> jego propagatorów (i w rezultacie większość jego użytkowników) skupia się 
> na jego wykorzytaniu w trybie "jeden prostokącik <-> jedna niskopoziomowa 
> konstrukcja w kodzie źródłowym danego języka".
> To faktycznie jest słabe.
>
> -- 
> Maciej Sobczak : http://www.msobczak.com/
> Programming    : http://www.msobczak.com/prog/ 

Witam

Maciej Sobczak napisał(a):
> Można to << >> przykleić nie do klasy Foo, ale do relacji pomiędzy Foo i
> Bar. Wtedy będzie widać, że jest to cecha relacji a nie cecha jednej klasy.

Poproszę o przykład może być na priv.

> A ja bym tego nie modelował w UML tylko raczej potraktował jako element
> języka.

To nie chodzi tyle o język, bo gdyby w innym było to możliwe to też
byłoby dobrze.
Np. ciekawe są klasy w których możesz w runtime lub w czasie
kompilacji
rozszeżać ilośc metod. I tego też się nie da zobrazować.

Krótko mówiąc. UML staje się nażędziem, które przy pewnym
poziomie abstrakcji
jest tylko kulą u nogi, bo nie da się narysować tego co jest
ciężkie. Z rzeczy proste
są proste.
 Oczywiście rozumiem i cały czas podkreślam, że np. projekty
biznesowe są
wystarczająco proste strukturalnie, aby stosować UML. Mam nawet
informacje z
wiarygodnego zródła, że w Javie można wiele napisać tyko rysując
i kożystając
z gotowych beanów, to jest programowanie przez rysowanie :-).

> Obecność czegoś takiego na diagramie kompletnie niczego nie
> wnosi, bo ostatecznie struct IF jest tylko narzędziem do wyrażania
> relacji pomiędzy tymi typami, które są właściwą domeną dla
> analityka/projektanta. Dlatego posłużyłbym się raczej pojęciem IF w
> stereotypach albo innych dekoracjach w relacjach pomiędzy tymi
> właściwymi typami, zakładając, że IF jest już częścią języka
> programowania (dotyczy to wszystkich konstrukcji typu MPL).
> Odpowiedni generator potrafiłby taką iluzję stworzyć.

Czyli dochodzi Ci potrzeba użycia dodatkowego utilka pokazującego na
zależność
pomiędzy typami.

> > Tak więc jeśli możesz wskazać na
> > jakieś opracowania
> > w których podjęte jest wyzwanie narysowania takich konstrukcji jak
> > "boost::" to chętnie
> > poczytam.
>
> Nie znam żadnych takich opracowań. :-)

Szkoda :-).

Pozdrawiam, Seweryn Habdank-Wojewódzki.

Witam

Jarosław Żeliński napisał(a):
> UML to nie jest język programowania,

Oczywiście.

> jednego celem jest wsparcie procesu
> analizy, modelowanie i opracowanie koncepcji systemu oraz zebranie np.
> wymagań na system.

Tak. Tylko, że jest wiele utilków, które zamieniają UML na kod. A
dwa co zrobić, aby pokazać coś czego UML nie potrafi.

> Jeżeli jakieś narzędzie pozwala wyeksportować model w tai sposób, że możliwe
> jest wygenerowanie nawet części kodu to mamy dodatkowo zmniejszenie
> pracochłonności.

I tu włąsnie pojawia się drugi wspomniany przezemnie problem. Bo
nawet jeśli trzeba UML przepisać na kod. To i tak na diagrame UML
trzeba zaznaczyć ołówkiem to czego standard nie przewiduje.

> Literatura podaje: dobre i udane projekty IT:
> - 50% czasu na analizę i modelowanie
> - 30% kodowanie
> - 20% testy i oddanie do użytku.

To może być prawda nie potrafię ocenić, ale co jest ogólniejsze
niż UML czy BON tak, żeby
można było standardowo umijscowić nie tylko relacje pomiędzy
metodami, zawieraniem się obiektów czy innymi typowymi sprawami, a
także relacje pomiędzy
typami parametryzującymi.

Pozdrawiam, Seweryn Habdank-Wojewódzki

Jarosław Żeliński napisał(a):
> > 
> Literatura podaje: dobre i udane projekty IT:
> - 50% czasu na analizę i modelowanie
> - 30% kodowanie
> - 20% testy i oddanie do użytku.
> 
> 
> 
Ciekawe co to znaczy. Jak to mówią statystyka to najwyższy poziom kłamstwa.
Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
analiza : 5 osób pracuje przez rok -
testy : 30 osób pracuje przez miesiąc

i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%

Chyba że w "literaturze" podaje się czas adaptacji programu, to można 
się zgodzić. Ale jeżeli to są adaptacje (parametryzacja, modyfikacje czy 
jakkolwiek to nazwiemy) to należy to wyraźnie zaznaczyć. Czy innym jest 
tworzenie systemu od podstaw a czym innym przystosować istniejący do 
nowych potrzeb.

Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste. 
Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc 
analiza trwa 4 lata, konsumowane jest większość budżetu a potem 
informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się 
  nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system 
oczywiście przekraczając wszystkie limity oprócz  jakości. Żeby nie 
było, to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby 
ją tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to 
przykład jak przytoczone wskaźniki mogą powstawać.


Darek

DarekM <darekm@emadar.com> napisal:
> Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
> analiza : 5 osób pracuje przez rok -
> testy : 30 osób pracuje przez miesiąc
> i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
> SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%

Kula w plot. Te 5 osobolat to tylko customizacja, wiec nie
porownuj tego do czasochlonnosci napisania ERP-a, tylko
do czasochlonnosci napisania poprawek, dostosowan i raportow.
A to w 1 osoboroku sie zmiesci. Zreszta nie przesadzaj z tym
1K osobolat dla budowy ERP-a. To nie program Apollo :)

> Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste. 
> Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc 
> analiza trwa 4 lata, konsumowane jest większość budżetu a potem 
> informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się 
>   nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system 
> oczywiście przekraczając wszystkie limity oprócz  jakości. Żeby nie 
> było, to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby 
> ją tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to 
> przykład jak przytoczone wskaźniki mogą powstawać.

Przyklad instytucji budzetowej nie jest wlasciwy, bo to
patologia zarzadzania. Sam w takowej siedze jedna noga
i szlag mnie trafia, jak widze marnotrawsto nie tyle
pieniedzy wprost, ale mojego i kolegow czasu.

Glowne problemy trapiace kierownictwo:
a) jak tu zrobic, zeby nic nie zrobic,
b) jak juz trzeba cos zrobic, to jak to zrobic, aby nic nie zmienic,
c) jak tu zrobic, aby samemu zarobic (nagrody itp.), ale nie dac
zarobic nikomu nizej.

Niesmak bierze, tym bardziej, ze osoby utytulowane, wiec
w naiwnosci moznaby przypuszczac, ze na poziomie. Niestety,
stara kadra profesorska, ktora miala przynajmniej kindersztube
wymiera. A ja mimo kilkunastu lat pracy nie moge do tego
balaganu przywyknac.

Za duzo widac kontaktu ze zdrowym, drapieznym biznesem :)
-- 
Pozdrawiam,

Jacek

Jacek Pietraszek napisał(a):
> DarekM <darekm@emadar.com> napisal:
>> Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
>> analiza : 5 osób pracuje przez rok -
>> testy : 30 osób pracuje przez miesiąc
>> i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
>> SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%
> 
> Kula w plot. Te 5 osobolat to tylko customizacja, wiec nie
> porownuj tego do czasochlonnosci napisania ERP-a, tylko
> do czasochlonnosci napisania poprawek, dostosowan i raportow.

Popatrz na cel wypowiedzi. Właśnie to starałem się wykazać natomiast 
podane proporcje czasochłonności projektu IT tym nie wspominają (chyba 
że cytujący wyciął je z kontekstu). Ja mówię o wprowadzaniu w błąd 
takimi statystykami.

> A to w 1 osoboroku sie zmiesci. Zreszta nie przesadzaj z tym
> 1K osobolat dla budowy ERP-a. To nie program Apollo :)
Podałem konkretne oszacowanie dla SAP (bo słynny), oni tyle mają 
koderów. Natomiast dolne ograniczenie też mogę oszacować, nawet z 
autopsji. Tyle że nie o to tutaj chodzi
> 
>> Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste. 
>> Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc 
>> analiza trwa 4 lata, konsumowane jest większość budżetu a potem 
>> informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się 
>>   nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system 
>> oczywiście przekraczając wszystkie limity oprócz  jakości. Żeby nie 
>> było, to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby 
>> ją tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to 
>> przykład jak przytoczone wskaźniki mogą powstawać.
> 
> Przyklad instytucji budzetowej nie jest wlasciwy, bo to
> patologia zarzadzania. Sam w takowej siedze jedna noga
> i szlag mnie trafia, jak widze marnotrawsto nie tyle
> pieniedzy wprost, ale mojego i kolegow czasu.
> 
> Glowne problemy trapiace kierownictwo:
> a) jak tu zrobic, zeby nic nie zrobic,
> b) jak juz trzeba cos zrobic, to jak to zrobic, aby nic nie zmienic,
> c) jak tu zrobic, aby samemu zarobic (nagrody itp.), ale nie dac
> zarobic nikomu nizej.
> 

To dotyczy również instytucji naukowych oraz bardzo dużych firm. 
Oczywiście w mniejszym stopniu ale jednak.

> Niesmak bierze, tym bardziej, ze osoby utytulowane, wiec
> w naiwnosci moznaby przypuszczac, ze na poziomie. Niestety,
> stara kadra profesorska, ktora miala przynajmniej kindersztube
> wymiera. A ja mimo kilkunastu lat pracy nie moge do tego
> balaganu przywyknac.
Też mnie to rozczarowało
> 
> Za duzo widac kontaktu ze zdrowym, drapieznym biznesem :)

Wiadomo jak jest, delikatnie mówiąc nieidealnie. Mój głos ma na celu 
zwrócenie uwagi, albo raczej poszukiwanie drogi w zagadnieniu: "jak 
skutecznie wdrażać systemy IT" i to w takich warunkach i przy takich 
zasobach jakie są.

Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@gmail.com> napisał w 
wiadomości news:1161242352.864689.28680@e3g2000cwe.googlegroups.com...

Tak. Tylko, że jest wiele utilków, które zamieniają UML na kod. A
dwa co zrobić, aby pokazać coś czego UML nie potrafi.

> Tu chyba problem w tym, by nie traktowac UML (czy innych takich) jako 
> narzędzia programowania a tylo jako analityczne. Jeżeli ktos opisał np. 
> Use CAsem zawarł tak jakies Extendy ew, cos skomentował to programista ne 
> musi łazić po firmie klienta tyko siada i koduje, jego kompetencją jest 
> zreaizowac zamysł z projektu i ewentualnie podyskutowac z analitykiem, 
> jeżeli cos jest niewykonalne..

...
I tu włąsnie pojawia się drugi wspomniany przezemnie problem. Bo
nawet jeśli trzeba UML przepisać na kod. To i tak na diagrame UML
trzeba zaznaczyć ołówkiem to czego standard nie przewiduje.

> tu chyba pojawia się odwieczny problem: na ile korzytać ze standardów a na 
> ile z wąłsnych pomysłow....  potem przychodzi temat pracochłonności 
> konserwacji oprogramowania...


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

Tak się tworzy spiskowe teorie dziejów....

jest jednak istotna różnica pomiędzy pisaniem systemu na zamówienie a 
wdrażaniem gotowej kobyły z setkami parametrów. Po drugie pracochłonność i 
koszt nie tylko konsultantów z SAP oraz ich produkty (opracowania) nie są 
dla mnie żadnym wyznacznikiem, dla mnie miernikiem jakości pracy analityka 
jest różnica pomiędzy modelem jaki wykonał on przed wdrożeniem a tym co jest 
po jego zakończeniu.

Tu się okazuje, ze setki stron jakichś procesów narysowanych na bazie ankiet 
z pracownikami  (pomijam, że w Visio) bez żadnego odniesienia do rynkowych 
realiów analizowanej firmy prowadzi do pracy na półkę, której nawet zarząd 
firmy nie potrafi przebrnąć.

Tak więc analiza powinna moim zdaniem prowadzić do zrozumienia organizacji 
klienta, opisania tego jak pracuje (model procesowy) a potem do 
zaprojektowania narzędzia (czyli aplikacji) która tę organizację będzie 
wspierała (np. model w UML). 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.


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

Użytkownik "DarekM" <darekm@emadar.com> napisał w wiadomości 
news:eh8boo$s5t$1@node5.news.atman.pl...
> Jarosław Żeliński napisał(a):
>> >
>> Literatura podaje: dobre i udane projekty IT:
>> - 50% czasu na analizę i modelowanie
>> - 30% kodowanie
>> - 20% testy i oddanie do użytku.
>>
>>
>>
> Ciekawe co to znaczy. Jak to mówią statystyka to najwyższy poziom 
> kłamstwa.
> Weźmy na przykład takie wdrożenie SAP w przedsiębiorstwie
> analiza : 5 osób pracuje przez rok -
> testy : 30 osób pracuje przez miesiąc
>
> i to mniej więcej może wystąpić. Ale kodowanie sprawdźmy
> SAP "robi" 1000 osób przez 10 lat, więc chyba trochę więcej niż 30%
>
> Chyba że w "literaturze" podaje się czas adaptacji programu, to można się 
> zgodzić. Ale jeżeli to są adaptacje (parametryzacja, modyfikacje czy 
> jakkolwiek to nazwiemy) to należy to wyraźnie zaznaczyć. Czy innym jest 
> tworzenie systemu od podstaw a czym innym przystosować istniejący do 
> nowych potrzeb.
>
> Znam jeszcze jeden przypadek, że powyższe proporcje są rzeczywiste. 
> Instytucja otrzymuje grant (dotację) na system, czas trwania 5 lat. Więc 
> analiza trwa 4 lata, konsumowane jest większość budżetu a potem 
> informatycy muszą się uporać w rok z tym co otrzymali. Oczywiście że się 
> nie da, gdzieś pod koniec 5 roku wyrzucają analizę i kończą system 
> oczywiście przekraczając wszystkie limity oprócz  jakości. Żeby nie było, 
> to co trwało pierwsze 4 lata to dla mnie nie jest analiza (osoby ją 
> tworzące pewnie nie wiedziały co to jest). Podane zdarzenie to przykład 
> jak przytoczone wskaźniki mogą powstawać.
>
>
> Darek 

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
> 
> jest jednak istotna różnica pomiędzy pisaniem systemu na zamówienie a 
> wdrażaniem gotowej kobyły z setkami parametrów. Po drugie pracochłonność i 
> koszt nie tylko konsultantów z SAP oraz ich produkty (opracowania) nie są 
> dla mnie żadnym wyznacznikiem, dla mnie miernikiem jakości pracy analityka 
> jest różnica pomiędzy modelem jaki wykonał on przed wdrożeniem a tym co jest 
> po jego zakończeniu.
Można jeszcze wdrażać Excel/Visio . W większości przypadków robi się to 
bez analityka, a przydałby się czasami aby wytłumaczyć że jest ślepa 
uliczka.



> 
> Tak więc analiza powinna moim zdaniem prowadzić do zrozumienia organizacji 
> klienta, opisania tego jak pracuje (model procesowy) a potem do 
> zaprojektowania narzędzia (czyli aplikacji) która tę organizację będzie 
> wspierała (np. model w UML). 
W zasadzie masz rację , brakuje mi tylko stwierdzenia z jakim produktem 
startujemy. Czy to będzie rozwiązanie dedykowane (pisane od nowa na 
zamówienie) , parametryzowane (tak jak duże systemy ERP) czy też w miarę 
uniwersalny produkt który należy odpowiednio skonfigurować i nauczyć 
obsługiwać.




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.


  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).


Przykro mi ale wg mnie analityk bardzo przypomina mi architekta przy 
budowie domu. Zazwyczaj projekt domu obejmuje elementy zewnętrzne: bryłę 
domu kształt dachu, usadowienie na działce i tym podobne. Tak aby dom 
był śliczny. Natomiast funkcjonalność i ergonomia to dla wielu 
architektów nieznane pojęcia. To że łazienka jest na jednym końcu domu a 
kuchnia drugim to nic, przecież można zrobić 2,3 4 piony kanalizacyjne. 
To że do kuchni przechodzi się przez salon to również rzecz spotykana. 
Tyle że przynajmniej to jest. Natomiast brak: instalacji elektrycznej, 
alarmowej, telekomunikacyjnej, wentylacji, ogrzewania, dekoracje na 
ścianach, stolarka otworowa i wielu innych (każdy kto coś 
budował/remontował na podstawie projektu wie ile musiał podjąć decyzji).
Oczywiście istnieją dobrzy architekci ale żaden z nich nie schodzi do 
poziomu poszczególnych elementów kolejnych instalacji. To wykonują 
kolejne ekipy czasami tworząc projekt, czasami nie.

Proszę mnie uświadomić, czy analityk jest w stanie zawrzeć w analizie 
większość istotnych szczegółów koniecznych do zbudowania aplikacji. 
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.



Darek

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".

[...]
> Można jeszcze wdrażać Excel/Visio . W większości przypadków robi się to 
> bez analityka, a przydałby się czasami aby wytłumaczyć że jest ślepa 
> uliczka.

Ano święte słowa. To właśnie projekty powstaajce na bazie bezsensownych 
ankiet i dziesiątek niekontrolowalych schematów w Visio.

>> Tak więc analiza powinna moim zdaniem prowadzić do zrozumienia 
>> organizacji klienta, opisania tego jak pracuje (model procesowy) a potem 
>> do zaprojektowania narzędzia (czyli aplikacji) która tę organizację 
>> będzie wspierała (np. model w UML).
> W zasadzie masz rację , brakuje mi tylko stwierdzenia z jakim produktem 
> startujemy. Czy to będzie rozwiązanie dedykowane (pisane od nowa na 
> zamówienie) , parametryzowane (tak jak duże systemy ERP) czy też w miarę 
> uniwersalny produkt który należy odpowiednio skonfigurować i nauczyć 
> obsługiwać.

Moim zdaniem jeżeli planujemy wdrożenie gotowego systemu to robienie mapy 
procesów bardziej szczegołowej niż kluczowe zadania w firmie z 
uwzględnieniem podstawowych (nieusuwalych z firmy) dokumentów jest 
nieporozumiem.

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?


>
>  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".



> 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ć.


> 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.

-- 
-- 
Jarek
http://jarek.zelinski.biz.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

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 

DarekM <darekm@emadar.com> writes:

[...]

> 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ą.

A kto znał normy budowlane na schody: ty, architekt czy wykonawca?