🚀 go-pugleaf

On 20 Cze, 11:26, "yapann" <yap...@odwa.pl> wrote:
> reasumując, zaproponuję:
> 1) 'przypadek typu <include>', powinno się raz na zawsze zaminić na
> 'przebieg typu <include>'
> 2) bzdurę (<-według mnie), iż przypadek typu <include> nie może występować
> samodzielnie, należałoby skasować z całego internetu. Na szczęście
> zastosowanie reguły 1) załatwia sprawę.
>
> proszę o Wasze  komentarze do powyższych tez, dzięki.

przeszedłem wszytkie Twoje kometarze i w zasadzie ... witam w
klubie :). Dodał bym tylko tyle: nie lubię przypadków użycia w wersji
ludziki i bąbelki bo to wg, mnie jakaś kulawa atrapa diagramu klas.
Lubie przypadki użycia w rozumieniu scenariuszy zamienianych
ewentualnie z tekstu na diagramy sekwencji (traktuje taka zamianę jako
testowanie logiki słownomuzycznego opisu uzyskanego z wywiadów).

Metoda analizy Catalysis jest tu dobrym przykładem (w zasadzie nie ma
tam mowy o przypadkach użycia).  Doświadczenie moje plus tę metodę
stosuję do wypracowania wymagań metodą: (1) Model procesowy całej
firmy (raczej BPMN bo biznesowi ludzie nie kumają UML'a), (2) na
modelu procesów wybieram z np. zarzadem firmy jej obszar dla którego
planowany jest system, dla każdego tak wybranego procesu biznesowego
określam jego interakcje z planowanych systemem -> mam wymagania
funkjconalne w postaci przypadków użycia, (3) tworzę scenariusze dla
przypadkow użycia (np. opis + tabela lub/i diagramy sekwencji), (4)
model obiektowy firmy (diagram klas, model logiczny danych), (5)
odddaje taki model dalej inżynierom systemowym i programistom.

Nie ma tu miejsca na bąbelki i ludziki. Mój wniosek? zapomnieć o
przypadkach użycia i <<include>>, no troszke radykalny asle...;)