Tworzenie oprogramowania nie jest sprawą

Transkrypt

1 Inżynieria oprogramowania Rafał Kasprzyk Przegląd modeli cyklu życia oprogramowania Tworzenie oprogramowania nie jest sprawą prostą i nikogo, kto brał udział w dużym projekcie, nie trzeba o tym przekonywać. Czasy, kiedy jedna osoba zajmowała się zbieraniem wymagań, analizą, projektowaniem, programowaniem, testowaniem i wdrażaniem produktu informatycznego dawno już się skończyły. Programowanie odkrywcze nie jest obecnie dobrym sposobem budowy jakichkolwiek systemów informatycznych. Tworzone dziś systemy są po prostu zbyt skomplikowane, aby przez cały cykl życia tych systemów mogła nad nimi panować jedna osoba. Trudności w budowaniu dużych systemów wymusiły, już wiele lat temu, konieczność usystematyzowania procesu wytwarzania systemów informatycznych. Stworzono więc modele porządkujące podejmowane działania i stany w jakich znajduje się produkt informatyczny. Obecnie zbiór modeli cykli życia oprogramowania jest niezwykle bogaty. Oczywiście wystarczy poznać tylko kilka kluczowych modeli, pozostałe są najczęściej hybrydami tych podstawowych. Pojęcie modelu cyklu życia systemu informatycznego Czym właściwie jest model cyklu życia systemu informatycznego (oprogramowania)? To szereg wzajemnie zależnych od siebie etapów, w których podejmowane są działania, począwszy od ujawnienia potrzeby budowy systemu informatycznego, prezentacji jego idei, konstrukcję, użytkowanie, przystosowane do ewentualnych zmian funkcjonowania (wynikających najczęściej ze względu na zmieniające się warunki otoczenia), a kończąc na wycofaniu z eksploatacji. Będziemy zajmować się tylko tą częścią cyklu życia oprogramowania, która związana jest z procesem wytwórczym i w związku z tym nazywana jest cyklem wytwarzania oprogramowania. Każdy model cyklu życia oprogramowania ma na celu przedstawienie procesu wytwarzania oprogramowania, który prowadzi do stworzenia działającego systemu spełniającego oczekiwania klienta. Autor jest absolwentem Wydziale Cybernetyki Wojskowej Akademii Technicznej, gdzie od roku zajmuje stanowisko asystenta w Instytucie Systemów Informatycznych. Pracuje w firmie ISOLUTION będąc odpowiedzialnym za przygotowywanie, prowadzenie i audyt szkoleń obejmujących analizę i projektowanie systemów informatycznych z użyciem notacji UML. Kontakt z autorem: rafal.kasprzyk@wat.edu.pl Rysunek 1. Programowanie odkrywcze Popularne modele cyklu życia systemu informatycznego Najczęściej wymienianym procesem wytwarzania oprogramowania jest model kaskadowy (zwany również modelem wodospadu, ang. waterfall) i model iteracyjny. Terminy te często są nie do końca poprawnie rozumiane. Bardzo często można się spotkać z przekonaniem, że proces kaskadowy jest procesem przestarzałym, a jedynie słusznym podejściem jest proces iteracyjny. Osobiście ostrożnie podchodzę do takiej oceny tych dwóch najpopularniejszych modeli wytwarzania oprogramowania. Uważam, że wybór procesu w znacznym stopniu zależy od charakteru projektu, a tym samym nie ma jednego słusznego modelu cyklu życia oprogramowania. Co więcej, najczęściej okazuje się, że w praktyce najlepiej radzą sobie modele, które są modyfikacjami lub hybrydami procesów podstawowych. Przyczyna ich powstania związana jest bądź to z wadami bądź trudnościami w adaptacji do rzeczywistych warunków wytwarzania systemów informatycznych modelu kaskadowego. Zauważmy, że sam proces iteracyjny stanowi swego rodzaju modyfikację procesu kaskadowego. Inne znane i popularne modele cyklu życia oprogramowania to model spiralny, model V, prototypowanie, i wiele innych. Model kaskadowy Najstarszym i prawdopodobnie najlepiej znanym cyklem życia oprogramowania jest model wodospadu. Najpowszechniej spotykanym argumentem zachęcającym do użycia tego modelu jest fakt, iż jest on dla człowieka najbardziej naturalnym sposobem rozwiązywania wszelkich problemów. W modelu kaskadowym, aby zbudować system informatyczny należy przejść przez kolejne etapy, których realizacja ma zapewnić zakończenie projektu. Etapy na jakie dzielony jest proces wytwarzania to: zbieranie wymagań, analiza, projektowanie, implementacja, testowanie i wdrożenie systemu. W modelu wodospadu wyjście z jednego etapu jest równocześnie wejściem w kolejny, bez możliwo Software Developer s Journal 10/2006

2 Przegląd modeli cyklu życia oprogramowania Rysunek 2. Model kaskadowy ści powrotu. Zostaje zatem utworzona sztywno narzucona kolejność poszczególnych etapów. Analityk po stworzeniu modelu dziedziny problemu przekazuje wyniki swojej pracy projektantowi. Projektant, po stworzeniu projektu oprogramowania, w oparciu o wyniki etapu analizy, przekazuje go w ręce programisty, którego zadaniem jest jego implementacja. Następnie w celu zapewnienia wysokiej jakości produktu, kod jest testowany, a dopiero na samym końcu jest przekazywany klientowi. W procesie kaskadowym bardzo istotna jest forma przekazywania wyników z jednego etapu do drugiego. Niekiedy pojawiają się powroty, ale możliwość wystąpienia takiej sytuacji powinna być minimalizowana. Oczywistym jest przecież, że na przykład podczas implementacji może wystąpić jakiś problem, który zmusi zespół do powrotu do projektu lub co gorsza powtórnej analizy. Weryfikacja wyników poszczególnych etapów jest więc nieunikniona. Podstawowe cechy modelu kaskadowego niestety pokazują jednocześnie jego wady: Uzyskanie produktu spełniającego oczekiwania klienta niezwykle silnie zależy od stabilności wymagań, która jest przecież trudna do uzyskania. Weryfikacja zgodności produktu z wymaganiami i jego użyteczności następuje dopiero w końcowych krokach. Próba dopasowania produktu do zmieniających się wymagań, powoduje znaczący wzrostu kosztów budowy systemu. Kolejności wykonywania prac muszą być ściśle przestrzegane, co niekoniecznie trzeba uważać za wadę. Warto jednak zauważyć, że większość osób preferuje znacznie mniej rygorystyczne procesy wytwarzania oprogramowania. Wysoki koszt błędów popełnionych we wstępnych etapach jest bardzo charakterystyczną właściwością modelu kaskadowego. Przecież błędy popełnione na etapie zbierania lub analizy wymagań mogą być wykryte dopiero na etapie testów akceptacyjnych, bądź eksploatacji, a ich koszt o kilka rzędów wielkości przewyższać koszt błędów popełnionych podczas implementacji. Częstym argumentem podnoszonym przeciwko modelowi liniowemu jest zmarginalizowanie roli klienta w procesie wytwarzania oprogramowania. Długa przerwa w kontaktach z klientem, z którym ściśle współpracuje się podczas określania wymagań, pociąga za sobą ryzyko zmniejszenia zainteresowania klienta produktem, podczas gdy nie bierze on udziału w procesie wytwórczym. Klient przypomina sobie o systemie, który w końcu był przez niego zamawiany, na etapie wdrażania, kiedy to jego wizja na temat funkcjonalności, jaką system powinien zapewniać, może ulec istotnej zmianie. Warto nadmienić, że model kaskadowy mimo swych licznych wad, w nieco zmodyfikowanej postaci, stał się standardem, zalecanym przez Departament Obrony Narodowej Stanów Zjednoczonych (DOD STD 2167), stosowanym przy wytwarzaniu systemów informatycznych dla wojska. Standard ten jest ścisłą realizacją modelu kaskadowego kierowaną dokumentami. Na czym owa modyfikacja polega? Po prostu, każdy etap kończy się opracowaniem szeregu dokumentów, które z założenia są wystarczającą podstawą do realizacji kolejnych etapów. Dopiero akceptacja przez klienta dokumentacji zrealizowanego etapu pozwala na rozpoczęcie kolejnego. Rysunek 3. Model iteracyjny Software Developer s Journal 10/

3 Inżynieria oprogramowania Rysunek 4. Model V Model iteracyjny W modelu iteracyjnym wymagania są porządkowane i dzielone na mniejsze podzbiory. Każdy taki podzbiór wymaganej funkcjonalności wymaga przejścia przez etapy, o których była mowa w modelu kaskadowym. Po zakończeniu każdej iteracji wybierany jest kolejny podzbiór wymagań do realizacji i ponownie przechodzimy przez wszystkie etapy wytwarzania oprogramowania. Zauważmy, że takie podejście pozwala na szybką implementację przynajmniej części wymaganej funkcjonalności (tej o najwyższym priorytecie, lub też stanowiącej najwyższe ryzyko niepowodzenia realizacji). Model iteracyjny pozwala więc na bardzo szybką weryfikację realizowalności wytwarzanego systemu i informację zwrotną od klienta, czy to, czego potrzebuje, jest tym, co otrzyma jako produkt procesu wytwórczego. Praktyka stosowania procesu iteracyjnego zaleca przed rozpoczęciem rzeczywistych iteracji przeprowadzenie swego rodzaju rozpoznania wymagań, w celu uzyskania ogólnego obrazu i zakresu projektu. Celem, jaki przyświeca tym działaniom, jest podział wymagań na właściwe iteracje. Takie wstępne działania polegają najczęściej na stworzeniu ogólnej architektury systemu, a niekiedy nawet jego prototypu. Ciekawą i moim zdaniem niezwykle pożądaną odmianą procesu iteracyjnego jest możliwość przekazania systemu do wdrożenia, gdy tylko jakiś rozsądny podzbiór wymagań zostanie zaimplementowany i przetestowany. Jest to korzystne, co najmniej z dwóch powodów: wcześniej można uzyskać pewne korzyści (nie ma co ukrywać, że chodzi tu o korzyści finansowe) z wdrożenia systemu, ale również, co w dłuższej perspektywie jest ważniejsze, można uzyskać w pełni obiektywne opinie na temat jego działania w rzeczywistych warunkach. W takich sytuacjach system można wypuszczać w kolejnych wydaniach, z których każde podzielone jest na pewną liczbę iteracji. Rysunek 5. Model spiralny 54 Software Developer s Journal 10/2006

4 Przegląd modeli cyklu życia oprogramowania Bardzo często można spotkać się z pojęciem procesu przyrostowego, ewolucyjnego lub spiralnego, które w praktyce są tym samym, co proces iteracyjny. Oczywiście na gruncie teoretycznym rozważa się różnice pomiędzy tymi procesami, ale nie są one wyraźne. W dalszej części artykułu przedstawiony jednak zostanie model spiralny, ze względu na częste odwołania się do niego w literaturze dotyczącej omawianego tematu. Model kaskadowy i model iteracyjny możliwe scalenie Przedstawiony opis modelu kaskadowego i iteracyjnego został znacząco uproszczony, aby czytelnik uchwycił podstawową różnicę pomiędzy tymi procesami. Praktyka pokazuje, że oba procesy mogą podlegać bardzo wielu zaburzeniom, co nie oznacza oczywiście, że wówczas system jest realizowany niemetodycznie. Często proponowanym rodzajem procesu jest tzw. etapowy cykl tworzenia oprogramowania, które stanowi scalenie modelu kaskadowego i modelu iteracyjnego. Proponuje się w nim dokonać według modelu kaskadowego zbierania wymagań, analizy i projektowania, a implementację i testowanie podzielić następnie na iteracje. Wdrożenia można natomiast dokonać po zaimplementowaniu i przetestowaniu całości wymagań ponownie według modelu kaskadowego lub też może to polegać na instalacji kolejnych wydań systemu, co zależy oczywiście od charakteru projektu i uzgodnień z klientem. Oczywistym jest, co już zostało wspomniane, że to drugie podejście wydaje się być z różnych przyczyn korzystniejsze zarówno dla twórców, jak i odbiorców systemu. Można śmiało postawić tezę, że jednym z głównych powodów modyfikacji modelu kaskadowego elementami charakterystycznymi dla procesu iteracyjnego są względy finansowe, a nie jak by się mogło wydawać oczywiste zalety iteracyjnego podejścia do wytwarzania oprogramowania. Zauważmy, że wykonawca żąda pieniędzy za każdy wykonany etap. Z kolei klient, płacąc za wykonany etap, żąda wyników, które jest wstanie ocenić pod względem zgodności z wymaganiami (a często niestety mało precyzyjnymi wyobrażeniami). Model V Rozwinięciem modelu wodospadu jest model V, charakteryzujący się rozbudowaną fazą testów. Model V jest jednym z najpopularniejszych podejść do procesu testowania. Testy mają na celu weryfikację i walidację poprawności wykonania każdego etapu stanowiącego cykl życia oprogramowania. Dzięki rozbudowaniu sekwencji etapów wytwórczych o testowanie otrzymujemy produkt o najwyższej jakości, spełniający wymagania klienta. Model V podobnie jak klasyczny model kaskadowy stwarza bardzo duże niebezpieczeństwo. Oczywistym jest przecież, że im później zostanie wykryty błąd lub niezgodność z wymaganiami, tym kosztowniejsza będzie naprawa. Dzięki temu, że każdy z etapów wytwórczych kończy się różnego rodzaju przeglądami i inspekcjami prawdopodobieństwo pojawienia się błędu lub niezgodności z wymaganiami przy wdrożeniu i eksploatacji jest dużo mniejsze niż w modelu klasycznym. Powoduje to znaczące obniżenie kosztów pielęgnacji systemu. Dodatkowo wynikiem każdego etapu wytwórczego są plany testów, które po zakończeniu zstępującego cyklu produkcyjnego (lewe ramię litery V) realizowane są wstępująco (prawe ramię litery V). Model spiralny Model spiralny jest w pewnym sensie próbą formalizacji podejścia iteracyjnego do wytwarzania oprogramowania. Główną cechą tego modelu jest analiza ryzyka występująca w każdej iteracji. Ciągłe monitorowanie i pomiar zmian, które poddawane są krytycznemu spojrzeniu użytkownika, umożliwiają dokonanie analizy ryzyka. Pierwszą czynnością, która nie jest przedstawiona na rysunku obrazującym model spiralny, jest analiza wymagań wstępnych. Jeżeli wymagania wydają się być realizowalne w założonym czasie, budżecie i przy dostęp- R E K L A M A

