IT i operative systemer baseret på COTS programmel

Indledning
Kommando- og kontrolsystemer er i stigende grad baseret på informationsteknologi (IT), der er anskaffet som færdige hyldevarer, COTS. Der er mange grunde hertil, men de væsentligste er ønsker om at reducere omkostninger til udvikling og udrulning, gøre tiden fra ide til færdigt, implementeret system kort og endelig ved at vælge systemkomponenter med en etableret stor brugerskare at få robuste og pålidelige systemer med en vis leveringssikkerhed. Denne artikel er IKKE et budskab om, at man skal holde sig langt væk fra COTS i operative systemer, men et opgør med myterne om velsignelserne ved COTS og en opfordring til at tænke på konsekvenserne for vore (Forsvarets) anskaffelsesprocedurer - og for uddannelsen af vore brugere og teknikere.

Foto: Forsvaret.dk

Med COTS- produkter forstås i denne artikel programmel og maskinel, der er færdigudviklet og som kan anskaffes direkte uden yderligere udvikling hos en leverandør, der i øvrigt leverer mange eksemplarer af produktet. Artiklen kon- centrerer sig om COTS programmel. Sådanne produkter vil normalt være beregnet på at tilfredsstille et så bredt markedssegment som muligt, dvs. det vil ofte have en bred vifte af funktioner. Dette gør, at megen COTS software er kompleks og derfor med mange mulige fejltilstande. Mange COTS produkter er udviklet med større vægt på funktionalitet end robusthed og sikkerhed generelt. Til gengæld er funktionaliteten i COTS produkter ofte billig. Et anerkendt mål for størrelsen af programmel er funktionspoint (function points). Et funktionspoint er kort fortalt en veldefineret klump funktionalitet som f.eks. et skærmbillede eller oprettelse og læsning af en tabel i en database. Et funktionspoint i et COTS administrativt system kan fås for måske $0.20, medens et funktionspoint i et specialudviklet militært system koster $2500 eller mere [ref. 1 og 4].
 
Hvorfor er operative systemer specielle ?
Vore kommando- og kontrolsystemer er beregnet på at understøtte så mange af føringsprocessens komponenter som muligt. Vel vidende, at OODA-loopen kun er en meget overordnet beskrivelse, vil vi her betragte føringsprocessen opdelt i OODA-loopens underopgaver, der er med vekslende kognitivt indhold. De 4 underopgaver i OODA-loopen er som bekendt observer, orienter, beslut og agér (Observe, Orient, Decide, Act). Herudover er der vigtige opgaver som planlægning og disseminering  af  information  (ordrer,  rapporter)  og  styring  af  sensorer  og observatører. Opgaverne er fra det simple håndværksmæssige (observer, ager, disseminer), måske regelbaseret (beslut) til vidensbaseret (orienter, planlæg). Tendensen i IT- støtten til kommando- og kontrol er fra en simpel automatisering af de håndværksmæssige (skills based) opgaver til mere og mere støtte til de regel- og vidensbaserede opgaver. Det betyder, at systemerne indeholder stadigt mere militær semantik og pragmatik. COTS-produkter kan kun forventes at levere rammen for sådanne systemkomponenter. Ud over de militært specifikke funktioner er der krav om korrekthed og hastighed i systemerne. Realtidskravene i kommando- og kontrolsystemer er alene så hårde, at traditionelle administrative systemer har svært ved at leve op til dem. Eksempelvis er distribueret transaktionsbehandling særdeles ressourcekrævende.
Kommando- og kontrolsystemer adskiller sig altså fra traditionelle administrative systemer på tre væsentlige punkter. De indeholder speciel militær semantik, pragmatik og algoritmer; de skal leve op til realtidskrav, og de skal være sikre (pålidelige, robuste, modstandsdygtige over for angreb). De er relativt nemt at finde produkter i den civile sektor, der kan leve op til to ud af de tre krav, men næsten umuligt at finde produkter, der lever op til dem alle samtidig. Det betyder, at der vil skulle foretages væsentlige tilpasninger eller indkapslinger af kommercielt tilgængelige produkter for at de kan leve op til Forsvarets krav til kommando- og kontrolsystemer. Ikke desto mindre kommer vi ikke uden om at anvende en lang række COTS løsninger- det er effektivt, og vi har ikke råd til andet.
 
