🚀 go-pugleaf

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