🚀 go-pugleaf

koncepcja przypadkuw uzycia jest ortogonalna do tego czy dotyczyc maja 
funkcjonalnosci czy arhitektury czy tez tego i tego na raz

to w jaki sposub bedzie sie korzystac z koncepcji "przypadku uzycia" zalezy 
od wielu rzeczy. np. przyjetej metodologji. "w ogulnosci" trudno music tutaj 
o jakihs ograniczeniah

generalnei dla kazdego projektu najlepiej dobierac/modyfikowac metodologie 
indywidualnie

a tak naprawde - dla kazdego projektu i wykonawcuw. bo sa np. sytuacje gdy 
wykonwacy jednak wola za kazdym razem tak samo ;p przy pewnej skali tak 
bedzie efektywniej 

hoc oczywiscie najczesciej use cases dotycza funkcjoalnosci

On Fri, 11 May 2007 15:25:26 +0200, "yapann" <yapann@odwa.pl> wrote:

>Użytkownik "radoslaw tereszczuk" <tereszczuk@it1.pl> napisał w wiadomości 
>news:63d79$464463e3
>
>> koncepcja przypadkuw uzycia jest ortogonalna do tego czy dotyczyc maja 
>> funkcjonalnosci czy arhitektury czy tez tego i tego na raz
>ad opcji ostatniej (mieszanej) - czemu służyć ma mieszanie analizy (CO) z 
>projektem (JAK)? Bo chyba nie sprzyja jakości produktu. Jesteś pewien, że 
>jest to w _jakimkolwiek_ przypadku pożądane? Jeśli nie strawiamy pastucha 
>elektrycznego w miejscu, gdzie kończy się opis funkcjionalności a zaczyna 
>projekt rozwiązań, czy można w ogóle mówić o zarządzaniu projektem / 
>produktem w tej sytuacji?Konsekwencją mieszania tych dówch typów jest stan, 
>gdzie twórca PU narzuca (świadomie lub nie) pewne aspekty projektowe - co 
>ogranicza architekta / kodera. Zwracam tu szczególną uwagę na szczególny 
>przypadek, iż analityk nie musi być architektem i w ogóle nie bazować na 
>aspektach strukturalności, mudularyzacji, i innych istotnych na etapie 
>projektowym.

Konczyles Prywatna Szkole Zarzadzania i Informatyki?...

A.L.

Użytkownik "yapann" <yapann@odwa.pl> napisał w wiadomości news:f21r86

>> koncepcja przypadkuw uzycia jest ortogonalna do tego czy dotyczyc maja 
>> funkcjonalnosci czy arhitektury

dodam jeszcze tyle, iż do dokumentacji architektury (rozwiązania projektowe) 
mamy mnóstwo bardziej odpowiednich od PU notacji - diagramy (stanów, 
aktywności, etc). Dokumentacja projektowa przy użyciu PU jest po prostu wg 
mnie ułomna z definicji - nie można jednoznacznie wielu aspektów zawrzeć, 
nie wspominając o spójności. 

Użytkownik "yapann" <yapann@odwa.pl> napisał w wiadomości 
news:f21ssj$a2m$1@nemesis.news.tpi.pl...
> Użytkownik "A.L." <fela@2005.com> napisał w wiadomości
>
>> Konczyles Prywatna Szkole Zarzadzania i Informatyki?...
> nie.

jestem po uczelni techniczej :p - tam się takimi pierodłami nikt nie 
zajmował. :D

Innymi słowy poruszam zagadnienia z autopsji (praca w zespole analizy) i 
zwracam się tu nie tyle po weryfikację nagich podstaw teoretycznych (co 
oczywiście jest wskazane) - co po wiedzę ekspercką w kwestii sensownego 
stosowania ich w praktyce.

> ad opcji ostatniej (mieszanej) - czemu służyć ma mieszanie analizy (CO) z 
> projektem (JAK)?

celem jest produkcja oprogramowania za kture klient zaplaci :O)

zawsze  kazdy przypadek uzycia wiaze sie z wykorzystaniem elementuw 
implementacyjnyh. moziwe sa sytuacje gdy eksplicite myslenie o tym jest do 
czegos potrzebne

przy tworzeniu oprogramowania maja miejsce bardzo ruzne sytuacje, wymagajace 
ruznego rodzaju myslenia. nie zawsze trzeba to "myslenie" formalnei 
zapisywac - czasem warto ;p a to ze jakas metodologia czegos zabarania to 
niekoniecznie sensowny powud

prostym przykladem nieh bedzie kwestia praw dostepu do poszczegulnyh 
elementuw implementacyjnyh przez poszczegulnyh aktoruw

> Bo chyba nie sprzyja jakości produktu. Jesteś pewien, że jest to w 
> _jakimkolwiek_ przypadku pożądane?

tak

> Konsekwencją mieszania tych dówch typów jest stan, gdzie twórca PU narzuca 
> (świadomie lub nie) pewne aspekty projektowe - co ogranicza architekta / 
> kodera.

