Untitled - Försvarets Historiska Telesamlingar,FHT

gamle” gir seg ikke så lett! Odin 1 hadde også brukt maskinspråk i programmeringen.
Planen var også å levere prøvesystemet med det. I første
omgang ble det en utfordring som medførte forsinkelser, som man søkte
å bekjempe med ”mer av det samme”. Omsider innså man, sannsynligvis
var STK først ute, fordi det hadde den mest komplekse oppgaven, at
man måtte gjøre noe med selve SW utviklingsmiljøet. Heldigvis hadde
Sintef utviklet et egnet verktøy som de kalte CHILL-Chipsy. Det tok ett
års tid å omvende systemerere og programmere til strukturert programmering.
”Omvendelsen” må sies å ha vært vellykket. Den var implementert
da TADKOM ble et prosjekt, så spådommer om SW-fremdrift ble
langt mer presise og realistiske da, enn i tiden før 1982. SW gikk fra å
være kunst til å bli ingeniørkunst. Men metodikkutviklingen har vel selv
i dag ikke klart å gjøre SW helt til vitenskap og teknikk? For TADKOM
førte det imidlertid til at SW-utvikling kunne planlegges. Kompilatoren
fra Sintef som ”berget Dir Tidemann/STK” var så god, at man nå kan
se tilbake på nesten 30-generasjoner av sammenhengende programvareutvikling
i FDN og TADKOM. Det synes ganske unikt i global kontekst.
Men som sagt SW, så vel sivilt som militært, fikk aldri det samme preg av
determinisme som brikkeutviklingen. Det finnes ingen Moore`s lov for SW.
Programmering ble mer avhengig av enkeltpersoner, utviklingen av SW
synes derfor å gå i ring, 50 % av utviklingsprosjektene når ikke virksomhetens
mål osv. Men slik er det i kunsten ellers også! Nerdene synes f eks at
Windows system 7 er dårligere enn Win Xp. Sikkert ikke tilfeldig at over
60 % av bevisste brukere hoppet over Win Vista?
Ovennevnte strukturbilde, de strukturkomponenter man valgte, teknologiutviklingen
og en rimelig bra SW-kompetanse hos designerne påvirket
prosjektets tankesett. Prosjektet og HFK hadde et rimelig nøkternt forhold
til SW-utvikling. Man innså f eks behovet for en K2IS P&F, så resultatene
kunne måles mht funksjonalitet og feilfunksjon. Man fant ingen
annen metodikk enn MFT til å håndtere en iterativ og evolusjonær utvikling,
herunder å utvikle divergent kompetanse. Man tok i bruk noe metodikk
som MFTene trengte. M2EE/MACCIS er de mest formelle. Dette
var grunnlaget for det tankesett for utvikling og samarbeid man utviklet
over tid og brukte tverrfaglig i TADKOM/MRR prosjektet.
3