Enterprise Architect w służbie GAMP5

Czas czytania: 20 min.

Na końcu artykułu znajduje się plik do pobrania.

Jeśli chcesz stworzyć oprogramowanie wspierające obrót produktami leczniczymi to musi być ono zwalidowane po stronie dostawcy, jak i po strony klienta, który je zamówił. Artykuł poświęcam stronie dostawcy oprogramowania. Pokażę jak przy użyciu narzędzia typu CASE zaprojektować nowy produkt informatyczny, w której uzyskamy także część dokumentów walidacyjnych pod kątem GAMP5. Zaznaczę, że w artykule nie będę poruszał co to jest GAMP5 i jakie są jego poszczególne etapy walidacji.

Klasyczne podejście firmy developerskiej to wytworzenie oprogramowania w taki sam sposób jak przy wcześniejszych projektach nie związanych z farmacją, a następnie aktywowanie sztabu ludzi, którzy stworzą do niego walidację w metodzie GAMP5. Takie podejście dla mnie jest wysoce nieefektywne z kilku powodów:

  1. Duży nakład pracy – projektujemy oprogramowanie, developujemy, testujemy, a następnie wracamy do początku, aby praktycznie przejść jeszcze raz tą samą ścieżkę tylko pod kątem wytworzenia dokumentów walidacyjnych, których wymaga klient.
  2. To nie jest sexy – tworzenie dokumentacji walidacyjnej post produkcyjnie jest po prostu nudne. Nikt nie chce tego robić.
  3. Utrzymanie dokumentacji  walidacyjnej –  utrzymywanie dokumentacji walidacyjnej w którymś z edytorów tekstu (np. Word) w żaden sposób nie wspiera wersjonowania. Jest duże ryzyko,  walidacja i oprogramowanie nie utrzymają spójności po kilku sprintach. Całość się rozjedzie, co wyjdzie klientowi na jego testach UAT, czy walidacyjnych PQ1.

Znamy już dziedzinę problemu. Czas na lekarstwo. Jak to zrobić szybko i przyjemnie, żeby wykonana praca miała dodatni wpływ na proces wytwarzania. Użyjemy do tego celu narzędzia typu CASE: Enterprise Architect firmy Sparx Systems. (W dalszej części artykuły będę stosował skrót EA). To MUSI BYĆ SEXI, aby zespół IT zamiast się demotywować widział, że to co robi ma rzeczywisty wpływ na projekt.

— Zaczynamy –

Niezależnie, czy pracujesz waterfall’owo, czy którąś z metod Agile, całość pracy projektowej trzymaj w jednym narzędziu. Kiedy już masz narzędzie, stwórz jedną, spójną zasadę lub zestaw zasad jak projektować efektywnie w narzędziu Enterprise Architect. Stwórz standaryzację pracy w narzędziu projektowym typu CASE, a otrzymasz w zamian poprawnie zaprojektowane rozwiązania oraz dużą część dokumentów walidacyjnych, jakie są wymagane przy oprogramowaniu wykorzystywanym w szeroko pojętej farmacji.

Jakie dokumenty pod GAMP 5 możesz wygenerować automatycznie stosując zaproponowany w tym artykule standard pracy?

Poniższy schemat „V” wzbogaciłem tak, aby obrazował dwa dodatkowe aspekty:

  1. Wykaz wszystkich dokumentów należy dostarczyć przy oprogramowaniu dla szeroko pojętej farmacji.
  2. Na czerwono zaznaczyłem dokumenty, które dzięki narzędziu Enterprise Architect (skrót: EA) możesz wygenerować praktycznie bezkosztowo, stosując projektowanie oprogramowania zgodnie z moją propozycją.

Zestaw zasad jak projektować efektywnie w narzędziu Enterprise Architect

Konstrukcja katalogów

Poniżej przedstawiłem Ci podstawowy układ katalogów, który wykorzystuje przy praktycznie każdym  projekcie. Oczywiście w trakcie uszczegóławiania projektu można zejść niżej do budowania diagramów klas, albo zacząć od architektury systemu. Ja w tym artykule skupię się na elementach, które powstają na etapie projektowania rozwiązania, i bezpośrednio się przekładają na proces walidacyjny GAMP5. Zaczynamy od stworzenia w EA drzewa katalogów z typowymi dla danego katalogu diagramami.

  • Doc. URS, który otrzymujemy od klienta. Czasami nazywa się go Brief’em lub po prostu BR.

NOTA: Przeważnie otrzymujemy go w Wordzie, ale możemy uprzedzić klienta wysyłając mu template w pliku Excel. Import wymagań przygotowanych w pliku Excel jest znacznie szybszy niż ręczne go przepisywanie. Polecam.

  • Procesy biznesowe w BPMN
  • UseCase
  • Dokumenty
  • Interfejsy graficzne – GUI

Masz już stworzoną strukturę katalogów. Dzięki temu, wiesz już jak agregować poszczególne elementy użyte do projektowania. Katalog „Dokumentacja” możemy dodać na późniejszym etapie projektowania. Przyda się on na etapie generowania dokumentacji do plików płaskich (np. Word)

Numeracja elementów

