Temat: Czy przypadki użycia definiują system informatyczny ?

dlatego potrzebny jest projektant... a projektowanie jest procesem twórczym a nie automatycznym deterministycznym ...

Aktualnie tak, ale...

i przy tym pozostańmy, jak się coś w tym zmieni zmieni to ja popatrzę ;)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jarek Żeliński:

dlatego potrzebny jest projektant... a projektowanie jest procesem twórczym a nie automatycznym deterministycznym ...

Aktualnie tak, ale...

i przy tym pozostańmy, jak się coś w tym zmieni zmieni to ja popatrzę ;)

Brr..
Nie lubię dyskusji które kończą się tak jak mogłyby się zacząć. ;)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:

i przy tym pozostańmy, jak się coś w tym zmieni zmieni to ja popatrzę ;)

Brr..
Nie lubię dyskusji które kończą się tak jak mogłyby się zacząć. ;)

a co tu dodać? Fakty są takie jakie są, a ja z faktami nie dyskutuję :)

Temat: Czy przypadki użycia definiują system informatyczny ?

Brr..
Nie lubię dyskusji które kończą się tak jak mogłyby się zacząć. ;)

a co tu dodać? Fakty są takie jakie są, a ja z faktami nie dyskutuję :)

Hm..
fakty są takie, że ok 50% (według innych szacunków 70%) projektów IT kończy się fiaskiem. Dla mnie to znaczy tylko tyle, że są one realizowane (a w zasadzie nierealizowane) źle.

Z pewnych, nie znanych sobie powodów, próbuje przedstawić pomysły na zmianę tej sytuacji;

Mam takie 'pesymistyczne' wrażenie, że z tych samych powodów, z jakich projekty IT nie wypalają, nie wypali również ta (i jej podobne) dyskusje.. ale to jak na totalnym marginesie ;)Jakub Wojt edytował(a) ten post dnia 21.06.11 o godzinie 23:58

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:
fakty są takie, że ok 50% (według innych szacunków 70%) projektów IT kończy się fiaskiem. Dla mnie to znaczy tylko tyle, że są one realizowane (a w zasadzie nierealizowane) źle.

i wiadomo dlaczego (te same badania): źle określone wymagania, wiadomo, także że jest to powód pomijania lub znacznego ograniczania analiz wymagań i zły osób ich prowadzenia.

Wiadomo także, że przytłaczająca większość wypadków drogowych jest z winy kierowców: nie przestrzeganie przepisów ruchu drogowego, i jak na razie nic nie wskazuje by miało się tu coś zmienić na lepsze.

Z pewnych, nie znanych sobie powodów, próbuje przedstawić pomysły na zmianę tej sytuacji;

robi to wielu, Ty, ja itp. Powiem więcej: potrafię na własnych referencjach pokazać, że da się, zapewne i Ty masz takie referencje. rzecz w tym, że poprawianie jakości projektów nie jest w interesie wielu firm - dostawców - bo z tego żyją... co mi już niejedna powiedziała wprost.

Mam takie 'pesymistyczne' wrażenie, że z tych samych powodów, z jakich projekty IT nie wypalają, nie wypali również ta (i jej podobne) dyskusje.. ale to jak na totalnym marginesie ;)

ja uważam, że nie jest to problem tej dyskusji a tego o czym napisałem powyżej. Jak na razie regularnie słyszę od firm IT: proszę Pana, prowadzimy projekty po swojemu bo nam się to lepiej opłaci. Dlatego prawie każdy mój klient (ale są wyjątki ;)) to nabywca oprogramowania, w zasadzie w 100% są to firmy mające już jakiś nieudany projekt za sobą. Oto klasyczny początek moich projektów:

Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że „tego nie można”, „to należy uprościć” albo „tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy może nam Pan tym razem pomóc?

