Mjukvaruarkitektur en översikt Sten Sundblad, Sundblad & Sundblad ADB-Arkitektur, Uppsala

Storlek: px
Starta visningen från sidan:

Download "Mjukvaruarkitektur en översikt Sten Sundblad, Sundblad & Sundblad ADB-Arkitektur, Uppsala"

Transkript

1 , Sundblad & Sundblad ADB-Arkitektur, Uppsala Vi skriver nu januari 2005 och det är dags för ett nytt tema för Microsofts arkitektwebb. Under kvartalet januari mars 2005 är det arkitektur och arkitektens roll som gäller, och det här är den första av tre artiklar under detta tema. Avsikten med den här artikeln är att ge en översikt över ämnet mjukvaruarkitektur; februariartikeln kommer att handla om olika arkitektroller och arkitektens ansvar, medan marsartikeln kommer att diskutera mjukvaruarkitektens verktyg och arbetssätt. En jämförelse med traditionell arkitektur Som vi framhåller i kursen Arkitektur och arkitektens roll, som ingår i vårt utbildnings- och certifieringsprogram för lösningsarkitekter som arbetar i.net-miljö, har vi mycket att vinna på att se hur arkitektur och arkitektyrket definieras i mera traditionella sammanhang. Idén om mjukvaruarkitektur har ju inte särskilt många år på nacken, särskilt om man jämför med traditionell arkitektur som var ett viktigt ämnesområde långt före Kristi födelse, och det är först på senare år som begreppen arkitektur och arkitekt verkligen har blommat ut i IT-sammanhang. Brooks och arkitektur 1975 skrev Frederick P. Brooks, Jr. The Mythical Man-Month I. Brooks är känd som the father of the IBM System/360. Han var projektledare vid utvecklingen av detta välkända stordatorsystem. Han var också under designfasen ansvarig för utvecklingen av operativsystemet till IBM System/360. Bokens titel kommer sig av Brooks syn på begrepp som manår och manmånad. Brooks menar att det finns en vanföreställning omkring dessa begrepp, nämligen att ett projekts framåtskridande kan samvariera med antalet personer och antalet tidsenheter som sätts in i projektet. Kostnaden för projektet samvarierar tämligen väl med antalet manmånader eller manår menar Brooks; projektets framåtskridande gör det inte. Utifrån Brooks erfarenheter från 360-projektet och andra projekt stiftade han det han kallar för Brooks s Law. Han medger att han förenklar problemställningen på ett närmast skamligt sätt men att lagen icke dess mindre har giltighet. Så här ser Brooks s Law ut: Adding manpower to a late software project makes it later. Brooks s Law är emellertid inte skälet till att jag tar upp Brooks här. Det är i stället att han så tidigt som 1975 talar om arkitektur av mjukvarusystem. Han gör det i ett avsnitt om konceptuell integritet, där han jämför arkitektur i de flesta europeiska katedraler med arkitektur i katedralen i Reims. I de flesta fall, menar Brooks, finns det skillnader i arkitekturell stil mellan delar som har byggts av olika generationer av byggare. Senare byggherrar frestats att förbättra stilen från tidigare, dels för att återspegla skillnader i mode och dels för att sätta sin egen prägel på de tillkommande delarna. Katedralen i Reims, menar Brooks, är det lysande undantaget. Åtta generationer av byggherrar har nekat sig tillfredsställelsen av att sätta sin egen prägel på sin del av verket och i stället böjt sig för de ursprungliga arkitektoniska idéerna. Den glädje som vederfars åskådaren kommer i lika hög grad från utformningens integritet som från några enskilda förträffligheter, menar Brooks. I en kommentar om mjukvarusystem säger Brooks att konceptuell integritet enligt hans uppgift är den allra viktigaste faktorn i systemdesign. Det är bättre, säger han, att ett system återspeglar en enda uppsättning designidéer och saknar vissa funktioner och förbättringar än att det innehåller ett antal goda men oberoende och ej samordnade idéer. Brooks menar att det är svårt att åstadkomma konceptuell integritet i större system som kräver att många är inblandade i dess utformning och utveckling, men att han har identifierat två sätt att ändå göra det: Det första sättet är att noggrant fördela utvecklingsarbetet med en del för arkitektur och en annan separat del för implementering. Systemet skall ha en enda arkitekt, eller högst ett fåtal arkitekter som utformar systemet i nära samverkan med varandra.

2 Det andra sättet är att strukturera de lag eller grupper som skall implementera systemet på ett särskilt sätt som ligger utanför den här artikelns intresseområde. Brooks s definition av arkitektur Brooks s definition av arkitektur är intressant eftersom den ligger nära den traditionella synen på arkitektur. Så här säger han ordagrant: By the architecture of a system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job. Det är intressant att ta del av Brooks s definition av arkitektur, eftersom den så helt fokuserar på systemets exteriör. Han påpekar också att en mjukvaruarkitekt, precis som en byggnadsarkitekt, är användarens representant. Han är inte säljare och inte heller tillverkare. Han har i stället ett odelat ansvar för att applicera sitt professionella kunnande och tillämplig teknologi i användarens intresse. Arkitekten är helt enkelt användarens och kundens agent. Med referens till sin samarbetspartner i 360-projektet, G.A. Blaauw, exemplifierar Brooks med arkitekturen för en klocka. Klockans arkitektur består av (eller bestod åtminstone då av) beståndsdelar som urtavlan, två eller flera visare och en uppdragningsmekanism. När ett barn har lärt sig förstå denna arkitektur kan det läsa av tiden oavsett om det sker från ett armbandsur eller en kyrkklocka trots att de båda implementerar denna arkitektur på helt olika sätt. Poängen är, menar Brooks, att ett systems arkitektur beskriver systemets utsida; implementationen beskriver dess insida. Vitruvius: Ten Books on Architecture Om Brooks var en pionjär inom mjukvaruarkitektur borde Marcus Vitruvius Pollio kunna betraktas som en pionjär inom traditionell arkitektur. Han levde i Rom under tiden strax före Kristi födelse och skrev under perioden omkring år för Kristus tio böcker om arkitektur (De Architectura). Dessa böcker finns översatta till engelska att köpa hos till exempel Amazon. De är samlade i en volym och har titeln Ten Books on Architecture II. Var och en av de tio böckerna är också försedd med nutida kommentarer. Det är visserligen sant att vi haft betydande arkitekter långt före Vitruvius, men det lär vara så att ingen före honom har skrivit om arkitektur och fått sina alster bevarade ända in i våra dagar. Det är inte minst därför det är relevant att tala om Vitruvius som pionjär. Han lär ha inlett sin arkitektbana omkring 50 före Kristus, det vill säga ungefär vid den tid då inbördeskriget mellan Ceasar och Pompejus bröt ut. I inledningen var hans karriär därför militärt inriktad, och han talar i sina böcker om sitt ansvar för utformningen av de katapulter som användes vid belägring av städer för att bryta ner försvaret. Han anses emellertid också vara arkitekt för basilikan i Fano som byggdes under Ceasar och Augustus. Det sägs att Vitruvius idéer om arkitektur påverkar arkitektyrket ända in i vår tid, direkt eller indirekt, så det kan vara intressant att ta del av hans budskap. Vitruvius hävdade att arkitektur utgår från tre principer: Principen om utilitas handlar om att den struktur vi tänker bygga skall vara användbar för sitt syfte. För att arkitekten skall kunna åstadkomma det måste han skaffa sig ingående kunskap om den tänkta strukturens syfte. Det är användarens/beställarens ansvar att syftet blir ordentligt beskrivet, men i de flesta fall krävs att arkitekten ställer sin yrkeskunskap till användarens/beställarens förfogande för att syftet skall bli så väl beskrivet som krävs. Användaren/beställaren är sällan professionella kravanalytiker eller kravställare; arkitekten måste vara det. Arkitekten måste alltså först skaffa sig ingående kunskap om det eller de problem som skall lösas för att sedan åstadkomma en arkitektur med god potential att lösa dem. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 2

3 Utilitas handlar också om den tänkta strukturens eller produktens flexibilitet. För att den skall bli användbar över tiden måste den kunna anpassas till nya användares behov och nya användningssituationer. Även detta är naturligtvis arkitektens ansvar. Principen om venustas säger att den struktur vi tänker bygga skall vara behaglig att använda eller vistas i. Venustas är helt och hållet arkitektens ansvar. I traditionell arkitektur är det här arkitektens huvudansvar ligger; i mjukvaruarkitektur får man nog säga att venustas hittills spelat en undanskymd roll. Ofta är det problematiskt att det är så användaren som borde sitta i högsätet gör det inte alltid. Alan Cooper har skrivit en del om det här i About Face 2.0 The Essentials of Interaction Design III och The Inmates Are Running the Asylum IV. Cooper är känd som mannen bakom Microsoft Visual Basic. Han hade en formulärhanterare för Windows kallad Ruby. Han sålde Ruby till Microsoft och hjälpte Microsoft att sammanföra Ruby och Windows. Resultatet var Visual Basic 1.0, och Ruby har fortsatt varit Visual Basic s formulärhanterare ända fram till och med Visual Basic 6.0. Det är först nu med.net som Microsoft lämnat Alan Cooper s Ruby bakom sig. Coopers hela professionella verksamhet kretsar sedan tiden med Visual Basic 1.0 kring det han kallar Interaction Design. Hans grundinställning är att all mjukvara i princip är användarfientlig ( user hostile ), och han har många recept för att förbättra situationen. Den som i likhet med Vitruvius och Brooks menar att arkitekten har ett stort ansvar för användbarhet och användarens välbefinnande i relation till den tänkta produkten har mycket att hämta hos Cooper. About Face vänder sig främst till dig i din roll som utvecklare medan The Inmates Are Running the Asylum främst vänder sig till beslutsfattare. Den schweiziske arkitekten Le Corbusier levde mellan 1887 och Enligt Marvin Trachtenberg, författare till Architecture: From Pre-History to Postmodernism V, uttryckte sig Le Corbusier så här om arkitektur (min översättning från författarens engelska översättning av Le Corbusiers uttalande): Du använder sten, trä och betong, och med dessa material bygger du hus och palats. Detta är konstruktion. Skarpsinne och genialitet sätts i arbete. Men plötsligt rör du vid mitt hjärta, du får mig att må bra, jag är lycklig och jag säger Detta är vackert. Då är det arkitektur. Principen om firmitas innebär att den struktur som byggs skall vara stark, att den skall vara uthållig och varaktig nog att stå emot tidens tand och flitig användning över år och årtionden. Det här är traditionellt byggarens ansvar, och så är det också i samband med mjukvaruutveckling, men jämfört med traditionell arkitektur ligger nog mjukvaruarkitektens intressen mer på firmitas än det gör i traditionell arkitektur. Förmodligen beror detta på att vi mjukvaruarkitekter så gott som uteslutande kommer från och har vår huvudsakliga erfarenhet från byggsidan. Om arkitektur, arkitekter och design Det är uppenbart att arkitektur handlar om design, och främst då om övergripande design. Grady Booch har i något sammanhang sagt att all arkitektur är design men all design är inte arkitektur. Det här uttalandet är emellertid förledande enkelt, och det vet Grady Booch. Arkitektur är mer än design, eftersom arkitekten måste åstadkomma en arkitektur eller utformning som löser väl kända problem. Utan problem finns det inget behov av arkitektur, och arkitekten måste ha ingående kännedom om dessa problem om han skall kunna lösa dem på ett för användaren och beställaren tillfredsställande sätt. Arkitektur måste alltså föregås av ett gediget analysarbete, och arkitekten måste vara beredd att ta på sig ett stort ansvar för detta analysarbete. Vad ingår i ett systems arkitektur? I boken Evaluating Software Architectures VI räknar Paul Clements m.fl. upp tre skäl till att mjukvaruarkitektur har blivit så betydelsefull för stora, komplexa mjukvaruintensiva system: 1. Författarna positionerar arkitektur som ett kommunikationsmedel bland ett tänkt systems intressenter. (Det begrepp författarna använder är naturligtvis stakeholders, men jag har valt att använda det svenska intressenter som en motsvarighet. Jag tycker egentligen att ordet intressenter är litet svagare än stakeholders eftersom det svenska ordet kan innefatta någon som bara har ett svalt intresse av området. Den Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 3

4 här aktuella betydelsen är emellertid att intressenten har en insats ( stake ) i det tänkta systemet och att man är aktivt intresserad av att skydda denna insats. 2. De menar också att ett systems arkitektur är en yttring av de tidigaste designbeslut som rör systemet. När ett arkitekturförslag presenteras är det första chansen att analysera de prioriteringar som har gjorts mellan konkurrerande krav och önskemål, och ett systems arkitektur är enligt författarna den artefakt som har den största inverkan av alla på systemets kvalitet. De säger att kompromisser mellan prestanda och säkerhet, mellan underhållsvänlighet och pålitlighet, och mellan tidiga och framtida utvecklingskostnader tydliggörs i en arkitekturbeskrivning. 3. De säger också att ett systems arkitektur är en återanvändbar och överföringsbar abstraktion av systemet. Jämfört med ett systems kodmassa är dess arkitektur en tämligen liten och överblickbar modell av systemet som visar hur dess viktigaste komponenter samverkar med varandra. En sådan modell kan överföras till andra system som skall tillfredsställa liknande krav och kan på sikt stimulera till storskalig återanvändning och till produktlinjer. Vår kommentar är att detta skäl förmodligen har extra stor giltighet i en serviceorienterad arkitektur där speciellt entitetstjänster, men även aktivitetstjänster, helt enkelt är till för storskalig återanvändning. Samma bok försöker att besvara frågan om vad arkitektur egentligen är, eller kanske snarare vilka delar av en design som är arkitektur och vilka som inte är det. I våra kurser för blivande certifierade.net-arkitekter kommer relativt ofta frågan upp om var gränsen går mellan arkitektur och övergripande design. Med andra ord: hur långt skall arkitekten gå innan han eller hon överlämnar sitt verk till en designer som inte är arkitekt? Vi brukar alltid besvara den frågan med referens till den här boken som räknar upp några användbara principer för avgränsning och arkitektur och annan design. Jag tänker inte räkna upp alla dessa principer, och jag tänker inte gå in lika djupt på dem som boken gör. Vill du ha mera bredd och djup på den här frågan rekommenderar jag att du köper boken den ger dig bra värde i utbyte för de pengar och den tid du lägger ner på den. Här kommer emellertid vårt urval (för den här artikeln) av dessa principer: Extern synlighet. För att något skall räknas som arkitekturellt måste det vara en komponent, en relation mellan komponenter eller en egenskap i en sådan komponent eller relation som behöver synas externt. Extern synlighet skall möjliggöra resonemang om systemets potential att tillgodose krav som ställts på det, eller om nedbrytning av systemet i mindre oberoende delar som kan implementeras var för sig. Hög abstraktionsnivå. Den information som framgår av en arkitekturbeskrivning är den mest abstrakta men ändå meningsfulla beskrivningen av systemet. Dessa båda egenskaper, att både vara rejält abstrakt men ändå meningsfull kan ibland synas motsägelsefulla. Ibland måste du för att beskrivningen skall bli meningsfull gå ned på en detaljnivå som andra bedömer som för låg, men om det behövs så behövs det, och i så fall ingår denna detaljerade beskrivning absolut i systemets arkitektur. Som framgår av nästa punkt är det arkitekten som avgör var gränsen mellan arkitektur och mer detaljerad design går. Arkitekten bestämmer gränsen. En av uppgifterna för ett systems arkitektur är att överbrygga klyftan mellan de krav som ställs på systemet och systemets detaljerade design och implementering. Det här kan också uttryckas så att systemets arkitektur lägger band på oönskad kreativitet. Om du som arkitekt anser att du för att säkerställa ett verksamhets- eller användarkrav måste beskriva någon aspekt på systemet på ett detaljerat sätt, då skall du också göra det. Då ingår denna detaljerade beskrivning i systemets arkitektur. Du som arkitekt har det övergripande ansvaret för att alla krav på systemet blir tillgodosedda så väl som möjligt, och eftersom det är du som sitter på kravbilden kan ingen vara en bättre domare än du över vad som skall ingå i systemets arkitektur och vad som skall vara detaljerad design. Det du beskriver ingår i systemets arkitektur det du utelämnar gör det inte. Var börjar arkitektens ansvar? Var börjar då arkitektens ansvar? Svaret är naturligtvis som alltid att det beror på. Bland annat beror det på vilken arkitektroll frågan avser. Olika arkitektroller är ett av föremålen för nästa månads artikel; för den här artikeln nöjer vi oss med att diskutera den arkitektroll både vi och Microsoft valt att kalla lösningsarkitekt. Denna roll har vi tidigare kallat för applikationsarkitekt, men i takt med att vi (långsamt men ganska säkert) rör oss i riktning mot en service- Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 4

5 orienterad paradigm blir det mer relevant att i stället tala om lösningsarkitekter. Vi stödjer oss här på potentater som Don Box och Pat Helland som båda menar att det är bäst att låta applikationsbegreppet stå för samma sak som det alltid har stått för, nämligen en tämligen sammanhållen programenhet som är till för att lösa ett specifikt problem. I en serviceorienterad miljö kommer motsvarande lösning att bestå av ett antal till varandra löst kopplade tjänster som samverkar till att åstadkomma lösningen. Många tycker det här är hårklyveri, men ju mer distinkta vi kan vara i våra ordval, desto lättare kommer det bli att kommunicera med precision. Frågan gäller alltså var lösningsarkitektens ansvar börjar. Många skulle säkert besvara den frågan med att lösningsarkitektens ansvar börjar när det finns en tydlig kravbild som skall omsättas i en övergripande arkitektur. Vi menar att den börjar tidigare, redan vid insamlingen av denna kravbild. Arkitekten måste ta ett ansvar för att den kravbild han eller hon skall utgå från är tillräckligt omfattande och tillräckligt tydlig. Om så inte är fallet kan inte arkitekten åstadkomma en relevant arkitektur; den kommer att sakna nödvändiga sammanhang. I en idealisk värld kommer beställaren av en lösning att kunna redogöra för sina krav på ett så bra sätt att arkitekten kan utgå från dem. I verkligheten är det ytterst sällan så; arkitekten måste ställa sin professionella kompetens i beställarens tjänst och hjälpa beställaren både att formulera och strukturera sina krav. Så är det för den traditionelle arkitekten, som i de allra flesta fall måste hjälpa husköparen att formulera och strukturera sina krav och önskemål, och så måste det också vara för en lösningsarkitekt inom IT. IEEE Det finns en formell standard för arkitekturbeskrivningar inom IT. Den heter IEEE Std , och den utgör en rekommendation för utformandet av arkitekturell beskrivning av mjukvaruintensiva system. Den omfattar alltså inte på något sätt ett systems arkitektur endast beskrivningen av denna arkitektur. Som de flesta av denna artikels läsare säkert känner till är IEEE en standardiseringskommission med stort inflytande inom området elektricitet och elektronik. Det kan ändå vara intressant att i figuren till höger, som är ett klipp ur the About Box från IEEE s hemsida se omfattningen av denna kommissions åtaganden. Det formella namnet på denna standard är IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, och du hittar en formell beskrivning av den på följande adress: Det finns åtminstone tre intressanta aspekter på denna standard: 1. Den kan hjälpa oss som lösningsarkitekter att strukturera innehållet i våra arkitekturbeskrivningar. Det måste vara av stort värde att formalisera sådana beskrivningar så att strukturen på flera olika arkitekturbeskrivningar påminner om varandra. Det borde också underlätta för konsumenter av sådana beskrivningar att de liknar varandra. 2. En sådan standard som IEEE Std borde kunna hjälpa vårt yrke till en högre grad av mognad. Vi ligger långt efter traditionell arkitektur när det gäller former och innehåll för vårt arbete, vilket inte minst manifesteras av de många uppfattningar som finns om vad arkitektur och arkitekter är i vår bransch. 3. Det borde finnas ett marknadsvärde i att kunna säga att de arkitekturbeskrivningar jag/vi framställer är förenliga med den enda formella standard som finns på området. Av dessa skäl har vi gjort IEEE Std till en av tre grundpelare för vår verksamhet med utbildning och certifiering av.net-arkitekter. En arkitekt som gått igenom hela vårt utbildningsprogram för arkitekter och som är certifierad av oss kan garanterat framställa arkitekturbeskrivningar som är förenliga med IEEE Std Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 5

6 Konceptuell modell av en arkitekturbeskrivning I beskrivningen av IEEE Std ingår en konceptuell modell av en arkitekturbeskrivning. Denna modell se nedan beskriver vad en sådan bör innehålla för att vara förenlig med IEEE Std Observera att en lösningsarkitekt måste anses vara ansvarig för ett systems arkitekturbeskrivning, även om arkitekten inte kan svara för varje del av beskrivningens innehåll. Man kan göra några intressanta observationer i denna modell: Varje system har ett eller flera distinkta uppdrag ( mission ), och dessa uppdrag måste ingå i systemets arkitekturbeskrivning för att den skall vara förenlig med IEEE Std Det här är ett bra exempel på beskrivningsdelar där arkitekten är ansvarig för att de kommer in men knappast för innehållet. Ett systems uppdrag måste definieras av verksamhetsansvariga. Varje system existerar i en miljö, och denna miljö påverkar systemet. Även detta skall ingå i en arkitekturbeskrivning som är förenlig med IEEE Std I systemets miljö ingår andra system som påverkar eller påverkas av systemet. Lägg märke till att ordet system inte inskränker sig till något som har med IT att göra utan med hela verksamhetssystem och delar av sådana. Det är alltså viktigt att arkitektoniskt kunna beskriva vilka verksamhetsdelar ett tänkt system kommer att påverka och vilka det kommer att påverkas av. I miljön ingår också de användare som skall utnyttja systemet. Användar- och användningskrav ingår alltså i den miljö som skall ingå i arkitekturbeskrivningen. Återigen ansvarar lösningsarkitekten för att de blir väl och tillräckligt beskrivna utan att därför nödvändigtvis kunna ta ansvar för innehållet i dessa krav. Innehållet måste komma från användare och områdesexperter; arkitektens ansvar är att få fram dem, ofta att dokumentera dem och alltid att inordna dem i sitt arkitektoniska sammanhang. Varje system har en arkitektur, känd eller okänd. Denna arkitektur är beskriven i en arkitekturbeskrivning (Architectural Description, ofta kallad AD). Varje system har en eller flera intressenter (stakeholders) som var och en har ett antal intressen (concerns) i förhållande till det tänkta systemet. Arkitekturbeskrivningens främsta uppgift är att tillgodose dessa intressenters intressen. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 6

7 Jag har redan nämnt svagheten i begreppet intressent som motsvarighet till originalets stakeholder. På liknande sätt är det svenska begreppet intresse en alltför oprecis översättning av originalets concern. Tittar man i Webster s Dictionary ser man att begreppet concern förklaras på följande sätt: an uneasy state of blended interest, uncertainty, and apprehension. När du tänker i termer av intressenters intressen i ett tänkt system måste du alltså förstå att dessa intressen har en hög angelägenhetsgrad och innehåller ett tydligt element av oro: kommer det här verkligen att bli bra för mig?. Det kan vara av intresse att också se hur IEEE ser på begreppet system stakeholder. Så här förklaras det i dokumentationen: An individual, team or organization (or classes thereof) with interests in, or concerns relative to, a system. Det jag egentligen vill framhålla här är att du förlorar i precision när du använder de svenska begreppen intressent och intressen, och att det är bra att vara medveten om det. Själva föredrar vi på Sundblad & Sundblad att undvika denna förlust genom att använda originaluttrycken stakeholder och concerns. En arkitekturbeskrivning består av ett antal vyer, där varje vy består av en uppsättning modeller. En modell är en abstraktion av något verkligt och kan mycket väl bestå av en löpande text som beskriver det verkliga. Den kan också vara grafisk, som till exempel en datamodell eller en klassmodell uprättad i UML. Varje vy (eller view) är baserad på en så kallad viewpoint, och varje viewpoint är till för att adressera en viss uppsättning stakeholders och att täcka en viss uppsättning stakeholder concerns. Till det ändamålet specificerar varje viewpoint ett antal modeller. Vi vet från vår utbildningsverksamhet att det här med views och viewpoints är litet svårt att ta till sig, förmodligen för att de av IEEE valda begreppen inte riktigt stämmer överens med vårt eget svenska idiom. Jag skall ändå försöka att på kort utrymme klargöra relationerna mellan de båda och användningen av dem. Av erfarenhet vet jag dock att en sådan förklaring blir ännu mer svårsmält om man översätter begreppen till utsiktspunkt och vy så jag gör som i fallen med stakeholder och concern använder mig av svengelska. Hoppas du ursäktar! En viewpoint är en mall för views. Den specificerar vilka stakeholders som skall adresseras och vilka av deras concerns som skall täckas. Den specificerar också vilka modelleringsspråk (där engelska eller svenska är fullt godkända alternativ) för att beskriva någon aspekt av systemet, systemets omgivning eller systemets uppdrag. Views är implementationer av viewpoints. Du kan alltså ha ett förråd av viewpoints, där ingen av dem hanterar något system utan endast är mallar för views. En view beskriver alltid en aspekt på ett enda system och är alltid baserat på en viewpoint. Detta är vad IEEE föreskriver om viewpoints och views. IEEE säger ingenting om vilka viewpoints du bör ha det avgör du helt och hållet själv. Figuren ovan till höger är en standard-viewpoint hämtad ur vårt utbildningsmaterial. Den är något framåtblickande i det att den specificerar ett verktyg och därmed ett modelleringsspråk som ännu inte finns (Microsoft Application Connection Designer). Vi räknar dock med att den kommer att ändras ytterligare något om och i så fall när Microsoft presenterar sitt eget språk och tillhörande verktyg för modellering och hantering av Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 7

8 verksamhetsmodeller. Fram till dess väljer vi bland många tillgängliga alternativ IDEF0, som är en formell standard för modellering av verksamhetsfunktioner och verksamhetsprocesser. En process i processen Arkitekturprocessen är en del av utvecklingsprocessen. Vi får ofta frågan om hur den arkitekturprocess vi förordar stämmer överens med förekommande utvecklingsprocesser som Rational Unified Process (RUP) eller Microsoft Solution Framework (MSF). Vårt svar är alltid att av oss föreslagen arkitekturprocess är oberoende av den utvecklingsprocess företaget i fråga redan använder. Det innebär emellertid inte att man bara utan vidare kan stoppa in vår arkitekturprocess i utvecklingsprocessen. Det skulle säkert gå, men det skulle vara ineffektivt. Man måste först se över vilken redundans som skulle uppstå i de olika artefakter som arkitekturprocessen respektive utvecklingsprocessen föreskriver och sedan förändra någon av dem för att undanröja denna redundans. Man kan emellertid med säkerhet påstå att i varje fall RUP och MSF har brister i sitt sätt att se på arkitektur och arkitektens ansvarsområde. En satsning på arkitekturdriven systemutveckling kräver för alla eller i varje fall de flesta ingrepp i utvecklingsprocessen oavsett hur arkitekturprocessen ser ut. Ett arkitektoniskt ramverk Ett arkitektoniskt ramverk kan vara ett bra sätt att styra arkitekturprocessen. Fadern till idén om sådana ramverk är utan tvekan John Zachman. Han arbetade på 70-talet för IBM med fokus på planering och strategi för utveckling av informationssystem och hjälpte bland annat Boeing att sätta upp planer för deras utveckling av informationssystem. Under det arbetet blev Zachman imponerad av företagets förmåga att tillverka relevanta, komplexa produkter, föra ut dem på en dynamisk marknad, och att underhålla och förändra dem när de väl var byggda. De arbetar sig steg för steg fram från en övergripande affärsmässig beskrivning av en tänkt produkt till en detaljerad beskrivning av de komponenter som behövs för att sätta ihop produkten. De köper en del komponenter och tillverkar andra. De monterar dem sedan till ett flygplan. De provflyger planet, och det flyger! Det är vi inte i närheten av att åstadkomma när vi bygger informationssystem. Det här citatet, hämtat ur minnet, var förmodligen inte en ordagrann översättning av vad Zachman har sagt, men det innefattar ganska väl det han ändå sade. Zachman har också sagt att han lärt sig mycket av flygplansoch byggnadsindustriernas förmåga att åstadkomma sådana relevanta och komplexa produkter och av de processer de använder för att göra det. Zachmans ramverk var från början tänkt för utveckling av enstaka produkter (läs applikationer), för det var det rådande perspektivet vid tiden för ramverkets tillkomst. Han vidareutvecklade det så småningom, och det uttalade syftet blev mer att bygga det elektroniska företaget (the Electronic Enterprise) än applikationer. Därför är det inte vare sig märkligt eller olämpligt att olika initiativ tagits för att ta fram alternativa arkitektoniska ramverk, som ofta är derivat av Zachmans kompletta modell. Microsoft har tagit fram ett sådant, kallat BAIT (för Business, Application, Information och Technology). Avsikten med BAIT var emellertid aldrig att bidra till en formell arkitekturprocess, endast att redovisa fack i vilka man kan stoppa in arkitektoniska artefakter. Det ser vi som en allvarlig brist, och därför har vi utvecklat vårt eget derivat se ovan till höger som påminner både om BAIT och om Zachman men som också skiljer sig från båda. Det är emellertid mera likt Zachman än BAIT, vilket vi inte ser som en nackdel. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 8

9 Figuren visar också att vårt ramverk ger vägledning när det gäller vilka viewpoints man bör hålla sig med och utgå från. En av arkitektens uppgifter vid inledningen av en utvecklingsprocess bör vara att välja viewpoints till sina arkitekturbeskrivningar, och där kan Sundblad & Sundblads ramverk vara till god hjälp. Urfadern till alla arkitektoniska ramverk är emellertid utan tvekan Zachmans ramverk. Vi har hört tydliga signaler om att Microsoft har tagit fram ett nytt ramverk som är mera tydligt baserat på Zachmans ramverk än deras BAIT-ramverk är, och att Microsoft kommer att föra fram detta nya ramverk framför BAIT. Vi tycker det är bra, särskilt som det nya ramverket mer liknar vårt än det liknar BAIT. Vi säger inte det för att antyda att Microsoft skulle ha använt vårt som en utgångspunkt för sitt nya, för så är det inte alls. Men det nya ramverket är mer likt Zachmans än deras tidigare, och det är vårt också. Det innebär att en eventuell anpassning från vårt ramverk till Microsofts nya inte är särskilt problematisk. Vi räknar med att så småningom göra en sådan anpassning, för det finns ingen egentlig poäng i att vara avvikande. Det fanns ett värde i att avvika från BAIT eftersom BAIT inte var till hjälp i arkitekturprocessen; med det nya kommer denna anledning inte att finnas kvar. Ett arkitektoniskt ramverk bör också hjälpa till med urval av beskrivningsartefakter. Figuren ovan till höger också hämtad ur vårt utbildningsmaterial, ger exempel på innehåll i var och en av de celler (läs viewpoints) som är relevanta för arkitekturbeskrivningar. Se dem just som exempel! Varje organisation måste sätta upp sin egen modell för vilka artefakter organisationen vill använda för att tillgodose olika stakeholders behov. Fördelning av utvecklingstid Jag vill gärna avsluta den här artikeln med ännu något från Brooks. I ett kapitel som i likhet med boken heter The Mythical Man-Month har han ett avsnitt som handlar om optimism. Alla programmerare är optimister, säger han. Visserligen är vår industri nu ganska precis dubbelt så gammal som den var 1975 då Brooks skrev boken, men den är fortfarande mycket ung som industri. Brooks fortsätter: Datorer är en ung företeelse, programmerare är ännu yngre, och unga är alltid optimister. Han säger också att vi som mänskliga tillverkare av saker och ting inte blir uppmärksammade på brister och motsägelser i våra tankar och idéer förrän i samband med att de implementeras. Som de optimister vi tenderar att vara tror vi alltid att allting skall gå bra, men om vi inte tänkt igenom dem tillräckligt väl innan vi började implementera dem kommer de att visa sig felaktiga. Då är vår inneboende optimism ogrundad, menar Brooks. För att undvika ogrundad optimism, som alltid spräcker alla tidsuppskattningar när den först visar sig vara ogrundad, använder Brooks följande tumregel när han tidsplanerar ett utvecklingsprojekt: En tredjedel av tillgänglig tid och tillgängliga resurser allokerar Brooks till det han kallar planering. I det ingår analys och dokumentation av krav samt övergripande arkitektur och design. Brooks menar att även om en så stor andel av projektets resurser går till planering räcker det inte om man måste inkludera undersökning av nya teknologier. Endast en sjättedel sätter Brooks av till kodning. En fjärdedel sätter han av till komponenttester och till tidig systemtest. Ytterligare en fjärdedel sätts av till systemtest med alla komponenter inblandade. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 9

10 Kanske allra mest intressant är det att Brooks sätter av halva den tillgängliga produktionstiden till test och att endast en sjättedel av tiden sätts av till kodning. Det är också intressant att han sätter av dubbelt så stora resurser till planering som till kodning. En liten tabell illustrerar förhållandet mellan de olika delarna ännu bättre. Jag har tänkt mig ett projekt om 36 manmånader, eftersom denna siffra lätt går att dividera med både 3, 4 och 6. Fördelningen kommer att se ut så här: Aktivitet Manmånader Planering (Kravanalys, arkitektur, design) 12 Kodning 6 Komponenttest och tidig systemtest 9 Systemtest med alla komponenter tillgängliga 9 Summa 36 Det som gör att det är så svårt att åstadkomma en så stor andel för planering av ett mjukvarusystem är naturligtvis att nästan alla vill komma till kodning så snart som möjligt. Det är först när det börjar finnas något så när körbar kod som det går att se några påtagliga resultat av allt arbete som har lagts ner. Brooks menar att inblandades brådska att få se resultat kan påverka planerat datum för färdigställande av systemet men inte verkligt datum. Han jämför med situationen för en kock: En omelett som utlovats inom två minuter kan se ut att utvecklas på ett positivt sätt under huvuddelen av den utsatta tiden. Men när de två minuterna har gått och omeletten inte har stelnat har kunden två alternativ att välja mellan. Han kan vänta tills den blir färdig eller äta den så gott som rå. Kocken har ytterligare ett alternativ: han kan höja värmen under slutet av de två minuterna, men resultatet blir i varje fall inte gourmetmat utan en omelett som är bränd på den ena sidan och närmast rå på den andra Brooks budskap är tydligt. Det är viktigt att avsätta tillräckligt med tid för att bestämma, dokumentera och kommunicera vad det tänkta systemet skall uträtta. Det är också viktigt att sätta av ordentligt med tid för att planera utformningen arkitektur och övergripande design av de delar systemet skall bestå av. Om allt detta arbete görs med tillräcklig noggrannhet förenklas kodningen rejält. Ändå kommer det att behövas mycket tid för att testa och stabilisera systemet så att det utför de uppgifter det är till för på ett korrekt sätt och att det tillgodoser alla verksamhets- och användarkrav. Vi kan tydligt se att Brooks idéer från 1975 vinner i betydelse. Aldrig tidigare har arkitektur varit så på tapeten i vår industri som nu, och aldrig tidigare har så mycket tid och pengar lagts ner på att utbilda arkitekter och ge dem utrymme tidigt i projekten. Kan det vara så att det vi åstadkommit hittills har visat att det behövs mer av arkitekturinsatser än vi varit beredda att sätta in? Kan det också vara så att den ökade komplexitet vi idag möter, jämfört med tidigare, gjort det uppenbart att vi måste tänka mer i förväg än vi hittills har gjort? Rörelserna XP och Lean Software Development då? Det kan tyckas som om rörelsen mot mer och bättre arkitektur står i djup kontrast mot rörelser som Extreme Programming (XP) och Lean Software Development. Vi menar att det inte är så, men det finns inte utrymme i den här artikeln att utveckla den tanken. Ändå vill vi säga att idéerna bakom Lean Software Development kan genomsyra hela arkitekturprocessen och kanske också bör göra det. När det gäller Extreme Programming finns det på ytan ett tydligt motsatsförhållande mot arkitekur, men det finns absolut inget som hindrar att man använder principerna för XP när man till exempel implementerar en service. XP-programmerarna kommer att ha ett tydligt servicegränssnitt att implementera och kan excellera i parprogrammering, testdriven utveckling och annat inom ramarna för sitt uppdrag. Det kanske till och med är så att man bör använda XP-principer för implementering av services. Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 10

11 Om nästa artikel Därmed sätter vi punkt för januari månads artikel Den blev längre än jag tänkt mig. Jag hade tänkt göra den kortare än de tre artiklarna om SOA, men jag tror faktiskt att det blev tvärtom. Hoppas du har överseende med det och att du skall finna något för dig i den. Februari månads artikel kommer att handla om olika arkitektroller och arkitektens ansvar i förhållande i dessa roller till beställare, användare och utvecklare. Fokus i hela artikelserien, över alla de tre teman som är beslutade, ligger dock även fortsatt på lösningsarkitektens roll och uppdrag. Referenser I Frederick P. Brooks, Jr., The Mythical Man-Month Addison-Wesley, USA. ISBN II III IV V VI Marcus Vitruvius Pollio (Edited by Inrid D. Rowland and Thomas Noble Howe), Ten Books on Architecture Cambridge University Press, United Kingdom. ISBN Alan Cooper & Robert Reimann, About Face 2.0 The Essentials of Interaction Design Wiley Publishing Inc., USA. ISBN Alan Cooper, The Inmates Are Running the Asylum Sams Publishing, USA. ISBN Marvin Trachtenberg, From Pre-History to Postmodernism Prentice Hall, USA. ISBN Paul Clements, Rick Kazman, Mark Klein, Evaluating Software Architectures Addison-Wesley, USA. ISBN X Copyright 2005 Sundblad & Sundblad ADB-Arkitektur AB 11

, Sundblad & Sundblad ADB-Arkitektur, Uppsala Så var det dags att återuppta skrivandet på den artikelserie jag inledde i våras för Microsofts svenska arkitektwebb. Den här gången vänder jag mig minst lika

Läs mer

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell Informationsstruktur 2015:1 Bilaga 7: Arkitektur och metodbeskrivning Innehåll Nationell informationsstruktur arkitektur och metod... 3 Standarder inom informatik... 3 NI relaterat till ISO 42010...

Läs mer

2014-2015 Alla rättigheter till materialet reserverade Easec

2014-2015 Alla rättigheter till materialet reserverade Easec 1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL

Läs mer

Om ämnet Engelska. Bakgrund och motiv

Om ämnet Engelska. Bakgrund och motiv Om ämnet Engelska Bakgrund och motiv Ämnet engelska har gemensam uppbyggnad och struktur med ämnena moderna språk och svenskt teckenspråk för hörande. Dessa ämnen är strukturerade i ett system av språkfärdighetsnivåer,

Läs mer

Planeringsspelets mysterier, del 1

Planeringsspelets mysterier, del 1 Peter Lindberg Computer Programmer, Oops AB mailto:peter@oops.se http://oops.se/ 28 februari 2002 Planeringsspelets mysterier, del 1 Om jag ska spela ett sällskapsspel för första gången så vill jag att

Läs mer

SAS Intelligence Architecture. Patrick Eckemo IT Arkitekt / PM Arkitektur EIP @ SAS Institute

SAS Intelligence Architecture. Patrick Eckemo IT Arkitekt / PM Arkitektur EIP @ SAS Institute SAS Intelligence Architecture Patrick Eckemo IT Arkitekt / PM Arkitektur EIP @ SAS Institute Agenda Inledning vad är arkitektur? Definition Vyer Nivåer av arkitektur Behovet av arkitektur SAS Intelligence

Läs mer

En ansats till behovsstyrd applikationsutveckling

En ansats till behovsstyrd applikationsutveckling Datavetenskap Opponenter: Daniel Mester Pirttijärvi Hampus Skystedt Respondent: Johan Björlin En ansats till behovsstyrd applikationsutveckling Oppositionsrapport, C-nivå 2011:05 1 Sammanfattat omdöme

Läs mer

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur 2016:1 Bilaga 7: Arkitektur och metodbeskrivning Nationell informationsstruktur arkitektur och metodbeskrivning Nationell informationsstruktur (NI) ska bestå av sammanhängande

Läs mer

Användbarhet i sitt sammanhang

Användbarhet i sitt sammanhang Användbarhet i sitt sammanhang Världsanvändbarhetsdagen 2009-11-12 Anders Hedberg, Guide Konsult Stockholm Innehåll En helikoptertur över ett projekts olika faser med belysning på användbarhet i förhållande

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Varje rätt svar ger 0.5 poäng. (max 3p)

Varje rätt svar ger 0.5 poäng. (max 3p) Fråga 1) Följande fråga beaktar skillnaden mellan marknadsdriven och kontraktsdriven produktutveckling. Para ihop varje scenario med det alternativ som passar bäst. A Kontraktsdriven produktutveckling

Läs mer

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? 1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? Att lära sig via metaforer innebär att man drar nytta av kunskap som användaren redan har,

Läs mer

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu. Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund

Läs mer

Informationssystem och databasteknik, 2I-1100

Informationssystem och databasteknik, 2I-1100 Informationssystem och databasteknik, 2I-1100 Introduktion till informationssystem - användning, teknik och utveckling Vad är ett informationssystem? Informationssystem: datoriserat system som stödjer

Läs mer

"Distributed Watchdog System"

Distributed Watchdog System Datavetenskap Emma Henriksson Ola Ekelund Oppositionsrapport på uppsatsen "Distributed Watchdog System" Oppositionsrapport, C-nivå 2005 1 Sammanfattande omdöme på exjobbet Projektet tycks ha varit av

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Tre misstag som äter upp din tid och hur kan göra någonting åt dem

Tre misstag som äter upp din tid och hur kan göra någonting åt dem Tre misstag som äter upp din tid och hur kan göra någonting åt dem En rapport från PersonligEffektivitet.com Innehåll Inledning... 3 Misstag #1: Önskelistan... 4 Misstag #2: Parkinsons lag... 7 Misstag

Läs mer

Vägledning för innovativ applikations- och tjänsteutveckling

Vägledning för innovativ applikations- och tjänsteutveckling Vägledning för innovativ applikations- och tjänsteutveckling Version 2.0 2014-04-15 ARK_0022 Innehåll Inledning... 2 Syfte... 2 Målgrupper... 3 Avgränsning... 3 Vägledningens mallar... 3 Informationsspecifikation...

