De flesta här är säkert utvecklare och kan svara mig på en fråga som har med systemkrav att göra?

Som jag förstår det så byggs ett system upp baserat på 1) eventuell lagring och tillgång till information, 2) ett lager av logiska komponenter samt 3) gränssnitt för åtkomst av information & logiska funktioner genom API:er, rapporter och GUI?

Min fråga är i vilken form och hur detlajerad skulle den perfekta kravställningen se ut för att utvecklare ska kunna så effektivt som möjligt bygga ett sådant systemstöd?

För att förtydliga mig så kan jag ge ett exempel. Logiska komponenter implementerar affärsregler (som ex validering av personnummer) och kravställningen på en logisk komponent blir därför någon form av kravdokument för affärsregeln. Frågan blir då hur detaljerat ser en utvecklare att kravet kan bli på en affärsregel?

Vad är ni vana vid?

Kravställning av det här slaget är en jävligt tveksam idé.


Sannolikheten att en "kravställare" har fullständig förståelse, kan och kommer ihåg alla specialfall och undantag är mycket liten. Att sen som utvecklare få något dokument med en lista med hur saker ska bete sig är inte speciellt användbart, dels missförstår man, dels missar man detaljer. I slutändan visar det sig att "kravställningsfasen" var helt meningslös och egentligen bara kom fram till självklarheter.

Vad man istället bör göra är att låta utvecklare på ett eller annat sätt vara med under framtagandet av krav. Något som är populärt idag är olika former av agil utveckling, där kraven tas fram inkrementellt under tiden man utvecklar, i samband med att affärsexperter förstår utvecklingen och utvecklare förstår businessen.


Ska man göra kravställning bör den inte handla om ett specifikt lager eller ett specifikt gränssnitt.
Om vi tar ditt exempel med validering av personnummer finns det ett helt spektra av nivåer hur komplicerat man vill göra det, och kostnad därefter. Att speca något som har en direkt inverkan på utvecklingskostnad utan att ha tagit ett konkret beslut kring det är vansinne.

Istället bör man då speca det på en nivå typ "Via val av pnr, få fram en schablonberäkning av skatt." Valideringen ska inte ens ingå i beskrivningen.


Har man rätt uppsättning folk och <b>prompt</b> vill göra en "klassisk kravställning" så ska man åtminstone leverera rätt dokument ut. Rätt dokument är en uppsättning tester, skrivna och kompilerade, som utvecklare kan köra om och om igen för att testa att koden är korrekt.

Du säger att du är tveksam. Jag vet inte om jag ska tolka dig som att "kravställandet", "kravställaren" eller "kravställningsfasen" är problemet, eller rent av alla tre?

Hur det görs ("kravställandet") är lite av min frågeställning. Om jag förstår dig rätt så ser du inte att det under några andra former än genom kod går att säkerställa att man fått med all specialfall och undantag som en systemimplementation behöver ta hänsyn till? Att alla andra sätt enbart leder till missförstånd och uteblivna detaljer. Då undrar jag så klart vad du är van vid för typ av krav för att kunna undvika dessa? Speciellt om de enbart leder fram till "självklarheter" ...

Av vem det görs ("kravställaren") borde ju vara helt och hållet beroende på hur man kravställer. Väljer man att koda up-front så är ju kravställaren mer av en sagotant som berättar för utvecklaren som i sin tur går loss på tangentbordet. Har man däremot en massa krav i form av modeller som ska produceras så krävs det mer folk med olika roller.

När det görs ("kravställningsfasen") är nog lite boven i dramat eftersom det oftast finns en förhoppning bland olika beställare av systemlösningar att man först beskriver målen, sedan skriver ned kraven, bygger lösningen och tillslut testar att den fungerade enligt kravbilden. Du nämner inkrementell utveckling, men det kan ju även appliceras på ett mer omfattande kravställande, där kod och implementation bara är en förlängning av kravmodellerna?

Ok, om vi tar exemplet personnummer.

En kravställare kanske säger "applikationen ska kontrollera att personnumret är korrekt." Detta betyder i princip ingenting, om man inte specificerar noggrannare.

Vad en mer ingående kravställan då ska göra är att specificera
- när applikationen ska kontrollera det
- hur den ska reagera om det inte är korrekt
- hur man kontrollerar personnummer

De två första skulle förmodligen falla i skymundan. (I mitt tycke korrekt - det är något man borde lösa med UX-tester). Då kommer vi in på en ren domänfråga. Om vi utgår ifrån att det inte finns någon befintlig lösning:

Hur detaljerat ska man göra detta?
- "Innehålla 6+4 siffror".
- "Bestå av ett korrekt datum + 4 siffror".
- "Bestå av ett korrekt datum + 3 siffror + kontrollsiffra".
- "Bestå av ett korrekt datum + 3 siffror + kontrollsiffra + stämma överens med angivet kön".
- "Faktiskt representera en befintlig person".
- "Faktiskt representera en befintlig, icke avliden person"

(Och sen kommer det in problemet med de där nya personnumren som de har pratat om.)

Om vi antar att man lägger sig på nivå 3 eller 4.
En kass utvecklare kommer börja försöka lösa datumgrejen och kontrollsiffran själv, om man har valt den nivån. Vilken kravspec som helst i världen kommer inte få utvecklaren att göra det rätt.

Det enda sättet utvecklaren har en chans att göra det rätt är om han får en rad uttömmande tester.


En duktig utvecklare i sin tur, vet vilka delar den inte ska försöka lösa själv, och kommer att lösa det på ett annat sätt oavsett vad kravspecen säger.

<b>>Då undrar jag så klart vad du är van vid för typ av krav för att kunna undvika dessa? Speciellt om de enbart leder fram till "självklarheter" ...</b>
Jag är nog inte helt med på vad du frågar efter här.

Vad jag menade med "sälvklarheter"-delen var helt enkelt om någon försöker få med exempel i en kravställan. Det tenderar att bli något i stil med
"AC'4YY1 är inte ett korrekt personnummer"
"800101-0112 är ett korrekt personnummer"

Specialfallen är inte med och exemplen är meningslösa. Vidare är de i en oanvändbar form eftersom ingen utvecklare vill sitta och skriva in personnumren. Kommer någon på idén att börja fylla på med specialfall kommer de definitivt inte användas, eftersom de är på fel form.

---

