Implementationen består av fem stora delar: • Modul till Visual Studio
• Incheckningspolicy för Visual Studio
• Mall för arbetsuppgifter i Team Foundation Server • En användargränssnittskomponent till schablonen
• En webbservice med gränssnitt till dokumentlänkhantering • Ett användargränssnitt för webbservicen
Arbetet med att hitta information om hur dessa delar skulle kunna
implementeras har hindrats i varierande grad av det faktum att bara en tidig version av Visual Studio 2010 har släppts. Det verkar dock bara innebära större problem med modulen till Visual Studio 2010, resterande delar verkar det finnas tillräckligt stöd för att implementera i betaversionen av Visual Studio 2010. Den slutgiltiga versionen kommer troligen att släppas den 22 mars 2010[38].
4.4.1
Implementera modul till Visual Studio
För att hantera dokument och dokumentdelar från Visual Studio och som utvecklare inte behöva använda externa verktyg behövs en ny modul till Visual Studio. Då det bara finns tidiga versioner av Visual Studio 2010 så är dokument- ationen om detta kraftigt begränsad.
I den tidiga versionen av Visual Studio 2010 är stödet för att utveckla moduler inte särkilt utvecklat vilket gör den här delen svår att börja på överhuvudtaget. Stödet för utökningar ska byggas om rejält till Visual Studio 2010 vilket gör det svårt att börja utveckla mot Visual Studio 2008 och sedan uppgradera till den nyare versionen.
Modulens uppgift blir i princip att erbjuda ett gränssnitt mot webbservicen(se avsnitt 4.4.5) så att utvecklare kan arbeta i enbart Visual Studio och inte behöver använda en webbläsare vid sidan av.
4.4.2
Implementera incheckningspolicy för Visual Studio
Efter undersökningar (jag letade på forum på internet) har det visat sig att det enda enkla sättet att åstadkomma målet är att skriva en egen incheckningspolicy. En incheckningspolicy är ett test som programkod måste passera innan systemet tillåter att utvecklaren checkar in koden. Man skulle kunna implementera en policy som kontaktar webbservicen och frågar vilka dokument som hör till PBI:n som den incheckade koden hör till, visa en lista för användaren som får uppdatera dessa och sedan låta incheckningen fullföljas.
Då Team Foundation Server 2010 bara är i beta har det varit vissa problem med att hitta information om hur man gör detta men jag har funnit några sidor
4.4 Implementeringens delar 41
som beskriver proceduren. Jag har haft kontakt med en person på Microsoft som rekommenderar att man utvecklar mot Visual Studio 2008 och sedan konverterar det till en policy för Visual Studio 2010 när det släppts[15].
4.4.3
Utöka mallen för arbetsuppgifter i Team Foundation
Server
Schablonen för arbetsuppgifter i Medius Team Foundation Server-installationen behöver utökas med möjlighet att koppla en PBI till dokument eller delar av dokument. Man behöver två typer av kopplingar: uppdateringskopplingar till de dokument som ska uppdateras när PBI:n är klar och genereringskopplingar till de dokumentdelar som hör till PBI:n och ska läggas till i dokument som rör PBI:n. När man lägger till en PBI ska det ges möjlighet att ange dessa kopplingar. En anpassad kontroll listar alla delar så att användaren enkelt kan välja rätt delar.
Om man vill ändra i en schablon behöver man ladda hem den existerande mallen från TFS:en, ändra i den lokalt och sedan ladda upp den igen. Mallen är definierad i en XML[22]-fil vilket betyder att man kan ändra den i valfri text- hanterare. Det är brist på tydlig information på MSDN1men det finns några sidor
av andra personer, i vissa fall relaterade till Microsoft. Den
främsta om just XML-mallarna finns på http://teamfoundation.blogspot.com/ search/label/WIT, det är skrivet för Visual Studio 2008 men det kommer troligen inte att förändrats särskilt mycket till Visual Studio 2010.
Varje gruppprojekt i TFS:en använder en viss schablon för sina uppgifter och när projektet skapats kan inte mallen ändras. Detta gör att man när man ändrar i en mall behöver skapa ett nytt projekt för att den ska användas. Detta gör att alla grupprojekt som ska konverteras behöver skapas igen och alla PBI:er flyttas över. När man utvecklar en ny mall behöver man testa den och för det behöver man skapa ett nytt projekt, detta leder till många testprojekt men i gränssnittet för TFS:en verkar det inte gå att ta bort projekt. Däremot finns det ett verktyg, TFSDeleteProject.exe, som ingår i Visual Studio 2010 och fungerar riktigt bra.
4.4.4
Implementera en användargränssnittskomponent till
mallen
Genom redigering av ren XML kan man ändra mycket, men det finns ett fast antal standardkontroller man kan använda, så vill man göra något som standard- kontrollerna inte stöder behöver man utveckla en anpassad kontroll. Det ger en nästan total kontroll över vad som ska finnas men innebär även ett problem: Visual Studio förutsätter att binären med kontrollen i finns på datorn, finns den inte blir det problem och Visual Studio har inget inbyggt sätt att automatiskt distribuera binärfiler med kontroller som behövs, det måste man göra manuellt. Även om detta är informationen på MSDN begränsad, men det finns ett antal sidor som beskriver processen:
• http://blogs.msdn.com/vstsue/archive/2006/09/27/777554.aspx
• http://olausson.net/blog/PermaLink,guid,8d7a24a9-b1b4-463c -a037-769c33aabfb9.aspx
• http://ognjenbajic.com/blog/2007/09/custom-work-item- controls.html
Med informationen på dessa borde det inte vara alltför svårt att utveckla en komponent, distribueringen behöver man dock göra manuellt för varje dator som ska läsa, inte bara de som ska redigera, arbetsuppgifter i Visual Studio vilket troligen kommer att vara varje dator med Visual Studio installerat.
Komponenten kommer att behöva undersöka vilka dokumentdelar som finns i Sharepointen och vilka dokumenttyper dessa tillhör, samt visa detta i ett gräns- snitt så att användaren kan välja delar på ett enkelt och överskådligt sätt.
Öppnar man en uppgift som har länkar till dokument eller dokumentdelar som inte längre finns bör dessa markeras och alternativ erbjudas för att länka om eller ta bort länkarna. Komponenten bör även innehålla funktionalitet för att ta bort, flytta runt och utföra andra funktioner man kan tänka sig behöva för att hantera länkar.
4.4.5
Implementera en webbservice med gränssnitt till
dokumentlänkhantering
En webbservice blir processens arbetshäst. Det är tre huvuddelar av denna som delvis motsvarar processens två huvudfunktioner.
• Hantering av uppdateringar av dokumentation • Generering av dokumentation från delar • Övrig funktionalitet
Hantering av uppdateringar av dokumentation
Tanken är att bygga en webbservice som meddelas varje gång en utvecklare checkar in kod. Då letar den igenom en databas och ser vilka dokument eller dokumentdelar som hör till PBI:n och vilka personer som ska uppdatera dessa, och lägger dessa uppdateringar i en lista. Denna tabell kan man sedan komma åt antingen genom modulen i Visual Studio 2010(se avsnitt 4.4.1) eller genom en webbläsare.
Team Foundation Server erbjuder prenumeration på notifikationer om att diverse händelser har hänt - till exempel att en utvecklare har checkat in kod - enligt designmönstret skribent - prenumerant[10] och lagrar alla prenumeranter i en databas. Man kan lägga till eller ta bort en prenumerant på två sätt;
Team Foundation Object Model[20] Vill man hantera prenumerationer programmatiskt(i programkod) är det Team Foundation Object Model som gäller, ett ramverk som levereras av Microsoft tillsammans med Team Foundation Server.
4.4 Implementeringens delar 43
BiSubscribe BiSubscribe.exe är ett kommandoradsverktyg som följer med installationen av Team Foundation Server 2010 för att hantera prenumeranter. Jag har hittat två sidor med information om hur man använder BiSubscribe[1][32].
Genom en av dessa två metoder kan man lägga till eller ta bort en e-mailadress eller webbservice som prenumerant, dock går det inte att genom BiSubscribe lista vilka som prenumererar vilket känns lite märkligt men det finns en väg runt det; alla sparas i en särskild tabell man kan kolla i för att se om man redan är registrerad. Det finns tredjepartsverktyg för att underlätta hanterandet av prenumerationer genom BiSubscribe så att man inte behöver göra det manuellt[36]. Då det finns tredjepartsverktyg med tillräcklig funktionalitet anser jag att det inte är nödvändigt att fixa detta i programkod utan väljer istället BiSubscribe.
Ett alternativ som lades fram av en fokusgrupp var RSS[27]-flöden över händelser, men då jag inte har hittat någon sådan funktionalitet i TFS:en blir det svårt.
Generering av dokumentation
Generering av dokumentet är en 6-stegsprocess.
1. Användaren talar om vilket dokument denne vill ha och för vilken version det ska gälla. Detta kan ske genom modulen till Visual Studio 2010 eller genom hemsidan för webbservicen.
2. Webbservicen hämtar hem de PBI:er som hör till den versionen.
3. PBI:ernas dokumentlänkar följs för att se vilka dokumentdelar som är av rätt typ och gör en lista av dessa.
4. De delar som finns i listan slås ihop till ett dokument. 5. Dokumentet sparas på Sharepointen.
6. Användaren meddelas om att processen är klar, detta sker på olika sätt beroende på om denne gått via modulen eller hemsidan men skulle också kunna ske via mail.
Förutom det första steget är detta en automatiserad process som utförs av webbservicen när ett dokument ska genereras.
Övrig funktionalitet
En annan funktion som efterfrågats och som jag anser kan höra hemma i webb- servicen är att generera dokument från dokument, til exempel att publicera Word- dokument som pdf-dokument. Lägger man all dokumenthantering i webbservicen blir det enklare för användarna då de slipper använda flera olika sidor/verktyg för sin dokumenthantering. En annan vettig plats för detta hade varit en modul till Sharepointen. Om man för Word-dokument kan lägga till det som alternativ direkt i dokumenthanteringen stör det troligen inte gränssnittet alltför mycket.
4.4.6
Implementera ett användargränssnitt för
webbservicen
För att webbservicen ska kunna användas genom en webbläsare och inte bara via Visual Studio behöver man även ett användargränssnitt för denna. All funktion- alitet behöver nås i användargränssnittet, men då detta är en punkt jag tror bör utvecklas i iterationer ger jag mig inte i kast med att designa denna del av pro- cessen.
Kapitel 5
Utvärdering av nya
processen
5.1
Jämförelse med existerande process
I det här avsnittet gör jag en jämförelse mellan den existerande processen så som den ser ut att fungera, och hur jag vill att den nya processen ska fungera.
• Problem 1: Det finns inga dokument kopplade till PBI:n.
Lösning: Genom att göra det lätt att skapa kopplingar till dokument eller dokumentdelar tror jag att antalet länkar till dokument kommer att öka. Brist på länkar beror ofta på brist på tid och/eller motivation. Genom att sänka mängden arbete som krävs kommer troligen fler att skapa länkar. • Problem 2: Dokumentation uppdateras inte efter att en PBI är avslutad.
Lösning: Detta kan avhjälpas genom att systemet automatiskt talar om vilka delar av vilka dokument som ska uppdateras samt levererar dessa till användaren, då slipper personalen fundera och leta vilket tar tid samt ökar frustration och tristess.
• Problem 3: Konsulterna har ingen ordentlig informationskanal för projekt- relaterad information.
Lösning: Detta löser inte den nya processen men det skulle ganska enkelt kunna lösas genom att etablera rutiner för detta. Ett dokument med status högst upp och loggbok längre ner vore en enkel lösning som jag tror skulle fungera tillfredställande.
• Problem 4: Uppdateringar av dokument prioriteras ned och glöms i vissa fall bort.
Lösning: Alla uppdateringar skrivs in i tabeller som lagras, dessa tabeller gås igenom och påminnelser skickas ut till de användare som är ansvariga om uppdateringarna inte är utförda inom ett visst antal dagar. Genom dessa
påminnelser tror jag att nästan alla uppdateringar kommer att utföras inom en relativt kort tidsperiod från PBI:ns slutförande.
Den nya processen hjälper Medius att jobba mot lösningar till fyra av sex problem med ett förslag till separat lösning till ett femte.