z ograniczeniami do wariantowania przedsięwzięć informatycznych

Transkrypt

1 Wykorzystanie technik programowania z ograniczeniami 99 Marcin RELICH Zakład Controllingu i Informatyki Ekonomicznej, Uniwersytet Zielonogórski E mail: m.relich@wez.uz.zgora.pl Wykorzystanie technik programowania z ograniczeniami do wariantowania przedsięwzięć informatycznych Streszczenie: Celem niniejszej pracy jest wykorzystanie technik programowania z ograniczeniami do wariantowania przedsięwzięć informatycznych zagrożonych niepowodzeniem. W pracy przedstawiono model referencyjny, stanowiący podstawę do formułowania i rozwiązywania problemów decyzyjnych dotyczących w szczególności określenia wariantów alternatywnych projektu. Model referencyjny składa się ze skończonego zbioru zmiennych decyzyjnych, ich dziedzin oraz ograniczeń, które opisują przedsiębiorstwo oraz obszary zarządzania projektem. Specyfikacja problemów decyzyjnych w postaci problemu spełniania ograniczeń pozwala formułować pytania rutynowe w oparciu o wspólną, integrującą kwestię zarządzania, bazę wiedzy. Deklaratywny charakter proponowanego modelu referencyjnego w naturalny sposób pozwala implementować go w środowiskach programowania z ograniczeniami. 1. Wstęp W działalności współczesnych organizacji coraz większego znaczenia nabierają działania niepowtarzalne, zwane przedsięwzięciami lub projektami. Projekt jest sekwencją unikalnych, złożonych i powiązanych ze sobą czynności, mających jeden cel, który musi zostać zakończony w określonym czasie, budżecie i zgodnie ze specyfikacją [11]. Rośnie w związku z tym zapotrzebowanie na wiedzę umożliwiającą rozwiązywanie problemów występujących w realizacji złożonych przedsięwzięć. Kluczowe znaczenie ma tu znajomość zasad zarządzania projektami, w szczególności zaś identyfikacji czynników wpływających na sukces czy porażkę projektu i stosowanych w związku z tym specyficznych metod oraz technik. Zebrane doświadczenia wskazują, że projekty zakończone sukcesem, tzn. zrealizowane w terminie i przy założonych nakładach stanowią mniej niż połowę wszystkich projektów [6, 13, 16, 19, 21]. Większość projektów przekracza czas realizacji przyjęty w projekcie bazowym o 40%-200% [15]. Przykładowo tylko jedna trzecia projektów Banku Światowego realizuje swój cel, ze średnim opóźnieniem wynoszącym 50%. Inne badania wskazują, że tylko 17% projektów spełnia przyjęte kryteria kosztu, cza-

2 100 Marcin Relich su i celu, ze średnim przekroczeniem kosztów o 189% [7]. W przypadku projektów informatycznych aż 60-80% nie jest zgodnych z pierwotną specyfikacją [8, 12, 20]. Na realizację projektu wpływa wiele czynników, które mogą dotyczyć rodzaju projektu, dostępności zasobów, zarządzania projektem oraz środowiska zewnętrznego [2, 16]. Przyczyny niepowodzeń realizacji projektu w ogólności dotyczą zmienności występowania zasobów w przedsiębiorstwie oraz jego otoczeniu, jednakże mogą one również zostać spowodowane brakiem poprawnie zdefiniowanego celu projektu, zmienną specyfikacją projektu zgodnie z wymaganiami zleceniodawcy, nieodpowiednią jakością zarządzania czy nieodpowiednimi umiejętnościami pracowników. W przypadku przedsiębiorstw, które realizują jednocześnie kilka projektów, przekroczenie planów projektu może zostać również spowodowane zmianą priorytetu danego projektu. Skuteczna realizacja projektu wymaga planowania zawierającego między innymi oszacowania stopnia zaawansowania projektu, pożądanych zasobów, czasu itp., czyli parametrów, które są niezbędne do realizacji danej czynności projektu. W celu zredukowania nadmiernego przekroczenia zaplanowanych wartości parametrów projektu zazwyczaj zostaje wykorzystane jedno z dwóch podejść. Po pierwsze można zwiększyć dokładność oszacowań, po drugie zwiększyć kontrolę projektu. Oczekiwanie bardzo dokładnych prognoz parametrów projektów nie jest realne, ze względu na pewien poziom niepewności związany ze specyfiką przedsięwzięcia, a także złożoność i dynamikę interakcji pomiędzy czynnikami wpływającymi na jego rozwój. Jednakże nawet niewielka poprawa dokładności oszacowań jest pożądana, szczególnie biorąc pod uwagę dużą skalę przedsięwzięć. Poprzez dokładniejsze prognozowanie, menedżerowie projektu mogą zostać wsparci na etapie planowania oraz monitorowania projektu, na przykład poprzez dokładniejsze określenie wymaganych nakładów, alokacji zasobów, zaplanowania harmonogramu realizacji inwestycji. Tematyka ratowania przedsięwzięć zagrożonych niepowodzeniem skupia się zazwyczaj na aspekcie precyzyjnie zdefiniowanych celów projektu, na zwiększeniu szczegółowości planowania i związanej z tym kontroli stopnia realizacji projektu czy też zwiększeniu częstotliwości spotkań zespołu projektowego [10]. W przypadku wystąpienia znacznych odchyleń pomiędzy planem a jego realizacją, zazwyczaj ma miejsce pozyskanie dodatkowych zasobów w celu doraźnego usunięcia wąskich gardeł oraz prowadzenie negocjacji dotyczących zmiany wymagań zleceniodawcy przedsięwzięcia [14, 22]. Brakuje jednak podejścia, które w przypadku przewidywalnego zagrożenia niepowodzeniem przedsięwzięcia umożliwiałoby generowanie zbioru wariantów alternatywnych dokończenia projektu i dzięki temu wsparcie decydenta w procesie podejmowania decyzji. Wariant alternatywny należy rozumieć jako modyfikację projektu bazowego, dotyczącą czasu, kosztu czy też zakresu realizowanego przedsięwzięcia. Szybko zmieniające się oczekiwania związane ze wspomaganiem decyzji, jak również dążenie do zmniejszenia ryzyka związanego z podjęciem niewłaściwej decyzji, stanowią potrzebę opracowania dedykowanego systemu wspomagania decyzji. Występujące w literaturze podejścia odrębnie rozpatrują obszar przedsiębiorstwa oraz zarządzania przedsięwzięciem. Odrębność ta wynika z istnienia oddzielnych baz

