In the end of the 80´s the area of system development moved into a new era. As a consequence many new methods and development models emerged which in many cases resulted in problems when choosing system development models and methods. As a result of these problems the today standardized modeling language UML (Unified Modeling Language) was created. UML is tailored to support many different types of projects. This is possible because of UML’s capacity to be adjusted and adapted to a specific company environment. The purpose of this bachelor thesis is to investigate how and why companies use UML and what experiences and opinions those who use UML have of using UML in practice. To fulfill our purpose we have chosen to carry out a qualitative study with semistandardized interviews. The interviews were accomplished on four companies in Jönköping. The result of the research shows that the primary reason for companies to carry out modeling is because it results in good documentation which makes development, administration and operation easier. Furthermore, the study has shown that the reason that companies have chosen UML is because it is a standard which is suited for various different projects and also for the development model used in the company. The standardization is also, according to all companies, the primary strength with UML. Weaknesses in UML are considered to be the lack of process diagrams and standardized syntax in modeling tools. There was found to be an increase in the number of diagrams used the longer the companies have used UML. The diagrams applied by all companies are: use case diagram, class diagram and sequence diagram. Moreover, the use of diagrams for a specific project is dependent on the project type and size. However, none of the companies utilize the flexibility to adjust the syntax. All companies combine UML with RUP or business customized development models with characteristics from RUP. There is, however, a difference in how companies use the diagrams in combination with the development models. This probably depends on the companies’ iterative way of working where the diagrams are involved in the whole system development process. / I slutet av 80-talet gick systemutvecklingen in i ett nytt skede. Detta fick som följd att många nya metoder och utvecklingsmodeller för systemutveckling skapades vilket i flera fall ledde till problem vid val av systemutvecklingsmetod och modell. Till följd av detta skapades det idag standardiserade modelleringsspråket UML (Unified Modeling Language). UML är anpassat för att stödja många olika typer av projekt eftersom det tillåter företagsspecifika anpassningar och förändringar. Syftet med studien är att undersöka hur och varför företag använder sig av UML samt vilka erfarenheter och uppfattningar de som arbetar med UML har av att tillämpa det i praktiken. För att uppfylla syftet har vi valt att genomföra en kvalitativ studie med semistandardiserade intervjuer. Intervjuerna utfördes på fyra företag i Jönköpingsregionen. Resultatet av studien visar att den främsta anledningen till att företag modellerar är att det ger en bra dokumentation vilket underlättar utveckling, förvaltning och drift. Vidare har studien visat att UML har valts på grund av att det är en standard som lämpar sig för många olika projekt samt för att UML passar den utvecklingsmodell som tillämpas på företaget. Standardiseringen är även enligt samtliga företag den främsta styrkan med UML. Svagheter i UML anses vara avsaknaden av processdiagram samt bristen på standardiserad syntax i verktygen. Ju längre UML har använts på företagen desto fler diagram används. De diagram som tillämpas av samtliga företag är användningsfallsdiagram, klassdiagram och sekvensdiagram. I övrigt beror användningen av diagram för ett specifikt projekt på projektets typ och storlek. Däremot utnyttjar inget av företagen UML:s flexibilitet att anpassa syntaxen. Samtliga företag kombinerar i någon utsträckning UML med RUP eller egenutvecklade utvecklingsmodeller med liknande egenskaper som RUP. Det skiljer sig dock i hur företagen använder diagrammen i samband med utvecklingsmodellerna. Detta beror troligtvis på det iterativa sätt företagen arbetar efter där diagrammen följer med i hela systemutvecklingsprocessen.

Abstract This paper discusses how system development methods today support communication between system developers and their customers and end users. Today there are many system development methodologies with different aims and emphases. It is difficult, however, to find among these methods those who promote good and effective communication with customers because so many of these are very technically rooted and not as much directed towards the soft aspects of systems development - i.e. Human aspects. Our own experiences tells that a simple interview can be initialized without us having an idea what to ask the customer about or how to structure it up - nonetheless it’s done, but the outcome is just chance. This is however not an effective way to work. Yes! We do the interview, but the implementation is another issue!   By interviewing established system developers and looking into different system development methods, the aim with this work was to find out how well these methods aid the communication between developers and their customers or end users. The result of this paper shows that there is a need to ingrain communication in system development methods to support the dialog between developers and customers. There were also suggestions considering the development of communication tools which may be a solution to this problem.   With this paper we mean to put the spotlight on this particular area to hopefully push the issue further.       Key words: System development methods, communication, system developers, customers, end users. / Sammanfattning   Denna uppsats diskuterar hur systemutvecklingsmetoder idag stöder kommunikation mellan systemutvecklare och deras kunder och slutanvändare. Idag finns det mångfaldiga systemutvecklingsmetoder med olika syften och inriktningar. Det är dock svårt att hitta bland dessa, dem som söker främja en god och effektiv kommunikation med kund. Detta eftersom många av dessa är väldigt tekniskt rotade och riktar sig inte i lika stor grad mot de mjuka delarna av systemutveckling – dvs. de mänskliga aspekterna. Vår egen erfarenhet säger att en enkel intervju med en kund kan påbörjas utan att vi har en aning om vilka frågor vi ska ställa eller hur den ska struktureras. Ändå genomförs den. Fast resultatet är bara chansning! Detta är dock inte ett effektivt sätt att arbeta på. Att arrangera en intervju är inte svårt, men att genomföra den är en annan fråga!Genom att intervjua etablerade systemutvecklare och undersöka olika systemutvecklingsmetoder, är syftet med detta arbete att ta reda på hur väl dessa metoder stödjer kommunikationen mellan utvecklare och deras kunder eller slutanvändare. Resultatet av denna uppsats visar att det finns ett behov av att inkorporera kommunikation i systemutvecklingsmetoder för att stödja dialogen mellan utvecklare och kunder. Det fanns också förslag kring utvecklingen av något slags kommunikationsverktyg för att förebygga denna sorts problem. Avsikten med denna uppsats är att sätta fokus på detta område för att förhoppningsvis driva frågan vidare.Nyckelord: Systemutveckling metoder, kommunikation, systemutvecklare, kunder, slutanvändare.