5 Inżynieria oprogramowania ocena przez klienta walidacja wydania i jego ocena z możliwością modyfikacji wymagań na system (możliwość wystąpienia modyfikacji wymagań powinna być minimalizowana). Główne zalety modelu spiralnego to próba minimalizacji ryzyka niepowodzenia przedsięwzięcia oraz ciągła weryfikacja produktu przez użytkownika, co ma na celu wytworzenie produktu w pełni satysfakcjonującego klienta. Rysunek 6. Model prototypowania nych zasobach (tzw. zasad trójkąta) można przejść do planowania projektu i pierwszej iteracji. Właściwie kolejne iteracje mają postać małych wodospadów. Po każdej takiej pełnej iteracji dokonuje się przeglądu systemu. Jeżeli dane przedsięwzięcie wymaga dalszych prac wówczas należy zaplanować kolejną iterację, a następnie przeprowadzić analizę ryzyka realizacji kolejnego wydania. Model spiralny stanowi więc obudowaną wersję modelu wodospadu opartą o bieżącą analizę ryzyka. Model spiralny można postrzegać jako cyklicznie powtarzane cztery czynności: planowanie na podstawie wymagań i celów wyznaczonych przez klienta, dokonuje się określenia alternatyw i ograniczeń oraz planowania iteracji przy każdorazowym rozpoczęciu kolejnego cyklu spirali. analiza ryzyka sprowadza się do oceny rozwiązań alternatywnych oraz próby identyfikacji i analizy ryzyka związanego z każdą z możliwych alternatyw konstrukcji nowego wydania. konstrukcja ma postać małego wodospadu, a jej celem jest wytworzenie kolejnego wydania systemu. Prototypowanie Model prototypowania jest kolejną próbą radzenia sobie z problemem identyfikacji i braku stabilności wymagań. Prototypowanie polega na budowaniu kolejnych przybliżeń systemu do momentu aż prototyp stanie się dobrym odzwierciedleniem wymagań. Oceny prototypów i kolejne wersje owych prototypów, w sposób bardzo naturalny prowadzą do identyfikacji wymagań. Zauważmy, że prototypowanie w tym przypadku pokrywa etap analizy wymagań i stąd często przedstawiany model określa się jako prototypowanie wymagań. Cechą charakterystyczną prototypowania wymagań jest budowa szybkiego projektu bez dbałości o jego jakość i dostosowanie do środowiska docelowego. Oczywiście możliwe jest szersze spojrzenie na prototypowanie tak, aby obejmowało ono również etap projektowania w celu weryfikacji efektywności przyjętych rozwiązań. Ten rodzaj prototypowania określany jest mianem prototypowania wytwórczego. Gdy mamy już pewność, że wszystkie wymagania zostały zidentyfikowane, wówczas można przystąpić do konstrukcji właściwego produktu zgodnie z modelem klasycznym wytwarzania oprogramowania, rozpoczynając od etapu projektowania. Tego typu podejście może niekiedy spotkać się z niezrozumieniem ze strony klienta, bądź też pojawić się na wyższych szczeblach zarządzania firmą wykonawcy. Często pojawiają się pytania typu: Dlaczego trzeba zaczynać wszystko od nowa jeśli już prawie wszystko zrobiono? Kolejną wadą prototypowania jest możliwość przyzwyczajenia się klienta do funkcjonalności oferowanej przez prototyp, a która nie wynika z przyjętych wymagań. Również projektant może przyzwyczaić się do rozwiązań zastosowanych w prototypie. Reasumując, model prototypowy musi być dobrze rozumiany przez obie strony tj. zarówno twórcę systemu informatycznego, jak i klienta. Planowanie predykcyjne i adaptacyjne Wybór procesu wytwarzania oprogramowania bardzo silnie zależeć będzie od stabilności wymagań. Również sposób planowania jest uzależniony od stabilności wymagań. Przy założeniu, że wymagania, które zostały zebrane nie będą już się zmieniały, jak również klient nie będzie dodawał nowych, za- Literatura [1] Marin Fowler UML Distilled: A Brief Guide To The Standard Object Modeling Language, Pearson Education, Inc., 2004; [2] Stanisław Szejko Metody wytwarzania oprogramowania, MIKOM, Warszawa 2002; [3] Graham I. Inżynieria oprogramowania metody obiektowe w teorii i praktyce, WNT, Warszawa Software Developer s Journal 10/2006

