Konstruktion av IT-lösningar

1. Konstruktion av IT-lösningar OH-serie i kursen Datasystem och systemarbete Kenneth Norrgård Baserat på boken: Praktisk konstruktion av IT-lösningar, Gunnarsson, Samuelsson, Svensson – Studentlitteratur 1999

2. Kund Faktura Order Verksamhet Informationsstruktur Produkt Funktionsmodell Klassmodell Dialogmodell Användar- interaktion Inledning Kravområden

3. Inledning Funktionsmodell • Funktionella krav som verksamheten ställer på det planerade systemet • Definieras i kravspecifikationen Behov

4. Inledning Dialogmodell • Beskriver användarens krav på interaktion på det system som konstrueras • Två typer • Användargränssnitt • Gränssnitt till andra system

5. Kund Faktura Order Produkt Inledning Klassmodell • Informationens struktur i form av klasser och deras strukturer • Modellen utgör underlag för designen (läs: programmering och införande) • Klassmodellen kan vara: • ER-schema (Entity Relationship)  Relationsdatabas • Klassdiagram  Objektorienterad databas

6. 1.1 Strategi… Strategi och projektmål • Utvecklingsstrategi? • Metodik? • Teknisk ambitionsnivå? • Överenskommelse (avtal) mellan beställare (kund) och leverantör (IT-specialist)  Kom överens om Tid – Kostnad - Omfattning • Projektplan – hur beaktas bl.a. följande aspekter? • Kvalitetssäkring? – ändring-/felhantering? – versionshantering programtestning – dokumentation? – konvertering av data? – behörighetssystem? – utbildning? – support/förvaltning? Många faktoreratt beakta

7. 1.1 Strategi… Vattenfallsmodellen Förstudie/Kravspec. Funktionskrav/Planering Konstruktion/Programmering Implemetering/Installering Drift/Underhåll System ABCDE

8. FunktionskravPlanering FunktionskravPlanering Konstruktion/Programmering Konstruktion/Programmering Delsystem B Delsystem C OK Nästa i tur Implemetering/Installering Implemetering/Installering System A Drift/Underhåll Drift/Underhåll Delsystem D Delsystem E 1.1 Strategi… Etappvis utveckling

9. Delsystem B Delsystem C Delsystem B Delsystem C Delsystem E Delsystem D System A System A System A Delsystem D Delsystem E Delsystem B Delsystem C Delsystem E Delsystem D 1.1 Strategi… Evolutionär utveckling

10. Komponent A Komponent B Komponent C Komponent D 1.1 Strategi… Köp av färdiga system/komponenter • Färdiga programpaket och/eller programkomponenter • Verksamheten kan anpassas till programvaran eller tvärtom • Ofta snabb leverans till fast pris • Standardlösningar • Kravspecifikation bör i alla fall göras • Innan anskaffning görs är det viktigt att utvärdera om en komponent eller program uppfyller speciferade krav System ABCD

11. Kasta inte tärning… 1.1 Strategi… Riskanalys • Ger överblick och underlag att diskutera utvecklingsstrategin • Faktorer som påverkar val av strategi • oklara krav • att kunden vill ha hela produkten på en gång och ersätta en gammal produkt • att vissa programfunktioner behövs tidigt • begränsade resurser (tid?, pengar?, personal?, utrustning?) • komplexa och omfattande programprodukter • att programprodukten behövs snabbt

12. …spela med säkra kort 1.1 Strategi… Riskanalys (forts) • Faktorer som påverkar val av strategi • att färdig ”paketlösning” skall anskaffas och minimal egen utveckling får ske • utveckling skall ske med prototyping • ny teknik • höga säkerhetskrav • höga prestandakrav • även andra kvalitetskrav som portabilitet, återanvändbarhet, användarvänlighet, testbarhet…m.m.

13. Kund Faktura Order Produkt Förbättringsförslag Förstudie Projektstart Verksamhetenskravspecifikation Program-specifikation Projekt- avslut 1.2 Verksamhetsmodeller… Direct-modellen Verksamhetens procresser och ansvar Gränssnitt och programkomponenter Begrepp och informationsstruktur Tillverka och för in i verksamheten Detaljera programkrav Modellera och beskriv verksamhetens krav

14. Kund Faktura Order Produkt 1.2 Verksamhetsmodeller… Direct-modellen Verksamhetens procresser och ansvar Gränssnitt och programkomponenter Begrepp och informationsstruktur Tillverka och för in i verksamheten Detaljera produktkrav Modellera och beskriv verksamhetens krav

15. 1.2 Verksamhetsmodeller… Modeller och krav • Verksamhetens processer och ansvar • Processmodell • Rutinmodell • Användningsfall • Ärendemodell

