Temat: Procesy, strategie i reguły...

Bo można robić rysunki techniczne które z kolei mogą zostać użyte do czegoś konkretnego.
Zapis formalny nie od razu oznacza zapisu użytecznego.

jak każdy zapis, istniejąc kod nie oznacza czegokolwiek wartościowego

Dla przykładu: do czego konkretnego można użyć np. diagramu UC ?

Np. do udokumentowania zakresu projekt

Teza "kod programu jest także jego dokumentacją" natychmiast rodzi w mojej wyobraźni: zbudowany dom jest udokumentowaniem jego istnienia.

A nie jest ? ;)

Nie, stań przed swoim i powiedz mi szybko ja skonstruowano fundament...

Z domami jest o tyle prostsza sprawa, że je widać i "stan domu" nie ulega zmianie w czasie.
Można więc je "narysować".

jak byś zareagował, gdyby Ci w sklepie rowerowym ekspedient powiedział, że dostaniesz coś na dwóch kołach, pod warunkiem, że podpiszesz umowę, że zapłacisz za każdy jego kilogram niezależnie od tego czy wyjdzie rower czy hulajnoga?

Tu nikt nikogo do niczego nie przekonuje, po protu w zawalonych projektach (nie tylko IT), podczas ich ratowania (lub ponownego rozpoczynania) projektowanie i dokumentowanie projektu pojawia się bardzo często jako wymagany etap.

No w końcu ogólnie pojęty management zaczyna rozumieć, że żeby coś zrobić, trzeba wiedzieć co ;)

a skąd ma wiedzieć skoro nie ma projektu? Kota w worku?

Nawet mój obecny projekt: dlaczego zostałem zaangażowany? Bo nikt nie miał pojęcia co powstaje, nie licząc fasady jaką jest ekran programu.

Ich problem rozwiązałby Agile albo Scrum; po co od razu zastanawiać się nad tym, co chce się robić ;)

tej sentencji nie zdążył byś nawet wypowiedzieć do końca, Ci od Agile? Scrum właśnie wylecieli ...

z poważnym biznesem to jest tak, że najpierw chce zobaczyć co dostanie a później płaci nie odwrotnie... i są to raczej umowy o dzieło więc opis dzieła musi istnieć w momencie podpisywania umowy o to dzieło.

Temat: Procesy, strategie i reguły...

jak każdy zapis, istniejąc kod nie oznacza czegokolwiek wartościowego

...

Dla przykładu: do czego konkretnego można użyć np. diagramu UC ?

Np. do udokumentowania zakresu projekt

na pewno ?

No w końcu ogólnie pojęty management zaczyna rozumieć, że żeby coś zrobić, trzeba wiedzieć co ;)

a skąd ma wiedzieć skoro nie ma projektu? Kota w worku?

No właśnie (najczęściej) nie wie i nie zdaje sobie z tego sprawy....

Nawet mój obecny projekt: dlaczego zostałem zaangażowany? Bo nikt nie miał pojęcia co powstaje, nie licząc fasady jaką jest ekran programu.

Ich problem rozwiązałby Agile albo Scrum; po co od razu zastanawiać się nad tym, co chce się robić ;)

tej sentencji nie zdążył byś nawet wypowiedzieć do końca, Ci od Agile? Scrum właśnie wylecieli ...

chyba muszę być mniej sarkastyczny ..

z poważnym biznesem to jest tak, że najpierw chce zobaczyć co dostanie a później płaci nie odwrotnie...

:)

Temat: Procesy, strategie i reguły...

Dla przykładu: do czego konkretnego można użyć np. diagramu UC ?

Np. do udokumentowania zakresu projekt

na pewno ?

w sensie, że w czym problem?

Temat: Procesy, strategie i reguły...

Dla przykładu: do czego konkretnego można użyć np. diagramu UC ?

Np. do udokumentowania zakresu projekt

na pewno ?

w sensie, że w czym problem?

W jaki sposób UC dokumentuje "zakres projektu" ?
Jak relacje między aktorami i przypadkami użycia definiują zakres ?

Dla mnie brzmi to trosze absurdalnie....

"Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu."

Temat: Procesy, strategie i reguły...

Jakub Wojt:
"Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu."

Zakres projektu dla kogo?