Min kontenta är: "Kravmodeller" etc. är enligt mig helt enkelt fel väg att gå från början. Det är ett trubbigt verktyg som inte gör det man vill. Det är alltid en planering som inte kan ta hänsyn till det man upptäcker när man utvecklar. Jag har svårt att beskriva det, men det blir lite som att ge folk lön efter antalet rader kod de producerar, man är fel ute från början.

Jag är just nu i ett projekt med ett väldigt aktivt kravställande. Sättet vi kan få det att fungera (och mitt krav) är med möten en gång i veckan. Det vi i huvudsak gör där är att vi stämmer av varför förra veckans "krav" inte var relevanta och vad vi har fått ändra det till.


Missförstå mig inte - planering är bra. Det är själva planerna som är skit och man kan slänga sen.

"Det enda sättet utvecklaren har en chans att göra det rätt är om han får en rad uttömmande tester."

Menar du att utvecklaren har större nytta av en mängd varianter (testfall) av personnummer än att en kravställare ska formulera ett kryptiskt krav som utvecklaren inte kan tillgodose sig?

Så utvecklaren har alltså större nytta av "uttömmande tester" än av "självklara krav"? Det är lite som ordspråket - "det är bättre att vara rik och frisk än fattig och sjuk".

Finns lite motsägelser i det resonemanget ...
1. Om kravställaren enbart kan producera självklara krav så borde han ju rimligtvis även enbart kunna skapa självklara tester?
2. Om kravställaren har förmåga att skapa uttömmande tester så borde han väl rimligtvis kunna producera uttömmande krav?

Krav och tester hänger ihop så det mest sannolika är att kvalitén på krav och tester är de samma ...

Okej, jag var kanske otydlig.

1. En stor lista med testfall skrivna i text är omöjlig att använda för en utvecklare.
2. En liten lista med testfall skrivna i text kommer aldrig kunna täcka in alla viktiga fall, och därmed bara vara "självklara". Däremot tänkbar att man tar till sig.
3. En liten uppsättning riktiga tester hjälper lika lite som få testfall.
4. En stor lista med tester är mycket, mycket svårt att göra up front på det sättet som behövs.

Alltså: "krav" som inte är testfall i kod är meningslösa. Tester går åtminstone att använda, men de är ändå inte fungerande.

-

Om jag kanske säger hur jag tycker att man borde göra istället:

1. Kort analys av ungefär vad det är för problem man vill lösa, med affärsexperter, någon eller några utvecklare och någon typ av moderator.
2. Sätter upp en grov budget och avgränsning
3. Enkel gränssnittsprototyp för att hamna på ungefär samma breddgrad.
4. Någon form av iterativ, inkrementell utveckling där man i korta iterationer:
- Pratar om allas förståelse av domänen och implementerar domänen
- Diskuterar vilka begränsningar av domänen man ska dra
- Gör gränssnitt för vad man just har lagt till
- Låter användarna arbeta med det nya


Idéerna är ungefär samma i alla former av agil utveckling. Många verkar antingen dämpa ui, ux eller domän, jag tycker det är viktigt att lyfta alla tre på en gång.

Hej

Det måste också finnas någon form av avstämning med hur välinsatta utvecklarna är i kundens behov och vision av systemet. Är det utvecklare som gör något utomlands eller hemma, får de tillgång till att utveckla agilt tillsammans med kund eller beställare.

Lite beroende på vad kravbilden är kan man också sätta ambitionsnivån. Att ta exemplet personnummer kan ju antingen innebära att man gör ett testfall som utvecklaren får som innehåller alla varianter, även att inte kunna skriva bokstäver. Alternativt, ett krav där man skall "validera" personnummer och utgår från att utvecklaren förstår vad detta innebär eller tar reda på det under utvecklingsstiden.

Det finns också aspekter på hur komplext uppdraget är. Finns det risk att det kan bytas ut utvecklare över tid, måste det finnas dokumenterat för överlämning och snabbt komma in i utvecklarnas tänk mm.

Kör man agilt med ex scrum är det fördelaktigt att ha någon med varje dag som kan såväl fungera som produktägare som att ha rätten att ta beslut utifrån det som presenteras. Har personen inte beställanderätt så brukar det bli mycket svårt.

Det är många mjuka aspekter och många skolor. Allting är från fall till fall. Hur ser dina förutsättningar ut för detta projektet?

Tack Niklas för du tog dig tid att beskriva dina erfarenheter av krav.

Hej Pelle,

Tror du det finns en bakgrund till att utvecklare inte riktigt "litar" på kraven och ser dom mest som självklarheter? Det jag är ute efter i min frågeställning är hur krav kan formuleras så att utvecklaren kan känna förtroende för dem och till och med dra nytta av dem i sin leverans. Tar vi återigen fallet regler så skulle de kunna kravställas genom en beslutstabell vilket ligger väldigt nära en implementation i sin struktur och detaljgrad. Samma sak gäller andra modeller som exempelvis HTML-prototyper, processmodeller, informationsmodeller, tjänstemodeller, etc. Följer kraven den avsedda arkitekturen så finns det en möjlighet att driva kraven utifrån målet att ta modeller till exekvering. Därmed göra utvecklarens roll mer till vad den var tänkt till (ursäkta om jag reducerar bilden av en utvecklare en aning :)).

Hej igen,

Som ansvarig för våra utvecklarekonsulter och arkitekter samt dess utveckling och önskemål så vet jag också vad denna kategori konsulter/utvecklare triggar på. Den största faktorn att folk byter arbetsgivare är idag att det är tråkiga uppdrag. En utvecklare triggas antingen av frihet att skapa, eller svåra utmanande lösningar som skall knäckas. En mycket välskriven kravspec kan utföras av väldigt många utvecklare, och mindre välskriven öppnar för tolkningar och fantasi.

Så, med det svaret är det också svårt att säga vad som är rätt eller fel. Kortfattat är det mycket mer kostnadseffektivt med en väldigt bra spec, å andra sidan stänger det alla möjligheter till att skapa ett ännu bättre system utifrån förutsättningarna.

Affärsregler och liknande är ett skall-krav, så det syftar jag inte på. Utan jag menar de tolkningsbara frågorna såsom bästa sättet att skriva återanvändbar kod, att normalisera, vilket sätt data skall hämtas och skrivas osv.

Pelle,