3 Wykorzystanie technik programowania z ograniczeniami 101 wiedzy dla obszaru przedsiębiorstwa i zarządzania przedsięwzięciem. Konsekwencją tego jest trudność implementacji tych obszarów w ramach jednego narzędzia, wykorzystywanego do wspomagania decyzji. Powstaje w związku z tym potrzeba budowy jednego modelu łączącego obszary przedsiębiorstwa i zarządzania przedsięwzięciem, stanowiącego platformę do opracowania dedykowanego systemu wspomagania decyzji. W kolejnych rozdziałach pracy przedstawiono obszary charakteryzujące przedsiębiorstwo oraz zarządzanie przedsięwzięciem, zapisano model referencyjny w postaci problemu spełnienia ograniczeń (rozdział 2), sformułowano problem wariantowania przedsięwzięć zagrożonych niepowodzeniem (rozdział 3), a także przedstawiono metodę wariantowania dopuszczalnych realizacji projektu (rozdział 4). W rozdziale 5 przedstawiono przykład ilustrujący funkcjonowanie proponowanej metody. W zakończeniu pracy przedstawiono uwagi końcowe oraz wnioski. 2. Model referencyjny przedsiębiorstwa oraz zarządzania przedsięwzięciem Przedsiębiorstwo rozumiane w kategoriach systemów złożonych [3] może być opisywane poprzez wiele kryteriów, odpowiadających jego strukturze oraz cechom otoczenia, a także pozwalających na różnorodną klasyfikację przedsiębiorstw. Na rysunku 1 przedstawiono przykładowe obszary związane z działalnością przedsiębiorstwa, jego otoczeniem oraz klasyfikacją. Należy zaznaczyć, że dany obszar można opisać zbiorem kryteriów, miar, zwanych dalej zmiennymi decyzyjnymi. Przykładem może być wyznaczanie wielkości przedsiębiorstwa według liczby zatrudnionych, wartości obrotów rocznych czy wielkości produkcji. Ponadto obszary te mogą być wzajemnie powiązane ze sobą, np. wielkość kupowanych w danym okresie materiałów zależy od informacji dotyczących planowanej sprzedaży, produkcji (m.in. dostępnych mocy przerobowych) czy też zgromadzonych w magazynach zapasach tychże materiałów. Projekt realizowany jest zgodnie ze specyfiką i dostępnymi zasobami danego przedsiębiorstwa. Z tego też powodu obszary funkcjonowania przedsiębiorstwa wpływają na obszary dotyczące zarządzania przedsięwzięciem. Przykładowo od rodzaju prowadzonej działalności zależy czy przedsiębiorstwo będzie mogło realizować dany typ przedsięwzięcia. Również wielkość czy rodzaj własności przedsiębiorstwa determinuje realizację projektu, gdyż małe prywatne przedsiębiorstwo, ze względu na ograniczenia finansowe i personalne nie mogłoby zapewnić wymaganej ilości zasobów do wykonania dużego przedsięwzięcia, np. budowy lotniska. Proponowane podejście łączy w ramach jednego modelu obszar przedsiębiorstwa oraz zarządzania przedsięwzięciem. W przypadku rozwiązywania typowych problemów decyzyjnych występujących w przedsiębiorstwach zajmujących się realizacją projektów, wydaje się czymś naturalnym połączenie elementów związanych z przedsiębiorstwem oraz zarządzaniem przedsięwzięciem w ramach jednej platformy modelu referencyjnego. W ten sposób powstaje jedna baza wiedzy, która w uzupełnieniu o mechanizmy wnioskowania umożliwia łatwiejszą implementację systemu wspomagania decyzji.

4 102 Marcin Relich Otoczenie prawne ekonomiczne technologiczne społecznokulturowe ekologiczne Rodzaj własności prywatne spółdzielcze samorządu terytorialnego państwowe Struktura organizacyjna liniowa funkcjonalna dywizjonalna macierzowa mieszana Przedsiębiorstwo Obszary funkcjonalne zakupy produkcja sprzedaż gospodarka magazynowa marketing finanse personel rachunkowość Zakres terytorialny jednozakładowe wielozakładowe sieciowe Zakres internacjonalizacji krajowe międzynarodowe wielonarodowe globalne Wielkość mikro małe średnie duże Rodzaj prowadzonej działalności produkcyjna handlowa usługowa Forma prawna prywatne i spółki cywilne spółki prawa handlowego spółki handlowe kapitałowe Rys. 1. Obszary funkcjonowania przedsiębiorstwa W analogiczny sposób można również podejść do problematyki zarządzania przedsięwzięciem. Zgodnie ze standardem Project Management Institute zarządzanie projektami jest postrzegane jako 9 obszarów aktywności (rysunek 2). Przedstawione na rysunkach 1 i 2 obszary funkcjonowania przedsiębiorstwa oraz charakteryzujące zarządzanie przedsięwzięciem dotyczą przypadku ogólnego, pozwalającego na opisanie dowolnego rodzaju przedsięwzięcia w dowolnym przedsiębiorstwie. W celu zilustrowania idei połączenia tych obszarów w ramach jednego modelu referencyjnego, ogólny przypadek ograniczono dalej do klasy przedsiębiorstw usługowych średniej wielkości wdrażających projekty informatyczne. Zarówno w przedsiębiorstwie jak i przy zarządzaniu przedsięwzięciem występują pewne funkcjonalności. Mogą one dotyczyć tych samych obszarów np. zarządzania ludźmi (tak w dziale administracji przedsiębiorstwa, jak i przy projekcie) lub też stanowić odrębny obszar np. planowanie sprzedaży dotyczące zarządzania przedsiębiorstwem czy zarządzanie integracją projektu. Na rysunku 3 przedstawiono przykładowy zestaw funkcjonalności w obszarze zarządzania przedsiębiorstwem oraz projektem. Obszary te są ze sobą powiązane poprzez ograniczenia, oznaczone na rysunku 3 symbolem C1. Przykładowo liczba pracowników przedsiębiorstwa informatycznego, np. programistów powinna być większa od zapotrzebowania związanego z realizacją przedsięwzięcia informatycznego. Innym przykładem ograniczenia łączącego dwa rozważane obszary może być

5 Wykorzystanie technik programowania z ograniczeniami 103 niższa wartość wymaganych nakładów na wykonanie projektu od poziomu środków pieniężnych w przedsiębiorstwie. Zarządzanie przedsięwzięciem Zarządzanie integracją - planowanie projektu - planowanie realizacji projektu - sterowanie zmianami Zarządzanie zakresem - definicja zakresu - planowanie projektu - weryfikacja i sterowanie zmianami zakresu Zarządzanie czasem - definiowanie działań - szacowanie czasu realizacji zadań - harmonogramowanie - kontrolowanie harmonogramu Zarządzanie kosztami - planowanie zasobów - szacowanie kosztów - budżetowanie kosztów - kontrolowanie kosztów Zarządzanie ludźmi - planowanie organizacji zespołu - pozyskiwanie pracowników - tworzenie zespołu - kontrolowanie kosztów Zarządzanie jakością - planowanie jakości - zapewnienie jakości - kontrolowanie jakości Zarządzanie komunikacją - planowanie komunikacji - dystrybucja informacji - raportowanie - administrowanie zamknięciem projektu Zarządzanie ryzykiem - identyfikacja ryzyka - ocena ryzyka - przeciwdziałanie ryzyku - kontrolowanie działań zapobiegawczych Zarządzanie dostawami - planowanie dostaw - wybór źródła dostaw - administrowanie kontraktem Rys. 2. Obszary charakteryzujące zarządzanie przedsięwzięciem Związki łączące przedsiębiorstwo z realizowanym w nim projektem (C 1 ) Zarządzanie przedsiębiorstwem Zarządzanie ludźmi Planowanie sprzedaży Związki łączące typy zarządzania (C 11 ) Związki łączące typy zarządzania (C 12 ) Zarządzanie projektem Zarządzanie ludźmi Zarządzanie integracją Zarządzanie czasem Rys. 3. Idea hierarchicznej struktury modelu referencyjnego Poszczególne funkcjonalności związane z zarządzaniem przedsiębiorstwem oraz projektem zawierają pewne wspólne elementy dotyczące samego zarządzania, oznaczone na rysunku 3 symbolem C 11, C 12. Przykładowo zarządzanie ludźmi składa się z planowa-

