Temat: Analityk IT vs Projektant IT

Nie pamiętam (szczerze), ale czy teorie Popera nie zostały całkowicie odrzucone przez filozofię? Jego definicja nauki, teorii, potwierdzenia itd. chyba nie działała.

niestety Popper ma się dobrze, na jego tezach opiera się ogólna teoria systemów i oparta na niej tak zwana "metoda naukowa" bazująca na budowaniu modeli i ich falsyfikacji jako dowodzeniu słuszności.

W mojej działce musimy jednocześnie być programistami oraz naukowcami. Przechodzimy przez cały proces, od badań poprzez projektowania, na implementacji skończywszy. Często zadaję sobie pytanie, czy to efektywne? I ... nie wiem. Na pewno działa sprzężenie zwrotne. Dzięki temu, że implementuje moje pomysły moimi palcami muszę sobie wszytko dobrze "zadizajnować". W końcu "dizjnuję" dla siebie.

problem w tym, że podstawą prawdziwej nauki jest powtarzalność... tak więc projekt (hipoteza, modele) jest tym lepszy im mniejszy rozrzut efektów notujemy, innymi słowy jeżeli np. na bazie jednej specyfikacji wymagań powstają skrajnie różne produkty i ich wyceny, np. OPZty, konkurencyjne oferty itp., tym bardziej ta specyfikacja wymagań jest do d.....py.

Niestety nauka nie zna pojęcia "zwinnych metod" .... przed zbudowaniem trzeba projektować (tak jak mosty czy wieżowce)

w nauce nadal ścierają się dwie "wersje" dowodzenia praw: indukcyjna (wnioskowanie logiczne) i dedukcyjna (oparta na falsyfikacji Poppera) Wadą tej pierwszej jest to, że wywodzi wszystko z historii i rzeczy znanych, tak więc nie da się wymyślić np. koła metodami indukcyjnymi..... bo ono nie istniało przed jego wymyśleniem.

http://pl.wikipedia.org/wiki/Rozumowanie_indukcyjne

jak na razie metoda dedukcyjna (w tym popperyzm) wygląda na skuteczniejszą, nie mającą poważnej wady indukcjonizmu: ten to tylko ocena prawdopodobieństwa powtórzenia się tego co wynika z historii i zaobserwowanych zjawisk, popperyzm ma wielu wrogów bo łatwo "obnaża" wszelkie pseudo nauki i pseudo twierdzenia. Hipoteza Popperowska pozwala przewidywać zachowania opisanego teorią zjawiska nawet gdy dane "rzeczy" sie jeszcze nie wydarzyły, narzędziem jest "model zjawiska", indukcja co najwyżej poda mało wiarygodne prawdopodobieństwo powtórzenia się czegoś co już poznano (empiria).

klasycznym przykładem niemocy indukcji a siły falsyfikacji jest słynne i uznawane w nauce mimo braku dowody na poprawność (popperyzm: dowodem słuszności tezy jest brak jej obalenia), Twierdzenie Fermata: uznawane jest za prawdziwe bo nikt go do tej poty nie obalił (nie znany jest przykład liczb obalających to twierdzenie)....

Temat: Analityk IT vs Projektant IT

Ja osobiście ze statystyką i średnimi bym uważał. Ludzie bardzo często przeceniają rolę średniej i dopasowania wyników do modelu. Bardzo często rozrzut (nie mówiąc już o estymacji błędów pomiarowych) jest taki, że można do wykresu dopasować wszystko, np. Pamelę Anderson. Swoją drogą, chętnie zobaczyłbym oryginalną pracę na temat RUP (chyba, że mi coś umknęło i była tu już cytowana).

co do zasady te wykresy RUP'owe to nie model a statystyka czyli materiał do oceny ryzyka...

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:

