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

Informations struktur Kravområden Inledning Dialogmodell Klassmodell Funktionsmodell Verksamhet Informations struktur Kund Order Produkt Faktura Användar- interaktion

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

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

Klassmodell Inledning 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 Kund Order Produkt Faktura

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 faktorer att beakta

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

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

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

Köp av färdiga system/komponenter 1.1 Strategi… 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 Komponent A Komponent B Komponent C Komponent D System ABCD

Riskanalys 1.1 Strategi… Kasta inte tärning… 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

Riskanalys (forts) 1.1 Strategi… Faktorer som påverkar val av strategi …spela med säkra kort 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.

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

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

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

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

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

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…?

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 alla fel bör rättas till ”Skall fungera”-system normalt vid utveckling av administrativa som normalt inte är kritiska ”Bör fungera”-system ”Quick and dirty”

QTC (Quality, Time and Cost) 1.3 Ambitionsnivå 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 Åtagande triangeln C = Kostnad T = Tid Q = Kvalitet

QTC – viktning … 1.3 Ambitionsnivå 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

QTC – viktning (forts) … 1.3 Ambitionsnivå 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?)

QTC – viktning (forts) … 1.3 Ambitionsnivå 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?

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

Kvalitetssäkring 1.5 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

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

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