Kravspecifikationer Aktiveringsdokument Känsliga: Användarhandledningar Konfigurationshandledningar Buggöversikter Manualer Använderhandledningar Konfigurationshandledningar Tekniska riktlinjer Produktdefinitioner Måttligt känsliga: Produktblad Presentationer Frikopplade: Offerter Egna prislistor Partners prislistor Programmeringsriktlinjer Utveckingsriktlinjer
3.5
Nuvarande verktyg
3.5.1
Team Foundation Server
Team Foundation Server[35] (TFS) är Microsofts lösning för utvecklingsgrupper, det är efterföljaren till Visual Sourcesafe, Microsofts tidigare verktyg för ungefär samma ändamål. Det är gjort för att täcka upp alla aspekter av utvecklingen för ett mjukvaruföretag. TFS innehåller bland annat1
• Versionshantering • Bugghantering • Funktionalitetshantering • Webbåtkomst • Automatiserade byggprocesser • Automatiserade tester • Rapportgenerering
1För mer detaljerad beskrivning se http://msdn.microsoft.com/en-us/library/ms242904.
TFS är fokuserat runt konceptet arbetsuppgift. En arbetsuppgift kan vara en bugg som ska fixas, en ny funktion som ska implementeras eller något annat som ska utföras; en arbetsuppgift är en PBI eller en bugg.
I Team System, Visual Studio Team Explorer och Team Foundation
Server, finns det två typer av projekt. Arbetsprojekt och gruppprojekt; arbets- projekt innehåller alla kodfiler och liknande som produceras under arbetets gång medan gruppprojekten innehåller information om vad som ska göras, PBI:er och liknande.
Dokumentation för en PBI
Varje PBI ska ha ha länkar till ett antal dokument: designspecifikation, test- specifikation, lösningsförslag och kravspecifikation. För mer detaljerad
information om dokumenten, se avsnitt 3.2.1. Tidigare var det dock långt från alla PBI:er som hade alla dokument kopplade till sig, men det har skett en uppstramn- ing, nu är ett lösningsförslag obligatoriskt innan PBI:n antas för utvärdering över huvud taget, och resterande dokument ska också skrivas.
Det finns även stöd för att ha länkar till andra dokument, arbetsuppgifter, noteringar eller annat som kan vara relevant. Varje PBI delas upp i ett antal SBI:er och i TFS finns det kopplingar åt båda håll mellan varje SBI och dess PBI-förälder.
Dokumentation för en bugg
Buggar har som regel ingen dokumentation kopplad till sig men GUI-relaterade buggar kan ha skärmdumpar som visar hur det ser ut när användaren råkar ut för buggen. De har även en koppling till en eller flera SBI:er som motsvarar rättandet av buggen.
3.5.2
Visual Studio 2008
Idag använder Medius Visual Studio 2008[37] som är en integrerad utvecklingsmiljö, det vill säga en helhetslösning för utvecklare. Det ingår texteditor med funktion- alitet för att underlätta skrivande av programkod i specifika programmeringsspråk. Visual Studio 2008 Team System är en version av Visual Studio som innehåller funktionalitet för att underlätta arbetet för flera utvecklare att arbeta med samma projekt, till exempel har det inbyggt stöd för att koppla projekt mot versions-hantering eller hanterare. Det finns stöd för att koppla ihop projekt med en TFS, då får man integrerat stöd för att hantera kopplingar mellan programkod och SBI och därigenom även till PBI:er.
Visual Studio 2008 är inriktat mot utveckling på .NET-plattformen men stöder även utveckling mot maskinkod om man skriver i C++.
3.5.3
.NET-plattformen
3.5 Nuvarande verktyg 27
Lågnivåspråk Språk som ligger väldigt nära maskinkod, här finns i stort sett bara olika typer av Assembler, även om vissa skulle lägga ren C här. Program- meraren har stor kontroll över vad som händer men behöver göra mycket själv. Det går att optimera kod väldigt hårt om man vet vad man gör, men det krävs ofta lång erfarenhet innan man kan börja med mer avancerade saker.
Mellannivåspråk Språk som ligger lite högre upp: C++, Delphi och liknande språk som kompileras till maskinkod. Lite mindre kontroll över vad som händer än i lågnivåspråk men det går fortare att utveckla hela program. Språk på den här nivån har ofta möjlighet att lägga in avsnitt med låg- nivåspråk. Inom riktigt prestandakrävande områden som spel där man vill pressa hårdvaran så mycket man kan är mellannivåspråk i överväldigande majoritet.
Högnivåspråk Språk som ligger väldigt högt upp i abstraktionsnivå. Språket gör mycket automatiskt vilket gör att utveckling går fort men som utvecklare har man i vanliga fall inte så mycket kontroll över vad som händer. Högnivåspråk är ofta enklare att komma igång med för att det inte krävs så mycket kod innan man ser ganska stora resultat.
Många högnivåspråk körs i virtuella maskiner som tolkar bytekoden och utför instruktionerna vilket ger plattformsoberoende men också innebär långsam- mare exekvering. På senare år har det dock kommit två varianter för att komma runt detta tapp i hastighet.
• JIT(Just In Time)-kompilering som innebär att bytekoden kompileras till maskinkod när programmet körs. Det tar lite längre tid när koden körs första gången men programmet som levereras som bytekod är plattformsoberoende.
• Kompilering till maskinkod. Vissa kompilatorer för vissa språk kan kompilera direkt till maskinkod istället för bytekod. Man tappar ingen hastighet men programmet blir inte längre plattformsoberoende. .NET-plattformen är ett samlingsnamn för en rad olika tekniker som till- sammans gör det möjligt att skriva i flera olika språk, kompilera ner till samma format och sedan köra på olika plattformar eller operativsystem.
Högst upp, se figur 3.2, finns naturligt nog de olika språk programmeraren kan använda.
Under dem finns Common Language Specification[7] (CLS), en specifikation som Microsoft och skrivit som anger vilka anrop som måste finnas på varje objekt för att det ska kunna användas i valfritt .NET-språk. CLS innehåller en samling regler som är ett subset av Common Type System.
Common Type System[8] (CTS) beskriver hur typer deklareras, definieras och hanteras i miljön. Där definieras även ett antal vanliga typer som har
representationer i de olika språken. Till exempel finns System.Int32 i CTS vilket i C#representeras av datatypen “int” medan den i VB.Net representeras av
Figur 3.2. Delarna av .NET ramverket[21], högre upp är närmare användaren
.NET Framework Class library[11] (FCL) är en samling klasser som erbjuder färdig funktionalitet. Det hjälper utvecklaren att snabbare få sin mjukvara färdig genom att använda dessa klasser istället för att skriva sina egna från grunden. De ger utvecklaren tillgång till bland annat:
• GUI • Nätverk • Filhantering
Under FCL ligger interna bibliotek för GUI, konsol, databaskopplingar, webb- formulär och annat.
Allt detta körs av Common Language Runtime[6] (CLR) som innehåller kom- pilator, skräphantering, säkerhet och annat. Kompilatorn är till för att kompilera .NET-applikationer från bytekod till maskinkod när de startas. Då kan de köras av processorn och behöver inte översättas av en virtuell maskin och tappa prestanda. Hela den här kedjan är Microsofts version av Common Language Infrastructure[5] (CLI). Den har blivit en officiell standard under ECMA och går där under namnet “ECMA-335”. CLI definierar varje steg från programspråk till exekvering och om ett språk är CLI-kompatibelt innebär det att du kan ta bytekoden, i Microsofts fall kallas den Microsoft Intermediary Language eller MSIL, och köra i valfri CLI- kompatibel miljö.