I detta kapitel beskrivs den validering vi gjort av vårt ramverk. Denna validering har skett genom en kvalitativ intervjustudie. Detta kapitel mynnar ut i eventuella föränd-ringar som bör implementeras i vårt ramverk.
We must learn our limits. We are all something, but none of us are everything.
- Blaise Pascal För att kontrollera att vi har förstått utvecklarna av e-Me rätt, och för att validera att den input vi har fått från dem lyser igenom vårt ramverk, har vi genomfört en kvalitativ vali-derande intervjustudie.
7.1 Respondenter
Vi har intervjuat samtliga utvecklare igen, denna gång genom två e-postintervjuer med respondenterna B och C (på grund av en av utvecklarnas tidsbrist och en av utvecklarnas ledighet) samt en fysisk intervju på InnovationLab, med respondent A. För en kort be-skrivning av respondenterna, se 4.1 Respondenter.
7.2 Validering av kriterier
När det gäller de kriterier vi tagit fram för vårt ramverk tyckte respondent A vi diskutera-de diskutera-detta med att vi hadiskutera-de hittat rätt. Han håller på med om att API:er bör vara flexibla, han gav dock ett exempel på en situation där de absolut inte bör vara det. Detta exempel handlade om ett API som han och en medarbetare utvecklade, där integritetsfrågan var av högsta vikt, därför var det viktigt att inte lämna något som helst utrymme för att kränka integriteten, och därav blev API:et ej flexibelt. Han anser dock att i 95% av fallen så bör ett API vara flexibelt. Flexibilitet är även väldigt viktigt inom agila systemutvecklings-metoder, samt co-design, då man som utvecklare måste vara mottaglig för förändringar och förbättringar i förhållande till konsumenterna. Att ha en hög flexibilitet är även vik-tigt för metautvecklingsprocessen, där flexibilitet skapas genom att man låter användaren välja olika vägar inom en metodik.
Han anser att outside in-tänket är väldigt bra, och att man för att bygga API:et först måste ta reda på vem som vill använda API:et till vad. Också riskanalysen tycker han är viktig, speciellt ur säkerhets- och integritetsperspektiven. Han anser, precis som i outside in-tänket, att det är viktigt att blanda in slutanvändaren (konsumenten) för att få ett så bra API som möjligt, och ett led i detta kan vara att göra prototyper, vilket han definitivt tycker var ett bra kriterium. Detta kriterium kan även grundas i teorin om test-driven de-velopment, där man anammar precis detta perspektiv.
Dokumentation av API:et är enligt utvecklare A oerhört viktigt, och speciellt att doku-mentationen uppdateras i takt med det faktiska API:et. Han påpekar dock att detta kan vara relativt svårt att göra, även för väldigt stora aktörer som skapar API:er. Som
exem-pel nämnde han Googles Calendar-API, som han har arbetat med i e-Meprojektet. Google hade uppdaterat sitt plugin, och utvecklaren installerade den nya versionen. Han fick då ett fel han inte fått innan, och det tog två timmar innan han kom på att det hade tillkom-mit ett beroende i API:et som han var tvungen att hantera, genom att ladda ner filerna för detta beroende och inkludera i projektet. Det nämndes ingenting om detta i Googles egna dokumentation, utan han hittade det genom att använda just sökmotorn Google. Man kan i detta fall dra paralleller till utvecklingsmetoden Scrum: Där man dokumenterar det som är viktigt, och inte bara dokumenterar för sakens skull. I Scrum dokumenterar man till exempel vad kunden vill ha, och i Googles fall borde man ha dokumenterat vilka beroen-den gränssnittet vill ha.
Enkelhet och tydlighet är enligt respondent A nödvändigt för att snabbt kunna ta till sig en ny metod, modell eller ett nytt ramverk. Han höll också med författarna att de tre krite-rier som identifierats med prioritet medel var korrekt prioriterade, detta eftersom dessa tre kriterier (funktionalitet, användande av standardiserade tekniker och kompabilitet) i nå-gon mån är beroende av vad som framkommer under co-design: Hur och vad vill slutan-vändaren egentligen ha? Det kan enligt utvecklaren i flera fall till exempel vara lämpligt med ett API som har en egen kommunikationsstandard, som passar för just det API:et specifika ändamål.
När det gäller kriterier att man skall jobba outside in, med tester, anser respondent B att det är oklart vilken typ av tester som menas. Han anser att den typ av testning som vi av-ser, programmatiska tester, ej är den enda typen av tester som kan användas, han föreslår till exempel användartester. Med fasen Test Case(s) Identification & Specification avser vi dock att mappa implementationen mot kontraktet, och därigenom säkerställa att kon-sumenternas förväntningar programmatiskt infrias, vilket kan ha varit lite otydligt. Denna utvecklare var inte heller helt säker på vad vi menade med grafiska gränssnitt under krite-riet Kompabilitet, det finns nämligen ingen närmare förklaring av detta i det underlag som respondenterna tog del av. Detta förklaras dock tidigare i denna studie.
Sammanfattningsvis så verkar det som om de kriterier vi tagit fram med hjälp av den ti-digare studien samt benchmarkingen är bra för ändamålet, och tillför något till utveck-lingen av själva ramverket. När det gäller den teoretiska valideringen av ramverket, så har kriterierna främst sin grund i agila systemutvecklingsmetoder, co-design och metaut-veckling.
7.3 Validering av ramverk
När det gäller själva ramverket hade de tre respondenterna lite skiljda åsikter: Två av ut-vecklarna (respondenterna A och B) tyckte direkt att ramverket och modellen var klar och tydlig, medan den tredje (respondent C) ansåg att det inte var så lätt att se att arbetet sker i iterationer. Den utvecklaren blev ”lurad” av att vi använder ordet faser, han anser att man aldrig kan gå tillbaka till en föregående fas. Han ansåg också att modellen såg lite ”vattenfall” ut, vilket de andra utvecklarna inte ansåg. Respondent C som ansåg att mo-dellen såg ut som en vattenfallsmodell föreslog att vi döper om ”fas” till ”arbetsmoment” eller något liknande, samt att vi försöker förändra den grafiska representationen av ram-verket till något som tydligare visar att arbetet sker iterativt, till exempel att göra
model-len i cirkulär form istället. När det gäller namnet på ramverket så anser två av utvecklarna (respondent A och B) att det är bra, då det fångar SOA, API och SOAP, och är relativt lätt att komma ihåg och uttala.
Respondenterna A och B tyckte direkt att modellen var klar och tydlig, och fick direkt ett positivt intryck av den. De anser att det ramverket tar upp är sådant som man som utveck-lare av ett API faktiskt behöver ta upp, även om den kanske är lite av en idealbild: Man hinner eller har inte alltid möjlighet att ta upp allt i ramverket. De anser dock att man egentligen bör ta upp det. Respondent A tycker också att modellen går att applicera på projektet e-Me, och att vissa av aktiviteterna har genomförts i arbetet med e-Me. Han an-ser dock att vissa av aktiviteterna kan vara svåra att förstå enbart grundat på namnet: Till exempel Sharing analysis. Han anser att det behövs en skriftlig förklaring till hur man arbetar med ramverket, och att denna skrift framförallt beskriver de olika aktiviteterna. Det respondent A tycker saknas i modellen är någon form av versionshantering: Hur ser det ut om man levererar API:et i olika omgångar? Han anser därför att det behövs någon form av inkrementell leverans av själva API:et, och att detta framgår av ramverket. Om det inte finns någon bra versionshantering, så kan det vara lätt att bryta kontraktet vid uppdateringar eller tillägg till API:et. Det är därför viktigt att kommunicera med konsu-menterna, och att kommunicera ändringar av API:et i god tid. Ett exempel på detta är Ladoks API:er, som utvecklaren har jobbat med. Tidigare var Ladok benägna till att bryta kontrakten för sina API:er vid uppdateringar, nu har de enligt utvecklaren lärt sig av sina misstag, och försöker så gott det går med att inte bryta kontraktet. Detta tog respondent C upp under den första omgången intervjuer.
Det är också enligt utvecklarna A, B och C viktigt att iterativt förbättra API:er, genom utvärderingar av dessa i samarbete med alla intressenter. Som respondent A uttryckte det: ”Bugghantering och förvaltning kommer man aldrig ifrån, och det är något man måste leva med”. Det är därför viktigt med utvärdering.
Respondent B anser att fasen Conceptualization har ett mycket bra innehåll, men han ifrågasätter ordningen i den. Han anser att aktiviteten Consumer Expectations
Identifica-tion eventuellt bör ligga före aktiviteten Sharing Analysis, samt att det bör ske någon sorts iterativt flöde mellan dessa. Han anser att konsumentens behov bör styra vad man delar med sig av. Denna utvecklare tycker också att det skulle vara intressant att förklara mer hur aktiviteten Contract Validation fungerar. Han anser också att det kan vara lite svårt att förstå vad termen outside in egentligen betyder.
När det gäller hur utvecklarna A och C upptäcker nya ramverk, metoder och idéer inom systemutveckling, så sade dem att det är relativt mycket som sprids från jobbarkompisar och bekanta, och därigenom når utvecklarna. De håller sig också uppdaterade genom till exempel forum och bloggar, samt communities som till exempel ASP.NET. När dem le-tar efter något specifikt, till exempel för att lösa ett specifikt problem, är det främst Goog-le Search som används, och dem anser att detta fungerar bra.
Utvecklarna (A, B och C) anser alltså att det är viktigt att klargöra att arbetet med ram-verket sker iterativt, samt att klart och tydligt förklara de olika aktiviteterna. Respondent B anser också att det vore bra att på något sätt i själva modellen över ramverket klargöra vilka intressenter som utför aktiviteterna. Även utvärderingar anser respondenterna A, B och C behöver införas, samt stöd för delleveranser och versionshantering.
De teorier som främst går att applicera på ramverket är agila systemutvecklingsmetoder och co-design. I ramverket sker utvecklingen iterativt och inkrementellt, vilket oftast är fallet i agila systemutvecklingsmetoder, samt i nära samarbete med användaren i alla fa-ser, vilket ökar graden av co-design.
7.4 Nya kriterier och förändringsåtgärder
De nya kriterier och förändringsåtgärder som vi har identifierat utifrån de validerande intervjuerna är:
• Iterationer. Visa klart och tydligt att arbetet kan ske i iterationer.
• Intressenter. Visa vilka intressenter som är inblandade i vilka aktiviteter. • Utvärdering. Inför utvärdering av API:et, i samarbete med alla intressenter. • Delleveranser/Versionshantering. Inför och visa att API:er kan levereras
inkre-mentellt.
• Förtydliga Contract Validation. Hur sker denna validering?
• Justera Conceptualization. Sharing Analysis bör ske i samband med Consumer
Expectations Identification; konsumentens behov bör styra det som API:et expo-nerar, ej tvärtom. Ge också en bättre bild av att detta kan ske iterativt.
Vi kommer att i nästa kapitel att införa dessa förändringsåtgärder i vårt ramverk.
7.5 Sammanfattning
Sammanfattningsvis var intrycket av ramverket positivt, och det som saknades var främst en tydlig indikation om att det går att iterera genom de olika aktiviteterna, och att införa en versionshantering och stöd för delleveranser. Det är också viktigt att visa vilka intres-senter som ingår i vilka aktiviteter.