Witold Rakoczy

Pisząc poprzednie odcinki starałem się powstrzymać od przedstawiania alternatywnych rozwiązań, usuwających obecne wady i niedostatki systemu D.XP. Wychodziłem z założenia, że podstawowym moim zadaniem jest skatalogowanie błędów i usterek (wszystko jedno – implementacyjnych, projektowych, czy koncepcyjnych) i pozostawienie ich naprawy inwencji pracowników producenta.
Ten odcinek jest inny, ponieważ oprócz analizy wady projektowej przedstawiam zarys odmiennej koncepcji realizacyjnej istotnego mechanizmu systemu. Wada ta została zasygnalizowana w  Poletku hackerów, poniżej zaś przedstawiam szerzej jej konsekwencje i – jako przeciwstawienie – szkic alternatywnego rozwiązania, “załatwiającego” przy okazji kilka pomniejszych kłopotów. Rzecz dotyczy sprawy ważnej, bo mechanizmu kontroli uprawnień osób wpisujących oceny.

Jednym z najistotniejszych mechanizmów kontroli dostępu jest ograniczanie możliwości wpisywania studentom ocen końcowych z zajęć. W systemie D.XP prowadzi to z jednej strony do wprowadzenia danych do bazy danych, z drugiej zaś do przygotowania protokołów, które następnie są podpisywane i stanowią dokument referencyjny (tj. ważny z punktu widzenia prawa, jako że D.XP nie używa technologii podpisu cyfrowego i w związku z tym nie zapewnia prawnie rozstrzygającego zapisu danych). Protokoły są sporządzane w taki sposób, że administracyjny podział studentów na lata i grupy dziekanatowe są traktowane odrębnie, a podział ten jest podstawą grupowania studentów również wewnątrz systemu. Jest to dokładna kopia sposobu tradycyjnego, stosowanego przez administracje wydziałów od wieków…

Ktoś zapyta: Po co w systemie listy studentów z podziałem na grupy dziekanatowe, jeśli na danym kierunku studenci dzielą się do uczestnictwa w zajęciach inaczej? Ha! Ja też się zastanawiałem i początkowo doszedłem do wniosku, że jest to skutek “mentalności administracyjnej”, powszechnie występującej – zgodnie z prawem Parkinsona – w administracji instytucji o dostatecznie długiej historii funkcjonowania: skoro tak było zawsze, to i w Systemie być musi… Ale sprawa ma głębsze podłoże.

Problemem podstawowym jest sprawa uprawnień, a dokładnie kontroli uprawnień. Idzie o to, że oceny z określonych zajęć w odniesieniu do określonych studentów powinni móc wystawiać (zatem i wpisywać do systemu) tylko upoważnieni dydaktycy, a wśród nich na pewno ten prowadzący zajęcia, w którego grupie student zajęcia odbywa.

Oczywiście logika dyktuje tutaj pewne proste rozszerzenie, w praktyce stosowane od zawsze, polegające na przydzieleniu ponadto: uprawnień do wpisywania zaliczeń zajęć z danego przedmiotu – dydaktykowi odpowiedzialnemu za ten przedmiot (zwykle jest to wykładowca); uprawnień do wpisywania wszelkich zaliczeń, egzaminów i ocen końcowych z przedmiotów prowadzonych przez daną katedrę przez kierownika tej katedry; rzecz jasna prawo do wpisywania wszelkich w ogóle ocen ma dziekan.

Niestety, aby spełnić powyższe postulaty (a właściwie pierwszy z nich – całkowicie oczywisty – bo jeśli on jest spełniony, to i pozostałe można łatwo wypełnić) trzeba stworzyć i zaimplementować adekwatny model kontroli dostępu zależnej od danych. Innymi słowy, wpis oceny z określonego przedmiotu jest dopuszczony, jeśli realizuje go prowadzący zajęcia danego studenta, odpowiedzialny za przedmiot, kierownik jednostki (w której zatrudniony jest odpowiedzialny za przedmiot) lub dziekan. Najprostszy sposób zapewnienia możliwości sprawdzenia tego warunku jest przypisanie studentowi do jego wpisu “zaliczenia z danych zajęć” (a więc pary przedmiot i rodzaj zajęć)  informacji o prowadzącym zajęcia. Informacja o odpowiedzialnym za przedmiot jest wspólna dla wszystkich studentów i może być pamiętana jako atrybut przedmiotu (chyba, że jest więcej niż jedna grupa wykładowa  – wtedy wykład z przedmiotu występuje dwukrotnie z różnymi wykładowcami). Sprawdzanie uprawnień kierownika katedry i dziekana łatwiej rozwiązać inaczej, zatem tę sprawę zostawimy na boku.

W systemie Dziekanat.XP połaczenie pomiędzy wpisem zaliczenia danego studenta a osobą uprawnioną do wprowadzenia tego zapisu zrealizowano metodą “od siekiery”, kopiując z administracyjnego “realu” tradycyjny model grupy dziekanatowej, która ma zwykle dla określonego przedmiotu jednego, wspólnego prowadzącego. W większości przedmiotów jest to zapewne wygodne i pokrywa się z praktyką. Pozornie jedynym kłopotem jest przenoszenie się studentów z grupy do grupy na pojedyncze zajęcia, które – choć niechętnie traktowane – czasem jednak się zdarza (wtedy prowadzący wpisują pojedyncze zaliczenia na “nie swoich” protokołach).