to tylko jedna z mozliwosci

pewnei ze analityk nie jest od arhitektury

ale nie mozna powiedziec zeby przypadki uzycia nie mogly miec z nia nic 
wspulnego

On Fri, 11 May 2007 16:04:28 +0200, "yapann" <yapann@odwa.pl> wrote:

>Użytkownik "yapann" <yapann@odwa.pl> napisał w wiadomości 
>news:f21ssj$a2m$1@nemesis.news.tpi.pl...
>> Użytkownik "A.L." <fela@2005.com> napisał w wiadomości
>>
>>> Konczyles Prywatna Szkole Zarzadzania i Informatyki?...
>> nie.
>
>jestem po uczelni techniczej :p - tam się takimi pierodłami nikt nie 
>zajmował. :D
>
>Innymi słowy poruszam zagadnienia z autopsji (praca w zespole analizy) i 
>zwracam się tu nie tyle po weryfikację nagich podstaw teoretycznych (co 
>oczywiście jest wskazane) - co po wiedzę ekspercką w kwestii sensownego 
>stosowania ich w praktyce.
>

Zmien prace. Szczerze radze.

A.L.

Użytkownik "A.L." <fela@2005.com> napisał w wiadomości

> Zmien prace. Szczerze radze.
poćwicz dyskutowanie na temat, szczerze radzę. 

Użytkownik "radoslaw tereszczuk" <tereszczuk@it1.pl> napisał w wiadomości 
news:c48d1$46448600

> celem jest produkcja oprogramowania za kture klient zaplaci :O)
celem jest produkcja oprogramowania, za które klient zaplaci i I UTRZYMANIE, 
za które klient zaplaci.

> zawsze  kazdy przypadek uzycia wiaze sie z wykorzystaniem elementuw 
> implementacyjnyh
nie podważam użycia elementów 'implementacyjnych', jeśli nalezy się do 
takich obiektów odnieść, tylko fakt opisywania / projektowania rozwiązań.

> a to ze jakas metodologia czegos zabarania to niekoniecznie sensowny powud
'metodologia' (PU) nie zabrania (nie uniemożliwia) - zagadneiniem jest 
zastosowanie technologii: przeznaczenie PU: co POWINNA modelować, a czego 
nie (w obszarze specyfikacji wymagań systemowych metodą PU)

>> Jesteś pewien, że jest to w _jakimkolwiek_ przypadku pożądane?
> tak
? w jakim?


>> Konsekwencją mieszania tych dówch typów jest stan, gdzie twórca PU 
>> narzuca (świadomie lub nie) pewne aspekty projektowe - co ogranicza 
>> architekta / kodera.
> to tylko jedna z mozliwosci
hmm ... to AŻ jedna z możliwości.


> pewnei ze analityk nie jest od arhitektury
> ale nie mozna powiedziec zeby przypadki uzycia nie mogly miec z nia nic 
> wspulnego
mogą - jeśli się uprzeć, by produkt był słabo rozwijalny, słabo zarządzalny, 
słabo modyfikowalny, słabo skalowalny, etc.

jeszcze raz

koncepcja przypadku uzycia nie jest zadna metodologia

to po prostu narzedzie kturego zastosowanie zalezy od kontekstu

co innego np. diagram przypadku uzycia w konkretnej metodologji << a to jest 
juz bardzo konkretny przypadek

ja pisze ogulnie

przyklad gdy w przypadku uzycia potrzebne jest odwolanie sie do elementuw 
implementacyjnyh podalem w poprzednim poscie 

Użytkownik "radoslaw tereszczuk" <tereszczuk@it1.pl> napisał w wiadomości 
news:a0a65

to nadal nie odpowiada na wyjściowe pytanie: czy elemnety projektowe są 
dopuszczalne w dokumentacji funkcjonalności systemu za pomocą PU.
(i czy PU funkcjonalny oraz PU projektowy nie powinny jawnie nazywać się 'PU 
funkcjonalnym',  czy 'PU projektowym', (w odóżnienia od 'PU 
bezpłciowego/wielopłciowego' - bezużytecznego) co czyni je innym tworem w 
sensie przeznaczenia, mimo że notacja ta sama).


ps:
> koncepcja przypadku uzycia nie jest zadna metodologia
'notacja' będzie dobrze?
> to po prostu narzedzie kturego zastosowanie zalezy od kontekstu
to ja myślałam że narzędzie to co inngo jest, ale mniejsza o to.

On Fri, 11 May 2007 19:18:11 +0200, "yapann" <yapann@odwa.pl> wrote:

>Użytkownik "radoslaw tereszczuk" <tereszczuk@it1.pl> napisał w wiadomości 
>news:a0a65
>
>to nadal nie odpowiada na wyjściowe pytanie: czy elemnety projektowe są 
>dopuszczalne w dokumentacji funkcjonalności systemu za pomocą PU.
>(i czy PU funkcjonalny oraz PU projektowy nie powinny jawnie nazywać się 'PU 
>funkcjonalnym',  czy 'PU projektowym', (w odóżnienia od 'PU 
>bezpłciowego/wielopłciowego' - bezużytecznego) co czyni je innym tworem w 
>sensie przeznaczenia, mimo że notacja ta sama).