Jag tror du sätter fingret på problemet som varje försenat IT-projekt brottas med, nämligen utvecklarens egna agenda som är skapad av en lite sned självbild. Inget negativt, men ibland lite fördelaktigt för utvecklarens egna utveckling. En utvecklare vill inte ha en välskriven kravspec för den ger inte svängrum och frihet i sitt skapande. En utvecklare ser sig själv som konstnär och inte som arbetare. En utvecklare vill inte konfigurera ett system, bara skriva ett system som är konfigurerbara. En utvecklare vill inte återanvända, bara skriva kod som ska återanvändas. En utvecklare litar inte på mellanhänder som kravfolk, bara på sin egna förmåga att tolka behov.

Det här är ingen ny bild, men man kanske hade en förhoppning om att det skulle ske förändringar under de senaste 10 åren. Men jag skulle påstå att det snarare är på väg och helt omvänd riktning om man får tolka bl a Scrum-rörelsen.

Jag skulle snarare säga att problemet är det motsatta.

För 20 år sen såg man "utvecklare" eller "programmerare" som kodapor som bara ska leverera kod utifrån vad självgoda arkitekter, designers, kravställare och verksamhetskonsulter magiskt har lyckats få reda på och förstå.

De här personerna som "på riktigt" kan sätta sig in i verksamheter och "är experter på att ställa krav" levererar då något slags dokument som aldrig någonsin fungerar att använda.

Orsaken är inte att de är dåliga utan att det inte går att göra något sånt i förväg.
(Sen är den synen de har på sig själva ofta ett problem när det visar sig att dokumenten är fel, handlar om fel saker och bränner pengar på meningslösa detaljer, men det är en annan fråga.)


Sen har du helt rätt i att utvecklare idag har en vilja att göra "mer elegant kod" eller snarare "mer avancerad kod" än de behöver, och att detta är en fråga om att man vill vara en konstnär (vilket iofs inte ska underskattas). Det är inte det som är problemet du pratar om. Det leder till längre tid, säg ett påslag på 20%, men är förhållandevis konstant. Det handlar om en mogenhet som många tyvärr saknar, att acceptera att det finns delar av koden som inte behöver vara konfigurerbara.

Att utvecklare inte vill syssla med konfigurering är ytterligare ett separat problem. Där är dock problemet ofta att om utveckling helt reduceras till konfigurering, så kan man sätta in vilken mellanchef som helst att göra det istället. Det är också vanligen svårare att få rätt än många tror, och därför är det då och då vettigt att göra bedömningen att det inte är värt att försöka.
Återstående fallen handlar om mogenhet och saknad kunskap om vad som finns.

Jag håller med dig om att problemen du beskriver finns. Jag håller inte med dig om att det är det som är orsaken till krisartade projekt.


Orsaken till den "nya rörelsen" bort från vattenfallsmodeller är att:
- verksamheten (domänen) måste vara representerad i kod. Alltså måste utvecklare förstå domänen. Att börja med ett kravdokument är inte riktigt rätt väg att gå.
- utveckling går inte att dela upp i arkitekt och programmerare. Det är samma sak, alla utvecklare måste vara inblandade på många nivåer.
- domänen har specialfall som är olika viktiga. "koden" har specialfall som är olika komplicerade. en bedömning om vilka specialfall som ska implementeras kan man bara göra med domänexperter och kodexperter.
- det fungerar bättre än allt annat. Åtminstone för mig, jag ligger inom 10% upp från ursprunglig budget, går vi över är det pga aktiva beslut från kund.

Verksamhetskonsulter ska inte vara med för att göra ett kravdokument, de ska vara med för att förstå systematiska problem i en organisation och koppla det till utveckling.

Det känns som att din syn är att problemen i grunden är organisatoriska - "kodarna" gör som de vill och levererar inte rätt grejer. Det är mycket IBM över det synsättet. Jag menar att det snarare är så att information måste förmedlas mycket fort, till rätt folk, i rätt format, och att det är där tid försvinner annars.

Pendeln slår alltid från ena sidan till den andra.

Jag tror vi delar synen att man kunnat se en trend de senaste 10 åren ...

Från tungkörda projekt med mycket specar, krav och folk inblandade på vägen som inte jobbar tillsammans á la Vattenfall, där kraven oftast är iskalla och sönderknådade innan de ens nått fram till utvecklaren.

Till agila projekt där kraven är stekheta och oknådade när de implementeras och där utvecklare och beställare bollar krav och implementation som om det vore ping pong.

Jag skulle vilja säga att inget av dessa sätt är optimala. Jag har jobbat i båda läger och har sett avigsidorna hos bägge. Stora projekt med fullständig oöverblickbar kravmängd som står och stampar i utredning efter utredning till s.k. agila projekt där man öst in utvecklare som sitter och väntar på att någon ska tala om för dem vad som ska göras.

Pendeln behöver slå tillbaka, men inte till tungkörda projekt som inte levererar värde. Den behöver slå över till ett arbetssätt där man inte pratar om krav som egna artefakter som lever sitt eget värdelösa liv. Istället behöver man kunna hitta en metodik för att förfina modeller som i sin tur har en naturlig hemvist i arkitekturen. Modeller som fungerar som konfiguration av systemstödet så man lämnar den vallgrav som ofta uppstår mellan krav och kod. Det ställer nya krav på arkitektur - att gå från plattformar som enbart representerar lösvirke som kräver programmerare och deras skaparglädje för att åstadkomma resultat till plattformar som består av mojänger där förlängningen av verksamhetens modeller kan exekvera (regelmodeller, processmodeller, tjänstemodeller, UI-modeller, etc) och dessutom livscykelhanteras.

Utvecklarens verksamhetskunskap (domän tror jag du kallade det för??) är inte att förringa, men varför skulle en snickare behöva bankkunskaper bara för att bygga ett bankkontor? Det är mer relevant att snickaren fokuserar på sina egna domän-kunskaper. Resultatet av ett IT-projekt kan inte vara avhängande på hur väl utvecklarna är insatta i verksamheten. Det är en farlig och dum väg att ta.

<b>till s.k. agila projekt där man öst in utvecklare som sitter och väntar på att någon ska tala om för dem vad som ska göras.</b>
Man ska göra skillnad på buzzword och metodik.
Många såg förstås agil utveckling som jättetrevlig av helt fel anledningar.
"Folk kommer med konstiga krav, vill göra meningsfulla designer och arkitekturer. De tjatar om snygg, ren kod, om testbarhet. Nu slipper jag allt det, vi bara löser grejer hur vi vill!"
Eller
"Nu slipper jag alla jobbiga projektledningsgrejer - besluten tar vi efter hand, och allt är öppet hur länge vi vill."