6 104 Marcin Relich nia, organizowania, zatrudnienia, motywowania i kontroli. Realizacja tych elementów następuje w kontekście obszarów funkcjonowania przedsiębiorstwa (rysunek 1). Wobec tego na zarządzanie ludźmi wpływa m.in. otoczenie firmy (np. sytuacja na rynku krajowym i międzynarodowym) czy rodzaj własności (inna polityka zatrudnienia w przedsiębiorstwie prywatnym i państwowym). Realizacja innej funkcjonalności planowania sprzedaży uzależniona jest m.in. od rodzaju prowadzonej działalności, gdzie w przypadku przedsiębiorstwa produkcyjnego, planowanie sprzedaży powinno uwzględniać harmonogram produkcji. W analogiczny sposób można również podejść do określenia związków łączących różne funkcjonalności w obszarze zarządzania projektem, oznaczonych na rysunku 3 symbolem C 12. W tej sytuacji funkcjonalności zależą od elementów zarządzania takich jak planowanie czy kontrola, lecz również zostają zdeterminowane rodzajem przedsięwzięcia, np. zarządzanie integracją czy zarządzanie czasem będzie inne dla projektu informatycznego oraz inne dla budowlanego. Model przedsiębiorstwa charakteryzują moce wytwórcze będące w jego dyspozycji. Model projektu wynika z potrzeb zleceniodawcy (lub w przypadku przedsięwzięć własnych z określonych wymagań przedsiębiorstwa). W modelu przedsiębiorstwa oraz modelu projektu przyjmuje się pewne parametry, wśród których można wyróżnić zbiory zmiennych decyzyjnych oraz ograniczeń. Modelowane ograniczenia wiążą zarówno zmienne decyzyjne opisujące możliwości przedsiębiorstwa, jak też zmienne charakteryzujące warunki realizacji projektu [4]. Przykładowo ilość pracowników przedsiębiorstwa ogranicza czas realizacji projektu. Oznacza to, że spełnienie przyjętych ograniczeń umożliwia realizację danego projektu przez przedsiębiorstwo zgodnie z przyjętymi wymaganiami. Z uwagi na sposób specyfikacji modelu, ograniczający się w zasadzie do specyfikacji zbiorów: zmiennych decyzyjnych, dziedzin zmiennych oraz ograniczeń narzucanych na podzbiory zmiennych, naturalnym wydaje się sklasyfikowanie odpowiednich problemów decyzyjnych jako problemów należących do klasy Problemów Spełnienia Ograniczeń (PSO) (ang. constraints satisfaction problem - CSP). Przyjęty sposób specyfikacji warunkowany ograniczeniami modelu referencyjnego problemu decyzyjnego, pozwala na pewien uproszczony opis sytuacji rzeczywistej, tzn. opis obejmujący założenia dotyczące obiektu, realizowanych z nim zadań oraz zbioru pytań rutynowych (instancji problemów decyzyjnych) formułowanych w kontekście PSO [1, 4]. W dalszych rozważaniach przyjmuje się, że model referencyjny problemu wariantowania przedsięwzięć zagrożonych niepowodzeniem ma strukturę Problemu Spełnienia Ograniczeń, tzn. wyraża się w postaci [1, 4]: PSO = ((V, D), C) (1) gdzie: V = {v 1, v 2,..., v n } skończony zbiór n zmiennych decyzyjnych, D = {d 1, d 2,..., d n } zbiór dziedzin n zmiennych decyzyjnych, C = {c 1, c 2,..., c m } skończony zbiór m ograniczeń wiążących zmienne decyzyjne.

7 Wykorzystanie technik programowania z ograniczeniami 105 PSO implementowany w językach programowania z ograniczeniami (ang. Constraint Programming CP), kojarzony z obszarem technik sztucznej inteligencji, badań operacyjnych oraz języków programowania deklaratywnego, wykorzystywany jest do modelowania, rozwiązywania i implementacji problemów, które mogą być opisane za pomocą zbioru stanów wyrażanych w postaci ograniczeń, odzwierciedlających zależności pomiędzy zmiennymi problemu. Poszukiwane rozwiązanie PSO jest rozwiązaniem dopuszczalnym, w którym wartości wszystkich zmiennych spełniają wszystkie ograniczenia, bądź też rozwiązanie optymalne ekstremalizujące funkcję celu określoną na wybranym podzbiorze zmiennych decyzyjnych. W poszukiwaniu rozwiązania wykorzystywane są techniki propagacji ograniczeń i dystrybucji zmiennych [4, 17]. PSO implementowany jako model referencyjny może być również interpretowany jako swoista baza wiedzy (BW), obejmująca zbiory zmiennych decyzyjnych i ich dziedziny oraz relacje (ograniczenia). BW służy jako platforma, tak dla formułowania pytań, jak i wypracowywania odpowiedzi. Przyjmuje się, że BW budowana jest w oparciu o regułową reprezentację wiedzy. Oznacza to, że informacja zapisywana jest przy użyciu faktów i reguł. Fakt wyraża pewne przekonanie, zaś reguła formułuje związek przyczynowo-skutkowy między podzbiorami faktów pochodzących z tej samej przestrzeni (dziedziny wiedzy). BW można postrzegać jako układ wejście wyjście [5]. Wejście układu opisują zmienne reprezentujące podstawowe cechy obiektu, znane i zadawane przez użytkownika. W rozważanej BW dla obiektu opisywanego modelem przedsiębiorstwo projekt są to m.in. zmienne dotyczące struktury przedsięwzięcia (sieci czynności), zmienne określające ilość zasobów przedsiębiorstwa, itp. Wyjście z kolei opisuje zbiór zmiennych reprezentujących cechy obiektu, które nie są znane, lub są znane tylko częściowo. W rozważanym przypadku mogą to być zmienne określające koszty czynności, czasy realizacji czynności, obciążenie zasobów, poziom wskaźników efektywności inwestycji itp. [4]. Wyróżnienie w bazie wiedzy zmiennych decyzyjnych klasyfikowanych jako należących do zmiennych wejściowych i wyjściowych dokonywane jest w sposób arbitralny i umożliwia formułowanie pytań typu [1, 4]: jakie wartości przyjmą parametry opisujące właściwości zmiennych wyjściowych obiektu, gdy zadane są wartości parametrów opisujących właściwości zmiennych wejściowych? (np. na jakie terminy ukończenia projektu wskazują zadane wartości zasobów finansowych, pracowników oraz dopuszczalne warianty alokacji zasobów?) jakie wartości przyjmą parametry opisujące właściwości zmiennych wejściowych obiektu, gdy zadane są wartości parametrów opisujących właściwości zmiennych wyjściowych? (np. jakie wartości zasobów oraz ich dopuszczalne warianty alokacji implikują ukończenie projektu w zadanym terminie?) Pierwszy typ pytania dotyczy wnioskowania w przód, drugi wnioskowania wstecz. Odpowiedzi na powyższe pytania poszukuje się przy założeniu, że wszystkie ograniczenia opisujące obiekt są prawdziwe. W kolejnym rozdziale przedstawiono problem wariantowania przedsięwzięcia zagrożonego niepowodzeniem, sformułowany w kontekście PSO.

