Av Gjermund Dahl og Kai-Erik Uleberg, Norconsult AS

Regneark: Disse fine datafilene som kan være så nyttige, men som også kan skape store frustrasjoner og masse arbeid. De kan brukes til å kombinere store mengder data for å regne ut omtrent hva det måtte være. Med egendefinerte formler og interne miniprogrammer (makroer) finnes det knapt grenser for hva som går an. I mange organisasjoner og bedrifter er den daglige driften fullstendig avhengig av regneark. Regnearkene varierer fra de aller enkleste til store, komplekse systemer. Så var det dette med kvalitetssikring, da. Er det virkelig nødvendig? Og hvordan gjør man det?

En studie fra Oracle, Performance Management: An Incomplete Picture, viser at bedrifter stadig vekk baserer viktige beslutninger på informasjon i regneark. Da er det kritisk at underlaget er til å stole på. For å oppnå det, må alle kritiske regneark være under god kontroll. Det forutsetter full oversikt over deres funksjoner, status og kvalitet, som igjen krever oppdatert dokumentasjon.

Det er menneskelig å feile, noe som da også skjer rett som det er. Om tallmaterialet er stort nok, blir vi trøtte og gjør feil før eller siden. Et regneark blir aldri trøtt. Regneark gjør heller ikke feil hvis det er satt opp riktig. Men hvis det inneholder feil, vil det gjøre den samme feilen konsekvent, uten at vi nødvendigvis oppdager feilen før det er for sent.

Så hvordan kvalitetssikrer man regneark? Vi vil i denne artikkelen gi en oversikt over «beste praksis» fra farmasøytisk industri. Det er en industri med strenge krav til dokumentasjon og testing, inkludert datasystemer, og inkludert regneark.

UTFORDRENDE FILER

Regneark tilbyr kraftige funksjoner med lav brukerterskel. De kan følgelig lages av brukere som ikke har erfaring med applikasjonsutvikling fra før. Noen typiske utfordringer er:

1. Hvem som helst kan utvikle regneark
2. Alle har tilgang til dem, og regnearkene kan enkelt spres via nettverket
3. Regneark kan brukes uten at resultatene dokumenteres eller kontrolleres på andre måter
4. Hvem som helst kan gjøre endringer i layout og funksjoner
5. Kalkulasjoner blir ikke tilstrekkelig testet på forhånd
6. Varierende bruksmiljøer (for eksempel typer datamaskin, operasjonssystem, versjon) mens utviklingen derimot er gjort under bare en enkelt variant av disse
7. Regnearkene møter ikke nødvendigvis de krav som stilles av kunder og offentlige instanser

En profesjonell utvikler forstår ut fra erfaring hvor feil kan oppstå og hvor kritiske de er, og er derfor vant med å gjøre risikovurderinger og kvalitetstester. For en uerfaren bruker er det i teorien ingenting som hindrer henne fra å utvikle regneark med graverende feil. Slike feil kan godt dukke opp når man minst venter det, når det passer dårligst og når konsekvensene blir størst. Her lister vi opp noen typiske feil:

• Feil i egendefinerte formler
• Feil under inntasting
• Mangelfulle eller ingen forhåndstester
• Mangelfulle eller ingen restriksjoner mot feil inntasting
• Utdatert versjon av regnearket benyttet
• Ukjente, mellomliggende formler i skjulte rader og kolonner påvirker resultatet
• Feil tallformat

Noen eksempler
I 2010 publiserte økonomene Reinhart og Rogoff artikkelen «Growth in a Time of Debt». Konklusjonen deres var at når et lands offentlig gjeld overstiger 90 prosent av BNP blir økonomisk vekst vesentlig lavere enn i land med lavere gjeld. Tre år senere demonstrerte akademiske kritikere at dataunderlaget ikke støttet forfatternes konklusjoner. Blant annet hadde Reinhart og Rogoff markert feil celler i et regneark og dermed regnet gjennomsnittet i 15 i stedet for 20 land, i tillegg til selektivt å ekskludere år med høy gjeld i kombinasjon med normal vekst. Det alvorligste var at artikkelen fikk betydelig innvirkning på valget mellom budsjettpolitiske modeller i mange land, og konsekvensene kan vise seg å bli kostbare.

