konto usunięte

Temat: Analityk IT vs Projektant IT

a tu:

Obrazek


widać, że problem brzmi we wskazaniu kluczowej kompetencje a nie jedynej bo się one nakładają... Projektant przejmuje po Analityku Biznesowym, odpowiada za "drugie pół specyfikowania i pierwsze pół wytwarzania".... wg. powyższego.

Na podstawie czego powstały te wykresy ?
Jak rozumiem z czegoś wynikają, bo przecież nikt poważny nie nabazgrał by sobie (bez skali) kilku kresek na papierze twierdząc, że "tak powinno być".

PS: nic nie zaczyna się od zera (?) i nigdy się na nim nie kończy :) Agile ... cuda się dzieją.Jakub Wojt edytował(a) ten post dnia 22.06.12 o godzinie 21:28

konto usunięte

Temat: Analityk IT vs Projektant IT

To proszę o źródło :)
nie uwierzę dopóki nie zobaczę

np. Rational Unified Process Version 2003.06.00.65 ;-)

-- EDITED:
Wersję 2003.* mam na laptopie, w sieci możesz znaleźć w różnych miejscach, np. nieco starsze wydanie :)
http://www-natali.deis.unibo.it/Material/RationalUnifi...


No dobrze; bardzo fajny diagram ale tak na poważnie - "Define the Bussines Architecture" to bardzo ładne, nośne hasło; z marketingu - piątka.

Ale co to tak naprawdę znaczy?
Nie wiadomo, prawda ? :)

Jeśli wiadomo - proszę o wskazanie akapitu / rozdziału ze źródła albo dyplomatyczne zignorowanie tematu :) Nie chcę nikomu, jak to kiedyś ktoś określił, burzyć strefy komfortu :)

PS: Od razu zaznaczam - coś w rodzaju "Bussines Architecture is an agile model of an enterprise organisation structure" to taki sam bełkot.Jakub Wojt edytował(a) ten post dnia 22.06.12 o godzinie 21:14
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Analityk IT vs Projektant IT


Obrazek
Na podstawie czego powstały te wykresy ?

na bazie uśrednionej zajętości czasu nad zagadnieniem (dziedziną) w jednostce czasu, czyli np. analiza biznesowa kończy się w pierwszej części.Jarek Żeliński edytował(a) ten post dnia 22.06.12 o godzinie 21:40

konto usunięte

Temat: Analityk IT vs Projektant IT


Obrazek
Na podstawie czego powstały te wykresy ?

na bazie uśrednionej zajętości czasu nad zagadnieniem (dziedziną) w jednostce czasu, czyli np. analiza biznesowa kończy się w pierwszej części.

Proszę o źródła.

PS:
W drugiej - w specyfikacji.
I nie tyle analiza co "modelowanie biznesowe" bo analiza wymagań kończy się w "wytwarzaniu" a i samo modelowanie biznesowe - po prostu "pojawia się" czyli zaczyna się "poza wykresem"... ale może coś źle "odczytuję".
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Analityk IT vs Projektant IT

Proszę o źródła.

brak zaufania nie tłumaczy chciejstwa ;),

teraz uwaga: podobno 2+2=4 prawie zawsze, poproszę źródła
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
To proszę o źródło :)
nie uwierzę dopóki nie zobaczę

np. Rational Unified Process Version 2003.06.00.65 ;-)

-- EDITED:
Wersję 2003.* mam na laptopie, w sieci możesz znaleźć w różnych miejscach, np. nieco starsze wydanie :)
http://www-natali.deis.unibo.it/Material/RationalUnifi...


No dobrze; bardzo fajny diagram ale tak na poważnie - "Define the Bussines Architecture" to bardzo ładne, nośne hasło; z marketingu - piątka.

Ale co to tak naprawdę znaczy?
Nie wiadomo, prawda ? :)

W kontekście RUP masz podane wyjaśnienie. Wystarczy kliknąć w odnośniki na diagramie i można uzyskać szczegóły dotyczące opisu:
- aktywności (definiowanie architektury biznesowej)
- artefaktu ( dokument opisujący architekturę biznesową) będącego efektem aktywności "definiowanie architektury biznesowej"

"The Business Architecture Document provides a comprehensive overview of the business, using a number of different architectural views to depict different aspects of the business."

Proponuję wykonać eksperyment myślowy i zamienić w powyższym "business" na "software" i zastosować stwierdzenie o marketingu ;-)

konto usunięte

Temat: Analityk IT vs Projektant IT

Proszę o źródła.