Wiedzą co było powodem kłopotów: koszty zmian zakresu w trakcie trwania projektu. Zwróć uwagę, że takich ludzi jak ja czy ty "torpeduję" programiści i dostawcy różnych ERPów, CRM'ów a nie inni analitycy projektanci... choć teoretycznie dostawcom powinno zależeć na poprawie tych złych statystyk... Znam metodyki analiz zalecane przez producentów ERP (w tym dość dobrze Microsoft, ISF i SAGE). Wszystkie wskazuje na potrzebę wykonania map procesów, analizy gap/fit danego ERP (które potrzeby realizuje a które nie), wdrożenia bez zmian pasujących funkcjonalności, ewentualnego zaprojektowania, implementacji i integracji funkcjonalniej brakujących (każdy z nich dostawcza stosowny framework!), prawie żaden integrator tego nie robi!, preferują kastomizacje, które niszczą system...

Przeczytaj to:
http://it-consulting.pl/autoinstalator/wordpress/index...

Tak więc niezależnie od metody analizy i projektowania (preferowana przez Ciebie, przez ze mnie, inne) da się, rzesze ludzi skutecznych analityków skupione np. wokół IIBA są na to żywym dowodem. Jarek Żeliński edytował(a) ten post dnia 22.06.11 o godzinie 06:53

Temat: Czy przypadki użycia definiują system informatyczny ?

i wiadomo dlaczego (te same badania): źle określone wymagania,
wiadomo, także że jest to powód pomijania lub znacznego
ograniczania analiz wymagań i zły osób ich prowadzenia.

Czy istnieje jakikolwiek 'algorytm' tworzenia analizy wymagań ?
Czy otrzymaną dokumentacje można jakoś ocenić pod kątem 'jakości' albo użyteczności dla architekta / programisty ?

Wiadomo także, że przytłaczająca większość wypadków
drogowych jest z winy kierowców: nie przestrzeganie przepisów
ruchu drogowego, i jak na razie nic nie wskazuje by miało się tu
coś zmienić na lepsze.

Hm.. gdyby przeciętna podróż samochodem kończyła by się tak jak kończy się przeciętny projekt IT ... ;)

[...] rzecz w tym, że poprawianie jakości projektów nie
jest w interesie wielu firm - dostawców - bo z tego żyją... co
mi już niejedna powiedziała wprost.

Hm.. jeśli pojawia się coś nowego i to coś działa to według mnie wdrożenie takiej 'nowości' jest jak najbardziej w ich interesie. Ale na biznesie się nie znam... ;)

ja uważam, że nie jest to problem tej dyskusji a tego o czym
napisałem powyżej.

Tak, ale wydaje mi się, że są też inne problemy. I są one bardziej 'podstawowe'.

Nie ma algorytmu tworzenia dobrej analizy tzn. analiza pozostaje czymś w rodzaju sztuki. A przynajmniej nie spotkałem się z jakimkolwiek działającym (w ogólnym przypadku) modelem realizowania projektu IT.

"Realizacja projektów IT" to tylko nazwa. Nie wiadomo co to właściwie oznaczy. Tzn nie ma na to modelu.

Nie ma algorytmu tworzenia dobrej analizy bo nie wiadomo co ma być przetworzone na co i w jaki sposób ma się to odbyć.

Odnosząc to do modelu budowlanego (chociaż pewnie nic on nie wyjaśni ;) - jeśli ktoś chce zbudować dom (przetworzenie cegieł i betonu na budynek) to musi znać prawa fizyki. Bez ich znajomości albo się robi coś co już 'działa', albo ruderę albo coś co się szybko wali.

Projekty IT polegają na przetwarzaniu informacji. Jeśli ktoś chce sensownie realizować projekty IT musi znać prawa fizyki dot. przetwarzania informacji i w odniesieniu do nich stworzyć 'framework' realizacji. Tego się nie robi (a przynajmniej ja na nic takiego nie znalazłem) i według mnie to, a nie brak 'dobrej' analizy, jest główną przyczyną takiej sytuacji.

RUP, AGILE, UML, Waterfall to niby (im dłużej o nich myślę i czytam - tym bardziej wydają mi się trywialne a w konsekwencji bezużyteczne) fajne narzędzia ale nigdzie nie definiują swojego określają swojego kontekstu tzn: nigdzie nie jest napisane jaki (dokładnie) proces usprawniają i w odniesieniu do czego należy badać ich 'jakość / przydatność'.

