Affärsprocess
En affärsprocess är ett förlopp (eller skeende) som består av en, eller flera, sammanhängande aktiviteter (operationer) som behövs för att leverera en produkt eller tjänst med ett kundupplevt värde.

Ansvarstriangeln
Ansvarstriangeln tas upp i kapitlet om processers styrning och kontroll. En verksamhets, avdelnings eller medarbetares arbetsområde kan beskrivas med hjälp av en ansvarstriangel. För att en verksamhet ska kunna fungera bör det finnas en harmoni inom varje triangel och mellan en verksamhets olika trianglar.

- Ansvar måste vara kopplat till mätbart mål (annars otydligt ansvar & svårt uppfylla de uppsatta målen)

- Ansvar måste vara kopplat till befogenheten/möjligheten att påverka. (Ex: mål: nyanställa. I så fall måste den som har ansvar också ha befogenhet att besluta om nyanställning)

- Den ansvarige måste få tillgång till nödvändig info/kunskap för att kunna uppfylla sitt ansvar (inom det egna området och i gränssnitten mot andra)

- Bristande harmoni mellan trianglarnas olika spetsar, exempelvis överlappande ansvar, innebär att man byggt in potentiella konfliktsituationer i organisationen.

Attribut
Kallas den information man vill hålla reda på om ett objekt.

Attributens värdemängd
Mängden av alla tillåtna värden, tex. Namn: (Jonas, Niclas, Magnus, Henrik, Roberto) eller Ålder: (20 - 60).

Batch-rutin
Systemet är programmerat att vid vissa tidpunkter eller på begäran utföra en mängd rutiner i en viss ordning. Exempel: månadsbearbetning på ett företag, där allt ska ske in en viss ordning för att redovisning och försäljningsstatistiken ska bli korrekt och att även alla listor skrivs ut i den ordning som krävs.

Villkorsrang
Antalet möjliga allternativ för villkoret, dvs J eller N ger villkorsrang 2.

Situationsrang
= Regelrang. Antalet möjliga kombinationer av situationer i en spalt.

Regelrang
= Antalet möjliga kombinationer av situationer i en spalt. En regel är en spalt i tabellen bestående av villkor och åtgärder.

Elementär regel
= J eller N

Komplex regel
= - , dvs regeln kan vara både J eller N i en situation.

Tabellrang
= å RR (regelrang) = Villkorsrang^villkor
Kontrollera att tabellen är korrekt och visa att alla elementära regler är intäckta endast en gång.

Metod: J = 1, N = 0. - = 1 eller 0. Prova alla kombinationer spalt för spalt (situation för situation).

S 1. (möjliga situationer som ska ge samma åtgärd om tabellen är korrekt, strecken betyder ju J eller N och innebär att oavsett om vi svarar J eller N på detta villkor ska åtgärden bli densamma):

16x1 (viktxJ) + 8x1(viktxJ) + 4x1(viktxJ) + 2x1 (viktxJ) + 1x1(viktxJ) = S32
16x1 (viktxJ) + 8x1(viktxJ) + 4x1(viktxJ) + 2x1 (viktxJ) + 1x0(viktxN) = S31
16x1 (viktxJ) + 8x1(viktxJ) + 4x1(viktxJ) + 2x0 (viktxN) + 1x1(viktxJ) = S30
16x1 (viktxJ) + 8x1(viktxJ) + 4x1(viktxJ) + 2x0 (viktxN) + 1x0(viktxN) = S29

Fortsätt på samma sätt. Om någon situation saknas eller är dubbel har man gjort fel när villkor, situation och åtgärd ställts upp. Gå då igenom hela tabellen igen kontrollera villkor för villkor mot situation och åtgärd för att hitta felet.

Binär relation
En semantisk relation mellan två objekt. Relationen har två riktningar (primär riktning och invers riktning). För tydlighetens skull bör man namnge riktningarnas namn, tex. Person "äger" Bil, Bil "ägs av" Person.

BPR
Business Process Reengineering. Innebär att man i ett slag gör en stor strukturell förändring, toppstyrd förändring. Risken för misslyckande är betydligt större än vid TQM.

CASE
Computer Aided Software Engineering. På svenska skulle man säga datorstödd systemering.

Ett DFD-diagram görs först på en så kallad kontext-nivå, dvs en helt övergripande verksamhetsbeskrivning, för att sedan brytas ner på mer detaljerad nivå.

Även externa källor och mottagare som är väsentliga för beskrivningen anges med informationsflöden till verksamhetens processer. Exempel på externa källor/mottagare kan vara kunder, leverantörer mm. Dessa skall inte beskrivas.

På nivån under kontext-nivå (0-nivå) definieras verksamhetens olika processer och flöden. Därefter gör man en avgränsning av den del av verksamheten som man önskar beskriva i detalj, man gör en så kallad fördjupning av en av processerna. På fördjupningsnivå beskrivs en process i detalj.

En process kan beskrivas med hjälp av verb och substantiv, tex kontrollera faktura.

Flöden och datalager beskrivs med substantiv, tex. faktura, kontrollerad faktura.

Dynamiska attribut
Attribut som förändras, mindre lämpligt att använda, ex. ålder (25 år)

Entitetstyp
Informationsobjekt, objektstyp. En företeelse i vår verksamhet som vi önskar hålla information om, tex. artikel, lärare, patient. Entitetstypen karakteriseras och definieras genom sina attribut. Observera skillnaden mellan typnivå (entitetstyp) och förekomstnivå (entitet).

Epistemologi
Våra möjligheter att veta något om verkligheten.

ESU
Experimentell Systemutveckling, Prototyping. Om användarna får möjlighet att testa ett system så har de större möjligthet att uttala sig om vad de vill och därmed så får man också en bättre kravspecifikation. En prototyp kan av användarna uppfattas som färdig eftersom den ser ut att fungera med de finns inget bakom skalet och dädrför tar det längre tid att bli färdig än de tror.
+: anv kan prova systemet, bättre kravspec, feedback.
-: uppfattas som "färdig" produkt.

Evolutionär systemutveckling
Motsatsen: revolutionär, typ vattenfall, allt levereras på en gång, sk Big Bang.

En strategi för systemutveckling, hur leverans av system bör gå till. Man kan välja mellan att få snabba delresultat eller att vänta på ett större och mer omfattande resultat.

Vanligast är att leverera hela det nya systemet på en gång och samtidigt lägga ner det gamla. Förespråkarna för evolutionär systemutveckling menar att den långa tiden mellan start och leverans sänker användarnas motivation och att användarnas krav ändras med tiden och att dessa krav inte tas med i utvecklingen av systemet.

Leverera systemet steg för steg i mindre omgångar. Den del som bedöms mest lönsam införs först.

Kortare väntetid på första leverans, nöjda, motiverade användare.

Problem: Svårt att hitta en uppdelning i mindre bitar som göra att informationssystemet kan utvecklas rationellt i flera små delar. Kritik: Slöseri med utvecklingsresurser, mindre effektiva lösningar:

Till skillnad mot traditionell systemutveckling då hela systemet levereras samtidigt och helt klart (sk. revolutionär systemutveckling), levereras det nya systemet vid evolutionär systemutveckling gradvis.

Den evolutionära systemutvecklingen innebär ett helt annat sätt att angripa utvecklingsuppgiften, den första delleveransen kommer mycket snabbt och ett nytt informationssystem består av mellan 20-100 olika implementeringar.

Evolutionär systemutveckling är först och främst att i snabb ordningsföljd leverera en rad mindre delar som användarna verkligen värdesätter. Därmed skapar man intresse och motivation bland användarna. Det är detta engagemang och resultatet av detta, som är det huvudsakliga syftet. Om man vill uppnå detta engagemang får det naturligtvis inte finnas en detaljerad plan för alla leveranserna. Evolutionär systemutveckling utgår från att man bestämmer varje leverans efter hand.

Sättet att välja nästa delleverans är också viktig. Här koncentrerar man sig på om något kan göras snabbt och i liten skala och samtidigt vara till nytta för användaren. Beslut om nästa delleverans fattas utifrån en nyttovärdering. Varje delleverans består av en systemeringsuppgift (analys och utformning), en realisering och en implementering.

All systemutveckling är målinriktad, men den evolutionära är särskilt starkt målinriktad. Vid valet mellan möjliga delleveranser spelar de olika alternativens nytta en central roll.

En annan grundläggande tanke är att man måste ha en öppen arkitektur. Det vill säga en teknisk lösning som utan problem accepterar förändringar och utvidgningar. Det måste vara lätt att lägga till nya funktioner och ändra existerande.