Ktos tam u was w firmie sie nudzi

A.L.

koncepcja przypadkuw uzycia jest czyms wiecej niz diagramem przypadkuw 
uzycia z uml

natomiast zawezajac sie do tego o czym zdajesz sie muwic:

w ramah wiekszosci metdologji dokumentowania - masz racje

sa jednak sytuacje gdy warto robic od tego odstepstwa

nie sposub oceniac ogulnie - to akademickie podejscie. do wlasciwej oceny 
potrzebna byla by konkretny kontekst i dokumentacja projektu. ale nawet 
tutaj mozna sie spierac czy cos ma sens czy nie. kwestia wielu rzeczy w tym 
kultury procesu, ludzi (autoruw, korzystajacyh)

> to nadal nie odpowiada na wyjściowe pytanie: czy elemnety projektowe są 
> dopuszczalne w dokumentacji funkcjonalności systemu za pomocą PU

w dokumentacji funkcjonalnosci to nieszczegulnie ;p to oczywiste. tak muwi 
teoria i wiekoszc praktyki

> (i czy PU funkcjonalny oraz PU projektowy nie powinny jawnie nazywać się 
> 'PU funkcjonalnym',  czy 'PU projektowym', (w odóżnienia od 'PU 
> bezpłciowego/wielopłciowego' - bezużytecznego) co czyni je innym tworem w 
> sensie przeznaczenia, mimo że notacja ta sama).

oczywiscie ze warto to rozgraniczyc

>> koncepcja przypadku uzycia nie jest zadna metodologia
> 'notacja' będzie dobrze?

notacja przypadku uzycia to cos o wiele bardziej konkretnego niz koncepcja 
przypadku uzycia jako taka 

radoslaw tereszczuk wrote:

  [CUT]

błagam, włącz sobie sprawdzanie pisowni, oczy mnie bolą od czytania tylu 
błędów ortograficznych jednocześnie

"sg" <alpha@skynet.org.pl_WITHOUT> wrote:

> błagam, włącz sobie sprawdzanie pisowni, oczy mnie bolą od czytania tylu 
> błędów ortograficznych jednocześnie

To akurat od lat nasz grupowy dyzurny dyslektyk :)
(do dzisiaj sie zastanawiam czy faktyczny czy wysmienicie symulujacy
 a w duchu majacy z nas ubaw :)
ale merytoryczna wartosc listow Radoslawa jest tak cenna ze mnie
te bledy nie przeszkadzaja a nawet sa sympatyczne :)
Tak podejdz do sprawy.

AK 

yapann wrote:

> mam wątpliwość odnośnie idei systemowych (nie biznesowych) przypadków
> użycia:
> 
> Otóż generalnie PU służą udokumentowaniu funkcjonalnych wymagań
> systemowych, z punktu widzenia użytkownika i pożądanego skutku (CO - a nie
> JAK (tzw 'czarna skrzynka')).
> 
> W książce 'Writing Effective Use Cases' autorstwa A.Cockburn czytam, iż
> innym, prawidłowym przeznaczeniem PU jest udokumentowanie projektu systemu
> (tzw 'biała skrzynka'): 'team might document the final design with the
> same use case form.'

Być może wcale nie chodzi o dokumentowanie _rozwiązań_ projektowych za
pomocą use-case'ów, a raczej udokumentowanie przypadków użycia, które
są możliwe w zaprojektowanym systemie.
Chodzi np. o sytuację, gdy ktoś sobie wymyślił na początku scenariusz
w wersji X, ale w czasie analizy lub projektowania okazało się, że taki
scenariusz nie uwzględnia jakichś problemów. Na końcu można więc
udokumentować przypadek użycia już zaprojektowanego systemu, żeby
np. tester mógł zaprojektować testy.

-- 
Mariusz Lotko

"radoslaw tereszczuk" <tereszczuk@it1.pl> writes:

> koncepcja przypadkuw uzycia jest ortogonalna do tego czy dotyczyc
> maja funkcjonalnosci czy arhitektury czy tez tego i tego na raz

Nie jest ortogonalna.

>> celem jest produkcja oprogramowania za kture klient zaplaci :O)
>
> Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.

a jaka widzisz ruznice ?

bardzo to ciekawe

pewnie hodzi o to ze nie ma materialnyh efektuw

hehe na tej samej zasadzie mozna muwic ze np. muzyki sie nie produkuje ale 
opracowuje ;pppp tyle ze w przypadku muzyki norma jezykowa jest "produkcja"

w przypadku oprogramowanie nie jestem juz taki pewien jaka jest norma 
jezykowa. a napewno mnie to specjalnei nie interesuje i jest tematem czysto 
zastepczym 