Ja osobiście ze statystyką i średnimi bym uważał. Ludzie bardzo często przeceniają rolę średniej i dopasowania wyników do modelu. Bardzo często rozrzut (nie mówiąc już o estymacji błędów pomiarowych) jest taki, że można do wykresu dopasować wszystko, np. Pamelę Anderson. Swoją drogą, chętnie zobaczyłbym oryginalną pracę na temat RUP (chyba, że mi coś umknęło i była tu już cytowana).

co do zasady te wykresy RUP'owe to nie model a statystyka czyli materiał do oceny ryzyka...

Rozumiem.

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:

Nie pamiętam (szczerze), ale czy teorie Popera nie zostały całkowicie odrzucone przez filozofię? Jego definicja nauki, teorii, potwierdzenia itd. chyba nie działała.

niestety Popper ma się dobrze, na jego tezach opiera się ogólna teoria systemów i oparta na niej tak zwana "metoda naukowa" bazująca na budowaniu modeli i ich falsyfikacji jako dowodzeniu słuszności.

Jednak obecnie falsyfikowalność jedynie jest jednym z kryteriów oceny. Zdaje się, że jest cały czas "istotna", ale już nie jedyna.

W mojej działce musimy jednocześnie być programistami oraz naukowcami. Przechodzimy przez cały proces, od badań poprzez projektowania, na implementacji skończywszy. Często zadaję sobie pytanie, czy to efektywne? I ... nie wiem. Na pewno działa sprzężenie zwrotne. Dzięki temu, że implementuje moje pomysły moimi palcami muszę sobie wszytko dobrze "zadizajnować". W końcu "dizjnuję" dla siebie.

problem w tym, że podstawą prawdziwej nauki jest powtarzalność... tak więc projekt (hipoteza, modele) jest tym lepszy im mniejszy rozrzut efektów notujemy, innymi słowy jeżeli np. na bazie jednej specyfikacji wymagań powstają skrajnie różne produkty i ich wyceny, np. OPZty, konkurencyjne oferty itp., tym bardziej ta specyfikacja wymagań jest do d.....py.

Niestety nauka nie zna pojęcia "zwinnych metod" .... przed zbudowaniem trzeba projektować (tak jak mosty czy wieżowce)

w nauce nadal ścierają się dwie "wersje" dowodzenia praw: indukcyjna (wnioskowanie logiczne) i dedukcyjna (oparta na falsyfikacji Poppera) Wadą tej pierwszej jest to, że wywodzi wszystko z historii i rzeczy znanych, tak więc nie da się wymyślić np. koła metodami indukcyjnymi..... bo ono nie istniało przed jego wymyśleniem.

http://pl.wikipedia.org/wiki/Rozumowanie_indukcyjne

jak na razie metoda dedukcyjna (w tym popperyzm) wygląda na skuteczniejszą, nie mającą poważnej wady indukcjonizmu: ten to tylko ocena prawdopodobieństwa powtórzenia się tego co wynika z historii i zaobserwowanych zjawisk, popperyzm ma wielu wrogów bo łatwo "obnaża" wszelkie pseudo nauki i pseudo twierdzenia. Hipoteza Popperowska pozwala przewidywać zachowania opisanego teorią zjawiska nawet gdy dane "rzeczy" sie jeszcze nie wydarzyły, narzędziem jest "model zjawiska", indukcja co najwyżej poda mało wiarygodne prawdopodobieństwo powtórzenia się czegoś co już poznano (empiria).

klasycznym przykładem niemocy indukcji a siły falsyfikacji jest słynne i uznawane w nauce mimo braku dowody na poprawność (popperyzm: dowodem słuszności tezy jest brak jej obalenia), Twierdzenie Fermata: uznawane jest za prawdziwe bo nikt go do tej poty nie obalił (nie znany jest przykład liczb obalających to twierdzenie)....

Fakt. Panie Jarku, oto moje rozumowanie (nie wiem na ile prawdziwe). Analiza i projektowanie IT to trochę sztuka. Taka "nauka" z pogranicza socjologii-psychologii-ekonomii-zarządzania itd. W związku z tym nie jest "twardą nauką", jak w przypadku (mojej ulubionej) fizyki, czy matematyki. Teoria popperyzm nadaje się idealnie do nauk ścisłych i zawodzi w przypadku nauk humanistycznych. Czy może też zawieść w przypadku IT?

