Sidan: 1(23) RISKANALYS Projekt KA KA-system Version 1.0
Sidan: 2(23) INNEHÅLL 1 REVISIONSINFORMATION... 3 2 OM DETTA DOKUMENT... 4 2.1 Syfte... 4 2.2 Målsättning... 4 2.3 Omfattning... 4 2.4 Metod... 4 3 SAMMANFATTNING... 5 Sortering efter prioritet... 5 4 PROJEKTRISKER... 7 P1 Nyckelpersoner med flera uppdrag... 7 P2 Bortfall av personal, sjukdom... 8 P3 Resursbrist avseende teknik- och utvecklingskompetens... 9 P4 Kort kalendertid... 10 P5 Avsaknad av Produktionsmodell... 11 P6 Avsaknad av Chalmersgemensam Persondatabas... 12 5 AFFÄRS- & PRODUKTRISKER... 13 A1 Kvalitet på kravställning... 13 A2 Ej godkänd enligt PUL och andra lagar... 14 A3 Avsaknad av Processbeskrivning SA... 15 A4 Avsaknad av Förvaltningsorganisation SA... 16 A5 Svårigheter med terminologiförvirring... 17 A6 Svårunderhållen kod, förvaltningsovänligt system... 18 6 TEKNISKA RISKER... 19 T1 Vald tekniklösning håller ej... 19 T2 Avsaknad av utvecklingserfarenhet i Zope... 20 T3 Lasthantering... 21 T4 Ej realistiska tester... 22 7 REFERENSER... 23
Sidan: 3(23) 1 REVISIONSINFORMATION Utarbetat av Datum Utgåva Ändringar 01-09-27 P1.5 Utskick till styrgrupp på remiss 01-10-04 P2.0 Kommentarer omhändertagna 01-10-11 1.0 Godkänd Riskanalys
Sidan: 4(23) 2 OM DETTA DOKUMENT Detta dokument beskriver projekt KA:s risker. Dokumentet är en uppdatering av den Riskanalys som gjordes i Projekt KA 2000-10-31, samt kompletterad med kapitel 7 Risker i den godkända KA1.0_Projektdefinition_1.0, se kap 7 Referenser. Dokumentet baserar sig på projektets nya dokumentmall. 2.1 Syfte Att lista hot och risker, göra en uppskattning och prioritering samt föreslå åtgärder för att eliminera eller minimera riskerna. 2.2 Målsättning Att identifiera de risker som finns, informera styrgruppen och beställaren/systemägaren samt att ta hand om de identifierade riskerna och hantera dem under genomförandet, dvs. utvecklingsfasen. så att införandet av systemet skall gå så smidigt som möjligt och att lägga grunden för en kommande implementering av systemet i verksamheten. 2.3 Omfattning Riskanalysen omfattar projekt-, affärs-/produkt- och teknikrisker. 2.4 Metod Följande steg ingår i riskanalysen: 1. Gemensamt komma överens om projektet mål 2. Lista risker och hot för projektet. Detta görs individuellt i gruppen 3. Sätt ihop en gemensam lista, som grupperas i kategorier ( på tavlan) 4. Gör en prioritering av varje risk genom att uppskatta en sannolikhet för att Risken/hotet skall inträffa och konsekvensen om det inträffar. H M L H 1 3 5 H=Hög Konsekvens M 2 4 6 M=Medel L 5 6 6 L=Låg 5. Föreslå åtgärder för att eliminera eller minimera risker, utse ansvarig person och bestämma färdigtidpunkt Prio 1 - riskerna skall elimineras Prio 2-4 - riskerna skall elimineras, hanteras eller minimeras Prio 5-6 - riskerna skall hanteras eller bevakas
Sidan: 5(23) 3 SAMMANFATTNING Sortering efter prioritet sordning: 1 har högst prioritet, 6 har lägst prioritet. Risk Risk benämning S K Prio Åtgärd NU Ansv Ansv När nr proj utanför P4 Kort kalendertid H H 1 Koordinering, styrning, SB - Löpande planering, uppföljning P6 Avsaknad av H H 1 Temporärt skapa en JG JML 01-10-01 Chalmersgemensam Persondatabas egen databas med uppgifter A2 Ej godkänd enl. PUL H H 1 Granskning utförs av MH JML/ 01-10-31 PUL-ombud IBS A4 Avsaknad av H H 1 Temporär förvaltningsorganisation MH IBS/ 01-11-05 Förvaltningsorg. SA JML A3 Avsaknad av Processbeskrivning H M 2 Detaljerade verklighets- NS Proc- 01-12-01 SA nära testfall per modul ägare T3 Lasthantering H M 2 Genomföra lasttest tidigt NS - 01-12-13 och grundligt P2 Bortfall av personal, M H 3 Undvika övertid, god SB - Löpande sjukdom projektatmosfär A1 Kvalitet på M H 3 Detaljerade testfall per NS - 01-10-31 kravställning modul, spåra test till krav A6 Svårunderhållen kod M M 4 Utvecklingshandbok, JG - 01-12-01 gemensamma komponenter, granska kod, systemdokumentationen P5 Avsaknad av M M 4 Skapa en egen JG JML/ Löpande Produktionsmodell produktionsmodell GO T2 Avsaknad av utverfarenhet M M 4 Kompetensnätverk internt JG - Löpande i Zope och externt P1 Nyckelpersoner med L H 5 Personliga åtaganden MH - 01-09-30 flera uppdrag P3 Resursbrist teknik- & L H 5 Uppföljning av JG - 01-11-30 utvecklingskompetens utvecklingsarbete T1 Vald tekniklösning L H 5 Utvärdering av Zopemiljö, JG GO/ Löpande håller ej lyft till styrgruppen JML A5 Svårigheter med L L 6 Dokumentet LS - 01-09-30 terminologiförvirring KA1.0_Terminologi T4 Ej realistiska tester M L 6 Detaljerad Testplan, verklighetsrelaterade testfall NS - 01-10-31
Sidan: 6(23) Förklaring till kolumnrubrikerna: Risk nr: Riskens nummer P = Projektrisk A = Affärsmässig risk / Produktrisk T = Teknisk risk Risk benämning: Riskens benämning (riskens namn, riskens rubrik) S: K: Konsekvens P:, Produkten av S och K. Prio 1 - riskerna skall elimineras Prio 2-4 - riskerna skall elimineras, hanteras eller minimeras Prio 5-6 - riskerna skall hanteras eller bevakas Åtgärd: Vad som skall göras för att åtgärda risken. Ansvarig: Vem som är ansvarig för att åtgärden blir utförd. När: När åtgärden senast skall vara åtgärdad.
Sidan: 7(23) 4 PROJEKTRISKER P1 Nyckelpersoner med flera uppdrag Projektet är uppbyggt på ett fåtal personer med en eller flera nyckelroller per person. Problemet som uppstår är när nyckelpersoner är involverade i flera uppdrag eller projekt. Fokusering behövs av de inblandade. Varje bortfall blir en risk. LÅG: Efter att alla projektmedlemmar godkänt sitt personliga åtagande till projektledningen, är sannolikheten rätt låg för ej fokusering och plötsligt bortfall. Konsekvenser/Effekt HÖG: Teknikgruppen får svårigheter att leverera enligt tidplan. LÅG, Konsekvens HÖG ger Prio 5 Inte ännu Projektledningen har skrivit Personliga åtaganden till varje projektmedlem, där varje projektmedlem godkänner sitt ansvar och engagemang i projektet. Även rollfördelningen som finns inom projektet fungerar i förebyggande syfte att avlasta varandra. Uppföljning av Personliga åtaganden samt planering med uppdelning och fördelning av arbetspaket
Sidan: 8(23) P2 Bortfall av personal, sjukdom Projektet är uppbyggt på ett fåtal personer med en eller flera nyckelroller per person. Bortfall av personal på grund av sjukdom eller annan lång frånvaro är en risk. MEDEL Konsekvenser/Effekt (MYCKET) HÖG MEDEL, Konsekvens HÖG ger Prio: 3 Ännu finns inga kännetecken på att vi drabbats, men det räcker med en lång sjukdomsfrånvaro så får projektet uppenbara problem. Mot sjukdom är det svårt att göra något förebyggande, förutom att skapa god projektatmosfär samt att hålla nere övertid. Akut resursförstärkning blir första åtgärd om projektet skulle förlora personal oplanerat.
Sidan: 9(23) P3 Resursbrist avseende teknik- och utvecklingskompetens Projektets teknik- och utvecklingsresurser har var och en en nyckelroll i gruppen. Om någon slutar uppstår akut resursbrist. Befintliga resurser känner till utvecklingsplattformen Zope. Det är svårt att få tag på resurser som kan Zope. LÅG: en att få resursbrist är låg. Konsekvenser/Effekt HÖG: Teknikgruppen får svårigheter att leverera enligt tidplan. LÅG, Konsekvens HÖG ger Prio 5 Inga hittills Projektledningen har skrivit Personliga åtaganden till varje projektmedlem, där var och en godkänner sitt ansvar och engagemang i projektet. Detta är en förebyggande åtgärd mot att resurser slutar oförberett, eftersom de då har ett ansvar att fullfölja åtagandet. Åtagande-avtalet gäller som ett anställningsbevis i projektet, vilket bl a hjälper projektledningen med viss framförhållning ( uppsägningstid ). Uppföljning av Personliga åtaganden. Resursbrist avseende teknikkompetens får initieras av teknikgruppsledaren i god tid, så att projektet får förstärka teknikgruppen med rätt kompetens och resurser.
Sidan: 10(23) P4 Kort kalendertid Kalendertiden i planen för genomförandet, dvs. utvecklingsdelen, är mycket knapp i förhållande till den omfattande utvecklingen. På drygt 3 kalendermånader skall specificering, analys, utveckling och test av sju moduler utföras. HÖG Konsekvenser/Effekter HÖG: Effekten med kort kalendertid är att projektet blir mycket intensivt. Projektet måste hålla högt tempo varje dag och det finns ingen tid för andrum och lugna veckor. HÖG, Konsekvens HÖG ger Prio 1 Projektet känner redan av denna risk. Den är uppenbar varje dag och kommer så att förbli tills leverans. Dock är det inget nytt eller okänt, utan alla som skrivit på sina Personliga åtaganden är införstådda i situationen. För att klara den korta tidsplanen måste projektet: Arbeta parallellt med allt, vilket kräver koordinering och information samt noggrann planering o Åtgärd för koordinering och information är bl a regelbundna möten både i projektledningen, teknikgruppen och hela projektet samt veckobrev till hela projektet. o Åtgärd för planering är bl a milstolpar för utvecklingen, uppdelning av arbetspaket (moduler och komponenter) per utvecklare, Kravplan, Testplan. Ha en stark fokusering på resultatet. o Rollindelning, avlasta varandra, var och en ansvarar för sitt o Skapa förutsättningar för att få jobba så effektivt som möjligt genom erfarenhetsutbyte/hjälpa varandra, återanvändning av kod, gemensamma komponenter, submoduler. o Ha en god projektatmosfär vi skall klara det! o Lyssna på och nyttja projektets kvalitetssäkrare i Analysgruppen. Ha god kontroll och uppföljning på projektläget och projektmedlemmarna. o Tidsrapportering veckovis samt protokollförda veckomöten. Ha ett anpassat arbetssätt, metoder och rutiner för denna typen av tidspressat projekt. o Projektledningen har beställt en Projektanalys som skall utvärdera projektets arbetssätt och metoder/rutiner Visar det sig att kalendertiden för detta åtagande är för kort så måste en akut handlingsplan skapas. Först måste styrgruppen diskutera och besluta om projektprioriteringen: resultat, tid, kostnad. Sedan måste verksamheten göra en omprioritering av funktionaliteten för att minska omfattningen och för att kunna dela upp leveransen. Beordrad övertid är inget vi strävar efter.
Sidan: 11(23) P5 Avsaknad av Produktionsmodell Chalmers saknar en generell Produktionsmodell för utveckling av produkter, i detta fall utveckling av IT-stöd. Eftersom produktionsmodellen skall komplettera projektstyrningsmodellen i ett utvecklingsprojekt med tanke på vilket arbetssätt och vilka systemutvecklingsmetoder projektet skall jobba efter, uppstår problem när den saknas. Finns en generell och gemensam produktionsmodell från början vet alla direkt vilket arbetssätt som gäller. MEDEL Konsekvenser/Effekt MEDEL: Svårigheter att genomföra krav- och utvecklingsfasen av projektet utan på förhand uppsatta metoder och arbetsrutiner. Projektet blir tvunget att lösa metoder och rutiner på eget sätt, vilket är tids- och resurskrävande och kan medföra att en försening av tidplanen kan uppstå. MEDEL, Konsekvens MEDEL ger Prio 4 Projektet känner redan av denna risk. Projektet har fått lösa problemet för att kunna gå vidare. Beräkna längre utvecklingstid för genomförandet Projektet får själv skapa det arbetssätt som passar bäst, dvs. ta fram arbetsrutiner och metoder/ systemutvecklingsmetoder för det som skall utföras. Detta blir projektets produktionsmodell, anpassat till just denna leverans och denna typ av tidspressat projekt. På lång sikt: Styrgruppen bör, för kommande projekt på Chalmers, verka för att ta fram en generell Produktionsmodell för utveckling av produkter, i detta fall utveckling av IT-stöd, så att man inte behöver uppfinna hjulet igen
Sidan: 12(23) P6 Avsaknad av Chalmersgemensam Persondatabas Ända sedan projektet började har en Chalmersgemensam Persondatabas (PDB) saknats. Eftersom KA-systemet innehåller många personuppgifter, är projektet mycket beroende av en sådan databas. Avsaknaden innebär att Teknikgruppen får skapa motsvarande funktionalitet inom projektets ramar, dvs. bygga en temporär lösning som inte uppnår samma funktionalitet och kvalitet jämfört med en riktig persondatabas. HÖG Konsekvenser/Effekter HÖG: Projektet får ett onödigt merjobb med att skapa en temporär lösning, vilket leder till en förlängning och fördyring av projektet. Projektet får en ökad administrativ arbetsbelastning, med bland annat manuell uppdatering och temporära rutiner för detta. Den temporära lösningen är inte komplett med all information och uppgifter om alla användargrupper i KA-systemet. Förvaltningsorganisationen får ett merjobb att byta ut den temporära mot den permanenta Persondatabasen HÖG, Konsekvens HÖG ger Prio 1 Risken har redan drabbat projektet. Ett stort jobb är nedlagt/kommer att läggas ner på en temporär lösning i väntan på PDB. Projektet har informerat och flaggat för risken i mycket tidigt skede för styrgrupp och beställare. Projektet har temporärt skapat en egen databas med alla de uppgifter som KA-systemet behöver, för att få önskad funktionalitet och kunna leverera systemet Projektet jobbar aktivt med den manuella uppdateringen av den temporära lösningen Dokumentation över var och hur den temporära lösningen används (t ex. i Ändringslogg KA ), så att förvaltningsorganisationen vet vad som skall uppgraderas, när PDB införs. Förvaltningsorganisationen får ha nära kontakt och samarbete med PDB-projektet Avlasta, med rätt arbetsfördelning, de resurser som jobbar med att hantera den egna databasen. På lång sikt: Styrgruppen bör verka för att ta fram en Chalmersgemensam Persondatabas, som gynnar alla projekt och system som behöver dessa uppgifter. Styrgruppen bör säkerställa att pågående PDB-projekt fortsätter och att målet uppnås. KA Förvaltningsorganisation bör få hjälp att samverka med pågående PDB-projekt och kommande PDB-system.
Sidan: 13(23) 5 AFFÄRS- & PRODUKTRISKER A1 Kvalitet på kravställning Risken finns att kraven på systemet är för abstrakta (generella), uttrycker inte tillräckligt tydligt vad som skall byggas. Dessutom har inte alla grupper varit representerade i kravställningsarbetet, vilket kan leda till ett system anpassat för endast vissa sektioner eller roller inom Chalmers. MEDEL Konsekvenser/Effekt HÖG: Produkten accepteras inte ute i hela verksamheten alternativt att produkten inte svarar upp mot majoritetens förväntningar. MEDEL, Konsekvens HÖG ger Prio 3 Prototypvisning och testomgångar kommer att ge projektet indikationer tidigt gällande felaktig implementation av kraven. Projektet har färdigställt en Kravspecifikation från de förutsättningar som fanns. Fortsatt arbete för att förebygga denna risk är att arbeta med Kravplan och Testplan som innehåller detaljerade testfall per modul (se kapitel 7 Referenser). Fokusera spårbarhet, spåra varje testfall mot uppsatt krav Intervjua testgrupperna, lyssna och omhänderta deras åsikter och synpunkter. Rätt sammansättning av testgrupperna. Alla ej åtgärdade krav och önskemål dokumenteras i Ändringslogg KA (se kapitel 7 Referenser). Genom att ta med fler studenter, utöver kravställningsgruppens medlemmar, under prototypvisning och i test kommer vi bättre få med studentens behov. Satsa tid och resurser på testfasen. Informera ute i verksamheten parallellt med utvecklingen. På lång sikt: Styrgruppen bör verka för att förankra och informera verksamheten om produkten.
Sidan: 14(23) A2 Ej godkänd enligt PUL och andra lagar Personuppgiftslagen och Lagen om ansvar för elektroniska anslagstavlor är styrande för KA-systemet. Risk uppstår om inte projektet följer de regler och förordningar som finns vid framtagning systemet. HÖG Konsekvenser/Effekter HÖG: Systemet kan bli olagligt, vilket leder till anmälan mot Rektor. HÖG, Konsekvens HÖG ger Prio 1 Chalmers PUL-ombud kommer att göra en bedömning av systemet. En granskning kommer enligt PUL att utföras av Chalmers PUL-ombud. I det fallet inte all funktionalitet godkänns enligt PUL kommer samtycke att krävas av användaren. Ett förfarande för samtycke bör planeras i god tid. Skulle systemet bryta mot vedertagen arbetsordning kommer systemet att anpassas vid uppgradering till kommande version.
Sidan: 15(23) A3 Avsaknad av Processbeskrivning SA En total processbeskrivning saknas över verksamhetsområde SA. KA-systemet är uppbyggt utifrån projektets egna processutveckling/processkartläggning kombinerat med ett generiskt arbetssätt inom kursadministration. Dock ligger de två processbeskrivningar, vilka blev kartlagda under sommaren 2001, till grund för två av modulerna inom KA-systemet. Systemet ska stödja på Chalmers vedertaget arbetssätt inom kursadministration, vilket systemet riskerar att inte göra. HÖG Konsekvenser/Effekt MEDEL: Användarna känner inte igen sitt arbetssätt i systemet, utan upplever systemet som felaktigt och använder inte systemet. Oro för de förändringar i arbetssätt som KA-systemet kan medföra HÖG, Konsekvens MEDEL ger Prio 2 Projektet har redan blivit drabbat av denna risk. Kan senare visa sig i form av att systemet inte följer KAprocesserna tillfredställande. Projektet bygger KA-systemet version 1.0 utifrån de förutsättningar som finns framtagna. Projektets informationsspridning samt styrgruppens förankring av resultatet skall medföra att användarna blir familjära med systemet och dess arbetssätt, trots att lösningen baserar sig på ett generiskt arbetssätt. På lång sikt: Processägarna bör verka för att snarast ta fram processbeskrivningar för varje process inom SA samt processambandskartor över SA. Dessa kommande processkartläggningar bör vara underlag till vidareutveckling av systemet.
Sidan: 16(23) A4 Avsaknad av Förvaltningsorganisation SA KA-systemet ingår i verksamhetsområde SA (StudieAdministration). Förvaltningsorganisation inom SA saknas. Vid framtagning av ett omfattande IT-stöd som berör en bred verksamhet och många sektioner, är det viktigt att det finns en utpekad förvaltningsorganisation med roller, ansvar, befogenheter och arbetsuppgifter, som kan ta emot det nya IT-stödet. KA-systemet och andra system/lösningar inom SA behöver koordineras, planeras och förvaltas på ett etablerat sätt inom SA. Projektet känner inte att detta är någon projektrisk, eftersom det redan finns en utpekad beställare/systemägare att lämna över systemet till. Det räcker egentligen från projektets håll. Däremot känner projektet att det är en affärs- och produktrisk, eftersom tillsättande av roller (temporärt eller permanent) inte räcker för att få en stabil förvaltningsorganisation. Det behövs dessutom ett etablerat arbetssätt, ansvarsfördelning, utredning av flöden och rutiner osv. Detta ligger inte inom projektets ramar, utan är verksamhetens ansvar. HÖG Konsekvenser/Effekt HÖG: Projektet får: merarbete med att ta fram förslag på temporär förvaltningsorganisation svårigheter vid införandet till temporär förvaltningsorganisation, där arbetssätt och rutiner saknas lösa ett antal problem som egentligen ligger utanför projektets ansvar, ex: o Oklar vinstrealistering, vilket kan leda till låg förståelse för nyttan av systemet. o Konkurrens från andra satsningar på Chalmers, vilket ger lågt användande av systemet. Verksamheten får: en otydlig förvaltningsorganisation, vilket kan leda till oklarhet hos användarna: vem sköter vad, när, hur och varför? o utreda ansvarsgränsen, arbetssätt och rutiner mellan tekniskt stöd & support samt verksamhetsstöd & support svårigheter att koordinera och planera förvaltningsaktiviteter med andra system inom SA HÖG, Konsekvens HÖG ger Prio 1 Projektet har redan blivit drabbat av denna risk. Projektet har haft svårigheter att veta vem som skall kontaktas när och hur. Projektet har tagit fram ett Informationsmaterial, där förslag på förvaltningsorganisation finns. Styrgruppen ansvarar för att tillsätta en temporär förvaltningsorganisation för KA-systemet och tillsätta rollerna samt ge förutsättningar att rätt arbetsuppgifter sköts inom respektive roll. På lång sikt: Styrgruppens och systemägarens ansvar blir att verka för att Förvaltningsorganisation SA skapas, där KAsystemet ingår.
Sidan: 17(23) A5 Svårigheter med terminologiförvirring Verksamheten och projektet har olika definitioner på ett antal begrepp etc., vilket förvirrar och försvårar samförstånd och förståelse. LÅG Konsekvenser/Effekter LÅG LÅG, Konsekvens LÅG ger Prio 6 Slutrapporten på Processkartläggningarna inom SA var första indikationen på att denna risk drabbat projektet. Projektet har tagit fram ett dokument där alla definitioner, begrepp och ord som kan misstolkas eller ha olika betydelser skall finnas med. Dokumentet heter KA1.0_Terminologi_P1.0 (se kapitel 7 Referenser). Ansvaret och underhåll av dokumentet kommer fr.o.m 01-10-01 att ligga hos Referensgruppen. Terminologi-dokumentet bör vara åtkomligt från Portalen i KA-systemet, så att det är lättillgängligt för alla.
Sidan: 18(23) A6 Svårunderhållen kod, förvaltningsovänligt system Systemdokumentationen inte tillräcklig Systemet är svårt att förvalta och underhålla. Koden är svår att tyda och läsa, är ej utvecklad på ett enhetligt sätt. Systemdokumentationen är inte tillräckligt bra och komplett för att förvaltningen skall fungera. MEDEL Konsekvenser/Effekter MEDEL MEDEL, Konsekvens MEDEL ger Prio 4 Risken har delvis redan inträffat, eftersom teknikgruppen redan i tidigt skede har fått programmera om vissa delar för att få enhetlighet. Teknikgruppen försöker förebygga detta genom att: använda och följa en gemensamt framtagen utvecklingshandbok, med standards och riktlinjer (se kap 7 Referenser). använda så många gemensamma komponenter som möjligt granska varandras kod, ge synpunkter och kommentarer ta fram systemdokumentationen successivt, så att innehållet växer fram parallellt med utvecklingen (systemdokumentationen är tänkt att utgå från Lösningsspecifikationen, se kap 7 Referenser ). Om systemet blir förvaltningsovänligt med svårunderhållen kod, så måste detta tas upp i Ändringslogg KA omgående, så att koden uppdateras och justeras i nästa version av KA-systemet samt att dokumentationen ses över i det sammanhanget.
Sidan: 19(23) 6 TEKNISKA RISKER T1 Vald tekniklösning håller ej Teknikgruppen kan inte bygga produkten med vald teknik, dvs. Zope. LÅG Konsekvenser/Effekt HÖG: Projektet får problem med utveckling, lagring, gränssnitt, kopplingar, säkerhet eller integrering. Lösningen blir inte det förväntade. LÅG, Konsekvens HÖG ger Prio 5 Inga hittills. Lasttester behöver utföras för att kontrollera prestanda. Teknikgruppsledaren måste genast avisera om vald teknik eller systemdesign inte är den rätta. Lyft till styrgrupp och ta fram akut handlingsplan.
Sidan: 20(23) T2 Avsaknad av utvecklingserfarenhet i Zope Zope-miljön är en (relativt) ny systemutvecklingsmiljö för alla inblandande i projektet. Detta innebär att projektet saknar erfarenhet och kompetens runt kod, komponenter och lösningar i denna miljö. MEDEL Konsekvenser/Effekt MEDEL På grund av avsaknad av systemutvecklingserfarenheter i vald utvecklingsmiljö (Zope-miljö) kan det resultera i att de effektivaste lösningarna inte skapats i denna första version. MEDEL, Konsekvens MEDEL ger Prio4 Dubbelarbete, dvs. utvecklarna ändrar redan fungerande kod för att få enhetlighet. Erfarenhetsutbyte och kompetensnätverk såväl internt som externt. 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: 21(23) T3 Lasthantering Projektet har i detta skede inte en klar bild av lastsituationen, dvs. hur många samtida användare av KAsystemet. Risken är därför att systemet inte hanterar och klarar tillräckligt många samtida användare på ett bra sätt. Med ett bra sätt menas att websidan inte hänger sig och framför allt att systemet inte går ner. HÖG: På grund av oklart behov av lasthantering samt systemets (inkluderat hårdvara, nätverk etc.) förmåga att hantera last. Konsekvenser/Effekter MEDEL: Om systemet inte uppfyller behovet av antalet samtida användare leder det till problem, exempelvis blir registrering inte möjlig. Detta skapar irritation och i sämsta fall tvingar fram manuell registrering. I förlängningen kan det innebära att användarna flyr systemet. HÖG, Konsekvens MEDEL ger Prio 2 Systemet blir långsammare redan under funktionell test när många testar samtidigt. Lasttest ger tendenser om läget. Göra lasttest tidigt för att förstå om konstruktion eller serverkonfiguration måste ändras. Höja fokus på lasttest, eftersom lasttest i detta skede har lägre prioritet än funktionell- och gränssnittstest. Lasttest i sig är mer komplex än exempelvis funktionell test och det är svårare att efterlikna verklig lastsituation. Teknikgruppen har rutin sedan tidigare liknande system och bör ha en känsla om lastsituationen. Detta gör att systemet klarar last bra och lämplig serverhårdvara kan rekommenderas. Använda verktyg för lastfördelning för att fördela belastningen. Utöka server-hårdvara i systemet.
Sidan: 22(23) T4 Ej realistiska tester Att de olika tester som skall utföras (funktionstest, systemtest, lasttest) inte fångar verkligt användande och inte speglar hur systemet används/kommer att användas i verkligheten. MEDEL Konsekvenser/Effekter LÅG: Att testfallen inte hittar de kritiska momenten och de verkligt svåridentifierade användningsfallen. MEDEL, Konsekvens LÅG ger Prio 6 Test enligt testfall går bra, men fri testning, av exempelvis studenter, visar på systemfel. Skapa så verklighetsrelaterade detaljerade testfall som möjligt tillsammans med testgrupperna/modul och att det finns spårbarhet till kraven, se dokumenten KA1.0_Testfall_Modulnamn (se kapitel 7 Referenser). Om fel inte upptäcks under testomgångarna, utan först senare, måste dessa tas upp i Ändringslogg KA, för att behandlas i nästa version av KA-systemet.
Sidan: 23(23) 7 REFERENSER Här redovisar Du vilka dokument som detta dokumentet refererar till. Ref. Dokumentnamn och dokumentbeteckning Utgåvenr Dokumentdatum Riskanalys 00-10-31 KA1.0_Projektdefinition 1.0 01-08-28 KA1.0_Kravspecifikation 1.0 01-09-14 KA1.0_Ändringslogg P1.0 KA1.0_Terminologi P1.0 KA1.0_Kravplan P1.0 KA1.0_Testplan P1.0 KA1.0_Testfall_modulnamn P1.0 KA1.0_Lösningsspecifikation P1.0 Utvecklingshandbok för Teknikgruppen