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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

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

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

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

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

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

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

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

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

Läs mer

1 Ramverk för interoperabilitet och återanvändbarhet i e-förvaltningen

1 Ramverk för interoperabilitet och återanvändbarhet i e-förvaltningen PM 1 (6) 2007-05-25 1 Ramverk för interoperabilitet och återanvändbarhet i e-förvaltningen (Texten är baserad på ett kapitel i Vervas rapport om att utveckla och använda gemensamma kravspecifikationer,

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

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

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

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

AvI-index. Ett instrument för att mäta IT-systems användbarhet

AvI-index. Ett instrument för att mäta IT-systems användbarhet ANDERS GUNÉR AvI-index Ett instrument för att mäta IT-systems användbarhet Iordanis Kavathatzopoulos Uppsala universitet ISBN 978-91-976643-5-6 Copyright 2008 Iordanis Kavathatzopoulos. Uppsala universitet,

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

men borde vi inte också testa kraven? Robert Bornelind

men borde vi inte också testa kraven? Robert Bornelind men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST 15 års jubileum 14 oktober 2010 SQS Software Quality Systems Nordic Innehåll Introduktion Kvalitet, tid och kostnad Process Testning

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

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

Modell för ledning av kundorienterad och systematisk verksamhetsutveckling (fd Utmärkelsen) Göteborgs stad

Modell för ledning av kundorienterad och systematisk verksamhetsutveckling (fd Utmärkelsen) Göteborgs stad Modell för ledning av kundorienterad och systematisk verksamhetsutveckling (fd Utmärkelsen) Göteborgs stad Innehållsförteckning 1 Frågor... 5 1.1 KUNDEN I FOKUS... 5 1.1.1 Hur tar ni reda på kundernas

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

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

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

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

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

Analys av BI-system och utveckling av BIapplikationer

Analys av BI-system och utveckling av BIapplikationer Computer Science Fredrik Nilsson, Jonas Wånggren Daniel Strömberg Analys av BI-system och utveckling av BIapplikationer Opposition Report, C/D-level 2005:xx 1 Sammanfattat omdöme av examensarbetet Vi tycker

Läs mer

Certifierad IT-arkitekt

Certifierad IT-arkitekt Certifierad IT-arkitekt En utbildning med sex fristående tvådagarsavsnitt och 100 timmar lärarledd utbildning, samt självstudier Har du och ditt företag kompetensen att välja den lämpligaste tekniska lösningen?

Läs mer

Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter

Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter Mohammad Honarbakhsh 2013 01 11 073 784 22 74 mo.honar@wisebs.com www.wisebs.com Ms Office Ms Word, Ms Outlook, Ms PowerPoint, Ms

Läs mer

Objekt-orienterad programmering. Klassbegreppet och C++ UML. UMLs fördelar

Objekt-orienterad programmering. Klassbegreppet och C++ UML. UMLs fördelar Klassbegreppet och C++ OOP UML Klasser och objekt i C++ Uppdelning i filer Attribut och metoder Inkappsling - åtkomst Klassattribut - objektattribut Objekt-orienterad programmering Att använda ett objektorienterat

Läs mer

Kort om kursplanen i teknik

Kort om kursplanen i teknik Kort om kursplanen i teknik är ett sammandrag av Skolverkets kursplan i teknik från Läroplan för grundskolan, förskoleklassen och fritidshemmet 2011 1 samt Kommentarmaterial till kursplanen i teknik 2.

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

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5)

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5) Läs mig först Stockholms stad SOA-plattform 1 (5) Innehållsförteckning 1 Beskrivning av SDK 3 1.1 Software Developer Kit för Utvecklare... 3 1.2 Support för... 3 1.3 Omfattning... 4 1.4 Versionshantering...

Läs mer

3. Kursplaner 3.1 BILD. Syfte

3. Kursplaner 3.1 BILD. Syfte BL BILD 3. Kursplaner 3.1 BILD Bilder har stor betydelse för människors sätt att tänka, lära och uppleva sig själva och omvärlden. Vi omges ständigt av bilder som har till syfte att informera, övertala,

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

Se upp med Oracle och SAP