Med andre ord gjør til og med de profesjonelle feil, men heldigvis er ikke alle feilene like alvorlige. Norges Bank klarte å publisere en feil i sin Pengepolitiske rapport II/2011. Tallet på ventet gjennomsnittlig styringsrenteprosent i tredje kvartal 2011 skulle vært 2,39, men ble oppgitt som 2,35. Feilen ble raskt korrigert, og sjansen for renteendring i august det året steg fra 70 til 100 prosent.

Under OL i London i 2012 ble fire øvelser oversolgt med flere tusen billetter. Et av stabsmedlemmene hadde nemlig tastet inn 20.000 i stedet for 10.000 gjenværende billetter i det sentrale regnearket. De plassløse fikk heldigvis billetter til andre øvelser i stedet.

KATEGORIER AV REGNEARK

Det er viktig å vite hvor man skal legge lista. Det er her som ellers: For mye eller for lite blir feil. Regnearkets bruksområde har stor betydning for hvor mye arbeid som bør legges ned i utvikling og testing.

Regneark brukes på ulikt vis:

• som en enkel kalkulator for engangsbruk
• som en erstatning for en tekstbehandler hvor beregninger også blandes inn i teksten
• som en database, eller
• som en mal som brukes gjentatte ganger hvor spennet er fra enkle beregninger til større komplekse systemer med tilhørende VBA makroer eller linker til datakilder fra andre systemer.

Det er ikke nødvendig å legge inn samme innsats i testingen av regneark fra de ulike bruksområdene- Figur 1 viser at innsatsen i testfasen øker med økende kompleksitet i regnearket.

Hvor omfattende bør man så teste? Et kritisk, komplekst regneark, som for eksempel har betydelig innvirkning på et produkts kvalitet, mange logiske funksjoner, lenker til andre datakilder over nettverket, makroer eller egendefinerte funksjoner, bør testes tilsvarende grundig, fordi muligheten for feil øker med kompleksiteten.

Her har typiske bruksområder:

Regneark for engangsbruk

Regneark som database

Regneark som mal

HVORDAN UTFORME ET GODT REGNEARK

Spesifikasjon
Hvis regneark skal utformes som en mal, bør man starte med å lage en spesifikasjon. Denne bør inneholde en beskrivelse av hensikten med regnearket, hvilken arbeidsoppgave det skal benyttes til, en detaljert beskrivelse av kalkulasjoner eller andre oppgaver som skal gjøres, og en nøyaktig beskrivelse av hvordan resultatet skal presenteres (for eksempel antall gjeldende sifre, desimaler og benevning).

Struktur
Et regneark kan lett bli uoversiktlig, og det er derfor viktig å tenke struktur helt fra begynnelsen av. Her en noen tips:

Toppteksten bør inneholde tittel, filnavn og -bane, versjonsnummer, samt en referanse til spesifikasjon eller siste testrapport. Da vil en bruker raskt kunne identifisere regnearket, kontrollere at filen er hentet fra riktig sted, og at riktig versjon benyttes.

Regneark leses på samme måte som man leser en bokside, fra venstre til høyre, rad for rad nedover, og innholdet bør derfor struktureres på samme måte. Da vil regnearket oppleves brukervennlig, og det blir lettere for en annen part å sette seg inn i det.

Dersom utskriften skal signeres, er det en fordel å sette inn egne felter for signatur og dato under sluttresultatet. Her bør det være felter for både den som utfører utregningen, og for den som skal kontrollere i etterkant.

I bunnteksten bør man ha sidetall og totalt antall sider, slik at det blir mulig å kontrollere om utskriften er komplett.

Fargekoder
Bruk av farger kan øke lesbarheten og brukervennligheten til et regneark. Vårt råd er å være ryddig og konsekvent. Hvis det stilles krav til bruk av farger, bør korrekt bruk verifiseres i testfasen.

Datasikkerhet, datavalidering
For faste, kritiske inndata kan det være fornuftig å definere lister over alle aktuelle verdier. Brukeren må da velge fra listen, og muligheten for feil inntasting blir mindre.

Dersom applikasjonen har en innebygd valideringsfunksjon er det en god ide å bruke denne til å sikre riktig formatering av inndata (tekst, tallverdi, antall desimaler, datoformat, og slike ting).