Det är inte förespråkare av agil utveckling, det är idioter. Agil utveckling handlar (för mig) framförallt om att man höjer upp kodkvalitet, kodevolution och aktivt ifrågasättande som begrepp och att man inte är rädd för att göra fel, man kan alltid backa.

För att detta ska vara möjligt måste man involvera utvecklare i hela fasen, man måste använda rätt verktyg, och man måste med mycket korta iterationer (inte nödvändigtvis reguljära) stämma av allt man gör.

<b>Den behöver slå över till ett arbetssätt där man inte pratar om krav som egna artefakter som lever sitt eget värdelösa liv.</b>
Ok, om vi är säkra på att kraven som separat begrepp öht har en funktion. Vilket jag inte är.

<b>Istället behöver man kunna hitta en metodik för att förfina modeller som i sin tur har en naturlig hemvist i arkitekturen. Modeller som fungerar som konfiguration av systemstödet så man lämnar den vallgrav som ofta uppstår mellan krav och kod. Det ställer nya krav på arkitektur - att gå från plattformar som enbart representerar lösvirke som kräver programmerare och deras skaparglädje för att åstadkomma resultat till plattformar som består av mojänger där förlängningen av verksamhetens modeller kan exekvera (regelmodeller, processmodeller, tjänstemodeller, UI-modeller, etc) och dessutom livscykelhanteras.</b>
Jag har nog lite svårt att hänga med. Det låter som att du tänker dig att "någon viktigare, smartare" än programmerare ska få något slags färdiga lådor de kan binda ihop och trycker på en knapp så blir det system byggda? Det finns väl ett tusental såna projekt. Inget har funkat hittills, eftersom det _alltid krävs programmerare_. (Kör SAP vet jag! Det finns det inga misslyckade implementationer av. Annars kräver väl Sharepoint aldrig insatser av programmerare va? Och skulle det trots allt bli problem kan du ju alltid köra Workflow?)

Jag är framförallt inte med på varför. Vilka krav är det som "professionella kravställare" kan upptäcka och skriva ner som inte vanliga programmerare kan?


<b>Utvecklarens verksamhetskunskap (domän tror jag du kallade det för??) är inte att förringa, men varför skulle en snickare behöva bankkunskaper bara för att bygga ett bankkontor? Det är mer relevant att snickaren fokuserar på sina egna domän-kunskaper. Resultatet av ett IT-projekt kan inte vara avhängande på hur väl utvecklarna är insatta i verksamheten. Det är en farlig och dum väg att ta.</b>
Öh... jag vet knappt vad jag ska säga, detta är ju en ganska tydlig linje genom hela branschen som du säger är fel. 100% av de fallen jag har varit inblandad i har blivit avsevärt bättre genom att alla utvecklare förstår vad projektet handlar om.

1. Din jämförelse haltar. En snickare bygger byggnader, det är döda, statiska objekt som ska användas som utrymme för att utföra en verksamhet. En arkitekt har ritat byggnaden, i samråd med kunniga om hur bankkontor bör utformas. Fine - vattenfall.

Ett system däremot, är en del av en verksamhetsprocess.
Syftet med ett system är normalt att göra något snabbare, säkrare eller ge någon slutanvändare en mer givande upplevelse. Samtidigt är detta omöjligt att se före man sitter i systemet. Detta är första skillnaden.

Vidare, alla verksamheter förändras hela tiden. Om en process inte uppdateras för att möta de förändringarna går det åt helvete. Detta kräver dels en design som är någorlunda förberedd för att kunna uppdateras, vilket i sin tur kräver verksamhetsförståelse, och dels människor som förstår hur man förändrar systemet på rätt sätt. Andra skillnaden.

Tredje skillnaden: om ingen vet hur bankkontor ska utformas, då får man problem. Man kan inte testa att bygga ett rum och se om det verkar bra, och bygga på med nästa. Det enda alternativet man har är att planera hela grejen från scratch, och hoppas att man har gissat rätt för hur man borde göra.

En stor del av utveckling handlar just om att förstå vad det är man ska lösa.


2. Om inte utvecklarna - vem är det som ska vara insatt i verksamheten?
Bara de som är del av verksamheten? Lycka till!
Någon slags fadersgestalt som "kan allt" och som all information måste gå igenom åt båda hållen? Varför? Vad tillför detta? Och varför har det inte fungerat hittills?
Eller, mitt förslag, någon som är van vid att sätta sig in i komplicerade processer, olika verksamheter, och hur som helst måste veta vad som ska göras sen ändå.


3. Det här är egentligen det viktigaste. Vi har kanske tre olika "krav" (ambitionsnivåer) A, B, C. Skulle man rangordna dem så skulle C vara bäst och A sämst. En "professionell kravställare" som inte förstår utvecklingen - vilket de inte gör om de inte är utvecklare - kommer då i första hand vilja ha alternativ C.

Han kan också förstå att C förmodligen är dyrare än B, och kanske godtyckligt väljer att säga att det är nivå B vi ska ligga på.

En utvecklare däremot, vet med betydligt större säkerhet hur svårt olika alternativ är. (Fortfarande ganska dålig säkerhet om han inte förstår domänen.)

Om nu kravställaren kommer med kraven till utvecklaren kan det visa sig att bedömningen var helt vansinnig, och att man antingen får en dålig funktion för något som är ganska viktigt, eller en alldeles för dyr funktion helt i onödan.

Utvecklaren har inget att säga till om - och KOMMER inte säga till om något - om han inte förstår domänen.


Alltså - kan man inte utveckling vet man inte vad A, B, C kostar. Kan inte utvecklarna domänen förstår de inte vilka alternativ A, B, C det finns och kommer inte föreslå något.

För att göra en bedömning behövs kombinerad, omedelbar kunskap om vilka alternativ som finns, hur stor påverkan beslutet har på verksamheten och vad resp alt kostar.

Jag måste erkänna att jag har lite svårt att följa ditt resonemang eftersom jag ibland undrar om du är ironisk. Som exempelvis kommentarerna:

- "Om inte utvecklarna - vem är det som ska vara insatt i verksamheten?"
- "Vilka krav är det som 'professionella kravställare' kan upptäcka och skriva ner som inte vanliga programmerare kan?"
- "100% av de fallen jag har varit inblandad i har blivit avsevärt bättre genom att alla utvecklare förstår vad projektet handlar om."

