TheTarPit

gdzie ten diabeł?

Całkiem interesujący i generalnie słuszny punkt widzenia analityka systemowego:

W praktyce dokument analityczny charakteryzuje wszystkie procesy, których obsługa jest przewidziana w systemie, na dość dużym poziomie ogólności; wynika to z faktu, że ani nie ma czasu na wchodzenia w mało istotne - z punktu widzenia biznesu - detale oraz - co może ważniejsze - nikt nie jest w stanie nigdy tak przewidzieć wszystkich rzeczy, które zajść mogą, jak i określić wszelkich funkcji, które użytkownikowi mogą okazać się przydatne. W zasadzie więc dokument analizy jest ledwie szkicem tego, co będzie w systemie zaimplementowane.

Łukasz Grabuń

Tam, gdzie tkwi diabeł

Chyba większość praktycznych analityków jak i projektantów systemów informatycznych zgodzi się z powyższym bez szczególnych oporów. Przynajmniej jeśli mowa o zakresie funkcjonalnym systemu... Teoretycy uprą się przy opisaniu funkcjonalności w „ścisły, klarowny i nie pozostawiający miejsca na rozbieżne interpretacje sposób”, ale mniejsza o nich. Spójrzmy na sprawę realnie.

W dalszej części zacytowanego tekstu czytamy:

Jeśli dodamy do tego prototypy [...], uregulowania prawne, listę dokumentów wejściowych i wyjściowych oraz ERD, to możemy powiedzieć, że mamy opisane około 50% funkcjonalności. Reszta [...] regulowana jest przez życie i bieżące potrzeby.

tamże

Jak rozumiem opisane „wystarczająco dobrze”, a nie przesadnie...

szczegół

Rozmowa na temat modelu klas zidentyfikowanych w procesie analizy pewnego systemu jaką kilka dni temu przeprowadziłem z naszym analitykiem:

— na ile ten model klas jest wiążący? np. jeśli napisałaś „Pełna nazwa / Imię Tekstowy(172)” to serio znaczy, że ma być zaprojektowane na 172 znaki?

— model nie jest wiążący, bo to są klasy analityczne, natomiast tam, gdzie jest podana długość znaków, tam ma być zachowana - ma to różne przyczyny, czasem chęć ograniczenia twórczości, czasem wymóg z powodu zarządzeń wewnętrznych itd.

— to 172 to taka ciekawostka w sumie ;-) magic number?

— już nie pamiętam, dlaczego tyle, zdaje się, że sprawdzili to trochę empirycznie na przykładach podmiotów, które mają aktualnie w bazie, a może chcieli mieć tak jak w starym systemie. zgodziłam się, skoro im zależało, a ja nie widziałam w tym nic groźnego dla nas, a w końcu od czasu do czasu musiałam im ustępować i przychylać się do ich zdania

— trochę mnie to zdziwiło - liczba nie okrągła ani dla człowieka ani dla maszyny...

— z pewnością jakiejś okrągłości się tam dopatrzyli, pewnie patrzą dalej (albo bliżej) niż my maluczcy

Dyskutowany dokument analizy powstawał w bólach przez około pół roku, nie mam więc śmiałości polemizować z jego treścią. Jeżeli zawiera takie szczegóły jak „długość pola = 172” to widocznie zostało tu uznane za istotne. „Im zależało”. Zatem wychodzi na to, że nawet jeśli faktycznie opis funkcjonalności jest „rozsądnie uogólniony”, to projekt techniczny i tak musi zawierać kilka zupełnie irracjonalnych szczegółów... :-/ Największy diabeł tkwi w tym, co zostało w cytowanym na wstępie tekście ujęte rozbrajająco prostym „oraz ERD”.

A nawiasem mówiąc — wydaje mi się co najmniej interesujące, że to właśnie funkcjonalność, a nie szczegóły techniczne są tym, co potrafi zrozumieć/docenić analityk jak i decydent szczebla dowolnego zarówno po stronie klienta jak i wykonawcy systemu...

Komentarze