Se upp med Oracle och SAP Överlever dagens affärssystem en tjänsteorientering i moln? Eskil Swende, seniorkonsult och partner, IRM Se upp med Oracle och SAP Det är inte så lätt att baxa in kolossalprodukter som Oracle databas och

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

Centralt innehåll. Bildframställning. Redskap för bildframställning. Bildanalys. Bildframställning. Redskap för bildframställning.

Centralt innehåll. Bildframställning. Redskap för bildframställning. Bildanalys. Bildframställning. Redskap för bildframställning. BILD Bilder har stor betydelse för människors sätt att tänka, lära och uppleva sig själva och omvärlden. Vi omges ständigt av bilder som har till syfte att informera, övertala, underhålla och ge oss estetiska

Läs mer

Utforma säkerhetsprocesser

Utforma säkerhetsprocesser Utforma säkerhetsprocesser www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

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

Att skriva en vetenskaplig rapport

Att skriva en vetenskaplig rapport Att skriva en vetenskaplig rapport Eventuell underrubrik Förnamn Efternamn Klass Skola Kurs/ämnen Termin Handledare Abstract/Sammanfattning Du skall skriva en kort sammanfattning som är en koncentrerad

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

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

Digital strategi för Uppsala kommun 2014-2017

Digital strategi för Uppsala kommun 2014-2017 KOMMUNLEDNINGSKONTORET Handläggare Datum Diarienummer Sara Duvner 2014-04-23 KSN-2014-0324 Digital strategi för Uppsala kommun 2014-2017 - Beslutad av kommunstyrelsen 9 april 2014 Postadress: Uppsala kommun,

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

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport

Collector en Android-app för att samla saker. Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Collector en Android-app för att samla saker Kim Grönqvist (kg222dk) 2013-06-10 Slutrapport Abstrakt Jag har gjort en Android-app för att samla saker, Collector. Med den kan man upprätta att göra-listor

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

Agile-metoder, XP och ACSD

Agile-metoder, XP och ACSD Användarcentrerad systemdesign. Föreläsning 12 Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, stefan.blomkvist@it.uu.se & Profdoc AB www.profdoc.se www.it.uu.se/edu/course /homepage/acsd/s04 XP

Läs mer

Steget efter CAD Data Management. Per Ekholm

Steget efter CAD Data Management. Per Ekholm Steget efter CAD Data Management Per Ekholm Agenda Vilka processer/discipliner stöds i PDMLink Dokument management Configuration Management Change Management Project Management Hur utvärderar jag behovet?

Läs mer

Om IT är svaret hur lyder då frågan?

Om IT är svaret hur lyder då frågan? Om IT är svaret hur lyder då frågan? Om IT är svaret HUR LYDE R DÅ FRÅGA N? Allt för ofta har nya tekniska verktyg utmålats som lösningen på våra verksamheters problem och utmaningar och vi på IT-sidan

Läs mer

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1 " Scrum Scrum en beskrivning a description 1" 1 Scrums principer Värderingar från Agile Manifesto Scrum är mest känt av de agila arbetssätten. Agile Manifesto utgör en gemensam bas för att arbeta agilt

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

Utveckling av simulator för ärendehanteringssystem

Utveckling av simulator för ärendehanteringssystem Datavetenskap Opponent(er): Emil Danielsson & Patrik Lundberg Respondent(er): Niclas Hanold & Samiar Saldjoghi Utveckling av simulator för ärendehanteringssystem Oppositionsrapport, C/D-nivå 2005:xx 1

Läs mer

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Grupp 6 Ali Abid Kjell Nilsson Patrick Larsson Mälardalens högskola KN3060, Produktutveckling med

Läs mer

ANSVARSFULL ARKITEKTUR

ANSVARSFULL ARKITEKTUR OM WHITE ANSVARSFULL ARKITEKTUR Människans inverkan får allt tydligare konsekvenser för det ekologiska system vi alla tillhör. Aldrig har en generation behövt bry sig så mycket om vad som händer med jorden

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

FÖRETAG SOM VÄXER. Sveriges Arkitekter 4:e mars 2015

