🚀 go-pugleaf

On Thu, 23 Aug 2007 15:33:30 +0200, "Filip Sielimowicz" <sielim@wp.pl>
wrote:

>Interesuje mnie zagadnienie znalezienia dobrej analogii między konstrukcją 
>systemu informatycznego
>a konstrukcją jakiegoś złożonego bytu, np. architektonicznego (wysokościowca 
>? wiaduktu w miejscu przecięcia
>się dwóch autostrad ?).
>
  
> 

Wizezowiec: a) trzeba miec plan architektoniczny, b) tzreba miec plan
konstrukcyjny. Plan konstrukcyjny musi byc wykonany przez inzynierow
posiadaajcych odpowiednei uprawnienia, c) plany musza byc zatwierdzone
pzrez odpowiednie uzredy miejskie, a to co do lokacji a to co do
wygladu, a to co do spraw ekologicznych, d) Budowa odbywa sie pod
nadzorem odpowiednich fachowcow z miaste, inspektorow budowlanych (czy
"kody" sa pzresztregane), inzynierow srodowiska, a sama firma jest
prowadzona przez inzynierow posiadajacych odpowiednei uprawnienia, e)
Po zakonczeniu budynek pzrechodzi szcagolowa inspekcja odpowiednich
uzredow miasta (owe "kody", sprawy ekologiczne, bezpieczenstwo,
zgodnosc z dokumentacja), a jezeli jest na przyklad blisko autostrady
i moga z tego wyniknac problemy, to i pzrez nadzor panstwowy

Budowa systemu informatycznego: a) CHLOPAKI, LAC BETON! Co mi tam beda
p... o jakiejs dokumentacji! b) Jak cos spieprzymy to sie odkuje.

A.L.

Filip Sielimowicz pisze:
> Interesuje mnie zagadnienie znalezienia dobrej analogii między konstrukcją 
> systemu informatycznego
> a konstrukcją jakiegoś złożonego bytu, np. architektonicznego (wysokościowca 
> ? wiaduktu w miejscu przecięcia
> się dwóch autostrad ?).

Mnie się wydaje, że dobrą analogią jest budowa miasta, tzn. tu budujemy dom, tam 
drogę, teraz most, a potem remontujemy kanalizację




  Od modernizacji oczekuje się spełnienia
> dwóch podstawowych celów:
>  - system ma zostać przeniesiony na relacyjną bazę danych (bezpieczeństwo 
> danych i inne)
>  - system ma uzyskać architekturę umożliwiającą jego rozwój (kontrolowane, 
> bezpieczne spełnianie żądań zmian - zapanować
> nad powiązaniami w systemie)

Ten drugi jest ważniejszy. Im lepsza architektura tym prostsze przeniesienie i 
inne zmiany, a te mogą być ważniejsze. O ile się nie wybierze budowy od podstaw to 
jest to raczej operacja na otwartym sercu. Kluczowym jest takie przerobienie, a 
właściwie przerabianie kodu aby można było go sprawnie ... przerabiać, czyli aby 
system realizował kolejne zadania. Czy baza centralna, która technologia, gdzie 
wyznaczyć warstwy to tak jakbyś pytał mieszkańców miasta:
-- ile ma być przystanków, dworców, lotnisk
-- z czego budujemy domy
-- czym ogrzewamy
-- jakie napięcie ma być w sieci


A jeżeli spytasz kogoś innego, to sprawdź w jakim mieście żyje.

> 
> Macie jakieś pomysły, jak wybrnąć z tej sytuacji ? :)))

Nie, ale jak wymyślisz jak to zrobić tanio, szybko i przyjemnie to się pochwal, 
niekoniecznie bezinteresownie.

Albo jeden: znaleźć nową funkcjonalność, niedostępną dla dotychczasowej 
architektury i wokół niej oprzeć całą migrację, dzięki czemu klient (zewnętrzny 
lub wewnętrzny)  otrzyma realną  korzyść i wytrzyma koszty migracji (czas, 
pieniądze, nerwy).

