Concurrent E-Learning Design

Transkript

1 FOR Concurrent E-Learning Design Arbeidsdokument Versjon 0.5 Side 1

2 Revisjonshistorie Denne revisjonshistorien inneholder en oversikt over forskjellige versjoner av denne prosessbeskrivelsen og den skal fjernes når prosessbeskrivelsen er ferdig utarbeidet. Versjon Dato Forfatter(e) Beskrivelse av endring aug Knut Arne Strand Første versjon av prosessbeskrivelse. Må betraktes som et arbeidsdokument hvor tanker og ideer beskrives for senere evaluering. Basert på møte mellom Tor Atle Hjeltnes, Monica Storvik, Geir Maribu, Thorleif Hjeltnes og Knut Arne Strand aug Knut Arne Strand Oppdatert etter møte mellom Tor Atle Hjeltnes, Monica Storvik, Geir Maribu, Thorleif Hjeltnes, Arvid Staupe og Knut Arne Strand den 24. August 2009 ( ). Oppdateringene er gjort i avsnitt 1 til og med 7, siden det var denne delen av dokumentet som ble behandlet i ovennevnte møte sept Knut Arne Strand Oppdatert etter møte mellom Tor Atle Hjeltnes, Monica Storvik, Geir Maribu, Thorleif Hjeltnes, Arvid Staupe og Knut Arne Strand den 31. august 2009 ( ). Oppdateringene er gjort i avsnitt 8 og ut sept Monica Storvik Tekst til punkt 5.1 samhandlingsrommet lagt inn nov Monica Storvik Oppdatert etter at vi har jobbet videre med de ulike modellene. Nytt punkt 5.2 Mindjet Manager tankekart lagt inn. Innhold Concurrent E-Learning Design... 1 Arbeidsdokument... 1 Revisjonshistorie Om metoden Concurrent E-Learning Design (CCeD) Om prosessen i CCeD Oversikt over prosessen Beskrivelse av prosessen Benevnelse for roller og funksjoner Beslutningspunkter Beskrivelse av arbeidssesjonenes samhandlingsteam Modeller fra CCeD prosessen Versjon 0.5 Side 2

3 4.5 Delprosesser Infrastruktur og samhandlingsrom Samhandlingsrommet Rommets oppbygging Arbeidsstasjoner og team Tilrettelegger og sesjonssekretær Mindjet MindManager Input & inngangskriteria Output & utgangskriteria Delprosesser og aktiviteter Initieringsprosessen Sesjonsplanleggingsprosessen Sesjonsgjennomføringsprosessen Avslutningsprosessen Sjekkliste for bruk av prosessen (Skal utarbeides) Prosessevaluering Verktøy (Skal utarbeides) Maler og dokumenter Kontroll og eierskap for prosessen (Skal vurderes) Spesielle retningslinjer (Skal utarbeides) Kompetanse- og opplæringsbehov Aksjonsliste Vedlegg A Generelt om modellering av prosesser Grunnelementene i BPMN Flytobjekter Koblingsobjekter Rollebånd (Basseng og svømmebaner) Artefakter En enkel forretningsprosess i BPMN Versjon 0.5 Side 3

4 1. Om metoden Concurrent E-Learning Design (CCeD) ConCurrent e-learning Design (CCeD) er en metode for design- og utvikling av e-læring. Metodens hovedfokus er å involvere alle relevante interessenter, i en integrert prosess, hvor tverrfaglig samhandling og utstrakt bruk av egnede dataverktøy og programvare står sentralt. Sentrale elementer i metoden er: En prosessbeskrivelse som definerer prosessens sentrale egenskaper fra begynnelse til slutt. Et tverrfaglig team som settes sammen av alle relevante interessenter. Interessentene vil representere forskjellige roller eller kompetanseområder og ha spesifikt ansvar for sine respektive kompetanseområder i prosjektet. Modellbasert design- og utvikling som innebærer at forskjellige delmodeller til sammen utgjør en helhetlig designmodell for e-læringstilbudet. Et samhandlingsrom hvor hele designteamet gjennomfører integrerte arbeidssesjoner. Samhandlingsrommet er utstyrt med nødvendig datautstyr og programvare for effektiv utveksling av modellelementer på tvers av alle sesjonsdeltakere. Arbeidssesjonene styres av en tilrettelegger (eng. facilitator ), som bidrar til at nødvendig informasjon blir utvekslet mellom aktuelle interessenter, slik at designteamet i størst mulig grad når definerte mål for den aktuelle arbeidssesjonen. En infrastruktur som sikrer alle involverte prosjektdeltakere nødvendige verktøy og relevant informasjon gjennom prosjektet. 2. Om prosessen i CCeD Prosessen skal primært benyttes ved design og utvikling av nye e-læringstilbud for eksterne oppdragsgivere. Metoden og prosessen kan imidlertid også benyttes for videreutvikling og redesign av eksisterende e-læringstilbud eller andre mer tradisjonelle undervisningsopplegg som campusfag eller bedriftskurs. Prosessen skal på en kostnadseffektiv måte, bidra til best mulig kvalitet og forutsigbarhet for alle involverte parter, når e-læringstilbud designes, utvikles og leveres til oppdragsgiveren. Prosessen skal definere hvilke input vi har til et CCeD prosjekt, hvilke roller som inngår, hvilke arbeidsoppgaver som skal utføres og hva som skal produseres eller hvilke output vi har fra CCeD prosjektet. Versjon 0.5 Side 4

5 3. Oversikt over prosessen Concurrent E-Learning Design Fig. 1 - Overordnet prosessbeskrivelse for ConCurrent e-learning Design (CCeD) prosessen. 4. Beskrivelse av prosessen Denne prosessbeskrivelsen skal samle og dokumentere prosessen på en overordnet og praktisk måte. I figur 1 vises en overordnet beskrivelse hvor det framgår at prosessen består av tre faser og fire del-prosesser. Prosessen beskriver hvilke aktiviteter som skal utføres i forbindelse med et CCeD prosjekt og hvilke beslutningspunkter som gjelder. Prosessen forutsetter innledende aktiviteter hvor prosjektets bakgrunn, hensikt, mandat og forutsetninger dokumenteres i et prosjektdirektiv. Prosessens endelige output er et detaljert designdokument for det nye e-læringstilbudet som inneholder alle modeller og all informasjon som er nødvendig for å utvikle og levere systemet til oppdragsgiveren. 4.1 Benevnelse for roller og funksjoner I CCeD-prosessen skiller vi mellom operative roller (de som utfører produktivt arbeid i forhold til prosjektleveransene) og besluttende roller (de som foretar formelle beslutninger i prosjektene). Her følger en oversikt over henholdsvis operative og besluttende roller. Versjon 0.5 Side 5