Den miljö som dagens informationssystem (IS) befinner sig i kommer att förändras och bli mer komplex (Lindencrona, 2000). Lindencrona (2000) menar att de nya IS som skapas kommer att utvecklas genom att de befintliga systemen integreras med nya resurser. Företag kan besparas stora kostnader vid en utvecklingsprocess genom att nya resurser integreras med det befintliga systemet (Lyttinen & Zhang, 2000). Den systematiserade kunskap som finns på marknaden idag behandlar främst återanvändning och integrering av källkod. Aggestam (2001) har i sitt examensarbete identifierat fyra olika aktiviteter som sker i VAD-fasen vid vidareutveckling av befintliga IS. En av dessa aktiviteter är att fatta beslut. Detta arbete har genom en enkätundersökning identifierat de beslut som företag fattar i VAD-fasen då de vidareutvecklar sina befintliga IS. Resultatet från studien tillför kunskap till ytterligare forskning som bör göras för att få fram metoder för utveckling av de IS som kommer att skapas utifrån vidareutveckling och integrering av befintliga IS.

När verksamheter ska införa nya informationssystem uppstår det ofta problem som kan ha med sociala och organisatoriska effekter att göra. Problem kan även uppstå vid utvecklandet av informationssystem och då ofta vid slutet av systemutvecklingen eller när informationssystemet har tagits i drift. Problem med systemutveckling och införande av informationssystem kostar mycket tid och pengar för verksamheter. Detta arbete har som syfte att se om verksamheter kan dra nytta av liknande verksamheters erfarenheter av problem vid införande av ett nytt informationssystem. För att undersöka problemområdet har en litteraturstudie genomförts där det har identifierats ett antal problem med införande av ett nytt informationssystem inom hemsjukvården. Vidare gjordes en surveyundersökning där intervjuer användes för att intervjua distriktsveterinärer då det ansågs som en liknande verksamhet där båda åker ut på patientbesök. Sedan gjordes en jämförelse mellan de båda verksamheterna, detta för att se om det fanns några likheter, skillnader och eventuella risker med en sådan jämförelse. Det resultat som framkom visade att det fanns vissa likheter och även skillnader mellan de båda verksamheterna, några risker med en sådan jämförelse kunde dock inte påvisas.

Systemutvecklingen har under de senaste åren medfört mer komplexa och tidskrävande arbetsuppgifter vilket har genererat olika problem. Resultatet av detta har gett upphov till att organisationer uppfunnit och infört systemutvecklingsmetoder. Enligt litteraturen används dock metoder sällan som de föreskrivs då olika anpassningar ofta genomförs. Det finns idag en uppsjö systemutvecklingsmetoder på marknaden, däribland RUP, som valts att belysas i detta arbete. Studien som genomförts undersöker hur systemutvecklare anpassar RUP i olika projekt samt vilka motiv det finns till de anpassningar som görs. Undersökningen omfattar sju respondenter från olika företag vilka har goda erfarenheter inom området. Resultatet av studien visar att RUP aldrig används i sin helhet och att kompletterande metoder ofta förekommer. Några större anpassningar i arbetsflödet kravhanteringen inträffar sällan, dock förekommer vissa mindre justeringar. Motiven till anpassningarna var många. De främsta var att bemanningen, inarbetade processer och metoder samt att olika standarder styrde mycket

Det talas ofta om hur viktigt det är att involvera användarna i en systemutvecklingsprocess. Användarnas medverkan ska bidra till bättre system både i teknisk synpunkt och i användarsynpunkt. Men empiriska resultat har dock visat på olika resultat om huruvida användarmedverkan bidrar till systemframgång eller inte. Detta arbete syftar till att undersöka ett antal empiriska studier och ta reda på varför en del studier visar på att användarmedverkan ökar systemframgångarna medan andra inte visar på detta. Arbetet har genomförts genom en litteraturstudie där olika empiriska undersökningar har jämförts.

Systemutveckling omfattar alltmer komplexa och tidskrävande uppgifter, vilket lett till större fokus på användningen av metoder och processer. Systemutvecklingsmetoder är ofta generellt beskrivna för att passa flera olika typer av verksamheter och projekt. Generaliseringen gör att metoden passar alla och ingen, vilket kan föranleda att den måste anpassas för att ge optimal hjälp och vägledning till en enskild verksamhet. Detta arbete belyser hur systemutvecklingsprocessen RUP anpassas, införs och används inom ett företag, samt vilka problem som är förenat med detta. Studien omfattas av en fallstudie som gjorts vid ett större mjukvaruutvecklingsföretag. Resultatet visar att processen inte används i sin helhet, utan att delar valts ut och integrerats med befintlig metodik. Anpassnings- och införande arbetet har organiserats som projekt och resultatet har dokumenterats i development case. Innehållet och omfattningen av anpassningen har påverkats av en mängd faktorer däribland verksamhetens metodtradition och metodens uppbyggnad/stuktur.

Att involvera användare vid systemutveckling kan bidra till att informationssystem som utvecklas i större grad accepteras av användarna samt blir lättare att använda. Det finns olika tekniker för att involvera användare i systemutvecklingsarbetet. Att dessa tekniker existerar medför dock inte nödvändigtvis att de används. Syftet med arbetet är att identifiera huruvida tekniker som framkommit från forskning används och om de inte används hur användarna då involveras rent praktiskt i systemutvecklingsarbetet. Om tekniker inte används undersöks vidare vilka orsakerna till det kan vara samt om systemutvecklare eventuellt utvecklar egna tekniker. För att undersöka problemområdet har ett antal intervjuer genomförts med systemutvecklare. Resultatet visar att tekniker för att involvera användare i systemutvecklingsarbetet inte används i så stor utsträckning. Den främsta orsaken till att tekniker inte används är att det inte anses finnas något direkt behov av det. Egna tekniker och tillvägagångssätt utvecklas inte i någon större grad.

Litteraturen förespråkar hur viktigt det är att involvera användarna i systemutvecklingsprocessen, speciellt när kraven skall samlas in för att slutligen resultera i en kravspecifikation. Det krävs dock att användare och systemutvecklare samarbetar på ett bra sätt och förstår varandra. Undersökningen som genomförts i denna rapport syftar till att skapa en förståelse för hur en kravspecifikation kan tas fram i analysfasen, samt att undersöka hur kravinsamlingen har genomförts mellan TietoEnator och Timrå kommuns förvaltningar miljö och bygg och kultur och fritid. Utifrån detta är målet att klargöra vad i analysfasen som kan vara orsaken till att kraven som ställts utav miljö och bygg- och kultur och fritidsförvaltningen inte riktigt är uppfyllda. Undersökningen började med en litteraturstudie för att få en förståelse för hur en kravspecifikation kan tas fram i analysfasen. Resultatet visade bl.a. att när kraven skall samlas in är kommunikation och kontakt med användarna mycket viktigt. Undersökningen fortsatte sedan med intervjuer av anställda på förvaltningarna och TietoEnator för att få en förståelse för hur deras kravinsamling hade fungerat. Resultatet visade bl.a. att någon kravspecifikation inte arbetats fram när hemsidan skulle utvecklas. Resultatet visade dessutom att samarbetet mellan TietoEnator och förvaltningarna inte har fungerat tillfredsställande, och att förvaltningarna och TietoEnator är oeniga om hur stor del av kraven som är uppfyllda.

Arbetet med att utveckla informationssystem organiseras ofta som ett projekt, och därmed kan projektstyrningen ses som ett hjälpmedel i systemutvecklingen. Innan projektgruppen startar är det även viktigt att rätt användarrepresentanter väljs till den projektgrupp som arbetet ska bedrivas i. De användare som ska delta i projektgruppen måste vanligtvis friställas från sina ordinarie arbetsuppgifter just för att kunna delta i projektgruppen. Om en användare med de egenskaper som efterfrågas i projektgruppen inte friställs, kanske risken finns att projektgruppen saknar nödvändig kompetens för att projektet ska kunna uppfylla det förväntade resultatet. Det ansågs därför intressant att undersöka om det förekom några organisatoriska motståndsfaktorer vid val av särskilda användare, samt om detta kunde generera några konsekvenser för fortsatt arbete och resultat. Den undersökning som genomfördes visade att det förekom motståndsfaktorer vid val av användare till projektgrupper. Undersökningen visade bland annat att oförståelse kan leda till brist på tillgänglighet, vilket i sin tur kan leda till tidsförskjutningar i projektet. Ovilja eller rädsla mot ett nytt system kan leda till brist på kompetens i projektgruppen. Slutligen visade undersökningen att dålig kommunikation inom företaget från ledningen till övriga anställda kan leda till brist på kompetens i projektgruppen.