Inżynieria oprogramowania
wykład 8
ZarzÄ…dzanie konfiguracjÄ…
oprogramowania
1
ZarzÄ…dzanie konfiguracjÄ… -
definicja
dotyczy przypadków wprowadzania zmian do
wytwarzanego oprogramowania
operacje zarzÄ…dzania konfiguracjÄ…:
Ä„ð identyfikacja zmian
Ä„ð kontrolowanie procesu wprowadzania zmian
Ä„ð wspomaganie poprawnoÅ›ci dokonania zmian
Ä„ð przekazanie informacji o zmianach (kierownictwo, analitycy, inne
zespoły twórców)
jest czynnością przekrojową (wykonywaną na każdym
etapie procesu wytwórczego)
jest jednym z priorytetów inżynierii oprogramowania i ma
na celu ułatwienie dokonywania zmian oraz zmniejszanie
pracochłonności tych czynności
2/21
ZarzÄ…dzanie konfiguracjÄ… vs.
wsparcie produktu
wsparcie to czynności wykonywane po
wdrożeniu produktu, podczas eksploatacji
oprogramowania
czynności obejmujące zarządzanie konfiguracją
mogą być wykonywane tuż po rozpoczęciu
procesu wytwórczego, na wszystkich jego
etapach, aż do wycofania produktu z rynku
3/21
Czego dotyczy zarzÄ…dzanie
konfiguracjÄ…
rezultatem procesu wytwórczego są 3 składniki
Ä„ð program, w formie kodu z
ródłowego lub języka wykonywalnego
Ä„ð dokumentacja programu opis dziaÅ‚ania programu: aspekty
techniczne, przeznaczona dla informatyków oraz aspekty
użytkowe, przeznaczone dla przyszłych użytkowników
Ä„ð dane które zawiera program lub doÅ‚Ä…czone do programu
konfiguracja oprogramowania wszelkie informacje
powstałe w procesie wytwórczym, np. specyfikacja
produktu, specyfikacja wymagań, plan przedsięwzięcia
zarzÄ…dzanie konfiguracjÄ… oprogramowania obejmuje
wszelkie aspekty wynikajÄ…ce z wprowadzania zmian w
procesie wytwórczym, kontrolę tych zmian
4/21
Pierwsze prawo inżynierii
systemów*
zmiany mogą wystąpić w każdej chwili i być
efektem różnych przyczyn
 niezależnie od stanu zaawansowania prac nad
