Essäy frågor, från gamla tentor. Systemutveckling A 7.5hp Flashcards
I väntrummet på en akutmottagning väntar olika patienter på att få träffa en läkare. Akutsjuksköterskorna jobbar med triagering, alltså att
sortera och prioritera i patientflödet utifrån en bedömning av en patients medicinska allvarlighetsgrad. Till sin hjälp har de en
triageringshandbok samt en app i vilken de bland annat registrerar när en patient anländer. Vissa patienter har bedömts behöva
snabbare behandling, bland annat de som behöver röntgas. När en patient varit på röntgenavdelningen får denne sina röntgenbilder i ett
grönt kuvert och återvänder då till väntrummet på akutmottagningen. Akutsjuksköterskorna som jobbar med triagering kan lätt identifiera
dessa patienter då det gröna kuvertet sticker ut bland patienterna. Det gröna kuvertet underlättar även när det finns språkbarriärer på
grund av bristande språkkunskaper.
Beskriv triagering som system och vad som ingår i det utifrån beskrivningen ovan. Motivera ditt svar (8 poäng).
Triageringssystemet består i den här fallbeskrivningen av ett antal komponenter. Vi har dels en app, dels de olikfärgade kuverten men
även akutsjuksköterskorna som är användarna av detta system. I huvudsak fungerar systemet genom att en patient (intressenter i systemet)
kommer till akuten, efter att ha registrerats och tilldelats en prioritet av sjuksköterskan (intressenter i systemet) slussas de vidare till respektive vårdavdelning. De
patienter som exempelvis tilldelats en hög prioritet och som röntgas omgående återvänder med ett färgat kuvert innehållandes dennas
röntgenbilder.
Allt detta gör triagering till ett Aktivitetssystem, det vill säga en logisk samling av aktiviteter som utförs av en grupp av människor för att nå ett mål.
Triagering är i sin helhet ett informationssystem då det hjälper vårdpersonalen att förmedla information mellan de olika instanserna. Vilket även gör det till ett socio-tekniskt system.
Det är ett informationssystem då appen (som stödjs av användarmanualen) lagrar information om när de anländer och det är input från sjuksköterskorna.
De gröna kuverten nyttjas av personalen som är en komponent (Personalen bearbetar data (grönakuvertet),
systemet tar in inputs bl.a. (sjuksköterskornas
allvarlighets bedömning eller när de ger information till appen) och ger outputs i form av en prioriteringsordning av vårdtagarna i ett inledande steg på akuten. med hjälp av komponenten triageringshandbok
Är triageringssystemet ett öppet eller slutet system? Motivera ditt svar.
Triagering är ett öppet system. Detta då det tar inputs från sin omgivning / användarna, vilket är i enlighet med definitionen
för ett öppet system. Ett slutet system skulle tvärtemot agera utan inputs från sin omgivning, vilket inte är fallet i detta scenario.
Franck vill bygga en relationsmodell om utbildningar i systemvetenskap på Uppsala Universitet. Han har konstaterat följande: det är
flera olika kurser under höstterminen, det finns flera utbildningar (t.ex. kandidatprogram i systemvetenskap, A-kursen i
systemvetenskap) och såklart många studenter som ivrigt läser systemvetenskap.
Kan du hjälpa Franck att identifiera de olika komponenter som ska ingå i relationsmodellen? Beskriv vilka entiter som finns (minst 3),
vad är möjliga attribut till dessa entiteter, och vilka relationer som kan finnas mellan dessa entiteter (dvs. kardinalitet).
(poängssättning: 1+1 poäng för varje entitet + attribut ; 1 poäng per relation med kardinalitet)
Ett ERD-digram för utbildningarna inom systemvetenskap skulle kunna innehålla (exempelvis)
följande entiteter: *Elev *Kurs *Lärare
Där relationen skulle beskrivas som följande, en elev kan delta på en eller flera kurser, där kursen kan ha en eller flera lärare (kardinaliteten
beskrivs mer utförligt i slutet av frågan).
Attributen till dessa entiteter skulle exempelvis kunna vara som följande: *Elev: Student-ID (någon form av
identifikation), Program eller kurs (Kurs-ID), Ålder, antal HP, adress mm. *Kurs: Kurs-ID, antal registrerade
studenter (genom Student-ID), utbildningens längd mm. *Lärare: Delaktighet i kurser (genom Kurs-ID),
Lärar-ID, antal undervisningstimmar mm.
Kardinaliteten mellan dessa entiteter skulle då vara som följande: *Elev: Relationen mellan elev och kurs är sådan att en elev kan delta på en eller
flera kurser (för att få ett student-ID och därmed vara med i ERD). En kurs kan även läsas av en eller flera elever (förutsatt att skolan inte håller
lektioner för tomma salar). *Kurs: En kurs kan som tidigare nämnt ha en eller flera elever. Kursen kan även ha en eller flera lärare (Möjligen skulle
en kurs kunna gå helt utan lärare, exempelvis en distanskurs med enbart en ansvarig. Defintionsfråga). *Lärare: En lärare kan vara delaktig i en
eller flera kurser under en termin. Relationen är därför att en kurs kan ha en eller flera lärare, och att en lärare kan vara delaktig i en eller flera
kurser.
Kvalitetsgranskning av kraven.
Namnge och definiera 5 kriterier för kvalitetsgranskning av krav. Ge ett exempel för varje kriterium.
*Mätbart: För att ett krav ska fylla en funktion ska det gå att testa vid systemets lansering. Exempelvis måste ett krav som
“lättanvänt” kunna testas genom exempelvis hur många första-gångs-användare som har en grundläggande förståelse för systemet efter en
genomgång på X antal timmar.
*Tydligt: Ett krav måste vara tydligt. Det kravet som nämndes i föregående exempel kan sägas vara otydligt i sin utformning. Ett krav måste vara tydligt definierat, exempelvis som att “systemet ska uppdateras var 3:e timme med nya kunduppgifter”.
*Motiverat:
Anledningen till att kravet ställs. Vad finns det för fördelar för användaren, och i förlängningen verksamheten med att detta krav ställs på systemet?
Ett exempel kan vara att “Genom att ha ett kundordersystem effektiviseras kundorderhanteringen, och därmed frigörs mer personal vilket ökar
kundnöjdheten i butiken”.
*Spårbart: Vem är det som formulerat kravet? För att förstå kravet ursprung och dess värde är det viktigt med en tydligt definierad intressent, särskilt då vissa intressenter kan ha prioritet i utvecklingen. Exempelvis “Kassapersonalen önskar större knappar i ordersystemets gränssnitt för att minska antalet felaktiga klick”.
*Sammanhang: I vilket sammanhang ställs kravet, eller i vilken del av processen.
För att till fullo förstå ett krav är det nödvändigt att beskriva i vilken situation som kravet formulerats. Att exempelvis skriva “När en order anländer
via hemsidan bör detta aviseras i personalens telefoner” sätter kravet i ett sammanhang, nämligen att kravet / behovet uppstår när en kundorder
inkommer via hemsidan.
Förklara varför det är viktigt att planera testning av systemet i samband med kravanalys
När kraven analyseras är det av största vikt att även planera in testningen av systemet för att säkerställa att dessa krav uppfylls
vid den faktiska lanseringen. För att kraven ska fylla någon funktion överhuvudtaget måste de vara mätbara/ möjliga att testa, vilket innebär att ett
välformulerat krav utan större problem bör kunna omsättas i ett test av systemet redan vid kravanalysen. Sammantaget är det alltså viktigt att
planera test av systemet vid kravanalysen för att säkerställa att kraven faktiskt uppfylls i det faktiska systemet inför lansering, ett välformulerat
krav ska även vara mätbart vilket gör att planering av tester även blir en naturlig del av kravanalysen.
Förklara vad V-modellen går ut på (syftet och olika typer av tester)
V-modellen är en modell som går ut på att man medan man utveckar varje del av ett system utvecklar man även en rad tester för att testa
denna del av systemet. Så när systemet väl är färdigställt använder man sig av dessa tester för att se om de lever upp till kraven som ställts.
testerna som utförs är:
- enhetstest: testar om en enskild funktion hos systemet fungerar som den ska
- integrationstest: testar om olika funktioner som är beroende av varandra fungerar tillsammans
- systemtest: testar om systemet i sin helhet fungerar som det är tänkt, ger rätt inputt rätt output
- acceptanstest: testar om det lever upp till användarnaskrav på systemet
Förklara vad ett acceptanstest är (ange 2 olika typer av acceptanstester)
Ett acceptanstest är ett test på hur användarna uppelver systemet och om de “accepterar” det, det vill säga om de kommer att
använda som avsett vid lansering. Det finns i huvudsak två acceptanstester som genomförs i och med lanseringen av ett nytt system:
Alpha-testing: Ett test av systemet med fabricerad data, det vill säga att systemet beter sig som vanligt, men den data som används av
användarna är skapad specifikt för testet.
Beta-testing: Ett test av systemet med verklig data. I dette skede så får användarna alltså testa systemet praktiskt taget exakt som det
kommer att se ut vid lanseringen.
Kravinsamling (eng. requirements elicitation)
FÖRSTÅELSE: definiera syftet av denna process.
Syftet med kravinsamlingen är att kartlägga vilka funktioner systemet förväntas handhålla och vilka problem dessa förväntas lösa.
Kraven kan delas in i olika kategorier, beroende på vem eller vad de rör, exempelvis Business Requirements som direkt rör affärsplanens
framgång, User Requirements som syftar att förenkla användares arbetsuppgifter, Functional Requirements som definierar vad systemet
förväntas göra samt Non-functional Requirements som beskriver hur systemet ska fungera.
Dataflödesdiagram (DFD).
Förklara vad ett dataflödesdiagram är och vad det används till
Ett dataflödes-diagram visar hur dataelement flödar mellan entiteter, datalager och processer inom en övergripande process.
Dataflödes- diagrammet är en processmodell som används vid analys och design fasen för att tydliggöra hur data flödar inom en process.
Eftersom att dataflödesdiagrammet har flera nivåer (kontext ->0,1,2,3,4,5 osv) kan det användas för att dels skapa en överblick av en process
genom kontextdiagrammet / nivå 0, exempelvis då man vill analysera vilka entiteter och delprocesser som finns i en process. Men även för att
närmare analysera en delprocess genom nivå 0,1,2,3 osv. exempelvis för att se vilka datalager som är delaktiga vid en viss process för att
möjliggöra för högre säkerhet hos de datalager som hanterar personuppgifter eller för att helt enkelt förstå kopplingarna inom systemet och
processen.
Förklara vad DFD-nivåer syftar till och hur indelningen i olika DFD-nivåer sker.
DFD-nivåerna syftar till att skapa abstraktionsnivåer i avbildningen av en process. Den mest övergripande nivån,
kontextdiagrammet visar enbart entiterna och den övergripande processen som sker. Exempelvis Kund -> Order -> Företag.
I nästa nivå, nivå 0 adderas även datalager och delprocesser till beskrivningen. Därmed kan föregående exempel utökas med en databas för
kundordrar, lagerstatus och processer för betalning, leverans med mera.
I de fortsatta nivåerna, som börjar vid nivå 1 isoleras enskilda delprocesser för att beskrivas närmare. Exempelvis kan processen för
betalning i nivå-0 diagrammet disikeras närmare och delas upp i flera delprocesser och datalager.
Den fortsatta nivå-indelningen sker då man går in i mer detalj på en enskild process i nivå-1 diagrammet (som då skapar nivå 2-diagrammet) och
så vidare. Genom de olika nivåerna kan man alltså analysera processer både övergripande, men även på en extremt hög detaljnivå.
Arkitekturstilar
Kurslitteraturen behandlar olika arkitekturstilar, bl.a. klient-server och flerskiktsarkitektur som bygger på begreppet “skikt”.
Förklara vad menas med skikt och ge ett exempel på en logisk uppdelning i 3 olika skikt. Förklara vad som ingår i dessa 3 skikt.
Skikt är en typ av logisk arkitektur som beskriver hur en process utförs i systemet. En grundläggande två skikts arkitektur kanske
exempelvis enbart innefattar en dator som visar det grafiska och en databas som hämtar, och bearbetar data.
En arkitektur med tre skikt tar ofta sin utformning i en stil liknande denna: 1) Presentation av data -> 2) Hämtning av data -> 3) Bearbetning av
data. Genom att dela upp uppgiften på detta sätt i tre delar blir hela systemet snabbare. Exempelvis kan en vanlig kontorsdator presentera
informationen på skärmen, som gått via en separat server som inhämtar datan från en databas, där datan lagras och behandlas för det specifika
syftet.
Att dela upp arkitekturen på detta sätt i n-antal skikt ger mer processkraft i varje enskilt steg, vilket kan kraftigt påskynda annars långsamma
processer. Att via en persondator både hämta, bearbeta och presentera exempelvis aktiedata, skulle i de flesta fall gå extremt långsamt, om det
skulle gå överhuvudtaget.
Förklara varför det är viktigt för en systemdesigner att ha ett etiskt förhållningssätt till design- och utvecklingsarbetet.
Design och utvecklingsarbetet är essentiellt för den färdiga produktens utformning. I designfasen utvecklas exempelvis
gränssnittet för användarna som i slutändan är hur systemet “representeras” här finns ett mycket stort ansvar för hur användarna i slutändan
kommer att bruka, eller missbruka programmet och hur det till följd kommer att påverka dom.
Ett relevant exempel i dagsläget är sociala medier, som ofta till stor del skapar sina användare genom att designa sin applikationer så att
användarna stannar kvar på appen, och inte minst upplever att det är viktigt för dom. Genom att designa funktioner som stora knappar med
hjärtan (symboler vi relaterar till) som ska utgöra “likes” och genom att skapa flöden som aldrig tar slut, utan där man kan scrolla förevigt kan
man säga att de utgör exempel på oetisk design. Genom mänsklig psykologi får nämligen denna design oss att stanna kvar längre, och uppleva
likes på våra bilder som en utvärdering av oss själva - vilket har visats leda till en rad psykologiska åkommor hos användarna (kan talas om en
ny folksjukdom).
Vidare kan man diskutera information overflow, och hur man som designer ansvarar för att rätt information presenteras på rätt sätt. Att för mycket
information presenteras på exempelvis studentportalen har visats leda till onödig stress då hjärnan konstant försöker processera all den
information som den slås av. Hur man visuellt presenterar informationen man vill förmedla påverkar alltså användaren. Detsamma gäller vid
skapandet av produktionssystem och dylikt där systemet kanske i större utsträckning påverkar arbetaren än vice versa. Alla system bör ta hänsyn
till den människan som kommer att använda systemet, och hur det påverkar denna tilltänkta användare.
Det finns även aspekter av etik inom designen av datalagringen, då man exempelvis ansvarar för att välja en säker lagring av personuppgifter eller
annan känslig data som systemet kan tänkas hantera.
=> Tillägg!! Därför är det bra att testning sker så tidigt som möjligt i ett systemutvecklingsprojekt, för att identifiera vilka brister och problem
som finns med tex det föreslagna gränssnittet.
Kravhantering: FÖRSTÅELSE: Definiera följande begrepp: i. funktionellt krav ii. icke-funktionellt krav iii. kravspecifikation
Ett funktionellt krav beskriver VAD ett systemet ska göra, utan hänsyn till tekniska aspekter. Kan exempelvis vara:
“Tillgång till kundhanteringssystem”
Ett icke-funktionellt krav besrkiver HUR ett system ska fungera. Detta kan då exempelvis ta formen av:
“kundhanteringssystemet ska finnas
tillgängligt i alla butiker i Frankrike och Spanien”.
Kravspecifikationen är det dokument som sammanställer samtliga funktionella och icke-funktionella krav på systemet. Den kan även innehålla
användarkrav och affärskrav, där indelningen är efter vad som är krav utifrån verksamhetens mål och vad användarna av systemet har för krav
för att kunna genomföra sina arbetsuppgifter.
=> ett tillägg!! Krav ska inte ge förslag på lösningar. Om kraven ger förslag på lösningar låser man sig tex fast vid en speciell hårdvara eller
mjukvara. Kraven ska inte vara creeping utan hålla sig inom projektets ramar.
REFLEKTION: man brukar säga att kravhantering sker inom analysfasen av systemutveckling. Men man kan också hävda att kravhantering kan också ske delvis inom andra faser. Motivera hur och varför kravhantering kan sträcka sig över systemutvecklings
samtliga faser
Först och främst ska sägas att i enlighet med Eriksson (2008) så bör kravhantering ske iterativt och regelbundet i hela
utvecklingsprocesen. Detta har sin grund i att krav, som när allt kommer kring avgör hela utformningen av systemet, är en föränderlig åsikt.
Intressenterna som vädrar sina krav i analysfasen kan 1) komma på andra krav för systemet 2) ändra sin uppfattning under systemets gång 3)
inse att ett krav inte längre är relevant.
Eftersom att intressenternas kravbild är föränderlig så bör projektet ta höjd för detta, genom en regelbunden kravinsamling som även innefattar
återkoppling med de intressenter som ursprungligen lyfte krav säkerställs att systemet är relevant även när det lanseras (Eriksson, 2008). Det
förefaller därför naturligt att kravhantering sker även i design, och till viss del i konstruktionsfasen av systemet för att säkerställa att systemet
utformas efter intressenternas nuvarande kravbild.
I ett användningsfall anges:
i) det sk. normala händelseförloppet.
ii) alternativa händelseförlopp.
iii) undantag.
FÖRSTÅELSE: Förklara innebörden av ovanstående begrepp.
Normalt händelseförlopp:
Det normala händelseförloppet är den “väg” som användaren förväntas ta genom programmet när allt går enligt förväntningarna. Användaren
tar alltså den uttänkta vägen för att komma fram till den erfordrade lösingen.
Alternativt händelseförlopp:
Det alternativa händelseförloppet är en icke-tilltänkt väg som användaren kan ta, men som fortfarande leder till önskat resultat. Detta innebär
alltså att användaren lyckas göra en by-pass någonstans, men viktigt att poängtera är att det fortfarande resulterar i att önskat resultat
uppnås.
Undantag:
Med ett undantag menas att något har gått fel. Det är alltså nästa steg utöver ett alternativt händelseförlopp, men här har användaren inte
bara hamnat på en icke-tilltänkt väg genom programmet, det har dessutom gått så fel att resultatet blir felaktigt.