16. 1.2 Verksamhetsmodeller… Modeller och krav • Gränssnitt och programkomponeneter • Aktörs-/rollmodell • Dialogmodell med användarfönster (i boken bildspel)

17. Kund Faktura Order Produkt 1.2 Verksamhetsmodeller… Modeller och krav • Begrepp och informationsstruktur • Begreppsmodell • Förekomstexempel • Händelsemodell

18. 1.3 Ambitionsnivå Vad innebär hög ambitionsnivå? • Exempel på faktorer som kan innebära hög ambitionsnivå: • Grafisk direktmanipulation • Extremt hög säkerhet (kryptering…) • Distribuerade lösningar • Drag and Drop-teknik… • Sofistikerade Help-funktioner • Webbkopplingar…?

19. 1.3 Ambitionsnivå Ambitionsnivån påverkar kostnaderna • Ju högre ambitionsnivå desto högre kostnader • Bör man tumma på kraven?  Det beror på typ av system • ”Får inte bli fel”-system • kärnkraftverk, banksystem, aktiesystem… • ”Fel tillåtna undantagsvis”–system • fel leder inte till katastrof, men allafel bör rättas till • ”Skall fungera”-system • normalt vid utveckling av administrativasom normalt inte är kritiska • ”Bör fungera”-system • ”Quick and dirty”

20. Åtagande triangeln Q = Kvalitet T = Tid C = Kostnad 1.3 Ambitionsnivå QTC (Quality, Time and Cost) • Dessa faktorer bör bestämmas och ”viktas” i ett tidigt skede av programutvecklingsprojektet • Q står för kvalitet och är kopplad till ambitionsnivån och olika kvalitetsfaktorer • T står för tid och anger hur viktigt det är att systemet blir klart på utsatt tid • C står för kostnad och anger hur viktigt det är att projektet är kostnadseffektivt

21. … 1.3 Ambitionsnivå QTC – viktning Viktning för projektmål: ”utveckla ett system där vi är kostnadseffektiva” Quality=0,1 Time=0,2 Cost=0,7 • Överväganden för projektledaren (PL) • vissa funktionella krav kommer antagligen att behöva prioriteras bort eftersom de inte ryms i kostnads-ramarna • svårt att få en nöjd systemanvändare även om den som betalar är nöjd

22. … 1.3 Ambitionsnivå QTC – viktning (forts) Viktning för projektmål: ”utveckla ett system där vi håller leveranstiden” Quality=0,1 Time=0,7 Cost=0,2 • Överväganden för PL • alla förändringar mot ursprunglig kravspecifikation är riskfaktorer • viktigt att klassa funktionalitetskraven så att vissa viktiga krav bör få ta längre tid inom projektet utan att äventyra projekttidsplanen mindre viktiga funktioner borde kunna göras snabbt (annars utelämnas de?)

23. … 1.3 Ambitionsnivå QTC – viktning (forts) Viktning för projektmål: ”utveckla ett system med hög kvalitet” (”hög kvalitet” bör förstås specificeras) Quality=0,8 Time=0,1 Cost=0,1 • Överväganden för PL • PL bör fråga sig vem som ställer kvalitetskraven och för vem skall de vara tillräckliga  resultatet skall vara prisvärt • testningen av programmen är en viktig aktivitet • förändringar efter utförd test inte bra  risk för nya fel för stor?

24. 1.3 Ambitionsnivå Vems ambitionsnivå? Vems QTC? • Bör överenskommas i ett tidigt skede av projektet • Alla bör vara ense – uppdragsgivaren är i nyckelställning (den som betalar för projektet • Ambitionsnivån och QTC-faktorn inverkar i hög grad på styrningen av projektet i och inte minst på kostnaden

25. 1.5 Kvalitetssäkring Kvalitetssäkring • Spårbarhet = möjligheten att kunna spåra det man gör och kontrollera att det bygger på föregående steg (Jmfr med ett bokföringssystem) • Svårt att behålla spårbarheten i ett programutvecklingsprojekt

26. Läs boken kap 1.5 1.5 Kvalitetssäkring Kvalitetspåverkande faktorer • Typ av system • Beställarorganisation • Leverantörsorganisation • Projektorganisation • Kvalitet hos källmaterial • Kvalitetssäkringsarbete (V-modellen) • Kvalitetssäkringsplan • Versionshantering • Ändringsstyrning • Granskning

27. VD LG PL PS Pr PL Pe Ek Ma PM PL PM PM Xx Xx 1.6 Säkra kompetens… Kompetens och personalresurser • Läs boken kapitel 1.6 Vilka kompetenserbehövs till projektet?