Analiza wymagań użytkowników na przykładzie systemów ......wego rodowiska programistycznego...

ANALIZA WYMAGA U YTKOWNIKÓW NA PRZYK ADZIE SYSTEMÓW ELEKTRONICZNEGO INDEKSU

ZBIGNIEW FILUTOWICZ, KRZYSZTOF PRZYBYSZEWSKI

Streszczenie

Trafne analizy procesów biznesowych i analizy systemów teleinformatycznych s

kluczem do sukcesu in ynierii oprogramowania. W pracy pokazano jak wa ne jest spe-

cyfikowanie potrzeb u ytkowników systemów teleinformatycznych na przyk adzie

fragmentu systemu wirtualnego dziekanatu. Dobrze dzia aj ce procesy wymiany in-

formacji w formie tradycyjnej z wykorzystaniem dokumentacji papierowej, nie musz

by optymalnym rozwi zaniem w przypadku obiegu informacji w formie elektronicz-

nej. Zdaniem autorów dobrze przeprowadzona analiza potrzeb u ytkowników powinna

zawiera specyfikacj potrzeb u ytkowników bez sugerowania projektowych rozwi -

za realizacji procesów biznesowych. Natomiast na etapie projektowania wymagana

jest analiza alternatywnych projektów przy uwzgl dnieniu wszystkich uwarunkowa

wynikaj cych z dokumentacji analitycznej.

S owa kluczowe: analiza wymaga ICT, analiza procesów biznesowych, in ynieria

oprogramowania, systemy wirtualnego dziekanatu, indeks elektroniczny

1. Wprowadzenie

Od pocz tku istnienia systemów informatycznych zdawano sobie spraw z wagi czynnika ludz-

kiego na etapie tworzenia systemu oraz jego eksploatacji. Dlatego pojawi a si definicja systemu

informatycznego mówi ca, e sk ada si on z hardware’u, software’u oraz humanware’u. W miar

rozwoju, popularyzacji i zwi kszania mo liwo ci systemów informatycznych zauwa ono, e decy-

duj cy wp yw na sukces systemu teleinformatycznego ma po pierwsze dostosowanie jego

funkcjonalno ci do potrzeb u ytkowników oraz po drugie przyjazno sposobu obs ugi, jaki zapew-

nia on u ytkownikowi (u yteczno – jako interakcji cz owieka z systemem informatycznym).

Wydawa oby si , e w tej dziedzinie ju tak du o napisano i stosowane s dobre praktyki in ynier-

skie. Autorzy na przestrzeni ostatnich kilkunastu lat mieli kontakt i maj z kilkoma systemami

informatycznymi wirtualnych dziekanatów wspomagaj cymi procesy obiegu informacji w dzieka-

natach wy szych uczelni. Jednym z podsystemów wirtualnych dziekanatów jest system tzw.

elektronicznych indeksów. Do obecnych czasów informatyzacja obiegu dokumentów elektronicz-

nych dubluje obieg dokumentów w postaci papierowej lub tylko nieznacznie redukuje liczb

dokumentów papierowych. Podobne do wiadczenia maj autorzy w przypadku elektronicznych in-

deksów. Zebrane do wiadczenia jednoznacznie przemawiaj za tym, aby upowszechni wnioski

wynikaj ce z eksploatacji tych systemów oraz na ich podstawie przybli y praktyczne aspekty in-

ynierii oprogramowania mi dzy innymi studentom informatyki. Warto w tym miejscu tak e

nadmieni , e statystyki pokazuj problemy z terminowym uko czeniem przedsi wzi informa-

tycznych, utrzymaniem si w bud ecie przedsi wzi cia a tak e sytuacje niewywi zania si

Zbigniew Filutowicz, Krzysztof Przybyszewski

Analiza wymaga u ytkowników na przyk adzie systemów elektronicznego indeksu

42

z przyj tych za o e [5,263–276]. W Internecie od kilkunastu lat jest dost pny rysunek, który w sposób

satyryczny przedstawia problemy in ynierii oprogramowania[6]. Do wiadczenie pokazuje, e e-go-

spodarka to komputerowe wspomaganie procesów biznesowych zachodz cych w rzeczywistym

wiecie. Dlatego oprócz poj cia analizy systemów teleinformatycznych (analizy systemowej) funk-

cjonuje poj cie analizy procesów biznesowych oraz projektowanie procesów biznesowych

i projektowanie systemów teleinformatycznych. Rodzi si tak e pytanie czy dobrze zorganizowane

procesy biznesowe w formie tradycyjnej bez wykorzystania systemów elektronicznego wspomaga-