6 Przegląd modeli cyklu życia oprogramowania leca się planowanie predykcyjne. Planowanie predykcyjne jest bardzo często narzucone w projektach rządowych i dla wojska. Trudno wyobrazić sobie tutaj inny sposób planowania, ponieważ mamy najczęściej sztywną datę zakończenia i kwotę budżetu. Ustalenia pomiędzy twórcą systemu i zamawiającym muszą jednoznacznie precyzować, co właściwie jest do zrobienia, ile produkt finalny będzie kosztował i kiedy zostanie ukończony. To dlatego w tego typu projektach możliwe jest wykorzystania procesu kaskadowego. Dla administracji nic przecież nie jest bardziej kłopotliwe niż brak jasnej wizji kosztu wytworzenia jakiegoś produktu i czasu jego realizacji. Powstaje jednak pytanie, czy projekty informatyczne mogą być w ogóle przewidywalne. Bez wątpienia w większości projektów można się spotkać z chaosem wymagań. Chaos polega na wprowadzaniu zmian do wymagań w późniejszych etapach cyklu życia oprogramowania. Zmiany takie praktycznie zawsze powodują konieczność przebudowy pierwotnie stworzonego planu projektu. Oczywiście można próbować walczyć z taką sytuacją. Powszechnie stosowanym sposobem radzenia sobie ze zmianami życzeń klienta jest zamrożenie na pewnym etapie zbioru wymagań. Powstaje jednak pewien problem. Zamrożenie wymagań powoduje ryzyko stworzenia produktu, który właściwie nie jest potrzebny klientowi już w chwili wdrażania. Można jednak inaczej próbować podejść do problemu zmieniających się wymagań. Zakładamy mianowicie, że chaos wymagań jest zjawiskiem nieuniknionym, a pełna przewidywalność to iluzja. Doskonale sprawdza się wówczas planowanie adaptacyjne, które traktuje zmiany jako coś zupełnie naturalnego. Zmiany muszą być oczywiście kontrolowane. Ciekawą rzeczą jest fakt, że w przypadku planowania adaptacyjnego ciężko powiedzieć, że system jako całość rozwija się zgodnie z planem, a to dlatego, że taki plan ulega ciągłej modyfikacji. Oznacza to tyle, że plan służy raczej do możliwości oszacowania konsekwencji wprowadzenia zmian niż do przewidywania, kiedy system zostania oddany w ręce klienta. W przypadku planowania adaptacyjnego można oczywiście na stałe określić budżet przewidziany na projekt i czas jego zakończenia, jednak nie można przewidzieć zakresu wymagań, które zostaną zrealizowane. Planowanie adaptacyjne wymaga ścisłej permanentnej współpracy zespołu projektowego z klientem, a zbiór wymagań może być dość elastycznie modyfikowany, rozszerzany, a niekiedy zawężany, oczywiście wszystko za porozumieniem obu stron. W tego typu projektach zastosowanie modelu kaskadowego z góry skazane jest na niepowodzenie. Plan adaptacyjny możliwy jest do zastosowania jedynie w przypadku zastosowania procesu iteracyjnego i jego licznych modyfikacji, z których niektóre przedstawione zostały w artykule. Podsumowanie Badania prowadzone w Stanach Zjednoczonych wykazały, że ponad 2/3 wszystkich projektów informatycznych kończą się niepowodzeniem. Niepowodzenie było najczęściej rezultatem braku środków finansowych na kontynuowanie projektu (niedoszacowanie kosztów), stworzenie produktu, który nie spełnia wymagań klienta lub zakończenie procesu wytwarzania z bliżej nieokreślonych względów (często politycznych). Powodów porażki może być wiele, ale najczęściej wskazywanymi były: brak większego zaangażowania ze strony klienta; zbyt ogólnie sformułowane wymagania lub ich modyfikacja; brak właściciela projektu; brak planu działania. Wydaje się więc, że rozważania na temat procesu wytwarzania oprogramowania są potrzebne, ponieważ twórcom systemów informatycznych zależy na tym, aby sukces jednego projektu przekładał się na następny, aby był powtarzalny. Takie podejście daje możliwość doskonalenia procesu wytwarzania oprogramowania poprzez dokonywanie pomiarów i oszacowań, a to z kolei wpływa na polepszenie jakości produktu i zadowolenie klienta. Nie wolno zapominać, że proces wytwarzania oprogramowania powinien być wspomagany przez narzędzia CASE, które oczywiście wymagają odpowiedniej konfiguracji na potrzeby danego projektu. Umiejętność wykorzystania tego typu narzędzi jest praktycznie warunkiem koniecznym powodzenia każdego większego przedsięwzięcia informatycznego. R E K L A M A