Darek

DarekM <darekm@emadar.com> writes:

> Filip Sielimowicz pisze:
>> Interesuje mnie zagadnienie znalezienia dobrej analogii między
>> konstrukcją systemu informatycznego a konstrukcją jakiegoś
>> złożonego bytu, np. architektonicznego (wysokościowca ? wiaduktu
>> w miejscu przecięcia się dwóch autostrad ?).
>
> Mnie się wydaje, że dobrą analogią jest budowa miasta, tzn. tu
> budujemy dom, tam drogę, teraz most, a potem remontujemy kanalizację

Czyli Debian to miasto, które można dostosować do własnych potrzeb?

Piotr Dembiński pisze:
> DarekM <darekm@emadar.com> writes:
> 
>> Filip Sielimowicz pisze:
>>> Interesuje mnie zagadnienie znalezienia dobrej analogii między
>>> konstrukcją systemu informatycznego a konstrukcją jakiegoś
>>> złożonego bytu, np. architektonicznego (wysokościowca ? wiaduktu
>>> w miejscu przecięcia się dwóch autostrad ?).
>> Mnie się wydaje, że dobrą analogią jest budowa miasta, tzn. tu
>> budujemy dom, tam drogę, teraz most, a potem remontujemy kanalizację
> 
> Czyli Debian to miasto, które można dostosować do własnych potrzeb?
Nie rozumiem pytania (o ile mam tak to traktować)

Pytanie było o proces tworzenia a nie używania. A nawet jeżeli to  należy 
porównywać używanie z zamieszkiwaniem. Też wiele analogii można znaleźć.

Darek

DarekM <darekm@emadar.com> writes:

[...]

>>> Mnie się wydaje, że dobrą analogią jest budowa miasta, tzn. tu
>>> budujemy dom, tam drogę, teraz most, a potem remontujemy
>>> kanalizację
>> Czyli Debian to miasto, które można dostosować do własnych potrzeb?
> Nie rozumiem pytania (o ile mam tak to traktować)
>
> Pytanie było o proces tworzenia a nie używania. A nawet jeżeli to
> należy porównywać używanie z zamieszkiwaniem. Też wiele analogii
> można znaleźć.

OIDP dziedziną nauki traktującą o systemach w sposób niezależny natury
i przeznaczenia tych systemów jest teoria systemów.  Czyli zarówno
systemy miejskie, jak i systemy komputerowe można rozpatrywać
w kategoriach teorii systemów, a w konstrukcji oraz konserwacji 
tych systemów stosować zdobycze inżynierii systemów.

-- 
http://www.piotr.dembiński.prv.pl

>> Pytanie było o proces tworzenia a nie używania. A nawet jeżeli to
>> należy porównywać używanie z zamieszkiwaniem. Też wiele analogii
>> można znaleźć.
> 
> OIDP dziedziną nauki traktującą o systemach w sposób niezależny natury
> i przeznaczenia tych systemów jest teoria systemów.  Czyli zarówno
> systemy miejskie, jak i systemy komputerowe można rozpatrywać
> w kategoriach teorii systemów, a w konstrukcji oraz konserwacji 
> tych systemów stosować zdobycze inżynierii systemów.

No i ...
Tak, istnieje taka nauka. Tylko co z tego wynika dla pytacza. Same osiągnięcia są 
dosyć dyskusyjne. Przyjmując jednak że są całkowicie prawdziwe to pewnie są tak 
użyteczne jak prawo Ohma przy konstruowaniu telewizora a prawa Newtona do budowy 
dźwigu. Po drugie przypuszczam że większościowym beneficjentem byłaby sama teoria 
systemów a nie rozwiązanie problemu, tzn. na podstawie przeprowadzonych działań 
można by coś nieco wnieść do teorii, w drugą stronę transfer wiedzy jakoś wydaje 
mi się mało prawdopodobny. Może jedynie terminologia była by pomocna, o ile pytacz 
nie dysponuje własną systematyką.