Lås alle celler utenom inndatacellene, og bekreft dette i testfasen. Cellelås og passordbeskyttelse gir en ekstra sikkerhet, men husk at alle som kjenner passordet kan låse opp og endre regnearket uten at det registreres noe sted. Her kan opplæring og arbeidsinstrukser være til hjelp.

Restriksjoner på inndata må brukes med forsiktighet og ettertanke. Slike tiltak skal ikke gå på bekostning av brukervennlighet, snarere støtte den ved å gjøre arbeidsprosessen mer intuitiv.

RISIKOANALYSE

Det bør gjennomføres en dokumentert risikovurdering for regneark som skal behandle forretningskritisk eller produktkritiske data.

Noen grunnleggende spørsmål som risikoanalysen skal besvare, er:

1. Hva er påvirkningen på kvalitet, dataintegritet og business?
2. Hvor stort er problemet om data som er generert av regnearket er feilaktige eller går tapt?
3. Hva er sannsynligheten for at regnearket genererer feilaktige data eller at data går tapt

Punkter som da bør vurderes er:

• Hvor kritisk er regnearket og de data det behandler?
• Kompleksitet eller sannsynlighet for feil. Disse går hånd i hånd. Komplekse regneark har større sjanse for å generere feil. Det enkleste er ofte det beste.
• Modenhet. Det kan være en fordel om regnearket er brukt tidligere.
• Sannsynlighet for å oppdage og korrigere eventuelle feil. De feilene man ikke oppdager i tide er de skumleste feilene.
• Innvirkning på kvaliteten i produktet eller tjenesten som regnearket brukes til
• Innvirkning på dataintegritet (troverdige og intakte data)

Når dette er behørig vurdert og tenkt gjennom, er det klart for å lage en strategi for testing og sikring av data:

• Testomfang: Hva skal testes og hvor omfattende skal testen være?
• Datasikkerhet og -integritet
  • Hvordan sikrer vi at riktig versjon av applikasjonen benyttes?
  • Hvordan håndterer vi filen med malen
  • Hvordan håndterer vi resultatfilene?
• Hvilke tiltak må på plass for å sikre kontroll over endringer? Hvordan unngår vi at planlagte eller utilsiktede endringer skaper feil i regnearket?
• Hvilken påvirkning, positiv eller negativ, har operativsystem og nettverk på datasikkerhet og dataintegritet?

Risikoanalysen dokumenteres på samme måte som alle andre formelle dokumenter, så klart.

TESTING

Når man har definert testomfanget under risikoanalysen, handler det om to ting: Å beskrive testene godt, og å utføre testene riktig

Her må det beskrives i detalj hva testpersonen skal gjøre og hvilke akseptkriterier som skal tilfredsstilles. En god testbeskrivelse deler opp oppgaven i overkommelige og målbare trinn. Hvert trinn kan ha ett eller flere akseptkriterier slik at det blir enkelt å avgjøre om trinnet er en suksess eller ei. Erfaringsvis fungerer det godt med et tabelloppsett med kolonner for testbeskrivelse, forventet resultat, faktisk resultat, samt utfall (for eksempel «Akseptert» eller «Ikke akseptert»).

Det lyder enkelt «å utføre testen riktig», men realiteten er overraskende nok en ganske annen. For å sikre at testene utføres nøyaktig slik de er beskrevet, er det en god idé å bruke en utenforstående som ikke har vært involvert i å utvikle regnearket eller å utarbeide testene. Det er også viktig å avklare kjørereglene på forhånd. Her følger noen eksempler på slike regler:

• Utfør én test om gangen. Arbeid aldri på flere tester parallelt. Gjør deg ferdig med hvert trinn før du går videre til neste.
• Fyll ut underveis. Ikke i etterkant.
• Undertegn og dater når du er ferdig.
• Bruk penn eller annet permanent skriveredskap.
• Skriv datoer på et enhetlig format, for eksempel 1. januar 2014.
• La ikke felter stå tomme når du er ferdig, da dette gir et tvetydig uttrykk. Skriv ganske enkelt «Skal ikke brukes» dersom feltet ikke skal brukes.
• Unngå bruk av gjentakelsestegn.
• Unngå bruk av korrekturlakk. Gjør du en feil, sett en rett og fin strek over, slik at det fortsatt er mulig å lese hva som ble opprinnelig skrevet. Skriv den riktige innføringen ved siden av. Slik ser det penere ut, og det hersker ingen tvil om hva som er feil og hva som er riktig.

