System wspomagania zarządzania konfiguracjami oprogramowania

1. System wspomagania zarządzania konfiguracjami oprogramowania Prezentacja założeń do pracy magisterskiej Opracowała: Agnieszka Zawadzka

2. Plan prezentacji 1.Kategoria tematyczna pracy. 2. Co jest zarządzanie konfiguracją oprogramowania. 3. Cel pracy - ogólnie 4. Dlaczego biblioteka/repozytorium. 5. Cechy biblioteki/repozytorium. 6. Aspekty i funkcjonalności ZKO a biblioteka/repozytorium. 7. Przedmiot biblioteki/repozytorium 7.1. Wstępny podział przedmiotów przechowywanych w R. 7.2. Zasady przechowywania elementów 7.2.1. Atrybuty (wstępna orientacja) 7.2.2. Rodzaje dokumentów administracyjnych 8. Stan sztuki (ogólnikowo) - Działające systemy 8.1. Narzędzia (Co jest na rynku). 8.3. CVS 9. Co chcę osiągnąć.

3. 1.Kategoria tematyczna pracy. • Kategoria tematyczna prezentowanej pracy magisterskiej, która w pełni obrazuje jej zakres, to: • Zarządzanie konfiguracjami i wersjami oprogramowania; • Ponieważ praca obejmować będzie dokumentowanie (zasady, wzorce, wymagania dotyczące zawartości dokumentów), procesy zarządzania dokumentacją (kto, czym, i w jakim celu), oraz przechowywanie poszczególnych wersji oprogramowania wytwarzanego podczas poszczególnych faz rozwoju, zakres tej pracy ociera się również o kategorie: • Dokumentowanie oprogramowania i procesów wytwarzania oprogramowania; • Ponowne użycie oprogramowania, dokumentacji i procesów wytwarzania oprogramowania.

4. 2. Co to jest zarządzanie konfiguracją oprogramowania (ZKO) Temat prezentowanej pracy “System wspomagania zarządzania konfiguracjami oprogramowania” jest określany w dostępnej literaturze jako Zarządzanie Konfiguracją (Configuration Management). Wg przyjętych definicji, zarządzanie konfiguracją oprogr. zajmuje się planowaniem, organizowaniem, sterowaniem koordynacją działań mających na celu identyfikację, przechowywanie i zmiany oprogr. w trakcie jego rozwoju, integracji i przekazania do użycia. Wiąże się to w głównej mierze z tworzonymi dokumentami i kolejnymi wersjami tworzonego oprogramowania, w poszczególnych etapach cyklu życia tego oprogramowania. Każdy projekt musi podlegać konfiguracji oprogramowania, gdyż ma to krytyczny wpływ na jakość końcowego produktu i jest to niezbędne do efektywnego rozwoju i późniejszego utrzymania oprogramowania.

5. 3. Cel pracy - ogólnie (1) • Cel: W bardzo dużym skrócie celem niniejszej pracy jest stworzenie: biblioteki/repozytorium do przechowywania i zarządzania pozycjami konfiguracji oprogramowania. • Dobrze zorganizowany system ZKO powinien być oparty na bazie danych oraz integrować informacje o pozycjach konfiguracji z tymi właśnie (w postaci elektronicznej) pozycjami konfiguracji, natomiast dobrze zorganizowana biblioteka/repozytorium pozycji konfiguracji jest fundamentem dla dobrego systemu ZKO. • Stworzenie takiego modelu bazy danych to główny cel tej pracy. • Cel: Sama baza danych musi przede wszystkim zawierać: • związki pomiędzy poszczególnymi pozycjami konfiguracji; • pozycje konfiguracji; • wszelkie informacje o pozycji konfiguracji (zgłaszane zmiany, wersje, rewizje, itp.)

