System wspomagania zarządzania konfiguracjami oprogramowania

System wspomagania zarządzania konfiguracjami oprogramowania Slajd nr 1

System wspomagania zarządzania konfiguracjami oprogramowania

Prezentacja założeń do pracy magisterskiej

Opracowała: Agnieszka Zawadzka


Plan prezentacji

1.Kategoria tematyczna pracy.2. Co jest zarządzanie konfiguracją oprogramowania.3. Cel pracy - ogólnie4. 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 systemy8.1. Narzędzia (Co jest na rynku).8.3. CVS

9. Co chcę osiągnąć.


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.


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.


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.)


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


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


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.


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.


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ę


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.


7. Przedmiot biblioteki/repozytorium7.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)


7. Przedmiot biblioteki/repozytorium7.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;


7. Przedmiot biblioteki/repozytorium7.2. Zasady przechowywania elementów

Wszystkie pozycje konfiguracji (i pozostałe elementy) muszą być przechowywane:

bezpiecznie,systematyczniew 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.


7.2. Zasady przechowywania elementów7.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.


7.2. Zasady przechowywania elementów7.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.


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.




Dla dokumentów są to:Document Change Record – DCR – Ewidencja Zmiany DokumentuDocument Status Sheet – DSS – Arkusz Statusu DokumentuReview Item Discrepancy – RID – Raport Niezgodności Pozycji

Dla kodów i jednostek oprogramowania są to:Software Change Request – SCR – Wniosek Zmiany OprogramowaniaSoftware 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.




Document Change Record – DCR – Ewidencja Zmiany Dokumentu

Numer DCRDataZgłaszający

(DCR) Zapis ZmianyDokumentu

Zatwierdzony przez:1. Tytuł (nazwa) dokumentu:

2. Numer odnośnego dokumentu:

3. Numer wersji/korekty dokumentu

4. Strona 5. Akapit 6. Powód zmiany

Opisuje jedną lub więcej zmian w określonym dokumencie.




Document Status Sheet – DSS – Arkusz Statusu Dokumentu

(DSS) Arkusz Statusu Dokumentu

1. Tytuł (nazwa) dokumentu:


3. Wersja 4. Rewizja 5. Data 6. Powód zmiany

zawiera historię dokumentu, w której są opisane kolejne wersje dokumentu




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

Numer RIDData

(RID) Raport NiezgodnościPozycji

Zgłaszający1. Tytuł (nazwa) dokumentu:


3. Numer wersji/korekty dokumentu

4. Lokacja problemu

5. Opis problemu

6. Zalecane rozwiązanie

7. Odpowiedź autora.

8. Decyzja przeglądu: zamknąć / aktualizować / wykonać/ odrzucić




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

Numer SCRDataZgłaszający

(SCR) Wniosek ZmianyOprogramowania

Powiązane SPR1. Tytuł (nazwa) pozycji oprogramowania:

2. Numer wersji/wydania pozycji oprogramowania

3. Priorytet: krytyczny / pilny / rutynowy

4. Wymagane zmiany

5. Odpowiedzialny personel

6. Przybliżona data rozpoczęcia, data zakończenia i nakład pracy:

7. Załączniki





Software Modification Report – SMR – Raport Modyfikacji Oprogr.

Raport opisujący implementację oprogramowania wg oczekiwanych

zmian.

Numer SMRDataZgłaszający

(SMR) Raport modyfikacjioprogramowania

Powiązane SCR1. Tytuł (nazwa) pozycji oprogramowania:


3. Zaimplementowane zmiany

4. Rzeczywista data rozpoczęcia, data zakończenia i nakład pracy:

5. Załączniki




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.

Numer SPRData

(SPR) Zgłoszenie problemuoprogramowania

Zgłaszający1. Tytuł (nazwa) pozycji oprogramowania:


3. Priorytet: krytyczny / pilny / rutynowy

4. Opis problemu:

5. Opis środowiska:

6. Zalecane rozwiązanie:


8. Załączniki:




Software Release Note – SRN – Nota Wydania Oprogramowania

Dokument opisujący zaminay i PK objete wydaniem na zewnatrz oprogramowania.

Numer SRNData

(SRN) Wydanie oprogramowania

Zgłaszający1. Tytuł (nazwa) pozycji oprogramowania:


3. Zmiany w tym wydaniu:

4. Pozycje konfiguracji zawarte w tym wydaniu:

5. Instrukcje instalacji:


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.



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.



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 .



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.



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).



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).


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


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;



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 repozytorium6. 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 konfiguracji9. Usprawnienie lub wsparcie wszelkiego rodzaju raportowania lub podejmowania decyzji.


System wspomagania zarządzania konfiguracjami oprogramowania

Documents

Transcript of System wspomagania zarządzania konfiguracjami oprogramowania