Test av beregningsformler
Kontroller at alle cellereferansene stemmer – bruk gjerne innebygde verktøy for dette. Alle egendefinerte beregningsformler, inklusive bruk av logiske funksjoner (IF, AND, OR og så videre) må testes, inkludert håndtering av «ekstremverdier» (0, negative, utenfor grenser). Slik testing gjøres ofte ved å sammenligne med manuelle beregninger.

Egendefinerte makroer eller koblinger mot andre datakilder må også testes.

Avrundning/forkortning
Vær bevisst på hvordan et tall avrundes til et gitt antall desimaler (opp eller ned) eller når det forkortes uten avrunding. Dette bør være beskrevet i kravene og verifiseres i testfasen.

Sikker plassering
Et testet regneark bør lagres på nettverksdisk i en katalog med tilgangskontroll. Lagre gjerne filen som et templat slik at en lesekopi åpnes når regnearket skal brukes. Ferdig utfylt regneark bør lagres i en nærmere spesifisert (prosjektrelatert?) katalog på en nettverksdisk slik at det kan finnes igjen. Filformatet det lagres i kan gjerne være PDF. Det forutsettes her at nettverksdiskene har definerte og fungerende rutiner for sikkerhetskopi.

OPPSUMMERING

Fordi regneark er så fleksible, er det nærliggende å bruke dem til oppgaver de ikke er designet for. Det er viktig å tenke gjennom om regnearket passer til bruksområdet, og eventuelt vurdere å gå over til en annen, mer egnet applikasjon.

For å kvalitetssikre et regneark anbefaler vi denne arbeidsflyten:

• Planlegge
• Spesifisere
• Utvikle / endre
• Risikoanalyse
• Teste
• Gi opplæring
• Ta i bruk

Ved behov for endringer begynner prosessen på nytt. Alle trinn i prosessen dokumenteres.
På denne måten har du god kontroll over viktige data, du har oppnådd et høyere kvalitetsnivå, og du har høynet sjansene dine for å ta riktige beslutninger.

Apple er i forhandlinger om å overta deler av den japanske halvledergiganten Renesas Electronics, nærmere bestemt Renesas SP Drivers. Det melder Nikkei.

Renesas Electronics er en av verdens største leverandører av mikrobrikker. Under en ellers stille dag på Tokyo-børsen hoppet aksjekursen deres på et tidspunkt mer enn 10 prosent.

Apple skal være villig til å betale 50 milliarder yen (2,9 milliarder kroner) for selskapets 55 prosent eierandel i Renesas SP Drivers, som er en joint venture.

Tokyo-baserte SP Drivers utvikler drivere og mikrokontrollere for styring av små og mellomstore LCD-paneler, typisk til bruk i smarttelefoner og nettbrett. Selskapet oppgir å ha om lag 240 ansatte.

Dette selskapet sies å være eneste leverandør av LCD-brikker til iPhone, noe som kan forklare Apples angivelige interesse.

– Renesas har slitt med svak ordreinngang og hard konkurranse fra blant annet Samsung, skriver nyhetsbyrået Reuters i sin melding om oppkjøpet.

Sharp ventes å være villige til å selge sin 25 prosent eierandel i selskapet, ifølge Nikkei. Resten av Renesas SP er eid av taiwanske Powerchip, som står for selve brikkeproduksjonen.

Hvis opplysningene stemmer kan dette bli det største kjente oppkjøpet i Apples historie. Apple er i mindre grad enn andre IT-giganter kjent for aller dyreste oppkjøpene.

Det er fortsatt kjøpet av NeXT i 1996 for 404 millioner dollar (2,4 milliarder kroner), som også markerte Steve Jobs’ tilbakekomst, som representerer det hittil høyeste kjente beløpet de har betalt for et selskap.

Apple har de siste årene sikret seg en rekke brikkespesialister.

Det er snart påske og tid for datatreffet The Gathering (TG) i Vikingskipet på Hamar.

Det ventes 6000 deltakere. Vikingskipet utstyres med nettverk og internettilgang beregnet på 10 000 enheter. Deltakerne stiller med pc-er, mobiltelefoner, nettbrett og spillkonsoller, og de er kresne på bredbånd.

