Vi mangler uddannelse i "bærende konstruktioner"

Ville du hyre en ingeniør til dit mega-byggeprojekt, hvis han eller hun ikke var blevet undervist i beregning af bærende konstruktioner? Forhåbentlig ikke; men det er ikke desto mindre fuldt sammenligneligt med, hvad der sker med de offentlige it-udvklingsprojekter. Tænk Tinglysning, Elektronisk patientjournal, og utallige andre. Det er mine penge, der fosser ud i sådanne projekter, og det vil jeg ikke bare finde mig i længere.

Danske politikere ynder at sige, at vi er, om ikke allerede, så dog godt på vej til at blive, verdens bedste it-nation. Det er rent ud sagt noget vrøvl.

Trods undtagelser er de, der arbejder med it-udviklingsprojekter i Danmark simpelthen ikke gode nok. Der mangler helt grundlæggende forståelse for it-fagområder, og der mangler kompetence og erfaring. Erfaring får man selvfølgelig kun hen af vejen, men også kun hvis forståelsen og den grundlæggende kompetence er på plads, og hvis man har kompetente chefer, mentorer og kollegaer. Det er der alt for mange, der ikke har. Jeg vil ikke komme med konkrete eksempler; men jeg kender MANGE, og resultaterne af de it-udviklingsprojekter, som det offentlige sætter i gang, taler ders eget sprog - og så hører vi endda kun om nogle få af dem i offentligheden.

Der mangler målrettet og velstuktureret undervisning i alle de fagområder, der hører til god it-udvikling.

IT-universitetet, som man skulle tro gik forrest med den slags, har indtil nu kun leveret et rodet og usammenhængende undervisningsprogram såvel på bachelor- som på kandidatniveau. Der er ikke et eneste selvstændigt kursus i udarbejdelse og styring af krav - det vigtigste fagområde indenfor it-udvikling, og heller ikke noget i test - som er næsten lige så vigtigt. Til gengæld er der indtil flere kurser i programmering - som 'bare' er et håndværk, og ensidige kurser i objekt-orienteret udvikling - som for længst har mistet sin status som 'løsningen på alle it-udviklingsproblemer'. Jeg kender det indefra, for jeg er og har været ekstern lektor i flere år, og min mulighed for at undervise er gået fra 4 forelæsninger i test på et semester til 14, til 2 og nu til 0! Den detaljerede historie kan fås på opfordring.

For nylig var jeg til et seminar om uddannelse inden for it-udviking, og jeg spurgte Mads Tofte (chef or ITU), som også deltog, hvordan han så på, at uddannelserne ikke lever op til det, der er behov for ude i industrien. Hans svar var noget i retning af: "Det er ikke universiteternes opgave at overtage det, som virksomheder underviser deres ansatte i. Vi skal sikre, at de uddannede har lært at indlære og er i stand til at analysere problemer og finde frem til gode løsninger."

Helt ærligt! Skoleelever lærer at indlære og analysere og løse problemer fra 1. klasse. Jeg har en datter på 15 år; hun går i 9. klase og hun kan bare det der. Universiteterne skal, efter min mening, bygge dybe fagkundskaber ovenpå. Ikke at undervise ordentligt i f.eks. krav og test svarer til, at jeg som civilingeniør i sin tid ikke var blevet undervist i beregning af bærende konstruktioner og materialelære. Det kan ikke være meningen, at virksomheder, som dårligt mestrer it-fagområderne selv, skal uddanne deres ansatte i det mest grundlæggende. Det har hverken de eller vi råd til.

Få nu styr på den danske it-uddannelse - vi kan f.eks. hente inspiration fra Indien, Kina, Japan og Korea. De ved, hvordan man bliver 'verdens bedste it-nation'.

AM

Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Hans-Kristian Bjerregaard

Enig, der burde være en særskilt linie der specialiserede i styring af IT-projekter. Men så længe det offentlige og andre store organisationer bare køber hvad som helt er der jo intet incitament til en såddan uddannelse.

Jeg er oftest lamslået over at man inviliger i at købe software af den ringe kvalitet man oftest ser. En ting er at systemer fejler, det sker! Men f.eks. på KU har vi et studie og eksamenssystem (STADS) der ikke engang kan printe alle de kurser man har taget (når jeg printer mister jeg ca 1/3 af alle kurser) og aligevel har man ikke bare købt det, det bliver også brugt på flere andre danske universiteter!

Så i mine øjne handler det mere om at kunderne ikke er konsekvente nok med at stille krav til det de betaler for. Og så længe de ikke er det er der ingen der gidder bruge tid på kvalitet.

  • 3
  • 1
Anonym

Jeg er enig i, at "Verdens største IT-nation" er utopisk, med det grundlag som er nu.
Jeg har selv familie, der har uddannet sig inden for IT, og som jeg måtte motiverer på anden måde, simpelthen fordi den uddannelse der blev givet, ikke var motiverende nok.
Permanent, måtte jeg høre på, hvor elendigt det stod til, og at der faktisk ikke var tale om lærens undervisning af eleven, men om elevens undervisning af læreren.
Det var en laaang kamp, hvor jeg fortsat er i tvivl om, at jeg gjorde det rigtige, ved at fastholde mit motiv, at "et papir på uddannelsen" var vigtig. Der var egentlig tale om spild af tid, for at få det stykke papir.

Der er mange, der kan leverer de løsninger, der forventes og som der betales for. Men tilsvarende, besværliggøres mulighederne for at man kommer ind som leverandør. Der er tale om, at man forfordeler en række leverandører, også selv om disse leverandører ikke kan levere varen.

Det nævnte eksempel, Digital Tinglysning, er et skoleeksempel på, hvor farligt det kan være, når man køber en løsning og ikke får leveret varen. Man skal bare prøve at forestille sig, at Digital Tinglysning mister alle Data, så er der ikke mulighed for at tilbagerulle til de gamle Tinglysningsbøger, for de findes ikke mere og har ikke eksisteret længe.
Et Dataflop i den forbindelse, vil have ufattelige konsekvenser.
Foruden det usikkerhedsmoment som ligger i, at data enkelt kan kopieres af dem med direkte tilgang til data.
Ejeren af tinglyst ejendom, har ikke engang indsigt i, hvem der tilgår dennes data, eller hvad dennes data benyttes til.

Tilsvarende, er der mange andre projekter, også nogen som anvendes, som ikke overholder basale elementer. Elementer som vores retssamfund og demokrati har sit fundament i.
Det ser jeg som den største mangel inden for IT leveret til det offentlige.

  • 0
  • 0
Mark Gray

Anne Mette, så vidt jeg ved er der et fag i Anskaffelse og kravsspecifikation på ITU udbudt under masterunderdannelsen (https://mit.itu.dk/ucs/cb/course.sml?course_id=1192985&mode=search&semes...). Rammer det helt skævt i forhold til det du efterspørger? Jeg har ikke selv fulgt det, men har fået det anbefalet.

Derudover er det rigtigt, at softwaretestfaget er blevet nedlagt som obligatorisk fag på cand.it i softwareudvikling (SDT) for at blive erstattet af et mere generelt "software engineering"-fag. Nu fuldte jeg dette nye fag i i efteråret var egentlig ganske tilfreds med det lidt bredere fokus. Faget er jo netop obligatorisk for folk der læser cand.it uden en IT-faglig bacheloruddannelse som måske har mindre gavn af et så specialiseret fag så tidligt i deres studieforløb (første semester).

Måske er der grobund for et videregående fag med fokus på softwarekvalitet og test for folk med en større baggrund indenfor softwareudvikling? Tror du ikke det er muligt at oprette et sådan som valgfag? En anden mulighed kunne være at se nærmere på en egentlig specialisering på SDT-uddannelsen (22,5 - 30 ECTS), men det kræver nok nærmere analyse for at se om efterspørgslen er der for det.

Forresten, tillykke med din nye blog! Den er blevet delt blandt de studerende på SDT så mon ikke der kommer en flok faste læsere derfra i fremtiden :).

  • 1
  • 0
Lars Balker

