Praktično kamorkoli se danes ozremo, nas obkrožajo izdelki in naprave, ki vsebujejo mikroprocesorje, v katerih je neki program (Embeded Software), ki krmili, meri, nadzira, sporoča, prižiga, obvešča, komunicira ... Tako je programska oprema (software) prisotna v otroških igračah, v »karneval kištah«, mikrovalovnih pečicah, DVD in Blue-Ray predvajalnikih, bankomatih, avtomobilih, salamoreznicah, multipraktikih, mešalnikih, brivnikih, depilatorjih, urah, traktorjih, avtomobilih, projektorjih, MP4 predvajalnikih, elektronskih števcih, letalih, podmornicah, vesoljskih ladjah …

In kakšne so posledice, če v teh napravah programska oprema, funkcije zatajijo in ne delujejo pravilno? Če se to zgodi v otroški igrači, je najhujše, kar nas lahko doleti, nekaj joka, slaba volja, pokvarjen večer in zamenjava, nakup nove igrače. Če "crkne ura", potem zamudimo oziroma ne vstanemo zjutraj pravočasno. Če ne dela bankomat, ostanemo brez denarja, redko nas z njim zasuje. Sedaj pa si predstavljajmo rentgensko napravo, bojni raketni sistem nadzvočnega vojaškega letala ali računalniški sistem, ki upravlja s pariško podzemno železnico… Kot lahko hitro in enostavno ugotovimo, ima nedelovanje programske opreme zelo različne posledice, od čustvenih, finančnih pa vse do človeških žrtev.
 
 

Več, hitreje, ceneje, učinkoviteje

Leta 1950 je Peter Drucker, oče sodobnega menedžmenta, dejal: "Živimo v času velikih sprememb". Očitno pa se je s spremembami že pred njim ukvarjal tudi Charles Darwin. Ugotovil je, da ne preživijo največji, najmanjši, najhitrejši, najbogatejši, najlepši…, ampak da preživijo najbolj prilagodljivi.

Visoka integracija elektronskih komponent, napredek informacijsko-komunikacijskih tehnologij, računalništva ter vedno novi in novi materiali narekujejo vedno kompleksnejše multifunkcijske izdelke. Čas za prihod izdelka na trg (Time To Market) je zaradi konkurence vedno krajši, izdelki vsake naslednje generacije so samo še bolj zapleteni in imajo vgrajenih več in več novih funkcij. Na trg prihajajo nepreizkušeni in jih v bistvu preizkuša kupec. Težave imajo avtomobilska industrija, elektronska, računalniška, programska, vojaška… praktično vse. Milijarde dolarjev se letno porabijo za testiranja, še več pa za odpravljanje napak. Naloga današnjega marketinga ni prepričevanje, da nujno potrebujete izdelek, ampak da boste zelo težko shajali brez zadnjega, prenovljenega in boljšega modela. Če vzamemo ne preveč zapleten algoritem z nekaj odločitvenimi zankami in stavki (nekaj deset vrstic v programskem jeziku C) ter z matematično kombinatoriko izračunamo število možnih kombinacij (pet na dvajseto), nato pa rečemo, da bi vsako kombinacijo testirali 1 stotinko sekunde, bi celotni čas testov znašal 30 000 let. Pa dodajmo še različne procesorje (po proizvajalcih in modelih), operacijske sisteme (2000, XP, Vista, Windows 7, Linux …) in njihove verzije. Kar veliko dela, tudi za podaljšano delovno dobo.
 

Kaj je napaka

Napaka je, če računalnik zazna, da tipkovnica ni priključena, in nam prijazno svetuje, naj pritisnemo karkoli, napaka je, da pri vnosu prevelike številke program zmrzne in pomagajo le še trije čarobni gumbki (CTRL-ALT-DELETE), napaka je črn ali moder zaslon s sporočilom, napaka je, da policijski radar izmeri hitrost bagra in izpiše 96 km/h, napaka je 31. februar, napaka je "pijačomat", ki nam "požre" dva evra in nam ne da Coca Cole Zero… Napako je imel Disneyev Levji kralj, ki ni deloval na vseh konfiguracijah, napako plavajoče vejice je imel Intelov procesor P3 (400 milijonov dolarjev je na koncu "nepomembna malenkost" stala podjetje), napako je imel leta 1999 Mars Polander, ki je "trdo pristal", napako je imel ameriški obrambni sistem Patriot v prvi zalivski vojni (28 mrtvih vojakov), napako je imel mercedes A, ki se je prevrnil na streho, napako je imela Toyota, ko se ni dalo hitro zmanjšati hitrosti avtomobila… Vsakdo se je že srečal s kakšno napako v delovanju naprave, programa, sistema … in ima o tem svojo predstavo.

Pri definiciji napake pa ne moremo mimo specifikacije izdelka, ki je dogovor skupine, kako bo izdelek naredila – razvila. Specifikacija zelo podrobno opredeljuje izdelek; v njej je do potankosti določeno, kaj bo nastalo, kakšno bo, kaj bo omogočalo in kako bo delovalo. Ta dogovor je lahko preprost verbalni dogovor, ker pa so izdelki vedno bolj zapleteni, je to kar zajeten dokument. In sedaj za izdelek vzemimo programsko opremo – program. In potem o napaki govorimo, ko program (izdelek) ne dela nečesa, kar specifikacija pravi, da bi moral; program dela nekaj, kar specifikacija pravi, da ne bi smel; program dela nekaj, kar specifikacija ne omenja; program ne dela nečesa, kar specifikacija ne omenja, pa bi morala; program je težko razumeti, težko ga je uporabljati, je počasen, v očeh uporabnika pa ne bo viden kot ustrezen.
 

Zakaj nastajajo napake

Sedaj, ko vemo, kaj napake so, bi bilo zanimivo pogledati še, zakaj do njih prihaja. Presenečeni bomo nad dejstvom, da večina napak ni programerska, vnesena s programiranjem. Neskončno veliko študij je bilo narejenih, od najmanjših projektov pa do največjih sistemov, a rezultat je vedno isti. Vzrok za napake številka ena je specifikacija. Da so ravno specifikacije največji generator napak, je razlogov več. Za zelo veliko programske opreme specifikacije enostavno ni. Drugi razlogi so še, da specifikacija ni dovolj podrobna in konkretna, da se neprestano spreminja in da je v razvojnem timu premalo medsebojnega komuniciranja. Načrtovanje programske opreme je vitalnega pomena. Če ne poteka dosledno in v pravilnem zaporedju, je to največji generator napak (specifikacija 55 %, arhitektura programske opreme 25 %, kodiranje 15 %, drugo 5 %). Naslednji največji vir napak je arhitektura programske opreme (dizajn). To je dokument, kjer razvijalci izdelajo svoj plan za programsko opremo. Primerjamo ga lahko z arhitektovimi načrti za hišo. Do napak prihaja iz istih razlogov kot pri specifikacijah. Dizajn je slab, stalno se spreminja (nove zahteve), premalo pa je tudi usklajen (modularna zasnova). Obstaja stari rek, ki pravi: če nečesa ni mogoče izreči oziroma zapisati, tega tudi narediti ni mogoče. To še posebej velja za razvoj in testiranje programske opreme. Napake, vnesene s kodiranjem, so bližje programerjem in pa tistim, ki imajo neposredni stik s kodo. Vzroki zanje so zapletenost programske opreme, slaba dokumentacija (posebej pri kodi, ki je bila nadgrajena ali popravljena), terminski pritiski in enostavno "neumne napake". Dostikrat slišimo programerja: "Seveda, to bi SW moral delati! Če bi mi to kdo povedal, tega ne bi tako napisal!" Zadnja kategorija obsega še vse, kar ostane, ki pa ponavadi znaša le 5 % vseh napak, komaj omembe vredno.

Stroški napak

Programska oprema se ne pojavi kar čudežno. Navadno je to metodičen, planiran razvojni proces. Zlato pravilo razvojnega procesa je KISS, pa ne poljub, ampak Keep It Simple Stupid (stvari naj bodo enostavne in lahko razumljive, tako izvajalcu testiranja kot tudi drugim udeležencem IT-razvojnega procesa). Napake je mogoče odkriti v vseh razvojnih fazah, a se stroški bistveno razlikujejo po tem, kdaj je napaka odkrita. Številke prikazujejo, kako stroški odpravljanja napake časovno naraščajo, v prvih fazah so najnižji, potem pa nas "kresne" vedno močneje, logaritmično! Napaka, odkrita v specifikaciji, nas stane 0,1 €, v dizajnu 1 €, če je odkrita v kodi 10 €, pri testiranju 100 €, ko pa je izdelek že zunaj podjetja, pa je to drag "špas", več kot en "cankar" (1000 €). Kot primer vzemimo igrico Levji kralj (Walt Disney). Če bi že v začetku nekdo raziskal, kateri računalniki so popularni, in načrtoval (specificiral) uporabo in testiranje produkta tudi na teh računalnikih, bi bil strošek zanemarljiv. To se ni zgodilo. Napaka je bila zgrešena v vseh fazah in prodanih je bilo več tisoč zgoščenk igrice. Disney je na koncu plačal telefonsko uporabniško podporo, reklamacijo programske opreme, zamenjavo zgoščenk, popravek napake, ponovno razhroščevanje in testiranje. Povsem enostavno je zapraviti ves dobiček, ki bi ga sicer imeli, če se napaka zgodi pri uporabniku.
 

Kaj je testiranje

Testiranje je aktivnost, ki je tesno povezana s celotnim razvojnim procesom izdelka (programske opreme) od začetka do konca. Prisotno je pri definiciji ciljev, pri izvajanju planov, preverjanju rezultatov in ukrepanju ob napačnih rezultatih. Smisel testiranja je predvsem v tem, da dokaže, da izdelek ustreza specifikaciji. Testiranje je torej proces iskanja napak oziroma vsaka aktivnost, katere osnovni cilj je ocena, ali izdelek ustreza na začetku podanim zahtevam. Pojmujemo ga lahko kot sestavni del nadzora kakovosti celotnega razvojnega cikla, pri katerem moramo poskrbeti, da je rezultat vsake razvojne faze kakovosten in v skladu z globalnimi cilji podjetja.
 
 