Det interne nettverket må forholde seg til en enorm og konsentrert mengde brukerenheter og samtidig tilfredsstille høye krav til responstid og stabilitet. Som i tidligere år stiller Cisco opp med lånt spesialutstyret for et solid trådløst nettverk i Vikingskipet. Årets utlån verdsettes til rundt 10 millioner kroner. Logistikken rundt utstyret besørges av Atea.

I fjor samarbeidet Eidsiva bredbånd og Blix Solutions om internettilknytningen. Eidsiva bygget ut infrastrukturen med fiberledninger på begge sider av Mjøsa. Opplegget fungerte så bra at teknisk ansvarlig Peter Blakstad i TG nå har undertegnet en fireårsavtale med de to leverandørene. Eidsiva står for forbindelsen til Oslo, mens Blix leverer selv internettkapasiteten. Utstyret som binder de to sammen leveres av SmartOptics.

Nettlinjen til årets TG er på 30 gigabit per sekund, og det skal være mulig å levere ytterligere 10 gigabit per sekund ved behov.

I fjor var kapasiteten opptil 30 gigabit per sekund, og det ble levert opptil 14 gigabit per sekund.

Inne i Vikingskipet kreves 20 kilometer nettverkskabel, i tillegg til over en kilometer med fiberkabel.

Analyseselskapet Gartner melder at slakken som IKT-bransjen har opplevd de siste årene nå ser ut til å være forbi.

Gartner bekrefter sin prognose fra januar: Det ligger fortsatt an til en vekst på 3,2 prosent til 3 771 milliarder dollar i global IKT-omsetning i 2014.

Visepresident Richard Gordon i Gartner sier bedrifter verden over er i ferd med å riste seg løs fra de siste års økonomiske bekymringer, og er igjen i ferd med å investere i IT for å få til vekst.

Når det gjelder forbrukermarkedet, mener Gordon at det går i retning av større volumsalg av ulike typer utstyr, men til lavere pris og enklere funksjonalitet enn i tidligere år.

Brukerutstyr – pc-er, mobiltelefoner, brett med mer – falt med 1,4 prosent i fjor, men ligger an til en vekts på 4,4 prosent i år, til 689 milliarder dollar. Etterspørselen etter de mest avanserte mobiltelefonene dabber av: I modne markeder velges flere midt-på-tre-modeller, mens enkle Android-basert telefoner vinner fram i vekstmarkeder.

På pc-markedet vil leverandørene være henvist til å konkurrere på pris. Trenden går i retning av at bærbare byttes i ultralette modeller, og at nettbrett utgjør et eget marked.

Innen utstyr for datasentraler ventes 2,3 prosent vekst til 143 milliarder dollar, mot 0,2 prosent fall i fjor. Området preges av trendene nettsky, virtualisering og mobilitet. Ellers framhever Gartner betydelig etterspørsel etter utstyr for trådløse nett.

Raskest vekst er innen bedriftsprogramvare: Her ventes 6,9 prosent vekst til 320 milliarder dollar, mot en vekstrate på 4,9 prosent i fjor. Gartner venter størst vekst innen kundehåndtering (CRM), databaseverktøy, dataintegrering og datakvalitet. Ifølge Gordon vil omsetningen innen databaseverktøy overstige omsetningen innen operativsystemer.

I fjor økte omsetningen av IT-tjenester med 1,8 prosent. Gartner tror på en akselerasjon til 4,6 prosent vekst, og en omsetning i 2014 på 964 milliarder dollar. Ifølge Gordon pågår en endring fra planlegging til gjennomføring av prosjekter. Utsiktene er gode for videre økt veksttakt.

Innen telekom er det små endringer, men også der går det fra et fall på 0,5 prosent til en økning på 1,3 prosent.

NetCom kom i dag med ti-på-topp-listen over smartmobiler solgt gjennom selskapets salgskanaler i mars. Det er ikke de store endringene, siden det er de samme ti modellene mars-listen som i februar.

Det som er verdt å bemerke er at to av tre av dagens iPhone-modeller klatrer, mens interessen for den egentlig utgåtte modellen iPhone 5 ser ut til å skrumpe inn.

Samsung dominerer i antallet modeller med på listen, mens Sony har greid å etablere seg i konkurransen med to modeller. Det er ikke så lenge siden listen kun besto av Apple- og Samsung-telefoner.

