1

Inżynieria oprogramowania

wykład 8

Zarządzanie konfiguracją

oprogramowania

2/21

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

3/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

4/21

Czego dotyczy zarządzanie
konfiguracją



rezultatem procesu wytwórczego są 3 składniki



program, w formie kodu ź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

5/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

6/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

7/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

8/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 źródłowy,
specyfikacja testów

9/21

Elementy konfiguracji -
przykład

specyfikacja projektu

projekt danych

projekt architektury

projekt modułu

projekt interfejsu

specyfikacja testów

plan testowania

procedura testowania

zestawy testów

model danych

moduł n

opis interfejsu

opis algorytmu

pseudokod

kod źródłowy

zależność

bycie częścią

10/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

11/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)

12/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

13/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

14/21

Graf ewolucji obiektu *



opisuje historię zmian dotyczących obiektu,
który może być wielokrotnie modyfikowany

1.0

1.1

1.2

1.3

1.4

2.1

1.1.1

2.0

1.1.2

pierwsza

modyfikacja

kolejne drobne

modyfikacje

nowa

wersja

poważna

modyfikacja

rozwijane

2 wersje

* A. Gustavsson: Miantaining the evolution of software
objects in integrated enviroment, 1989

15/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

16/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

17/21

Formalna kontrola zmian



odbywa się po oddaniu produktu użytkownikowi

projektant /

programista

baza danych

przedsięwzięcia

rejestracja

kontrola

dostępu

odczytanie

obiekt. konf.,

wersja zmodyf.

dane z

przeglądów

obiekt. konf.,

wersja bazowa

obiekt. konf.,

wersja bazowa

zablokowanie

obiekt. konf.,

wersja pobrana

odblokowanie

dane o prawach

dostępu

18/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

19/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

20/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

21

Dziękuję za uwagę

źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman