Presentation Stockholm 2009-01-27

Diskussionsunderlag för att redan under datainsamling skapa förutsättningar att utveckla säljstödsverktyg/verksamhetsutvecklingsverktyg.

Ett stort problem som blev påtagligt redan i början av datainsamlingen är att alla aktörer har olika bilder av och förstår det som händer på olika sätt.

→

intressant att pröva om UML-diagrammen kan fungera som ett datainsamlingsverktyg, som stödjer analys och som skapar förutsättningar för att från resultat lättare kunna utveckla företagsstöd (sälj- och/eller verksamhetsutvecklings).

• Pröva att konstruera olika diagram.

• Pröva att använda olika diagram i diskussion med intressenter i projektet.

• Gå vidare med diagram som fungerar i kommunikation med intressenter i projektet.

diagram 1

diagram 2

diagram 3

• Redan från början hade jag kunnat skilja på olika entreprenadformer, eftersom detta påverkar byggprocessen och samverkan/kommunikation mellan olika parter.

• Jag byggde upp diagrammen fel från början då jag inte fullt ut förstod alla finesser i yED.

• Jag valde efter litteraturstudie att pröva att göra klassdiagram, use case diagram och aktivitetsdiagram. Kanske finns det fler diagram som skulle kunna fungera (bättre) men vars potential jag inte till fullo förstått. Att läsa är en sak, att pröva en annan.

• Enkla use case diagram förefaller vara ett bra sätt att diskutera kring roller.

• Att koppla use case diagram och aktivitetsdiagram för att beskriva roller, aktiviteter och hur olika parter samverkar förefaller vara ett hjälpmedel för att förstå komplexiteten/identifiera problem och constraints.

• Aktivitetsdiagrammen går att utveckla mycket, frågan är bara när de blir för komplexa att läsa för “oinitierade intressenter”.

• Påbörjat koncept går att utveckla.

• Återkoppling, att vi förstår samma sak, och att min analys ska bli genomskinlig gnm intressenterna i projektet förefaller kunna underlättas genom användingen av UML-diagrammen.

• Ett problem är att göra diagrammen tillräckligt enkla, utan att de därmed eg inte tillföra någonting.

• Jag trodde initialt att jag skulle kunna identifiera constraints och bygga diagram därifrån, istället landade jag i att utveckla diagram för att kunna identifiera constraints. I ett nästa skede skulle den ursprungliga tanken kunna utvecklas, igen med hjälp av UML-diagram. Därifrån skulle även (hypotetiskt sett) ritningar kunna kopplas till, för utveckling av något sorts säljstöd.

• Potentialen att utveckla ett hjälpmedel för verksamhetsutveckling förefaller dock i dagsläget vara större än potentialen att utveckla ett säljstöd. Detta eftersom företagen befinner sig i en fas av förändring, och ett säljstöd förmodligen skulle kunna verka utvecklingshämmande snarare än utvecklingsstödjande.

Och en sista reflektion…

Att jobba med UML har för mig inneburit att jag “tvingats” tänka på ett annat sätt, och uttrycka mig på ett annat språk. Det har varit mycket svårt…men mycket lärorikt. Jag tänkte initialt att “jag skulle kunna köra igång och utveckla diagram”, istället har jag fått använda den mesta av tiden till att försöka se hur jag kan tänka kring och förstå problemen i projektet. Eftersom mitt forskningsprojekt handlar mycket om kommunikation känns det särskilt viktigt att kunna redogöra för uppläggning av datainsamling, analys och resultatens återkoppling och användbarhet för intressenter i projektet. Här har UML varit ett bra verktyg, redan innan några diagram ens fanns, eftersom det hjälpt mig att reflektera kring varför ett projekt som mitt överhuvudtaget ska ta den utgångspunkt som det nu ska.

Avslutningsvis kan jag säga att jag gillade “Systems Engineering with SysML/UML - Modeling, Analysis, Design” av Tim Weilkiens. Jag tror den mycket väl kan vara rekommenderad kurslitteratur i en kurs som denna.