NetCom bemerker i pressemeldingen at 9 av de 10 modellene har støtte for 4G, eller LTE (Long Term Evolution) som teknologien egentlig heter. På listen er det kun Apple iPhone 4S som ikke støtter mobildata via LTE.

De ti mest solgte smarttelefonene i mars 2014 gjennom NetComs salgskanaler:

1 (1) Apple iPhone 5S
2 (2) Samsung Galaxy S4 LTE+
3 (4) Apple iPhone 4S
4 (3) Samsung Galaxy Note 3
5 (5) Sony Xperia Z1 Compact
6 (7) Apple iPhone 5C
7 (9) Samsung Galaxy S4 Active
8 (8) Sony Xperia Z1
9 (6) Apple iPhone 5
10 (10) Samsung Galaxy S3 LTE

Tallene i parentes er plasseringen i februar.

Foreningen Environmental Entrepreneurs (E2) sendte 7. mars et brev til USAs utenriksminister John Kerry for å be ham avvise prosjektet Keystone XL, en rørledning for å frakte råolje fra oljesandanlegg i den kanadiske provinsen Alberta til Houston i Texas. Brevet ble offentliggjort 1. april.

Brevet er underskrevet av over 200 gründere og næringslivsledere. Blant dem er representanter for Apple (ved handelsdirektør Jim Patton), Facebook (ved «bærekraftguru» Bill Weihl), Google (ved styreleder Eric Schmidt) og Oracle (ved arkitekt Mike Ubell). Listen omfatter også flere investeringsselskap, blant dem Angel VC og Birch Tree Capital, og banker som Credit Suisse First Boston.

Obama-administrasjonen har bedt USAs næringsliv om innspill i den pågående prosessen der det skal avgjøres om oljesandledningen er i nasjonens interesse.

I brevet heter det at Keystone XL ikke er i USAs interesse.

– Oljeledningen Keystone XL er en langsiktig investering i oljesand, et av planetens mest karbon- og vannintensive drivstoffer. Oljeledningen vil øke karbonforurensningen og tilhørende kostnader, og undergrave USAs forpliktelse til å gå over til ren, bærekraftig og lavkarbonenergi, heter det i brevet.

Brevet ble offentliggjort samtidig med en ny rapport fra IPCC, det internasjonale for klimaendring, med særdeles kraftige advarsler om hva global oppvarming vil medføre.

Utenom klimaendring, anfører brevet en rekke økonomiske argumenter mot å bygge oljesandledningen. Underskriverne mener at ledningen vil spille en viktig rolle i å skape «enorm framtidig skade på vår økonomi», samtidig som den bare fører til en nettotilvekst på 35 permanente arbeidsplasser.

Det vises til analyser utført i regi av USAs utenriksdepartement, som går ut på at rørledningen vil tilføre 1,4 milliarder tonn karbonforurensning over 50 år, og at dette vil medføre nære 100 milliarder dollar i økte kostnader for USAs innbyggere, næringsliv og skattebetalere.

Det vises videre til at oljesandindustrien ser på rørledningen som livsviktig for sine utvidelsesplaner, og at disse vil måtte bremses dersom ledningen ikke bygges.

Det er, ifølge Businessweek, kjent at det er motstand mot Keystone XL også helt øverst i Obama-administrasjonen.

Flere innen USAs IT-elite har prosjekter for å sørge for kun fornybar energi til sine datasentraler, og for å oppnå status som «nullutslippsbedrifter».

Oracle kunngjorde denne uken at en ny milepælversjon av den kommende MySQL 5.7 er klar. Den kommende utgaven skal blant annet være utstyrt for å levere bedre ytelse, skalerbarhet og pålitelighet.

I egne tester basert på SysBench Read-only Point-Selects, med 1024 forbindelser, skal MySQL 5.7 på dagens stadium greie å levere 512 000 SELECT-spørringer i minuttet. Dette skal være dobbelt så mange som det man har oppnådd med MySQL 5.6 og tre ganger høyere enn MySQL 5.5.

Det skal være flere årsaker til den kraftige ytelsesforbedringen. Oracles sjef for MySQL-teknologi, Tomas Ulin, sier i et intervju med Infoworld at mye skyldes bedre utnyttelse av systemer med mange kjerner. Ulin sier at deler av kodebasen til MySQL stammer fra 1980-tallet og bærer preg av dette, blant annet fordi den opprinnelig ble laget for systemer med én prosessorkjerne. Det er ikke tilstrekkelig i dag.

