Zasady zarządzania projektem eLearningowym - Projektowanie
Moduł Zasady zarzadzania projektem eLearningowym skupia uwage na technikach prowadzenia projektów. W szczególnosci opisuje kluczowe fazy rozwoju projektu. Opisuje sposoby jego prowadzenia, podkreśla także znaczenie odpowiedniej dokumentacji potrzebnej do prowadzenia projektu.
Określenie celu edukacyjnego modułu
Celem modulu jest zapoznanie się bliżej z fazą projektowania projektu eLearningowego. Podczas nauki projektowania będziemy zwracać uwagę na na poszczególne czynności które należy wykonać w celu prawidłowego zaplanowania projektu, wskażemy także najlepsze praktyki (best practice), które umozliwią proste i łatwe projektowanie.
Faza Projektowanie jest drugą po Planowaniu fazą prowadzenia projektu eLearningowego. W fazie Planowanie skupiliśmy się na lepszym poznaniu klienta i jego potrzeb, przygotowaliśmy budżet, wiemy zatem jakimi zasobami dysponujemy. Faza Planowanie pomogła nam także w zbadaniu dostępnych dla nas technologii, mamy już oprawcowane pomysły na których możemy oprzeć. W fazie Projektowania wykorzystamy wcześniej zdobytą wiedzę, zbudujemy dokument "projektowanie", skupimy się na detalach dotyczących projektowania interfejsu a także na sposobach przekazywania wiedzy.
Celem Fazy Projektowanie będzie przeniesienie pomysłu na papier, zrozumienie potrzeb w postaci rozwiązań projektowych, tworzenie programu, który odpowiada potrzebom odbiorcy a także produkcja dokumentacji.
Wiedza bazowa potrzebna do pracy nad modułem
|
|
| wersja multimedialna | wersja do druku |
Projektowanie
Drugą fazą budowy projektu e-learningowego jest faza projektowania.
W projektowaniu produktu eLearningowego znajdziemy analogię do pracy nad projektem
architektonicznym. Architekt chcąc wybudować dom musi wiedzieć, jakim budżetem
dysponuje jego klient. Musi też znać preferencje klienta co do kolorów, struktury
a czasem i materiałów, z jakich budowla powstanie. W naszej pracy spotkamy analogiczne
działania.
Projektant musi potrafić także zaprojektować interfejs, który zostanie prawidłowo
zrozumiany/odebrany przez uczniów.
Wiele osób twierdzi, że projektowanie to pozbieranie razem wszystkich potrzebnych
składników projektu i przekazanie ich do zaimplementowania. Nic błędniejszego.
Podczas nauki natknęliśmy się na różnych nauczycieli. Bez wątpienia dwie osoby
najczęściej różnie przedstawiają ten sam materiał. Pomimo, że wiedza, którą
przedstawiają dotyczy tego samego zagadnienia, każdy z nauczycieli przedstawi
ją w zupełnie inny sposób. Jedni mogą to zrobić nawet nie zrozumiale, inni poruszą
nas. Większość projektantów nie ma odpowiedniej wiedzy merytorycznej, wie natomiast
jak wydobyć ją od ekspertów.
Powróćmy do analogi dotyczącej budowy domu. Podobnie jak
tam gdzie architekt po zrozumieniu potrzeb i oczekiwań klienta, przystępuje
do szkicu projektu. Podobnie my powininśmy przygotować kilka wizji graficznych,
które przedstawimy naszemu klientowi.
Trudnym, ale niezmiernie ważnym elementem jest wzięcie pod uwagę opinii i wszystkich
ze stron: Klienta, nauczycieli, ekspertów oraz projekt menadżerów. Poniżej przedstawiamy
opis ról poszczególnych podgrup projektowych.
Przygotowanie dokumentów w fazie projektowanie
Osoby i ich role:
Klient
Pamiętajmy, że możemy mieć doczynienia z wieloma typami klientów. Klientem możemy być my sami, zewnętrzna firma, wewnętrzna organizacja, cała ludzka populacja albo tylko studenci. Podczas fazy projektowania powinniśmy szczególną uwagę przywiązywać w pełnym doinformowaniu klienta. Musimy się strzec przed wprowadzaniem zmian nieustalonych z klientem, możemy się przez to narazić na przymusowe ich wycofanie.
Pamiętajmy:
Doinformowanie klienta to podstawa podczas pracy nad projektem. Warto też przyjąć dewizę "bez niespodzianek", czyli zbudować sobie mocne postanowienie, że zawsze informujemy klienta o wszelkich opóźnieniach i postępach w pracach oraz zawsze pilnujemy by uczestniczył w podejmowaniu decyzji.
Koordynator
Koordynator zaangażowany jest w produkcję prawie wszystkich dokumentów projektowych. Jest odpowiedzialny także za ich uaktualnianie oraz wszelki zmiany. Logi czy też dzienniki będą głównie do użytku wewnętrznego, pozostałe dokumenty będą współdzielone z klientem i współpracownikami.
Kierownik projektu
Kierownik projektu jest odpowiedzialny za wszystkie fazy projektu. Jego głównymi zadaniami są: dopilnowanie by projekt przebiegał płynnie, mieścił się w budżecie, czynności wykonywane były w kolejności zgodnej z harmonogramem i o czasie. Kierownik projektu może nie uczestniczyć w samych pracach projektowych. Kierownik projektu nie musi znać dokładnych danych dotyczących treści projektu, powinien jednak posiadać wiedzę o ilości modułów i zawartych w nich grafikach, filmach i ścieżkach dźwiękowych.
Ekspert
Często projektanci by prawidłowo przygotować się do wdrożenia projektu zagłębiają wiedzę teoretyczną dotyczącą zagadnienia. Regułą powinno jednak być współpracowanie z ekspertami w danej dziedzinie, i ograniczenie się jedynie do przygotowania skryptu opisującego ze wszelkimi szczegółami aspekty wiedzowe zagadnienia. Rolą eksperta było by następnie zweryfikować ta wiedzę. Eksperci mogą sami partycypować przy produkcji takich dokumentów.
Trenerzy i nauczyciele
Trenerzy i nauczyciele są szczególnie przydatną grupą zaangażowaną w projekt eLearningowy. Ich wiedza może zostać spożytkowana nie tylko podczas pisania skryptu (trenerzy i nauczyciele to często eksperci posiadający także praktykę w nauczaniu danego przedmiotu). Nauczyciele pomogą w określeniu tematów trudnych dla odbiorcy. Ich wiedza praktyczna pomoże nam w lepszym przygotowaniu storyboard oraz chartflow'ów.
Odbiorca
Odbiorcy należy przekazać przede wszystkim instrukcję obsługi oprogramowania. Uczeń będzie chciał wiedzieć ile czasu pozostało mu do zakończeniu danego działu. Czy czeka go test z wiedzy, którą już zgłębił. Te dokumenty będą potrzebne dopiero w fazie wdrożenia oprogramowania, nie ma więc potrzeby by zamieszczać je w dokumentach związanych z projektowaniem.
Odbiorcy w tej fazie będą testować prototyp, wyrażać opinii e dotyczącą interface'u graficznego, przekazywać nam informację dotyczące trudnych tematów, rzeczy nie zrozumiałych.
Zespół implementacyjny:
Edytor
W dużych projektach koordynator odpowiedzialny jest za ogół zagadnień. Rolę osoby opisującej storyboard czy chartflow przejmuje Edytor. Przygotowuje on także teksty, które później będzie czytał narrator.
Programista
Programista odpowiedzialny jest za przeniesienie projektu do żyjącego produktu. (Dzieje się to w fazie implementacji). Zazwyczaj w projekcie pracuje kilku programistów.
Grafik
Osoby odpowiedzialne za grafikę zajmują się przygotowaniem wizji artystycznej naszego produktu. Kolejnym ich zadaniem jest przygotowanie elementów graficznych, takich jak przyciski, tła i inne wizyjne składowe projektu. Graficy w swej pracy bazują na przygotowanych ówcześnie storyboards oraz chartflow.
Fotograf
Podczas pracy nad projektem przydaje się osobą profesjonalnie zajmująca się fotografią oraz jej digitalizacją. Fotograf potrzebuje dostępu do informacji dotyczącej storyboard. Właśnie na tym fotograf opiera swoją wiedzę podczas sesji zdjęciowych do naszego projektu.
Filmowiec
Zależnie od tematu oraz ustaleń z klientem, w naszym projekcie mogą pojawić się materiały promocyjne oraz scenki filmowe. Filmowiec będzie odpowiedzialny za ich przygotowanie, nagranie oraz digitalizację. Filmowiec potrzebuje podobnego dostępnego dostępu do dokumentacji jak fotograf.
Dźwiękowiec
Podobnie jak Fotograf i Filmowiec, dźwiękowiec będzie opierał się głównie na storyboard oraz skryptach. Jego zadaniem będzie przygotowanie ścieżek dźwiękowych do zajęć oraz filmów. Będzie także odpowiedzialny za przeniesienie ich z nośników audio do komputera.
Specjalista od efektów specjalnych
W przypadku, gdy roli tej nie przejęli Filmowiec albo Fotograf w naszym projekcie może pracować także specjalista od efektów specjalnych. Jego zadaniem może być wspomaganie procesów tworzenia animacji, przejść pomiędzy ekranami i innych. Podobnie jak u innych osób zaangażowanych w multimedialne aspekty projektu, jego głównym źródłem wiedzy będzie storyboard oraz skrypty.
Aktor
W przypadku scenek filmowych, czy też nagrań dźwiękowych, proces tworzenia wspomagać będą aktorzy. Zazwyczaj skupiają się oni na skryptach opisujący dialog postaci które będą grali. Część związaną z wizją przejmuje reżyser.
Burza Mózgów
W fazie Planowanie przygotowaliśmy nie wielkie ćwiczenie, w postaci wstępnej burzy mózgów. Ćwiczenie to miało na celu wydobyć kreatywne pomysły drzemiące w naszym zespole. Wyniki zapisywane były na tablicy.
Kolejnym krokiem jest eliminacja niepotrzebnych pomysłów.
Kryteria eliminacji niepotrzebnych pomysłów
Po zakończeniu sesji burzy mózgów otrzymamy listę ad-hoc powstałych pomysłów. Jeśli spotkanie miało charakter techniczny, będzie to lista rozwiązań które możemy zastosować w naszym projekcie. Jeśli zaś spotkanie miało charakter użytkowy, będzie to zbiór pomysłów dotyczących funkcjonalności oraz procesu nauki.
Pamiętajmy, że rozwiązania te były wymyślane w szybkim tempie, bez dokładnego przemyślenia. W ćwiczeniu nie pozwalaliśmy także na ich krytykę, dlatego na pewno wiele z nich będzie nie spójnych, nie zrozumiałych lub nietrafionych.
Do prawidłowego wyszukania najlepszych pomysłów możemy zastosować kilkostopniową eliminację pomysłów w oparciu o poniższe kryteria:
Charakterystyka odbiorcy
Podczas Fazy Planowanie zapoznaliśmy się bliżej z charakterystyką naszego odbiorcy. Ta charakterystyka może pomóc nam w wyeliminowaniu pomysłów, których charakter może według nas się nie przyjąć. Załóżmy, że jedno z założeń powstałych podczas burzy mózgów zakładało dużą ilość tekstów. Jeśli nasz odbiorca to ludzie bardzo młodzi, z pewnością szybko się znudzą czytając długie skrypty. Dlatego taki pomysł nie uzyska aprobaty podczas kategoryzacji pomysłów.
Związki pomysłów z treścią i celem programu
Następnie, warto wyeliminować pomysły, które jedynie abstrakcyjnie nawiązują do tematu szkolenia. Prawdopodobnie znajdziemy także pomysły nazbyt zaawansowe, by móc je zaimplementować, jak i takie, których wprowadzenia do treści szkolenia było by nie potrzebne, gdyż dotyczą wiedzy bardzo ogólnej, niewnoszącej nic do tematu szkolenia.
Dostępność odbiorcy
Kolejną cechą odbiorcy, która poznaliśmy charakteryzując odbiorcę był czas, który będzie w stanie poświęcić na naukę. Korzystając z tego kryterium możemy szacować czas potrzebny użytkownikowi do prawidłowego przysposobienia sobie wiedzy. Jeśli więc któryś z pomysłów zajmował zdecydowanie za dużo czasu, warto zastanowić się nad jego eliminacją. Jeśli jednak takie działanie miałoby spowodować znaczne zubożenie materiału, należy zastanowić się nad przedyskutowaniem z klientem czasu, który zamierzał wygospodarować na naukę.
Restrykcje narzucone przez technologię
Kolejną cechą naszego klienta był dostępny przez niego sprzęt. Klient mógł poza parametrami hardware podać nam także swoją politykę bezpieczeństwa. Znamy także oprogramowanie zainstalowane na komputerach klienta. Posiadając te dane możemy ocenić, które z pomysłów możemy wdrożyć. Innymi restrykcjami poza pamięcią RAM, miejscem na dysku twardym, mocą komputera czy też zainstalowanymi kartami dźwiękowymi są dostępność sieci komputerowej. Ważne może się też okazać czy użytkownik posiada drukarkę, mikrofon czy też głośniki.
Możliwości grupy projektowej
Podczas fazy planowania, badaliśmy dostępne przez nas zasoby. Wiemy zatem, jakich programistów posiadamy, oraz jakie oryginalne oprogramowanie posiadamy. Możemy więc przystąpić do eliminacji pomysłów, których wdrożenie wymagałoby wdrożenia nowych technologii.
Zakończenie procesu eliminacji
Po przeprowadzeniu eliminacji według powyższych powinniśmy
otrzymać kilka pomysłów określających technologiczny aspekt projektu, także kilka
innych dotyczących jego sfery funkcjonalnej. Te pomysły, możemy nazwać "planem
minimum".
Czasami warto przeanalizować jeszcze raz odrzucone konspekty. Pamiętajmy, że
powyższe kryteria nie muszą być zawsze realizowane.
Prototyp
Wielu klientów ma bardzo silną potrzebę naocznego stwierdzenia
czy produkt im się podoba. Nie będą ich interesować nowoczesna technologia,
nie typowe, nowatorskie rozwiązania, jeśli produkt nie będzie "ładny".
Dlatego zawsze warto przygotowywać prototypy oprogramowania, które zamierzamy
wyprodukować.
W dokumencie dotyczącym standardów (Faza planowania) zawarliśmy potrzebne informacje
podstawowe. Znając klienta, standardy oraz jego oczekiwania możemy przystąpić
do tworzenia Prototypu.
Klient zechce zobaczyć rozwiązanie graficzne (layout), jak i interakcję, która
będzie następowała pomiędzy uczniem a programem. W tym celu należy przygotować
kilka głównych funkcji w postaci odpowiedniej do przetestowania.
Jeśli projekt jest nie pewny, i nie chcemy zbyt dużo czasu poświęcać na budowanie prototypów, nie należy rezygnować z nich. Możemy je natomiast bardzo uprościć. Prototyp to świetne narzędzie w metodzie "nie zaskakujmy klienta".
Flowcharting
Graficzna reprezentacja struktury treści
flowchart - diagram, na którym procedura, system albo program komputerowy są reprezentowane przez opisane figury geometryczne, połączone liniami zgodnie z kolejnością wykonywania czynności wynikających z przyjętego algorytmu rozwiązania zadania.
Flowchart pozwala dostrzec istotne etapy algorytmu i logiczne zależności między nimi.
Zależnie od przedstawianego stosowane są różne zestawy figur geometrycznych zwanych blokami, których kształty reprezentują umownie rodzaje elementów składowych.
Przykład struktury pracy asystenta biurowego
Przykład - Odbieranie telefonów w biurze
Podstawowe elementy graficzne flowchartu
 |