brak zaufania nie tłumaczy chciejstwa ;),

teraz uwaga: podobno 2+2=4 prawie zawsze, poproszę źródła

Łatwe ;)
http://en.wikipedia.org/wiki/Natural_number#Constructi...

Wciąż proszę o źródła. :)

konto usunięte

Temat: Analityk IT vs Projektant IT

W kontekście RUP masz podane wyjaśnienie. Wystarczy kliknąć w odnośniki na diagramie i można uzyskać szczegóły dotyczące opisu:
- aktywności (definiowanie architektury biznesowej)
- artefaktu ( dokument opisujący architekturę biznesową) będącego efektem aktywności "definiowanie architektury biznesowej"

"The Business Architecture Document provides a comprehensive overview of the business, using a number of different architectural views to depict different aspects of the business."
Proponuję wykonać eksperyment myślowy i zamienić w powyższym "business" na "software"

A ja proponuję "whateva". Wow, wciąż dobrze "brzmi".
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Analityk IT vs Projektant IT

teraz uwaga: podobno 2+2=4 prawie zawsze, poproszę źródła

Łatwe ;)
http://en.wikipedia.org/wiki/Natural_number#Constructi...

Wciąż proszę o źródła. :)

a ja poproszę o źródła powyższego np. autora tego wpisu... ;)

Jako praktyk ale też jako dydaktyk powiem Ci tak: potraktuj to jako wiedzę ekspercką, nie ma żadnego obowiązku uznawania jej (nikt nikogo nie zmusza do uznania jakiejkolwiek wiedzy za wiarygodną). Np. każdy mój klient, i nie tylko mój, żąda od dostawcy usługi jakiegoś uwiarygodnienia obietnicy, że "potrafię i wiem jak". Zastanów się ilu Twoich klientów pyta o "źródła" w odpowiedzi na np. Twoje CV lub stwierdzenie "napisałem takich systemów wiele"...

Pytanie "Proszę o źródła" to jedne z najbardziej demagogicznych i, wybacz, idiotycznych pytań, bo jeżeli jakiekolwiek grono ludzi ze sobą rozmawia to albo uznaje wzajemnie swoje wypowiedzi albo nie bierze udziału w dyskusji. Ja zakładam, że każdy szczerze wypowiada swoje opinie, wierzy w to co pisze. Owszem nie zmienia to faktu, że można z tym polemizować ale prosta logika nakazywała by, byś Ty pokazał kontrargument (inne badanie) - bo oczekiwanie od rozmówcy dowodu, że "nie jest wielbłądem" jest nie na miejscu. Tak wiec jak chcesz zanegować czyjąś wypowiedź to na Tobie spoczywa obowiązek wykazania, ze masz rację negując...

Nawet nie mam ochoty cytowania tu jakiejś sterty książek z mojej półki, masz prawo nie wierzyć, że w ogóle je posiadam, ale to podważa sens Twojej obecności w tej dyskusji. Mam te książki i daję wiarę ich autorom (nie pytaj dlaczego..., zapewne także czytasz książki i dajesz wiarę ich autorom, no chyba, ze do każdego wysyłasz pytanie o źródła... masz prawo)

Tak więc, prośba do każdego kto nie daje wiary w powyższy wykres: pokaż konkurencyjny wraz ze źródłem.

To powyższe adresuje do każdego kto ma zamiar pytać o źródła...
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
Proszę o źródła.

brak zaufania nie tłumaczy chciejstwa ;),

teraz uwaga: podobno 2+2=4 prawie zawsze, poproszę źródła

Łatwe ;)
http://en.wikipedia.org/wiki/Natural_number#Constructi...

Wciąż proszę o źródła. :)

Aczkolwiek to co napiszę nie jest przedmiotem tej dyskusji, ale żeby być w zgodzie z matematyką to nie chodzi w 2+2=4 o zdefiniowanie pojęcia liczba naturalna. Starożytni Grecy nie znali pojęcia zbioru, a jednak jakoś tam arytmetykę uprawiali. W tym równaniu chodzi o inny dział matematyki: algebrę. Otóż na jedno z pierwszych "ćwiczeń" w algebrze to definiowanie samej algebry: czyli działań addytywnych i multiplikatywnych. W algebraicznym ujęciu 2+2=4 jest tylko i wyłącznie w jednym przypadku, a cała reszta (nieskończenie wiele) to są dowolne inne liczby (dajmy na to ze zbioru liczb naturalnych), czyli np. 2+2=1, 2+2=2, ... Co tylko chcesz.