6 4.1.1 Operative roller og funksjoner Rolle Beskrivelse Prosjektleder Eksempel Prosjektlederen har ansvaret for å lede prosjektet fra begynnelse til slutt. Prosjektlederrollen skal være i tråd med tradisjonell prosjektledelse som vi også kjenner fra andre typer prosjekter. Prosjektlederen overlater styringen av arbeidssesjonene til tilretteleggeren og utøver selv prosjektadministrativt arbeid i disse arbeidssesjonene. Ansvar Gjennomføre prosjektet innenfor gitte rammer. Planlegging, ledelse og oppfølging. Ferdigstille og overlever alle leveranser/ delleveranser med riktig sammensetning. Sikre at organiseringen er hensiktsmessig, at prosessen følges, at arbeidssesjonene planlegges og gjennomføres, at arbeidsmiljøet ivaretas og at hjelpemidler og verktøy benyttes riktig. Identifisere/ innføre forbedringstiltak. Foreslå avtaleendringer. Avtale om ressurser. Rapportere om prosjektets status til styringsgruppen og andre interessenter. Tilrettelegger (Eng. facilitator) Myndighet Styring av tildelte ressurser. Endre prosjektets organisering ved behov. Organisere arbeidssesjoner og møtevirksomhet. Forhandle med kundeansvarlig dersom dette delegeres av leverandøransvarlig. Godkjenne eller avvise leveransene i prosjektet. Eksempel Tilretteleggeren er ansvarlig for å gjennomføre arbeidssesjonene i samhandlingsrommet. Dette er en dedikert rolle som benyttes i arbeidssesjonene. Vedkommende bør ha god kompetanse i forhold til alle aspekter ved utvikling av e-læringstilbud slik at man oppnår god, relevant og tverrfaglig samhandling i arbeidssesjonene. Ansvar Planlegge, gjennomføre og evaluere arbeidssesjonene i prosjektet. Skal bidra til relevant informasjonsutveksling mellom alle deltakerne i arbeidssesjonene slik at man i størst mulig grad når målene for hver arbeidssesjon. Beslutte (i samråd med andre sesjonsdeltakere) i forhold til tekniske og funksjonelle egenskaper. Versjon 0.5 Side 6

7 Rolle Sesjonssekretær Beskrivelse Myndighet Organisere og lede arbeidssesjonene. Eksempel Dette er en person som fungerer som tilretteleggerens høyre hånd i arbeidssesjonene. Vedkommende kan bidra med teknisk gjennomføring av arbeidssesjonene (for eksempel svitsjing mellom forskjellige skjermer og arbeidsstasjoner). Videre sørger vedkommende for å notere eventuelle beslutninger som fattes i løpet av arbeidssesjonene samt å skrive sesjonsreferat. Ansvar Å sikre at arbeidssesjonene funger teknisk. Å notere ned alle beslutninger som treffes i løpet av sesjonene. Å skrive endelig sesjonsreferat som formidles til alle sesjonsdeltakere. Fagekspert(er) (Eng. Subject Matter Expert) En nøkkelrolle for utvikling av den faglige modell (kunnskapsmodellen). Den som er ansvarlig for faglig team. Myndighet Delta i arbeidssesjonene. Eksempel Den eller de personene som er ansvarlig for faglig innhold i e-læringstilbudet som skal utvikles. Vedkommende skal beskrive den faglige modellen (kunnskapsmodellen) for e-læringstilbudet som skal utvikles. Den faglige modellen beskrives med valgt programvareverktøy. Kunden har gjerne en representant som fungerer som fagekspert i prosjektet. Ansvar Definere relevant faglig innhold. Finne aktuelle kilder til faglig innhold. Foreslå organisering for faglig innhold. Gjennomføre kontekstanalyse (hvilke case er relevant). Gjennomføre innholdsanalyse (hvilket faglig innhold trengs). Å definere målene for e-læringstilbudet: o Læringsmål skal beskrives slik at de er etterprøvbare og at de indikerer hvordan læringen skal foregå. o Nåværende kompetansenivå eller forventet bakgrunn for studentene må også beskrives. Svare på spørsmål som andre teammedlemmer (f.eks. pedagogisk designer) måtte ha om faglig innhold. Pedagogisk designer(e) (eng. Instructional Designer) En nøkkelrolle for utvikling Myndighet Foreta endelig beslutning i forhold til faglig innhold. Eksempel Den eller de personene som er ansvarlig for det pedagogiske opplegget i e-læringstilbudet som skal utvikles. Vedkommende skal beskrive den pedagogiske modellen (lærings- Versjon 0.5 Side 7

8 Rolle av den pedagogiske modellen. Den som er ansvarlig for pedagogisk team. Teknisk leveranseansvarlig En nøkkelrolle for utvikling av teknisk leveransemodell. Den som er ansvarlig for teknisk leveranseteam. Beskrivelse aktiviteter) som skal benyttes i forbindelse med e-læringstilbudet. Den pedagogiske modellen beskrives med valgt programvareverktøy. Lærer/instruktør er gjerne representert som pedagogisk designer. Ansvar Overordnet ansvar for pedagogisk designer er å tilfredsstille behovene til studentene og instruktørene. Å sørge for at det utvikles et pedagogisk opplegg som er: o Tilstrekkelig kostnadseffektiv. o Pedagogisk effektivt. o Appellerende til så vel student som instruktør. Gjennomføre aktivitetsanalyse o Hvilke læringsaktiviteter. o Vurdering av studentene underveis og til slutt. o Evaluering av e-læringstilbudet under veis (formativ evaluering) og til slutt (summativ evaluering). Myndighet Foreta endelig beslutning i forhold til pedagogisk opplegg. Dette inkluderer: o Læringsaktiviteter o Vurderingsaktiviteter o Evalueringsaktiviteter (formativ/ summativ) Eksempel Den som er ansvarlig for den tekniske leveransen som prosjektet definerer. Dette går på å definere teknisk leveranseplattform for e-læringstilbudet som skal utvikles. IT- medarbeidere, både på kundens og leverandørens side, kan typisk jobbe med teknisk leveranse i prosjektet. Ansvar Overordnet ansvar for teknisk leveranse. Å utarbeide en modell for den tekniske leveransen. Dette inkluderer: o Å definere teknisk plattform for e-læringsopplegget. o Å definere hvilke medier som skal benyttes (synkron, asynkron, lyd, bilde, animasjoner, presentasjoner, leksjoner, programvareløsninger, etc.) Forretningsansvarlig(e) En nøkkelrolle i forhold til å sikre kvalitet på alle nivå i prosjektet samt å ivareta Myndighet Foreta endelig beslutning i forhold til teknisk leveranse. Eksempel Vedkommende er ansvarlig for å sikre de forretningsmessige og administrative forhold, samt kvalitetssikringsarbeidet i prosjektet. Dette går på å sikre at prosjektet opererer innenfor den definerte rammen av tid, kostnader og kvalitet. Videre skal Versjon 0.5 Side 8

