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 w Enterprise Architect

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 - elementy

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.

Diagram utrzymania - przykład

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.

Podobne wpisy
Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia

Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny. W projektach dla mnie ważne więcej

Szacowanie projektu w Enterprise Architect

Szacowanie projektu oraz jego złożoności jest trudne. Istnieją metody, które wspomagają ten proces. Jedną z nich jest metoda  use case więcej

Transformacja PIM-PSM w Enterprise Architect

Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM więcej

Sprawdzanie pisowni w Enterprise Architect – polski słownik

Robiąc projekt piszę szybko i popełniam literówki. Ręczne sprawdzanie wpisów jest kłopotliwe, gdyż domyślnie w Enterprise Architect nie ma zainstalowanego więcej

Reklama
MODESTO - licencje Enterprise Architect

1 komentarz dla “Diagram utrzymania w Enterprise Architect”

  1. Bardzo ciekawy temat. Na codzień pracuje nad rozwojem systemu z kilkunastoletnim stażem. Brakowało mi jednak pomysłu, jak zapanować za pomocą EA, nad zmianami i prowadzić efektywną analizę wpływu zmiany na całość systemu.

    Proszę kontynuację tematu 🙂

Dodawanie komentarzy zostało zablokowane.

Scroll to Top