Projekt strategii rozwoju systemu USOS
Transkrypt
Projekt strategii rozwoju systemu USOS
Projekt strategii systemu USOS rozwoju Autorzy raportu Dorota Nicewicz-Modrzewska z-ca Dyrektora Centrum Zarządzania Infrastrukturą i Projektami Informatycznymi UAM dr Ścibór Sobieski Dyrektor Centrum Informatyki UŁ Projekt strategii rozwoju systemu USOS Spis treści I. Streszczenie ..................................................................................................................................... 4 II. Analiza strategiczna ......................................................................................................................... 5 1. Wprowadzenie ............................................................................................................................ 5 2. Otoczenie konkurencyjne – rynek światowy ............................................................................... 6 Zmiany na światowym rynku IT ....................................................................................................... 6 Proces boloński................................................................................................................................ 7 Rynek oprogramowania Open Source............................................................................................. 7 Model biznesowy oparty o Open Source ...................................................................................... 11 Europejski rynek oprogramowania dla uczelni ............................................................................. 12 Fundacja Kuali................................................................................................................................ 12 3. Otoczenie konkurencyjne – rynek krajowy ............................................................................... 15 Podaż produktów konkurencyjnych .............................................................................................. 15 Pozycja systemu USOS na polskim rynku ...................................................................................... 16 Rynek pracy programistów............................................................................................................ 18 4. Otoczenie technologiczne ......................................................................................................... 21 Wstęp ............................................................................................................................................ 21 Bazy danych ................................................................................................................................... 24 Technologie i rozwiązania na uczelniach wyższych ....................................................................... 27 Wymagania co do integracji systemu............................................................................................ 27 Architektura aplikacji w kontekście kosztów ................................................................................ 29 5. Otoczenie socjologiczno-psychologiczne .................................................................................. 31 Rola zaufania w budowaniu środowiska Open Source ................................................................. 31 Nowy paradygmat socjologiczny o motywacji .............................................................................. 31 Misja uczelni wyższych a Open Source.......................................................................................... 32 Zamachowiec Oracle ..................................................................................................................... 33 6. Analiza aktualnego stanu projektu USOS .................................................................................. 34 MUCI .............................................................................................................................................. 34 USOS .............................................................................................................................................. 35 Funkcjonalność .............................................................................................................................. 35 Zarządzanie projektem .................................................................................................................. 36 Technologia ................................................................................................................................... 37 Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 2/58 Projekt strategii rozwoju systemu USOS 7. Analiza SWOT ............................................................................................................................ 37 III. Opcje strategiczne ......................................................................................................................... 40 Wariant I „USOS 2” ............................................................................................................................ 40 Analiza SWOT ................................................................................................................................ 40 Wariant II Projekt „NEW USOS” ........................................................................................................ 42 Analiza SWOT ................................................................................................................................ 43 Wariant III Projekt „NINA”................................................................................................................. 44 Analiza SWOT ................................................................................................................................ 45 Wariant IV Projekt „KUALI PL”........................................................................................................... 46 Analiza SWOT ................................................................................................................................ 46 IV. Rekomendacje ............................................................................................................................... 48 V. O autorach ..................................................................................................................................... 49 VI. Dodatki .......................................................................................................................................... 53 Dodatek 1. Lista członków Fundacji Kuali .................................................................................... 53 Dodatek 2. The Open Source Definition ...................................................................................... 53 Spis rysunków ........................................................................................................................................ 54 Spis tabel ............................................................................................................................................... 55 Bibliografia............................................................................................................................................. 56 Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 3/58 Projekt strategii rozwoju systemu USOS I. Streszczenie System USOS rozwijany jest przez zespół programistów Uniwersytetu Warszawskiego pod kierownictwem pani Janiny Mincer-Daszkiewicz już od blisko 10-ciu lat. Praktyka rozwoju systemów informatycznych mówi, że systemy o tak długim czasie projektowania zwykle wymagają gruntownych zmian architektonicznych, tak np. podaje w swojej publikacji Mityczny Osobomiesiąc. Eseje o inżynierii oprogramowania F. Brooks, pada wręcz stwierdzenie, że często należy przewidzieć porzucenie pierwszej wersji systemu. Dzieje się tak z kilku zasadniczych powodów: 1. zakres funkcjonalności systemów zwykle bardzo różni się od pierwotnych założeń, a co za tym idzie pierwotnie przyjęte rozwiązania architektoniczne utrudniają dalszy rozwój systemu, 2. system, który tworzony jest przez wiele lat zwykle nie posiada odpowiedniej spójności wewnętrznej (tworzony jest przez zmieniająca się grupę osób), przez co jego utrzymanie oraz dalszy rozwój staje się utrudniony, 3. niezwykle szybkie tempo rozwoju technologii informatycznych pozwala na zastosowanie bardziej efektywnych rozwiązań. Wybrane dla budowy systemu USOS technologie Oracle Forms i Oracle Reports, Oracle przestały być rozwijane przez producenta, co z każdym rokiem zwiększa ryzyko utraty kompatybilności ze środowiskiem systemowym stacji roboczych i serwerów. Zdarzenie to powinno być, naszym zdaniem, bodźcem do zaprojektowania nowoczesnej architektury systemu, która pozwoli na rozwój systemu w perspektywie wielu lat. Biorąc pod uwagę uwarunkowania uczelni wyższych, szczególnie publicznych, uważamy, że mówiąc o perspektywie wdrażania i użytkowania systemu informatycznego należy operować okresem 15-20 lat. Chcemy jednocześnie zaznaczyć, że dokonując niniejszej analizy nie kwestionujemy słuszności wyboru pierwotnej technologii użytej do budowy USOS, która była dokonywana w zupełnie odmiennych uwarunkowaniach. Nie kwestionujemy też modelu w jakim powstawał oraz powstaje USOS, choć i tu można wprowadzić wiele ulepszeń – co wskazujemy w wielu miejscach niniejszego opracowania. Niniejsze opracowanie ma na celu przedstawienie wariantów nowej architektury systemu, która naszym zdaniem, pozwoli mu na utrzymanie obecnej oraz rozwój pozycji systemu USOS na rynku uczelni polskich co stanowi główny i jedyny priorytet niniejszego opracowania. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 4/58 Projekt strategii rozwoju systemu USOS II. Analiza strategiczna 1. Wprowadzenie Współczesny świat podlega nieustającym zmianom, jako przyczyny tychże można wymienić wiele aspektów współczesnego życia, takie jak: pośpiech, ogromny postęp technologiczny, rozwój nauk socjologicznych i politycznych, globalizację i wiele innych. Przeprowadzając analizę strategiczną należy dokonać bardzo wnikliwej analizy otoczenia, w którym się znajduje dana organizacji, i to zarówno otoczenia technologicznego jak i organizacyjnego. W przypadku przedsięwzięć takich jak projekty dużych systemów informatycznych zaniedbanie dokładnej analizy otoczenia może prowadzić do nieprzewidzianych skutków, objawiających się tym, że system informatyczny jest, działa poprawnie, ale z niewiadomych przyczyn użytkownicy nie chcą go używać, te „niewiadomie przyczyny” były często przyczyną klęsk bardzo dobrych rozwiązań. Można mnożyć przykłady wielu rozwiązań, które choć dobre miały przejściowe kłopoty albo musiały zostać porzucone. Przykładowo, systemy firmy Apple już w 1985 roku miały system „okienkowy”, dlaczego zatem to nie one obecnie dominują na biurkach użytkowników? Skoro istniały dobre i sprawdzone systemu Unixowe, to czemu obecnie zostały one wyparte przez Linuksa? Dlaczego firma Xerox, która jako pierwsza posiadała bardzo dobry system graficzny użytkownika, nie wdrożyła go w rozwiązaniach powszechnych? Dlatego też, w swoich publikacjach wielu autorów (np. Pressman, Sommerville) związanych z inżynierią oprogramowania wskazuje, że w trakcie pozyskiwania wymagań od klienta celem budowy nowego rozwiązania informatycznego należy uwzględnić również takie rzeczy jak (wymieniamy tylko najważniejsze w kontekście dalszych rozważań): 1. oszacować biznesowe i techniczne możliwości dla tworzonego systemu, 2. należy określić środowisko techniczne, tj. architekturą, system operacyjny, wymagania sieciowe i teleinformatyczne, w którym ma docelowo pracować system, Ponieważ według wiedzy autorów tego opracowania, dla systemu USOS nigdy nie przeprowadzono takiej analizy (powstawał on metodą iteracyjną), to według autorów jest to właściwy moment na to by przyjrzeć się niejako „od nowa” temu systemowi i wyciągnąć wnioski na przyszłość. Niniejszy dokument nie zawiera dokładnej analizy porażek poszczególnych przedsięwzięć informatycznych, których przykłady podano powyżej, jednak zawiera te informacje o obecnym „środowisku” czy też „otoczeniu” uczelni wyższych, które zdaniem autorów są istotne z punktu widzenia dalszej analizy i wyboru rozwiązań, które będą wspierały rozwój systemu USOS. Według autorów otrzymujemy niepowtarzalną okazję na to by zaprojektować „wersję drugą” USOS, która może zdominować rynek, składa się na to ogromne doświadczenie osób tworzących ten system, oraz odpowiedni moment w czasie. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 5/58 Projekt strategii rozwoju systemu USOS 2. Otoczenie konkurencyjne – rynek światowy Zmiany na światowym rynku IT Pomimo, że system USOS nie był pisany z myślą o jego wykorzystaniu przez inne uczelnie niż polskie, na jego pozycję na polskim rynku będzie miał wpływ rozwój systemów o zasięgu światowym. Zauważmy, że prawdopodobnie to właśnie globalizacja w dużym stopniu dotyka rynku IT, który podlega zmianom będącym skutkiem międzynarodowej współpracy społeczności internetowej. Ekonomia skali wpływa w znaczący sposób na koszty wytwarzania systemów informatycznych. Małe systemy do wspierania procesów zarządzania przedsiębiorstwami konkurują obecnie na rynku z dużymi systemami ERP, których ceny bądź spadły, bądź też zostały dostosowane do średnich przedsiębiorstw. I to właśnie systemy ERP swoją elastycznością konstrukcji przezwyciężyły bariery, które teoretycznie wynikały ze specyfiki systemów finansowo-księgowych w poszczególnych krajach. W naszej opinii, na rynku systemów do zarządzania uczelniami wyższymi, pozycję dominującą zdobędą w najbliższych latach systemy dystrybuowane na zasadach Open Source (lub podobnych), których konstrukcja pozwoli np. na lokalizacje językowe oraz swobodne dostosowanie do uwarunkowań prawnych panujących w danym kraju. Przykładem ogromnego znaczenia dystrybucji w zdobywaniu pozycji na rynku, szczególnie na rynku IT, jest firma Google. Jednym z kluczowych czynników, jakie zadecydowały o jej sukcesie, była bezpłatna dystrybucja ich wyszukiwarki. Zanim zaczęło rozpowszechniać się Google Search, na rynku istniało kilka dużych serwisów wyszukiwawczych, które pozwalały włączać swoją aplikację do stron WWW tylko za opłatą. Google była pierwszą firmą, która pozwoliła wykorzystywać swoją wyszukiwarkę całkowicie bezpłatnie. To spowodowało, że w ciągu kilku miesięcy nowa wyszukiwarka wyparła z rynku płatne serwisy, a jej nazwa stała się błyskawicznie rozpoznawalna na świecie. Czy oznacza to, że firma Google nie czerpie zysków ze swojej działalności? Oczywiście nie, zmodyfikowała jedynie ówczesny model biznesowy i dzięki temu rozwinęła się w szybszym tempie. Pokory dla ograniczania się w planowaniu przyszłości dowolnego systemu informatycznego wyłącznie do rynku polskiego, w tym systemu USOS, a także w forowaniu opinii o niezagrożonej jego pozycji, powinny uczyć niektóre spektakularne zdarzenia z ostatnich kilkunastu lat m.in.: zniknięcie z rynku potentatów takich jak, Digital Equipment Corporation czy Compaq oraz zaprzestanie produkcji większości serwerów RISC. Główną przyczyną był wysoki koszt ich produkcji i rozwoju, który nie znajdował poparcia w odpowiedniej dystrybucji systemów – liczbie klientów. Wygrały rozwiązania tańsze o dużo sprawniejszej dystrybucji. Podkreślamy tańsze, a nie koniecznie lepsze. Podobny przykład można podać w zakresie komercyjnych systemów Unix, które utraciły na znaczeniu w momencie pojawienia się systemu Linux. W efekcie, dzisiaj bardzo niewielkie znaczenie na rynku mają komercyjne systemy unixowe. Wniosek Autorów. W świetle tak znaczących przemian na rynku IT, wiara, że system USOS przetrwa tylko dlatego, że ma obecnie wiodącą pozycję lub, że polskie uczelnie mają jakąś szczególną specyfikę, której nie sprosta żaden inny system jest, w naszej opinii, wiarą naiwną. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 6/58 Projekt strategii rozwoju systemu USOS Proces boloński W 1999 roku europejscy ministrowie edukacji podpisali w Bolonii deklarację koordynacji swoich wewnętrznych działań w celu osiągnięcia w pierwszej dekadzie nowego tysiąclecia celów, które określono jako kluczowe dla utworzenia Europejskiego Obszaru Szkolnictwa Wyższego i promocji europejskiego systemu szkolnictwa wyższego na świecie: • • • • Przyjęcie systemu czytelnych i porównywalnych ocen, także poprzez implementację Suplementu do Dyplomu. Przyjęcie systemu opartego o dwa główne etapy edukacji. Dostęp do drugiego etapu powinien wymagać pomyślnego ukończenia pierwszego etapu, trwającego co najmniej 3 lata. Ustanowienie systemu punktacji – podobnie jak w systemie ECTS – dla promocji mobilności studentów. Punkty te będzie można także uzyskać poza kontekstem szkolnictwa wyższego, włączając to kształcenie ustawiczne i być rozpoznawalne przez uczelnie. Promocję mobilności poprzez przezwyciężanie przeszkód w swobodnym przemieszczaniu się, ze szczególnym uwzględnieniem: o studentów – dla dostępu do studiów i możliwości szkolenia oraz usług powiązanych, o nauczycieli, naukowców, personelu administracyjnego, uznawania i rewaloryzacji okresów spędzonych w europejskim kontekście badań, uczenia i szkoleń bez pogarszania ich ustawowych praw. (1) Proces wdrażania zapisów deklaracji bolońskiej koordynuje obecnie Europejska Komisja ds. Edukacji i Szkolnictwa. Co dwa lata odbywają się spotkania krajów uczestniczących w procesie bolońskim (obecnie 46) w celu pomiaru progresu i ustalenia nowych priorytetów. Jednym z najważniejszych celów ustalonych na kolejne dziesięciolecie jest nadal mobilność zmierzając do osiągnięcia w 2020 roku wskaźnika absolwentów z Europejskiego Obszaru Szkolnictwa Wyższego, którzy studiowali zagranicą na co najmniej 20%. (2) Wdrażanie procesu bolońskiego nakłada na systemy informatyczne zarządzające procesem edukacyjnym nowe wymagania. Implementacja suplementu do dyplomu, katalogu punktów ECTS a szczególnie mobilności studentów wymaga kolejnych nakładów na rozszerzanie funkcjonalności w istniejących systemach. Wniosek Autorów. System USOS musi sprostać wymaganiom związanymi z procesem bolońskim, zatem musi m.in. umożliwić łatwą integracje z innymi systemami występującymi na świecie ze szczególnym uwzględnieniem Europy. Rynek oprogramowania Open Source1 W opinii Autorów, na rynku systemów do zarządzania uczelniami wyższymi, pozycję dominującą zdobędą w najbliższych latach systemy dystrybuowane na zasadach Open Source lub zbliżonych, których konstrukcja zapewni odpowiednią elastyczność rozwiązania, łatwe lokalizacje językowe oraz dostosowywanie do uwarunkowań prawnych. Opłacalność utrzymywania lokalnych systemów stanie wówczas pod znakiem zapytania. Taniej jest bowiem finansować rozwój i utrzymanie lokalnych modyfikacji, unikając kosztów utrzymania i rozwoju architektury systemu. 1 Definicję oprogramowania Open Source zawarto w Dodatku 2. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 7/58 Projekt strategii rozwoju systemu USOS Według tej samej zasady system USOS wyparł wiele systemów działających lokalnie na uczelniach. Szybka dystrybucja jaką daje licencja Open Source ułatwi znacząco upowszechnienie się takich systemów. Pojawienie się pierwszego takiego systemu z polską lokalizacją, spowoduje, że większość osób odpowiedzialnych za informatyzację uczelni będzie ostrożnie podejmować decyzję co do inwestycji w system USOS. W podobny sposób rozprzestrzenił się dystrybuowany na licencji GPL system Moodle – pomimo, że istnieją na rynku konkurencyjne, zaawansowane systemy komercyjne, podjęcie decyzji o wdrożeniu Moodle obarczone było znacznie mniejszymi nakładami początkowymi (ryzykiem finansowym). Według informacji dostępnych Autorom, nikt w Polsce nie wykonywał precyzyjnych badań związanym z udziałem platformy Moodle na rynku, ale szacuje się, ż jest to 8090% rynku uczelni (statystyki ogólne: http://moodle.org/stats/). Jak niżej wykazano, dotychczasowe, dość powszechne, poglądy utożsamiające oprogramowanie Open Source z grupką entuzjastów lub wręcz fanatyków, należy bardzo szybko zrewidować. Zmiany na rynku IT spowodowane przez projekty tego typu, ich wpływ na przyspieszenie rozwoju cywilizacji oraz odkrycia socjologiczne związane z badaniem przyczyn sukcesu projektów Open Source powodują, że rynek komercyjny bardzo poważnie podchodzi do modelu biznesowego opartego o Open Source. Analizując obecny zakres stosowania oprogramowania Open Source na uczelniach wyższych oprogramowania należy podkreślić, że programowanie to upowszechnia się coraz szybciej. Poniżej wykres zakresu stosowania Open Source na UAM. Rysunek 1. Zakres stosowania oprogramowania OpenSource na UAM Źródło: opracowanie własne Z każdym rokiem wykorzystujemy coraz więcej systemów Open Source w codziennej pracy służb informatycznych. Wiele z tych rozwiązań, które do nie dawna nie mogły konkurować Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 8/58 Projekt strategii rozwoju systemu USOS z komercyjnymi systemami, obecnie stały się rozwiązaniami na tyle dojrzałymi, że wyparły znacznie droższe rozwiązania (np. system OpenNMS do monitorowania systemów, system OTRS – zapewniający wsparcie dla helpdesku). Od lat, powszechne jest wykorzystywanie środowisk programistycznych udostępnianych na zasadach Open Source takich jak Perl, TCL, Phyton czy Java. Ilość bibliotek dostępnych w ramach projektów Open Source rośnie z roku na rok, a istniejące rozwiązania stają się rozwiązaniami na tyle dojrzałymi, że zaczynają być wykorzystywane przez producentów systemów komercyjnych. Tendencję te potwierdzają wykonane w kwietniu 2009 roku przez IDC badania światowego rynku oprogramowania. Wykazały one, że wydatki na oprogramowanie oprogramowanie związane z systemami typu Linux rosną w znacznie większym stopniu niż rynek i pozostali gracze na rynku. Oznacza to, że oprogramowanie Open Source zdobywa swoją pozycję na rynku w bardzo szybkim tempie zagrażając dotychczasowym potentatom. 40 35 30 (%) 25 20 15 10 5 0 2006 2007 2008 2009 2010 2011 2012 2013 Linux i oprogramowanie z nim związane Unix i oprogramowanie z nim związane Windows i oprogramowanie z nim związane Cały rynek Rysunek 2 Poziom wzrostu światowych przychodów z oprogramowania liczony rok do roku w latach 2006-2013 2006 Źródło: (3) W 1976 roku Bill Gates w zapytał retorycznie: „Kto Kto może pozwolić sobie na wykonywanie profesjonalnej onalnej pracy za nic? Jaki hobbysta poświęci lata na programowanie, odnajdywanie błędów, dokumentowanie swojego produktu i dystrybucję za darmo?” darmo? (4) Ten daleko posunięty sceptycyzm był błędem. Obecnie Microsoft traktuje rynek oprogramowania związanego z Linuxem jako jednego z głównych swoich rywali. W swoim rocznym raporcie (5) wskazuje oprogramowanie Open Source a przede wszystkim inny model biznesowy przez niego wykorzystywany jako jedno z zasadniczych zasadniczych ryzyk, które mogą obniżyć ich przychody. Co więcej, Autorzy: Dorota Nicewicz-Modrzewska, Modrzewska, Ścibór Sobieski 9/58 Projekt strategii rozwoju systemu USOS rozpoczęła współpracę z projektami typu Open Source takimi jak Linux rozwijając ich oprogramowanie na zasadach licencji GPL v2 oraz stworzyła licencję Microsoft Public Licence i zachęca do wytwarzania oprogramowania w oparciu o ten model. Wystarczy spojrzeć na portal projektów realizowanych w oparciu o rozwiązania Microsoft (http://www.codeplex.com/), zawiera on projekty udostępniana na jednej z licencji Open Source. Zatem, czy wolno bagatelizować ten model wytwarzania oprogramowania, jeśli tacy potentaci jak Microsoft zrozumieli, że warto pójść tą drogą? Analitycy firmy Gartner, po wielu latach sceptycznego podejścia do rynku Open Source, w ostatnich latach zmienili swoje poglądy. Opublikowano prognozy, z których wynika, że 80% systemów komercyjnych do roku 2012 będzie zawierać komponenty Open Source. Dostrzegli również, że wiele systemów tej klasy stało się systemami dojrzałymi, stabilnymi i posiadającymi dobre wsparcie. Zdaniem Gartner systemy Open Source pozwalają znacząco zmniejszać całkowity koszt użytkowania systemów. Ignorowanie tego faktu, zdaniem analityków Gartner, może wprowadzić firmy w poważne problemy konkurencyjne. W najbliższych latach spodziewają się, że opracowanie strategii adaptacji systemów Open Source będzie jedną z najważniejszych decyzji strategicznych w firmach. (6) Zarysowująca się tendencja, która pozwoli twórcom oprogramowania na utrzymanie swojej pozycji na rynku polega na adaptacji rozwiązań Open Source w zakresie budowy jądra, tak aby skoncentrować swoje zasoby na innowacyjności, zamiast nad kolejnymi próbami wynalezienia na nowo „koła”, które to próby nie budują przewagi konkurencyjnej systemów. Istotne rezultaty przyniosło wykonane przez firmę Accenture w marcu i kwietniu 2010 roku badania 300 organizacji publicznych i prywatnych z Wielkiej Brytanii i Stanów Zjednoczonych. Zdaniem analityków Accenture, nadchodzi era oprogramowania Open Source, a swoje wnioski opierają o wynik badania, z którego widać, że: • • • 69% organizacji planuje zwiększenie wydatków na systemy typu Open Source. 38% spodziewa się migracji swoich kluczowych systemów do systemów Open Source w ciągu najbliższych 12 miesięcy. 88% organizacji obecnie wykorzystujących Open Source planuje w najbliższym czasie wzrost wydatków na oprogramowanie tego typu. Wykonane badanie pokazało również, że wraz z dojrzewaniem rynku Open Source zmieniły się przyczyny adaptacji takiego oprogramowania w przedsiębiorstwach, i tak: • • • • 76% organizacji określiło, jako najważniejszy czynnik jakość oprogramowania, 71% wskazało niezawodność, 70% sprawniejsze rozwiązywanie błędów i dziur w bezpieczeństwie, 50% wskazało jako najważniejsze obniżenie kosztów. Już w 2000 roku badania niezawodności oprogramowania dla technologii WWW wykazało znaczącą przewagę projektów Open Source: Czas awarii Wrzesień Apache Microsoft Netscape 5.21 10.41 3.85 Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski Inne 8.72 10/58 Projekt strategii rozwoju systemu USOS Październik Listopad Średnia 2.66 1.83 3.23 8.39 14.28 11.03 2.80 12.05 3.39 6.85 3.35 9.21 Tabela 1 Średni czas awarii (w godzinach w miesiącu) dla poszczególnych typów serwerów http Źródło: (6) Analiza czasu naprawy luk w bezpieczeństwie systemów wykonana jeszcze w 1999 roku wykazała co następuje: Producent Liczba dni przerw spowodowanych przez hackerów Red Hat Microsoft Sun 348 982 716 Ilość reakcji Ilość dni/reakcję 31 61 8 11.23 16.10 89.50 Tabela 2 Analiza czasu rozwiązania problemów z bezpieczeństwem systemów Źródło: (6) W serwerach opartych na dystrybucji Linux firmy Red Hat wystąpiło trzykrotnie mniej problemów z bezpieczeństwem niż w serwerach Microsoft. Pomimo, że systemy Sun odnotowały dużo mniejszą ilość przypadków, to bardzo długi czas naprawy spowodował, że systemy Red Hat wykazały najkrótszy sumaryczny czas przerw spowodowanych atakami hackerów. Podobne rezultaty dało badanie wykonane w okresie od czerwca do grudnia 2004 roku przez Symantec Corp. Przeglądarka Mozilla Firefox rozwiązuje swoje problemy z bezpieczeństwem szybciej i odnotowuje mniej poważnych dziur niż komercyjny Internet Explorer. Systemy Open Source wykazują się również dużo większą skalowalnością niż systemy komercyjne. W okresie od marca do listopada 2005 odnotowano, że systemy GNU/Linux były używane przez 78% spośród 500 najszybszych na świecie superkomputerów oraz przez większość najszybszych superkomputerów, włączając najpotężniejszy. Wyniki powyższych analiz wskazują, że adaptacja systemów Open Source staje się coraz bardziej powszechna, a systemy te zaczynają wypierać systemy zamknięte (czasami określane mianem komercyjnych). Ponadto przyjęta w projektach Open Source organizacja oraz architektura wpływa znacząco na poziom bezpieczeństwa i jakość kodu co powinno zachęcać do czerpania z ich doświadczeń i naśladowania ich metod pracy. Wniosek Autorów. Niezmiernie ważne dla rozwoju systemu USOS jest zwrócenie uwagi na model Open Source i poważne potraktowanie tej alternatywy jako dalszej drogi rozwoju systemu. Przy czym, najważniejsze zdaniem Autorów opracowania, jest model dystrybucyjny, „architektura” Open Source oraz otwartość kodu – w tej kolejności. Model biznesowy oparty o Open Source W ostatnich latach zwiększa się na świecie liczba firm, które opierają swój model biznesowy o oprogramowanie typu Open Source. Znaczenie ich działalności na rynku rośnie, co daje się zauważyć w analizach Magic Quadrants publikowanych przez Gartner Inc. Podstawową zasadą tego modelu jest otwarcie kodu oprogramowania, umożliwienie tworzenia własnych modyfikacji przez użytkowników, ale przede wszystkim tworzenie społeczności wokół rozwoju systemu. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 11/58 Projekt strategii rozwoju systemu USOS Wbrew potocznym opiniom Open Source może generować znaczny strumień przychodów. W drugim kwartale 2010 roku całkowite przychody firmy Red Hat wyniosły 219 mln USD i wzrosły o 20% w stosunku roku poprzedniego. Przychody z samych subskrypcji wsparcia technicznego wyniosły 186 mln USD. (7) Model Open Source wykorzystuje następujące strumienie przychodów: wsparcie techniczne, konsulting, sprzedaż pakietów enterprise, sprzedaż modułów komercyjnych, szkolenia, dotacje, reklama. Wniosek Autorów. System USOS, może rozwijać się w modelu Open Source z pozytywnym skutkiem dla wpływów do budżetu projektu. Europejski rynek oprogramowania dla uczelni W wielu krajach europejskich rozwojem oprogramowania do zarządzania tokiem studiów zajmują się gremia powołane na poziomie krajowym, podobnie jak to się dzieje w Polsce. Do takich krajów należą m.in.: Szwecja (Ladok), Niemcy (HIS), Norwegia (USIT), Włochy (CINECA/KION). Formuła organizacyjna tych jednostek jest różna, stosowane są zarówno konstrukcje oparte o agencje rządowe, fundacje i stowarzyszenia uczelni. Większość systemów powstaje w oparciu o licencje zamknięte, jednakże np. HIS rozpoczął udostępniać swoje systemy na licencji typu Open Source. Współpracą z HIS, a przede wszystkim możliwością włączenia do systemu rozwiązania BI (eduStore), zainteresowała się Fundacja Kuali. W dniach 22-23 września 2010 z inicjatywy HIS odbyło się seminarium na temat modelu Open Source w tworzeniu rozwiązań dla uczelni oraz możliwości współpracy w tym zakresie. Dyskusja przeprowadzona w tych dniach pokazała, że wiedza o korzyściach płynących z modelu Open Source jest jeszcze bardzo niewielka. Jednakże organizacje uczestniczące w spotkaniu poszukując możliwych pól współpracy zadeklarowały wspólnie gotowość do kontynuowania rozmów w tym kierunku. Fundacja Kuali W 2004 roku z inicjatywy Uniwersytetu Indiana rozpoczęły się w Stanach Zjednoczonych działania mające na celu rozpoczęcie współpracy uczelni wyższych w celu stworzenia systemu finansowego dedykowanego do użytku przez uczelnie wyższe. Po ponad roku prac przygotowawczych uzyskano dofinansowanie z fundacji Mellona na prace programistyczne. Wśród inicjatorów współpracy było 8 amerykańskich uczelni wyższych i organizacji. W 2006 roku wraz z pojawieniem się nowych pomysłów na rozwój oprogramowania powołano do życia Fundację Kuali, której celem było zarządzanie współpracą pomiędzy partnerami oraz projektami. Misją Fundacji Kuali jest stworzenie systemów informatycznych typu Open Source przez uczelnie wyższe z przeznaczeniem dla uczelni wyższych. W 2006 roku, w ramach fundacji powołano do życia drugi projekt – Kuali COEUS – mający na celu stworzenie systemu do zarządzania badaniami naukowymi, który bazował na doświadczeniach systemu o tej samej nazwie stworzonym przez MIT. W roku 2007 rozpoczął prace projekt Kuali STUDENT, którego założeniem było stworzenie systemu do zarządzania tokiem studiów. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 12/58 Projekt strategii rozwoju systemu USOS Rysunek 3. Struktura organizacyjna Kuali Źródło: (8) Ze względu na istnienie kilku projektów w ramach Kuali powstała potrzeba oddzielenia wspólnych komponentów wszystkich projektów i uformowania z nich samodzielnego projektu pod nazwą Kuali RICE odpowiedzialnego za podstawową architekturę systemów tworzonych w ramach Kuali. Do innych projektów powołanych w ramach Kuali należą: • • Kuali OLE – system do zarządzania i współpracy pomiędzy bibliotekami, Kuali READY – narzędzie do planowania ciągłości funkcjonowania uczelni wyższych (business continuity planning tool). Rozpoczęto także przygotowania do stworzenia systemu kadrowo-płacowego oraz systemu do zarządzania wiedzą. Oprogramowanie stworzone przez Fundację Kuali, zgodnie z założeniami, jest dystrybuowane bezpłatnie na zasadach licencji Educational Community License, która należy do grupy licencji typu Open Source i jest zgodna z licencją GPL w wersji 3. Fundacja jest finansowania ze składek jej członków oraz ze zdobytych grantów (np. Fundacja Mellona). Wysokość rocznej składki członka Fundacji jest uzależniona od wielkości jego budżetu: Wielkość rocznego budżetu (mln USD) Powyżej 750 500 - 750 250 - 500 Mniej niż 250 Fundacje Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski Wysokość składki rocznej (USD) 24,500 14,500 9,500 4,500 14,500 13/58 Projekt strategii rozwoju systemu USOS Korporacje 20,000 Tabela 3 Wysokość rocznej składki w Fundacji Kuali Źródło: (8) W ciągu 6 lat istnienia Fundacja Kuali przeżyła dynamiczny wzrost liczby jej członów. W samych tylko ostatnich 3 miesiącach ilość członków Fundacji wzrosła z około 40 do blisko 50. Obecną listę członków Fundacji Kuali zawarto w Dodatku 1. Należy podkreślić, że jednym z członków biorących udział w procesie tworzenia systemów w ramach Fundacji jest Massachusetts Institute of Technology. W 2010 roku do współpracy w ramach Fundacji Kuali jako partner fundacji zaangażowany w rozwój systemu Kuali STUDENT dołączyła pierwsza europejska uczelnia wyższa – University of Cambridge. Rozwój systemów tworzonych przez Kuali jest przedmiotem obserwacji licznych uczelni europejskich. W ramach spotkania, które odbyło się w dniach 22-23.09 2010 pt. „Open source activities in the area of university management in Europe” jedna z uczelni fińskich poinformowała, że są w trakcie wykonywania testów technologii Kuali Rice. W grudniu 2010 roku, wkrótce po opublikowaniu pierwszego wydania systemu Kuali STUDENT mają zamiar rozpocząć testy tego oprogramowania. Uniwersytet im. Adama Mickiewicza rozpoczął testy oprogramowania Kuali COEUS. Członkostwo w Fundacji Kuali nie warunkuje prawa do wykorzystania lub modyfikacji jej oprogramowania, gdyż jest ono dystrybuowane na zasadach Open Source. Jednakże umożliwia ono wywieranie wpływu na rozwój systemów poprzez prawo głosu podczas wyboru dyrekcji Fundacji, procesie przydzielania zasobów projektom oraz określania priorytetów Fundacji. Członkowie Fundacji są zachęcani do udostępniania swoich zasobów ludzkich dla projektów Fundacji na określony okres czasu. Na podkreślenie zasługuje transparentność procesu zarządzania. Wszystkie spotkania dyrekcji i kierownictwa projektów są dokumentowane i publikowane na stronach internetowych Fundacji. Podsumowując, informacje o działalności Fundacji Kuali należy podkreślić, że staje się ona głównym graczem na rynku systemów do zarządzania uczelni w skali światowej. Rysunek 4. Ilość odwiedzających stronę kuali.org według lokalizacji, od 1 do 4 lutego 2010 Źródło: (8) Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 14/58 Projekt strategii rozwoju systemu USOS Jej dynamiczny rozwój może, w krótkim czasie, spowodować wejście na rynek europejski i zacząć zagrażać systemom krajowym. W rzeczywistości zaangażowanie University of Cambridge w rozwój projektu Kuali STUDENT stanowi już o rozpoczęciu ekspansji Kuali na rynku europejskim. Wniosek Autorów. Fundacja Kuali jest organizacja, którą należy traktować jako bardzo poważnego konkurenta systemu USOS ze względu na jej tempo rozwoju oraz ze względu na fakt, że pierwsze europejskie uczelnie zaczęły testować ich systemu lub nawet rozpoczęły z nimi oficjalną współpracę. 3. Otoczenie konkurencyjne – rynek krajowy Podaż produktów konkurencyjnych Do niedawna rynek uczelni wyższych w Polsce nie cieszył się wielkim zainteresowaniem firm komercyjnych, zwłaszcza dotyczyło to tzw. uczelni państwowych (publicznych). Wynikało to z wielu przyczyn, do których jako główne można zaliczyć: 1. Skala wdrożenia – uczelnie, które bardzo potrzebują dobrych i rozbudowanych systemów informatycznych wspierających ich procesy, są zwykle ogromne. Zatem złożoność ich procesów biznesowych również jest duża. W efekcie działające na rynku małe i średnie firmy komercyjne nie były często w stanie podołać wdrożeniom, a duże firmy nie były zainteresowane tym rynkiem ze względu na jego specyfikę. 2. Specyfika uczelni publicznych – uczelnie publiczne podlegają dość specyficznym uwarunkowaniom prawnym, które są odmienne niż w typowym „biznesie”, co więcej, jedna uczelnia może mieć w pewnym zakresie odmienne akty prawne od innej (np. uchwały senatu uczelni). Stąd też, nie można wprost, wdrażać na nich rozwiązań przenoszonych ze świata komercji np. systemów ERP. Idąc dalej, wdrożenie na każdej z uczelni jest inne (ma indywidualny charakter), stąd każde obarczone jest dużym ryzykiem. Z kolei w porównaniu do segmentu zwykłego „biznesu” uczelni nie jest aż tak dużo. Te czynniki powodowały, że przez wiele lat duże firmy informatyczne nie były zainteresowane wejściem w ten rynek. 3. Nietypowe procesy biznesowe – istnieje wiele obszarów procesów biznesowych uczelni wyższych, które nie występują w ogóle, lub jedynie w szczątkowej postaci, w firmach komercyjnych. Dla przykładu wystarczy wymienić: rekrutację, obsługę studentów, biuro nauki. Stąd też, firma, która chciałaby wejść na ten rynek musi liczyć się z dużymi nakładami w początkowej fazie, które zwrócą się dopiero na przestrzenie wielu lat. Ostatecznie, jak pisaliśmy, przez wiele lat rynek publicznych uczelni wyższych nie cieszył się dużym zainteresowaniem. Zmieniło się to ostatnimi laty i można obecnie wymienić wiele firm, które oferują rozwiązania dla uczelni wyższych (poniższy spis ma charakter jedynie poglądowy i nie dokonujemy w nim porównania pokrycia konkretnych obszarów, to znaczy: gdy piszemy „kadry” nie oznacza, że funkcjonalność pokrywa całość potrzeb uczelni). Firmy wymieniamy w porządku alfabetycznym: 1. ComArch (http://www.comarch.pl) – firma założona w 1993 roku, działa w wielu obszarach rynku, w przypadku uczelni wyższych są to: kadry, płace, finanse. Nie są nam znane wdrożenia w dużych i liczących się uczelniach publicznych. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 15/58 Projekt strategii rozwoju systemu USOS 2. CSF Polska (http://www.csf.pl) – firma istnieje od 1996 roku i posiada oprogramowanie w obszarach: obieg dokumentów, projektu, rozliczenia projektów. Firma reklamuje swoją platformę one4all jako rozwiązanie dla wszelkich obszarów uczelni, jednak głównie sprowadza się ona do obszarów wymienionych powyżej. Nie są nam znane wdrożenia w dużych i liczących się uczelniach publicznych. 3. Kalasoft (http://www.kalasoft.com.pl) – firma istnieje od lutego 1989 roku i posiada oprogramowanie w obszarach: dziekanat, kadry, płace, finanse. Przy czym oprogramowanie to można scharakteryzować jako przeznaczone dla małych i średnich uczelni. W niektórych obszarach można zauważyć obecność tej firmy na uczelniach dużych i liczących się, np. UW. 4. Microsoft (http://www.microsoft.com) – wiodąca firma informatyczna na świecie, która do tej pory funkcjonowała w innym obszarze. Jednak od kilku lat próbuje wejść na rynek ze swoim produktem klasy ERP, jakim jest Dynamix AX. W zakresie wdrożeń na dużych i znaczących uczelniach można wymienić UAM. 5. Partners in Progress (http://www.partnersinprogress.pl/) – firma istnieje od 1995 roku i posiada oprogramowanie w obszarach: dziekanat, rekrutacja i inne drobne. Nie są nam znane wdrożenia w dużych i liczących się uczelniach publicznych. 6. S.A.P. (http://www.sap.com) – największa na świecie firma z zakresu rozwiązań ERP, która nie posiada jeszcze wyspecjalizowanych rozwiązań dla uczelni wyższych w Polsce, ale poprzez wdrożenie w 4 uczelniach powoli nadrabia zaległości. Rozpoczęte wdrożenia na: UJ, UMCS, UŚ, PW. 7. Simple (http://www.simple.com.pl) – firma działa od roku 1988 i posiada oprogramowanie w obszarach: niektóre obszary dziekanatu, kadry, płace, finanse. Nie są nam znane wdrożenia w dużych i liczących się uczelniach publicznych. Należy jednak zaznaczyć, że nawet obecnie żadna z firm nie dostarcza rozwiązania kompleksowego (dla wszystkich obszarów działalności) przeznaczonego dla publicznej uczelni wyższej w Polsce. Jeśli natomiast zawęzimy naszą analizę do obszaru dziekanatu (by odnieść się do USOS), to okaże się, że jest jeszcze gorzej i krąg dostawców się zawęża. Tak naprawdę, USOS w chwili obecnie jest bezkonkurencyjny w zakresie obsługiwanej funkcjonalności. Jednak nie należy traktować tego stwierdzenia jako dobrego omenu, gwarantującego ten stan na długie lata. Jak wiadomo rynek nie znosi stagnacji, a firmy komercyjne przebijają USOS modelem biznesowym (np. w zakresie wdrożenia i wsparcia). Widać to wyraźnie na przykładzie uczelni, które wciąż nie decydują się na wdrożenie systemu USOS brakuje głównie ze względu na brak komercyjnego wsparcia. Wniosek Autorów. „Świat komercji” zaczął traktować rynek uczelni wyższych, jako ważną niszę do zagospodarowania. Stąd też, naszym zdaniem, komercyjne rozwiązania należy postrzegać jako konkurencyjne dla systemu USOS,, co więcej, posiadające przewagę konkurencyjną w zakresie dostarczanego wsparcia technicznego i powdrożeniowego. Pozycja systemu USOS na polskim rynku System USOS uzyskał obecnie dominującą pozycję na rynku uczelni wyższych w Polsce z każdym rokiem zyskując nowe zainteresowane wdrożeniem uczelnie. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 16/58 Projekt strategii rozwoju systemu USOS 35 30 30 25 23 25 20 20 14 15 9 10 16 15 19 21 19 16 12 7 5 0 2000-2003 2004 2005 2006 Liczba uczelni przystępujących do projektu 2007 2008 2009 Liczba uczelni rozpoczynających wdrożenie Rysunek 5. Postęp w rozwoju projektu Źródło: (9) Szacuje się, że USOS działa w 20% publicznych uczelni wyższych i obsługuje 40% 40% studentów uczelni tego rodzaju. Uniwersytety 14 Politechniki, Wyższe szkoły… 5 19 Wyższe szkoły zawodowe i inne 3 Wyższe szkoły pedagogiczne 4 242 2 16 Wyższe szkoły ekonomiczne 2 81 Akademie wychowania fizycznego 2 4 Wyższe szkoły rolnicze 1 7 Szkoły resortowe (MON i MSWiA) 1 6 Akedemie medyczne 0 9 Wyższe szkoły artystyczne 0 21 Wyższe szkoły morskie 0 2 Wyższe szkoły teologiczne 0 15 0% 20% Uczelnie wdrażające USOS 40% 60% Pozostałe uczelnie 80% 100% Rysunek 6.. Uczelnie wdrażające USOS według rodzaju Źródło: (9) Duża penetracja rynku wpływa na wysoki poziom zaufania uczelni co do trwałości projektu. Autorzy: Dorota Nicewicz-Modrzewska, Modrzewska, Ścibór Sobieski 17/58 Projekt strategii rozwoju systemu USOS Rynek pracy programistów Jednym z najważniejszych czynników, które wpływają na powodzenie projektów informatycznych jest dostęp do kadry informatycznej wyspecjalizowanej w technologiach stosowanych w systemach. Zmiany w popycie na określone kompetencje pracowników są pierwszym wskaźnikiem rozwijających się na rynku trendów w zakresie adaptacji technologii. Rosnący przez lata popyt tworzy lukę na rynku pracy co wpływa na kierunki edukacji specjalistów. Odwrotnie – stagnacja zapotrzebowania zmniejsza zainteresowanie rozwojem osobistym w tym kierunku. Poniżej przedstawiono wyniki długoterminowych analiz popytu na poszczególne kompetencje informatyczne, mogące mieć znaczenie w doborze technologii dla systemu USOS. Wykresy przedstawiają relatywny wzrost (rok do roku) ilości ofert pracy na rynku światowym, gromadzonych przez agencję Indeed. Rysunek 7 Relatywny trend rozwoju rynku specjalistów związanych z bazami danych Źródło: indeed.com Najbardziej widoczny jest trend wzrostu zapotrzebowania na specjalistów związanych z bazami MySQL oraz PostgreSQL co oznacza, że rynek w coraz większym stopniu przyjmuje te rozwiązania. Co prawda może to się zmienić, ze względu na przejęcie MySQL przez firmę Oracle, ale z pewnością PostgreSQL utrzyma swoją pozycję. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 18/58 Projekt strategii rozwoju systemu USOS Rysunek 8 Liczba ofert pracy dla specjalistów związanych z bazami danych Źródło: (10) W liczbach absolutnych na rynku dominują oferty związane Oracle, co wiąże się z pozycją rynkową wypracowaną przed 2005 rokiem. Rysunek 9 Relatywny trend rozwoju rynku specjalistów związanych z językami programowania Źródło: (10) Powyższy wykres oddaje dynamikę wzrostu adaptacji technologii PHP w porównaniu do innych języków programowania. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 19/58 Projekt strategii rozwoju systemu USOS Rysunek 10 Liczba ofert pracy dla specjalistów związanych z językami programowania Źródło: (10) W liczbach bezwzględnych dominującą pozycję na rynku wykazują oferty związane z programowaniem w języku Java. Tu znów może to w najbliższym czasie się zmienić, ze względu na przejęcia SUN przez Oracle. Na dzień 29 września 2010 roku jeden z największych serwisów ogłoszeniowych w Polsce zawierał następującą ilość ofert pracy: Stanowisko Programista Oracle Programista baz danych Programista Java Programista PHP Ilość ofert pracy 4 5 77 25 Tabela 4 Liczba ofert pracy w serwisie pracuj.pl w dniu 29.09.2010 Źródło: Opracowanie własne Wykonane w tym samym dniu wyszukiwanie w nazwach stanowisk ciągów znaków takich jak: Oracle, Java, PHP, PostgresSQL, MySQL w portalach społecznościowych związanych z karierą zawodową dało następujące wyniki: ciąg znaków linkedin.com linkedin.com Polska 689 877 491 454 269 098 26 184 205 080 5 939 6 327 4 488 1 457 3 159 oracle java php postgresql mysql goldenline.pl 6 694 6 307 7 820 1 849 4 843 Tabela 5 Liczba osób zarejestrowanych w portalach społecznościowych, które zawarły w opisie swojego stanowiska lub kompetencji poszukiwany ciąg znaków w dniu 29.09.2010 Źródło: Opracowanie własne Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 20/58 Projekt strategii rozwoju systemu USOS Liczby te potwierdzają, że na rynku pracy zachodzą dynamiczne zmiany w dostępie do kompetencji programistycznych. Mała ilość ofert pracy związanych z bazami Oracle przy dużej podaży osób posiadających te kompetencje, może w bardzo istotny sposób zniechęcać młodych ludzi do podejmowania edukacji w tym zakresie, zwłaszcza że jest bardzo kosztowna. Odwrotnie, duża podaż ofert pracy związanych z językiem Java i PHP wspiera wzrost ilości osób planujących zdobycie tych kompetencji. Proporcje ilości osób zarejestrowanych w portalach pokazują, że tendencje te zarysowują się na polskim rynku dużo szybciej niż na świecie. Wniosek Autorów. Dalsze opieranie się na bazie Oracle może w dłuższej perspektywie spowalniać rozwój systemu ze względu na spodziewany rosnący koszt specjalistów Oracle i przenoszenie kompetencji na rynku w stronę projektów Open Source. Stąd tez należy poważnie zastanowić się nad rozważeniem użycia baz innych firm, np. Open Source lub bazy o dużo korzystniejszym stosunku ceny do oferowanych możliwości jaką jest baza MS SQL Server 2008. 4. Otoczenie technologiczne Wstęp Informatyka jest bardzo młodą dziedziną nauki, a inżynieria oprogramowania posiada jeszcze krótszą historię, bo zaczynająca się tzw. kryzysem inżynierii oprogramowania plasowanym na początek lat 60-tych ubiegłego wieku. Z pozoru wydaje się, że 50 lat historii to wystarczający czas by dana dziedzina nauki okrzepła, jednak pamiętajmy, że w informatyce w tym czasie nastąpił ogromny postęp technologiczny, przez co można było tworzyć bardziej zaawansowane rozwiązania w zakresie oprogramowania. Postęp ten widać na przykładzie trzech obszarów: systemy operacyjne, sieci i komunikacja oraz języki programowania. To co kiedyś wydawało się nie osiągalne, obecnie jest możliwe i, co więcej, zalecane. Stąd też musiały się przez te lata zmieniać tendencje w zakresie wytwarzania oprogramowania. Dla przykładu, kiedyś dążono do tworzenia aplikacji o architekturze klient-serwer z tzw. cienkim klientem (szczegółowe wyjaśnienie poniżej), gdyż sieci komputerowe wykazywały się niską wydajnością. Obecnie dla odmiany odchodzi się od tego modelu na rzecz dążenia do chmur, gdzie cala aplikacja działa „gdzieś w obłokach”, a klient widzi jedynie okienko aplikacji w przeglądarce. Poniżej wymieniono typowe strategie architektoniczne występujące w tworzeniu złożonych systemów informatycznych (część to opracowanie własne, część podajemy za Wikipedią). 1. Architektura jednowarstwowa – aplikacja jest tworzona wraz z obsługa bazy danych i dane zwykle są przechowywane w plikach płaskich. Architektura ta nadaje się jedynie do niewielkich aplikacji o charakterze lokalnym (nie udostępnianych w sieci). Instalacja takiej aplikacji w środowisku sieciowym wraz ze współdzieleniem danych jest możliwa, choć bardzo uciążliwa. 2. Architektura dwuwarstwowa – aplikacja jest oddzielona od bazy danych. Baza danych to zwykle jakiś rodzaj relacyjnej bazy danych do której dostęp odbywa się poprzez sieć. Ten rodzaj czasami określany jest mianem klient-serwer (choć to jest pewne uproszczenie). W zakresie tej klasy zwykle mówimy o dwu podtypach: a. Gruby klient – dane pomiędzy serwerem a klientem przesyłane są po sieci, a ilość tych danych jest duża. Wynika ona z faktu, że zadawane są do Serwera zapytania Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 21/58 Projekt strategii rozwoju systemu USOS dość ogólne, a wyniki są filtrowane dopiero po stronie Klienta. Przykładowo, chcemy uzyskać informacje o pracownikach o nazwisku „Kowalski”, zatem serwer zwraca całą listę pracowników, a aplikacja wyświetla jedynie te, które dotyczą nazwiska „Kowalski”. Ten rodzaj wymaga wydajnych łączy sieciowych, ale zwykle prostego serwera bazy danych. b. Cienki klient – dane pomiędzy serwerem a klientem przesyłane są po sieci, a ilość tych danych jest możliwe mała. Wynika ona z faktu, że zadawane są do Serwera zapytania bardzo szczegółowe, które zawierają od razu interesujące nas wyniki. Przykładowo, chcemy uzyskać informacje o pracownikach o nazwisku „Kowalski”, zatem serwer zwraca całą listę pracowników o tym nazwisku. Ten rodzaj wymaga wydajnych słabszych łączy sieciowych, ale zwykle silniejszego serwera bazy danych. 3. Architektura wielowarstwowa – w tym zakresie mieszczą się bardzo różne modele architektoniczne, wymieńmy dwie przykładowe: a. Warstwa bazy danych, warstwa serwera aplikacji, warstwa widoku – tak może wyglądać aplikacja tworzona np. w PHP, gdzie widok jest realizowany za pomocą przeglądarki internetowej. b. Warstwa bazy danych, warstwa dostępu do danych, warstwa logiki aplikacji, warstwa kontrolera, warstwa widoku – tak może wyglądać aplikacja tworzona np. w technologii J2EE. 4. Architektura oparta na usługach (ang. Service-Oriented Architecture, SOA) – koncepcja tworzenia systemów informatycznych, w której definiowane są usługi, które spełnią pewne wymagania użytkownika. Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych mający na celu lepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi. Mianem usługi określa się tu każdy element oprogramowania, mogący działać niezależnie od innych oraz posiadający zdefiniowany interfejs, za pomocą którego udostępnia realizowane funkcje. 5. REST (ang. REpresentational State Transfer) – wzorzec architektury oprogramowania opierający się na bezstanowej wymianie informacji w środowisku rozproszonym. Jako nośnik informacji wykorzystuje m.in. formaty XML i JSON. W przeciwieństwie do architektur opartych na usługach (SOA), w REST główną jednostką informacji jest zasób, do którego dostęp uzyskuje się poprzez wykorzystanie różnych czasowników – typów wywołań protokołu HTTP (jak GET, POST, PUT, DELETE). Co więcej można mówić o różny modyfikacjach wymienionych powyżej modeli, stąd też bogactwo rozwiązań jest ogromne. Rozważając wybór technologii do tworzenia oprogramowania w architekturze wielowarstwowej należy wziąć po uwagę: • • • • • Języki kompilowane typu: C/C++ i podobne. W oparciu o nie można dość wygodnie tworzyć aplikacje jedno i dwuwarstwowe, ale również i wielowarstwowe. Języki interpretowane typu: PHP i podobne. W oparciu o nie zwykle tworzy się aplikacje dwu lub wielowarstwowe. Rodzina J2SE – przeznaczona do aplikacji jedno i dwuwarstwowych. Rodzina J2EE – przeznaczona do aplikacji wielowarstwowych. Rodzina .NET – w zależności od użytej technologii (np. WPF czy ASP.NET), można w niej tworzyć wszystkie rodzaje aplikacji. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 22/58 Projekt strategii rozwoju systemu USOS W zakresie standardów wymiany informacji w ramach architektury wielowarstwowej spotkać takie pojęcia jak (zwykle podajemy za Wikipedią): • • • możemy Web Service – usługa sieciowa będąca komponentem programowym niezależnym od platformy i implementacji, dostarczającym określoną funkcjonalność. Może być: o zdefiniowana za pomocą języka opisu usług – standaryzowanym językiem, bazującym na XML jest WSDL (ang. Web Services Description Language), o opublikowana i wyszukana w rejestrze usług za pomocą standardowego mechanizmu (np. rejestry UDDI), o wywołana zdalnie przez zdefiniowany interfejs, o częścią innych usług sieciowych lub być ich kompozycją. Na bazie usług sieciowych można konstruować rozproszone systemy i aplikacje. Aplikacje komunikują się z usługami sieciowymi z wykorzystaniem internetowych protokołów i formatów danych. Protokołem najczęściej stosowanym do komunikacji z usługami sieciowymi jest SOAP, zatwierdzony przez organizację W3C. Najbardziej znanymi platformami natywnie obsługującymi standardy XML, UDDI i SOAP są .NET i Java EE. Usługi sieciowe okazały się skuteczne w sieciach prywatnych, gdzie duże korporacje budowały systemy wymiany danych między swoimi oddziałami oraz z partnerami i klientami. W takich kontrolowanych środowiskach łatwiej jest uzyskać zgodność danych przesyłanych między poszczególnymi komponentami usług sieciowych, otwartość standardów zaś ułatwia tworzenie rozwiązań klienckich niezależnie od platformy. Usługi sieciowe w publicznym Internecie są w okresie powolnej, zakrojonej na wiele lat materializacji. System wyszukiwawczy UDDI umożliwia rejestrowanie usług w Internecie i pozwala aplikacjom wyszukiwać takie usługi i wymieniać dane. Jeśli usługa sieciowa jest płatna, można dołączyć procedurę wnoszenia płatności. Dla poprawnego funkcjonowania na skalę globalną wymaga to bardzo precyzyjnego określenia wszystkich szczegółów działania usługi, zanim zostanie udostępniona publicznie. Wykorzystanie usług sieciowych pozwala komponentom programowym współdziałać ze sobą przez Internet, niezależnie od swojej lokalizacji i szczegółów implementacji. Dzięki temu będą w stanie zastąpić starsze rozwiązania, opracowane dla sieci prywatnych, jak CORBA czy DCOM, zaś dzięki stosunkowo prostej konstrukcji mogą uzyskać znacznie większą popularność. SOAP (ang. Simple Object Access Protocol) – protokół, nadzorowany przez organizację W3C, do wywoływania zdalnego dostępu do obiektów, wykorzystujący XML do kodowania wywołań i najczęściej HTTP lub RPC do ich przenoszenia, możliwe jest jednak wykorzystanie innych protokołów do transportu danych. Korporacyjna Magistrala Usług (ang. Enterprise Service Bus) – dodatkowa warstwa pośrednia w wielowarstwowej architekturze systemów informatycznych umożliwiająca zastosowanie koncepcji SOA w środowisku korporacyjnym. Umożliwia dynamiczne przyłączanie i odłączanie usług wchodzących w skład korporacyjnego systemu informacyjnego. Na sam koniec warto zadać pytanie, która technologia jest lepsza czy gorsza? Niestety odpowiedź na to pytanie jest bardzo złożona i nie będziemy tu prowadzić przesadnych wywodów. Warto zauważyć, iż niewątpliwie tendencje na świecie idą w stronę tworzenia dużych systemów informatycznych przy wykorzystaniu architektury wielowarstwowej oraz SOAP i REST. Co więcej, coraz rzadziej świat „upiera” się by stosować jedną bazę, czy jedną warstwę prezentacji idąc w stronę otwartości oraz Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 23/58 Projekt strategii rozwoju systemu USOS aplikacji typu WWW, które mogą być obsługiwane przez kilka przeglądarek (rzadko wszystkie) co najmniej na systemach operacyjnych rodzin: Windows, Linux, Mac. Bazy danych Do porównania funkcjonalności dostępnych na rynku baz danych wykorzystaliśmy opracowanie zawarte na stronach Wikipedii. (11) Data ostatniej modyfikacji wskazuje na październik 2010. Zawiera również bardzo szeroki zakres analizowanych baz danych: około 50 produktów komercyjnych i open source. Dokonaliśmy prostego podsumowania posiadanych przez bazy danych funkcji w zakresie m.in.: wsparcia dla systemów operacyjnych, podstawowych funkcji, tabel i widoków, indeksów, możliwości bazy danych, partycji, kontroli dostępu przyporządkują jeden punkt za posiadanie funkcji. W wyniku tej analizy można wyodrębnić bazy danych o najbogatszej funkcjonalności. Należą do nich: Miejsce Baza danych - produkt Ilość punktów Licencja 1 Informix Dynamic Server 46 komercyjna 1 Oracle 4 46 komercyjna 1 PostgreSQL 46 2 DB2 5 44 Free and Open Source komercyjna 3 Microsoft SQL Server 38 komercyjna 4 Postgres Plus Standard Server 35 BSD 4 Postgres Plus Advanced Server 35 BSD 5 SQL Anywhere 34 komercyjna 6 Empress Embedded Database 33 komercyjna 7 Linter SQL RDBMS 6 32 komercyjna 7 MySQL 8 32 8 H2 2 31 GPL i komercyjna EPL i MPL 8 Teradata 31 komercyjna 8 UniVerse 31 komercyjna 9 Firebird 29 IPL i IDPL 10 HSQLDB 2 28 BSD 10 Ingres 28 10 OpenLink Virtuoso 28 GPL i komercyjna GPL i komercyjna Tabela 6 Ranking baz danych według danych porównawczych w Wikipedia Źródło: Opracowanie własne na podstawie (11) Należy zauważyć, że na pierwszym miejscu znajdują się ex eaquo bazy danych: Informix Dynamix Server, Oracle 4 oraz najbardziej otwarta baza danych na rynku: PostgreSQL. Jest to jeden z argumentów uzasadniających coraz większą dynamikę penetracji rynku przez tę bazę danych. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 24/58 Projekt strategii rozwoju systemu USOS Access Control Partitioning Other objects Database capabilities Fundamental features Operating system support Informix Dynamic Server 6 5 6 9 9 1 4 6 Oracle 4 7 4 6 11 7 2 4 5 PostgreSQL 7 4 6 DB2 5 8 4 6 10 9 1 4 5 11 4 2 4 5 Microsoft SQL Server 9 1 6 11 4 2 4 1 Postgres Plus Standard Server Postgres Plus Advanced Server 0 0 6 10 9 1 4 5 0 0 6 10 9 1 4 5 SQL Anywhere 7 0 6 10 1 2 4 4 Empress Embedded Database 4 1 6 8 3 2 4 5 Linter SQL RDBMS 6 8 0 4 9 1 1 4 5 MySQL 8 2 4 5 6 3 1 3 8 H2 2 5 0 5 8 2 1 4 6 Teradata 0 4 5 9 4 2 4 3 UniVerse 0 5 6 7 5 1 4 3 Firebird 3 1 6 7 2 1 4 5 HSQLDB 2 4 0 5 8 0 1 4 6 Ingres 0 4 6 6 2 1 4 5 2 4 6 Produkt Tables Indexes and views OpenLink Virtuoso 0 1 6 5 4 Tabela 7 Funkcjonalność baz danych - porównanie na podstawie danych w Wikipedia Źródło: Opracowanie własne na podstawie (11) Porównanie wydajności dwóch czołowych baz open source przedstawiono w (12). Zapytanie SELECT COUNT(id) FROM liczby SELECT id FROM WHERE liczba = 67 SELECT id FROM WHERE liczba = 67 SELECT COUNT(id) FROM stringi; INDEX liczby NIE liczby TAK SELECT id FROM stringi WHERE string=’HDDFBAGFHCABIBIAFAAE’; SELECT id FROM stringi WHERE string=’HDDFBAGFHCABIBIAFAAE’; NIE TAK MySQL 1 rows fetched (844 ms) 55 rows fetched (1,078 s) 55 rows fetched (141 ms) 1 rows fetched (859 ms) 1 rows fetched (1,172 s) 1 rows fetched (16 ms) PostgreSQL 1 rows fetched (719ms) 20533 rows fetched (735 ms) 20533 rows fetched (234 ms) 1 rows fetched (828 ms) 1 rows fetched (1,016 sec) 1 rows fetched (15 ms) Tabela 8 Testy wydajności baz MySQL i PostgreSQL dla 2 mln wierszy Źródło: (12) Dla tabel z 0.6 mln wierszy wyniki przedstawiają się następująco: Zapytanie SELECT COUNT(id) FROM liczby INDEX Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski MySQL 1 rows fetched (265 PostgreSQL 1 rows fetched (188 ms) 25/58 Projekt strategii rozwoju systemu USOS SELECT id FROM WHERE liczba = 67 SELECT id FROM WHERE liczba = 67 SELECT COUNT(id) FROM stringi; liczby NIE liczby TAK SELECT id FROM stringi WHERE string=’HDDFBAGFHCABIBIAFAAE’; SELECT id FROM stringi WHERE string=’HDDFBAGFHCABIBIAFAAE’; NIE TAK ms) 55 rows fetched (312 ms) 55 rows fetched (47 ms) 1 rows fetched (265 ms) 1 rows fetched (359 ms) 1 rows fetched (15 ms) 6170 rows fetched (193 ms) 6170 rows fetched (31 ms) 1 rows fetched (234 ms) 1 rows fetched (250 ms) 1 rows fetched (16 ms) Tabela 9 Testy wydajności baz danych MySQL i PostgresSQL dla 0.6 mln wierszy Źródło: (12) Powyższe wyniki wskazują, że baza PostgreSQL wykazuje wyższą wydajność niż MySQL. Równocześnie testy wykonane przez SUN Microsystems wykazały, że baza PostgreSQL jest tylko 12% wolniejsza od bazy danych Oracle, co potwierdza wyjątkowo wysoką jakość tego produktu, tworzonego przez środowisko Open Source (13). Opierając się na danych zawartych w (14) należy zauważyć, że produkty Oracle posiadają jedne z najwyższych cen na rynku pośród produktów komercyjnych: Liczba procesorów Oracle9i Standard IBM DB2 v.8.1 Workgroup MS SQL Server 2000 Edition Edition Standard Edition 1 $15 000,00 $7 500,00 $4 999,00 Tabela 10 Porównanie kosztów licencji baz danych Źródło: (14) Firma analityczna Evans Data przeprowadziła badania poświęcone popularności baz danych w regionie EMEA wśród firm tworzących oprogramowanie i okazało się, że 48,3% firm wybiera Microsoft SQL Server, ale na drugim miejscu z wynikiem 45,6% plasuje się MySQL, podczas gdy Oracle wybiera tylko ¼ pytanych (wskaźniki nie sumują się do 100%, gdyż firma może wybierać kilka rozwiązań). Co prawda raport ten był wykonany przed przejęciem MySQL przez Oracle, ale widać wyraźnie, że baza Open Source nie jest lekceważona. Jednak po przejęciu MySQL przez Oracle baza ta prawdopodobnie będzie dalej rozwijana . (15) Wniosek Autorów. Oparcie systemu na komercyjnej bazie danych Oracle, której ceny są jednymi z najwyższych na rynku, przy równoległym dostępie do bezpłatnych baz danych o porównywalnej funkcjonalności (PostgreSQL), oraz dużo tańszych baz komercyjnych (MS SQL), może okazać się w dłuższej perspektywie nieuzasadnionym kosztem, który będzie wpływać negatywnie na decyzje nowych uczelni o przystąpieniu do projektu, ale przede wszystkim może spowodować konieczność wykonania kosztownych modyfikacji architektury w przyszłości, aby umożliwić obniżenie kosztów bazy danych poprzez zastosowanie tańszych rozwiązań. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 26/58 Projekt strategii rozwoju systemu USOS Technologie i rozwiązania na uczelniach wyższych Warto teraz spróbować odnieść się do użycia technologii i standardów rozwiązań stosowanych na uczelniach wyższych. Niniejsze punkt będzie miał niestety jedynie charakter szkicu, gdyż nikt w Polsce nie prowadził badań w zakresie omawianych zagadnień. Na podstawie rozmów prowadzonych z przedstawicielami różnych uczelni można poczynić następujące obserwacje: 1. Stosowane rozwiązania zależą od zamożności uczelni – mniejsze i biedniejsze uczelnie stosują bardzo dużo rozwiązań typu Open Source, gdyż często oznacza to jednocześnie brak opłat za licencje. Większe i zamożniejsze uczelnie stosują droższe rozwiązania, budują też własne. 2. Stosowane rozwiązania zależą od preferencji osób decydujących o ich nabyciu – tutaj nie ma zależności pomiędzy wielkością uczelni a stosowanym rozwiązaniem, jest to sprawa preferencji osób decydujących o wyborze technologii i często nie wynika ona wyłącznie z ich preferencji ale jest wypadkową wielu czynników. 3. Stosowane rozwiązania zależą od historii rozwoju systemów informatycznych na danej uczelnie – tu im starsza uczelnia tym zwykle rośnie ilość stosowanych rozwiązań i technologii, wynika to z prostej zależności, ze systemy były kupowane, bądź powstawały etapami. Często w tym przypadku również integracja tych systemów jest bardzo słaba. Podsumowując, możemy stwierdzić, że zróżnicowanie technologii i rozwiązań stosowanych na uczelniach jest ogromne, co powoduje, iż trudno jest jednoznacznie wskazać na faworyta pod tym kontem. Oczywiście planując wybór technologii dla USOS można zapytać, czy musimy kierować się tym co posiadaj uczelnie. Otóż, według naszej opinii odpowiedź nie jest jednoznaczna, poniżej przedstawiamy argumentację: • • TAK – gdyż jeśli wybierzemy platformę łatwą do akceptacji przez środowisko np. z przyczyn ekonomicznych, to tym samym ułatwiamy ekspansję tego systemu. NIE – jeśli wybierzemy platformę, które jest otwarta i tania, to fakt, że uczelnie posiadają już jakieś rozwiązania nie będzie takie krytyczne. Oczywiście w tej sytuacji należy dać wsparcie utrzymaniowe i serwisowe. Wymagania co do integracji systemu W chwili obecnej na świecie istnieje ogromny rynek aplikacji czy systemów informatycznych, które wypełniają niemal każdy z obszarów życia. Problem ten dotyka również uczelni wyższych, na uczelniach z których pochodzą autorzy niniejszego opracowania można wymienić co najmniej kilkanaście systemów wspierających zasadnicze obszary działania uczelnie. Systemy te bardzo często są bardzo słabo ze sobą skomunikowane. Wielu użytkowników zadaje sobie pytanie, czy nie można uprościć tego złożonego świata informatyki i zastąpić wielu systemów jednym? Niestety, odpowiedź na to pytanie jest negatywna. Wynika to z wielu przyczyn, jak choćby zakup poszczególnych systemów w różnych latach, czy też brak systemów na tyle zintegrowanych, by mogły spełniać się w każdym obszarze (już sygnalizowana to wcześniej). Ta różnorodność, poza uciążliwością dla użytkownika - objawiającą się np. w konieczności nauki nowego interfejsu, ma ogromne oddziaływanie w obszarze serwisu, utrzymania a przede wszystkim Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 27/58 Projekt strategii rozwoju systemu USOS integracji tych systemów. Integracja jest naturalną potrzebą wynikającą np. z faktu iż dane istotne dla użytkownika powinny być spójne niezależnie od systemów w jakich są przetwarzane. Pozornie wydaje się, iż nie ma nic prostszego jak uzgodnić dane pomiędzy dwoma systemami informatycznymi. Jednak to nie prawda, istnieje wiele problemów związanych z transformacją danych, ich dopasowaniem, wpływem specyfiki organizacyjnej, poufnością, spójnością. Co więcej, aby mówić o integracji danych należy wpierw zapewnić poprawną komunikację danych pomiędzy tymi systemami, czy to poprzez szynę danych, SOA, Web Service, czy inne rozwiązania. To z kolei implikuje, że musimy mieć poprawnie zbudowaną architekturę systemów informatycznych, tak by nie było łatwo do niej się włamać, a jednocześnie by wymiana danych nie była nadmiernie utrudniona. Wszystkie te zagadnienia powodują, że integracja jest obecnie jednym z największych wyzwań wdrożeń i eksploatacji systemów informatycznych. W świetle tych faktów i rzeczywistej różnorodności systemów informatycznych występujących na uczelni, widać wyraźnie, że dowolny system jaki teram ma być wprowadzony na uczelnie musi być projektowany z myślą o łatwej integracji z innymi. Należy podkreślić, że każda uczelnia posiada co najmniej kilka systemów z którymi USOS musi się w sposób wygodny i łatwy integrować, będą to co najmniej: • • • • Kadry – integracja musi przebiegać co najmniej jednokierunkowo (Kadry -> USOS), gdyż USOS musi być zasilany informacjami o zatrudnieniu i zwolnieniu pracownika, czy zmianie jego danych (np. nazwiska). Ideałem by było, gdyby ta integracja przebiegała również w drugim kierunku, wtedy system kadrowy mógłby otrzymywać informacje o pokojach czy telefonie pracownika. Płace – system płacowy musi pobierać dane z USOS w celu obsługi karty KIOD dla pracowników dydaktycznych, obecnie uczelnei we własnym zakresie muszą dopisywać taką funkcjonalność. Rekrutacja – w wyniku procesu rekrutacji kandydaci którzy zostali przyjęci staja się studentami, zatem migrują ich dane do USOS, jednak na chwilę obecną ta migracja to wręcz ręczny proces, który nie ułatwia pracy dziekanatom. Z drugiej strony integracja jest niezbędna w zakresie prezentacji kierunków i specjalnści, a to są dane, które system Rekrutacyjny w sposób automatyczny powinien przenosić z USOS. Finanse – wymagana jest integracja w zakresie stypendiów studentów, opłat za studia, opłat za akademiki i wielu innych. Można wymienić jeszcze wiele obszarów w których potencjalnie ta integracja z USOS jest niezbędna, lub choćby mile widziana. Graficznie obrazuje to poniższy rysunek. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 28/58 Projekt strategii rozwoju systemu USOS Narzędzia do tworzenia treści e-learning Inne System Systemy Finansowy System Zarządzania Studiami System CRM System KadrowoPłacowy System BI Rysunek 11 Współpraca systemów informatycznych uczelni z Systemem Zarządzania Studiami Źródło: Opracowanie własne na podstawie: (16) Podsumowując jednym z krytycznych czynników przy wyborze architektury oraz sposobu tworzenia oprogramowania takiego ogromnego systemu jak USOS powinna być łatwość integracji z innymi systemami. Architektura aplikacji w kontekście kosztów W kontekście kosztów utrzymania i rozwoju systemu niezmiernie ważną cechą nowoczesnej architektury systemów jest modularność i wielowarstwowość. Specyfika współpracy w projektach Open Source, konieczność współpracy wielu osób, które nigdy lub bardzo rzadko komunikują się w sposób bezpośredni, najczęściej skutkuje, że jego architektura spełnia te kryteria. W 2004 roku zespół Hardvard Business School wykonał pogłębione studium m.in. kosztów związanych architekturą monolityczną (głównie produkty komercyjne) i modularną (prowokowaną przez model współpracy Open Source). W pracy naukowcy z Harvard Business School dokonali próby porównania kosztów wprowadzania zmian i poprawek w aplikacji Mozilla, która pierwotnie miała architekturą monolityczną, z kosztami w wersji wdrożonej w 1999, która została całkowicie przebudowana pod kątem modularności i Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 29/58 Projekt strategii rozwoju systemu USOS wielowarstwowości, oraz w systemie Linux, charakteryzującym się również nowoczesną architekturą. Analiza ta wykazała, że systemy projektowane w architekturze monolitycznej są droższe o rząd wielkości w utrzymaniu w porównaniu do systemów modularnych. W poniższej tabeli przedstawiono średni koszt wykonania pojedynczej zmiany w systemie, mierzony ilością elementów, które trzeba było równocześnie zmodyfikować w stosunku do liczby wszystkich elementów. Program Mozilla-1998-04-08 Mozilla-1998-10-08 Mozilla-1998-12-11 Mozilla-1999 Linux-2.1.88 Linux-2.1.105 Koszt zmian 17.35% 18.00% 2.78% 3.80% 3.72% 5.16% Tabela 11 Koszt wprowadzania zmian w systemach Mozilla i Linux Źródło: (17) Innym sposobem pomiaru jakości kodu było oszacowanie kosztu koordynacji zmiany – szacunkowego kosztu komunikacji pomiędzy osobami tworzącymi poszczególne elementy systemu. Miara ta silnie zależy od rozmiaru systemu – dużo łatwiej jest koordynować mniejsze projekty. Poniższa tabela porównuje system Mozilla-1998-04-08 o starszej architekturze z systemem Mozilla-1998-12-11 (tuż po przeprojektowaniu systemu) oraz z systemem Linux 2.1.105. Linux 2.1.105 Mozilla 1998-04-08 Mozilla 1998-12-11 1678 1684 1508 Ilość plików źródeł 30,537,703 10,234,903 Koszt koordynacji zmian 20,918,992 Tabela 12 Koszt koordynacji zmian w systemach Mozilla i Linux Źródło: (17) Liderzy projektów Open Source koncentrują się nad podejmowaniem decyzji architektonicznych umożliwiających modularność systemów. Jedynie bowiem modularna architektura systemu pozwala na przyciągnięcie do projektu dużej liczby projektantów. Bez architektury modularnej jest niewielka szansa, że osoby współpracujące w modelu Open Source są w stanie: a) dostatecznie zrozumieć konstrukcję systemu aby móc wnieść istotny wkład w projekt; b) tworzyć nowe funkcjonalności lub poprawiać błędy nie wywierających wpływu na pracę zbyt wielu innych osób. Wniosek Autorów. Zastosowanie organizacji projektu opartej o Open Source może w długiej perspektywie pozwolić na tworzenie oprogramowania bardzo wysokiej jakości ponosząc dużo niższe koszty niż przy tradycyjnym podejściu. Niezwykle ważne jest utrzymanie trzonu projektantów, którzy będą odpowiedzialni za architekturę rozwiązania oraz za kontrolę jakości w projekcie. Architektura powinna być oparta o wielowarstwowość i modularność co pozwoli na łatwą integrację z innymi systemami oraz utrzymanie małego kosztu zmian systemu. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 30/58 Projekt strategii rozwoju systemu USOS 5. Otoczenie socjologiczno-psychologiczne Rola zaufania w budowaniu środowiska Open Source Fenomen rozwoju oprogramowania Open Source, trwałość tego procesu oraz coraz większy wpływ na tradycjonalny rynek IT spowodował duże zainteresowanie naukowców zbadaniem jego przyczyn. W pracy pt. „Open source – new rules in software development” (18) autorzy wykazują, że decydującym czynnikiem dla utrzymania związku pomiędzy twórcami kodu z jednej strony a firmami, które ten kod wykorzystują komercyjnie jest wewnętrznie motywowane zaufanie do norm i zasad panujących w środowisku. Co więcej zaufanie to ma charakter instytucjonalny – nie bazuje na zaufaniu do konkretnych osób. Podstawową zasadą środowiska Open Source jest, że firmy komercyjne nie mają prawa sprzedaży źródeł oprogramowania. Oprogramowanie to każdy może ściągnąć za darmo. Firmy mogą sprzedawać wygenerowaną przez siebie wartość dodaną w postaci np. kompletowania lub testowania pracującego systemu, o potwierdzonej przez nich jakości rynkowej. Nowy paradygmat socjologiczny o motywacji Zaskakujące wyniki opublikował w swojej książce pt. „Drive: The whole truth about what motivates us” Daniel Pink. Przeprowadzone eksperymenty wykazały, że tradycyjne metody motywacji oparte w dużym stopniu o zasadę tzw. „kija i marchewki” są właściwe dla prac nie wymagających kreatywności intelektualnej. Rysunek 12 Motywacja oparta o kij i marchewkę Źródło: (19) Daniel Pink dowodzi, że tam gdzie wykonywane zadania wymagają dużej innowacyjności skuteczniejszymi metodami motywacji są: autonomia (zarządzanie samym sobą), mistrzostwo (możliwość wykazania się wysokimi kwalifikacjami), cel (impuls powodujący, że chcemy być częścią czegoś większego, wykraczającego poza nas samych). Zaskakująco, stosowanie tradycyjnej motywacji opartej o finanse przynosi gorsze rezultaty. Zaktualizowana teoria motywacji tłumaczy zjawisko Open Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 31/58 Projekt strategii rozwoju systemu USOS Source i potwierdza, że jego byt nie jest krótkotrwały i przypadkowy lecz wywodzi się z konstrukcji psychologicznej człowieka. W pracy pt.” Using Social Psychology to Motivate Contributions to Online Communities” autorzy dowodzą, że o aktywnym uczestnictwie w projektach Open Source nie decydują żadne osobiste korzyści, które uczestnicy mogą uzyskać lecz wiara, że ich osobisty wkład jest istotny dla grupy. (20) Misja uczelni wyższych ych a Open Source Ogromny wpływ na rozwój sieci Internet miało i nadal ma oprogramowanie typu „public-domain”. „public To dzięki darmowej dystrybucji rozwinęły się liczne usługi sieci w tym także WWW. Świat nie byłby takim jaki jest obecnie gdyby nie oprogramowanie „public-domain” „public domain” a potem Open Source. Dzięki rozpowszechnianiu się języków programowania i środowisk uruchomieniowych (kompilatory i interpretery) na licencjach typu Open Source oraz szybkiemu rozwojowi bibliotek funkcyjnych nastąpił przyspieszony rozwój systemów informatycznych. Programiści mogli pracować nad rozwiązaniami bardziej zaawansowanymi opierając się na powszechnie dostępnych i sprawdzonych bibliotekach funkcji i obiektów czy modułów. Obecnie trwa następny następny etap tego rozwoju. W ramach dystrybucji Open Source dostępnych jest wiele komponentów, które stanowią kolejną warstwę architektury aplikacji. Nowoczesne programowanie rozpoczyna się od doboru odpowiednich komponentów. Kolejnym etapem jest rozwój interfejsów interfejsów komunikacyjnych pomiędzy komponentami takimi jak SOAP czy REST. Inwencja programisty może zostać wykorzystana na poziomie bazującym na komponentach i interfejsach co znacznie zmniejsza koszt wytworzenia systemu. Przyspieszenie budowy systemów informatycznych atycznych jest jednym z zasadniczych rezultatów rozwoju oprogramowania Open Source, co stanowi o olbrzymim jego znaczeniu dla rozwoju cywilizacji. Interfejsy (SOA, REST, ESP) Komponenty Biblioteki funkcji i obiektów Języki programowania (PHP, Perl, Phyton, Java) Rysunek 13 Piramida technologiczna - wpływ Open Source na rozwój metod programowania programow Źródło: Opracowanie własne Autorzy: Dorota Nicewicz-Modrzewska, Modrzewska, Ścibór Sobieski 32/58 Projekt strategii rozwoju systemu USOS Znakomita większość oprogramowania „public-domain” powstawała na uczelniach wyższych – głównie amerykańskich. Uczelnie te udostępniając w sposób otwarty oprogramowanie rozsławiały swoją markę i potwierdzały własny wysoki poziom. Uczelnie wyższe, wypełniając szczególną misję w rozwoju cywilizacyjnym i kulturowym, niejako zobligowane są do promowania idei Open Source, także poprzez kreowanie własnego wkładu w ten model wytwarzania oprogramowania. Zamachowiec Oracle 20 stycznia 2010 roku ogłoszono zakończenie procesu przejęcia firmy SUN przez Oracle. W środowisku Open Source przejęcie to zrodziło wiele obaw o losy takich projektów Open Source jak Java, Open Office czy MySQL (kupiony wcześniej przez SUN). Zdaniem autorów niniejszego opracowania, główną przyczyną tego przejęcia były skutki recesji w Stanach Zjednoczonych, które spowodowały aż 17% spadek przychodów ze sprzedaży nowych licencji oraz 22% spadek przychodów z usług Oracle. (21) Od czasu rozpoczęcia recesji wielu komentatorów podkreślało, że jedynym segmentem na rynku, który na niej skorzysta jest właśnie Open Source. (22) (23) (24) (25) Ograniczanie kosztów zmusza bowiem firmy do uważniejszego przyglądania się tańszym rozwiązaniom a w tracie tych analiz często menedżerowie zauważają, że dojrzałe produkty Open Source istnieją prawie dla każdego obszaru oprogramowania (26) oraz, że posiadają profesjonalne wsparcie. Im dłużej zatem będzie trwała recesja tym szybciej Open Source zdobędzie pozycję na rynku kosztem rozwiązań komercyjnych. (27) (28) Przez następne miesiące cały świat obserwował jakie będą prawdziwe poczynania Oracle w stosunku do zakupionych projektów. Oracle nie pozwolił długo czekać. W sierpniu 2010 roku, społeczność Open Source zmroziła wiadomość, że korporacja wystąpiła z pozwem przeciwko Google, zarzucając mu łamanie patentów i praw autorskich związanych z Javą na platformie Android. Google Corp. odpowiedział na tę informację bardzo stanowczym sprzeciwem, deklarując zdecydowaną obronę standardów Open Source i kontynuację prac nad platformą Android. (29) W aspekcie reguł socjologicznych, którym podlega społeczność Open Source można zaryzykować twierdzenie, że ruch ten był jednym z najbardziej ryzykownych posunięć Oracle. Jak bowiem można przeczytać we własnych biuletynach korporacji (30), zaufanie do producenta warunkuje jego sukces rynkowy. Występując przeciwko Google, Oracle zaatakował ogromną społeczność, która dotychczas współtworzyła oprogramowanie takie jak OpenOffice, Java czy MySQL. Błyskawicznie spadło zaufanie do korporacji a przede wszystkim do produktów Open Source z jego portfolio co może uniemożliwić utrzymanie społeczności wokół nich. Co ciekawe, OpenOffice nie czeka na ruch ze strony korporacji i samo postanowiło zadbać od siebie tworząc wolny fork LibreOffice. To właśnie pokazuje jak świat Open Source reaguje w przypadku zagrożenia i to świadczy o prawdziwej utracie zaufania. O ile obecnie pojawiają się ogromne wątpliwości co do przyszłości bazy danych MySQL, niepewna jest przyszłość OpenOffice o tyle należy zauważyć, że oprogramowanie Java znajduje się w innej sytuacji. Jego poziom upowszednienia się na rynku jest ogromny, od wielu lat istnieją niezależne projekty, w tym także Open Source (np. Apache Harmony) tworzące niezależną od Oracle wirtualną maszynę Javy. Ciałem zarządzającym rozwojem Javy jest Java Community Process (JCP), która na początku Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 33/58 Projekt strategii rozwoju systemu USOS września 2010 roku wydała rezolucję w kwestii przekształcenia jej w całkowicie niezależne od producentów ciało, w której wszyscy członkowie są sobie równi i nikt nie ma prawa weta. W głosowaniu wszyscy członkowie JCP , w tym reprezentanci IBM-a, Google'a, Intela, Red Hatu, Nokii, AT&T, VMware, Vodafone, Research In Motion i Fundacji Apache poparli rezolucję. Wszyscy za wyjątkiem jednego. Przedstawiciel Oracle'a wstrzymał się od głosu. (27) Można więc zaryzykować twierdzenie, że atak Oracle na wolność Javy przyspieszy jedynie jej całkowite uwolnienie od producentów, co więcej, społeczność Open Source zyskała dzięki niemu bardzo potężnego i innowacyjnego sprzymierzeńca – firmę Google. Wniosek Autorów. Zastosowanie najnowszych odkryć socjologicznych może pozwolić na zmianę organizacji projektu USOS w taki sposób aby wzrosło zaangażowanie w programowanie systemu po stronie wszystkich uczestników. W świetle problemów z utrzymaniem stałego zespołu programistycznego jest to, zdaniem autorów, szansa na przyspieszenie rozwoju systemu i poprawę jakości kodu bez ponoszenia nadmiernych kosztów. Co więcej, autorzy opracowania uważają, że „uwolnienie” USOS może mieć bardzo pozytywny wpływ na wzrost zaufania do tego systemu i wiele uczelni będzie samo z siebie aplikować poprawki do systemu. 6. Analiza aktualnego stanu projektu USOS Autorzy niniejszego opracowania nie uczestniczą bezpośrednio w pracach projektu. Ich wiedza o organizacji projektu wywodzi się z codziennego doświadczenia w opiece nad systemem USOS oraz z wymiany informacji na spotkaniach kierownictwa IT uczelni zrzeszonych w MUCI, które odbywają się cyklicznie oraz z informacji opublikowanych na stronach muci.amu.edu.pl oraz USOS.edu.pl. MUCI Międzyuniwersyteckie Centrum Informatyzacji zostało powołane jako jednostka międzyuczelniana uchwałą Konferencji Rektorów Uniwersytetów Polskich w 2001 roku. Za siedzibę obrano Uniwersytet im. Adama Mickiewicza. MUCI jest jednostką koordynującą projekt. Jego udziałowcami jest 18 uniwersytetów publicznych. Dwadzieścia uczelni ma status członka stowarzyszonego. Na czele MUCI stoi Rada licząca 18 członków. Pracami MUCI kieruje Dyrekcja, w której zasiada 7 członków, z czego 5 równocześnie zasiada w Radzie MUCI. (31) W skład Rady MUCI wchodzą w większości rektorzy, prorektorzy lub pełnomocnicy rektorów uczelni uczestniczących w MUCI. Daje to Radzie bardzo wysokie kompetencje do podejmowania decyzji oraz do zawierania konsensusu w środowisku. Jest to niezwykle ważna jej cecha i siła jednocześnie. Na stronach MUCI brak jest informacji o działalności Rady MUCI i Dyrekcji. Nie wiadomo jak często gremia te się zbierają i co jest tematem ich prac. Informacja ta nie dociera do osób odpowiedzialnych za wdrożenia systemu USOS na uczelniach także innymi kanałami. Nie wiadomo w jaki sposób wydatkowane są pieniądze pochodzące ze składek uczelni, jakie są plany co do rozwoju systemu itp. Należy podkreślić, że informacja ta jest wysoce niedostateczna. Ostatnie, szczegółowe informacje, jakie są publikowane na stronach MUCI dotyczą działań w początkowej fazie projektu w ramach UPI (Uniwersyteckiego Porozumienia Informatycznego) w latach 2000-2001 i zawierają bardzo wyczerpującą informacje o stanie prac na tamtym etapie. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 34/58 Projekt strategii rozwoju systemu USOS Nie jest jasna rola Rady MUCI w stosunku do Dyrekcji, ponieważ aż 5 z 7 członków Dyrekcji sprawuje równocześnie funkcję członka Rady, co uniemożliwia sprawowanie kontrolnej funkcji przez Radę. USOS Pracę nad systemem zapoczątkowało otrzymanie w roku 1999 przez 17 polskich uniwersytetów publicznych grantu w ramach programu TEMPUS (UM_JEP-14461-1999). Jest rozwijany od 2000 roku, najpierw przez Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, a później przez Zespół Roboczy USOS usytuowany przy tym wydziale. W jego skład wchodzą pracownicy różnych uczelni, które wnoszą pewien wkład w rozwój oprogramowania, jednakże wiodącą rolę nadal spełnia Uniwersytet Warszawski z dużym wsparciem Uniwersytetu Mikołaja Kopernika. Jednostką posiadającą wyłączne prawo do korzystania z systemu USOS i rozporządzaniem nim na wszystkich polach eksploatacji jest MUCI. MUCI udziela licencji swoim członkom oraz członkom stowarzyszonym na podstawie umowy licencyjnej za roczną opłatą w wysokości 16000 lub 8000 zł (wg danych zawartych na stronie MUCI w dniu 10.10.2010). Zdaniem wielu uczelni uczestniczących w projekcie USOS, obecnie ponoszone koszty nie są znaczne i ich podniesienie nie będzie źle przyjęte, o ile zostanie ono odpowiednio umotywowane. Funkcjonalność Zakres funkcjonalności jest obecnie najsilniejszą stroną systemu USOS. Obejmuje on (32) m.in.: • • • • • • • • • • • Immatrykulacja; księga albumów; współpraca z elektroniczną legitymacją studencką; obsługa szerokiego zakresu rodzajów studiów oraz trybów; obsługa dyplomów, w tym suplementu; pomoc materialna dla studentów (stypendia, przelewy, raporty i sprawozdania); płatności; kontrola poprawności planowania zajęć i zajętości sal; wsparcie dla wymiany studenckiej; przeprowadzanie ankiet; sprawozdania statystyczne dla GUS. Aplikacje zespolone z USOS oferują między innymi: • • • • • elektroniczną rekrutację na studia; webowy interfejs dla studentów i pracowników dydaktycznych; archiwum prac dyplomowych; rejestrację żetonową na zajęcia; katalog ECTS. Pomimo bardzo szerokiej funkcjonalności i znacznego zmniejszenia pracochłonności obsługi administracyjnej w dziekanatach, system USOS co roku zbiera dużą ilość złych ocen od studentów i pracowników wykorzystujących system. Narzekają głównie na bardzo nieczytelny i mało intuicyjny interfejs systemu USOSweb i zupełnie nieczytelny interfejs USOS, na awaryjność systemu do Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 35/58 Projekt strategii rozwoju systemu USOS zapisywania się na zajęcia oraz systemu rekrutacyjnego. (33) Wątpliwości budzi organizacja procesu testowania, czy brak specjalisty, który wykonywałby automatyczne testy systemu. Uniwersytet im. Adama Mickiewicza wykorzystuje dotychczas własną aplikację do rekrutacji. Podejmując decyzję o dalszym jego utrzymaniu dokonał szczegółowego porównania funkcjonalności oraz jakości interfejsu w stosunku do modułu rekrutacji dostępnego w ramach USOS. Analiza wykonana przez osoby z zewnątrz jednostki IT, nie znające ani jednego z systemów wykazała, że lokalnie rozwijany system nie ustępując funkcjonalnością ma znacząco czytelniejszy, łatwiejszy w obsłudze interfejs. Doświadczenie to pokazuje, że lepsza współpraca pomiędzy uczelniami mogłaby w efekcie dać oprogramowanie o dużo wyższej jakości, pozwalając na wykorzystanie doświadczeń nie tylko Uniwersytetu Warszawskiego ale również pozostałych uczelni. Zarządzanie projektem Kierownikiem projektu od początku projektu jest pani dr Janina Mincer-Daszkiewicz, pracownik Instytutu Informatyki Uniwersytetu Warszawskiego. Dzięki bliskiemu powiązaniu z działalnością dydaktyczną uczelni wiele funkcjonalności systemu była tworzona w ramach prac magisterskich studentów Uniwersytetu Warszawskiego, co z pewnością pozwoliło na szybki rozwój funkcjonalności w stosunku do posiadanych środków finansowych. Należy podkreślić, że osobiste zaangażowanie w projekt kierownika projektu stanowi w dużym stopniu o jego obecnym sukcesie. Uczestnictwo w wielu konferencjach, w zespołach międzynarodowych przy równoczesnym szybkim odpowiadaniu na pocztę elektroniczną spina wewnętrznie projekt. Jednak zdaniem autorów, dla bezpieczeństwa dalszego rozwoju, organizacja projektu nie powinna w tak dużym stopniu zależeć od zaangażowania tylko jednej osoby. Do wad obecnego sposobu zarządzania projektem należy jednak zaliczyć małą stabilność głównego zespołu programistów, który w ostatnich latach opuściło kilku projektantów, a z informacji przekazywanych przez kierownika projektu wynika, że należy się spodziewać pogorszenia tej sytuacji. Niestety niewiele uczelni deklaruje chęć aktywnego uczestnictwa w pracach programistycznych pomimo ponawianych apeli kierownika projektu. Zdaniem autorów niniejszego projektu jest to spowodowane przede wszystkim bardzo zamkniętym sposobem zarządzania projektem, zamkniętą licencją oraz oparciem o kosztowną architekturę Oracle. Krytycznie należy niestety ocenić planowanie projektu. Na stronach projektu nie jest dostępny żaden harmonogram planowanych prac ani ich kosztorys. Dostępna jest jedynie informacja o wykonanych pracach lub stanie zaawansowania rozpoczętych zadań. Dostęp do stron USOS.edu.pl dla członków MUCI jest bardzo utrudniony. Otrzymanie uprawnień przez autorów niniejszego raportu trwało wiele miesięcy a i tak nadal nie jest on pełen – brak jest dostępu np. do strony Komisji USOS. Prace Komisji USOS koordynowane są za pomocą listy dyskusyjnej oraz poprzez spotkania Komisji. Niestety postulaty zgłaszane przez uczelnie nie trafiają na żadną oddzielną listę, która byłaby kontrolowana i zdarza się, że zgłaszane postulaty giną w powodzi maili na liście dyskusyjnej. Wiele uczelni podnosi, że obecne wsparcie systemu ze strony Zespołu Roboczego USOS jest niedostateczne. Zdaniem autorów raportu, na negatywną ocenę wpływa rosnąca skala systemu, brak Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 36/58 Projekt strategii rozwoju systemu USOS regulacji co do sposobu realizacji wsparcia technicznego oraz niestabilny skład Zespołu Roboczego. Brak jest uregulowań formalnych gwarantujących czas reakcji chociażby na najbardziej krytyczne zdarzenia. Sytuację mogłaby poprawić współpraca firmami komercyjnymi udostępniającymi komercyjne wsparcie techniczne. Niestety oparcie o technologię Oracle oraz zamknięta licencja znakomicie utrudnia rozwinięcie modelu, który sprawdza się przy rozwiązaniach Open Source. Należy podkreślić, że problemy z systemem USOS, często wpływają na obniżenie prestiżu uczelni, ze względu na pojawiające się w mediach krajowych negatywnych ocenach działalności nie tylko systemu USOS ale również samych uczelni. Technologia Główna aplikacja USOS oparta jest o bazę danych Oracle oraz interfejs Oracle Forms i Oracle Reports. Decyzja o wyborze tej technologii została podjęta blisko 10 lat temu. Należy podkreślić, że obecnie firma Oracle wycofała się z dalszego rozwoju Oracle Forms w tamtej wersji co powoduje, że w najbliższej przyszłości mogą nastąpić problemy z kompatybilnością z nowymi systemami operacyjnymi stacji roboczych. Fakt ten zmusza do dokonania istotnej zmiany technologii, która powinna objąć przede wszystkim interfejs użytkownika USOS. Aplikacje stowarzyszone takie jak UsosWeb wykorzystują technologie Open Source takie jak PHP, Phyton, Smarty oraz bazę danych MySQL. Osoby obsługujące system USOS w dziekanatach często narzekają na mało wygodny interfejs, przestarzały jego wygląd, odbiegający od obecnych standardów. Uczelnie wykorzystujące system USOS wskazują niejednokrotnie na problemy wynikające z konieczności migracji danych pomiędzy systemem USOS a systemami takimi jak USOSweb. Dla systemu USOSweb, ze względu na wysokie koszty licencji, w większości wykorzystują bazę danych MySQL. Problemy z synchronizacją danych pomiędzy aplikacjami tak blisko powiązanymi jakimi są USOS i USOSweb wskazują, że architektura aplikacji nie wspiera w wystarczającym stopniu integracji z innymi aplikacjami, co zdaniem autorów jest dużą wadą systemu. Z informacji, które były wymieniane w zespole pracującym nad strategią systemu USOS wynika, że ze względu na pisanie kodu w języku polskim system nie pozwala na włączenie w łatwy sposób do prace programistyczne osób obcojęzycznych. Nie jest też możliwa łatwa lokalizacja systemu i udostępnienie go do użytkowania dla uczelni spoza Polski co uniemożliwia konkurowanie na rozwijającym się rynku europejskim. Z doświadczeń Uniwersytetu im. Adama Mickiewicza, niezwykle pracochłonna jest obsługa raportów systemie USOS. W skali uczelni jaką jest UAM, do sprawnej obsługi tej części systemu niezbędne jest zatrudnienie co najmniej dwóch osób. Wiele problemów generuje również moduł związany z obsługą płatności. 7. Analiza SWOT Dokonana poniżej analiza SWOT powinna pozwolić na zdefiniowanie opcji strategicznych, które pomogą wykorzystać silne strony oraz szanse płynących z otoczenia aby zminimalizować słabe strony projektu oraz ryzyko zidentyfikowanych zagrożeń. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 37/58 Projekt strategii rozwoju systemu USOS Silne strony • Duży zakres obsługiwanej funkcjonalności • Dominująca pozycja na rynku polskim • Duże osobiste zaangażowanie kierownika projektu • Duże zaufanie do trwałości projektu ze strony uczestniczących uczelni • Wysoki prestiż członków Rady MUCI pozwalający na wypracowanie niezbędnego konsensusu w środowisku akademickim Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski Słabe strony • Oparcie o technologię Oracle Forms i Oracle Reports, nie rozwijaną już przez producenta • Uzależnienie od jednej z droższych na rynku baz danych przy równoczesnym dostępie do porównywalnych funkcjonalnie rozwiązań o dużo niższym koszcie lub bezpłatnych • Archaiczny w swoim wyglądzie, negatywnie oceniany przez użytkowników interfejs systemu USOS • Monolityczna architektura aplikacji wpisana w silnik bazy danych – stosunkowo duże koszty zmian • Kłopotliwa integracja danych pomiędzy systemami USOS, USOSweb, IRK itp. • Mała stabilność trzonu zespołu programistów • Słabo rozwinięta komunikacja w projekcie • Brak harmonogramów rozwoju systemu • Brak kosztorysów rozwoju systemu • Brak informacji o działaniach Rady MUCI i Dyrekcji MUCI • Małe zaangażowanie w prace programistyczne większości członków MUCI • Duża zależność trwałości projektu od zaangażowania jednej osoby – kierownika projektu • Niedostateczne wsparcie techniczne systemu • Brak komercyjnych firm realizujących wsparcie systemu • Źle oceniany przez studentów interfejs systemu USOSweb • Powtarzające się problemy z wydajnością i obsługą modułu rekrutacyjnego • Powtarzające się co roku problemy z realizacją rejestracji żetonowej • Problemy z synchronizacją danych pomiędzy USOS a aplikacjami stowarzyszonymi (np. USOSWeb) • Pracochłonny system raportowania systemu USOS • Kod systemu pisany w języku polskim • Brak gotowości do lokalizacji systemu dla innych krajów • Brak informacji o aktualnych kosztach wprowadzania zmian w architekturze systemu • Bardzo wolny proces tworzenia nowej strategii systemu USOS 38/58 Projekt strategii rozwoju systemu USOS Szanse • Gotowość do ponoszenia wyższych kosztów na system USOS przez uczelnie • Szybki rozwój funkcjonalny darmowych baz danych takich jak np. PostgreSQL pozwala na zmniejszenie kosztów wejścia w projekt przez nowe uczelnie, łatwiejsze włączanie się programistów do realizacji zadań, przeznaczenie większych środków na wynagrodzenia kluczowych projektantów • Zweryfikowany na rynku model rozwoju w oparciu o Open Source pozwalający na czerpanie przychodów z subskrypcji, włączenie do współpracy firm komercyjnych, szybszą penetrację rynku • Możliwość zmiany architektury systemu na wielowarstwową, pozwalającą łatwiejsze włączanie się programistów do projektu, lepszą kontrolę jakości projektu, łatwiejszą integrację z innymi systemami oraz lokalizację • Możliwość bezpłatnego wykorzystania dojrzałych rozwiązań typu Open Source – np. eduSTORE (HIS) • Podniesienie jakości kodu systemu poprzez zastosowaniu modelu rozwoju opartego o Open Source • Gotowość środowiska europejskiego do nawiązania współpracy Zagrożenia • Ryzyko braku kompatybilności systemu Oracle Forms i Oracle Reports z systemem operacyjnym stacji roboczych • Ryzyko wejścia na rynek europejski systemów Fundacji Kuali • Możliwość zainteresowania firm komercyjnych rozwojem swojego biznesu przy wykorzystaniu systemów Fundacji Kuali • Ryzyko rozpowszechnienia się na rynku europejskim projektów innych uczelni europejskich (np. HIS). • Rozpowszechnienie się komercyjnych rozwiązań do obsługi toku studiów opracowywanych przez firmy takie jak SAP lub Microsoft, wraz ze wdrażaniem rozwiązań ERP na uczelniach • Uzyskanie dominującej pozycji na rynku rozwiązań typu Open Source takich jak PostgreSQL, Java, C# utrudniające uzasadnienie dalszego ponoszenia kosztów na rozwiązania komercyjne (np. Oracle) • Zmniejszające się zainteresowanie programistów posiadaniem kompetencji związanych z systemem Oracle Tabela 13 Analiza SWOT projektu „USOS” Źródło: opracowanie własne Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 39/58 Projekt strategii rozwoju systemu USOS III. Opcje strategiczne Wariant I „USOS 2” Opcja ta została przedstawiona w rekomendacji przesłanej przez p. Janinę Mincer Daszkiewicz, opartą o stopniową zmianę systemu. Koncepcja zakłada: • • • • • • • • pozostawienie Oracle jako bazy centralnej z osadzonej na niej logiką i rolami pozyskanie środków na nowy zespół rozważenie technologii Java lub WPF prowadzenie dwóch osobnych realizujących proof of concept pozostawienie aplikacji webowych bez zmian stopniowe przenoszenie modułów USOS do nowej technologii przeprowadzenie analizy przepływu informacji w USOS dla zastosowania ESB stopniowe pisanie kodu w języku angielskim Analiza SWOT Zdaniem autorów raportu przyjęcie powyższego modelu rozwoju pozwoli na usunięcie jedynie niewielu słabych stron systemu nie zabezpieczając przed zagrożeniami płynącymi z zewnątrz, a przede wszystkim nie wykorzystując szans. Silne strony • Duży zakres obsługiwanej funkcjonalności • Duże zaufanie do trwałości projektu ze strony uczestniczących uczelni • Wysoki prestiż członków Rady MUCI pozwalający na wypracowanie niezbędnego konsensusu w środowisku akademickim • Szansa na unowocześnienie interfejsu systemu USOS • Stosunkowo niski koszt zmian architektury systemu • Ryzyko popełnienia błędów przy projektowaniu nowego rozwiązania • Łatwiejsza integracja danych Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski Słabe strony • Opór przed zmianą podstawowego interfejsu wykorzystywanego przez dziekanaty • Uzależnienie od jednej z droższych na rynku baz danych przy równoczesnym dostępie do porównywalnych funkcjonalnie rozwiązań o dużo niższym koszcie lub bezpłatnych • Monolityczna architektura aplikacji wpisana w silnik bazy danych – utrzymanie stosunkowo dużych kosztów zmian • Małe szanse na poprawę stabilności zatrudnienia trzonu zespołu programistów • Brak zmian w organizacji projektu dotyczących komunikacji, harmonogramowania, kosztorysowania • Brak zmian w sposobie funkcjonowania ciał nadrzędnych dla Zespołu Roboczego USOS. • Nadal małe zaangażowanie w prace programistyczne większości członków MUCI • Duża zależność trwałości projektu od zaangażowania jednej osoby – kierownika projektu 40/58 Projekt strategii rozwoju systemu USOS • Ryzyko utrzymania niedostatecznego wsparcia technicznego systemu • Trudności w nawiązaniu współpracy z firmami komercyjnymi realizujących wsparcie systemu • Utrzymanie źle ocenianego przez studentów interfejsu systemu USOSweb • Powtarzające się problemy z wydajnością i obsługą modułu rekrutacyjnego • Powtarzające się co roku problemy z realizacją rejestracji żetonowej • Brak koncepcji rozwiązania problemów z systemem raportowania systemu • Większość kodu nadal pisana w języku polskim • Utrzymanie obecnej architektury utrudni umożliwienie lokalizacji systemu dla innych krajów Szanse • Gotowość do ponoszenia wyższych kosztów na system USOS przez uczelnie wykorzystana • Szybki rozwój funkcjonalny darmowych baz danych takich jak np. PostgreSQL pozwala na zmniejszenie kosztów wejścia w projekt przez nowe uczelnie, łatwiejsze włączanie się programistów do realizacji zadań, przeznaczenie większych środków na wynagrodzenia kluczowych projektantów niewykorzystana • Zweryfikowany na rynku model rozwoju w oparciu o Open Source pozwalający na czerpanie przychodów z subskrypcji, włączenie do współpracy firm komercyjnych, szybszą penetrację rynku - niewykorzystana • Możliwość zmiany architektury systemu na wielowarstwową, pozwalającą łatwiejsze włączanie się programistów do projektu, lepszą kontrolę jakości projektu, łatwiejszą integrację z innymi systemami oraz lokalizację - niewykorzystana • Możliwość bezpłatnego wykorzystania dojrzałych rozwiązań typu Open Source – np. eduSTORE (HIS) - niewykorzystana • Podniesienie jakości kodu systemu poprzez zastosowaniu modelu rozwoju opartego o Open Source – niewykorzystana • Gotowość środowiska europejskiego do nawiązania współpracy – niewykorzystana Zagrożenia • Ryzyko wejścia na rynek europejski systemów Fundacji Kuali • Możliwość zainteresowania firm komercyjnych rozwojem swojego biznesu przy wykorzystaniu systemów Fundacji Kuali • Ryzyko rozpowszechnienia się na rynku europejskim projektów innych uczelni europejskich (np. HIS). • Rozpowszechnienie się komercyjnych rozwiązań do obsługi toku studiów opracowywanych przez firmy takie jak SAP lub Microsoft, wraz ze wdrażaniem rozwiązań ERP na uczelniach • Uzyskanie dominującej pozycji na rynku rozwiązań typu Open Source takich jak PostgreSQL, Java, C# utrudniające uzasadnienie dalszego ponoszenia kosztów na rozwiązania komercyjne (np. Oracle) • Zmniejszające się zainteresowanie programistów posiadaniem kompetencji związanych z systemem Oracle Tabela 14 Analiza SWOT projektu „USOS 2” Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 41/58 Projekt strategii rozwoju systemu USOS Źródło: opracowanie własne Wariant II Projekt „NEW USOS” Aby zwiększyć wykorzystanie szans płynących z otoczenia aby przeciwdziałać zagrożeniom oraz aby osłabić słabe strony projektu w drugiej opcji strategicznej proponujemy: • • • • Utrzymanie wsparcia obecnego systemu lecz zminimalizowanie wprowadzania zmian do niego. Powołanie nowego zespołu, który byłby odpowiedzialny za równoległe tworzenie nowej architektury systemu. Architektura systemu powinna spełniać następujące założenia: o Wielowarstwowa z przeniesieniem logiki z bazy do serwera aplikacji zminimalizowanie kosztów wprowadzania zmian w przyszłości, zmniejszenie kosztów utrzymania systemu po stronie uczestniczących uczelni (brak konieczności szkolenia dużej ilości pracowników w zakresie zaawansowanego wykorzystania bazy Oracle), wykorzystanie doświadczeń Uniwersytetu Łódzkiego w projektowaniu aplikacji wielowarstwowych. o Oparta o rozwiązania Open Source lub niosące niskie szanse ich zamknięcia, takie jak np. Java lub C# - umożliwić jak największej grupie programistów włączenie się do prac projektowych. o Przed rozpoczęciem pisania elementów architektury należy się upewnić, że na rynku nie ma odpowiednio dojrzałego komponentu typu Open Source. o Kod tworzony i komentowany wyłącznie w języku angielskim – łatwiejsza współpraca międzynarodowa. o Gotowość do lokalizacji dla innych krajów – pozwalać na konkurowanie na rynku europejskim. o Umożliwić stosowanie innych baz niż Oracle – zmniejszenie kosztów utrzymania systemu po stronie uczestniczących uczelni, łatwiejsze pozyskiwanie nowych klientów (zminimalizowanie obaw o przyszłe koszty). o Pozwalać na łatwą integrację danych przy wykorzystaniu standardowych mechanizmów takich jak np. ESB. Zmiana organizacji MUCI • Zachować Radę MUCI, ale wprowadzić bardziej transparentne zasady jej działania (dokumentowanie i publikowanie posiedzeń). • Wprowadzenie zgromadzenia użytkowników USOS (zmiana funkcji Komisji USOS), którego działanie byłoby bardziej sformalizowanie, a w jego skład wchodziłyby osoby odpowiedzialne za wdrażanie systemu na uczelniach – kierownicy IT lub ich pełnomocnicy. • Ograniczyć ilość członków Dyrekcji MUCI oraz zapewnić, że nie będą oni członkami Rady MUCI. Naszym zdaniem Dyrekcja MUCI powinna składać się z osób posiadających operacyjne doświadczenie w zarządzaniu projektami informatycznymi. Jej sposób działania powinien być transparentny dla członków MUCI. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 42/58 Projekt strategii rozwoju systemu USOS • • Wprowadzenie roli Kierownika Programu, nadrzędnego dla Kierownika Projektu, który przejąłby koordynację następujących funkcji w projektach MUCI: o Planowanie finansowe o Harmonogramowanie o Marketing o Kontrola jakości kodu i dokumentacji o Współpraca międzynarodowa Kierownik Programu powinien wchodzić w skład Dyrekcji MUCI. Przy przejściu na nową architekturę wprowadzić następujące zmiany: o Zastosowanie licencji „Educational Community License” – otwarcie kodu, pozwolenie na bezpłatną instalację każdej instytucji edukacyjnej, pozwolenie na rozwój systemu w oparciu o model Open Source – ma pozwolić na szybszy rozwój systemu na polskim i europejskim rynku o Zmiana umów licencyjnych na subskrypcję wsparcia technicznego oraz prawo do uczestniczenia w zgromadzeniu użytkowników USOS – otwarcie na współpracę z komercyjnymi firmami realizującymi wsparcie techniczne. Analiza SWOT Silne strony • Utrzymanie obecnej funkcjonalności do czasu powstania nowej architektury • Szansa na utrzymanie wiodącej pozycji na rynku • Utrzymanie dużego zaufania do trwałości projektu ze strony uczestniczących uczelni • Wysoki prestiż członków Rady MUCI pozwalający na wypracowanie niezbędnego konsensusu w środowisku akademickim • Szansa na unowocześnienie interfejsu systemu USOS • Wielowarstwowa architektura zmniejszy koszty zmian w systemie • Przeniesienie logiki do serwera aplikacji pozwoli na uniezależnienie się od serwera bazy danych • Łatwiejszy udział nowych programistów w projekcie dzięki wielowarstwowej architekturze, wykorzystaniu środowisk Open Source, pisaniu kodu w języku angielskim • Możliwość wejścia na rynek europejski, dzięki gotowości do lokalizacji systemu • Włączenie doświadczeń innych uczelni (np. system rekrutacji UAM) Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski Słabe strony • Długi czas wypracowania nowej architektury i przeniesienia funkcjonalności (2-3 lata) • Wysoki koszt stworzenia nowej architektury • Ryzyko popełnienia błędów przy projektowaniu nowej architektury • Opór przed zmianą podstawowego interfejsu wykorzystywanego przez dziekanaty • Opór przed zmianą interfejsów Web i systemem raportowania 43/58 Projekt strategii rozwoju systemu USOS Szanse • Gotowość do ponoszenia wyższych kosztów na system USOS przez uczelnie wykorzystana • Szybki rozwój funkcjonalny darmowych baz danych takich jak np. PostgreSQL pozwala na zmniejszenie kosztów wejścia w projekt przez nowe uczelnie, łatwiejsze włączanie się programistów do realizacji zadań, przeznaczenie większych środków na wynagrodzenia kluczowych projektantów wykorzystana • Zweryfikowany na rynku model rozwoju w oparciu o Open Source pozwalający na czerpanie przychodów z subskrypcji, włączenie do współpracy firm komercyjnych, szybszą penetrację rynku - wykorzystana • Możliwość zmiany architektury systemu na wielowarstwową, pozwalającą łatwiejsze włączanie się programistów do projektu, lepszą kontrolę jakości projektu, łatwiejszą integrację z innymi systemami oraz lokalizację - wykorzystana • Możliwość bezpłatnego wykorzystania dojrzałych rozwiązań typu Open Source – np. eduSTORE (HIS) - niewykorzystana • Podniesienie jakości kodu systemu poprzez zastosowaniu modelu rozwoju opartego o Open Source – wykorzystana • Gotowość środowiska europejskiego do nawiązania współpracy – niewykorzystana Zagrożenia • Ryzyko wejścia na rynek europejski systemów Fundacji Kuali • Możliwość zainteresowania firm komercyjnych rozwojem swojego biznesu przy wykorzystaniu systemów Fundacji Kuali • Ryzyko rozpowszechnienia się na rynku europejskim projektów innych uczelni europejskich (np. HIS) – zmniejszone poprzez przygotowanie systemu USOS do konkurowania na rynku europejskim. • Rozpowszechnienie się komercyjnych rozwiązań do obsługi toku studiów opracowywanych przez firmy takie jak SAP lub Microsoft, wraz ze wdrażaniem rozwiązań ERP na uczelniach Tabela 15 Analiza SWOT projektu „NEW USOS” Źródło: opracowanie własne Wariant III Projekt „NINA” W trzeciej opcji strategicznej proponujemy większe wykorzystanie szans jakie płyną z istniejącego potencjału współpracy europejskiej przy tworzeniu systemów do zarządzania tokiem studiów oraz celów jakie sobie stawia Unia Europejska w zakresie utworzenia Europejskiego Obszaru Szkolnictwa Wyższego. Proponujemy nadać temu projektowi nazwę „NINA” w uznaniu wkładu pani dr Janiny MincerDaszkiewicz w dotychczasowy rozwój funkcjonalności systemu USOS oraz współpracę międzynarodową w tym zakresie. W ramach realizacji trzeciej opcji proponujemy: • Zainicjowanie przez Radę MUCI rozmów z Komisją Europejską ds. Szkolnictwa w celu powołania oficjalnego projektu „NINA” finansowanego przez Komisję, który powiązałby Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 44/58 Projekt strategii rozwoju systemu USOS • doświadczenia takich organizacji jak: MUCI, LADOK, HIS, CINECA dla stworzenia wspólnego systemu do zarządzania tokiem studiów. Zachowanie założeń architektonicznych i modelu biznesowego opisanego w Wariancie II Analiza SWOT Silne strony • Wzrost międzynarodowego prestiżu MUCI jako lidera w międzynarodowym projekcie • Utrzymanie obecnej funkcjonalności do czasu powstania nowej architektury • Utrzymanie dużego zaufania do trwałości projektu ze strony uczestniczących uczelni • Szansa na stworzenie nowoczesnego systemu wspierającego w pełni założenia Procesu Bolońskiego i przyspieszającego jego wdrożenie w skali Europy • Wielowarstwowa architektura zmniejszy koszty zmian w systemie • Przeniesienie logiki do serwera aplikacji pozwoli na uniezależnienie się od serwera bazy danych • Łatwiejszy udział nowych programistów w projekcie dzięki współpracy międzynarodowej, wielowarstwowej architekturze, wykorzystaniu środowisk i komponentów Open Source • Połączenie doświadczeń uczelni polskich i europejskich Słabe strony • Ryzyko opóźnienia związanego z koniecznością zyskania zgody Komisji UE dla stworzenia systemu oraz ryzyko niepowodzenia tego działania • Ryzyko opóźnienia związanego z koniecznością integracji środowiska międzynarodowego oraz ryzyko niepowodzenia tego działania • Długi czas wypracowania nowej architektury i przeniesienia funkcjonalności (2-3 lata) • Wysoki koszt stworzenia nowej architektury – zmniejszony poprzez większe wykorzystanie komponentów Open Source oraz doświadczenia międzynarodowego środowiska • Zmniejszone ryzyko popełnienia błędów przy projektowaniu nowej architektury – udział większej ilości doświadczonych projektantów • Opór przed zmianą dotychczasowych systemów Szanse • Gotowość do ponoszenia wyższych kosztów na system USOS przez uczelnie wykorzystana • Szybki rozwój funkcjonalny darmowych baz danych takich jak np. PostgreSQL pozwala na zmniejszenie kosztów wejścia w projekt przez nowe uczelnie, łatwiejsze włączanie się programistów do realizacji zadań, przeznaczenie większych środków na wynagrodzenia kluczowych projektantów wykorzystana • Zweryfikowany na rynku model rozwoju w oparciu o Open Source pozwalający na czerpanie przychodów z subskrypcji, włączenie do współpracy firm komercyjnych, szybszą penetrację rynku - wykorzystana • Możliwość zmiany architektury systemu na wielowarstwową, pozwalającą łatwiejsze Zagrożenia • Ryzyko wejścia na rynek europejski systemów Fundacji Kuali • Możliwość zainteresowania firm komercyjnych rozwojem swojego biznesu przy wykorzystaniu systemów Fundacji Kuali • Rozpowszechnienie się komercyjnych rozwiązań do obsługi toku studiów opracowywanych przez firmy takie jak SAP lub Microsoft, wraz ze wdrażaniem rozwiązań ERP na uczelniach – zminimalizowane poprzez rosnące znaczenie systemu NINA Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 45/58 Projekt strategii rozwoju systemu USOS włączanie się programistów do projektu, lepszą kontrolę jakości projektu, łatwiejszą integrację z innymi systemami oraz lokalizację - wykorzystana • Możliwość bezpłatnego wykorzystania dojrzałych rozwiązań typu Open Source – np. eduSTORE (HIS) - wykorzystana • Podniesienie jakości kodu systemu poprzez zastosowaniu modelu rozwoju opartego o Open Source – wykorzystana • Gotowość środowiska europejskiego do nawiązania współpracy – wykorzystana Tabela 16 Analiza SWOT projektu „NINA” Źródło: opracowanie własne Wariant IV Projekt „KUALI PL” W czwartej opcji strategicznej proponujemy przystąpienie MUCI do Fundacji Kuali oraz aktywne włączenie się do rozwoju ich systemów w zakresie: • • • Lokalizacji na polski rynek Rozwoju funkcjonalności, które posiada USOS a nie posiada system Kuali Student Rozwoju funkcjonalności w celu lepszego wspierania uwarunkowań prawnych właściwych dla Polski i Europy Analiza SWOT Silne strony Słabe strony • Szybka realizacja niezbędnej funkcjonalności • Opór przed zmianą dotychczasowych w oparciu o dojrzałą architekturę wspieraną systemów przez takich liderów jak MIT • Ryzyko dominacji na świecie jednego systemu • Niski koszt rozwoju systemu do zarządzania tokiem studiów • Wzrost międzynarodowego prestiżu MUCI jako uczestnika w dużym, międzynarodowym projekcie • Utrzymanie obecnej funkcjonalności do czasu powstania nowej architektury • Utrzymanie dużego zaufania do trwałości projektu ze strony uczestniczących uczelni • Wielowarstwowa architektura Kuali zmniejszy koszty zmian w systemie • Logika aplikacji Kuali znajduje się w warstwie serwera aplikacji co pozwala na dużą niezależność baz danych • Mniejszy koszt tworzenia systemu, dzięki koncentracji wyłącznie na realizowaniu funkcjonalności bez tworzenia od nowa architektury Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 46/58 Projekt strategii rozwoju systemu USOS • Włączenie doświadczenia polskich uczelni w międzynarodowy projekt Szanse Zagrożenia • Gotowość do ponoszenia wyższych kosztów • Rozpowszechnienie się komercyjnych na system USOS przez uczelnie rozwiązań do obsługi toku studiów wykorzystana opracowywanych przez firmy takie jak SAP lub Microsoft, wraz ze wdrażaniem rozwiązań ERP • Szybki rozwój funkcjonalny darmowych baz na uczelniach – zminimalizowane poprzez danych takich jak np. PostgreSQL pozwala na rosnące znaczenie systemów Kuali zmniejszenie kosztów wejścia w projekt przez nowe uczelnie, łatwiejsze włączanie się programistów do realizacji zadań, przeznaczenie większych środków na wynagrodzenia kluczowych projektantów wykorzystana • Zweryfikowany na rynku model rozwoju w oparciu o Open Source pozwalający na czerpanie przychodów z subskrypcji, włączenie do współpracy firm komercyjnych, szybszą penetrację rynku - wykorzystana • Możliwość zmiany architektury systemu na wielowarstwową, pozwalającą łatwiejsze włączanie się programistów do projektu, lepszą kontrolę jakości projektu, łatwiejszą integrację z innymi systemami oraz lokalizację - wykorzystana • Możliwość bezpłatnego wykorzystania dojrzałych rozwiązań typu Open Source – np. eduSTORE (HIS) - wykorzystana • Podniesienie jakości kodu systemu poprzez zastosowaniu modelu rozwoju opartego o Open Source – wykorzystana • Gotowość środowiska europejskiego do nawiązania współpracy – wykorzystana tylko pod warunkiem włączenia pozostałych uczelni europejskich do projektu Kuali Tabela 17 Analiza SWOT projektu „KUALI PL” Źródło: opracowanie własne Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 47/58 Projekt strategii rozwoju systemu USOS IV. Rekomendacje Zdaniem autorów niniejszego opracowania ostatnia opcja strategiczna, aczkolwiek pozwalająca na szybkie przejście na nową architekturę i rozwój funkcjonalności bardzo niskim kosztem, niesie ryzyko dominacji jednego systemu na świecie. W związku z powyższym naszym zdaniem należałoby: • • • • • wprowadzić zmiany w organizacji MUCI jak zaproponowano w Wariancie II; wypracować konsensus w środowisku co do zastosowania rozwiązań Open Source i przejścia na nowy model biznesowy; rozpocząć prace nowego zespołu, który dokonałby analizy dostępnych technologii stosowanych przez Kuali pod kątem wykorzystania ich w projekcie USOS oraz analizy procesów i przepływu danych w systemie USOS; równocześnie rozpocząć rozmowy z UE w celu powołania projektu „NINA” i integracji europejskich uczelni wokół tego projektu; wprowadzić założenia czasowe dla realizacji powyższej aktywności a w razie jej niepowodzenia włączyć się do Fundacji Kuali. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 48/58 Projekt strategii rozwoju systemu USOS V. O autorach Dorota Nicewicz-Modrzewska Absolwentka Uniwersytetu im. Adama Mickiewicza - Wydział Matematyki i Informatyki, specjalność metody numeryczne i programowanie. Absolwentka studiów Executive MBA z Nottingham Trent University. Związana z UAM od 1993 kiedy rozpoczęła pracę jako administrator systemów UNIX. Jako jedna z pierwszych osób w Polsce a pierwsza w Poznaniu stworzyła wdrożyła serwery takich usług internetowych jak: USENET, GOPHER i WWW. Zasiadała w zarządzie trzech spółek prawa handlowego zajmujących się m.in. usługami internetowymi. Zdobyła doświadczenie w pracy z systemem SAP oraz koordynacji umów SLA pracując jako IT Service Manager w firmie The Lorenz Bahlsen Snack World. W 2005 roku została członkiem „Klubu kreatywnych LSW”. Doświadczenie w zarządzaniu usługami IT zgodnie z metodologią ITIL, a także w wykorzystywaniu rozwiązań BI zdobyła pracując w dwóch projektach realizowanych w Londynie dla międzynarodowej spółki Capgemini. Prowadziła własną działalność gospodarczą w zakresie tworzenia oprogramowania, głównie w języku Java w obszarze zarządzania i publikacji danych kartograficznych. W 2007 rou wyjście z tej inwestycji zostało wykonane z sukcesem poprzez sprzedaż praw autorskich giełdowej spółce IT. Od września 2007 roku piastuje funkcję zastępcy dyrektora Centrum Zarządzania Infrastrukturą i Projektami Informatycznymi UAM. W latach 2007-2009 doprowadziła do zakończenia prowadzonego przez wiele lat wdrożenia systemu ERP (MS Dynamix AX) na uczelni. Rozpoczęła wdrażanie metodologii ITIL w celu podniesienie jakości obsługi IT. Została powołana do zespołu ds. opracowania strategii uczelni i w trakcie jego prac zdefiniowała wiele przyjętych przez zespół celów w zakresie zarządzania uczelnią. W 2009 roku uzyskała nagrodę specjalną rektora za szczególny wkład w rozwój uczelni. Brała udział jako prelegent w następujących konferencjach: 2010 – VI Konferencja „Integracja systemów informatycznych”, Warszawa, Dorota NicewiczModrzewska, “ Specyfika integracji systemów informatycznych na przykładzie uczelni wyższej” 2008 – EUNIS 2008, Arhus, Dorota Nicewicz-Modrzewska, Przemysław Stolarski, „ITIL implementation roadmap based on process governance” Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 49/58 Projekt strategii rozwoju systemu USOS 2000 – IV Konferencja „Miasta w Internecie”, Tarnów, Dorota Nicewicz-Modrzewska, „Interaktywna Mapa” 1997 – I Konferencja „Miasta w Internecie”, Tarnów, Dorota Nicewicz-Modrzewska, Andrzej Mikosz, “Interaktywny Poznań” dr inż. Ścibór Sobieski Absolwent Politechniki Łódzkiej – Wydział Fizyki Technicznej i Matematyki Stosowanej, kierunek matematyka stosowana. Dyrektor Centrum Informatyki Uniwersytetu Łódzkiego, adiunkt na Wydziale Fizyki i Informatyki Stosowanej. Posiada szeroką wiedzę w zakresie informatyki, utrwaloną bogatym, 20-to letnim doświadczeniem zawodowym. W latach 1994-1998 programista w spółce z kapitałem zagranicznym. Od 1998 związany ze światem akademickim, początkowo asystent na Politechnice Łódzkiej, a następnie na Uniwersytecie Łódzkim, gdzie działalność naukowa zwieńczona została obroną pracy doktorskiej w 2002 roku. W latach 1998-2004 właściciel firmy wdrażającej rozwiązania informatyczne dla firm. Od 1998 roku nieprzerwanie pracuje jako niezależny konsultant. W latach 2003-2008 kierownik Grupy Programistycznej RPG działającej na UŁ, tworzącej systemy informatyczne na potrzeby uczelni. Grupa ta pod kierownictwem dr Sobieskiego stworzyła i do tej pory utrzymuje systemy: Kadry, Płace, BHP, Rozliczenia, Umowy, KIOD i wiele mniejszych. W 2008 objął stanowisko Dyrektora Centrum Informatyki UŁ, które powstało jako wynik połączenia niezależnych jednostek związanych z utrzymaniem IT na UŁ. Obecnie Centrum Informatyki liczy prawie 40 osób. Współautor książek z informatyki oraz podręcznika akademickiego. Autor i współautor licznych publikacji naukowych z dziedziny zastosowań informatyki, w szczególności tworzenia i zarządzania złożonymi projektami informatycznymi. Brał udział w licznych konferencjach naukowych oraz popularno naukowych, gdzie referował lub publikowała wiele artykułów. Poniżej wymieniono niektóre – dotyczące tematów pokrewnych do tematyki niniejszego opracowania: J. Kalinowski, Ś. Sobieski, Od systemu informatycznego do systemu informacyjnego, czyli o ewolucji świadomości na przykładzie doświadczeń Uniwersytetu Łódzkiego w latach 2002-2009, Komputerowo Zintegrowane Zarządzanie, ed. R. Knosala, Vol. I, ISBN: 978-83-923797-9-9, Oficyna Wydawnicza PTZP, Opole 2010, pp. 614-621. Ś. Sobieski, P. Zajączkowski, The Concept of Internet System Supporting Process of Making Decision of Study Profile Choice by Candidates Based on Fuzzy Logic, Proceedings of the IADIS International Conference WWW/Internet 2009 Vol. II, ISBN: 978-972-8924-93-5, Rome (2009), pp. 215-219. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 50/58 Projekt strategii rozwoju systemu USOS P. Słowik, Ś. Sobieski, System antyplagiatowy w nauczaniu informatyki, Technologie i systemy komunikacji oraz zarządzania informacją i wiedzą, red. L. Kiełtyka, Difin (2008), pp. 342-348. A. Nowakowski, Ś. Sobieski, Evolution of Information Systems at the University of Lodz during 2002 – 2007 - the Report of Achievements and Failures, Proceedings of Eunis 2007, Conference 2629.06.2007, University of Grenoble. K. Miodek, Ś. Sobieski, Architektura i bezpieczeństwo systemu elektronicznej rekrutacji kandydatów na studia, Nowe Technologie Sieci Komputerowych, tom 2, Wydawnictwa Komunikacji i Łączności, Warszawa, 2006, pp. 483-489. P. Puścian, Ś. Sobieski, Udział w rzeczywistym projekcie informatycznym jako forma praktyk studenckich oraz doskonalenia pracowników, Kształcenie zawodowe w teorii i praktyce edukacyjnej, Wydawnictwo Wyższej Szkoły Bezpieczeństwa, Poznań, 2006, pp. 356-360. P. Puścian, Ś. Sobieski, Zarządzanie ryzykiem w projekcie informatycznym - studium przypadku, Materiały Ogólnopolskiej Konferencji Naukowej „Ryzyko Przedsięwzięć Informatycznych", Politechnika Szczecińska, Wydział Informatyki, 2006, pp. 143-153. R. Pszonczenko, Ś. Sobieski, Design and implementation of the middle-class web-portal for cooperation with students team, Annales UMCS - Informatica, Vol. V, Lublin 2006, pp. 427-434. Ś. Sobieski, Ewolucja systemu rekrutacji na Uniwersytecie Łódzkim w latach 2003 – 2005, Aplikacje technik multimedialnych w organizacjach gospodarczych, wydawnictwa zwarte Wyższej Szkoły Ekonomii i Administracjii w Kielcach, 2006, pp. 77-81. Ś. Sobieski, Organizacja pracy w pracowniczo-studenckim zespole projektowym - studium przypadku, Nowoczesne technologie informacyjne w zarządzaniu, red. E. Niedzielska, H. Dudycz, M. Dyczkowski, Wydawnictwo Akademii Ekonomicznej, Wrocław (2006), pp. 265-271. Ś. Sobieski, Ryzyko realizacji projektów informatycznych w oparciu o zespół pracowniczo-studencki studium przypadku, Materiały Ogólnopolskiej Konferencji Naukowej „Ryzyko Przedsięwzięć Informatycznych", Politechnika Szczecińska, Wydział Informatyki, 2006, pp. 181-187. A. Nowakowski, Ś. Sobieski, Integrated Information System for University of Łodź, Proceedings of Eunis 2005 Conference 20-24.07.2005, University of Manchester. Ś. Sobieski, K. Miodek, Możliwości i ryzyko wykorzystania oprogramowania opensource w zastosowaniach komercyjnych, Ogólnopolska Konferencja naukowa Ryzyko Przedsięwzięć Informatycznych 2005, Szczecin, 20-21.10.2005, pp. 93-100. Ś. Sobieski, Koncepcja systemu informatycznego wspomagającego pracę państwowej uczelni wyższej oraz omówienie wybranych modułów, Bazy danych: modele, technologie, narzędzia. Analiza danych i wybrane zastosowania Tom II, Wydawnictwo Komunikacji i Łączności, Warszawa 2005, pp. 273-279. Ś. Sobieski, Wspomaganie procesu zarządzania wiedzą w projekcie informatycznym za pomocą mechanizmów Wiki, Multimedia w biznesie i edukacji Tom II, Fundacja Współczesne Zarządzanie, Białystok 2005, pp. 53-59. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 51/58 Projekt strategii rozwoju systemu USOS Ś. Sobieski, Elektroniczna rekrutacja na studia wyższe, Internet 2005 Tom I, Oficyna Wydawnicza Politechniki Wrocławskiej, Wrocław 2005, pp. 261-271. A. Nowakowski, Ś. Sobieski, K. Zyskowska, Wdrożenie średniej wielkości projektu na uczelni państwowej a wdrożenie typowe, Inżynieria oprogramowania. Nowe wyzwania, Rozdział XV, Wydawnictwo Naukowo-Techniczne 2004, pp. 199-212. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 52/58 Projekt strategii rozwoju systemu USOS VI. Dodatki Dodatek 1. Lista członków Fundacji Kuali 28.09.2010 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Australian National University Boston University Bradley University Brock University Brown University California State University - Office of the Chancellor Carnegie Mellon University Colorado State University Cornell University Duke University Indiana University Indiana University Foundation Iowa State University Lehigh University Marist College Massachusetts Institute of Technology Michigan State University NACUBO Naval Postgraduate School North Carolina State University North West University - South Africa Pennsylvania State University Research Foundation of the City of New York Dodatek 2. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. San Joaquin Delta College The University of Arizona Triangle Research Libraries Network Tufts University Tulane University University of British Columbia University of California- President's Office University of California-Berkeley University of California-Davis University of California-Irvine University of California-Santa Barbara University of California-San Diego University of Chicago University of Connecticut University of Florida University of Hawaii University of Illinois University of Maryland University of Pennsylvania University of Southern California University of Toronto University of Virginia University of Washington West Virginia University The Open Source Definition Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: 1. Free Redistribution Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 53/58 Projekt strategii rozwoju systemu USOS The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. 7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. 9. License Must Not Restrict Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. 10. License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface. Spis rysunków Rysunek 1. Zakres stosowania oprogramowania OpenSource na UAM ................................................ 8 Rysunek 2 Poziom wzrostu światowych przychodów z oprogramowania liczony rok do roku w latach 2006-2013 ............................................................................................................................................... 9 Rysunek 3. Struktura organizacyjna Kuali ............................................................................................. 13 Rysunek 4. Ilość odwiedzających stronę kuali.org według lokalizacji, od 1 do 4 lutego 2010 .............. 14 Rysunek 5. Postęp w rozwoju projektu ................................................................................................. 17 Rysunek 6. Uczelnie wdrażające USOS według rodzaju ........................................................................ 17 Rysunek 7 Relatywny trend rozwoju rynku specjalistów związanych z bazami danych ....................... 18 Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 54/58 Projekt strategii rozwoju systemu USOS Rysunek 8 Liczba ofert pracy dla specjalistów związanych z bazami danych........................................ 19 Rysunek 9 Relatywny trend rozwoju rynku specjalistów związanych z językami programowania....... 19 Rysunek 10 Liczba ofert pracy dla specjalistów związanych z językami programowania ..................... 20 Rysunek 11 Współpraca systemów informatycznych uczelni z Systemem Zarządzania Studiami........ 29 Rysunek 12 Motywacja oparta o kij i marchewkę ................................................................................. 31 Rysunek 13 Piramida technologiczna - wpływ Open Source na rozwój metod programowania.......... 32 Spis tabel Tabela 1 Średni czas awarii (w godzinach w miesiącu) dla poszczególnych typów serwerów http...... 11 Tabela 2 Analiza czasu rozwiązania problemów z bezpieczeństwem systemów .................................. 11 Tabela 3 Wysokość rocznej składki w Fundacji Kuali ............................................................................ 14 Tabela 4 Liczba ofert pracy w serwisie pracuj.pl w dniu 29.09.2010 .................................................... 20 Tabela 5 Liczba osób zarejestrowanych w portalach społecznościowych, które zawarły w opisie swojego stanowiska lub kompetencji poszukiwany ciąg znaków w dniu 29.09.2010 .......................... 20 Tabela 6 Ranking baz danych według danych porównawczych w Wikipedia ....................................... 24 Tabela 7 Funkcjonalność baz danych - porównanie na podstawie danych w Wikipedia ...................... 25 Tabela 8 Testy wydajności baz MySQL i PostgreSQL dla 2 mln wierszy ................................................ 25 Tabela 9 Testy wydajności baz danych MySQL i PostgresSQL dla 0.6 mln wierszy ............................... 26 Tabela 10 Porównanie kosztów licencji baz danych ............................................................................. 26 Tabela 11 Koszt wprowadzania zmian w systemach Mozilla i Linux ..................................................... 30 Tabela 12 Koszt koordynacji zmian w systemach Mozilla i Linux.......................................................... 30 Tabela 13 Analiza SWOT projektu „USOS” ............................................................................................ 39 Tabela 14 Analiza SWOT projektu „USOS 2” ......................................................................................... 41 Tabela 15 Analiza SWOT projektu „NEW USOS” ................................................................................... 44 Tabela 16 Analiza SWOT projektu „NINA” ............................................................................................ 46 Tabela 17 Analiza SWOT projektu „KUALI PL”....................................................................................... 47 Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 55/58 Projekt strategii rozwoju systemu USOS Bibliografia 1. The Bologna Declaration of 19 June 1999. Bolonia Web Site. [Online] 1999. http://www.bolognabergen2005.no/Docs/00-Main_doc/990719BOLOGNA_DECLARATION.PDF. 2. The Bologna Process - Towards the European Higher Education Area. European Commission Education & Training. [Online] 11 marca 2010. http://ec.europa.eu/education/highereducation/doc1290_en.htm. 3. Brown, Eric. As open source surges, Microsoft admits Linux threat. Linux-Watch. [Online] sierpień 2009. http://www.linux-watch.com/news/NS3927699066.html. 4. Gates, Bill. An Open Letter to Hobbyists. Hembrew Computer Club Newsletter. 31 stycznia 1976, Tom 2, 1. 5. Microsoft. U.S. Securities and Exchange Commission. FORM 10-K MICROSOFT CORPORATION. [Online] 2009. http://www.sec.gov/Archives/edgar/data/789019/000119312509158735/d10k.htm. 6. Wheeler, David A. Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! David A. Wheeler’s Personal Home Page. [Online] kwiecień 2007. http://www.dwheeler.com/oss_fs_why.html. 7. Vaughan-Nichols, Steven J. Red Hat: The 1st billion-dollar open-source company? Computerworld. [Online] 10 września 2010. http://blogs.computerworld.com/17014/red_hat_the_1st_billion_dollar_open_source_company. 8. Kuali Foundation. [Online] http://kuali.org/. 9. Czerniak, Mariusz. Stan wdrożenia systemu USOS Wyniki ankiety 2010. Uniwersytecki System Obsługi Studiów. [Online] http://usos.edu.pl/Ankiety/USOS_Stan_wdrozenia_2010.pdf. 10. Indeed. [Online] http://www.indeed.com/. 11. Comparison of relational database management systems. Wikipedia. [Online] 2010. http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems. 12. Kamiński, Mateusz. Porównanie wydajności baz danych (MySQL, PostgreSQL). matipl. [Online] http://matipl.pl/2009/01/07/porownanie-wydajnosci-baz-danych-mysql-postgresql/. 13. Babcock, Charles. Open Source PostgreSQL Trails Oracle In Benchmark, But Not By Much. InformationWeek. [Online] http://www.informationweek.com/news/software/linux/showArticle.jhtml?articleID=201001901. 14. SQL Server Articles Comparison. MS http://www.mssqlcity.com/Articles/Compare/Compare.htm. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski SQL City. [Online] 2010. 56/58 Projekt strategii rozwoju systemu USOS 15. Golański, Adam. Przyszłość bazy MySQL: biznesowy styl i daleko posunięta integracja z Windows. Webhosting.pl. [Online] 24 września 2010. http://webhosting.pl/Przyszlosc.bazy.MySQL.biznesowy.styl.i.daleko.posunieta.integracja.z.Windows . 16. Paulsen, Morten Flate. Online Education Systems:Discussion and Definition of Terms. Universidade Catolica Portuguesa Centro Regional do Porto. [Online] lipiec 2002. http://www.porto.ucp.pt/open/curso/modulos/doc/Definition%20of%20Terms.pdf. 17. Alan MacCormack, John Rusnak, Carliss Baldwin. Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. free/opensource reasearch community. [Online] 2004. http://opensource.mit.edu/papers/maccormackrusnakbaldwin.pdf. 18. Margit Osterloh, Sandra Rota, Marc von Wartburg. Open source – new rules in software development. University of Zurich, Institute of Organization and Administrative Science (IOU). [Online] http://www.iou.uzh.ch/orga/downloads/OpenSourceAoM.pdf. 19. Pink, Daniel. Drive: The whole truth about what motivates us. Riverhead. grudzień 2009. 20. Kimberly Ling, Gerard Beenen, Pamela Ludford, Xiaoqing Wang, Klarissa Chang, Xin Li, Dan Cosley, Dan Frankowski, Loren Terveen, Al Mamunur Rashid, Paul Resnick, Robert Kraut. Using Social Psychology to Motivate Contributions to Online Communities. CiteSeerX - Scientific Literature Digital Library and Search Engine. [Online] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.59.2999&rep=rep1&type=pdf. 21. Earnings Press Releases. Oracle. [Online] 16 lipca http://www.oracle.com/us/corporate/investor-relations/financials/q1fy10-080073.pdf. 2009. 22. Meisner, Jeff. Open Source, the Recession and the Lower-TCO Promise. LinuxInsider. [Online] 27 września 2009. http://www.linuxinsider.com/story/Open-Source-the-Recession-and-the-Lower-TCOPromise-66323.html. 23. Open-source software in the recession. The Economist. [Online] 28 maja 2009. http://www.economist.com/node/13743278. 24. Orion, Egan. Open source will gain during recession. The Inquirer. [Online] 21 października 2008. http://www.theinquirer.net/inquirer/news/1036390/open-source-gain-during#. 25. Recession Worries? Open Source Software Is a Great Way to Cut Costs. CIO. [Online] 14 października 2008. http://www.cio.com/article/print/454766. 26. OpenSource alternative for almost Everything. Recession Friendly alternatives. TaranFX. [Online] 3 lipca 2009. http://www.taranfx.com/opensource-alternative-for-almost-everything-recessionfriendly-alternatives. 27. The Benefits of the Recession for Open Source. Bright Hub. [Online] 14 września 2010. http://www.brighthub.com/computing/linux/articles/86986.aspx. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 57/58 Projekt strategii rozwoju systemu USOS 28. Recession fears will boost open source business solution adoption. Optaros. [Online] 15 października 2008. http://www.optaros.com/blogs/recession-fears-will-boost-open-source-businesssolution-adoption. 29. Patel, Nilay. Google calls Oracle Android lawsuit 'baseless,' says Java goes 'beyond any one corporation'. Engaget. [Online] 13 sierpnia 2010. http://www.engadget.com/2010/08/13/googlecalls-oracle-android-lawsuit-baseless-says-java-goes/. 30. Claire Carradice. High-trust Companies Equal High-profit Companies. An Oracle Business Intelligence and Performance Management Publication. 6, maj 2009. 31. Międzyuniwersyteckie Centrum Informatyzacji. muci.amu.edu.pl. [Online] 32. Mincer-Daszkiewicz, Janina. Zintegrowany system dla uczelni wyższych. USOS. [Online] http://usos.edu.pl/Artykuly/KonferencjaOracle2009-04-01.pdf. 33. Studenckie zmagania z dziełem szatana. Polskie Radio. [Online] http://www.polskieradio.pl/5/115/Artykul/266110,Studenckie-zmagania-z-dzielem-szatana. 34. Bologna Process - all set for the next decade. European Commission Education & Training. [Online] 4 maja 2009. http://ec.europa.eu/education/news/news1357_en.htm. 35. Przyszłość Javy niejasna. Drogi Oracle'a i społeczności rozejdą się? Webhosting.pl. [Online] http://webhosting.pl/Przyszlosc.Javy.niejasna.Drogi.Oraclea.i.spolecznosci.rozejda.sie?page=1. Autorzy: Dorota Nicewicz-Modrzewska, Ścibór Sobieski 58/58