Darek

On 23 Sie, 16:19, A.L. <f...@2005.com> wrote:
> On Thu, 23 Aug 2007 15:33:30 +0200, "Filip Sielimowicz" <sie...@wp.pl>
> wrote:
>
> >Interesuje mnie zagadnienie znalezienia dobrej analogii między konstrukcją
> >systemu informatycznego
> >a konstrukcją jakiegoś złożonego bytu, np. architektonicznego (wysokościowca
> >? wiaduktu w miejscu przecięcia
> >się dwóch autostrad ?).
>
> Wizezowiec: a) trzeba miec plan architektoniczny, b) tzreba miec plan
> konstrukcyjny. Plan konstrukcyjny musi byc wykonany przez inzynierow
> posiadaajcych odpowiednei uprawnienia, c) plany musza byc zatwierdzone
> pzrez odpowiednie uzredy miejskie, a to co do lokacji a to co do
> wygladu, a to co do spraw ekologicznych, d) Budowa odbywa sie pod
> nadzorem odpowiednich fachowcow z miaste, inspektorow budowlanych (czy
> "kody" sa pzresztregane), inzynierow srodowiska, a sama firma jest
> prowadzona przez inzynierow posiadajacych odpowiednei uprawnienia, e)
> Po zakonczeniu budynek pzrechodzi szcagolowa inspekcja odpowiednich
> uzredow miasta (owe "kody", sprawy ekologiczne, bezpieczenstwo,
> zgodnosc z dokumentacja), a jezeli jest na przyklad blisko autostrady
> i moga z tego wyniknac problemy, to i pzrez nadzor panstwowy
>
> Budowa systemu informatycznego: a) CHLOPAKI, LAC BETON! Co mi tam beda
> p... o jakiejs dokumentacji! b) Jak cos spieprzymy to sie odkuje.

To prawda, że większość projektów informatycznych tak wygląda, ale ten
przykład pokazuje właśnie, że analogia jest totalnie chybiona, co nie
po raz pierwszy powtarzam.

System informatyczny to zupełnie inne charakterystyki zarówno
materiału, jak i sposobu wykonania, weryfikacji, diagnostyki,
przewidywalności, komplikacji logicznej - w skrócie, te dwie koncepcje
różnią się niemal wszystkim. Jeśli coś one mają ze sobą wspólnego to
to, że obie są projektami inżynierskimi i obie muszą spełniać
określone kryteria. Ale na tym podobieństwa się kończą.

Po pierwsze: oczywiście, że możemy poprawiać później, bo system
informatyczny daje nam taką możliwość. Jeśli aplikacja wywala się na
jakichś danych - poprawimy. Nie da się tego zrobić w przypadku
budynków - jak jest kolumna nie w tym miejscu co trzeba, to żeby się
człowiek zesrał, nie przestawi jej w inne miejsce. Zgadza się, to
wielu rozleniwia i pozwala odłożyć na bok myśl o dokładnym
dopracowaniu. Ale to nie jest jedyna przyczyna takiego podejścia.

Po drugie: jakich wiadomości teoretycznych potrzebujemy, żeby postawić
budynek? Wszystko to jest chemia, fizyka, no i oczywiście ekonomia. A
co się dzieje w systemach informatycznych? Okazuje się, że
charakterystyki funkcjonowania takiego systemu są za każdym razem
inne. A na dodatek niestabilne.

Już znacznie bardziej mi się podobała analogia do stoczni.

