Aktualizowanie diagramów architektury logicznej i fizycznej

12

W każdym projekcie programistycznym, który obejmuje systemy rozproszone z wieloma programistami, najlepszym rozwiązaniem jest posiadanie diagramów architektury logicznej i fizycznej, ale z mojego doświadczenia wynika, że ​​te diagramy zawsze zaczynają być dobrze utrzymane na początku projektu, ale nie są aktualizowane po wydaniu projektu rozpoczynają się fazy konserwacji.

W przypadku złożonych projektów z wieloma rozproszonymi procesami diagramy stają się bardzo przestarzałe lub niedokładne bardzo szybko, nawet przed pierwszym wydaniem, ponieważ żadna osoba nie ma całej wiedzy.

Biorąc pod uwagę to tło, chcę zadać społeczności następujące pytania:

  1. Jak ważne są dokładne i aktualne diagramy architektury logicznej i fizycznej?
  2. Czy są jakieś narzędzia i procesy, które mogą pomóc w ich aktualizacji?
  3. Kto powinien być odpowiedzialny za ich aktualizowanie? W jaki sposób mogą wnieść swój wkład administratorzy, programiści i zespoły kontroli jakości?
ARau
źródło
Artykuł sugeruje, że powinny one stanowić część „dokumentacji dostarczalnej”, dlatego nadano jej znaczenie. Czy powinny to być przedmioty utworzone w ramach zaległości i powinny stać się częścią dostawy?
ARau

Odpowiedzi:

5

Żyję w realnym świecie z ograniczeniami czasowymi i problemami z zasobami, więc rozumiem, dlaczego większość dokumentacji oprogramowania jest ignorowana lub nieaktualna, ale nawet w tych warunkach absolutnie nalegam, aby diagramy baz danych były tworzone i aktualizowane. Jeśli nie jest to zwykły model relacyjny i składa się z encji z dokumentami, parami klucz-wartość lub struktur JSON / XML, wówczas należy również utworzyć i utrzymywać model obiektowy tych elementów. Jeśli wszystko inne zawiedzie w wysiłkach związanych z dokumentacją projektu, przynajmniej schemat bazy danych i / lub modele obiektowe pozwolą pracować wstecz do frontonu, aby dowiedzieć się, co się dzieje.

Istnieje wiele opcji tworzenia i zarządzania dokumentami oprogramowania, ale jednym z moich ulubionych jest Enterprise Architect. Jest kompleksowy i łączy ze sobą przypadki, diagramy sekwencji, diagramy klas i inne.

Co do tego, kto jest za to odpowiedzialny, uważam to za wysiłek zespołu. Niewiele osób lubi to robić, ale trzeba to zrobić. Architekt lub lider techniczny projektu powinien ostatecznie być za niego odpowiedzialny, odpowiednio delegując zadania.

David Spenard
źródło