Jaki stąd może płynąć morał:
1. Źródła bywają różne: bardziej lub mniej kompletne
2. Aby szukać lub wskazywać źródło rozwiązania problemu trzeba najpierw ten problem umieć zdefiniować.
3. Są łatwe i proste rozwiązania. Trzeba dążyć do prostych, bo łatwe to z reguły skróty, a do prostego rozwiązanie z reguły prowadzi trudna droga przez zdobywanie wiedzy i doświadczenia.
4. Wskazanie źródła czasem bywa trudne, gdyż rozwiązanie powstaje jako połączenie różnych praktyk i metod. Tak powstają odkrywcze rozwiązania.
5. Dobry analityk/projektant powinien mieć naturalne pragnienie drążenia tematu. Inaczej kończy się na wskazaniu obcojęzycznego źródła rozwiązania w Wikipedii.
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
W drugiej - w specyfikacji.
I nie tyle analiza co "modelowanie biznesowe" bo analiza wymagań kończy się w "wytwarzaniu" a i samo modelowanie biznesowe - po prostu "pojawia się" czyli zaczyna się "poza wykresem"... ale może coś źle "odczytuję".
To nawet ma sens - w końcu tej analizy nigdy nie robisz od zera - firma jakoś funkcjonuje, jakieś dokumenty posiada, jakieś procesy w niej istnieją w bardziej lub mniej sformalizowanej formie. Analiza biznesowa nie istnieje tylko w ramach danego projektu.
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...
PS:
W drugiej - w specyfikacji.
I nie tyle analiza co "modelowanie biznesowe" bo analiza wymagań kończy się w "wytwarzaniu" a i samo modelowanie biznesowe - po prostu "pojawia się" czyli zaczyna się "poza wykresem"... ale może coś źle "odczytuję".

Są to uśrednione rozkłady statystyczne obłożenia ról projektowych pracą. Stanowią one modelowy rozkład prac projektowych. Pierwotna "czysta" wersja tego rysunku może wyglądać tak:
Obrazek
.

Chyba wszystko już gra?

Aby dobrze zrozumieć co się dziej w projekcie prowadzonym zgodnie z RUP i w jakiej kolejności najlepiej spojrzeć na ten rysunek:
Obrazek


Pierwsza wersja harmonogramu projektu (rozkład prac i rzeczy do zrobienia) powinna powstać zanim projekt ruszy. Równolegle do tego startują pierwsze prace związane z modelowaniem biznesowym (co się wiąże z konkretną dokumentacją). Dalej specyfikacja wymagań, analiza i projektowanie, programowanie, testowanie i wdrożenie. Gdzieś tam pod koniec projektu poza ramami projektu jest ocena działań projektowych. Zarządzanie projektem, przygotowanie środowiska i zarządzanie konfiguracją i zmianami jest procesem ciągłym.

Łącząc jeden i drugi rysunek dostajemy obraz: co po czym startuje, co jest procesem ciągłym oraz gdzie te prace się zaczynają a gdzie się kończą.

konto usunięte

Temat: Analityk IT vs Projektant IT

Pytanie "Proszę o źródła" to jedne z najbardziej demagogicznych i, wybacz, idiotycznych pytań,

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

Jeśli nikt o takie uzasadnienia nie prosi to najwyraźniej dyskutanci mają taką samą wiedzę ale w takim przypadku ich dyskusja jest trochę bez sensu ponieważ ogranicza się do przekazywania sobie wiedzy którą najwyraźniej już posiadają albo przyjmowania każdej informacji na wiarę co imho, inżynierowi nie przystoi ;)
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 :)
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 ...
Tak więc, prośba do każdego kto nie daje wiary w powyższy wykres: pokaż konkurencyjny wraz ze źródłem.

Aleksander podesłał jakiś inny. :)
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...
Aleksander podesłał jakiś inny. :)

RUP sam w sobie ma kilka odmian: RUP, OpenUP, OpenUP/Basic i jeszcze kilka. Z tego co widzę, Jarek podesłał jeszcze inną kompilację procesu wytwórczego. Jako że RUP jest ramą projektową to wszystko co się mieści w ramie projektowej i nie jest z nią sprzecznym jest jak najbardziej poprawne.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
Pytanie "Proszę o źródła" to jedne z najbardziej demagogicznych i, wybacz, idiotycznych pytań,

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

Jeśli nikt o takie uzasadnienia nie prosi to najwyraźniej dyskutanci mają taką samą wiedzę ale w takim przypadku ich dyskusja jest trochę bez sensu ponieważ ogranicza się do przekazywania sobie wiedzy którą najwyraźniej już posiadają