Hvad i alverden har uddannelse med vores offentlige katastrofeprojekter at gøre. Udbudspolitikken og kyniske konsulentfirmaer har jo lagt opskriften på fiasko længe inden en tekniker har rørt et tastatur.

  • 8
  • 0
Anonym

@ Lars Balker Rasmussen.
Jep.
Du beskriver meget flot og kort, de værste elementer i hvad der går galt i levering af bl.a. IT til det offentlige.

Det skal også tilføjes, at der accepteres leveringer, som på ingen måde lever op til det forventede. Hvorfor disse leveringer accepteres, kan ikke forklare med konsulentbistand eller kompliceret udbud.

I bedste fald, kan accepten af disse leverancer forklares i inkompetence og manglende overblik, hos dem der accepterer leverancen.

Der kan altså være en grund til, at accepterer disse leveringer er blevet accepteret.
Men tilsvarende, så er der leveringer, hvor der er tale om at man direkte har ødelagt eksisterende systemer, uden at have leveret den forventede erstatningsløsning.
Især i forbindelse med Digital Tinglysning, gik det helt galt, og det udgør fortsat et problem.

Den fysikske løsning, er jo ikke længere mulig, så man er tvunget til at forholde sig til den digitale løsning, uanset om man vil eller ej.
Lykkedes det f.eks. ikke, at hæve sikkerheden omkring den identifikationsløsning der skal benyttes som login, er der et meget alvorligt problem.

Der er ganske enkelt tale om, muligheden for frit og sikkert, dokumenteret at eje ejendom i Danmark, eller ej.

Det er nu styret af en virksomhed, ikke af en offentlig myndighed.

  • 1
  • 0
Nikolaj Brinch Jørgensen

Det er fint nok alt sammen, men jeg må tilslutte mig Lars' kommentar. Årsagen for de forliste projekter skal ikke findes i uddannelsessystemet.

Desuden ved jeg ikke hvad du mener vi kan lærer af offshoring. Alle de leverancer jeg har været med til at modtage fra bla. Indien er klart det værste der er blevet leveret. ISO, CMMI osv. hjælper ikke en dyt på noget som helst. Det betyder ganske enkelt blot at man konsistent laver de samme fejl og levere det samme mg hver eneste gang.

Tilsidst vil jeg sige at analogien til ingeniør verdenen jo enten skal føres helt ud, eller droppes. Dvs. hvis IT skal sammenlignes med bærende konstruktioner, så skal vi huske at fjerne test som vi kender det i dag fra softwareudviklingen, for det kan man altså ikke med en storebæltsbro. Vi kan ikke lave den, for så at teste den, og så fixe defects på den, eller lave refactorings.
Et af problemerne med mange organisationers tilgang til netop softwareudvikling er, at vi først definere alle krav til systemet (og bruger uforholdsmæssig lang tid på det). Så koder vi alle kravene (uagtet at verden ændrer sig, og dermed også kravene), og derefter tester vi det så. Det er den måde man lave store IT projekter i det offentlige på. Måske man skulle pille ved grundlaget for offentlige IT projekter, før man skyder skylden på ITU, DIKU eller andre.

Desuden er der rigtigt mange som uddanner sig til at arbejde med IT fordi de netop kan lide at være kreative og skabe løsninger. Desværre er der også rigtigt mange af dem som ikke interessere sig for kundens forretning og dermed kravene. Det er meget vanskeligt at uddanne folk til at have en specifik interesse. Det er også derfor der ikke ersærlgt mange rigtigt dygtige udviklere der beskæftiger sig med test (dem der er besjæftiger sig med automatisering af test - noget som mange testere ikke bryder sig om - de vil hellere gemme sig bag QTP, QC osv. dyre og unødvendige værktøjer).

  • 6
  • 0
Karen Lisbeth Schmidt

Selve driftssiden på IT-området har altid været et stedbarn. Når det er kodet og testet, så bliver det smidt i drift. Ofte har man ikke lavet loadtest, så når der pludselig er 3000 brugere på og ikke kun 3, så står det hele stille.
Hvad angår datadelen, så mener alle jo at de nemt kan lave de tabeller i databasen, der skal bruges UDEN at have konsulteret specialister inden for databaser og fået lavet en fornuftig datamodel med det resultat at systemet går i stå med deadlocks og andre "sjove" oplevelser.
Men DRIFT er åbenbart ikke fint nok til at komme på IT-universitet eller andre IT uddannelser for den sags skyld.
Og ITIL kurser er jo kun for driftsfolk - eller hva?

  • 0
  • 0
