PROJEKTDEFINITION Projekt KA

Sidan: 1 (30) PROJEKTDEFINITION Projekt KA KA-system Version 1.0 nbit

Sidan: 2 (30) INNEHÅLL 1 BASFAKTA... 3 1.1 GODKÄNNANDE... 3 1.2 REVISIONSINFORMATION... 3 2 IDÈ OCH MÅL... 4 2.1 BAKGRUND... 4 2.2 IDÉ/EFFEKTMÅL... 4 2.3 MÅL... 4 2.4 AVGRÄNSNINGAR... 5 3. LEVERANSER OCH GODKÄNNANDE... 6 3.1 INLEVERANSER... 6 3.2 LEVERANSER OCH DELLEVERANSER... 7 3.3 GODKÄNNANDEKRITERIER... 7 3.4 LEVERANS- OCH ÖVERLÄMNINGSPROCEDUR... 7 3.5 PROJEKTAVSLUT... 8 4 ORGANISATION... 9 4.1 PROJEKTORGANISATION OCH BEMANNING... 9 4.2 ANSVARSFÖRDELNING OCH BESLUTSPROCESS... 11 4.3 UTBILDNING... 13 5 TIDSPLAN OCH RESURSBEHOV... 14 5.1 PROJEKTTIDSPLAN...14 5.2 BESLUTSPUNKTER OCH MILSTOLPAR... 14 5.3 RESURSBEHOVSPLAN... 15 5.4 UTRUSTNING OCH LOKALER... 15 6 ARBETSFORMER... 16 6.1 PRODUKTIONSMODELL... 16 6.2 PRODUKT- OCH DOKUMENTSTYRNING... 16 6.3 AVVIKELSE OCH ÄNDRINGSHANTERING... 17 6.4 PROJEKTANALYS... 17 6.5 SEKRETESS OCH SÄKERHET... 19 6.6 INFORMATIONSSPRIDNING... 19 7 RISKER...21 7.1 PROJEKTRISKER... 21 7.2 PRODUKTRISKER... 22 8 EKONOMI... 24 8.1 KALKYL... 24 8.2 FINANSIERING... 24 9 REFERENSER... 25 BILAGOR Bilaga Dokumentnamn A Funktionalitet KA V1.0 B Tidsplan KA V1.0 C Kalkyl KA V1.0

Sidan: 3 (30) 1 BASFAKTA 1.1 Godkännande Projektdefinitionens giltighet bekräftas av underskrifter av respektive part. Uppdragsgivaren är kundens projektansvarig och uppdragstagaren är projektchefen/projektledaren. Projektdefinitionen godkänns i styrgruppen och det bekräftas i ett styrgruppsprotokoll. Projektdefinitionen godkänd av: Uppdragsgivare/Beställare:. Ing-Britt Svensson (Utbildningsavdelningen) Projektchef: Projektledare:. Magnus Holmström (CITES)... (Sigma nbit AB) 1.2 Revisionsinformation Här redovisar Vi vad som skiljer de olika utgåvorna åt, genom att övergripande ange syfte och orsak till ändringen. Utgåva Datum Kommentar 1.0 2000-10-20 PDF Fas 1, godkänd och undertecknad

Sidan: 4 (30) 2 IDÈ och MÅL 2.1 Bakgrund Här beskriver Vi kortfattat bakgrunden till projektet genom att ange kopplingen mellan företagets (kundens) mål, resultatet mål och projektets mål. Enligt Chalmers strategiska plan, att ett Chalmers-gemensamt system för kursadministration ska införas, har projekt KA sedan hösten 2000 arbetat med att ta fram förutsättningar för KA-systemet, ett system som kommer att erbjuda funktionalitet inom kursadministration för hela Chalmers. Projekt KA har genomfört fas 1 och skapat en struktur och planering för fortsatt arbete. Projekt KA Version 1.0 kommer att arbeta vidare på strukturen och erfarenheterna från fas 1, men framför allt bygga systemet utifrån den kravställning som genomförts samt resultaten från processkartläggningarna inom området SA. Enligt Högskolans ledningsgrupps, HLG, tillstyrkan och rektors beslut planerar projekt KA att leverera KAsystemet version 1.0 2001-12-31. 2.2 Idé/Effektmål Här redovisar Vi projektidén. Projektidén speglar syftet med projektet och redovisar varför projektet finns. Genom KA-systemet görs Chalmersövergripande information, rörande kursadministration, lättillgänglig på ett ställe för alla kategorier av användare. Exempelvis: Studerande ges ökade möjligheter att själva ta ansvar för sina studier. Anställda kan frigöra tid och skapa bättre struktur i sitt arbete. Chalmers organisation får ett verktyg för att hantera sina resurser inom kursadministration. 2.3 Mål Här redovisar Vi projektets mål - vilka resultat som skall finnas vid genomförandets slut. Målet för projekt KA är att KA-systemet, version 1.0, finns i drift på Chalmers i januari 2002. Systemet skall vara godkänt av beställaren och styrgruppen, samt förankrat hos användarna. De krav och önskemål som framkommit under projektarbetet, men inte realiserats, skall dokumenteras i KAsystemets Ändringslogg KA, som ett underlag för eventuellt fortsatt arbete.