9 Rolle forretningsmessige behov på vegne av kunde og leverandør. Den som er ansvarlig for forretningsteamet. Lærer(e)/ instruktør(er) Beskrivelse forretningsansvarlig sørge for at nødvendige administrative forhold vedrørende utvikling og leveranse av e-læringstilbudet blir ivaretatt. Prosjektlederen inngår typisk som forretningsansvarlig i arbeidssesjonene. Ansvar Å definere eventuelle avtaler og rettigheter (IPR) som skal gjelde for e-læringstilbudet som utvikles. Kvalitetssikring: o På prosjektadministrativt nivå. o På resultatnivå. Myndighet Foreta endelig beslutning i forhold til forretningsmessige og administrative forhold, samt kvalitetsarbeid. Herunder ligger utvikling og vedlikehold (endringer) av prosjektets planer. Eksempel Dette er lærere eller instruktører som skal levere e-læringstilbudet når det er ferdig utviklet. Disse ressursene kan typisk inngå i fagligog/eller pedagogisk team i arbeidssesjonene. Ansvar Sikre at det utvikles et pedagogisk opplegg som det er forsvarlig å levere. Bidra sammen med fagekspert(er), pedagogisk designer(e), og andre teammedlemmer for å sikre best mulig resultat. Student(er) Myndighet Delta i arbeidssesjonene. Delta i beslutningsprosessen sammen med nøkkelrollene og øvrige deltakere. Eksempel En eller flere representanter som skal formidle den lærendes behov i prosjektet. Dette er framtidige studenter på e-læringstilbudet som utvikles og som prosjektdeltakere skal de sikre at opplegget som utvikles tilfredsstiller deres behov. Studentene kan typisk inngå i pedagogisk- og/eller teknisk leveranseteam i arbeidssesjonene. Ansvar Formidle behov og krav på vegne av sin gruppe. (Både faglig, pedagogisk, teknisk og administrativt.) Myndighet Delta i arbeidssesjonene. Delta i beslutningsprosessen sammen med nøkkelrollene og øvrige deltakere. Versjon 0.5 Side 9

10 Rolle Kunde Beskrivelse Eksempel Kundene kan delta med flere personer i prosjektet alt etter eget ønske og behov. Kunden er i denne sammenheng en eller flere person(er) som skal bidra til å kvalitetssikre e-læringstilbudet som utvikles, sett fra kundenes ståsted. Kundens representanter kan typisk bidra med faglige krav, pedagogiske krav, krav til teknisk leveranse og forretningsmessige krav. Ansvar Formidle alle krav på vegne av kunden(e). Myndighet Delta i arbeidssesjonene. Delta i beslutningsprosessen sammen med nøkkelrollene og øvrige deltakere. Tabell I Rollebeskrivelser for operative roller Besluttende roller og funksjoner Rolle Beskrivelse Leverandøransvarlig Eksempel Den som eier og godkjenner prosjektet på leverandøren sin side. Dette kan typisk være lederen ved instituttet/ fakultetet (dekan). Vedkommende er normalt ikke utøvende i prosjektet, men involvert i forhold til prosessens beslutningspunkter og medlem av prosjektets styringsgruppe. Ansvar Bedømme lønnsomhet og sørge for finansieringen av prosjektet. Opprette eventuelle avtaler. Sikre at prosjektet svarer til kundens forventninger. Ta hånd om økonomiske konsekvenser. Vurdere prosjektets lønnsomhet og måloppnåelse. Kundeansvarlig Myndighet Godkjenne prosjektets mandat som beskrives i prosjektdirektivet. Starte prosjektet. Håndtere eventuelle foretningsmessige relasjoner. Avslutte prosjektet. Eksempel Den på kundens side som er ansvarlig for oppdraget og finansieringen av det. Dette kan typisk være en leder hos kunden som er overordnet ansvarlig for oppdragsbestillingen. Vedkommende er normalt ikke utøvende i prosjektet, men involvert i forhold til prosessens Versjon 0.5 Side 10

11 Rolle Beskrivelse beslutningspunkter og medlem av prosjektets styringsgruppe. Ansvar Utarbeide effektmål på vegne av kunden og sikre at man når disse ved anvendelse av prosjektets resultat. Finansiere prosjektet. Opprette eventuelle avtaler. Ta hånd om økonomiske konsekvenser. Vurdere nytten ved anvendelse av resultatet. Styringsgruppe En besluttende funksjon som fylles av flere personer Myndighet Godkjenne prosjektets mandat. Starte prosjektet. Håndtere eventuelle foretningsmessige relasjoner. Eie og forvalte resultatet. Avslutte prosjektet. Eksempel Styringsgruppen settes sammen av ansvarlige personer på leverandørsiden (leverandøransvarlig) og kundesiden (kundeansvarlig). Videre deltar prosjektlederen i styringsgruppemøtene. Styringsgruppen har det overordnede og formelle ansvaret i prosjektet og den er involvert i godkjennelse av alle beslutningspunkter. Styringsgruppen kan godkjenne et beslutningspunkt uten at det arrangeres dedikerte styringsgruppemøter, men prosjektlederen skal sørge for at styringsgruppedeltakerne gir sin tilslutning till alle beslutningspunktene i prosessen. (Se avsnitt 4.2 for en oversikt over prosessens beslutningspunkter.) Ansvar Sikre at prosjektets resultater blir i tråd med bestillingen. Tilføre prosjektet de ressurser som kreves. Sikre at prosjektlederen har god kontroll og at prosjektet når målene. Myndighet Tilsette prosjektlederen og prosjektgruppen. Godkjenne alle beslutningspunkter (BP1 BP4) i prosjektet. Initiere prosjektanalyser. Avslutte prosjektet. Tabell II Rollebeskrivelser for besluttende roller. Versjon 0.5 Side 11

12 4.2 Beslutningspunkter Her følger en oversikt over beslutningspunktene i CCeD prosessen: BP1 - Godkjennelse av prosjektdirektivet. Dette er en godkjennelse til å bruke ressurser på å planlegge prosjektet basert på forutsetningene og rammebetingelsene som er beskrevet i prosjektdirektivet. BP1 er altså et beslutningspunkt hvor styringsgruppen gir en godkjennelse i forhold til å gjennomføre forberedelsesfasen (utarbeide plan for prosjektet), basert på prosjektdirektivet. BP2 - Godkjennelse av prosjektplanen. Dette er en godkjennelse av prosjektplanen hvor prosjektets formål og mål, kostnadsbudsjett, tidsplan, ressursplan og leveranseplan er beskrevet. BP2 er altså en godkjennelse til å gjennomføre prosjektet basert på prosjektplanen som er utarbeidet i initieringsprosessen. Ved å godkjenne dette beslutningspunktet gir styringsgruppen sin tilslutning til at prosjektlederen kan gjennomføre hele prosjektets gjennomføringsfase. Gjennomføringsfasen inkluderer en serie med arbeidssesjoner (omfang skal framgå av prosjektplanen) og kan strekke seg over lang tid. Styringsgruppen kan eventuelt kreve statusrapportering og statusmøter i denne fasen, for på denne måte å forsikre seg om at prosjektets leveranser er i henhold til leverandøren(e) og kunden(e) sine ønsker. BP3 - Avslutte sesjonsarbeidet. Dette er en godkjennelse til å avslutte arbeidssesjonene i prosjektet. Dette innebærer at man ikke trenger å gjennomføre flere arbeidssesjoner for å oppnå ønskede resultater i prosjektet. BP3 er altså en godkjennelse til å gå over til avslutningsfasen. Denne beslutningen skal være basert på resultatene som er produsert i gjennomføringsfasen og styringsgruppen godkjenner med dette prosjektets leveranseomfang. BP4 - Avslutte prosjektet. Dette er en godkjennelse til å avslutte prosjektet og oppløse prosjektgruppen. Endelig designdokument og sluttrapport for prosjektet skal være ferdig utarbeidet før dette beslutningspunktet kan godkjennes. Dette er prosessens siste beslutningspunkt som skal være basert på endelig designdokument og sluttrapport for prosjektet. 4.3 Beskrivelse av arbeidssesjonenes samhandlingsteam Arbeidssesjonene i CCeD prosjektene (se gjennomføringsprosessen) gjennomføres ved at forskjellige team fokuserer på bestemte arbeidsoppgaver i arbeidssesjonene. Her følger en oversikt over disse teamene. Team Beskrivelse og oppgaver Verktøy Sesjonsledelse (2 personer) Dette teamet består av tilretteleggeren (eng. facilitator) og sesjonssekretæren. Deres oppgave er å sørge for god gjennomføring av sesjonene. For hver sesjon skal man ha en oppstartssekvens (som formidler målene for sesjonen), gjennomføring (hvor tilretteleggeren skal sikre god og relevant samhandling mellom alle involverte parter i arbeidssesjonen) og en evalueringssekvens (debrief) hvor sesjonsresultatene reflekteres over og Sesjonsplanen. Styring av samhandlingen og utveksling av modeller, informasjon, etc. Versjon 0.5 Side 12

