Diagram utrzymania w Enterprise Architect

Bardzo często myśląc o inżynierii oprogramowania myśli się o wytwarzaniu oprogramowania. A co z jego utrzymaniem, rozwojem? O tym nie mówi się zbyt wiele. Sam UML czy BPMN nie są wystarczające by zarządzać zamianą. Jak to zrobić?

Enterprise Architect jest narzędziem, które w miarę kompleksowo stara wspomóc procesy związane z inżynierią oprogramowania. W obszarze szeroko rozumianego zarządzania zmianą oferuje byty, którymi można opisać defekty, zagadnienia, zmiany. Innymi słowy można zamodelować w Enterprise Architect obszar zmian i utrzymania systemów. Szereg z tych elementów można znaleźć na diagramie utrzymania (Maintenance Diagram).

Diagram utrzymania jest diagramem, który pozwala mi na prezentację (mapowania) wpływu zidentyfikowanych defektów czy zagadnień na poszczególne elementy.

Diagram utrzymania – elementy

Znaczenie poszczególnych elementów:

• Zmiana (Change) – jeśli do wdrożonego już systemu, jest zgłaszana potrzeba zmiany to element ten jest idealny do tego by nazwać tą zmianę i w kilku zdaniach opisać czego ona dotyczy. Zmiany kolekcjonuję w odpowiednim pakiecie – takim swoistym rejestrze zmian. Mają one swoje statusy. Na diagramie utrzymania mapuję zmianę na komponenty, przypadki użycia, interfejsy a czasem na poszczególne klasy.
• Zagadnienie (Issue) – odpowiada niespełnieniu wymagań dla bieżącego systemu z powodu nowo powstałych czynników. Dla mnie to doskonały element do prezentacji luki, która powstaje po wprowadzeniu zmiany. Luka obrazuje różnicę pomiędzy stanem docelowym (po zmianie) a stanem obecnym (przed zmianą). Zagadnienie nie jest wymaganiem a raczej opisem tego czym różni się stan docelowy od stanu obecnego. Często też używam tego elementu by zaznaczyć temat do omówienia z interesariuszami. Wynik wspomnianej rozmowy, to zadania lub wymagania.
• Defekt (Defect) – odpowiada niespełnieniu wymagań dla bieżącego systemu z powodu usterki w modelu, systemie lub procesie. Innymi słowy to element o oznaczania błędu. Stosuję go bardzo rzadko odnośnie systemu, gdyż w organizacjach defekty zgłasza się zazwyczaj w takich narzędziach jak JIRA. Nie mniej jednak Enterprise Architect daje możliwość oznaczania błędów, które można przypisać do innych elementów takich jak przypadki użycia czy komponenty. Defekt powinien zawierać w komentarzu informacje o usterce i środkach podjętych w celu jej usunięcia.
• Zadanie (Task) – to element, który wykorzystywany jest do zaznaczenia a raczej zdefiniowania pracy, jaką trzeba wykonać w celu zbadania lub rozwiązania zagadnienia, czy usterki. Można utworzyć hierarchię lub strukturę drzewa z elementów zadania. W ten sposób można podzielić duże zadanie na mniejsze części i przypisać do tych mniejszych części elementy, których zadanie dotyczy.

Diagram utrzymania – przykład

Zaletą stosowania tych elementów jest możliwość użycia ich na dowolnym diagramie. Każda zmiana, zagadnienie czy defekt można połączyć z innymi elementami modelu w projekcie, aby zilustrować, w jaki sposób byty te przyczyniają się lub mają wpływ zmapowany element. Co więcej każdy z tych elementów ma pasek stanu na lewym końcu, który jest kodowany kolorem, aby wizualnie przedstawiać wartość pola Status we właściwościach elementu. W ten oto sposób można wskazać aktywne lub rozwiązane defekty, zagadnienia czy zadania.

Na powyższym przykładzie powstałą zmiana Dodanie obsługi paragonów niefiskalnych. Zmiana ta wpływa na na przypadek użycia Przekazanie parametrów zamówienia. W związku z tą zmianą powstało zagadanienie Minimalny zakres danych dla paragonu niefiskalnego. Powstało także zadanie Rozszerzyć scenariusz główny o paragon niefiskalny. Zadanie to dotyczy zmiany we wskazanym relacją realizacji – przypadku użycia.

Reasumując. Zastosowanie, opisanych powyżej, elementów pochodzących z diagramu utrzymania zapewnia szeroki zakres zarządzania zmianami, defektami i zagadnieniami. Pozwala na wizualizację problemu i jego rozwiązywania za pomocą powiązanych elementów. Ponadto można wskazać za pomocą powiązań wpływ wspomnianych artefaktów na byty z modeli opisujących oprogramowanie lub procesy biznesowe.

Reklama