Nikolaj Brinch Jørgensen

Selve driftssiden på IT-området har altid været et stedbarn. Når det er kodet og testet, så bliver det smidt i drift. Ofte har man ikke lavet loadtest, så når der pludselig er 3000 brugere på og ikke kun 3, så står det hele stille.
Hvad angår datadelen, så mener alle jo at de nemt kan lave de tabeller i databasen, der skal bruges UDEN at have konsulteret specialister inden for databaser og fået lavet en fornuftig datamodel med det resultat at systemet går i stå med deadlocks og andre "sjove" oplevelser.
Men DRIFT er åbenbart ikke fint nok til at komme på IT-universitet eller andre IT uddannelser for den sags skyld.
Og ITIL kurser er jo kun for driftsfolk - eller hva?


Problemet er nok snarere silo-opdeligen, som gør at det hele tiden bliver nogle andres problem. Hvis man pine-død har ansvaret - og man derigennem kan mærke smerten når man har lavet noget rigtig lort, ja så er det sjovt hvordan det får de fleste til at gribe opgaven anderledes an næste gang og gøre sig mere umage.
Hvis derimod der ingen konsekvens er, og man som enten leverandør, udvikler, tester, driftsperson, sælger, arkitekt mv. kan blive ved med at sjuske og fylde andre med varm luft, uden konsekvens, ja så fortsættes denne fremgangsmåde.
Det er problemet i mine øjne. Projektudvikling er nemlig kun en lille bitte sum, sammenlignet med de kæmpe summer der for eftertiden skal erlægges i ændringsønsker, og drift. Det er drift de fleste store danske IT organisationer er interesseret i, ikke softwareudviklingen, eller test.
Så jo drift er fint nok og vigtigt.

  • 0
  • 0
Peter Juhl Christiansen

Er enig i a det offentlige udbuds misk mask ikke er med til at vi får gode IT løsninger for vores skatte kroner.

Men tingene hænger sammen, tror simplethen ikke at et firma byder på noget vel vidende at deres løsning vil blive noget hø!

De mener at vide de kan lave noget der virker.

Jeg tror bestemt at hvis man på UNI lærte at lave

  1. Systemer der er robuste
  2. teste det man laver
  3. vide at det kan sættes i drift

Så ville de løsningsforslag der kommer fra diverse IT firmaer være bedre! Vi kan ikke give Projekt chefer og advokater skylden for at IT systemer ikke kan det brugerne har brug for.

Det er da "IT-Eksperter" der har bild Embedsmænd, politikere og godt folk ind at alt hvad vi behøver en en stor fed kravsspecifikation så skal vi nok skrive noget kode der gør alle glade.

Det må altså også være (os) "IT-eksperts" ansvar at fortælle dem at vi tog fejl og at hvis de bestiller et IT-system styret på den måde vil det blive noget hø.

Desværre ser det udtil at vi kun kan blive enige om hvad man ikke skal gøre.

  • 0
  • 0
Troels Thomsen

Hvis man vil opnaa succes med offentlige it-projekter bliver man noedsaget til at tilpasse sig branchens maade at arbejde paa. Jeg kan ikke komme i tanke om et eneste godt (it-)produkt, der er produkt af netop den proces, man fra det offentlige efterspoerger.

Der er en regel i datalogi om, at man altid kan loese et problem ved at tilfoeje et ekstra abstraktionslag (selvom det dog ikke altid er en god ide). For projektstyring er det aldrig en god ide. Afstanden imellem kunden og den, der skal udfoere implementering, bliver simpelthen for stor, hvilket unaegteligt medfoerer en kravspecifikation med en hoej detaljegrad.