FÖRETAG SOM VÄXER. Sveriges Arkitekter 4:e mars 2015 FÖRETAG SOM VÄXER Sveriges Arkitekter 4:e mars 2015 JOHN LYDHOLM Vd Sverige LINDA SANTESSON Avdelningschef, region Öst Vad får ett företag att växa? Vilka utmaningar finns i en växande organisation? Vad

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

Nya möjligheter med M3 Technology. Björn Svensson, Björn Torold

Nya möjligheter med M3 Technology. Björn Svensson, Björn Torold Nya möjligheter med Technology Björn Svensson, Björn Torold Vem är vi? 2 Copyright 2011 Lawson. All rights reserved. Nya möjligheter med Technology System Foundation Grid Förändrar basen i Installation

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

Exempel på verklig kravspecifikation

Exempel på verklig kravspecifikation Exempel på verklig kravspecifikation Detta är ett exempel på en proffessionell kravspecifikation hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och

Läs mer

POLISENS LEDARKRITERIER

POLISENS LEDARKRITERIER MÅL OCH RESULTAT Det innebär att styra och driva mot angivna mål och att se vad som gagnar på såväl kort som lång sikt. Ha god uthållighet och förmåga att ha målen i sikte även när händelseutvecklingen

Läs mer

Insikt. kräver kunskap, erfarenhet och förståelse

Insikt. kräver kunskap, erfarenhet och förståelse Insikt kräver kunskap, erfarenhet och förståelse Målet är utveckling... håller inte måttet Företag med teknologibaserad utveckling står idag inför många utmaningar. Den viktigaste är utan tvekan förmågan

Läs mer

Molntjänster -- vad är molnet?

Molntjänster -- vad är molnet? En e-bok från Visma Spcs Molntjänster -- vad är molnet? Vad du bör tänka på för att göra rätt val till ditt företag Molntjänster -- vad är molnet? En guide till att förstå molntjänster Innehåll Hänger

Läs mer

Unit testing methodology

Unit testing methodology Department of Computer Science Per Hurtig Stefan Lindberg & Fredrik Strandberg Unit testing methodology Opposition Report, C/D-level 2005:xx 1 Övergripande utvärdering Helhetsintrycket av uppsatsen är

Läs mer

GYMNASIEARBETET - ATT SKRIVA VETENSKAPLIGT

GYMNASIEARBETET - ATT SKRIVA VETENSKAPLIGT GYMNASIEARBETET - ATT SKRIVA VETENSKAPLIGT Ditt gymnasiearbete ska bygga kring den frågeställning du kommit fram till i slutet av vårterminen i årskurs 2 och du ska i ditt arbete besvara din frågeställning

Läs mer

Presentation av IT-utbildningar. Vidareinformatörsdag 2015-02-18 Anna Palmquist

Presentation av IT-utbildningar. Vidareinformatörsdag 2015-02-18 Anna Palmquist Presentation av IT-utbildningar Vidareinformatörsdag 2015-02-18 Anna Palmquist Våra utbildningar Systemarkitekt (SA) Systemvetare (SV) Dataekonom (DE) Affärsinformatiker (IMIT) Akademiska ämnen Systemarkitekt

Läs mer

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström.

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström. Författare Per Johansson, Henrik Wallinder Generellt Helhetsintrycket från genomläsning av uppsatsen

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

Information Management made simple

Information Management made simple Information Management made simple Genom fullständigt stöd för dokument hantering tillsammans med inbyggd ärendehantering och nämndadministration erbjuds ett komplett informationsstöd som påtagligt underlättar

Läs mer

Chefsarkitekten förstärker individerna och säkerställer nyttan med arkitekturen. Eva Kammerfors Alexander Novella

Chefsarkitekten förstärker individerna och säkerställer nyttan med arkitekturen. Eva Kammerfors Alexander Novella Chefsarkitekten förstärker individerna och säkerställer nyttan med arkitekturen Eva Kammerfors Alexander Novella Marknaden rör sig! 3 Hur passar det in med övriga processer? oklart blir till att bygga

Läs mer

Serviceorienterad arkitektur och processer Sten Sundblad, Sundblad & Sundblad ADB-Arkitektur, Uppsala