8 106 Marcin Relich 3. Sformułowanie problemu wariantowania przedsięwzięć zagrożonych niepowodzeniem Przedstawiona na rysunku 3 hierarchiczna struktura modelu referencyjnego implikuje podobną strukturę określającą Problem Spełnienia Ograniczeń. Rysunek 4 przedstawia ideę tego podejścia. Model referencyjny wariantowania przedsięwzięć można opisać w postaci jednego PSO, które składa się z PSO 1 dotyczącego obszaru funkcjonowania przedsiębiorstwa oraz PSO 2 dotyczącego obszaru zarządzania przedsięwzięciem. Z kolei PSO 1 i PSO 2 zawiera kolejne elementy opisujące funkcjonalności występujące w rozważanych obszarach (PSO 11,..., PSO 1n oraz PSO 21,..., PSO 2n ). PSO PSO 1 PSO 2 PSO PSO 1n PSO PSO 2n Rys. 4. Struktura Problemu Spełnienia Ograniczeń Przyjmując dwupoziomową strukturę modelu referencyjnego problemu wariantowania przedsięwzięć zagrożonych niepowodzeniem (MRPWP), można go zapisać w następującej postaci (por. rys. 3, 4 oraz (1)): MRPWP = ((PSO 1, PSO 2 ), C) (2) PSO 1 dotyczy obszaru funkcjonowania przedsiębiorstwa, PSO 2 obszaru zarządzania przedsięwzięciem, natomiast C stanowią ograniczenia łączące te dwa obszary, w jeden Problem Spełnienia Ograniczeń. Wielkości te są definiowane następująco: gdzie: PSO 1 = (({R 1, R 2 }, {D R1, D R2 }), C PSO1 ) (3) R 1 = {r 1,1,1,..., r 1,m,h,..., r 1,M,H } wartość zasobu finansowego dla m-tej grupy środków pieniężnych (np. gotówka, lokaty i należności krótkoterminowe) w h-tej jednostce czasu horyzontu H (h = 0, 1,..., H). Dany jest zbiór zasobów R = (R 1,..., R k,..., R z ); R 2 = {r 2,1,1,..., r 2,n,h,..., r 2,N,H } liczba roboczogodzin dla n-tej grupy pracowników (np. programistów) w h-tej jednostce czasu horyzontu H; D R1 zbiór dopuszczalnych wartości środków pieniężnych R 1, r 1,m,h D R1 ; D R2 zbiór dopuszczalnych wartości roboczogodzin R 2, r 2,n,h D R2. Należy zwrócić uwagę, że w przypadku znanych wartości zmiennych decyzyjnych, dziedziny są zbiorami jednoelementowymi.

9 Wykorzystanie technik programowania z ograniczeniami 107 C PSO1 zbiór ograniczeń: C PSO1,1 wartość dostępnych w przedsiębiorstwie środków pieniężnych nie może być większa niż suma wartości gotówki (r 1,1,h ), środków na rachunkach bankowych (r 1,2,h ), należności (r 1,3,h ) oraz kredytów bankowych (r 1,4,h ) w h-tej jednostce czasu: r 1,1,h + r 1,2,h + r 1,3,h + r 1,4,h r 1,h (4) C PSO1,2 liczba dostępnych w przedsiębiorstwie roboczogodzin nie może być większa niż suma iloczynów liczby pracowników n-tej grupy (analityków r 2,1,h, konsultantów r 2,2,h, programistów r 2,3,h ) oraz dziennego wymiaru godzin pracy wh: wh (r 2,1,h + r 2,2,h + r 2,3,h ) r 2,h (5) W przypadku obszaru zarządzania przedsięwzięciem (PSO 2 ) wybrano jedną funkcjonalność dotyczącą harmonogramowania. Przyjęto, że każde przedsięwzięcie P i składa się z J czynności: P i = {A i,1,..., A i,j,..., A i,j }. Przyjmuje się, że: każda czynność może być wykonana przy udziale, co najmniej jednego z zasobów przedsiębiorstwa, czynności są niepodzielne, rozpoczęcie kolejnej czynności następuje po zakończeniu czynności poprzedzającej, pod warunkiem dostępności danego zasobu, każdy zasób w danej czynności A i,j może być wykorzystany tylko jednokrotnie, ilość danego zasobu wykorzystywanego przez daną czynność A i,j nie może ulec zmianie, nie może również zostać przydzielona do innej czynności, warunkiem rozpoczęcia czynności A i,j jest dostęp do żądanej liczby zasobów w terminach Tp i,j. Zasoby należą do klasy zasobów niewywłaszczalnych, tzn. zasobów, które przydzielone do czynności mogą zostać zwolnione dopiero po ukończeniu etapu czynności wymagającego zastosowania danego zasobu. Przyjęto ponadto, że znana jest liczba dostępnych zasobów r k,h w h-tej jednostce czasu horyzontu H. Horyzont planowania obejmuje zbiór wartości reprezentujących momenty rozpoczęcia kolejnych jednostek czasu.