nia s optymalne w przypadku systemów teleinformatycznych?

Intencj autorów nie jest krytykowanie konkretnych systemów wirtualnych dziekanatów, ale

pokazanie zjawiska istniej cego w przypadku wolnego wyboru przez uczelnie konkurencyjnych

rozwi za w drodze przetargów, gdy wygrywa najta szy. Wzorem innych krajów mo na by zasto-

sowa regu , e w przetargu wygrywa propozycja rodkowa wzgl dem ceny, co zach ci oby

producentów do podnoszenia jako ci dostarczanych produktów. Zakupów oprogramowania u ytko-

wego cz sto dokonuj pracownicy administracji i personel ICT. Dobr praktyk by oby

wcze niejsze testowanie oprogramowania przez przedstawicieli przysz ych u ytkowników kupowa-

nego oprogramowania. Przypadek wirtualnych dziekanatów nie jest odosobniony, ale raczej typowy

dla bran y informatycznej. Podobne sytuacje zaobserwowano w innych systemach wspomagaj cych

obieg informacji elektronicznych. Dodatkow inspiracj do tego artyku u by kontakt autorów z sys-

temami recept elektronicznych wybieranych przez przychodnie lekarskie.

W pracy pomini to zagadnienia dotycz ce specyfikacji wymaga u ytkowników dotycz ce in-

terfejsów komunikacji cz owiek-komputer, co jest tak e istotne w projektowaniu systemów

teleinformatycznych.

Diagramy przypadków u ycia j zyka UML [1,223–249] wykonano za pomoc wolnodost po-

wego rodowiska programistycznego typu CASE o nazwie WhiteStarUML[13].

2. In ynieria oprogramowania

In ynieri oprogramowania mo na porówna z dziedzin in ynierii l dowej, która czy w so-

bie umiej tno ci takie jak: projektowanie, wznoszenie oraz utrzymanie wszelkich obiektów

budowlanych, a szczególnie mostów, dróg, kana ów, zapór oraz budynków. Architektem nazywamy

osob , której projekt koncepcji inwestycji budowlanej odpowiada wymaganiom inwestora i mo e

by realizowany pod jego nadzorem lub innego kierownika budowy. Projekt architektoniczny za-

wiera tak e projekt konstrukcyjny (np. obliczenia wytrzyma o ci, wybór materia ów

konstrukcyjnych), który mo e by wykonany przez innego in yniera. Osoba, która posiada odpo-

wiednie wykszta cenie oraz uprawnienia, wykonuje zawód architekta budownictwa poprzez

opracowywanie autorskich projektów budowlanych oraz nadzoruje ich wykonanie. Projekt, dzi ki

któremu powsta a nowa architektura mo na nazwa projektem architektonicznym. W szerszym za-

kresie architektem nazywa si pomys odawc , projektanta, autora zrealizowanego kompleksu lub

systemu, który nadzorowa jego realizacj . Bran a budownictwa l dowego ma d ug tradycj i dla-

tego warto wykorzysta jej do wiadczenia. Mimo tak d ugich tradycji w tej bran y funkcjonuje

pogl d, e dopiero po wybudowaniu domu inwestor wie co naprawd potrzebowa i dzi ki temu

do wiadczeniu powinien zbudowa drugi dom jego marze . Wyci gaj c wnioski z tego ostatniego

stwierdzenia warto przeprowadzi dok adn analiz potrzeb inwestora, aby zrealizowana inwestycja

odpowiada a jego oczekiwaniom.

43

In ynieria oprogramowania to dziedzina informatyki zajmuj ca si budow systemów telein-

formatycznych i wszystkimi etapami tworzenia systemów: od specyfikacji celów i potrzeb

u ytkowników poprzez projektowanie, implementacj , testowanie, wdro enie oraz ci g y rozwój

systemu teleinformatycznego[4,50–79]. Podstaw budowy systemów teleinformatycznych jest ana-

liza potrzeb (requirements analysis, requirements engineering) u ytkownika ICT (Information and

Comunication Technology). Analiza potrzeb u ytkowników wywodzi si z in ynierii oprogramo-

wania (software engineering), in ynierii systemów (systems engineering) oraz analizy systemowej

(systems analysis). Podobne podej cie obserwujemy w zarz dzaniu, gdzie w celu specyfikacji po-

trzeb u ytkownika u ywamy poj cia analiza procesów biznesowych. W marketingu pos ugujemy

si poj ciem architekta (projektanta) procesów biznesowych, a w przypadku informatyki mówimy