Temat: Analityk IT vs Projektant IT

Sławomir Orłowski:
...
Ja osobiście ze statystyką i średnimi bym uważał. Ludzie bardzo często przeceniają rolę średniej i dopasowania wyników do modelu. Bardzo często rozrzut (nie mówiąc już o estymacji błędów pomiarowych) jest taki, że można do wykresu dopasować wszystko, np. Pamelę Anderson. Swoją drogą, chętnie zobaczyłbym oryginalną pracę na temat RUP (chyba, że mi coś umknęło i była tu już cytowana).

To jak to jest? Metody stochastyczne w fizyce się sprawdzają, ale w statystyczne badanie w informatyce już nie? To, że 75% projektów kończy się fiaskiem jest naciągane? Nikt przecież nie dopasowywał wyników projektów do zakładanej krzywej. Masowo zbadano przyczyny które się przyczyniły do fiaska. Co więcej RUP przez około 20 lat działa i to skutecznie.

Czy taki przegląda po dekadach wraz bibliografią jednego z autorów badania będzie kompletnym i wyczerpującym źródłem? http://sunset.usc.edu/events/2006/CSSE_Convocation/pub...

Można też sięgnąć do źródła źródła: boehm@cse.usc.edu i napisać do Barry'ego Boehmy z prośbą o podanie jego źródła, aha i dodać kilka uwag na temat ułomności statystyki :)

Temat: Analityk IT vs Projektant IT

Jednak obecnie falsyfikowalność jedynie jest jednym z kryteriów oceny. Zdaje się, że jest cały czas "istotna", ale już nie jedyna.

a jakie inne poza jeszcze powtarzalnością?

Fakt. Panie Jarku, oto moje rozumowanie (nie wiem na ile prawdziwe). Analiza i projektowanie IT to trochę sztuka. Taka "nauka" z pogranicza socjologii-psychologii-ekonomii-zarządzania itd. W związku z tym nie jest "twardą nauką", jak w przypadku (mojej ulubionej) fizyki, czy matematyki. Teoria popperyzm nadaje się idealnie do nauk ścisłych i zawodzi w przypadku nauk humanistycznych. Czy może też zawieść w przypadku IT?

nauka jest sztuką i Popper to tylko podkreśla :), w nauce "Poppera" nie ważne jest skąd się wzięła idea (mogła być nawet efektem narkotycznej wizji jak twierdzą niektórzy) ważne czy jest słuszna.

IT to modelowanie - w końcu program to nic innego jak jakiś model :), w IT to głownie psychologia komunikacji i teoria poznania jako "narzędzia" pomagające "zrozumieć usera" :)

Temat: Analityk IT vs Projektant IT

a ja myślałem, że umiejętność uzasadnienia tego co się pisze, albo przynajmniej wskazanie miejsca gdzie takie wyjaśnienie można znaleźć świadczy o tym, że dyskusja jest produktywna; tzn jest o czymś co "działa".

owszem, ale jeżeli uzasadnianie polega wyłącznie na podawaniu źródeł, cytowaniu bibliografii, to jest to tylko uzasadnianie cudzego zdania a nie swojego,

Źródła to właśnie uzasadnienie (albo jego brak; w każdym razie - coś konkretnego).

każdy kto dużo czyta i pracuje raczej tylko odpowiada na pytania, bardzo rzadko ma sens prośba o bibliografię po każdym usłyszanym zdaniu

To mamy zgodność ;)

Dobrze wiem, że to nie mam sensu ponieważ (w przypadku RUP) rzeczy o które proszę po prostu nie istnieją. No ale mówmy dalej o "savoir vivre"; przecież niegrzecznie się "zachowuję".... proszę o koleją lekcję grzeczności. tzn informacje o tym, o co należy pytać a o co nie należy.

po drugie są ludzie, którzy nie tylko "cytują cudze" ale także "mówią od siebie", zresztą to drugie sobie bardziej cenię... własne zdanie a cudze zdanie to różnica... dodam, że pytając kogoś o coś raczej oczekuje jego opinii bo cudze sam znajduję...

To nie jest o RUP

co prawda wikipedia ale Poppera znam i to co tu widzę w zawiera jest OK :)

to w sumie dość zabawne bo swego czasu, chciałem zaznaczyć "nie falsyfikowalność" RUP'A.
Dla przykładu (podesłanego przez Adriana) - analiza biznesowa (jak i wszystko inne) zaczyna się na początku a kończy na końcu projektu - genialne. Z resztą - właściwie wszystko w RUP 'zaczyna się na początku a kończy na końcu' (no może poza wykresami bo te są różne).. no i kto tę "mądrość" podważy ?

programista, który tworzy oprogramowanie na bazie szczegółowego opisu to właśnie craftsmanship czyli dobre rzemiosło, zresztą nie raz czytam, że tak właśnie powinno być z programistami, i chyba jest w tym wiele racji.

czym jest ten "szczegółowy opis"(baza) ? nie proszę o źródła tylko o zdanie własne.

bo jeżeli jakiekolwiek grono ludzi ze sobą rozmawia to albo uznaje wzajemnie swoje wypowiedzi albo nie bierze udziału w dyskusji.

Tak, ale tylko w towarzystwie wzajemnej adoracji :)

to jak nazwiesz konferencje i seminaria?

Nie wiem jak konferencje, ale "moje" seminaria były w sumie przeciwieństwem (na szczęście) wzajemnej adoracji.

Ja zakładam, że każdy szczerze wypowiada swoje opinie, wierzy w to co pisze.

Ale rozmowa nie jest o opiniach ale o faktach. Opinie każdy ma jakąś, a fakty ...

ale "fakt" to także to co widziałem wczoraj na ulicy, opowiadając o tym prezentuję fakty czy opinie?

Hm... zależy ;)
Są ludzie dla których opinia to fakt; żeby było gorzej - takich ludzi jest za dużo.

Tak więc osobiście stoję za tym, by uznawać, że analityk i projektant to samo,

"O to to..."
O tym pisałem na początku - różnica ogranicza się do nazwy.

Temat: Analityk IT vs Projektant IT

Ja osobiście ze statystyką i średnimi bym uważał.

E tam... ja np. w połowie jestem kobietą a w 1/4 chińczykiem...
I jakby tak uśrednić rów mariański i mount everest to w sumie wyjdzie... wielkopolska.Jakub Wojt edytował(a) ten post dnia 27.06.12 o godzinie 23:01

Temat: Analityk IT vs Projektant IT

Źródła to właśnie uzasadnienie (albo jego brak; w każdym razie - coś konkretnego).

a ja zawsze zastanawiam się na jakie źródła powoływał się np. wynalazca koła.... bo co z tego, że koło pokazał skoro nie potrafił go "uzasadnić"?

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:

Źródła to właśnie uzasadnienie (albo jego brak; w każdym razie - coś konkretnego).

a ja zawsze zastanawiam się na jakie źródła powoływał się np. wynalazca koła.... bo co z tego, że koło pokazał skoro nie potrafił go "uzasadnić"?

On akurat nie musiał bo to, co robił "działało".
A te procesy "wytwarzania oprogramowania" to oj .... każdy kto chce z nich skorzystać musi je osobie dopasować; po swojemu oczywiście.

Każdy robi po swojemu; ale oczywiście zawsze można nazwać to rup / agile etc ... bo przecież to to tylko szablony metodyk. :\Jakub Wojt edytował(a) ten post dnia 27.06.12 o godzinie 23:09

Temat: Analityk IT vs Projektant IT

a ja zawsze zastanawiam się na jakie źródła powoływał się np. wynalazca koła.... bo co z tego, że koło pokazał skoro nie potrafił go "uzasadnić"?