Jednak dla sporej części zajęć, w prowadzeniu których grupy dziekanatowe nie są stosowane (laboratoria, projekty, zajęcia praktyczne, projekty inżynierskie, seminaria dyplomowe itp.), model ten ma podstawową wadę: trzeba tworzyć fikcyjne “grupy specjalne”, łączące w jedno wszystkich studentów, związanych przez wspólnego prowadzącego dane zajęcia. Takiej grupie przypisuje sie prowadzącego – i już! Ktoś nie wiedział, co to jest “Grupa spec PInż01″ ? Teraz już wie…

Jasną jest sprawą, że taki sposób prowadzi do absurdu, bo jeżeli jakieś dwie grupy zajęciowe, powiedzmy A i B, mają  prowadzących odpowiednio Abackiego i Babackiego, zaś grupa C – obu wymienionych, to trzeba utworzyć trzy “grupy specjalne”: po jednej dla Abackiego i Babackiego oddzielnie i jedną dla nich razem wziętych (=uprawnionych).  Dlatego w praktyce (na przykład na Informatyce stacjonarnej, gdzie jest mnóstwo zajęć prowadzonych w małych grupach przez wielu dydaktyków) nie tworzy się w ogóle indywidualnych grup, tylko dla wszystkich studentów całego roku uprawnienia do wpisów nadaje się wszystkim prowadzącym – rezygnując tym samym z jakiejkolwiek kontroli uprawnień!

Dzięki błędowi koncepcyjnemu (lub projektowemu, zależnie od tego jak bardzo bezkompromisowi jesteśmy w naszej krytyce autorów systemu D.XP) mamy zatem albo zupełny brak kontroli (teoretycznie wygodny, ale ryzykowny), albo kontrolę bardzo kosztowną, bo wymagającą ogromnego nakładu pracy (pewnie urzędników dziekanatu), i ryzykowną, bo tworząc fikcyjne grupy nietrudno popełnić pomyłkę. Gdyby zastosować zaproponowany wcześniej model, sprawa byłaby o wiele prostsza.
Po pierwsze, podział na “grupy dziekanatowe” w systemie nie byłby potrzebny wcale, choć możliwy do zrealizowania poprzez przypisywanie poszczególnym prowadzącym wszystkich studentów, należących do określonych “papierowych grup dziekanatowych”.
Po drugie, sposób dzielenia studentów przez prowadzących na grupy zajęciowe byłby ich wyłączną sprawą (dla ułatwienia tego system mógłby udostępniać zainteresowanym prowadzącym odrębny sposób dzielenia studentów na zespoły; ten temat wymaga jednak dłuższych rozważań, więc tu go nie rozwiniemy), zaś wpisywanie ocen z zajęć nie wymagałoby odszukiwania studentów w obrębie grup dziekanatowych, tylko wśród wszystkich studentów danego prowadzącego co paradoksalnie może być łatwiejsze i szybsze (wspominam o trudnościach wywołanych rozmieszczeniem studentów jednego prowadzącego pomiędzy kilka grup w D.XP w innym miejscu). [Co więcej swoboda podziału pozwoliłaby na wdrożenie w Uczelni modelu swobodnych zapisów, znanego z uniwersytetów zachodnich.]
Po trzecie wreszcie, gdyby zachowano zasadę drukowania protokołu papierowego i podpisywania każdej z ocen z osobna (taka praktyka ma sens, gdy w ramach jednej listy oceny są wystawione przez różnych prowadzących), wydruk nazwiska prowadzącego w rubryce oceny, ułatwiający złożenie podpisu we właściwej linijce, byłby banalnie prosty, podczas gdy w tej chwili może przerastać mozliwości twórców systemu. Dodam, że przy okazji odpowiedzialny za przedmiot mógłby dostawać zestawienie wszystkich ocen wszystkich studentów z możliwością filtrowania również po prowadzących zajęcia składające się na przedmiot (oddzielnie każdy rodzaj zajęć – ćwiczenia, laboratorium, projekt) – czyli coś, co teraz jest prawie nie do zrealizowania.

I pomysleć, że aby zauważyć opisaną, alternatywną metodę przyznawania uprawnień wystarczyło poruszać chwilę głową (dostatecznie wcześnie…) i spostrzec słabość opisu uprawnień dydaktyków ograniczonego do najprostszego widoku – przez pryzmat grup dziekanatowych…

W tym odcinku zajmiemy się usilną działalnością twórców systemu D.XP na polu udostępniania czarnym kapeluszom, jak zwykło określać się “hackerów złych” (w odróżnieniu od tych, którzy przeszli przemianę duchową i zamiast łamać zabezpieczenia, zajmują się ich wzmacnianiem), obszarów do wykazywania się umiejętnościami.

Generalnie istnieją dwa pola działalności, zmierzającej do nieuprawnionej ingerencji w dane przechowywane w jakimś systemie. Jedno dotyczy przełamania zabezpieczeń zewnętrznych systemu i uzyskania przez osoby nieuprawnione przywilejów, dostępnych normalnie dla uprawnionych użytkowników (najlepiej takich, którzy mają poziom tych przywilejów możliwie wysoki).

Drugie pole, to wykorzystywanie słabości konstrukcyjnych systemu dla przeprowadzania przez użytkowników, posiadających już jakieś przywileje dostępu do danych systemu, działań, na które ich przywileje nie powinny pozwalać. Oczywiście, takim użytkownikiem może być hacker, który… właśnie przełamał zabezpieczenia systemu i założył sobie (bez pomocy, a nawet wiedzy admina systemu) własne konto, którego uprawnienia nie odpowiadają jego potrzebom :-)