o architektach (projektantach) oprogramowania. W in ynierii oprogramowania w stosunku do pro-

jektanta/architekta jest u ywane okre lenie „system evangelist” (software evangelist lub technology

evangelist) pierwotnie stosowane przez firm Apple. W Polsce tytu u Adobe platform evangelist

(Adobe developer evangelist) u ywa mi dzy innymi Piotr Walczyszyn Adobe Polska[12]. Potrzeby

u ytkownika ICT to istotny element w przypadku przedsi wzi informatycznych podobnie jak

w zarz dzaniu i naukach spo ecznych. W przypadku rozporz dzenia MNiSW „w sprawie obszarów

wiedzy, dziedzin nauki i sztuki oraz dyscyplin naukowych i artystycznych”[11] informatyka wyst -

puje w obszarze wiedzy nauk cis ych w dziedzinie nauk matematycznych oraz w obszarze nauk

technicznych w dziedzinie nauk technicznych. Powinna tak e wyst powa w obszarze nauk spo-

ecznych w dziedzinie nauk spo ecznych. Dodatkowym argumentem przemawiaj cym za

spo ecznym charakterem ICT jest dzia alno polegaj ca na zarz dzaniu projektami informatycz-

nymi.

Analityk systemów teleinformatycznych na etapie analizy wymaga u ytkownika zbiera, kla-

syfikuje, analizuje oraz dokumentuje informacje dotycz ce funkcjonowania systemu rzeczywistego

obiegu informacji oraz propozycji jego automatyzacji z wykorzystaniem systemu teleinformatycz-

nego[3,224–245]. O sukcesie projektu decyduje wspó praca ze zleceniodawc i zespo em

projektowym. Mówi si tak e o nadzorze po stronie zleceniodawcy, który wynajmuje niezale nych

analityków systemowych do reprezentowania zleceniodawcy przed firm wykonuj c projekt. Ana-

lityk systemów teleinformatycznych analizuje mo liwo ci zastosowania rozwi za

teleinformatycznych w celu automatyzacji wybranych procesów biznesowych. Jest on tak e odpo-

wiedzialny za przygotowanie dokumentacji analitycznej i zarz dzania jej zmianami. Analityk

systemowy to dobrze zorganizowana osoba potrafi ca samodzielnie podejmowa decyzje, komuni-

katywna, twórcza i potrafi ca pracowa w zespole. Identyfikacja zawodu analityka systemów

teleinformatycznych: Wed ug systemu Klasyfikacji zawodów i specjalno ci na potrzeby rynku

pracy (KziS 2010): 251101 Analityk systemów teleinformatycznych. Grupa wielka 2 – Specjali ci

(w Mi dzynarodowej Klasyfikacji Standardów Edukacyjnych ISCED 2011 – poziom 6). Grupa ele-

mentarna 2511 – Analitycy Systemowi (w Mi dzynarodowym Standardzie Klasyfikacji Zawodów

ISCO-08 odpowiada grupie 2511 Systems analysts).Wed ug Polskiej Klasyfikacji Dzia alno ci

(PKD 2007): Sekcja J. Informacja i komunikacja. Dzia 62. Dzia alno zwi zana z oprogramowa-

niem i doradztwem w zakresie informatyki oraz dzia alno powi zana. Grupa 62.02. Dzia alno

zwi zana z doradztwem w zakresie informatyki[9].

Architekt/projektant systemów teleinformatycznych to twórczy i wysokokwalifikowany

znawca technologii implementacyjnych systemów. W tych zawodach ceni si do wiadczenie i zna-

jomo bran y teleinformatycznej. Prowadzenie przedsi wzi wymaga tak e zarz dzania oraz

Studies & Proceedings of Polish Association for Knowledge ManagementNr 71, 2014



44

wyboru sposobu prowadzenia projektu. Zespo y tworz ce systemy oprogramowania musz by

przygotowane do pracy w metodykach zwinnych np. scrum oraz korzysta z oprogramowania do

komputerowego wspomagania ró nych faz in ynierii oprogramowania. In ynieria oprogramowania

jest nieod cznie zwi zana z oprogramowaniem wykorzystywanym do komputerowego wspomaga-

nia produkcji oprogramowania (IDE, CASE, SDK, VPL)[2,55–67]. Oprogramowanie mo na

podzieli na systemowe (systemy operacyjne), narz dziowe, oprogramowanie rodowisk programi-

stycznych (oprogramowanie do produkcji oprogramowania) oraz aplikacyjne (u ytkowe).

