🚀 go-pugleaf

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.