Przypuśćmy, że hacker ma już uprawnienia. Jak z nich skorzysta ? Po pierwsze, może pozyskać dane osobowe w systemie się znajdujące, na przykład dane studentów, dydaktyków, urzędników.  Im bardziej szczegółowe dane znajdują się w systemie, tym większej szkody doznają użytkownicy, których dane zostaną skradzione.

W tym względzie Dziekanat.XP nie ma sobie równych! Dokładność informacji, pamiętanych w systemie, dorównuje dokładności danych posiadanych przez banki, a może nawet je przewyższa. Ponieważ tabelka z danymi o użytkowniku, która do niedawna pokazywała sie zaraz po zalogowaniu [udostępniając te dane hackerowi, preferującemu socjalne metody kradzieży danych :-) ], została wreszcie ukryta, i to tak skutecznie, że w ogóle jej nie można znaleźć, nie pokażę listy danych osobowych, które w systemie D.XP są pamiętane o każdym pracowniku. Za to poniżej pokazuję listę danych, dotyczących studentów, na której nie ma na szczęście numeru dowodu osobistego i nazwiska panieńskiego matki….

 Nr albumu, Wydział, Specjalność (Specjalizacja), Kierunek, Semestr, Adres stały, Adres do korespondencji, Imię matki, Imię ojca, Data urodzenia, Miejsce urodzenia, Nr telefonu (dom), Nr telefonu (kom), Email

Studenci nie muszą więc przesadnie obawiać się o bezpieczeństwo swoich tożsamości, martwią się jednak, że obecne w systemie dane roją się od błędów [podaję na odpowiedzialność zaprzyjaźnionych studentów, bo w moich danych błędów nie ma]. Kradzieży tożsamości obawiają się za to pracownicy, a niektórzy protestują głośno, domagając się usunięcia zbędnych danych  osobowych z potencjalnie słabo zabezpieczonego systemu.

O ile zawartość zestawu danych osobowych użytkowników może podlegać dyskusjom i ewentualnym korektom, dane dotyczące postępów studentów muszą być pamiętane w systemie w komplecie. Do nich należą: program studiów obowiązujący studenta,  wyniki (oceny) uzyskane w trakcie studiów wraz z datami ich otrzymania oraz informacja identyfikująca pracownika dydaktycznego, który daną ocenę wystawił.

Ochrona tych danych musi być znacznie szersza niż danych osobowych użytkowników systemu (którzy sami są w stanie skorygować błędne wartości, albo powiadomić uprawnionego do zrobienia takiej korekty pracownika). Przede wszystkim, raz wprowadzona do systemu i zatwierdzona ocena nie może być zmieniona bez pozostawienia śladu takiej modyfikacji; zmiana naniesiona w systemie musi być sygnowana przez osobę, która jej dokonała, zaś poprzednia wartość musi w systemie pozostać, tak, aby dało się odtworzyć całą historię zmian. Takie wymagania są równoważne poprawianiu na papierowym dokumencie, gdzie wolno skreślić albo (jak w indeksie) nakleić karteczkę  i wpisać nową wartość, ale nie wolno zamazać ani zamalować starego napisu w sposób całkowicie uniemożliwiający docieczenie co było wpisane poprzednio.

Wydaje się też oczywiste, że ocena może zostać wpisana tylko przez uprawnionego do tego pracownika. Zatem można uznać, że oprócz rejestrowania w systemie historii zmian musi w nim być prowadzona kontrola dostępu do działań, takie zmiany powodujących.

Niestety sprawa uprawnień, a dokładnie kontroli uprawnień, jest w systemie Dziekanat.XP problemem nierozwiązanym. Idzie o to, że oceny z określonych zajęć w odniesieniu do określonych studentów powinni móc wystawiać (zatem i wpisywać) tylko upoważnieni dydaktycy, a wśród nich na pewno ten prowadzący zajęcia, w którego grupie student odbywa zajęcia. Jednak wpisaną ocenę może zmienić pracownik dziekanatu, a system nie rejestruje historii zmian. [Mogę się w tej sprawie mylić, ale raczej nic na to nie wskazuje.] W każdym razie, dydaktyk nie ma możliwości stwierdzić, czy zmiana poza jego wiedzą została wprowadzona, inaczej niż porównując bieżący stan danych w systemie z prywatną kopią oceny. W konsekwencji dydaktyk nie może odpowiadać za stan danych w systemie. Dlatego dydaktycy muszą potwierdzać (w sposób wiążący prawnie) wystawione oceny drukując i podpisując papierowe protokoły ocen. [Gdyby oceny były podpisywane cyfrowo, problem by nie istniał.]

Jakie skutki miałby uwieńczony powodzeniem atak hackerski na D.XP? Hacker, posiadając konto o uprawnieniach pracownika dziekanatu, mógłby swobodnie modyfikować oceny w systemie, z niewielkim ryzykiem, że ktoś to wykryje. Ba, ponieważ zaliczanie semestrów jest zapewne zorganizowane na podobnej zasadzie, co wpisywanie ocen, “black hat” mógłby spokojnie wystawić zezwolenie na przedłużenie sesji (czyli wystawić komputerową “żółtą kartkę”).  Co gorsza, nie jest wykluczone, że odpowiednie zmiany można wykonać bezpośrednio w bazie danych – brak historii zmian uniemożliwia zbudowanie mechanizmu kontroli spójności i nienaruszalności danych na poziomie transakcji biznesowych, a zatem i błąd w oprogramowaniu może mieć poważne konsekwencje – nawet bez udzialu włamywacza.