6. 3. Cel pracy - ogólnie (2) • Cel: Usystematyzowanie zarządzania zmianami, które jest podstawą dobrego zarządzania konfiguracjami (dokumenty, role, personel). • Wszelkie zmiany oprogramowania (kodu, dokumentacji) są rzeczą normalną oraz jedną z podstawowych podczas rozwoju i pielęgnowania systemu i dlatego wymagają wnikliwych badań, analiz, procedur, reguł, itp. • Cel: Usystematyzowanie wiedzy o pozycjach konfiguracji, które są kluczowymi jednostkami ZKO i są nimi wszystkie elementy projektu i oprogramowania. Próba podziału i ich uporządkowania będzie dalej. • Dodatkowo praca obejmować będzie: • dokumentowanie (zasady, wzorce, wymagania dotyczące zawartości dokumentów ze szczególną uwagą na dokumenty administracyjne), • procesy zarządzania dokumentacją, komponentami oprogramowania (kto, czym, i w jakim celu), • przechowywanie poszczególnych wersji oprogramowania i dokumentów wytwarzanych podczas poszczególnych faz rozwoju

7. 4. Dlaczego biblioteka/repozytorium • Dobrze zorganizowana biblioteka/repozytorium pozycji konfiguracji jest fundamentem dla dobrego systemu ZKO. • Biblioteka/repozytorium powinna umożliwiać: • łatwe odszukanie, • odczytanie, • wstawienie, • zastąpienie • usuwanie • dowolnych PK zawartych w tej bibliotece/repozytorium. • Dodatkowo przy okazji buduje się baza informacji, z której można wygenerować mniej lub bardziej sensowne, ale efektywne raporty (liczba zgłoszonych błędów). • Ponadto pozwala monitorować przebieg prac, faz rozwoju projektu, uzyskać historię zmian, historię pozycji konfiguracji

8. 5. Cechy biblioteki/repozytorium. • Kluczową cechą biblioteki jest bezpieczeństwo i autoryzowany dostęp. • Szczegółowo rozpatrując te cechy, podstawą jest: • osiągnięcie minimalizacji nieautoryzowanego dostępu; • zapewnienie precyzyjnego określenia praw dostępu poszczególnych uczestników projektów; Oraz cechy wynikające z zasad i procedur ZKO: • zablokowanie możliwości jednoczesnej aktualizacji tej samej PK przez dwie osoby; • zablokowanie zmiany pozycji konfiguracji, które są produktami bazowymi; • minimum możliwości zniszczenia biblioteki poprzez awarię, błąd lub sabotaż; • Osiągnięcie i zapewnienie tych cech i celów absolutnie nie mogą wiązać się z niewygodą w pracy użytkowników, zwiększenia czasów dostępu, istotnych nakładów, itd.

9. 6. Aspekty i funkcjonalności ZKO a biblioteka/repozytorium (1) • Repozytorium/biblioteka na której opiera się ZKO powinno wspomagać następujące aspekty i umozliwiać nastepujące funkcjonalności: • Funkcjonalności: • Organizowanie aktywności związanych z ZKO • identyfikację PK, • przechowywanie PK, • kontrola zmian konfiguracji, • określenie statusu konfiguracji; • przekazanie PK na zewnątrz; • Zdefiniowanie ról personelu oraz przypisanie ról do personelu; • Identyfikację wszystkich komponentów składających się na projekt oprogramowania i określania ich statusu; • Podział komponentów oprogramowania pomiędzy personel rozwijający oprogramowanie; • Śledzenie pochodzenia i rozwijania każdego komponentu oraz ustalanie kompletności i poprawności każdej konfiguracji; • Przejrzystość projektu i produktu dla użytkowników. .

10. 6. Aspekty i funkcjonalności ZKO a biblioteka/repozytorium (2) • Aspekty: • Zawsze będzie wiadomo, która wersja komponentu oprogramowania jest najnowsza; • Zawsze będzie wiadomo, która wersja dokumentacji pasuje do której wersji komponentu oprogramowania; • Komponenty oprogramowania będą zawsze łatwo dostępne; • Komponenty oprogramowania nigdy nie zostaną stracone (np. wskutek awarii nośnika lub błędu operatora); • Każda zmiana oprogramowania będzie zatwierdzona i udokumentowana; • Zmiany oprogramowania nie zaginą (np. wskutek jednoczesnych aktualizacji); • Zawsze będzie istniała możliwość powrotu do poprzedniej wersji; • Historia zmian będzie przechowywana, co umożliwi odtworzenie kto i kiedy zrobił zmianę, i jaką zmianę

