Hierarchizacja funkcji - redagowanie dokumentu

Witam

Chciałbym zaczerpnąć rady/ oceny co do nowo tworzonego osobiście projektu na razie niewielkiego systemu do wymiany usług. Na obecna chwilę rozpisuję funkcjonalność względem przepływu danych oraz encji. Natomiast nie do końca jestem pewien czy w dobry sposób tworzę hierarchię funkcji biorąc pod uwagę, że rozpisujemy ją do funkcji elementarnych. Tak więc na jak bardzo drobne elementy powinienem funkcje rozdzielić. Wiem, że w sieci jest nieco przykładów aczkolwiek inaczej pokazują to podręczniki inaczej ludzie w praktyce jako ,,nazwa funkcji()""

Na razie rozpisałem sobie 2 punkty ze spisu wymagań.

Jak z każdym diagramem musisz zadać sobie pytanie: kto będzie adresatem i co ma z niego wyciągnąć? Ten diagram jest dziwny, bo nie przypomina niczego znanego z UML, najbliżej mu chyba do activity diagram, ale jest skomplikowany zawiera za dużo szczegółów implementacyjnych. Do tego brakuje aktorów

slsy napisał(a):

Jak z każdym diagramem musisz zadać sobie pytanie: kto będzie adresatem i co ma z niego wyciągnąć? Ten diagram jest dziwny, bo nie przypomina niczego znanego z UML, najbliżej mu chyba do activity diagram, ale jest skomplikowany zawiera za dużo szczegółów implementacyjnych. Do tego brakuje aktorów

Adresatem ma być przede wszystkim użytkownik serwisu. Na razie starałem się rozbić większe ogólne funkcje na mniejsze bez modelu przypadków użycia. Chyba, że powinienem to opisać bardziej jako model działa firmy, poszczególne procesy. poza tym zachodzi pytanie co można uznać za funkcje elementarną.

Wygląda jak poplątany use case diagram z UML'a Nie rozumiem dlaczego tworzysz jakiś własny standard.

Diagram jest skrajnie nieczysty, w różnych fragmentach strzałka pokazuje co innego
czynnośc koniecznie następująca w sekwencji
czynnosc opcjonalną, ale ew kończącą sekwencję (obie jakby wizard)
cz. opcjonalną do wyboru (jedyna wyrażona jako menu)

Skoro podobno to ma być dla uzytkownika, to (może) myśla kategoriami "menu", "wizard" itd...

Miesza czynności wyższego stopnia abstrakcji (obsługa hasła) i niskiego rzędu (odczytanie z pól)

Co do czynnosci .. dawno się pożegnałem z wizją wylistowania wszystkich czynności z góry - raczej staram sie mieć przemyślany mechanizm "jak dodawać czynności bez szkody dla systemu".
I róznież na poziomie UI wydaje mi sie, to nadal jest swoista struktura obiektowa, czynnosci nad kontem użytkownika", "czynności nad komuniaktem"

piotrpo napisał(a):

Wygląda jak poplątany use case diagram z UML'a Nie rozumiem dlaczego tworzysz jakiś własny standard.

Nie tworzę nowego standardu tylko staram się rozłożyć ogólnie funkcje systemu na drobniejsze jako iż hierarchia funkcji jest jednym z elementów narzędzi modelowania strukturalnego. Tak jak i diagramy przepływu danych czy też diagramy encji. Po prostu bardziej szczegółowo graficzne opisane wymagania funkcjonalne. Może graficznie niezbyt dobrze to wyglądać aczkolwiek staram się zrozumieć w jaki sposób dojść do funkcji elementarnej.

Co na wzór tego : http://jjakiela.prz.edu.pl/dhf.htm

Ok, rozumiem. W takim razie wydajesz się mieszać hierarchię tych funkcji z ich składowymi. Nie znam tej metodyki analizy wymagań. Co powiesz na coś takiego?

