ATiSA H3: Beer Web Store

Størrelse: px
Starte visningen fra side:

Download "ATiSA H3: Beer Web Store"

Transkript

1 ATiSA H3: Beer Web Store Gruppe: Hotel Christer Vindberg, Anders Kabell Kristensen, Bo Sunesen og Anders Viskum , , og {chrisv10, dalko, sunesen, cs.au.dk december 2008

2 Indholdsfortegnelse 1 Software Architecture Beer Web Store Architectural Description - Beer Web Store Quality Attributes Beer Web Store Architectural Design Beer Web Store...11 Performance tactics...11 Availability tactics...11 Layered architectural style...12 Major elements in component and connector structure...12 Connector types Architectural Prototyping Beer Web Store...15 Types of architectural prototyping...15 Choosing programming language/framework...15 Architectural prototype for testability...15 Benefits and liabilities of using ArchJava...16 Service-Oriented Architecture Architectural Evaluation Beer Web Store...18 Beskrivelse af ATAM-processen...18 Identificering af sensitivity points, tradeoff points og risks...20 Fordele og svagheder ved ATAM i forbindelse med Beer Web Store...20 At bruge DiscoTect til evaluering af Beer Web Store...20 Sammenligning af ATAM og architectural prototyping...21

3 1 Software Architecture Beer Web Store Outline how you would approach the tasks of creating the architecture for the BeerWeb Store. Consider, e.g., which steps would you takes and in which order? I den meget simplificerede udviklingsproces som er vist på nedenstående figur undersøges de ønsket krav til systemet. Udviklingsprocessen undersøger både kvalitet og funktionelle krav. Ud fra disse opbygger man så systemets arkitektur krav, som så ledere os til software arkitektur kravene. Hvor ud fra vi kan gå i gang med at implementere et system. Figur 1 : The (Very) Simplified Development Process For at designe vores arkitektur har vi valgt at gøre brug af følgende punkter: Quality attributes: Her vil vi definere både kvalitets og funktionelle krav, og vi vil finde frem til de attributter der er vigtig for vores system, avalibility, security, usability er f. eks nok nogen vi vil fokusere meget på i vores Beer Web Store (BWS), men andre attributter som performance og modifiability vil nok også spille væsentlig rolle. Architectural Description: I dette punkt vil vi beskrive systemets arkitektur, vi vil også definere nogle viewpoints og forkellige views for dem. Efter som systemet kan være kompleks kan det være nødvendigt at have flere forskellige views. Vi vil nok også lave nogle tegninger over de forskellige views for at øge forståelsen. Architectural Design: Her vil vi designe de forskellige elementer og relationerne mellem disse, dette design skal opfylde de fundne kvalitets attributter. Vi kan her evt. også ligge os fast på et eller flere patterns som vi ønsker at gøre brug af. Architectural Evaluation: Her vil vi evaluere den fundne software arkitektur. Vi kunne f. eks vælge at strukturere vores evaluering som en Quality Assurance Workshop (QAW) som beskrevet i [Bass et. al. 2003] eller bruge ATAM [Kazman et al. 2000]. I begge disse scenarier vil vi nok ikke udføre alle skridt men tilpasse dem til vores ønsker og interesser. Vi vil nok udføre punkterne i den listet orden, men det kan meget vel være nødvendigt at besøge nogen af dem igen. Så en iterativ proces over punkterne er nok den bedste løsning.

4 Relate the definition of software architecture in [Bass et al., 2003] to the elements of your design as outlined above. Give concrete examples of elements, relations, and structures. Strukturen er vores lagdelte Client - Server arkitektur, som består af elementerne Client, Server og Database. Relationen mellem Client og Server er et web-baseret request/response pattern mens relationen mellem Server og Databasen følger Facade pattern et. De eksterne synlige egenskaber for Databasen er dem der er synlige gennem Facaden. Som en konsekvens af den lag delte struktur er klientens egenskaber ikke synlige for serveren, og serverens egenskaber kan heller ikke tilgås fra databasen. Apply [Perry and Wolf, 1992] s model of software architecture as Software Architecture = {Elements, Form, Rationale} to the Beer Web System I artiklen deler de elementerne op i 3 kategorier: processsing, data og connecting. Processing er transformationer af data, data er information der kan blive ændret på og connecting er den måde vi forbinder de forskellige elementer i arkitekturen på. Vi definere Client, Server, Database, Client - Server relationen og Facade relationen til at være elementer i systemet. Databasen er et Data element da det eneste den skal er at send og modtag data. Server, Client og Facade er Processing elementer da de har til opgave at processer den information de modtager også at sende den videre. Forbindelsen mellem Client og Server er vores Connection element som bruger en form for internet kommunikation til at kommunikere over. Form beskriver de relationer der binder systemet sammen, i BWS s tilfælde er det vores Client Server relationen der tydeligvis er en rationale for systemet, da det er et krav at vores BWS system fungere på tværs af internettet. Da facade pattern et abstrahere den konkrete database kunne det meget vel tyde på at abstraktion af databasen også er et rationale for systemet. Discuss how the intentionality/locality thesis relates to the example Den givne specifikation for vores BWS er bevidst, da den ikke beskriver en specifik implementering, men bare en general arkitektur. Denne arkitektur kan man implementere på mange forskellige måder. Lokaliteten for arkitekturen er non-local, da vi sagtens kan tilføje elementer til den nuværende struktur der vil bryde strukturen. Vi kan f. eks tilføje et element der muliggøre kommunikation op i gennem vores lag og derved bryde den lag delte struktur vi har i vores BWS system. Reflect on what happens if the words software and computing are removed from the definition of software architecture in [Bass et al., 2003] Hvis vi fjerne de to ord bliver definitionen meget mere general. Den kan nu bruges på et hvert system, hvilket gør definitionen meget bred. Det er nu mere en general beskrivelse af at der kan identificeres som elementer og egenskaber. Selvom man nok kan beskrive et hvilket som helst system på denne måde, er det ikke sikkert at det er ønskværdigt. Der er situationer i den rigtige verden og sikkert også nogen i den digital, hvor man sikker godt kan beskrive den på denne måde. Men det vil nok være mere praktiske og hensigtsmæssigt at gøre det på en anden.

5 The architect decides to create a full architecture description before embarking on any implementation of the system. Discuss pros and cons of taking that approach I software arkitektur er tid ofte en af de vigtigste ting for stakeholders, ofte vil stakeholders gerne have produktet/systemet ud på markedet så hurtigt som muligt, et for at sikrere at andre ikke frigiver et lignende produkt og for det andet for at de kan begynde at promovere produktet og potentielt tjene penge på det. Så selvom man nok for et bedre og mere stabilt produkt ved at finpudse arkitekturen, så koster det flere penge og kan gøre udviklingsprocessen længere. Modsat er der også problemer med at frigiver et ufærdig eller ikke ordentlig gennemtænkt produkt, da det meget vel kan øge maintenance, ikke ordentligt supportere modifiability, produktet kan have problemer med performance, og hvis der er bugs kan det påvirke avalibility. Valget af hvad man gør, afhænger af hvad stakeholders krav til systemet er. Der er dog vigtigt at man ittrere hen over processen og ikke bare løser den slavisk trinvis. Det er f. eks vigtigt at man bliver klar over om de valgte kvalitets attributter er mulig at implementere, enten teoretisk eller inden for den givne tidsramme.

6 2 Architectural Description - Beer Web Store Which structures does a system such as the above exhibit? Give examples of elements and relations pertaining to each structure Ifølge [Bass et al., 2003] er en arkitektur-struktur en samling af elementer og deres forbindelser. Et view er en repræsentation af en sådan struktur. Artiklen beskriver også hvordan systemer ofte er alt for komplekse til at beskrive og forstå på en gang. En beskrivelse af et system består derfor af flere views, der hver repræsenterer en bestemt struktur i systemet. Som vist på tegningen i opgaven består Beer Web Store systemet af et antal brugere, en webserver og en database. Der er ikke specificeret noget viewpoint, og vi ved derfor ikke præcist hvordan tegningen skal analyseres. Et viewpoint er en generel måde at lave et view på og specificerer altså hvilken struktur man har valgt at beskrive et view med. [Bass et al., 2003] har lavet tre inddelinger af disse strukturer: Module: Fokuserer på implementationdelen af systemet. Et system kan være delt op i et antal moduler, der logisk adskiller forskellige dele af systemet. Disse moduler kan deles om i mindre komponenter/moduler. Der er altså tale om en beskrivelse af de statiske dele af systemet. Component and Connector: Fokuserer på de elementer der eksisterer når systemet afvikles. Allocation: Fokuserer forskellige software elementer i forhold til det environment det afvikles i. I Beer Web Shop kan man vælge at tolke systemet sådan at der findes tre hoved elementer; brugere, webserver og databasen. Her vil webserveren og databasen være modulopbygget. Hvert af disse moduler definerer en afgrænset rolle/opgave. Webserveren er i dette tilfælde delt op i tre undermoduler (decomposition), der hver afgrænser bestemte opgaver indenfor webserverens opgaver. Brugerene kan ses som værende en del af environmentet. Dvs. at de ville høre en under strukturen Allocation. Which viewpoints are relevant when describing the example? Give examples of partials views for each viewpoint For at gøre tegningen i opgaven mere sigende, kunne man vælge at bruge viewpoints. Her ville et sekvensdiagram eksempelvis kunne illustrere hvordan brugerne interagere med systemet og hvordan kommunikationen mellem webserveren og databasen foregår. Her ville et deploymentdiagram (allocation viewpoint) hjælpe med til at beskrive de konkrete valg af database og webserver. For at beskrive skrukturen af webserveren yderligere, kunne module viewpointet bruges. Her kunne der gives en uddybning af hvordan webserveren er delt op (udover "overview", "basket" og "data") i forskellige moduler og klasser. Dette ville give et større indblik i hvordan den statiske struktur af systemet ville se ud. Til sidt ville et C&C viewpoint kunne føre til forskellige views, der beskrev flowet i systemet.

7 Argue for benefits and liabilities of describing software architecture via a boxand-line drawing such as the above Tegningen i opgaven er en såkaldt box-and-line tegning. Her er fokus ikke nogen dybere indsigt i systemet eller strukturen, men derimod at give overblik. Der bliver ikke fulgt nogen fast standard i udarbejdelsen af en sådan tegning. Fordelen er at der ikke kræves nogen særlig (computer-) forståelse når en sådan tegning skal diskuteres mellem flere parter. Her vil alle kunne være med til at diskutere. Dette ville højst sandsynligt ikke være tilfældet hvis man diskuterede views ud fra eksempelvis allocation viewpoint. Ulempen er selvfølgelig at en sådan tegning ikke er ret konkret og specielt sigende når man kommer udover en generel diskussion af systemet. Discuss how architectural reflection could be used on the final running system Når et system er færdigudviklet er det selvfølgelig interessant at se på om den oprindelige arkitekturbeskrivelse stemmer overens med det færdige system. Ved at bruge refleksion kan man danne en arkitekturbeskrivelse ud fra et færdigudviklet system. Her vil den statiske del kunne genereres via UML-programmer direkte ud fra source-koden. Hvis man ønsker sekvens diagrammer skal man selvfølgelig analysere programmet mens det kører. Det samme gør sig gældende med views lavet ud fra C&C viewpointet. Til sidst vil man så kunne sammenholde de to arkitekturbeskrivelser og se om de er ens. Discuss what architectural description would be needed if the system was to be written using ArchJava Her ville man skulle opdele systemet i component and connectors, dvs. ud fra C&C viewpointet. Samtidig skal alt kommunikation der sker mellem de forskellige connectors beskrives. Når dette er gjort kan man begynde implementationen i ArchJava.

8 3 Quality Attributes Beer Web Store Describe technique(s) for architectural requirements capture that are applicable to the above case I dette kursus har vi anvendt Bass et al. måde at beskrive kvalitet på. Her anvendes betegnelsen kvalitetsattributter, der beskriver kvalitative egenskaber ved et system. Bass et al. mener at følgende seks kvalitetsattributter er de vigtigste. Availability Modifiability Performance Security Testability Usability For at kunne anvende ovenstående attributter giver Bass et al. en måde at beskrive disse på; Kvalitetsscenarier. Disse anvendes til at repræsentere de forskellige krav. Give feasible architectural requirements for availability and performance for the Beer Web Store using such techniques (at least one for each quality attribute) Til Beer Web Store har vi lavet følgende scenarier: Performance Source Stimulus Artifact Enviroment Response Response Measure Databasen får 100 forespørgsler på et sekund. Internt Webserver kommer med dataforespørgsel System Normal Databasen returnerer de ønskede oplysninger En forespørgsel svares på 1/100 sekund

9 Performance Source Stimulus Artifact Enviroment Response Response Measure brugere tilgår webserveren i timen Eksterne brugere Sidernes indhold sendes tilbage til brugerne System Normal Siderne sendes/vises til brugerne En bruger skal have vist sin side indenfor 2 sekunder Avalibility Source Stimulus Artifact Enviroment Response Response Measure Databasen er blevet utilgængelig Intern Databasen har ikke svaret indenfor en fastlagt tidsperiode System Normal Ansvarshavene underrettes Backupserver tilsluttes indenfor 2 min. Argue how tactics and/or styles may be used to resolve the requirements Tactics beskriver hvordan bestemte kvaliteter opnås. Ved performance er målet at give svar på en forespørgsel inden for en given tid. Der er flere faktorere der spiller ind når man snakker om performance. Eksempelvis vil resourceforbruget have indvirkning. Resourcer kunne være CPU, hukommelse, plads på disk, båndbredde mm. Herudover er blokkeringer af resourcer også en faktor der spiller ind. Man vil f.eks. kunne komme ud for at vente på en ressource hvis en anden forspørgsel er i gang med at skrive til den. Sandsynligheden for at sådanne situationer opstår stiger i takt med at der kommer forespørgsler til ressourcen og tiden det tager at behandle en sådan forespørgsel. Dvs. problemet kan reduceres ved at gøre behandlingstiden mere effektiv. Dette kan gøres ved f.eks. benytte bedre algoritmer. I Availability er målet at undgå at fejl opstår og i tilfælde af at de gør, få dem rettet. Her deles taktikkerne op i forskellige kategorier; Fault Detection, Fault Recovery og Fault Prevention. I Fault Detection taktikken har man metoder til at se om der er noget galt. Dette kan f.eks. ske ved jævnligt at sende heartbeat signaler ud, der indikerer at serveren er i live. På samme

10 måde kunne der også kommunikeres ved ping/echo i faste tidsintervaller for at holde øje med om serveren var i live. Disse to taktikker opererer i forskellige processer. Hvis der er tale om komponenter i én proces, kan man bruge exceptions til at fange fejl. Ved Fault Recovery prøver man at forberede/lave et repair af systemet. Bass et al. beskriver flere måder at gøre dette på. Ved Voting-taktikken stemmer flere processer om hvad outputtet fra en algoritme er. Denne information sendes til en voter. De processer der ikke er enige med de andre markeres som fejlbehæftet. I Shadow Operation kan en proces der tidligere have fejlet køres i skygge. Her prøver processen at efterligne en normal proces før den igen selv bliver en aktiv service. Fault Prevention. Her kan man igen bruge forskellige taktikker. Removal from Service fjerner komponenten fra systemet for at undgå at den forventede fejl opstår. I Process Monitor kan man have en proces der overvåger andre processer. Hvis en fejl opstår slås processen ihjel og et nyt instans oprettes. Discuss where Service-Oriented Architecture can play a role with respect to the Beer Web Store? Consider the quality implications Nogle funktioner i Beer Web Store vil sagtens kunne flyttes ud af huset. F.eks. vil betalingsdelen af Beer Web Store godt kunne flyttes til et eksternt sted. Her skal man selvfølgelig være sikker på at det ikke går ud over ens kvalitetsattributter. På den anden side vil visse funktioner i Beer Web Store også kunne bruges af andre. Man kunne igen forestille sig betalingsdelen og f.eks. Basket delen af webserveren. Begge kunne være self contained og samtidig opfylde de to krav om at være Stateless og Context Independent. Reflect upon what the role of quality attributes in software architecture is Forskellige deltagere i en udviklingsproces har ofte mange forskellige holdninger til hvad kvalitet er. Det er da også rimelig klart at en udvikler ikke altid vil definere kvaliteten af noget software på samme måde som eksempelvis en grafiker. De kvalitetsattributter vi har kigget på, forsøger at lave en standard for hvordan kvalitet i software skal opfattes. Ved at have en sådan standard skulle det være muligt at træffe fælles beslutninger og konklusioner i forhold til hvilke kvaliteter der er vigtige i det konkrete system.

11 4 Architectural Design Beer Web Store Performance tactics Der er ifølge [Bass et al., 2003] tre kategorier af performance taktikker: Resource Demand Til det givne scenarie giver det mest mening at bruge taktikkerne increase computational efficiency og reduce computational overhead. Alternativt kan man prøve at reducere antallet af events der skal processeres, men da det er brugeren der styrer hvor mange events der kommer til systemet, ville det resulterer i at nogle events blev ignoreret, hvilket ville være meget uheldigt. Taktikken er altså at forbedre de algoritmer man bruger til at håndtere brugerens input, der består af betalingsoplysninger i det konkrete scenarie, samt minimere overhead i forbindelse med processeringen af disse input. Man skal dog være opmærksom på at hvis man reducerer overhead ved at fjerne abstraktionslag, hvilket medfører tab i modifiability. Resource Management Den nemmeste taktik at bruge her er increase available resources, men denne taktik har en klar ulempe; det koster penge. Desuden tilføjer den ikke nogen skaleringsmuligheder, hvis der kommer for mange samtidige brugere af systemet må man i ud og investere i endnu dyrere hardware. Det vil formegentlig være billigere at bruge de to andre nævnte teknikker til resource management: Introduce concurrency og maintain multiple copies of either data or computations. Det er dog vigtigt at man holder styr på sine kritiske regioner, og sikrer at man ikke for eksempel sælger en vare som lagervare hvis den i virkeligheden er udsoglt. Resource Arbitration Denne kategori omhandler scheduling, og der kan være fordele at hente ved at prioritere requests forskelligt, hvis krav til processeringstid ikke er proportional med den forventede processeringstid. Man kan for eksempel have et andet request end det i scenariet hvor den forventede processeringstid er lavere end det der er givet i scenariet, men kravet til processeringstiden af dette request er længere end de 10 sekunder fra scenariet; i dette tilfælde vil man kunne prioritere scenariets request højere, og på den måde tilfredsstille de ønskede krav. Availability tactics Der er ifølge [Bass et al. 2003] tre kategorier af availability taktikker: Fault detection Man kan gøre brug af alle tre taktikker fra [Bass et al., 2003] (ping/echo, heartbeat, exceptions) på følgende måde: Betalingsservicen kommunikerer med webserveren jævnligt; enten fordi den rent faktisk sender et heartbeat eller fordi den sender en log over aktivitet eller lignende, der så anvendes som heartbeat. Hvis webserveren opdager at der er gået for lang tid siden sidste heartbeat, kalder den en intern metode i webserverens fault detection system, der så sender et ping til servicen. Hvis servicen ikke returnerer et echo til det afsendte ping indenfor rimelig tid, kaster fault detection systemet en exception.

12 Fault recovery Den taktik der er lagt op til er at en administrator kontaktes og retter fejlen. Hvilket ikke har så meget med de taktikker der er angivet i [Bass et al., 2003] at gøre. Alle de taktikker der er angivet i [Bass et al., 2003] er forskellige grader af redundancy, på nær checkpoint/rollback. Checkpoint/rollback taktikken ville være meget passende til et betalingssystem, idet at hvis der går noget galt under en bataling, skal man sikrer sig at når betalingsservicen reintroduceres til systemet, så er der foretaget rollback til før eventuelle igangværende/ufærdige transaktioner. Fault prevention Der er i scenariet lag op til at anvende taktikken removal from service; hvis betalingsservicen går ned, kan man altså ikke fortaget et checkout af de varer man har tilføjet sin indkøbskurv, før betalingsservicen er reintroduceret, dette gøres for at undgå at yderligere fejl opstår i interaktionen med en defekt eller ikke-eksisterende betalingsservice. Taktikken transactions kan også anbefales, af samme grunde som checkpoint/rollback taktikken. Layered architectural style En layered architectural style medfører modifiability, idet et lag kun kommunikerer med det over-/under-liggende lag. Den modifiability taktik der bruges kaldes i [Bass et al., 2003] restrict communication paths. Desuden vil det i implementationen af den lagdelte arkitektur være oplagt at anvende flere modifiability taktikker som maintain semantic coherence, hide information, maintain existing interfaces og use an intermediary. Generelt set går en lagdelt arkitektur imod performance taktikken reduce computational overhead, da man ved at afgrænse kommunikationen vil komme til at forlænge den. Major elements in component and connector structure

13 Components og deres ansvar Database Persistent lagring af information omkring varer, for eksempel: antal, pris, URL til billede, beskrivelse Persistent lagring af ordrer Lagerstyring Varernes repræsentation på webserveren Holde styr på reserverede varer Opdatering af produktkataloger i tilfælde af reserverede eller solgte varer Opdatering af database i tilfælde af nye ordrer Produktkatalog Indkøbskurv Startpunkt for interaktion med brugeren Præsentation af de tilgængelige varer Udvælgelse af varer til indkøbskurv Holde styr på de varer kunden vil købe Præsentation af de varer kunden vil købe Fjerne varer fra indkøbskurv Betalingsservice Indsamle betalingsoplysninger Gennemføre betaling af ordre Annullere ordren hvis brugeren fortryder Connectors Når webserveren starter indhenter lagerstyringen information fra databasen via SQL query Et nyoprettet produktkatalog indhenter oplysninger omkring varer fra lagerstyring i XML Produktkataloget sender forespørgsler til lagerstyringen om at reservere en vare som kunden vil købe Lagerstyring er subject og produktkataloger er observer i et observer pattern, hvor der observeres på antalet af de enkelte varer Produktkataloget er producer og indkøbskurven er consumer af varer som kunden vil købe Produktkataloget og indkøbskurven kan overføre kontrol af brugergrænseflade til hinanden Indkøbskurven er subject og betalingssystemet er observer i et observer pattern, hvor der observeres på prisen af den aktuelle ordre Indkøbskurven og betalingssystemet kan overføre kontrol af brugergrænseflade til hinanden

14 Betalingsservice informerer indkøbskurven om at betalingen er gennemført Betalingsservice informerer indkøbskurven om at ordren er fortrudt Indkøbskurven er producer og produktkataloget er consumer af varer der er fortrudt Indkøbskurven er producer og produktkataloget er consumer af ordrer der er betalt Produktkataloget er producer og lagerstyringen er consumer af varer der er fortrudt Produktkataloget er producer og lagerstyringen er consumer af ordrer der er betalt Lagerstyringen sender databaseopdatering til databasen via SQL update Connector types Ved at brug connector types kan man opnå større modifiability, idet koden bliver delt op i mindre bider med semantic coherence. Prisen for denne modifiability er, som det ofte er tilfældet, performance på grund af computational overhead.

15 5 Architectural Prototyping Beer Web Store Types of architectural prototyping I [Christensen and Hansen, 2008] er architectural prototypes delt op i tre kategorier: Exploratory Denne type af prototyper er beregnet til at finde frem til forskellige arkitektoniske løsninger, da der allerede er fastsatte rammer (deployment strukturen) for arkitekturen er denne type mindre relevant, men kan stadig bruges til at udforske forskellige arkitektoniske valg indenfor de fastsatte rammer; for eksempel om man kan bruge et observer pattern til at holde browseren opdateret i tilfælde af ændringer så som en udsolgt vare. Experimental Denne type af prototyper er beregnet til at at måle og evaluere en arkitektur. Det ville være oplagt at anvende en experimental prototype til at vurdere om den angivne deployment arkitektur er fornuftig. Evolutionary En evolutionary prototype er en prototype som man iterativt modificerer, i håb om at forbedre den. Et prototype forløb kunne for eksempel være at have bygget exploratory prototyper, og kommet frem til en fornuftig arkitektur indenfor de rammer deployment strukturen angiver. Herefter har man udviklet en lidt tungere experimental prototype. Efter at have målt på denne og vurderet at arkitekturen lever op til de kvalitetsattributter der er stillet op har man iterativt videreudviklet denne experimental prototype via evolutionary prototyper, og kommet frem til en endelig arkitektur. Choosing programming language/framework Man kan bygge en ekperimental prototype i begge sprog og måle på prototypens kvalitetsattributter. Disse måldte kvalitetsattributter sammenholdes med de ønskede kvalitetsattributter for systemet, og ud udfra denne sammenholdning kan man så vælge programmeringssprog. Architectural prototype for testability I [Bass et al.] er der nævnt fire taktikker til testability: Record/playback Via en arkitektonisk prototype kan man undersøge muligheden for at bygge arkitekturen op så den understøtter at man kan optage den information der under kørsel bliver sendt fra en component over connector(s) til et andet component. Hvis man kan: Optage information der kommer som input til en komponent Optage den information der efterfølgende kommer som output Afspille optaget input til komponenten Så kan man skifte implementationen af en komponent ud, og sikre at den information der bliver optaget som output ikke er uhænsigtsmæssigt ændret siden det sidst optagede output.

16 Seperate interface from implementation Ved at lave en arkitektonisk prototype der helt konkret specificerer de interfacesc som implementationen skal opfylde sikrer man at man kan skifte implementationen af komponenter ud, og komponenten vil stadig kunne tale med andre komponenter, uden at skulle modificere disse. Dette gør også at man kan udskifte komponenter med stubløsninger, for at have fuld kontrol over komponentens handlinger. Specialize access routes/interfaces Specialized access routes/interfaces specificeres i den arkitektoniske prototype, så de ikke bliver glemt under implementationen. Build-in monitors Build-in monitors er ikke så egnet til at blive udforsket i en arkitektonisk prototype, da det handler om at aflæse tilstande internt i en komponent. Disse tilstande vil ofte ikke være til stede i de stub implementationer man benytter sig af i en arkitektonisk prototype. Benefits and liabilities of using ArchJava Benefits I ArchJava vil det være muligt at specificere opførelsen af connectors mere præcist, så man ved præcis hvilken type information der kan komme over en connector, or dermed sikre at alle disse typer kan testes jævnfør en eller flere af taktikkerne overnfor. I exploratory prototyping vil det være muligt at skifte connectors ud, for at afprøve hvilken effekt det har på de ønskede kvalitetsattributter; testability i denne case. Liabilities Der er ummiddelbart tre ulemper ved at bruge ArchJava: Det tager længere tid at udvikle Det medfører et computational overhead, og dermed performance tab og usikkerheder, hvilket medfører at man ikke kan regne med sine performance test. Hvis ikke implementationen skal være i ArchJava, skal de connectors der er specificeret i prototypens connectors oversættes til et andet programmeringssprog hvilket kan medføre nye fejlkilder.

17 Service-Oriented Architecture På slidesne fra forelæsningen om SOA er følgende guidelines for services beskrevet: Self-contained Service should have coarse-grained functionality Context-independence Service should not depend on other services Stateless Aka loose coupling Service should not retain client state between invocations Ved at benytte en service-oriented architecture opnår man et meget højt niveau af modifiability, idet man opfylder modifiability taktikker som maintain semantic coherence, generalize the module, hide information, maintain existing interfaces og ikke mindst runtime registration. Desuden vil det medfører at man kan samarbejde med andre webservices hvis det skulle være ønsket, også kaldet interoperability. Ulemper Som så ofte, er ulempen ved modifiability en risiko for at computational overhead bliver stort, hvilket vil medføre et performance tab.

18 6 Architectural Evaluation Beer Web Store Beskrivelse af ATAM-processen Architecture Tradeoff Analysis Method (ATAM), er et værktøj til at evaluere en arkitektur. Først og fremmest er ATAM et middel til at få indsigt i, hvorvidt den pågældende arkitektur opfylder forskellige kvalitetsmål, men den giver desuden et billede af, hvilke sammenhænge der er, disse kvaliteter imellem. Vi vil her antage, at læseren har kendskab til ATAM og blot opridse hvert trin i processen, som beskrevet i [Kazman et al., 2000]. På samme tid vil vi løbende forsøge at påpege, hvordan den kan benyttes til at evaluere Beer Web Store-systemet (BWS). Vi ved ikke meget om denne, men i og med at ATAM benyttes til at evaluere en arkitektur, bliver vi nødt til at antage, at der allerede eksisterer et forslag til én. Step 1 Present the ATAM Her klargøres selve metoden for alle de deltagende parter, ved en orientering fra de folk der leder processens afvikling, samt mulighed for at deltagerne kan stille spørgsmål. Dette indebærer både en præsentation af de ni forskellige trin i processen, en beskrivelse af de teknikker der benyttes (f.eks. utility tree generation), samt en beskrivelse af det forventede resultat af processen (f.eks. de tradeoffs, der identificeres). For Beer Web Store, kunne man forestille sig, at deltagerne ville bestå af en arkitekter (som typisk afvikler ATAM), projektledere, forretningsfolk, udviklere, driftstab og kommende kunder/brugere. Step 2 Present Business Drivers Målet med dette trin er at sikre, at alle deltagere har en ordentlig forståelse for det overordnede mål med systemet. Dette foregår igennem en beskrivelse, der foretages af projektlederen. Denne beskrivelse har en forretningsorienteret vinkel og kan blandt andet klargøre ting som; hvordan ser markedet ud, hvem er interessehavere i projektet, hvad er tidsbegrænsningerne, hvad er kundernes behov, hvad er budgettet, hvad er det tekniske fundament og begrænsninger, hvilke kvalitetsattributter skal der tages hensyn til og hvorfor. Her kunne projektlederen udover de ovennævnte ting f.eks. præsentere allerede eksisterende alternativer på markedet. Desuden ville de kvalitetsattributter der er nævnt i opgaveformuleringe, nemlig performance og modifiability, blive bragt på bane. Her ville main use case også blive fremlagt. Step 3 Present Architecture Her vil softwarearkitekten give en præsentation af arkitekturen. Denne er selvfølgelig direkte afhængig af, hvilke beslutninger der hidtil er taget om systemets arkitektur. Som en del af dette trin bidrager deltagerne desuden, ved at definere yderligere arkitektonisk information om systemet, som skal tages op til overvejelse i analysen. De dele af arkitekturen der dækkes, omfatter; tekniske begrænsninger helt ned til hardware-niveau, andre systemer som det pågældende system skal gøre brug af, samt de arkitektoniske tiltag der allerede er blevet overvejet til at imødekomme de opstillede kvalitetsmål. Vi ved ikke meget om arkitekturen for Beer Web Store, men i dette trin ville arkitekten præsentere sin deployment structure. Da web-serveren er en helt central komponent, ville det være naturligt, at diskutere den arkitektoniske struktur for denne og samspillet med de andre komponenter. Browser og database ville ikke kræve så meget tid, da de er temmelig veldefinerede, men man ville også diskutere valget af payment service man kunne forestille sig at dette ville være et eksternt system,

19 som BWS skal kommunikere med. Step 4 Identify Architectural Approaches Her identificeres de Architectural Approaches og Architectural Styles, der definerer de vigtige strukturer i systemet. Dette er vigtigt, fordi det er dem, der skal sikre at de krav og forventninger der er til systemet overholdes. For BWS-systemet ved vi som sagt ikke så meget konkret, men det ville f.eks. blive identificeret, at vi bruger client-server arkitektur og ikke eksempelvis en layered arkitektur. Step 5 Generate Quality Attribute Utility Tree I dette trin benytter man et Utility Tree til at finde ud af, hvilke kvalitetsattributter der ligger til grund for de væsentligste kvalitetsmål. Når de er blevet identificeret, prioriteres og forfines de og der genereres kvalitetsscenarier til at repræsentere de højest prioriterede. På denne måde indskrænkes antallet af områder, hvor resten af processen skal fokusere, til de vigtigste. Dette er essentielt, fordi det hjælper alle deltagerne til at opnå en form for konsensus, så de kan arbejde sammen, i stedet for at fokusere på deres personligt højest prioriterede områder. Dette handler altså udelukkende om at fastslå indsatsområder og ikke om at analysere systemet for at finde de arkitektoniske løsninger på problemstillingerne. Det utility tree der ville blive genereret her, ville give os nogle højt prioriterede scenarier, der ville afspejle de nævnte quality attributes, performance og modifiability. Ikke nødvendigvis de eneste, men vi ved fra opgaveformuleringen at de er vigtige, så man må antage, at i hvert fald nogle scenarier ville indfange disse. Step 6 Analyze Architectural Approaches Her benyttes kvalitetsscenarierne fra trin 5 til, igennem en dybdegående analyse, at finde frem til mulige Architectural Approaches og Styles for systemet. Resultatet er altid en liste af disse vigtige arkitektoniske beslutninger, men man sørger også for, på samme tid, at identificere en række risks (og non-risks), sensitivity points og tradeoff points. Samtidig sørger man for, på en struktureret måde, at dokumentere resultaterne igennem Architectural Approach Descriptions. Resultatet af dette vil blive præsenteret senere i afsnittet om Identificering af sensitivity points, tradeoff points og risks. Step 7 Brainstorm and Prioritize Scenarios I dette trin af ATAM-processen genereres der en række nye scenarier, igennem en brainstorming, foretaget af alle deltagere. Der søges to typer af scenarier, nemlig use case scenarios og change scenarios. Change scenarios kan opdeles i to kategorier; growth scenarios, som benyttes til at forudsige systemets styrker og svagheder i situationer hvor det udsættes for moderate ændringer, som f.eks. ændring af den underliggende platform, og exploratory scenarios, som benyttes til at beskrive situationer hvor systemet udsættes for drastiske ændringer, som f.eks. en omstrukturering af infrastrukturen. De forskellige scenarier prioriteres igennem en afstemning blandt deltagerne. For BWS ville man kunne finde begge typer af scenarier. Use case scenarier ville nok hovedsagligt beskæftige sig med brugerens oplevelse og have kvalitetsattributter som performance og (mindre arkitektonisk) usability i højsædet, mens change scenarier f.eks. kunne omhandle udvidelse af server delen, således at systemet ville kunne håndtere mange flere brugere, måske ved at lade flere servere dele arbejdet, i stedet for som deployment diagrammet antyder kun at have én.

20 Step 8 - Analyze Architectural Approaches Her foretages, i bedste fald, endnu en iteration af trin 6 og altså en knytning imellem hvert scenarie og en af de Architectural Approaches, som tidligere er blevet identificeret i systemet. Hvis det er tilfældet, at der ikke kan findes et arkitektonisk tiltag, som varetager det givne scenarie - hvilket betyder at vi i trin 7 har fundet et scenarie, som ingen af vores Architectural Approach Descriptions indfanger - så skal vi helt tilbage til trin 4 og gennemgå proceduren endnu en gang, indtil vi når til trin 8, uden at afsløre nogen problematiske brist i den samling af arkitektoniske tilgangsvinkler vi har samlet sammen. Her ville man, som sagt, i bedste fald ikke opdage noget nyt. Step 9 Present Results Her foretages en grundig rapportering af resultaterne fra hele processen. Identificering af sensitivity points, tradeoff points og risks Sensivity points Sensitivity points gør det klart, hvor der skal lægges særlig fokus, for at opnå et kvalitetsmål. Et eksempel kunne være, kommunikationen mellem serveren og de andre komponenter. Dette er et sensitivity point, der er væsentligt for at nå målet om modifiability og performance. At gøre det nemt at udvide (modify) systemet til at benytte mange servere, for at opnå bedre responstider (performance). Tradeoff points Et tradeoff point er et punkt, hvor man ved at varetage ét kvalitetsmål, tilsidesætter et andet. Lad os sige at man lavede en meget specifik implementering af kommunikationen mellem server og database, som er spredt rundt i hele server-implenteringen, med det mål at gøre kommunikationen hurtig, så tilgodeser man performance, men på samme tid tilsidesætter man modifiability, fordi det bliver meget sværere at skifte til en anden database. Havde man i stedet lavet et lag / interface imellem disse to komponenter, ville man situationen være omvendt. Fordele og svagheder ved ATAM i forbindelse med Beer Web Store Fordelen ved at bruge ATAM til at evaluere arkitekturen af Beer Web Store er begrænsede. ATAM er en langsommelig process, der kræver mange involverede, men kan til gengæld identificere nogle vigtige indsatsområder. Dog er BWS et forholdsvist simpelt system og måske ville tiden være givet bedre ud med andre evalueringsmetoder. At bruge DiscoTect til evaluering af Beer Web Store DiscoTect benyttes jo til at overvåge systemets runtime adfærd. I forbindelse med BWS-systemet, kunne man f.eks. benytte DiscoTect til at sikre, at tilgangen til databasen kun sker fra nogle bestemte software-komponenter i web-server-delen.

21 Sammenligning af ATAM og architectural prototyping ATAM er en mere teoretisk analyse, hvor man finder potentielle risici og beslutter hvilke arkitektoniske metoder, der er passende til det givne system. Derimod kan man med prototyping lave faktiske tests på systemet og finde ud af om der virkelig er tale om en risiko eller hvornår man når en grænse for hvad systemets arkitektur kan klare. Det idelle er kombinationen af de to metoder, hvor man først kunne lave en ATAM til at finde sensitivity points osv., for dernæst at lave prototypen til at teste dem. Når man tager Beer Web Store-systemets størrelse i betragtning, er det ikke sikkert at det vil være tiden og pengene værd at benytte en ATAM, men i stedet få nogle hurtige prototyper op i stedet. BWS er et forholdsvist simpelt system, der ideelt skal kunne håndtere mange brugere. Derfor ville de stress-tests som prototyping giver mulighed for være meget værdifulde.

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF) Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Framework (TOGAF) Otto Madsen Director of Enterprise Agenda TOGAF og informationsarkitektur på 30 min 1. Introduktion

Læs mere

Hand in H6. Software Architecture in Practice. Book Swap Case

Hand in H6. Software Architecture in Practice. Book Swap Case Hand in H6 Software Architecture in Practice Book Swap Case Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N, Denmark Gruppe: Bravo 20074842, Lars Kringelbach, lars@kringelbach.com

Læs mere

WINDCHILL THE NEXT STEPS

WINDCHILL THE NEXT STEPS WINDCHILL THE NEXT STEPS PTC/user, 4. marts 2015 Jens Christian Jensen, Econocap Agenda Windchill the next steps Bliv opdateret og inspireret til at se hvor Windchill kan hjælpe dig med andet end blot

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

Projektledelse i praksis

Projektledelse i praksis Projektledelse i praksis - Hvordan skaber man (grundlaget) for gode beslutninger? Martin Malis Business Consulting, NNIT mtmi@nnit.com 20. maj, 2010 Agenda Project Governance Portfolio Management Project

Læs mere

Bilag 2 og 3 og værktøjer

Bilag 2 og 3 og værktøjer Bilag 2 og 3 og værktøjer Lars Erik Storgaard Geodatastyrelsen, laers@gst.dk Program for workshop Geodatastyrelsen Formål hvorfor workshop? Kvalificering af listen over myndigheder Temakammerater Opmærksomhed