...Ale to moja autorska teoria więc proszę się nie sugerować ;)

Jak na razie regularnie słyszę od firm IT:
proszę Pana, prowadzimy projekty po swojemu bo nam się to lepiej
opłaci.

Imho mówią tak bo nie wiedzą co robią. A jak się i tak nie co się robi to lepiej zrobić to taniej ;)

Wiedzą co było powodem kłopotów[...] poprawie tych złych statystyk...
Znam metodyki analiz zalecane przez producentów ERP (w tym dość
dobrze Microsoft, ISF i SAGE). Wszystkie wskazuje na potrzebę
wykonania map procesów, [...] brakujących (każdy z nich dostawcza
stosowny framework!), prawie żaden integrator tego nie robi!,

Nie dziwie się takiej sytuacji. Diagramy, mapy, analizy gap/fit itd to bardzo fajne narzędzia ale nie wiadomo właściwie jaki proces mają usprawniać (a przynajmniej ja się nie spotkałem definicją) . Jeśli nie wiadomo co mają usprawniać, to właściwie skąd wiadomo czy używa się ich dobrze ? W takiej sytuacji tak na prawdę mogą się sprawdzić jedynie Artyści analizy a ich jest po prostu za mało żeby 'uprzemysłowić' IT.

Na czym polega ‘realizacja projektu IT’ ?

Co na co przetwarzamy i jaki jest sposób na 'dobre' przetwarzanie?
Jeśli ktoś uważa, że bez 'fizyki informacji' i opartego na niej frameworka jest w stanie wykonać 'dobrą analizę' to IMHO popełnia ten sam błąd co programista, który nie wiadomo skąd, ‘wie’ jakie atrybuty musi mieć ‘użytkownik’ i na czym ma polegać jego ‘rejestracja’ tzn. ignoruje kontekst rzeczy którą ma zrobić.

Z tego samego powodu o realizacji IT można sobie pisać (i robić) byle co bo (jeśli tylko brzmi sensownie) i tak nie wiadomo co się robi (Testy mutacyjne, Agile, TDD, waterflow). Tzn. nie ma kontekstu na podstawie którego można było by ww. metodologie ocenić... to samo dotyczy notacji (łącznie z UML)

preferują kastomizacje, które niszczą system...
Przeczytaj to:
http://it-consulting.pl/autoinstalator/wordpress/index...
/03/frameworks-introduction-czyli-jak-sie-psuje-dobre-erp/

czytałem wcześniej ;)

Hm .. najwyraźniej problem 'chęci zmiany czegoś co działa' dotyczy projektów IT na wszystkich poziomach.. ;)

Tak więc niezależnie od metody analizy i projektowania
(preferowana przez Ciebie, przez ze mnie, inne) da się, rzesze
ludzi skutecznych analityków skupione np. wokół IIBA są na to
żywym dowodem.

Oczywiście są nieliczni Artyści analizy którzy intuicyjnie(?) potrafią wykonać dobrą dokumetację. Być może nawet to nie są artyści a jedynie ludzie którzy do perfekcji opanowali metodę tworzenia dobrej dokumentacji analitycznej.

Zarówno w jednym i drugim przypadku sprwadza się to do tego, że albo nie ma przepisu na dobrą analizę albo jest on zbyt trudny do nauczenia; a zatem trzeba ten przepis albo stworzyć albo uprościć. I do tego właśnie dążę :)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:
Zarówno w jednym i drugim przypadku sprwadza się to do tego, że albo nie ma przepisu na dobrą analizę albo jest on zbyt trudny do nauczenia; a zatem trzeba ten przepis albo stworzyć albo uprościć. I do tego właśnie dążę :)

Osobiście obstawiam pierwsze, dlatego, że nadal w budownictwie niezdefiniowano "przepisu" na fajne projektowanie domów... podobnie nie ma przepisu na dobrego kucharza, dobrego biegacza itp...