Jag kan bara återigen ge uttryck för att ett projekts framgång inte kan bygga på att utvecklarna ska vara fullt insatt i verksamhetskunskap. Det är inte rimligt på flera sätt, men framför allt därför att det skapar en situation där beställaren ska sitta och hålla tummarna för att det hela till slut kommer att gå vägen. Fullständigt utelämnad åt utvecklarna och helt i händerna på leverantören. I ingen annan bransch där man implementerar eller konstruerar något i projektform finns ett liknande upplägg.

<b>>Det är inte rimligt på flera sätt, men framför allt därför att det skapar en situation där beställaren ska sitta och hålla tummarna för att det hela till slut kommer att gå vägen. Fullständigt utelämnad åt utvecklarna och helt i händerna på leverantören.</b>
På intet sätt ironisk. Jag vill gärna att du svarar på vem (om någon?) mer än kunden som ska förstå kundens verksamhet?
Jag har arbetat på det här sättet så länge att jag inte minns hur ett projekt någonsin har fungerat utan.

- Jag ser inte hur <b>mer</b> kunskap skulle leda till problem?
- Jag ser inte varför kunden är utelämnad åt leverantören för att leverantören är insatt i domänen?
Kunden kan dra proppen när den vill, kunden kan styra bort från oönskad funktionalitet när den vill, kunden kan begränsa omfattning och detaljnivå när den vill. Och den <b>kan</b> göra det, eftersom utvecklarna förstår vad kunden pratar om.

<b>>I ingen annan bransch där man implementerar eller konstruerar något i projektform finns ett liknande upplägg.</b>
Ja, det finns i den här branschen och fungerar, kan jag säga. Jag vill återigen påpeka att detta <b>inte</b> går att jämföra med att bygga ett hus. System är del av processer, en vettigare jämförelse är implementation av ett nytt logistiskt upplägg i ett lager. Det vågar jag också påstå är omöjligt utan att förstå detaljerna i lagret.


Om vi drar extremfallet åt andra hållet? Utvecklarna vet ingenting öht om verksamheten.
Klassiskt exempel, det kommer ett slags kravdokument:
Säljare ska läggas in i systemet och identifieras med deras anställningsnummer.
Alla säljare har en chef, som definieras med dess anställningsnummer.
Cheferna ska kunna se en sammanställning av alla sina säljare.
[yaddi-yaddi, kommer in försäljningsdata, bla bla.]

Utvecklarna bygger det, exakt enligt specifikation. Kunden har inte tänkt på några andra fall, tester inleds med tre användare, allt verkar fint. Systemet går live, två veckor senare har det skitit sig.

En del säljare har två chefer, eftersom de jobbar på två avdelningar samtidigt. En del säljare är inhyrda och har inget anställningsnummer. En del chefer är säljare.

En utvecklare som inte förstår verksamheten reagerar naturligtvis inte på något av detta under utvecklingen.
En kund som inte förstår utveckling kan inte föreställa sig att något av detta skulle vara ett problem.

Antingen måste man någon som är väldigt duktig på att skriva specifikationer och utreder alla olika fall, och sedan delar ut delsystem på olika utvecklare, eller så måste utvecklarna själva lära sig verksamheten.

"Jag vill gärna att du svarar på vem (om någon?) mer än kunden som ska förstå kundens verksamhet?"

Självfallet kan kunden sin verksamhet bäst och självfallet kan leverantören sina produkter och tjänster bäst. Att passa ihop dessa med varandra kräver att mål möter medel och att kunden har tydliga krav som kan fungera som både underlag för leverantören och som underlag för acceptens.

När vi ändå pratar om jämförelsen med andra branscher så finns det något väsentligt som IT-branschen saknar och det är en tredje part. Saknar man egen kompetens att kravställa så finns det i alla andra branscher en självklar roll att fylla i form av beställarstöd. Det stödet representeras i värsta (och tyvärr oftast) av leverantören eller i näst värsta fall av beställaren själv. Jävighet och egenintressen styr över stora investeringar.

"- Jag ser inte hur mer kunskap skulle leda till problem?"

Det ser inte jag heller, men det du föreslår är att kunskap ska flyttas från kravställande roller till rena utvecklare. Det kallar jag snarare reducerad mängd kunskap.

"- Jag ser inte varför kunden är utelämnad åt leverantören för att leverantören är insatt i domänen?"

Jag säger att kunden är utelämnad åt leverantören om de lägger all tolkning av verksamhetens krav i händerna på utvecklare. Utvecklare kan vara hur insatta de vill i verksamheten, men det ska inte vara det som är avgörande för ett projekts leveransförmåga.

Att utreda oika (undantags) fall ska väl inte vara orimligt att kräva av de som formulerar kravbilden?

Är kunden "utelämnad" eller "utlämnad"? Eller kanske både och?

<b>Att utreda oika (undantags) fall ska väl inte vara orimligt att kräva av de som formulerar kravbilden?</b>

Ofta blir det nog bäst om beställare och utförare tillsammans formulerar kravbilden.

<B>>"Jag vill gärna att du svarar på vem (om någon?) mer än kunden som ska förstå kundens verksamhet?"

Självfallet kan kunden sin verksamhet bäst och självfallet kan leverantören sina produkter och tjänster bäst. Att passa ihop dessa med varandra kräver att mål möter medel och att kunden har tydliga krav som kan fungera som både underlag för leverantören och som underlag för acceptens.</B>
Detta var inte så tydligt - jag kan inte tolka detta på annat sätt än att ingen annan än kunden ska kunna kundens verksamhet?

Naturligtvis vet kunden sin egen verksamhet bäst. Problemet är att leverantörens tjänster här inte är något att "kunna" i vanlig mening. Det jag säger är att ett system är en del av en process, och att leverantören av systemet måste förstå vilken process systemet ersätter, vad som kommer före det och vad som kommer efter det. Inte hela verksamheten.

<B>>När vi ändå pratar om jämförelsen med andra branscher så finns det något väsentligt som IT-branschen saknar och det är en tredje part. Saknar man egen kompetens att kravställa så finns det i alla andra branscher en självklar roll att fylla i form av beställarstöd. Det stödet representeras i värsta (och tyvärr oftast) av leverantören eller i näst värsta fall av beställaren själv. Jävighet och egenintressen styr över stora investeringar.
</B>
Jag tycker fortfarande det låter märkligt när du pratar om "kravställa" som en slags enskild roll.
Jag delar upp "kravställande" i ett antal delar:
1. Förståelse av domän, tillsammans med grov specificering av målbild.
2. Specificering av "moduler" eller arbetspaket, och vilka alternativ det finns.
3. Uppskattning av kostnad och "prerequisite"-analys (i vilken ordning måste saker göras?).
4. Bedömning nytta/kostnad/kalendertid och prioritering.

