Processen består av tre huvuddelar: • Visual Studio
• Team Foundation Server
• Webbservice, agerar mellanhand mellan utvecklare, TFS och personer som ska uppdatera dokument
För att detta ska kunna fungera i praktiken behöver ett antal verktyg tas fram eller modifieras och det behövs ett antal kopplingar mellan olika personer och artefakter, 4.10. Olika dokumenttyper ska ändras av olika roller och man behöver därför definiera vilka dokument som ska ändras av vilka, se figur 4.9.
De två huvuddelarna av processen, uppdatering och generering, arbetar lite olika:
Figur 4.9. Kopplingar för dokumentuppdatering i nya processen
Figur 4.10. Kopplingar för dokumentgenerering i nya processen
4.3.1
Filformat
I mina exempel och undersökningar har jag fokuserat på Microsoft Word 2007(.docx) då det är formatet som används för dokument på Medius, men det ska finnas möj- lighet att senare kunna lägga till stöd för andra filformat.
4.3 Implementering 37
4.3.2
Dokumentlagringsmetoder
På något sätt behöver man lösa problemet med att bara visa upp rätt delar av existerande dokumentet för användaren. Det finns ett antal vägar att göra detta.
Jag rekommenderar att man implementerar en funktion som varje natt går igenom alla länkar och skickar de som inte stämmer till webbservicen, som bör in- nehålla funktionalitet för att användare ska kunna rätta till de felaktiga länkarna. Hur man identifierar en dokumentdel
Alla metoder där man sparar hela dokumentet ger ett problem, hur man ident- ifierar en del av ett dokument. Det finns två enkla sätt:
Rubrikens text Man sparar vad rubriken heter, “Rubrik 3 har texten
’Metodbeskrivning’ ” och förutsätter att det bara finns en rubrik med det namnet i dokumentet. Den här metoden klarar inte att man rättar stavning i eller döper om rubriker.
Rubrikens placering Man sparar var i dokumentet rubriken finns, “Rubrik 3 finns efter tecken 1743”. Metoden klarar inte av att man ändrar antalet tecken innan rubriken; lägger man till eller tar bort en enda bokstav i hela dokumentet före delen stämmer inte antalet längre.
Båda dessa får problem om dokumentet ändras efter att länken skapats. På grund av dessa brister föreslår jag en kombination av dessa metoder.
Man sparar var i dokumentet rubriken finns och vad den har för text. När det är dags att undersöka om länken stämmer kollar man om rubriken finns där och att texten stämmer, gör den inte det går man till närmaste rubrik som skiljer sig så lite som möjligt från den lagrade texten. Det blir en del merarbete men kommer förhoppningsvis att kunna klara av många små ändringar utan manuellt arbete. Användare bör bekräfta de nya kopplingarna, i de fall det går att hitta förslag på troliga nya kopplingar kan systemet förhoppningsvis spara mycket tid.
Dela lokalt
Man kan hämta hem hela dokumentet från servern, dela upp det genom mjukvara och visa upp temporära dokument. När användaren stängt ner dessa kopieras innehållet tillbaka till originaldokumentet som sedan skickas tillbaka till servern. Jag har gjort en kort undersökning och API:t för att styra Microsoft Word 2007 verkar kompetent nog för detta. Det finns dock problem: kopierandet fram och tillbaka kan bli svårt; stilmallar, bilder och liknande saker som är mer avancerade än vanlig text kan skapa problem.
Dela på server
Man kan sköta delningen av dokument på servern och bara hämta hem rätt delar av dokumentet. När användaren är klar skickar verktyget sonika tillbaka de modifierade delarna, och dokumentet slås ihop igen på servern. En fördel med
detta jämfört med ovanstående är att man kan låsa en del av dokumentet utan att behöva låsa hela när man bara ändrar en viss bit.
En risk med den här metoden är att belastningen på servern bli väldigt tung om det blir många som ska delas och slås ihop.
Spara delat
Man kan spara dokumentdelarna som enskilda dokument och bara slå samman dem vid behov, ungefär som man arbetar med LATEX[24]. Då skulle man spara in
på delning och sammanslagning men det skulle ge mångdubbelt fler filer att hålla koll på.
Väljer man den här metoden behöver man upprätta och underhålla listor för vilka dokumentdelar som hör till vilka dokument vilket om man har många dokument kan bli en del jobb. Detta behövs inte för övriga metoder då själva dokumentet lagras i sin helhet på servern och delas innan det skickas eller levereras i sin helhet. Man slipper dock problemet med att identifiera var en del av ett dokument finns.
Problemet med denna lösning är troligen formatmallar, bilder och annat innehåll som inte är ren text.
Automatisk bläddring
Man kan skicka hela dokumentet och implementera ett litet verktyg som bläddrar till rätt avsnitt. En begränsad undersökning har som jag gjort visat att detta troligen inte skulle vara särskilt svårt att göra. Jag har implementerat en proto- typ som klarar av att bläddra mellan rubriker, ett mer komplett verktyg handlar troligen bara om lite mer tid.
Manuell bläddring
Man kan skicka hela dokument fram och tillbaka och låta användaren hitta rätt delar själv. Markant enklare att implementera men innebär mer arbete för användaren.
4.3.3
Vald metod
Hade det bara varit fråga om uppdatering av dokument hade jag rekommenderat Automatisk bläddring. Användaren slipper fundera över var i dokumentet som ändringarna ska göras vilket jag tror är den egentliga efterfrågade funktionaliteten, utan att belasta vare sig server eller klient markant. Den lösningen kräver troligen också betydligt mindre tid för implementation än “Dela på server”, “Dela lokalt” och “Spara delat”. Jag tog upp mitt förslag på metod med min handledare och en medlem i en fokusgrupp(utveckklarna) och de höll med, att enkelt hitta rätt del av dokumentet var den egentliga efterfrågade funktionaliteten när det gäller uppdatering.
Men ska man generera dokument av delar på begäran så är “Spara delat” det enda alternativet som inte medför en mängd merarbete. Annars behöver man
4.3 Implementering 39
extrahera delarna ur existerande dokument för att kunna bygga upp andra dokument av dessa, och att hålla koll på i vilka dokument vilka delar finns och i vilken version blir troligen betydligt mer jobb än att lagra dem i delar. I resten av processbeskrivningen kommer jag att utgå från att “Spara delat” är den valda metoden för att lagra dokumentdelar.
Dokumentdelarna lagras på Sharepoint för att de då går att komma åt från alla datorer om det skulle behövas, och man får versionshantering och låsning på köpet.
4.3.4
Låsning och versionshantering av dokument
Enbart en utvecklare i taget kan arbeta med ett dokument om det inte ska bli krockar och konflikter; om två personer vill ändra i olika delar av ett dokument går inte detta att göra parallellt utan de behöver arbeta sekventiellt. Detta kan skapa problem då personer glömmer att de redigerar dokument och liknande problem som beror på den mänskliga faktorn uppstår.
Den mänskliga faktorn skulle gå att lösa genom att implementera låsnings- funktionalitet på servern. När någon laddar hem ett dokument för uppdatering kan ingen annan ladda hem det innan den första personen är klar. Då bör använ- daren ges möjlighet att ställa sig i en kö och bli notifierad när personerna före i kön är klara med dokumentet och användaren kan börja göra sina uppdateringar. Ett enklare alternativ till att implementera en egen låsning är att använda den som finns i SharePoint. Då Medius redan använder sig av SharePoint för sin dokumenthantering verkar detta vara en enkel och tillräckligt kompetent lösning. Använder man SharePoint för dokumenthanteringen får man även versions- hantering på köpet vilket är ett till argument för att inte implementera en egen lösning.
Det finns även ett tredje alternativ, att lagra dokumentdelarna som versions- hanterade filer i TFS:en. Då får man versionhantering och låsning, och av vad jag sett av API:erna verkar TFS:en betydligt enklare att arbeta med, vilket gör att detta är alternativet som rekommenderas. Kömekanismen som diskuteras ovan går troligen att implementera genom prenumeration av händelser eller genom att med ett visst intervall se om filen är ledig. De färdiga dokumenten kommer att behövas läggas upp på Sharepoint, men man slipper arbeta mot den mitt under processens gång.
4.3.5
Generera dokument
Generering av dokument sker genom att användaren ber om ett dokument för en version. Detta sker via webbservicen som då hämtar hem information om relevanta PBI:er för den versionen. Denna information talar om vilka dokumentdelar som hör till dessa PBI:er samt vilken typ av dokument de bygger upp. De delar som bygger upp rätt typ hämtas och slås ihop till det efterfrågade dokumentet. Detta laddas upp på Sharepoint och användaren meddelas om var denne kan hitta dokumentet.