No cóż, temat się w rozmowach powtarza, jest nie łatwy więc kilka słów. Pomijając narzędzie, którym się tu posłużę, chodzi o “pryncypia” :): bezpieczeństwo projektu oraz zarządzaniem wersjami, zmianą, w tym wymaganiami.

Zarządzanie zmianą

Po pierwsze wydaje mi się, że chyba najlepszym sposobem na zarządzanie wersjami, zmianami, śledzeniem projektu itp. są wypracowane mechanizmy znane każdemu kto korzysta(ł) z takich narzędzi do zarządzania projektami jak SVN ([[Subversion]]) czy [[CVS]]. Chodzi o coś co się nazywa: znaczniki, gałęzie, wersje.

Projekt ma tak zwaną linie główną (baseline, trunk). Jednak w trakcie prac nad projektem warto czasem stworzyć “odnogę” projektu. Pozwala to po pierwsze wydzielić “podprojekt” (gałąź) dla zespołu by panować nad zmianami w taki sposób, by jeden zespół na etapie projektowania nie zakłócał pracy drugiego. W dowolnym momencie można porównać oba projekty i nawet je scalić.

W efekcie mamy możliwość rozdzielenia pracy dwóch (lub więcej) zespołów nad jednym projektem. Po drugie nawet, jeżeli analityk sam pracuje nad projektem, ma możliwość testowania swoich pomysłów bez “psucia” zasadniczego projektu. Po takich pracach można projekt zostawić i scalić to co wyszło najlepiej.

Jak widać jeden projekt może mieć także znaczniki (tagi). Załóżmy, że pracujemy na projektem, mającym etapy rozwoju. Wtedy np. oddajemy dokumentację w wersji np. 1.0 i pracujemy dalej. Aby później możliwe było porównanie wersji obecnej z wersją “wypuszczoną” wcześniej, wystarczy odwołać się do oznaczonej takim znacznikiem wersji (zwanej w slangu Rewizją ;))  i prześledzić różnice jak poniżej:

Na bieżąco, możemy śledzić kto i kiedy co załadował na serwer, cofnąć się do wcześniejszej wersji by porównać efekty pracy różnych członków zespołu, albo pracując samemu, porównać pomysły nowe z wcześniejszymi i wybrać najlepszy.

Kopia bezpieczeństwa

Bardzo ważne jest to, że nasz komputer nie był jedynym miejsce przechowywania projektu. Tu uwidacznia się zyskana “przy okazji” cecha pracy z serwerami kontroli wersji: nie tylko zarządzają wersjami ale także przechowują kopie naszych projektów.  Panujemy więc nad wszystkim, mamy dodatkowo kopię bezpieczeństwa.

Narzędzia kompatybilne z SVN pracują w trybie off-line client-server, wiec są bardzo wygodne bo nie obciążają sieci i pozwalają pracować bez dostępu do niej co nie raz jest wygodne. Scalanie wersji jest bezpieczne, wszelkie konflikty wersji (wykryte zmiany po stronie serwera i po naszej) są od razu monitowane, mamy możliwość świadomego ich rozwiązywania.

Na zakończenie

Na koniec dodam, że niektórzy dostawcy poszerzają możliwości swoich narzędzi (np. moje, tu opisywane) i pozwalają na wersjonowanie nie tylko pliku z projektami UML czy BPMN (że nie wspomnę o kodzie projektu), ale także pozwalają na skojarzenie z projektem folderu na dysku i wtedy cała jego zawartość, w szczególności  pliki pdf od klienta, dokumentacja w plikach word, rtf, notatki itp. podlega powyższym mechanizmom zarządzania (wersjonowanie i kopia bezpieczeństwa).

Czemu o tym pisze? Bo mnie pytają klienci i nie tylko :). Czy to ważne? Tak! Tak prowadzony projekt jest bardzo bezpieczny, szczególnie gdy serwer projektu jest hostowany w bardzo dobrze administrowanej, bezpiecznej serwerowni a pliki są szyfrowane podczas transferu. Efektywność pracy w takim trybie jest także dużo większa.

Tak więc gorąco polecam pracę z SVN (i innymi podobnymi) i narzędzia CASE kompatybilne z nim. Zainteresowanych powyżej opisanym narzędziem TWS zapraszam tu: http://www.visual-paradigm.com/product/vpts/provides/management.jsp