Czy jednak ktoś może być zainteresowany atakiem na system dziekanat? To oddzielna sprawa. Niektórzy, nieprzesadnie przekonani o jakości oprogramowania systemu D.XP, są przekonani, że prędzej czy później do ataku takiego dojdzie, choćby ze względu na stare przysłowie “Na pochyłe drzewo każda koza wlezie.”, i tym racji odmówić trudno…

Co to ergonomia, każdy z czytających te słowa wie. Albo przynajmniej powinien wiedzieć. Niemniej jednak, ergonomia w budowie interfejsu użytkownika systemu informatycznego nie jest czymś oczywistym. A przecież nieergonomiczny interfejs katastrofalnie obniża użyteczność każdego systemu, powodując pogorszenie sprawności użytkownika w podstawowych działaniach i zwiększając czestotliwość popełnianych przez niego błędów. Jeżeli można powiedzieć, że poziom użyteczności jest miarą przydatności systemu do przewidywanych jego zastosowań, to ergonomia decyduje o tej części owej (nie)przydatności, która niezależna jest od funkcjonalności systemu.

Innymi słowy, nawet najlepiej zaprojektowany sposób korzystania z usług systemu (funkcjonalność) można udostępniać użytkownikowi tak, aby był on wygodny – lub nie, dawał komfort pracy lub powodował przyśpieszone zmęczenie użytkownika, zmniejszał albo zwiększał szanse popełnienia przez niego błędu.

Użyteczność i ergonomia interfejsu na ogół są oceniane z punktu widzenie typowych, stale wykonywanych operacji. Nietypowa operacja zdarza się rzadko, więc wysiłek włożony w poprawne jej przeprowadzenie i ewentualne skorygowanie popełnionego błędu mają mały udział w nakładzie pracy użytkownika (no, chyba, że błąd mógłby pozostać niezauważony i spowodować znaczne szkody). W konsekwencji autorzy projektując interfejs biorą pod uwagę przede wszystkim najczęściej wykonywane działania, bo użytkownicy gros czasu spędzają wykonując niewielką część repertuaru operacji. Dla tych części projektanci starają się zapewnić łatwy dostęp (każde dodatkowe kliknięcie czy uderzenie w klawisz w wielopiętrowym menu, powtarzane dziesiątki razy jest stratą czasu), zminimalizować czynności zbędne w większości przypadków (dobry dobór wartości domyślnych pozwala pomijać większość typowych działań typu ustawianie parametru) i ograniczyć do minimum korzystanie z funkcji systemu, jeśli ten sam efekt daje się uzyskać w inny sposób (np. stosowanie filtra w aplikacji webowej jest mniej skuteczne, niż korzystanie z wbudowanej w przeglądarkę funkcji wyszukiwania tekstu na stronie).

Projektanci zatem, skupiając szczególnie uwagę na najważniejszych dla użytkownika operacjach, są w stanie zbudować wygodny, ergonomiczny interfejs relatywnie niewielkim nakładem pracy. Pod warunkiem, że wiedzą po pierwsze, która część funkcji systemu i w jaki sposób jest używana najwięcej, i po drugie, że potrafią tę wiedzę wykorzystać.

Innym sposobem poprawy użyteczności interfejsu jest wbudowanie w niego rozmaitych – drugorzędnych z punktu widzenia zasadniczej funkcji – udogodnień opcjonalnych, przydatnych do uczynienia wygodnym interfejsu przy założeniu indywidualnego sposobu działania użytkownika (a więc decydujących o ergonomii przy pewnym – niekoniecznie powszechnie stosowanym – sposobie korzystania z funkcji systemu).

Przykładowo, wpływ użytkownika na sposób posortowania danych według wartości pewnej kolumny (gdy dane prezentowane są tabelarycznie) bywa przydatny, o ile posortowanie możemy zmienić jednym kliknięciem; jeśli zmiana ta nie narusza uporządkowania wprowadzonego wcześniej według innej kolumny, a jeszcze w dodatku domyślny początkowy sposób posortowania system ustala na podstawie wcześniejszych działań użytkownika, to – mimo, iż nie jest to sprawa pierwszorzędnej wagi – użytkownik oceni to pozytywnie, bo będzie mógł sprawniej korzystać z tak prezentowanych danych. Podobny efekt ma możliwość stosowania filtrów ukrywających część wierszy (które w dodatku mogą niekiedy być zaimplementowane bez odwoływania się do funkcji systemu), pod warunkiem, że są to prawdziwe filtry, a nie prymitywna funkcja wyszukiwania pojedynczej pozycji.

Zastanówmy się, jak używa systemu Dziekanat.XP przeciętny dydaktyk. Po pierwsze rozkład częstotliwości korzystania z rozmaitych funkcji jest wybitnie nierównomierny – dydaktyk zajmuje się prawie wyłącznie rejestrowaniem postępów studentów, wystawiając oceny, zaznaczając zaliczone elementy programu, albo przeciwnie – nieobecności studenta itp. Te działania każdy dydaktyk prowadzi w sposób z jednej strony związany z charakterystyką zajęć, z drugiej zaś – dla niego najwygodniejszy, wynikający z przyzwyczajeń i nawyków, nie poddający się standaryzacji i z całą pewnością nie dający się sprowadzić do prostych ocen punktowych, które – mechanicznie uśrednione – dawałyby ocenę końcową.

