Mitt blogginlägg i mars, om att
ta för sig lagom från modell-smörgåsbordet, berörde även kravkommunikation.
I en vinglig färd genom åren har ungefär lika många kört i båda diken: det ena med
underförstådda krav (ibland med dyra missförstånd, ibland med dyra glädjekalkyler),
det andra med en byråkratiserad fabrik och överdådig notation i många ritningar
som få läser (ibland osammanhängande, ibland ur fas med programkod). En rimlig väg
är att noga pröva ut ett fåtal diagram i praktisk användning för konkreta syften,
med feedback löpande från olika roller och vid regelbundna ”iteration
retrospectives”. Tanken bakom standarderna UML och BPMN var ju aldrig att alla
projekt ska svälja all notation.
När man kommunicerar krav i agila projekt behöver man hela
tiden ha syftet klart för sig och dosera/förpacka
efter vilka roller och bakgrunder vi vänder oss till, i vilka situationer de har
nytta av kravinformationen (i ledning, design, programmering, test,
vidareutveckling/underhåll, personalutbildning, osv), och vilka eventuella detaljer
de har störst nytta av för att förebygga missförstånd. Diagrammen på kravstadiet
brukar använda mer verksamhetsanknuten/”framtung” notation än de i designen: t
ex processflöden med processhierarkier alternativt verksamhetsanvändningsfall,
eller domänindelning. Vissa företag har ibland använt två skilda ritverktyg,
medan standarden Model Driven Architecture använder separata modellnivåer
(datoriseringsoberoende, plattformsoberoende, och plattformsspecifik nivå – en
och annan bloggbesökare lär nog känna igen strukturen från kursen Agile
modellering med UML2).
Lika klokt är att även undvika överlappningar inom
resp modell, eftersom de leder till dubbelarbete vid ändringar. Arkitekten
strävar efter symmetri med ”restricted vocabulary”, dvs systemen ska
utföra en typ av uppgifter på ett enhetligt sätt överallt. Något liknande
gäller kraven: krav av samma typ bör man uttrycka på ett koncist snarlikt sätt
överallt, med samma medel så långt möjligt.
Behov av precision medför mer modellering i
kravkommunikation, men också risk för överlappning och dubbelarbete. Lagom är bäst
- för eller senare inträffar en brytpunkt där marginalinsatsen överstiger
marginalnyttan och fokus på dokument tränger ut det som dokumenteras.
I en granskande eller ledande roll bör man inte heller
mekaniskt räkna antalet diagram och dokument (med tiden kan f.ö. antal bli
omvänt proportionerlig till aktualitet). Kvalitet slår kvantitet i längden,
medan dubbelarbete och dubbelunderhåll hämmar användningen av modeller i
längden.
Till citatet ”you can still build significantly complex
systems using only three diagrams” i mitt blogginlägg i mars kan man alltså lägga
till: ”eftersom det minskar överlappning, underlättar uppdateringar, styr rätt
information i rätt diagramtyp – och eftersom fler kommer att läsa dem”. Hellre
än att frossa i notation har Informators modelleringskurser eftersträvat valuta
för modelleringspengarna: ett smalt urval av diagram som hänger ihop och
kompletterar varandra (även i övningar).
Konsult, Kiseldalen.com
UML 2
Professional, OCUP Advanced Level (certifikatnivå 3 av
3)
Huvudförfattare
UML Xtra Light – How to Specify Your SW Requirements
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.