Oprogramowanie wirtualnego dziekanatu nale y do kategorii oprogramowania u ytkowego.

Identyfikacja zawodu projektant/architekt systemów teleinformatycznych: wed ug Klasyfikacji

zawodów i specjalno ci na potrzeby rynku pracy (KZiS 2010): 251103 Projektant / architekt syste-

mów teleinformatycznych. Grupa wielka 2 – Specjali ci (w Mi dzynarodowej Klasyfikacji

Standardów Edukacyjnych ISCED 2011 – poziom 7). Grupa elementarna 2511 – Analitycy syste-

mowi. Wed ug Polskiej Klasyfikacji Dzia alno ci (PKD 2007): Sekcja: J. Informacja i komunikacja,

Dzia : 62. Dzia alno zwi zana z oprogramowaniem i doradztwem w zakresie informatyki oraz

dzia alno powi zana, Grupa 62.02. Dzia alno zwi zana z doradztwem w zakresie informatyki,

Grupa 62.01. Dzia alno zwi zana z oprogramowaniem[9].

Na rysunkach numer 2 i 3 s przyk adowe statystyki z pocz tku roku 2014 przedstawiaj ce

struktur p ac zwi zanych z wykonywaniem zawodów analityka i projektanta systemów teleinfor-

matycznych.

Rysunek 1. P ace w zawodzie analityka oraz projektanta/architekta systemów teleinformatycznych

ród o: [7].

W biznesie, badaniach naukowych oraz bran y ICT wa na jest kreatywno , innowacyjno

i twórcze podej cie. Oprócz wiedzy i umiej tno ci licz si tak e motywacje i kompetencje spo-

eczne. Dobra znajomo zagadnie zwi zanych z wykonywanym zawodem i ich zrozumienie jest

kluczem do sukcesu. Aby tworzy konkurencyjne rozwi zania konieczna jest dzisiaj tak e wspó -

praca mi dzy specjalistami ró nych dziedzin. W e-biznesie musz ze sob wspó pracowa

45

biznesmeni, specjali ci ICT i PR oraz graficy arty ci i graficy komputerowi. W tej pracy zawarto

do wiadczenia in ynierów oprogramowania, analityków, projektantów, programistów, testerów,

wdro eniowców oraz dydaktyków technologii teleinformatycznych. Studenci in ynierii oprogramo-

wania musz by przygotowywani nie tylko w zakresie programowania, ale tak e pod k tem

rozumienia potrzeb u ytkowników oraz musz rozumie potrzeby ró nych form procesów bizneso-

wych.

3. Analiza najcz stszych rozwi za elektronicznego indeksu

W klasycznym systemie obiegu dokumentów papierowych (rys. 2) pracownicy dziekanatów

przygotowywali karty egzaminacyjne dla studentów oraz protoko y dla nauczycieli. Studenci mu-

sieli osobi cie odebra indeksy i karty egzaminacyjne z dziekanatu, a nauczyciele protoko y

egzaminacyjne. Nast pnie studenci musieli zg osi si osobi cie do nauczyciela po wpis z zaliczenia

przedmiotu lub egzaminu. Nauczyciele dokonywali wpisu do kartu egzaminacyjnej i do indeksu na

podstawie w asnej dokumentacji. Studenci po uzyskaniu wpisów zdawali karty egzaminacyjne i in-

deksy do dziekanatu. Nauczyciele na podstawie w asnej dokumentacji dokonywali wpisów zalicze

i egzaminów do protoko ów, które nast pnie zdawali do dziekanatu. Nauczyciele t sam ocen

wpisywali czterokrotnie: do w asnej dokumentacji, karty egzaminacyjnej, indeksu oraz protoko u.

Znacznym u atwieniem by o wpisywanie dwa razy tej samej oceny do dokumentów karty egzami-

nacyjnej i indeksu, które posiada y podobn struktur i odbywa o si to w tym samym czasie. Na

rysunku 2 nie uwzgl dniono jeszcze przypadku zgubienia przez studenta karty egzaminacyjnej lub

indeksu poniewa , taka sytuacja nie b dzie mo liwa w przypadku dziekanatu wirtualnego. Do do-

kumentacji procesu kszta cenia zalicza si tak e dokumentacj dotycz ca wszystkich prac

zaliczeniowych wykonywanych przez studentów. S to sprawozdania z laboratoriów, kolokwia,

prace egzaminacyjne pisemne oraz wszystkie inne prace dostarczane w formie papierowej lub elek-

tronicznej przez studentów nauczycielom. Prace te powinny by przechowywane przez ca y cykl

kszta cenia studenta.




