projektgrupper för att kunna vara mer tidseffektiva. Att ha regelbundna möten underlättade för alla projektgrupper eftersom samtliga projektmedlemmar visste statusen på produkten. De erfarenheter som var mer relevanta för det här projektet var att påbörja GUI:t tidigare, ha fler kundmöten och ha fler statusmöten. Dessa erfarenheter är applicerbara för liknande projekt. Att börja arbeta på ett GUI:t tidigt är applicerbart på projekt som ska implementera ett GUI. Att ha flera kundmöten är relevant för de projektgrupper som har en produkt som är komplex. Att ha statusmöten är applicerbart för de arbetsgrupper som använder sig av att ha ett möte där alla gruppmedlemmarna kan få hjälp med problem som har uppstått och fastnat med.
6.4
Diskussion om B-ASIC:s värdeskapande
I detta kapitel diskuteras metoden för hur projektgruppen skulle arbeta för att B-ASIC skulle vara av värde till kunden.
6.4.1
B-ASIC
B-ASIC är en produkt som skapades i syfte att designa och analysera kretsar på hög nivå. Ge- nom ett enkelt användargränssnitt utvecklat i främst Python är användandet mycket enkelt för användare av biblioteket.
Vidare har projektgruppen även implementerat ett GUI för biblioteket B-ASIC i syfte att för- enkla användningen ytterligare. Detta medför att produkten B-ASIC levereras med möjlighet att använda enbart biblioteket B-ASIC samt ett GUI som implementerat funktionaliteten hos biblioteket.
Produkten B-ASIC har utvecklats under den öppna källkodslicensen MIT, vilket medför att vidareutveckling och verifiering av produktkoden är enkelt för alla parter som är intresserade av produkten.
B-ASIC är således en produkt som skapar värde för dels kunden samt för andra intressenter.
6.4.2
Samtal med kunden
Genom många samtal med kunden om dess förväntningar av produkten fick projektgruppen en bättre förståelse om vad som skulle utvecklas. Det var i projektets initiala fas som projekt- gruppen hade mest möjlighet att anpassa utvecklingsmålen till kundens önskemål då ingen eller liten utveckling hade påbörjats.
Ett krav som formulerades tidigt efter ett initialt möte med kunden var det om projektets vidareutvecklingsbarhet. Det var viktigt för kunden med enkel vidareutveckling av grund- funktionalitet och detta var något som formulerades i kravspecifikationen. Fler samtal med kunden hade behövts här då vidareutvecklingsbarhet inte är svart och vitt. Arkitekturen och programkoden hade i en större skala behövts anpassas till kundens önskemål för att maxi- mera det kunden anser vara vidareutvecklingsbart.
6.4. Diskussion om B-ASIC:s värdeskapande
6.4.2.1 Kravlista
De förändringar som gjordes i kravspecifikationen med omförhandling av krav gjorde det möjligt för projektgruppen att skapa produkten. När omformuleringar och förtydliganden om krav gjordes underlättade det för projektgruppen att förstå sig på kravets innebörd. Det gjorde att projektgruppen fick en bra bild av hur delar av B-ASIC ska fungera och har en bättre förståelse hur implementationen ska fungera. Vid omförhandling av de krav som togs bort påverkade det projektgruppen så att utvecklingen av produkten blev mer genomförbar. Att utvecklingen av produkten blev mer genomförbar hjälpte projektgruppen att göra en produkt som blir komplett till vad den ska kunna utföra. Det leder till att produkten inte har krav som inte är implementerade och gör att kunden är mer nöjd med en färdig produkt än en halvfärdig produkt.
Kravlistan som formulerades i en kravspecifikation var positivt värdeskapande då projekt- gruppen fick en god möjlighet att ta ställning till, och omförhandla krav för att sätta en rea- listisk förväntning till kunden. En del krav utgick under projektets gång och mindre omfor- muleringar och förtydliganden gjordes. Ett exempel på en större förändring var att sekun- därkravet på ett grafiskt gränssnitt ändrades till ett primärkrav då det var önskat av kunden och projektgruppen ansåg det vara görbart inom ramen för projektets budget.
6.4.3
GUI-prototyp
Efter att projektgruppen, tillsammans med kunden, bestämde sig för att ändra GUI- sekundärkravet till ett primärkrav framtogs en GUI-pappersskiss som kan ses i bilagor Figur I.1. Denna omarbetades under projektets gång och den slutgiltiga GUI-designen kan ses i bi- lagor Figur I.2. En sammanfattad jämförelse kan göras mellan Figur I.1 och Figur I.2 i Tabell 6.1:
Tabell 6.1: Jämförelser mellan första och slutgiltiga GUI-prototypen
Skiss Leverans
En lista av operationsikoner finns till vänster.
En lista av operationsnamn finns till väns- ter.
Högerklickmenyn tillåter namnbyte. Högerklickmenyn tillåter namnbyte. Överst i fönstret finns knapparna ’File’
och ’Edit’.
Överst i fönstret finns knapparna ’File’, ’Edit’ och ’View’.
De tekniska begränsningar som projektgruppen fått anpassa sig efter påverkade designen av GUI:t, men den överhängande GUI-designen från den första skissen i appendix I.1 är kvar.
6.4.4
Produktdemonstrationer
För att ytterligare öka kommunikationen mellan kunden och projektgrupp utökades pro- duktdemonstrationerna som genomfördes till ett produkttest där kunden direkt fick intera- gera med produkten under projektets gång. I detta projekt användes bara digitala produktde- monstrationer där kunden fick se på när en projektmedlem presenterade de funktioner som vid tiden för demonstrationen var implementerade.
6.4. Diskussion om B-ASIC:s värdeskapande
6.4.5
Kodgranskning
Vidareutvecklingsbarheten var en viktig aspekt för kunden. Då vidareutvecklingsbarhet är svårtolkat, och är högst individuellt, var det av stor vikt att kunden hade en god insikt i utvecklingen och en god förståelse av mjukvaruarkitekturen samt kodstilen. Det fanns så- ledes en möjlighet till ökat kundvärde genom att ge kunden en ökad insikt i utvecklingen genom att önska kodgranskning där kunden själv fick gå igenom programkoden och lämna synpunkter på arkitektur eller implementation.
6.4.6
Kodstilguide
Projektgruppen hade formulerat en kodstilguide som var menad att sätta en rad förväntning- ar på hur projektmedlemmarna skulle skriva och formulera kod för att öka enhetligheten. Det är möjligt att ökad kundnytta hade nåtts om kunden haft ökad insikt och återkopplingsmöj- lighet i formuleringen av kodstilguiden då kunden kan få kodstilen på det sättet kunden önskar.
6.4.7
Arbetsmetodik
Ökad insyn och återkoppling från kunden om projektgruppens arbetsmetodik hade kunnat resultera i ökad produktivitet och således ökat antalet slutförda krav och implementerade funktioner.
6.4.8
Återstående för fullt kundvärde
I projektets nuvarande fas återstår det saker i projektet som maximerar det slutgiltiga kund- värdet och dessa presenteras i detta avsnitt.
Vissa av kraven uppnåddes inte på grund av tidsbrist. Dessa krav listas i restlistan nedan, se Tabell 6.2.
6.4.8.1 Restlista
Följande prioritet ett-, två- och tre-krav som specificerades i B-ASIC:s kravspecifikation har inte implementerats:
6.4. Diskussion om B-ASIC:s värdeskapande
Tabell 6.2: Projektets restlista av krav som ej uppnåddes.
Krav Kravinnehåll Prioritet
7 Användaren ska kunna bygga upp och modifiera en SFG med stöd av ett GUI. Modifieringar som ska kunna göras är krav 19, 23, 24, 25, 30, 76 och 77
1
23 En operation i en SFG ska kunna ersättas med en eller flera andra operationer med totalt sett samma antal in- och utgångar.
1 25 Alla operationer med samma typnamn i en SFG som består av
mindre beståndsdelar ska kunna delas upp till dess mindre be- ståndsdelar med totalt sätt samma antal in- och utgångar genom en automatiskt funktion.
3
26 Flera operationer i en SFG ska kunna ersättas med ett färre antal operationer med totalt sett samma antal in- och utgångar
1 33 Programmet ska kunna rulla upp flera olika fördröjningselement
som har återkopplats i en SFG
2 53 Data som beskriver schemat ska kunna skrivas ut till terminalen.
Data som ska skrivas ut är latens och exekverngtid för operatio- ner
1
54 Schemat ska kunna redovisas visuellt. 1
55 Schemat ska kunna modifieras så att operationer kan flyttas på tidsskalan, det ska dock kontrolleras att förändringen är tillåten innan den görs, d.v.s. att man inte bryter mot den topologiska ordningen av operationern
1
56 Utifrån schemat ska använda processor-element redovisas i ut- skriven data.
1 57 Utifrån schemat ska använda processor-element redovisas visu-
ellt
2 58 Utifrån schemat ska använda minneshenheter redovisas. 1 59 Utifrån schemat ska använda minnesenheter redovisas visuellt 2 60 Utifrån schemat ska olika diagram för olika kombinationer av
operationstyper och resurser kunna genereras.
2 62 I schemat ska varje ingång för varje operation ha en starttid och
ett antal varv. (Antal varv är antal perioder
1
63 Programmet ska kunna ändra schemats sluttid 1
64 Programmet ska kunna ändra schemats sluttid med en kontroll så att ingenting överlappar
2 65 Programmet ska kunna ändra på upplösningen mellan operatio-
ner i schema.
1 66 Programmet ska kunna ändra på upplösningen mellan operatio-
ner i schemat med en kontroll så att ingen information försvinner. 2 69 Programmet ska kunna utnyttja symmetri och kunna byta plats
på operationers ingångar genom att modifiera schemat.
3 70 Modifieringar på schemat ska kunna göras direkt på schemat.
Modifieringar beskrivs i kraven 55, 63 och 65.
1 71 Modifieringar av scheman ska kunna göras genom ett GUI. Mo-
difieringar som ska kunna göras är krav 55.