Temat: Czy przypadki użycia definiują system informatyczny ?

Zarówno w jednym i drugim przypadku sprwadza się to do tego, że albo nie ma przepisu na dobrą analizę albo jest on zbyt trudny do nauczenia; a zatem trzeba ten przepis albo stworzyć albo uprościć. I do tego właśnie dążę :)

Osobiście obstawiam pierwsze, dlatego, że nadal w budownictwie niezdefiniowano "przepisu" na fajne projektowanie domów...

Wychodzi chyba na to, że 'budowlanka' ma ten sam problem co IT;
Czy w związku z tym, trzeba zrezygnować z modelu 'budowlanego' ;)

Temat: Czy przypadki użycia definiują system informatyczny ?

Jakub Wojt:
Czy istnieje jakikolwiek 'algorytm' tworzenia analizy wymagań ?

A czy istnieje algorytm pisania wiersza, opery, projektowania hotelu?

Czy otrzymaną dokumentacje można jakoś ocenić pod kątem 'jakości' albo użyteczności dla architekta / programisty ?

Tak.

Hm.. jeśli pojawia się coś nowego i to coś działa to według mnie wdrożenie takiej 'nowości' jest jak najbardziej w ich interesie. Ale na biznesie się nie znam... ;)

Najwyraźniej. Jeżeli firma IT rozlicza się za czas pracy a pozyskanie każdego klienta kosztuje to jest jasną sprawą, że najbardziej opłaca jej się prowadzić jak najdłuższe projekty zawsze dla tego samego odbiorcy.

Nie ma algorytmu tworzenia dobrej analizy tzn. analiza pozostaje czymś w rodzaju sztuki. A przynajmniej nie spotkałem się z jakimkolwiek działającym (w ogólnym przypadku) modelem realizowania projektu IT.

Model i algorytm to 2 różne rzeczy. Jestem w stanie zaprezentować kilka modeli realizowania projektów IT. Skutecznych w różnych scenariuszach.

"Realizacja projektów IT" to tylko nazwa. Nie wiadomo co to właściwie oznaczy. Tzn nie ma na to modelu.

Nie prawda. Wiadomo co to jest realizacja projektów IT. Przynajmniej w mojej organizacji jest to jasno zdefiniowane. Jest to proces dostarczania systemów IT zgodnych ze Specyfikacją Wymagań Systemu.

Odnosząc to do modelu budowlanego (chociaż pewnie nic on nie wyjaśni ;) - jeśli ktoś chce zbudować dom (przetworzenie cegieł i betonu na budynek) to musi znać prawa fizyki. Bez ich znajomości albo się robi coś co już 'działa', albo ruderę albo coś co się szybko wali.

Sama znajomość fizyki w niczym Ci nie pomoże. Musisz wiedzieć co to za budynek, dla kogo, co będzie w nim robione, jaką ma mieć powierzchnię przeznaczoną dla poszczególnych działań. Trzeba znać prawo. Trzeba znać dostępne technologie i materiały. Słowem potrzebujesz:
projektu architektonicznego
projektu budowlanego
projektów branżowych (elektryka, wod-kan, klima-went)
inspektora nadzoru budowlanego
kierownika budowy
a dopiero potem WYKONAWCY
i nie wystarczy powiedzieć "chcę dom dla 4 osobowej rodziny: salon z aneksem kuchennym, 4 sypialnie, 2 pokoje dzienne i 2 łazienki" żeby powstał taki dom jakiego potrzebujesz

Projekty IT polegają na przetwarzaniu informacji. Jeśli ktoś

Nieprawda. Projekty IT polegają na tworzeniu systemów do zbierania, przechowywania, przetwarzania i udostępniania informacji.

'framework' realizacji. Tego się nie robi (a przynajmniej ja na nic takiego nie znalazłem) i według mnie to, a nie brak 'dobrej' analizy, jest główną przyczyną takiej sytuacji.

Robi się, nawet niektóre wymieniasz niżej.