Læs mere

Da beskrivelserne i danzig Profile Specification ikke er fuldt færdige, foreslås:

Da beskrivelserne i danzig Profile Specification ikke er fuldt færdige, foreslås: NOTAT 6. juni 2007 J.nr.: 331-3 LEA Bilag A danzig-møde 15.6.2007 Opdatering af DAN-1 og danzig Profile Specification Forslag til opdatering af Z39.50 specifikationerne efter udgivelse af Praksisregler

Læs mere

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 Security as a Service hvorfor, hvornår og hvordan Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 SecaaS hvorfor, hvornår og hvordan hvad Hvorfor.. Hvornår.. Hvordan.. Disclamer: Dubex er MSSP og leverer

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

Availability og reliability i softwarearkitektur

Availability og reliability i softwarearkitektur Availability og reliability i softwarearkitektur Gruppe 2 Jørgen Vrou Hansen 20042728 Marjus Nielsen 20064684 Said Shah Alizadeh 19963592 19. marts 2010 Abstract Dette papir omhandler arkitektoniske discipliner

Læs mere

Hvor er mine runde hjørner?

Hvor er mine runde hjørner? Hvor er mine runde hjørner? Ofte møder vi fortvivlelse blandt kunder, når de ser deres nye flotte site i deres browser og indser, at det ser anderledes ud, i forhold til det design, de godkendte i starten