Pamiętaj, aby każdy element zaczynał się od unikalnego numeru. Najlepiej jak zastosowana numeracja jest w łatwy sposób wymawiana i zapamiętywana.

Przykład: Numeracja UseCase
Dziedzina funkcjonalna „Przyjmowanie dostawy”.
Numeracja może wyglądać następująco: „UPD_01, UPD_02, UPD_03, itd”.
U – UseCase, PD – Przyjmowanie dostawy.

Przykład: Numeracja URS
Rozdział dokumentu URS: „Generalne wymagania”
Numeracja wymagań: GEN_001, GEN_002, GEN_003, itd.

Statusy elementów

UseCase jak i wymagania z URS muszą posiadać statusy. Bez nich nie będziesz wiedział, czy dany UseCase jest już zaimplementowany oraz, czy dane wymaganie klienta przedstawione w URS są już zrealizowane. Moja propozycja:

UseCase Wymagania z URS
– Nowy
– Zaprojektowany
– Zaimplementowany
– Odrzucony
– Nowy
– Zrealizowany
– Odrzucony

Połączenia między elementami

Bardzo ważne w EA są połączenia między elementami. Nie tylko kierunek połączenia, ale także typ samego połączenia.

Przykład:
Takie połączenie:

To nie zupełnie inne połączenie:

To, w jaki sposób zbudujesz połączenia, będzie miało bezpośredni impakt na generowanie dokumentacji. Konstrukcja projektowania rozwiązania w AE, czyli jakich elementów używasz, jak je łączysz między sobą i w jakich katalogach przechowujesz jest bardzo silnie skorelowane z konstrukcją template, których użyjesz do tworzenia wersji papierowej swojej pracy. Ważne, że kiedy ustalisz jedną koncepcję projektowania w EA musisz ją konsekwentnie stosować w danym projekcie.

Moja propozycja stosowania relacji między elementami:

Dzięki powyższym wskazówkom z jednej strony możesz poprawnie projektować nowe rozwiązanie informatyczne, a z drugiej strony, w każdej chwili będziesz mógł wygenerować wersję papierową dokumentów zaznaczonych na kolor czerwony na schemacie „V” znajdującym się na samym początku artykułu. Aby to zrobić musisz mieć przygotowany jedynie template do generowania dokumentacji z EA.

Template do generowania dokumentacji

Jeśli projektowałeś rozwiązanie zgodnie z powyższymi wskazówkami to jest to bardzo dobry materiał dla developerów i wygenerowania dokumentacji walidacyjnej. Pytanie jakie się nasuwa to: Jak to zrobić? Dostępne template w EA są mało przejrzyste, a na pewno nie spełniają standardów GAMP5. Odpowiedź jest prosta. Musimy napisać swoje template i to kilka, w zależności, od danych jakie chcemy uzyskać.

Ilość dokumentów jaką chcemy wygenerować:

  • FS
  • Protokół OQ, który potem zostanie wypełniony danymi z testów
  • Protokół PQ, który potem zostanie wypełniony danymi z testów
  • Macierz FS x URS

Opcjonalnie możemy jeszcze wytworzyć dokument „Glosariusz”, czyli nomenklaturę specyficznych słów użytych w projekcie, ale to nie jest wymóg GAMP5.

Jedna z dróg otwarcia interfejsu do tworzenia template w EA: Zaznacz okno „Project Browser” >  kliknij „F8” > przycisk „Open Template”

Okno do projektowania template już z gotowym template pod UseCase.

Okno do projektowania template już z gotowym template pod Protokołu PQ0.

Generowanie dokumentacji

Po stworzeniu poprawnej konstrukcji projektu oraz zaprojektowaniu template masz kilka możliwości generowania dokumentacji np.:

  1. Stworzenie dedykowanego katalogu ze specjalnym diagramem umożliwiającym dopasowywanie template do wielu katalogów
  2. Wybór katalogu z drzewa w Project Browser oraz template, w zależności jakie dane potrzebujesz.

W obu przypadkach efekty są takie same, czyli dokumentacja w wersji elektronicznej z możliwością edycji w takich programach jak np.: Word.

W artykule opiszę wersję nr 2.

  1. Zaznacz katalog w Project Browser i kliknij F8
  2. Wybierz z rozwijanej wcześniej utworzony template
  3. Kliknik przycisk „Generate”

EA daje pełną paletę możliwości konfiguracji i filtracji, ale to już temat na inny artykuł.

Podsumowanie

Moim celem było zaprezentowanie Ci pewnej metody projektowania w EA, dzięki której nie tylko stworzysz świetny produkt, na którym można bazować przy implementacji rozwiązania, ale także wygenerujesz serię dokumentów, niezbędną przy wdrażaniu rozwiązania w obszarze farmaceutycznym. Mam nadzieje, że mi się udało i wskazówki w nim zawarte pomogą Ci w dalszej pracy.



2 Replies to “Enterprise Architect w służbie GAMP5

  1. Świetny artykuł. Wiele czytałam o GAMP5 i używam Enterprise Architect w pracy, ale jeszcze nie widziałam możliwości połączenia tego w całość. SUPER

Dodaj komentarz

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