ESTYMACJA PARAMETRÓW PROCESU WYTWARZANIA OPROGRAMOWANIA. Maciej Grabowski, Małgorzata Łatuszyńska Wprowadzenie Wytwarzanie oprogramowania to jeden z typów projektów informatycznych. Proces wytwarzania oprogramowania, szczególnie w przypadku duŝych systemów informatycznych, podobnie jak proces realizacji wszelkich projektów informatycznych jest bardzo złoŝony i dlatego często kończy się niepowodzeniem. Według opracowania Standish Group w USA, obejmującego 8380 aplikacji jedynie 16% projektów informatycznych uwaŝa się za zakończone pomyślnie. AŜ 53% projektów przekroczyło załoŝony czas realizacji, nie zmieściło się w załoŝonym budŝecie albo w efekcie obejmowało mniejszą funkcjonalność niŝ zaplanowano [CaYe04, s. 34]. W związku z tym potrzebna jest wnikliwa analiza przyczyn takiego stanu rzeczy oraz poszukiwanie sposobów zapobiegania poraŝkom poprzez dobór odpowiedniej metody estymacji parametrów projektów exante (przede wszystkim koszty i czas realizacji projektu, por. [Szyj01 s.60-76]). W artykule omawia się przydatność róŝnych metod estymacji projektów informatycznych w zakresie wytwarzania oprogramowania w aspekcie złoŝoności procesu ich realizacji.
ZłoŜoność procesu wytwarzania oprogramowania Wytwarzanie oprogramowania jest projektem informatycznym, i jako taki stanowi niepowtarzalny, nierutynowy proces realizacji określonych celów w określonym czasie i za pomocą określonych środków [Szyj01, s. 16]. Jest to proces nierutynowy i niepowtarzalny, gdyŝ w przeciwieństwie do procesu wytwarzania wielu innych dóbr, który dla wszystkich egzemplarzy produktu przebiega się w pewien ściśle określony sposób (np. proces produkcji samochodów polega na powtarzaniu zestawu czynności - dla kaŝdego kolejnego egzemplarza tego samego typu proces jest identyczny), w procesie wytwarzania oprogramowania mamy do czynienia za kaŝdym razem z innym produktem: nowatorskim, róŝniącym się od wszystkiego, co do tej pory zostało utworzone. Proces jest nierutynowy, poniewaŝ po napisaniu programu nie istnieje juŝ problem produkowania kolejnych egzemplarzy zamiast tego tworzy się po prostu kopię, która nie wymaga juŝ kolejnych iteracji procesu wytwarzania oprogramowania. Na proces wytwarzania oprogramowania składa się kilka etapów. Są to: identyfikacja projektu, definicja projektu, realizacja projektu, ukończenie projektu [Szyj01, s. 60-76]. Celem pierwszego etapu jest precyzyjne określenie załoŝeń oraz celów projektu. NaleŜy tu zdeterminować potrzeby i wymagania. W projektach informatycznych występuje przy tym dodatkowe utrudnienie klient na ogół nie zna technologii i nie jest w stanie sprecyzować swoich oczekiwań uwzględniając sposób implementacji. Rolą analityka jest w takim przypadku przeprowadzenie wywiadu i przeanalizowanie potrzeb klienta
oraz wyjaśnienie wszelkich pojawiających się wątpliwości tak, aby uniknąć jakichkolwiek niedomówień i nieporozumień. PoniewaŜ na ogół moŝliwe jest osiągnięcie celu róŝnymi sposobami, naleŝy więc na tym etapie ustalić moŝliwe rozwiązania oraz skonfrontować wizję uŝytkownika z wizją realizatorów w celu wyboru najlepszego z dostępnych rozwiązań. Powinno to ostatecznie prowadzić do precyzyjnego zdefiniowania zakresu realizacji projektu. W fazie identyfikacji naleŝy równieŝ przeanalizować czynniki, które mogą zagraŝać realizacji projektu, aby prawidłowo ocenić ryzyko. Następnie powinny zostać ocenione szanse powodzenia oraz wskazane czynniki decydujące o sukcesie. Zakończeniem tej fazy powinno być opracowanie poczynionych ustaleń w formie sformalizowanego dokumentu, który powinien zostać podpisany przez kaŝdą ze stron. Ma to na celu uniknięcie późniejszych sporów, jakie mogłyby wynikać z niedomówień i róŝnic w interpretacji. Po określeniu głównych parametrów projektu rozpoczyna się faza definicji projektu. Mając wcześniej zdefiniowany zakres prac naleŝy określić dwa pozostałe parametry projektu, którymi są czas oraz budŝet. Poza zdefiniowaniem zakresu prac dobrze jest równieŝ precyzyjnie określić, czego projekt nie obejmuje. Ułatwia to późniejszy odbiór prac. Trzeci etap, czyli realizacja projektu, obejmuje projektowanie oraz właściwe programowanie, czyli implementację wyspecyfikowanych zadań przy pomocy jakiegoś konkretnego języka programowania oraz przy wykorzystaniu wybranych wcześniej technologii i metodologii. Wszelkie prace muszą być jednak odpowiednio wyspecyfikowane oraz konieczne jest opracowanie harmonogramu, według którego będą realizowane. W
trakcie realizacji powinna powstawać równieŝ dokumentacja obejmująca sposób działania poszczególnych funkcji jak równieŝ wszystkie zmiany, które zaszły w trakcie realizacji. Ostatni etap polega na odbiorze gotowego produktu, jakim moŝe być utworzony i wdroŝony system informatyczny, przeprowadzonym zgodnie z ustalonymi wcześniej zasadami. Powinno to nastąpić w terminie wyznaczonym w kontrakcie. Wielokrotnie jednak zdarza się, Ŝe z rozmaitych względów, nastąpiły opóźnienia w realizacji projektu. Taka sytuacja ma miejsce szczególnie często, jeŝeli w trakcie realizacji projektu informatycznego zaszły zmiany np. w zakresie wymagań klienta. W takim przypadku następuje określenie opóźnienia oraz wyznaczenie nowego terminu zakończenia projektu. Przekazanie produktu końcowego powinno zostać formalnie potwierdzone. MoŜliwe staje się wtedy porównanie faktycznie poniesionych nakładów z planowanym budŝetem projektu. Gotowy system informatyczny zaczyna funkcjonowanie i zaczyna się okres zapewnienia pomocy technicznej oraz serwisowania produktu. Z przedstawionego w skrócie opisu procesu realizacji projektu informatycznego, który ze swej natury jest procesem iteracyjnym, wymagającym dodatkowo ciągłej synchronizacji róŝnych elementów, widać wyraźnie jak bardzo jest on złoŝony. Aby dokładniej unaocznić złoŝoność procesu wytwarzania oprogramowania na rys. przedstawiono schemat przedstawiający czynności składające się na omawiany proces obrazujący zaleŝności przyczynowo-skutkowe występujące pomiędzy jego elementami. ZłoŜoność procesu wytwarzania oprogramowania, która przyczynia się duŝej ilości niepowodzeń w realizacji systemów informatycznych, wynika głównie z duŝej ilości elementów składających się na proces realizacji
projektu oraz występowania pomiędzy tymi elementami wielu sprzęŝeń prostych i zwrotnych zarówno dodatnich jak i ujemnych wpływających na ogólna dynamikę omawianego procesu. Rys. ZłoŜoność procesu wytwarzania oprogramowania (źródło: opracowanie własne na podstawie [Lebc02]) Ilość elementów, jakie naleŝy wziąć pod uwagę w procesie produkcji oprogramowania, jest zaleŝna od ilości zadań występujących na kaŝdym jego etapie: począwszy od analizy, poprzez projektowanie poszczególnych elementów gotowego programu oraz ich implementację, na testowaniu kaŝdego elementu z osobna oraz testach końcowych całości kończąc. NaleŜy przy tym zauwaŝyć, Ŝe ilość pojedynczych funkcji tworzonego programu moŝe wahać się od kilku do kilkuset.
Kolejnym czynnikiem znacznie podnoszącym stopień złoŝoności omawianego procesu jest ilość i charakter relacji pomiędzy poszczególnymi funkcjami tworzonego oprogramowania. W najprostszym przypadku mamy do czynienia z systemem informatycznym, realizującym kilka, zupełnie od siebie oderwanych funkcji, np. wysłanie wiadomości e-mail oraz przeglądanie kalendarza. KaŜda z tych funkcji moŝe być zaprojektowana i zaimplementowana w oderwaniu od drugiej. RównieŜ testowanie takich funkcji ograniczy się jedynie do sprawdzenia kaŝdej z nich osobno. JeŜeli natomiast rozwaŝymy zintegrowany system wspomagający np. realizację zamówień klientów i wyróŝnimy sobie w nim przetwarzanie zamówień oraz ich fakturowanie, to oczywistym staje się, Ŝe funkcje te nie mogą być traktowane zupełnie rozdzielnie. Poprawność fakturowania naleŝy weryfikować w kontekście zamówień, a wszelkie zmiany w jednym z modułów mogą mieć wpływ na drugi. W takim wypadku dochodzi problem testów końcowych: po oprogramowaniu kaŝdej z funkcji naleŝy sprawdzić działanie systemu jako całości. JeŜeli dodatkowo rozwaŝyć jeszcze w takim systemie np. ewidencjonowanie kontrahentów (co jest poniekąd naturalną koniecznością w przypadku przetwarzania zamówień), to oczywiste wydają się powiązania jakie będą występowały pomiędzy tymi modułami: konieczne jest sprzęŝenie między modułem ewidencji kontrahentów a zamówieniami oraz między modułem ewidencji kontrahentów a fakturowaniem. Dodatkowo naleŝy uwzględnić fakt, Ŝe sprzęŝenia pomiędzy poszczególnymi elementami mogą być proste (gdy jeden element oddziałuje na drugi) oraz zwrotne (gdy dwa elementy oddziałują na siebie wzajemnie). Konieczność zidentyfikowania i przeanalizowania wszelkich sprzęŝeń
równieŝ powoduje wzrost złoŝoności procesu wytwarzania oprogramowania. Jest to o tyle trudne, Ŝe w przypadku złoŝonych systemów ilość relacji pomiędzy poszczególnymi elementami moŝe być bardzo duŝa. Ostatnim aspektem decydującym o stopniu złoŝoności omawianego procesu jest dynamika całego procesu. Określone początkowo zasoby mogą ulegać zmianie w trakcie realizacji przedsięwzięcia. I chociaŝ w przypadku wytwarzania oprogramowania jest ich stosunkowo niewiele, to zmiany tych zasobów mogą mieć szczególny charakter. Przykładowo, moŝe ulec zmianie ilość osób wytwarzających oprogramowanie. Paradoksalnie, w olbrzymiej ilości projektów informatycznych, zwiększanie ilości osób zaangaŝowanych w realizację projektu zamiast do skrócenia czasu realizacji całego projektu prowadzi do jego wydłuŝenia, a często nawet do całkowitego fiaska. Wynika to z faktu, Ŝe ludzie angaŝowani do realizacji projektu na późnym etapie nie mają wiedzy i doświadczenia związanego z danym projektem, a to prowadzi do nieporozumień i komplikacji oraz spiętrzenia istniejących problemów. Ponadto, oprócz zmiany ilości, skład osobowy zmienia równieŝ się pod względem jakościowym ludzie pracując nad danym projektem zdobywają doświadczenie i wiedzę w miarę jego realizacji. Występowanie tego typu zmian w procesie wytwarzania oprogramowania równieŝ przyczynia się do wzrostu złoŝoności całego procesu. Przegląd metod estymacji parametrów procesu wytwarzania oprogramowania
ZłoŜoność procesu wytwarzania oprogramowania powoduje, Ŝe bardzo trudno oszacować w sposób precyzyjny parametry projektu. Proces ten, jak kaŝdy projekt, tak teŝ proces wytwarzania oprogramowania, określony jest przez: produkt końcowy czyli zakres prac, które mają być wykonane; opisuje on szczegółowo w uzgodnionej specyfikacji wszelkie funkcje, które mają być zawarte w tworzonym oprogramowaniu; czas realizacji czyli przede wszystkim czas, do którego projekt musi zostać ukończony, ale moŝna teŝ określić kilka etapów realizacji wraz z ich terminami; koszty realizacji czyli budŝet projektu. Do szacowania projektów informatycznych stosuje się, z mniejszym lub większym powodzeniem, róŝne metody. W tabeli zestawiono metody najczęściej wymieniane w literaturze w układzie wady-zalety ([Pieg03], [CaYe04]). Określając słabe i mocne strony metod brano między innymi pod uwagę, jak bardzo dane podejście oparte jest na doświadczeniach z przeszłości. Wynika to ze wspomnianej wcześniej cechy projektów informatycznych, jaką jest niepowtarzalność całego procesu. Poza pewnymi wspólnymi cechami (jak na przykład produktywność pracowników) nie ma moŝliwości wykorzystania doświadczenia z przeszłości, co moŝe stanowić o stosowalności niektórych metod. Tabela Wady i zalety metod estymacji projektów informatycznych METODA ZALETY WADY Modele parame- obiektywność wysoka subiektywność
METODA ZALETY WADY tryczne powtarzalność oceny wejść bazowanie na przeszłości Szacowanie przez analogię Szacowanie przez eksperta Sieci neuronowe wykorzystuje doświadczenie stosowalność przy braku precedensów szeroki wachlarz metod nauczania sieci moŝliwość analizowania heterogenicznych danych konieczne dane z przeszłości ograniczona stosowalność (sposób realizacji analogiczny do poprzednich projektów) subiektywność brak moŝliwości dokonania weryfikacji brak doświadczeń w realizacji tego typu przedsięwzięć brak zasad określających sposób organizacji sieci Logika rozmyta intuicyjność trudność w konstruowaniu zbioru warunków określających sposób działania systemu Podejście bazujące na regułach Drzewa regresji Systemy hybrydowe prostota w posługiwaniu się danymi wejściowymi wysoka wydajność obliczeniowa udany kompromis między prostotą a dokładnością przewidywania potencjalnie duŝe moŝliwości Źródło: Opracowanie własne. trudność dokładnej kwantyfikacji danych testuje się wartość jednego atrybutu na raz brak łatwej moŝliwości inkrementacyjnego aktualizowania kosztowna reprezentacja alternatyw brak doświadczeń w realizacji tego typu przedsięwzięć wzrost trudności wynikający z fuzyfikacji Pierwsze trzy metody są w bardzo duŝym stopniu oparte na doświadczeniach z przeszłości, co jak wcześniej wspomniano, powoduje znaczne problemy przy ich stosowaniu. Szczególnie szacowanie przez analogię zakłada wystąpienie podobnego projektu w przeszłości. Prowadzić to moŝe do znacznych błędów, gdyŝ wyszukiwanie podobieństw między
projektami moŝe prowadzić do przeoczenia lub wręcz zlekcewaŝenia róŝnic. Stosunkowo najlepiej pod tym względem wypada szacowanie przez eksperta, gdyŝ nie wymaga ono analogicznego projektu w przeszłości a jedynie wiedzy i doświadczenia z innych projektów. Nasuwa się jednak tu pytanie, na ile ta wiedza i doświadczenia mogą zostać przeniesione do nowego projektu. Dodatkowo, wadą tej metody jest jej subiektywność oraz brak moŝliwości weryfikacji oceny dokonanej przez eksperta. Sieci neuronowe są obiektywne i umoŝliwiają wykorzystanie danych w róŝnej, niekoniecznie liczbowej postaci. JednakŜe złoŝoność tej metody powoduje duŝe trudności w konstruowaniu sieci. Ze względu na niewielkie wykorzystanie tej metody do estymacji projektów trudno nawet oprzeć się na przeszłych doświadczeniach. Podobnie rzecz ma się z metodami bazującymi na logice rozmytej oraz regułach. ChociaŜ obie metody są bardzo intuicyjne, to jednak tworzenie zbioru warunków oraz kwantyfikacja danych są bardzo trudne i to w największym stopniu ogranicza ich stosowalność [Pieg03, s. 210]. Większą łatwością stosowania, przy jednocześnie wysokiej dokładności, charakteryzują się drzewa regresji. Problemem w tym przypadku jest to, Ŝe na kaŝdym etapie o sposobie dalszego postępowania decyduje wartość pojedynczego parametru. Ponadto rozwaŝenie alternatywnych sposobów realizacji projektu wymaga za kaŝdym razem tworzenia nowego, kompletnego drzewa, co w oczywisty sposób komplikuje wykorzystanie tej metody. Nie jest teŝ moŝliwe łatwe dodawanie kolejnych czynników mających wpływ na sposób realizacji przedsięwzięcia. DuŜe nadzieje związane są z wykorzystaniem metod stanowiących połączenie kilku spośród wyŝej wymienionych. Bardzo często łączy się lo-
gikę rozmytą i sieci neuronowe. NaleŜy przy tym jednak pamiętać, Ŝe oprócz zwiększenia moŝliwości bardzo często wzrasta równieŝ stopień trudności wykorzystania takich metod. Wnioski Przedstawiony, z konieczności skrócony, przegląd metod estymacji projektów informatycznych jest podstawą do stwierdzenia, Ŝe metody te mogą nie dawać precyzyjnych rezultatów. W związku z tym oczywista wydaje się potrzeba poszukiwania innych, alternatywnych metod w tym zakresie, przy czym poszukiwaną metodę powinny cechować: łatwość wykorzystania, moŝliwie niewielkie bazowanie na danych z przeszłości oraz moŝliwość jak najwierniejszego odwzorowania procesu wytwarzania oprogramowania. Zdaniem autorów wymagania te mogą być spełnione przez metodę opartą na modelowaniu symulacyjnym. W literaturze spotyka się bardzo pozytywne opinie na temat moŝliwości wykorzystania podejścia symulacyjnego do badania złoŝonych systemów a takim przecieŝ jest proces produkcji oprogramowania (por. [Lebc02], [XiLe05], [NiWW05], [Ster02], [Cemp03]). Przykładowo C. Cempel stwierdza, Ŝe w poznawaniu systemów złoŝonych, symulacja przez swą zdolność manipulacji czasoprzestrzenią jest jedynym narzędziem pozwalającym ująć i zrozumieć przyczynowo skutkowe powiązania odległe w czasie i w przestrzeni i powiązane wieloma sprzęŝeniami zwrotnymi. Symulację komputerową charakteryzuje duŝa łatwość w stosowaniu mając model symulacyjny moŝna przeanalizować wiele róŝnych warian-
tów i warunków realizacji projektu bez dodatkowego nakładu pracy. Nie są równieŝ wymagane doświadczenia z przeszłości do opisania projektu oraz późniejszej eksploatacji modelu. Jednocześnie metoda ta pozwala na bardzo dobre opisanie całego projektu. Decyduje o tym kilka czynników, ale podstawowy wynika z moŝliwości ujmowania złoŝonego procesu w sposób dynamiczny, w przeciwieństwie do statycznych metod modelowania przedstawionych wcześniej. To wszystko pozwala twierdzić, Ŝe zastosowanie podejścia opartego na symulacji komputerowej moŝe przełamać bariery ograniczające stosowalność innych metod oraz umoŝliwić bardziej precyzyjną estymację projektów informatycznych przyczyniając się tym samym do zwiększenia ilości projektów zakończonych sukcesem. WaŜną kwestią jest oczywiście dobór szczegółowej techniki modelowania symulacyjnego - i tu, na podstawie literatury przedmiotu, moŝna zaryzykować hipotezę, Ŝe do estymacji procesu wytwarzania oprogramowania korzystne byłoby zastosowanie podejścia symulacyjnego opartego na teorii dynamiki systemów. Zagadnienie to jednak, ze względu na swój wymiar, powinno stanowić temat odrębnego artykułu. Literatura [CaYe04] Cadle J., Yeates D.: Zarządzanie procesem tworzenia systemów informacyjnych, Wydawnictwa Naukowo- Techniczne, Warszawa 2004.
[Cemp03] [Lebc02] [NiWW05] [Pieg03] [Ster02] [Szyj01] [XiLe05] Cempel C.: Nowoczesne Zagadnienia Metodologii i Filozofii Badań, Politechnika Poznańska, Internet 2002-2003, http://neur.am.put.poznan.pl/. Lebcir R.: Integrative Mechanisms in New Product Development Projects: Effect of Project Complexity on Project Performance A System Dynamics Approach, Proceedings of the 2 nd IEEE Engineering Management Society International Conference, Cambridge 18-20 August 2002, http://www.systemdynamics.org/conf2002/papers/lebcir1. pdf. Ning X. Wang Q. Wu B.: The Influence of Schedule Target on Project Performance, The 23rd International Conference of the System Dynamics Society, Boston 2005. Piegat A.: Modelowanie i sterowanie rozmyte, Akademicka Oficyna Wydawnicza EXIT, Warszawa 2003. Sterman J.: System Dynamics Modeling for Project Management, Projects & Profits 2002, s. 46-50. Szyjewski Z.: Zarządzanie projektami informatycznymi, A.W. Placet, Warszawa 2001. Xia W., Lee G.: Complexity of Information Systems Development Projects: Conceptualization and Measurement Development, Journal of Management Information Systems Vol. 22 No. 1, 2005, s. 45 84. Informacje o autorach
dr hab. Małgorzata Łatuszyńska mgr Maciej Grabowski Instytut Informatyki w Zarządzaniu Wydział Nauk Ekonomicznych i Zarządzania Uniwersytet Szczeciński ul. Mickiewicza 66 71-101 Szczecin Numer telefonu +48/91/4441915 e-mail: malgorzata.latuszynska@uoo.univ.szczecin.pl maciejg@gmail.com