Użytkownik "ethouris" <ethouris@gmail.com> napisał w wiadomości 
news:1188252081.622766.220450@50g2000hsm.googlegroups.com...
On 23 Sie, 16:19, A.L. <f...@2005.com> wrote:
> On Thu, 23 Aug 2007 15:33:30 +0200, "Filip Sielimowicz" <sie...@wp.pl>
> wrote:
>
> >Interesuje mnie zagadnienie znalezienia dobrej analogii między 
> >konstrukcją
> >systemu informatycznego
> >a konstrukcją jakiegoś złożonego bytu, np. architektonicznego 
> >(wysokościowca
> >? wiaduktu w miejscu przecięcia
> >się dwóch autostrad ?).
>
> Wizezowiec: a) trzeba miec plan architektoniczny, b) tzreba miec plan
> konstrukcyjny. Plan konstrukcyjny musi byc wykonany przez inzynierow
> posiadaajcych odpowiednei uprawnienia, c) plany musza byc zatwierdzone
> pzrez odpowiednie uzredy miejskie, a to co do lokacji a to co do
> wygladu, a to co do spraw ekologicznych, d) Budowa odbywa sie pod
> nadzorem odpowiednich fachowcow z miaste, inspektorow budowlanych (czy
> "kody" sa pzresztregane), inzynierow srodowiska, a sama firma jest
> prowadzona przez inzynierow posiadajacych odpowiednei uprawnienia, e)
> Po zakonczeniu budynek pzrechodzi szcagolowa inspekcja odpowiednich
> uzredow miasta (owe "kody", sprawy ekologiczne, bezpieczenstwo,
> zgodnosc z dokumentacja), a jezeli jest na przyklad blisko autostrady
> i moga z tego wyniknac problemy, to i pzrez nadzor panstwowy
>
> Budowa systemu informatycznego: a) CHLOPAKI, LAC BETON! Co mi tam beda
> p... o jakiejs dokumentacji! b) Jak cos spieprzymy to sie odkuje.

To prawda, że większość projektów informatycznych tak wygląda, ale ten
przykład pokazuje właśnie, że analogia jest totalnie chybiona, co nie
po raz pierwszy powtarzam.

System informatyczny to zupełnie inne charakterystyki zarówno
materiału, jak i sposobu wykonania, weryfikacji, diagnostyki,
przewidywalności, komplikacji logicznej - w skrócie, te dwie koncepcje
różnią się niemal wszystkim. Jeśli coś one mają ze sobą wspólnego to
to, że obie są projektami inżynierskimi i obie muszą spełniać
określone kryteria. Ale na tym podobieństwa się kończą.

Nie zgodzę się z takim sposobem argumentacji, gdzie pojawiają się
np. pojęcia "zupełnie inne charakterystyki" ;). Analogii jeszcze tu nie 
skonstruowaliśmy,
a już pada 'totalnie chybiona" ;).

Ja rozumiem, że materiał jest inny, ale zwracam uwagę na to, że jednak ten 
"materiał"
opisuje się tymi samymi przymiotnikami z języka naturalnego. I dlatego 
właśnie
jest podstawa do szukania analogii.

Im "wyżej", tym analogii jest wiecej. Najwyżej mamy "oczekiwania klienta",
"koszty budowy", "koszty utrzymania". W sensie zarządczym, z punktu widzenia
procesu wytwarzania systemu informatycznego, jest to po prostu 
przedsięwzięcie
biznesowe którego celem jest wytworzenie i sprzedaż produktów o pożądanej
jakości. Pytanie jest, jak teraz stopniowo schodzić z tym na dół: wyznaczać
podprodukty, miary ich jakości, powiązania, koszty utrzymania, koszty
naprawy/modernizacji, koszty wymiany.