On akurat nie musiał bo co robił "działało".

Każdy robi po swojemu; ale oczywiście zawsze można nazwać to rup / agile etc ... bo przecież to to tylko szablony metodyk. :\

nie zapominaj, że nawet z roweru można się zwalić na pysk...

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...
to w sumie dość zabawne bo swego czasu, chciałem zaznaczyć "nie falsyfikowalność" RUP'A.
Dla przykładu (podesłanego przez Adriana) - analiza biznesowa (jak i wszystko inne) zaczyna się na początku a kończy na końcu projektu - genialne. Z resztą - właściwie wszystko w RUP 'zaczyna się na początku a kończy na końcu' (no może poza wykresami bo te są różne).. no i kto tę "mądrość" podważy ?

Rozumiem, że chodzi o mój wykres? :) Każdy wykres trzeba umieć czytać.

Są 2 rzeczy:
1. Krzywa, która znajduje się na wykresie ma charakter ciągły. Umiejscowiona jest jednak w przestrzeni dyskretnej. Co za tym idzie? biorąc mały projekt o robiąc z niej małe schodki krzywa aktywności zaniknie dosyć szybko ostatnim schodkiem przyłożenia palca do klawiatury analityka biznesowego.
2. W dużym i długim projekcie odpowiednie artefakty z reguły mają również sekcję powysłów na rozwój oraz uwag w trakcie projektu. Nie zmieniamy plany cyklu ale zbieramy wymagania i uwagi na następny cykl.

Trochę ma dosyć tych dywagacji: RUP ma, RUP nie ma. Ma wszystko: zestaw szablonów dokumentów też. Szablon w RUP służy do przejścia właściwego dla danej aktywności projektowej procesu myślowego. Będzie długi post, ale niech będzie. Oto spis treści jednego z artefaktów RUPowych --- dokumentu wizji biznesowej:

Business Vision

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview

2. Positioning
2.1 Business Opportunity
2.2 Problem Statement
2.3 Business Position Statement

3. Stakeholder and Customer Descriptions
3.1 Market Demographics
3.2 Stakeholder Profiles
3.2.1 Stakeholder Name
3.3 Customer Profiles
3.3.1 Customer Name
3.4 Customer Environment
3.5 Key Stakeholder or Customer Need
3.6 Alternatives and Competition
4. Business Modeling Objectives

5. Precedence and Priority

6. Other Requirements
6.1 Constraints
6.2 Applicable Standards
6.3 Quantifiers
6.4 Infrastructure Requirements
6.5 Environmental Requirements

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:

a ja zawsze zastanawiam się na jakie źródła powoływał się np. wynalazca koła.... bo co z tego, że koło pokazał skoro nie potrafił go "uzasadnić"?

On akurat nie musiał bo co robił "działało".
Każdy robi po swojemu; ale oczywiście zawsze można nazwać to rup / agile etc ... bo przecież to to tylko szablony metodyk. :\

nie zapominaj, że nawet z roweru można się zwalić na pysk...

Nie raz i nie dwa. I właśnie dlatego nie wierzę w "mowę kwiecistą" tych speców od "realizacji projektów dowolnych w dowolny sposób".

Z drugiej strony nie przejmował bym się tym tak bardzo - żaden potencjalny klient tej rozmowy nie przeczyta.

Temat: Analityk IT vs Projektant IT

Z drugiej strony nie przejmował bym się tym tak bardzo - żaden potencjalny klient tej rozmowy nie przeczyta.

nigdy nie mów nigdy.... ;)

Temat: Analityk IT vs Projektant IT

Rozumiem, że chodzi o mój wykres? :) Każdy wykres trzeba umieć czytać.

e.e.
Każdy wykres trzeba umieć zrobić tak, żeby został zrozumiany. A przynajmniej - żeby odbiorca miał wrażenie, że coś zrozumiał.

I to nie był Twój wykres :)

Temat: Analityk IT vs Projektant IT