Læs mere

CASE: Royal Copenhagen

CASE: Royal Copenhagen When Your Website Goes Shopping CASE: Royal Copenhagen v/mads Gustafsen & Line Ghisler, Creuna Sitecoreseminar 6. februar 2008 CASE Royal Copenhagen præsenteret af Creuna Royal Copenhagen Kongelig Hofleverandør

Læs mere

Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer?

Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer? Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer? Christian Eilskov Sales Engineer, christian_eilskov@dell.com +45 40 60 13 92 Dell Cloud Client Computing Dell lever produkter

Læs mere

Data Warehouse Knowledge is Power - Sir Francis Bacon -

Data Warehouse Knowledge is Power - Sir Francis Bacon - Data Warehouse 4. sem. datamatiker uddannelse Tietgen Skolen Odense Skrevet af Troels Markvard Andersen (DM08228) Knowledge is Power - Sir Francis Bacon - Troels Markvard Andersen Side 1 af 8 Forord /

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

Læs mere

Overblik Program 17. nov

Overblik Program 17. nov Overblik Program 17. nov Oplæg, diskussion og sketchnoting af artikler Pencils before pixels, Drawing as... og Learning as reflective conversation... Intro til markers Øvelser: Formundersøgelser & idegenerering

Læs mere

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR EG Copyright Infrastruktur er mere end nogle servere... Den Mentale Infrastruktur Den Fysiske Infrastruktur Den Mentale Infrastruktur Vi vil jo gerne have vores

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Database "opbygning"