Serviceorienterad arkitektur och processer Sten Sundblad, Sundblad & Sundblad ADB-Arkitektur, Uppsala , Sundblad & Sundblad ADB-Arkitektur, Uppsala Det här är den tredje och (för tillfället) sista artikeln om serviceorienterad arkitektur för Microsofts arkitektwebb, som under kvartalet oktober december

Läs mer

Verksamhetsanalys enligt BABOK Konsten att göra rätt sak!

Verksamhetsanalys enligt BABOK Konsten att göra rätt sak! Verksamhetsanalys enligt BABOK Konsten att göra rätt sak! I den alltmer komplexa organisations- och projektmiljö vi lever i så är det kritiskt att ha kunniga verksamhetsanalytiker som fokuserar på intressenter

Läs mer

1. Ni vet själva, bröder, att vår insats hos er inte var förgäves.

1. Ni vet själva, bröder, att vår insats hos er inte var förgäves. 1 Tessalonikerbrevet 2 (2:1 16) Apostelns tjänst i Tessalonika 1 Ni vet själva, bröder, att vår insats hos er inte var förgäves. 2 Tidigare hade vi, som ni vet, plågats och misshandlats i Filippi, men

Läs mer

Måldriven, informationscentrerad webbdesign

Måldriven, informationscentrerad webbdesign Måldriven, informationscentrerad webbdesign Linus Forsell Digitala Distributionsformer vid Högskolan Väst, Trollhättan, Sverige linus.forsell@student.hv.se 1 Abstrakt I den här essän kommer måldriven och

Läs mer

Distribuerade affärssystem

Distribuerade affärssystem Distribuerade affärssystem Kursens mål Bygga upp, strukturera och programmera distribuerade system med en flerskiktsarkitektur Beskriva och förklara teorier och uttryck som används inom affärskritiska

Läs mer

Using SharePoint Workflow

Using SharePoint Workflow Datavetenskap Opponent(er): Anders Olsson Marcus Karlsson Respondent(er): Harald Quist Creating a Help Desk Using SharePoint Workflow Oppositionsrapport, C-nivå 2009:xx 1 Sammanfattat omdöme av examensarbetet

Läs mer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete Projektmetodik II HF1005, Informationsteknik och ingenjörsmetodik för Datateknik Projektarbete Förväntade resultatet är t.ex. en produkt Vi behöver arbeta med Analys Faktainsamling Genomförande Rapportering

Läs mer

2007 07 15 Vår ref Pär Trehörning. Yttrande Allmänhetens tillgång till handlingar från Europeiska gemenskapens institutioner KOM (2007) 185, slutlig

2007 07 15 Vår ref Pär Trehörning. Yttrande Allmänhetens tillgång till handlingar från Europeiska gemenskapens institutioner KOM (2007) 185, slutlig 2007 07 15 Vår ref Pär Trehörning EU-kommissionen Yttrande Allmänhetens tillgång till handlingar från Europeiska gemenskapens Det är viktigt att yttrandefrihet, tryckfrihet och offentlighet inte enbart

Läs mer

Övergripande granskning av ITverksamheten

Övergripande granskning av ITverksamheten Övergripande granskning av ITverksamheten Februari 2006 (1) 1. Inledning PricewaterhouseCoopers (PwC) har på uppdrag av kommunrevisionen i Borås Stad genomfört en övergripande granskning av Borås Stads

Läs mer

Testning som beslutsstöd

Testning som beslutsstöd Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten

Läs mer

Wireframe när, vad, hur och varför?

Wireframe när, vad, hur och varför? Wireframe när, vad, hur och varför - 1 Wireframe när, vad, hur och varför? Arbetsflöde är ett samlande begrepp för alla steg som används för att göra en webbplats. Från första början till färdig sajt.

Läs mer

SVAR 2012-01-10. Enheten för fastighetsrätt och associationsrätt Stefan Pärlhem 103 33 STOCKHOLM

SVAR 2012-01-10. Enheten för fastighetsrätt och associationsrätt Stefan Pärlhem 103 33 STOCKHOLM SVAR 2012-01-10 Enheten för fastighetsrätt och associationsrätt Stefan Pärlhem 103 33 STOCKHOLM Inbjudan att lämna synpunkter på förslag till EU-direktiv om årsbokslut, sammanställda redovisningar och

Läs mer