Kvalitetssäkrad leverans i Maximoprojekt Maximo användarförening Göteborg 2008-04-03 Kl 10.30 – 12.00 Philip Nederfeldt philip.nederfeldt@sigma.se

Agenda Projektöversikt Test och verifiering Diskussion Frågan om hur man kan kvalitetssäkra IT-projekt, såsom förändringar av Maximo i förvaltnings- och uppgraderingsprojekt ställs allt oftare. I denna workshop kommer vi att diskutera metoder och arbetssätt i syfte att säkerställa kvaliteten i en Maximo-leverans. Detta görs genom att titta på olika faser i ett uppgraderingsprojekt, från specifikation och förstudie till test och implementering. Som en utgångspunkt kommer vi använda det pågående uppgraderingsprojektet på ITT Flygt. Projektöversikt Test och verifiering Diskussion

Statistik Brist på medverkan från slutanvändare 12,8% 16 % av alla IT-projekt klassas som lyckade 53 % anses misslyckade 31 % läggs ned innan de slutförts 53 % kostar 189 % av uppskattningen vid start 17 % levererar på utsatt tid Brist på medverkan från slutanvändare 12,8% Ofullständiga krav och specifikationer 12,3% Förändringar i krav och specifikationer 11,8%

Projektmodell Förstudie Krav- hantering Utveckling System-tester Acceptans-tester

Förstudie Förstudien tar fram VAD som skall utföras/förändras. Affärsnytta Processkartläggning Nulägesbeskrivning och GAP-analyser Projektets omfattning och avgränsningar sätts Uppgradering av databasen och uppsättning av en labbmiljö Enkla pilottester tas fram, ”prototyping”

Kravhantering I kravhanteringen bestäms hur/på vilket sätt ändringarna skall genomföras Skärmbildsändringar, rapporter, integrationer hanteras olika Kravdokumenten måste vara förståeliga för alla inblandade parter. En bild säger mer än… Allt dokumenteras. Granskning sker av referenspersoner.

Utveckling Utveckling sker enligt skrivna specifikationer (Kravdokumenten). Kommunikationsväga upprättas mellan utvecklare och användare (Kravställare). Kommunikationsvägar upprättas mellan utvecklare och testare (systemtester) Regelbundna avstämningar med alla utvecklare – beroenden mellan olika utvecklingsdelar identifieras tidigt!

Tester, tidig inblandning Användandet av ett testledningssystem Vad skall testas i projektet och vad är status på det som testats? PL, utvecklare, beställare, testledare Kraven registreras, säkerställ mätbara krav, Testfall/testscenarios skapas Allt som skall fungera skall testas! I praktiken sker ett kvalificerat urval. Avrapportering av tester  input till utvecklare

Systemtester Test av delar eller hela system Förändringar i kravbilden leder till rekursiva tester Explorativa tester eller efter testfall kan förekomma Referenspersoner (Kravställare) deltar från kunden Viktigt att få en tidig återkoppling på det som utvecklats Delar av systemet testas innan det är helt klart – dock är det viktigt att testa i rätt ordning! Iterativ process. Alla systemtester måste vara avklarade innan acceptanstest . Start- stopp och avbrottskriterier

Acceptanstest Slutanvändare testar och godkänner inför leverans Ingen inblandning av projektdeltagare – varken utvecklare eller referenspersoner. Färdiga testfall används. Acceptanstesmiljö skall motsvara den kommande produktionsmiljön Svarstider, integrationer, loggar, parametrar, utskrifter, rättigheter osv

Dokumentation Förstudierapport Kravdokument Systemdokumentation Objektsbeskrivningar, funktionell dokumentation Testrapporter – efter varje testomgång Testscenarios – tas fram tillsammans

Beroenden kring test

Till sist… Kvaliteten på ett system mäts genom test Tester syftar till att hitta fel och skapa tilltro till systemet Byggs systemet rätt? Byggs rätt system? Alternativkostnaden för att testa är kostnaden för att inte testa Felrapportering, helpdesk, omtestning information, badwill mm

Sammanfattning Kommunikation och avstämning, vad skall utföras? Håll strikt på det lagda scoopet. Försök inte få in allt på en gång. Tydliggör målen med specifikationer Tidigt testfokus Uppgradera under förstudien Blanda tidigt in referensgrupper (ge tid för dem också) Ledningens engagemang Inga ”Turn key” lösningar

Diskussion