"yapann" <yapann@odwa.pl> writes:

> Użytkownik "yapann" <yapann@odwa.pl> napisał w wiadomości 
> news:f21ssj$a2m$1@nemesis.news.tpi.pl...
>> Użytkownik "A.L." <fela@2005.com> napisał w wiadomości
>>
>>> Konczyles Prywatna Szkole Zarzadzania i Informatyki?...
>> nie.
>
> jestem po uczelni techniczej :p - tam się takimi pierodłami nikt nie
> zajmował. :D

Ja też kończyłem techniczną i wiem na pewno, że przypadki użycia nie
są ortogonalne do funkcji.

"yapann" <yapann@odwa.pl> writes:

> Użytkownik "A.L." <fela@2005.com> napisał w wiadomości
>
>> Zmien prace. Szczerze radze.
> poćwicz dyskutowanie na temat, szczerze radzę. 

Na temat już dostałeś odpowiedź.

"yapann" <yapann@odwa.pl> writes:

> Użytkownik "yapann" <yapann@odwa.pl> napisał w wiadomości
> news:f21r86
>
>>> koncepcja przypadkuw uzycia jest ortogonalna do tego czy dotyczyc
>>> maja funkcjonalnosci czy arhitektury
>
> dodam jeszcze tyle, iż do dokumentacji architektury (rozwiązania
> projektowe) mamy mnóstwo bardziej odpowiednich od PU notacji -
> diagramy (stanów, aktywności, etc). Dokumentacja projektowa przy
> użyciu PU jest po prostu wg mnie ułomna z definicji - nie można
> jednoznacznie wielu aspektów zawrzeć, nie wspominając o spójności.

Ale wiesz, że to, co piszesz, to jest trochę od rzeczy?

hehe no ale jak juz pisze na temat zastepczy to moge go zbadac

a wiec norma wydaje sie byc "produkcja"

przynajmniej norma jezyka w sieci

http://www.google.pl/search?hl=pl&q=%22produkcja+oprogramowania%22&btnG=Szukaj&lr=

"produkcja oprogramowania" - 43 200

http://www.google.pl/search?hl=pl&q=%22opracowanie+oprogramowania%22&btnG=Szukaj&lr=

"opracowanie oprogramowania" - 557

z mojej strony eot

"radoslaw tereszczuk" <tereszczuk@it1.pl> writes:

>> ad opcji ostatniej (mieszanej) - czemu służyć ma mieszanie analizy
>> (CO) z projektem (JAK)?
>
> celem jest produkcja oprogramowania za kture klient zaplaci :O)

Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.

sg <alpha@skynet.org.pl_WITHOUT> writes:

> radoslaw tereszczuk wrote:
>
>   [CUT]
>
> błagam, włącz sobie sprawdzanie pisowni, oczy mnie bolą od czytania
> tylu błędów ortograficznych jednocześnie

Można sobie napisać filtr :>

""Piotr Dembiński"" <pdemb@gazeta.pl> wrote:

> Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.

Sie produkuje
Sie sprzedaje
Sie zarabia
Sie produkuje..

AK

On Sun, 13 May 2007 20:15:03 +0200, pdemb@gazeta.pl (Piotr Dembiński)
wrote:

>"radoslaw tereszczuk" <tereszczuk@it1.pl> writes:
>
>>> ad opcji ostatniej (mieszanej) - czemu służyć ma mieszanie analizy
>>> (CO) z projektem (JAK)?
>>
>> celem jest produkcja oprogramowania za kture klient zaplaci :O)
>
>Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.

W przedszkolu?

A.L.

A.L. wrote:

> On Sun, 13 May 2007 20:15:03 +0200, pdemb@gazeta.pl (Piotr Dembiński)
> wrote:
> 
>>"radoslaw tereszczuk" <tereszczuk@it1.pl> writes:
>>
>>>> ad opcji ostatniej (mieszanej) - czemu służyć ma mieszanie analizy
>>>> (CO) z projektem (JAK)?
>>>
>>> celem jest produkcja oprogramowania za kture klient zaplaci :O)
>>
>>Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.
> 
> W przedszkolu?

Nie wiem po co ta złośliwość. Fakt, że w "w przemyśle" mówi się
o produkcji oprogramowania nie oznacza, że jest to poprawne stwierdzenie.
Produkcja kojarzy mi się nieodmiennie z taśmą produkcyjną do _gotowego_
produktu. W przypadku softu - byłby to chyba tylko etap: wypal na płytkę
i wsadź do pudełka.
To, co zwykło się nazywać produkcją softu, czyli to co robimy my,
projektanci-programiści jest raczej projektowaniem, a może nawet
(boję się tego powiedzieć) prototypowaniem. Bo tak naprawdę, soft,
który jeszcze nie przeszedł testów akceptacyjnych jest tylko prototypem.

-- 
Mariusz Lotko

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