Po drugie, obowiązek wystawienia oceny na koniec zajęć (zwykle semestralnie) jasno precyzuje sposób oceniania, skalę dopuszczalnych ocen i sposób rejestrowania wyniku. Tu nie ma żadnej swobody, jeśli idzie o formę – oceny, daty, liczba terminów zaliczeń czy egzaminów jest ustalona regulaminem [nie, żeby była niezmienna: w mojej wieloletniej karierze wykładowcy widziałem tyle zmian w tym zakresie, że jak dobrze pójdzie, wkrótce chyba zostaną wyczerpane wszystkie kombinacje :-) ].

Zatem wystawianie oceny końcowej z określonych zajęć (jak również oceny końcowej z przedmiotu, łączącej wszystkie oceny zajęć składowych) nie jest działaniem mechanicznym, lecz zawiera krok podsumowania ocen cząstkowych, uzyskanych przez studenta w ciągu ocenianego okresu, i krok przetworzenia go w jedną ocenę, zapisywaną wg zasad regulaminu studiów w odpowiedniej rubryce (indeksu, karty postępów studenta, i protokołu egzaminacyjnego – czy jest on papierowy, czy elektroniczny).

Oczywiście, możliwe jest (i do tej pory było jedynie dostępne) prowadzenie rejestracji bieżących postępów studentów we własnym notesie albo w prywatnym arkuszu kalkulacyjnym [chyba powinienem napisać "wciąż jeszcze możliwe jest", jako że "inwencja" administracji jest nieskończona, więc może się w przyszłości okazać, iż tego nam nie będzie wolno]. Ja na przykład korzystam z takiego arkusza do obliczania wyników egzaminów i tworzenia jednej wspólnej listy wyników, a moi koledzy mają świetne arkusze do rejestracji postępów studentów podczas zajęć projektowych (pozwalają odnotowywać osobno oceny rozmaitych aspektów działania studentów – o różnym wpływie na końcowy wynik, i dzięki temu obiektywizować jego wartość). W efekcie tylko ustalone, końcowe oceny z przedmiotu muszą być przeniesione do oryginalnych dokumentów, uznawanych przez dziekanat (lub do systemu).

W takim przypadku podstawowe znaczenie ma łatwość przenoszenia wyników do systemu. Jeżeli daty uzyskania zaliczeń są jednakowe wystarczy, aby domyślna data wystawienia zaliczenia została wstępnie ustawiona, i wysiłek dydaktyka spada o więcej niż połowę (wpisywanie czy nawet tylko wybieranie daty z formantu kalendarza jest parę razy bardziej pracochłonne niż wprowadzenie oceny). Jeśli nawet niektórzy studenci uzyskali zaliczenie w innej dacie, poprawienie dla nich domyślnej daty zaledwie przywraca normalny, typowy nakład pracy. Zatem Dziekanat.XP daje tu wyraźną oszczędność.

Niemniej jednak, dydaktyk za każdą przepisywaną oceną musi sprawdzić zgodność nazwisk. Tu dla “ułatwienia” Dziekanat.XP wyświetla nazwiska studentów na tle ciemniejszym niż w położonych obok rubrykach, mających białe tło – wbrew elementarnym zasadom ergonomii, nakazującym przyciemnianie pasywnego tła (wszak ono zajmuje większość powierzchni ekranu) i wyświetlanie z dużym kontrastem między napisem i tłem tylko rubryk zawierających istotne dane. Podobnego rodzaju absurd znajduje się w formularzach do wystawiania ocen końcowych: tam data zaliczenia przedmiotów składowych, niezbędna do określenia daty wpisywanej oceny końcowej, jest ukryta, choć miejsca na nią jest aż za dużo:

Rysunek (choć przeskalowany przez WordPressa) ujawnia, że data dla każdego z wpisów mogłaby być umieszczona pod oceną, zaś zmniejszając szerokość  pola na datę dla nowowprowadzanych danych można byłoby uzyskać układ formularza protokołu używanego od wielu lat, co niewątpliwie ograniczyłoby pomyłki.

Jak jednak przeprowadzić wpisywanie zaliczeń, gdy kolejność nazwisk w naszym prywatnym zestawieniu ocen jest inna niż kolejność w systemie? Jeśli tabela ocen zawiera wszystkich studentów, to wykorzystanie przeglądarkowej funkcji wyszukiwania tekstu na stronie pozwala natychmiast odnaleźć pożądaną pozycję – bez interakcji z systemem – i zakoczyć cały proces przy jednym jedynym odwołaniu się do systemowej operacji zapisywania danych – na samym końcu. Gorzej, gdy lista studentów jest postronicowana albo podzielona na grupy: w pierwszym przypadku trzeba spowodować wyświetlenie właściwiej strony (co w dobrze zrobionym systemie trwa parę, a “naszym” dziekanatowym paręnaście i więcej sekund), w drugim pracy jest znacznie więcej – na przykład w naszym systemie trzeba zapisać wprowadzone dotąd wyniki bieżąco obrabianej grupy (kilkanaście do parudziesięciu sekund), wybrać z menu funkcję uzupełniania ocen i ponownie wybrać przedmiot wskazując inną, potrzebną nam grupę (kolejne kilkanaście sekund). Po tym – sięgającym minuty – czasie możemy już (o ile mamy szczęście i wybraliśmy właściwą grupę studencką) wpisać ocenę.