RUP, AGILE, UML, Waterfall to niby (im dłużej o nich myślę i czytam - tym bardziej wydają mi się trywialne a w konsekwencji bezużyteczne) fajne narzędzia ale nigdzie nie definiują swojego określają swojego kontekstu tzn: nigdzie nie jest napisane jaki (dokładnie) proces usprawniają i w odniesieniu do czego należy badać ich 'jakość / przydatność'.

RUP jest dokładnie zdefiniowanym frameworkiem procesu, więc piszesz bzdury kompletne. Jest wiele opracowań mówiących gdzie i w jakich warunkach wymienione przez Ciebie organizacje projektów się sprawdzają. I nie rozumiem co tam robi UML, bo nie ma nic wspólnego pozostałymi - czy to jakieś ćwiczenie z cyklu skreśl niepasujące?

Imho mówią tak bo nie wiedzą co robią. A jak się i tak nie co się robi to lepiej zrobić to taniej ;)

Dokładnie wiedzą co robią.

Nie dziwie się takiej sytuacji. Diagramy, mapy, analizy gap/fit itd to bardzo fajne narzędzia ale nie wiadomo właściwie jaki proces mają usprawniać (a przynajmniej ja się nie spotkałem definicją) . Jeśli nie wiadomo co mają usprawniać, to właściwie skąd wiadomo czy używa się ich dobrze ? W takiej sytuacji tak na prawdę mogą się sprawdzić jedynie Artyści analizy a ich jest po prostu za mało żeby 'uprzemysłowić' IT.

Wszystko wiadomo. Poczytaj o tym czym jest modelowanie i do czego służy. To tak samo jak mapa. Po co jest mapa? Przecież niczego nowego nie wnosi i nie usprawnia - a jednak łatwiej jest szukać drogi do celu z jej wykorzystaniem niż jeżdżąc po mieście w ciemno.

Jeśli ktoś uważa, że bez 'fizyki informacji' i opartego na niej frameworka jest w stanie wykonać 'dobrą analizę' to IMHO popełnia ten sam błąd co programista, który nie wiadomo skąd, ‘wie’ jakie atrybuty musi mieć ‘użytkownik’ i na czym ma polegać jego ‘rejestracja’ tzn. ignoruje kontekst rzeczy którą ma zrobić.

Nie wiem co to jest 'fizyka informacji' wiem natomiast co to jest modelowanie obiektowe i wiem, że pozwala ono tworzyć dobre - tzn. pozwalające na osiągnięcie wyznaczonych celów i możliwie jednoznaczne - wymagania.

Z tego samego powodu o realizacji IT można sobie pisać (i robić) byle co bo (jeśli tylko brzmi sensownie) i tak nie wiadomo co się robi (Testy mutacyjne, Agile, TDD, waterflow). Tzn. nie ma kontekstu na podstawie którego można było by ww. metodologie ocenić... to samo dotyczy notacji (łącznie z UML)

Oczywiście że są miary skuteczności projektów, wydajności procesów wytwórczych itp.

Hm .. najwyraźniej problem 'chęci zmiany czegoś co działa' dotyczy projektów IT na wszystkich poziomach.. ;)

???

Oczywiście są nieliczni Artyści analizy którzy intuicyjnie(?)

Intuicja pozwala skrócić czas takiej analizy. Sprawdzone metody, narzędzia i doświadczenie to źródło powtarzalnego(!) sukcesu.

Zarówno w jednym i drugim przypadku sprwadza się to do tego, że albo nie ma przepisu na dobrą analizę albo jest on zbyt trudny do nauczenia; a zatem trzeba ten przepis albo stworzyć albo uprościć. I do tego właśnie dążę :)

Premature optimization is the root of all evil. (Donald Knuth)

Temat: Czy przypadki użycia definiują system informatyczny ?

Czy istnieje jakikolwiek 'algorytm' tworzenia analizy wymagań ?

A czy istnieje algorytm pisania wiersza, opery, projektowania hotelu?

... a zatem to sztuka :)

Czy otrzymaną dokumentacje można jakoś ocenić pod kątem 'jakości' albo użyteczności dla architekta / programisty ?