początek lub koniec |
 |
proces, input lub output |
 |
punkt decyzyjny |
 |
konektor do następnego ekranu |
Graficzna reprezentacja struktury programu (Określa "przebieg" programu)
Struktura programu jest flowchartem struktury treści jeśli
program jest programem informacyjnym
Struktura programu jest flowchartem analizy zadania jeśli program jest symulacją
lub tutorialem
Różnice między strukturą treści a analizą zadania
zależą od kontekstu
Cztery główne elementy flowchartu
Sekwencja
Decyzja
Powtórzenie (loop)
Wybór (case)
|
Sekwencja |
 |
Decyzja |
 |
Powtórzenie (loop)
|
|
Wybór (case) |
Zalety Flowchart
Efektywna komunikacja: Flowchart pomaga w opisie
logiki programu
Efektywna analiza: Złożone problemy można dokładniej analizować
Poprawna dokumentacja: Efektywna ewaluacja projektu
Efektywne programowanie: Mapa nawigacyjna
Efektywne bieżące utrzymanie i modyfikacje programu
Wady flowchartu
Duże programy o dużej złożoności mają bardzo złożone
flowcharty
Storyboard
Storyboardy są bardzo wydajnym i silnym narzędziem do obrazowania
członkom zespołu oraz klientowi naszych planów projektowych. Przekazują wizualizację
naszych pomysłów, posiadają istotne informacje z punktu widzenia użytkownika.
W prostych programach szkoleniowych praca z Flowcharts może w zupełności wystarczyć.
Dostarczenie jednak nawet kilku ekranów Storyboard zabezpiecza nas przed odrzuceniem
gotowego produktu ze strony klienta. Czym zatem są Storyboard w projekcie eLearning'owym?
To nic innego jak graficzna reprezentacja programu z punktu widzenia użytkownika.
Elementy storyboard
W poniższym dziale przyjrzymy się bliżej elementom storyboard, ich umiejscowieniu i funkcjom. Odpowiemy na pytania: jaki wygląd ma ekran, jak wyglądać będzie i gdzie znajdować się będzie menu, Jaka grafika i animacje zostaną zastosowane.
Przykład Storyboard
Storyboard
x / y |
|||||||||||||||||||||||||
|
wizualizacja projektu |
|||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
Komentarz
|
|||||||||||||||||||||||||
Storyboard - przykłady
Powyższy storyboard pokazuje pierwszy ekran edycji programu
pomagającego "zrozumieć swój samochód".
Na ekranie Tym jest wizyjne odzwierciedlenie interfejsu użytkownika. Zwrócimy
uwagę, autor nie przywiązuje uwagi do jakości rysunku, ważne by wyraźnie wskazywał
najważniejsze elementy. W tym przypadku są to: Tytuł, grafika przedstawiająca
samochód oraz przycisk - strzałka - kierujący nas w "głąb" kursu.
Ekran opisuje także jaka akcja dobędzie się w przypadku uruchomienia przycisku.
Poniżej przykład zaczerpnięty z tej samej aplikacji. Przedstawia on drugi ekran programu "zrozumieć swój samochód".
Zawróćmy uwagę na zdecydowaną różnicę pomiędzy kolejnymi
ekranami Storyboard.
W tym przypadku mamy możliwe dopisanie informacji o ścieżkach muzycznych. (Audio
1, Audio 2).
Możemy też opisać zastosowany przez nas skrypt (jeśli został wykorzystane).
Reasumując. Nie ma stałego, jednego wzoru na opisanie storyboard. Ważne by zamieszczać w nim wszystkie szczegóły dotyczące danego ekranu.
W przypadku kiedy w dokumencie opisującym standardy projektu opisaliśmy podstawowe dane takie jak: czcionka, tło, ścieżka dźwiękowa, powtarzanie ich w każdym kolejnym Storyboard wydaje się być bez celowe. Warto jednak zapisywać wszystkie anomalie - które mogą wystąpić w stosunku do standardu.
Zalety Storyboard
Pomaga w ocenie użyteczności
programu.
Problemy w storyboardzie będą obecne w programie.
Pomyłki i przeoczenia w strukturze mógłbyć wykryte w trakcie tworzenia storyboardu.
Dokument komunikujący idee dla członków zespołu i dla klienta.
Storyboard pokazuje rzeczywiste rozmiary i przybliżony czas pracy użytkownika.
(sitting time)
Storyboard jednego projektu znaczenie przyśpiesza pracę nad następnym projektem.
(wzorzec storyboardu)
Sprawdzenie spójności Storyboard i Flowchart
Do tej pory patrzyliśmy na kolejne elementy naszego projektu. Chcąc sprawdzić jego spójność musimy teraz sprawdzić kolejne ekrany flowchart oraz ich graficzne przedstawienie z pomocą Storyboard. Dobrym sposobem sprawdzenia spójności jest rozłożenie ekranów Storyboard obok siebie, w kolejności ich występowania. Następnie z pomocą flowchart możemy przejść kolejne ekrany edycji, niczym komiks. Nawet jeśli nasz storyboard oraz flowchart był przygotowany na komputerze, podczas badania spójności warto przygotować wersję papierową.
Możemy teraz proces uczenia się "na sucho". Przechodząc kolejne ekrany wchodzimy w rolę odbiorcy. Sprawdzamy przejścia do kolejnych ekranów, możliwe ścieżki przejść, odpowiedzi na pytania (prawidłowe i błędne). Ta czynność może pochłonąć bardzo wiele czasu, daje nam jednak odpowiedź czy przygotowane ekrany zawierają wszystkie zaplanowane przez nas akcję.
Po zakończeniu tego procesu powinniśmy uzyskać odpowiedź dotyczącą:
-brakujących lub nie kompletnych ekranów
-brakujących lub nie prawidłowo działających przeskoków pomiędzy ekranami (np.
z pomocą przycisku, albo zakończenia sekcji)
-powtarzających się ekranów
-zapętlających się akcji
Warto także robić notatki, spisywać wszystkie uwagi i problemy które według nas mogą wystąpić podczas pracy.
Dialogi i skrypty
W projektach eLearningowych, w których występują narracje
lub klipy wideo warto przygotować dialogi oraz skrypty.
Skrypty to po prostu teksty wypowiadanych przez narratora słów. Ich przygotowanie
powinno być bardzo podobne do pisania sztuki lub słuchowiska radiowego. Pamiętajmy
o występujących różnicach między językiem pisanym i mówionym. Skrypty należy
pisać "językiem mówionym", tak by głos lektora brzmiał naturalnie.
Podpisanie umowy z klientem
Jak już wcześniej zaznaczaliśmy, zaangażowanie klienta w pracę nad projektem, to klucz do jego sukcesu. Pamiętajmy aby nigdy nie zaskakiwać klienta, zawsze konsultować z nim najważniejsze zmiany projektowe. Pokazywać mu nasze pomysły, zawsze wysłuchiwać jego opinii .
Podpis klienta to bardzo ważne narzędzie. Często opierając
się na zaufaniu, zapominamy o tym procederze, jest on jednak niezbędny do bezpiecznego
i prawidłowego prowadzenia pracy.
Poniżej przypominamy które z ustaleń należy zakończyć podpisanym przez klienta
dokumentem:
Treść szkolenia i jego wartość merytoryczną.
Sposób nawigacji w oprogramowaniu
Projekt graficzny a w nim obiekty graficzne, tło, kolory
Ścieżkę dźwiękową a w niej utwory i prawa do nich, głos lektora, dżingle
Klipy wideo
Testy, quizy, egzaminy wraz z pytaniami egzaminacyjnymi, sposobem naliczania
punktów itp
Dokument opisujący łączenia z bazami danych
Opis baz danych i ich relacji (*jeśli jest częścią nowo powstałego produktu,
lub jeśli klient przekazuje nam dokument w celu zintegrowania naszego oprogramowania
z bazą)
Dodatkowe wymagania: np. wersja szkolenia przygotowana do wydruki
Niniejszy dokument przybliża sposób prowadznia projektu eLearningowego, opisują fazę ewaluacji projektu eLearningowego.
Zarządzenie Projektem |
Zarzadzanie projektem jest to zbiór czynności wykonywanych
w celu osiagnięcia wyznaczonych celów. Zawiera sie w nim planowanie, harmonogramowanie
i utrzymywanie postępów w czynnościach składających się na projekt. Najprościej
można także powiedzieć, iż jest to nauka o utrzymywaniu ryzyka porażki
na możliwie niskim poziomie w całym cyklu życia projektu. Ryzyko to bierze
się głównie z niepewności związanej z przyszłymi wydarzeniami na każdym
etapie przedsięwzięcia. Z innego punktu widzenia, zarzadzanie projektem można zdefiniować, jako
naukę o definiowaniu i osiąganiu celów przy jednoczesnej optymalizacji
użycia zasobów (np. czasu, pieniedzy, ludzi, itd.). Zarzadzanie projektem to pole działania i odpowiedzialności jednej osoby,
zwanej menadżerem projektu. Taka osoba rzadko uczestniczy bezposrednio
w czynnościach, które prowadzą do doprowadzenia projektu do celu, lecz
raczej sluży jako koordynator, którego zadaniem jest utrzymanie postepów
i współpracy pomiędzy członkami projektu w taki sposób, by zredukować
całkowite ryzyko porażki. W języku polskim przyjeły się głównie dwie nazwy okreslające tą samą
dziedzinę wiedzy, zarządzanie projektami (zamiast zarządzania projektem)
oraz zarządzanie przedsięwzieciami, z czego to pierwsze cieszy się największą
popularnością. Wsród osób zajmujących sie tą nauką zawodowo dużym powodzeniem
cieszy się także angielskojęzyczne sformułowanie Project Management. |
Standard
|
Wspólnie ustalone kryterium, które okresla powszechne, zwykle najbardziej pożadane cechy czegoś, np. wytwarzanego przedmiotu (np. standardem jest, ze każdy współczesnie wytwarzany telewizor wyświetla kolory) czy ludzkiego zachowania (norma kulturowa). Standard to czasem takze podstawowa, najprostsza wersja produktu.
Standard w tym ujeciu jest kryterium, którego nie można zmierzyć (można zmierzyć pewne cechy kryterium, jak np. dopuszczalna dlugość telefonu komórkowego itp., ale samego standardu dokładnie zmierzyć sie nie da), jest płynna granica ustalana na bieżąco zarówno przez grupy konsumenckie, jak i osobnych odbiorców.
|
| Organizacja wirtualna | Nowy typ organizacji charakterystyczny dla wielkich korporacji charakteryzujacy sie tym, ze nie posiadają one własnych srodków produkcji w postaci zakładów produkcyjnych czy nawet pracowników, natomiast wynajmują zewnętrznych podwykonawców, którzy realizują cele organizacji. Zazwyczaj są to organizacje dysponujące znacznym kapitałem i mające już
duże uznanie na rynku. Jej działanie ogranicza się do nadawania produktom
swojej marki, przy czym proces produkcji nie jest przez tego typu organizację
kontrolowany. Charakterystyczna dla tego typu organizacji jest elastycznośc
przy wyborze podwykonawców w skali globalnej i stosunko łatwa delokalizacja
kapitału. Zazwyczaj dla potanienia kosztów produkcji organizacje tego
typu poszukują coraz tańszej siły roboczej w różnych regionach świata,
bardzo często lokując w końcu fabryki w krajach Trzeciego Świata. Naomi
Klein w swojej pozycji No Logo ostro skrytykowała tego typu organizacje,
między innymi firmy Reebok, Nike, czy Microsoft za brak odpowiedzialności
za warunki pracy oferowanych przez podwykonawców wynajmowanych przez te
firmy. |
| Planowanie | Faza projektu w której badamy własne zasoby, przygotowujemy ofertę, nakreślamy budżet. |
Klient |
Osoba lub organizacja dla której świadczona jest usługa. Klient wewnętrzny - to osoba lub organizacja zamawiająca usługę znajdująca się w tej samej firmie. W przypadku gdy oprogramowanie tworzymy dla siebie, stajemy się klientem wewnętrznym. Klient jest osobą opłacającą projekt. |
| Użytkownik
|
Osoba lub grupa osób, które finalnie będą użytkowały oprogramowanie. Użytkownikem szkolenia eLearningowego może być wyspecjalizowana grupa ludzi, lub też bliżej nie określona. Np. segment rynku lub "wszyscy studenci" |
Nauka w trybie mieszanym (blended-learning) |
Ten terminy zamiennie opisują podejście do kształcenia, w którym łączy się metodę w klasie i metodę na odległość, w której instruktor lub tutor spotyka się ze swoimi uczniami (albo metodą twarzą w twarz, albo przy użyciu środków technicznych), a baza zasobów zawierająca materiały i ćwiczenia jest udostępniana uczniom. Dodatkowo mógłbyć wykorzystywane niektóre z metod eLearning. |
System Zarządzania Uczeniem się (Learning Management System) |
Zestaw narzędzi eLearningowyxch dostępnych poprzez wspólny administrowany interfejs. System zarządzania uczeniem się może być traktowany jako platforma na której zbiera się i używa kursów on-line i komponentów kursów. |
| Storyboard | Scenorys (ang. storyboard), scenopis obrazkowy - seria obrazów i szkiców, będących wskazówkami przy filmowaniu dla reżyserów, scenografów, operatorów, aktorów i montażystów. |
Komunikacja synchroniczna |
Komunikacja w czasie rzeczywistym (np. chat). |
| Flowchart | Schemat blokowy (ang. block diagram, flowchart) - diagram,
na którym procedura, system albo program komputerowy są reprezentowane przez
opisane figury geometryczne, połączone liniami zgodnie z kolejnością wykonywania
czynności wynikających z przyjętego algorytmu rozwiązania zadania.
Schemat blokowy pozwala dostrzec istotne etapy algorytmu i logiczne zależności między nimi. Zależnie od przedstawianego stosowane są różne zestawy figur geometrycznych zwanych blokami, których kształty reprezentują umownie rodzaje elementów składowych. |
| Prototyp | urządzenie, obwód lub program zaprojektowany i zbudowany w celu zademonstrowania zdolności do budowy urządzenia docelowego. Podczas budowy prototypu inżynierowie wprowadzają pierwszy raz w życie swoje nowe pomysły. Jeżeli uda się zbudować prototyp i on działa, to można przystąpić do budowy finalnego urządzenia. Często podczas projektowanie niektóre rzeczywiste zjawiska związane z konstrukcją zostają pominięte. Prototyp pozwala na odkrycie ich nieznanego wpływu i wprowadzenie korekt. Jeżeli pierwszy prototyp nie jest udany, to buduje się kolejne, aż do uzyskania w urządzenia spełniającego założenia. Prototyp może fizycznie bardzo różnić się od ostatecznego urządzenia, jeżeli chcemy sprawdzić tylko pewną jego cechę. |
| Burza mózgów | technika wywodząca się z psychologii społecznej, która ma na celu doskonalenie decyzji grupowych. Burza mózgów jest również formą dyskusji dydaktycznej, wykorzystywaną jako jedna z metod nauczania. Zalicza się ją wówczas do metod aktywizujących, która stanowi podgrupę metod problemowych. |
Komunikacja asynchroniczna |
Komunikacja w czasie opóźnionym (np. email). |
Literatura podstawowa i poszerzająca
Portal Wikipedia - www.wikipedia.pl |
Alessi Stephen M., Trollip Stanley R. (2001) "Multimedia for Learning - Methods and Development" |
Rosenberg Marc J. (2001) "E-Learning - Building successful online learning in Your organization - strategies for delivering knowladge in the digital age" |
Schank, Roger C. (2002) "Designing World-Class E-learning" |
Kitaoka Vance,Shea Andrea,Uehara Randal (1998) "Creating a Storyboard for Video Production" www2.hawaii.edu/~ricky/etec/storyboarding.html |
|
Oprogramowanie do tworzenia Storyboard |
Kruse Kevin "Creating
Scripts and Storyboards for e-Learning" |
Czy projektowanie szkolenia eLearningowego może odbyć się bez udziału klienta?