Z drugiej strony nie przejmował bym się tym tak bardzo - żaden potencjalny klient tej rozmowy nie przeczyta.

nigdy nie mów nigdy.... ;)

No dobrze, nigdy nie powiem nigdy ;)

Temat: Analityk IT vs Projektant IT

Jakub Wojt:

Rozumiem, że chodzi o mój wykres? :) Każdy wykres trzeba umieć czytać.

e.e.
Każdy wykres trzeba umieć zrobić tak, żeby został zrozumiany. A przynajmniej - żeby odbiorca miał wrażenie, że coś zrozumiał.

I to nie był Twój wykres :)

Ja się wypisuję z tej dyskusji. Nie mam czasu przeglądać czy był jakiś Adrian, czy był jakiś jeszcze wykres itp. W tym poście było 2 wykresy i nie było żadnego Adriana.

Temat: Analityk IT vs Projektant IT

Aleksander Olszewski:

Sławomir Orłowski:
...
Ja osobiście ze statystyką i średnimi bym uważał. Ludzie bardzo często przeceniają rolę średniej i dopasowania wyników do modelu. Bardzo często rozrzut (nie mówiąc już o estymacji błędów pomiarowych) jest taki, że można do wykresu dopasować wszystko, np. Pamelę Anderson. Swoją drogą, chętnie zobaczyłbym oryginalną pracę na temat RUP (chyba, że mi coś umknęło i była tu już cytowana).

To jak to jest? Metody stochastyczne w fizyce się sprawdzają, ale w statystyczne badanie w informatyce już nie? To, że 75% projektów kończy się fiaskiem jest naciągane? Nikt przecież nie dopasowywał wyników projektów do zakładanej krzywej. Masowo zbadano przyczyny które się przyczyniły do fiaska. Co więcej RUP przez około 20 lat działa i to skutecznie.

Powiem dosadnie. Za dużo miałem do czynienia z pseudo-naukowcami, którzy ze średniej wróżyli, iż Polska pokona Czechów. A nie pokonała. Wiem, bo byłem na meczu. I co oznacza, że w 96,78% elektron będzie się znajdował na pozycji (x,y,z)? Nic, bo w doświadczeniu, które Pan przeprowadzi akurat się tam nie znajdzie.
W fizyce sprawa jest prosta (w miarę). Analizujemy układy, które poddają się opisowi za pomocą modeli. W dziedzinach gdzie wchodzi tzw. "czynnik ludzki", tak łatwo nie jest. Mam za dużo zmiennych i stopni swobody. To, że 75% projektów IT kończy się nie powodzeniem, to się okaże, że dlatego, że zaczynały się w poniedziałek. Więc ktoś stwierdzi, ze trzeba je zaczynać we wtorek.

Czy taki przegląda po dekadach wraz bibliografią jednego z autorów badania będzie kompletnym i wyczerpującym źródłem? http://sunset.usc.edu/events/2006/CSSE_Convocation/pub...

Przeczytam i odpowiem.

Można też sięgnąć do źródła źródła: boehm@cse.usc.edu i napisać do Barry'ego Boehmy z prośbą o podanie jego źródła, aha i dodać kilka uwag na temat ułomności statystyki :)

Widzę, że kolega średnio znosi głosy sprzeciwu, lub nawet nie, głosy, które lubią się zastanawiać. Nawet nad podstawami. W końcu to należy do nauki, czyż nie? Ja lubię zadawać pytania: dlaczego?
Podsumowując, wie Pan, że 75% projektów się kończy fiaskiem i wie Pan jak temu zapobiec? Jest Pan milionerem! Co ja mówię: miliarderem!

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:

Jednak obecnie falsyfikowalność jedynie jest jednym z kryteriów oceny. Zdaje się, że jest cały czas "istotna", ale już nie jedyna.

a jakie inne poza jeszcze powtarzalnością?

Ech, no i muszę poszperać. Jakiś czas temu musiałem się przygotować z teorii poznania, Poppera itd do pewnego egzaminu.

