Att Stärka Innovation i
Mjukvaruföretag
Sammanfattning
Detta examensarbete har två huvudsakliga mål. Det ena är att utöka funktionaliteten i mjukvaran C3Loops för att underlätta för musiker som producerar elektronisk musik som vill använda mjukvaran i liveframträdanden. Det andra är att titta närmre på hur
processmodeller för mjukvaruutveckling stödjer innovation. Denna rapport ger läsaren ett tvärvetenskapligt perspektiv. Tre för ämnet relevanta teoretiska områden, innovation, software-engineering och design tas upp. C3Loops projektet används som ett exempel på ett innovativt mjukvaruprojekt och det är arbetet inom detta projekt som står som modell och bakgrund till resultatet och slutsatsen.
Idén till mjukvaran C3Loops är resultatet av tekn.Dr Rikard Lindellʼs avhandling ”jag älskar att allt ligger överst”. Arbetet resulterade i en interaktiv prototyp som Lindell beslöt sig för att ta vidare och kommersialisera. Syftet med prototypen var att utforska bruksvärdet av ytinteraktion med pekskärmar. Mjukvaran är ett preformance verktyg för kollaborativa multimedia-framträdanden. Den skall skapa nya möjligheter för liveframträdanden och samarbeten mellan elektroniska musiker, Dj och Vj.
C3Loops projektet är fortfarande pågående. Plattformen som projektet produceras för är iPad plattformen. Release datum för projektet är tänkt att överenstämma med iPads releasedatum i Sverige. Rapporten leder till ett förslag på hur organisationer som vill förbättra sin innovationsförmåga kan gå tillväga. Detta i form av en projektmetod tänkt att stödja processen för att ta fram och pröva idéer till V1.0 mjukvara. Det återstår att testa och utvärdera metoden i skarpa projekt.
Abstract
This thesis work has two main goals. The first is to extend the functionality of the C3Loops software in such a way as to make it usfull for a wider variety of electronic musicians The second is to examine how well software engineering process models support innovation. The C3Loops project is used as a case wich is studied in relation to this inquiry.
The idea for C3Loops is the result of the doctoral thesis ”i love the fact that everything is on top” by tekn.Dr.Rikard Lindell. The work on this thesis resulted in an interactive prototype, which Lindell decided to try and commercialise as a product. The original purpose of this prototype was to explore the value of surface interaction using touch screens in a collaborative multimedia preformance context. It creates new posibilities for live preformance and collaboration between electronic artists, Djs and Vjs.
The C3Loops project is still ongoing. The software is being produced for the iPad platform and its release is planned to coincide with the iPad release in Sweden. The result of this report is a suggestion on how organizations that develop software can improve their ability to innovate. This suggestion takes the form of a process model specifically designed to help support the creation and evaluation of idéas for V1.0 software. Future work includes testing this new method on real projects.
Tack till!
6
Introduktion!
6
1.1Bakgrund - om C3Loops och Exjobbet!
6
1.2 Syfte !
6
1.3 Instruktioner till läsaren!
7
2. Problemformulering!
8
2.1 Vad skall jag göra i Exjobbet!
8
2.2 Projektet C3Loops!
8
2.2.1 Bakgrund till idén för mjukvaran C3Loops.! 8
2.2.2 Den elektroniska musikens framväxt! 9
2.2.3 Behovet av verktyg! 9
2.2.4 Live musik! 10
2.2.5 Den elektroniska live-musiken! 10
2.2.6 Verktyg för elektronisk live musik! 11
2.2.7 C3Loops idé sammanfattad! 12
2.2.8 C3Loops funktionalitet! 12
2.2.9 Grunden till min idé! 13
2.3 Ändringar längs projektets gång!
14
2.4 Problemanalys!
14
2.5 Avgränsningar!
15
3 Relaterade arbeten och teori!
16
3.1.5 Komponentbaserad utvecklingsmetod! 19 3.1.6 Iterativa utvecklingsprocesser! 20 3.1.7 Agila utvecklingsmetoder! 21 3.1.8.1 Extreme Programming! 22 3.1.8.2 SCRUM! 22
3.2 Innovationsprocesser!
24
3.2.1Vad kännetecknar en innovations process! 24
3.2.2 Interna och externa faktorer! 24
3.2.3 Innovation, kärnan i affärsprocessen för mjukvaruföretag! 25
3.2.4 Innovationsportfolion hos organisationer! 26
3.2.5 Den lärande organisationen! 26
3.2.6 Hur innovativa är stora mjukvaruföretag?! 26
3.2.7 Innovation lyckas sällan och tar tid! 27
3.2.8 Fem färdigheter som används vid innovation! 28
3.3.1 Design! 29
3.3.1 Användargränssnittets plats i utvecklingsprocessen! 29 3.3.3 Patterns vid utveckling av UI(användargränssnitt)! 29
3.3.4 Designens roll vid framgång för innovation! 30
3.3.5 Användarens plats i gränssnitets utformning! 31
3.3.6 Gränssnittsprototyper! 31
3.3.7 Skisser enligt Bill Buxton! 31
3.3.8 Prototyper enligt Bill Buxton! 32
4 Metod!
34
4.1 De olika faserna! 34 4.2 Reflektion-i-handling! 34 4.3 Reflektion-över-handling! 355 Arbetsflöde!
36
6 Resultat!
37
6.1 Hur funktionaliteten fördes in i C3Loops! 37
6.2 Hur lösningen implementeras! 39
6.3 Användarens nyttovärde av arbetet! 39
6.4 Evolverad projektmetodik! 39
6.5 Hur man driver V1.0 projekt! 40
7 Sammanfattning och slutsatser!
42
Min syn på SCRUM! 43
Framtida arbete inom projekt metodik för V1.0 mjukvara! 43
Framtida arbete inom projektet C3Loops! 43
8 Referenser!
44
Tack till
Jag skulle vilja tacka några av de som hjälpt mig under skrivandet av denna rapport. Rikard Lindell för all hans hjälp samt det mycket givande sammarbete jag haft med honom, inbjudan till MusicHackdays i stockholm tackar jag också för. Carolin Uppsäll för korrekturläsning. Nalle Roth för att han så vänligt lånat ut böcker om OSX programmering till mig.
Introduktion
Den här rapporten är en del i ett 30Hp examensarbete på D-nivå vid mälardalens högskola. Arbetet har utförts i samråd med Tkn.Dr Rickard Lindell.Arbetet innefattar en praktisk del med implementation samt en teoretisk del där den här rapporten ingår.
1.1Bakgrund - om C3Loops och Exjobbet
C3Loops är namnet på det projekt som legat till grund för Lindells avhandling ”jag älskar
att allt ligger överst”. Grund idén med C3Loops var att skapa en prototyp för att utforska
bruksvärdet av kollaborativa live multimedia framträdanden med ytinteraktion. Ytinteraktion är ett gränssnittsparadigm där allt material/innehåll ligger på en oändligt stor
tvådimensionell yta. Användaren navigerar bland innehållet på ytan med hjälp av zoom och pan[A1]. Detta paradigm skiljer sig från det tradionella WIMP (windows icons mouse pointer) som länge dominerat datormarknaden. Gränssnittet är främst tänkt att användas tillsammans med skärmar med touch teknik. Jag är själv musiker och har länge, ca 6 år, uppträtt med elektronisk musik live. Jag har framförallt använt verktygen Reaktor[B1] samt Live[C1] vid live-framträdanden. Begränsningarna i dessa verktyg gav mig en idé om ett enklare program som fokuserade på det jag ville kunna göra och gav mig kraftfullare och enklare gränssnitt för att i live situationer kunna manipulera musiken. Denna idé
presenterades för Lindell och vi kom fram till att den skulle infogas i nästa version av C3Loops som Lindell avser att kommersialisera.
1.2 Syfte
Målet med projektet som helhet var att förbättra C3Loops och byta ut kodbibliotek vars licensmodeller försvårat en kommersiell lansering av produkten. Ljudbibloteket byts från PortAudio till CoreAudio, nätverket byts från Raknet till ett eget OSC baserat
nätverksprotokoll. De Lua/OpenGL-baserade GUI komponenterna byts mot
CoreAnimation. Tanken är att applikationen när jag är klar skall ha ett CoreAudio baserat ljudsystem som stödjer navigering i stora ljudströmmar. Gränssnittet skall även anpassas så att användaren kan komma åt och manipulera denna nya funktionalitet. Syftet med allt detta är att C3Loops skall kommersialiseras.
1.3 Instruktioner till läsaren
Den här rapporten tar upp frågeställningar om förutsättningarna för innovation inom organisationer som sysslar med utveckling av mjukvara. Den använder sig av projektet C3Loops som ett case inom utveckling av V1.0 mjukvara. Projektet och dess bakgrund beskrivs i del 2.2. I del 3 så presenteras en litteratur studie över relevant teori inom områdena Innovation, Software-engineering och Design. I del 4 beskriver jag den metod som jag använt mig av. I del 6 presenteras resultatet av arbetet, här redogörs det för hur idén fördes in i C3Loops samt hur vi arbetade i projektet och hur detta arbete ledde fram till en idé om en ny typ av projektmetod för tidiga stadier av utveckling av V1.0 mjukvara vidare så innehåller del 7 slutsatser och diskussion kring arbetet i projektet. Här
2. Problemformulering
IT-industrin ses idag som en av de mest innovativa branscherna inom affärsvärlden[D1]. Därför är det särskilt intressant att titta på hur utvecklingsprocesser för mjukvara stödjer innovation och vad det är i processerna som möjliggör denna explosiva innovationskraft. För att undersöka en sådan sak krävs ett tvärvetenskapligt perspektiv. Vi måste veta vad innovation är och vad som kännetecknar innovationsprocesser. Vi måste även känna till hur mjukvarutvecklare jobbar idag och hur marknadens krav och utvecklarna själva har format de processer som används inom området. Eftersom att mjukvaran i fallstudien till stor del handlar om nya former av människa-datorinteraktion så kommer även
interaktionsdesign att belysas. Sedan krävs en metod för kunskapsbyggande genom konstruktion; arbetet använder konstruktion i projektet C3Loops som medel för att lära sig om innovativa mjukvaruprojekt.
2.1 Vad skall jag göra i Exjobbet
Målet med Examens arbetet är tvådelat, det är en praktiskt del där min idé skall
implementeras i C3Loops projektet samt en analyserande del där projektet och mitt arbete analyseras utifrån ett innovations perspektiv. Min roll i projektet startade som innovatör där en idé som förändrade och utökade C3Loops funktionalitet presenterades och såldes in hos projektägaren Lindell. Mitt uppdrag blev sedan att undersöka hur denna funktionalitet kunde infogas i mjukvaran samt att delta i implementationen av mjukvaran. Denna rapport är en reflektion över innovationsmöjligheter i mjukvaruprojekt utifrån detta perspektiv.
2.2 Projektet C3Loops
C3Loops har fötts ur ett långt arbete för att utforska ytinteraktion som startade 2001. För att utforska ytinteraktion så byggdes interaktiva prototyper/skisser som utforskades tillsammans med fokusgrupper av användare. Det började med en flashprototyp som var avsedd att användas med pekskärm. Användarna i fokusgruppen fick sedan
experimentera/leka med prototypen och detta låg sedan som underlag för analys och diskussion inför nästa prototyp/skiss. På detta sätt fortskred sedan arbetet genom
ytterligare två iterationer av prototyper/skisser. Efter detta så kom design processen in i en ny fas där många föreställningar nu var testade. Det hade nu blivit uppenbart vilka problem som designen skulle lösa. Därefter började nya pappersskisser tas fram. Detta ledde till den slutgiltiga prototypen C3Loops som ligger till grund för arbetet.[A9]
2.2.1 Bakgrund till idén för mjukvaran C3Loops.
För att förstå vad C3Loops är för typ av mjukvara och på vilket sätt den är innovativ så krävs en grundlig genomgång av området som verktyget är avsett för. Nedan försöker jag ge en kontex till C3Loops. Mjukvaran är avsedd att lösa problem som uppstår för musiker som skapar elektronisk musik. En kort bakgrund till elektonisk musik ges.Vi tittar också på de verktyg som formats av musikernas behov. Därefter ges en förklaring till C3Loops och den idé som jag försökt att implementera.
2.2.2 Den elektroniska musikens framväxt
Att skapa musik med hjälp av maskiner och i förlängningen datorer har förändrat hur musik låter, men framförallt hur musik skapas. I den elektroniska musikens barndom fokuserade man på de nya uttryck som industrialismens framsteg möjliggjorde [E1]. Men i och med att datorer blivit snabbare och kommit in i hemmen så är idag den mesta musiken i någon mening elektronisk. Mycket popmusik är idag helt eller delvis producerad med hjälp av elektroniska musiker som programmerats att spela sina instrument.
Ur de nya möjligheter som tekniken erbjuder så har flera nya typer av musikskapare växt fram. Dessa musiker sysslar med musik som är helt fokuserad på de nya
utrycksmöjligheter som denna utveckling möjliggör, de försöker inte använda datorn för att härma "riktiga" musiker utan fokuserar helt på att skapa nya ljudbilder med hjälp av syntes eller manipulation av förinspelade ljud. Det hela började med musik-concrete och
elektronishe-musik rörelsen som, mellan 1945-1960 använde sig av bandspelare och analoga oscillatorer för att organisera ljud som tidigare sågs som omusikaliska till musikaliska verk [5].
Lite senare så kom det fram musiker som använde ljudsyntesen som möjliggjorts av synthar som tex Moog,ARP etc för att orkestrera mer traditionella verk [F1]. Denna rörelse växte sig allt större och mer brokig. Det som från början varit mest konstmusik växte sedan i alla riktningar och blev en grund för mycket av avantgardemusiken och popmusiken på samma gång.
2.2.3 Behovet av verktyg
Denna utrycksform har gett upphov till en stor marknad för verktyg som möjliggör och stödjer den här typen av musikproduktion. Många av dessa verktyg, som från början startade som verktyg för att orkestrera synthezeisers tex cubase etc. Är idag så pass utvecklade att de kan ersätta allt ifrån synthar och bandspelare till mixerbord och annan signalbehandlings utrustning som tidigare fanns i traditionella studios. Nuförtiden kan allt detta emuleras direkt i datorn. Det finns en uppsjö av olika verktyg som är avsedda att lösa en rad olika uppgifter för den elektroniska musikern. De mest signifikanta idag är
• DAW Digital Audio Workstation: DAW program syftar till att vara hjärtat i en elektronisk musikskapar-process genom att samla upp andra verktyg och centralisera och
organisera orkestreringsprocessen. Till en början kunde dessa centraliseringsverktyg enbart hantera notdata som skickades via nätverk (midi,CV) till annan utrustning och kallades då för sequensers. De kördes till en början på specialiserad hårdvara. När sequensern flyttade in i hemdatorn så dröjde det inte länga förr än funktionaliteten utökades för att även innefatta digitala ljudspår. Namnet ändrades då från sequenser till DAW men i många texter så används dessa ord som synonymer. Det är här man jobbar med att sätta ut musikaliska händelser längs den tidslinje som representerar musiken. Detta program är även värd för insticksprogram(Plug-ins) som representerar instrument eller effekter.
vanliga effekter som använts i studios enda sedan den inspelade musiken möjliggjordes finns som digitala upplagor. Det finns även en del digitala effekter som saknar motpart bland "traditionella" studio effekter.
• Visuella DSP-språk: Dessa program tillåter användaren att konstruera egna ljudverktyg genom att erbjuda stora bibliotek med moduler som utför olika typer digital
signalbehandling(DSP). Detta möjliggör för användaren att konstruera nya synthesizers och ljud manipulerings verktyg utan att behöva djupa programmerings kunskaper.
2.2.4 Live musik
Innan det var möjligt att spela in musik så var musiker tvungna att närvara för att framföra musiken live. Detta var länge det huvudsakliga sättet som musiker tjänade pengar. När det sedan blev möjligt att spela in musik och distribuera detta på ett media som gemene man kunde spela i sitt hem så blev detta en ny inkomstkälla för musiker.. När sedan internet kom och piratkopieringen blev tillräckligt spridd så blev det svårare för musiker att tjäna pengar på skivor [U1]. Många musiker kompenserade detta tillkortakommande genom att ta mer betalt för sina live-framträdanden och genom att turnera mer [X1]. Inom den
elektroniska musiken blev dock detta en större utmaning då DJs dominerade en stor del av utelivet [Y1].
När traditionell musik framförs live så finns vissa förväntningar hos publiken för vad de räknar som ett live-framträdande. Detta består vanligtvis av att musikerna som
hantverkare utför sitt hantverk och spelar upp musik via sitt instrument. I det uttrycket så formas musiken via små misstag och även genom att musikern anpassar sin spelstil till situationen och den stämning som finns.
Vad händer när elektronisk Musik skall framföras live ? När många av de roller som
traditionellt utförts av människor nu utförs av maskiner som enbart kan följa tidigare givna, förprogrammerade instruktioner. Kan elektronisk musik överhuvudtaget ses som live-musik ?
2.2.5 Den elektroniska live-musiken
I den elektroniska dansmusikens barndom (1980 talet) var de tekniska möjligheterna starkt begränsade av den utrustning som fanns. Att ta med sig och sätta upp den utrustning man använt för att skapa musiken var inte praktiskt möjligt. Det gick inte att spara inställningar på utrustningen och att ta fram de inställningar som använts för att skapa en viss låt var en tidskrävande process som i princip omöjliggjorde att musikerna kunde framföra sina
stycken och samtidigt ha möjligheten att påverka hur musiken lät. Ur denna brist växte ett nytt sätt att spela upp inspelad musik fram. Några av de tidiga artisterna kom på att de kunde använda skivspelare och mixers för att blanda låtar med varandra och även för att blanda in andras musik och mixa med ljudet från de trummaskiner som användes i den tidiga Technon och Housen. Det var möjligt att ta med sig två skivspelare en mixer och en trummaskin och sen göra en unik spelning som publiken upplevde som levande [S1].
Den framväxande Dj-kulturen kom snart att forma hur musiken skapades, Technon påverkades tydligast då man under en period helt slutade med arrangemang i traditionell mening och bara gjorde långa oavbrutna beats så att Dj:n skulle kunna bygga upp nya låtar genom att kombinera fragment av flera skivor. Snabbt så växte det fram en DJ-kultur
som var separat från producenterna, dvs personer som inte skapade egen musik alls utan specialiserade sig på att spela upp skivor och att på ett skickligt sätt sätta ihop
musikupplevelser från andras musik. Men publiken ville se artister live, riktigt vad detta innebar var dock oklart. I de allra flesta fall så använde sig artister av förinspelade bakgrunder och spelade något av instrumenten på riktigt eller synkroniserade dess uppspelning till bakgrundsmusiken och påverkade sedan ljudet genom att förändra de parametrar som formade ljudet [S1].
Ur detta problem så har det fötts ett behov av en ny typ av verktyg nämligen ett verktyg som kan hjälpa en elektronisk musiker att interagera med sin musik live och kunna skapa ett mer levande och unikt framträdande.
2.2.6 Verktyg för elektronisk live musik
De producenter av elektronisk musik som haft ambitionen att framföra sina verk live var länge helt förpassade till att konstruera egna lösningar. Vanligtvis så resulterade dessa lösningar i olika variationer av att trycka på play och stå och låtsas som att man gör något medan musiken spelas upp. Vissa artister ansträngde sig mer men att göra musiken möjlig att påverka live var en tidskrävande och arbetsam process. Att det fanns behov av verktyg för att lösa den här uppgiften var länge något som branschens stora aktörer ignorerade. I mitten av 90 talet, när den elektroniska dansmusiken växt till en stor kommersiell genre [Z1], började en del tillverkare designa produkter som var anpassade för att man skulle kunna skapa och manipulera hela musikstycken. Dessa kallades ofta för Groovebox [G1] och bestod av en integrerad Sequenser och synthesizer. Tanken var att man skulle kunna använda maskinen för att göra en hel låt utan att behöva annan hårdavara. Gränssnitten var konstruerade så att man byggde upp sin låt av ett antal loopande sektioner (fraser) som man sedan fritt kunde hoppa mellan. Det gick även att fritt välja mellan de olika spåren som maskinen styrde för att skicka kontrolldata via midi till dessa och styra parametrar i ljudsyntesen. Denna teknik hade dock sina begränsningar. Te.x så blev det genast problematiskt att integrera mer hårdvara då denna enbart kunde kommunicera via midi protokollet [AD1]. Detta protokoll kan inte innehålla någon information om hur ljudet låter bara vilken not som spelas och med vilken styrka samt förändringar av
standardiserade paramterar. Parametrarna kan dock vara godtyckligt mappade mot funktioner på den mottagande hårdvaran. Med andra ord, om man ville använda andra ljudkällor än den integrerade så var man nästan tillbaka på ruta ett. Verktygen krävde också att man skrev musiken med grooveboxen eller manuellt importerade
notsekvenserna till groovboxens interna sequenser.
Det är även ungefär vid denna tidpunkt(mitten av 1990 talet) som de Visuella DSP-språken Reaktor och Max/Msp [G1] gör sitt intåg på marknaden. Runt dessa program så växer ett stort community upp där användare delar med sig av sina skapelser och
diskuterar vad det är för verktyg de drömmer om.
funktionalitet som gör Live till ett preformance-verktyg inte utvecklats så mycket trots att versionssiffran och antalet features har växt explosionsartat sedan programmets release. [V1]
2.2.7 C3Loops idé sammanfattad
C3Loops är tänkt som ett rent preformance-verktyg för Dj:s och Vj:s samt elektroniska musiker som vill kunna göra mer saker live med sin förinspelade flerkanalsmusik. Det skall stödja kollaborativa multimedia-framträdanden. Gränssnittet skall vara specifikt anpassat till live-situationen och ge användaren en omedelbar koppling till musik och video
uppspelning samt erbjuda kraftfulla och spontana navigationsmöjligheter i mediaströmmarna.[A5]
2.2.8 C3Loops funktionalitet
Den funktionalitet som beskrivs här är den som fanns närvarande i prototypen innan detta projekt drog igång. När C3Loops öppnas så möts användaren av en grå yta, på denna yta ligger filer som finns i programmets databas. Dessa filer har olika format och formaten bestämmer vilken typ av kontroller som är knutna till filen[se fig1]. Två typer av media stöds; video och audio. Filerna kan ligga löst på ytan eller inuti en cirkelformad
preformance-kontroller. Preformance-kontrollers kan styra de klipp som ligger inuti den cirkel som de utgör. Sänks volymen här så sänks volymen på samtliga spår kopplade till denna preformance.
De kontrollers som är associerade med ljud klippet är
• Play: Sätter igång uppspelningen av ljudet eller videon kvantiserat till nästa 4/4 taktslag, trycker man på den en gång till så stannar klippet
• Volym: styr volymen på ljudspåret.
• Scene Enablers: styr till vilken scen* i det preformance* som filen ligger inom detta klipp hör, ett klipp kan höra till hur få eller hur många scener som helst.
När ett klipp befinner sig inom den cirkel som preformance-kontrollern utgör så kan dessa triggas från de scene enablers som finns hos preformance kontrollern. För att koppla ett klipp så att det spelas upp när man trycker på en scen hos preformance kontrollern så taggas det upp. Detta görs genom att motsvarande scen enabler markeras på ljudfilens kontroller. Denna blir då ljusgrön för att markera att den är upptaggad. Tjockleken på scenerna hos preformancekontrollern beror på hur många klipp som är upptaggade på denna scen.
Video har förutom de ovan nämnda kontroll elementen även två konformade reglage dessa anger vart i klippet som uppspelningen startar och slutar. Dessa kan dras och sättas till vilka positioner som helst. Om startpunkten hamnar efter slutpunkten så blir
uppspelningen bakvänd.
2.2.9 Grunden till min idé
Inom musiken så finns precis som inom programmeringen, olika abstraktionsnivåer. Längst ner så har vi noter, dessa bygger i sin tur upp fraser som med viss variation upprepas dessa ordnas sedan till arrangemang som till sist utgör hela musik stycket. Fraser kallas inom modern elektronisk musik för loopar [A2]. De verktyg som hittills kommit ut på marknaden har fokuserat på denna abstraktions nivå. Detta har varit fullt tillräckligt för delar av den elektroniska musiken där upprepning är centralt för hela estetiken (Techno,House). Men vad händer när musiken har ett mer utpräglat och komplicerat arrangemang?
Ett komplext arrangemang består ofta av loopar som i grunden gör det fullt möjligt att flytta över till loopbaserade verktyg. Denna process är mycket arbetsamt och resultatet
svåröverskådligt då en låt kan bestå av ett tjugotal olika loopar som sedan har ett tiotal olika variationer genom låtens progression. Att hålla koll på hundratals olika loopar inom en låt och i förlängningen i flera låtar är svårt och ointuitivt [AB1]. Därför finns här en intressant uppgift att lösa. Nämligen att skapa ett verktyg som på en mer övergripande arrangemangsnivå låter användaren, dynamiskt i flykten, välja ut de specifika loopar som är intressanta för vidare manipulation, samt att kunna sömlöst navigera mellan loopar och hela arrangemang. På så sätt kan man manipulera och interagera med musiken i båda dessa abstraktionsnivåer. Ännu mer intressant blir det om man kan skapa en tät koppling mellan gränssnittet som styr detta och användaren så att verktyget känns som ett
instrument och lämnar utrymme för virtuositet. [AA1]. Användaren skall i flykten kunna välja ut loopar och sedan markera denna plats i musiken så att denne när som helst kan återvända dit.
• Användaren skall kunna välja ut och loopa partier i låtar.
• Användaren skall kunna gå från ett loopat parti och sömlöst ut till låten igen.
2.3 Ändringar längs projektets gång
Från början var min idé tänkt att implementeras som ett AU-plugin som kunde laddas i alla AU kompatibla värdprogram. Efter att ha försökt genomföra detta så visade det sig att detta inte passade med den komponentbaserade lösning som från början var tänkt.
CoreAudio biblioteket stödjer denna möjlighet men ej som AU-plugin utan som exekverbar fil. Idén ändrades därefter till att direkt kunna integreras i C3Loops kodbas.
Projektet förlitade sig även på att billiga bra touch skärmar skulle bli tillgängliga. Den ursprunliga tanken var att dessa enbart skulle visa gränssnittet och att den del av
mjukvaran som skötte det tunga arbetet skulle köras på en dator kopplad till skärmen. När iPad utannonserades av Apple så överträffade dess specifikationer våra förväntningar och Lindell bestämde sig för att satsa på en Native iPad version.
2.4 Problemanalys
Arbetet består av två huvuduppgifter, att införa min idé i C3Loops samt en studie av innovativa mjukvaruprojekt och processmodeller som stödjer dessa.
Idén implementeras med XCode som IDE och med Apples CoreAudio API. Detta görs i språken C/C++ och Objective-C++. Projektet bestod av totalt 3 medlemmar. Eftersom min idé har kommit att bli en integrerad del av C3Loops så har inte implementationen av idén färdigställt innan arbetetet redovisats. C3Loops planeras att släppas till den svenska lanseringen av iPad.
I studien av innovation och processmodeller låter jag detta arbete bli ett case som jag relaterar och bygger min teori på. Målet är att undersöka innovationskraften hos
organisationer som jobbar med mjukvaruprojekt och hur detta fenomen kan stödjas och underlättas.
2.5 Avgränsningar
Arbetet har ett tvärvetenskapligt perspektiv. Syftet med detta är att ge en hollistisk bild av ett mångfacetterat fenomen. Det svåra har varit att inte bli allt för ofokuserad utan hålla mig kvar i ett perspektiv. Mitt fokus är utvecklaren och teamet som utvecklar. Jag är programmerare och det är därför naturligt att software-engineering är mitt fokus och mitt perspektiv. Nedan presenteras specifika avgränsningar som jag valt att göra inom respektive område.
Software-engineering
syftet med avsnittet är att ge en översiktsbild av hur utvecklingsprocesser är organiserade. Det är detta område som är fokus för rapporten. Jag skriver hela tiden ur ett software-engineering-perspektiv. Jag kommer inte ta upp underhåll av mjukvara trots att detta är en stor och oundviklig del av mjukvarutveckling. Detta eftersom att denna del sällan kan ses som en bidragande faktor till innovation. Jag tar enbart upp att man bör bygga robust programvara för att i största möjliga mån undvika en arbetsam och dyr underhållsprocess av mjukvaran.
Innovation
Syftet med avsnittet är att titta på innovation ur ett mjukvarutvecklingsperspektiv och hur detta kan generera värde för företaget. Jag går dock inte in på exakt hur detta värde genereras ur en ekonomisk synpunkt. Jag tar inte upp marknadsanalys och
omvärldsanalys utan fokuserar på hur man i en redan existerande utvecklingsprocess kan maximera sin innovationskraft.
Design
Syftet här är att synligöra designprocessen inom mjukvaruutveckling. Jag tar inte upp specifika riktlinjer för grafisk design. Jag tar inte upp design av hårdvarugränssnitt utan fokuserar på grafiska användargränssnitt.
3 Relaterade arbeten och teori
I detta avsnitt avhandlas den teori som är relevant för detta arbete. Tre huvudsakliga områden presenteras.
• Software Engineering för att ge en bakgrund till hur mjukvaruutvecklaren jobbar. De processmodeller som används för att organisera arbetet och några specifika
programmerings termer som är relevanta för detta projekt tas upp.
• Innovation för att förklara vad jag menar med termen samt att belysa vad forskare inom området innovation-management,innovation-strategi idag har kommit fram till.
• Designområdet tas upp inom kontexten för interaktiva system.
Fokuset ligger alltid på mjukvaruutveklare och de företag som producerar mjukvara.
3.1 Software Engineering
Allmänt kan sägas att ingenjörens uppgift är att införskaffa och applicera tekniskt,
vetenskapligt och matematiskt kunnande på design och implementera material, strukturer, maskiner, artefakter, system och processer som realiserar mål eller uppfinningar [Å1].
Software engineering är den ingenjörsdisciplin som fokuserar på alla aspekter av att producera fungerande mjukvara, från tidig specifikation till att upprätthålla systemets funktionalitet efter det att det tagits i bruk. Ingenjören är inte enbart intresserad av tekniska processer utan även projektledning samt utvecklingen av verktyg och metoder för att stödja mjukvaruproduktion [O1]. Det är inom denna kontext som mjukvaruutvecklaren befinner sig.
3.1.1 Mjukvaruarkitektur
Alla tillräckligt stora och komplicerade system består av ett antal olika subsystem. Att organisera dessa subsystem logiskt och etablera ett ramverk för subsystemens kontroll och kommunikation kallas för arkitekturel design. Denna del av utvecklingsprocessen är det första steget i att översätta design till specifikation [O2]. Det går att säga att
mjukvaruarkitektur är den övergripande logiska organisationen för systemet.
Arkitekturiel design representerar en kreativ process där man försöker etablera en
systemorganisation som tillfredställer de funktionella och icke-funktionella krav som ställs på mjukvaran. Aktiviteterna inom processen kan variera stort beroende på vilken art av mjukvara som utvecklas. Det är därför mer användbart att se på denna process ur ett beslutsfattandeperspektiv än från ett aktivitetsperspektiv. Under denna fas behöver systemarkitekten ta ett antal fundamentala beslut som i slutänden kommer att påverka systemet och dess utecklingsprocess [O3]. Genom arbetet i denna process försöker man besvara följande frågor.
"1. Is there a generic application architecture that can act as a template for the system that is being designed?
3. What architectural style or styles are appropriate for the system? 4. What will be the fundamental approach used to structure the system? 5. how will structural units in the system be decomposed into modules?
6. what strategy will be used to controll the operation of the units in the system ? 7.How should the architetcture of the system be documented? " [O4]
Att utvärdera en arkitekturell design är svårt eftersom det sanna testet an en arkitektur är hur väl den möter sina funktionella och ickefunktionella krav [O4].
Produkten av den arkitekturella designprocessen är ett designdokument – en ritning över systemets konstruktion. Detta kan inkludera grafiska representationer av systemet med tillhörande beskrivande texter [O3].
3.1.2 Utvecklingsprocesser
För att stödja den invecklade process där mjukvara blir till så har ett antal olika
projektmetoder utvecklats för att öka chanserna att projektet blir framgångsrikt. De olika metoderna har utvecklats ur sammanhang där olika egenskaper hos systemet varit av särskild vikt. Därför finns ingen generell lösning på vilken av dessa processer som är bäst. Men genom att känna till de olika metoderna kan man lättare välja den metod som passar ett specifikt projekt. Jag tänker ge en överblick över de vanligaste och gå in lite djupare på de som är särskilt relevanta för den typ av projekt som återfinns i case-studien [O17].
3.1.3 vattenfallsmodellen
Vattenfallsmodellen är den äldsta software-engineering-metoden. Metoden har sina rötter i äldre ingenjörsprocesser och bygger på en strikt linjär sekvens av aktiviteter där man gör klart en aktivitet innan man går vidare till nästa [O18].
Aktiviteterna är i ordning
• krav specifikation: här specas kraven som produkten skall uppfylla
• system och mjukvaru design: Här specas de olika subsystemen, dess roller och dess inbördes kommunikation
• implementation och enhetstestning: här implementeras subsystemen och implementationen testas
• integration och systemtest: här integreras subsystemen till det slutgiltiga sammansatta systemet och detta testas i sin helhelt
• underhåll och drift: här tas systemet i drift och sedan utförs löpande underhåll av systemet
Principen är att varje fas genererar ett antal styrande dokument som är helt klara och sen blir ledande i nästa fas av utvecklingen. Problemet är att faserna i praktiken har en
tendens att växelverka med varandra. Under designen så upptäcks problem i
specifikationen, under implementationen så upptäcks brister i designen osv. Detta har gett upphov till en rad olika typer av processmodeller som på olika sätt försöker lösa detta problem. Vattenfallsmetoden ligger dock ofta till grund för dessa där man delar upp arbetet i ett antal vattenfall och skapar specifika återkopplingar mellan stegen så att man mer fritt kan röra sig både framåt och bakåt mellan stegen.
Metoden fungerar bra när mjukvaruingenjörer måste samverka med mer traditionella ingenjörsprojekt men har till stor del förkastats av mjukvaruindustrin till förmån för mer flexibla metoder som inte dras med de begränsningar som verkligheten påtvingar. Mjukvara är ju enbart virtuell den kan byggas hur många gånger som helst den kan förstöras och brytas ned för att sedan byggas upp utan de följder som detta skulle få vid användning av fysiska material [AF1]. Det finns dock mjukvaruprojekt av säkerhetskritisk typ där detta påstående inte stämmer, man kan t.ex inte sätta ett styrsystem för ett kärnkraftverk i drift hur som helst.
3.1.4 Evolutionär utvecklingsmetod
Denna process baseras kring idén att den initiala implementationen av systemet exponeras för användaren/kunden som får komma med kommentarer och feedback, sedan förfinas implementationen kontinuerligt och mjukvaran "evolverar" fram. Här vävs specifikation, utveckling och validering samman och snabb återkoppling mellan stegen faciliteras.
Det finns enligt Sommerville [O5] två fundamentala huvudtyper inom den evolutionärautvecklings metoden.
1. Utforskande utveckling: Här är målet att jobba tillammans med kunden och utforska
kraven på mjukvaran för att kunna leverera systemet till kund. Utecklingen startar med de delar av systemet som är mest välkända/välförstådda. Systemet evolverar sedan genom att nya funktioner som föreslås av kunden läggs till en och en.
2. Engångsprototyper: Här är målet att förstå kundens kravbild och utveckla bättre
kravspecifikation som definierar systemet. Man tillverkar här prototyper av de delar av systemet som är sämst kända för att få bättre grepp om vad det egentligen är kunden är ute efter. Prototyperna är ej avsedda att faktiskt användas som mjukvara av kunden utan är endast verktyg för att lära sig och öka förståelsen för problemet.
Denna metod lämpar sig oftast bäst för små projekt då det är svårt att hinna med att dokumentera varje version något som oftast är nödvändigt i större projekt. Systemets struktur kan ofta bli lidande när kontinuerliga förändringar leder till att delar av systemet måste användas på sätt som det inte från början var designat för.
3.1.5 Komponentbaserad utvecklingsmetod
Att återvanvända kod har blivit allt vanligare i och med att de objektorienterade språken uppmuntrar detta med sina arvs-och inkapslingsmekanismer. Detta informella
återanvändande finns inom alla utecklingsprocesser och sker automatiskt när utvecklare känner till gammal kod som kan modifieras för att passa systemet. Dock så måste man ha tillgång till källkoden för att sådant återanvändade skall vara möjligt [O6]. Detta är inte alltid praktiskt då kod ofta är affärshemligheter. För att göra det möjligt att sälja komponenter med specifik funktionalitet till andra företag så har ett antal komponentmodeller utvecklats så att färdigkompilerade komponenter som ej exponerar källkoden kan säljas. Detta har givit upphov till en komponentbaserad utevecklingsmetod känd under namnet CBSE (component based software engineering). Detta väldigt återanvändningscentrerade tillvägagångssätt har vunnit mycket mark då det möjliggör väldigt korta utvecklingstider [O19]. Stegen i processen skiljer sig dock något från de som finns i vattenfallsmodellen.
1. Komponent analys: I detta steg så analyseras kravspecifikationen och en sökning efter
färdiga komponenter som motsvarar den specifikationen görs. Vanligtvis så finns det ingen exakt mappning mellan existerande komponenter och kraven vilket leder till att
komponenterna endast kan uppfylla en del av kravspecifikationen.
2. Kravspecifikationsjustering : I detta steg så kan kravspecifikationen modifieras utefter
de tillgängliga komponenterna. När modifikationer på specifikationen inte anses möjliga kan analysfasen utföras på nytt för att försöka finna alternativa lösningar.
3.Systemdesign med återanvändning: Här upprättas ett ramverk för systemet,alternativt
så väljs ett färdigt och passande ramverk ut och återanvänds. Designen tar med återanvändning av komponenter i beräkningen och organiserar ramverket för att underlätta detta tillvägagångssätt. Viss ny mjukvara kan behöva designas om återanvändningsbara komponenter ej står att finna.
3.1.6 Iterativa utvecklingsprocesser
Förändring är oundvikligt i stora mjukvaruprojekt. Systemens kravspecifikationer förändras när de organisationer som är kund anpassar sig till externa faktorer. Nya teknologier blir tillgängliga vilket förändrar förutsättningarna för design och implementation. Prioriteringar hos ledningen läggs om [O8].
Detta betyder att utvecklingsprocessen inte kan ses som en engångsprocess utan snarare som en rad processaktiviteter som upprepas regelbundet för att anpassa sig till
förändringar. Iterativ utveckling har blivit en fundamental del av mjukvaruutveckling [O7]. Två exempel på processmodeller som stödjer detta förfarande är inkrementell leverans och spiralutveckling.
Vid inkrementell leverans så delas mjukvaran upp i ett antal increment som kan levereras separat. Det är inte förrän nästa inkrement skall levereras som full specifikation för detta inkrement definieras. Detta kan ses som ett antal mini-vattenfallsprocesser som kopplas ihop.
Spiralutvecklings modellen bygger på utvecklingsprocessen ses som en loop där varje varv i loopen representerar en fas av mjukvaruprocessen. Den innersta loopen fokuserar på systemets gångbarhet, nästa loop på kravdefinition, nästa på systemdesign och så vidare. Varje loop delas upp i fyra segment
• Målbildsdefinition: Specifika mål för fasen definieras och en detaljerad plan skapas.
Projektet risker identifieras och alternativa strategier beroende av dessa risker kan tas fram.
• Risk-definition och -reduktion: För varje identifierad risk så görs en detaljerad analys.
Åtgärder vidtas för att reducera risken. Ex om risken är att kravspecifikationen är dåligt förstådd så kan en engångsprototyp utvecklas för att förstå dem bättre.
• Utveckling och validering: Efter det att alla risker bedömts och analyserats så väljs en utvecklings metod för den delen av systemet ut. Här kan det bli aktuellt att använda en evolutionär metod när det passar eller en mer formell metod när det passar.
• Planering: projektet granskas och beslut tas om man skall fortsätta med nästa loop i
•
Denna metod försöker plocka russinen ur kakan genom att ge varje del av projektet den utvecklingsmetodik som passar bäst just där.
Den centrala delen av den iterativa processen är att specifikationen utvecklas tillsammans med mjukvaran, detta ses inte som två separata processer utan som en sammanflätad process[O8].
3.1.7 Agila utvecklingsmetoder
Företag jobbar idag på en global marknad som förändras snabbt. Mjukvara spelar ofta en central roll i nya affärsverksamheter [O9] det är därför viktigt att mjukvara kan levereras snabbt, tas i drift och förändras i samma takt. Ur detta klimat så har ett antal
utvecklingsmetoder vuxit fram. Dessa har samlats under paraplybegreppet de Agila metoderna. Alla dessa metoder baseras kring inkrementell utveckling och leverans av systemet men har de alla olika metodik för att ta sig fram till målet. De delar dock ett antal grundläggande principer som hämtats ur det agila manifestet [P1] Dessa kan
sammanfattas som fem punkter.
1. Kunden är involverad: Kunderna skall vara nära iblandade i utvecklingsprocessen.
Deras roll är att förse systemet med krav och prioritera dessa samt att utvärdera iterationerna av systemet.
4. Välkomna förändringar: Förvänta dig att förändringar kommer, designa systemet med
detta i åtanke.
5. Bibehåll enkelheten: Fokusera på enkelhet både i mjukvaran som utvecklas och i
utvecklings processen. När det är möjligt jobba aktivt för att eliminera komplexitet.
Det finns ett antal olika projektmetoder som sällar sig till de agila metoderna, jag tar dock bara upp de två mest centrala och populära agila metoderna, Scrum samt XP (extreme programming)[K2].
3.1.8.1 Extreme Programming
Metoden namngavs av Beck [O10] och har fått sitt namn från att erkänd ”best-practice” har tagits till extrema nivåer. Iterativ utveckling och kundfokus är centralt för metoden. Man formulerar krav som scenarios (även kallade användarhistorier) dessa implementeras sedan som en serie av programmeringsuppgifter. Programmerare jobbar i par och
utvecklar test för varje programmeringsuppgift innan denna implementeras. Alla test skall sedan genomföras framgångsrikt för att koden skall gå vidare och integreras med resten av systemet. Metoden innehåller ett antal aktiviteter som stödjer de agila principerna. • Man stödjer inkrementell utveckling genom att ha små frekventa versioner av systemet
samt att kravspec och implementering förs samman genom arbetet med användarhistorier.
• Kunden skall delta i utvecklingsprocessen som en del av teamet. Kundens representant förväntas hjälpa till med scenarios och designa acceptanstest för varje version av
systemet.
• Fokus på människor istället för process genom att man programmerar i par. Koden och systemet ägs kollektivt i teamet och övertid ses som något dåligt som bör undvikas om kvaliteten skall hållas hög. Paren är inte statiska utan man byter partner regelbundet och man sitter inte och jobbar på samma del av systemet hela tiden utan byter, detta
eliminerar sårbarhet som annars uppstår kring nyckelpersoner.
• Förändringar stödjs genom de små frekventa versionerna av systemet
• Enkelhet stödjs genom kontinuerligt underhåll av koden och genom att kollegor konstant granskar varandra.
Extreme programming är förmodligen den bäst kända om mest välanvända av de agila metoderna [O20]. Metoden är extremt iterativ i den bemärkelsen att nya versioner av systemet byggs ofta, ibland flera gånger per dag, och levereras till kund ca varannan vecka [O21].
3.1.8.2 SCRUM
Extreme programming används ofta tillsammans med SCRUM i projekt. Om extreme programming fokuserar på programmerare och bra principer för att stödja dem i sitt arbete så fokuserar SCRUM mer på projektledning och projektplanering. Detta genom att sätta upp ett strikt ramverk men utan att exakt detaljstyra vad man skall fylla detta ramverk med. [K1] SCRUM definierar ett antal roller, dessa är:
• ScrumMaster: en SCRUM-process faciliteras av en så kallad SCRUM-master, denna persons primära jobb är att ta bort hinder så att teamet kan jobba ostört och har så bra förutsättningar som möjligt att leverera ett fungerande inkrement. Han skall vara en buffert mellan teamet och störande element. Denna person har även ansvaret för att ramverket används som det är tänkt, han har en sorts domarroll och skall se till att uppsatta regler efterlevs.
• Teamet: det är teamets ansvar att leverera systemet/produkten. Ett team är någonstans mellan 3-9 personer.
• Produktägaren: Detta bör vara kundens representant i projektet. Dennes roll är att försäkra sig om att projektet sysslar med rätt saker, har rätt prioriteringar från ett
affärsperspektiv. Projektägaren har ansvar för att användarhistorier (scenarios) tas fram och prioriteras på rätt sätt. Dessa användarhistorier används som utgångspunkt för kravspecifikationen.
Projektet organiseras som en serie små vattenfall som kallas sprinter, dessa är mellan 2-4 veckor långa. Utvecklingsprocessen börjar med att en så kallad backlog skapas för
projektet. Denna skall fyllas med användarhistorier som sedan kan väljas ut till nästa utvecklingssprint. Varje sprint startar med ett planeringsmöte där de användarhistorier ur backlog som man tror sig hinna med och som är högst prioriterade väljs ut i samråd med produktägaren. Dessa blir sedan till en så kallad sprint backlog. Denna backlog samlas inte i ett dokument utan sätts upp på en vägg (SCRUM-board) där man håller reda på varje arbetsmoments status. När sprinten är över så skall en demonstration av alla de
SCRUM-metoden är tänkt att leda till ett självorganiserande team när sprinten väl är igång så skall teamet vara näst intill autonomt. Inom teamet så uppmuntras kommunikation. Arbetsrummet organiseras på ett sådant sätt att alla lätt kan kommunicera både muntligt och genom den SCRUM-board som skall finnas väl synligt. Får man nya idéer så är man fri att göra användarhistorier av dem och lägga till dem i backlogen. Har de ett tydligt värde för kunden så kommer de med annars så prioriteras de bort.
3.2 Innovationsprocesser
Den här rapporten handlar om hur kunnande inom datavetenskap skall kunna
kommersialiseras i produkter. När ny kunskap på detta sätt omsätts så uppstår innovation. Det är därför ett centralt begrepp i rapporten. Innovation är ett stort område, här ges en kort inblick i de delar som är viktigast för att motivera de slutsatser och den inriktning rapporten har.
3.2.1Vad kännetecknar en innovations process
En innovation är resultatet (produkten) av en innovationsprocess, men behöver inte vara en fysisk vara (ett föremål man kan ta på). En innovation kan lika gärna vara en tjänst, en ny filosofi eller ett nytt sätt att göra någonting [AG1]. Begreppet kan upplevas väldigt brett. Men för att precisera det något så kan man ta ett exempel. Att tillverka något nytt på exakt samma sätt som tidigare inte är någon innovation, en ny bilmodell är således en
innovation men varje nytillverkad bil av den modellen inte är någon innovation.
Mjukvaruindustrin är en otroligt innovationsintensiv bransch [D1]. Att skapa mjukvara består nästintill enbart av design och implementation, att sedan producera enheter blir trivialt eftersom det enbart handlar om att duplicera data. Innovation inom denna bransch hamnar mestadels inom två kategorier vad man levererar (vilken tjänst eller vilket verktyg) samt hur man väljer att distribuera det (på fysisk skiva eller via nätet etc) [D11]. Ett företag som förnyat hur man distribuerar en tjänst är Spotify med sin prenumerations baserade musik, ett exempel på det första är företaget Propellerhead som designat verktyg för musiker som förändrat hur de skapar sin musik. Spelföretaget Blizzard lyckades
kombinera båda dessa och leverera en ny typ av spelupplevelse och kombinera detta med ett prenumerationsbaserat spelande.
3.2.2 Interna och externa faktorer
De mekanismer som triggar innovationsprocesser befinner sig olika i förhållande till organisationen [D12]. Externa faktorer kan vara trender hos kunder, nya plattformar som produkten kan levereras till, snabbare eller annorlunda utformad hårdvara som skapar nya möjligheter för vad produkten kan leverera som kundnytta [X6][D13]. Interna faktorer kan vara idéer som föds i utvecklingsprocessen eller internt utvecklad teknik som öppnar nya möjligheter. Av dessa båda mekanismer så är de interna faktorerna det som är särskilt intressanta för detta arbete. Ingen intern mekanism existerar dock i ett vakuum så
skiljelinjerna mellan dessa båda kan vara svåra och ibland omöjliga att dra upp. Men det går ändå att titta på hur utvecklarna själva har möjlighet att vara delaktiga och drivande för innovations kraften i en organisation. Det går även att hävda att en väl fungerande strategi för att stödja utvecklarnas egen möjlighet att delta i innovationsprocessen är centralt för organisationers framtida överlevnad och framgång [D2]. Det bör då vara en högt
prioriterad uppgift för företag som sysslar med denna typ av verksamhet att lyckas föra in en sådan kultur i sitt arbetsätt för att stärka företagets livskraft på marknaden.
Ett citat som stödjer detta påstående kommer från Richard Rumelt, en professor i strategi
"A great deal of buisness success depends on generating new knowledge and on having the capabilities to react quickly and intelligently to this new knowledge... I believe that strategic thinking is a necessary but overrated element of business success. If you know how to design great motorcycle engines I can teach you all you need to know about
strategy in a few days. If you have a PhD in strategy, years of labor are unlikely to give you the ability to design great new motorcycle engines." [D3]
Motorcykelmotorer får här vara vår metafor för mjukvarutveckling vilket kan ses som en minst lika avancerad uppgift.
3.2.3 Innovation, kärnan i affärsprocessen för mjukvaruföretag
"Whilst competitive advantage can come from size or possession of assets, the pattern is increasingly coming to favor those organizations that can mobilize knowledge and
technological skills and experience to create new products, processes and services."[D4].
Detta påstående gäller i synnerhet mjukvaruindustrin där ägandet av fabriker och annan dyr tillverknings utrustning är helt onödigt och där inträdet till marknaden pga av detta är betydligt lägre än inom andra branscher te x kemisk industri, bilindustri etc.
"With the rise of the internet the scope for service innovation has grown enormously - not for nothing is it sometimes called 'a solution looking for problems." [D5]
Detta påstående kan även påstås gälla datorer i allmänhet dvs att datorer innebär lösningar som letar efter problem. Det blir då uppenbart att innovation är kärnan i mjukvaruutvecklarens affärsmodell. Det är innovationer man erbjuder kunderna och
konstant måste fortsätta att erbjuda sina kunder om man skall överleva på marknaden. Att leverera nya versioner av produkter och nya lösningar är det man sysslar med det är därför av yttersta vikt att man undersöker hur man skall kunna förbättra kärnan i sin verksamhet, dvs innovationsprocessen.
"By far the most important input into the process of advancing science and technology is the creative power of human beings, in economic terms, human capital." [M1]
Såhär inleder F. M. Scherer en professor i ekonomi ett kapitel i sin bok om nya perspektiv på ekonomisk tillväxt och teknologisk innovation. Han fortsätter sedan med att visa upp empiri och föra en diskurs som styrker detta påstående genom hela det kapitel som han valt att kalla human capital. Det är mot denna bakgrund som frågeställningen i arbetet uppstått.
Att påstå att det företag vars ledning bäst kan spå framtiden även skulle vara det företag som kommer lyckas bäst med sin innovationsstrategi kan verka som något av en plattityd.
3.2.4 Innovationsportfolion hos organisationer
Generellt sätt så bör företagen arbeta med en portfolio av innovationer. Där kan allt ifrån inkrementell innovation till mer radikal innovation finnas [D8]. En av nyckelfärdigheterna för att framgångsrikt styra sin innovationsprocess är att balansera kompositionen av portfolion och matcha detta mot organisationens kompetens och förmåga inom teknologi och
marknader [D8]. Att åstadkomma detta i praktiken är dock svårt. Organisationer tenderar att strukturera sina innovationsstrategier runt en sorts ”stadig takt” av utveckling där man fokuserar på att göra det man gör lite bättre [D8]. Detta leder till närmre interaktion med kunderna för att sakta närma sig ett optimalt förhållande för kvalitet, leveranstid, kostnader etc. Denna innovation som till sin natur är inkrementell är naturligtvis livsviktig för företag. Men det finns även omständigheter, radikala förändringar av marknaden eller ny teknologi som förändrar förutsättningar i grunden för en vara eller tjänst, som kräver mer radikala innovationer. Det är därför viktigt att även denna del av portfolion finns[D8]. Här riskerar man även att gå miste om nya marknader om man inte är uppmärksam och utnyttjar den kompetens som finns i organisationen.
3.2.5 Den lärande organisationen
Den lärande organisationen är ett centralt begrepp inom innovation-management literaturen och definieras av Nationalencyklopedin på följande sätt:
”lärande organisation, organisation som kontinuerligt lär av sina erfarenheter i syfte att
lösa sina uppgifter på ett bättre sätt. Begreppet, som är centralt i arbetslivet, uttrycker ett idealtillstånd. Lärande organisation har utvecklats till en viktig vision som påverkat synen på hur organisationer bör utvecklas. Ett flertal förutsättningar brukar framhävas. Ledningen har en viktig funktion och behöver utveckla en samlande vision kring organisationens mål, den skall uppmuntra medlemmarna att tillsammans undersöka och diskutera samarbete och resultat. Vidare skall organisationen medvetet stödja kreativitet och uppmuntra risktagning, vara frikostig med information, sträva efter ett helhetsperspektiv och stödja laganda. I en lärande organisation har medlemmarna god kunskap om resultat, problem och mål. Utvärderingar är vanliga och samtliga känner samhörighet med varandra och kämpar för att nå bättre resultat. Lärande organisation som begrepp används framför allt inom management i samband med kompetens- och organisationsutveckling, liksom inom organisationsteori med inriktning mot företagande och human resource.” [M1]
Detta begrepp infattar den företags kultur som bäst faciliterar innovation [D10]. Organisationer som vill vara innovativa bör därför sträva efter att vara lärande
organisationer. Att inom organisationen generera kunskap i utvecklings processen är således helt vitalt för ett företags överlevnad och ett större mjukvaruföretag bör ha detta som en central del i sin strategi [D10].
3.2.6 Hur innovativa är stora mjukvaruföretag?
Mjukvara kan klassas i två kategorier. Version 1.0 produkter dvs helt nya produkter och Version n+1 produkter, dvs förfinade varianter av tidigare produkter [N1]. Att fortsätta att förfina produkter har två huvudsakliga mål
• Locka nya användare till produkten
• Att fortsätta och förfina produkter för att göra kunderna nöjdare och locka in fler nya användare är ett bra sätt att tjäna pengar. Problemet är att produkten över tid mognar. Det gör även användarna som vänjer sig vid att det skall vara på ett visst sätt, på gott och ont. Produkten blir allt mer komplex, förändringar tar mer och mer tid och riskerar att alienera gamla användare samtidigt som nya kan bli svåra att få in i en allt mer komplex produkt. För varje ny version så blir det både och svårare och dyrare att uppnå dessa två mål.
Därför måste man förr eller senare skapa nya V 1.0 produkter om företaget skall kunna fortsätta att öka sin vinst och omsättning [N2].
De flesta mjukvaruföretag är dock riktigt dåliga på att skapa V 1.0 produkter. T.ex hade Adobe, som är ett stort mjukvaruföretag inom grafik- och webbbranschen, fram till 2002 enbart lyckas utveckla två av sina produkter i egen regi från det att företaget föddes 1984. De allra flesta nya produkterna (V1.0) kommer in via uppköp av mindre företag eller uppstår genom så kallade ”skunkworks”, där personal tagit saken i egna händer och helt enkelt struntar i vad ledningen säger och utvecklar saker på eget bevåg. Att genom
uppköp av intressanta företag konsolidera sin egen position på marknaden är ju inte något dåligt i sig men det är problematiskt av flera skäl
• Det är inte alltid det man vill ha går att köpa
• Ibland kan geografiska avstånd göra det svårt att till fullo utnyttja det företag man köpts kompetens i den egna organisationen
• Skillnader i affärskultur kan göra samarbete svårt och olönsamt.
• Kreativa och duktiga medarbetare blir frustrerade och kanske lämnar företaget istället för att bidra till företagets innovations kraft.
Av dessa skäl kan man inte enbart förlita sig på att det finns extern kompetens att köpa upp, man måste hitta mekanismer för att själv kunna driva innovation [N3].
3.2.7 Innovation lyckas sällan och tar tid
Det kan på ytan verka som om succé sker över en natt. Ta iPod till exempel, helt plötsligt så var den bara överallt alla skulle ha en och den sålde som smör. Det var i och för sig ”bara” en mp3 spelare men under skalet så doldes så mycket mer. En helt integrerad lösning med en design som tilltalade användarna både på ett praktiskt och estetiskt plan. Men hur fort gick det egentligen? Den lanserades 2001 det fjärde kvartalet och sålde då relativt låga volymer. Produkten förfinades sedan successivt och det var först i det fjärde kvartalet 04 som försäljningen började ta fart. Första kvartalet 05 var succén ett faktum [N4]. Det tog totalt fyra år innan iPod blev riktigt etablerad. Vägen fram till denna framgång var inte heller helt spikrak. Tittar man på Apples historia från det att Steve Jobs kom
tillbaka till företaget igen 1997 så var det inte idel framgångar för deras satsningar. Ett av dessa misslyckanden var G4 Cube – en kubformad dator som enligt de flesta var otroligt snygg. Den blev dock inte riktigt lika snygg i verkligheten p.g.a. att dess rena design var en otrolig kontrast mot fula kabelhärvor samt att plasten i skalet lätt sprack och gav den ett
sysslar med innovation. Man kommer att misslyckas ibland så det gäller att ha detta med i beräkningarna. Varje misslyckande måste leda till att värdefull kunskap genereras.
3.2.8 Fem färdigheter som används vid innovation
Jeffrey H. Dyer, Hal B. Gregersen och Clayton M. Christensen presenterar i en artikel i Harvard buisness review fem centrala färdigheter som skiljer de som är bra på innovation från de som är sämre. De menar att det är dessa fem färdigheter som kopplas samman och leder till nytänkande. De påstår även att om man är medveten om dessa färdigheter så kan man aktivt träna sig i dem för att bli mer innovativ. De fem färdigheterna är:
• Association: Detta är innebär förmågan att koppla samman tillsynes orelaterade
frågeställningar. Att bryta ut ur status quo och se nya möjligheter. Ju bredare erfarenhet och kunskap desto fler möjligheter till kopplingar finns det.
• Ifrågasättande: Peter Drucker beskrev detta så här ”The important and difficult job is
never to find the rigth answers, it is to find the rigth question.” Hitta och ställ rätt frågor.
Fråga ”varför” och ”varför inte” samt ”tänk om”. Föreställ dig motsatser och försök att förena dessa. Om ett påstående existerar spela djävulens advokat och ifrågasätt detta påstående. Välkomna begränsningar, tänk om du inte hade anställt den personen, inte hade implementerat en process eller följt en viss strategi vad skulle hända då?
• Observera: Genom att noggrant observera vanliga fenomen kan många behov hos kunder upptäckas. Scott Cook utryckte sig såhär ”Often the surprises that lead to new buissnes ideas come from watching other people work and live their normal lives.” • Experimentera: Liksom vetenskapsmän experimenterar innovativa entreprenörer aktivt
med nya idéer. De skapar prototyper och lanserar pilotprojekt och observerar reaktioner på dessa.
• Nätverkande: Att ägna tid åt att hitta och testa idéer genom nätverk av olika individer ger innovatörer ett annorlunda perspektiv. Innovativa entreprenörer anstränger sig för att träffa människor med olika sorters idéer och perspektiv för att vidga sina egna vyer.
Innovatörer har ofta en naturlig fallenhet för dessa färdigheter men det går att träna sig menar författarna. Genom aktiviteter som tvingar personer att associera, ifrågasätta, observera, experimentera och nätverka [AC1].
3.3 Gränssnittet mellan människa och dator
”Neither [Interface]design nor engineering is sufficient for the task at hand, and both are essential.” Buxton [N6].
Påståendet ovan tycker jag sammanfattar gränssnittets förhållande till resten av mjukvaran.
Arbetet fokuserar på mjukvara som används av människor, denna avgränsning kan tyckas trivial för någon som inte är insatt i mjukvarutveckling. Men faktum är att det finns mycket mjukvara som inte har något direkt gränssnitt mot människor utan som körs som
bakgrundsprocesser för att styra olika system eller interagera med andra system. Eller där gränssnittet implicit definieras av användningsområdet. ABS-bromsar har ju en
bromspedal som gränssnitt mot användaren men detta definieras ju ej i
utvecklingsprocessen av mjukvaran. Gränssnittet är det användaren ser och det som för användaren definierar mjukvaran. Kan användaren inte komma åt funktioner genom gränssnittet så existerar de inte för användaren. Gränssnittets design är därför lika central som mjukvarans underliggande funktionalitet för dess nyttovärde.
3.3.1 Design
Själva ordet design är oerhört svårdefinierbart. Jag definierar det som en process där man organiserar en mängd element på ett önskvärt sätt. Denna organisation utgör sedan den lämpliga enheten för att uppfylla ett förutbestämt mål för ett givet sammanhang. Arbetet med design består i att definiera de element som utgör designen och att utforska olika möjliga organisationer av dessa [A7].
”Design is not just what it looks like and feels like. Design is how it works”-Steve Jobs [A8] Design i någon form finns med i alla delar av mjukvarutveckling. Detta gör att själva ordet får en så diffus betydelse att det ibland kan kännas innehållslöst. I det här arbetet så talar jag i huvudsak om två typer av design, den logiska uppdelningen och funktionen som utgör själva koden refereras tills om mjukvarudesign och den grafiska modell som användaren exponeras för kallas för gränssnittsdesign.
3.3.1 Användargränssnittets plats i utvecklingsprocessen
Endast stora företag använder specialister för att utveckla användargränssnitten till deras applikationer. Detta innebär att det ofta är mjukvaruingenjören som får till uppgift att utveckla användargränssnittet [O11]. Detta får till följd att designprocessen direkt vävs in i utvecklingen av mjukvarusystemet. UI-designprocessen ses som en iterativ process där användare interagerar med designern och prototyper av gränssnittet för att bestämma vilka ”features” som skall vara med samt hur dessa skall vara organiserade. Vid iterativ utveckling fortskrider gränssnittets design vanligtvis inkrementellt tillsammans med den övriga utvecklingen. Detta ses idag av många som ett problem eftersom mjukvarutvecklare sällan har de färdigheter som krävs för att utforma bra design [O12].
3.3.3 Patterns vid utveckling av UI(användargränssnitt)
Patterns (mönster) är ett vanligt förekommande hjälpmedel vid objektorienterad
mjukvarutveckling. Patterns kan vara fördefinierad arkitektur som man konformerar systemet till. Eftersom att det tillvägagångssättet har löst liknande problem tidigare. Ett sådant pattern kallas arkitekturiellt pattern. MVC (Model View Controller) är är ett sådant pattern, det är ett av de vanligaste pattern som används vid implementation av
användargränssnitt. Här separerar man systemet i tre huvudsakliga delar, modellen, vyn och kontrollern. Modellen håller det data systemet hanterarar. Vyn renderar
användargränssnittet och kontrollern tar emot händelser från användaren och gör anrop till modellen. Styrkan som ofta framhålls är här att man separerar data från gränssnittet och möjliggör för att underliggande funktionalitet ej är beroende av användargränssnittets utformning. Detta är väldigt bra för företag som vill bygga generella gränssnittsbibliotek. Cocoa och Cocoa Touch från Apple (gränssnittsbiblioteken för Mac OS X respektive iOS)
3.3.4 Designens roll vid framgång för innovation
Vid ett flertal tillfällen så har användargränssnittet spelat en helt avgörande roll för en produkts framgång. Vi börjar med det exempel som fick en hel industri att inse att det fanns en massmarknad för datorer; Visicalc. Detta var det första kalkylprogrammet och dess enkla gränssnitt gjorde kalkyl tillgängligt för alla. All funktionalitet för att utföra enkla beräkningar och bokföring fanns redan i maskinen om man lärde sig något högnivåspråk t.ex basic eller pascal men det krävdes att någon erbjöd användaren ett gränssnitt som samlade denna funktionalitet för att gemene man skulle förstå detta [Ä1]. Om vi går framåt några år i tiden till Xerox uppfinning av grafiska användargränssnitt som en metod att hantera sin dator och dess operativsystem, så ses detta som en stor del av framgångarna för PC´n, att man lyckades sänka inlärningströskeln för att hantera sin persondator med hjälp av ett enklare gränssnitt än det tidigare CLI (textbaserade) gränssnittet. Enligt Peter Manning så var detta även en avgörande faktor till att datorn blev ett centralt verktyg för musikproduktion [E2]. Ett exempel som känns särskilt relevant för detta arbete är
musikprogrammet Cubase som med sin grafiska representation av arrangemanget och noterna blev en mall för hur musikprogram kom att se ut [Q1][AE1]. Ytterligare ett exempel är när synthtillverkaren Roland år 1991 släppte sin JD-800 synth. Synthen innehöll en lätt uppdaterad version av den tidigare framgångsrika D-50-arkitekturen från 1987 med den stora skillnaden att ett stort fysiskt användargränssnitt lagts till för att användaren lättare och snabbare skulle komma åt de parametrar som formade ljudet. I princip alla synthar som släpptes efter denna, där användarna antogs vilja skapa egna ljud och inte bara använda förinställda ljud, gjorde samma sak och gjorde parametrarna tillgängliga via reglage.
Man kan kort sagt påstå att även om användargränssnittet inte är den enda faktorn som avgör om en mjukvara är framgångsrik så är det definitivt en av de viktigaste faktorerna. Idag kan man även se en trend där allt fler program med samma underliggande
funktionalitet konkurrerar med varandra där den enda egentliga skillnaden är det grafiska gränssnittet. Andra exempel där gränssnittet och designen varit avgörande del i
framgången för produkten är iPod [N7] och iPhone.
Model-View-Controller-koncept. Den heldragna linjen representerar en direkt förbindelse, den streckade linjen indikerar förbindelse via en observatör. Källa: http://sv.wikipedia.org/wiki/Fil:ModelViewControllerDiagram2.svg