Om 80 - 20 reglen
En god tommelfingerregel siger, at hvis man kan få opfyldt 80% eller flere af sine krav med et COTS- produkt er det en god ide at anvende det. Ligger opfyldelsesgraden under 80% bør man seriøst overveje en specialudvikling. Omvendt er det for projektledere kendt, at i et projekt anvender man typisk 20% af ressourcerne på at opfylde de første 80% af kravene, medens de resterende 80% af ressourcerne anvendes på blot 20% af kravene. Selvom dette afspejler ideen om at plukke de lavthængende frugter først, skal man være opmærksom på, at det måske netop kun er de lavesthængende frugter, man får gennem et COTS -produkt.
 
Levetidsomkostninger for IT- systemer [ref. 5]
Ved et systems levetidsomkostninger forstås summen af samtlige omkostninger ved at erhverve og drive systemet, herunder omkostninger ved ikke at have systemet til rådighed på grund af svigt. Over systemets levetid er omkostningsfordelingen for COTS programmel forskellig fra specialudviklet software. De væsentligste omkostningskomponenter gennemgås i dette afsnit.
 
Omkostninger ved erhvervelse af programmel Det er relativt nemt at fastlægge en købspris for programmel- den fremgår af en kontrakt. Imidlertid vil fastlæggelse af krav, udbudsforretninger, markedsundersøgelser og produkt- og tilbudsvurderinger udgøre væsentlige bidrag ud over købsprisen. Da COTS- produkter oftest er at betragte som black- boxes er det vanskeligt at bedømme programmellets intrinsikke kvalitet, ligesom programmets effektivitet kun kan vurderes ved sammenligning med tilsvarende produkter eller benchmarking. Ved specialudviklet programmel, kan der stilles krav om en væsentligt større synlighed. Normalt vil COTS være væsentligt billigere at erhverve end specielt udviklet software. Omvendt vil det være  vanskeligt  med COTS uden tilretninger at få opfyldt alle krav. Tilretninger af COTS- produkter kan være meget omkostningskrævende. Et eksempel er tilretning af et geografisk informationssystem (GIS) til specielle analyser eller til at acceptere et specielt filformat. Administrative produkter som SAP R/3 er også kostbare at customisere.
 
Omkostninger ved idriftsættelse
Omkostninger ved idriftsættelse er først og fremmest ressourceforbrug ved uddannelse, træning og ændringer eller tilpasninger af forretningsgange. COTS- produkter vil ofte være nemme at bruge med intuitive grænseflader, men samtidigt også ofte med (alt for) megen funktionalitet. Kan den overflødige funktionalitet ikke slås fra, kan brugeren bringes ud i situationer, hvor programmet enten svigter eller kvalificeret hjælp er nødvendig. Et specielt udviklet programmel vil ofte have en funktionalitet, der er mere præcist tilpasset virksomheden og dens forretningsgange, hvilket gør både uddannelse og indpasning nemmere.
 
Omkostninger ved at programmellet er utilgængeligt
Tilgængeligheden er sandsynligheden for at programmellet er til rådighed og giver korrekte svar på et givent tidspunkt. Hvis vi tillader os kun at betragte programmellet som årsag til manglende tilgængelighed kan det nævnes, at selv i dag er fejlhyppigheden på just afleveret kode, altså kodningsfejl, ca. 8 per 1000 linier kode (svarende ca. til ca. 10 funktionspoint), men for dedikeret programmel er fejl i kravspecifikation og design hyppigere end i selve kodningen. Eliminering af fejl indebærer en lang række ting, som anvendelse af moderne metoder til kravfangst, iterativ udvikling evt. med prototyper, modularisering og anvendelse af komponenter og effektive teststrategier. Ved et gennemprøvet COTS- produkt kan en række af de nævnte fejlmuligheder være ganske små, fordi andre kunder har aftestet produktet. Moderne udviklingsmetoder kan naturligvis også bidrage hertil ved dedikeret udvikling. I sidste tilfælde er kravene både til leverandør og til den købende organisation ganske store.
 
