Arkitekturprinciper för informationsöverlägsenhet i framtidens ...
Arkitekturprinciper för informationsöverlägsenhet i framtidens ...
Arkitekturprinciper för informationsöverlägsenhet i framtidens ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
vis en ljus framtid <strong>för</strong> UML men medger också att metodens omfattning är så stor att<br />
den överväldigar en del användare.<br />
Vi vill trots dessa nackdelar ändå hävda att Försvarsmakten bör basera sin framtida<br />
systemutveckling på denna standard, som av många tecken att döma är på väg att<br />
konkurrera ut de flesta äldre medtävlare. Nedan presenterar vi där<strong>för</strong>, med generöst<br />
medgivande av Metria GIS-Centrum, ett utdrag ur beskrivningen av Metrias<br />
utvecklingsmodell Symmetria som är grundad på UML och Rational Rose-metoden,<br />
det sistnämnda en processbeskrivning och ett utvecklingsverktyg <strong>för</strong> UMLmodellering.<br />
<br />
En vanlig motivering till att in<strong>för</strong>a modellering som en projektaktivitet i systemutveckling<br />
är att ”ingen skulle komma på tanken att bygga ett hus utan ritningar”.<br />
Detta gäller särskilt <strong>för</strong> det fall då huset är stort och bygget inbegriper flera <strong>för</strong>etag<br />
och konstruktörer. Om arbetet ut<strong>för</strong>s av en person som gör allt arbete åt sin kund, är<br />
behovet av en strukturerad utvecklingsmetod inte lika stort som om många utvecklare<br />
gemensamt skall få ett stort projekt i hamn.<br />
Att arbeta på ett gemensamt sätt i hela organisationen underlättar utbyte av både<br />
information (t ex programkod och goda exempel från tidigare projekt) som utvecklarresurser.<br />
En ytterligare vinst är den kvalitetsmärkning som användning av en välkänd<br />
utvecklingsmetod innebär.<br />
Nära kopplat till utvecklingsmetoden är valet av arbetssätt. Modellering, dokumentation<br />
och testning är viktiga arbetsmoment men det är också viktigt att återkoppla till<br />
tidigare ut<strong>för</strong>t arbete. Att remodellera, bygga om, modifiera kodstruktur etc bör ses<br />
som naturliga arbetsmoment och som något som bör ges resurser redan vid projektstart.<br />
Ett system kan inte anses färdigt <strong>för</strong>rän dokumentationen <strong>för</strong>eligger. Man måste också<br />
se till att dokumentationen kan läsas av alla som behöver den. Detta underlättas<br />
naturligtvis av mallar och gemensamma verktyg men också av att man tar del av hur<br />
andra projekt har arbetat och använder detta som utgångspunkt.<br />
Det huvudsakliga problemet vid in<strong>för</strong>ande av en arbetsmetod är inte metodutvecklingen,<br />
dokumentationen eller utbildningsarbetet. Flaskhalsen sitter istället vid att få<br />
personalen att börja använda den nya metoden praktiskt istället <strong>för</strong> att hålla fast vid<br />
tidigare invanda arbetssätt.<br />
Det bästa sättet att in<strong>för</strong>a modellering är att helt enkelt lägga in detta som en aktivitet i<br />
projektplaner och tilldela den rikligt med tid. Inled med en längre modelleringsfas<br />
som avslutas <strong>för</strong>st när hela uppgiften är genomanalyserad. Försök sedan konstruera en<br />
<strong>för</strong>sta version av systemet så att det går att verifiera vilka delar av modelleringen som<br />
var korrekta och vilka som behöver omarbetas. Återgå sedan till modellering och dra<br />
nytta av de vunna erfarenheterna, och iterera på detta sätt ett par gånger under<br />
projektet.<br />
- 45 -