Artikelförfattare: Grinter

Sammanfattande student: Anna Liljekvist

"Supporting Articulation Work Using Software Configuration Management Systems" by Rebecca Grinter (1996)

Grinters syfte och metod:

Artikeln handlar om en empirisk studie som Grinter utfsrt fsr att undersska hur anvSndningen av ett system fsr att koordinera arbetet ser ut. Det system Grinter utvSrderade kallas fsr ett "configuration management tool" (CM). I studien har hon fokuserat pŒ tre huvudaspekter: Hur arbetet representeras i systemet, behovet av att stsdja bŒde individuellt arbete och grupparbete, hur inbyggda fsrestSllningar i systemet interagerar med organisationen i svrigt. Grinter har valt tvŒ fsretag, "Tool Corp." som utvecklar CMs och "Computer Corp." som ska byta ut sitt gamla CM mot det som "Tool Corp." bygger.

Intro till CM:

Den fsrsta generationens CMs anvSnde sig frSmst av s.k. "checked-out" och "checked-in" fsr att kontrollera fsrSndringar pŒ programkoderna. Det gick bara att koda en Œt gŒngen och systemet stsdde bara kodningen. I modernare CMs kan flera jobba samtidigt pŒ samma modul s.k. parallell utveckling. Dagens CMs har dessutom tre andra funktionalitets lager utsver check-in/ check-out modellen. De funktioner de tillSgger Sr bland annat information om de artefakter som formar slutprodukten, vilken livscykel de befinner sig i t.ex. under kvalitetstestning etc

Utmaningar fsr CM verktyg

Det finns en del utmaningar med CM som Tool Corp. och Computer Corp. upptSckte nSr de anvSnde det. En utmaning var den parallella utvecklingen, trots att systemet stsdjer parallell kodning Sven pŒ samma stSlle i modulen sŒ undvek de flesta att utfsra kodning parallellt fsr att det var fsr komplicerat. De flesta brukade bestSmma att koda en i taget, eller sŒ samlades de runt en terminal (joint merging). PŒ Computer Corp. gick de t.o.m. runt systemet och Sndrade nSr modulen var i "check-in" stadiet Sven om det kunde fŒ allvarliga efterverkningar fsr andra moduler. Detta gjorde de fsr att om de var siste person som Sndrade i en modul var de skyldiga att sammanfsra alla Sndringar som gjorts parallellt och testksra det med andra rutiner innan den kunde checkas in, vilket tog tid. En andra utmaning gSllde representationen av hela arbetsprocessen. PŒ Tool Corp. saknade utvecklarna information om hur deras eget arbete passade in i helhetsbilden under systemutvecklingsprocessen, det fanns ingen representation av arkitekturen sver hela systemet. PŒ det viset var det svŒrt att fŒ fsrstŒelse fsr andra utvecklares arbete och hur allt passade ihop. Den tredje utmaningen handlade om att systemet inte visade pŒ beroendefsrhŒllanden som rŒdde mellan subsystem pŒ organisationsnivŒ. Anledningen till parallell problematiken fsrklarar Grinter bland annat med den formella och kulturella sprŒkliga nivŒn. PŒ den formella nivŒn kan saker diskuteras utan nSrmare fsrklaring. PŒ den kulturella nivŒn krSvs det fsrklaringar fsr att de involverade ska fsrstŒ. CM stsdde alltsŒ parallell utveckling pŒ den formella nivŒn men det blev oanvSndbart nSr det blev fsr komplext fsr dŒ krSvdes stsd pŒ den kulturella nivŒn. Systemet stsdde inte heller koordineringen mellan grupper som jobbade pŒ olika subsystem utan bara pŒ individnivŒ inom en grupp (arkitekturproblematiken). Ett sista problem med den hSr typen av verktyg Sr vad som sker nSr den inbyggda modellen i systemet inte stSmmer sverens med den i verkligheten vilket ledde till att utvecklar gick runt systemet.

Slutsatser:

Att det Sr viktigt att fsrstŒ interaktionen mellan organisationen och verktyget fsr CM system-utvecklare och att CM verktyg har egenskaper som liknar gruppvarusystem. Det organisatoriska sammanhanget mŒste byggas in i CM-verktyget genom att gsra informationen om systemutvecklingsprocessen tillgSnglig fsr utvecklarna.