Database opbygning Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser,

Læs mere

Terese B. Thomsen 1.semester Formidling, projektarbejde og webdesign ITU DMD d. 02/11-2012

Terese B. Thomsen 1.semester Formidling, projektarbejde og webdesign ITU DMD d. 02/11-2012 Server side Programming Wedesign Forelæsning #8 Recap PHP 1. Development Concept Design Coding Testing 2. Social Media Sharing, Images, Videos, Location etc Integrates with your websites 3. Widgets extend

Læs mere

CFU forventer at undertekstformat vælges i samarbejde med en kommende leverandør, men at undertekstformatet er af en accepteret standard i markedet.

CFU forventer at undertekstformat vælges i samarbejde med en kommende leverandør, men at undertekstformatet er af en accepteret standard i markedet. CFU UC Udbud af streaming Spørgsmål-svar, Version 1 Spørgsmål 1-12 er besvaret den 14-1-2015. Spørgsmål 1 What subtitle formats will need to be used? Spørgsmålet refererer til krav 8 Rip af undertekster

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Termin 2013-2015 Institution Rybners Tekniske Gymnasium Uddannelse Fag og niveau Lærer(e) HTX Informationsteknologi B Jeppe Moritz Led Hold 3.E, Årgang 2012 Oversigt over undervisningsforløb

