aw3m #014 Analiza wteczna – jak ogarnąć nieudokumentowany system

2 czerwca 2019

Jak ogarnać istniejący, nieudokumentowany system, kiedy musimy go zmieniać, utrzymywać, rozwijać, a dokumentacji brak i nie wiadomo jak działa? Kilka kroków, które pomogą Ci zrobić inżynierię wsteczną.

Analiza interfejsu

Przejrzyj system. Zobacz jakie ma zakładki, przyciski, jakie akcje są możliwe, jakie są wartości statusów. Wydedukuj co w tym systemie można robić? Jakie funkcjonalności są dostępne? Kto może wykonywać które czynności?

Przykładowo – w systemie do zarządzania urlopami widzę zakładki “Plan urlopowy”, “Moje wnioski urlopowe”, itd. Widzę przyciski “Złóż wniosek”, “Zmień plan urlopowy”, itd. Wnioski mają statusy “zatwierdzony”, “anulowany”, “odrzucony”, itd.

Diagram przypadków użycia UML

Na pytanie “Co to robi?” odpowiedz diagramem przypadków użycia UML. Zobacz jak go narysować: https://www.youtube.com/watch?v=yFVIBQcEl3w

Przykładowo – Pracownik może wykonać przypadki użycia “Przeglądaj plan urlopowy”, “Złóż wniosek”, “Zmień wniosek”, itd. Przełożony może wykonać akcje “Przeglądaj wnioski”, “Zaakceptuj wniosek”, “Złóż wniosek na pracownika”.

Grupy / role użytkowników

Poszukaj w interfejsie wskazówek jakie są grupy/role użytkowników. Może wyświetla się to gdzieś? Może znajdziesz to w bazie danych? A może pomoże Ci developer?

Przykładowo – w systemie zarządzania urlopami mamy role: pracownik, przełożony, administracja/hr, zarząd. Po co zarząd? A co robi tu zarząd? Może trzeba dodać jakiś przypadek użycia? Mogą przeglądać raporty? Muszę się o nich więcej dowiedzieć.

Interesariusze, procesy, cele, wymagania

Kto korzysta z tego systemu? Skoro już wiesz, spotkaj się z tymi osobami. Zapytaj czy mogą robić w systemie to, co pokazuje Twój diagram przypadków użycia, czy może coś więcej/mniej? Czy wiedzą o jeszcze innych użytkownikach? Jakie oni mają opcje?

Skoro już rozmawiasz z interesariuszami, dowiedz się jak wygląda proces biznesowy. Jak wykonują czynności krok po kroku tak w ogólne, pomijając korzystanie z jakichkolwiek systemów? Narysuj proste diagramy BPMN najważniejszych procesów, żebyś lepiej zrozumiał dziedzinę.

Dlaczego właściwie powstał ten system? Jakie cele ma spełniać? Spróbuj dokopać się do celów biznesowych. Miał coś uprościć, przyspieszyć?

Czy coś jest problematyczne w systemie? Może dowiesz się też czegoś o wymaganiach jakościowych?

Przykładowo – idąc do pracownika, przełożonego i administracji/hr dowiesz się jak w tej firmie działa proces zarządzania urlopami – jak wygląda ich składanie, zatwierdzanie, itd. Dowiesz się, że system miał skrócić czas pracowników spędzany na zajmowaniu się urlopami i zapewnić spójne raportowanie czasu pracy w zakresie nieobecności urlopowych. Wymagania jakościowe to m.in. obsługa 700 pracowników i zgodność z aktualnym prawem pracy.

Struktura systemu

Zastanów się jakie kategorie informacji znajdziesz w systemie? Na jakie komponenty możnaby go podzielić? Narysuj bardzo prosty diagram komponentów UML. Z takim szkicem idź do architektów i deweloperów powierdzić swoje domysły. Będą mieli bazę do skomentowania. Pamiętaj, że interesują Cię najpierw tylko ogólniki – nie wchodźcie za bardzo w szczegóły techniczne, bo zaciemni to obraz na tym etapie.

Czy ten system współpracuje z jakimś innym systemem firmy lub spoza firmy? Jakich danych potrzebuje? Jakie przesyła? Przygotuj zarys interfejsów. Potwierdź z architektem i developerami. A może mają już gotowy materiał dla Ciebie?

Przykładowo – system zarządzania urlopami może składać się z modułów: urlopy i wnioski, reguły prawa pracy, itd. Do działania potrzebują danych pracowników z firmowego systemu. Wysyłają informacje o urlopach do sstemu rejestracji czasu pracy.

Zachowanie systemu

Jak ten system działa w środku, w szczegółach? Możesz to opisać diagramami aktywności, diagramami sekwensji UML, itd. Nie wszystko odczytasz z interfejsu użytkownika, np. jakim wzorem jest coś wylicznane. Poproś dewelopera, żeby zajrzał do kodu. Zadawaj mu pytania, uzupełniaj dokumentację, rysuj diagramy.

Przykładowo – pokaż jak system do zarządzania urlopami komunikuje się z innymi na diagramie sekwencji w procesie składania i zatwierdzania wniosku. Opisz jak wygląda obliczanie przysługujących dni urlopowych oraz jakie reguły prawa pracy są weryfikowane.

Minimalistycznie i iteracyjnie

Wiesz już, że brak dokumentacji nie był dobry, bo mieliście problemy ze zmianą, utrzymaniem i rozwijaniem systemu. Na początku zbierz informacje na dużym poziomie ogólności. Jeśli będzie potrzeba (coś jest kluczową funkcjonalnością systemu lub za chwilę będziemy coś zmieniać i potzrebujemy zrozumieć jak to działa i dlaczego), doprecyzowuj. Będziesz mieć już ogólną bazę, więc wszystkie bardziej szczegółowe informacje znajdą swoje właściwe miejsce (poddiagram, podkatalog, podstronę) i nie powinieneś się już pogubić.

Powodzenia 🙂 Daj znać jak idzie?

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020