10 108 Marcin Relich Obszar dotyczący zarządzania przedsięwzięciem można zapisać w następującej postaci: PSO 2 = (({P i, A i,l, s i,j, t i,j, Tp i,j, Tz i,j, Dp i,j }, {D Pi, D Ai, D si, D ti, D Tpi, D Tzi, D Dpi }), C PSO2 (6) gdzie: P i i-te przedsięwzięcie; A i,j j-ta czynność i-tego przedsięwzięcia, definiowana następująco: A i,j = (s i,j, t i,j, Tp i,j, Tz i,j, Dp i,j ); s i,j termin rozpoczęcia czynności A i,j ustalony względem terminu rozpoczęcia projektu s 1,1 ; t i,j czas trwania czynności A i,j ; Tp i,j = (tp i,j,1, tp i,j,2,..., tp i,j,z ) oznacza sekwencję terminów pobrania przez czynność A i,j kolejnych zasobów: tp i,j,k termin pobrania przez czynność A i,j k-tego zasobu w ilości dp i,j,k, liczony względem s i,j. Przyjmuje się, że zasób jest pobierany w trakcie trwania czynności: 0 tp i,j,k < t i,j; k = 1, 2,..., z; Tz i,j = (tz i,j,1, tz i,j,2,..., tz i,j,z ) oznacza sekwencję terminów zwolnienia przez czynność A i,j kolejnych zasobów: tz i,j,k termin zwolnienia przez czynność A i,j k-tego zasobu w ilości dp i,j,k, liczony względem s i,j ; Dp i,j = (dp i,j,1, dp i,j,2,..., dp i,j,z ) oznacza sekwencję liczby zasobów pobieranych przez czynność A i,j : dp i,j,k ilość k-tego zasobu pobieranego przez czynność A i,j ; D Pi zbiór dopuszczalnej liczby przedsięwzięć realizowanych w przedsiębiorstwie; D Ai zbiór dopuszczalnej liczby czynności w i-tym projekcie; D si zbiór dopuszczalnych terminów rozpoczęcia czynności A i,j w i-tym projekcie; D ti zbiór czasów realizacji czynności A i,j w i-tym projekcie; D Tpi zbiór dopuszczalnych terminów pobrania przez czynność A i,j k-tego zasobu w ilości dp i,j,k, w i-tym projekcie; D Tzi zbiór dopuszczalnych terminów zwolnienia przez czynność A i,j k-tego zasobu w ilości dp i,j,k, w i-tym projekcie; D Dpi zbiór dopuszczalnych liczby zasobów pobieranych przez czynność A i,j, w i-tym projekcie; C PSO2 zbiór ograniczeń: C PSO2,1 ograniczenie na horyzont realizacji przedsięwzięcia H = {0, 1,..., h}: s i,j t i,j (s i,j + ti,j H) (7) C PSO2,2 ograniczenie kolejnościowe [4]: - dla czynności występujących po sobie A i,j A i,k ograniczenie: s i,j + t i,j s i,k (8) - dla wielu poprzedników A i,j+1, A i,j+2,..., A i,j+n A i,k ograniczenia dla n poprzedników: s i,j + t i,j s i,k ; s i,j+1 + t i,j+1 s i,k ;...; s i,j+n + t i,j+n s i,k (9)

11 Wykorzystanie technik programowania z ograniczeniami dla wielu następników A i,k A i,j+1, A i,j+2,..., A i,j+n ograniczenia dla n następników: s i,k + t i,k s i,j ; s i,k + t i,k s i,j+1 ;...; s i,k + t i,k s i,j+n (10) Ograniczenia kolejnościowe tworzą relację binarną między czynnościami. Jeśli A 1,1 i A 1,2 są dwiema czynnościami i A 1,1 poprzedza A 1,2, co zapisuje się A 1,1 A 1,2, oznacza to, że A 1,1 musi skończyć się przed rozpoczęciem A 1,2. W modelu referencyjnym problemu wariantowania przedsięwzięcia elementem łączącym PSO 1 oraz PSO 2 są ograniczenia C (por. (2)). Do ograniczeń tych można zaliczyć: C 1 środki pieniężne dla i-tego projektu r 1h,i nie mogą być większe niż łączna wartość środków pieniężnych r1 h dostępnych w przedsiębiorstwie w h-tej jednostce czasu: r 1h,i r 1h (11) C 2 liczba dostępnych roboczogodzin dla i-tego projektu i n-tej grupy pracowników (r 2n,h, i ) nie może być większa niż łączna wartość roboczogodzin dostępnych w przedsiębiorstwie w h-tej jednostce czasu r 2h : r2 n,h,i r2 h (12) PSO 1 = (({R 1, R 2 }, {D R1, D R2 }), {(4), (5)}) C = {(11), (12)} PSO 2 = (({P i, A i,l, s i,j, t i,j, Tp i,j, Tz i,j, Dp i,j }, {D Pi, D Ai, D si, D ti, D Tpi, D Tzi, D Dpi }), {(7), (8), (9), (10)}) Rys. 5. Model referencyjny deklaratywnej reprezentacji problemu wariantowania przedsięwzięć Przyjęto, że dla każdego i-tego projektu P i istnieje l wariantów alternatywnych jego realizacji P l,i. Przez wariant alternatywny rozumie się przedsięwzięcie, którego parametry dotyczące czasu, kosztu lub zakresu różnią się od parametrów projektu bazowego. Dla przedstawionego MRPWP można formułować pytania dotyczące wnioskowania w przód lub wstecz. W przypadku wnioskowania w przód rozważany problem sprowadza się do odpowiedzi na pytanie: Czy dla zadanych wartości zmiennych wejściowych istnieje harmonogram spełniający zadane ograniczenia, a jeżeli tak, to jakie są jego parametry? Pytanie to może zostać rozszerzone o kolejne, następującego typu: czy dany harmonogram realizacji może zostać wykonany w horyzoncie H, przy nieprzekroczeniu wartości r 1 środków pieniężnych oraz r 2 roboczogodzin w przyjętej jednostce czasu h? Pozwala to rozważać klasę problemów wielokryterialych.

12 110 Marcin Relich W przypadku, gdy dla wnioskowania w przód nie istnieje harmonogram spełniający zadane ograniczenia, przyjmuje się, że realizacja projektu bazowego jest zagrożona niepowodzeniem. Wówczas można sformułować pytanie dotyczące wnioskowania wstecz: jakie wartości zmiennych wejściowych gwarantują ukończenie przedsięwzięcia przy spełnieniu zadanych ograniczeń? Wyróżnienie zmiennych wejściowych, których wartości zostają zmienione stosownie do przyjętych ograniczeń, dokonywane jest w sposób arbitralny. Koncepcję metody wyznaczania rozwiązań dopuszczalnych dla sformułowanego problemu decyzyjnego w aspekcie szacowania kosztów przedstawia poniższy rozdział. 4. Metoda wariantowania przedsięwzięcia Zagadnienie planowania, a następnie sukcesywnego monitorowania realizacji projektu, jest jednym z najistotniejszych elementów zarządzania przedsięwzięciem, decydujących o jego sukcesie bądź porażce [9]. Powstaje wobec tego potrzeba opracowania metody, która umożliwiałaby odpowiednio wczesne wykrycie nieprawidłowości w realizacji przedsięwzięcia, a także określałaby warianty alternatywne pozwalające uzyskać przyjęty cel projektu i uniknąć przewidywanych nieprawidłowości. Procedurę realizacji proponowanej metody przedstawiono na rysunku 6. W przypadku, gdy dla przyjętych ograniczeń nie istnieje harmonogram (np. prognozowany koszt realizacji przedsięwzięcia przewyższa dostępne środki pieniężne), wówczas z wykorzystaniem podejścia wstecz następuje określenie wartości zmiennych decyzyjnych gwarantujących realizację przedsięwzięcia. Określenie zmiennych decyzyjnych, których wartości zostają zmienione, aby nie przekroczyć przyjętych ograniczeń czy ewentualne dodanie nowych ograniczeń jest uzależnione od rozważanego problemu i następuje w sposób arbitralny. Jako przykład ilustrujący ideę proponowanego, implementowanego jako MRPWP, podejścia wybrano funkcjonalność dotyczącą szacowania kosztów. Na rysunku 7 przedstawiono przykładowy wariant alternatywny przedsięwzięcia wyznaczony w przypadku, gdy prognoza wskazuje brak możliwości realizacji wariantu bazowego przy przyjętych ograniczeniach. Prognoza kosztu stanowi dodatkowe ograniczenie i jest dodawana do MRPWP oraz zapisywana w postaci PSO 2n. Na rysunku 7 większy prostopadłościan wyznaczony zostaje poprzez przyjęte ograniczenia: czasowe (H), kosztowe (R 1 ) oraz dotyczące zakresu przedsięwzięcia. Przyjęto, że ocena stopnia realizacji danej czynności, jak również aktualizacja zbioru rozwiązań dopuszczalnych następuje w jednostce czasu h. Zaznaczony linią ciągłą odcinek trajektorii realizacji projektu wskazuje na koszt czynności zakończonych oraz czynności w toku w pierwszej jednostce czasu. Aproksymując funkcję kosztu można określić jego zmianę w kolejnych jednostkach czasu. Na rysunku przedstawiono to w postaci odcinków zaznaczonych linią przerywaną. Dany odcinek mieści się w zbiorze rozwiązań dopuszczalnych, który został zaznaczony na rysunku 7 w postaci mniejszego prostopadłościanu. Na wielkość tego zbioru mają wpływ dziedziny zmiennych oraz przyjęte ograniczenia. Długość odcinka a zależy od ograniczeń kolejnościowych realizacji czynności oraz horyzontu przedsięwzięcia, a w konsekwencji od istniejącego zapasu czasu, tj. różnicy pomiędzy najpóźniejszym terminem rozpoczęcia czynności

13 Wykorzystanie technik programowania z ograniczeniami 111 a możliwym najwcześniejszym terminem jej rozpoczęcia. Długość odcinka b zależy natomiast od ograniczenia związanego z wielkością zasobów finansowych r 1 w przyjętej jednostce czasu h. START Czy istnieje harmonogram dla przyjętych ograniczeń? (podejście w przód) Tak Nie Określenie wartości zmiennych decyzyjnych gwarantujących realizację przedsięwzięcia przy przyjętych ograniczeniach (podejście wstecz) Nie Czy istnieje więcej niż jedno rozwiązanie dopuszczalne? Tak Kryterium oceny wariantu Optymalny wariant alternatywny STOP Rys. 6. Procedura wariantowania przedsięwzięć zagrożonych niepowodzeniem W przypadku, gdy prognoza kosztu przekracza przyjęte ograniczenie finansowe (wariant bazowy), następuje sprawdzenie czy istnieje wariant alternatywny dokończenia przedsięwzięcia, spełniający przyjęte ograniczenia, m.in. czasowe (H) i finansowe (R 1 ). Jeżeli istnieje wieloelementowy zbiór rozwiązań dopuszczalnych, warianty oceniane są zgodnie z przyjętym kryterium, dotyczącym przykładowo minimalizacji czasu czy kosztu realizacji wariantu.

14 112 Marcin Relich Koszt R 1 Wariant bazowy Wariant alternatywny b 1 a H Czas Zakres Rys. 7. Planowane trajektorie wariantu bazowego i alternatywnego przedsięwzięcia Do zalet proponowanego podejścia można zaliczyć uzyskanie zbioru rozwiązań dopuszczalnych w kolejnych jednostkach czasu h, pozwalającego w przypadku przewidywanych trudności z realizacją projektu na wybór wariantu alternatywnego i w ten sposób uniknięcie przekroczenia przyjętych ograniczeń zasobowych czy czasowych. Odnosi się to również do sytuacji braku możliwości realizacji danej czynności i sprawdzenia możliwości dokończenia projektu w zmienionej postaci. Oczywiście kontynuacja przedsięwzięcia bez danej czynności jest uzależniona od charakteru tej czynności, a w konsekwencji od możliwości realizacji kolejnych czynności, co powinno zostać uzupełnione dodatkową informacją. W tym przypadku następuje sprawdzenie czy po usunięciu czynności i związanego z tym ograniczenia kolejnościowego, wyznaczony zostanie niepusty zbiór rozwiązań dopuszczalnych. 5. Przykład Celem przykładu jest ilustracja sposobu definiowania PSO dla problemu wariantowania przedsięwzięć zagrożonych niepowodzeniem. W kolejnych podrozdziałach problem sformułowany został jako problem typu w przód oraz wstecz Pytania rutynowe formułowane dla podejścia w przód Przedsięwzięcie dotyczy wdrożenia oprogramowania obejmującego obszar sprzedaży w przedsiębiorstwie handlowym, dalej zwanym zleceniodawcą. Zleceniodawca posiada już oprogramowanie w tym obszarze, jednakże posiada ono ograniczony zakres funkcjonalności oraz nie zapewnia pełnej integracji z innymi programami dziedzinowymi funkcjonującymi u zleceniodawcy. Do wymaganych dodatkowych funkcjonalności należy np. wystawianie ofert, rejestracja zleceń, ustalanie limitu kredytu kupieckiego,

15 Wykorzystanie technik programowania z ograniczeniami 113 możliwość analizy lojalności klienta (częstotliwości zakupu towarów i płatności), przypisanie kilku warunków płatności w zależności od długości okresu płatności czy prognozowanie sprzedaży w oparciu o zgłoszone zlecenia oraz historię transakcji z danym klientem. Przedsięwzięcie dotyczące wdrożenia nowego oprogramowania składa się z siedmiu czynności: 1. analiza realizowanych procesów biznesowych oraz systemu informacyjnego w przedsiębiorstwie zleceniodawcy, obecnego stanu infrastruktury informatycznej, struktur baz danych; 2. instalacja nowego oprogramowania; 3. wstępna konfiguracja oraz testowanie nowego oprogramowania; 4. dopasowanie standardowych ustawień oprogramowania do wymagań klienta; 5. kastomizacja przeprowadzona zgodnie z nietypowymi wymaganiami klienta; 6. opracowanie sposobu migracji danych, dotyczących np. klientów zleceniodawcy, do bazy danych nowego oprogramowania; 7. tworzenie interfejsów łączących nowe oprogramowanie z innymi obszarami działalności przedsiębiorstwa zleceniodawcy; 8. konfiguracja finalna oprogramowania oraz jego testowanie; 9. szkolenie użytkowników końcowych. Na rysunku 8 przedstawiono sieć czynności rozważanego przedsięwzięcia P = {A 1,..., A 9 }. Czasy trwania (w roboczogodzinach) poszczególnych czynności zostały ustalone na podstawie podobnych projektów realizowanych w przeszłości i opisane w postaci sekwencji: T = (20, 6, 4, 20, 40, 10, 30, 20, 80). Pogrubione strzałki na rysunku 8 symbolizują ścieżkę krytyczną o czasie realizacji równym 190 roboczogodzinom. A 1 A 2 A 3 A 6 A 7 A 8 A 9 A 4 A 5 Rys. 8. Sieć czynności przedsięwzięcia W oparciu o dane zakończonych projektów należących do tej samej klasy co realizowany projekt, przyjęto zależność liniową kosztów od czasu realizacji czynności: dp 1,j = 1 + 0,8 t j, uwzględniającą odpowiednio koszty stałe (np. koszt delegacji) oraz jednostkowy koszt zmienny (np. stawka roboczogodziny). Sekwencja wartości zasobu finansowego dp 1,j pobieranego przez czynność j przyjmuje zatem postać: Dp 1 = (17; 5,8; 4,2; 17; 33; 9; 25; 17; 65). Całkowity planowany koszt inwestycji wynosi 193 jednostek umownych (j.u.). Zasoby są przydzielane w całości do czynności w momencie jej rozpoczęcia. Ograniczenia kolejnościowe wynikające ze struktury przedsięwzięcia przyjmują postać: C 1 : s 2 s 1 + t 1, C 2 : s 3 s 2 + t 2, C 3 : s 4 s 3 + t 3, C 4 : s 5 s 4 + t 4, C 5 : s 6 s 3 + t 3, C 6 : s 7 s 6 + t 6, C 7 : s 8 s 5 + t 5, C 8 : s 8 s 7 + t 7, C 9 : s 9 s 8 + t 8.

16 114 Marcin Relich Przedsiębiorstwo zlecające realizację projektu wyznaczyło zakończenie wdrożenia w horyzoncie czasowym H = {0, 1,..., 200}), przy budżecie 200 j.u. Szukana jest odpowiedź na pytanie: czy istnieje, a jeżeli tak, to jaką ma postać harmonogram realizacji czynności, gwarantujący ukończenie przedsięwzięcia w rozważanym horyzoncie H oraz spełniający ograniczenia zasobowe przedsiębiorstwa? Pytanie należy do klasy pytań w przód, a odpowiedź wiąże się z wyznaczeniem wartości terminów rozpoczęcia czynności S = (s 1, s 2,..., s 9 ), gdzie 0 s j < 200; j = 1, 2,..., 9. Jako środowisko programistyczne umożliwiające implementację modelu referencyjnego wybrano program Oz Mozart [18]. Na rysunku 9 przedstawiono harmonogram projektu dla pierwszego rozwiązania dopuszczalnego S = (0, 20, 26, 30, 50, 30, 40, 90, 110), natomiast na rysunku 10 wykres wykorzystania środków finansowych w poszczególnych jednostkach czasu. Rys. 9. Harmonogram projektu Rys. 10. Wykorzystanie środków pieniężnych Załóżmy, że po zakończeniu realizacji czynności A 1, ponownie oszacowano zależność pomiędzy kosztami a czasem wykonania czynności: dp 1,j = t j. Sekwencja wartości środków finansowych dla kolejnych czynności przyjmuje zatem postać: Dp 1 = (17, 8, 6, 22, 42, 12, 32, 22, 82). Całkowity planowany koszt inwestycji wyniesie wówczas 243 j.u.