Läs mer

AffärsCoaching i privata och offentliga organisationer. En praktisk handledning.

AffärsCoaching i privata och offentliga organisationer. En praktisk handledning. Gunnela Westlander, bokanmälan Gunnar Kihlblom: AffärsCoaching i privata och offentliga organisationer. En praktisk handledning. Värmdö: Solid Affärs Coaching. ISBN 978-91-633-8657-2 Coaching är en metod

Läs mer

Mönster. Ulf Cederling Växjö University Ulf.Cederling@msi.vxu.se http://www.msi.vxu.se/~ulfce. Slide 1

Mönster. Ulf Cederling Växjö University Ulf.Cederling@msi.vxu.se http://www.msi.vxu.se/~ulfce. Slide 1 Mönster Ulf Cederling Växjö University UlfCederling@msivxuse http://wwwmsivxuse/~ulfce Slide 1 Beskrivningsmall Beskrivningsmallen är inspirerad av den som användes på AG Communication Systems (AGCS) Linda

Läs mer

Slutrapport Projekt Internet i Sverige

Slutrapport Projekt Internet i Sverige Slutrapport Projekt Internet i Sverige 1. Inledning Wikimedia Sverige är en förening som verkar för att göra kunskap tillgänglig för människor, särskilt genom att stödja Wikimedia Foundations projekt,