13 Team Beskrivelse og oppgaver Verktøy evalueres. Teamet ledes av tilretteleggeren. Faglig (Inntil 4 personer) Pedagogisk (Inntil 4 personer) Teknisk leveranse (Inntil 4 personer) Forretning (Inntil 4 personer) Dette teamet består av de personene som skal utvikle den faglige modellen for e-læringstilbudet. Teamet ledes av faglig ekspert (eng. subject matter expert). Kan for øvrig bestå av student(er), instruktør(er), kunderepresentant(er), etc. Dette teamet består av de personene som skal utvikle den pedagogiske modellen for e-læringstilbudet. Teamet ledes av pedagogisk designer (eng. instructional designer). Kan for øvrig bestå av student(er), instruktør(er), kunderepresentant(er), etc. Dette teamet består av personene som skal utvikle og beskrive teknisk leveransemodell. Teamet ledes av teknisk leveranseansvarlig. Kan for øvrig bestå av IT medarbeidere, studenter, instruktører, kunderepresentanter, grafiske designere, utviklere, etc. Dette teamet er ansvarlig for at de forretningsmessige og administrative behov tilfredsstilles i prosjektet samt for kvalitetssikring. Teamet ledes av prosjektets forretningsansvarlig. Kan for øvrig bestå av prosjektlederen, leverandøransvarlig, kundeansvarlig, økonomiansvarlig, kvalitetsansvarlig, kunderepresentant(er), etc. Tabell III Beskrivelse av team for arbeidssesjoner. Vi benytter MindMap (tankekart) med forhåndsdefinert mal. Vi benytter MindMap (tankekart) med forhåndsdefinert mal. Vi benytter MindMap (tankekart) med forhåndsdefinert mal. Fra dette tankekartet kan man henvise til prototyper av nye løsningsforslag, eksisterende løsninger, etc. Vi benytter MindMap (tankekart) med forhåndsdefinert mal. Fra dette tankekartet kan man henvise til planverk, kalkyler, rapportering, etc. 4.4 Modeller fra CCeD prosessen Dette avsnittet inneholder en overordnet beskrivelse av de fire modellene som utvikles i forbindelse med et CCeD prosjekt. CCeD prosessens endelige output er et designdokument som også henviser til hver av disse fire modellene. Det finnes flere aktuelle verktøy som kan benyttes til å dokumentere de forskjellige modellene, og i forbindelse med denne prosessbeskrivelsen har vi valgt å benytte Tankekartet MindManager fra Mindjet til dette formålet. Faglig modell Den faglige modellen er en kunnskapsmodell (eng. Knowledge Model) som inneholder hva slags kunnskap og ferdigheter studentene skal tilegne seg når de gjennomfører det aktuelle e-læringstilbudet. Den faglige modellen utarbeides med utgangspunkt i MindManager malen MAL Faglig modell.mmat, og er en oversikt over kunnskapen og ferdighetene som er relevant for e-læringstilbudet. Versjon 0.5 Side 13

14 Pedagogisk modell Den pedagogiske modellen (eng. Instructional Model) inneholder de pedagogiske aktivitetene som studenter og faglærer/ instruktør skal gjennomgå i forbindelse med e-læringstilbudet. Den pedagogiske modellen utarbeides med utgangspunkt i MindManager malen MAL Pedagogisk modell.mmat, og er en oversikt over pedagogiske aktiviteter som skal inngå som en del av e-læringstilbudet. Teknisk leveransemodell Den tekniske leveransemodellen (eng. Technical Delivery Model) inneholder en oversikt over hvordan de tekniske leveransene skal foregå, hvilke teknologier og verktøy som skal benyttes, etc. Den tekniske leveransemodellen utarbeides med utgangspunkt i MindManager malen MAL Teknisk leveransemodell.mmat. Forretningsmodell Forretningsmodellen (eng. Business Model) er sammensatt av økonomiske forhold (budsjett og forbruk), ressursmessige forhold (plan og forbruk), tidsmessige forhold (plan og leveranser), rettigheter (IPR) og avtaleverk, kvalitetssikring (planer og resultater), etc. Forretningsmodellen utarbeides med utgangspunkt i MindManager malen MAL Forretningsmodell.mmat. 4.5 Delprosesser CCeD prosessen består av følgende delprosesser og hovedaktiviteter: 1. Initiering: Her planlegges prosjektet med utgangspunkt i prosjektdirektivet og avklaringer med aktuelle interessenter. Man etablerer en infrastruktur for prosjektet og man definerer prosjektorganiseringen, tidsplanen, ressursplanen, etc. som inngår i prosjektplanen. 2. Sesjonsplanlegging: Her detaljplanlegges prosjektet inklusive alle arbeidssesjoner. Dette oppsummeres i en sesjonsplan som inneholder alle sesjoner, når de skal foregå, hvem som skal delta, hvilke roller de forskjellige deltakerne skal ha, etc. 3. Sesjonsgjennomføring: I denne delprosessen gjennomføres en serie med planlagte arbeidssesjoner i et spesialisert samhandlingsrom. Tiden mellom hver arbeidssesjon benyttes til etterarbeid (gjennomførte sesjoner) og forberedelse (nye sesjoner). De fire modellene (1-faglig modell, 2-pedagogisk modell, 3-teknisk leveransemodell og 4-forretningsmodell) utarbeides i denne delprosessen. 4. Avslutning: I denne delprosessen ferdigstilles resultatene inklusive aktuelle modeller og det endelige designdokumentet. Videre utarbeides en sluttrapport som skal godkjennes før prosjektet kan avsluttes. 5. Infrastruktur og samhandlingsrom Dette avsnittet gir en kort beskrivelse av infrastrukturen som CCeD prosjektet skal benytte seg av. Dette innbefatter beskrivelse av samhandlingsrommet, Mindjet Mind Manager 8 og evt andre støttesystemer. Versjon 0.5 Side 14

