Mitt förra inlägg här (oktober) handlade om att förenkla
”användningsfallskartan”, underförstått en enhetlig systemarkitektur. Men varför
bloggar numera även sådana roller som som managementforskare
kring Harvard om Användningsfall? Intresset i ett mycket bredare spektrum
av branscher än mjukvara tilltar när nu lättviktiga processer på slimmade
FoU-avdelningar (Agile/Lean) betonar handgriplig kundnytta.
Användningsfall (Use Cases) fungerar bäst på produkter som
ska samspela med sin omgivning, alltså produkter med mycket skiftande andel
mjukvara. I stället för ”mjukvara” eller ”objektorientering” bör man hålla ett annat
nyckelord i minnet: interaktivitet.
Ju mer interaktiv produkten förväntas vara, ju mer kommer
Användningsfall att krympa ”långbänken” i början där olika roller lätt pratar i
cirklar kring en ny produktidé. De kommer ursprungligen från telecom, men interaktiviteten
(deras paradnummer) passar innovatörer av allt mellan din e-bank och
förarmiljön i din bil – som kanske redan drömmer om en bilmodell byggd kring en
plattform som Android eller Apple (iCar, kanske ? :-)
Utvecklingsspecialister är traditionellt skolade att
beskriva nya produkter i termer av komponenter och produktstrukturer.
Användningsfall lägger till även kundens perspektiv, särskilt samspelet produkt
– omgivning, hur produkten är tänkt att bete sig utåt. Att kombinera dessa två
perspektiv spar tid och missförstånd i tidiga skeden, underlättar tester, ger marknadssidan
underlag för träffsäkrare värdering av en produktidé, och förankrar därigenom idén
även utanför FoU-teamet.
Kan Användningsfall ersätta affärsprocessmodeller (BPM)?
Nej. I och för sig triggas även de igång av en verksamhetshändelse, och de
beskriver förlopp, men annorlunda förlopp. För FoU-teamets del handlar
processen om ”vem gör vad när och överlämnar till vem” medan Användningsfall är
framförallt en kravfångststeknik och en grund till tester.
Passar Användningsfall även på produkter/system som inte är
särskilt interaktiva? Det beror på. Jag tar med en länk om Användningsfall
kontra annat i mitt nästa inlägg.
Informator betonar valuta för modelleringspengarna:
arkitektur, få men informationsrika bilder, och agil modellering där Användningsfall
är en teknik (av flera) för kravfångst och kommunikation med projektets
intressenter.
konsult, Kiseldalen.com
UML 2 Professional, OCUP Advanced Level
(certifikatnivå 3 av 3)
Huvudförfattare
UML
Xtra Light – How to Specify Your SW Requirements
Samarbetar med Informator sedan våren 1996 inom modellering,
UML, analys och design.
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.