--edit
Jeżeli chcesz użyć hierarchii, to mi dobrze sprawdzały się narzędzia typu FreeMind, Freeplane. Ich obsługa jest na tyle szybka, a wynik na tyle intuicyjny, ze można zebrać kilku ekspertów razem, rzucić na ścianę i na bieżąco aktualizować.

piotrpo napisał(a):

Ok, rozumiem. W takim razie wydajesz się mieszać hierarchię tych funkcji z ich składowymi. Nie znam tej metodyki analizy wymagań. Co powiesz na coś takiego?

--edit
Jeżeli chcesz użyć hierarchii, to mi dobrze sprawdzały się narzędzia typu FreeMind, Freeplane. Ich obsługa jest na tyle szybka, a wynik na tyle intuicyjny, ze można zebrać kilku ekspertów razem, rzucić na ścianę i na bieżąco aktualizować.

Drugi z diagramów który podlinkowałeś bardziej mogę utożsamić z tym o co mi chodziło. Zastanowiłem się głębiej na funkcjonalnością i zmieniłem koncepcje na opis faktycznie funkcjonującej firmy/portalu trochę to sobie rozpisując. Zastanawiam się trochę czy nie lepiej takie rzeczy rozpisywać sobie na brudno na kartce i wtedy wersja ostateczna w dokumentacji która będzie stanowić podstawę do budowy fizycznego oprogramowania. Nie wiem jak w praktyce działa to w firmach. Mam nadzieje, że ten model wygląda bardziej klarownie.

strike

delform_17 napisał(a):

piotrpo napisał(a):

Ok, rozumiem. W takim razie wydajesz się mieszać hierarchię tych funkcji z ich składowymi. Nie znam tej metodyki analizy wymagań. Co powiesz na coś takiego?

--edit
Jeżeli chcesz użyć hierarchii, to mi dobrze sprawdzały się narzędzia typu FreeMind, Freeplane. Ich obsługa jest na tyle szybka, a wynik na tyle intuicyjny, ze można zebrać kilku ekspertów razem, rzucić na ścianę i na bieżąco aktualizować.

Drugi z diagramów który podlinkowałeś bardziej mogę utożsamić z tym o co mi chodziło. Zastanowiłem się głębiej na funkcjonalnością i zmieniłem koncepcje na opis faktycznie funkcjonującej firmy/portalu trochę to sobie rozpisując. Zastanawiam się trochę czy nie lepiej takie rzeczy rozpisywać sobie na brudno na kartce i wtedy wersja ostateczna w dokumentacji która będzie stanowić podstawę do budowy fizycznego oprogramowania. Nie wiem jak w praktyce działa to w firmach. Mam nadzieje, że ten model wygląda bardziej klarownie.

Rozumiem, aczkolwiek Twoim zdaniem rozpisać to jako model działania określonej firmy(ostatni screen)czy typowe funkcje systemu(menu) ?

@delform_17: Nie cytuj samego siebie :)

A odnoście pytania - zależy co rozpisujesz. Jeżeli piszemy o inżynierii wymagań, to ten diagram ma ci pomóc (?) zrozumieć czym się zajmuje firma. Nawet zakładając, że mają jakiegoś wielkiego kloca, który w całości obejmuje jej działalność, to menu w tej aplikacji jest jedynie efektem głuchego telefonu pomiędzy tym co ktoś tam powiedział, analityk zrozumiał, programista błędnie zaimplementował. Lepiej korzystać z oryginału.

Czyli z tego co zrozumiałem hierarchizacja funkcji, diagramy w których ustalamy przepływ danych,tworzenie encji etc. jest bardziej modelem funkcjonowania firmy natomiast to co wcześnie opisywaliście tutaj Przypadki użycia, diagramy klas, diagram komponentów są elementami tworzonymi przez developerów na podstawie modelu działania firmy. Więc jeśli budujemy aplikacje która wspomaga podatnika w tworzeniu np deklaracji zaczynamy od diagramów klas i przypadków użycia(software dla mas).
Jeśli mówimy o aplikacji dla firmy produkcyjnej tworzymy model jej funkcjonowania co niestety jest takie łatwe ubrać w odpowiednie słowa, a dopiero później tworzymy model systemu.