Med en udfoerlig kravspecifikation faar man i bedste fald det, man har bestilt, men ikke noedvendigvis det, man til den tid har brug for. Man faar dog ogsaa kun sjaeldent det, man har bestilt, fordi dygtige udviklere simpelthen ikke trives med at foelge en vejledning til, hvordan de skal arbejde (og selv velmenene krav ender ofte med netop at diktere teknisk implementering saavel som arbejdsproces). At implementere noget slavisk er ikke programmering, lige saa lidt som at foelge et opskrift er gastronomi. Selv velmente krav ender typisk med at diktere teknisk udfoersel saavel som arbejdsproces.

Loesningen paa offentlige it-projekter maa altsaa vaere enten at opfinde maskiner, der kan omsaette krav til kode, eller at goere brug af den ressource, dygtige udviklere er. Det betyder selvfoelgelig, at man ogsaa maa aendre opfattelsen fra at betragte it-projekter som byggeprojekter til at betragte det som en selvstaendig kategori. Udbydsstrukturen skal derfor aendres radikalt, saa den understoetter inkrementelle leverancer, hvor man loebende kan evaluere baade samarbejde og projektets tilstand.

  • 3
  • 0
Steen Christensen

Der findes rent faktisk nogen "herude" der har fokus på test og kvalitet.

Jeg arbejder for en farma virksomhed, som operere under FDA og GAMP reglerne.

For lige at beskrive et jo for mig som programmør:

  1. Change Control Application bliver skrevet af brugeren
  2. Quality Unit Officer godkender eller afviser ønsket.
  3. Den kommer til mit skrivebord, hvor jeg evt. med hjælp af en "forretningskonsulent" udarbejder løsningen.
  4. Der skrives en Funktionsbeskrivese, som skal godkendes af QU
  5. Jeg udarbejder en Programspecifikation som beskriver hvor og hvordan jeg vil effektuere ændringen.
  6. ps'en godkendes/afvises af en anden programmør
  7. Jeg programmer og laver alpha test/ brugeren + forretningskonsulent laver test plan ud fra funktionsbeskrivelsen.
  8. Min kode unittestes enten manuelt eller programmelt og programgranskes dvs overholder de standarder jeg skal.
  9. Brugeren + Forretningskonsulent tester.

For hvert trin er der nogle dokumenter der skal godkendes inden næste trin kan gå igang.

Når dette nu er sagt, skal det siges at denne adfær bestem ikke kom naturligt til mig :) - jeg er gammeldags EDB assistent, og mente at min kode var selvdokumenterende... og kunne man ikke læse den, var det ikke meningen man skulle.....

Med hensyn til de offenligt projekter, læste jeg for ganske nyligt at helt tilbage i 1968 havde der været i konference, i Nato regi mener jeg, hvor mange klogehoveder der iblandt nogle danskere også, fandt ud af at den måde som vi stadig laver projeter på - big bang - ikke dur.

Vi er rigtig mange kloge mennesker her i danmark, men der er desværre ikke ret mange af os, der kan håndtere et helt Amanda eller DeMars kravspec i hovedet, ej heller holde overblik over sådanne systemer.

Der er kun en løsning og det er at dele opgaverne op.

Det var så mit lille pip :) God week-end til alle der ude

  • 1
  • 0
Nikolaj Brinch Jørgensen

Jeg tror det er væsenligt at vide at det som kunderne betaler for er løsninger der letter deres arbejde, eller gør deres forretning konkurrencedygtig. At vide hvad dette er og omsætte dette er ikke nemt.
Det kræver noget meget dyrbart, nemlig erfaring. Der er rigtigt mange der tror de ved hvad det betyder og hvad det er.
Der er også forfærdelig mange der spilder vores skattekroner med at tro de ved hvad der skal til, og enten undervurdere en opgave, men oftere overvurdere den, og skaber en kæmpe klods som der ikke er brug for.
Erfaring med succesfuldt at realisere store IT projekter er der ikke ret mange der har. Erkændelsen af at der er forskel på at lave projekter i udbud vs. inhouse udvikling, eller produktudvikling, og at det er 3 forskellige størrelser der bør behandles forskelligt, er også noget som oftest overses. Der er mange ting som går igen, men der er også ting som ikke direkte lader sig overføre fra den ene type projekt til den anden.

Derudover er der også den store misforståelse at en rigid process som er dokumenteret, og skaber en masse dokumenter skulle skabe kvalitet. Kunden er ikke interesseret i dokumenter og dokumentation, de er interesseret i løsninger. MS Project filer og oversigter, er der igen ingen der har den store interesse i, udover en projektleder. Har de en værdi? Jeg tvivler, for jeg ser flere projekter der fejler hvor MS Project er anvendt, end projekt hvor det ikke er anvendt. Ligesom jeg ser flere projekter uden MS Project der lykkedes end projekter der lykkedes hvor MS Project var omdrejningspunktet for processen.

Det er ledelsen på begge sider af hegnet, når vi snakker projektudvikling, der skal rettes skarpt på, hvis vi vil ændrer den måde vi forsøger at skabe IT løsninger på, så det går bedre. Det er ikke leverandøren (uagtet at nogen er en smule bedre end andre til at levere), programmeringssproget, værktøjet (nogle værltøjer giver dog fordele frem for andre), testere, kravsudarbejdere, proces-folk og deres rigide procesopfindelse, der egentlig kun tjener til at minimere output fra udviklingen. Grunden til det sidste er den dybe mistillid der er til at det udviklere laver, som udgangs er fejlfyldt og ikke virker. Fejl er spild og skal være undtagelsen.
Og så kunne moderne ledelse med delegering af beslutningskompetence virker hjælpe en del, i stedet for at bygge hierarkier i et væk.

  • 2
  • 0
Lasse Lindgård

@Anne Mette Hass

Når nu du er ansat hos Devoteam, hvorfor spørger du så ikke "in-house" hos Devoteam om hvad der er op og ned på e-Tinglysning? Eller har du gjort det og svaret var at deltagerne ikke var dygtige nok og at det var fordi de ikke var godt nok uddannede?

  • 2
  • 0
Anne Mette Hass

Uddannelse har ALT at gøre med både offentlige og private katastrofer at gøre. Med bedre forståelse af (i dette forum) test hos myndighederne, ville udbudsmaterialet være bedre; bedre forståelse hos modtagerne vill nedsætte behovet for konsulenter (som ikke er kyniske - hvor har du det fra?). Generelt gælder det i IT som i alt andet, at jo mere man ved, jo bedre er man til at tage beslutninger.

  • 0
  • 0
Anne Mette Hass

Det nævnte kursus er på vej i forhold til krav (dog stærkt farvet af Søren Lausens angrebsvinkel); men det hjælper ikke på elendige forhold for uddannelse i test.
Tak for interessen for bloggen! Jeg ser frem til en meget livlig debat!

  • 0
  • 0
Nikolaj Brinch Jørgensen

Generelt gælder det i IT som i alt andet, at jo mere man ved, jo bedre er man til at tage beslutninger.


Og netop derfor har Toyota lært os at vi skal tage beslutningerne så sent som muligt, da det er her vi ved mest. Og ikke som vi gør det idag, specielt i vandfaldsprojekter - tage alle beslutninger up front, også beslutningen at vi ikke tillader os selv at blive klogere i løbet af projektforløbet.

Jeg er ikke sikker på jeg giver dig ret i at det har ALT med det at gøre.
Jeg tror stadigt på at manglende erfaring med realisering af løsninger spiller væsenligt mere ind end uddannelse. Der er så meget man kan uddanne folk til, men det er praktisk erfaring der rigtigt tæller når vi taler om at realisere systemer. Deusden er det jo den efterfølgende drift som der oftest skal tjenes penge på og ikke implementeringen. Regnestykket er derfor lidt større end du giver udtryk for.

  • 0
  • 0
Anne Mette Hass

"Desuden ved jeg ikke hvad du mener vi kan lærer af offshoring."
Jeg mente ikke, at vi kan lære af off-shoring, men at vi kan lære af, hvad de nævnte lande bruger på uddannelse inden for IT. Det er meget mere end vi gør.