> Nie da się tego zrobić w przypadku budynków - jak jest kolumna nie w tym
> miejscu co trzeba, to żeby się człowiek zesrał, nie przestawi jej w inne 
> miejsce.
> Zgadza się, to wielu rozleniwia i pozwala odłożyć na bok myśl o dokładnym
> dopracowaniu. Ale to nie jest jedyna przyczyna takiego podejścia.
1. A kto powiedział, że odpowiednikiem danych jest kolumna ?
2. Da się. Tylko problem jest źle postawiony. Nikt nie przenosi kolumny
dla idei. Za tym stoi jakieś wymaganie funkcjonalne/niefunkcjonalne.
Być może kolumna zasłania drzwi wejściowe. Rozwiązanie: zamieniamy
kolumnę łukiem. Tak - to kosztuje. Trzeba zastosować tymczasowe podparcie
i kilka innych technicznych tricków. Ale jest to do zrobienia. W górnictwie
czy przy renowacji mostów zapewne nie takie rzeczy się robi. Nawet całe
budynki się przesuwa razem z kawałkiem ziemi.

>Po drugie: jakich wiadomości teoretycznych potrzebujemy, żeby postawić
>budynek? Wszystko to jest chemia, fizyka, no i oczywiście ekonomia. A
>co się dzieje w systemach informatycznych? Okazuje się, że
>charakterystyki funkcjonowania takiego systemu są za każdym razem
>inne. A na dodatek niestabilne.
Mózg człowieka opisuje rzeczywistość w kategoriach przestrzeni i pojęć 
fizycznych
gdzie mamy pojęcie góry, dołu, ciężaru, szybkości, ścieżki 
wąskiej/szerokiej,
pozycji/adresu, 'zmieści się/nie zmieści', przyczepiony/luźny, itp. 
Informatycy nie są tu
wyjątkiem - tylko sobie często sami robią pod górę nie w pełni zdając sobie 
z tego
sprawę.

> Już znacznie bardziej mi się podobała analogia do stoczni.
Bardzo poproszę o więcej szczegółów tej analogii ;)

Użytkownik "ethouris" <ethouris@gmail.com> napisał w wiadomości
news:1188252081.622766.220450@50g2000hsm.googlegroups.com...
On 23 Sie, 16:19, A.L. <f...@2005.com> wrote:

>To prawda, że większość projektów informatycznych tak wygląda, ale ten
>przykład pokazuje właśnie, że analogia jest totalnie chybiona, co nie
>po raz pierwszy powtarzam.

>System informatyczny to zupełnie inne charakterystyki zarówno
>materiału, jak i sposobu wykonania, weryfikacji, diagnostyki,
>przewidywalności, komplikacji logicznej - w skrócie, te dwie koncepcje
>różnią się niemal wszystkim. Jeśli coś one mają ze sobą wspólnego to
>to, że obie są projektami inżynierskimi i obie muszą spełniać
>określone kryteria. Ale na tym podobieństwa się kończą.

Nie zgodzę się z takim sposobem argumentacji, gdzie pojawiają się
np. pojęcia "zupełnie inne charakterystyki" ;). Analogii jeszcze tu nie
skonstruowaliśmy, a już pada określenie 'totalnie chybiona" ;).

Ja rozumiem, że materiał jest inny, ale zwracam uwagę na to, że jednak ten
"materiał" opisuje się tymi samymi przymiotnikami z języka naturalnego. I 
dlatego
właśnie jest podstawa do szukania analogii.

Im "wyżej", tym analogii jest wiecej. Najwyżej mamy "oczekiwania klienta",
"koszty budowy", "koszty utrzymania". W sensie zarządczym, z punktu widzenia
procesu wytwarzania systemu informatycznego, jest to po prostu
przedsięwzięcie biznesowe którego celem jest wytworzenie i sprzedaż
produktów o pożądanej jakości. Pytanie jest, jak teraz stopniowo schodzić
z tym na dół: wyznaczać podprodukty, miary ich jakości, powiązania, koszty
utrzymania, koszty naprawy/modernizacji, koszty wymiany.