Wiem, że pewnie teraz trochę powtarzam to co już tutaj padło, ale chce dobrze zrozumieć w praktyce zagadnienie aby w przyszłości nie popełniać błędów i nie marnować na siłę czasu na coś co jest od podstawy źle utworzone. .

Marginesem co sądzicie o narzędziu Visual Paradigm, warty uwagi ?

@delform_17: Za bardzo koncentrujesz się na narzędziach, za mało na problemie, który chcesz rozwiązać. Po co chcesz zrobić ten diagram? Chcesz zrozumieć działanie firmy, zaprojektować działanie systemu dla tej firmy, będziesz za jego pomocą rozmawiał z biznesem, dostawcami, programistami?

Problemem było tutaj utworzenie przykładowego np diagramu przepływu danych odnoszącego się do wybranego narzędzia dla usera, ale obecnie wyłącznie jako ćwiczenie. Sądziłem iż przy pomocy diagramu przepływu czy hierarchi funkcji będę w stanie opisać teoretyczne działanie aplikacji dla firmy lub pojedynczego użytkownika, aby w późniejszym czasie napisać na bazie tego funkcjonalne narzędzie(system).

Również dobrze mógłbym rozpocząć opisywać działanie firmy działającej w spedycji. Dlatego też pytam, aby mieć jasność co już wcześniej piotrpo zaznaczyłeś. Te diagramy z początku posta są narzędziami analityka w momencie budowania modelu działania przedsiębiorstwa. Na tym więc utworzonym przez analityka modelu developer projektuje już system który jest rozwiązaniem problemu usprawnienia działania firmy.

Tworze taki diagram aby móc w praktyce zrozumieć jak i w jakim celu pisze się takie rzeczy.

@delform_17: Ja widzę to inaczej. Dla mnie diagram (jakikolwiek) to sposób na usprawnienie komunikacji, wygodniejszy niż słowa sposób na przedstawienie jakiegoś zagadnienia, albo narzędzie które pomaga mi zrozumieć jakiś tam fragment rzeczywistości. Dlatego tworzenie jakiegoś diagramu, żeby zrozumieć do czego on może się przydać jest z mojego punktu widzenia bezproduktywne i raczej nie da się wiele z tego wyciągnąć. Podobnie jak z ćwiczenia "poużywam trochę młotka, żeby zobaczyć do czego może się przydać".
Jeżeli mówimy o procesie projektowania aplikacji, mającej wspierać jakiś proces biznesowy, to trzeba ten proces biznesowy zrozumieć, diagramy bywają często pomocnym narzędziem w tym rozumieniu. Można użyć gotowych typów diagramów, bo one dają gotowy język. Jeżeli autor i odbiorca diagramu mają zrozumienie czym np. różni się "extends" od "uses" w takim use case diagram, to oszczędzą masę czasu na uzgadnianiu własnego języka. Pod warunkiem, że potrzebują o tym rozmawiać. Jeżeli nie potrzebują, to stracą jedynie czas.

W diagramie, który przygotowałeś, najbardziej przeszkadza mi to, że nie mogłeś się zdecydować na to co chcesz przedstawić i mocno pomieszałeś poziom szczegółowości. Jeżeli przedstawiasz "punkt widzenia użytkownika", to "zapis w bazie danych" jest głęboko schowanym detalem. Jeżeli to ma być dokumentacja dla programisty, to gdzie jest nazwa tabeli w której trzeba to hasło zapisać/sprawdzić, sposób jego zapisu (jakaś tam sól, i złożoność algorytmy haszującego). Truizm, ale albo opisujesz coś na wysokim poziomie, w dużym uproszczeniu, albo szczegółowo na niższym poziomie. Są też narzędzia pozwalające łączyć (linkować) ze sobą diagramy.