Wykład 13

dr in . Włodzimierz D browski

P

olsko

J

apo ska

W

y sza

S

zkoła

T

echnik

K

omputerowych

Katedra Systemów Informacyjnych, pokój 310

e-mail:

[e-mail]

Materiał wył cznie do u ytku przez studentów PJWSTK kursu BYT.

Copyright © 2002 – 2004 by W. D browski - wszelkie prawa zastrze one.

Materiał ani jego cz

nie mo e by w adnej formie i za pomoc jakichkolwiek rodków technicznych reprodukowany bez zgody wła ciciela praw autorskich.

Wersja PB

Budowa i integracja

systemów informacyjnych

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 2

marzec, 2004; PB

Zarz dzanie konfiguracj oprogramowania, ZKO

software configuration management, SCM

Celem zarz dzania konfiguracj oprogramowania jest planowanie,

organizowanie, sterowanie i koordynowanie działa maj cych na celu

identyfikacj , przechowywanie i zmiany oprogramowania w trakcie jego

rozwoju, integracji i przekazania do u ycia.
Ka dy projekt musi podlega konfiguracji oprogramowania. Ma ono

krytyczny wpływ na jako

ko cowego produktu. Jest niezb dne dla

efektywnego rozwoju oprogramowania i jego pó niejszej piel gnacyjno ci.
ZKO jest szczególnie wa ne, je eli projekt mo e toczy si przez wiele lat, je eli

cel lub wymagania na oprogramowanie s niestabilne, je eli oprogramowanie

mo e mie wielu u ytkowników, i/lub je eli oprogramowanie jest przewidziane na

wiele platform sprz towo-programowych.

W takich sytuacjach złe zarz dzanie konfiguracj oprogramowania mo e

całkowicie sparali owa projekt.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 3

marzec, 2004; PB

ZKO powinno zapewnia , e ...

Ka dy komponent oprogramowania b dzie jednoznacznie identyfikowany;
Oprogramowanie b dzie zbudowane ze spójnego zestawu komponentów;
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 .

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 4

marzec, 2004; PB

Zadania kierownictwa projektu w zakresie

ZKO

Kierownictwo projektu jest odpowiedzialne za organizowanie aktywno ci

zwi zanych z ZKO, zdefiniowanie ról personelu (np. bibliotekarza

oprogramowania) oraz przypisanie ról do personelu.
Kierownictwo projektu musi wymaga dokładnej identyfikacji wszystkich

komponentów składaj cych si na projekt oprogramowania i okre lania ich

statusu (np. wst pny, roboczy, zatwierdzony, ko cowy).
Personel rozwijaj cy oprogramowanie powinien dzieli mi dzy siebie

komponenty w sposób bezpieczny i efektywny.
Personel zapewnienia jako ci oprogramowania musi mie mo liwo

ledzenia pochodzenia i rozwijania ka dego komponentu oraz ustalania

kompletno ci i poprawno ci ka dej konfiguracji.
Wdro one przez kierownictwo

procedury lub system ZKO powinny

zapewnia przejrzysto projektu i produktu dla wszystkich zainteresowanych

stron.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 5

marzec, 2004; PB

Pozycja konfiguracji oprogramowania

Wszystkie elementy projektu i oprogramowania musz by przedmiotem

ZKO, w szczególno ci:
dokumentacja: wymaga , analityczna, projektowa, testowania, u ytkownika, itd.
moduły z kodem ródłowym, kody do konsolidowania, kody binarne,
ekrany interfejsu u ytkownika,
pliki z danymi tekstowymi (np. komunikatami systemu), bazy danych, słowniki,

itd.
kompilatory, konsolidatory, interpretery, biblioteki, protokoły, narz dzia CASE,

konfiguracje sprz towe, itd.
oprogramowanie testuj ce, dane testuj ce,
serwery WWW wraz z odpowiednimi stronami HTML i oprogramowaniem,
...
Wyró nialny element uczestnicz cy w projekcie lub produkcie b dzie okre lany

jako

„pozycja konfiguracji”. Jest ona traktowana jako pojedynczy, mo liwy do

odseparowania komponent projektu lub produktu programistycznego.

configuration item

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 6

marzec, 2004; PB

Hierarchia pozycji konfiguracji

A

A

A

A

AA

AA

AA

AC

Wersja 1

Wersja 2

Wersja 3

Wersja 4

AA

AA

AA

AB

AA

AA

AA

AA

Pozycja konfiguracji mo e istnie w wielu wersjach oraz mo e by agregatem

zło onym z pozycji konfiguracji. Wszystkie pozycje konfiguracji, od atomowych

modułów do całkowitej uko czonej wersji oprogramowania, musz by zdefiniowane

tak wcze nie jak to mo liwe i systematycznie oznaczone w momencie utworzenia.

AAA

AAA

AAA

AAA

AAA

AAA

AAA

AAB

AAA

AAA

AAA

ACA

AAA

AAA

AAA

ACB

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 7

marzec, 2004; PB

Aktywno ci ZKO

Identyfikacja pozycji konfiguracji (PK)
Przechowywanie pozycji konfiguracji (PK)
Kontrola zmian konfiguracji
Okre lanie statusu konfiguracji
Przekazanie pozycji konfiguracji na zewn trz (release)

Identyfikacja

PK

Rozwijanie

PK

Zapami tanie

PK

Integracja

PK

Zmiana

PK

Okre lenie

statusu PK

Przekazanie

PK

przyj ta

konwencja

identyfikacji

opis

problemu

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 8

marzec, 2004; PB

Produkt bazowy

baseline

Produktem bazowym jest pozycja konfiguracji oceniona i zaakceptowana

formalnie przez odpowiednie ciało weryfikacyjne jako zako czona, stanowi ca

podstaw do dalszych faz rozwoju projektu.
W szczególno ci, zako czony projekt jest produktem bazowym.
Rozwój projektu post puje od produktów bazowych do kolejnego produktu

bazowego. Produkt bazowy jest podstaw formalnego rozliczenia wykonawców.
Wczesne produkty bazowe zawieraj dokumenty analityczne i projektowe.

Pó niejsze produkty bazowe zawieraj równie kod.
Poszczególne PK w produkcie bazowym musz by wzajemnie spójne.
Produkty bazowe s niemodyfikowalne. S one podstaw wymiany informacji

pomi dzy uczestnikami projektu oraz podstaw testów nowego oprogramowania.
Kluczowe pozycje bazowe s przywi zane do kamieni milowych w planie

zarz dzania projektem.
Nowe produkty bazowe s okre lane w miar integracji nowych komponentów

oprogramowania.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 9

marzec, 2004; PB

Wersje (warianty)

versions (variants)

Termin wersja (lub wariant) jest u ywany dla okre lenia pozycji konfiguracji,

która ma prawie identyczn logik i przeznaczenie, ale ró ni si w pewnych

aspektach, takich jak:
docelowa platforma/konfiguracja sprz towa lub system operacyjny;
protokół komunikacyjny, współdziałanie z innym (zewn trznym)

oprogramowaniem;
j zyk u ytkownika (komend, komunikatów, menu), np. polski, angielski, itd.;
specyficzne wymagania poszczególnych u ytkowników;
post puj ce w czasie ulepszenia;
realizacja celów diagnostycznych i testowych podczas rozwoju oprogramowania.
Istnienie wielu wersji PK znacznie komplikuje zarz dzanie konfiguracjami.

Liczba wersji powinna by minimalizowana. Podstawow metod jest

parametryzowanie wytwarzanego kodu celem zwi kszenia stopnia jego

generyczno ci. Powoduje ona jednak zwi kszenie skomplikowania modułów

oprogramowania. Konieczne jest uzyskanie kompromisu pomi dzy zło ono ci

wytwarzanych modułów oprogramowania a zło ono ci konfiguracji.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 10

marzec, 2004; PB

Konwencja identyfikacji konfiguracji

Pierwszym krokiem w stworzeniu systemu zarz dzania konfiguracj

oprogramowania jest stworzenie

konwencji identyfikacji.

Konwencja identyfikacji jest zbiorem stringów, zwykle zło onym z liter, cyfr i

znaków kropki, /, -, itd. umo liwiaj ca jednoznaczne oznaczenie dowolnej

pozycji konfiguracji.
Konwencja powinna odzwierciedla hierarchiczn struktur pozycji

konfiguracji, rodzaj pozycji i/lub przypisanie pozycji do projektu. Konwencja

powinna odzwierciedla przyj te w danej firmie formularze, dokumenty i kody.
Np. SME/ANA/DW 3.2 oznacza: projekt oznaczony jako SME, pakiet prac

(zadanie) oznaczony ANA, DW oznacza dokument wymaga , 3-cia wersja,

2-ga rewizja.
Konwencja identyfikacji powinna:
• ustala jak nale y nazywa pozycje konfiguracji;
• okre la kto jest odpowiedzialny za nazwanie danej pozycji konfiguracji;
• odwzorowywa (w miar mo no ci) histori danej pozycji konfiguracji.

identification convention

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 11

marzec, 2004; PB

Co nale y identyfikowa jako PK?

Na górnym poziomie cały system/projekt jest PK; powinien on otrzyma unikalny

identyfikator. System/projekt składa si z PK ni szego rz du; zwykle ich

identyfikatory s poprzedzone identyfikatorem PK wy szego rz du.
PK danego projektu mo e wł cza PK innych projektów; w tym przypadku

identyfikacja „obcych” PK nie ulega zmianie.
Na dolnym poziomie znajduj si atomowe PK, np.:

• poszczególne dokumenty analityczne i projektowe;

• jednostki kodu ródłowego i wynikowego (pliki kodu, pliki nagłówkowe, itd.)

traktowane jako niepodzielne przez oprogramowanie narz dziowe (np. kompilator)
PK mog odzwierciedla podział projektu na zadania.
Konfiguracje musz by praktyczne z fizycznego punktu widzenia (t.j. musz by

łatwe do tworzenia, kopiowania, modyfikacji i usuwania) oraz musz by naturalne

z logicznego punktu widzenia (tj. ich cel musi by łatwy do zrozumienia).
Atomowe PK musz mie odpowiednia ziarnisto : zbyt du e s trudne do

manipulowania, zbyt małe powoduj nadmierne rozdrobnienie i w konsekwencji

trudno ci w utrzymaniu i zarz dzaniu.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 12

marzec, 2004; PB

Jak identyfikowa pozycj konfiguracji?

Identyfikator powinien zawiera nazw , typ i wersj PK. Nowy identyfikator nie

mo e implikowa konieczno ci zmiany poprzednich identyfikatorów.
Dobre identyfikatory pozwalaj na szybkie zorientowanie si o jak PK chodzi i na

łatwe jej odszukanie. Dokumenty powinny mie standardowe nazwy.

Identyfikatory kodu powinny uwzgl dnia jego jego hierarchiczn budow .
Identyfikator powinien uwzgl dnia równie typ PK. Trzy podstawowe typy:

• ródłowa PK (np. tekst programu);

• pochodna PK (np. binarny kod programu);

• narz dzie dla generowania pochodnej PK ze ródłowej PK (np. kompilator).
Wszelkie poprawki powinny by dokonywane na wersji ródłowej. Poprawki na

wersji wygenerowanej s niedopuszczalne.
Identyfikatory powinny by wyposa one w numery wersji i rewizji. Ka da, nawet

najmniejsza zmiana powoduje powstanie nowej pozycji z nowym identyfikatorem.
Niektóre schematy zarz dzania konfiguracj rozró niaj „wersje” i „rewizje”.

Rewizje dotycz drobnych zmian, np. usuni cia bł du. W tym przypadku numer

(oznaczenie) wersji składa si z dwóch członów: wersji i rewizji, np, „wersja 5.4”.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 13

marzec, 2004; PB

Odpowiedzialno

za pozycje konfiguracji

Trzy poziomy odpowiedzialno ci:

• autor kodu (programista) lub dokumentacji;

• kierownik projektu;

• ciało kontrolno-rewizyjne.
Du e projekty mog posiada wi cej poziomów, zgodnie z fazami kontroli i

weryfikacji oprogramowania.
Kierownik projektu jest odpowiedzialny za poł czenie PK ni szego poziomu

(kod, dokumentacja) w PK wy szego poziomu (konfiguracje).
PK ni szego poziomu s przechowywane w bibliotece/repozytorium. Kierownik

projektu jest odpowiedzialny za udokumentowanie PK wy szego poziomu. Dobre

repozytorium powinno tak e przechowywa informacj o PK wy szego poziomu.
Dla celów wi kszych projektów konieczne jest powołanie funkcji lub stanowiska

bibliotekarza oprogramowania.
Ciało kontrolno-rewizyjne aprobuje produkty bazowe i zmiany do produktów

bazowych. Ciało to mo e składa si z kierownika projektu, przedstawiciela

klienta, przedstawiciela zarz du firmy, bibliotekarza oprogramowania, personelu

zarz dzania jako ci , itd.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 14

marzec, 2004; PB

Przechowywanie pozycji konfiguracji

Wszystkie pozycje konfiguracji musz by przechowywane w sposób

bezpieczny, systematyczny i dobrze zorganizowany - jak ksi ki w bibliotece.
System przechowywania PK musi dotyczy wszystkich mediów - elektronicznych,

papierowych i innych.
Powinien istnie system ewidencji i rejestracji zale no ci pomi dzy pozycjami

konfiguracji. Dobrze zorganizowany system powinien by oparty na bazie danych

oraz integrowa informacje o PK z samymi (elektronicznymi) PK.
System powinien tak e rejestrowa i przechowywa wszelkie dokumenty

administracyjne zwi zane z projektami oprogramowania, takie jak raporty etapowe

i ko cowe, zlecenia, raporty zaistniałych problemów, raporty z testów, itd.
Dokumenty administracyjne powinny by powi zane z pozycjami konfiguracji w

taki sposób, aby mo na było prze ledzi ich histori oraz zwi zki przyczynowo-

skutkowe pomi dzy dokumentami i pozycjami konfiguracji.
Rodzaje bibliotek konfiguracji oprogramowania:

• biblioteki zwi zane z bie cym rozwojem oprogramowania;

• biblioteki uko czonych (bazowych) produktów programistycznych;

• archiwa (przechowywanie nieaktualnych kodów i dokumentów)

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 15

marzec, 2004; PB

Biblioteki/repozytoria pozycji konfiguracji

Dobrze zorganizowana biblioteka/repozytorium PK jest cech fundamentaln dla

zarz dzania konfiguracjami oprogramowania.
Biblioteka powinna umo liwia łatwe odszukanie, odczytanie, wstawienie,

zast pienie i usuwanie dowolnych pozycji konfiguracji.
Kluczow cech biblioteki jest bezpiecze stwo i autoryzowany dost p:

• zminimalizowanie prawdopodobie stwa nieautoryzowanego dost pu;

• precyzyjne okre lenie praw dost pu poszczególnych uczestników projektów;

• uniemo liwienie jednoczesnej aktualizacji tej samej PK przez dwie osoby;

• uniemo liwienie zmiany pozycji konfiguracji b d cych produktami bazowymi;

• minimum mo liwo ci zniszczenia biblioteki poprzez awari , bł d lub sabota ;

• kwestie bezpiecze stwa nie powinny powodowa : niewygody w pracy

u ytkowników, zwi kszenia czasów dost pu, istotnych nakładów, itd.
Wszystkie PK, elektroniczne i papierowe, musz mie etykiet zawieraj c :

• nazw projektu;

• identyfikator pozycji konfiguracji;

• dat wprowadzenia do repozytorium;

• krótki opis lub charakterystyk zawarto ci PK.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 16

marzec, 2004; PB

Kontrolowanie zmian konfiguracji

Zmiany s rzecz normaln podczas rozwoju i ewolucji systemu. Dobre

zarz dzanie zmianami jest esencj dobrego zarz dzania konfiguracjami.
Zmiany nie powinny prowadzi do utraty informacji. Wszystkie przestarzałe

dokumenty (elektroniczne i papierowe) powinny by archiwizowane.
Osoba odpowiedzialna za zmiany (np. kierownik projektu) koordynuje ich

wprowadzenie.
Repozytorium powinno utrzymywa odpowiednie powi zania pomi dzy PK w taki

sposób, aby było wiadomo, e zmiana jednej PK poci ga za sob zmian innych

PK. Np. zmiana kodu mo e poci ga za sob zmian dokumentacji projektowej,

dokumentacji u ytkownika, planu testów, itd.
Zmiany powinny by zweryfikowane przed wprowadzeniem nast pnych zmian.

Podstaw zmian s odpowiednie dokumenty: formularz zmian w oprogramowaniu

oraz formularz zmian w dokumentacji.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 17

marzec, 2004; PB

Okre lanie statusu konfiguracji

Jest to zapisywanie informacji i sporz dzanie raportów niezb dnych do

efektywnego zarz dzania konfiguracjami, wł czaj c listowanie identyfikatorów

wszystkich zatwierdzonych pozycji, statusu wszystkich proponowanych zmian do

konfiguracji oraz statusu implementacji proponowanych zmian.
Status wszystkich pozycji konfiguracji musi by zapami tany. Istotne jest przede

wszystkim zapis stanu pozycji bazowych.
W tablicy na nast pnym slajdzie pokazano rozwój oprogramowania zgodnie z

produktami bazowymi (kamieniami milowymi); ka da kolumna tablicy odpowiada

pewnej fazie ycia oprogramowania. Elementy tablicy przedstawiaj pozycje

konfiguracji, ich wersje i rewizje.
Tablica taka jest dokumentem przedstawiaj cym status konfiguracji. Mo liwe s

inne formy dokumentowania statusu, o ile s one łatwe do manipulowania i

czytania.
Status konfiguracji powinien by aktualizowany na bie co i powinien by na

bie co dost pny dla wszystkich członków zespołu projektowego. Je eli program

działał poprzedniego dnia, a dzisiaj nie działa, pierwszym pytaniem jest: "co

zostało zmienione?".

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 18

marzec, 2004; PB

Przykład tablicy statusu konfiguracji

PZPO - Plan Zarz dzania Projektem Oprogramowania

PZKO - Plan Zarz dzania Konfiguracj Oprogramowania

PWWO - Plan Weryfikacji i Walidacji Oprogramowania

PZJO - Plan Zapewnienia Jako ci Oprogramowania

DWU - Dokument Wymaga U ytkownika

DWO - Dokument Wymaga na Oprogramowanie.

DAP - Dokumentacja Analityczno-Projektowa

DDP - Detaliczny Dokument Projektowy

DIO - Dokument Instalacji Oprogramowania

Produkty

bazowe

1

2

3

4

5

6

7

Kamienie

milowe

PK

Zatwier-

dzenie

DWU

Zatwier-

dzenie

DWO

Zatwier-

dzenie

DAP

Po redni

produkt

bazowy

Zatwier-

dzenie

DDP

Akcep-

tacja

wst pna

Akcep-

tacja

ko cowa

PZPO

1.0

2.0

3.0

4.0

4.0

4.1

4.2

PZKO

1.0

2.0

3.0

4.0

4.0

4.0

4.0

PWWO

1.0

2.0

3.0

4.0

4.1

4.2

4.3

PZJO

1.0

2.0

3.0

4.0

4.0

4.0

4.0

DWU

1.0

1.1

1.2

1.3

1.4

1.5

1.6

DWO

1.0

1.1

1.2

1.3

1.4

1.5

DAP

1.0

1.1

1.2

1.3

1.4

DDP

1.0

1.1

1.2

1.3

Podr.u ytk.

1.0

1.1

1.2

1.3

