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?
0 komentarze “aw3m #014 Analiza wteczna – jak ogarnąć nieudokumentowany system”
Snowball effect – this is my answer… 😉
W funkcji kolejnych zmian w systemie należy uzupełnić tylko tą cześć dokumentacji, która pozwala ocenić wpływ wprowadzanej zmiany na istniejące assety. Można tu oczywiście przejść przez wszystkie domeny; od biznesu aż po wykon, tylko zastanawiam się, kto za to zapłaci… ?! 🙂
Aby jeszcze obniżyć koszty – nie trzeba uzupełniać szczegółowych opisów (np scenariuszy UC – czasem wystarczy samo 'jajo’). Ważny jest kontekst i świadomość jakie jest otoczenie, a jak będzie sezon ogórkowy – to można wrócić do aptekarstwa.. 😉
Stosując tą przyrostową technikę po jakimś czasie dokumentacja uzupełni się sama, przy okazji koljenych iteracji projektu, koszty można ukryć bo są dużo ,mniejsze dla iteracji, Nie ma chyba nic gorszego niż powiedzieć PMowi, że teraz zamykamy się na pól roku bo będziemy 10 k JIR przenosić do narzędzia CASE żeby zrobić syntezę…. Ja bym nie ryzykował. 🙂