A
slightly shortened version in English:
Stakeholders must acquire “language
skills” - a skilled specification of
requirements is a foremost requirement…
In knowledge-intensive sectors, the customer–vendor
dialog, and clear requirements, is the be-all and end-all; simply, there are two parties to make a dialog. That’s why
both stakeholders and IT-staff need a basic knowledge of each other’s fields.
The important thing is the ability to jointly transform business-process needs
into legible, concrete IT-aid requirements – relevant enough in business as
well as in software development. "Word-processor Poetry" of soaring
visions in natural language —and with just as natural ambiguity— creates confusion in specification (this need for
accuracy is similar to other contexts such as law).
Because of this, there has been a world standard for
software documentation for the past 6½ years (Unified Modeling Language, a new
extended version 2.0 to be launched early this summer). Although for the
stakeholder, something like a tenth of the IT-staff’s level of UML knowledge
can do, a serious enterprise can never afford a complete absence of this basic
”language skill”, nonetheless; without a common language, true communication
hardly ever takes place. Modern requirements-management tools, including
Also, instant follow-up and feedback is already key in
software processes (such as CMM, DSDM,
RUP, Perspective, Agile). A
commonplace bottleneck however, is a lack of background from up-to-date systems
development and architecture; this results in the process-handbook being
applied just slavishly — as long as a
process is applied at all. In
contrast to this, a sound project is based neither on bureaucratic ceremony
(the ditch on one side) nor on chaos (the ditch on the other side). Relevant
academic schooling and experience facilitate a balance; when lacking these on
the part of the stakeholders, or of the IT-people, the project is likely to
skid off into both ditches — at the same
time...
This
polemical article on software requirements and “CEO” UML was published in
Swedish by “pink daily” Dagens Industri,
debate page, www.di.se, May
24th, 2003 (in a version slightly shortened from my original text
below).
Beställarna
måste bli språkkunniga - kompetenta kravställare är viktigaste kravet…
Karin Grauers skrev i DI den 14 maj: "It-kunderna måste ställa tydligare krav, fundera över vad arbete i projekt innebär och akta sig för partnerskap med it-leverantören". Fast det sistnämnda blir knappast bättre av statens rutin med massinköp av kompetens (i vissa fall bara förmodad) via ramavtal… I kunskapsbranscherna är dialogen kund - leverantör och tydliga krav A och O, och det skall till två parter i en dialog. Därför behöver både beställare och IT-sidan baskunskap om varandras områden. Det viktiga är förmågan att tillsammans omsätta affärsprocessernas behov till tydliga, konkreta krav på fullvuxna IT-stöd, krav som har bäring i såväl affärsverksamhetens ögon som i systemutvecklarens. "Word-Poesi" med svävande visioner på naturligt språk, och med lika naturlig tvetydighet, leder till förvirring kring en kravspecifikation (jämför exempelvis med behovet av exakthet i juridiska texter).
Det är därför
vi haft en världsstandard för mjukvarudokument i 6½
år (Unified Modeling
Language, en utökad version 2.0 kommer i försommar). Även om det hos
beställarna räcker med säg en tiondel av IT-sidans UML-kunnande, så kan ett företag inte slå sig till ro med
frånvaron av denna grundläggande "språkkunnighet", lika lite som med
grundläggande brister i svenskan och engelskan. Utan ett
gemensamt språk inte mycket till kommunikation. Det är ingen slump att
moderna kravhanteringsverktyg, inklusive den svenska exportsuccén Doors (Telelogic), är integrerade med UML vilket i sin tur
mångdubblar automationsmöjligheterna i projektarbetet. Erfarenheterna från
projekt som fungerar är lika viktiga som genomlysningen av flopparna; ett
standardiseringsorgan som även samlar på solskenshistorior hittar man på www.omg.org .
Ett
stimulerande uppdrag för en handelshögskola vore att kartlägga andelen IT i de
innovationer som gett olika bransch- eller koncerngemensamma utmärkelser åt sin
primus motor. Till exempel på SKF i höstas (Innovation Award 2002) var andelen
IT och kunskapsteknik bortåt 100 % och produktivitetsvinsterna i många av SKF:s
100 länder är tvåsiffriga procenttal.
Artikeln
föreslog också ett system för att analysera och dokumentera orsakerna i de fall
som gått snett. Snabb uppföljning är faktiskt redan central i alla moderna mjukvaruprocesser (CMM, DSDM, RUP, Perspective,
Agile-rörelsen). Problemet är, som artikeln också
antydde, bakgrundskunskap om modern systemutveckling; brist på sådan kunskap
gör att processhandboken följs endast slaviskt - i de fall man har någon
process alls. Ett sunt projekt bygger tvärtom varken på byråkratisering (ena
diket) eller på kaos (andra diket) eftersom relevant högskoleutbildning och
erfarenhet gör det lättare för alla att hitta balansen; saknas dessa
förutsättningar på beställar- eller IT-sidan så riskerar
projektet att hamna i båda dikena - samtidigt...
Milan Kratochvíl
Back, Kiseldalens
Top Page