Program A

1.0

1.1

1.2

1.3

Program B

1.0

1.1

1.2

1.3

Kompilator

5.2

5.2

5.2

5.2

Linker

3.1

3.1

3.1

3.1

Syst.oper.

6.1

6.1

6.1

6.1

Program C

1.0

1.1

1.2

DIO

1.0

1.0

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 19

marzec, 2004; PB

Recenzje (przegl dy) dokumentów

Dokumenty opisuj ce elementy projektu lub dokumentacja u ytkowa powinna

podlega recenzjom (przegl dom).
W zale no ci od charakteru dokumentu, recenzenci mog rekrutowa si z

wewn trz lub z zewn trz zespołu projektowego.
Zadaniem recenzenta jest znalezienie mo liwie najwi kszej liczby defektów.
Recenzent przedstawia wynik w postaci dokumentu, gdzie zapisuje:

• Identyfikator PK

• Lokalizacj defektu (PK ni szego poziomu, nr strony, nr wiersza,...)

• Opis defektu

• Mo liwy sposób usuni cia defektu (rozwi zania problemu).
Po recenzji (recenzjach) nast puje spotkanie wszystkich zainteresowanych stron,

gdzie po dyskusji podejmuje si decyzj o zmianach w dokumentach lub o ich

zatwierdzeniu.
Dokumenty podlegaj okre laniu statusu na podanych wcze niej zasadach.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 20

marzec, 2004; PB

Wydanie (

opublikowanie

)

release

Ka da pozycja konfiguracji (zwykle cały projekt, ale niekoniecznie), która

jest zako czona i oficjalnie przekazana na zewn trz (zwykle na zewn trz

firmy wytwórcy oprogramowania), jest okre lana jako wydanie (release).
Wydania musz by odpowiednio opisane, udokumentowane i zaaprobowane na

poziomie kierownictwa projektu, kierownictwa firmy oraz klienta.
Pozycje konfiguracji b d ce wydaniami musz by wyra nie oznaczone i

"zamro one" w bibliotece/repozytorium konfiguracji. Identyfikacja i rejestracja

wyda powinna by zgodna z konwencj identyfikacji. Np. konfiguracja

oznaczona SME 1.0 mo e nie by wydaniem, jest nim np. konfiguracja SME 1.4.
Na poziomie firmy wytwórcy oprogramowania wszystkie składniki wydania

(wł czaj c dokumenty analityczne, plany, kody ródłowe, dokumenty

wewn trzne, dokumentacja testowa, itd.) musz by przechowywane jako

składniki wydania. Zwykle tylko pewna cze z tych pozycji konfiguracji jest

przekazana na zewn trz (np. wynikowy kod programu plus dokumentacja).

Pozycje konfiguracji przekazane na zewn trz jako składniki wydania powinny by

odnotowane w bibliotece/repozytorium konfiguracji.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 21

marzec, 2004; PB

Plan Zarz dzania Konfiguracj Oprogramowania

Wszystkie aktywno ci zwi zane z zarz dzaniem konfiguracj oprogramowania dla

danego projektu lub jego fazy powinny by przewidziane w Planie Zarz dzania

Konfiguracj Oprogramowania (PZKO).
Nowe sekcje PZKO musz pojawia si w miar przyst powania do kolejnych faz

rozwoju oprogramowania. Ka da sekcja powinna dokumentowa wszystkie

aktywno ci zwi zane z konfiguracja oprogramowania, w szczególno ci:

• organizacj zarz dzania konfiguracjami;

• procedury do identyfikacji konfiguracji;

• procedury do kontroli zmian;

• procedury do rejestrowania statusu konfiguracji;

• narz dzia, techniki i metody dla zarz dzania konfiguracjami;

• procedury do kontrolowania dostawców;

• procedury do gromadzenia i zachowywania zapisów dotycz cych konfiguracji.
Procedury zarz dzania konfiguracj powinny by ustanowione przed

