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

  • Podkarpackie modelowanie Kolejny raz okazało się, że duży potencjał jest ukryty także poza dużymi ośrodkami takimi jak Warszawa, Kraków czy Gdańsk. O Wrocławiu nie wspominając. Tym razem miałem okazję i […]
  • Rola: Mistrz Scrum (Scrum Master) Mistrz Scrum (ang. Scrum Master) odpowiada za zapewnienie tego, aby Zespół Scrum żył wartościami i praktykami Scrum czyli innymi słowy on nadzoruje sposób wykorzystania metodyki. Mistrz […]
  • Modelowanie zagrożeń – praktycznie W poprzednim artykule Modelowanie zagrożeń - teoretycznie przedstawiłem założenia do przygotowania modelu zagrożeń. W tym artykule zaprezentuję jak za pomocą Enterprise Architect […]
  • Zabezpieczenie aplikacji ASP.NET przy użyciu mechanizmów bezpieczeństwa Forms Artykuł opublikowany na Codeguru.pl Z zabezpieczeniami aplikacji webowych spotykamy się prawie przy każdej okazji, gdy logujemy się do dowolnego serwisu internetowego. Dzięki temu […]
  • Dokumentacja wymagań Pozyskane wymagania należy opisać w dokumencie wymagań. Niniejszy post rozpoczyna cykl wpisów dotyczących dokumentacji wymagań.  Definicja: Dokument wymagań / Specyfikacja […]
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 🙂

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry