Københavns Brandvæsen om forsinket kontrolrums-software: Hele grundtanken har været forkert
Alarmcentraler, der tager imod 112-opkald, og vagtcentraler, der eksempelvis disponerer og koordinerer brandbiler, er normalt to forskellige enheder. Men i København er alarmcentralen fysisk placeret ved Københavns Brandvæsen, hvor man har lagt vagtcentral- og alarmcentralfunktionen sammen i ét egenudviklet system.
It-chef i Københavns Brandvæsen Kurt Christensen, hvorfor har Københavns Brandvæsen valgt at gå videre med udviklingen af en egenløsning til kontrolrumssoftware i stedet for at vente på løsningen fra Terma?
»I forhold til Termas løsning, så har jeg endnu ikke set, hvad den går ud på. Jeg har set den ganske enkelt på nogle overheads, og så har jeg set en minimal radiobetjeningsløsning. Og det er sandt at sige ikke et flådestyringssystem (software, der kan holde styr på eksempelvis alle brandbiler hos ét brandvæsen,red.). Terma har ingen moduler, der understøtter vores alarmcentralfunktion.
Jeg er sikker på, at hvis de havde et system, der understøttede det, så ville det formentlig være billigere, end det vi gør selv - og så ville vi selvfølgeligt bruge det. Men de har ikke sådan et system, fordi alarmcentralfunktionaliteten ikke er skrevet ind i det kontraktmateriale og den kravspecifikation, der er lavet.«
* **Hvorfor tror du, Terma-softwaren er forsinket?*
»Jeg tror egentlig, at der er flere årsager til det. Den ene årsag er, at den kravspecifikation, der er lavet, sandsynligvis ikke har afspejlet brugernes forventninger. Det har været en standard kravspecifikation, som man laver til store it-projekter. Men vores erfaring siger, at hvis ikke man har brugeren med - i særdeleshed den direkte bruger, som sidder med skærmbilledet foran sig - så går det galt.
Jeg tror, Terma i princippet har kunnet leve op til den kravspecifikation. Men der har aldrig været enighed om, hvordan systemet skulle bruges. Det, tror jeg, er gået op for alle parter nu. Man har lavet en kravspecifikation, som egentlig ser meget fornuftig ud, men når den bliver bragt frem til et brugerniveau, så hænger den ikke sammen med den verden, som brugerne normalt ser på. Så det er sådan en standard it-projektfejl, vil jeg gætte på.
Hvis vi kigger sådan på det, så tror jeg egentlig, at Terma har forsøgt at leve op til de krav, der er stillet, og jeg tror sådan set også, de har leveret noget af det. Men når man så skal have nogen til at teste det i den anden ende, så siger de: Hvad pokker er det for noget?«
Er det utopi overhovedet at begynde at udvikle software, der skal kunne bringe alle beredskaberne sammen?
»Jeg tror, metoden man har valgt, er forkert. Hele grundtanken har været forkert. Man skulle have lavet integrationen mod SINE-nettet på de standard snitflader, der allerede er beskrevet og veldokumenterede i Tetra-standarden, det havde været godt nok - mere behøver man ikke. Men så var der måske ikke så meget til konsulenthusene bagefter, så de kan hjælpe med at bygge nogle gode flådestyringssystemer.«
Er det overhovedet realistisk, at man kan kravspecificere sig ud af et projekt af dette omfang?
»Nej, det tror jeg ikke. Jeg tror, dette her er et udviklingsprojekt. På samme måde, som når vi laver vores alarmcentral. Så starter man med nogle beskrivelser af og en ramme om, hvad der skal laves. Og så demonstrerer du det stille og roligt. Og efterhånden får du det drejet i den rigtige retning. Og det er jo også det, der er sket, når Terma er kommet med noget. Så har der hele tiden været nye krav, og lige pludselig kan de ikke genkende kravspecifikationen i forhold til de operatører, der sidder og gerne vil have systemet.«
Læs hele interviewet med Kurt Christensen i den trykte udgave af Ingeniøren fredag.
Kommentarer (11)
Man har lavet en kravspecifikation, som egentlig ser meget fornuftig ud, men når den bliver bragt frem til et brugerniveau, så hænger den ikke sammen med den verden, som brugerne normalt ser på.
Igen igen igen. Det her sker hele tiden. Hvornår begynder man at inddrage brugerne - og i den sammenhæng: ALLE brugerne.
Her går der totalt fisk i systemudviklingen igen igen igen. Systemet er lavet så det svarere til krav, men det kan ikke bruges af dem som det er lavet for at hjælpe.
Dog har kravspecifikationsteam det altid med at vaske hænderne og leverandøren sidder med aben.
-
0 -
0
Så det er sådan en standard it-projektfejl, vil jeg gætte på.
En standard fejl er ikke at undersøge de faktiske behov, men i stedet bruge kravspecifikationen som udgangspunkt og senere hen som undskyldning for at systemet ikke kan imødekomme brugernes faktiske behov.
Kontraktform og udviklingsmetodik gør det typisk umuligt at styre efter behovene. I stedet bliver det kravene og de økonomiske rammer i kontrakten, der der styres ud fra.
-
0
-
0
En standard fejl er ikke at undersøge de faktiske behov, men i stedet bruge kravspecifikationen som udgangspunkt og senere hen som undskyldning for at systemet ikke kan imødekomme de faktiske behov, som brugerne har.
Men er det ikke også netop hvad artiklen siger?
-
0
-
0
Men er det ikke også netop hvad artiklen siger?
Jo. Jeg forsøgte blot at konkretisere essensen.
-
0
-
0
@Carsten
OK ;-) Var ikke sikker på om jeg forstod hvad du mente, men det gør jeg nu.
-
0
-
0
Som der også fremgår af artiklen, så kan det pågældende projekt også opfattes som et decideret udviklingsprojekt.
Og udvikling er det mig bekendt ikke muligt i detaljer at kravspecificere sig ud af.
Her var det mere på sin plads, ud fra den overordnede målsætning, på ganske traditionel vis at planlægge, analysere, designe, programmere, teste og evaluere.
At man overhovedet ikke har behandlet opgaven som et udviklingsprojekt, ser jeg som det egentlige problem.
En anden vinkel er, at såfremt det alene er Kbh. Brandvæsen, der har brug for flådestyringsmodulet, så ligger dette vel ikke inden for projektets naturlige rammer.
-
0
-
0
Det er min erfaring at de skrivebordsgeneraler der forlanger at godkende udviklingskontrakter (alt der ikke er hyldevare er pr. definition udvikling) desværre meget tit ikke har den fjerneste forståelse for, at slutbruger skal med fra den tidligste fase af projektet.
Og det er lidt sjovt - fordi langt de fleste projekter opstår pga. funktionsønsker fra slutbruger - men når bundlinie fikserede økonomer bliver blandet ind i et projekt - så går det galt. Disse sparer gerne på alle andres funktioner end deres egen løn. Selvom det er kendt at økonomifolk ikke er særligt kreative, andet end i regnskaber :-)
En kravspecifikation er et must - men kun hvis den afspejler virkelighedens krav til funktionalitet, ellers er kravspek'en kun spild af alles tid.
Mvh Lars plbrake.dk
-
0
-
0
Her var det mere på sin plads, ud fra den overordnede målsætning, på ganske traditionel vis at planlægge, analysere, designe, programmere, teste og evaluere.
Forhåbentlig ikke efter den alt for traditionelle måde du opstiller (Waterfall)
-
0
-
0
Og udvikling er det mig bekendt ikke muligt i detaljer at kravspecificere sig ud af.
Hvordan ved man så hvad man skal udvikle? Kravspecifikationer er da netop til for at prøve at opsummere kravene til det produkt man skal udvikle.
-
0
-
0
Det ved man kun ud fra den overordnede målsætning. - Mine erfaringer siger, at kravspecifikationer ikke hører hjemme i udviklingsprojekter, med mindre man kan opfinde "dynamiske kravspecifikationer".
Heri ligger jo netop forskellen på et "standard projekt" kørt lige ud ad landevejen og udvikling.
-
0
-
0
Mine erfaringer siger, at kravspecifikationer ikke hører hjemme i udviklingsprojekter
Hmm. Min erfaring med software udvikling, er at der er nødt til at ligge nogle overordenede krav til at produkt, før end det kan realiseres. Ellers ved man dårligt hvad man laver. Om det er software, biler eller hvad som helst andet, så er der en kravspecifikation (jeg har ikke prøvet at udvikle biler, men jeg tror de har en plan for at det skal være en bil, med ca. så mange døre, den type motor osv.).
Heri ligger jo netop forskellen på et "standard projekt" kørt lige ud ad landevejen og udvikling.
Hvad er et "standard projekt"? Og hvad er det i forhold til udvikling. Det er ikke en defintion at sige mangel på udvikling. Jeg har været med til at udvikle meget software (rigtig meget endda), og der er da altid en kravspec.
Det kan godt være jeg har misset pointen, men kan du ikke give eksempler Erik? Hvad er det man udvikler som "standard projekter" og hvad er det man udvikler uden en kravspec. (altså en liste af krav til det endelige produkt).
-
0
-
0
Tilføj kommentar