17 Wykorzystanie technik programowania z ograniczeniami 115 Pozostałe wartości zmiennych decyzyjnych, ich dziedziny oraz przyjęte ograniczenia (np. kolejnościowe) nie uległy zmianie. Rozważany problem należy do klasy wnioskowania w przód i sprowadza się do odpowiedzi na pytanie: czy istnieje, a jeżeli tak, to jaką ma postać harmonogram realizacji czynności, gwarantujący ukończenie przedsięwzięcia w rozważanym horyzoncie H oraz spełniający ograniczenia zasobowe przedsiębiorstwa? Planowany koszt inwestycji (243 j.u.) przekracza budżet określony przez zleceniodawcę (200 j.u.), wobec tego zbiór rozwiązań dopuszczalnych jest pusty nie istnieje harmonogram, spełniający wszystkie przyjęte ograniczenia. W tej sytuacji proponuje się przeformułować rozważany problem do postaci wnioskowania wstecz, tj. podejścia mającego na celu wyszukanie wartości zmiennych decyzyjnych (np. czasu realizacji czynności) gwarantujących zakończenie przedsięwzięcia w horyzoncie H oraz spełnienie ograniczeń zasobowych przedsiębiorstwa. Podejście to zostało przedstawione w kolejnym podrozdziale Pytania rutynowe formułowane dla podejścia wstecz Przyjęto tę samą sieć czynności, horyzont przedsięwzięcia, dziedziny zmiennych decyzyjnych i ograniczenia, jak w podejściu w przód. Należy zaznaczyć, że poszczególne czynności w różnym stopniu wpływają na powodzenie przedsięwzięcia jako całości, na osiągnięcie zamierzonego celu. Menedżer projektu przypisuje priorytet dla każdej czynności, uwzględniając takie czynniki jak np. czy dana czynność jest położona na ścieżce krytycznej, czy wymaga wykorzystania szczególnie istotnych zasobów (np. jakich specjalistów oddelegować do jej realizacji), ile czasu przeznaczyć na jej wykonanie, czy częściowe wykonanie czynności nie wpłynie na przekroczenie założonych ograniczeń. Przykładowo instalacja oprogramowania (czynność A 2 ) jest czynnością o wysokim priorytecie, o wyraźnie określonych etapach i czasie realizacji. Natomiast na szkolenie użytkowników końcowych (czynność A 9 ) wpływa wiele czynników (np. percepcja użytkowników, ich wykształcenie i wcześniejsze doświadczenia), przez co utrudnione jest jego dokładne oszacowanie. Ze względu na charakter rozważanego zagadnienia dotyczącego wdrożenia oprogramowania, przyjęto, że najniższy priorytet posiada czynność A 5 dopasowanie oprogramowania do nietypowych wymagań klienta (część dopasowań jest możliwa dopiero po całkowitym wdrożeniu projektu) oraz ostatnia czynność A 9 szkolenie użytkowników końcowych. Przyjęto, że zapewnienie podstawowego celu projektu, tj. instalacji i dopasowania nowego oprogramowania do oprogramowania już istniejącego w przedsiębiorstwie zleceniodawcy, jest możliwe przy minimalnej liczbie 35 i 40 roboczogodzin odpowiednio dla czynności A 5 i A 9. Biorąc pod uwagę powyższe założenia, problem sprowadza się do odpowiedzi na pytanie: jaki czas realizacji czynności A 5 i A 9 gwarantuje zakończenie przedsięwzięcia w horyzoncie H oraz spełnienie pozostałych ograniczeń zasobowych przedsiębiorstwa? Odpowiedź na powyższe pytanie jest związana z określeniem czasu realizacji czynności t 5 i t 9, oraz związanego z tym kosztu dp 1,5 i dp 1,9. Rozwiązania dopuszczalne dla t 5 należą do przedziału {35,..., 37}, natomiast dla t 9 należą do przedziału {40,..., 42}.

