Stroški ali investicija ?

Koliko stane razvoj in izdelava nekega APS? Kakšna je končna cena APS? In kolikšni so stroški vzdrževanja posameznega APS? Ali je takšen način razmišljanja že prešel meje naše države? In če je že v naši okolici, ali je prodrl tudi v SDK?

To je le nekaj vprašanj, na katera skuša ta zapis odgovoriti in nakazati možno smer izboljšanja. Kot osnova so služili tuji članki na to temo v revijah DATAMATION, COMPUTERWORLD in IBM COMPUTER TODAY. Težišče se suče okoli vzdrževanja, predvsem pa kako zmanjšati te stroške.

Spreminjanje APS (Aplikacijskega Programskega Sistema) ali programa s ciljem, da odpravimo ugotovljene napake ali spremenimo njegove funkcije, imenujemo vzdrževanje (angleško: maintenance). Ne ravno najbolje izbrana beseda, saj pri vzdrževanju APS ne odpravljamo okvar ali obrab zato, ker smo pač APS ali program uporabljali, temveč gre za izboljševanje kvalitete in njegov razvoj. V članku je obravnavano le področje vzdrževanja APS in programov, kar pa ne pomeni, da tudi ostala področja delovanja vsakega računskega centra in le računskega centra, ni možno racionalizirati.

Danes se porabi preveč časa za vzdrževanje obstoječih APS, namesto da bi razmišljali o načinu, kako zmanjšati stroške takega vzdrževanja. Nekatere ocene se sučejo do 50% vseh izdatkov v AOP - vključno s strojno in programsko opremo ter plače zaposlenih, torej vse, kar je posredno ali neposredno povezano z vzdrževanjem.

S pojmom strošek razumejo v deželah z razvitimi informacijskimi in računalniško podprtimi sistemi vse tisto kar da končnemu izdelku - APS določeno vrednost.

Vzdrževanje obsega do 75% vseh izdatkov uporabe nekega APS. To pa so sredstva, ki bi se lahko koristneje uporabila pri razvoju novih APS.

Ti visoki razvojni in vzdrževalni izdatki pomenijo, da z zmanjšanjem vzdrževalnega časa veliko prihranimo. Če se za vzdrževanje v resnici porabi do 75% sredstev, časa in napora, bo zmanjšanje vzdrževanja le za 30% podvojilo obseg časa, ki je na razpolago za razvoj. Vzdrževanje se lahko zmanjša tudi z uvajanjem takih postopkov razvoja, ki pozneje zmanjšujejo stroške vzdrževanja.

Proces vzdrževanja spremeni obstoječi APS toda ohranja njegove prvotne in osnovne funkcije nespremenjene. Takšno vzdrževanje lahko

• odstrani skrite in novo odkrite napake,
• poveča učinkovitost,
• prilagodi APS spremembam v okolici,
• spremeni APS z dodajanjem ali brisanjem njegovih delov.

Vsako vzdrževanju APS opravimo v treh stopnjah:

1. Oseba ali osebe morajo razumeti zahtevano spremembo v APS,
2. Zahtevana sprememba mora biti narejena in
3. APS mora biti ponovno pregledan (verificiran), če je sprememba zadovoljila zahtevek za spremembo.

Te tri stopnje težko izvedemo na starem, zastarelem APS, kar seveda pomeni, da je vzdrževanje izjemno zahtevno in težko izvedljivo delo. Če program ni pisan v strukturirani in "top-down" obliki, je precej problematično uspešno in zadovoljivo izvršiti tudi najmanjšo spremembo. Praktično nemogoče pa je pravilno spremeniti eno samo inštrukcijo, če se ne da ugotoviti, kaj sploh program dela in čemu služi.

Področja in načini, kjer in na kakšen način lahko vplivamo na vzdrževanje in stroške, so naslednji:

• Izboljšati dokumentacijo obstoječih APS.
• Ena kvalitetna sprememba namesto večkratnega popravljanja.
• Načrtovanje, kontrola in le neobhodne spremembe.
• Strukturirana oblika in programske tehnike.
• Orodja četrte generacije.
• Luč na koncu tunela.
• APS je premoženje.