Alternatywnie, możemy korzystać z wyszukiwania studenta po nazwisku (musi być wprowadzone całe i dokładnie w takiej pisowni jak w systemie) albo po numerze albumu (kto w swoich notatkach identyfikuje studenta numerem albumu…). Ten sposób działania załatwia sprawę grup postronicowanych. Jednak za każdym razem wymaga wprowadzenia daty ręcznie, gdyż po każdym zapisie danych system przestawia domyślne daty terminów na datę bieżącą, a ponadto każde wprowadzenie jednej oceny wymaga wykonania zapisu (kilkanaście sekund).  W efekcie warto tak działać, gdy mamy do dopisania parę ocen – przy masowym wpisywaniu proces zwalnia parokrotnie.

Cóż zatem robić? Sprytny dydaktyk przygotowuje sobie notatki w wersji elektronicznej, układając listę studentów w wygodnej postaci – tj. ułożoną np. zespołami projektowymi, a przed wpisywaniem zaliczeń sortuje ją alfabetycznie (tak, jak to jest wymagane w systemie Dziekanat.XP). I wtedy wprowadzanie wymaga tylko synchronicznego przepisywania ocen i dat.

Że to kłopotliwe? No pewnie… Że można byłoby zrobić półautomatyczny import danych z pliku? Jasne! Że w ogóle opóźnienia w reakcjach systemu nie dają się wytłumaczyć jego obciążeniem, a co najwyżej niewłaściwie dobraną technologią i kiepską implementacją? Pewnie i to prawda.

Ale to wszytko nie musi być dobre, bo nie jest potrzebne administracji, tylko nam, dydaktykom, więc pewnie nie będzie zrobione, bo przecież wiadomo, że nos dla tabakiery a nie odwrotnie :-)

Trawestując w tytule hasło Clintona, miałem na myśli to, że być może kiedyś ktoś na naszej uczelni będzie pamiętał o podstawowych cechach wdrażanych do praktyki produktów, procedur i regulaminów – to jest o tych cechach, które decydują o warunkach pracy deklarowanych beneficjentów zmian, którymi powinni być (nie tylko w słowach) dydaktycy.

Ilekroć wchodzę na stronę systemu Dziekanat.XP i spoglądam na pierwszą pokazującą się stronę, zastanawiam się, kto z niego w zamyśle twórców miał korzystać. Prowokuje mnie do tego to oczywiście, co widzę: zajmujący pół (no nie, tylko jedną trzecią…) ekranu widoczek, “wołowymi literami” wypisana  nazwa nasze uczelni wraz z logo i menu główne, z którego mnie – jako dydaktyka – interesuje na codzień tylko jedna pozycja: “Pracownik”. [Widoczek będziemy dobrze pamiętać, bo jest obecny na każdej stronie systemu i zawsze w tej samej wielkości...]

To zrozumiałe, że jako dydaktyk interesuję się głównie postępami moich studentów, a więc ocenami, które im wystawiłem kiedyś, i tymi, które mam wystawić na koniec bieżącego okresu. Oprócz tego czasem mogę chcieć sprawdzić inne informacje dotyczące studentów i… w zasadzie tyle. Menu proponuje mi natomiast takie możliwości:

Aby dostać się do funkcji systemu, potrzebnych mi w codziennej pracy, muszę za każdym razem przechodzić przez dodatkowy poziom menu. W nagrodę dostaję ponad dziesięć możliwości… w których trudno się połapać i trudno nie odnieść wrażenia, że to za wiele. Ale i tak najgorsze (przynajmniej na początku), że nie ma żadnej informacji, co z pomocą danej funkcji można zrobić.

Pół biedy z pozycją “Podział godzin”, choć dostęp do funkcji “Wydruk podziału godzin” w tym samym menu to już zbytek łaski. Ale co oznaczają pozycje “Wolne terminy” i “Wolne terminy dla studentów”? Czy to coś związanego z podziałem godzin?

Bliższe badanie doprowadza do ustalenia, że to “Dydaktyka – Wolne terminy dla grup” i “Pracownik wolne terminy studentów i wykładowcy”. Obie formatki przedstawiają bardzo podobne listy zajęć i ostatecznie można w nich zaznaczyć całe grupy wybranych studentów lub (w kolejnej formatce) pojedynczych studentów. Ki diabeł?

Krótki eksperyment prowadzi do wniosku, że jest to “udogodnienie”, pozwalające zaplanować spotkanie grupowe lub indywidualne w określonej porze (wybieranej z bardzo dziwnego, na sztywno ustalonego rozkładu zajęć) i w sali, która jest w tym czasie wolna (z rezerwacją tej sali). Niestety na razie chyba nie działa. Ale cokolwiek to jest, ma związek z podziałem zajęć, więc te pozycje menu powinny być raczej zgrupowane w jednym miejscu.

Pozostaje jeszcze “Aktywność pracownika”  (bardzo tajemnicza formatka zatytułowana Udział studentów w aktywnościach – oczywiście pusta) oraz parę pozycji łatwo poddających się interpretacji, jak “Umieszczanie materiałów dydaktycznych” [pozwala udostępniać pliki  grupom studenckim, w tym na przykład grupie do zajęć Egzamin, albo Ocena końcowa :-)], albo “Wysyłanie wiadomości dla studentów”, które tym się charakteryzuje, że gdy już rozpocznie się przygotowanie tekstu wiadomości, to nie widać do kogo wiadomość zostanie wysłana i – jak można się spodziewać – nie da się jej wysłać do nie-studenta.