Omkostninger til reparation og udskiftning af SW
Det vil som regel være umuligt at influere reparation af COTS software, da udvikling og vedligeholdelse helt er overladt til leverandøren. Han vil reparere defekter i den takt, der optimerer hans økonomi. Reparation af uhensigtsmæssigheder vil enten finde sted i form af udgivelse af metoder til såkaldte work-arounds, lapper (patches), opdateringer eller helt nyt programmel. Dette kan betyde  omkostninger  i  form  af  mindre  effektivitet  ved  afvikling  af  købers forretningsprocesser, eller i form af køb af opdateringer. I forbindelse med COTS kan der ofte tegnes ved ligeholdelsesaftaler, der typisk årligt beløber sig til 15% af anskaffelsesprisen. For dedikeret SW kan vedligeholdelsen enten være en del af anskaffelsesprisen, eller i form af en licensaftale, der indebærer årlige omkostninger. Igen må det forventes, at omkostningerne for det dedikerede programmel er høje (synlige eller skjulte) simpelthen fordi leverandøren eller egen organisation skal bevare ekspertise for en relativt lille kundeskare. For udbredte COTS- produkter deles denne ekspertise af mange. Det bør endelig bemærkes, at installation  af COTS- produkter ofte er simpel, fordi en stor måske utrænet kundeskare skal kunne gøre det, medens installation af mere specielt programmel kan være en plagsom affære.
 
Omkostninger til opdatering af programmel
Omkostninger til opdatering af programmel er dels de direkte omkostninger ved erhvervelse af opdateringen, dels omkostninger ved implementeringen af den nye version. Da megen moderne SW er opbygget efter Client/Server princippet, kan opdateringsomkostninger gøres lave ved at have tynde klienter, dvs. det meste programmel på de relativt få servere, eller ved at tillade et skub (push) af opdateringerne fra et centralt sted over et net ned på klientsiden. Begge metoder medfører forøgede sikkerhedsmæssige risici. Programmellet skal naturligvis både platformsmæssigt og opbygningsmæssigt være forberedt for disse opdateringer. For dedikeret programmel vil opdateringerne efter en indkøringsperiode ofte være relativt sjældne, medens det for mainstream COTS produkter typisk vil ske med en frekvens af 0.5 per år. Det betyder, at omkostningsfordelingen over et systems levetid er meget forskellig for de to typer af produkter. For COTS produktet er omkostningerne relativt ligeligt fordelt over produktets levetid, medens det dedikerede SW har store omkostninger i initialfasen (erhvervelse). Opdateringer af et COTS- produkt kan medføre følgeomkostninger i form af nye versioner af basisprogrammel som operativsystem og databasesystem.
 
Om omkostninger generelt

Det er meget nemt at fokusere på den forkerte ting, når valget mellem en COTS- løsning og specielt udviklet software skal tages, nemlig den nøgne anskaffelsespris. Den eneste rimelige betragtning er at estimere levetidsomkostningerne og samtidig medregne de indirekte omkostninger til uddannelse, ændring af forretningsgange mv. Tages alle omkostninger med er det ikke muligt generelt altid at pege på den ene type løsninger. Dette gælder specielt for operative systemer, hvor COTS produkter til de specielle militære funktioner er sjældne og med et begrænset marked.
 
COTS og sikkerhed
Området COTS og sikkerhed fortjener megen mere plads end, hvad der kan indpasses i denne korte artikel. Her vil blot blive givet en introduktion til nogle få væsentlige problemstillinger og peget på nogle løsningsforslag. Det bør bemærkes, at operative systemer, er store distribuerede systemer, der oven i købet interopererer på stadigt højere niveau med andre operative systemer. Interoperabiliteten kan gøre disse systemer af systemer sårbare i stor skala.
 
COTS og ondartet kode
Mange COTS komponenter er kodemæssigt utilgængelige og samtidig ganske store. Moderne udviklingsmiljøer som MS NET fylder f.eks. 1.6 GB installeret, operativsystemer op mod 0.5 GB og selv en simpel wordprocessor 100 MB. Et velkendt GIS- produkt består installeret af over 3500 filer. Så selvom COTS komponenter er attraktive er der en række sikkerhedsmæssige risici ved dem ikke mindst i form af ondartet kode, der kan give indeholde trojanske heste, vira, trapdoors, tidsbomber og logiske bomber. Disse forskellige typer af angreb kan det på grund af programmellets kompleksitet være næsten umuligt at undgå-- og måske efter effektueringen svært at fastslå årsagen til. At analysere programmer kan enten gøres statisk, dvs. uden at køre programmet, eller dynamisk ved eksekvering. I praksis er statisk analyse ganske vanskelig, ligesom der kan være ændringer fra den statisk analyserede kode til den faktisk eksekverede (dynamiske pointers, import af kode osv.). Omvendt kan dynamisk analyse ikke detektere problemer i kode, der ikke eksekveres. Derfor er både statisk og dynamisk analyse nødvendig for at detektere ondartet kode. I praksis er dette ikke muligt for meget store, monolitiske COTS- komponenter.
 