18 116 Marcin Relich Z ograniczenia kosztowego Σ dp 1,j 200 wynikają następujące dodatkowe ograniczenia: t 5 + t 9 75 oraz t 5 + t Otrzymane warianty można oceniać np. według takich kryteriów jak czas czy koszt. W przypadku minimalizacji czasu (kosztu), optymalny jest wariant dla t 5 = 35 oraz t 9 = 40 roboczogodzin. Wówczas sekwencja czasu trwania poszczególnych czynności ma postać T = (20, 6, 4, 20, 35, 10, 30, 20, 40), natomiast czas całkowity realizacji projektu wynosi 145 roboczogodzin. Sekwencja wartości środków finansowych dla kolejnych czynności przyjmuje postać: Dp 1 = (17, 8, 6, 22, 37, 12, 32, 22, 42), natomiast koszt całkowity wynosi 198 j.u. Harmonogram projektu oraz wykorzystanie środków finansowych dla pierwszego rozwiązania dopuszczalnego (t 5 = 35 i t 9 = 40; S = (0, 20, 26, 30, 50, 30, 40, 85, 105)) przedstawiono odpowiednio na rysunkach 11 i 12. Rys. 11. Harmonogram projektu dla kryterium minimalizacji czasu Rys. 12. Wykorzystanie środków pieniężnych dla kryterium minimalizacji czasu Należy zaznaczyć, że zbiór rozwiązań dopuszczalnych uzależniony jest oprócz zawartości bazy wiedzy również od zadeklarowanej przez użytkownika ziarnistości rozwiązania w językach klasy CP, np. Oz Mozart [18] czy ILOG.