> Ale wiesz, że to, co piszesz, to jest trochę od rzeczy?
a nie wiem, bo jeszcze nie uzasadniłeś.

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości 
news:f28p0f$h52

> Nie wiem po co ta złośliwość.
niektórzy mają tak zaimplementowane, nic nie zrobisz.

> Produkcja kojarzy mi się nieodmiennie z taśmą
spotkałam się w skelpie z terminem 'Cytryny wyprodukowane w ..."

> soft,
> który jeszcze nie przeszedł testów akceptacyjnych jest tylko prototypem.
jestem _przekonana_, ze prototyp jest kompletnie czymś innym, ale 
mniejsza.Jest takie piękne powiedzenie, że gdzie brak argumentów, tam odzywa 
się ona - argumentacja. Więc nie plumkać na tematy nie przynoszące pieniędzy 
(a jak ktoś widzi potrzebę, to kysz do odrębnego wątku).
:] 

Użytkownik "Adam Karpierz" <karpierz@NOOOOSPAAAAMpython.pl> napisał w 
wiadomości

> grupowy dyzurny dyslektyk :)
z dwojga złego lepsze to niż bezmyślność
> ale merytoryczna wartosc listow Radoslawa jest tak cenna ze mnie
niech więc tak będzie, póki tylko stosowne proporcje ilościowo-jakościowe 
zostaną zachowane :]

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości

>> 'team might document the final design with the
> Być może wcale nie chodzi o dokumentowanie _rozwiązań_ projektowych za
> pomocą use-case'ów, a raczej udokumentowanie przypadków użycia, które
> są możliwe w zaprojektowanym systemie.
zapewne, aczkolwiek nadal będzie to ALBO walidacja (czy tam kolejna 
iteracja) analizy funkjonalnej i udokumentowanei zmian, ALBO dokumentacja 
rozwiązań danego zagadnienia, co należałoby zaznaczyć literalnie, imo. Po 
co?  A po to na przykład, żeby było przełożenie na testy funkcjonalne i te 
pozostałe (niefunkcjonalne, statyczne, i takie tam). Komentarze?

> żeby
> np. tester mógł zaprojektować testy.

Użytkownik "yapann" <yapann@odwa.pl> napisał w wiadomości

>> Być może wcale nie chodzi o dokumentowanie _rozwiązań_ projektowych za
czarne na białym jak byk stoi, że jednym z przeznaczeń PU może być 
"..document the final design..", z czym po dalszych przemyśleniach coraz 
trudnije mi się zgodzić, z racji na prosty argument, iż są ku temu lepsze 
notacje. 

"radoslaw tereszczuk" <tereszczuk@it1.pl> writes:

>>> celem jest produkcja oprogramowania za kture klient zaplaci :O)
>>
>> Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.
>
> a jaka widzisz ruznice ?

Ilościowo rzecz biorąc, to jest różnica jednej sylaby.

> bardzo to ciekawe
>
> pewnie hodzi o to ze nie ma materialnyh efektuw

Pewnie też.

> hehe na tej samej zasadzie mozna muwic ze np. muzyki sie nie
> produkuje ale opracowuje ;pppp tyle ze w przypadku muzyki norma
> jezykowa jest "produkcja"

Zawsze myślałem, że kompozycja. 

A.L. <fela@2005.com> writes:

[...]

>>Mnie uczono, że oprogramowanie się opracowuje, a nie produkuje.
>
> W przedszkolu?

Prawie -- na drugim roku studiów :)

"yapann" <yapann@odwa.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości
>
>> Ale wiesz, że to, co piszesz, to jest trochę od rzeczy?
> a nie wiem, bo jeszcze nie uzasadniłeś.

'Przypadki użycia nie dokumentują rozwiązań projektowych.
Dokumentacja rozwiązań projektowych przy użyciu przypadków 
użycia jest niepełna.'

Inna sprawa, że można rozumieć architekturę tak, jak sprzętowcy,
czyli jako zestaw sprzęgów systemu z jego otoczeniem.  Wówczas
diagramy przypadków użycia mogłyby stanowić część dokumentacji
architektury systemu.

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

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

> 'Przypadki użycia nie dokumentują rozwiązań projektowych.
> Dokumentacja rozwiązań projektowych przy użyciu przypadków
> użycia jest niepełna.'
co/kogo cytujesz, jeśli mógłbyś wskazać

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

>> w przypadku muzyki norma
>> jezykowa jest "produkcja"
> Zawsze myślałem, że kompozycja.
Zawsze będą idealiści ;) 

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości
> Zawsze myślałem, że kompozycja.
Zawsze będą idealiści ;]. 

yapann wrote:

> Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości
> 
>>> 'team might document the final design with the
>> Być może wcale nie chodzi o dokumentowanie _rozwiązań_ projektowych za
>> pomocą use-case'ów, a raczej udokumentowanie przypadków użycia, które
>> są możliwe w zaprojektowanym systemie.
> zapewne, aczkolwiek nadal będzie to ALBO walidacja (czy tam kolejna
> iteracja) analizy funkjonalnej i udokumentowanei zmian, ALBO dokumentacja
> rozwiązań danego zagadnienia, co należałoby zaznaczyć literalnie, imo. Po
> co?  A po to na przykład, żeby było przełożenie na testy funkcjonalne i te
> pozostałe (niefunkcjonalne, statyczne, i takie tam). Komentarze?