systemem będzie on się zmieniał, a dążenie do
zmian występuje przez cały czas jego istnienia
* E. H. Bersoff, V. D. Henderson, S. G. Siegel:  Software configuration management , Prentice-Hall 1980
5/21
Przyczyny zmian w procesie
wytwórczym
zmiany uwarunkowań stawianych przez rynek
powodują zmiany wymagań stawianych produktowi
oraz firmie wytwarzajÄ…cej program
nowe potrzeby i wymagania klienta  zmiana
funkcjonalności, przetwarzanych danych i rezultatów
działania programów
zmiany w strukturze firmy (reorganizacja, ograniczenia,
rozwój)  efekt: zmiana priorytetów firmy, zmiany w
zespołach twórców
ograniczenia czasowe lub budżetowe
nowe informacje i doświadczenia, dodatkowa wiedza
wynikająca z obserwacji i analizy zakończonych lub
prowadzonych prac wytwórczych
6/21
Baza zmian*
pojęcie wprowadzone celem kontroli zmian ale bez
utrudniania ich wprowadzania
specyfikacja lub produkt, który poddano formalnemu
przeglądowi i zaakceptowano, który może służyć jako
podstawa dalszego rozwoju i który można zmieniać,
stosujÄ…c tylko formalne procedury kontrolowania zmian*
element konfiguracji który nie jest bazą można
modyfikować szybko i nieformalnie
element konfiguracji będący bazą może być zmieniany
ale wg określonej formalnej procedury, zmiany należy
kontrolować i analizować
* wg normy IEEE nr 610.12-1990
7/21
Elementy konfiguracji
oprogramowania
elementy konfiguracji sÄ… przechowywane w
bazie danych opisane, w sposób
pogrupowany, jako tzw. obiekty konfiguracji
posiadają nazwę i zestaw atrybutów, są
połączone z innymi obiektami siecią zależności
(zmiana jednego elementu pociÄ…ga za sobÄ…
konieczność zmiany drugiego)
przykłady:
Ä„ð specyfikacja projektu, model danych, kod z
ródłowy,
specyfikacja testów
8/21
Elementy konfiguracji -
przykład
specyfikacja projektu model danych
projekt danych
projekt architektury
projekt modułu
moduł n
projekt interfejsu
opis interfejsu
opis algorytmu
specyfikacja testów
pseudokod
plan testowania
procedura testowania
kod z
ródłowy
zestawy testów
zależność bycie częścią
9/21
Proces zarzÄ…dzania konfiguracjÄ…
identyfikacja i zarzÄ…dzanie istniejÄ…cymi wersjami
programów i ich dokumentacją w celu potencjalnej
modyfikacji
kontrolowanie wersji - zmian przed i po oddaniu
programu użytkownikowi
kontrolowanie akceptowanie i ocenianie
wprowadzonych zmian
sprawdzanie konfiguracji  poprawność
wprowadzonych zmian
raportowanie  rozpowszechnianie informacji o
wprowadzonych zmianach
10/21
Identyfikacja obiektów konfiguracji
w celu kontroli i zarzÄ…dzania elementami
konfiguracji należy je nazwać i pogrupować,
stosuje się tu podejście obiektowe
używane są dwa rodzaje obiektów:
Ä„ð proste fragment tekstu powstaÅ‚y podczas
analizowania, projektowania, kodowania lub
testowania (rozdziały specyfikacji wymagań, kod
modułu, zestaw testów modułu itp.)
Ä„ð zÅ‚ożone zbiór obiektów prostych i zÅ‚ożonych (np.
obiekt składający się z obiektów prostych: opis
interfejsu, algorytm, pseudokod)
11/21
Atrybuty obiektu konfiguracji
nazwa
opis typ elementu (np. dokument, program,
dane), identyfikator przedsięwzięcia, informacje
o wersji i/lub wprowadzonej zmianie
lista zasobów (typy danych, funkcje, nazwy
zmiennych)
realizacja
hierarchia obiektów ustalona na podstawie
zależności między obiektami np. diagram jest
częścią modelu danych, model danych jest
częścią specyfikacji projektu
12/21
Hierarchia obiektów
konfiguracji
hierarchia obiektów ustalona na podstawie
zależności między obiektami np. diagram jest
częścią modelu danych, model danych jest
częścią specyfikacji projektu
związki między obiektami można zapisać w
postaci tzw. drzewa hierarchii
czasem zależności między obiektami
przebiegajÄ… w poprzek hierarchii
13/21
Graf ewolucji obiektu *
opisuje historiÄ™ zmian dotyczÄ…cych obiektu,
który może być wielokrotnie modyfikowany
poważna
modyfikacja
1.3 1.4
rozwijane
2 wersje
1.0 1.1 1.2
2.0 2.1
pierwsza
modyfikacja
nowa
1.1.1
1.1.2
wersja
kolejne drobne
modyfikacje
* A. Gustavsson: Miantaining the evolution of software
objects in integrated enviroment, 1989
14/21
Kontrolowanie wersji
metody i narzędzia pomagające zarządzać
wieloma wersjami obiektów konfiguracji
powstałych w procesie wytwórczym
każda wersja może mieć przypisane
odpowiednie atrybuty np. numer, ciÄ…g
zmiennych logicznych oznaczajÄ…cy rodzaje
wprowadzonych zmian
poszczególne wersje produktu można
przedstawić na grafie ewolucyjnym
15/21
Kontrolowanie zmian
kontrolowanie zmian ma zapobiegać powstaniu chaosu w
przedsięwzięciu programistycznym
czynności:
Ä„ð rozpoznanie potrzeby wprowadzenia zmian, analiza skutków
zmiany, ocena zgłoszenia potrzeby zmiany, raport, decyzja ws.
wprowadzenia zmiany
Ä„ð odrzucenie, poinformowanie wÅ‚aÅ›ciwych osób, lub
Ä„ð przyjÄ™cie zgÅ‚oszenia, przydziaÅ‚ pracowników, identyfikacja
obiektów konfiguracji, wprowadzenie zmian, analiza wyników,
rejestracja zmian, ustalenie nowej bazy do testowania,
testowanie, zatwierdzenie zmian, budowa nowej wersji, przeglÄ…d
wszystkich zmian wprowadzonych w różnych elementach
konfiguracji, wprowadzenie zmian do nowej wersji,
rozpowszechnianie nowej wersji
16/21
Formalna kontrola zmian
odbywa się po oddaniu produktu użytkownikowi
rejestracja
obiekt. konf., obiekt. konf.,
wersja zmodyf. wersja bazowa
odblokowanie
dane z
przeglądów
dane o prawach
kontrola
projektant / baza danych
dostępu
dostępu
programista przedsięwzięcia
zablokowanie
obiekt. konf.,
wersja bazowa
obiekt. konf.,
wersja pobrana odczytanie
17/21
Audyt konfiguracji
jest uzupełnieniem wyników przeglądów technicznych,
dostarcza oceny cech obiektów pomijanych podczas
przeglądów
odpowiada na pytania:
Ä„ð czy zadania zostaÅ‚y wykonane, czy byÅ‚y dodatkowe
modyfikacje
Ä„ð czy odbyÅ‚ siÄ™ przeglÄ…d techniczny poprawnoÅ›ci
Ä„ð czy stosowano zgodnie z zaÅ‚ożeniami proc. wytw. i
przestrzegano norm
Ä„ð czy wyróżniono zmienione fragmenty, czy zapisana data i autor
zmian
Ä„ð czy stosowano odpowiednie procoeduty zarzÄ…dzania
konfiguracjÄ…
Ä„ð czy uaktualnione zostaÅ‚y zmiany konfiguracji
18/21
Raportowanie o stanie
konfiguracji
nazywane również księgowaniem zmian
odpowiada na pytania:
Ä„ð co zostaÅ‚o zmienione
Ä„ð kto wprowadzaÅ‚ zmiany
Ä„ð kiedy wprowadzono zmiany
Ä„ð jakie bÄ™dÄ… skutki zmian
służy do rozpowszechniania informacji o
zmianach
19/21
Podsumowanie  zarzÄ…dzanie
przedsięwzięciem programistycznym
podstawy zarzÄ…dzania
miary przedsięwzięć programistycznych i
procesów wytwórczych
planowanie przedsięwzięć programistycznych
analiza i zarzÄ…dzanie ryzykiem
tworzenie i śledzenie harmonogramów
zapewnienie jakość oprogramowania
zarzÄ…dzanie konfiguracjÄ… oprogramowania
20/21
Dziękuję za uwagę
z
ródło:  Praktyczne podejście do inżynierii oprogramowania , R.S. Pressman
21