Kan man pakke COTS komponenter ind?
For at undgå problemer med COTS og ondskabsfuld kode, er en oplagt løsning at pakke COTS produktet ind. Det betyder, at alle aktiviteter fra produktet moniteres og undersøges for lovlighed i henhold til en sikkerhedspolitik, ligesom produktet eksekveres i et begrænset miljø (en sandkasse), hvor dets eventuelle skadevirkninger kan begrænses. Et godt eksempel på en sådan indpakning findes i eksekveringen af Java Applets, der i denne forbindelse kan betragtes som mobil kode, der eksekveres efter nogle check af en Java Virtuel maskine. Dette kan f.eks. sikre, at en Applet ikke kommunikerer med objekter på andre maskiner, at den ikke kan få andre processer til at gå i stå osv. Moderne systemer i form af distribuerede objekter med veldefinerede grænseflader og eventuelle kontrakter kan give samme muligheder. Af effektivitetsmæssige årsager er denne indpakning endnu ikke særlig udbredt. I princippet kan vi altså godt pakke COTS komponenterne ind, i praksis udnyttes denne mulighed kun meget lidt.
 
Diskussion
Diskussionen om anvendelse af COTS er blevet meget præget af, at det tilsyneladende er et enten eller. I praksis er der selv ved typiske COTS- produkter tilpasninger både af produktet og af organisationen. Et illustrativt eksempel er anvendelse af MS Office i et føringssystem. Det er klart, at f.eks. selv MS Word for at fungere effektivt skal tilpasses. dette vil ske i form af udvikling af dedikerede formularer (skabeloner), beskyttelse af klasser af dokumenter, udvalg af funktioner på værktøjsbjælken og integration med postsystemer, databaser og Web-baserede systemer. For andre COTS- systemer som GIS er tilpasningen væsentlig større. Det betyder, at der alligevel er dedikeret udvikling selv ved anvendelse af COTS, med de vedligeholdelsesmæssige problemer dette giver.
Den moderne udvikling af systemer i form af komponenter og distribuerede objekter giver mulighed for at erhverve systemer, der er en blanding af rene COTS- komponenter og komponenter, der er dedikeret fremstillet [3]. For at opnå denne fleksibilitet kræver det, at vi stiller krav til leverandører af programmel om, at de skal anvende åbne de facto eller de jure standarder, at de opbygger systemet om en fleksibel arkitektur, at de anvender moderne komponentbaseret udvikling, at de undgår tæt kobling af komponenter og derved monolitiske systemer og at både den intrinsikke og den udadvendte kvalitet er i orden. Først da kan vi opnå de fordele i form af skalerbarhed, fleksibilitet, sikkerhed og robusthed som anvendelse af COTS giver mulighed for. Det betyder at kravene til overordnet design og arkitektur for alle systemer, vi anskaffer, bliver nøglen til succes. En forståelse af disse områder er nødvendig ikke kun på leverandørside, men i mindst lige så høj grad på Forsvarets side. De traditionelle IT uddannelser tilgodeser ikke dette behov.
Levetidsomkostningernes fordeling ved erhvervelse og anvendelse af et COTS- baseret system minder meget mere om en form for leasing end om en egentlig erhvervelse. Den teknologiske udvikling vil gøre, at den konstante tilpasning og videreudvikling også af dedikerede systemer bliver nødvendig. For at udnytte teknologiens muligheder vil dette kræve et meget tættere samarbejde med leverandøren (partnering) end vi er vant til i dag. Dette stiller ikke kun nye og store krav til Forsvarets operative eksperter, men også til indkøbsorganisationen.

PDF med originaludgaven af Militært Tidskrift hvor denne artikel er fra:

militaert_tidsskrift_130.aargang_nr.5_2001.pdf

 
Referencer
1.     Capers Jones: Assessment of Software Risks, Yourdon Press, Prentice Hall 1994
2.     Mark R. Vigler and John Dean: Maintaining COTS-based Systems, NATO RTO/IST Symposium on Commercial Off The Shelf Products in Military Applications, Belgium 2000.
3.     Ben Orfali et al: The Client/Server Survival Guide, Wiley 1999.
4.     Capers Jones: Software Assessments, Benchmarks and Best Practice, Addison Wesley 2000.
5.     Norman F. Schneidewind: The Ruthless Pursuit of the Truth about Cots, NATO RTO/IST Symposium on Commercial Off The Shelf Products in Military Ap

Litteraturliste

Del: