PROJEKT SYSTEMU ZARZĄDZANIA W FIRMIE RADIX

Transkrypt

1 POLITECHNIKA GDAŃSKA WYDZIAŁ ZARZĄDZANIA I EKONOMII PRACA DYPLOMOWA magisterska PROJEKT SYSTEMU ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA W FIRMIE RADIX autor: inż. Adam Czarnecki promotor: dr inż. Cezary Orłowski Gdańsk, maj 2004

2

3 Spis treści 1. WSTĘP ANALIZA LITERATURY DEFINICJE, SKRÓTY I AKRONIMY NORMY DOTYCZĄCE ZARZĄDZANIA KONFIGURACJĄ I ICH PORÓWNANIE MODELE CYKLU ŻYCIA OPROGRAMOWANIA WNIOSKI Z ANALIZY LITERATURY ANALIZA STANU ISTNIEJĄCEGO PODSTAWOWE INFORMACJE O FIRMIE OFERTA OBECNE ROZWIĄZANIA I PROBLEMY W ZAKRESIE ZKO WNIOSKI Z ANALIZY STANU ISTNIEJĄCEGO SYSTEM ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT INFORMACJE OGÓLNE ORGANIZOWANIE ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA CZYNNOŚCI PRZY ZARZĄDZANIU KONFIGURACJĄ OPROGRAMOWANIA HARMONOGRAM ZKO ZASOBY ZKO DOBÓR NARZĘDZI CHARAKTERYSTYKA APLIKACJI DO ZKO KRYTERIA OCENY APLIKACJI ZKO WYNIKI OCENY PODSUMOWANIE BIBLIOGRAFIA SPIS RYSUNKÓW SPIS TABEL SPIS ZAŁĄCZNIKÓW I. Spis treści I

4

5 1. Wstęp Radix jest gdańską firmą powstałą w 1986 roku. Zajmuje się wytwarzaniem, wdrażaniem i szkoleniem w zakresie użytkowania oprogramowania dla administracji publicznej, głównie samorządów. Problemem podjętym w pracy są trudności firmy Radix z zarządzaniem konfiguracją przy dużej liczbie kolejnych wersji produkowanego oprogramowania oraz przy nowych warunkach pracy polegających na podziale konkretnych projektów pomiędzy kilku programistów. Celem pracy jest opracowanie projektu systemu zarządzania konfiguracją oprogramowania, który spełniłby oczekiwania firmy Radix, a także dobór narzędzi służących jego wdrożeniu. Podstawę dla powyższego ma stanowić analiza literatury i dotychczasowej praktyki firmy w zakresie opisywanego elementu zarządzania przedsięwzięciem informatycznym. Zaproponowane rozwiązanie oparto głównie na kaskadowym cyklu życia oprogramowania oraz normie ANSI/IEEE Std Odbiorcą wyników pracy jest firma Radix. 1. Wstęp 1

6 2. Analiza literatury W rozdziale tym przybliżone zostanie pojęcie zarządzania konfiguracją oprogramowania jako elementu zarządzania jakością w przedsięwzięciu informatycznym oraz terminów z nim związanych. Następnie przedstawione będą normy regulujące tworzenie planów zarządzania konfiguracją. Spośród nich wskazana zostanie jedna, najbardziej przydatna dla osiągnięcia celu pracy. Dalsza część rozdziału poświęcona będzie modelom cyklu życia oprogramowania ze wskazaniem najbardziej optymalnego z punktu widzenia zarządzania konfiguracją w firmie Radix. Norma wraz z modelem niczym wątek i osnowa powinny stworzyć przestrzeń dla projektu systemu Definicje, skróty i akronimy Poniżej zaprezentowano definicje pojęć związanych z zarządzaniem przedsięwzięciami informatycznymi, a kwestiami konfiguracji oprogramowania w szczególności, oraz skróty i akronimy z tym związane. W dalszej części pracy mogą znaleźć się informacje precyzujące i odnoszące definicje do specyfiki projektu Skróty i akronimy Skróty i akronimy używane w tej pracy: BSD Berkeley Software Distribution CPL Common Public License FTP File Transfer Protocol FZPB formularz zatwierdzania produktu bazowego FŻZ formularz żądania zmiany GNU GNU's Not Unix GPL General Public License GUI Graphics User Interface HTTP HyperText Transfer Protocol IP Internet Protocol JP jednostka programowa MPP metoda porównywania parami PB produkt bazowy PK pozycja konfiguracji PZK(O) plan zarządzania konfiguracją (oprogramowania) SWS specyfikacja wymagań systemowych 2. Analiza literatury 2

7 TCP ZK(O) ŻZ Transmission Control Protocol zarządzanie konfiguracją (oprogramowania) żądanie zmiany Definicje Zarządzanie konfiguracją (ZK) (ang. configuration management, CM) to dyscyplina stosująca techniczne i administracyjne wskazówki i nadzór w celu identyfikacji i dokumentacji fizycznych cech pozycji konfiguracji, kontroli nad zmianami tych cech, rejestracji i raportowania przebiegu zmian i statusu wdrażania oraz dla weryfikacji zgodności z określonymi wymaganiami [STSC 1999, s. 44]. Definicja [ANSI/IEEE Std ] podkreśla następujące aspekty ZK (rys. 2.1): identyfikację: schemat identyfikacji odzwierciedla strukturę produktu, rozróżnia składniki i ich typ, czyni je unikatowymi i dostępnymi w określonej postaci, kontrolę: kontrolowanie wydań (ang. release) produktu oraz jego zmian (poprawek i wersji) w cyklu życia oprogramowania poprzez nadzór w miejscu, które zapewnia spójność oprogramowania dzięki tworzeniu produktu stanowiącego podstawę odniesienia (produkt bazowy), rejestrowanie statusu (ang. status accounting): zapisywanie i raportowanie statusu składników i żądań zmian, gromadzenie istotnych statystyk o elementach składowych produktu, przegląd: sprawdzanie kompletności produktu i utrzymywanie spójności pomiędzy elementami składowymi poprzez zapewnienie, że produkt informatyczny jest poprawnie zbudowanym zbiorem elementów. ZARZĄDZANIE KONFIGURACJĄ OPROGRAMOWANIA Identyfikacja Kontrola zmian Rejestrowanie statusu Przeglądy Źródło: [STSC 1999, s. 10]. Rysunek 2.1 Elementy składowe zarządzania konfiguracją oprogramowania. W związku z istnieniem wielu platform środowiska programistycznego, zwiększającą się skalą przedsięwzięć informatycznych oraz równoległą pracą wielu zespołów 2. Analiza literatury 3

8 nad jednym projektem, postuluje się poszerzenie definicji ZK o następujące elementy [Brown, Dart i in. 1991, s. 3]: wytwarzanie: zarządzanie konstruowaniem i budową produktu w sposób efektywny i optymalny, zarządzanie procesami: zapewnienie wypełniania przez organizację procedur, założeń i stosowanie się do modelu cyklu życia, praca zespołowa: kontrola pracy i współdziałania pomiędzy wieloma użytkownikami produktu. Ta praca skupia się na zarządzaniu konfiguracją oprogramowania (ZKO) (ang. software configuration management, SCM). Stanowi ono mechanizm do identyfikowania, nadzorowania i śledzenia różnych wersji każdej jednostki programowej [PN- ISO , s. 21] na wszystkich etapach cyklu życia systemu informatycznego [STSC 1999, s. 10]. Pozycja konfiguracji (PK) (ang. configuration item, CI) to pojedynczy, możliwy do odseparowania komponent projektu lub produktu programistycznego [Subieta 2000, wykład 15, folia 5]. Zatem jest to wielkość atomowa z punktu widzenia ZKO. Jednostka programowa (JP) (ang. software item, SI) to dowolna część wyrobu programowego identyfikowana podczas pośredniego lub końcowego etapu opracowywania [PN-ISO , s. 5]. W niniejszej pracy przyjmuje się, że jednostka programowa jest szczególnym rodzajem pozycji konfiguracji. Produkt bazowy (PB) (ang. baseline) to pozycja konfiguracji oceniona i zaakceptowana formalnie przez odpowiednie ciało weryfikacyjne jako kompletna, stanowiąca podstawę do dalszych faz rozwoju projektu i której zmiana może być dokonana tylko poprzez odpowiednią procedurę kontroli zmiany [STSC 1999, s. 39]. Jedną z najwcześniej pojawiających się w przedsięwzięciu pozycji konfiguracji jest specyfikacja wymagań systemowych (SWS) (ang. System Requirements Specification, SRS). Ten dokument to część kontraktu pomiędzy klientem a wykonawcą, który stanowi podstawę dla projektu wytworzenia systemu i bazę, na której wykonawca szacuje koszt i czas trwania projektu [Górski 2000, s. 72]. Definicja zarządzania konfiguracją odwołuje się do pojęcia weryfikacji (ang. verification). W odniesieniu do oprogramowania oznacza ono proces oceny wyrobów danego etapu w celu zapewnienia prawidłowości i zgodności, w odniesieniu do wyro- 2. Analiza literatury 4

9 bów i norm dostarczonych jako dane wejściowe do tego etapu [PN-ISO , s. 5]. Walidacja, zatwierdzenie, atestowanie (w odniesieniu do oprogramowania) (ang. validation): to trzy nazwy procesu często idącego w parze z weryfikacją, a oznaczającego ocenę oprogramowania w celu zapewnienia zgodności z określonymi wymaganiami [PN-ISO , s. 5]. Na koniec warto wprowadzić pewne rozróżnienie między trzema zbliżonymi definicjami. Wydanie (ang. release) to pozycja konfiguracji przekazana na zewnątrz (zwykle na zewnątrz firmy wytwórcy oprogramowania); także czynność takiego przekazania [Subieta 2000, wykład 15, folia 20]. Pojęcie wydania jest zbliżone, lecz nie tożsame z terminami poprawka i wersja, gdyż poprawka (ang. revision) odnosi się zazwyczaj do zmienionej PK, a wersja (ang. version) do takiej poprawki, którą można uznać za znaczącą zmianę w stosunku do poprzedniej treści pozycji konfiguracji Normy dotyczące zarządzania konfiguracją i ich porównanie Jakkolwiek zarządzanie konfiguracją oprogramowania nie jest czynnością narzuconą firmom przez prawo, istnieją jednak normy ten obszar regulujące i zalecane do stosowania. Ogólną zaletą korzystania z norm w przypadku zarządzania konfiguracją jest łatwiejsza współpraca pomiędzy wieloma zespołami projektowymi z różnych firm, gdzie jednolity schemat ZK ułatwia czy wręcz umożliwia koordynowanie wspólnego projektu. Druga kwestia ma związek z opracowanym przez Instytut Inżynierii Oprogramowania Uniwersytetu Carnegie Mellon z Pittsburgha modelem oceny dojrzałości firmy informatycznej (ang. The Capability Maturity Model for Software, SW-CMM) [Paulk, Curtis i in. 1993]. Zgodnie z istniejącą w nim pięciostopniową gradacją, drugi stopień dojrzałości (tzw. powtarzalny, ang. repeatable) może osiągnąć to przedsiębiorstwo, które pośród wielu innych wymagań stosuje zarządzanie konfiguracją oprogramowania [Paulk, Curtis i in. 1993, s. 31], najlepiej zgodną z oficjalną normą. Pytanie brzmi: którą normę wybrać? Istnieje wiele norm dotyczących ZKO i różny jest zakres ich stosowania. Od norm wewnętrznych firm, przez branżowe (np. dla elektrowni atomowych [NUREG ]), po ogólnokrajowe i światowe. W niniejszym rozdziale przedstawione zostanie porównanie trzech amerykańskich norm [Bounds, Dart 1993]: 2. Analiza literatury 5

10 IEEE Standard for Software Configuration Management Plans [ANSI/IEEE Std ], NASA Software Configuration Management Plan Data Item Description [NASA Sfw DID ], DoD Software Development Plan Data Item Description (DID) w powiązaniu z DoD-STD-2167A [DoD DI-MCCS-80030A 1986]. O wyborze do porównania wyłącznie norm opracowanych w Stanach Zjednoczonych zadecydowały dwa powody. Po pierwsze, USA są liderem w zakresie rozwiązań informatycznych, zatem wypracowane w tym kraju tzw. dobre praktyki w zakresie inżynierii oprogramowania wydają się być najbardziej rozwinięte. Po drugie zaś, amerykańskie normy w odróżnieniu od, na przykład, europejskich są powszechnie dostępne i dzięki swojej popularności pozwalają zachować zgodność procedur pomiędzy różnymi wytwórcami oprogramowania, którzy mieliby w przyszłości współpracować. Wyrażając to mniej formalnie i przewrotnie, można napisać, że normy amerykańskie są powszechnie stosowane, gdyż posiadają najwięcej zalet, zaś jedną z największych jest ich powszechne stosowanie Kryteria porównania Jak zaznaczono, przedstawione w niniejszej pracy porównanie zostało dokonane przez Nadine M. Bounds i Susan A. Dart [1993]. Poniżej skrótowo przedstawione zostaną kryteria, jakie posłużyły autorkom do oceny trzech opisywanych norm. Nie przydzielono im żadnych wag, zatem przy przedstawionej później ocenie ich wpływ na wynik będzie taki sam Łatwość posługiwania się Pojęcie łatwości posługiwania się odnosi się do wymaganego wysiłku, jaki należy wnieść, by nauczyć się korzystać z normy oraz jaki konieczny jest przy kolejnym używaniu. Wśród cech opisywanego kryterium warto wskazać na przydatność normy dla osób o różnym stopniu doświadczenia w tworzeniu planów ZKO. Idealna byłaby norma, która potrafiłaby poprowadzić przez cały proces osobę mało lub wcale niedoświadczoną, a jednocześnie jej układ pozwalałby ekspertowi na szybki dostęp i wgląd do interesujących go zagadnień bez konieczności przeglądania całego dokumentu. Z wywiadu przeprowadzonego w firmie Radix wynika brak doświadczenia w stosowaniu procedur 2. Analiza literatury 6

11 ZKO, stąd warto zadbać, aby wprowadzający je dokument sam w sobie nie stanowił utrudnienia w korzystaniu Kompleksowość Za kompleksową należy uznać taka normę, która nie wymaga od korzystającego z niej zaglądania do innych źródeł ani proszenia innych o pomoc w trakcie opracowywania planu ZKO. Jest to dość ogólnikowe wyjaśnienie, zatem można rozszerzyć je wymieniając składniki, jakie obowiązkowo musi posiadać norma, by uznać ją za kompletną: opis części składowych planu ZK, a w szczególności: wprowadzenie i cel dokumentu, organizację ZK i podział kompetencji, identyfikację konfiguracji, kontrolę konfiguracji, rejestrowanie i raportowanie zmian w statusie konfiguracji, opis przeglądów/audytów konfiguracji w ZK, opis harmonogramów i kamieni milowych w ZK, jasno określony cel i odbiorców, czytelną, zwięzłą, prostą i sensowną zawartość, bez żadnych dwuznaczności. Listę można by oczywiście rozbudować o zalecenia o charakterze bardziej edytorskim niż merytorycznym [Bounds, Dart 1993, s ], jednak w tym miejscu zostaną one pominięte jako poboczne w stosunku do projektowanego systemu zarządzania konfiguracją oprogramowania Możliwość dopasowania Możliwość dopasowania oznacza, że normę można dostosowywać do potrzeb projektu. Minimum wymagań to: 2. Analiza literatury 7

12 możliwość usunięcia z planu elementu, który nie ma zastosowania w danym przedsięwzięciu, możliwość dowolnego kształtowania układu planu ZK, tak by jak najlepiej pasował do przedsięwzięcia. Cechy bardziej zaawansowanej normy to możliwość dostosowania jej do: każdego obszaru, jakiego dotyczy przedsięwzięcie informatyczne, dowolnego modelu lub fazy cyklu życia przedsięwzięcia, stosowania przy aplikacjach, sprzęcie i oprogramowaniu układowym (ang. firmware) Konsekwencja Normę można uznać za konsekwentną, jeśli nadano jej czytelną, jednolitą strukturę. Musi ona spełniać co najmniej poniższe warunki: standardowy format reprezentacji treści, standardowe nazewnictwo i posługiwanie się pojęciami, ten sam element ZK lub pojęcie nie są określane przez więcej niż jedną unikatową nazwę i nie są definiowane przez więcej niż jeden zestaw charakterystyk Poprawność Norma jest uważana za poprawną, gdy zawiera jedynie ważne i prawdziwe informacje. Wydawać by się mogło, że samo słowo norma wskazuje na dokument, który powinien wcześniej przejść przez procedurę weryfikacyjną wykluczającą istnienie jakichkolwiek niepoprawnych danych. Tak jest w przypadku norm krajowych lub branżowych, gdzie pisaniem norm zajmują się uznani eksperci, a i wiele szczebli musi pokonać dokument przed ostatecznym zatwierdzeniem. Jeśli jednak standard opracowywany jest wewnątrz firmy, nawet dużej, to może on posiadać formalne lub merytoryczne braki lub nieścisłości, które co prawda nie przeszkadzają osobom znającym stan faktyczny w jego stosowaniu w macierzystym przedsiębiorstwie, ale mogą utrudniać lub uniemożliwiać podążanie za wytycznymi przez osobę opierającą swoją wiedzę tylko na treści normy. Wskazując na minimalne wymagania wobec tego kryterium, stwierdza się, że norma jest poprawna, gdy: 2. Analiza literatury 8

13 nie zawiera żadnych błędnych informacji, nie zawiera żadnych sprzecznych informacji. Rozszerzając wymagania wobec normy, można żądać, aby: zawierała wyłącznie informacje niezbędne do zrozumienia tematu; niedostatek informacji zmusza użytkownika normy do poszukiwania informacji u innych źródeł; informacje zbędne lub zbyt rozbudowane, natomiast, utrudniają koncentrację na zagadnieniach naprawdę istotnych, zaproponowane w niej podejście miało sens zarówno z technicznego jak i praktycznego punktu widzenia Nawiązanie do cyklu życia Norma powinna wskazywać, jakie jest umiejscowienie planu ZKO w cyklu życia projektu informatycznego. Dodatkowym wymaganiem podnoszącym ocenę normy może być wskazywanie, jak do całego cyklu życia oprogramowania mają się poszczególne działania składowe ZK. Sześć wymienionych powyżej kryteriów odniesione zostanie do trójki norm, które uczestniczą w porównaniu. Zanim jednak przedstawiona zostanie ocena ilościowa, omówione zostaną mocne i słabe strony tych norm [Bounds, Dart 1993, s ] Norma dotycząca planu zarządzania konfiguracją oprogramowania IEEE Standard IEEE , będący uaktualnioną wersją normy z 1990 roku, nie powstał z myślą o żadnym konkretnym sektorze gospodarki, zatem jego zastosowanie jest uniwersalne. Kierowany jest do firm o różnym poziomie doświadczenia w zakresie ZKO, obejmuje cały cykl życia oprogramowania, uwzględnia współpracę z innymi organizacjami oraz różnice w stosowanym sprzęcie, a także inne czynności w obrębie projektu. Co więcej, nie jest ograniczony do żadnego określonego typu oprogramowania. Do zalet można także zaliczyć szczególną wagę, jaką przywiązuje standard IEEE do kontroli nad interfejsem (tj. powiązaniami z innymi elementami przedsięwzięcia informatycznego wykraczającymi poza zakres ZK) oraz podwykonawcami/dostawcami oraz szczegółową listę zagadnień, jakie należy wziąć pod rozwagę w każdym z kluczowych obszarów ZKO. 2. Analiza literatury 9

14 Innymi mocnymi stronami normy IEEE są: gruntowne podejście do każdego z elementów planu zarządzania konfiguracją, kompleksowość oraz odniesienie każdego z punktów do powiązanej z nią uzupełniającej normy będącej poradnikiem dobrego planowania ZKO [ANSI/IEEE ]. Pomimo wymienionych powyżej ogromnych zalet tego standardu, posiada on jednak kilka wad. Po pierwsze, nie przewiduje skorowidzu, który pozwoliłby czytelnikowi na sprawniejsze poruszanie się po dokumencie, jakim jest powstały w wyniku jego zastosowania plan ZKO. Nie jest to, oczywiście, uwaga merytoryczna, niemniej ten techniczny brak zmniejsza wygodę użytkowników dokumentu. Po drugie, norma nie zawiera przykładowego planu ZK czy nawet jego fragmentu. Standard wiele by zyskał, gdyby czytelnik mógł porównać przykład ze wskazówkami zawartymi w planie, a przynajmniej gdyby zawarto przykładowy diagram procesu kontroli zmiany, który to proces jest najtrudniejszy do zrozumienia i zaplanowania w całym ZKO. I wreszcie norma w niewielkim stopniu nawiązuje do cyklu życia oprogramowania, podczas gdy pożądane by było, aby wskazywała na związek cyklu z elementami ZK oraz pokazywała, jak czynności związane z zarządzaniem konfiguracją zmieniają się w poszczególnych fazach Opis elementu danych planu zarządzania konfiguracją oprogramowania NASA Norma amerykańskiej Narodowej Agencji do spraw Aeronautyki i Przestrzeni Kosmicznej [NASA Sfw DID ] powstała z myślą o określonym segmencie przemysłu. Ma ona dwie podstawowe zalety. Po pierwsze, jest uporządkowana i jednolita, dzięki czemu korzystanie z informacji w niej zawartych jest łatwe. Po drugie, niektóre składniki ZKO są opisane lepiej niż w dwóch pozostałych porównywanych normach. Są to: dokumentacja, formularz kontroli zmiany i zasoby. Norma traktuje dokumentację niezależnie od jednostek programowych w działach poświęconych identyfikacji oraz przechowywaniu i wydawaniu. Jest to swoiste przypomnienie dla użytkownika planu powstałego w wyniku stosowania normy, by pamiętał o odwoływaniu się do odpowiedniej dokumentacji. Norma uszczegóławia także dane, jakie zawierać powinien formularz kontroli zmiany, podczas gdy pozostałe standardy jedynie wspominają o konieczności istnienia takiego dokumentu. Rozróżniane są też przez normę takie zasoby jak: urządzenia, nośniki danych i ludzie. Niestety, można wskazać co najmniej kilka wad tej normy. Główną jest konieczność przygotowania oddzielnego planu ZK dla każdej jednostki programowej. 2. Analiza literatury 10

15 Wprowadza to ogromną nadmiarowość informacji, co komplikuje korzystanie z takiego planu w przeciętnej firmie. Można się domyślać, że dla NASA, której przedsięwzięcia obarczone są dużym ryzykiem i złożonością, takie rozwiązanie jest korzystne. Niemniej nie sprawdza się takie podejście w przypadku względnie niewielkich projektów. Jako drugi zarzut można wskazać mały stopień kompleksowości i szczegółowości opisywanej normy, przez co konieczne jest wspieranie się innymi dokumentami. Powierzchownie potraktowano m.in. kwestię identyfikacji pozycji konfiguracji. Ogólnie, osoba nie będąca ekspertem w zakresie zarządzania konfiguracją oprogramowanie nie jest w stanie skutecznie opracować planu ZKO bez odwoływania się do innych źródeł Opis elementu danych planu rozwoju oprogramowania Departamentu Obrony USA Norma ta [DoD DI-MCCS-80030A] powstała na potrzeby amerykańskiego Departamentu Obrony, niemniej pisano ją z myślą o możliwościach dostosowania do zmieniających się wymagań związanych z szybkim rozwojem technik informatycznych. Ma ona charakter swoistego przewodnika, a nie narzucanych z góry rozwiązań. Prócz wspomnianej zdolności do dopasowywania, norma ta posiada dwie główne zalety. Pierwsza z nich to możliwość włączenia planu ZKO do planu wytwarzania oprogramowania (ang. software development plan, SDP) lub traktowania jako osobnego dokumentu. Takie połączenie ma znaczenie wówczas, gdy ZK jest ściśle powiązane z zarządzaniem całym projektem oraz cyklem życia oprogramowania. Drugą z zalet jest dołączony przykładowy schemat działania kontroli nad konfiguracją, którą określono już wcześniej jako kluczową w całym planie ZK. Podobnie jak normie NASA, również dokumentowi Departamentu Obrony USA można zarzucić niewielki stopień kompleksowości i dogłębności, co każe wspierać się przy tworzeniu systemu ZK innymi opracowaniami. Inną wadą jest, co może z pozoru zaskakiwać, podatność na dopasowywanie. Chodzi o to, że ten zabieg może odbywać się jedynie poprzez rozbudowywanie planu względem opisywanej normy. Wymaga więc doświadczenia i wiedzy na temat elementów, o jakie należy plan wzbogacić. Poza tym norma DoD DI-MCCS-80030A dotyczy całego planu wytwarzania oprogramowania, którego zarządzanie konfiguracją jest tylko jedną z części. Do tego układ dokumentu sprawia, że bez przejrzenia całości, czytelnik nie dotrze do dwóch istotnych elementów ZK: do repozytorium rozwijanego oprogramowania oraz działań korygujących, które znajdują się poza rozdziałem poświęconym zarządzaniu konfiguracją. 2. Analiza literatury 11

16 Porównanie norm Tabela 2.1 ukazuje porównanie opisywanych norm pod kątem zaproponowanych w punkcie kryteriów. Tabela 2.1 Porównanie norm. Kryterium IEEE NASA DoD Łatwość posługiwania się Kompleksowość Możliwość dopasowania Konsekwencja Poprawność Nawiązanie do cyklu życia SUMA Źródło: [Bounds, Dart 1993, s. 16]. Jak widać, norma ANSI/IEEE Std uzyskała najlepszą ocenę w oczach autorów zestawienia. Na przydatność tej normy w praktyce firm informatycznych sektora MSP wskazują także Pacheco i Sanches [2000, s.3]. Również na tę normę, a nie na standard NASA, powołuje się Europejska Agencja Kosmiczna (ESA) w wydanym przez siebie przewodniku po zarządzaniu konfiguracją oprogramowania [ESA PSS ]. Cytowane porównanie nie jest jedynym. Zestawienie cech sześciu norm (w tym IEEE , poprzedniczki IEEE ) można znaleźć w wojskowym poradniku poświęconym ZKO [MIL-HDBK , załącznik F]. Nie zawiera on jednak oceny punktowej, ani nie wskazuje na najlepszą pod danym względem normę. Podobnie jest z porównaniem zamieszczonym w innej wojskowej publikacji, Software Configuration Management Technologies and Applications [STSC 1999, s. 23] Modele cyklu życia oprogramowania Proces zarządzania konfiguracją oprogramowania powinien być wpisany w cykl życia produktu programowego, albowiem w zależności od przyjętego modelu różnić się może rodzaj, kolejność i powiązanie między fazami cyklu. To zaś wpływa na strukturę ZKO, która niejako rozpięta jest na szkielecie wybranego modelu cyklu życia. W tym podrozdziale przedstawione zostaną najpopularniejsze modele cyklu życia oprogramowania oraz wskazany zostanie jeden, najbardziej optymalny pod względem przydatności w realiach firmy Radix Model kaskadowy Felix Redmill w [Górski 2000, s. 34] stwierdza, że zgodnie ze sztuką inżynierską projektowanie powinno poprzedzać realizację, a faza specyfikacji znajdować się na osi 2. Analiza literatury 12

17 czasu przed projektowaniem. Ten szereg zdarzeń jest punktem wyjścia do definicji modelu kaskadowego (ang. Waterfall Model). W tym modelu główne procesy projektu ukazane są jako etapy realizowane w ściśle zdefiniowanej kolejności, tak jak to ilustruje rys Nowy etap nie rozpocznie się, póki nie zakończy się jego poprzednik. Model przedstawiony na rysunku uwzględnia etap inicjalizacji (tu nazwany fazą strategiczną), często pomijany tam, gdzie kwestie zarządzania przedsięwzięciem nie znajdują zrozumienia w kierownictwie zespołu. Faza strategiczna Określenie wymagań Projektowanie Implementacja Integracja Testowanie Instalacja Konserwacja Źródło: [oprac. własne na podstawie: Jaszkiewicz 1997 i Pressman 2001]. Rysunek 2.2 Model kaskadowy. Model kaskadowy zakłada, że możliwe lub wręcz wskazane są iteracje, zarówno do etapu poprzedzającego jak i cofnięcie się do niemal samego początku, jakim jest określenie wymagań. Zaletą modelu kaskadowego jest łatwość zarządzania przedsięwzięciem na nim opartym. Natomiast jako wady wymienia się [Jaszkiewicz 1997, s. 17]: narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac, wysoki koszt błędów popełnionych we wstępnych fazach, długą przerwę w kontaktach z klientem. 2. Analiza literatury 13

18 Model V Podobnie jak model kaskadowy, model V definiuje główne procesy projektu jako etapy realizowane jeden po drugim (sekwencyjnie), przy czym rozpoczęcie kolejnego etapu jest uzależnione od zakończenia etapu poprzedniego. Sprzężone są z nim procesy weryfikacyjne i walidacyjne rozmieszczone na drugim ramieniu litery V, która obrazuje strukturę całego modelu jak pokazano na rysunku 2.3. Specyfikacja Projekt systemu Projekt podsystemu Projekt modułu Testowanie akceptacyjne Integracja i walidacja systemu Integracja i weryfikacja podsystemu Formalne testowanie modułu Kodowanie, wstępne testowanie modułu Źródło: [oprac. własne na podstawie: Górski 2000, s. 36]. Rysunek 2.3 Model V. Kolejne kroki procesu definiowania systemu (od specyfikacji rozpoczynając, na projekcie szczegółowym kończąc) umieszczone są coraz niżej na lewym ramieniu litery V. Po osiągnięciu dolnego punktu realizowane są kroki integracyjne umieszczone coraz wyżej na prawym ramieniu litery V, odpowiadające poszczególnym krokom znajdującym się na jej lewym ramieniu [Górski 2000, s ] Model przyrostowy W [Jaszkiewicz 1997, s.23] znajdujemy, że realizacja przyrostowa (ang. incremental development) rozpoczyna się od określenia wymagań (rys. 2.4) oraz wykonania wstępnego, ogólnego projektu całości systemu. Następnie wybierany jest pewien podzbiór funkcji systemu. Dalej, zgodnie z przebiegiem modelu kaskadowego, wykonywany jest szczegółowy projekt oraz implementacja części systemu realizującej te funkcje. Po przetestowaniu zrealizowany fragment pełnego systemu może zostać dostarczony klientowi. 2. Analiza literatury 14

19 Określenie wymagań Ogólny projekt Proces realizowany iteracyjnie Wybór podzbioru funkcji Szczegółowy projekt, implementacja i testy Dostarczenie zrealizowanej części systemu Źródło: [Jaszkiewicz 1997, s. 23]. Rysunek 2.4 Model przyrostowy. Zalety tego modelu to: skrócenie przerw w kontaktach z klientem, możliwość wczesnego wykorzystywania przez klienta dostarczonych fragmentów systemu. możliwość elastycznego reagowania na powstałe opóźnienia. Jeżeli realizacja fragmentu systemu opóźni się, nie musi to oznaczać opóźnienia całego przedsięwzięcia. Istnieje wtedy możliwość przyspieszenia prac nad dalszymi częściami. Wadą modelu przyrostowego jest pewien dodatkowy koszt związany z niezależną realizacją fragmentów systemu. Zazwyczaj nie ma możliwości wyodrębnienia podzbioru funkcji w pełni niezależnych od pozostałych. Toteż może zajść potrzeba implementacji tzw. szkieletów modułów, tj. modułów o interfejsie zgodnym z modułami, które znajdą się w pełnym systemie, lecz nie realizujących w pełni ich funkcji. 2. Analiza literatury 15

20 Model spiralny Jaszkiewicz [1997, s ] stwierdza, że bodaj najbardziej ogólnym modelem cyklu życia oprogramowania jest model spiralny zaproponowany przez Boehma w 1988 roku. Model ten (rys. 2.5) składa się z czterech głównych faz wykonywanych cyklicznie: Określenie celów ocena celów bieżącej fazy, definiowanie ograniczeń, wyznaczenie alternatywnych podejść do osiągnięcia tych celów. Analiza ryzyka rozważanie ogólnych opcji budowy nowej wersji systemu przy uwzględnieniu związanego z nimi ryzyka; faza ta może też obejmować budowę prototypu. Opracowanie i weryfikacja budowa kolejnej wersji systemu w sposób zgodny z modelem kaskadowym (por ) oraz ocena przez klienta; jeśli jest pozytywna, rozpoczyna się kolejny cykl. Planowanie ustalenie generalnych celów produkcji kolejnej wersji systemu. Skumulowany koszt Określenie celów, możliwości, ograniczeń Analiza ryzyka, ocena możliwości Uzgodnienie Planowanie następnej fazy Opracowanie, weryfikacja następnego produktu Źródło: [oprac. własne na podstawie: Beynon-Davies 1999, s. 77, Sikorski 2000, s. 37]. Rysunek 2.5 Model spiralny. Wadą wynikającą z konieczności tworzenia wielu modeli jest długi cykl wytwórczy. Zaletami modelu spiralnego są: iteracyjność oraz częste kontakty z klientem. 2. Analiza literatury 16

21 Wybór modelu Decydując się na wybór modelu cyklu życia programowania należy uwzględnić zalecenia literatury traktującej o ZKO i istniejącą praktykę firmy Radix. Z reguły pozycje literaturowe wymieniają wspomniane powyżej modele jako równorzędne w stosowaniu na potrzeby ZKO. Niemniej, zapewne ze względu na największą użyteczność, omawiany jest model kaskadowy. Autorzy jednego z opracowań [Futrtell, Shafer, Shafer 2002, s. 1215] dotyczących jakości w zarządzaniu przedsięwzięciami wpisują całość procesów ZKO w model kaskadowy. Natomiast bezpośredni wywiad w firmie Radix zakończył się stwierdzeniem jej przedstawiciela, że przedsięwzięcia realizowane są w oparciu o model spiralny. Zatem powstaje wrażenie, że projektant systemu zarządzania konfiguracją oprogramowania dla firmy Radix stoi przed dylematem, czy wybrać model kaskadowy, w który stosunkowo łatwo wpisać procedury ZKO, czy też pozostać przy modelu spiralnym, by jak najmniej odchodzić od wymagań firmy. Tak naprawdę dylemat jest pozorny. Model spiralny to w rzeczywistości model kaskadowy poszerzony o zagadnienia zarządzania projektem, głównie zaś o analizę ryzyka. Widać to dobrze na rysunku 2.5, gdzie przecinająca spiralę strzałka ukazuje przebieg modelu kaskadowego. Jako że ZKO dotyczy zagadnień przedstawionych w ćwiartce poświęconej opracowywaniu produktu (to tam powstają i są zmieniane pozycje konfiguracji), można zawęzić zagadnienie ZKO w modelu spiralnym do podejścia kaskadowego. Zatem ze względu na przejrzystą strukturę, odniesienie w literaturze traktującej o ZKO i współgranie z wymaganiami samej firmy wybiera się model kaskadowy jako zalecany przy tworzeniu systemu zarządzania konfiguracją oprogramowania dla potrzeb firmy Radix Wnioski z analizy literatury Zgodnie z tym, co zaznaczono na początku rozdziału, zarządzanie konfiguracją oprogramowania jest elementem zarządzania jakością, a dokładniej zapewnienia jakości. Podejściem ułatwiającym stosowanie ZKO w przedsięwzięciach informatycznych jest stosowanie zaleceń w postaci normy. Jako najbardziej przydatną dla tworzonego w tej pracy projektu wybrano normę ANSI/IEEE Std ze względu na możliwość dość dobrego dopasowania do potrzeb niewielkiej firmy, jaką jest Radix. Porównując ją z pozostałymi dwiema nie moż- 2. Analiza literatury 17