Läs mer

Vägledning för krav på dokumenterad information enligt ISO 9001:2015

Vägledning för krav på dokumenterad information enligt ISO 9001:2015 Vägledning för krav på dokumenterad information enligt ISO 9001:2015 1 Orientering Två av de viktigaste målen vid revideringen av standarderna i ISO 9000-serien var att a) utveckla förenklade standarder

Läs mer

1.1. Numeriskt ordnade listor Numerically ordered lists 1.1.1. Enheter med F3= 10 efter fallande F Units with 10 by descending F

1.1. Numeriskt ordnade listor Numerically ordered lists 1.1.1. Enheter med F3= 10 efter fallande F Units with 10 by descending F 1.1. Numeriskt ordnade listor Numerically ordered lists 1.1.1. Enheter med F3= 10 efter fallande F Units with 10 by descending F 1 DET ÄR 2652 282 71 HAR EN 350 140 141 KAN INTE 228 59 2 FÖR ATT 2276 369

Läs mer

MinBaS II. Stenarkitektur. Slutrapport. Mineral Ballast Sten Område 4 Rapport nr 4.7: 101231

MinBaS II. Stenarkitektur. Slutrapport. Mineral Ballast Sten Område 4 Rapport nr 4.7: 101231 MinBaS II Område 4 Applikationsutveckling - stenindustrin Delområde 4 Projekt 4.7 Slutrapport Lennart Selrot och Kurt Johansson Stenindustrins Forskningsinstitut Kristianstad 2011-04-15 Sammanfattning