> Nie da się tego zrobić w przypadku budynków - jak jest kolumna nie w tym
> miejscu co trzeba, to żeby się człowiek zesrał, nie przestawi jej w inne
> miejsce.
> Zgadza się, to wielu rozleniwia i pozwala odłożyć na bok myśl o dokładnym
> dopracowaniu. Ale to nie jest jedyna przyczyna takiego podejścia.

1. A kto powiedział, że odpowiednikiem danych jest kolumna ?
2. Da się. Tylko problem jest źle postawiony. Nikt nie przenosi kolumny
dla idei. Za tym stoi jakieś wymaganie funkcjonalne/niefunkcjonalne.
Być może kolumna zasłania drzwi wejściowe. Rozwiązanie: zamieniamy
kolumnę łukiem. Tak - to kosztuje. Trzeba zastosować tymczasowe podparcie
i kilka innych technicznych tricków. Ale jest to do zrobienia. W górnictwie
czy przy renowacji mostów zapewne nie takie rzeczy się robi. Nawet całe
budynki się przesuwa razem z kawałkiem ziemi.

>Po drugie: jakich wiadomości teoretycznych potrzebujemy, żeby postawić
>budynek? Wszystko to jest chemia, fizyka, no i oczywiście ekonomia. A
>co się dzieje w systemach informatycznych? Okazuje się, że
>charakterystyki funkcjonowania takiego systemu są za każdym razem
>inne. A na dodatek niestabilne.

Mózg człowieka opisuje rzeczywistość w kategoriach przestrzeni i pojęć
fizycznych gdzie mamy pojęcie góry, dołu, ciężaru, szybkości, ścieżki
wąskiej/szerokiej, pozycji/adresu, 'zmieści się/nie zmieści', 
przyczepiony/luźny,
itp. Informatycy nie są tu wyjątkiem - tylko sobie często sami robią pod
górę nie w pełni zdając sobie z tego sprawę.
Do pojęć fizycznych działających głównie na zmysł wzroku, postrzegamy także
bardzo silnie rzeczywistość w kategoriach bardziej abstrakcyjnych, np. 
związanych
z granicami (pojęcie własności), relacjami(powiązaniami - np. rodzinnymi), 
które
zaś są nośnikiem dla procesu komunikacji (np. wyrażania potrzeb, wymiany 
dóbr).
To także mamy niejako "we krwi" aczkolwiek temat jest bardziej złożony, 
trudniej
go związać z wyobraźnią przestrzenną. Problem właśnie w tym, że systemy 
informatyczne
uderzają głównie w te pojęcia bardziej abstrakcyjne. Ale budowle 
architektoniczne
typu skrzyżowanie autostrad są pewnego rodzaju wizualizacjami fizycznymi 
pojęć
abstrakcyjnych z działki komunikacji - i tu być może właśnie jest pole do 
budowania
analogii/jej fragmentów.

> Już znacznie bardziej mi się podobała analogia do stoczni.
Bardzo poproszę o więcej szczegółów tej analogii ;) 

Witam

Filip Sielimowicz wrote:

> Nie zgodzę się z takim sposobem argumentacji, gdzie pojawiają się
> np. pojęcia "zupełnie inne charakterystyki" ;). Analogii jeszcze tu nie
> skonstruowaliśmy, a już pada określenie 'totalnie chybiona" ;).

[...]

Bazrdzo dobre wyabstrachownie problemu.

Może dodam tylko, taki wniosek racjonalizatorski. W informatyce jak i w
architekturze dość dobrze są opracowane metody specyfikowanie, i
projektowania. Natomiast IMHO miażdząca różnica polega na: 

1. Time to market. W budownictwie nikt się tak nie śpieszy. To znaczy jak
się ktoś pospieszy, to się to kończy jak z budową jednego mostu w Wawie,
gdzie ktoś "przeoczył", że pod nim nie mogą przejeżdżać ciężarówki. To jest
tak jakby ktoś w programie zapomniał czegoś ważnego i potem poprawka kończy
się przepisaniem kodu w większości od zera. Ile jest takich błędów w
informatyce a ile w budownictwie? A wszystko z powodu pośpiechu.

