Aplikacja wspomagająca funkcjonowanie

firmy transportowej

Plan Zarządzania Konfiguracją

dla Firma Transportowa „CMX”

Historia zmian

Data	Wersja	Opis zmiany	Autor
6/12/08	1.0	Zapoznanie się z szablonem i wyznaczenie celów	Stańczuk Sławomir
7/12/08	1.1	Opis punktów 1 i 2	Stańczuk Sławomir
10/12/08	1.2	Dokończenie pracy nad rozdziałem	Stańczuk Sławomir

Spis treści

1. Wprowadzenie

Plan Zarządzania Konfiguracją

1. Wprowadzenie

Projektowany system dla firmy transportowej w swojej rozpiętość będzie musiał spełniać założenia projektu przez wiele lat i na wielu stanowiskach roboczych. W celu sprawnego działania obsługi technicznej i programistycznej system potrzebny jest Plan Zarządzania Konfiguracją.

W prezentowanym planie zarządzania konfiguracją znajdziemy informacje dotyczące identyfikacji, kontroli wersji, organizacji odpowiedzialności za publikowanie nowych wersji systemu oraz sposobu ich kontroli i akceptacji. Każdy system podawany jest ulepszeniom w dążeniu do perfekcji wykonania, aby każda kolejna zmiana w systemie była jasna dla wszystkich osób związanych z jego tworzeniem potrzebny jest jasny opis zmian oraz polityka archiwizacji dla bezpieczeństwa systemu.

1. Cel

Celem Planu Zarządzania Konfiguracji jest umożliwić członkom Zespołu projektowego i wszystkim, którzy będą użytkowali produkt sprawdzenie, czy posiadają właściwą wersję i umożliwienie śledzenie statusu każdego produktu i zapisywanie śladu rewizyjnego.

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.

2. Zakres

Plan Zarządzania dokumentacją i procedury w nim zawarte powinny być ustalone jeszcze przed rozpoczęciem produkcji kodu i dokumentacji. Wszelkie przejawy zarządzania konfiguracją oprogramowania muszą opierać się na opisanych poniżej schematach i procedury. Ich przestrzeganie jest obligatoryjne na każdym szczeblu prowadzenia projektu. 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.

1. Definicje, akronimy i skróty

2. Dokumenty powiązane

Plan Zarządzania Projektem

Data oddania: 27.11.2008

Osoba odpowiedzialna: Katarzyna Kolbrecka

Źródło: załącznik

Plan komunikacji - szablon

Data oddania: 9.12.2008

Osoba odpowiedzialna: Małgorzata Jaworska

Źródło: załącznik

Plan Zarządzania Ryzykiem

Data oddania: 27.11.2008

Osoba odpowiedzialna: Małgorzata Jaworska

Źródło: załącznik

Źródło: załącznik

Plan testów

Data oddania: 4.12.2008

Osoba odpowiedzialna: Maciej Koltermann

Źródło: załącznik

Plan zarządzania konfiguracją

Data oddania: 15.12.2008

Osoba odpowiedzialna: Sławomir Stańczuk

Źródło: załącznik

Plan Zapewnienia Jakości

Data oddania: 27.11.2008

Osoba odpowiedzialna: Sandro (…)

Źródło: załącznik

3. Organizacja dokumentu

W dalszej części planu zarządzania projektem znajduje się identyfikacja konfiguracji projektowej, sposób przetwarzania zgłoszeń zmian i ich akceptacji, skład i funkcja Ciała Kontrolnego Zmian oraz charakterystyka planu archiwizacji systemowej.

2. Zarządzanie konfiguracją oprogramowania

1. Organizacja, odpowiedzialności oraz interfejsy

Trzy poziomy odpowiedzialności:

• autor kodu (programista)

Programista główny- Odpowiedzialny za implementację systemu zgodnie z przedstawionym projektem, a także za koordynację pracy podległych mu programistów oraz przekazywanie im dokładnych instrukcji.

Programista - Odpowiedzialny za implementację systemu zgodnie z przedstawionym projektem

• kierownik projektu;

Kierownik projektu - jest odpowiedzialne za organizowanie aktywności związanych z ZKO, zdefiniowanie ról personelu oraz przypisanie ról do personelu. Kierownik 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). Jest odpowiedzialny za połączenie PK niższego poziomu (kod, dokumentacja) w PK wyższego poziomu (konfiguracje).

• ciało kontrolno-rewizyjne.

W skład tego ciała wchodzi właściciel firmy, czyli zleceniodawca i kierownik projektu,

Konserwator oprogramowania - Odpowiedzialny za etap instalacji i przeszkolenia przyszłych użytkowników systemu, oraz za konserwację oprogramowania po etapie instalacji. Współpracuje z programistami

1. Narzędzia, środowisko oraz infrastruktura

Do prawidłowego funkcjonowania systemu wymagane są:

• Komputer z procesorem Intel Pentium II lub szybszy,

• 1024 MB pamięci operacyjnej RAM,

• 8 GB wolnej przestrzeni na dysku twardym,

• Karta grafiki obsługująca 128 MB pamięci RAM lub lepsza,

• Przeglądarka internetowa Explorer wersja 7 lub Mozilla FireFox wersja 3,

• System nie działa pod platformami Linux/Unix.

• Wymagana jest platforma Windows. System współpracuje z Microsoft Windows, wersja: 98, 2000, XP, Vista.

Narzędzie służące do wersjonowania artefaktów powstających na przestrzeni całego projektu.

TortoiseSVN - przykładowy klient SVN

Integracja z ExploratoremWindows

_ Dostęp do poleceń przez menu kontekstowe

_ Znaczniki na ikonach folderów/plików o ich aktualności

_ Wbudowane narzędzia:

• TortoiseDiff

• TortoiseMerge

• TortoiseBlame

• Revision Graph

• słownik

_Licencja GNU GPL

http://tortoisesvn.net/

Cały system wraz z plikami instalacyjnymi będzie zajmował od kilku do kilkunastu MB pamięci. Składowany będzie na serwerze firmowym zleceniodawcy. Programiści przy swoich indywidualnych stanowiskach będą łączyć się z serwerem przez Internet w celu synchronizacji wersji systemu, aby pliki, na których pracują były zawsze aktualne.

3. Plan Zarządzania Konfiguracją

1. Identyfikacja konfiguracji

1. Metody identyfikacji

Każda wersja produktu lub rzeczy posiada, następujące identyfikatory, aby zapewnić minimalny poziom kontroli:

 Data wytworzenia/rejestracji

 Typ/Nr wersji (szkic, nn:nn)

 Numer kopi lub nazwisko właściciela

 Nazwa dokumentu lub produktu

 Nazwa pliku, jeśli dotyczy pliku

• Miejsce składowania

• Nazwa skrócona:

Sposób nazewnictwa, tworzenia nazwy skróconej:

Każda nazwa rozpoczyna się od przedrostka w przypadku

hardware'u: „ha-“

software-u: “sof-“

plany: “plan-“

model: “mod-“

komponenty: “kompo-“

oprogramowanie testujące: “oprotest-“

pliki wykonywalne: „plik-„

Później jego nazwa własna. Nazwa skrócona kończy się numerem wersji w systemie konfiguracji po sleszu „/”. W chwili rejestracji nadawana jest jej wersja 1 każda aktualizacja zwiększa wersję, a każda zmiana zwiększa wariant.

Przykład: ha-dysk twardy 3.5 cala 80GB/1

1. Wytyczne projektowe

Na początku każdego etapu projektowego pracy tworzone są wytyczne projektowe obowiązujące w danym etapie. Kierownik projektu uprawniony jest do autoryzacji wytycznych .

1. Zarządzanie Konfiguracją i Zmianą

1. Przetwarzanie zgłoszenia zmiany oraz jej akceptacja

Kierownik projektu po otrzymaniu wniosku o zmianie lub akceptacji zmian spotyka się z głównym programistą w celu przeglądu zgłoszonych wniosków. Podczas tego spotkania podejmowane są decyzje o sposobie i formie rozwiązania problemu. Na zakończenie spotkania sporządzany jest protokół zawierający instrukcje naprawcze dla programistów.

2. Ciało Kontroli Zmian (CKZ)

Ciało kontroli zmian składa się z kierownika projektu oraz zleceniodawcy lub przedstawiciela firmy. Ciało kontrolno-rewizyjne aprobuje produkty bazowe i zmiany do produktów bazowych i systemowych. CKZ otrzymuje zgłoszenie zmiany po rozpatrzeniu jego zasadności akceptuje je lub nie. Po zakończeniu zebrania CKZ zapisywany jest protokół spotkania, a kierownik projektu publikuje listę zmian zaakceptowanych od poprzedniej wersji do użytku wszystkich osób związanych z systemem.

2. Archiwizacja stanu konfiguracji

1. Przechowywanie projektu oraz proces publikacji produktu (release)

Proces publikacji kolejnej wersji system jest zawsze zapoczątkowany od wprowadzenia zmian do systemu. Każde wydania jest odpowiednio opisane, udokumentowane i zaaprobowane na poziomie kierownika projektu oraz klienta właściciela firmy

Pozycje konfiguracji są wydaniami wyraźnie oznaczone i "zamrożone" w repozytorium konfiguracji. Identyfikacja i rejestracja wydań jest 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.) są przechowywane jako składniki wydania. Jednak tylko pewna cześć z tych pozycji konfiguracji jest przekazana na zewnątrz, przeważnie wynikowy kod programu plus dokumentacja. Pozycje konfiguracji przekazane na zewnątrz jako składniki wydania są odnotowane w repozytorium konfiguracji.

Wszelkie aktywności jak spotkania, przeglądy, przejścia, audyty, notatki, korespondencja,

wykryte błędy i ich korekcje powinny być dokumentowane. Co tydzień wszystkie dokumenty pakowanie są do pliku .zip i archiwizowane online na serwerze. Raz w miesiącu zebrane dokumenty są wypalane na płytach CD, każda płyta nagrywana jest podwójnie, aby zapobiec ewentualnej utracie danych.

Płyty archiwizowane są w specjalnie przeznaczonym pomieszczeniu, do którego dostęp ma tylko jeden pracownik firmy, odpowiedzialny za utrzymanie archiwum.

Dokumentacja przechowywana jest przez pięć lat od momentu archiwizacji.

2. Raporty oraz audyty

Wyprodukowane oprogramowanie musi podlegać późniejszym przeglądom i audytom. Wykonywane one będą przez przeznaczone specjalnie do tego komórki, składające się najlepiej z osób zaangażowanych czynnie w każdą fazę tworzenia oprogramowania - oni najlepiej zorientują się w ograniczeniach i ukrytych wadach produktu, które nie zostały dostrzeżone w procesie testowania.

Jednostka ta może także składać raporty kierownikowi zakończonego projektu w celu przedstawienia wszelkich uwag i sugestii dotyczących możliwych późniejszych nowych wersji systemu i ich modyfikacji. Dostrzeżone wady i błędy nie zostaną tak szybko naprawione, jak w czasie budowy systemu, ale jest duża szansa, że w nowych wersjach oprogramowania się nie powtórzą.

Szablony raportów

• Szablon o czasie (czas wykrycia i naprawy defektu) :

Raport „Wiek”

dotyczący wykonywania zadań

Data :

Nazwa grupy :

Osoba wypełniająca :

Opis defektu:

Data wykrycia:

Data naprawienia:

Osoby odpowiedzialne :

Procent zaawansowania :

Priorytet:

Uwagi :

• Szablon rozproszenia (aktualna ilość defektów w projekcie i procent zaawansowania napraw):

Raport rozproszenia

dotyczący wykonywania zadań

Data :

Nazwa grupy :

Osoba wypełniająca :

Ilość defektów:

Procent zaawansowania :

Uwagi :

• Szablon o raportu Trendu (ilość defektów, czas naprawy, stopień wykrywalność ) :

Raport „Wiek”

dotyczący wykonywania zadań

Data :

Nazwa grupy :

Osoba wypełniająca :

Łączna ilość defektów:

Łączna ilość naprawionych defektów:

Średni czas naprawy defektów:

Stopień wykrywalności błędów:

Uwagi :

4. Kamienie milowe

Kamieniem milowym planu zarządzania konfiguracją jest wystąpienie sytuacji wcześniej nie sklasyfikowanej, momentu kiedy dostępne szablony i procedury nie definiują jednoznacznie czynności które powinna wykonać osoba zgłaszająca lub wykonująca daną czynność.

5. Szkolenia i zasoby

Szkolenia będą prowadzone przez konserwatora oprogramowania na prośbę zleceniodawcy dla jego pracowników w terminie ustalonym z kierownikiem projektu. Zakres tematyczny, czas i przeznaczenie szkoleń będzie ustalany przez kierownika projektu w porozumieniu z zleceniodawcą.

6. Kontrola podwykonawców oraz dostawców oprogramowania

Każdy produkt dostarczony przez dostawców jest sprawdzany pod kontem ogólnie przyjętych norm.

Przedstawienie wszystkich norm aktualnie stosowanych i wymaganych od dostawców. Rolę kontrolera pełni główny programista i jego zadaniem jest aby prace wykonane przez podwykonawców były poprawne i integralne z systemem.

CMX

Aplikacja wspomagająca funkcjonowanie firmy transportowej	Wersja: 1.0
Plan Zarządzania Konfiguracją	Data: 10.12.2008
Konfiguracja dla “CMX”

Poufne

©CMX 2009

Strona 2

---