Powyższa definicja z ust Księgowej:
- wystawianie faktur sprzedaży (w załączeniu wzory faktur)
- rejestracja zamówień klientów (w załączeniu przykłady zamówień)
- oprogramowanie ma działać bezawaryjnie (dopuszczamy przerwy trwające do godziny czasu ale nie częściej niż raz w tygodniu)
- wystawione faktury mają być eksportowane do biura księgowego.
- z oprogramowania korzysta wyłącznie księgowa

To jest zakres dla analityka projektanta, w 100% do za modelowania z pomocą diagramu UC, ale opis powyższe jest zupełnie bezwartościowy dla programisty (kodera).

Analityk biznesowy musi powyższe zamienić na obiektowy model całej logiki jaka ma być zaimplementowana: model dziedziny systemu.

Tu pojawią się: klasy, sekwencje, statusy klas, algorytmy metod. To jest zakres projektu dla architekta, który "wpakuje" np. do frameworka i stworzy zakres projektu dla programistów.

W moich oczach nie ma nic bardziej ryzykownego niż przekazanie opisu księgowej programistom do wykonania.

Reguły biznesowe odgrywają tu niebagatelna rolę: stanowią kwintesencje logiki biznesowej.

Tak więc mamy trzy zakresy projektu, każdy inny i każdy należy udokumentować, jednoznacznie postawić zadanie.

Praca bez dokumentów, lubiane przez wielu zwinne agile/scrum, to atak na twierdzę bez mapy terenu i strategii.... rzeźnia....Jarek Żeliński edytował(a) ten post dnia 05.09.12 o godzinie 10:45

Temat: Procesy, strategie i reguły...

"Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu."

Zakres projektu dla kogo?

Powyższa definicja z ust Księgowej:
- wystawianie faktur sprzedaży (w załączeniu wzory faktur)
- rejestracja zamówień klientów (w załączeniu przykłady zamówień)
- oprogramowanie ma działać bezawaryjnie (dopuszczamy przerwy trwające do godziny czasu ale nie częściej niż raz w tygodniu)
- wystawione faktury mają być eksportowane do biura księgowego.
- z oprogramowania korzysta wyłącznie księgowa

To jest zakres dla analityka projektanta, w 100% do za modelowania z pomocą diagramu UC

... gdybym bym wredny, to prosiłbym o dowód czyli model tych wymagań wyrażony w UC.

W UC tego się nie wyrazi.

, ale opis powyższe jest zupełnie bezwartościowy dla programisty (kodera).

Analityk biznesowy musi powyższe zamienić na obiektowy model całej logiki jaka ma być zaimplementowana: model dziedziny systemu.

Właśnie dlatego prosiłem o określenie tematu rozmowy; tak na prawdę mówimy o różnych rzeczach; ja, osobiście, nawet nie jestem pewien swojego (tematu)...

Temat: Procesy, strategie i reguły...

Jakub Wojt:

"Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu."

Zakres projektu dla kogo?

Powyższa definicja z ust Księgowej:
- wystawianie faktur sprzedaży (w załączeniu wzory faktur)
- rejestracja zamówień klientów (w załączeniu przykłady zamówień)
- oprogramowanie ma działać bezawaryjnie (dopuszczamy przerwy trwające do godziny czasu ale nie częściej niż raz w tygodniu)
- wystawione faktury mają być eksportowane do biura księgowego.
- z oprogramowania korzysta wyłącznie księgowa

To jest zakres dla analityka projektanta, w 100% do za modelowania z pomocą diagramu UC

... gdybym bym wredny, to prosiłbym o dowód czyli model tych wymagań wyrażony w UC.

mówisz i masz ;)

W UC tego się nie wyrazi.

???Jarek Żeliński edytował(a) ten post dnia 06.09.12 o godzinie 08:13

Temat: Procesy, strategie i reguły...

Powyższa definicja z ust Księgowej:
- wystawianie faktur sprzedaży (w załączeniu wzory faktur)
- rejestracja zamówień klientów (w załączeniu przykłady zamówień)
- oprogramowanie ma działać bezawaryjnie (dopuszczamy przerwy trwające do godziny czasu ale nie częściej niż raz w tygodniu)
- wystawione faktury mają być eksportowane do biura księgowego.
- z oprogramowania korzysta wyłącznie księgowa

To jest zakres dla analityka projektanta, w 100% do za modelowania z pomocą diagramu UC

... gdybym bym wredny, to prosiłbym o dowód czyli model tych wymagań wyrażony w UC.