Sidan: 5 (30) 2.4 Avgränsningar Här förtydligar Vi projektets mål genom att ange vad andra projekt eller linjeinstanser ansvarar för. Funktionalitet: Version 1.0 ska endast täcka den funktionalitet som ingår i Kravspecifikation KA V1.0, se Referenser (kap 9). Kraven är generellt beskrivna i Funktionalitet KA V1.0 (bilaga A). I Kravspecifikation KA V1.0 är kraven specificerade på låg detaljeringsnivå, vilket återspeglas i funktionaliteten i första versionen av KA-systemet. Dock kommer vidareutveckling av KA-systemet att ge mer detaljerade krav, vilket leder till en mer förfinad funktionalitet och komplett system. I de fall en perfekt lösning kräver stor resursinsats eller förändringar i arbetssätt utanför projektets kontroll, skall detta dokumenteras i Ändringslogg KA. Arbetssätt/processer: Projektet ansvarar ej för verksamhetens rutiner och arbetssätt eller för processkartläggning. Dock ligger de processer som blivit identifierade och kartlagda av Projekt SA som inleveranser till projektet. Organisation: KA-systemet ingår i verksamhetsområdet StudieAdministration, dvs. SA. Projektet ansvarar inte för förvaltningsorganisation, roller eller ärendehantering inom detta område, då det åligger verksamheten att ta fram Förvaltningsorganisation SA. Utredning och rapport från detta är inleverans till projekt KA. Drift: CITES ansvarar för drift av KA-systemet efter projektets överlämning av systemet. Vidareutveckling: Projektet upphör efter leverans av version 1.0. Systemägaren kommer då att överta ansvaret och koordinering av vidareutveckling av systemet. Stöd och tekniskt support: Projektet ansvarar för stöd och tekniskt support till användare samt sektionernas IT-avdelningar fram till leveransen, då ansvaret övergår till CITES. Utbildning: Information till sektionernas IT-avdelningar inför implementering och överlämning ansvarar projektet för fram till leverans. Kunskap om systemet till användare tillhandahålls endast genom medverkan i krav-, test- och referensgrupperna. Utbildning inom KA-systemet ingår ej inom projektets ramar.

Sidan: 6 (30) 3. LEVERANSER och GODKÄNNANDE 3.1 Inleveranser Här redovisar Vi vilka förutsättningar som gäller för projektet i form av inleveranser som skall komma från andra projekt och/eller linjeinstanser. Inleveranserna kan vara både produkter och resurser som projektet kräver för att klara sina åtaganden. Projekt KA är beroende av inleveranser av både förberedande och praktisk karaktär. 3.1.1 Omfattning av inleverans till projektet Nedan följer en beskrivning av inleveranserna: De förberedande inleveranserna är: Sambandskarta för processer inom SA (för att systemet skall stödja verksamhetens arbetssätt) o Varav processen Kursutbud samt Studentregistrering är framtagna Förvaltningsorganisation SA (för att säkerställa drift- och förvaltningssituationen) Kostnads- och intäktsanalys för KA (för att rättfärdiga projektet och dess modulval) Persondatabas (för att öka kvaliteten och minska driftskostnader) Replikering från LADOK open dokumentation (för att säkerställa lösningen) Autentisering DCE/Y500 kopplat till personnummer i Persondatabas (för ökad säkerhet) De praktiska inleveranserna består av: Äldre system och prototyper framtagna under Fas 1, det vill säga: o Portal o Meritförteckning o MTS o Kursplaner/kurskatalog enligt ECTS o Kursval IT-infrastruktur Delaktighet från verksamheten

Sidan: 7 (30) 3.2 Leveranser och delleveranser Här redovisar Vi vilka leveranser och delleveranser projektet skall göra. För varje delleverans beskriver vi idé och mål samt vid behov avgränsningar och inleveranser. Projekt KA innehåller endast en leverans, en slutleverans, som baserar sig på beställarens prioritering av omfattning och innehåll och är en sammanslagning av projektets hittills gjorda fasindelning, fas 1 och fas 2. Under utvecklingens gång kommer delresultat att förevisas i form av prototyper för referensgrupper för att säkerställa att systemet uppfyller kraven. Eftersom en leverans kräver en hel del administration skall dessa prototyper ej betraktas som leveranser. 3.2.1 Innehåll Slutleverans Här redovisar Vi alla resultat i form av alla produkter som projektet kommer att leverera och överlämna. Slutleveransen av KA-systemet, version 1.0, omfattar: Basfunktionalitet inom modulerna: o Studentportal o Kursutbud (Kurskatalog/kursplaner enligt ECTS) o Studentregistrering o Personlig information o Kursval o MTS o Kurshemsidor Systemdokumentation Användardokumentation Ändringslogg KA 3.3 Godkännandekriterier Här redovisar Vi vilka godkännandekriterier som gäller per delleverans och resultat. Följande kriterier har framkommit: Systemet är granskat enligt Kravspecifikation KA V1.0 och godkänt av både teknik- och referensgruppen vid protokollförda möten Systemdokumentationen är granskad och godkänd av CITES. Användardokumentationen är granskad och godkänd av systemägaren. Ändringslogg KA uppfyller sitt syfte, dvs. innehåller de krav och önskemål som inte är med i denna leveransen och är granskad och godkänd av systemägaren. Styrgruppen har befogenheter för godkännande av avvikelser från ovanstående. Styrgruppen, inklusive beställaren, beslutar om levererat resultat godkänns. 3.4 Leverans- och överlämningsprocedur Här redovisar Vi hur leverans till förvaltningsorganisationen/användaren/resultatansvarige går till. Leverans- och överlämnande går till på följande sätt: Efter godkännande av styrgruppen sker leverans till beställaren vid ett slutseminarium. Överlämning sker till chefen för CITES i samband med projektavslutet i januari 2002. Överlämnandet innehåller även den systemdokumentation som är nödvändig för att kunna ta systemet i drift. Leverans och överlämnande protokollförs och godkänns av styrgruppen.

Sidan: 8 (30) 3.5 Projektavslut Här redovisar Vi resultat som skall uppnås och aktiviteter som skall genomföras efter leverans och överlämning för att Vi skall kunna avsluta projektet. Projektet är avslutat när: Godkännande skett enligt leverans- och överlämningsproceduren (se kapitel 3.4) Allt inlånat material är återlämnat och personliga arbetsexemplar makulerade All projektdokumentation är arkiverad Slutrapporten är godkänd av styrgruppen Avslutande styrgruppsmöte har förklarat projektet avslutat