Jasno je, da so obstoječi APS osnova za začetek zmanjševanja stroškov vzdrževanja. Seveda pa ti APS niso tudi kandidati za skorajšnjo zamenjavo ali odpis. To pa pomeni, da bodo služili še nekaj časa svojemu namenu in zato bodo tudi deležni določenega vzdrževanja. Ključ je v obstoječih APS in v izvajanju kvalitetnih sprememb, ki bodo vodile k lažjemu (cenejšemu ?) vzdrževanju tudi v prihodnje.

Izboljšati dokumentacijo obstoječih APS

Po nekaterih ocenah porabijo tehnologi med 40 - 65% svojega delovnega časa za študiranje in proučevanje dokumentacije in logike programov.

Tehnolog je delavec RC. Odlikuje ga odlično poznavanje strojne in programske opreme v RC. Suvereno obvlada "orodja" za obdelavo podatkov, ima informacijsko znanje in če pozna podatke, potem sta z uporabnikov idealna sodelavca.

Dokumentacija je najpomembnejše orodje in sredstvo, da tehnolog razume zgradbo in delovanje APS. Toda ta ista dokumentacija ima le neznatno vlogo pri projektiranju in razvoju. Četudi je dokumentacija bila napisana, običajno izkazuje KAJ je bilo narejeno, ne pa KAKO in ZAKAJ je bilo narejeno.

Tehnolog izvrši nedokumentirano spremembo, nato pride drugi tehnolog, ki mora ugotoviti posledice te spremembe. Ker običajno ne zaupa dokumentaciji, skuša razumeti in tolmačiti izvirno kodo in tako tudi delovanje celotnega APS.

Prednost lahko dosežemo že z izboljšanjem dokumentacije. Dokumentiranje APS nam lahko nudi informacijo, ki bo kdaj drugič koristna pri odločitvi, ali je APS že v taki fazi razpadanja, da ga lahko upravičeno pričnemo projektirati in izdelovati na novo.

Zelo pomembno pa je dokumentiranje sprememb na takšen način, da bo v bodoče bistveno olajšalo, izboljšalo in predvsem pocenilo vzdrževanje. Ti vzdrževalci bodo hitro razumeli vsebino in delovanje APS, predvideli morebitne nezaželene in predvsem nepredvidene stranske učinke že pred samo dejansko izvršeno spremembo.

Ena kvalitetna sprememba namesto večkratnega popravljanja

Hitro krpanje je današnja pogubna praksa. Najuspešnejši pri takem krpanju so tisti tehnologi, ki želijo hitro rešiti težave, ne glede na izgube in se čimprej vrniti k svojemu trenutnemu delu - projektiranju ali programiranju novih APS. Tako delo lahko primerjamo z beračevo suknjo, s krpo na krpi, ki takoj razpade, ko popusti šiv prve krpe.

Takšen način vzdrževanja in dela ustvari situacijo, da krpanje napak povzroči nove napake: vedno ko se izvršijo programske spremembe je tudi velika verjetnost, da se pri tem naredijo nove napake.

Razlog je v tem, da se popravljanje izvede hitro, v časovni stiski in brez določenega reda. Z vlaganjem določenega napora lahko dosežemo kvalitetne spremembe, saj le premišljeno izvedeno popravljanje ni povezano z novimi napakami. Na splošno drži, da se z reševanjem najbolj težavnih problemov izognemo dodatnim težavam v bodoče. Nekateri podatki kažejo, da z odpravo 20% najtežjih problemov rešimo morda do 80% bodočih problemov.

Kvalitetni popravki lahko izboljšajo poročila - rezultate za uporabnike. Uporabniki vedno kaj pričakujejo: dobro in slabo. Napačna ali nepopolna sprememba lahko povzroči nemir in nezaupanje uporabnika. Vzdrževanje, tj. sprememba APS, naj bi se izvajala "skupinsko", tj. več sprememb skupaj. Povezovanje posameznih sprememb omogoča njihovo natančno proučitev, podrobno analizo problema, samo spremembo in testiranje.