– Folk vil ikke bli glade om de oppgraderer fra en 16-kjernet til en 32-kjernet maskin og ikke får noe igjen for det, sier Ulin og gir dermed løfter om nettopp denne typen forbedringer.

I tillegg forteller han at viktige deler av databasesystemet har blitt skrevet om til å være egne moduler med tydelige grensesnitt, noe som skal gjøre det enklere for tredjepartsutviklere å utvide funksjonaliteten.

Bedre utnyttelse av SSD-basert lagring og raskere etablering av forbindelser er annet som nevnes. Dessuten skal bruk av Memcached-pluginen ytterligere kunne doble ytelsen ved lesing.

I intervjuet med Infoworld sier Ulin at arbeidet Facebook, Google, LinkedIn og Twitter nå gjør med WebScaleSQL, bare er positivt for Oracle, fordi disse selskapene da vil enes om hvor de ønsker at de neste forbedringene skal skje. Da kan MySQL-teamet til Oracle forholde seg til én part i stedet for fire, forklarer Ulin.

Målinger
På administrasjonssiden skal databasesystemet samle inn mer informasjon om hva som skjer i minnet til serverne, noe som skal gjøre det enklere for administratorer å sette fingeren på problemer og å finne løsninger til disse.

En ny versjon av MySQL Workbench, 6.1, skal inkludere nye, grafiske diagnoseverktøy som utnytter den nye minnebruk-informasjonen.

Den nye testversjonen av MySQL 5.7, 5.7.4 Development Milestone Release, er tilgjengelig for en rekke plattformer fra denne siden.

Oslo (NTB): Bare 5 prosent av alle selskaper som er notert på Oslo Børs, har god nok sikring mot IT-angrep, viser en test utført av sikkerhetseksperter.

Bare ni selskaper får godkjent i undersøkelsen som sikkerhetsekspertene Einar Otto Stangvik og Per Thorsheim har gjort for Dagens Næringsliv. Dette er DNB, Sparebank 1, DNO, Norwegian, Bouvet, Funcom, Nordic Semiconductors, Eqology og Apptix.

Alle de øvrige 188 selskapene har enten gjort det de kaller grove feil, eller mangler helt enkel kryptering på sine offisielle nettsider.

Testen gjelder såkalte digitale sertifikater – nettsidenes legitimasjon, som skal sikre at uvedkommende ikke kan overvåke informasjonen som sendes til og fra nettsiden. Digitale sertifikater gjør at kommunikasjonen med nettstedet blir kryptert.

IT-selskapet Evry som blant annet har ansvaret for driften av store deler av norske banker, mangler helt slike sertifikater på sine nettsider.

– Denne svakheten rettes opp umiddelbart, forsikrer informasjonsdirektør Geir Remman overfor avisen.

Etter hvert flystyrt dukker det samme spørsmålet opp: Kan svartboksen, enheten som kontinuerlig samler lydopptak fro cockpiten og en mengde annen essensiell informasjon hentes ut av vraket?

Et annet spørsmål er: Hvorfor kringkastes ikke denne informasjonen fortløpende i stedet for – eller i tillegg til – å lagres i en enhet i flyet?

Spørsmålet ble stilt før Malaysian Airlines rute MH370 fra Kuala Lumpur til Beijing forsvant 8. mars i år, og før Air France rute AF447 fra Rio de Janeiro til Paris forsvant 1. juni 2009. Som vi husker tok det to år før svartboksen fra sistnevnte ble lokalisert, hentet opp fra dypet og analysert.

Ifølge Businessweek ble problemstillingen utredet i 2002 av L-3 Aviation Recorders, leverandør av dataopptakere til fly, og en ikke navngitt satellittoperatør.

Utredningen konkluderte med at kostnadene ville være uoverkommelige.

Beregningsmodellen forutså 50 prosent rabatt på selve satellittkommunikasjonen, og la ikke inn utgifter til ny maskinvare om bord i flyene. Svaret, tilpasset en amerikansk flyoperatør med ruter over hele verden, var 300 millioner dollar i året. En svartboks, derimot, er en éngangsutgift på 20 000 dollar per fly. Når den først er på plass, holder den i 100 000 flytimer, eller rundt 30 år.