Läs mer

ENGELSKA. Ämnets syfte. Kurser i ämnet

ENGELSKA. Ämnets syfte. Kurser i ämnet ENGELSKA Det engelska språket omger oss i vardagen och används inom skilda områden som kultur, politik, utbildning och ekonomi. Kunskaper i engelska ökar individens möjligheter att ingå i olika sociala

Läs mer

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare Fibonacci / översättning från engelska IBSE Ett självreflekterande(självkritiskt) verktyg för lärare Riktlinjer för lärare Vad är det? Detta verktyg för självutvärdering sätter upp kriterier som gör det

Läs mer

AL T granskning NeR 2013-01-13. Version 1.0

AL T granskning NeR 2013-01-13. Version 1.0 AL T granskning NeR 2013-01-13 Version 1.0 Revisionshistorik Datum Version Beskrivning Författare 2013-01-13 PA1 Dokumentet skapat AL T, CeHis, Lennart Eriksson 2013-01-31 1.0 Bara gula markeringar inför

Läs mer

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Innehåll Vad är en bra uppsats? Söka, använda och refera till litteratur Insamling

Läs mer

Ämne - Engelska. Ämnets syfte

Ämne - Engelska. Ämnets syfte Ämne - Engelska Det engelska språket omger oss i vardagen och används inom skilda områden som kultur, politik, utbildning och ekonomi. Kunskaper i engelska ökar individens möjligheter att ingå i olika

Läs mer

Objektorienterad analys och design

Objektorienterad analys och design Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 1 Objekt-orienterad analys och design: Litteratur Skansholm: Kapitel 4 Se även 1. http://www.uml.org/ 2. http://www-306.ibm.com/software/rational/uml/

Läs mer

Kursplanering Objektorienterad programmering

Kursplanering Objektorienterad programmering Kursplanering Objektorienterad programmering Fakta Ämne Programmering Poäng 40 Yh-poäng Kurskod YSYS-OOP Klass Systemutvecklare.NET 2 Syfte och koppling till yrkesrollen Syftet är att få en stabil grund

Läs mer

Operatörer och användargränssnitt vid processtyrning

Operatörer och användargränssnitt vid processtyrning Operatörer och användargränssnitt vid processtyrning Normativa och beskrivande analyser Uppsala universitet @ 2003 Anders Jansson Sammanfattning kap. 1 Sociotekniska system Många olika grupper av användare

Läs mer

Preliminär specifikation av projekt

Preliminär specifikation av projekt Preliminär specifikation av projekt Projektets namn: Infraröd Minneslåda (numera omdöpt till FastSync) Uppdragsgivare: Alex Olwal aolwal@cs.columbia.edu Deltagare: Johan Ullberg Nils

Läs mer

1. Inledning, som visar att man inte skall tro på allt man ser. Betrakta denna följd av tal, där varje tal är dubbelt så stort som närmast föregående

1. Inledning, som visar att man inte skall tro på allt man ser. Betrakta denna följd av tal, där varje tal är dubbelt så stort som närmast föregående MATEMATISKA INSTITUTIONEN STOCKHOLMS UNIVERSITET Christian Gottlieb Gymnasieskolans matematik med akademiska ögon Induktion Dag 1 1. Inledning, som visar att man inte skall tro på allt man ser. Betrakta

Läs mer

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1 Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut

Läs mer

ENGELSKA FÖR DÖVA. Ämnets syfte

ENGELSKA FÖR DÖVA. Ämnets syfte ENGELSKA FÖR DÖVA Det engelska språket omger oss i vardagen och används inom skilda områden som kultur, politik, utbildning och ekonomi. Kunskaper i engelska ökar individens möjligheter att ingå i olika

Läs mer

Progressionen i teknikämnets centrala innehåll

Progressionen i teknikämnets centrala innehåll Det centrala innehållet i kursplanen anger vilket obligatoriskt innehåll som ska behandlas i undervisningen. Det är strukturerat så att det visar på en progression. Det innebär att innehållet vidgas och

Läs mer

Visionen om en Tjänstekatalog

Visionen om en Tjänstekatalog Visionen om en Tjänstekatalog Varför ska vi införa tjänster? Copyright BiTA Service Management/Rolf Norrman 1 IT:s värde för verksamheten tydliggörs i verksamhetens egna termer Organisationens kundfokus

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Elevernas uppfattningar om alltmer digitaliserad undervisning

Elevernas uppfattningar om alltmer digitaliserad undervisning Resultat Elevernas uppfattningar om alltmer digitaliserad undervisning Fråga 1 Mycket inspirerande (6) till mycket tråkigt (1) att arbeta med etologisidan Uppfattas som mycket inspirerande eller inspirerande

Läs mer

Skapa en generell informationsmodell?

Skapa en generell informationsmodell? Sven-Håkan Olsson Konsult, arkitekt och utvecklare Oberoende konsult och teknikentreprenör Skapa en generell informationsmodell? Sven-Håkan Olsson måndag 11 aug 14 TEKNIK En generell, kanonisk informationsmodell

Läs mer

Nätkurs Design & konstruktion av användargränssnitt 1MD113 Sid 1 (5) Lektion 11 Användare, uppgifter och krav del

Nätkurs Design & konstruktion av användargränssnitt 1MD113 Sid 1 (5) Lektion 11 Användare, uppgifter och krav del Nätkurs Design & konstruktion av användargränssnitt 1MD113 Sid 1 (5) Del 3 Uppgiftsanalys Av Stefan Blomkvist Uppgiftsanalysen ska svara på frågor om vilka uppgifter användarna utför och hur dessa genomförs.

Läs mer

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 Document: STG/PS K 525SV1 Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 SIS, Projekt Kvalitetsledning 1 1) Introduktion Produktstöd Två av de viktigaste målsättningarna i arbetet

Läs mer

Formativ bedömning i matematikklassrummet

Formativ bedömning i matematikklassrummet Modul: Taluppfattning och tals användning Del 4: Formativ bedömning Formativ bedömning i matematikklassrummet Peter Nyström, NCM Termen bedömning, eller pedagogisk bedömning kan uppfattas väldigt olika,

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Irland nr. 003. Progressive Systems Enterprise Limited

Irland nr. 003. Progressive Systems Enterprise Limited Irland nr. 003 Progressive Systems Enterprise Limited En av våra unika egenskaper är att vi förenar teknologi med affärsskicklighet på marknaden. Vi är stolta över vår förmåga att förstå affärsproblem

Läs mer

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram 2EMHNWRULHQWHUDG5HDOWLGVSURJUDPPHULQJ Föreläsning 7 OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram - Kravspecifikationer, användningsfall, systemarkitektur - Analysfas vad är analys?