11. 7. Przedmiot biblioteki/repozytorium Podstawowym przedmiotem, który ma być przechowywany w bibliotece/repozytorium jest pozycja konfiguracji - jej opis i ona sama. Dodatkowo muszą być przechowywane informacje o jej powiązaniu z innymi PK, jej miejsce w hierarchii wszystkich PK, historia zmian tej PK, wszystkie wersje tej PK, jakie były wytworzone. Dla pełnego obrazu zarządznia konfiguracja oprogramowania, repozytorium/biblioteka powinna przechowywać wszystkie PK, zarówno w postaci elektronicznej, papierowej jak i każdej innej. Jednak z racji bardzo szerokiego tematu sposobów przechowywania, narzędzi do przechowywania praca ta zajmie się tylko PK w postaci elektronicznej.

12. 7. Przedmiot biblioteki/repozytorium 7.1. Wstępny podział przedmiotów przechowywanych w R. (1) • Podział ten ma na celu doprowadzenie do usystematyzowania rodzajów przedmiotów trzymanych w repozytorium oraz ustalenia niezbędnych atrybutów, potrzebnych do przechowania informacji o PK. • Proponowany wstępnie podział: • elektroniczne PK dotyczące wszelkiej dokumentacji związanej z wytworzeniem oprogramowania (dokumenty analityczne, wymagań, projektowe, testowania, użytkownika itd.) • elektroniczne PK dotyczące kodu źródłowego i wynikowego oprogr. ( kody źródłowe, programy wykonywalne, pliki nagłówkowe, kody binarne, kody do konsolidowania, ekrany interfejsu użytkownika) • elektroniczne PK dotyczące narzędzi do tworzenia oprogramowania (kompilatory, linkery, konsolidatory, interpretery, biblioteki, protokoły, narzędzia CASE, konfiguracje sprzętowe, oprogramowanie testujące)

13. 7. Przedmiot biblioteki/repozytorium 7.1. Wstępny podział przedmiotów przechowywanych w R. (2) • elektroniczne PK wspomagające tworzenie oprogr. jak: pliki z danymi tekstowymi, (komunikaty systemu), BD, słowniki, dane testujące; • elektroniczne dokumenty administrayjne związane z projektami oprogramowania, o nich mowa dalej; Warto też zastanowić się nad takimi przedmiotami i sensownością przechowywania ich definicji i informacji o nich w repozytorium jak: • zasady identyfikacji PK, które można narzucić, definiując parametry systemu; • wersjonowania PK; • przechowywania PK; • procesów kontroli zmian; • procesów określania statusu konfiguracji; • zdefiniowanie ról i przypisanie ich do użytkowników; • być może definiowanie również samych użytkowników;

14. 7. Przedmiot biblioteki/repozytorium 7.2. Zasady przechowywania elementów • Wszystkie pozycje konfiguracji (i pozostałe elementy) muszą być przechowywane: • bezpiecznie, • systematycznie • w dobrze zorganizowany sposób • tak jak książki w bibliotece. • Za koordynację i wprowadzanie PK oraz zmian odpowiada osoba odpowiedzialna. • Wyróżnianie są trzy poziomy odpowiedzialności: • autor kodu (programista) lub dokumentacji; • kierownik projektu; • ciało kontrolno-rewizyjne • Poziomów tych może być więcej, zgodnie z wielkością projektu, fazami kontroli i weryfikacją oprogramowania. • Przy dużych projektach uzasadnione jest powołanie funkcji lub stanowiska zw. bibliotekarzem oprogramowania.

15. 7.2. Zasady przechowywania elementów 7.2.1. Atrybuty (wstępna orientacja) (1) • Podstawowe atrybuty zmiany (np. błędu, ulepszenia, modyfikacji): • rodzaj : • błąd krytyczny (nie można działać w systemie), • błąd poważny (nie działa lub błędnie działa moduł), • niezbyt istotny (drobna niedogodnoścć, niekonsekwencja , nieelegancja), • konkretne rozszerzenie, • wartościowy luźny pomysł; • waga: jak szybko musi zostać to naprawione, • natychmiast, • jak najszybciej, • w normalnym trybie, • w dowolnej przyszłości • numer wersji w której wykryto błąd; • platforma, środowisko systemowe. • Lista ta może być modyfikowana w zalezności od potrzeb danego projektu, bądź firmy.

16. 7.2. Zasady przechowywania elementów 7.2.1. Atrybuty (wstępna orientacja) (2) • Zasady i procedury ZKO jako minimum informacji w bibliotece dla wszystkich PK, (elektronicznych i papierowych), wymagają: • nazwy projektu; • identyfikatora pozycji konfiguracji; • daty wprowadzenia do repozytorium; • krótkiego opisu lub charakterystyki zawartości PK, • które powinny być zawarte w tzw. etykiecie PK. • Identyfikator: Zawierać musi: nazwę, typ i wersję PK. Musi być unikalny.

17. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (1) • Z wymienionych grup pozycji do rejestracji myślę, że najmniej znane, mimo, że oczywiste są dokumenty administracyjne. • W ich skład wchodzą takie dokumenty jak: • formularz zmian w oprogramowaniu • formularz zmian w dokumentacji • raporty etapowe; • raporty końcowe; • zlecenia zmian; • raporty zaistniałych problemów • raporty z testów. • Wydawać się może,że tego typu dokumenty mogą tylko komplikować życie osobom rozwijającym oprgramowanie, (marnowanie czasu na pisanie, czekanie na reakcję zainteresowanych, dyskusja, spotkania przeglądowe, czekanie na decyzję, opis tego zo zostało faktycznie zrobione), jednak przy dużych projektach, lub długotrwałych jest to chyba najrozsądniejsza metoda dokumentowania postepów, a już na pewno historii zmian pozycji konfiguracji.

18. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (2) Dla dokumentów są to: Document Change Record – DCR – Ewidencja Zmiany Dokumentu Document Status Sheet – DSS – Arkusz Statusu Dokumentu Review Item Discrepancy – RID – Raport Niezgodności Pozycji Dla kodów i jednostek oprogramowania są to: Software Change Request – SCR – Wniosek Zmiany Oprogramowania Software Modification Report – SMR – Raport Modyfikacji Oprogr. Software Problem Report – SPR – Zgłoszenie Problemu Oprogr. oraz dodatkowo: Software Release Note – SRN – Nota Wydania Oprogramowania Dalej przedstawiam przykładowe szablony tych dokumentów, obrazujące co muszą zawierać i krótkie opisy definiujące zawartość. Są one podstawowym kluczem do przedstawiania historii zmian PK.

19. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (3) Document Change Record – DCR – Ewidencja Zmiany Dokumentu Opisuje jedną lub więcej zmian w określonym dokumencie.

20. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (4) Document Status Sheet – DSS – Arkusz Statusu Dokumentu zawiera historię dokumentu, w której są opisane kolejne wersje dokumentu

21. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (5) Review Item Discrepancy – RID – Raport Niezgodności Pozycji opisuje problem lub niezgodności w określonym dokumncie w stosunku do innego związanego z nim dokumentu oraz proponowane rozwiązanie problemu

22. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (6) Software Change Request – SCR – Wniosek Zmiany Oprogramowania Opis potrzebnych zmian w dokumentacji i kodzie przez określony personel, w szacowanym określonym harmonogramie i nakładzie pracy

23. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (7) Software Modification Report – SMR – Raport Modyfikacji Oprogr. Raport opisujący implementację oprogramowania wg oczekiwanych zmian.

24. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (8) Software Problem Report – SPR – Zgłoszenie Problemu Oprogr. Raport, który opisuje problem z oprogramowaniem, priorytet tego problemu, opisuje środowisko w którym problem zaistniał oraz proponowane rozwiązanie.

25. 7.2. Zasady przechowywania elementów 7.2.2. Rodzaje dokumentów administracyjnych (9) Software Release Note – SRN – Nota Wydania Oprogramowania Dokument opisujący zaminay i PK objete wydaniem na zewnatrz oprogramowania.

26. 8. Stan sztuki (ogólnikowo) - Działające systemy • System zarządzania wersjami jest kluczem do efektywnego tworzenia oprogramowania. Powinno istnieć jedno repozytorium, w którym znajduje się pełny kod źródłowy tworzonych systemów dokumenntacji do nich. • Musi być możliwe dokładne odtworzenie kodu, dokumentu, z których zbudowano wersję aktualnie działającą u klientów (nawet gdy klientów jest kilku i każdy używa trochę innej wersji). • Musi być dostępna historia zmian - zarówno w formie opisów podawanych przez wprowadzających modyfikacje, jak bezpośredniego porównania poszczególnych plików. • Często pojawia się konieczność wprowadzania "na boku" poprawek w starszej wersji programu czy biblioteki - akurat w chwili, gdy właśnie jesteśmy w środku głębokich przeróbek. • Potrzeby takie są wyraźne nawet w projektach robionych przez jedną osobę przez jeden-dwa miesiące. Gdy pracuje kilku czy kilkunastoosobowy zespół (nie mówiąc o większych) a projekt trwanie trwa wiele miesięcy, brak zarządzania wersjami daje praktyczną pewność ogromnych problemów.

27. 8. Stan sztuki (ogólnikowo) - Działające systemy 8.1. Narzędzia (Co jest na rynku) • Rynek narzędzi do zarządzania wersjami (czy też zarządzania konfiguracją - co oprócz zarządzania wersjami obejmuje oczywiście procedury budowy kodu, rejestracji błędów, powiadamiania o zmianach itp) jest bardzo bogaty. • Są to jednak w większości przypadków: • produkty dosyć prymitywne (RCS, SCCS, SourceSafe, PVCS) • produkty drogie (Perforce, StarTeam, Razor) • produkty bardzo drogie (ClearCase, Continouous). • W polskiej praktyce wydanie nawet kilku tysięcy dolarów na tego typu narzędzia nie jest rzeczą łatwą. Ale istnieje produkt, który nie kosztuje nic a zapewnia całkiem zaawansowane możliwości - CVS.

28. 8. Stan sztuki (ogólnikowo) - Działające systemy 8.1. CVS (1) Niektóre istotne zalety CVS: 1. Przede wszystkim: darmowość. 2. CVS działa w sieci 3. CVS działa na wszystkim 4. Można używać wielu kopii roboczych 5. Nie trzeba być stale podłączonym 6. Dodanie lub skasowanie pliku jest wersjonowane 7. Repozytorium ma strukturę 8. CVS nie wymaga blokowania plików 9. CVS obrasta w narzędzia uzupełniające .

29. 8. Stan sztuki (ogólnikowo) - Działające systemy 8.1. CVS (2) • Niektóre istotne wady CVS: • 1. CVS nie jest systemem zarządzania konfiguracją • CVS jest dobrym systemem zarządzania wersjami ale niczym więcej. • Nie obsługuje: • rejestracji błędów i wiązania ich z poprawkami. • nie implementuje procedur kompilacji i tworzenia wydań na zewnątrz • nie daje możliwości określania stanu poszczególnych modułów (czyli przydzielania etykietek typu w trakcie tworzenia, alfa - faza wstępnych testów, beta - faza finalnych testów, gotowe do dystrybucji). • nie definiuje i nie wymusza żadnego standardowego procesu rozwijania kodu.