Tak. Właśnie po to, żeby tester miał odniesienie do rzeczywistego przypadku
użycia, tzn. takiego z jakim będzie pracował użytkownik, a nie takiego
niedopracowanego z początku zastanawiania się "co to my chcemy zrobić".

-- 
Mariusz Lotko

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości 
news:f2bn06

> Tak. Właśnie po to, żeby tester miał odniesienie do rzeczywistego 
> przypadku
> użycia, tzn. takiego z jakim będzie pracował użytkownik, a nie takiego
> niedopracowanego z początku zastanawiania się "co to my chcemy zrobić".

nie znajduję w tym odpowiedzi na zacytowane przez ciebie moje pytanie/a, być 
może będe musiała sprecyzować je inaczej. Natomiast poproszę o rozwinięcie 
tego, co napisałeś, gdyż co rozumiem dotąd z tego, to truizm, iż PU powinien 
być aktualny i wystarczająco szczegółowy, by służył za podstawę miarodajnego 
testu.
Innymi słowy nie zajmujemy się tym , czy PU jest 'rzeczywisty' 
(świeży/kompletny/ukończony/odzwierciedla docelowe wymaganie) - w 
postawionym przeze mnie problemie istotne jest to, że PU jako dokument 
wymagań f. będzie podstawą do testy systemowego (/ akceptacyjnego), podczas 
gdy PU jako dokument rozwiązań byłby podstawą dla wytworzenia jakiegoś testu 
rozwiązania (zapewne typu biała-skrzynka), i nalezy to literalnie 
rozdzielić, nazwać i nie mieszać pod żadnym pozorem, ale może ja źle 
rozumuję?

(że nie wspomnę poprzednio wypowiedzianej wątpliwości - jaki niby test mam 
utworzyć na podstawie PU dokumentującego zarówno funkjonalność jak i 
rozwiązania?)


ps:
Może się mylę, ale jeśli to, co chcemy zrobić zmienia się po zrobieniu tego, 
znaczy że robimy coś innego. Wymaganie nie powinno ulec zmianie z powodu 
jego realizacji (bądź powinno ulec walidacji w iteracyjnym procesie). 

"yapann" <yapann@odwa.pl> writes:

> Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał
> w wiadomości
>
>> 'Przypadki użycia nie dokumentują rozwiązań projektowych.
>> Dokumentacja rozwiązań projektowych przy użyciu przypadków 
>> użycia jest niepełna.'
> co/kogo cytujesz, jeśli mógłbyś wskazać

W taki sposób zrozumiałem to, co napisałeś/napisałaś.

yapann wrote:

> Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości
> news:f2bn06
> 
>> Tak. Właśnie po to, żeby tester miał odniesienie do rzeczywistego
>> przypadku
>> użycia, tzn. takiego z jakim będzie pracował użytkownik, a nie takiego
>> niedopracowanego z początku zastanawiania się "co to my chcemy zrobić".
> 
> nie znajduję w tym odpowiedzi na zacytowane przez ciebie moje pytanie/a,
> być może będe musiała sprecyzować je inaczej. Natomiast poproszę o
> rozwinięcie tego, co napisałeś, gdyż co rozumiem dotąd z tego, to truizm,
> iż PU powinien być aktualny i wystarczająco szczegółowy, by służył za
> podstawę miarodajnego testu.
> Innymi słowy nie zajmujemy się tym , czy PU jest 'rzeczywisty'
> (świeży/kompletny/ukończony/odzwierciedla docelowe wymaganie) - w
> postawionym przeze mnie problemie istotne jest to, że PU jako dokument
> wymagań f. będzie podstawą do testy systemowego (/ akceptacyjnego),
> podczas gdy PU jako dokument rozwiązań byłby podstawą dla wytworzenia
> jakiegoś testu rozwiązania (zapewne typu biała-skrzynka), i nalezy to
> literalnie rozdzielić, nazwać i nie mieszać pod żadnym pozorem, ale może
> ja źle rozumuję?

PU jest tworzony na początku w celu udokumentowania wymagania
funkcjonalnego. Z uwagi na to, że model kaskadowy tworzenia oprogramowania
zdaje się być wyparty przez model iteracyjny, PU jak wszystko w projekcie
będzie ewoluował. Stąd zapewne sugestia, że (ostatecznie)
odzwierciedla "final design".
I z drugiej strony: PU to nie jest coś, co tworzymy na początku, żeby mieć
punkt zahaczenia i jak już zahaczymy, to o nim zapominamy. Design powinien
być taki, że na końcu wszystkie PU przedstawiają użycie systemu, który
jest efektem "final design". Nie może być żadnych niezgodności.