Vrste testiranj in orodja

Poznamo zelo veliko testnih pristopov, nemogoče pa je pretestirati vse. Izdelek (napravo, program, programsko opremo v mikroprocesorju…) lahko obravnavamo kot črno škatlo (black box testing), kar pomeni, da določimo vhodne parametre in gledamo, kaj se dogaja na izhodih naprave, dogajanje v škatli nas ne zanima. Drugače je pri testiranju bele škatle (white box testing). Tu je škatla (naprava) "prozorna" in gledamo vanjo, zanima nas, kaj se dogaja, gledamo izvajanje kode, postavljanje parametrov, merimo veličine… Potrjujemo lahko delovanje funkcij (test to pass) ali skušamo napravo destabilizirati (test to fail). Testiramo lahko statično ali dinamično, lahko testiramo že samo specifikacijo, ko izdelka sploh še ni oziroma obstaja le na papirju. Zadnje se izkaže za zelo učinkovito. Programsko opremo testiramo na različnih platformah in v povezavi z različnimi programi, testiramo konfiguracije, združljivost, uporabnost… Testiranja jezikovnih variant se lotimo drugače kot testiranja domače strani ali podatkovne baze neplačnikov odvoza komunalnih odpadkov… Če testiramo dostopnost domače strani in skušamo ugotoviti, ali deluje, če po njej brska 30 000 ljudi, lahko najdemo 30 000 posameznikov, ki bodo ob določeni uri brskali po naši strani… Nemogoče. Obstajajo testna orodja, ki to simulirajo. Na voljo je ogromno testnih orodij, ki znajo pregledovati kodo, ugotavljati slepe zanke in druge nepravilnosti, ugotavljati skladnost (Conformance Test Tools), optimizirati kodo, simulirati uporabnikove akcije… vso noč neutrudno izvajati teste in zapisovati rezultate. Pomembnejši proizvajalci testne opreme so National Instruments (LabView), IBM-Rational (Robot, Visual test, Rhapsody …), Agilent Technologies, Empirix … Bistvo testiranja je neskončno množico kombinacij prevesti v končno minimalno število najverjetnejših vzorcev, ki bodo nastopili pri uporabniku, in to temeljito preveriti.
 
 

Model zrelosti razvojnega procesa

CMM pomeni Capability Maturity Model in je industrijski standard, ki ugotavlja in meri zrelost razvojnega procesa podjetja ter zagotavlja ukrepe za izboljšanje kakovosti programske opreme. Razvila sta ga Software Engineering Institute – SEI in Carneige Mellon University pod nadzorom Ministrstva za obrambo (USDoD). Posebnost modela sta njegova generičnost in možnost uporabe v vseh vrstah podjetij, od največjih multinacionalk pa do samostojnega konzultanta ali garažnega d.o.o.-jčka.

Zrelostna raven razvojnega procesa opisuje pet ravni (začetno, ponovljivo, definirano, upravljano, optimizirajočo raven), ki predpisujejo tudi ukrepe za prehod v naslednjo – višjo raven. Na začetni ravni je proces naključen in pogosto kaotičen. Uspeh projekta temelji na herojstvu in sreči. Ni neke posebne prakse pri načrtovanju, nadzoru in kontroli. Nemogoče je predvideti čas in stroške razvoja programske opreme. Testiranje je zgolj naključno, kakršno je tudi vse drugo pri procesu. Ponovljiva raven je najbolje opisana kot projektno razmišljanje. Spremljajo se stroški projekta, termini, funkcionalnost in kakovost. Upoštevajo se izkušnje iz prejšnjih, podobnih projektov. Občutiti je disciplino. Uporabljena je osnovna praksa testiranja, kot so testni plani in primeri. Na tretji ravni (definiran proces) se razmišlja organizacijsko, ne le specifično projektno. Skupne aktivnosti vodstva in inženirjev so standardizirane in dokumentirane. Standardi so preizkušeni in uporabljeni na različnih projektih. "Pravila igre" niso opuščena, ko gredo stvari "stresno". Testni dokumenti in postopki so pred testiranjem pregledani in potrjeni. Testna skupina je neodvisna od razvijalcev. Na podlagi testnih rezultatov se odloči, kdaj je programska oprema primerna za izdajo. Na četrti ravni (upravljana raven) je organizacijski proces pod statistično kontrolo. Kakovost proizvoda (programske opreme) je vnaprej kvantitativno opredeljena in programska oprema ni izdana, dokler cilj ni dosežen (npr. manj kot 0,5 napake na 1000 vrstic kode). Optimizirajoča raven se stalno izboljšuje. Stalno se uvajajo novi, boljši procesi in tehnologije, rezultati se merijo. Malenkostne in revolucionarne spremembe se uvajajo za doseganje boljše kakovosti. Ko je že vsakdo prepričan, da je doseženo najboljše, se starta ponovno in zopet je dosežena naslednja raven izboljšav.

 

Izobraževanja

Revije

Avtor