30. 8. Stan sztuki (ogólnikowo) - Działające systemy 8.1. CVS (3) Niektóre istotne wady CVS: 2. CVS niestety nie umożliwia kontroli wersji obejmującej dodawanie i kasowanie katalogów. Raz dodany nowy katalog wygląda jak gdyby istniał od zawsze, usunąć go praktycznie nie można (oczywiście można skasować katalog z repozytorium ale tracimy wtedy historię dla wszystkich plików które się w nim znajdowały a możemy też sprawić pewne problemy klientom). Równie kłopotliwe jest zmienianie nazwy katalogu (możemy zmienić nazwę katalogu w repozytorium ale tracimy na zawsze informację o jego wcześniejszej nazwie czyli np. możliwość dokładnego odtworzenia stanu źródeł z przeszłości).

31. 8. Stan sztuki (ogólnikowo) - Działające systemy 8.1. CVS (4) • Niektóre wady CVS: • 3. Choć jednym poleceniem cvs commit możemy zatwierdzić poprawki w wielu plikach, CVS wewnętrznie implementuje to po prostu jako kolejne zatwierdzanie poprawki w wszystkich tych plikach. Wiąże się to z pewnym problemem: • w razie jakichś problemów (np. zerwanie połączenia sieciowego z serwerem) część naszych zmian może zostać zatwierdzona a część nie - problem jest o tyle niezbyt istotny, że raczej to zauważymy, a zwykłe ponowienie tego samego polecenia dokończy aktualizację; tracimy informację o powiązaniu zmian - analizując historię zmian nie widzimy bezpośrednio, że czyjaś poprawka obejmowała zmiany w plikach A, B i C (mamy jedynie, w ramach historii plików A, B i C zmiany dokonane w tym samym czasie i z tym samym komentarzem).

32. 9. Co chcę osiągnąć (1) • Miedzy innymi: • 1. Jeden z głównych celów to tzw. monitorowanie błędów i wymaganych zmian – czymkolwiek by one były: • błędami do usunięcia, • rozszerzeniami do dodania, • operacjami administracyjnymi do wykonania. • Mają one następujące podstawowe zastosowania: • jeszcze w trakcie projektu • pod koniec • po wdrożeniu • udostepnianie klientom rozwoju prac

33. 9. Co chcę osiągnąć (2) • 2. Listy zmian, o określonych cechach: • gwarancja, że żadna informacja nie zginie • dostepność dla całego zespołu a nie jednej osoby (urlop, zmiana pracy) • oznaczanie rzeczy zrobionych nie przez kasowanie; • szybkie odnalezienie listy błędów do usunięcia przez konkretną osobę w okreslonym komponencie • Jest to absolutne minimum. • 3. Wytyczne i reguły cykl obsługi błędu (zmiany). • wprowadzenie informacji o błędzie (zmianie); • określenie odpowiedzialności za ten wniosek;; • toczą się prace związane z obsługą błędu, w trakcie których mogą być dołączane kolejne informacje i przypisania innym osobom; • koniec prac; oznaczenie ich; testowanie; wydanie na zewnątrz, zamknięcie sprawy;

34. 9. Co chcę osiągnąć (3) 4. Zawsze aktualna dokumentacja – przy tworzeniu różnych bibliotek, pakietów, modułów, klas , procedur (w zależności od jezyka programowania), trzeba je dokumentować, aby mogły być uzywane nie tylko przez autora (zresztą i dla autora np. po roku są bardzo cenne). Utrzymanie aktualnej dokumentacji często stanowi problem. Oraz cele dyktowane aspektami ZKO: 5. Ewidencję i rejestrację samych i wszystkich PK – zarówno PK niższego poziomu jak i wyższego poziomu – jest to jeden z warunków na dobre repozytorium 6. Ewidencję i rejestrację zależności i odpowiednich powiązań pomiędzy pozycjami konfiguracji 7. Ewidencję i rejestrację wszelkich dokumentów administracyjnych. 8. Ewidencję i rejestrację powiązań dokumentów administracyjnych z pozycjami konfiguracji 9. Usprawnienie lub wsparcie wszelkiego rodzaju raportowania lub podejmowania decyzji.