Mht. til analogien til ingeniør verdenen synes jeg, den holder hele vejen. Der gør man jo, som man også burde gøre i IT og som nogle (de veluddannede og gode kvalitetssikringsfolk) allerede gør eller prøver at komme til at gøre: have løbende kvalitetssikring (test) hele vejen gennem processen, fra ide over design til de detaljerede tegninger og i selve udførelsen. Sådan er ordentlig test i IT også. Det tager jeg op i næste blog.

"bruger uforholdsmæssig lang tid på det" - i forhold til hvad?

"Måske man skulle pille ved grundlaget for offentlige IT projekter, før man skyder skylden på ITU, DIKU eller andre." Nej, det er derfra den nyeste og bedste viden skal komme!

  • 0
  • 0
Anne Mette Hass

Det er rigtigt at erfaring er vigtigt og tæller rigtig meget - men kun hvis erfaringen er baseret på grundig forståelse af emner = uddannelse, enten hos den, der samler på erfaringerne eller på f.eks. ledere eller mentorer. Hvis erfaringen ikke er det, kan den være værre end ingenting.

  • 0
  • 0
Gert Madsen

Vi kan ikke give Projekt chefer og advokater skylden for at IT systemer ikke kan det brugerne har brug for.

Jeg tror faktiskt at dette er nærmere svaret end man umiddelbart forestiller sig, og også her hvor analogien til lastberegninger i byggeri er relevant.
Hvis ikke de grundlæggende ting er i orden og dokumenteret for en bro eller andet byggeri, så må det ikke tages ibrug.

Hvis de samme ting havde været gældende for de sikkerhedsmæssige aspekter ved tinglysning, NemID mm. så havde de ganske enkelt ikke fået lov at blive idriftsat.
Så havde fiaskoen været synlig, og ville ikke kunne skjules med tvang mod brugerne.
Dette vil også hjælpe til at beslutningstagerne (og advokater, projektchefer mm.) indser nødvendigheden af større faglighed og kvalitet i IT-løsningerne.

Der vil givetvis være en pris at betale i form af mindre funktionalitet, men det vil nok være et godt bytte.

Det er ganske rigtigt at der ofte kommer et hylekor fra IT branchen, hver gang der kommer nogen og kræver højere kvalitet i løsningerne. - Det er vist i øjeblikket lig med Datatilsynet, som hævder at persondata stadig skal omgås anstændigt, selvom om de foreligger elektronisk.
IT branchen adskiller sig ikke fra så mange andre brancher, hvor man heller ikke har meget højere niveau end myndighederne kræver.

Jeg er sikker på at det heller ikke er svært at få nogen til at bygge et faldefærdigt hus, hvis man kunne vælge en lav pris mod at droppe myndighedskravene om bygningsstabilitet. . . .

  • 1
  • 1
Anne Mette Hass

"At implementere noget slavisk er ikke programmering, lige saa lidt som at foelge et opskrift er gastronomi."
Det er fuldstændig korrekt. Men kodning er, at levere det, der bliver bedt om, ligesom at tilberede en ret efter en opskrift. Hvis man ikke gider det, skal man ikke være programmør, men f.eks. designer eller analytiker. Ligesom man ikke skal være sygehuskok, der laver et måltid efter en helt bestem opskrift, fordi det tjener patienten bedst udfra en lægefaglig vurdering, hvis man hellere vil eksperimentere og være gastronom.
Jeg mener, der findes begge typer mennesker - dem, der gerne vil lave reglerne, og dem, der gerne vil følge dem - og der er plads til dem begge. De skal bare ikke tage hinandens job, og tro, at de kan omdefinere rammerne, som det passer dem.

  • 1
  • 2
Mark Gray

Ja, Søren Lausen er vel guru indenfor dette område - på både godt og ondt :).

Muligheden for at få oprettet valgfag i softwaretest foreligger stadig. Jeg tror godt der kan samles studerende nok, hvis blot man lægger fokus korrekt. Jeg mener stadig, at det fag som blev fjernet fra SDT-uddannelsen lå helt forkert, men kan da godt se, at det er ærgerligt, at det ikke eksisterer i en anden form.

  • 0
  • 0
Jon Bendtsen