rozpocz ciem produkcji kodu i dokumentacji.
W miar mo no ci PZKO powinien przewidywa pozycje konfiguracji (b d ce

rezultatem danej fazy rozwoju) oraz ustala ich identyfikacje i odpowiedzialno ci.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 22

marzec, 2004; PB

Zawarto

PZKO

(Wg normy ANSI/IEEE Std 828-

1990)

(1)

a - Streszczenie (maksymalnie 200 słów)

b - Spis tre ci
c - Status dokumentu (autorzy, firmy, daty, podpisy, itd.)

d - Zmiany w stosunku do wersji poprzedniej

Informacje

organizacyjne

1. Wprowadzenie

1.1 Cel

1.2 Zakres

1.3 Słownik terminów, akronimów i skrótów

1.4 Odsyłacze

2. Zarz dzanie

2.1 Organizacja
2.2 Odpowiedzialno ci w zakresie ZKO

2.3 Zarz dzanie interfejsami zewn trznymi

2.4 Implementacja PZKO

2.5 Stosowane strategie, zalecenia i procedury

3. Identyfikacja konfiguracji

3.1 Konwencje

3.2 Produkty bazowe

..... c.d. na nast pnej stronie.....

Zasadnicza

zawarto

dokumentu

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 23

marzec, 2004; PB

Zawarto

PZKO (2)

..... c.d. z poprzedniej strony

4. Kontrola konfiguracji

4.1 Kontrola kodu i dokumentacji

4.2 Kontrola mediów

4.3 Kontrola zmian

4.3.1 Poziomy autoryzacji zmian
4.3.2 Procedury zmian
4.3.3 Ciało (rada, komisja) przegl dowa
4.3.4 Kontrola interfejsów
4.3.5 Procedury zmian oprogramowania obcego

5. Rejestracja statusu konfiguracji

6. Narz dzia, techniki i metody dla ZKO

7. Kontrola dostawców

8. Gromadzenie i przechowywanie zapisów

Zasadnicza

zawarto

dokumentu, c.d.

Numeracja punktów nie powinna by zmieniana. Je eli pewien punkt nie ma tre ci,

powinna tam znajdowa si informacja „Nie dotyczy”.

Informacje nie mieszcz ce si w tym spisie tre ci powinny by zawarte w dodatkach.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 24

marzec, 2004; PB

Omówienie zawarto ci PZKO (1)

1.1 Cel

Krótko omawia cel PZKO (do czego i dla kogo jest przeznaczony).
1.2 Zakres

Okre la z grubsza pozycje konfiguracji b d ce przedmiotem zarz dzania,

aktywno ci zwi zane z konfiguracj , organizacje (zespoły projektowe) do których

plan ma zastosowanie, oraz faz cyklu yciowego, której plan dotyczy.
1.4 Odsyłacze

Zawiera list wszystkich zwi zanych dokumentów, identyfikowanych przez tytuł,

autorów, daty, numery, sygnatury, itp.
2. Zarz dzanie

Sekcja ta opisuje organizacj zarz dzania konfiguracj oraz zwi zane z tym

odpowiedzialno ci oraz role.
2.1. Organizacja

Podsekcja ta identyfikuje role organizacyjne, które mog wpłyn na funkcje

ZKO, np. mened erów projektów, programistów, personel zapewnienia jako ci,

ciała przegl dowe, rewizyjne i akceptacyjne. Opisuje tak e zwi zki pomi dzy

rolami oraz interfejsy z organizacjami klienta/u ytkownika.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 25

marzec, 2004; PB

Omówienie zawarto ci PZKO (2)

2.2 Odpowiedzialno ci w zakresie ZKO
Okre la funkcje w zakresie w zakresie ZKO, za które s odpowiedzialne

poszczególne role organizacyjne (np. identyfikacje PK, przechowywanie, kontrola

zmian, okre lanie statusu. Ustala tak e odpowiedzialno ci w zakresie przegl dów,

audytów i zatwierdze , wł czaj c w to rol u ytkowników w tych czynno ciach.
2.3 Zarz dzanie interfejsami zewn trznymi
Okre la procedury zarz dzania interfejsami do zewn trznego sprz tu i oprogram.,

organizacje zewn trzne udost pniaj ce ten sprz t i oprogram., punkty kontaktowe

z tymi organizacjami, oraz grupy odpowiedzialne za poszczególne interfejsy.
2.4 Implementacja PZKO
Ustanawia kluczowe elementy w zakresie wdro enia PZKO, m.in. gotowo

systemu ZKO do u ycia, ciała przegl du oprogram., produkty bazowe, wydania

produktu, itd.
2.5 Stosowane strategie, zalecenia i procedury
Identyfikuje wszystkie maj ce zastosowanie strategie konfiguracji oprogram.,

zalecenia i procedury b d ce składow PZKO, oraz okre la ich interpretacj .

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 26

marzec, 2004; PB

Omówienie zawarto ci PZKO (3)

3.1 Konwencje
Okre la konwencj w zakresie nazywania PK etykietowania PK.
3.2 Produkty bazowe
Dla ka dego produktu bazowego sekcja ta okre la:
• identyfikator;
• zawarto , np. oprogramowanie, narz dzie, oprogramowanie testowe, raporty o

niezgodno ci, zgłoszenie problemu, itp. dokumenty;
• interfejsy do produktu bazowego;
• zdarzenia zwi zane z przegl dami i akceptacj ;
• uczestnictwo producentów i u ytkowników podczas okre lania produktu

bazowego.
Opis ka dego produktu bazowego powinien wyró nia oprogramowanie, które jest

ponownie u yte lub zakupione, definiowa rodowisko sprz towe, oraz okre la

PK b d ce składnikami produktu bazowego.

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 27

marzec, 2004; PB

Omówienie zawarto ci PZKO (4)

4.1 Kontrola kodu i dokumentacji
Okre la procedury dla zarz dzania bibliotek kodów i dokumentacji: bibliotek

rozwoju oprogramowania, bibliotek główn (produktów bazowych, wyda ) oraz

archiwum.
4.2 Kontrola mediów
Okre la na jakich no nikach i gdzie fizycznie b d przechowywane poszczególne

PK (dysk serwera, ta ma magnetyczna, dyskietki, dyski optyczne, szafy z

dokumentami papierowymi, itd.). Okre la tak e konwencj etykietowania

poszczególnych mediów (np. ta m, dyskietek, dysków optycznych, okre la sposób

i miejsce ich przechowywania (szafy pancerne, sejfy bankowe, itd.) oraz zasady

recyklingu mediów (kiedy dane medium mo e by ponownie u yte).
4.3 Kontrola zmian; 4.3.1 Poziomy autoryzacji zmian
Okre la poziom autorytetu, który mo e zarz dzi zmian do danego produktu

bazowego (bibliotekarz, kierownik projektu, itd.)
4.3 Kontrola zmian; 4.3.2 Procedury zmian
Okre la w jaki sposób zmiany b d nanoszone (kto, kiedy, jak).

W.D browski, Budowa i integracja systemów informacyjnych, Wykład 13, Slajd 28

marzec, 2004; PB

Omówienie zawarto ci PZKO (5)

4.3 Kontrola zmian; 4.3.3 Ciało (rada, komisja) przegl dowa
Okre la członków ciała przegl dowego, poziomy autorytetów, delegacje

uprawnie do ni szych poziomów.
5. Rejestracja statusu konfiguracji
Definiuje w jaki sposób b dzie zbierana, przechowywana i przetwarzana

informacja o PK, okre la okresowe raporty dotycz ce statusu PK.
6. Narz dzia, techniki i metody dla ZKO
Okre la narz dzia (np. repozytoria oprogramowania, takie jak CVS lub ClearCase)

oraz metody (np. metodyki), które b d u yte do ZKO.
7. Kontrola dostawców
Okre la zadania z zakresie ZKO, które b d wykonane przez zewn trznych

dostawców.
8. Gromadzenie i przechowywanie zapisów
Okre la które pozycje konfiguracji b d przechowywane, w jaki sposób, i jak

długo.