(Och detta följs av utveckling, och sen om i början igen, det hela mycket iterativt.)

Kundens roll är att vara tillgänglig och OK:a beslut av målbilden under steg 1, och ta beslut under steg 4. Inget görs någonsin utan kundens beslut.
Det sättet egenintressen skulle kunna styra är om någon ljuger i steg 2 eller 3. De stegen kan man förstås stämma av med en separat tredje part, och det sker ganska ofta. Betydligt vanligare är att man struntar i vad man har uppskattat, inte ger någon ny uppskattning, och debiterar mer. Jag kan dock inte se att detta har något med "kravställande" att göra, det handlar ju om rimlighetsbedömningar och kontroll.

Det finns förstås samma problem som i alla andra tjänstebranscher - bondfångare gör sig hackor på okunniga beställare. Samma lösningar finns också; att ta in tredje part, eller att ta in flera offerter och flera referenser, alternativt arbeta med lev. som man vet är ärliga och raka.

<b>>"- Jag ser inte hur mer kunskap skulle leda till problem?"

Det ser inte jag heller, men det du föreslår är att kunskap ska flyttas från kravställande roller till rena utvecklare. Det kallar jag snarare reducerad mängd kunskap.</b>
Jag vet fortfarande inte vad en "kravställande roll" gör. Och jag vet inte vad en "ren utvecklare" är.
Vad jag kan säga är att det inte går att skriva en enda rad kod utan att veta vad den är till för. Ju bättre man förstår vad man gör, desto bättre kod producerar man.
Det går inte att bygga "helt generella" system.

<b>Jag säger att kunden är utelämnad åt leverantören om de lägger all tolkning av verksamhetens krav i händerna på utvecklare.</b>
Jag hänger inte med. Det handlar om att kunden blir lurad för att utvecklarna tolkar verksamhetens krav på sätt som blir för dyrt?

<b>Utvecklare kan vara hur insatta de vill i verksamheten, men det ska inte vara det som är avgörande för ett projekts leveransförmåga.</b>
Jag kan säga att om vi tar det omvända - utvecklarna är inte insatta öht i verksamheten, då kommer det definitivt vara avgörande för projektets leveransförmåga. Tyvärr är det då helt garanterat kört.


Jag blir lite undrade kring dina resonemang, det är svårt att veta vad du menar - vad har du bakgrund?
Har du arbetat som utvecklare, projektledare osv.?

Du ger mest uttryck för förvirring så vi får väl se om polletten ramlar ned denna gång ...

"Naturligtvis vet kunden sin egen verksamhet bäst. Problemet är att leverantörens tjänster här inte är något att "kunna" i vanlig mening. Det jag säger är att ett system är en del av en process, och att leverantören av systemet måste förstå vilken process systemet ersätter, vad som kommer före det och vad som kommer efter det. Inte hela verksamheten."

Då är det väl lämpligt att kunden har dokumenterat de processer som har inverkan på systemet. Då kan de även sätta upp mål på högre genomströmning eller färre FTE och där igenom definiera vilka delprocesser som ska optimeras och i slutändan automatiseras eller supporteras med hjälp av IT.

Processer består av aktiviteter där det utförs ett arbete, vare sig det är manuellt, med hjälp av system eller helt automatiserat av ett system. Till aktiviteterna kopplar man roller som ska utföra arbetet, information som behövs för att utföra arbetet och information som produceras som mervärde under aktivitetens gång. I vissa aktiviteter tas beslut som kan formuleras som regler och ur aktiviteter ändras processens tillstånd vilket medför händelser som man kan reagera på när de inträffar. Allt detta är verksamhetsmodeller och på det här sättet är de vana att formulera sig. Får de dessutom rätt verktyg att uttrycka sig med så kan de skapa väldigt tydliga riktlinjer för IT-utvecklingsprojekt. Riktlinjer i form av krav som ligger i linje med de mätbara mål man satt upp genom analys av processerna.

Med processer, regler, informationsbehov, händelser och roller i en sammanhängande modell över hur verksamheten fungerar blir kravarbetet enbart en ökad detaljgrad av modellerna där processerna uttrycks med fel- och undantagshantering, informationsbehovet detaljeras och sourcas, grafiska gränssnitt prototypas, etc.

Kan man sedan i nästa led även mappa modellerna mot en arkitektur som består av delsystem vars enda syfte är att exekvera verksamhetens modeller som kommer det krävas en ytterligare detaljgrad men i det här läget så är detaljerna av teknisk art och kunskapen om verksamheten har reducerats ned till lagom nivå för vad som kan förväntas av en utvecklare.

På det här sättet skapar man mätbara mål för varje investering, verksamheten får verktyg för att arbeta med kontinuerlig förbättring, IT behöver aldrig producera waste igen, utvecklare kan ägna sig åt det de var ämnade för och systemlösningarna blir mer förändringsbara.

"Jag blir lite undrade kring dina resonemang, det är svårt att veta vad du menar - vad har du bakgrund?
Har du arbetat som utvecklare, projektledare osv.?"

Kanske min åsikt om utvecklares perspektiv på domain-driven design kommer fram i den här gamla tråden då DDD var aktuellt och trendigt som ursäkt för att alla skulle bygga ORM:ar:

http://www.pellesoft.se/communicate/forum/view.aspx?msgid=248975

BTW: Vad hände med alla dessa ORM:ar? Blev det som Ted Neward förespådde - ett mjukvaruindustrins Vietnam?

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

<b>>så vi får väl se om polletten ramlar ned denna gång ...</b>
Hos vem? ;)