Mads Tofte har ret. Universiteter skal lære folk at lære. Uddannelse skal være tidsløst, ikke tandløst. Hvordan skulle et universitet i øvrigt kunne uddanne programmører til industrien, når industrien ikke engang selv kan finde ud af hvad den vil? Industrien bruger C, perl, php, asp, python, java, erlang, javascript, C++, .NET, osv. Industrien laver embeddede systemer, web-, desktop-, mobil- og backend-applikationer. Hvordan skulle et universitet kunne nå at uddanne folk til alt det? Den eneste måde er at lære dem at lære, og så må virksomheden selv udføre den konkrete oplæring så den ansatte passer til virksomhedens systemer, viden og behov.

  • 2
  • 0
Lasse Lindgård

Det er så sandt. Det der skal prædikes er livslang læring. Den forskel jeg oplever mellem mine kollegers faglige niveau er ikke baseret på deres oprindelige uddannelse, men derimod på deres intelligens og deres evne og vilje til at holde sig opdaterede.
Man skulle tro at bloggens forfatter ville bekende sig til overstående. Med 30 års erfaring må det meste af den praktisk anvendelige viden være noget der er samlet op, ikke noget man er blevet undervist i.

  • 0
  • 0
Anne Mette Hass

Selvfølgelig bekender jeg mig til livslang læring og til at det er vigtigt at kunne lære! Men det er altså også vigtigt, at man lærer grundlæggende fagdiscipliner på universitetet.

Men man skal ikke nødvendigvis lære at kode! Det kan hvem som helst lære; det er et håndværk. Det man skal lære er teorien bag ordentlig softwareudvikling, dvs. projektledelse, krav, design og TEST!, således at man kan bruge det til at basere sin videre læring og sit arbejde i industrien på. Og den slags undervisning er der langt fra nok af som det ser ud i dag. Et IT universitet, der ikke har et kursus i test er en skændsel.

  • 0
  • 1
Anne Mette Hass

Det er en spændende tanke. Test bør være en naturlig del af alle aktiviteter (studiet og på en arbejdsplads), men jeg mener, det er nødvendigt med et decideret testkursus, så der er tid til at få overblik og forstå alle testaktiviteter og teknikker. På samme måde som for projektledelse; der er et kursus i projektledelse, og så kan man bruge det, man har lært der, som en naturlig del af alle de andre aktiviteter man har gang i.

  • 0
  • 0
Mogens Nørgaard

Ganske enig i dine betragtninger omkring manglende faglige færdigheder, Anne Mette.

Den her artikel/undskyldning blev skrevet i 2010, men der har været underligt tavst omkring den.... Lidt ligesom det studie over Dansk Ulandsbistand, der blev udarbejdet af en - af alle sider anerkendt - ekspert. Konklusionen var, at i nogle tilfælde havde dansk ulandsbistand ikke direkte skadet... mange gange havde den :-). Det siger næsten sig selv, at den rapport blev tiet ihjel, fordi ingen af dem, der tjener KASSEN til daglig på at arbejde for UM, DANIDA og alle de dersens "private" bikse, der kun lever af socialhjælp fra de to store pengetanke, havde interesse i at diskutere konklusionen.

Således også med denne undskyldning:

http://politiken.dk/debat/ECE1046319/undskyld-vi-tog-fejl/

Det er jo også derfor vore programmører og andre IT-eksperter ikke kan måle sig med folk fra f.eks. Østeuropa, der har fået en langt mere stringent uddannelse i de enkelte fag, og derfor kan meget mere og er langt mere kreative. Vores fantastiske, danske egoistselvforståelse af, at vi er bedre til f.eks. "samarbejde", og den slags pladder, er heldigvis efterhånden ved at få det grundskud vi har brug for, så vi kan bygge noget fornuftigt op igen.

Men hvordan bygger vi en faglig undervisning op fra grunden, når lærerne heller ikke kan læse eller stave eller regne, fordi de går direkte fra skolen ud i seminariet, som i den grad er smurt ind i gruppearbejde, temahalløj og alskens snikkesnakke-ting fremfor hård læring? Dét bliver den store udfordring - at boote undervisningssystemet...

Før det sker sker der intet.

Mvh Mogens

  • 0
  • 0
Log ind eller Opret konto for at kommentere