Kostnad var ikke utredningens eneste motforestilling.

En annen var behov. I tiårene fram til 2002 var det bare to tilfeller der man ikke fant igjen svartboksene fra styrtede jetmotordrevne passasjerfly. Det var flyene som ble brukt i terrorangrepet mot World Trade Center i New York 11. september 2001.

En tredje motforestilling i 2002 var at når alt går bra, er svartboksens data overflødige, og man var redd for opphopning av informasjon man ikke hadde muligheten til å gjøre bruk av. I 2009 inneholdt en svartboks 25 timers opptak av 88 parametere, samt de siste to timers lyd fra cockpiten. I dag er ikke dette en motforestilling lenger. Vi gasser oss i «big data» og har stadig mer avanserte verktøy for å finne nåler av innsikt i høystakk med informasjon.

Nå stilles verden overfor det faktum at dersom svartboksen hadde vært kringkastet, ville man kunne brukt den til å finne vraket av MH370.

Det kan også argumenteres for at man ville skjønt, flere timer før flyte styrtet, at det var på feil kurs. Kanskje kunne man gjort noe i forkant av styrten.

digi.no har henvendt seg til Telenor (satellittoperatør) og til Luftfartstilsynet om denne problemstillingen.

Utover momentene nevnt ovenfor, ble det pekt på at kringkastet svartboksinformasjon må nødvendigvis involvere satellitter, at nødvendig teknologi i hovedsak er tilgjengelig, men at det eventuelt vil kreve en omfattende internasjonal innsats for å koordinere utviklingen av en global standard, for eksempel i regi av den internasjonale organisasjonen for sivil luftfart, ICAO. Tor Iversen i Luftfartstilsynet skriver i en e-post til digi.no at en ny debatt om kringkasting av svartboksinformasjon kan tenkes å komme i kjølvannet av det som hendte med MH370.

Den internasjonale teleunionen ITU skriver i en pressemelding i dag at de vil engasjere seg i arbeidet for å utvikle standarder for framtidig overføring og behandling av dataopptak fra fly gjennom teknologier som «big data» og nettskyen.

ITU er i disse dager samlet til en stor utviklingskonferanse i Dubai, World Telecommunication Development Conference 2014.

Der holdt Sri Ahmad Shabery Check, Malaysias statsråd for kommunikasjon og multimedia, et innlegg der han blant annet sa følgende:

– Jeg tror at data fra fly, også det som inngår i svartboksen, kunne kontinuerlig overføres og lagres i datasentraler på bakken. Jeg oppfordrer ITU til å arbeide med næringen for å utvikle en bedre måte kontinuerlig å overvåke flydata og det som skjer i cockpiten. Med dagens framskritt innen IKT burde det være mulig for oss å innhente og analysere disse dataene selv om vi ikke finner svartboksen.

Statsråden la til at denne «enkle endringen» kunne gitt et annet utfall for rute MH370. Han merker seg at mens kommunikasjonsteknologi har hatt en rivende utvikling de siste fem årene, er svartboksene stort sett uendret de siste 30 årene.

ITUs generalsekretær Hamadoun Touré kom med dette forpliktende svaret:

– Vi må sikre at fly kan spores i sanntid slik at noe så tragisk [som rute MH370] ikke skjer igjen. ITU forplikter seg til å arbeide fram standarder som vil dra nyttet av big data og den mest avanserte formen for databehandling i nettskyen.

Dette ble utdypet av Malcolm Johnson, direktør for ITUs standardiseringsbyrå:

– ITU vil invitere flyprodusenter, leverandører av luft- og romfartselektronikk, satellittoperatører og flyselskaper til å arbeide for nye standarder til å spore fly i sanntid.

Senior visepresident Chris McLaughlin i Inmarsat fulgte opp slik:

– Vi ser fram til å arbeide med ITU for å utvikle en global løsning for å spore fly i kommersiell luftfart.

Inmarsat er, som kjent, satellittoperatøren bak beregningsmodellen som gjorde det mulig å fastslå hvor man burde lete etter vrakrestene fra MH370.

Vi har med andre ord ikke bare fått en debatt, men klare forpliktelser fra ledende aktører om at det må utvikles en global standard for å spore fly i sanntid.

Og motforestillinger rundt kostnad og behov er foreløpig uaktuelle.