nie, wyjaśniłem to powyżej: dyskutant dyskutuje a nie wymienia się cytatami, to jednak wymaga posiadania własnego zdania
albo przyjmowania każdej informacji na wiarę co imho, inżynierowi nie przystoi ;)

toczą się na forach nie raz długie dyskusje czy inżynier to także naukowiec: czy tylko wytwarza na bazie wiedzy jaką posiadł czy też "tworzy nowe", przyjmowanie na wiarę to nic innego jak wiara w cudzą wiedzę, podważać zaś trzeba umieć... polecam lekturę Karla Poppera (to źródło jak by co ;)).
http://pl.wikipedia.org/wiki/Karl_Popper
rozdział "Falsyfikowalność"

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

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.

http://en.wikipedia.org/wiki/Software_craftsmanship
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?
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? Na jakie źródło mam się powołać? Albo wierzysz mi albo nie.... jak nie to rozmowa nie ma sensu. Przesłuchanie świadka w sądzie to co? jego opinia i wymóg podania źródeł?

Tak więc, prośba do każdego kto nie daje wiary w powyższy wykres: pokaż konkurencyjny wraz ze źródłem.

Aleksander podesłał jakiś inny. :)

nieco się tylko różniący, zakładając że pochodzą z różnych źródeł ich podobieństwo powinno dać do myślenia... jak mawia mój znajomy profesor: gdy dwóch mówi to samo to nie jest to samo...

Tak więc osobiście stoję za tym, by uznawać, że analityk i projektant to samo, bo projektowanie wymaga analizy, rozdzielanie tego powoduje, że projektant poznaje cudzą analizę, ma wiedzę z drugiej ręki co nie pomaga a szkodzi (głuchy telefon). Osobna kwestią jest to "co jest projektowane", czym innym jest projektowanie logiki systemu a czym innym architektury środowiska w jakim się wykona, to dwa odrębne projekty... z tego powodu jeżeli programista uważa, że "wszystko co jest systemem to jego zadanie", raczej grubo się myli... i szkodzi projektowi.

konto usunięte

Temat: Analityk IT vs Projektant IT

PS:
W drugiej - w specyfikacji.
I nie tyle analiza co "modelowanie biznesowe" bo analiza wymagań kończy się w "wytwarzaniu" a i samo modelowanie biznesowe - po prostu "pojawia się" czyli zaczyna się "poza wykresem"... ale może coś źle "odczytuję".

Są to uśrednione rozkłady statystyczne obłożenia ról projektowych pracą.

Wiki nic o uśrednieniu i pracy nie wspomina (wiem, wiki się nie zna) a wykres jest tam nazwany "fazy i role (dyscypliny)". Ok, nieważne.

Może inaczej - czy ktoś potrafi odpowiedzieć na pytanie, dlaczego RUP jest dobrą metodyką realizacji projektów IT (bo złą przecież nie jest, prawda ?) ?Jakub Wojt edytował(a) ten post dnia 26.06.12 o godzinie 08:43
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Analityk IT vs Projektant IT

Może inaczej - czy ktoś potrafi odpowiedzieć na pytanie, dlaczego RUP jest dobrą metodyką realizacji projektów IT (bo złą przecież nie jest, prawda ?) ?

a kto napisał że "jest dobrą", co najwyżej "jest dobrą gdy..." po trzecie nie ma obowiązku stosowania, jak zresztą jakiejkolwiek metodyki czy nawet metody, w końcu mamy zawsze w arsenale XP...
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...
Może inaczej - czy ktoś potrafi odpowiedzieć na pytanie, dlaczego RUP jest dobrą metodyką realizacji projektów IT (bo złą przecież nie jest, prawda ?) ?

Dlatego że RUP powstał jako wnikliwa analiza tysięcy projektów. Tych projektów, które się zakończyły fiaskiem. Dało to statystyczny obraz tego co idzie nie tak oraz związek przyczynowo-skutkowy co mogło być zrobione inaczej. W wyniku tych badań zostały wyznaczone 6 najlepszych praktyk. Nie są to subiektywnie najlepsze praktyki dla jednostek, ale obiektywnie najlepsze praktyki dla projektu:
* Iteracyjne wytwarzanie oprogramowania (Iterative Development).
* Zarządzanie wymaganiami (Requirement Management).
* Architektura oparta na komponentach (Component Based Architecture).
* Graficzne projektowanie oprogramowania (UML).
* Kontrola jakości oprogramowania (Quality Assurance).
* Proces kontroli zmian w oprogramowaniu (Change Management).