15 5.1 Samhandlingsrommet Fig. 2 Oversikt over samhandlingsrommet hvor arbeidssesjoner foregår. Rommets oppbygging Samhandlingsrommet består av fire arbeidsgrupper. En arbeidsgruppe består av fire ordinære arbeidsstasjoner og en felles monitor. De fire gruppedeltakerne benytter arbeidsstasjonene som ordinære PCer, og på den felles monitoren kan de vise skjermbildene sine til hverandre. Dette hjelper dem til effektiv samhandling. I området mellom de fire arbeidsgruppene plasseres en arbeidsstasjon for tilrettelegger og en arbeidsstasjon for sesjonssekretær. I tillegg består samhandlingsrommet av to felles videoprosjektorer og tilhørende lerret. For å få til en effektiv samhandling under arbeidssesjonene må alle deltagerne kunne vise sitt skjermbilde på en hvilken som helst storskjerm, felles monitor eller PC. Dette kan gjøres på to måter; enten ved videosvitsjing (hardware) eller ved at en arbeidsstasjon sender skjermbildet sitt til en storskjerm, felles monitor eller annen PC over et datanettverk (software). Den første løsningen ved å benytte videosvitsj er relativt kostbar, mens svitsjing ved hjelp av programvare gir en langt rimeligere løsning. Arbeidsstasjoner og team Hver arbeidsstasjon må være installert med spesialistprogramvare tilpasset den enkelte, slik at en er i stand til å utføre de samme arbeidsoppgavene i samhandlingsrommet som ellers i arbeidshverdagen. Versjon 0.5 Side 15

16 De ulike teamene bør settes sammen og tilpasses oppgaven som skal løses. For design og utvikling av nye e-læringstilbud har vi valgt følgende fire team: Team A - Forretning Team B - Leveranse Team C - Pedagogikk Team D Faglig De ulike teamene har ansvar for hvert sitt delområde beskrevet i de ulike delmodellene. Selv om utgangsposisjonen for plassering av deltakerne i sesjonene er knyttet til hvilket område de skal jobbe med, kan det i enkelte tilfeller være hensiktsmessig med en plassering på tvers av teamene. Det vil være tilretteleggers oppgave å omstrukturere på gruppene slik at oppgavene blir løst best mulig. Tilrettelegger og sesjonssekretær Tilretteleggeren og sesjonssekretæren er plassert midt i rommet og er ansvarlig for å gjennomføre arbeidssesjonene i samhandlingsrommet. Tilretteleggeren er ansvarlig for svitsjingen, dvs det å få riktig skjermbilde opp på riktig storskjerm, PC eller felles monitor. I tillegg er hans oppgave å få samarbeidet mellom de ulike fagpersonene til å fungere, samt være i stand til å finne riktig tidspunkt for når beslutninger er klare til å tas. Dette er svært viktig for at en skal oppnå ønsket progresjon i arbeidssesjonene. Sesjonssekretæren skal hjelpe tilretteleggeren med det tekniske samt bistå med notater for beslutninger som tas. 5.2 Mindjet MindManager - tankekart I CCeD metoden benytter vi Mindjet Mind Manager og Mindjet Connect for å utarbeide maler og dokumenter som skal benyttes ved utvikling av e-lærinstilbud. Mindjet Mind Manager er et visuelt planleggingsverktøy som gjør at en effektivt kan fange opp, organiserer og kommunisere informasjon og ideer. Informasjon, ideer og tanker organiseres i tankekart som ser ut som et tre med et hovedtema i midten med mange underkategorier som springer ut i grener fra dette hovedtemaet. Grene kan igjen ha grener (underkategorier) og alle grenene er lette å legge til eller flytte på. Det er videre mulig å eksportere tankekartene til MS office filer. Med Mindjet Connect kan deltakerne jobbe i sann tid uavhengig av plassering. 6. Input & inngangskriteria Input til denne prosessen er: Et prosjektdirektiv som beskriver prosjektets bakgrunn, hensikt, mandat og forutsetninger. I noen tilfeller kan prosessen ta inn føringer fra oppdragsgiver eller føringer fra leverandør, men disse skal fortrinnsvis inngå som en del av prosjektdirektivet. 7. Output & utgangskriteria Output fra denne prosessen er: Et designdokument som inneholder all nødvendig informasjon for å produsere e-læringstilbudet som er designet i prosjektet. Her følger en oversikt over de viktigste avsnittene Versjon 0.5 Side 16