46

Rysunek 2. Tradycyjny system obiegu informacji

zwi zanych z dokumentowaniem procesu nauczania

ród o: opracowanie w asne.

Najcz stszymi za o eniami stosowanymi w systemach elektronicznych indeksów jest dost p

studentów do indeksu, a nauczycieli do protoko ów zaliczeniowych (rys. 3). Jest to rozwi zanie

przeniesione ywcem z dotychczasowych praktyk stosowanych w obiegu dokumentów papiero-

wych. W elektronicznej wersji indeksów w wirtualnych dziekanatach najcz ciej wykorzystuje si

elektroniczny obieg dokumentów z równoczesnym dublowaniem obiegu dokumentów w postaci

papierowej, tak jak to by o w systemie klasycznym (rys. 2). Studenci pobieraj z dziekanatu papie-

rowe wersje karty egzaminacyjnej, zbieraj wpisy wszystkich zalicze i egzaminów. Po uzyskaniu

wpisów zdaj kart egzaminacyjn w dziekanacie. Jedyn zmian w stosunku do wersji klasycznej

systemu odbiegu dokumentów jest brak indeksu w postaci papierowej oraz mo liwo podgl du

indeksu elektronicznego online po uprzednim si zalogowaniu si na witrynie wirtualnego dzieka-

natu.

47

Rysunek 3. Obieg dokumentów dla du ej liczby systemów elektronicznego indeksu


Nauczyciele musz prowadzi w asn dokumentacj monitoruj c post py studenta w trakcie

semestru. W wirtualnym dziekanacie zazwyczaj dopiero pod koniec semestru pojawiaj si spisy

protoko ów oraz protoko y zawieraj ce dane o studentach. Jako ciekawostk mo na poda , e cz

systemów wirtualnego dziekanatu do chwili obecnej nie posiada numeracji protoko ów w ich spisie.

Poniewa listy studentów odbywaj cych zaj cia nie musz si pokrywa z listami w protoko ach

(na przyk ad w wyniku czenia studentów ró nych specjalno ci) nauczyciel musi drukowa wszyst-

kie protoko y i przepisa oceny ostateczne z w asnej dokumentacji papierowej do wydrukowanej

dokumentacji zgodnej z wersj elektroniczn protoko ów. Nast pnie tak zapisane dane w wersji




48

papierowej wprowadza do systemu elektronicznego. Po uko czeniu wpisów w protoko ach musi je

jeszcze raz wydrukowa , podpisa i odda do dziekanatu. W takim modelu dziekanatu wirtualnego

praca nauczyciela o dziwo sta a si bardziej z o ona, bo przy podobnym obiegu dokumentów w wer-

sji papierowej zachodzi jeszcze konieczno dodatkowego wydruku protoko ów.

Z przeprowadzonych porówna systemu papierowego i elektronicznego wynika wniosek, e nau-

czyciele musz wykona dodatkow czynno polegaj c na prowadzeniu dodatkowej

dokumentacji papierowej w porównaniu z systemem obiegu dokumentów przed wprowadzeniem

systemu informatycznego.

Co si dzieje je eli chodzi o kontakty nauczyciel – student w przypadku elektronicznego in-

deksu? Czynno ci jakie wykonuj studenci nie zmieniaj si . Zg asza si on do nauczyciela po wpis

w postaci papierowej podobnie jak poprzednio, z jedn ró nic , wpisu dokonuj nauczyciele tylko

do karty egzaminacyjnej bez konieczno ci wpisywania do indeksu. Nauczyciele na podstawie w a-

snej dokumentacji dokonuj wpisu karty egzaminacyjnej. Je eli nauczyciele jednocze nie z wpisem

do karty papierowej maj wpisywa oceny do protoko ów w wirtualnym dziekanacie to system in-

formatyczny musi by dost pny online. Na zje dzie zaliczeniowym studiów niestacjonarnch w tym

samym czasie z systemu b dzie korzysta wielu nauczycieli i studentów. Do wiadczenie pokazuje,

e próby logowania do systemu nie zawsze udaj si . Przypu my, e nawet uda o si nauczycielowi

zalogowa , ale powstaje problem jak znale studenta w du ej liczbie protoko ów, nie zawsze do-

brze opisanych w spisie protoko ów. Jak wcze niej zaznaczono w niektórych wersjach systemów

brak jest nawet numeracji protoko ów na ich li cie, co znacznie utrudnia prac nauczycielowi.

W przypadku wpisywania kilku ocen danemu studentowi przyda by si system wyszukiwania,