Læs mere

Den røde tråd fra testdækning til releasemetrikker

Den røde tråd fra testdækning til releasemetrikker Den røde tråd fra testdækning til releasemetrikker The art of developing software cheaper, in good quality and at schedule Software-Pro Agenda Den røde tråd fra testdækning til releasemetrikker Mange har

Læs mere

Facilitering af Kreativitet & Innovation i VELUX Gruppen. Line Louise Overgaard Concepts & Innovation Support

Facilitering af Kreativitet & Innovation i VELUX Gruppen. Line Louise Overgaard Concepts & Innovation Support Facilitering af Kreativitet & Innovation i VELUX Gruppen Line Louise Overgaard Concepts & Innovation Support Fordi lys skaber liv VELUX Gruppen Etableret i 1941 Mere end 10.000 ansatte globalt heraf 2.600

Læs mere

Standardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners

Standardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners Standardiseret tilgang til Software Asset Management ISO19770 ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners 1 WG21 historien ISO19770 arbejder i WG21 under ISO Etableret i 2001 Første standard 19770-1

Læs mere

HVAD ER VÆRDIEN AF ANALYTICS FOR DIN VIRKSOMHED

HVAD ER VÆRDIEN AF ANALYTICS FOR DIN VIRKSOMHED HVAD ER VÆRDIEN AF ANALYTICS FOR DIN VIRKSOMHED AARHUS D. 26. MAJ 2015 PETER ANDERSEN, SAS INSTITUTE THE POWER TO KNOW HVEM ER SAS INSTITUTE? 91 af top 100-virksomhederne på 2013 FORTUNE Global 500 listen

Læs mere

Morten Juul Nielsen Produktchef Microsoft Danmark

Morten Juul Nielsen Produktchef Microsoft Danmark Morten Juul Nielsen Produktchef Microsoft Danmark Er du, din organisation og dit datacenter klar til Skyen? Dynamisk Datacenter & Cloud Computing System Center Suiten med fokus på Service Manager Next

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

Arbitration in Denmark

Arbitration in Denmark Arbitration in Denmark Steffen Pihlblad Christian Lundblad Claus Søgaard-Christensen DJØF PUBLISHING Arbitration in Denmark Eds. Grith Skovgaard Ølykke Carina Risvig Hansen Steffen Pihlblad, Christina

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Termin 2014-2015 Institution Rybners Tekniske Gymnasium Uddannelse Fag og niveau Lærer(e) HTX Informationsteknologi B Jeppe Moritz Led Hold 2.E, Årgang 2013 Oversigt over undervisningsforløb

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

Lykken er så lunefuld Om måling af lykke og tilfredshed med livet, med fokus på sprogets betydning

Lykken er så lunefuld Om måling af lykke og tilfredshed med livet, med fokus på sprogets betydning Lykken er så lunefuld Om måling af lykke og tilfredshed med livet, med fokus på sprogets betydning Jørgen Goul Andersen (email: goul@ps.au.dk) & Henrik Lolle (email: lolle@dps.aau.dk) Måling af lykke eksploderer!

Læs mere

Syllabus. On-Line kursus. POSitivitiES. Learning. Applied Positive Psychology for European Schools

Syllabus. On-Line kursus. POSitivitiES. Learning. Applied Positive Psychology for European Schools PositivitiES Applied Positive Psychology for European Schools POSitivitiES Positive European Schools On-Line kursus Learning This project has been funded with support from the European Commission.This

Læs mere

Kom i gang med SAS STPbaserede

Kom i gang med SAS STPbaserede make connections share ideas be inspired Kom i gang med SAS STPbaserede webapplikationer Lars L. Andersson Chefkonsulent Webapplikationer Interaktion med serverbaserede data via skærmbilleder leveret gennem

Læs mere

Den gode User Experience. Michelle Andreassen ITAddiction Blogs: QED.dk

Den gode User Experience. Michelle Andreassen ITAddiction Blogs: QED.dk Den gode User Experience Mathilde Hoeg mathildehoeg Michelle Andreassen ITAddiction Blogs: QED.dk Agenda Hvad er brugeroplevelse (UX)? Hvad er en user experience designer? Hvad er brugervenlighed(usability)?

Læs mere

Lav testsuppe på en sten med exploratory test

Lav testsuppe på en sten med exploratory test Lav testsuppe på en sten med exploratory test TestExpo 29. Januar 2015 Lidt om mig selv Uddannelse Konstabel i flyvevåbnet Certificeringer: SCRUM master, ISEB foundation/practitioner, CAT trainer, TMap

Læs mere

PS102: Den menneskelige faktor og patientsikkerhed

PS102: Den menneskelige faktor og patientsikkerhed IHI Open School www.ihi.org/patientsikkerhed PS102: Den menneskelige faktor og patientsikkerhed (1 time) Dette modul er en introduktion til emnet "menneskelige faktorer": Hvordan indarbejdes viden om menneskelig

Læs mere

make connections share ideas be inspired

make connections share ideas be inspired make connections share ideas be inspired Integration af prædiktive analyser og operationelle forretningsregler med SAS Decision Manager Kristina Birch, chefkonsulent Professional Services, Banking & Mortgage

Læs mere

Emergency call button. Stabilt og simpelt

Emergency call button. Stabilt og simpelt Emergency call button Stabilt og simpelt 1 Agenda Områder af speciel interesse Gennemgang Hvad har jeg lært? Spørgsmål 2 Områder af speciel interesse Domæne, Krav, Use Cases, Kvalitetsattributter Arkitektur

Læs mere

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer INDLÆG 13 : DYNAMICS AX Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer Tonny Bybæk, Lau Bøgelund Larsen Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Læs mere

2 Moduler Tilbud på betalingsmodul til Facecv.dk

2 Moduler Tilbud på betalingsmodul til Facecv.dk 2 Moduler Tilbud på betalingsmodul til Facecv.dk 1 Overblik Et eksisterende Codec9 baseret websted skal udvides til at understøtte dankortbetaling via en betalingsgateway. Webstedet er i opstartsfasen,

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

IntDesign - Kap 7. Kap 1.6.1 s. 20 - Usability goals

IntDesign - Kap 7. Kap 1.6.1 s. 20 - Usability goals IntDesign - Kap 1 Kap 1.6.1 s. 20 - Usability goals Usability goals are viewed as being concerned with meeting specific usability criteria, e.g. efficiency, whereas user experience goals are largely concerned

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

PHP Quick Teknisk Ordbog

PHP Quick Teknisk Ordbog PHP Quick Teknisk Ordbog Af Daniel Pedersen PHP Quick Teknisk Ordbog 1 Indhold De mest brugte tekniske udtryk benyttet inden for web udvikling. Du vil kunne slå de enkelte ord op og læse om hvad de betyder,