I wreszcze clou programu, czyli pozycje menu odnoszące się do ocen. Są aż cztery: “Oceny”, “Uzupełnianie ocen”, “Oceny cząstkowe” i “Statystyka ocen”.

Pierwsza z nich – “Oceny”, daje się najłatwiej rozszyfrować, ponieważ po przejściu przez poziom wyboru podzbioru studentów (w oparciu o nazwy przedmiotów i tajemnicze symbole grup studentów – niestety w większości nie odpowiadające zajęciom, z których wystawia się oceny) wyświetlają się tabele z ocenami poszczególnych studentów, w których nic nie można zmienić. Mamy więc pewność, że otrzymaliśmy listy wystawionych ocen. Problem tylko, przez kogo wystawionych, a także za jaki okres. [Przez analogię do sugerowanej zawartości tabeli ze statystyką można domniemywać, że zestawione są tylko oceny danego prowadzącego zajęcia.]

“Statystyka ocen” to bez wątpienia… statystyka ocen. Nagłówek wskazuje jednoznacznie, że odnosi sie ona do studentów danego prowadzącego. Tabela – chciałoby się powiedzieć “zajęć”, ale nie, to znowu grupy, tyle, że inaczej opisane niż przy “Ocenach” – z kolumnami, zawierającymi liczbę studentów, którzy uzyskali poszczególne oceny. [Jeśli ktoś chciałby mieć przekrój roku, albo wszystkich swoich grup łącznie - trzeba własny arkusz kalkulacyjny.]

“Oceny cząstkowe” pozwalają prowadzącemu zajęcia wpisywać oceny wystawiane w trakcie semestru. Niestety, nie wiem w jakim układzie widać byłoby wystawione oceny – dziennika szkolnego? listy ocen z datami? czy jakoś inaczej, bo nie udało mi się wprowadzić wiecej niż dwóch ocen w taki sposób, aby pozostały one zapamiętane pomiędzy wyświetleniami całego zestawienia. W każdym razie tryb wpisywania ocen nie jest najwygodniejszy: trzeba wybrać jeden z ustalonych na sztywno kwalifikatorów (np. sprawozdanie czy odpowiedź ustna) i wybrać z listy jedną z ustalonych wartości oceny. Myślicie, że jedną z 6 ocen? Jesteście w błędzie – lista liczy 10 pozycji, z czego jedna (“nb“) nie mam pojęcia co oznacza.

Na całe szczęście jest dodatkowy tryb wpisywania ocen, w którym można ustawić wspólny rodzaj oceny (np. kolokwium) i wspólną datę domyślną i wypełnić, przepraszam, wybrać ocenę dla każdego studenta. Wyświetla się ta tabelka pod tabelą ocen, więc trzeba ekran solidnie przewinąć w dół, tracąc z oczu informację o przedmiocie, rodzaju zajęć itp. Ale nie, nie, przepraszam, tej informacji na tej stronie w ogóle nie ma!  oceny wpisuje się na ślepo – więc nie przestaje ona być… niewidoczna.

Warto też zauważyć, że tabela grup studenckich jest wyświetlana w specyficzny sposób: od końca. To znaczy, że jako pierwsza pojawia się ostatnia, całkowicie wypełniona strona zestawienia, a na dole wyświetlany jest przycisk “Poprzednia”, którego naciśnięcie powoduje wyświetlenie poprzedniej strony, która niekoniecznie jest wypełniona, zaś przycisk na jej dole opisany jest “Następna”. Że co? że to na odwrót? No tak, ja też podpisałbym przyciski odwrotnie, ale cóż…

Ostatnia z czterech pozycji menu, odnoszących się do ocen to “Uzupełnianie ocen”, które nie oznacza nic innego, jak wystawianie ocen końcowych. [Prawda, jak łatwo na to wpaść?]  Tutaj tabela wyświetlana na wstępie jest bardzo szeroka, zawiera informacje o wydziale (z pełną nazwą), o nazwie przedmiotu, nazwie kierunku, typie studiów (napis, np. “pierwszego stopnia”),  rodzaju studiów (słownie, a jakże, np. “niestacjonarne”), specjalności [niektóre nazwy specjalności bywają długie...], nazwie grupy [kto zgadnie, co to "Grupa spec PInż02"], symbolu grupy [spróbuj rozkodować "GWyk01,"], formie zajęć [tu przynajmniej wszystko jasne - forma zajęć OK czy E nie budzi zdziwienia ;-)] i wreszcie o trybie zaliczania zajęć, pod nagłówkiem “Forma zaliczenia” [ach, co może znaczyć "ZzO"?]. Chyba nawet opuściłem jedną czy dwie kolumny…

Dzięki temu mamy tabelę “jak dzwon” (poniżej jest pokazana po wyświetleniu w znacznie za wąskim oknie i dodatkowo zwężona przez WordPressa):

Wskutek rozbudowanej w poziomie tabeli okno trzeba rozciągnąć  na co najmniej 1700 pikseli [może nam kupią monitory o większej rozdzielczości ?].

