🚀 go-pugleaf

On 11 Maj, 13:56, "yapann" <yap...@odwa.pl> 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.'
>
> Budzi to moją ogromną wątpliwość o tyle, iż na stronie ibm czytam, że PU
> systemowy ma dokumentować zachowanie systemu, nie projektować system:
>
> 'System use cases elaborate the system requirements. The purpose of the
> system use-case model is to document requirements from a stakeholder's
> perspective, not to design how to satisfy the requirements.'
> (http://www-128.ibm.com/developerworks/rational/library/apr07/english/).
>
> Jakkolwiek pozornie nie ma problemu (jedno drugiemu nie przeszkadza, niechby
> PU były środkiem wyrazu dla różnych perspektyw pewnych rzeczy), to nigdzie
> nie ma mowy o tym, że należy wskazać, czy dany PU dokumentuje wymagania
> użytkownika (CO), czy też dokumentuje projekt systemu (JAK), co jest
> (powinno chyba być) absolutnie rozłączne (???) - brak takiej informacji może
> moim zdaniem prowadzić w krzaki. W szczególnośći spotykam się z analitykami
> tworzącymi hybryd wymienionych dwóch zastosowań, często nieświadomi tego
> faktu, co poważnie podważa w moich oczach użyteczność / zastosowanie
> powstałych PU.
>
> Czy ktoś mógłby się wypowiedzieć odnośnie poruszonego przeze mnie problemu
> systematyki PU?

Moje doświadczenie mówi mi, że:
- PU najlepiej sprawdzają sie jako dokumentowanie wymagań
funkcjonalnych, jednak ich lista powinna powstać na bazie analizy
bzinesowej (np. procesów bzinesowych) co praktycznie gwarantuje, że
nie "odkryjemy" czegoś dopiero w trakcie projektu (widac to np. w
opisach korzsci jakie daje SOA), po drugie nie polecam pracy nad PU
metodą zaczynającą się od wywiadów z użytkownikami bo powstanie lista
pobożnych i niespójnych życzeń.
- sama aplikację wydaje mi sie , lepi opisać metodami obiektowymi
(klasy, diagramy stanów, przejść itrp.)
 - nie mylić modelu danych z diagramem klas (który jednak może
posłużyć do tworzenia diagramu ERD)

Ale potwierdzam, że nie ma chyba idealnej reguły i modelwoać powinno
sie każdy projekt metodą dobrana indywidualnie do projektu bo czym
innym jest pisanie rozbudowanego sterownika a czym innym programu do
fakturowania.