2. Częstotliwość i rozmiar wprowadzanych zmian do specyfikacji. Znajomi
architekci czasami muszą coś zmienić w projekcie, bo klient coś zażądał
innego, ale nie widziałem, aby to było tak częste jak w informatyce.

3. Cena przebudowy systemu, która odstrasza klienta od wydziwiania po
zamknięciu projektu. 
Czyli projekt budynku jest zamknięty i że się tak wyrażę "Chłopaki wylały
dekę.". Klient, który powie, że on chce dodatkową windę, 2 pokoje i
oranżerię za zmianę zapłaci masę kasy -- więc generalnie po zaczęciu budowy
nic się nie zmienia. 
W programowaniu tak nie jest, często pojawiają się nowe żądania już po tym
jak ruszyła maszyna kodowania. Menedżerom wydaje się, że jak klient żąda
dodatkowego ficzeru, to przecież trzeba mu to dać, to to czasem powoduje
zmianę w projekcie na tyle dużą, że trzeba go robić w dużej mierze od zera
a tego już manago nie mają ochoty słuchać, tylko każą łatać kod na siłę.
Takie łatanie projektu architektonicznego nie ma szans nigdzie przejść, bo
balkonów się nie doszywa niciami szewskimi, tylko potrzeba wszystko tak
przeprojektować aby balkon można było dodać.

4. Marketingowe zamydlanie oczu, że w informatyce to wszystko staje się
takie łatwe jak tylko stosuję się "technologię XYZ". Tego nie ma w
budownictwie. A na to często nadziewają się menedżerowie.

5. Ostatnia sprawa częstotliwość (szybkość) zmian narzędziowych w
informatyce vs. w budownictwie. Do tego należy dodać że tak jak w
informatyce jest wiele języków każdy ma inne podejście i w większości
przypadków można dany problem rozwiązać na bardzo wiele sposobów począwszy
od doboru języka poprzez modułów/bibliotek/frameworków itd. Kombinacji dróg
prowadzących do celu jest bardzo dużo. W budownictwie fizyka dość szybko
redukuje liczbę ścieżek sukcesu. 

6. Wiek dziedziny jako dziedziny naukowej: informatyka -- śmiech na sali,
budownictwo -- szacowna persona. Tak więc nie ma się co dziwić, że w
budownictwie jest bardziej wszystko ustabilizowane. 

Ale już na granicy budownictwa i informatyki, czyli np. w automatyce
budynków pojawiają się kłopoty typowe dla informatyki.

No i przykłady budownictwa z RPL mogą dobrze wskazywać, że budowę też można
spartaczyć.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

DarekM <darekm@emadar.com> writes:

>>> Pytanie było o proces tworzenia a nie używania. A nawet jeżeli to
>>> należy porównywać używanie z zamieszkiwaniem. Też wiele analogii
>>> można znaleźć.
>> OIDP dziedziną nauki traktującą o systemach w sposób niezależny
>> natury i przeznaczenia tych systemów jest teoria systemów.  Czyli
>> zarówno systemy miejskie, jak i systemy komputerowe można
>> rozpatrywać w kategoriach teorii systemów, a w konstrukcji oraz
>> konserwacji tych systemów stosować zdobycze inżynierii systemów.
>
> No i ...
> Tak, istnieje taka nauka. Tylko co z tego wynika dla pytacza. Same
> osiągnięcia są dosyć dyskusyjne. Przyjmując jednak że są całkowicie
> prawdziwe to pewnie są tak użyteczne jak prawo Ohma przy
> konstruowaniu telewizora a prawa Newtona do budowy dźwigu. Po drugie
> przypuszczam że większościowym beneficjentem byłaby sama teoria
> systemów a nie rozwiązanie problemu, tzn. na podstawie
> przeprowadzonych działań można by coś nieco wnieść do teorii,
> w drugą stronę transfer wiedzy jakoś wydaje mi się mało
> prawdopodobny. Może jedynie terminologia była by pomocna, o ile
> pytacz nie dysponuje własną systematyką.