Sidan: 9 (30) 4 ORGANISATION 4.1 Projektorganisation och bemanning Här beskriver Vi projektorganisationen i form av ett organisationsschema. Namn på nyckelpersoner skall finnas angivna. Styrgrupp Jan-Martin Löwendahl Analysgrupp Thomas Bjerkhede Projektchef Magnus Holmström Projektledning Referensgrupp Lilian Sandström Kravställning/test Niclas Stoldt Teknik/utveckling Jens Gustafsson Arbetsgrupper för kravställning/test * n Kravställningsgrupp Arbetsgrupper för teknik/utveckling och IT-infrastruktur * n Teknikgrupp

Sidan: 10 (30) Bemanning Projekt KA V1.0 Styrgrupp: Analysgrupp: Projektledning: Teknik/ utveckling: Kravställning/ test: Studentportal Kursutbud Studentreg. Kurshemsidor Meritförteckning Kursval MTS IT-infrastruktur Referensgrupp: Jan-Martin Löwendahl, CIO (ordförande) Bo Egardt, Prorektor Peter Olsson, Vicerektor för grundutbildningen Björn O Eriksson, Administrativ direktör, CA Ing-Britt Svensson, Avdelningschef, Utbildningsavdelningen CA Görgen Olofsson, IT-chef, CITES NN, vicedekan grundutbildningen Fredrik Wadström, Sigma nbit Thomas Bjerkhede, Sigma nbit Fredrik Wadström, Sigma nbit Magnus Holmström, CITES (projektchef), Sigma nbit (projektledare) Jens Gustafson, Sigma nbit (teknikgruppsledare) Dario López-Kästen, CITES Fredrik Svensson, CITES Linda Kullenberg, CITES Tobias Gustavsson, Sigma nbit CITES (Anne-Marie Achrenius, MD, Andreas Jonasson, MD) Niclas Stoldt, Sigma nbit (kravställningsgruppsledare & testledare) Björn Svennung, Askus AB Följande modulansvariga tillsammans med ett antal användare ingår i respektive kravställningsgrupp: Pia Lundberg, utbildningsavdelningen Patrik Hellman, utbildningsavdelningen Ingrid Sjöberg, utbildningsavdelningen Göran Stigler, M Stellan Englén, Ladok Johan Bankel, M Marie Arehag, MTS Görgen Olofsson, CITES Lilian Sandström, ED NN Samt modulansvariga: Pia Lundberg, utbildningsavdelningen Patrik Hellman, utbildningsavdelningen Ingrid Sjöberg, utbildningsavdelningen Göran Stigler, M Stellan Englén, Ladok Johan Bankel, M Marie Arehag, MTS Görgen Olofsson, CITES

Sidan: 11 (30) 4.2 Ansvarsfördelning och beslutsprocess Här beskriver Vi ansvar och befogenheter inom projektet. 4.2.1 Styrgrupp Ansvar Säkerställa att projektets resultat är i linje med och användbart i Chalmers verksamhet Säkerställa projektresultatet genom att tillföra de resurser som krävs för att få fram resultatet Styra projektet avseende tid, budget och resultat I avsaknad av Förvaltningsorganisation SA behövs koordinering av för projektet intressanta satsningar Befogenheter Godkänna och ändra projektdefinitionen Godkänna leveransen Tillsätta analysgrupp och initiera projektanalyser Avsluta projektet 4.2.2 Analysgrupp Ansvar Genomföra projektanalyser Rapportera och dokumentera resultatet och bedömningar till styrgruppen och projektledningen Befogenheter Genomföra projektanalyser med tillgång till projektledningen, nyckelpersoner, projekt- och resultatbiblioteket Identifiera, dokumentera och rapportera avvikelser från överenskommet arbetssätt till projektledningen och styrgruppen 4.2.3 Projektchef Ansvar Rapportera och informera om projektläget externt, dvs. ut från och in till projektet Informera om och förankra projektets resultat Planera för kommande arbete efter leverans av version 1.0 Skapa rutiner för projektets genomförande Leverera och överlämna rätt resultat Utveckla, förvalta och hushålla med resurserna Befogenheter Säkerställa projektorganisationen Initiera projektanalyser Initiera eventuella omförhandlingar angående projektet Avvisa inleveranser som avviker från överenskommet innehåll och överenskommen kvalitet Föreslå innehåll och omfattning för beslut i kravställningsgruppen Föreslå tekniska lösningar för beslut i teknikgruppen Införa och plocka ut produkter till och från projektbibliotek 4.2.4 Projektledare (PL) Planera, leda, följa upp, sammanställa och styra det interna projektarbetet Rapportera och informera om projektläget internt, dvs. uppåt och nedåt i projektet Genomföra projektet inom ramarna för denna projektdefinition Säkerställa att överenskomna metoder och hjälpmedel används Godkänna inleveranser Producera, leverera och överlämna rätt resultat Koordinera projektledningen Upprätta och underhålla projekt- och resultatbibliotek Befogenheter

Sidan: 12 (30) Styra tilldelade resurser enligt denna projektdefinition Anpassa projektorganisationen Initiera eventuella omförhandlingar angående projektet Avvisa inleveranser som avviker från överenskommet innehåll och överenskommen kvalitet Föreslå innehåll och omfattning för beslut i kravställningsgruppen Föreslå tekniska lösningar för beslut i teknikgruppen Införa och plocka ut produkter till och från projektbibliotek 4.2.5 Referensgruppsledare Ansvar Ingår i projektledningen Planera, koordinera och leda revisionstillfällen Fastställa leveransens funktionalitet Säkerställa att gruppen har ändamålsenliga metoder och hjälpmedel Rapportera och informera om tids- och projektläget till PL Upprätta och underhålla projektbibliotek Befogenheter Nyttja och styra tilldelade resurserna Föreslå ändring i referensgruppens organisation 4.2.6 Referensgrupp Ansvar och befogenheter Tekniskt modulansvarig, vilket även medför deltagande i respektive kravställnings- och testgrupp Remissa, revidera och verifiera kraven på funktionellt innehåll av leveransen Godkänna Kravspecifikation Godkänna och fastställa testprotokoll Godkänna leveransen av KA-systemet Tid- och lägesrapportering 4.2.7 Kravställningsgruppsledare Ansvar Ingår i projektledningen Planera, leda och följa upp framtagning av Kravspecifikation Framtagning och underhåll av Ändringslogg KA Säkerställa att överenskomna metoder och hjälpmedel används Rapportera och informera om tids- och projektläget till PL Befogenheter Nyttja och styra tilldelade resurserna Föreslå ändring i kravställningsgruppens organisation 4.2.8 Kravställningsgrupp Ansvar och befogenheter Bearbeta och sammanställa kraven på funktionellt innehåll av leveransen Producera Kravspecifikation Producera och underhålla Ändringslogg KA Tid- och lägesrapportering

Sidan: 13 (30) 4.2.9 Testledare Ansvar Ingår i projektledningen Planera, leda och följa upp system- och funktionstester Planera, leda och följa upp tester avseende prestanda, tillförlitlighet och integration Säkerställa att överenskomna metoder och hjälpmedel används Rapportera och informera om tids- och projektläget till PL Befogenheter Nyttja och styra tilldelade resurserna Föreslå ändring i testgruppens organisation 4.2.10 Testgrupp Ansvar och befogenheter Genomföra de olika tester som testledaren beslutar avseende funktionalitet, prestanda, tillförlitlighet och integration Tid- och lägesrapportering 4.2.11 Teknikgruppsledare Ansvar Ingår i projektledningen Systemdesign Planera, leda och följa upp framtagning av Lösningsspecifikation Planera, leda, följa upp, sammanställa och styra produktionsarbetet Producera, leverera och överlämna rätt resultat Planera, leda och ta fram förutsättningar för kommande driftsmiljö Säkerställa att överenskomna metoder och hjälpmedel används Utveckla, förvalta och hushålla med resurserna Rapportera och informera om tids- och projektläget till PL Befogenheter Nyttja och styra tilldelade produktionsresurser Föreslå funktioner och egenskaper för beslut i kravställargruppen Föreslå tekniska lösningar för beslut i teknikgruppen Fastställa inre struktur och uppbyggnad för KA-systemet Föreslå ändring i teknikgruppens organisation 4.2.12 Teknikgrupp (innehåller tekniskt modulansvarig, utvecklare samt DBA) Ansvar och befogenheter Producera Lösningsspecifikation Utveckla programvaran Genomföra systemtester Tid- och lägesrapportering Dokumentation 4.3 Utbildning Projektmedlemmarna ges vid behov utbildning i: Arbetsuppgifter samt arbetssätt inom Chalmers Projektstyrningsmodell: Praktisk projektstyrning, PPS Produktionsmodell: CITES arbetsformer samt delar av Rational Unified Process, RUP

Sidan: 14 (30) 5 TIDSPLAN och RESURSBEHOV 5.1 Projekttidsplan Här visar Vi projekttidsplanen, som i detta fall är en bilaga. Projektplan Projekt KA V1.0: 010701-020128 Se Tidsplan KAV1.0 (bilaga B) 5.2 Beslutspunkter och milstolpar Här redovisar Vi viktiga avstämningspunkter i form av milstolpar och beslutspunkter. 5.2.1 Beslutspunkter BP1 2001-04-18 Styrgruppsmöte Projektdirektivet godkänns av styrgruppen, med reservation för ändringar av nye beställaren. Diskussion om ny sammansättning av styrgruppen. BP2 2001-06-20 Styrgruppsmöte Diskussion kring förslag till Projektdefinition för Projekt KA V1.0 BP3/BP4 2001-08-28 Styrgruppsmöte Godkännande av Projektdefinition. Godkännande av Kravspecifikation. Information om Lösningsspecifikation. Starta genomförandet. Ställa resurser till projektets förfogande enligt Projektdefinitionen BP5 2001-10-03 Styrgruppsmöte 2001-11-05 Styrgruppsmöte 2001-11-26 Styrgruppsmöte Avrapportering av genomförandet. Avrapportering av projektgranskning. Uppföljning riskanalys BP6/BP7 2001-12-20 Styrgruppsmöte Leverans av KA-system version 1.0 till beställaren och verksamheten. Överlämning av resultat och ansvar till CITES för drift och förvaltning. BP8 2002-01-28 Styrgruppsmöte Godkännande av slutrapporten. Projektet avslutas.

Sidan: 15 (30) 5.2.2 Milstolpar 2001-08-20: Kravställningsgruppen är klar med Kravspecifikation 2001-08-27: Utvecklingsplattform beslutad. Moduler fördelade på IT-ansvariga. 2001-10-01: Start av gränssnittsdemonstrationer. 2001-11-05: Start av system- & funktionstester. 2001-12-03: Start av sluttester. 2001-12-20: Leverans av KA-systemet version 1.0 5.3 Resursbehovsplan Här beskriver Vi resursbehovet under projektets löptid. När så krävs redovisar Vi behovet uppdelat per kompetensområde. Resursbehovet finns dokumenterat i Kalkyl KA V1.0, sidan 2, se bilaga C. 5.4 Utrustning och lokaler Här beskriver Vi den utrustning och de lokaler som projektet behöver. 5.4.1 Utrustning Projektet äger följande utrustning: Två datorer för utveckling Projektet lånar följande utrustning från CITES: Tre datorer för planering och dokumentation Projektet ser följande behov framöver: Två datorer, en för utveckling och en för systemtester. 5.4.2 Lokaler Projektet kommer att i huvudsak bedrivas i CITES lokaler.

Sidan: 16 (30) 6 ARBETSFORMER 6.1 Produktionsmodell Här identifierar Vi vilket arbetssätt projektet använder för produktutvecklingen. Vid behov beskriver Vi avvikelser från utpekad modell. I enkla fall kan Vi beskriva hela arbetssättet. Projektet bygger sin produktionsmodell (egna rutiner och mallar) på CITES arbetsformer samt delar av RUP:s produktionsmodell (Rational Unified Process). 6.2 Produkt- och dokumentstyrning Här beskriver Vi hur Vi håller ordning och reda på både projekt- och produktdokument. Vi beskriver hur de olika dokumenttyperna identifieras, förvaras och hanteras vid ändringar. Här beskriver Vi också hur Vi hanterar olika utgåvor av produkterna och vilka krav på spårbarhet som finns till användare av olika utgåvor av produkterna. 6.2.1 Projektdokument Projektet använder PPS, Praktisk projektstyrning som projektstyrningsmetod. Samtliga dokument identifieras av dokumentnamn, datum och utgåva, enligt PPS. Handläggare måste framgå av varje dokument. Samtliga original lagras i den för projektmedlemmarna tillgängliga projektdatabasen, Livelink I Projektpärm 1 finns frysta/fastställda dokument, tillgänglig för alla med licens till Livelink. 6.2.2 Systemdokument All dokumentation som tillhör systemet identifieras av systembenämning, dokumentnamn, datum och utgåva. Handläggare måste framgå av varje dokument. Samtliga systemdokument och arbetsdokument lagras på en disk med backup på CITES, åtkomliga för alla projektmedlemmar. Efter överlämning till CITES kommer KA-systemet med dess ingående moduler att lagras enligt CITES:s policy för driftsmiljö. Driftsdokumentation och produktdokument lagras enligt CITES:s policy för driftsdokumentation

Sidan: 17 (30) 6.3 Avvikelse och ändringshantering Här beskriver Vi tillvägagångssättet vid förändringar av projekt- och produktstyrande dokument. 6.3.1 Kravhantering Kravställningsledaren ansvarar för att kravställningsgruppen utför insamling av krav och önskemål från beställare och användare. Kravställningsledaren ansvarar för framtagning och färdigställande av Kravspecifikation. Referensgruppen remissar, reviderar och godkänner den slutliga Kravspecifikation. Kravspecifikation blir fryst då systemansvarig godkänt den. När Kravspecifikation är fryst ansvarar Kravställningsledaren för att inkommande förslag till ändringar hanteras och bearbetas i samråd med Teknikgruppen. Beslut om ändringar som inte påverkar projektets tids- och kostnadsramar ska fattas av Projektledningen. Ändringar som ökar kostnaderna eller förlänger tidsplanen ska beslutas av Styrgruppen. De ändringsförslag som inte hanteras i innevarande version dokumenteras i Ändringslogg KA. 6.3.2 Teknik/utveckling Teknikgruppsledaren ansvarar för att teknikgruppen översätter Kravspecifikation till Lösningsspecifikation, vilken sedan utgör inleverans till genomförandefasen, då utveckling av modulerna görs. När Lösningsspecifikationen är fryst ansvarar Teknikgruppen för att utveckla enligt denna. Upptäcks möjligheter eller förbisedda krav som kräver ändringar av teknikgruppen, skall dessa föreslås tillsammans med en kostnadsuppskattning till PL. Beslut om ändringar som inte påverkar projektets tids- och kostnadsramar ska fattas av Projektledningen. Ändringar som ökar kostnaderna eller förlänger tidsplanen ska beslutas av Styrgruppen. De ändringsförslag som inte hanteras i innevarande version dokumenteras i Ändringslogg KA. 6.3.3 Test Testledaren ansvarar för att testgruppen utför system- och funktionstester mot de krav på funktionalitet som leveransen innehåller. Testgruppen utför även prestanda-, tillförlitlighets- och integrationstester. Testgruppen tar fram en testplan, som kan frysas, men som skall utformas på ett sätt som medger anpassning till situationen, då stort beroende finns till teknikgruppens arbete. Beslut om ändringar som inte påverkar projektets tids- och kostnadsramar ska fattas av Projektledningen. Ändringar som ökar kostnaderna eller förlänger tidsplanen ska beslutas av Styrgruppen. De ändringsförslag som inte hanteras i innevarande version dokumenteras i Ändringslogg KA. 6.3.3 Bemanning Alla förslag på personförändringar i viktiga positioner i styr-, kravställar- och teknikgrupperna skall rapporteras skriftligen till projektet. Konsekvenser avseende förändringar i kostnader och tidsplan redovisas för beslut i styrgruppen. 6.4 Projektanalys Här beskriver Vi vilka metoder och aktiviteter som genomförs för att säkerställa projektets resultat och genomförandet. Här anger Vi också vilka instanser eller personer som genomför projektanalyserna.

Sidan: 18 (30) 6.4.1 Projekt Riskanalys har genomförts under fas 1. Denna uppdateras av projektledningen och redovisas på första BP5 styrgruppsmöte. Riskanalyser görs för att identifiera hot mot projektet, händelser som försvårar genomförandet, möjligheter som underlättar samt tittar på åtgärder för att eliminera och reducera riskerna. Projektanalys/granskning initieras av projektchefen och genomförs av analysgruppen och redovisas på något BP5 styrgruppsmöte. Projektgranskning görs för att verifiera projektets arbetssätt, samt titta på möjligheterna att fullfölja åtagandet. 6.4.2 Produkt Kravspecifikationen granskas och godkänns av Referens- och Styrgrupp. Lösningsspecifikationen granskas och godkänns av Teknikgrupp. KA-systemet version 1.0 granskas och godkänns av Referens- och Styrgrupp.

Sidan: 19 (30) 6.5 Sekretess och säkerhet Här beskriver Vi vilka regler som gäller avseende tillgång till dels arbetsplats, dels information om projektet och dess produkter. Projekt KA som helhet klassas inte som konfidentiellt. Detta innebär att all dokumentation och information rörande projekt KA är tillgänglig för alla studerande och anställda på Chalmers. Dock kan det finnas restriktioner för vissa funktioner och moduler, se Funktionalitet KA V1.0 (bilaga A). Extern information får ges endast efter samråd med projektet. 6.6 Informationsspridning Här beskriver Vi hur projektinformation sprids internt och externt. Vi redovisar hur projektdokumentationen skall distribueras samt när och hur muntlig information lämnas. 6.6.1 Projektinformation externt Projektinformation kommer att spridas externt enligt följande: Informationsplan KA V1.0 Användarmanualer KA 1.0 (on-line i KA) Ändringslogg KA Slutrapport KA V1.0 Samtliga frysta dokument kommer att finnas tillgängliga via Livelink, Projektpärm 1. Vid behov tar projektet fram distributionslistor för ovanstående dokument. 6.6.2 Projektinformation internt Internt finns följande projektinformation tillgänglig: Projektdefinition Projekt KA V1.0 Kravspecifikation KA V1.0 Lösningsspecifikation KA V1.0 Projektrapport med bilagor Mötesprotokoll Samtliga frysta dokument kommer att finnas tillgängliga via Livelink, Projektpärm 1. Vid behov tar projektet fram distributionslistor för ovanstående dokument. I annat fall skall projektmedlemmarna aktivt söka upp önskad information.

Sidan: 20 (30) 6.6.3 Mötesstruktur Nedan redovisas de regelbundna möten som finns i projektet. Stående dagordningar fastställs vid första mötet. Styrgruppsmöten Vid planerade beslutspunkter eller vid behov. Protokoll förs av PL (via sekreterare). Projektledningsmöten Varje måndag. Protokollförs av PL. Avstämningsmöten (Teknikgrupp, Kravställningsgrupp, Testgrupp, Referensgrupp) Vid behov, ca en gång i veckan. Protokollförs vid behov av Teknikgruppsledare, Kravställningsgruppsledare, Testledare, Referensgruppsledare. Projektmöten Vid behov, minst en gång per månad, exempelvis efter styrgruppsmöten. Protokollförs av PL.

Sidan: 21 (30) 7 RISKER Här redovisar Vi de risker som har identifierats under förberedelsefasen. Vi redovisar också vilka åtgärder som är genomförda eller skall genomföras. 7.1 Projektrisker 1) Resursbrist avseende teknik- och utvecklingskompetens: Effekt: Sannolikhet: Åtgärd: Teknikgruppen får svårigheter att leverera enligt tidplan Hög Informera Styrgruppen och CITES. Förstärka teknikgruppen med rätt kompetens och resurser, skriv personliga åtaganden som påvisar varje projektmedlems ansvar och vad åtagandet innebär. 2) Detaljeringsgraden i Kravspecifikation : Effekt: Sannolikhet: Åtgärd: Svårigheter för Kravställningsgruppen att sätta gränsen för en komplett, detaljerad kravspec och känna sig klar med den samt svårigheter för beställaren att ta beslut om frysning Medel Kravställningsledaren måste styra, leda och koordinera gruppen och fokusera på resultatet Kravspecifikation. Alla Kravgrupper måste aktivt delta, för att så många krav och önskemål som möjligt skall komma fram. Sänk ambitionsnivån på en alltför detaljerad kravspec. Beställaren godkänner Kravspecifikation och sedan får inga ändringar förekomma i fryst kravspecifikation. 3) Avsaknad av inleverans Processambandskarta SA : Beskrivning: Effekt: Sannolikhet: Åtgärd: Då en total processambandskarta inte tagits fram över verksamhetsområde SA, så har Projekt KA känt att det varit svårt att skapa ett IT-stöd för arbetssättet inom SA. Projektet fruktar att inte hela arbetssättet i verksamhetsområdet kommit projektet tillhanda. Hög Informera Styrgruppen och processägarna. Processägarna bör snarast ta fram en total karta över alla processer och stödprocesser för SA samt dess beskrivningar och flöden. 4) Ej accepterade Processbeskrivningar : Effekt: Sannolikhet: Åtgärd: De framtagna processbeskrivningarna för Kursutbud och Registrering accepteras ej i verksamheten eller är okända/ej förankrade i verksamheten. Medel Informera Styrgruppen och processägarna. Processägarna måste förankra processbeskrivningarna i verksamheten, så att KA-systemet baseras på ett accepterat arbetssätt i verksamheten och blir användbart för hela organisationen. 5) Avsaknad av inleveransen Förvaltningsorganisation SA : Beskrivning: Effekt: Sannolikhet: Åtgärd: Projekt KA hade gärna sett att förvaltningsorganisationen inom verksamhetsområdet SA var klart vid införandet och att ett protokoll om resultatet hade funnits som inleverans till projektet Svårigheter med leveransen till förvaltningsorganisationen, som ej har arbetsätt, rutiner och roller klarlagda vid införandet. Projektet får dessutom merarbete att skapa temporära arbetssätt och roller samt lösa ett antal problem som egentligen ligger utanför projektets ansvar. Hög Informera Styrgruppen och verksamheten inom SA. Tillsammans med systemägaren skapa en temporär lösning på förvaltningsorganisation för KA.

Sidan: 22 (30) 6) Avsaknad av inleveransen Produktionsmodell : Effekt: Sannolikhet: Åtgärd: Svårigheter att genomföra krav- och utvecklingsdelen av projektet utan metod och rutin, då produktionsmodell som skall komplettera projektstyrningsmodellen i detta avseende saknas. Försening av tidplan uppstår. Medel Informera Styrgruppen och CITES. Intervjua CITES-personal och använd vissa framtagna arbetsformer och tankar till att ta fram projektets egna arbetsrutiner och systemutvecklingsmetoder. Projektet kan mycket väl använda egen produktionsmodell tillfälligt, men styrgruppen bör tänka på att lösa detta i framtiden, dvs. ev. till nästa version av KA eller nya projekt. 7) Avsaknad av inleverans Persondatabas Effekt: Sannolikhet: Åtgärd: Projektet får ett onödigt merjobb, till en högre kostnad. Hög Informera Styrgruppen och CITES. Projektet får temporärt bygga en egen persondatabas med alla uppgifter, för att få samma funktionalitet och kunna leverera systemet. 7.2 Produktrisker 1) Nedskärning i budget alternativt omprioritering av funktionalitet Effekt: Sannolikhet: Åtgärd: Användarnas förväntningar av leveransen kan ej infrias om för mycket funktionalitet skalas av eller inte finns med i leveransen Låg/Medel Beställaren, modulansvariga och användare måste vara delaktiga i alla ändringar och beslut, för att inte överraskas. Kravställningsgruppens arbete med både Kravspecifikation och testning revideras kontinuerligt av Referensgruppen. Genom GUI-prototyper (grafiska användargränssnittsprototyper) kommer beställare och modulansvarig lättare att kunna ge synpunkter och styrning innan slutleverans. 2) Planerad systemlösning håller inte med vald tekniklösning Effekt: Sannolikhet: Åtgärd: Projektet får problem med utveckling, lagring, gränssnitt, kopplingar eller integrering. Lösningen blir inte det förväntade. Medel Teknikgruppsledaren måste tidigt avisera om vald teknik eller systemdesign är den rätta 3) Ineffektiva eller ej smarta lösningar i systemet Effekt: Sannolikhet: Åtgärd: På grund av avsaknad av systemutvecklingserfarenheter i vald utvecklingsmiljö (Zopemiljö) kan det resultera i att de optimala och effektivaste lösningarna inte skapats i denna första versionen. Medel Informera beställare och styrgrupp. Sänk ambitionsnivån på leveransen av version 1.0 och planera en tydlig och omfattande Ändringslogg KA, där dessa problem loggas, utreds och löses i nästa version, då erfarenhet av utvecklingsmiljön införskaffats.

Sidan: 23 (30) 4) Osäker framtid med Zope som Open Source Beskrivning: Effekt: Sannolikhet: Åtgärd: Då Zope f.n underhålls och utvecklas av ett relativt litet företag, finns ett antal osäkerhetsfaktorer runt Zope-miljön. Frågeställningar: Om något händer med företaget, hur stor är risken att utvecklingen avstannar med tanke på att miljön är Open Source och andra kan ta över? Vilka andra är intresserade av att ta över underhåll och vidareutveckling av Zope? Hur känt/välanvänt är Zope? Hur ser man generellt på Zope som plattform? Svårigheter för projektet eller förvaltningsorganisationen att fortsätta utveckla/underhålla och vidareutveckla KA-systemet i Zope-miljö samt att hitta rätt kompetens för eventuellt eget underhåll av Zope-miljön. Låg/Medel Informera beställare och styrgrupp och CITES. Skulle detta inträffa måste konsekvensanalys samt handlingsplan tas fram för fortsatt användning alternativt utbyte av plattformen

Sidan: 24 (30) 8 EKONOMI 8.1 Kalkyl Här redovisar Vi antalet timmar, investeringar och andra kostnader som krävs för att genomföra projektet. Se Kalkyl KA V1.0 (bilaga C). 8.2 Finansiering Här anger Vi hur projektet ska finansieras. Projektet finansieras av Bo Egardt, Prorektor, inom ramen för stiftelsens IT-satsningar under år 2001.

Sidan: 25 (30) 9 REFERENSER Här redovisar Vi vilka dokument som projektdefinitionen refererar till. Referenser skall finnas till kravbeskrivningen och/eller andra dokument som fastställer kravbilden eller utgör underlag för projektet. Referenser kan finnas till dokument som beskriver projektets arbetssätt. Här följer listan på de dokument som det finns referenser till i projektdefinitionen. Ref. Dokumentnamn och dokumentbeteckning Utgåvenummer och dokumentdatum Produktstyrande dokument 1 Förstudie Kursadministrativt System, CTK AB 2000-04-27. 2 Förstudie Kursplaner och ECTS-information, CTK AB 2000-11-28 3 Kravspecifikation KA Utg. 1.0 4 Lösningsspecifikation KA Utg. 1.0 5 Ändringslogg KA Utg. 1.0 Projektstyrande dokument 6 Projektdirektiv 2001-04-18 7 PPS Handbok Utg. 3.1 8 Rational Unified Process, RUP

Sidan: 26 (30) Bilaga A: Funktionalitet KA V1.0 Detta är en sammanfattning av funktionaliteten i KA-systemet version 1.0, formulerade utifrån krav enligt Kravspecifikation KA. Allmänt KA-systemet skall byggas som ett webbaserat system mha applikationsservern Zope och databashanteraren Oracle. Systemet skall byggas för att kunna köras dygnet runt, med undantag för kortare stopp för backup och systemunderhåll, i CITES nuvarande driftmiljö. Systemet skall följa Chalmers ABs webpolicy, vara intuitivt och lättanvänt och kunna administreras utan programmeringsinsatser. Tillgänglighet till funktioner och data skall styras mha roller som tilldelas användarna. Viss data är tillgänglig för alla, men systemets målgrupp är studenter och personal på Chalmers. Beroende på administratörers beslut kan diskussionsforum och notis-funktion vara tillgängligt i de olika modulerna. Portal Innehållet i Portalen bestäms och redigeras av en administratör i ett formulärbaserat gränssnitt. Beroende på administratörsstyrning innehåller portalen tjänster och information av intresse för studenterna på Chalmers, t ex länkar till allmänna tjänster som studieinformation, aktuella aktiviteter, läsårstider, kalendarium länkar till externa system som Chalmers Studentkår, Chalmers Lindholmens studentportal, Careers service inloggning för att få tillgång till personliga tjänster som meritförteckning, kursval, MTS, kursutbud, registrering Personlig information Efter inloggning visas en portalsida upp med innehållet anpassat efter användaren. Så långt det är möjligt visas i första hand meddelanden och händelser som berör studentens kurser och program. Dessutom blir vissa helt personberoende tjänster tillgängliga, t ex adressändring översikt över studieresultat ( förteckning över studieresultat ) Kursutbud Administratören kan skapa nya kurser, och redan befintliga kan ändras, tas bort eller anmälas som nedlagda. Modulens godkännandeprocedur tillåter godkännande av information i olika behörighetsnivåer. Informationen om en kurs finns på tre nivåer: gällande - grunden för läsårets studier arbetsupplaga för löpande arbete under året, samt arkiv tidigare års versioner. Den gällande kursinformationen är tillgänglig för alla. Kursinformationen är anpassad till den europeiska standarden, ECTS, och är underlag för rapportering av ny och ändrad information till LADOK. Kursval Modulen skall stödja den process vilken leder fram till att studenten godkänner sitt kursval.

Sidan: 27 (30) Administratören skall kunna definiera ett kursval genom att ange starttid och sluttid för val, möjliga kurser, vilka studenter som får välja mm. Administratören skall kunna sätta upp regler som styr studenten att göra giltiga val och i annat fall hänvisas till programkansli eller dylikt. Studenten kan se de kurser som är möjliga att välja aktuell termin. Det skall vara enkelt att överblicka obligatoriska kurser och kurser som tillhör kursprogrammet, vilka studenten bör välja. I fallet övriga kurser skall det för studenten framgå att det är en kurs utanför programmet och vägledning skall ges för att kunna göra ett val. Om studenten vill välja icke valbara kurser, läsa mer än 30 poäng per termin eller på något annat sätt inte följa regler för kursval, skall kontaktinformation till programkansli eller dylikt finnas tillgängligt. Studentregistrering Modulen skall stödja den process vilken leder fram till att studenten godkänner sitt kursval och därmed blir terminsregistrerad och registrerad på de kurser som skall läsas. Studenten skall ges möjlighet att på ett enkelt sätt bekräfta det kursval som tidigare gjorts, eller ändra sina tidigare val. Önskade ändringar skall godkännas av registreringsansvarig, vars arbete skall underlättas genom att det är lätt att överblicka önskade ändringar. Registreringsansvarig kan godkänna eller underkänna studentens registrering. Underlag för att överföra inhämtad information till berörda system och myndigheter skall skapas. Kurshemsidor Kurshemsidan skall innehålla information vilken studenten, för aktuell kurs, kan tänkas behöva. Administratören styr innehåll på kurshemsidan. Exempel på möjlig information för kurshemsidan är: Aktuellt, dagens meddelande för kursen Utdelat material, möjlighet för kursansvarig att lägga upp samt för student att hämta hem viss kursrelaterade filer via nätet Undervisning, information om tid, plats, ämne Grupper/gruppindelning, val av och information om grupptillhörighet Filinlämning, inlämning av inlämningsuppgifter och grupparbeten Diskussionsforum för kursen Personal, uppgifter om ansvarig personal för undervisning och labbar Studenter, namn och e-postadress på studenter som är registrerade på kursen MTS Administratören skall kunna initiera MTS-val och lägga in MTS-föreläsningar. Vidare skall det vara möjligt att se statistik för valutfall. Adminstratören skall kunna köra fördelningsprogrammet och ta ut närvarolistor. Studenten skall kunna välja MTS-föreläsningar i prioriterad ordning, ändra sitt val och få bekräftelse av val. Det skall också vara möjligt att göra sista-minuten-val.

Sidan: 28 (30) Bilaga B: Tidsplan KA V1.0 Tidsplan Projekt KA, Översikt Idag 2001-06-20 BP2 2001-08-20 2001-08-27 2001-08-28 BP3/BP4 2001-10-01 2001-10-03 BP5 2001-11-05 2001-12-03 2001-11-05 BP5 2001-11-26 BP5 2001-12-20 BP6/BP7 2001-12-20 2002-01-28 BP8 Semester Genomförande Jul & Nyår 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 1 2 3 4 5 Aug Sep Okt Nov Dec Jan 6 2 Milstolpar: 2001-08-20: Kravspecifikation 1.0 klar 2001-08-27: Utv.plattform beslutad, moduler fördelade 2001-10-01: Start av gräsnsnittsdemonstrationer 2001-11-05: Start av funktionstester, prestanda etc. 2001-12-03: Start av sluttester 2001-12-20: Leverans av KA-systemet version 1.0 Styrgruppsmöten: BP2 Diskussion om PDF BP3 PDF(Projektdefinition) klar BP4 Genomförandet startar BP5 Uppföljning genomförandet BP6 Leverans till beställare BP7 Överlämning till driften BP8 Projektavslut

Bilaga C: Kalkyl KA V1.0 Sidan: 29 (30) Sidan 1 Kalkyl KA V1.0 (010701-020128) Budget Budget Budget Resurs timmar i projektet projektkostnad totalkostnad Externa resurser Projektledning 828 869 400 Kravställningsledare & Testledare 704 563 200 Teknikgruppsledare 920 690 000 Utvecklare 720 540 000 Analys 80 84 000 Kvalitetssäkring 80 84 000 Kravställningsledare Askus 48 52 800 Summa externa resurser 3 332 2 883 400 Interna resurser Projektchef 1 000 255 000 Referensgruppsledare 210 35 000 Teknikstöd 832 245 440 Fd Referensgruppsledare 48 14 400 Utvecklare1 760 224 200 Utvecklare2 456 116 280 Databasadministration 84 25 200 Summa interna resurser 3 390 915 520 Interna omkostnader OH CITES 165 000 Lokaler/möten, t ex hus 8 20 000 Utbildning (PPS)/resor/konferenser 40 000 Övrigt t ex kick-off, seminarier 40 000 Summa intern overhead 265 000 Totalsumma resurser 4 063 920

Resursbehov: Sidan: 30 (30) Sidan 2 Kalkyl KA V1.0 (010701-020128) arbetsveckor tim per vecka timmar i projekt Externa resurser Projektledning 23 36 828 Kravställningsledare & Testledare 22 32 704 Teknikgruppsledare 23 40 920 Utvecklare 18 40 720 Analys 20 4 80 Kvalitetssäkring 20 4 80 Kravställningsledare Askus AB 6 8 48 Summa externa resurser 3380 timmar Interna resurser Projektchef 21 40 1000 Referensgruppsledare 21 10 210 Fd referensgruppsledare 4 12 48 Teknikstöd 21 32 832 Utvecklare1 19 40 760 Utvecklare2 19 24 456 Databasadministration 21 4 84 Summa interna resurser 3390 timmar Totalsumma resurser 6770 timmar