Tak.

Jak można 'dobrze' ocenić sztukę ?

Hm.. jeśli pojawia się coś nowego i to coś działa to według mnie wdrożenie takiej 'nowości' jest jak najbardziej w ich interesie. Ale na biznesie się nie znam... ;)

Najwyraźniej. Jeżeli firma IT rozlicza się za czas pracy a pozyskanie każdego klienta kosztuje to jest jasną sprawą, że najbardziej opłaca jej się prowadzić jak najdłuższe projekty zawsze dla tego samego odbiorcy.

A mi się wydaje... :) że jak ktoś chce robić dobry biznes to obniża koszty i podnosi jakość swoich produktów; bez 'działających nowości' (innowacji) to nie jest możliwe. Dodatkowo gdybym miał dużą firmę IT to klientów chciałbym mieć jak najwięcej (albo - żeby konkurencja miała ich jak najmniej); to obniża koszty.

Kurcze, jak mówiłem to Niemcowi to zrozumiał od razu; może wiedział to wcześniej... ;)

Praca na godziny ? To nagradza niewydajność... można być uczciwym i pracować źle ;)

Nie ma algorytmu tworzenia dobrej analizy tzn. analiza pozostaje czymś w rodzaju sztuki. A przynajmniej nie spotkałem się z jakimkolwiek działającym (w ogólnym przypadku) modelem realizowania projektu IT.

Model i algorytm to 2 różne rzeczy. Jestem w stanie zaprezentować kilka modeli realizowania projektów IT. Skutecznych w różnych scenariuszach.

Proszę o nazwę :)

"Realizacja projektów IT" to tylko nazwa. Nie wiadomo co to właściwie oznaczy. Tzn nie ma na to modelu.

Nie prawda. Wiadomo co to jest realizacja projektów IT. Przynajmniej w mojej organizacji jest to jasno zdefiniowane. Jest to proces dostarczania systemów IT zgodnych ze Specyfikacją Wymagań Systemu.

Proszę o formalny zapis tej definicji.
Jeśli to jest opis precyzyjny – da się to zrobić. Jeśli nie jest precyzyjny ...

Sama znajomość fizyki w niczym Ci nie pomoże. Musisz wiedzieć co to za budynek, [...] budowy
a dopiero potem WYKONAWCY

Jak najbardziej, ale prawo (np. dot bezpieczeństwa), materiały, technologie to wszystko bazuje na fizyce.
Sama fizyka nie wystarczy, tak jak sam fundament nie tworzy domu, ale tak samo jak dom bez fundamentów nie powstanie, tak i nie da się ‘wydajnie’ budować bez znajomości fizyki (tzn bez fizyki budowanie domów jest sztuką ).

Projekty IT polegają na przetwarzaniu informacji. Jeśli ktoś

Nieprawda. Projekty IT polegają na tworzeniu systemów do zbierania, przechowywania, przetwarzania i udostępniania informacji.

A na podstawie czego te systemy powstają ?
Miałem na myśli 'przetwarzanie informacji od klienta'.

