Projekt strategii rozwoju systemu USOS

Transkrypt

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Ł
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
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
3/58
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.
4/58
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.
5/58
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ą.
6/58
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.
7/58
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ć
8/58
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
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
Inne
8.72
10/58
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.
11/58
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.
12/58
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
Wysokość składki
rocznej (USD)
24,500
14,500
9,500
4,500
14,500
13/58
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)
14/58
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.
15/58
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.
16/58
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.
17/58
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ę.
18/58
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.
19/58
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
20/58
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
21/58
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.
22/58
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
23/58
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.
24/58
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
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)
ms)
ms)
1 rows fetched (828 ms)
1 rows fetched (1,016 sec)
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
MySQL
1 rows fetched (265
PostgreSQL
25/58
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
SELECT
id
FROM
stringi
WHERE
NIE
TAK
ms)
ms)
55 rows fetched (47
ms)
1 rows fetched (265
ms)
1 rows fetched (359
ms)
ms)
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ń.
26/58
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
27/58
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.
28/58
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
29/58
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.
30/58
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
31/58
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
32/58
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
33/58
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.
34/58
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
35/58
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
36/58
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ń.
37/58
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
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
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”
39/58
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
• 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
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
• 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
na system USOS przez uczelnie wykorzystana
programistów
do
realizacji
zadań,
wynagrodzenia kluczowych projektantów niewykorzystana
czerpanie
przychodów
z
subskrypcji,
szybszą penetrację rynku - niewykorzystana
- niewykorzystana
• Możliwość
bezpłatnego
wykorzystania
eduSTORE (HIS) - niewykorzystana
Open Source – niewykorzystana
nawiązania współpracy – niewykorzystana
Zagrożenia
Fundacji Kuali
europejskich (np. HIS).
się
komercyjnych
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”
41/58
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.
42/58
•
•
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
• 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)
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
Szanse
programistów
do
realizacji
zadań,
wynagrodzenia kluczowych projektantów wykorzystana
czerpanie
przychodów
z
subskrypcji,
szybszą penetrację rynku - wykorzystana
- wykorzystana
• Możliwość
bezpłatnego
wykorzystania
eduSTORE (HIS) - niewykorzystana
Open Source – wykorzystana
nawiązania współpracy – niewykorzystana
Zagrożenia
Fundacji Kuali
europejskich (np. HIS) – zmniejszone poprzez
przygotowanie
systemu
USOS
do
konkurowania na rynku europejskim.
się
komercyjnych
na uczelniach
Tabela 15 Analiza SWOT projektu „NEW USOS”
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
44/58
•
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
• 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
• 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
programistów
do
realizacji
zadań,
czerpanie
przychodów
z
subskrypcji,
Zagrożenia
Fundacji Kuali
się
komercyjnych
na uczelniach – zminimalizowane poprzez
rosnące znaczenie systemu NINA
45/58
- wykorzystana
• Możliwość
bezpłatnego
wykorzystania
eduSTORE (HIS) - wykorzystana
nawiązania współpracy – wykorzystana
Tabela 16 Analiza SWOT projektu „NINA”
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
• Wielowarstwowa architektura Kuali zmniejszy
• 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
46/58
• 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
na uczelniach – zminimalizowane poprzez
rosnące znaczenie systemów Kuali
programistów
do
realizacji
zadań,
czerpanie
przychodów
z
subskrypcji,
- wykorzystana
• Możliwość
bezpłatnego
wykorzystania
eduSTORE (HIS) - wykorzystana
nawiązania współpracy – wykorzystana tylko
pod warunkiem włączenia pozostałych
uczelni europejskich do projektu Kuali
Tabela 17 Analiza SWOT projektu „KUALI PL”
47/58
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.
48/58
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”
49/58
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.
50/58
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.
51/58
Ś. 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.
52/58
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
53/58
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
54/58
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
55/58
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.
SQL
City.
[Online]
2010.
56/58
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.
57/58
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.
58/58

Projekt strategii rozwoju systemu USOS

Transkrypt

Podobne dokumenty