Sidan: 1(12) Projekt KA KA-system Version 1.0 Filnamn: KA1.0 1.0.doc
Sidan: 2(12) INNEHÅLL 1 Introduktion 3 1.1 Bakgrund 3 1.2 Metod 3 1.3 Läsanvisningar 3 2 Resultat från intervjuer 4 2.1 Allmänna frågor 4 2.2 Projektets styrning och omgivning 5 2.3 Projektets ledning 6 2.4 Kravhantering 6 2.5 Test 7 2.6 Design och implementation 8 3 Analysgruppens slutsatser 9 3.1 Vad är bra? 9 3.2 Vad kan förbättras? 9 3.3 Slutord 10 4 Referenser 12 Filnamn: KA1.0 1.0.doc
Sidan: 3(12) 1 Introduktion 1.1 Bakgrund En projektanalys av KA-projektet har beställts från dess projektledning (se ref. 1). Analysen har följande mål: Att bedöma projektets möjligheter att nå projektmålet. Att bedöma projektets metoder och arbetssätt. Resultatet skall dels vara till stöd för det resterande projektarbetet, dels för kommande projekt. KA-projektets mål (se ref. 2), är att KA-systemet version 1.0 finns i drift på Chalmers i januari 2002. Vad version 1.0 av systemet skall leva upp till finns specificerat i ref. 3. 1.2 Metod Projektanalysen har genomförts dels genom att studera de dokument som projektet arbetar med, dels genom att intervjua fem utvalda personer inom KA-projektet. Analysen har gjorts med avseende på följande fyra perspektiv: Projektets ledning och styrning Kravhantering Test Design och implementation Frågor runt trivsel, engagemang och arbetsmiljö har också studerats. Analysarbetet kan delas in i en förberedande fas, en genomförandefas, samt rapportskrivning. Genomförandet ägde rum under perioden 1 oktober till 17 oktober, och det är alltså projektets status vid denna period som rapportens innehåll rör. 1.3 Läsanvisningar I rapporten görs en tydlig åtskillnad mellan vad som framkommit vid intervjuerna å ena sidan, och analysgruppens reflektioner å den andra sidan. Information från intervjuerna återges i kapitel 2, och analysgruppens slutsatser i kapitel 3. Filnamn: KA1.0 1.0.doc
Sidan: 4(12) 2 Resultat från intervjuer 2.1 Allmänna frågor 2.1.1 Fråga: Vad fungerar bra? Att vi sitter ihop. Att flera av våra tekniker är insatta i den verksamhet i vilken systemet skall användas. Kompetenta medarbetare. Vi har rätt man på rätt plats. Bra att de modulansvariga har stor verksamhetskunskap och att de finns kvar i verksamheten när projektet är avslutat. Vi har ett gemensamt mål. Vi är ett bra gäng och alla vill väl (även om vi inte alltid har samma åsikter om saker och ting). 2.1.2 Fråga: Vad kunde ha fungerat bättre? En produktionsmodell hade behövts, dvs. en definierad systemutvecklingsprocess. Projektets korta kalendertid känns ofta pressande. Vi hade velat vara tidigare framme med GUI-prototypernas färdigställande, så att dessa var presenterade innan kravlåsningen. 2.1.3 Fråga: Vilka lärdomar har gjorts i projektet under hösten De olika sektionerna gör på olika sätt och har olika rutiner avseende ekonomi- och fakturering. Detta måste man känna till i projektets budgeteringsarbete. Det finns kulturskillnader mellan IT-konsultföretag och Chalmers akademiska värld. Det är viktigt att man som konsult är medveten om detta. Chalmers är i väldigt liten grad projektorienterade. Detta kan inte underskattas när projekt skall drivas på Chalmers. (T ex vetskapen om att ett projekt bara är något som existerar under en begränsad period, med allt vad det innebär.) En ganska stor skepticism till modeller och arbetssätt finns på Chalmers. Vi hade velat ha en klarare kravbild av prestanda och last. Kravställning med Use-Cases hade varit bra, men det befintliga projektläget tillät inte det. Man borde inte starta ett projekt innan nödvändigt förarbete är gjort från beställarens sida. Det är viktigt att den infrastruktur (t ex avseende teknik) som man skall använda finns på plats. Säkerställ att representanter från den mottagande verksamheten har avsatt tid till projektet. 2.1.4 Vilka är projektets största risker? Risken att projektets överlämning inte blir lyckad. Detta, på grund av att förvaltningsorganisation saknas. En utpekad systemägare finns och "bollen" ligger nu utanför projektet. Att vi upptäcker några begränsningar i Zope-milön som hindrar oss i arbetet. Filnamn: KA1.0 1.0.doc
Sidan: 5(12) 2.2 Projektets styrning och omgivning 2.2.1 Fråga: Vad fungerar bra? Styrgruppen har stor "tyngd" i organisationen. 2.2.2 Fråga: Vad kunde ha fungerat bättre? Bättre beställarkompetens. Beställaren och dess organisation hade behövt mer kunskap om hur de fungerar internt, t ex avseende dess struktur, processer och rutiner. Beställaren borde i högre grad ta på sig arbetet att "promota" (motivera) projektets existens. T ex genom att ta fram en kostnads- & intäktsanalys för det planerade systemet. Rutinerna på Chalmers för hur projekt informerar sin omgivning. Fler spontana önskemål från verksamhetens sida att samverka med projektet. T ex genom att ge önskemål och synpunkter. Det är svårt att ha ett nära samarbete med systemägaren, pga. att denna inte är så fysiskt tillgänglig. Ett större engagemang från den mottagande verksamheten vore önskvärt. 2.2.3 Fråga: Är alla styrgruppsmedlemmar engagerade och väl förberedda? Nej, tyvärr. Ja, ganska. Men från vissa håll hade det kunnat vara bättre. 2.2.4 Fråga: Vem har huvudansvaret för att styrgruppens förväntningar överensstämmer med projektets egen uppfattning? På vilket sätt görs detta? Projektchefen har detta huvudansvar. Det görs genom demonstrationer och prototypvisning på styrgruppsmötena. Detta ansvar delas mellan styrgruppsordföranden och projektchefen. Det görs genom att projektledningen rapporterar till styrgruppen. 2.2.5 Fråga: Är projektdefinitionen ett "heligt kontrakt" mellan projektet och beställaren? (Hur kommer avvikelser från dessa dokument att hanteras?) Styrgruppens prioritets-direktiv är: 1. Tid, 2. Kostnad, och 3. Resultat. Förståelse kommer finnas om avvikelser med avseende på 3 sker. Beställaren förväntar sig att Projektdefinitionen hålls, men avvikelser accepteras i viss mån med bra motiveringar. Styrgruppen är medveten om att projektets uppgift är utmanande. 2.2.6 Fråga: Vem på CITES godkänner leveransen? Är denna person informerad och förberedd på rollen? Görgen Olofsson som är driftsleverantör godkänner leveransen. Ja, han är informerad och förberedd på rollen. Vilka överenskommelser finns mellan projektet och dess mottagare angående utbildning och support runt produkten? Filnamn: KA1.0 1.0.doc
Sidan: 6(12) 2.2.7 Fråga: Vilka överenskommelser finns mellan projektet och dess mottagare angående utbildning och support runt produkten? Utbildning sker endast till dem som ingår i arbetsgrupperna, samt till delar av sektionernas IT-avdelningar. Projektets ansvar i detta gäller endast under projekttiden (dvs. före BP8). 2.3 Projektets ledning 2.3.1 Fråga: Vad fungerar bra? Den nya projektorganisationen känns bra. PPS-modellen ger stöd. En fast budget för hela projekt-löptiden skapar arbetsro. 2.3.2 Fråga: Under sektion 6.1 i PDF-dokumentet står att produktionsmodellen bland annat kommer bygga på utvalda delar av RUP. Vilka delar har ni valt att ta fasta på? Detta gäller mest krav-disciplinen. I övrigt, ej så mycket. RUP-inslag finns inom krav och test-området, när det gäller dokumentens struktur och innehåll. 2.3.3 Fråga: Vilka milstolpar har hittills passerats? Vilken milstolpe jobbar ni mot nu, och vilka kriterier är kopplade till den? MS1, 2 och 3 är passerade. Nu arbetar vi mot MS4: "Start av funktionstester, prestanda, etc.", som är planerad till den 5/11-01. 2.3.4 Fråga: Är format och innehåll på produktens dokumentation överenskommet med CITES? Om ja, finns förteckning över de produktdokument som kommer tas fram? Nej, inte ännu. Vår nuvarande lösningsspecifikation utgör grunden till den lösningsspecifikation som kommer ingå i systemdokumentationen. 2.3.5 Fråga: På vilket sätt sker uppföljningen inom projektet? Projektledaren följer upp förbrukad tid kopplad till resp. modul. Teknikgruppsledaren meddelar i procent i vilken utsträckning delar av respektive modul är klara. Testledaren meddelar vilka krav som är implementerade. 2.3.6 Fråga: I PDF sektion 6.3.2 beskrivs att lösningsspecifikationen skall vara klar innan starten av genomförandefasen (1 sept). Vilken är lösningsspecens nuvarande status? Lösningsspecen är påbörjad och kommer inte vara klar förrän till leveransen den 20/12. 2.4 Kravhantering 2.4.1 Fråga: Vad fungerar bra? Bra att kravspecifikationen är "spikad och klar". Filnamn: KA1.0 1.0.doc
Sidan: 7(12) Kommunikation med kravställarna. 2.4.2 Fråga: Finns KA-systemets omgivning beskriven någonstans? (T ex gränssnittet mot LADOK, mm.) Tänkta användartyper finns med i kravspecen. Om den resterande omgivningen är beskriven eller ej, det vet jag inte. 2.4.3 Fråga: Varje krav har som bekant en prioritet kopplad till sig (H, M, L). Hur används denna i projektet? Alla de krav som tillhör en och samma modul har lika stora prioriteter. Detta beror på att systemägarna hittills bara har gett prioriteter på modul-nivå. 2.4.4 Fråga: I PDF sektion 6.3.1 står att "systemansvarig" är den som avgör när kravspecen är redo att frysas. Vem är det som har denna rollen? Ing-Britt Svensson är systemansvarig. 2.5 Test 2.5.1 Fråga: Vilka förberedelser/planer finns för upprättande av testmiljön? Testmodell och plan klar den 19/10. Testmiljö klar den 26/10. Test startar den 5/11. Utvecklingsteamet kommer arbeta med att sätta upp testmiljön. (Dario, Andreas, m. fl.) Exakt ur uppsättningen av miljön går till är ännu oklart. Jag tror att initieringen av testmiljön inför varje test kan vara knepig. 2.5.2 Fråga: Enligt testplanen kommer två testomgångar att äga rum: "Test" resp. "Leveranstest". Vilka testfall kommer genomföras under respektive testomgångar? Under "Test" kommer vi genomföra testfall motsvarande det som då är implementerat. Vilka delar dessa blir, är i nuläget ej fastställt. Denna milstolpe är inte tillräckligt definierad. Under "Leveranstest" kommer resterande testfall i testmodellen att genomföras. 2.5.3 Fråga: I vilket testskede kommer vi att verifiera kommunikationen med LADOK? Kommunikationen från KA till LADOK är en viktig fråga att ta tag i. Kravbilden är ej klar, och tester kommer sannolikt att behövas. 2.5.4 Fråga: Vilka rutiner finns för att hantera fel som uppkommer under testerna? (Grad av formalitet, ansvarig, mm.) Fel som uppkommer under testerna rapporteras via ett Excel-dokument som heter "Testresultat". Testledaren är ansvarig för att förmedla denna hantering till teknikgruppen. Filnamn: KA1.0 1.0.doc
Sidan: 8(12) 2.6 Design och implementation 2.6.1 Fråga: Vad fungerar bra? Medarbetarna är kompetenta. 2.6.2 Fråga: Vad kunde ha fungerat bättre? Systemets tekniska fundament är väldigt viktigt. (Teknisk plattform och utvecklingsmiljön.) Detta kunde ha varit bättre. Ett "skelett" i systemutvecklandet. Vi borde arbeta mer aktivt med lösningsspecifikationen under projektets gång. Vi hade velat ha mer erfarenhet av Zope-miljön. 2.6.3 Fråga: Vad är syftet med lösningsspecifikationen, och hur används den (frysning, mm.)? Att beskriva vad som skall utvecklas, och i viss mån hur utvecklaren gjorde. Det sist nämnda, som en sorts logg. Eftersom lösningsspecen ej skall levereras, så räcket det att den är klar i god tid innan Systemdokumentationen skall vara klar. 2.6.4 Fråga: Vilken information finns eller kommer tas fram rörande systemets konstruktion? En systemdokumentation samt en utvecklingshandbok. Systemdokumentationen skall beskriva systemets uppbyggnad. Den nuvarande lösningsspecifikationen kommer att utgöra indata till systemdokumentationens framtagning. Utvecklingshandboken å andra sidan skall beskriva hur Zope används på Chalmers. 2.6.5 Fråga: Varje krav har som bekant en prioritet kopplad till sig (H, M, L). Hur används denna i projektet? Alla krav har i princip samma prioritet, med undantag av några få krav som inte är fullt så viktiga. Ovanstående prioriteter används inte i praktiken. 2.6.6 Fråga: I vilken ordning kommer de i kravspecifikationen beskrivna kraven att implementeras? Den ordningen är inte definierad. Kraven är inte prioriterade på ett sådant sätt att någon sådan inbördes implementeringsordning skulle ge nåt mervärde. (Mervärde, i händelse av att inte allt skulle bli klart inför leverans.) Däremot arbetar vi med systemelement och i vilken ordning som de kommer implementeras. 2.6.7 Fråga: Hur ser övergången/överlämningen ut från utvecklingsteamet till test-teamet? (organisation, leveransform, mm.) Utvecklingsteamet skall leverera ett testsystem i vilket leverablerna (exekverbar kod) är "up and running". Filnamn: KA1.0 1.0.doc
Sidan: 9(12) 3 Analysgruppens slutsatser 3.1 Vad är bra? Stämningen mellan projektmedlemmarna är bra. Alla vet vilka roller de har i projektet, och hanterar rollen på ett kompetent sätt. Medarbetarna har relativt stor arbetsro (trots den ganska pressade tidsplanen). Samarbetet mellan projektledningen och arbetsgrupperna fungerar bra. Projektet har relativt hög kunskapsnivå rörande den verksamhet i vilken projektets leverans skall användas. Att vissa av projektets medarbetare finns kvar i organisationen efter projektets slut Projektledningen ser mycket positivt på att ha en fast budget för hela löptiden, ty det skapar arbetsro. 3.2 Vad kan förbättras? 3.2.1 En mer aktiv beställare Projektet upplever att de får ägna sig åt saker som ligger inom beställarens ansvarsområde. Exempel på sådana saker: Ta fram underlag som motiverar projektets existens och genomförande. Se till att den mottagande verksamheten är utsedd, att de är aktiva, och att de är väl förberedda inför mottagandet. Orsaken till ovanstående problem är sannolikt att inte alla på Chalmers är fullt införstådda i projektbegreppet som arbetsform. Exempel på sådana frågor är innebörden av att ett projekt bara existerar temporärt, eller kunskap om vilka krav ett framgångsrikt projekt måste kunna ställa på sin närmaste omgivning. 3.2.2 Prioriteter på kraven Alla krav som tillhör en och samma modul har i regel samma prioritet. Detta kan tolkas som att projektet borde lägga all kraft på att färdigställa högt prioriterade moduler som Studentportal och Kursutbud, innan de lägger tid på lågt prioriterade moduler som Kursval. Ett sådant projektupplägg har dock inte valts. Analysgruppens slutsats blir att kravens prioriteter inte inverkar på projektets resursstyrning i den utsträckning som de borde. 3.2.3 Progressmätning Milstolparna i genomförandefasen behöver definieras tydligare, samt formuleras så att de är utvärderingsbara. De nuvarande beskrivningarna (t. ex: Start av gränssnittsdemonstrationer, Start av funktionstester) säger inte så mycket om vad man planerar ha klart vid aktuellt tillfälle, och hur det som är färdigt skall kunna utvärderas. Milstolpskriterierna skulle t ex kunna formuleras i termer av vilka krav som är realiserade (alternativt vilka systemdelar som är klara, eller vilka testfall som skall kunna köras). Använd redan från början korta och entydiga benämningar på milstolparna (t ex MS1, MS2, osv.) Då kan både milstolpens datum och dess utvärderingskriterier uppdateras Filnamn: KA1.0 1.0.doc
Sidan: 10(12) och förfinas utan att milstolpens identitet påverkas. (Denna terminologi infördes under analysens genomförande.) 3.2.4 Leveranssäkerhet Projektet är som bekant hårt pressat i tiden, och ingen är riktigt säker på om alla systemets krav kommer vara realiserade till projektets slutleverans (vars datum är fix och är av högsta prioritet). Ett sätt att angripa detta på, är att realisera systemet (dvs den totala mängden krav på systemet) i en sådan ordning, att det viktigaste alltid* kommer vara realiserat och ingå i leveransen. (*: Oavsett om det med facit i hand visar sig att man lyckades realisera 50%, 75%, eller 95% av det totalt specificerade systemet.) För att kunna implementera systemet i en sådan ordning behöver våra krav vara prioriterade med avseende på hur viktigt det är att det specifika kravet är realiserat vid slutleveransen. Denna prioritet blir sedan indata till definition av milstolparna i genomförandefasen. Milstolpskriterierna formuleras i termer av vilken delmängd av kraven som är realiserade och utvärderingsbara i form av ett framtaget exekverbart system. 3.2.5 Systemdokumentation Format, namn och innehåll på systemdokumentationen verkar ännu oklart bland medarbetarna. Tydliggör så snart som möjligt om det är lösningsspecifikationen som, efter komplettering, skall beskriva systemets konstruktion, eller om ett helt annat dokument (med helt annat format) skall tas fram. I den produktdokumentation som levereras tillsammans med systemet bör en beskrivning av systemets konstruktion ingå. Denna konstruktions/design - specifikation behöver vara tillräckligt komplett och detaljerad för att mottagaren (systemets förvaltare) skall kunna förstå "tänket" mellan kravspecifikation och källkod. I detta dokumentationsarbete, sträva efter att lägga kraften på att beskriva de aspekter av systemkonstruktionen där den största komplexiteten finns. Det är av största vikt att börja i den ändan. Speciellt om man dokumenterar konstruktionen efter att den redan är gjord. Beskriv t ex ingående delsystem, moduler, och komponenter, samt hur dessa samverkar med varandra. Använd figurer som stöd till texten. Beskriv vad som tas fram rent fysiskt i termer av körbara filer (enskilda eller grupper), samt hur de samverkar med varandra. Under dokumentationsframtagningen, låt gärna en eller flera representanter från de som skall ta över systemet ta del av upplägg och innehåll. Detta, för att säkerställa att dokumentationen passar mottagarens nivå och behov. 3.2.6 Samverkan mellan KA-systemet och LADOK Kommunikationen från KA till LADOK verkade vid analysens tidpunkt oklar. Hur ser gränssnittet ut? Vilka krav ställer LADOK, osv. Ta tag i denna eventuella risk (om det inte redan är gjort). 3.3 Slutord I somras när detta projekt gick igång i sin nuvarande form var det mycket som skulle åstadkommas på kort tid. Ett system skulle tas fram samtidigt som förändringar i olika Filnamn: KA1.0 1.0.doc
Sidan: 11(12) avseenden väntade projektet. Det rörde förändringar med avseende på nya projektmedarbetare, roller, arbetssätt, mm. Sådant förändringsarbete måste tas i lagom stora steg om produktivitet och arbetsglädje inte skall stryka på foten. Min bedömning är att projektledningen just har tagit ett sådant steg i rätt riktning. Vissa av punkterna i sektion 3.2 bör nog därför ses som förbättringstips på lite längre sikt än inom detta pågående projektet. För att det i kommande projektanalyser skall vara möjligt att uttala sig om projektets leveranssäkerhet behöver synpunkter av den typ som ges i sektion 3.2 adresseras. Filnamn: KA1.0 1.0.doc
Sidan: 12(12) 4 Referenser 1. Direktiv Projektanalys, "KA1.0_Direktiv_Projanalys_2.doc". 2. Projektdefinition KA, " KA1.0_Projektdefinition_1.0.doc". 3. Kravspecifikation KA, " KA1.0_Kravspecifikation_1.1.doc" Filnamn: KA1.0 1.0.doc