Nie szukałbym raczej możliwości udokumentowania wprost architektury
systemu czy innych szczegółów implementacyjnych za pomocą PU. Owszem, jakiś
przypadek użycia może część rozwiązań narzucić (choćby "nieświadomie").
Ba! Wszystkie PU razem wzięte na pewno zasugerują "jakieś rozwiązania".
W końcu po to są robione.

Co do truizmów: być może tak to brzmi, bo jest to proste jak 5gr, a Ty się
uparłaś, żeby to komplikować ;-)

> (że nie wspomnę poprzednio wypowiedzianej wątpliwości - jaki niby test mam
> utworzyć na podstawie PU dokumentującego zarówno funkjonalność jak i
> rozwiązania?)

"Przypadek _użycia_". Jego nazwa mówi wszystko. Wprost się nim rozwiązań
implementacyjnych nie dokumentuje. Są od tego inne narzędzia, wygodniejsze.
I już. Żadnej filozofii.

> ps:
> Może się mylę, ale jeśli to, co chcemy zrobić zmienia się po zrobieniu
> tego, znaczy że robimy coś innego. Wymaganie nie powinno ulec zmianie z
> powodu jego realizacji (bądź powinno ulec walidacji w iteracyjnym
> procesie).

Czym poza zestawem znaków ASCII różnią się w Twoim kontekście "zmiana"
i "ulegnięcie walidacji w iteracyjnym procesie"?
BTW, samo słowo "walidacja" sugeruje raczej sprawdzenie, czyli taką
operacje read-only, a u Ciebie to brzmi jakby walidacja coś zmieniała.

-- 
Mariusz Lotko

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

>>> 'Przypadki użycia nie dokumentują rozwiązań projektowych.
>>> Dokumentacja rozwiązań projektowych przy użyciu przypadków
>>> użycia jest niepełna.'

> W taki sposób zrozumiałem to, co napisałeś/napisałaś.

zatem demetuję:
'Przypadki użycia MOGĄ dokumentować rozwiązania projektowe,
aczkowiek Dokumentacja rozwiązań projektowych przy użyciu przypadków użycia 
jest niepełna, gdyż notacja nie jest przystosowana do reprezentacji wielu 
aspektów typowych dla rozwiązań projektowych, (podczas gdy świetnie 
wystarcza do reprezentacji wymagań f. udziałowców/użytkowników),  Ponieważ 
więc niektórych aspektów nie da się zamodelować / udokumentować, w efekcie 
więc dekumentacja projektowa będzie niedeterministyczna.

Poszukuję jakiegokolwiek uzasadnienia, kiedy miałabym w ogóle użyć PU w 
takim celu i nie widzę żadnego, za to same wady.

(nawet potrzeba przestawienia pewnych aspektów projektowych nieiżynierowi / 
nieinformatykowi (na przykład udziałowcom biznesowym), może przebiegać przy 
użyciu okrojonej (na dany użytek) stosownej notacji. Jeśli bowiem jest 
jakakolwiek potrzeba rozmowy z laikiem w obszarze zagadnień projektowych - 
to jakieś minimum pojęć służących abstrakcji zagadnień można i trzeba od 
niego wymagać i bardziej zaawansowane notacje nadal będą bardziej użyteczne, 
zwykle moożna je uogólnić tak by wskazać jedynie isotne szczegóły, jak np. 
uwarunkowania jakiegoś przebiegu, podział na podjednostki obiektu czy 
procesu, czy inne projektowe sprawy).

Dopóki nie znajdę takiego zastowania - uznaję użycie PU do dokumentowania 
projektu, jako stratę prądu. 

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości

> PU jest tworzony na początku w celu udokumentowania wymagania
> funkcjonalnego. Z uwagi na to, że model kaskadowy tworzenia oprogramowania
> zdaje się być wyparty przez model iteracyjny, PU jak wszystko w projekcie
> będzie ewoluował.
TRUE

> Stąd zapewne sugestia, że (ostatecznie)
> odzwierciedla "final design".
FALSE. Najdalsze uszczegóławnianie wymagania (CO) kończy się w punkcie, gdy 
zaczynamy opisywać rozwiązania (JAK).
> I z drugiej strony: PU to nie jest coś, co tworzymy na początku, żeby mieć
> punkt zahaczenia i jak już zahaczymy, to o nim zapominamy. Design powinien
> być taki, że na końcu wszystkie PU przedstawiają użycie systemu,
TRUE

> który
> jest efektem "final design".
FALSE. który jest efektem "final analysis".
(PU ewoluje z niezdarnego PU do dojrzałęgo i zwalidowanego, a nie z PU do 
projektu).

> Nie może być żadnych niezgodności.
TRUE


> Nie szukałbym raczej możliwości udokumentowania wprost architektury
> systemu czy innych szczegółów implementacyjnych za pomocą PU.
unikałabym jak ognia.