17 i designdokumentet. <Dette avsnittet må oppdateres når malen for designdokument er ferdig utarbeidet>: 1. Problemanalyse Introduksjon (om e-læringstilbudet og bakgrunnen for det). Problembeskrivelse (inkludert hvem som er målgruppen, hva som dekkes (relatert til andre kurs) og hva man skal oppnå. Pedagogiske mål (hva studentene skal beherske) Pedagogisk miljø (hvordan skal e-læringstilbudet tilbys) Kontekst Utdannelsesinstitusjonen sin infrastruktur. Teknisk støtte (hvem og hva?) Administrativ støtte (hvem og hva?) Utviklingsteam (hvem skal bringe e-læringstilbudet fra designdokument til ferdig resultat.) Leveranseteam (hvem skal levere e-læringskurset). Studentenes plassering og teknologi. Interessenter (en kartlegging av interessentene). Målgruppe (hvem skal dette e-læringstilbudet lages for?) Læringsmål (hva skal studentene beherske når de har gjennomført e- læringskurset?) Kart over læringsoppgaver (eng. learning task map). Vurdering av studentene (hvordan skal dette foregå) Underveis Til slutt Evaluering av e-læringsopplegget (hvordan skal dette foregå) Underveis Til slutt 2. Faglig modell En henvisning til faglig modell (kunnskapsmodell) som beskriver relevant kunnskap for e-læringstilbudet og kilder til aktuelt materiale. 3. Pedagogisk modell En henvisning til pedagogisk modell som beskriver læringsaktivitetene, øvingsaktivitetene, vurdering av studentene (underveis og til slutt). 4. Teknisk leveransemodell En henvisning til teknisk leveransemodell som inkluderer leveranseform, videoer, animasjoner, leksjoner, prototyper, etc. 5. Forretningsmodell En henvisning til forretningsmodellen som beskriver forretningsmessige forhold som er relevant for de som skal utvikle e-læringstilbudet. En sluttrapport som også inneholder en evaluering av prosjektet og som skal være godkjent før prosjektet kan avsluttes. Mens CCeD prosjektet foregår skal Team Forretning Versjon 0.5 Side 17

18 gjennomføre formativ og summativ evaluering av prosjektet. Resultatene fra disse evalueringsaktivitetene skal inngå i sluttrapporten. 8. Delprosesser og aktiviteter 8.1 Initieringsprosessen Fig. 3 Initieringsprosessen. Aktivitet Oppgave og retningslinjer Team eller rolle Legg frem Lag grunnlag for beslutning. Prosjektleder prosjektdirektiv Gjennomfør for godkjenning beslutningsmøte. Oppdater prosjektdirektivet med eventuelle innsigelser fra styringsgruppen. Lag prosjektplan Etabler infrastruktur Dokumenter beslutningene. Definer formål og mål, ressursbehov, kostnader, tidsaspekt, og beskriv dette i prosjektplanen. Definer prosjektets infrastruktur. Installer nødvendig programvare. Gi autorisasjon (tilgang på riktig nivå) for alle prosjektdeltakere. Output Signert prosjektdirektiv Maler og verktøy Mal for prosjektdirektiv Prosjektleder Prosjektplan Mal for prosjektplan Prosjektleder Ferdig installert og konfigurert infrastruktur. Veiledning for infrastruktur til CCeD prosjekter? Evaluer prosessen Gjennomfør en evalueringsundersøkelse blant involverte parter i prosjektet som har fokus på Alle (Prosjektleder er ansvarlig) Evalueringsrapport Nettbasert spørreundersøkelse som f.eks. Versjon 0.5 Side 18

19 Aktivitet Oppgave og retningslinjer Team eller rolle å evaluere prosessen. Output Maler og verktøy It s Learning tilbyr. 8.2 Sesjonsplanleggingsprosessen Tabell IV Aktiviteter i Initieringsprosessen. Fig. 4 Sesjonsplanleggingsprosessen. Aktivitet Oppgave og retningslinjer Team eller rolle Lag sesjonsplan Å beskrive alle Prosjektleder og definere arbeidssesjoner som skal team gjennomføres. Når skal de foregå, hvem skal delta, hvilket ansvar har de forskjellige deltakerne, hvilke resultater skal produseres i de enkelte arbeidssesjonene. Output En oversikt over alle planlagte sesjoner som inkluderer alle roller og alle team som skal delta i sesjonene. Maler og verktøy MindMap mal benyttes Ferdigstille Å utarbeide endelig Prosjektleder Komplett Må Versjon 0.5 Side 19

20 Aktivitet Oppgave og retningslinjer Team eller rolle sesjonsplan sesjonsplan som skal gjelde for prosjektet. Evaluer prosessen Gjennomfør en evalueringsundersøkelse blant involverte parter i prosjektet som har fokus på å evaluere prosessen. Alle (Prosjektleder er ansvarlig) Output sesjonsplan Evalueringsrapport Maler og verktøy eventuelt lages. Nettbasert spørreundersøkelse som f.eks. It s Learning tilbyr. 8.3 Sesjonsgjennomføringsprosessen Tabell V Aktiviteter i Sesjonsplanleggingsprosessen. Fig. 5 Sesjonsgjennomføringsprosessen. Versjon 0.5 Side 20

21 Aktivitet Utføre forretningsmessig arbeid Utvikle teknisk leveransemodell Utvikle pedagogisk modell Oppgave og retningslinjer Første del av arbeidssesjonen hvor tilretteleggeren gjennomgår målene for den kommende sesjonen. Aktiviteter som sikrer at prosjektet opererer innenfor definert ramme av tid, kostnader og kvalitet, samt at relevante avtaler etableres. Å utvikle en teknisk leveransemodell for e-læringstilbudet som inkluderer leveranseform, videoer, animasjoner, leksjoner, Å utvikle en pedagogisk modell som beskriver hele det pedagogiske opplegget for e-læringstilbudet. Dette inkluderer læringsaktiviteter, øvingsarbeid (vurdering av studentene underveis) og sluttevaluering (vurdering av studentene til slutt). Sesjonsforberedelse Team eller rolle Output Maler og verktøy Tilrettelegger er Oversikt over mål Samhandlingsrommet ansvarlig. Alle for sesjonen. sesjonsdeltakere deltar Team forretning Team teknisk leveranse Team pedagogikk Forretningsmodell Teknisk leveransemodell Pedagogisk modell MindMap mal. MindMap mal. MindMap mal. Versjon 0.5 Side 21

22 Utvikle faglig modell Lede arbeidssesjonen Sesjonsevaluering med eventuell prosessevaluering Lag sesjonsreferat Å utvikle en faglig modell som beskriver relevant faglig innhold, kilder til aktuelt materiale, etc. Dette er tilretteleggeren sin oppgave under arbeidssesjonene. Vedkommende skal stimulere til samarbeid mellom alle involverte parter på en hensiktsmessig måte slik at best mulig resultat oppnås. Etter hver sesjon skal tilretteleggeren sørge for at sesjonsarbeidet blir evaluert. Denne evalueringen har fokus på resultatoppnåelse i arbeidssesjonen. Videre kan man velge å gjennomføre prosessevaluering etter noen utvalgte sesjoner. Utarbeid et sesjonsreferat basert på hendelser i sesjonen og det som framkommer i sesjonsevalueringen. Team faglig Tilrettelegger Alle (Tilretteleggeren er ansvarlig for sesjonsevaluering mens prosjektlederen er ansvarlig for eventuell prosessevaluering.) Faglig modell Bidrag underveis i arbeidssesjonene Eventuell evalueringsrapport for prosess. MindMap mal. Samhandlingsrommet og etablert infrastruktur for prosjektet Eventuell nettbasert spørreundersøkelse som f.eks. It s Learning tilbyr for prosessevalueringen. Sesjonssekretær Sesjonsreferat Mal for sesjonsreferat Versjon 0.5 Side 22

23 Lag designdokument Dette går på å samle alle relevante modeller (eller referanser til disse) i en felles og overordnet design beskrivelse som skal benyttes når e-læringstilbudet skal utvikles og leveres til kunde. Team leveranse, Team pedagogikk, team faglig Designdokument Mal for designdokument (Word) med referanser til de fire kjernemodellene Tabell VI Aktiviteter i Sesjonsgjennomføringsprosessen. 8.4 Avslutningsprosessen Fig. 6 Avslutningsprosessen. Aktivitet Oppgave og retningslinjer Team eller rolle Utarbeide Å utarbeide endelig Prosjektleder endelig designdokument som kan designdokument legges fram for godkjennelse slik at prosjektet kan avsluttes. Output Endelig designdokument for nytt e-læringssystem Maler og verktøy Mal for designdokument Versjon 0.5 Side 23

24 Evaluer prosessen Lag sluttrapport Gjennomfør en evalueringsundersøkelse blant involverte parter i prosjektet som har fokus på å evaluere prosessen. Å lage prosjektets sluttrapport som oppsummerer hva prosjektet har oppnådd og hvordan det har gått. Skal legges fram for godkjenning. Alle (Prosjektleder er ansvarlig) Prosjektleder Evalueringsrapport. Godkjent sluttrapport Nettbasert spørreundersøkelse som f.eks. It s Learning tilbyr. Mal for sluttrapport. Tabell VII Aktiviteter i Avslutningsprosessen. 9. Sjekkliste for bruk av prosessen (Skal utarbeides) <Prosjektgruppen var i møte den 31. august 2009 enig om at dette punktet skal utarbeides senere.> Denne sjekklisten inneholder punkter som er aktuelle gjennom hele prosessen. Infrastruktur skal etableres og gjøres tilgjengelig for alle prosjektdeltakere. Maler. Alle maler skal gjøres tilgjengelig for prosjektdeltakerne. For alle arbeidssesjoner skal tilretteleggeren (eng. facilitator): o Gå gjennom sesjonens mål og forventet arbeidsmetode på forhånd. (Eng. briefing). o Tilrettelegge for god samhandling under arbeidssesjonene. o Sørge for oppsummering og evaluering etter sesjonen. (Eng. debriefing). Alle gjennomførte sesjoner skal dokumenteres i form av et sesjonsreferat som gjøres tilgjengelig for alle prosjektdeltakere. 10. Prosessevaluering Det gjennomføres prosessevaluering i alle fire hovedprosesser (1-initieringsprosessen, 2-sesjonsplanleggingsprosessen, 3-sesjonsgjennomføringsprosessen og 4- avslutningsprosessen). (Se beskrivelse av de aktuelle prosessene i avsnitt 8 for mer informasjon.) Alle involverte prosjektdeltakere deltar i forbindelse med prosjektevalueringen som i all hovedsak gjennomføres med nettbaserte spørreundersøkelser. Undersøkelsene skal bestå av noen lukkede spørsmål med svaralternativer og noen åpne spørsmål hvor fri meningsytring er mulig. På denne måten skal man klassifiserer hvor bra eller dårlig forskjellige aspekter er, hva som bør forbedres, hvordan det bør forbedres, hva som bør beholdes, etc. Prosjektlederen er ansvarlig for å utarbeide evalueringsundersøkelsene og å sammenstille resultatene i en evalueringsrapport. Resultatene fra prosessevalueringen skal benyttes til framtidig endring og forbedring av CCeD prosessen. Versjon 0.5 Side 24

25 11. Verktøy (Skal utarbeides) <Prosjektgruppen var i møte den 31. august 2009 enig om at dette punktet skal utarbeides senere.> Her beskrives aktuelle verktøy for sesjonsgjennomføring. Beskriv alle relevante verktøy men understrek at dette kan varierer for forskjellige brukere av prosessen. MindMap (Tankekart), Office, SharePoint, Sesjonsstyring, 12. Maler og dokumenter Her beskrives maler og dokumenter som skal benyttes i prosessen med henvisning til aktuelle dokumenter. Dokument Beskrivelse Ref. til mal Prosjektdirektiv Et dokument som initielt beskriver Mal_Prosjektdirektiv_CCeD_nnn.docx prosjektets bakgrunn, hensikt, mandat og forutsetninger. Prosjektplan Plan med oversikt over prosjektets Mal må lages. bemanning, omfang, kostnader, leveranser, etc. Sesjonsplan En plan over arbeidssesjonene som skal gjennomføres i prosjektet og Mal må eventuelt lages. Excel eller tankekart? detaljplaner for hver sesjon. Basert på milepælsplan og aktivitetskart slik den Knut Øxnevad benyttet. Sesjonsreferat Beskrivelse av de resultater som ble Mal må eventuelt lages. Føringer fra oppdragsgiver Føringer for leverandør Interessentanalyse Faglig modell (Kjernemodell) Pedagogisk modell Teknisk Leveransemodell oppnådd i en arbeidssesjon. Et signert dokument (av sponsor) som beskriver hva oppdragsgiveren ønsker å oppnå og hvilke forutsetninger som gjelder. Et signert dokument (av eier) som beskriver hva leverandøren ønsker å oppnå og hvilke forutsetninger som gjelder. Et dokument som beskriver interessentene og hvordan de kan påvirke prosjektet. (Makt og innflytelse) En oversikt over kunnskapen og ferdighetene som er relevant for e- læringstilbudet med relevante kilder. En oversikt over pedagogiske aktiviteter som skal inngå som en del av e- læringstilbudet. En oversikt over hvordan leveransene skal foregå, hvilke teknologier som skal Mal må eventuelt lages. Kan eventuelt fjernes både her og fra prosessen. (Forenkling). I praksis vil vi få inn eventuelle føringer på en mer uformell måte. Mal må eventuelt lages. Kan eventuelt fjernes både her og fra prosessen. (Forenkling). I praksis vil vi få inn eventuelle føringer på en mer uformell måte. Foreslår at denne fjernes. Legges inn i en av kjernemodellene. For eksempel faglig eller forretningsmodell. MAL Faglig modell.mmat MAL Pedagogisk modell.mmat MAL Teknisk leveransemodell.mmat Versjon 0.5 Side 25

26 Dokument Beskrivelse Ref. til mal benyttes, etc. Forretningsmodell Forretningsmodellen er sammensatt av MAL Forretningsmodell.mmat økonomiske forhold (budsjett og forbruk), ressursmessige forhold (plan og forbruk), tidsmessige forhold (plan og leveranser), kvalitetssikring (planer og resultater), etc. Prosjektrapport Statusrapport for prosjektet som viser Må ev. lages. Word/Excel. status, påløpte aktiviteter og kostnader, gjenstående arbeid, Designdokument Et dokument som beskriver hele e- Mal (Word) må lages. læringsleveransen som er designet i prosjektet. Dette er prosjektets endelige leveranse. Det skal godkjennes på riktig nivå og det skal også inneholde referanser til alle relevante modeller som er utviklet i prosjektet. Designdokumentet er nærmere beskrevet i avsnitt 7 i denne prosessbeskrivelsen. Sluttrapport En sluttrapport som viser endelig status og evaluering av prosjektet. Denne må være utarbeidet før prosjektet rettmessig kan avsluttes Må ev. lages. Word Tabell VIII Beskrivelse av maler som inngår i prosessen. 13. Kontroll og eierskap for prosessen (Skal vurderes) <Prosjektgruppen var i møte den 31. august 2009 enig om at dette punktet skal vurderes senere.> Her beskrives hvem som eier prosessen, hvem som er kontrollinstans og hvem som er ansvarlig for å benytte prosessen. Det understrekes at dette gjelder kontroll og eierskap for selve CCeD prosessen og ikke produktene som utarbeides ved anvendelse av prosessen. 14. Spesielle retningslinjer (Skal utarbeides) <Prosjektgruppen var i møte den 31. august 2009 enig om at dette punktet skal utarbeides senere.> Har vi for eksempel spesielle retningslinjer for prosjekter med eksterne oppdragsgivere, sammenlignet med intern fagutvikling? Vi kan også omtale hvordan prosessen kan skaleres ned i dette avsnittet. Skal det legges opp til forenkling i gitte situasjoner? For eksempel når man utvikler rene campusfag uten ekstern oppdragsgiver? Versjon 0.5 Side 26

27 15. Kompetanse- og opplæringsbehov For å gjennomføre prosjekter i henhold til denne CCeD prosessen er følgende kompetanse og erfaring viktig. Prosjekt- og prosessledelse. Prosjektene trenger en prosjektleder med god kompetanse i forhold til hele CCeD prosessen. Ledelse av arbeidssesjoner som utføres av tilrettelegger (eng. facilitator). Prosjektene trenger minimum en person med tilstrekkelig kompetanse og erfaring til å inneha denne rollen. Teknisk sesjonsledelse. Prosjektene trenger minimum en person som kan utnytte infrastrukturen på samhandlingsrommet slik at ønsket tverrfaglig samhandling og utveksling av modellelementer foregår i henhold til tilretteleggerens ønsker. Teknisk sesjonsledelse kan gjerne utøves av tilretteleggeren, sesjonssekretæren, prosjektlederen eller en annen valgt person. Utvikling av faglig modell. Prosjektene trenger minimum en person med kompetanse i forhold til utarbeidelse av den faglige modellen. Utvikling av pedagogisk modell. Prosjektene trenger minimum en person med kompetanse i forhold til utarbeidelse av den pedagogiske modellen. Utvikling av teknisk leveransemodell. Prosjektene trenger minimum en person med kompetanse i forhold til utarbeidelse av den tekniske leveransemodell. Utvikling av forretningsmodell. Prosjektene trenger minimum en person med kompetanse i forhold til utarbeidelse av forretningsmodellen. Etablering av infrastruktur for prosjektet basert på MS SharePoint teknologi. <Øvrig kompetanse- og opplæringsbehov beskrives her > 16. Aksjonsliste Denne aksjonslisten inneholder punkter som oppstår under utarbeidelse av prosessen og den skal fjernes når prosessbeskrivelsen er ferdig utarbeidet. ID Beskrivelse av aksjon Status A1 Lag mal for prosjektdirektiv i Word. Ferdig A2 Beslutningspunkter inn i oversikt over prosessen (avsnitt 3). Ferdig A3 IPR på endelig e-læringstilbud (inngår sannsynligvis i forretningsmodellen). Hvordan skal eierskapet til selve CCeD modellen være? Åpen A4 Drupal (CMS system) for å lage web 2.0. Kan dette være hovedprosjekt for 3. klassestudenter? Åpen A4 Monica legger inn utfyllende tekst om samhandlingsrommet. Avsnitt 5 Åpen A5 Rapid prototyping WBID s. 56. Sjekk dette KAS. Åpen A6 Føringer for sesjonsplanen med retningslinjer i forhold til overordnede mål for hver sesjon. (ADDIE). Sjekk dette KAS Åpen A7 Analysis: problem analysis and instructional component analysis (mål (hva Til Versjon 0.5 Side 27

28 ID Beskrivelse av aksjon Status skal studentene kunne gjøre) kontekst (miljø for design og leveranse og organisatorisk infrastruktur), studenter (interesser, behov, muligheter, tidligere kunnskap og ferdigheter, erfaring), pedagogisk innhold (struktur og sekvensen for hovedtrinnene og del-ferdighetene som blir fokusert i opplæringssystemet hvor skal man starte og hvilke forhåndskunnskaper kreves) orientering Versjon 0.5 Side 28

29 Vedlegg A Generelt om modellering av prosesser I dette avsnittet gjennomgås en konkret og mye brukt metode for modellering av forretningsprosesser. Hensikten med dette er å ha noe å støtte seg på når dette dokumentet utarbeides. Avsnittet vil sannsynligvis bli fjernet når prosessbeskrivelse er ferdig utarbeidet. Business Process Management Initiative (BPMI) har utviklet en standard notasjon for modellering av forretningsprosesser som har fått navnet Business Process Modelling Notation (BPMN). Versjon 1.0 av BPMN ble publisert i mai I BPMN defineres et prosessdiagram (Business Process Diagram) som baserer seg på flytkart teknikker og som er retningslinjer for å representere foretningsprosessenes operasjoner grafisk. En modell av en forretningsprosess representeres som et grafisk nettverk med objekter som representerer aktiviteter (arbeid som skal utføres) og flyter som kontrollerer rekkefølgen eller sekvensen i utførelsen. Kildene til BPMN i denne sammenheng er tilgjengelig materiale på internett (for eksempel Grunnelementene i BPMN Når man modellerer forretningsprosesser ved hjelp av BPMN benytter man fire kategorier av elementer. Dette er: Flytobjekter (Flow objects) Koblingsobjekter. (Connecting Objects) Rollebånd/ svømmebaner. (Swimlanes). Artefakter. (Artifacts) Flytobjekter Flytobjektene består av tre kjerneelementer. Dette er: Hendelser (Event) Aktiviteter (Activity) Porter (Gateway) Hendelser representeres ved hjelp av sirkler og representerer noe som skjer i løpet av forretningsprosessen. Hendelsene påvirker flyten til prosessen og de har vanligvis en årsak (trigger) eller et resultat. Det finnes tre forskjellige hendelser som tar utgangspunkt i når de påvirker flyten. Dette kan være i starten, midtveis eller til slutt. Symbol Beskrivelse Symbol for starthendelse. Symbol for slutthendelse. Symbol for midtveis hendelser. Fig. A1 Symboler for hendelser i BPMN Versjon 0.5 Side 29

30 Aktiviteter representeres med rektangler som er avrundet i hjørnene. Disse representerer et stykke arbeid som skal gjøres i prosessen. En aktivitet kan være en oppgave (Task) eller underprosess (Subprocess). En underprosess får et pluss tegn sentrert i bunnen av rektangelet. Symbol Beskrivelse Symbol for aktivitet. Dette representerer altså en oppgave som skal utføres. Symbol for en underprosess som egentlig er en selvstendig prosess. Det vil normalt eksistere en egen prosessbeskrivelse for denne prosessen Fig. A2 Symboler for aktiviteter i BPMN Porter representeres med en diamantlignende form og benyttes til å beskrive forskjellige beslutninger med forskjellig utfall som påvirkes og finnes i aktivitetsflyten. Disse kan ha forskjellig utfall og dette er bakgrunnen for betegnelsen porter. Symbol Beskrivelse Symbol for porter. Disse beskriver tradisjonelle beslutninger som gjøres i prosessen og de kan ha opp til flere innganger og/eller utganger. Man benytter tekst til å markere hvilke beslutninger man skal ta i en port. Fig. A3 Symboler for porter i BPMN Koblingsobjekter Flytobjektene kobles sammen med koblingsobjekter for å skape en grunnleggende struktur og et skjelett for forretningsprosessen. Det finnes tre forskjellige koblingsobjekter. Dette er: Sekvensflyt (Sequence Flow) Meldingsflyt (Message Flow) Assosiasjoner (Association) Symbol Beskrivelse Sekvensflyt representeres med heltrukne piler som kobler sammen hendelser innenfor samme svømmebane (lane). Meldingsflyt representeres med stiplede linjer med åpent endestykke. Disse benyttes til å vise meldingsflyten mellom to ulike deltakere i prosessen og disse deltakerne er gjerne plassert i forskjellige basseng (pool). Assosiasjoner representeres som stiplede linjer med linjert pilhode. De Versjon 0.5 Side 30