Læs mere

Software Arkitektur i Praksis (Modul 2) H5. In the Cloud + Architectural Evaluation

Software Arkitektur i Praksis (Modul 2) H5. In the Cloud + Architectural Evaluation Indholdsfortegnelse Introduktion... 2 Part1... 2 1. Oplevelser i skyen... 2 2. QA sammenligning... 4 3. Telemedicin i skyen... 6 4. TM12 i PaaS... 9 Part 2... 10 ATAM... 11 1. Tilpasning til TM12... 11

Læs mere

Masters Thesis - registration form Kandidatafhandling registreringsformular

Masters Thesis - registration form Kandidatafhandling registreringsformular Masters Thesis - registration form Kandidatafhandling registreringsformular Godkendelse af emne for hovedopgave af vejleder og undervisningskoordinator. Læs venligst retningslinjerne sidst i dette dokument

Læs mere

Kapitalstruktur i Danmark. M. Borberg og J. Motzfeldt

Kapitalstruktur i Danmark. M. Borberg og J. Motzfeldt Kapitalstruktur i Danmark M. Borberg og J. Motzfeldt KORT OM ANALYSEN Omfattende studie i samarbejde med Økonomisk Ugebrev Indblik i ledelsens motiver for valg af kapitalstruktur Er der en optimal kapitalstruktur

Læs mere

Hvad er cloud computing?

Hvad er cloud computing? Hvad er cloud computing? Carsten Jørgensen cjo@devoteam.dk Devoteam Consulting COPYRIGHT 11/05/2010 Architecture & Information Simplificering af it og effektiv it til forretningen Business Intelligence

Læs mere

MODERNISERINGSSTYRELSEN ØSLDV WINDOWS SERVICE DOKUMENTATION, INSTALLATION OG KONFIGURERING AF ØSLDV/RAY WINDOWSSERVICE

MODERNISERINGSSTYRELSEN ØSLDV WINDOWS SERVICE DOKUMENTATION, INSTALLATION OG KONFIGURERING AF ØSLDV/RAY WINDOWSSERVICE Indhold Ændringshistorik... 2 Formål... 2 Om programmet... 2 Systemkrav... 2 Installation... 3 Event Log... 5 Installationsprogrammets skærmbillede... 6 Konfigurering af xml-opsætningsfil... 7 Beskrivelse

Læs mere

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 PROJECT DATABASE 3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 Ved at underskrive dette dokument bekræfter vi, at det indsendte materiale alt sammen er vores eget materiale og arbejde. Andreas

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Forelæsning den 31. marts 2003

Forelæsning den 31. marts 2003 Forelæsning den 31. marts 2003 1. Spørgsmål & Svar: (a) Aflevering af Delopgave 1 for Det Gennemgående Udviklingsprojekt udskydes én uge til 14.04.03; (b) Ingen forelæsning den 07.04.03 (c) De to konsoliderede

Læs mere

Vejledning i projektledelse

Vejledning i projektledelse Dansk standard DS/ISO 21500 2. udgave 2013-09-27 Vejledning i projektledelse Guidance on project management DS/ISO 21500 København DS projekt: M268368 ICS: 03.100.40 Første del af denne publikations betegnelse

Læs mere

OPC ACCESS HEARTBEAT 1

OPC ACCESS HEARTBEAT 1 OPC Access Heartbeat Dette dokument gennemgår i et kort eksempel, hvordan OPC Access konfigureres til at anvende Heartbeat funktionen til at dokumentere kontinuerlig forbindelse mellem SQL Server og OPC

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

Vejledning til at tjekke om du har sat manuel IP på din computer.

Vejledning til at tjekke om du har sat manuel IP på din computer. Indhold Vejledning til at, komme på nettet. (DANSK)... 2 Gælder alle systemer.... 2 Vejledning til at tjekke om du har sat manuel IP på din computer.... 2 Windows 7... 2 Windows Vista... 2 Windows XP...

Læs mere

Data lagring. 2. iteration (implement backend)

Data lagring. 2. iteration (implement backend) Data lagring 2. iteration (implement backend) Emner Grundlæggende database begreber. Data definitionskommandoer ER-diagrammer og cardinalitet/relationer mellem tabeller Redundant data og Normalisering

Læs mere

Har det en værdi og hvordan kommer du i gang?

Har det en værdi og hvordan kommer du i gang? Virtualisering? Har det en værdi og hvordan kommer du i gang? Torben Vig Nelausen Produktchef Windows Server, Microsoft og Claus Petersen Senior Partner Technology Specialist, Microsoft Agenda Hvad er

Læs mere

Subject to terms and conditions. WEEK Type Price EUR WEEK Type Price EUR WEEK Type Price EUR WEEK Type Price EUR

Subject to terms and conditions. WEEK Type Price EUR WEEK Type Price EUR WEEK Type Price EUR WEEK Type Price EUR ITSO SERVICE OFFICE Weeks for Sale 31/05/2015 m: +34 636 277 307 w: clublasanta-timeshare.com e: roger@clublasanta.com See colour key sheet news: rogercls.blogspot.com Subject to terms and conditions THURSDAY

Læs mere

IT Service Management - the ITIL approach

IT Service Management - the ITIL approach IT Service Management - the ITIL approach Mikael M. Hansen mhansen@cs.aau.dk 2.2.57 Mikael M. Hansen Page 1 TOC Mine indlæg Dagens program: IT Service Management Alternativerne ITIL

Læs mere

Velkommen. Backup & Snapshot v. Jørgen Weinreich / Arrow ECS Technical Specialist

Velkommen. Backup & Snapshot v. Jørgen Weinreich / Arrow ECS Technical Specialist Velkommen Backup & Snapshot v. Jørgen Weinreich / Arrow ECS Technical Specialist 1 Agenda Fra backup til restore produkt Politikstyret Backup Live Demo 2 IBM XIV Snapshots - Næsten uden begrænsninger Snapshot

Læs mere

Transaktionen er gennemført i forkert valuta

Transaktionen er gennemført i forkert valuta Transaktionen er gennemført i forkert valuta Er beløbet er hævet i en forkert valuta, har du mulighed for at gøre indsigelse. Før du kan gøre indsigelse, skal du selv have kontaktet forretningen. Det er

Læs mere

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 LIDT OM MIG SELV Erfaring NIELS-HENRIK HANSEN 35+ års samlet IT erfaring 15+ år som test manager Certificeret Inspection Leader ISEB Foundation

Læs mere

Fra ERP strategi til succesfuld ERP implementering. Torben Storgaard HerbertNathan & Co

Fra ERP strategi til succesfuld ERP implementering. Torben Storgaard HerbertNathan & Co Fra ERP strategi til succesfuld ERP implementering Torben Storgaard HerbertNathan & Co ERP - realisér morgendagens gevinster + Leveringstid Omkostninger Kundeservice + + Hvem er brugere af ERP i dag? @

Læs mere

Dynamisk Webdesign F2010

Dynamisk Webdesign F2010 Dynamisk Webdesign F2010 Præsentationer Læringsmål Emnet: teknologi, koncept, design og process Projekt Semesterplan Jeres underviser: Tess Gaston Cand.it, software udvikling (ITU) og ba. pædagogik (KU)

Læs mere

Fremtidens Kontaktcenter 19.09.2014 1

Fremtidens Kontaktcenter 19.09.2014 1 Fremtidens Kontaktcenter 19.09.2014 1 Fact: Kunde Demographics demografien Are Changing ændrer sig fundamentalt med forskellige forventninger for kunde tilfredstillelse Erik, hvorfor svarer du ikke din

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

BACK-END OG DATA: ADMINISTRATION HVAD ER DE NYE MULIGHEDER MED VERSION 7.1? STEFFEN BILLE RANNES, 4. FEBRUAR 2015

BACK-END OG DATA: ADMINISTRATION HVAD ER DE NYE MULIGHEDER MED VERSION 7.1? STEFFEN BILLE RANNES, 4. FEBRUAR 2015 BACK-END OG DATA: ADMINISTRATION HVAD ER DE NYE MULIGHEDER MED VERSION 7.1? STEFFEN BILLE RANNES, 4. FEBRUAR 2015 SAS VISUAL ANALYTICS 7.1 ADMINISTRATOR Mulighed for at udføre handlinger på flere servere

Læs mere

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

EU vedtager et nyt program, som med 55 millioner EUR skal give børn større sikkerhed på internettet