Extranet
Motsvarighet till Intranet men med skillnaden att det kan nås utifrån av exempelvis behöriga kunder som ska kunna lägga in ordrar, och själva komplettera med uppgifter till en kreditanalys.

Främmande nyckel
En unik identifierare för ett (kärn)objekt (primärnyckel) som ingår som attribut i ett annat (relations)objekt kallas främmande nyckel.

Fundamentalprincipen
Den fundamentala principen för systemarbete - Utgångspunkten för principen är att det system man är intresserad av är omöjligt att överblicka, dvs. att systemet består av så många delar och innehåller så komplicerade relationer mellan delarna att man inte genast kan få en fullständig bild av systemet. Fundamentalprinscipen säger att man måste dela upp totalsystemet i delsystem, vilka i sin tur kanske delas upp i ytterligare delsystem. Uppdelningen fortsätter tills det att vi har överskådliga (del)system.

Under nedbrytningen gör man hela tiden bedömningar, och systembeskrivningen tillförs ny information så att den efterhand blir överskådlig. Principens styrka är att den ständiga tillförseln av information sker efter ett bestämt mönster som visar sig lämpligt för oss människor, och som leder till det resultat som man eftersträvar; ett överblickbart system.

Funktionell syn
Man ser bara till produktens funktion utan att bry sig/eller kunna förstå hur den fungerar.

Funktionsanalys
Uttrycker vad det blivande systemet skall göra (funktioner) men inte hur. Funktionsanalys innebär att genom att bryta ned en organisations olika funktioner i delfunktioner, erhåller man delfunktioner av en storlek där man kan avgöra om hela funktionen skall datoriseras eller ej. Man bryter även ned funktionen till en sådan nivå, att man har möjlighet att identifiera alla funktions aktiviteter mm, eftersom man behöver känna till dessa för att kunna avgöra om det nya systemet skall ha samma funktionalitet samt hur den skall se ut.

Funktionsdiagram
Beskriver funktioner i verksamheten på ett hierarkiskt sätt (olika nivåer).

Förändringsanalys
Förändringsanalysen resulterar i en beskrivning av nuläget och framtidsläget samt hur man går från nuläget till framtidsläget. Det finns även situationer där man funderar på att genomföra förändringar där det inte finns ett nuläge att först beskriva t ex om man funderar på att utöka verksamheten med en ny fabrik i Kina. Här beskrivs de olika arbetsstegen och vad man bör tänka på.

Bakgrund och direktiv - Hur ser verksamheten ut idag, finns det ett förändringsbehov, vilka problem vill man åtgärda, vilka alternativ finns, konsekvenser och lönsamhet.

Verksamhetsanalys och verksamhetsbeskrivning nuläge - Börja med att beskriva hur verksamheten ser ut idag. Gör dels en verbal beskrivning, DFD-diagram, en begreppsmodell samt rutinskisser.

Problemanalys och beskrivning - gå igenom de olika problemen i verksamheten och beskriv dessa verbalt.

Mål för förändring - Beskriv utifrån problembeskrivningen hur man vill att verksamheten skall fungera i framtiden.

Utvärdering av förändringsbehov - Utifrån problembeskrivning och mål för förändring, beskrivs förändringsbehoven.

Avgränsning - Motivera vilken förändringsåtgärd som i första hand skall genomföras.

Förslag till förändringsåtgärder

Framtida lösningsalternativ - Beskrivning av den framtida verksamheten, DFD-diagram, begreppsmodell, rutinskisser samt verbal beskrivning. Konsekvenser för verksamheten. Kostnadskalkyl.

Förslag till fortsatt arbete - Preliminär projektplan, projektorganisation, bemanning av projekt, resursbehov, budget för projekt.

Några vanliga misstag som man kan göra vid förändringsanalysen
Man kan tro att nuläget lätt låter sig beskrivas, men här finns lika många möjliga beskrivningar som personer som beskriver.

Samma sak gäller framtidsbeskrivningen, går heller ej att entydigt beskriva.

Att tro att man kan förutsäga händelser och deras effekter.

Att tro att framtidsvisionen kommer att inträffa.

Händelse
Förändring av situation som kräver någon form av åtgärd.

IAD
Iterative Application Development. Användarstyrd utv, sen leverans finns inte
Faser: 0-avgränsa, säkerställa; 1-kravspec; 2-pilotutveckl; 3-implementation

+: tidigleverans av högprioriterade delar, snabbare intäkter på IT-invest., hanterar ändrade krav, anv påverkar
-: (risker): oändliga iterationer, stora ändringar, ej representativa anv, instabila systemleveranser (tidsstress), missbruk av prototyper

Informationssystem
Ett informationssystem är ett system för insamling, bearbetning, lagring, överföring och presentation av information.

Några karakteristiska drag hos ett IS
- Är en mänsklig konstruktion.
- Måste vara knutet till en viss arbetsuppgift. ett informationssystem måste ses i förhållande till en viss uppgift i en bestämd verksamhet.
- Förmedlar information från vissa personer till andra personer.
- Tar emot information av olika slag.
- Utför olika typer av informationsbehandling.
- Informationsbehandlingen kan vara både manuell och maskinell. Med manuell behandling avses att en mänsklig bedömning krävs för informationsbehandlingen.

Intangibles
När man gör en effektbedömning och kalkylering av ett förändringsarbete, finns det alltid så kallade icke mätbara konsekvenser (intangibles).

IT-artefakt
Vad kännetecknar en god IT-artefakt? Förutom egenskaper såsom effektivitet, funktionalitet, driftsäkerhet och användarvänlighet bör man även ta hänsyn till andra aspekter när man bedömer en IT-artefakt, se nedan.:

Handlingsutrymme
De möjligheter och begränsningar som en IT-artefakt medför. Ex: med hjälp av   bankomaten kan jag ta ut pengar även på söndagar – mitt handlingsutrymme har ökat.