> Owszem, jakiś
> przypadek użycia może część rozwiązań narzucić (choćby "nieświadomie").
> Ba! Wszystkie PU razem wzięte na pewno zasugerują "jakieś rozwiązania".
nie powinny. Po to właśnmie by całym majdanem zarządzać. By zmiana rozwiązań 
nie musiała implikowac zmiany kształtu wymagań. (Oczywiście rozumiem co 
chciałeś przekazać, ta granica może być dyskusyjna, i jedn uzasadni że to 
jest już designm, a inny że jeszcze nie, ale chodzi o wyznaczeni założeń, 
które powiedzieć powinno: TU wymaganie, a TU rozwiązanie.



> Co do truizmów: być może tak to brzmi, bo jest to proste jak 5gr, a Ty się
> uparłaś, żeby to komplikować ;-)
mam bardzo szybki komplikator :-), z deoptymalizatorem


> "Przypadek _użycia_". Jego nazwa mówi wszystko. Wprost się nim rozwiązań
> implementacyjnych nie dokumentuje.
dyć do tego zmierzam, w ramach iż w tak dobrej wg mnie książce, którą 
zacytowałam, takie niechrześciajńskie podszepty znalazłam


> Czym poza zestawem znaków ASCII różnią się w Twoim kontekście "zmiana"
> i "ulegnięcie walidacji w iteracyjnym procesie"?
uściślam: 'Wymaganie nie powinno ulec zmianie na COŚ INNEGO (tu: projekt) z 
powodu jego realizacji - może za to (i powinno) ulec walidacji, nadal 
utrzymujac granice, 'których przektroczyć nie wolno'.


> BTW, samo słowo "walidacja" sugeruje raczej sprawdzenie, czyli taką
> operacje read-only, a u Ciebie to brzmi jakby walidacja coś zmieniała.
kazanie przyjęte. 

On Tue, 15 May 2007 16:41:04 +0200, "yapann" <yapann@odwa.pl> wrote:
 
>> Stąd zapewne sugestia, że (ostatecznie)
>> odzwierciedla "final design".
>FALSE. Najdalsze uszczegóławnianie wymagania (CO) kończy się w punkcie, gdy 
>zaczynamy opisywać rozwiązania (JAK).
>> I z drugiej strony: PU to nie jest coś, co tworzymy na początku, żeby mieć
>> punkt zahaczenia i jak już zahaczymy, to o nim zapominamy. Design powinien
>> być taki, że na końcu wszystkie PU przedstawiają użycie systemu,
>TRUE
  

Pytam z ciekawosci: czy oprocz rozwazania owych wysoce
skomplikowanych, filozoficznych, a abstrakcyjnych problemow, twoja
firma ROWNIEZ zajmuje sie produkcja oprogramowania i robieniem
pieneidzy?...

Znalem taka firma ktore tak sie wdala w podobne rozwazania, ze
zapomniala iz obiecala klientowi zrobic projekt, i na skutek tego
zbankrutowala z trzaskiem i swedem.

A moze ty piszesz parce magisterska i zbierasz materialy?...

A.L.

"yapann" <yapann@odwa.pl> writes:

[...]

> 'Przypadki użycia MOGĄ dokumentować rozwiązania projektowe,

OK.

"yapann" <yapann@odwa.pl> writes:

[...]

> Ponieważ więc niektórych aspektów nie da się zamodelować /
> udokumentować,

Zawsze można się spierać co do tego, czy aspekty wymagań, których nie
można udokumentować, są istotne z punktu widzenia przedsięwzięcia.

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

>> 'Przypadki użycia MOGĄ dokumentować rozwiązania projektowe,
> OK.
ale nie powinny. 

Użytkownik ""Piotr Dembiński"" <pdemb@gazeta.pl> napisał w wiadomości

>> Ponieważ więc niektórych aspektów nie da się zamodelować /
>> udokumentować,
> Zawsze można się spierać co do tego, czy aspekty wymagań, których nie
> można udokumentować, są istotne z punktu widzenia przedsięwzięcia.

jak cię nie stać na samochód, to nie potrzebujesz się przemieszczać :]
po1. nigdzie nie stwierdzono, że 'nie można', tylko że 'PU nie dają rady'.
po2. mowa była nie o dokumentowaniu wymagań, ale o tym drugim szczególnym 
zastosowaniu PU - dokumentowaniu projektu.

'reszta' się zgadza.. 

Użytkownik "A.L." <fela@2005.com> napisał w wiadomości

> Pytam z ciekawosci: czy
mylisz pojęcia.To twoje pytanie jest filozoficzne.
(rozważania na temat zasadności poszukiwania rozwiązania tego zagadnieni - 
również.)
- > ot, ntg.
Nie mam budżetu na zaspokojenie Twojej ciekawości, ale możesz negocjować.


> skomplikowanych, filozoficznych, a abstrakcyjnych
cała matematyka i wiele nauk opartych nań obfituje w zagadnienia ścisłe, 
całkowicie abstrakcyjne.