<b>> [...] Allt detta är verksamhetsmodeller och på det här sättet är de vana att formulera sig.</b>
1. Detta är inte min erfarenhet, majoriteten är inte vana vid att formulera sig i termer av regler och tillstånd. Även de som säger sig vara vana vid det uttrycker sig klumpigt och oprecist.
2. Även om de skulle vara vana vid det, är "tillstånden" och "reglerna" aldrig fullständiga, väldigt vaga, och omöjliga att översätta till kod. Det finns alltid undantag som går av bara farten i en manuell hantering.
3. Om vi antar att vi bara har verksamhetsmodell -> utvecklare, och struntar i din fortsättning: kunden har då lagt tid på att på egen hand, eller tillsammans med någon slags expert på det, ha uttryckt verksamheten i termer av en modell. Modellen visar sig ha liten nytta vid implementation. (1->N är i själva verket N->N. Obligatorisk är i själva verket "nästan obligatorisk".)
4. Det enda sättet att rätta till detta är upptäcka det. Har man inte upptäckt det i "modelleringen" går det bara att implementera och testa verkliga fall.
5. Jag hävdar då att cykeln:

modell tas fram med utv. + kund och beskrivs i kod -> implementationen är i princip klar direkt -> kunden testar -> repeat

kommer fram till korrekt (del)modell betydligt snabbare, istället för cykeln, som jag hävdar att det blir annars:

modell tas fram av kund själv och beskrivs på något sätt -> utv tolkar modellen, konverterar den till kod -> kunden testar -> repeat

eftersom det sista steget alltid har två extra steg som tar tid och gör att man missar målet; kundens försök att formellt beskriva sin verskamhet och utvecklarens försök att tolka kundens beskrivning. Att sätta in någon slags "kravexpert" förändrar inte mycket.

<b>>Processer består av aktiviteter [...] så är detaljerna av teknisk art och kunskapen om verksamheten har reducerats ned till lagom nivå för vad som kan förväntas av en utvecklare.</b>
Fin tanke. Tyvärr tror jag inte att det går, helt enkelt för att det inte gått hittills. Hade det varit så enkelt, så skulle naturligtvis alla verksamheter göra det. SAP är väl ett ganska bra exempel.
Jag tror också att den här "sammanhängande modellen" du beskriver är olämplig. Ett helt företag ändras för mycket och är för heterogen för att den ska fungera.



Låt mig göra ett försök att beskriva min syn från en annan vinkel:

Kundens process måste i slutändan på något sätt uttryckas i kod (skriven eller genererad). Det kommer vi inte ifrån?

En "process" är ett extremt generellt begrepp. För att kunna utrycka det formellt behöver vi någon form av språk som klarar av att beskriva både processen och alla de specialfall vi vill hantera. (Programmeringsspråk är en kandidat. SQL-DDL är en annan.
Engelska är ett språk som klarar det, men som inte är formellt.
Div "modellspråk" kan mycket väl vara det.)

Att förstå hur man beskriver en process i ett formellt, generellt språk är en skill, men det är ingen större skillnad på ett formellt språk eller ett annat.
Har man den, kan man skriva kod.
Har man den inte men ändå försöker beskriva processen, har man föga nytta av resultatet.

Sen är det naturligtvis en skill att kunna gräva sig in i en process och förstå alla detaljer, som kanske inte alla kan. Min erfarenhet är att utvecklare är exceptionella där. (Träffade en gång en kille som hade ett verksamhetskonsultbolag som uteslutande anställde före detta it-konsulter.)


<b>>utvecklare kan ägna sig åt det de var ämnade för</b>
Kodapor?


<b>>BTW: Vad hände med alla dessa ORM:ar? Blev det som Ted Neward förespådde - ett mjukvaruindustrins Vietnam?</b>
Man ska ha i åtanke att det du pratar om är ett fenomen hyfsat isolerat till .net/Java-världen.
Det har väl lugnat ner sig en smula. Nu är det IoC-bibliotek och MVVM-frameworks som har spytts ut åt höger och vänster.

Jag håller helt med dig i analysen att många "rockstar programmers" försöker höja upp sig själva till skyarna och bara göra helt generella grejer som någon bara ska konfigurera.
Jag hävdar att detta handlar om mogenhet - går det snabbast och ger bäst resultat om jag gör något från scratch som "är helt generellt", om jag gör något från scratch så enkelt som möjligt, eller om jag konfigurerar/ändrar någon annans grejer?
Detta har ju varit ett problem sen kommersiella system kom.

Däremot är jag övertygad om att det inte är det som stjälper projekt. Då har man både haft rejäl otur och varit bra pantad själv - satt in en ensam utvecklare utan någon form av avstämningar, utan någon form av uppföljning.

BTW:
"För .NET-utvecklare kommer WF spela en stor roll framöver"
Hur gick det med det? =)

Den felbedömningen skyller jag på ett lamt .NET community ;)

"Man ska ha i åtanke att det du pratar om är ett fenomen hyfsat isolerat till .net/Java-världen."

Adderar man all den tid som folk lagt ned på att skriva kod som mappar SQL till objekt så överträffar det garanterat det problem som man försökte adressera. Men varför sörja, det var säkert någon kund som fick betala kalaset och som nu sitter på helt osupporterad ORM-kod.

"Nu är det IoC-bibliotek och MVVM-frameworks som har spytts ut åt höger och vänster."

