Frågor Flashcards
(120 cards)
1
Q
Vad är arkitektur?
A
Arkitektur i ett ERP-system är den övergripande strukturen som definierar hur moduler, databaser, användargränssnitt och externa integrationer hänger ihop och kommunicerar.
2
Q
Vad är management i arkitekturen?
A
management handlar om att dela upp olika komplexa problem i mindre förståeliga delar.
3
Q
Vad är kravhantering i arkitekturen?
A
Kravhantering handlar om att möjligt ställa krav på modulnivå.
4
Q
Vad är vidareutveckling i arkitekturen?
A
Vidareutveckling handlar om att frikoppla delar i system så att ändringar inte påverkar hela systemet.
5
Q
Vad är underhåll i arkitekturen?
A
Det handlar om att underlätta och förenkla så att underhåll är lättare att förstå samt för att enklare kunna underhålla systemet.
6
Q
Vad är bra arkitektur, med The “illities” av arkitetur i design och utveckling?
A
Maintainability - hur enkelt ett system kan underhållas över tid så att det behåller sin funktionalitet.
Extensibility - förmågan att enkelt lägga till ny funktionalitet i systemet.
Portability - förmågan att kunna modifiera mjukvaran (”porta den”) så att den kan köras på en annan plattform (t.ex. med en annan databas eller ett annat operativsystem).
Interoperability - systemets förmåga att kunna kopplas ihop och kommunicera med andra system.
7
Q
Vad är bra arkitektur, med The “illities” av arkitetur i run-time?
A
Availability – ”uptime”
Scalability - the ability to handle an increased number of users, or an increased amount of data.
Performance - the ability to handle a request fast – the response time.
8
Q
Vad innebär indelningen av olika skikt (tiers)?
A
Olika skikt är olika nivåer som man kan dela in sammanlänkade datorer med ett nätverk. Exempel. Skikt 1 klient, skikt 2 logikserver och skikt 3 databasserver
9
Q
Vad innebär indelningen av olika lager (layers)?
A
En vanlig logisk indelning i tre lager är presentation, business logic och database.
10
Q
Vad innebär traditionella lagret (layers) presentation?
A
Vanligtvis grafiskt användargränssnitt, med tillhörande logik.
11
Q
Vad innebär traditionella lagret (layers) Business logic?
A
Business logic (”affärslogik”): Innehåller regler för verksamheten (”tex alla kunder som köper över 1000kr får fri frakt”), beräkningar, databearbetning.
12
Q
Vad innebär traditionella lagret (layers) Database?
A
Lagring av information, sökning av information.
13
Q
Hur är det vanlig att kombinera fysiska skikt med logiska lager?
A
One Tier, Two Tier, Three Tier och Multi tier
14
Q
Förklara en-skikts arkitektur?
A
Alla lager i ett skikt - en maskin. Vanligt för en-användarsystem. Ex. Word
15
Q
Förklara Två-skikts arkitektur?
A
Utvecklades för att separera grafiska användargränssnitt från datahantering, förenklade underhållet pga en tydligare separation av lager.
16
Q
Förklara Tre-skiktad arkitektur?
A
Ett alternativ till 2-skiktade klient-server lösningar- Inför ett nytt skikt som tillhandahåller affärslogik. Ger främst ökad skalbarhet men även förbättrade integrationsmöjligheter och är lättare att utöka jämfört med en 2-skiktslösning.
17
Q
Förklara Multi-skiktad arkitektur?
A
Multi-skiktad arkitektur är en vidareutveckling av den klassiska 3-skiktsarkitekturen (presentation, logik, data), där man delar upp systemet i flera logiska skikt (lager) för att uppnå bättre flexibilitet, skalbarhet och underhållbarhet.
- Tunna klienter (t.ex. webbläsare) kan användas eftersom delar av presentationslogiken flyttas till servern, t.ex. via webbservrar och API:er.
- Det blir enklare att integrera med andra system, t.ex. via webbtjänster eller REST-API.
- Systemet blir modulärt, vilket gör det enklare att underhålla, testa och vidareutveckla.
18
Q
Vad är “Middleware” Products?
A
En kategori av produkter som vanligtvis stödjer utvecklingen av business logic layer, och kommunikationen med och inom the business logic layer.
19
Q
Vad är message queue server?
A
En message queue server avkopplar avsändare och mottagare genom att använda en mellanliggande kö, där meddelanden (data-paket) placeras tills de kan hanteras av mottagaren. Detta gör att systemen inte behöver vara aktiva eller tillgängliga samtidigt.
20
Q
Vad är Business process server?
A
En Business Process Server (BPS) är en server som kör och hanterar affärsprocesser definierade i processbeskrivningsspråk, t.ex. BPEL (Business Process Execution Language) eller BPMN (Business Process Model and Notation).
21
Q
Vad är en portal server?
A
En portal server är en serverplattform som tillhandahåller ett webbgränssnitt där olika informationskällor och funktioner samlas på ett och samma ställe genom små, fristående komponenter som kallas portlets. Funktioner: Användargränssnitt med mashups från olika system. Single sign-on, att användaren endast behöver logga in en gång. Stöd för samarbetsverktyg som att hantera olika dokument och forum samtidigt.
22
Q
Vad är ett standard system?
A
Ett IT-system som utvecklats av en leverantör för att tillgodose behoven hos flera organisationer.
23
Q
Vad är ett ERP-system?
A
Affärssystem (ERP – Enterprise Resource Planning) är konfigurerbara standardsystem som integrerar information och informationsbaserade processer inom och mellan olika funktionella områden i en organisation.
24
Q
Vad är ett best-of-breed system?
A
Ett standardsystem som anpassats för att möta specifika behov inom ett visst område och som anses vara ”bäst” inom sitt område.
25
Best-of-breed +/- (vs ERP systems)
+ Varje avdelning/funktion kan ha ett skräddarsytt system.
+ Separata IT-strategier och uppgraderingsplaner.
+ Systemen kan uppgraderas oberoende av varandra.
- Problem med datakonsistens.
- Överlappande funktionalitet.
- Behov av integration.
26
Vad är kundsegmentering?
Dela in kunder efter domän, geografisk, Lagmässig etc. Eller dela in i Transaction, Consultative, Strategic.
27
Vad är Transaction, Consultative, Strategic?
Transaction - Vill enbart få systemet att “fungera”, Ovillig till förändring.
Consultative - Villig att ändra sig för att passa systemet, För en dialog om nya funktioner om det har ett behov av det.
Strategic - Har viktiga idéer områden att utveckla, är föredömen inom sitt område.
28
Beskriv tre olika sätt att hantera kunders krav vid utveckling av ett ERP-system
Ignorera/filtrera ut - Överlapp - funktionen finns redan, eller kan implementeras via konfigurering. Detta kan framförallt vara vanlig i stora ERP system – då det kan vara svårt att hitta vissa funktioner.
Generalisera systemet - Generalisera befintlig systemfunktionalitet för att passa fler önskemål, Jämför med andra kunders befintliga krav, jämka ihop
Ny funktion - Funktion som saknas i systemet – kan vara innovativ, Skapa en ny referensgrupp/stäm av med andra kunder – testa olika varianter av den nya funktionen
29
Vad betyder Generification (Generalisering)/Particularization (Specialisering)?
Generalisering - Processen att göra något generiskt, baserat på en uppsättning specifika situationer eller krav.
Specialisering - Processen att anpassa något generiskt till en specifik situation.
30
Vad betyder Generell, Poly-generell och Generell-specifik?
Generell - Delas av många kunder, Utgör grundfunktionalitet, ”core”
Poly-generell - Ger flera alternativa funktioner, kunder väljer en eller flera funktioner - Som en lista med valbara ”mallar”
Generell-specifik - Funktioner som distribueras med den generella programvaran men som bara baseras på en eller ett fåtal kunders behov. Kan vända sig mot viktiga kunder. Underlag för framtida generalisering.
31
Hur kan generalisering genomföras?
Informationsbaserad (Förändra systemets förmåga att hantera informationsstrukturer genom att göra dem mer generella) kan generaliser genom:
Arv, aggregering - sammanfogning eller sammanställning av flera delar till en helhet.
Levels of indirection - Lägg till extra nivåer för att kunna representera mer komplexa strukturer.
Processbaserad (Förändrar systemets logik, dvs de aktiviteter som utförs, eller ordningen på aktiviteterna):
Variation points - Definiera en punkt (variation point) i processen där alternativ logik (aktiviteter) kan utföras.
Business rules - Att man med hjälp av regelverk kan bestämma vägval vid variation points i processer. Kan liknas med IF och THEN satser.
32
Vad blir konsekvensen av för mycket abstraktioner?
Att lägga till för mycket abstraktion gör systemet svårt att använda eftersom viktiga detaljer är dolda bakom flera lager av abstraktion.
33
Vad är ett test i affärsystem?
Testning är en systematisk process för att ställa frågor till ett system genom att köra det, i syfte att hitta fel, verifiera att det fungerar som avsett och identifiera skillnader mellan faktisk och förväntad funktion.
34
Varför behöver en färdig produkt testas?
Varje organisation är unik, testa att systemet passar organisationen.
Ändringar kan vara gjorda i systemet, vilka behöver testas
35
Vad behöver testas i ett affärsystem? Förklara kort.
Konfigurationer betyder att affärssystem alltid behöver anpassas och därför behöver de testas för att kunna utföra den bästa anpassningen.
Integrationer betyder att affärssystem ofta integreras med andra system och för att se att det fungerar tillsammans så behöver man testa dem.
Data migration är implementation av affärsystem som ofta involverar migration av data från andra system och då behöever testas för att se att de fungerar väl ihop. Alla ändringar som görs behöver testas.
36
Vad är de 7 olika anpassningstyperna som man testar vid testning av affärssystem?
Parametrization/ customization - Adjusting the system’s functionality and data structures by setting values of predetermined system parameters.
Add-ons/Bolt-ons - Implementation of third-party standard package designed to work with ERP system and provide industry-specific functionality
Extension points - Extending the system’s functionality through custom code hooked into predefined places (extension points) of the ERP system’s code.
ERP Programming - Programming of additional applications within the ERP system, without changing the source code (using the computer language of the vendor)
Extension module - Code-based development of new components outside the ERP system. New components provide functionality not available in the standard system
API - Programming to application programming interfaces (API:s) to legacy systems or 3rd party products. Integration.
ERP code modification - Changing the ERP source-code ranging from small change to change whole modules
37
Vad finns det för två typer av fel när man testar ett affärssystem? Ge exempel.
Funktionella - Exekveringsfel (”krash”), Logiskt fel (felberäkning), Integrationsfel
Icke-funktionella - Låg prestanda, Brister i säkerhet, Dålig användbarhet
38
Vilka två olika metoder finns det för att åtgärda problem under utvecklingen?
Traditionell utveckling som sker sekventiellt, eller agil utveckling som sker iterativt.
39
Beskriv de sekventiella utvecklingmodellerna
Sekventiella utvecklingsmodeller består av fasta faser som utförs i en bestämd ordning, där varje fas avslutas innan nästa börjar. De passar bra när kraven är tydliga och stabila. Ett vanligt exempel är vattenfallsmodellen med steg som krav, design, implementation, test och driftsättning.
40
Beskriv de iterativa utvecklingmodellerna
Iterativa utvecklingsmodeller innebär att systemet utvecklas i upprepade cykler (iterationer) med planering, design, kodning och test i varje steg. Modellen möjliggör successiv förbättring och hanterar förändrade krav. Ett exempel är agila metoder som Scrum.
41
Förklara kortfattat om vattenfallsmodellen
Vattenfallsmodellen är en sekventiell utvecklingsmodell med fasta faser i bestämd ordning. Den lämpar sig bäst när kraven är tydliga från början, eftersom det är svårt och kostsamt att gå tillbaka och göra ändringar i efterhand.
42
Beskriv alla stegen i vattenfallsmodellen.
1. Krav -
* Användarnas krav på systemet
* Kravspecifikation
* Vad systemet ska stödja
2. Acceptanstest -
* Uppfyller den levererade mjukvaran kraven i kravspecifikationen?
* Möter systemet kundens krav (validering)
* Utförs vanligtvis av kunden
* Systemet testas vanligtvis i kundens miljö
3. Systemdesign -
* Krav omformas till en systemspecifikation (designspecifikation)
4. Systemtest -
* Testa hela systemets funktionalitet
* Verifiera att systemet motsvarar designspecifikationen
* Testa att systemet fungerar som en helhet från användarens perspektiv
5. Arkitekturdesign -
* Specifikation av systemets arkitektur (dess delar)
* Systemdesign bryts ned i moduler
* Moduler och deras gränssnitt
* Högnivådesign
6. Integrationstest -
* Säkerställ att samtliga moduler i systemet fungerar ihop
* Integrationer/gränssnitt mellan moduler (enheter) testas. (EJ integration av externa
system)
7. Moduldesign -
* Design av moduler (enheter)
* Klasser och relationer inom moduler
* Förbered för utvecklarna
* Lågnivådesign
8. Enhetstest (unittest) -
* Minsta testbara delarna i systemet testas
* Utförs av vanligtvis av programmerare
43
Vad innebär testdriven utveckling?
Testdriven utveckling (TDD) är en utvecklingsmetod där man skriver tester innan man skriver själva koden. Metoden bygger på att utvecklingen sker i korta cykler där man först formulerar vad koden ska göra genom ett test, och sedan skriver minsta möjliga kod för att klara testet.
Kortfattat:
- Designa nytt test
- Exekvera test (det ska fallera)
- Programmera
- Exekvera test
- Förbättra (refactor) kod när testen går igenom
44
Vilka tre olika delar finns inom testtekniker och de val man kan göra?
Verksamhet/IT - När tester omfattar verksamhetsprocesser, kontrolleras inte bara systemets funktion utan även hur väl det passar in i det dagliga arbetet, inklusive manuella rutiner. Detta skiljer sig från användningsfall (use cases), som fokuserar på interaktionen mellan användare och systemet, men ignorerar aktiviteter utanför systemet.
Täckning - Att förutse var fel kan uppstå är ofta en effektiv teststrategi, särskilt när testaren är erfaren och känner till systemets svagheter. En annan strategi är kodtäckning, som innebär att testa så stor del av programmets funktioner som möjligt – men detta kräver mer tid och resurser.
Styrning - Att använda scriptade tester (fördefinierade steg) underlättar regressionstestning, eftersom de kan köras om vid varje ny version av systemet. Dessa tester kan också dokumenteras som testfall, vilket ger struktur, spårbarhet och upprepbarhet i testarbetet.
45
På vilket sätt bygger man upp en testprocedur?
En testprocedur är en steg-för-steg-instruktion som används för att genomföra ett testfall – alltså ett konkret exempel på hur en viss del av systemet ska testas. Testproceduren beskriver hur testet ska utföras, med vilken data, och vilket resultat som förväntas.
▪ ID
▪ Namn
▪ Syfte - vad som ska testas och varför
▪ Förutsättningar - vad som behövs innan testet startar
▪ Testdata – data som behövs för test, data kan även inkluderas i testprocedur
▪ Testprocedur - stegvis beskrivning inkl förväntat resultat
46
Hur ser ett planerande och genomförande av ett testfall ut?
Testfall- Strukturerat testunderlag som beskriver hur en funktion eller egenskap ska testas. Innehåller bland annat teststeg och förväntat resultat. Kan innehålla scenarion för att beskriva teststegen.
▪ Testrapport- Dokument som summerar testaktiviteter efter en testperiod. Innehåller en rekommendation som baseras på om testmålen är uppnådda.
▪ Scenario– Specifik sekvens av aktiviteter som görs i ett system för at utföra en uppgift, till exempel logga in, lägg upp en kund, beställ varor, skriv ut faktura. Ett scenario är vanligtvis en specifik väg genom systemet, dvs en processinstans.
▪ Testsvit- Gruppering av testfall, till exempel samtliga testfall för systemtest.
47
Vad är skillnaden på varor och tjänst/service?
Varor är något som påverkas, överförs och modifieras är exempelvis en fisk, medan en tjänst är ett arbete som utförs av en part till förmån för en annan part, kan även vara kunskap.
48
49
Vad är operand resource och operant resource?
Operand resource = Varor
Operant resource = Tjänster
50
Vad är Goods Dominant Logic (GDL)?
Är ett perspektiv där operanda resurser (varor) är viktiga.
51
Vad är Service Dominant Logic (SDL)?
Svar: Är ett perspektiv där operanta resurser (tjänster) är viktiga.
52
Vad är SDL och GDLs etik?
SDL - Syftet med handel är att producera och sälja fler enheter av output (slutprodukter).
GDL - Syftet med utbytet är att ömsesidigt tjäna varandra.
53
Vad är ett API?
Application Programming Interface, är ett gränssnitt för system-till-system kommunikation. Anropas genom att följa standardiserade protokoll (Ex HTTP)
54
Vad är API-economy och vad kan det positiva vara med ett API?
API ekonomi handlar om hur man “öppnar” upp sitt API för andra användare för att dra nytta av det. Om man använder sig av ett open API kan skulle man kunna dra nytta av open innovation i termer av att de som kopplar upp sig mot API:et kan komma att skapa nya tjänster/funktionalitet för systemet. Dessa som leverantören av ERP-systemet sedan skulle kunna dra nytta av genom att implementera som en standardfunktion i systemet i framtiden. Det skulle kunna handla om utveckling av en ny modul som stödjer analysering av data – som ERP-system annars kan vara lite sämre på.
55
Vad finns det för olika slags API.er?
Private: Stängt utåt och används bara inom verksamheten
Partner: Öppet för affärspartners som kan utnyttja API:et.
Open: Öppet för alla att utnyttja
56
Vad är fördelarna med respektive API?
Private: Minskade kostnader, Förbättrade interna processer/operationer, Ökad flexibilitet: ”realtids”-verksamhet
Partner: Värdeskapande tjänst, Merförsäljning, Ett måste för affärspartners
Open: Delegerad forskning och utveckling, Ökad räckvidd och trafik, Ny intäktsström.
57
Vad är ett (Software) Service ecosystem?
- Nätverk av aktörer som utbyter tjänster
- Ett gemensamt syfte. Inte en uttrycklig kollektiv avsikt, utan snarare individuell överlevnad i kombination med ekosystemets överlevnad
- Samarbetande aktörer, snarare än i konflikt, med fokus på samarbete och koordinering
- Självanpassande
Ex: Apple, Google
58
Vad är de främsta fördelarna med API-ekonomin
Affärseffektivitet:
- Enkel integration - Inom och mellan organisationer. Möjliggör: automatisering över organisationsgränser.
- Förbättrad intern infrastruktur - Gör API:er till den grundläggande byggstenen för interna IT-system.
Affärsinnovation:
- Öppen innovation - Om du tillhandahåller ett öppet publikt API, kan vem som helst använda det och skapa nya tjänster – detta kan leda till fler användare av din tjänst
- Tillägg från tredje part - Partners kan få kontrollerad åtkomst till ditt API för att utöka ditt system. Dina kunder kan köpa tilläggen från dessa partners.
- Plattformar - Partners kan få kontrollerad åtkomst till ditt API för att utöka ditt system. Du styr vilka tillägg som körs i ditt system. Ditt system blir en plattform för nya tillägg. Kunder använder tillägget och betalar dig.
59
Vad är negativt med om ett företag inte har ett API?
Företaget når inte ut till lika mycket kunder/folk. Att ha ett API är ett sätt att tjäna pengar.
60
Vad kan vara nackdelar med att ha ett API?
Säkerhet
Beroenden av API-leverantörer
Hantering av API:er kan vara komplext – och kostsamt
KAN vara svårt att generera pengar genom ett API
61
Vad är SOA?
Det är Service Oriented Architecture - Ett systemarkitektur som är uppbyggd med tjänster kallas för en tjänsteorienterad arkitektur (SOA)
62
Vad menas med Presentation layer inom SOA?
Tjänster som tillhandahåller en del av ett användargränssnitt. Vanligtvis via en webbsida. Kan användas genom en ”Portlet” - En användargränssnittskomponent som kan kopplas in i en portalserver. Exempelvis kan det vara Google maps inbyggt på en kund sida i systemet.
63
Vad menas med Basic layer inom SOA?
Enkla tjänster som läser och/eller skriver data inom ett begränsat affärsområde.
Hantera vanligtvis ett affärsområde som består av 1–2 databastabeller/klasser/objekt.
Slutför anrop snabbt (sekunder, inte minuter).
Innehåller vanligtvis ett CRUD-gränssnitt. (Create, Read, Updatet, Delete)
64
Vad menas med Composite layer inom SOA?
- Tjänster som kombinerar andra tjänster till en ny. Vanligtvis kombineras flera grundläggande tjänster till en sammansatt tjänst.
- Innehåller ett ”mikroflöde” av aktiviteter som anropar andra tjänster. Vanligtvis sker dessa anrop i en enkel sekvens.
- Kortvariga (sekunder)
Ex: Katalogtjänsten hämtar information om produkter (produktdata) samt aktuellt lagersaldo och leveranstid, baserat på kundadress (kunddata).
65
Vad menas med Process layer inom SOA?
Tjänster som använder andra tjänster, vanligtvis grundläggande tjänster och sammansatta tjänster. Innehåller en process av aktiviteter som anropar andra tjänster.
Innehåller vanligtvis komplext beteende, till exempel:
- Parallell exekvering av flera uppgifter
- Asynkrona anrop till andra tjänster
- Långvariga processer (timmar, dagar)
- Manuella aktiviteter som processen måste vänta på
Ett exempel kan vara avboka order, då måste systemet avboka order, avboka faktura eller betala tillbaka pengarna etc.
66
Vilka två huvudegenskaper kännetecknar en bra mjukvaruarkitektur?
High cohesion och Low coupling
67
Förklara begreppen cohesion och coupling.
Cohesion: Med cohesion menas relationen inom en modul, t.ex. hur väl metoder i en klass är relaterade till varandra och arbetar mot ett gemensamt syfte.
Coupling: Med coupling menas hur moduler eller element är relaterade och beroende av varandra.
68
Vad menas med High cohesion och low Coupling?
Med high cohesion och low coupling menas att moduler är självständiga från varandra (low coupling) och att funktionerna inom varje modul är nära relaterade och arbetar mot ett gemensamt syfte (high cohesion).
Det innebär att varje modul har ett tydligt ansvar, och förändringar i en modul påverkar inte andra, vilket gör systemet mer robust, underhållbart och lätt att utveckla vidare.
69
Vad står FIRST för inom testdriven utveckling och vad betyder de?
Fast - Test ska vara snabba att köra, så att utvecklare kan få snabb feedback vid varje kodändring.
Independent - Tester ska vara fristående från varandra
Repetable - kunna köras flera gånger med samma resultat
Self-validating - Ett test ska själv avgöra om det är godkänt eller inte, utan att någon behöver tolka resultatet manuellt. Det ska ge tydligt utslag: rätt eller fel.
Timely - Testkoden ska skrivas tidigt i utvecklingsprocessen, sedan systemimplementationen.
70
Vilka designprinciper bör man använda om man vill separera service providern och användaren?
Discoverability och service contracts.
71
Vilka designprinciper bör man använda om man vill kombinera tjänster?
Composability
72
Vilka designprinciper bör man använda om man vill behandla tjänster som separata building blocks?
Autonomy, Loosely copuling, Service abstraction.
73
Vilka designprinciper bör man använda om man behöver scalability för stora system?
Statelessness
74
Hur fungerar designprincipen discoverability?
Designprincipen discoverability innebär att tjänster ska vara enkla att hitta och förstå. Det uppnås genom att man tillhandahåller ett sökbart register eller servicekatalog där alla tjänster listas med sina kontrakt (beskrivningar).
75
Hur fungerar designprincipen composability?
Designprincipen composability innebär att tjänster ska utformas så att de enkelt kan kombineras och användas tillsammans i olika sammanhang.
76
Hur fungerar designprincipen Autonomy?
Designprincipen autonomy innebär att tjänster ska vara så självständiga som möjligt och dela så få resurser som möjligt. Detta minskar risken att ett fel i en tjänst påverkar andra.
77
Hur fungerar designprincipen Abstraction?
Designprincipen abstraction innebär att man döljer all information som inte är nödvändig för att använda en tjänst. Användaren ska bara se det som behövs – inte hur tjänsten är byggd eller hur den fungerar tekniskt.
78
Hur fungerar designprincipen Loose coupling?
Designprincipen loose coupling innebär att man minimerar beroenden mellan tjänster, så att de kan fungera och utvecklas oberoende av varandra.
79
Hur fungerar designprincipen Statlessness?
Designprincipen statelessness innebär att en tjänst inte sparar något tillstånd (state) internt mellan anrop. All information som behövs för att behandla ett anrop måste skickas med i varje begäran.
80
Vad innebär BDUF-problemet vid tjänstedesign, och vad är risken med det?
Big Design Up Front innebär att man planerar och bygger för mycket i förväg innan man vet vilka tjänstefunktioner som faktiskt behövs.
Det leder till högre initiala kostnader och risk att man investerar i tjänster eller egenskaper som inte används, vilket i sin tur innebär slöseri med pengar och resurser.
81
Vad innehåller ett servicekontrakt och varför är det viktigt?
Ett servicekontrakt beskriver hur en tjänst ska användas och vad som förväntas av den.
Teknisk del:
WSDL: Beskrivning av tjänstens metoder/operationer
XML Schema: Beskrivning av datastrukturer som används
WS Policy: Regler för hur parametrar och krav ska hanteras
Affärsmässig del (SLA):
Service Level Agreement beskriver tillgänglighet, prestanda och användningsvillkor
82
Vad innebär Design-by-Contract (DbC) och hur fungerar det?
Design-by-Contract är ett sätt att beskriva hur två parter (t.ex. en klient och en tjänst) samarbetar genom ett tydligt kontrakt med ömsesidiga skyldigheter och förmåner
83
Hur kan man lösa problemet med otydliga kontrakt?
Genom att skapa ett användningskontrakt som tydligt anger:
Precondition: Vilka villkor som måste uppfyllas för att operationen ska köras
Postcondition: Vad som händer efter att operationen har körts
84
Vilka tekniska principer är centrala inom mikrotjänster och förklara de kort.
Autonomi: Varje mikrotjänst hanterar sin egen databas och fungerar oberoende.
Composability: Tjänster designas så att de enkelt kan kombineras och kommunicera med varandra.
Statelessness: Tjänster sparar inget internt tillstånd mellan anrop, vilket gör dem skalbara.
85
Vilka organisatoriska principer följer mikrotjänstarkitektur och förklara de kort.
Cross-functional team: Teamen har blandad kompetens och ansvarar för hela tjänsten – från utveckling till drift.
DevOps: Samma team utvecklar, levererar, installerar och övervakar tjänsten – enligt mottot: "If you build it, you ship it."
86
Vad innehåller (simple) Model of technical customizations?
Modulanpassning
Välj vilka moduler som ska installeras/aktiveras.
Exempel: Ska CRM-modulen användas?
Tabelleanpassning
Ändra inställningar, det vill säga ändra värden på parametrar.
Exempel: Ändra kontoplanen.
Kodanpassning
Ändra (program)kod i affärssystemet, eller lägg till egenutvecklade moduler såsom nya användargränssnitt.
87
Vad innehåller Model of organizational process customization?
Ingen förändring
Affärsprocessen passar systemets process. Endast förändringar inom enskilda aktiviteter/uppgifter och deras resurser.
Exempel: automatisering av uppgifter
Inkrementell förändring
Systemets process är idealisk och affärsprocessen ligger nära den. Förändringar görs i relationerna mellan uppgifter.
Exempel: köra uppgifter parallellt
Radikal förändring
Systemets process är idealisk och affärsprocessen är inte det. Ändra uppgifter, resurser och deras relationer. Kan även innebära förändring av processens mål/resultat.
Kallas ibland för Business Process Reengineering (BPR)
88
Vad är metoderna för anpassning av affärssystem & organisation?
1) Assess the organizations capability och 2) Select customization option
89
Vad innehåller metoderna Assess the organizations capability och Select customization option
Assess the organizations capability:
Teknisk förändringsförmåga:
- Förståelse för affärssystem (ERP-system.
- Färdigheter i mjukvaruutveckling
- Kompetens inom projektledning av mjukvaruprojekt
Organisatorisk/processförändringsförmåga:
Förståelse för organisationen (och dess processer
Kompetens inom förändringsledning
Projektledningsförmåga för att hantera organisatoriska förändringar
Select customization option:
Fastställ anpassningsalternativ baserat på förmågor
90
Vad är de fem olika perspektiven på anpassning?
Tekniskt - t.ex. tekniska anpassningsalternativ
Organisatoriskt - t.ex. organisatoriska anpassningsalternativ
Organisationens förmågor - förmågor som krävs for att genomföra anpassningar
(organisation och affärssystem/IT)
Affärssystemets förmågor – funktionalitet
Kostnadsperspektiv - t.ex. anpassning som en tillgång; kostnader för framtid underhåll och uppgradering av system
91
Vad är de 4 vanliga (Står 5 i föreläsningen men är bara 4) kraven som en användare har?
Analytics - Definiera individuella nyckeltal, diagram och rapporter. Utöka befintliga dashboards och fördefinierade datakällor. Exempel:
Konfigurera av gränssnitt genom drag and drop (dvs via configuration/parametersättning)
Webbgränssnitt (bolt-ons)
User interface - Anpassa användargränssnittet enligt verksamhetens behov. Detta inkluderar justeringar av företagsidentitet och namnstandarder, omplacering eller aktivering/inaktivering av inmatningsfält. Exempelvis:
Konfigurera av gränssnitt genom drag and drop (dvs via configuration/parametersättning)
Webbgränssnitt (bolt-ons)
Workflow programming - Anpassa förkonfigurerade arbetsflöden för att spegla affärsprocesser eller rutiner som krävs av organisationen. Exempel:
Ändringar som har påverkan på i vilken ordning aktiviteter utförs i systemet
Rollgränssnitt med stöd för arbetsflöden
Business objects - Definiera individuella datastrukturer och/eller utöka standardiserade affärsobjekt med nya datafält
92
Hur sker dessa 4 anpassningar?
Parametrization/ customization - Adjusting the system’s functionality and data structures by setting values of predetermined system parameters.
Add-ons/Bolt-ons - Implementation of third-party standard package designed to work with ERP system and provide industry-specific functionality
Extension points - Extending the system’s functionality through custom code hooked into predefined places (extension points) of the ERP system’s code.
ERP Programming - Programming of additional applications within the ERP system, without changing the source code (using the computer language of the vendor)
Extension module - Code-based development of new components outside the ERP system. New components provide functionality not available in the standard system
API - Programming to application programming interfaces (API:s) to legacy systems or 3rd party products. Integration.
ERP code modification - Changing the ERP source-code ranging from small change to change whole modules
93
Är Cloud affärssystem mindre flexibla och mindre anpassningsbara än onpremise affärssystem, om varför?
Till en viss del
Några anledningar:
- Cloud system ägs inte av kunden, de bara “hyr”
- Cloud miljöer är mer strikta än on-premise proprietära miljöer.
- Cloud arkitekturer begränsar möjligheterna att anpassa
94
Vad för anpassningar kan man göra på ett cloud baserat ERP-system?
Parametrisering - Ja - De flesta anpassningar görs via konfiguration i moln-ERP.
Add-ons/Bolt-ons - Oklart - Leverantören kan ha marknadsplatser för appar. (Se även föreläsning om API-ekonomin)
Extension points - Oklart - Beroende på arkitekturen för molnsystemet – möjligt i vissa fall.
Extension module - Oklart - Möjligt för PaaS men inte för SaaS.
API - Ja - SaaS-baserade ERP-system tillhandahåller vanligtvis strukturerade API:er – vilket gör det möjligt att koppla ihop dem med andra system.
Package code modification - Nej - Källkoden är endast tillgänglig för leverantören, det är omöjligt för kunder att göra ändringar.
95
Vilka är de fyra lagren inom SOA service typed & layers?
Presentation, Business process service, composite service och basic services.
96
Vilka lager ingår i den traditionella arkitekturen?
Presentation, Business logic och Database.
97
Vad finns det för typer av data?
Transaction data
Inventory data
Master data.
98
Vad är transaction data?
Transaktionsdata beskriver affärshändelser eller aktiviteter som sker i verksamheten, till exempel köp och försäljning.
99
Vad är inventory data?
Inventariedata beskriver lagerstatus för enskilda varor eller produkter som företaget säljer.
Den används för att hålla koll på lagernivåer och tillgänglighet.
100
Vad är master data?
Masterdata beskriver egenskaper hos verksamhetens kärnobjekt, alltså sådant som är centralt för företagets processer och delas mellan system och avdelningar. Exempelvis kunder.
101
Vilka fyra egenskaper (properties) kan användas för att särskilja master data från data om transaktioner och lagerdata (inventory) data?
Time reference, Modification frequency, Volume stability och Existential independence.
102
Förklara kort time reference.
Time reference innebär om datan är kopplad till en viss tidpunkt.
Transaktions- och inventariedata har nästan alltid en tidsangivelse (t.ex. orderdatum eller lagersaldo vid ett visst datum), medan masterdata oftast inte är direkt tidsbunden.
103
Förklara kort Modification frequency.
Modification frequency beskriver hur ofta data uppdateras.
Transaktions- och inventariedata ändras ofta, medan masterdata sällan ändras, även om enskilda fält i masterdata kan uppdateras under dess livscykel.
104
Förklara kort Volume stability.
Volume stability handlar om hur stabil datamängden är över tid.
Masterdata har oftast en jämn och stabil volym, medan transaktionsdata kan variera kraftigt från dag till dag eller månad till månad.
105
Förklara kort Existential independence.
Existential independence beskriver om datan kan existera självständigt.
Masterdata kan finnas på egen hand, medan transaktionsdata är beroende av att viss masterdata finns, t.ex. att en order måste vara kopplad till en kund.
106
Vad innebär Data Warehousing och hur går processen till?
Data Warehousing innebär att man samlar in information från hela organisationen för att stödja beslutsfattande.
Processen består av att först hämta data från utvalda affärsområden (data acquisition), sedan lagra och hantera den (data management), och till sist göra den tillgänglig för analys och rapporter (data delivery/analysis).
107
Vad finns det för fördelar/nackdelar med Data warehousing?
+ Samlad överblick över organisationens data.
+ Tillgång till kraftfulla verktyg för att analysera och dra slutsatser från datan.
- Går inte att ändra datan direkt.
- Endast läsning – används enbart för analys och rapportering.
- Data kan vara något inaktuell jämfört med källsystemen.
108
Vad är fokus för ett ERP-system?
Att stödja operativa affärsprocesser i en organisation genom att integrera dem i ett enda system.
109
Hur går processen till vid införande av ERP?
Den börjar med analys av affärsprocesser, följs av reengineering (omstrukturering vid behov), och avslutas med konfiguration av ERP-systemet så att det passar den nya processen.
110
Varför kan det vara svårt att hantera masterdata om man har flera ERP- eller externa system?
När flera system används samtidigt finns det ingen central källa för masterdata, vilket gör det svårt att hålla datan konsekvent utan ett MDM-system.
111
Vad ligger fokuset på inom MDM?
Fokuset inom MDM (Master Data Management) ligger på att förbättra datakvaliteten genom att säkerställa att central data (masterdata) alltid är uppdaterad och konsekvent i hela organisationen.
112
Hur går processen till inom MDM?
Processen inom MDM innebär att man först väljer vilken data som ska räknas som masterdata, därefter harmoniserar informationen mellan olika system, och slutligen integrerar systemen så att masterdata kan hanteras enhetligt och uppdateras centralt.
113
Vad finns det för fördelar/nackdelar med MDM?
+ Möjlighet att integrera nästan alla system, även om de är olika.
+ Transaktionsstöd – det går att uppdatera data via MDM-systemet.
+ MDM-systemet kan sprida ändringar automatiskt till andra system (propagera förändringar).
- De integrerade systemen måste följa en standardiserad informationsstruktur, vilket kan vara svårt att uppnå i praktiken – särskilt om systemen är olika eller äldre.
114
Vilka är de tre olika arkitekturstilarna inom MDM?
Repository - Man samlar all master data i en databas, “repository”.
Registry - Man lagrar endast referenser/nycklar i ett register. För att hämta data använder MDM-registret dessa referenser för att slå upp informationen i källsystemen.
Hybrid Model - Man lagrar den mest frekvent använda datan i MDM-systemet och behåller referenser/nycklar till källsystemen.
115
Vad finns det för fördelar/nackdelar med Repository, registry och MDM hybrid
Repository:
+ Alla system använder samma data så ingen synkronisering behövs.
- Alla system måste ändras för att använda det centrala repositoriet, vilket kan vara svårt – särskilt om man inte har tillgång till källkoden.
- En gemensam datamodell måste skapas som täcker behoven i alla system – detta kan bli komplicerat.
Registry:
+ Befintliga system behöver inte ändras särskilt mycket – det enda som krävs är att de synkroniseras med registret.
- När man vill hämta data måste MDM-systemet slå upp informationen i källsystemen, vilket kan göra det långsamt.
- Komplexiteten ökar ju fler system som kopplas till registret.
MDM hybrid:
+ Vanliga och frekventa dataförfrågningar kan hanteras mycket snabbt, eftersom datan finns direkt i MDM-systemet.
+ Gör det möjligt att hantera flera källsystem med komplex data.
- Det krävs synkronisering av både referenser och den lagrade källdatan, vilket gör hanteringen mer komplex.
116
Ibland behöver man ändra data i huvudkällan, detta kräver att även MDMS behöver uppdatera sin data. Vad finns det för lösningar till detta? Ge även kort beskrivning.
Enkel lösning - Denna lösning låter data bara ändras vid MDMS.
Realistisk lösning - Låt huvudkällan signalera MDM när data ändras.
117
Ibland ändras källdata i MDM, då behöver andra system signaleras om detta. Vilka två sätt går det att göra det på och ge kort beskrivning.
Push - MDMS skickar ett meddelande till alla källsystem som använder datan.
Pull - System kan skicka frågor till MDMS för senaste ändringar.
118
Man brukar säga att det inte finns någon Nu-data då olika system kan ha data från olika tider. Vad finns det för lösning på detta?
Immutable data.
119
Hur fungerar immutable data?
Immutable data är oföränderlig data – när datan väl har skrivits och fått en identifierare, kan den aldrig ändras. Den är alltid densamma, oavsett när eller var den används.
Ex namnet på en person vid ett visst datum
120
Hur fungerar mutable data?
Mutable data är föränderlig data, vilket innebär att dess innehåll kan ändras över tid, även om den har samma identifierare.