Uporabnik je oseba, ki uporablja storitve RC. Je odličen poznavalec podatkov, suvereno obvlada ustrezna "orodja" za obdelavo teh podatkov, je strokovnjak na svojem področju in če ima poleg tega še informacijsko znanje, potem je idealen sogovornik tehnologu.

Takšno grupiranje sprememb opozarja uporabnika in tehnologa na možne posledice in vplive na delovanje celotnega APS. Ob tem se skrajša tudi čas testiranja, saj se vse spremembe istočasno preverijo. Več takih posegov lahko postopoma pripelje tudi do večje zanesljivosti APS.

Načrtovanje, kontrola in le neobhodne spremembe

Največji delež stroškov vzdrževanja gre na račun sprememb, ki menjajo osnovno funkcijo APS. Sprememba funkcije je lahko rezultat uporabnikove pretirane domišljije ali pa slabo definiranih zahtev pri projektiranju. Uporabnik si običajno sploh ne predstavlja ekonomskega učinka svoje zahteve za spremembo APS. Najboljši način za kontrolo sprememb in njihovo zmanjševanje je obračunavanje in zaračunavanje stroškov naročniku sprememb.

Zviševanje stroškov pri vzdrževanju je najbolje nadzorovati tako, da ima uporabnik proste roke pri vsaki spremembi in seveda točne podatke, koliko ga bo sprememba stala. Te stroške mu posredujejo tehnologi. Odločitev, ali se ta sprememba izplača glede na predvidene stroške izvedbe spremembe in pričakovane rezultate po taki spremembi, sprejme uporabnik, ki je naročnik in plačnik. Takšen način dela mora zavreči vse tiste želje po spremembah, ki ne predstavljajo popravljane napak, so le "kozmetične" narave, predstavljajo pa kar opazne finančne izdatke.

Tudi vodstvo mora planirati in kontrolirati vzdrževanje. Treba se je odločiti za spremembe, ki so profitne: nek star APS, ki se bo kmalu zamenjal, drug obstoječ APS, za katerega se že izdeluje nov, ali pa tretji APS, ki se bo moral zamenjati, pa za to še ni nič narejenega. Za vse pa uporabniki zahtevajo vzdrževanje in spremembe.

Ključ za zmanjševanje bodočega vzdrževanja je v izdelavi novih APS na način, ki za vsak morebitni poznejši poseg ne zahteva visokih stroškov. To so predvsem sodobni načini in orodja za razvoj in izdelavo APS.

Strukturirana oblika in programske tehnike

Nesporno drži, da se APS, ki je bil razvit in izdelan strukturirano, dvakrat lažje vzdržuje. Pomembno pri tem je, da se že pri projektiranju upošteva morebitno poznejše vzdrževanje. To pa se doseže s ti. strukturiranim načinom razvoja (designa) in same izdelave (programiranje).

Tako izdelan APS omogoča tehnologu kvalitetno izvršeno spremembo v relativno kratkem času in ne nazadnje tudi stroškovno ceneje. APS mora imeti od strojne opreme (hardware) odvisne dele izločene od čiste aplikacijske kode. Podobno velja za odvisnost od operacijske opreme (sistemski software): osamitev takih rutin v ločene interne ali eksterne module v primeru modifikacije bistveno olajša celoten postopek vzdrževanja. Podobno velja tudi za neodvisnost od delovnega okolja uporabnika: razni šifranti podatkov, konstante vezane na določeno lokacija itd.

Tudi dosledna uporaba nekega splošno priznanega in uporabnega standarda za aplikacijski razvoj in programiranje lajša poznejše vzdrževanje. Vsak tehnolog, ki pozna in obvlada takšen standard, lahko z minimalnimi napori spozna in razume delovanje APS. To pa je tudi nujno potrebni osnovni pogoj za kakršnokoli uspešno intervencijo - spremembo. Ne gre prezreti, da z strukturiranim dizajnom in programiranjem izdelamo APS z minimalno zapletenostjo, kar vodi k minimalnim napakam.

Orodja četrte generacije