Läs mer

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Undervisningen i ämnet engelska ska ge eleverna förutsättningar att utveckla följande:

Undervisningen i ämnet engelska ska ge eleverna förutsättningar att utveckla följande: ENGELSKA Det engelska språket omger oss i vardagen och används inom skilda områden som kultur, politik, utbildning och ekonomi. Kunskaper i engelska ökar individens möjligheter att ingå i olika sociala

Läs mer

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

PROGRAMMERING. Ämnets syfte. Kurser i ämnet PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration

Läs mer

Objektorienterad programmering

Objektorienterad programmering Objektorienterad programmering Emil Ahlqvist (c10eat@cs.umu.se) Didrik Püschel (dv11dpl@cs.umu.se) Johan Hammarström (c08jhm@cs.umu.se) Hannes Frimmel Moström (c10hml@cs.umu.se) 1 1. Introduktion 1.1 Objektorienterad

Läs mer

Lars Wiktorin, IT plan

Lars Wiktorin, IT plan Lars Wiktorin, IT plan lars.wiktorin@itplan.se 2001-10-24 / Lars Wiktorin SESAM Höstseminarium 2001 1 2001-10-24 / Lars Wiktorin SESAM Höstseminarium 2001 2 Allt eller delar av? Vision konkretisering av

Läs mer

En dansk version av detta dokument kan laddas ned här: http://itu.dk/ people/hagerman/retningslinjer.pdf (pdf, 500 kb)

En dansk version av detta dokument kan laddas ned här: http://itu.dk/ people/hagerman/retningslinjer.pdf (pdf, 500 kb) Denna guide är till för folk som gör hemsidor med Öresundsregionen som målgrupp. Vilket språk är bäst att använda sig av - danska, svenska eller eventuellt bägge? - eller kanske engelska? Hur riktar man

Läs mer

SCRUM och mycket mer

SCRUM och mycket mer Typ av dokument Anvisning Skapad Senaste uppdatering 2008-01-27 2008-11-13 1 (5) Sida 1 Det minsta möjliga? SCRUM och mycket mer Om man nu vill vara agile och inte har allt tid i världen, vad skall man

Läs mer

Lyckade projekt - finns det?

Lyckade projekt - finns det? Lyckade projekt - finns det? Maria Lindqvist Björkman Enea Business Software Enea Business Software 2002 Sida 1 Agenda Förväntningar kund & leverantör Statistik om projekt Framgångsfaktorer Exempel på

Läs mer

Martin Völcker, SLL & Suit

Martin Völcker, SLL & Suit 1 2009-02-03 DSDM Martin Völcker, SLL & Suit martin.volcker@suit.se Tel: 08-648 70 00 Mobil:0708-252424 Mentorskap - Projektledning - Utbildning- Workshops 2 2009-02-03 Oklara krav Oklara roller Försenade

Läs mer

Bonus Rapport Kommersiell Design KTH

Bonus Rapport Kommersiell Design KTH Bonus Rapport Kommersiell Design KTH Johan Holmström & Lars Åkesson Introduktion Denna rapport beskriver projektet och delmomentet Kommersiell Design i kursen Interaktionsdesign 2 på KTH i Stockholm. Detta

Läs mer

Att skriva en ekonomisk, humanistisk eller samhällsvetenskaplig rapport

Att skriva en ekonomisk, humanistisk eller samhällsvetenskaplig rapport Att skriva en ekonomisk, humanistisk eller samhällsvetenskaplig rapport Eventuell underrubrik Förnamn Efternamn Klass Skola Kurs/ämnen Termin Handledare Abstract/Sammanfattning Du skall skriva en kort

Läs mer

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys Användbarhet och Webbutveckling för mobila enheter Behovsanalys Kurshemsidan Böcker mobilutveckling Dokumentation/Inlämningar Kommer på hemsidan (tills på måndag?) Nästa vecka: Planeringsdokument (Scrum)

Läs mer

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga

Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Förändringsstrategi anpassad till just din organisations förutsättningar och förmåga Att bedriva effektiv framgångsrik förändring har varit i fokus under lång tid. Förändringstrycket är idag högre än någonsin

Läs mer

Kataloghantering i Ariba kompletterande information om Partial Items & Parametric Data

Kataloghantering i Ariba kompletterande information om Partial Items & Parametric Data Kataloghantering i Ariba kompletterande information om Partial Items & Parametric Data Innehåll Roller/ansvarsområden Definitioner Partial Item Parametric Data Syntax Partial Item Parametric Data Exempel

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

RIKTLINJER FÖR GRANSKNING AV GEMENSKAPSVARUMÄRKEN VID KONTORET FÖR HARMONISERING INOM DEN INRE MARKNADEN (VARUMÄRKEN OCH MÖNSTER) DEL C INVÄNDNING

RIKTLINJER FÖR GRANSKNING AV GEMENSKAPSVARUMÄRKEN VID KONTORET FÖR HARMONISERING INOM DEN INRE MARKNADEN (VARUMÄRKEN OCH MÖNSTER) DEL C INVÄNDNING RIKTLINJER FÖR GRANSKNING AV GEMENSKAPSVARUMÄRKEN VID KONTORET FÖR HARMONISERING INOM DEN INRE MARKNADEN (VARUMÄRKEN OCH MÖNSTER) DEL C INVÄNDNING AVSNITT 2 IDENTITET OCH FÖRVÄXLINGSRISK KAPITEL 5 DOMINERANDE

Läs mer

Design. Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering sammanfa0ning 13/04/14

Design. Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering sammanfa0ning 13/04/14 Design Vad är design? Vad är arkitektur? Architectural Pa:erns Designprinciper Design Pa:erns UML Domain Driven Design Domänmodell Vad lärde jag mig förra lekfonen? Hur bidrog jag Fll lärandet? Kravhantering

Läs mer

Utdrag från kapitel 1

Utdrag från kapitel 1 Utdrag från kapitel 1 1.1 Varför en bok om produktionsutveckling? Finns det inte böcker om produktion så att det räcker och blir över redan? Svaret på den frågan är både ja och nej! Det finns många bra

Läs mer

Människa-Datorinteraktion

Människa-Datorinteraktion Människa-Datorinteraktion Grundutbildnings-, forskarutbildnings- och forskningsämne som behandlar Gränssnitt och kommunikation människa-dator Kommunikation och samarbete människa-människa via (medierat

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Statligt stöd för miljö- och sociala frågor till små och medelstora företag - en jämförande studie mellan Sverige och Storbritannien

Statligt stöd för miljö- och sociala frågor till små och medelstora företag - en jämförande studie mellan Sverige och Storbritannien I ett examensarbete från Sveriges Lantbruksuniversitet (SLU) av Katarina Buhr och Anna Hermansson i samverkan med Nutek, jämförs det statliga stödet till små och medelstora företags arbete med miljöoch

Läs mer

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg Automation Region Affärsdriven systemutveckling genom agila metoder Stefan Paulsson Thomas Öberg Frontit Frontit är ett svenskt konsultföretag i gränslandet mellan Management & IT, som stärker sina kunders

Läs mer

Progressionsuttryck i kunskapskraven Kommentarerna till progressionsuttrycken i kunskapskraven gäller för engelska språk 5 7.

Progressionsuttryck i kunskapskraven Kommentarerna till progressionsuttrycken i kunskapskraven gäller för engelska språk 5 7. Progressionsuttryck i kunskapskraven Kommentarerna till progressionsuttrycken i kunskapskraven gäller för engelska språk 5 7. Eleverna ska ges möjlighet att utveckla de förmågor som uttrycks i målen genom

Läs mer

Mentorprogram Real diversity mentorskap Att ge adepten stöd och vägledning Adeptens personliga mål Att hantera utanförskap

Mentorprogram Real diversity mentorskap Att ge adepten stöd och vägledning Adeptens personliga mål Att hantera utanförskap Mentorprogram Real diversity mentorskap Real diversity är ett projekt som fokuserar på ungdomar i föreningsliv och arbetsliv ur ett mångfaldsperspektiv. Syftet med Real diversity är att utveckla nya metoder

Läs mer

10 TIPS - ditt eget recept För balans och framgång!

10 TIPS - ditt eget recept För balans och framgång! 10 TIPS - ditt eget recept För balans och framgång! Kenth Åkerman Det är värt vilket pris som helst att få se en slocknad blick lysa upp på nytt, få se ett leende tändas hos den som tycktes ha glömt att

Läs mer

Sammanfattning av rapport 2011/12:RFR5 Näringsutskottet. ehälsa nytta och näring

Sammanfattning av rapport 2011/12:RFR5 Näringsutskottet. ehälsa nytta och näring Sammanfattning av rapport 2011/12:RFR5 Näringsutskottet ehälsa nytta och näring ehälsa nytta och näring Förord I Sverige finns goda förutsättningar att förbättra vården och omsorgen med hjälp av moderna

Läs mer

Frågor och svar om tekniska rapporter

Frågor och svar om tekniska rapporter Frågor och svar om tekniska rapporter Frågorna är ordnade efter rapportens struktur Titelsidan Hur ska titelsidan se ut? Universitet, program, kurs, termin, datum och år. Författarnamn och e-postadresser,

Läs mer

Skriva en sammanfattning 10 steg till framgång

Skriva en sammanfattning 10 steg till framgång Skriva en sammanfattning 10 steg till framgång SAMMANFATTA: i en enhetlig (i sht kortfattad o. översiktlig) framställning redogöra för (vissa företeelser, åsikter, intryck o dyl.) och det väsentliga av

Läs mer

DESIGNSTUDIO SPEL TEAM TONTOY. Patrik Lundin : : XXXX HÖGSKOLAN I HALMSTAD Digital Design och Innovation

DESIGNSTUDIO SPEL TEAM TONTOY. Patrik Lundin : : XXXX HÖGSKOLAN I HALMSTAD Digital Design och Innovation DESIGNSTUDIO SPEL Patrik Lundin : patlun14@student.hh.se : 840421-XXXX HÖGSKOLAN I HALMSTAD Digital Design och Innovation Designstudio < > Spel TEAM TONTOY Introduktion Under designstudio spel arbetade

Läs mer

Samma krav gäller som för ISO 14001

Samma krav gäller som för ISO 14001 Förordning (2009:907) om miljöledning i statliga myndigheter Relaterat till motsvarande krav i ISO 14001 och EMAS De krav som ställs på miljöledningssystem enligt EMAS är samma som ingår i ISO 14001. Dessutom

Läs mer

Diagnos och design av Verksamhet och IT, 7, 5 HP. Föreläsning 2 Sofie Pilemalm

Diagnos och design av Verksamhet och IT, 7, 5 HP. Föreläsning 2 Sofie Pilemalm Diagnos och design av Verksamhet och IT, 7, 5 HP Föreläsning 2 Sofie Pilemalm Dagens Agenda Systemutveckling i backspegeln och för framtiden Problem och utmaningar Användarcentrerad utveckling Som del

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

Köpguide för mobila växlar. Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan.

Köpguide för mobila växlar. Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan. Köpguide för mobila växlar Modern telefoni till företaget är långt ifrån vad det var för bara några år sedan. Tänk om din nya telefonilösning kunde förenkla din vardag och hjälpa dina medarbetare att arbeta

Läs mer

Anpassningsbar applikationsstruktur för flerpunktsskärmar

Anpassningsbar applikationsstruktur för flerpunktsskärmar Datavetenskap Opponent(er): Rikard Boström Lars-Olof Moilanen Respondent(er): Mathias Andersson Henrik Bäck Anpassningsbar applikationsstruktur för flerpunktsskärmar Oppositionsrapport, C/D-nivå 2005:xx

Läs mer

Introduktion. Byggstenar TDBA63 2005-11-22

Introduktion. Byggstenar TDBA63 2005-11-22 Introduktion UML står för Unified Modeling Language. Det är tänkt att fungera som hjälpmedel vid modellering av alla tänkbara typer av utvecklingsarbeten, inte bara inom dataomdrådet. Det största värdet

Läs mer

Att arbeta tillsammans Grupparbete, projekt och allt sånt

Att arbeta tillsammans Grupparbete, projekt och allt sånt Översikt Att arbeta tillsammans Grupparbete, projekt och allt sånt Vad är en grupp? Hur utvecklas en grupp? Vad är ett projekt? Hur funkar projektet i den här kursen? Föreläsning 4 i perspektivkurserna

Läs mer

[SLUTRAPPORT: DRAWPIXLZ (ANDROID-APP)] Slutrapport. Författare: Zlatko Ladan. Program: Utvecklare av Digitala Tjänster 180P

[SLUTRAPPORT: DRAWPIXLZ (ANDROID-APP)] Slutrapport. Författare: Zlatko Ladan. Program: Utvecklare av Digitala Tjänster 180P Slutrapport Författare: Zlatko Ladan Program: Utvecklare av Digitala Tjänster 180P Kurs: Individuellt Mjukvaruprojekt Z l a t k o L a d a n Sida 1 Abstrakt: Denna rapport handlar om mitt projekt som jag

Läs mer

Från Data till Process

Från Data till Process Från Data till Process - Om bryggor och annat KommITS 17 nov 2005 Perspektiv och definitioner SOA för utvecklare: Service orientation är ett sätt skapa dynamiska, samverkande och löst kopplade applikationer.

Läs mer

0HG HXURSHLVNW GLJLWDOW LQQHKnOO EHKnOOHUYLOHGQLQJHQ

0HG HXURSHLVNW GLJLWDOW LQQHKnOO EHKnOOHUYLOHGQLQJHQ 63((&+ (UNNL/LLNDQHQ Ledamot av Europeiska kommissionen med ansvar för näringspolitik och informationssamhället 0HG HXURSHLVNW GLJLWDOW LQQHKnOO EHKnOOHUYLOHGQLQJHQ Norden digitalt konferens +HOVLQJIRUVGHQRNWREHU

Läs mer

Undervisningen i ämnet moderna språk ska ge eleverna förutsättningar att utveckla följande:

Undervisningen i ämnet moderna språk ska ge eleverna förutsättningar att utveckla följande: MODERNA SPRÅK Moderna språk är ett ämne som kan innefatta en stor mängd språk. Dessa kan sinsemellan vara mycket olika vad gäller allt från skriftsystem och uttal till utbredning och användning inom skiftande

Läs mer

Decentraliserad administration av gästkonton vid Karlstads universitet

Decentraliserad administration av gästkonton vid Karlstads universitet Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå

Läs mer

Cloud Computing för arkitekter Sten Sundblad IASA och Sundblad & Sundblad

Cloud Computing för arkitekter Sten Sundblad IASA och Sundblad & Sundblad Cloud Computing för arkitekter Sten Sundblad IASA och Sundblad & Sundblad Är Cloud Computing intressant? 40 % tillväxt globalt 2009. Blir likadant i Sverige! Computer Sweden/IDC 2009-03-06 USA 2008 23

Läs mer

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad

Läs mer

Design för bättre affärer Fakta och kommentarer utifrån en undersökning om design i svenska företag, genomförd på uppdrag av SVID, Stiftelsen Svensk

Design för bättre affärer Fakta och kommentarer utifrån en undersökning om design i svenska företag, genomförd på uppdrag av SVID, Stiftelsen Svensk Design för bättre affärer Fakta och kommentarer utifrån en undersökning om design i svenska företag, genomförd på uppdrag av SVID, Stiftelsen Svensk Industridesign, Teknikföretagen och Svensk Teknik och

Läs mer

SPÅRFORDONSTEKNIK. Ämnets syfte

SPÅRFORDONSTEKNIK. Ämnets syfte SPÅRFORDONSTEKNIK Ämnet spårfordonsteknik behandlar funktion hos samt service och reparation av spårfordon. Det behandlar även spårfordons olika användningsområden och branschens olika arbetsområden. Ämnet

Läs mer

Föreläsning om OO, OOA och UML

Föreläsning om OO, OOA och UML Föreläsning om OO, OOA och UML Modellering Kristian Ekberg Källa bild: video Marie Åsberg, AFA Försäkring Dagens föreläsning Presentation Kristian Ekberg Model och modellering Vad är en modell och vad

Läs mer

Föreläsning 1, vecka 6: Abstraktion genom objektorientering

Föreläsning 1, vecka 6: Abstraktion genom objektorientering TDA 548: Grundläggande Programvaruutveckling Föreläsning 1, vecka 6: Abstraktion genom objektorientering Magnus Myréen Chalmers, läsperiod 1, 2016-2017 Hur skulle ni implementera detta? (3D demo) Vi återkommer

Läs mer

FÖRSLAG TILL KURSPLAN INOM KOMMUNAL VUXENUTBILDNING GRUNDLÄGGANDE NIVÅ

FÖRSLAG TILL KURSPLAN INOM KOMMUNAL VUXENUTBILDNING GRUNDLÄGGANDE NIVÅ Engelska, 450 verksamhetspoäng Ämnet handlar om hur det engelska språket är uppbyggt och fungerar samt om hur det kan användas. Det engelska språket omger oss i vardagen och används inom så skilda områden

Läs mer

Rekommenderade Arkitektroller inom IT i Sverige

Rekommenderade Arkitektroller inom IT i Sverige Rekommenderade Arkitektroller inom IT i Sverige IASA Sweden Beslut om publicering: IASA styrelse, oktober 2007 Revision 1.0 Innehåll 1 Introduktion... 3 2 Metodik - Arkitektur på flera nivåer och med olika

Läs mer