mówisz i masz ;)

No i mamy relacje między przypadkami użycia a aktorami.
Po co to się modeluje ?
Podkreślam - nie mamy jasno opisanych UC, mamy relacje między UC a aktorami.

I dlaczego właściwie, nie umieścić wszystkich tych punktów w komentarzach ?
W takim przypadku, to dalej będzie diagram UC.

Temat: Procesy, strategie i reguły...

Jakub Wojt:
Po co to się modeluje ?

tu odpowiedź:
http://it-consulting.pl/autoinstalator/wordpress/2012/...

Temat: Procesy, strategie i reguły...

Jakub Wojt:
Podkreślam - nie mamy jasno opisanych UC,

jak to nie?

Temat: Procesy, strategie i reguły...

Jarek Żeliński:

Jakub Wojt:
Po co to się modeluje ?

tu odpowiedź:
http://it-consulting.pl/autoinstalator/wordpress/2012/...

" Powyższy diagram pozwala sprawdzić, czy mamy właściwie skojarzonych użytkowników z tym jakie czynności będą wykonywali, czy nie ma zdublowanych funkcjonalniej (jajeczka) i nakładających się ról (ludzik, tak zwany Aktor systemu). "

Czyli jak rozumiem, UC pełni funkcje weryfikacyjne. Dobrze.
Po co w takim razie umieszczać je w dokumentacji ? Skoro UC nie przekazuje żadnej informacji, poza tą, że "jest dobrze" to moim skromnym zdaniem powinno się ich używać jedynie podczas tworzenia dokumentacji a z samej dokumentacji powinny takie diagramy zostać wykluczone. "Za dużo" też znaczy "źle".

Czy do jakiejś książki dołącza się słownik, żeby czytelnik mógł sobie sprawdzić, że w tekście nie ma błędów ortograficznych a każde słowo zostało użyte zgodnie ze swoim znaczeniem ?

Temat: Procesy, strategie i reguły...

Jakub Wojt:
" Powyższy diagram pozwala sprawdzić, czy mamy właściwie skojarzonych użytkowników z tym jakie czynności będą wykonywali, czy nie ma zdublowanych funkcjonalniej (jajeczka) i nakładających się ról (ludzik, tak zwany Aktor systemu). "

Czyli jak rozumiem, UC pełni funkcje weryfikacyjne. Dobrze.

ten etap za nami, nawiązanie dalej :)

Po co w takim razie umieszczać je w dokumentacji ? Skoro UC nie przekazuje żadnej informacji, poza tą, że "jest dobrze" to moim skromnym zdaniem powinno się ich używać jedynie podczas tworzenia dokumentacji a z samej dokumentacji powinny takie diagramy zostać wykluczone. "Za dużo" też znaczy "źle".

Kluczowym testem sensu i wartości treści, np. dokumentacji wymagań, są (mogą być, gorąco polecam) tak zwane "widły Hume'a". Czym są owe Widły Hume’a? Każdą wypowiedź (zapis w dokumentacji) należy sprawdzić dwoma pytaniami:
1. Co to znaczy?
2. Skąd to wiesz?

Jeżeli więc napiszę w dokumentacji, że "system ma ...." i tu pojawi się skończona lista wymagań (albo projekt architektury itp.), oraz dołożę do tego zapis: opracowane wymagania są spójne i kompletne, to w "profesjonalnie wykonanej dokumentacji" powinna pojawić się odpowiedź na pytanie Co to znaczy "Spójne i kompletne" a potem na pytanie "Skąd to wiemy".

Na pierwsze pytanie odpowiedź udziela sł. j.polskiego:
spójny «logicznie powiązany, harmonijny, konsekwentny»,
kompletny «taki, w którym nie brakuje żadnego z elementów»

Czy do jakiejś książki dołącza się słownik, żeby czytelnik mógł sobie sprawdzić, że w tekście nie ma błędów ortograficznych a każde słowo zostało użyte zgodnie ze swoim znaczeniem ?

Nie, słowniki są powszechnie dostępne, wystarczy podać którego użyto (Tu SJP, PWN).

Na drugie pytanie odpowiedzią są modele, które jako narzędzia, które posłużyły do wyspecyfikowania wymagań, pokazują "skąd to wiemy, że są spójne i kompletne".

Co do tezy "Za dużo" znaczy "źle", prawda, wymaga jednak uzupełnienia: co to znaczy za dużo. Każdy dobrze opracowany dokument ekspercki to "jedna strona" rekomendacji i załączone "setki stron" ich uzasadnienia (pierwsze czyta każdy, drugie ten kto chce). To uzasadnienie po pierwsze uwiarygadnia rekomendacje po drugie pozwala skorzystać z narzędzia (modeli) do ewentualnej kontynuacji tej pracy (rozwoju systemu).

Tak więc specyfikacja wymagań mogła by mieć postać suchej listy i w zasadzie powinna wystarczyć. Takie dokumenty dostarcza 99% klientów lub ich analityków. Problem pojawia się gdy zadać pytanie: czy wymagania są spójne i kompletne? Jeżeli tak, to "skąd to wiemy"?

A czego się czepiam? Bo jeżeli wymagania nie są "spójne i kompletne" to zachodzi ogromne ryzyko niepowodzenia projektu. Jedynym sposobem minimalizacji tego ryzyka jest to "skąd to wiemy, że są spójne i kompletne"

Podstawowy błąd to twierdzenie w odniesieniu do dokumentacji, że "Less is more". Powinna być na tyle obszerna by wyjaśniała "wszystko" ale nie powinna zawierać żadnych banałów, które można odsiać "Widłami Hume'a". Dobra dokumentacja zawiera dużo informacji ale nie "za dużo" bo to faktycznie źle.Jarek Żeliński edytował(a) ten post dnia 07.09.12 o godzinie 10:55

Temat: Procesy, strategie i reguły...

Kluczowym testem sensu i wartości treści, np. dokumentacji wymagań, są (mogą być, gorąco polecam) tak zwane "widły Hume'a". Czym są owe Widły Hume’a? Każdą wypowiedź (zapis w dokumentacji) należy sprawdzić dwoma pytaniami:
1. Co to znaczy?

To jest głupie pytanie. Wiem, nie nawiązuje do tematu (z drugiej strony - (de facto) go nie ma).

2. Skąd to wiesz?

To dlaczego pytanie o źródła jest niekulturalne ?

Jeżeli więc napiszę w dokumentacji, że "system ma ...." i tu pojawi się skończona lista wymagań (albo projekt architektury itp.), oraz dołożę do tego zapis: opracowane wymagania są spójne i kompletne, to w "profesjonalnie wykonanej dokumentacji" powinna pojawić się odpowiedź na pytanie Co to znaczy "Spójne i kompletne" a potem na pytanie "Skąd to wiemy".

Dla mnie to brzmi jak dokumentacja dokumentująca dokumentację.
Na prawdę są potrzebne takie osobliwe rzeczy i teorie ?

Jeśli tak, to wszystko i tak jest bez sensu ponieważ: dokumentacja dokumentująca dokumentację nie ma "sama dla siebie" dokumentacji.

Może pozostańmy przy po prostu "dokumentacji". Może to nie jest idealne (i przy okazji szalone) - ale przynajmniej, zgodnie z logiką - powinno działać, a UC nie powinno być jej częścią (jeśli UC pełni funkcje "weryfikacyjną")

Na pierwsze pytanie odpowiedź udziela sł. j.polskiego:

ten słownik nie definiuje hasła "rzeczywistość" tzn definiuje ale źle.

Co do tezy "Za dużo" znaczy "źle", prawda, wymaga jednak uzupełnienia: co to znaczy za dużo.

Źle ?
Ok, nie czytam dalej, bo jeszcze wyjdzie, że "za dużo" znaczy "lepiej". Przepraszam.Jakub Wojt edytował(a) ten post dnia 09.09.12 o godzinie 18:05

Temat: Procesy, strategie i reguły...

1. Co to znaczy?

To jest głupie pytanie. Wiem, nie nawiązuje do tematu (z drugiej strony - (de facto) go nie ma).

to bardzo mądre pytanie, weryfikuje czy wiemy o czym piszemy...

2. Skąd to wiesz?

To dlaczego pytanie o źródła jest niekulturalne ?

zależy o czym piszesz, jak ktoś pisze coś od siebie (są tacy co mają swoje zdanie) pytanie o źródła" jest nie tylko niekulturalne ale wręcz głupie...

Dla mnie to brzmi jak dokumentacja dokumentująca dokumentację.
Na prawdę są potrzebne takie osobliwe rzeczy i teorie ?

tak, bo owe 80% złych projektów IT to projekty mające niekompletne wymagania odkryte w trakcie projektu, warto się przed tym zabezpieczyć, przypomnę że nie tylko samoloty najpierw są dokumentowane a potem budowane, nawet domki jednorodzinne za 500 tys. tak się robi, a firmy T budują software za miliony tylko na bazie wizji ....

Jeśli tak, to wszystko i tak jest bez sensu ponieważ: dokumentacja dokumentująca dokumentację nie ma "sama dla siebie" dokumentacji.

nie, to nie prawda, jakiś przykład?

Może pozostańmy przy po prostu "dokumentacji". Może to nie jest idealne (i przy okazji szalone) - ale przynajmniej, zgodnie z logiką - powinno działać, a UC nie powinno być jej częścią (jeśli UC pełni funkcje "weryfikacyjną")

może powinno ale nią działa. Porażkowe projekty są tego dowodem...

Na pierwsze pytanie odpowiedź udziela sł. j.polskiego:

ten słownik nie definiuje hasła "rzeczywistość" tzn definiuje ale źle.

uuu a Ty wiesz jaka jest lepsza definicja? Jaka?

Co do tezy "Za dużo" znaczy "źle", prawda, wymaga jednak uzupełnienia: co to znaczy za dużo.

Źle ?
Ok, nie czytam dalej, bo jeszcze wyjdzie, że "za dużo" znaczy "dobrze". Przepraszam.

a widzisz...

Temat: Procesy, strategie i reguły...

1. Co to znaczy?

To jest głupie pytanie. Wiem, nie nawiązuje do tematu (z drugiej strony - (de facto) go nie ma).

to bardzo mądre pytanie, weryfikuje czy wiemy o czym piszemy...

Sensowniejsze IMHO było by pytanie o użycie / przydatność danej wiedzy / informacji.

Jeśli nie rozumiemy co coś znaczy "od razu" to świadczy o tym, że albo brakuje nam wiedzy, albo autor nie ma nic konkretnego do przekazania. W żadnej w tych sytuacji nie ma sensu zadawać pytania "co to znaczy".

Jak to powiedział kiedyś Wittgenstein: "Nie pytaj o znaczenie, pytaj o użycie"

Dla mnie to brzmi jak dokumentacja dokumentująca dokumentację.
Na prawdę są potrzebne takie osobliwe rzeczy i teorie ?

tak, bo owe 80% złych projektów IT to projekty mające niekompletne wymagania odkryte w trakcie projektu, warto się przed tym zabezpieczyć, przypomnę że nie tylko samoloty najpierw są dokumentowane a potem budowane, nawet domki jednorodzinne za 500 tys. tak się robi, a firmy T budują software za miliony tylko na bazie wizji ....

Ja nigdzie nie podważam sensu analizy i dokumentowania jej wyników.
Twierdzę jedynie, że UC jest do tego nieprzydatne.

Dlaczego wykonanie diagramu UC zabezpiecza przed niekompletnością wymagań / brakiem wyobraźni / kompetencji analityka ?

Jeśli tak, to wszystko i tak jest bez sensu ponieważ: dokumentacja dokumentująca dokumentację nie ma "sama dla siebie" dokumentacji.

nie, to nie prawda, jakiś przykład?

Nie można poprawności "treści" zabezpieczać inną "treścią".
Jeśli to "treść" może być zabezpieczeniem innej treści, to może warto robić kilka poziomów treści "zabezpieczających".

Może pozostańmy przy po prostu "dokumentacji". Może to nie jest idealne (i przy okazji szalone) - ale przynajmniej, zgodnie z logiką - powinno działać, a UC nie powinno być jej częścią (jeśli UC pełni funkcje "weryfikacyjną")

może powinno ale nią działa. Porażkowe projekty są tego dowodem...

Nie działa ponieważ osoby które ją robiły nie miały umiejętności analitycznego myślenia.
UC tutaj niczego nie zmieni ponieważ nie likwiduje przyczyn problemu a jedynie "omija" skutki.

Analogicznie w programowaniu: chyba wiadomo jak się kończy "omijanie problemów" driven development (najczęściej stosowana metodyka w IT, czasem nazywa się to Scrum / Agile / RUP).

Temat: Procesy, strategie i reguły...

Jakub Wojt:
Jak to powiedział kiedyś Wittgenstein: "Nie pytaj o znaczenie, pytaj o użycie"