w których protoko ach wyst puje dany student. Innym rozwi zaniem u atwiaj cym korzystanie

z systemu mog oby by dodanie do nazwiska studenta odniesieni do innych protoko ów, w których

on tak e wyst puje. Teraz wyobra my sobie sytuacj , w której nauczyciele metod prób i b dów

otwieraj ró ne protoko y, aby znale na nich konkretnego studenta. Taka sytuacja jeszcze bardziej

spowalnia prac systemu i sprawia, e staje si on bardziej niewydolny.

Ostateczny wniosek jest nast puj cy: systemy wirtualnego dziekanatu w sprawie indeksów au-

tomatyzuj obieg dokumentów przy jednoczesnym zachowaniu obiegu dokumentów w postaci

papierowej. Czynno ci jakie wykonuj studenci nie zmieniaj si , a jedynym plusem dla studenta

jest mo liwo dost pu online do jego indeksu w postaci elektronicznej. W przypadku nauczycieli

liczba wpisów nie zmienia si i czynno ci jakie musz wykona pozostaj identyczne jak w przy-

padku obiegu dokumentów w postaci tylko papierowej plus dodatkowo praca z niezbyt przyjaznym

rodowiskiem protoko ów elektronicznych.

49

4. Analiza oczekiwa nauczycieli wzgl dem elektronicznego indeksu

Specyfikuj c potrzeby u ytkownika systemu wirtualnego dziekanatu, którego u ytkownikiem

jest tak e nauczyciel nale y wzi pod uwag potrzeb prowadzenia przez niego w asnej dokumen-

tacji utrwalaj cej post py studenta w trakcie semestru. Podstawow zasad analizy systemowej jest

za o enie, e struktury danych reprezentowanych w interfejsie u ytkownika powinny pozwala na

uaktualnianie dokumentacji o studentach w sposób niezale ny od struktury magazynowania danych

w systemie wirtualnego dziekanatu. Na etapie analizy systemu teleinformatycznego optymalnym

rozwi zaniem jest okre lenie w diagramie przypadków u ycia, e nauczyciele maj mo liwo wy-

szukania studenta i wpisania mu zaliczenia, bez podawania sposobu w jaki to b dzie realizowane

(rys. 4.). Do decyzji etapu projektowania systemu informatycznego nale y okre lenie sposobu wy-

szukiwania studenta oraz jego zalicze , jakie ma u danego nauczyciela. Sposób dokonywania

wpisów z dokumentacji papierowej, polega na wyszukiwaniu nazwisk studentów w dokumentach

protoko ów przypisanych okre lonym przedmiotom. Tak musia o by w dokumentacji klasycznej

i jest to rozwi zanie uzasadnione, je eli nauczyciel ma plik dokumentów papierowych, które mo e

szybko kartkowa . W przypadku systemu informatycznego nic nie stoi na przeszkodzie, aby zasto-

sowa inny bardziej efektywny sposób wpisywania ocen. W postaci elektronicznej dokumentów

mo na w atwy sposób przedstawi wszystkie wpisy jakie dokonuje okre lony nauczyciel dla da-

nego studenta.




50

Rysunek 4. Optymalna wersja specyfikacji potrzeb u ytkowników elektronicznego indeksu


Je eli nauczyciel ma wpisywa zaliczenia do systemu elektronicznego w chwili gdy dokonuje

zaliczenia, najlepszym rozwi zaniem dla niego by aby sytuacja, aby zamiast protoko ów widzia

indeks elektroniczny zaliczaj cego studenta. Dokona by wtedy wszystkich wpisów do formularza

indeksu, a system by je przepisa do odpowiednich protoko ów (rys. 5). Takie rozwi zanie pozwo-

li oby na wykorzystanie systemu do operacji wprowadzania ocen w czasie rzeczywistym. Nale y

tak e pami ta o mo liwo ci pojawiania si na zaj ciach studentów, których nazwiska z ró nych

powodów nie wyst puj w protoko ach zaliczeniowych. W takich przypadkach prowadz cy zaj cia

musi dopisa ich do w asnej dokumentacji, gdy s oni cz sto pomijani w oficjalnej dokumentacji

protoko ów, a pojawiaj si w niej po zaliczeniu braków lub op aceniu czesnego.

Innym uproszczeniem by aby rezygnacja z dokumentacji w wersji papierowej. Dzisiaj doku-

menty w formacie pdf s traktowane jako dokumenty z podpisem. W przypadku wirtualnego

dziekanatu mo na by traktowa takie dokumenty jako dokumentacj procesu kszta cenia, eliminuj c