19 Wykorzystanie technik programowania z ograniczeniami Zakończenie We współczesnym, zmiennym otoczeniu przedsiębiorstwa, szybkość odpowiedzi na potrzeby klienta, nacisk na innowacyjność i efektywne zarządzanie kosztami decydują o sukcesie bądź porażce w walce o pozycję na rynku. Wymusza to na współczesnych organizacjach wprowadzenie zmian: coraz częstszych i na coraz większą skalę. Odpowiedzią na te nowe wyzwania staje się stosowanie zasad zarządzania projektami. W przypadku projektów wykonywanych na zlecenie klienta, błędne oszacowanie nakładów czy terminów realizacji projektu, może wiązać się z naliczeniem kar uzgodnionych w umowie czy pokrywanie kosztów ze środków własnych przedsiębiorstwa. Niewłaściwa decyzja może pogorszyć płynność finansową przedsiębiorstwa lub nawet doprowadzić do jego bankructwa. W tej sytuacji niezmiernie istotne wydaje się wsparcie decydenta w procesie podejmowania decyzji. Obszary charakteryzujące zarządzanie przedsięwzięciami oraz funkcjonowanie przedsiębiorstwa można przedstawić w postaci problemu spełniania ograniczeń i wyrazić w postaci zbioru zmiennych decyzyjnych, ich dziedzin oraz ograniczeń. W ten sposób powstaje model referencyjny zarządzania przedsięwzięciem, który można interpretować jako swoistą bazę wiedzy. Baza wiedzy służy jako platforma, tak dla formułowania pytań, jak i wypracowywania odpowiedzi. Stawiane pytania rutynowe można rozpatrywać z wykorzystaniem wnioskowania w przód oraz wnioskowania wstecz. Do budowy modelu, reprezentacji danych i założeń, można wykorzystać języki programowania deskryptywnego. Podstawową zaletą tych języków jest ich deklaratywność, oznaczająca że sposób sformułowania zadania interpretowany jest wprost jako program rozwiązujący to zadanie. Programowanie deklaratywne sprowadza się zatem do modelowania zadania, jako problemu spełniania ograniczeń. Deklarowane ograniczenia są zależne od dziedzin zmiennych, których dotyczą. Do zalet proponowanego podejścia można zaliczyć możliwość charakterystyki przedsiębiorstwa oraz obszaru zarządzania projektem w postaci jednej bazy wiedzy. Ponadto w przedstawionym podejściu istnieje możliwość uzyskania zbioru rozwiązań dopuszczalnych w poszczególnych fazach cyklu życia projektu. Jest to szczególnie atrakcyjne w sytuacji braku możliwości kontynuowania projektu w pierwotnej postaci i może wspomagać decydenta przy określeniu wariantu alternatywnego przedsięwzięcia. Literatura 1. Banaszak Z., Bocewicz G., Bach I., CP-driven production process planning in multiproject environment, Decision Making in Manufacturing and Services, pp. 5-32, Vol. 2, No.1-2, Belassi W., Tukel O.I., A new framework for determining critical success/failure factors in projects, International Journal of Project Management, 1996, vol. 14, ss Bertalanffy L., General system theory - A Critical Review, General Systems, 1962, vol. 7, ss

20 118 Marcin Relich 4. Bocewicz G., Bach-Dąbrowska I., Banaszak Z., Deklaratywne projektowanie systemów komputerowego wspomagania planowania przedsięwzięć. Akademicka Oficyna Wydawnicza EXIT, Warszawa Bubnicki Z., Logic-algebraic method for knowledge-based relation systems, Systems Analysis Modelling and Simulation, 1998, vol. 33, ss Cooke-Davies T.J., Arzymanow A., The maturity of project management in different industries: an investigation into variations between project management models, International Journal of Project Management, 2003, vol. 21, ss Jorgensen M., Sjoberg D.I., The impact of customer expectation on software development effort estimates, International Journal of Project Management, 2004, vol. 22, ss Jorgensen M., Gruschke T., The impact of lessons-learned sessions on effort estimation and uncertainty assessments, IEEE Transactions on Software Engineering, 2009, vol. 35, no. 3, ss Kerzner H., Project Management, A Systems Approach to Planning, Scheduling, and Controlling, 10th ed., John Wiley and Sons, Koenig D., Project Rescuing. PM Network 1, 2006, ss Meredith J.R., Mantel S.J., Project Management a managerial approach, 3rd ed., New York 1995, John Wiley and Sons. 12. Molokken-Ostvold K., Jorgensen M., A comparison of software project overruns, IEEE Transactions on Software Engineering, 2005, vol. 31, no. 9, ss Nitithamyong P., Skibniewski M.J., Success/failure factors and performance measures of web-based construction project management systems: professionals viewpoint, Journal of Construction Engineering and Management, 2006, vol. 132, ss Rakitin S., Creating accurate estimates and realistic schedules. SQP 4, 2002, ss Reichelt K., Lyneis J., The dynamics of project performance: benchmarking the drivers of cost and schedule overrun, European Management Journal, 1999, vol. 17, ss Robertson S., Williams T., Understanding project failure: using cognitive mapping in an insurance project, Project Management Journal, 2006, vol. 37, ss Rossi F., Constraint (logic) programming: A survey on research and applications, K.R. Apt i in. (red.), New Trends in Constraints, Springer-Verlag, Berlin 2000, ss Schutle H., Smolka G., Wurtz J., Finite Domain Constraint Programming in Oz, German Research Center for Artificial Intelligence, Saarbrucken Shore B., Systematic biases and culture in project failures, Project Management Journal, 2008, vol. 39, ss Singh R., Keil M., Kasi V., Identifying and overcoming the challenges of implementing a project management office, European Journal of Information Systems, 2009, vol. 18, ss Yeo K.T., Critical failure factors in information system projects, International Journal of Project Management, 2002, vol. 20, ss Yourdon E., Death march: The complete software developer s guide to surviving mission impossible projects. Englewood Cliffs. Prentice-Hall, New York 1997.

21 Wykorzystanie technik programowania z ograniczeniami 119 The application of constraint programming to IT projects prototyping Summary The paper aims to use the constraint programming techniques for prototyping of the software projects that are in trouble. The paper presents the reference model that is the base to formulate and solve the decision problems mainly concerning the receiving of the alternative projects. The reference model contains the finite sets of decision variables, their domains and constraints, which describe an enterprise and project management. The specification of decision problems in constraints satisfaction problem allows formulating the routine inquiries based on a common, inclusive issue of management, knowledge base. A declarative kind of proposed reference model in a natural way allows implementing its in constraint programming languages.