EU vedtager et nyt program, som med 55 millioner EUR skal give børn større sikkerhed på internettet IP/8/899 Bruxelles, den 9 december 8 EU vedtager et nyt program, som med millioner EUR skal give børn større sikkerhed på internettet EU får et nyt program for forbedring af sikkerheden på internettet

Læs mere

2013 SP1. Konfiguration af koncernindblik. Configuration Guide

2013 SP1. Konfiguration af koncernindblik. Configuration Guide 2013 SP1 Konfiguration af koncernindblik Configuration Guide Intellectual Property Rights This document is the property of ScanJour. The data contained herein, in whole or in part, may not be duplicated,

Læs mere

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

Læs mere

Ole Gregersen 26. november 2009 IT Universitetet

Ole Gregersen 26. november 2009 IT Universitetet Ole Gregersen 26. november 2009 IT Universitetet Hvorfor er det relevant at arbejde med? 5 minutter med sidemanden Kvalitetsegenskab Risikostyring Oplevelsesdesign En kontrolleret designproces Et brugercentreret

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Hvordan sikres personfølsomme data - og adgangen til disse så persondataloven overholdes. Klaus Kongsted, CRO, Dubex A/S Dubex A/S, den 5.

Hvordan sikres personfølsomme data - og adgangen til disse så persondataloven overholdes. Klaus Kongsted, CRO, Dubex A/S Dubex A/S, den 5. Hvordan sikres personfølsomme data - og adgangen til disse så persondataloven overholdes Klaus Kongsted, CRO, Dubex A/S Dubex A/S, den 5. maj 2015 Den nuværende persondatalov Fra år 2000, løbende smårevisioner

Læs mere

Virksomhedens informationssystem. Det elektroniske kontor. Elektronisk dokumenthåndtering Samfundet. Systembeskrivelse II IT og økonomi

Virksomhedens informationssystem. Det elektroniske kontor. Elektronisk dokumenthåndtering Samfundet. Systembeskrivelse II IT og økonomi Virksomhedens informationssystem Systembeskrivelse II IT og økonomi Det elektroniske kontor Elektronisk dokumenthåndtering Hvordan omlægger vi arbejdsgange, så elektronikken styrker vores arbejde? Data

Læs mere

LaserNet v6.6 Release Nyhedsbrev

LaserNet v6.6 Release Nyhedsbrev LaserNet v6.6 Release Nyhedsbrev NY Input Management-Løsning! Indhold: LaserNet v6.6 LaserNet Webinars NY LaserNet Input Management-løsning Nyt Produkt: LaserNet Client Nye Features & Functions Ny medarbejder

Læs mere

Vind Seminar Fredericia 4. april 2013 JOB2SEA

Vind Seminar Fredericia 4. april 2013 JOB2SEA Vind Seminar Fredericia 4. april 2013 JOB2SEA Rekrutteringsstrategi i et svært marked. Helle Drachmann Baggrund Job- & CV database Outplacement & transition management Koncern HR Selvstændig virksomhed

Læs mere

Microsoft Dynamics C5. Nyheder Kreditorbetalinger

Microsoft Dynamics C5. Nyheder Kreditorbetalinger Microsoft Dynamics C5 Nyheder Kreditorbetalinger INDHOLDSFORTEGNELSE Indledning... 3 Uddybning af ændringer... 4 Forbedring vedr. betalings-id er... 4 Ændringer i betalingsmåder (kreditorbetalinger)...

Læs mere

SOSI Gateway Komponenten (SOSI GW)

SOSI Gateway Komponenten (SOSI GW) SOSI Gateway Komponenten (SOSI GW) - en security domain gateway Version 1.2 1/8 Indledning Region Syddanmark er udvalgt som pilotregion for projektet Det Fælles Medicingrundlag, og i den forbindelse arbejdes

Læs mere

8. ARBEJDSPROCESSEN FOR SKABELSEN AF ET INTERNATIONALT WWW-STED... 113

8. ARBEJDSPROCESSEN FOR SKABELSEN AF ET INTERNATIONALT WWW-STED... 113 8. ARBEJDSPROCESSEN FOR SKABELSEN AF ET INTERNATIONALT WWW-STED... 113 8.1 FORSTÅELSE AF VIRKSOMHEDENS PRODUKTER/SERVICEYDELSER OG RESSOURCER... 114 8.2 INFORMATIONSSØGNING I RELATION TIL LANDE-, KONKURRENT-

Læs mere

Dit hus introduction. / Jeppe Brønsted, Arne Skou. and Per Printz Madsen, Rune Torbensen

Dit hus introduction. / Jeppe Brønsted, Arne Skou. and Per Printz Madsen, Rune Torbensen Dit hus introduction / Jeppe Brønsted, Arne Skou and Per Printz Madsen, Rune Torbensen Project facts Period: April 2009 (August 2008) October 2011 Budget: 10.6 mill.kr. Funding: 8 mill. kr. (2.6 mill.

Læs mere

Grundlæggende processer du skal have styr på ift. Informationsaktiv beskyttelse

Grundlæggende processer du skal have styr på ift. Informationsaktiv beskyttelse Grundlæggende processer du skal have styr på ift. Informationsaktiv beskyttelse 1 Agenda Kort om LinkGRC Omfanget af præsentationen Analyse Den røde tråd Implementering af krav i organisationen Informationsaktivers

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Hvad er INSPIRE? - visionen - infrastrukturen - relationer til danske forhold

Hvad er INSPIRE? - visionen - infrastrukturen - relationer til danske forhold Hvad er INSPIRE? - visionen - infrastrukturen - relationer til danske forhold Formålet med INSPIRE er : at støtte tilgængeligheden af geografisk information til brug ved formulering, implementering og

Læs mere

Hvordan flytter Økonomi ud af baglokalet og hen til beslutningsbordet?

Hvordan flytter Økonomi ud af baglokalet og hen til beslutningsbordet? Hvordan flytter Økonomi ud af baglokalet og hen til beslutningsbordet? Hvad er business partnering? Den rolle Økonomi påtager sig for at understøtte forretningen, øge kvaliteten af beslutningsprocessen

Læs mere

Apresa Call Recording

Apresa Call Recording Call Recording Hvorfor optage samtaler? De optagede samtaler giver en værdifuld indsigt i eksempelvis: Medarbejdernes evne til at kommunikere positivt med kunden Medarbejdernes fokus på aftalte KPI er

Læs mere

Hvordan finder man en god skala vha. Raschmetoden? Svend Kreiner & Tine Nielsen

Hvordan finder man en god skala vha. Raschmetoden? Svend Kreiner & Tine Nielsen Hvordan finder man en god skala vha. Raschmetoden? Svend Kreiner & Tine Nielsen 1 Svaret: Man spørger en, der har forstand på det, som man gerne vil måle 2 Eksempel: Spiritualitet Peter A., Peter G. &

Læs mere

Øvelse 9. Klasser, objekter og sql-tabeller insert code here

Øvelse 9. Klasser, objekter og sql-tabeller insert code here Øvelse 9. Klasser, objekter og sql-tabeller Denne opgave handler om hvordan man opbevarer data fra databasekald på en struktureret måde. Den skal samtidig give jer erfaringer med objekter, der kommer til

Læs mere

ALGARY-CAMBRIDGE GUIDEN TIL KOMMUNIKATION MELLEM PATIENT OG SUNDHEDSPROFESSIONEL

ALGARY-CAMBRIDGE GUIDEN TIL KOMMUNIKATION MELLEM PATIENT OG SUNDHEDSPROFESSIONEL C ALGARY-CAMBRIDGE GUIDEN TIL KOMMUNIKATION MELLEM PATIENT OG SUNDHEDSPROFESSIONEL Denne guide er en let bearbejdet oversættelse fra bogen Skills for Communicating with Patients af Jonathan Silverman,

Læs mere

PROfessiOnel RisikOstyRing med RamRisk

PROfessiOnel RisikOstyRing med RamRisk 4 Professionel risikostyring med ramrisk www.ramrisk.dk Risikostyring med RamRisk Rettidig håndtering af risici og muligheder er afgørende for enhver organisation og for succesfuld gennemførelse af ethvert

Læs mere

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion Driftskontrakter Hvordan sikrer man sig, at man får en ordentlig driftskontrakt? Hvad skal man være opmærksom på, og hvornår begynder man egentlig at tænke den ind? Velkommen Program: Oplæg om emnet baseret

Læs mere