Genomskinlighet
Hur pass man förstår hur IT-artefakten fungerar "inuti" (underliggande funktionssätt, bankomaten: liten genomskinlighet.

Föränderlighet

Handlingskaraktär
Exempelvis systemkomponent, handlingspartner, verktyg, arena eller medium.

Interaktivitet

Dynamisk gestalt
Tidsbunden karaktär som uppstår efter hand som användaren interagerar med den. Måste testa ett dataspel "live" för att se om det är bra; är det lugnt eller hackigt, är det många upprepningar.

Självständighet
Automaten = mest självständig, verktyget = minst självständig, gör inget på egen hand.

Symbolvärde

Inre motivation
Användaren använder den för sin egen skull, inte för yttre belöningar. är kul/intressant/fantasieggande/utmanande att använda, exempelvis dataspel.

Spelbarhet
Hur pass mycket inre motivation som IT-artefakten ger. Tecken bra spelbarhet: "bara en gång till".

IT-design
IT-design handlar om allt det som du måste göra från ax till limpa dvs från idé till färdigt artefakt. Systemutvecklingen täcker det mesta av det som måste göras men det kan finnas några steg innan där man arbetar med ideerna innan man börjar definierar kraven på IT-artefakten. Systemdesign, informations-systemdesign, programvaru- och interaktionsdesign är som regel del av systemutvecklingen.

Karaktärsobjekt
Ett objekt som för sin existens beroende av ett kärnobjekt. Tex. garageplats är ett karaktärsobjekt, beroende av garage (kärnobjekt).

- Identifiera objektens egenskaper/attribut. Ex. ålder, kön, storlek, antal
- Bestäm objektens unika identifierare, primärnycklar. Ex. persnr, kundnr
- Definiera relationerna mellan objekten. Har, består av, känner till
- Namnge eventuella relationsobjekt.
- Namnge relationerna (primär och invers riktning).
- Sätt ut kardinaliteten. Min- och maxvärdena för en relation.

Kvantifierbara
De mätbara konsekvenserna bör tas upp i kalkyler, K/I-analys (Kostnads/Intäkts)

- Direkta och indirekta kostnader
- Direkta och indirekta intäkter, besparingar exempelvis ökad försäljning, personalbesparingar

Icke kvantifierbara konsekvenser (Intangibles)
Exempel på sådana som ej direkt går att kvantifiera, mäta i pengar:
- Bättre service
- Mindre manuell hantering
- Enklare hantering
- Större driftsäkerhet
- Ökat beroende extern servicebyrå
- Övriga påverkande faktorer
- Mijö
- Personella
- Organisatoriska
- Politiska
- Fackliga

Kontextuellt utforskande
En uppsättning principer och tekniker, baserade på grundsynen att systemdesign ska ta sin utgångspunkt i de blivande användarnas arbete men syfta till att berika det genom de nya möjligheter som informationsteknologin ger. Väsentligen består ett kontextuellt utforskande av kombinerade intervjuer och observationer, där man strävar efter att få en så rik bild som möjligt av den verkliga arbetssituationen.

Kvalitetsplan
Vad innebär en kvalitetsplan och varför är det viktigt att upprätta en sådan i ett systemutvecklingsprojekt? Kvalitetsplanen ger en samlad presentation av hur kvalitetsarbetet ska bedrivas i projektet. Plan för kvalitetsstyrning, sätt att kvalitetssäkra. Styrande för vilka metoder, hjälpmedel och procedurer projektet ska användas.

Innehåll:
Syfte
Referenser
Organisation
Dokumentation
Metoder och standards
Granskningar och revisioner(besiktningar)
Test
Felrapportering och felkorrigering
Verktyg
Hantering av kod
Hantering av lagringsmedia
Underleverantörer
Lagring och underhåll av protokoll
Utbildning
Riskhantering

Kärnobjekt
Ett objekt som för sin existens ej är beroende av något annat objekt.

Analys
Vad för nytt/ändrat informationssystem behöver vår verksamhet?

Analysfasen delas in i:

Verksamhetsanalys, där man analyserar verksamheten och beskriver denna som en modell i form av ett verksamhetssystem. Resultatet blir beskrivningar som visar sammanhangen mellan informationssystemets yttre egenskaper och verkligheten i form av grova DFD:er, Funktionsträd och Objektmodell.

Informationssystemanalys. Här görs en analys av Informationssystemets inre egenskaper d.v.s. man analyserar hur data lagras rent strukturellt inne i systemet, vilken typ av informationsbearbetning som behövs i datasystemet för att erhålla efterfrågad utdata. Resultatet blir en beskrivning av informationssystemet i form av detaljerade DFD:er, Datamodell och Termkatalog.

En viktig länk mellan Analysfasen och Designfasen är Kravspecifikationen. Detta är ett dokument som ger en samlad beskrivning av de krav användarna ställer på det framtida informationssystemet.

Design
Utformning av en principskiss för hur systemet skall byggas upp i stort.

Här utformas tekniska lösningar baserade på den allmänna modellen av datasystemet. T.ex. att utifrån analysfasens Datamodell utforma tabeller i en relationsdatabas eller att i JSP-notation eller Pseudokod beskriva hur en viss informationsbearbetande process ska gå till. Denna fas resulterar bl.a. i en Databasmodell. Här sker även utformning av skärmlayouter.

Konstruktion
Realisering av informationssystemet. Här utarbetas och konstrueras det nya/ändrade systemets databastabeller och program samt ev. nya manuella rutiner. Testningar och detaljerad dokumentation sker. Resultatet av denna fas är en färdig databas med fungerande program, användarmanualer och ett färdigt fungerande användargränssnitt.

Införande
Här tas det nya systemet och ev. manuella rutiner i bruk av verksamheten. Aktiviteter som t.ex. utbildning av personalen och utformning av säkerhetsrutiner sker (t.ex. backup). Här kan även förekomma en omfattande registrering av data i den nya databasen.

Förvaltning
När systemet införts i verksamheten måste det fortlöpande kunna förbättras och underhållas i takt med att omgivningen förändras och nya funktionella önskemål uppkommer. Idag består arbetsuppgifterna för personal på dataavdelningar till största delen av underhåll av gamla system istället för utveckling av nya.

Metamodell
Modell av modellen.

Metod
En metod är en detaljerad beskrivning av sättet att lösa ett visst problem. En metod är långt mer detaljerad än en modell. En metod är ett sätt att lösa en viss typ av problem.

En metod karakteriseras av;
- Användningsområdet, dvs. på vilka typer av problem den kan tillämpas.
- Vilket arbete som skall utföras, och eventuellt hur detta arbete bör organiseras. vilka beskrivningstekniker som ska användas, och hur.

Minispecifikation
Är den lägsta nivå, som man tycker att det är nödvändigt att bryta ned av en DFD, för att identifiera de aktiviteter som skall utföras av datorn och de kan beskrivas med hjälp av bl a strukturerat språk, beslutsträd, beslutstabell mm.

Milstolpe
Kontrollstation, används i projektstyrning. Formulerar milstolpar(delresultat) som projektet ska passera på sin väg till slutresultatet.

MMI
Man Machine Interface.

Modell
Är en avbildning, i en viss form, av någonting, ur ett visst perspektiv, för ett visst ändamål. En modell förenklar, strukturerar och fokuserar. En modell är en ögonblicksbild, fryst vid en viss tidpunkt. En modell är en överenskommelse om hur vi ska se på verkligheten, basen för koordinerad verksamhet.

Konceptuell (data)modell
Begreppsmodell, terminologin i verksamheten. Beskriver informationen i verksamheten i form av de viktigaste begreppen och dess relationer. (Konceptuell modellering, begreppsmodellering, datamodellering, plus några begrepp till, är olika namn för egentligen samma sak, nämligen kartläggningen av en verksamhets information på ett begripligt och entydigt sätt)

Målmodell
Beskriver intentioner i en verksamhet eller med ett förändringsarbete, mål, åtgärder, möjligheter, problem. Målmodellen besvarar frågor som;
- Varför finns verksamheten?
- Vad vill man uppnå?
- Varför ska den bedrivas på detta sätt?
- Vad ska vi göra för att förbättra vår verksamhet?
- Vilka motstridiga mål finns i vår verksamhet?
- Exempel på målmodell, Mål - jag vill bli rik, Åtgärd - spela på V75.

Normalisering
Vid lagring av information i databas avlägsnas överflödig (redundant) information, man vill undvika att lagra samma information på flera ställen. Tänk på "Codds princip" attributen i objektet skall vara beroende av primärnyckeln, endast primärnyckeln och ingenting annat än primärnyckel.

Ontologi
Vår uppfattning om vad verkligheten är.

Produktsemantik
Designspråk, inom nästan alla designområden utvecklas olika sätt eller språk för att beskriva produkter och deras egenskaper. Syftet är att hitta ett sätt att uttrycka produktegenskaper så att de kan förstås och användas i fortsatt designarbete.

Process
En process är en eller flera aktiviteter som bearbetar en eller flera input (information eller material) och producerar en eller flera output på ett värdeskapande sätt.

De synpunkter som kommer fram under utprovningen av en prototyp kan leda till att man gör en ny förbättrad prototyp som i sin tur testas och ytterligare förbättringar kan göras. Processen kan upprepas flera gånger till det att man har det underlag som behövs för att framställa produkten. Prototyping är en iterativ process.

En del kallar prototypen av ett informationssystem för systemskiss, och prototyping blir då att utarbeta systemskisser.

Prototypen bör visa exakt hur kommunikation (gränssnittet) mellan människa och maskin kommer att se ut. Den måste kunna visa systemets funktionella egenskaper, det vill säga vad systemet kan göra för användaren, och vad det kräver av användaren. Prototypen behöver däremot inte ha en effektiv teknisk utformning. Den behöver inte klara fullskalebelastning etc.

Man kan givetvis bygga en prototyp även för att testa en speciell teknisk lösning och i det fallet är gränssnittet inte intressant. När man talar om protyping i samband med systemutveckling, handlar det oftast om att man gör en prototyp för att användarna ska få ge uttryck för sina önskemål.

Det huvudsakliga syftet med prototyping är att få en bättre kravspecifikation som verkligen beskriver vilka önskemål användarna har på systemet. En del hävdar att prototyping ger användarna ett färdigt system, både snabbare och billigare, vilket i och för sig är sant om man tillämpar time-boxing och 80/20-regeln (Denna ovetenskapliga regel tycks finna giltighet i många olika sammanhang, här innebär den att 20% av utvecklingsarbetet levererar 80% av systemets funktionalitet). Det viktigaste för en systemutvecklare är dock att man verkligen uppfattar vad användarna vill ha, och i och med prototyping blir det också lättare för användarna att uttrycka vad de vill ha. Just detta är pudelns kärna i all systemutveckling.

Tekniker för prototyping
Den ursprungliga utgångspunkten för prototyping var att prototypen enbart skulle användas för att prova ut viktiga egenskaper hos produkten. Efter utprovning hade prototypen spelat ut sin roll. På senare år har den mesta av prototypingen gjorts med hjälp av 4G-verktyg, dvs olika programmeringsverktyg för att snabbt få fram en prototyp. Detta har medfört att man skiljer mellan två typer av prototyping:

- Prototypen kasseras efter användning, och man utvecklar en ny driftsversion.
- prototypen byggs ut ytterligare och utvecklas till en driftsversion.

Metodstegen
Innan man inleder den egentliga prototypingen måste man avgöra om problemområdet lämpar sig för prototyping.

Prototyping är speciellt lämplig att använda då kraven på systemet är osäkra eller att kraven snabbt kan förändras, eller om kraven är svåra att analysera eller delvis okända. Kort sagt då man har med en föränderlig miljö eller organisation, och/eller där användarna är osäkra på vad de vill ha och/eller är ovana vid tekniken. Speciellt lämplig är metoden jämfört med traditionella systemutvecklingsmetoder (som ex. Vattenfallsmetoden) då den lätt fångar upp förändringar av systemet under senare faser.

Den egentliga metodstegen för prototyping består av fem metodsteg:
1. Identifiera centrala behov
Verksamhetsstudien syftar till att ringa in de mest centrala behoven. Den ska bara ge ett underlag till framställning av den första prototypen. Därefter använder man iterationer för att förfina och komplettera dess behov.

2. Utarbeta första prototyp
Prototypen måste ha en sådan relevant omfattning att den kan stimulera till meningsfull diskussion om fortsatt utvecklingsarbete. Den första prototypen måste täcka minst 60% av användarnas behov och bör dessutom levereras relativt snabbt.

3. Demonstrera och diskutera förbättringar
Avsikten med det här metodsteget är att få fram nya eller reviderade krav på informationssystemet. Detta sker genom att en rad användare får tillfälle att testa och använda prototypen, för att därefter komma med olika synpunkter på förändringar.

4. Införa förbättringar
I det här metodsteget bygger systemutvecklarna en ny prototyp som tar hänsynt till de önskemål om förbättringar som har framkommit.

5. Täcker prototypen behoven?
I det metodsteget avgör man om det krävs ytterligare en iteration. Iterationerna avslutas när prototypen har ett sådant innehåll att den kan sägas motsvara de krav användarna har på systemet för det aktuella användningsområdet.

PSO-utveckling
Person, (informations) System, och Organisations-utveckling. Vid utvecklingsarbete är det viktigt med samordning, samtidigt som man utvecklar informationssystemet, arbetar man med att motivera och kompetensutveckla användarna.

RAD
Rapid Application Development
+: återanvändbara delar, lägre underhållskostnader, användardeltagande, motsvarar organisationens behov bättre.
-: man måste kunna metod & verktyg – inlärning krävs

Rationell process
En process som går att förstå, dvs. när vi själva kan se varför processen utförts på ett visst sätt, och när utförandet stämmer med våra ideal och värderingar.

Relationsobjekt
Ett relationsobjekt är för sin existens beroende av de kärnobjekt som det är kopplat mot. Relationsobjektet identifieras av kärnobjektens ingående primärnycklar.

Relativitetsprinscipen för system
Varje system kan ses som en del i ett större system. Varje enskild del av systemet kan betraktas som ett system.

Riskanalys
Syftet med en riskanalys är att identifiera både möjligheter och risker för ett projekt innan dessa inträffar. Riskanalys kan också vara en del av konsekvensanalyser av en ny investering för att bedöma om man skall göra investeringen eller ej.

Rutinskisser
Beskriver arbetsrutiner i en verksamhet. Hur ett ärende behandlas från början till slut. Vem som gör vad och var. Vilken information som

Rutin
En formaliserad beskrivning över hur en verksamhet hanterar en viss typ av ärenden. Stat och kommun använder gärna begreppet ärende medan privata organisationer brukar föredra att använda begreppet (arbets)rutin.

SASD
Strukturerad Analys och Strukturerad Design. Det är ett angreppssätt vid systemutveckling där utgångspunkt för systemutvecklingen är verksamhetens funktionalitet (processer).

Semantisk relation 
En relation mellan två objekt som är dubbelriktad och där varje riktning kan namnges (primär och invers riktning)

SIV
Standardsystem I Verksamhet. Institut för verksamhetsutveckling (förkortat Institut V) i Stockholm är den instans som arbetat med metoder och beskrivningstekniker i anslutning till standardsystem. Institut V kallar sin modell för SIV. Modellen används för val- och anpassning av standardsystem till verksamheten.

Spelplan
Ett antal fristående arbetsmoment som kan bli aktuella vid en viss ärendetyp och vars ordningsföljd kan variera beroende på situationen.

Statiska attribut
Attribut som ej förändras, ex. personnummer (761231-0191)

Syntestänkande
Skapa sammansatta ting utifrån delar av mindre enheter och dessutom kunna sätta samman kunskap och information om detaljer på ett sätt som stödjer ett helhetstänkande.

Systemspecifikation -  Kravspecifikation

Kravspecifikationen - VAD
Kravspecifikationen är ett dokument som ger en samlad beskrivning av de krav användarna ställer på det framtida systemet. Kravspecen är resultatet av analysfasen och det fungerar som länk mellan denna och nästa fas (utformningsfasen).

Innehåll enl. livscykelmodellen:

Avsikten med systemet, mål

Övergripande beskrivning av systemet

Organisatorisk förutsättningar

Systemets funktioner (för varje funktion specificeras vad funktionen ska göra, vilka rapporter som ska tas fram samt vilken information funktionen behöver för att kunna lösa uppgiften.)

Systemets generella egenskaper (tillgänglighet, användarvänlighet, säkerhet, kvalitet och utvecklingsmöjligheter)

Funktionernas egenskaper (frekvens och spridning av rapporter, svarstider, kapacitet)

Manuella funktioner

Dokumentation (system-, drift-, användardokumentation)

Utbildning

Systemspecifikationen - HUR
Systemspecifikationen är det dokument som skapas under utformningsfasen. Det talar (troligen)om hur systemet ska utformas, den tekniska lösningen, vilken utrustning och programvara som ska användas.

Systemutvecklingsmodell
En modell som används vid systemutveckling, exempel på sådana är ISAC, livscykelmodellen mm. Varje modell har sina styrkor och svagheter.

Teknik
En teknik är ett arbetssätt. Ordet användes ursprungligen i samband med konstnärliga prestationer. Inom systemeringen arbetar man i första hand med beskrivningar. En beskrivningsteknik är ett slags "recept" på sättet att göra en beskrivning. Receptet besår av en uppsättning regler som säger hur en del av verkligheten kan uttryckas i en beskrivning. Formaliserade beskrivningstekniker - består i sin tur av dokumenterande och icke dokumenterande beskrivningstyper. Exempel på den första typen - byggritning, karta, den andra typen - muntliga militära kommandon. Icke formaliserade beskrivningstekniker - består i sin tur av dokumenterande och icke dokumenterande beskrivningstyper. Exempel på den första typen - brev till en vän, den andra typen - vanligt samtal. Inom systemutveckling används i huvudsak formaliserade beskrivningar.

Temporalt flöde
I interaktionen med en IT-artefakt finns ett temporalt flöde, som kan uppvisa olika karaktärer. Det kan vara lugn, snabbt, stressigt eller hackigt. Temporalt = tidsstyrt.

TQM
Total Quality Management. Innebär att alla på företaget kontinuerligt jobbar med små kvalitetsförbättringar. Förutsätter att alla känner ett engagemang.

Trappan
Trappan är en företags- och analysmodell som visar i vilken ordning ett företag i behov av förändring behöver angripa olika delar(trappsteg). De olika trappstegen är samma som "de samverkande kugghjulen"; d.v.s. affär, process, kompetens, mått, information och organisation. Trappan ska städas uppifrån och ner, man får inte hoppa över steg eller gå i annan ordning. Informationssystemet är hjärtat med ådror ut i alla trappstegen. Förändringar i info-lösningen får konsekvenser på trappstegen och tvärtom.

Ex. Om ett företags produkt ute i marknaden stöter på problem, tittar man först på vilken typ av problem det är, vilka nya krav kunderna ställer etc, sedan går man till processen för att se hur man kan möta de nya kraven, därefter ser man över organisation för att genomföra den nya processen, vilken kompetens som behövs.

UML
Unified Modelling Language. Standardiserat modelleringsspråk

Användningsfall, "use-case" (motsv. förundersökning/analys). typ rutinskiss