Bardzo ważną funkcją jest kontrola dostępu do przechowywanych informacji. W ten sposób eliminuje się przypadkowe zmiany w projekcie oraz utratę integralności. Poprzez ochronę realizuje się wcześniej opisaną zasadę zamrażania wersji historycznych. W środowisku ALS istnieją dwa sposoby zabezpieczeń: określenie użytkowników, którzy mają prawo czytać, poprawiać lub uruchamiać zasób oraz określenie narzędzi, za pomocą których można operować na chronionym zasobie. Przykładowo: żeby uczestnik projektu mógł zmienić zawartość pliku z kodem źródłowym musi należeć do upoważnionego zespołu programistów i powinien posługiwać się właściwym edytorem tekstów.

Istnieją też inne mechanizmy nadzoru nad projektem, które związane są z konstrukcjami językowymi Ady. Jedną z podstawowych jednostek programowych Ady jest pakiet. Składa się on dwóch, przechowywanych rozdzielnie części: specyfikacji i realizacji. Dzięki temu można osiągnąć silną modularność kodu, kontrolę pośrednictwa modułów oraz ukrycie pewnych, szczegółowych informacji. Część specyfikacyjna pakietu wypełniana jest w fazie projektowej, udostępniana dla wszystkich zainteresowanych, ale chroniona przed zmianami za pomocą specjalnej procedury postępowania. Uprawnieni programiści wypełniają treść pakietu (część realizacyjna), ale w tym wypadku zmiany wprowadza się bez dodatkowych ograniczeń. Kompilator automatycznie sprawdza zgodność obu składowych pakietu. Dzięki temu zachowuje się integralność projektu oraz jego dobrą strukturę.

LBMS

Wymienione dotychczas przykłady dotyczyły systemów czy środowisk pracy mało znanych w naszym kraju. Koncentrowały się one przede wszystkim na fazie realizacyjnej systemów. Ostatni przykład dotyczy funkcji zarządzania konfiguracją projektu w pakiecie Systems Engineer firmy LBMS (Learmonth & Burchett Management Systems). Jest to pakiet CASE, który tworzy zintegrowane środowisko dla projektowania i tworzenia systemów informatycznych. Modułem odpowiedzialnym za kontrolę i zarządzanie konfiguracją jest SE/Repository -wielodostępne repozytorium zrealizowane w architekturze klient/serwer. Łączy ono wszystkie obiekty projektu, takie jak: diagramy, opisy, związki między nimi, moduły z pseudokodem, itp. w centralnej bazie projektu. Są one tam umieszczane przez członków zespołu podzielenych na grupy. O podziale decyduje administrator systemu, który tworzy grupy

(nie ma ograniczeń na liczbę i liczebność grup), nadaje użytkownikom członkostwo (można należeć do wielu grup) oraz ustala prawa dostępu do obiektów projektu. Z drugiej strony użytkownik może być zarejestrowany w systemie jako użytkownik "bierny" (read-only user).

Kontrola dostępu do danych realizowana jest na poziomie obiektu -każdy element repozytorium jest własnością jednej grupy użytkowników, która go tworzy, modyfikuje i ewentualnie usuwa. Użytkownicy nie będący właścicielami obiektu mogą jednak oglądać jego definicję i wykorzystywać ją w stosownych miejscach własnej pracy. Na przykład członkowie grupy "Projektanci bazy danych" jako jedyni mogą tworzyć i modyfikować diagramy modelu danych oraz moduły zawierające kod triggerów.

Pakiet Systems Engineer może obsługiwać wiele repozytoriów dla jednego projektu. Pozwala to na rozproszoną pracę, zapewniając spójność danych projektowych. SE/Repository zawiera mechanizmy transferu danych między różnymi repozytoriami, w tym mechanizmy scalania danych z kilku repozytoriów w jedną, centralną bazę danych projektu.

Pamiętanie pełnej historii projektu jest możliwe dzięki mechanizmom kontroli wersji obiektów. Każdy użytkownik, mający odpowiednie prawa dostępu, może zapisywać aktualny stan obiektu w postaci jego wersji, dołączając opis i automatyczną lub specyficzną numerację wersji. Se/Repository działa w trybie "single-instance", co oznacza, że istnieje jedna aktualna wersja obiektu. W momencie, gdy uprawniony użytkownik zmienia jego zawartość, to wszystkie osoby pracujące z tym obiektem lub z elementami repozytorium z nim powiązanymi otrzymują informacje o modyfikacji. Oczywiście same nie mogą poprawiać tego obiektu, jedynie mogą otrzymać najświeższą wersję obiektu.

Pamiętane mogą być nie tylko zawartości obiektów, ale również związki i zależności omiędzy różnymi klasami obiektów. Istniejące w repozytorium wersje można wykorzystać do przywrócenia poprzednio zapamiętanego stanu, nawet w wypadku braku aktualnej roboczej wersji danego obiektu. W tym celu posługujemy się listą wersji wybranego obiektu uporządkowaną wg numerów lub czasu ich powstania.

Zarządzanie konfiguracją możliwe jest dzięki grupowaniu wersji obiektów w "etapy". Etapy wykorzystywane są zwykle do rejestrowania ważnych punktów kontrolnych w cyklu projektowym, zawierają np. obraz dokumentacji projektowej przed przeglądem kontroli jakości lub obraz zatwierdzonej specyfikacji wymagań. Tworzenie etapów jest proste i daje dużo korzyści w zarządzaniu projektem. W automatyczny sposób można znaleźć różnice między etapami a aktualną wersją repozytorium, dostępne są funkcje przeglądania składników etapu czy eksportowania ich w formacie CDIF. Administrator systemu może nawet jednym poleceniem przywrócić stan projektu zapisany w postaci etapu.

Prezentowane przykłady pokazują, jak różne sposoby wspomagania zarządzania konfiguracją mają szefowie dużych projektów informatycznych. Zakres udziału systemów komputerowych może być różny, ale wydaje się, że kluczem do sukcesu jest sama decyzja o porządkowaniu pracy zespołu, polepszaniu komunikacji między jego członkami, budowaniu bezpiecznego i spójnego repozytorium projektu.

Autor jest pracownikiem InfoViDE - przedstawiciela Learmonth & Burchett Management Systems (LBMS), brytyjskiego twórcy metodyk i narzędzi CASE. InfoViDE zajmuje się wdrażaniem systemów CASE, nauczaniem technik strukturalnych i konsultingiem informatycznym.