Sama uporaba aplikacijskih generatorjev - jezikov 4 generacije (Fourth Generation Languages - 4GL) sicer ne odpravlja problemov vzdrževanja, jih pa reducira na najmanjšo možno mero.

Aplikacijski generatorji jezikov četrte generacije lajšajo vzdrževanje zlasti zaradi

• programska koda je brez napake,
• absolutno čista APS koda,
• prisiljena standardizacija in
• avtomatična izdelava standardne dokumentacije.

Poleg navedenega pa 4GL olajšajo sporazumevanje med uporabniki in tehnologi. 4GL omogoča tehnologu hitro izdelavo prototipne rešitve, ki jo je ob skupni analizi z uporabnikom enostavno popraviti in izpiliti. Na tak način iz uporabnika lahko "izvleče" njegove resnične potrebe in želje, ki se jih v projektnem zahtevku le sluti. To pa tudi pomeni manjše možnosti za spremembe ali vzdrževanje v prihodnje. Velja pa opozorilo: uporabnik mora stalno bedeti nad razvojem APS, saj so 4GL še kako pripravni za izdelavo napačnih aplikacijskih in programskih rešitev.

Luč na koncu tunela

Velika večina tehnologov - vzdrževalcev glede na probleme pri vzdrževanju nekako takole:

• intelektualno in tehnično težko in naporno delo,
• nehvaležno, ker ni potrebnih podatkov za uspešno delo,
• brezuspešno, saj se bodo uporabniki vračali z vedno novimi problemi,
• delo brez konca in
• prikrajšani za tehnološki napredek.

Ti razlogi, včasih upravičeni in razumljivi, lahko negativno vplivajo na delo tehnologov. Da bi jih motivirali in tudi zadržali, mora vodstvo poskrbeti za "luč na koncu tunela". To so predvsem dobri in ustrezni pogoji za delo: lasten ekranski terminal ali ustrezen in zmogljiv osebni računalnik, prost dostop do potrebnih računalniških resursov itd. Drug način kako narediti vzdrževanje privlačnejše je sprememba v funkciji vzdrževanja. Avtor določenega APS je vsekakor najprimernejši vzdrževalec le-tega. Toda, ali to želi in hoče? Odvisno od človeške narave, potreb, želja in ambicij. Večini je vzdrževanje odveč. Rešitev je, da se "avtorju" dodeli kot pomoč sodelavca z osnovno nalogo vzdrževanja, "avtor" je tako delno razbremenjen toda vseeno prisoten, mu pa ostane dovolj časa za delo na novem APS, šolanju itd.

APS je premoženje

Tipičen tehnolog porabi zelo malo (recimo 1%) svojega časa za vzdrževanje, nekaj več (recimo 30%) za nove APS, bolj ga zanima, da čimprej spravi svoj APS v obdelavo in tako "požanje" slavo, ker je uspešno ujel rok izdelave, kakor pa da bi "videl" vsaj malo čez svoj nos v prihodnost in pričakovane probleme vzdrževanja. Pri tem mu lahko pomaga tudi vodstvo z ne dovolj stalno in strogo kontrolo nad njegovim delom.

V svetu je izvorna (source) programska vrstica ocenjena med 5 in 50 US$. To spoznanje le počasi zmanjšuje miselnost, da je APS le strošek, prikazan, če seveda je, kot negativna postavka v bilanci podjetja. Toda APS nikakor ni pasivna postavka kakor tudi stroški vzdrževanja niso vedno negativna. Vzdrževanje kot tako nikoli ne izkazuje direktnega profita, je pa bistveno za uspešno delovanje APS, kar pa je profitno.

Dobro premišljeno vzdrževanje veča vrednost APS. To spoznanje pa upošteva APS kot pravo osnovno sredstvo. Zavedati se je treba pomembnosti in vrednosti APS, kaj je to, kako deluje, da ima svojo ceno in vrednost, ki pa se lahko tudi "pokvari". Takrat pa nastopi vzdrževanje s ciljem za kvalitetnim, hitrim in poceni opravljenim delom.

September 1992