To tak jak z Gun Kata: dzięki przeanalizowniu tysięcy nagrań walk na broń palną Klerycy wywnioskowali, że geometryczne ustawienie i zachowania przeciwników podczas walki są statystycznie przewidywalnym elementem.
Sławomir Orłowski

Sławomir Orłowski PhD, physicist,
software
developer/architect
team leader...

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:
Jakub Wojt:
Pytanie "Proszę o źródła" to jedne z najbardziej demagogicznych i, wybacz, idiotycznych pytań,

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

Jeśli nikt o takie uzasadnienia nie prosi to najwyraźniej dyskutanci mają taką samą wiedzę ale w takim przypadku ich dyskusja jest trochę bez sensu ponieważ ogranicza się do przekazywania sobie wiedzy którą najwyraźniej już posiadają

nie, wyjaśniłem to powyżej: dyskutant dyskutuje a nie wymienia się cytatami, to jednak wymaga posiadania własnego zdania
albo przyjmowania każdej informacji na wiarę co imho, inżynierowi nie przystoi ;)

toczą się na forach nie raz długie dyskusje czy inżynier to także naukowiec: czy tylko wytwarza na bazie wiedzy jaką posiadł czy też "tworzy nowe", przyjmowanie na wiarę to nic innego jak wiara w cudzą wiedzę, podważać zaś trzeba umieć... polecam lekturę Karla Poppera (to źródło jak by co ;)).
http://pl.wikipedia.org/wiki/Karl_Popper
rozdział "Falsyfikowalność"

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

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.

http://en.wikipedia.org/wiki/Software_craftsmanship
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?
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? Na jakie źródło mam się powołać? Albo wierzysz mi albo nie.... jak nie to rozmowa nie ma sensu. Przesłuchanie świadka w sądzie to co? jego opinia i wymóg podania źródeł?

Tak więc, prośba do każdego kto nie daje wiary w powyższy wykres: pokaż konkurencyjny wraz ze źródłem.

Aleksander podesłał jakiś inny. :)

nieco się tylko różniący, zakładając że pochodzą z różnych źródeł ich podobieństwo powinno dać do myślenia... jak mawia mój znajomy profesor: gdy dwóch mówi to samo to nie jest to samo...

Tak więc osobiście stoję za tym, by uznawać, że analityk i projektant to samo, bo projektowanie wymaga analizy, rozdzielanie tego powoduje, że projektant poznaje cudzą analizę, ma wiedzę z drugiej ręki co nie pomaga a szkodzi (głuchy telefon). Osobna kwestią jest to "co jest projektowane", czym innym jest projektowanie logiki systemu a czym innym architektury środowiska w jakim się wykona, to dwa odrębne projekty... z tego powodu jeżeli programista uważa, że "wszystko co jest systemem to jego zadanie", raczej grubo się myli... i szkodzi projektowi.

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.

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.
Sławomir Orłowski

Sławomir Orłowski PhD, physicist,
software
developer/architect
team leader...

Temat: Analityk IT vs Projektant IT

Aleksander Olszewski:
Jakub Wojt:
...
Może inaczej - czy ktoś potrafi odpowiedzieć na pytanie, dlaczego RUP jest dobrą metodyką realizacji projektów IT (bo złą przecież nie jest, prawda ?) ?

Dlatego że RUP powstał jako wnikliwa analiza tysięcy projektów. Tych projektów, które się zakończyły fiaskiem. Dało to statystyczny obraz tego co idzie nie tak oraz związek przyczynowo-skutkowy co mogło być zrobione inaczej. W wyniku tych badań zostały wyznaczone 6 najlepszych praktyk. Nie są to subiektywnie najlepsze praktyki dla jednostek, ale obiektywnie najlepsze praktyki dla projektu:
* Iteracyjne wytwarzanie oprogramowania (Iterative Development).
* Zarządzanie wymaganiami (Requirement Management).
* Architektura oparta na komponentach (Component Based Architecture).
* Graficzne projektowanie oprogramowania (UML).
* Kontrola jakości oprogramowania (Quality Assurance).
* Proces kontroli zmian w oprogramowaniu (Change Management).

To tak jak z Gun Kata: dzięki przeanalizowniu tysięcy nagrań walk na broń palną Klerycy wywnioskowali, że geometryczne ustawienie i zachowania przeciwników podczas walki są statystycznie przewidywalnym elementem.
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).

Następna dyskusja:

Analityk biznesowy - początki




Wyślij zaproszenie do