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.
Inga kommentarer:
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.