RUP, AGILE, UML, Waterfall to niby (im dłużej o nich myślę i czytam - tym [...] jaki (dokładnie) proces usprawniają i w odniesieniu do czego należy badać ich 'jakość / przydatność'.

RUP jest dokładnie zdefiniowanym frameworkiem procesu, więc piszesz bzdury kompletne.

Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu.

1.Czyli to takie narzędzie do tworzenia narzędzi do ‘realizacji projektu IT’. Jest frameworkiem do tworzenia frameworków.

2.RUP nie specyfikuje kiedy (w jakich sytuacjach) należy wykorzystać szablony / elementy jakich dostarcza. Dla mnie to trochę tak jakby stworzyć narzędzie i nie napisać jak go używać.

3.RUP nie definiuje miar jakości artefaktów na bazie których ‘działa’. Np. Definiuje proces ‘tworzenie analizy’ ale nigdzie nie definiuje tego, jaka ma ona być. Samochód ‘nie zadziała’ jak do baku naleje się wody; RUP bez dobrej analizy też nie będzie działać. RUP nie definiuje swojego ‘paliwa’ – IMHO trochę głupio.

4.I najważniejsze, powtórzę się ale co tam: RUP nie definiuje swojego kontekstu. Tzn. Każde narzędzie służy do usprawnienia jakiegoś procesu. Rup tego procesu nie definiuje (‘realizacja projektu IT’ to nie jest definicja). W kontekście pkt.2 jego użytkownik, nie ma szans go dostosować do swoich potrzeb a w konsekwencji RUP nie ma prawa dla użytkownika działać.

Dla mnie RUP jest po prostu ładnie opakowanym zbiorem pobożnych życzeń. Jak ktoś chce robić coś szybko i dobrze to wg mnie powinien poszukać innej metod.

Jest wiele opracowań mówiących gdzie i w jakich warunkach wymienione przez Ciebie organizacje projektów się sprawdzają.

Czy są one częścią RUP’a ? Czyżby użytkownicy wiedzieli lepiej od twórcy jak trzeba / można używać narzędzia ? ;)
Jeśli nie - dlaczego nie ma tych informacji z specyfikacji?

I nie rozumiem co tam robi UML, bo nie ma nic wspólnego pozostałymi - czy to jakieś ćwiczenie z cyklu skreśl niepasujące?

UML nie definiuje jaki proces usprawnia i dlaczego.

Nie dziwie się takiej sytuacji. Diagramy, mapy, analizy gap/fit itd to bardzo fajne narzędzia ale nie wiadomo właściwie jaki proces mają usprawniać (a przynajmniej ja się nie spotkałem definicją) . Jeśli nie wiadomo co mają usprawniać, to właściwie skąd wiadomo czy używa się ich dobrze ? W takiej sytuacji tak na prawdę mogą się sprawdzić jedynie Artyści analizy a ich jest po prostu za mało żeby 'uprzemysłowić' IT.

Wszystko wiadomo.

A 50% - 60% projektów nie wypala.

To tak samo jak mapa. Po co jest mapa? Przecież niczego nowego nie wnosi i nie usprawnia - a jednak łatwiej jest szukać drogi do celu z jej wykorzystaniem niż jeżdżąc po mieście w ciemno.

Jasne. ‘Papierowa mapa, w pewnych warunkach, to użyteczny model. Mapa zapisana jako obraz BMP na pendrivie to też użyteczny model. Jedna i druga służą tym samym celom, modelują tak (i to) samo. Problem polega na tym, że w zależności od warunków któraś z nich może być całkowicie bezużyteczna.’

UML, RUP i inne... nie definiują warunków w jakich mają być używane tzn. Nie definiują swojego kontekstu. Nie można zatem ocenić ich jakości i przydatności co dla mnie oznacza są zbiorem ‘pobożnych zyczeń’ a nie narzędziem do realizacji projektów IT.

Nie wiem co to jest 'fizyka informacji' wiem natomiast co to jest modelowanie obiektowe i wiem, że pozwala ono tworzyć dobre - tzn. pozwalające na osiągnięcie wyznaczonych celów i możliwie jednoznaczne - wymagania.

Można ocenić jakość tych wymagań ?

Z tego samego powodu o realizacji IT można sobie pisać (i robić) byle co bo (jeśli tylko brzmi sensownie) i tak nie wiadomo co się robi (Testy mutacyjne, Agile, TDD, waterflow). Tzn. nie ma kontekstu na podstawie którego można było by ww. metodologie ocenić... to samo dotyczy notacji (łącznie z UML)

Oczywiście że są miary skuteczności projektów, wydajności procesów wytwórczych itp.

A miary jakości wyników analizy ?

Zarówno w jednym i drugim przypadku sprwadza się to do tego, że albo nie ma przepisu na dobrą analizę albo jest on zbyt trudny do nauczenia; a zatem trzeba ten przepis albo stworzyć albo uprościć. I do tego właśnie dążę :)

Premature optimization is the root of all evil. (Donald Knuth)

So true ...