Fakt. Panie Jarku, oto moje rozumowanie (nie wiem na ile prawdziwe). Analiza i projektowanie IT to trochę sztuka. Taka "nauka" z pogranicza socjologii-psychologii-ekonomii-zarządzania itd. W związku z tym nie jest "twardą nauką", jak w przypadku (mojej ulubionej) fizyki, czy matematyki. Teoria popperyzm nadaje się idealnie do nauk ścisłych i zawodzi w przypadku nauk humanistycznych. Czy może też zawieść w przypadku IT?

nauka jest sztuką i Popper to tylko podkreśla :), w nauce "Poppera" nie ważne jest skąd się wzięła idea (mogła być nawet efektem narkotycznej wizji jak twierdzą niektórzy) ważne czy jest słuszna.

Pozwolę sobie się nie zgodzić. Po ortodoksyjnej szkole fizyki śmiem twierdzić, że nauka nie jest sztuką. Fizyka nie jest. Matematyka nie jest. Tak jak, zdaje się, wielu krytyków Poppera uważam, że będziemy mogli opisać świat fizyką i matematyką. Do tej pory działa.

IT to modelowanie - w końcu program to nic innego jak jakiś model :), w IT to głownie psychologia komunikacji i teoria poznania jako "narzędzia" pomagające "zrozumieć usera" :)

To prawda. I w przypadku wytwarzanych modeli oprogramowania nie mam zastrzeżeń, co do teorii filozoficznych przytoczonych powyżej. Jednak grupy programistyczne, użytkownicy, szefowie projektów, czyli "narzędzia" tworzące te modele nie poddają się tak łatwo opisowi. Przynajmniej w moim rozumieniu sprawy. Nie są np. operatorami momentu pędu, które to operatory wiem jak działają na funkcję falową. Może to mój strach przed nieznanym, lub niewiedza, ale jak tu opisać Staszka, który nie lubi Krzysia. No i im źle idzie projekt. A potem wyjdzie w szumie danych, że 75% się nie udaje. A że Staszek nie lubił Krzyśka to już nie wyjdzie.

Temat: Analityk IT vs Projektant IT

nauka jest sztuką i Popper to tylko podkreśla :), w nauce "Poppera" nie ważne jest skąd się wzięła idea (mogła być nawet efektem narkotycznej wizji jak twierdzą niektórzy) ważne czy jest słuszna.

Pozwolę sobie się nie zgodzić. Po ortodoksyjnej szkole fizyki śmiem twierdzić, że nauka nie jest sztuką. Fizyka nie jest. Matematyka nie jest. Tak jak, zdaje się, wielu krytyków Poppera uważam, że będziemy mogli opisać świat fizyką i matematyką. Do tej pory działa.

Tu przyznaję, że popełniłem pewne uproszczenie i uogólnienie zarazem. Faktem jest, że prawa przyrody, jako takie, nawet nie podlegają ochronie prawem autorskim gdyż nikt ich nie "tworzy" a co najwyżej odkrywa. Drobny niuans: sztuką jest opracowanie modelu zjawiska (model to uproszczenie) a nie opisu samego zjawiska (bo ono jest, nie wynajdujemy go). Popper i falsyfikacja dotyczy nie tyle przyrody jako takiej co teorii (modeli) je opisujących, np. nikt nie rości sobie pretensji do powietrza, chmur itp.. ale model służący do prognoz pogody jest już "pomysłem"...

IT to modelowanie - w końcu program to nic innego jak jakiś model :), w IT to głownie psychologia komunikacji i teoria poznania jako "narzędzia" pomagające "zrozumieć usera" :)

To prawda. I w przypadku wytwarzanych modeli oprogramowania nie mam zastrzeżeń, co do teorii filozoficznych przytoczonych powyżej. Jednak grupy programistyczne, użytkownicy, szefowie projektów, czyli "narzędzia" tworzące te modele nie poddają się tak łatwo opisowi.

Dlatego to fajne i odkrywcze zajęcie :)