potrzeb obiegu dokumentów fizycznie podpisywanych przez nauczycieli.

51

Rysunek 5. Zapis ocen do indeksu elektronicznego danego studenta


Usprawniaj c system mo na rozbudowa go w dalszej kolejno ci o wersj offline czyli desk-

topow , z mo liwo ci zainstalowania jej na komputerze nauczyciela (rys. 6). Dzi ki takiemu

rozwi zaniu wyeliminujemy dokumentacj papierow , a nauczyciel mia by mo liwo w obecno ci

studenta wpisywania zalicze do dokumentacji elektronicznej offline. Takie rozwi zanie pozwala

na prac synchroniczn z wersj desktopow , a w dogodnej chwili nauczyciel móg by w trybie asyn-

chronicznym synchronizowa dane ze swojej aplikacji destopowej z wersj online systemu

elektronicznego indeksu. Takie rozwi zanie uwzgl dnia realne warunki w jakich odbywaj si za-

liczenia i egzaminy. Na zjazdach studiów niestacjonarnych spotkania s ograniczone do dwóch dni

w weekendy i jednocze nie z systemu wirtualnego dziekanatu korzystaj wszyscy nauczyciele i stu-

denci.

Teoretycznie istnieje tak e mo liwo prowadzenia dokumentacji w asnej (lista obecno ci, no-

tatki, oceny cz stkowe i oceny ko cowe) w postaci elektronicznej w systemie dziekanatu

elektronicznego online. Na obecnym etapie dost pu do lokalnych sieci komputerowych w szko ach

wy szych jest to jeszcze rozwi zanie o zbyt du ym ryzyku. Brak dost pu do sieci pozbawi by nau-

czyciela wszelkich informacji o post pach studenta zapisanych w systemie informatycznym.




52

W przypadku prowadzenia dokumentacji elektronicznej przez nauczyciela jedynym obecnie real-

nym rozwi zaniem jest posiadanie jej w wersji desktopowej na w asnym komputerze.

Uwzgl dniaj c ograniczenia czasowe w jakich nast puje kontakt konkretnego nauczyciela i studenta

desktopowa wersja dokumentacji nauczyciela zapewni by mo liwo niezawodnego jej wykorzy-

stania.

Rysunek 6. Wersja online i offline systemu elektronicznego indeksu


53

Systemy informatyczne w postaci online i offline (desktopowej) s wykorzystywane równole-

gle w obiegu dokumentów elektronicznych. Jako przyk ad mo na poda system e_Deklaracji

Ministerstwa Finansów dost pny w formie aplikacji online i desktopowej[10]. To samo oprogramo-

wanie aplikacyjne mo na wykorzystywa w postaci aplikacji w przegl darce webowej lub w postaci

aplikacji desktopowej offline do instalowania na komputerze u ytkownika.

5. Podsumowanie

Przeprowadzone analizy dowodz jak wa ne s etapy analizy systemowej oraz projektowania

systemów teleinformatycznych. Autorzy s zdania, e faza analizy powinna by wykonywana nie-

zale nie od fazy projektowania architektury systemów teleinformatycznych. Analizy procesów

biznesowych powinny stanowi punkt wyj cia do analiz systemów teleinformatycznych. Klasyczny

obieg informacji bazuj cy na dokumentach papierowych nie zawsze musi by odpowiedni w przy-

padku wersji elektronicznej tych dokumentów. Faza analizy potrzeb u ytkowników powinna by

bardzo rzetelna i nie powinna zawiera na tym etapie sugestii rozwi za czysto projektowych czy

ukierunkowa na okre lone technologie implementacyjne (rys. 4). W dokumentacji analizy potrzeb

u ytkowników powinno si wnikliwie dokona specyfikacji istniej cego systemu obiegu informacji

(rys. 2) oraz analizy najcz ciej stosowanych rozwi za automatyzuj cych procesy biznesowe w in-

nych dost pnych rozwi zaniach (rys. 3). Diagramy przypadków u ycia na rysunkach 5 i 6 zawieraj

ju sugestie dotycz ce rozwi za projektowych w formie alternatywnej. Etapy in ynierii oprogra-

mowania dotycz ce analizy i projektowania systemów teleinformatycznych nie poddaj si

automatyzacji i rola czynnika ludzkiego jest tu najistotniejsza. Komputerowe wspomaganie ograni-

cza si na obecnym etapie rozwoju in ynierii oprogramowania do generowania dokumentacji

elektronicznej, diagramów lub szablonów kodów w okre lonym j zyku programowania. Wa ne jest

zatem zwrócenie uwagi na odpowiednie przygotowanie praktyczne specjalistów kszta conych w za-

kresie in ynierii oprogramowania pod k tem analizy systemów teleinformatycznych.

Bibliografia

[1] Booch G., Rumbaugh J., Jacobson I., UML przewodnik u ytkownika, In ynieria

oprogramowania, WNT Warszawa 2001.

[2] Filutowicz Z., Paszkowski J., Sowa G., Przybyszewski K., Paradygmat programowania

wizualnego w in ynierii oprogramowania, Studia i materia y Polskiego Stowarzyszenia

Zarz dzania Wiedz , Redaktor prof. W. Bojar, Prof. M. Nied wiedzi ski, Bydgoszcz 2011.

[3] Paszkowski J., Sowa G., Filutowicz Z., Enterprise Processes Analysis and Modeling – Study

of Opportunities, Selected Topic in Computer Science Applications, Academic Publishing

House EXIT, Warszawa 2011.

[4] Sacha K., In ynieria oprogramowania,Wydawnictwo Naukowe PWN, Warszawa 2010.

[5] Skalik J., Strzelczyk A., Kluczowe czynniki sukcesu w zarz dzaniu projektami

informatycznymi, Journal of Management and Finance, Prace i Materia y Wydzia u

Zarz dzania Uniwersytetu Gda skiego, nr 4/1, Gda sk, 2013.

[6] Etapy in ynierii oprogramowania, 2009, (pierwsza edycja). [Online]. Dost pne:

http://atlantis-telemetry.com/Software-Engineering.aspx.

[7] Gazeta, 2014, P ace, (pierwsza edycja). [Online]. Dost pne: http://gazetapraca.pl/

gazetapraca/2,79052,,,,85882651,P_WYNAGRODZENIA.html.




54

[8] In ynieria oprogramowania, 2006, (pierwsza edycja). [Online]. Dost pne: http://wazniak.

mimuw.edu.pl/index.php?title=In%C5%BCynieria_oprogramowania.

[9] Kwalifikacje, portal Rz dowy, 2013, (pierwsza edycja). [Online]. Dost pne: http://www.

kwalifikacje.praca.gov.pl/.

[10] Ministerstwo Finansów, 2014, e_Deklaracje, (pierwsza edycja). [Online]. Dost pne:

http://www.finanse.mf.gov.pl/systemy-informatyczne/e-deklaracje/do-pobrania/-

/asset_publisher/rG2P/content/aplikacja-e-deklaracje-desktop-umozliwiajaca-zlozenie-

formularzy-elektronicznych-bez-podpisu-kwalifikowanego.

[11] MNiSW Rozorz dzenie nr 1065 z dnia 8 sierpnia 2011r, (pierwsza edycja). [Online].

Dost pne: http://isip.sejm.gov.pl/DetailsServlet?id=WDU20111791065.

[12] Walczyszyn P. Adobe Polska Adobe, 2014, (pierwsza edycja). [Online]. Dost pne:

http://www.adobe.com/devnet/author_bios/piotr_walczyszyn.edu.html.

[13] WhiteStarUML CASE, 2014 (5.5 edycja). [Online]. Dost pne: http://sourceforge.net/

projects/whitestaruml/.

55

ANALYSIS REQUIREMENTS OF USERS ON THE EXAMPLE OF THE VIRTUAL DEAN'S OFFICE

Summary

Accurate analysis of business processes and the analysis of information and com-

munication systems are key to the success of software engineering. The study shows

how important it is specification of the needs of users of ICT systems on the example

part of the system virtual dean's office. Well-functioning processes of information ex-

change using traditional paper records need not be the optimal solution for the flow

of information in electronic form. According to the authors of a well-conducted anal-

ysis of users' needs should include a specification of user needs without suggesting

solutions to design business processes. In contrast, at the design stage is required for

the analysis of alternative projects, taking into account all considerations arising from

the analytical documentation.

keywords: requirements analysis, software engineering, ICT systems, the virtual dean’s office,

system analysis

Zbigniew Filutowicz

Krzysztof Przybyszewski

Spo eczna Akademia Nauk w odzi

Instytut Technologii Informatycznych

Wydzia Studiów Mi dzynarodowych i Informatyki

ul. Sienkiewicza 9, 90-113 ód

e-mail: [email protected], [email protected]


Analiza wymagań użytkowników na przykładzie systemów ......wego rodowiska programistycznego...

Documents

Transcript of Analiza wymagań użytkowników na przykładzie systemów ......wego rodowiska programistycznego...