bardzo kiepski pomysł: "nie ma znaczeni co znaczy chamstwo, szukaj zastosowania"????
(to nie do Ciebie!)

Twierdzę jedynie, że UC jest do tego nieprzydatne.

UC to nie analiza :)

Nie można poprawności "treści" zabezpieczać inną "treścią".

można, każda teza naukowa i jej dowód to treść jedna plus treść druga zabezpieczająca pierwszą

Nie działa ponieważ osoby które ją robiły nie miały umiejętności analitycznego myślenia.

a to inna sprawa :)

Temat: Procesy, strategie i reguły...

Jak to powiedział kiedyś Wittgenstein: "Nie pytaj o znaczenie, pytaj o użycie"

bardzo kiepski pomysł: "nie ma znaczeni co znaczy chamstwo, szukaj zastosowania"????
(to nie do Ciebie!)

http://pl.wikipedia.org/wiki/Cham ;)
Cham to osoba która odnalazła .... ;)

Twierdzę jedynie, że UC jest do tego nieprzydatne.

UC to nie analiza :)

To stwierdzenie mi wystarcza :)

Nie można poprawności "treści" zabezpieczać inną "treścią".

można, każda teza naukowa i jej dowód to treść jedna plus treść druga zabezpieczająca pierwszą

Ciekawy temat: czy teza jest równa swojemu dowodowi ?
Przypominam - zmienne mają swoje określone znaczenie.

Nie działa ponieważ osoby które ją robiły nie miały umiejętności analitycznego myślenia.

a to inna sprawa :)

eh ... chyba sedno problemu ...Jakub Wojt edytował(a) ten post dnia 10.09.12 o godzinie 22:05

Temat: Procesy, strategie i reguły...

troszkę plączesz się a z Biblią przesadziłeś, co do dokumentacji, jej ilości i pracy nad testowaniem hipotez, pozostanę przy tym, że projektowanie to planowanie tego co ma powstać, jeżeli wolisz prace be planowania Twój wybór...

Ilość dokumentacji jaka powstaje zależy od projektu, zaś dobra dokumentacja to dokumentacja podzielona na części adresowane do odpowiednich ludzi (bo nie ma sensu by koder czytał model biznesowy a Zamawiający agregaty modelującego obiekty biznesowe).Jarek Żeliński edytował(a) ten post dnia 11.09.12 o godzinie 13:29

Temat: Procesy, strategie i reguły...

Jarek Żeliński:
troszkę plączesz się a z Biblią przesadziłeś,

chciałem tylko pokazać, że geneza słowa "cham" jest dość zabawna :)
zupełnie abstrahowałem od tematu.

co do dokumentacji, jej ilości i pracy nad testowaniem hipotez, pozostanę przy tym, że projektowanie to planowanie tego co ma powstać, jeżeli wolisz prace be planowania Twój wybór...

Kurcze. Nigdzie czegoś takiego nie powiedziałem. Mam pewne doświadczenia i wiem, że "praca bez planowania" (poza małymi projektami) to po prostu amatorszczyzna. ...

Chciałem jedynie pokazać (nie pamiętam od którego postu), że diagramy UC są generalnie bezużyteczne ...

UC to nie jest planowanie / projektowanie.Jakub Wojt edytował(a) ten post dnia 11.09.12 o godzinie 16:27

Temat: Procesy, strategie i reguły...

Jakub Wojt:

Jarek Żeliński:
troszkę plączesz się a z Biblią przesadziłeś,

chciałem tylko pokazać, że geneza słowa "cham" jest dość zabawna :)
zupełnie abstrahowałem od tematu.

OK

co do dokumentacji, jej ilości i pracy nad testowaniem hipotez, pozostanę przy tym, że projektowanie to planowanie tego co ma powstać, jeżeli wolisz prace be planowania Twój wybór...

Kurcze. Nigdzie czegoś takiego nie powiedziałem. Mam pewne doświadczenia i wiem, że "praca bez planowania" (poza małymi projektami) to po prostu amatorszczyzna. ...

Chciałem jedynie pokazać (nie pamiętam od którego postu), że diagramy UC są generalnie bezużyteczne ...

UC to nie jest planowanie / projektowanie.

A jak nazwiesz listę wymagań funkcjonalnych, zaliczysz ją do planowania a jak nie to do czego? Zakładam, że udokumentowanie zakresu projektu to element planowania....