Angående IoC-liknande ramverk så fanns det en rolig sekvens från samma episod av .NET Rocks som ovan (http://www.dotnetrocks.com/default.aspx?showNum=89) där Mark "Spring.NET" Pollack gör bort sig 17:50 minuter in i diskussionen. På den tiden böjde han nacke för Fowler, som många andra vilsna utvecklare.

"För att kunna utrycka det formellt behöver vi någon form av språk som klarar av att beskriva både processen och alla de specialfall vi vill hantera. (Programmeringsspråk är en kandidat. SQL-DDL är en annan. Engelska är ett språk som klarar det, men som inte är formellt. Div "modellspråk" kan mycket väl vara det.)"

Det mest standardiserade "språk" att kartlägga en process på idag är BPMN. Här finns tillräckligt mycket möjligheter att uttrycka sig så det blir över för vilken utvecklare som är van vid vilket språk som helst. Att beskriva processer i vanliga programspråk är inte att rekommendera eftersom de är skapade för OO-design och inte PO-design. De saknar bland annat prioriterat stöd för assynkron kommunikation. Vill man "koda" processer så är ju BPEL att föredra, även om det snart bara är IBM Process Server som driver den modellen för utveckling. WF tror jag helt enkelt inte gick fram … precis som WCF inte riktigt flög på grund av att .NET-utvecklare generellt sätt är gamla VB6-hackare som aldrig eller sällan utvecklat distribuerade lösningar. Ibland kan man se system där WCF skyfflar objektstrukturer över HTTP, vilket är helt galet. Ofta som ett resultat av att ORM-kramarna fått rodda på fri hand.

<b>Att beskriva processer i vanliga programspråk är inte att rekommendera eftersom de är skapade för OO-design och inte PO-design</b>

Jag såg att du hade ungefär samma argumentation i den tråden du länkade till. Jag menar att det inte stämmer.

Vad jag anser är att de flesta IT-projekten inte går att utveckla som stora komplexa, fullständiga, rigida system. Verksamheten ändras alldeles för snabbt, därför är varje ekonomiavdelning 10% affärssystem och 90% excel.

Samtidigt tror jag inte att det går att ha en slags flytande processmodell över hela organisationen där man hela tiden kan byta ut vad som helst - helt enkelt för att gemene man inte kan hantera det, och för att utvecklare inte kan sätta sig in i en så stor del av verksamheten.

Jag tror inte heller på iden med en helt serviceorienterad arkitektur där flak med data skickas runt från och till någon slags "core business service". Helt enkelt eftersom så många har försökt, och jag aldrig har sett någon som har lyckats. (Ska man prompt dra åt det hållet tycker jag event sourcing med någon oodb eller annan tillämplig NoSQL-db är ett vettigare drag. Då får man en elegant lösning på concurrency/asynkonitet utan att göra något speciellt.)



Vad jag anser är att man istället bör bygga små, autonoma enheter. En enhet har då, med lite justeringar, i allmänhet en livslängd på flera år, samtidigt som projektet blir "klart". Projekt på 100-2000 manstimmar tycker jag är optimalt. Man kan bestämma en teknik och filosofi, som lever över projektets livslängd, det kommer inte radikala nya idéer som "måste användas" under utvecklingen.

Lämpligen har man då också nerbantade output- och input-format, inte nödvändigtvis över några specifika serviceprotokoll, och kan på så sätt enkelt byta ut det som ligger runt omkring.


Inom varje enhet bygger man enligt den principen som är mest logisk och mappar bäst mot verksamheten, och som har bäst stöd i språket. Helst hade jag personligen skrivit allt i LISP men det går tyvärr inte. OO är i mindre projekt väldigt ofta en naturlig princip, och som är naturlig att implementera.

Jag ser hela diskussionen om ORM och problemet med att mappa data mellan X och objekt som ganska lam. I projekt där jag är inblandad rör sig detta om en litet jobb mot slutet. Är det ett stort problem har man fel språk.


Om vi tar dina exempel med BPEL (och WF), som jag inte använt mig av: Varför trappas det ner/används inte tror du?
Jag tror att utvecklare helt enkelt inte är intresserade av att arbeta med språken. Jag hävdar att det går att "bevisa" teoretiskt.

gå att använda i verkligheten => generella språk
gå att använda för programmerare => formella språk
vara möjliga att skriva för användare => tillräckligt abstraherade.

De tre står i konflikt, om inte användarna själva är programmerare, och därmed kan göra grejerna själva. Alltså blir det ett mellanlager, som utvecklare ska sitta och lite hjälpligt mappa mot. Det är ingen utvecklare intresserad av, oavsett mognadsgrad.

Varför inte använda all den kunskap och erfarenhet en utvecklare har från början istället?

"Jag såg att du hade ungefär samma argumentation i den tråden du länkade till. Jag menar att det inte stämmer."

Jasså, men då kanske du kan redogöra för vad som inte stämmer.

"Vad jag anser är att de flesta IT-projekten inte går att utveckla som stora komplexa, fullständiga, rigida system. Verksamheten ändras alldeles för snabbt, därför är varje ekonomiavdelning 10% affärssystem och 90% excel."

Det håller jag med om och jag är även vän av Excel.

"Samtidigt tror jag inte att det går att ha en slags flytande processmodell över hela organisationen där man hela tiden kan byta ut vad som helst - helt enkelt för att gemene man inte kan hantera det, och för att utvecklare inte kan sätta sig in i en så stor del av verksamheten."

Vet inte vad du menar med "flytande" men att verksamheten har som ambition att dokumentera sina processer är väl inte orimligt om man är klar över vad det bidrar till.

"Jag tror inte heller på iden med en helt serviceorienterad arkitektur där flak med data skickas runt från och till någon slags "core business service". Helt enkelt eftersom så många har försökt, och jag aldrig har sett någon som har lyckats. (Ska man prompt dra åt det hållet tycker jag event sourcing med någon oodb eller annan tillämplig NoSQL-db är ett vettigare drag. Då får man en elegant lösning på concurrency/asynkonitet utan att göra något speciellt.)"

Jag har nog aldrig hört tjänsteorientering beskrivits på det sättet förut … möjligtvis bland domänmodellsförespråkarna och ORM-anhängarna.

"Vad jag anser är att man istället bör bygga små, autonoma enheter. En enhet har då, med lite justeringar, i allmänhet en livslängd på flera år, samtidigt som projektet blir "klart". Projekt på 100-2000 manstimmar tycker jag är optimalt. Man kan bestämma en teknik och filosofi, som lever över projektets livslängd, det kommer inte radikala nya idéer som "måste användas" under utvecklingen."

Det normala med tjänstearkitekturen är att man bygger tjänster efter behov och om möjligt tillgodoser det genom centraliserad kontroll.

"Om vi tar dina exempel med BPEL (och WF), som jag inte använt mig av: Varför trappas det ner/används inte tror du?"

Jag minns ett annat försök från MS (som jag bloggade om i jämförelse med BPEL http://choreographictechniques.blogspot.se/2006/06/coordination-patterns.html) som hette Concurrency and Coordination Runtime (CCR) och gjorde livet lättare för C#-utvecklaren som ville koda asynkront.

För det första så måste vi skilja på motgångarna för WF från BPEL. WF lyckades inte lanseras därför att Microsoft dels inte gjorde ett seriöst försök och för det andra så tror jag inte den gemene .NET-utvecklaren begrep vad WF var när det kom.

När det gäller BPEL så finns det idag en gigantisk investering från alla plattformsleverantörer och inom Java-community så finns det många BPEL-utvecklare. BPEL däremot har fått konkurrens från BPMN och de flesta leverantörerna har nu bytt notation.

Process-orienterade modeller/notationer/språk har en given plats, men det som krävs är utvecklare som ser att lösningar inte ska orientera sig kring en informationsmodell, utan en processmodell.