Jest jeszcze teoria analogii.  ZTCW to teoria analogii zajmuje się
m.in. możliwościami symulowania jednych zjawisk przy pomocy innych,
posiadających właściwości na określonym poziomie abstrakcji
analogiczne.

-- 
http://www.piotr.dembiński.prv.pl

Tworzenie oprogramowania jest jak budowa katedry ..... budujesz, budujesz, 
budujesz,. ..... modlisz sie ;-)

M 

Tak sobie dłubię i szukam i coś takiego mi wyskoczyło (bardzo ogólnikowe, 
ale jakby w temacie):

http://www.cxo.pl/artykuly/33442.html

"...Inne założenia leżą u podstaw Architektury Zachmana, nazywanej tak od 
nazwiska twórcy. John Zachman uważał, że w procesie tworzenia 
skomplikowanych produktów, do których z pewnością należą systemy 
informatyczne, potrzebne są różnego rodzaju opisy i modele. Są one 
przeznaczone dla różnych uczestników tego procesu, z których każdy 
interesuje się czymś innym. Równocześnie każdy produkt opisać można z 
różnych punktów widzenia i dla różnych celów, co dodatkowo uzasadnia 
potrzebę różnorodnych opisów. (...) Zachman posługiwał się metaforami z 
sektora budowlanego, dlatego nazwy ról osób uczestniczących w procesie 
tworzenia systemu brzmią dość dziwnie w kontekście informatycznym..."

"...Tworzenie architektury danych i systemów, względnie też architektury 
informacyjnej, porównywane jest z projektowaniem nowego budynku. Tworzenie 
architektury technologicznej porównywane jest natomiast z zestawianiem listy 
materiałów i narzędzi. Architektura technologiczna, zwana także często 
architekturą IT, określa niezbędną infrastrukturę dla danych i systemów 
użytkowych: platformy i sieci komputerowe potrzebne do przetwarzania danych 
i wspomagania realizowanych w firmie zadań. Pojęcie platformy jest w tym 
przypadku obszerne i obejmuje zarówno oprogramowanie techniczne stanowiące 
środowisko danych i systemów, jak i sprzęt komputerowy i inne urządzenia. Na 
poziomie projektowym architekturę technologiczną stanowią opisy lokalizacji 
systemów komputerowych firmy i ich połączeń. Na poziomie wykonawczym 
architekturę technologiczną stanowią opisy systemów komputerowych i sieci 
komunikacyjnych..." 

On Mon, 17 Sep 2007 10:50:51 +0200, "Filip Sielimowicz"
<sielim@wp.pl> wrote:

>Tak sobie dłubię i szukam i coś takiego mi wyskoczyło (bardzo ogólnikowe, 
>ale jakby w temacie):
>
>http://www.cxo.pl/artykuly/33442.html
>
>"...Inne założenia leżą u podstaw Architektury Zachmana, nazywanej tak od 
>nazwiska twórcy. John Zachman uważał, że w procesie tworzenia 
>skomplikowanych produktów, do których z pewnością należą systemy 
>informatyczne, potrzebne są różnego rodzaju opisy i modele. Są one 
>przeznaczone dla różnych uczestników tego procesu, z których każdy 
>interesuje się czymś innym.

RE-WE-LA-CJA!!  Absolutna rewelacja! Proponuje wswadzic do FAQ aby
nikomu nie umknelo!

A.L.

"Filip Sielimowicz" <sielim@wp.pl> writes:

[...]

> Zachman posługiwał się metaforami z sektora budowlanego

Pozostaje tylko czekać, aż specjaliści innych branż zaczną się
posługiwać metaforami z sektora IT.