Dzięki “ergonomicznemu” doborowi kolorystyki, gdy tylko po wybraniu przedmiotu/zajęć pojawia się inna tabela, jasne białe tło bije po oczach. Ale nie jest tak źle, nie wszystko tak jasno świeci: jak widać nazwiska i numery albumu są na niebieskim tle i nie tak jak nagłowki pogrubioną, tylko czcionką cieniutką na jeden piksel. Przynajmniej w tym twórcy są konsekwentni… :-)

Tabela do uzupełniania ocen wygląda tak:

Autorzy konsekwentni są także i w tym, że przy okazji wyświetlania wszystkich tabel z zajęciami podają kod semestru (zapewne według programu studiów), ale nie podają identyfikacji semestru w oparciu o datę kalendarzową (np. Zima 2011-2012).

Konsekwencja zawodzi ich jednak w innych miejscach: kto objaśni mi, dlaczego w tabeli powyżej pierwszy student ma wyświetlone miejsce na ocenę z wykładu (oprócz oceny za projekt), a ten poniżej (i wszyscy następni) tylko projekt? A może to błąd? Ja nie wiem – mogę się tylko domyślać, ale ponieważ “interesujących właściwości” w tej pozycji menu jest więcej, “Uzupełnianie ocen” omówię przy innej okazji.

Zniesmaczony poziomem realizacji sławetnego systemu Dziekanat.XP, który od niedawna jest wreszcie (?) dostępny też dla Wydziału EAIiE, postanowiłem zbierać kwiatki, jakie odnajduję co rusz, próbując z systemu tego (dalej: D.XP) korzystać.  W tym – pierwszym – odcinku :-) zajmę się łamaniem zasad bezpieczeństwa.

Każdy system (dawniej napisałbym każdy system przechowujący ważne dane, ale dziś jest inaczej…) powinien chronić swoich użytkowników a także dbać o spójność danych, które przechowuje i przetwarza. W tej kolejności właśnie. Dlaczego ?

Otóż dlatego, że choćby dane przez system udostępniane funta kłaków nie były nawet warte, tak długo, jak długo budzą zainteresowanie, skłaniają użytkowników do korzystania z systemu. A to może narazić ich na niebezpieczeństwo: jeżeli niezbyt przyjazna “strona trzecia” dokona włamania do systemu i przejmie nad nim kontrolę, może w interfejs, mający służyć udostępnianiu owych “mało ważnych danych”, wmontować różne niebezpieczne narzędzia, służące do atakowania komputerów użytkowników systemu.

Zatem prawidłowo zaprojektowany system przede wszystkim dba o własne bezpieczeństwo. Oczywiście, jeśli dane w nim gromadzone powinny być chronione, musi je chronić! Jednak przede wszystkim powinien zapewniać bezpieczeństwo użytkownikom i w tym własnie sensie musi być bezpieczny – tak, jak bezpieczny w użyciu musi być scyzoryk, czy korkociąg.

Pierwszą zasadą bezpiecznej budowy i eksploatacji systemu, dostępnego bezpośrednio w internecie jest zagwarantowanie, że użytkownik, łącząc się z systemem, nie zostanie oszukany przez crackera  (jeśli myślisz, że powinienem napisać hackera, zajrzyj tutaj)i sprowokowany do dobrowolnego, acz nieświadomego udostępnienia mu swoich danych uwierzytelniających (loginu i hasła), co jest zawsze pierwszym (o ile tylko ma on szanse się udać) krokiem do włamania do systemu.

Wszyscy (?) wiedzą, że dla zabezpieczenia przed takim działaniem stosuje się uwierzytelnianie serwera, na którym zainstalowany jest system, polegające na umieszczeniu na nim, “okazywanego” przeglądarkom, certyfikatu cyfrowego. Dzięki temu użytkownik widzi, że strona WWW, na którą prowadzi go przeglądarka, znajduje się rzeczywiście na tym serwerze, co trzeba (i w konsekwencji bezpieczne, szyfrowane połączenie chroni nas przed podsłuchiwaniem, co nie miałoby miejsca, gdybyśmy byli podłączeni do fałszywego serwera, podstawionego nam przez crackera).

Jest tak zawsze po nawiązaniu połączenia z potwierdzającym swoją tożsamość serwerem, o ile tylko certyfikat jest wystawiony (podpisany cyfrowo) przez jakąś instytucję, której ufamy, bądź inną, która posługuje się certyfikatem wystawionym przez tamtą pierwszą, zaufaną.

I tu dochodzimy do sedna. Co widzimy, próbując nawigować po stronach D.XP ? Ano to:

A dlaczego tak jest? To proste – serwer został zaopatrzony w certyfikat, wygenerowany “chałupniczo” przez administratora systemu. Nie potwierdza on niczego – równie “dobry” certyfikat może wygenerować ktokolwiek, a na pewno cracker.

Możemy domyślać się, że serwer, zgłaszający się po wprowadzeniu URLa  https://dziekanat.agh.edu.pl/, jest serwerem uczelnianym i zignorować każde takie ostrzeżenie przeglądarki, a nawet wyłączyć ostrzeżenia dotyczące tego certyfikatu, i wszystko będzie dobrze. Do czasu…

To, co przy tej okazji zajdzie – całkowicie niepostrzeżenie – to dokonanie pierwszego kroku na drodze do wyrobienia w sobie nawyku ignorowania tego rodzaju ostrzeżeń. A za jakiś czas – w tym czy innym systemie – automatycznie zaakceptujemy bezwartościowy certyfikat, podstawiony nam na fałszywej stronie logowania ważnej dla nas witryny. I oby nie była to strona naszego banku…