Projekt POLIFEM

V stari grški mitologiji so bili Kiklopi (samo ime pomeni "okroglo oko") velikani z enim samim očesom v glavi. Pričevanja o njihovem življenju se precej razlikujejo:

• Heziod govori o treh kiklopih - Arg, Bront in Sterop naj bi bili otroci Urana in Geje, pozneje Zevsovi predani služabniki; iz maščevanja jih je ubil Apolon
• Homerjevi kiklopi naj bi živeli v pečinah otoka, ki so ga pozneje identificirali kot Sicilijo; med njimi je najbolj znan Polifem, ki je ujel Odisejevo posadko.

Pravljic se nadaljuje, zapleta, mi pa se vprašamo, kaj ima pri vsem SDK. Na prvi pogled nič, z malo domišljije in kančkom potrpljenja pa morda le nekaj. Poglejmo!

Že dolgo časa obupani delavci funkcij zunaj računalniške obdelave podatkov so prijetno presenečeni s spremembami v načinu obveščanja o novih APS-ih, ki so jih izdelali delavci SROP-a; poleg rednega obveščanja z dopisi smo priče obširnega oznanjevanja novih projektov tudi v »Obvestilih«.

Da bi spoznali za kakšno spremembo gre, vas bom na kratko seznanil s kronologijo dogodkov, ki so vezani s to temo in katere lahko dokumentiram. Na sestanku pomočnikov direktorjev in vodij ROP-a dne 17. 6. 1988 je bilo sklenjeno, med ostalim, da se izdela popis programov za osebne računalnike. To zaradi tega, ker vse podružnice niso bile seznanjena s tem, da so jim že na voljo določeni programi.

Dne 08. 09. 1988 so podružnice prejele pregled programov za osebne računalnike, s pripombo: »Uvajanje programov in usposabljanje delavcev bo zagotovila funkcija, za področje dela katere se programi uporabljajo, vzdrževanje programov pa mora v sodelovanju s funkcijo zagotoviti dobavitelj ali avtor programov. Pri instaliranju vseh programov in osebnih računalnikov bo po potrebi sodeloval sektor ROP
centrale.« Pripomba je lahko razumljiva, ker na seznamu programov ni bilo kompletnega programa, ki bi bil izdelan v SROP-u.

Na sestanku pomočnikov direktorjev in vodij ROP-a dne 16. 2. 1990 je bilo sklenjeno, med ostalim, da »Sektor za računalniško obdelavo podatkov bo tekoče obvešča] podružnice o projektih v razvoju.«

Dne 13. 03. 1990 so podružnice prejele katalog aplikacijskih programskih sistemov na osebnih računalnikih v SDK Slovenije in interno navodilo za arhiviranje le-teh. Katalog vsebuje APS-e, ki so izdelani v sektorju ROP centrale. V spremnem dopisu predlagajo, da vse podružnice formirajo podobne kataloge in sprejmejo tak način arhiviranja ter tekoče obveščajo SROP o morebitnih spremembah.

Dne 23. 05. 1990 so podružnice prejele »informacijo o novih programih za osebne računalnike«, v kateri se omenjajo štirje novi programi, ki sicer niso končani ampak so že v razvoju ali v tesni fazi (izpisovanje virmanskih nalogov, evidenca sodnih sklepov, evidenca telefonskih nalogov, evidenca trakov). Dne 26. 09. 1990 so podružnice prejele opisni listič za APS ČEKI, ki je izdelan po zahtevku podružnice Ljubljana in v podružnici tudi verificiran. Na koncu, »last but not least«, APS ARGUS, ki dopolnjuje to vse bolj svetlo podobo in o katerem poroča gospod XY.

Eppur si muove !

Zelo mi je všeč, da so v Službi poleg pridnih delavcev tudi duhoviti delavci, ki so sposobni ljudem približati še tako tuje področje kot je računalništvo. Gospod XY gotovo sodi med njih. Ker nobena stvar ni tako dobra, da ne bi bila lahko boljša, si upam opozoriti na nekaj pomanjkljivosti v njegovem tekstu.

Osebno menim, da je namen teksta »Projekt ARGUS« predstavitev novega APS-a ARGUS. Avtor teksta, kljub svojim škotskim prednikom, ne varčuje (s prostorom in besedami):

Od tukaj naprej je zapisano tudi v originalu malce zmedeno, pa vseeno!

Podatki, ki jih JUTRANJI PROGRAM vzdržuje se nahajajo v naslednjih podatkovnih zbirkah - datotekah:

Na glavnem računalniku se starta JUTRANJI PROGRAM, sledi tipična zaporedna (batch) obdelava:

Vidimo da je osnovna naloga JUTRANJEGA PROGRAMA vzdrževanje vseh podatkov v ustreznih podatkovnih zbirkah. To vzdrževanje obsega:

• odpiranje imetnikov računov - VP (vrsta posla) 9,
• popravljanje podatkov imetnikov računov - VP 1,
• zapiranje posameznih imetnikov računov - VP5

Konkretno pa se v SDK Ljubljana uporablja naslednja strojna oprema:
centralna procesna enota IBM 4341 z 8 MB glavnega spomina,
zunanji spomin na diskovnih enotah IBM 3375 in 3380 ter ustrezne kontrolne enote - skupaj 16,4 GB...

Programska oprema pa ja naslednja:
celoten računalniški sistem kontrolira operacijsko programje VM/SP, ki omogoča delitev strojne opreme različnim uporabnikom kot zaključne celote, VSE/SP je osnovni operacijski sistem, ki omogoča...

Do leta 1990 delavci referata RIR, ki je lociran v Ljubljani, Titova 66, računski center pa na Cankarjevi 18, niso imeli nobene računalniške opreme. Letos pa so dobili osebni računalnik IBM AT z opremo:

• 1 MB spomina
• 30 MB trdi disk
• 1,2 MB disketna enota
• tiskalnik

Konec  zmedenega besedila !

Šele na koncu nam pove kaj (bo) omogočal) novi APS. Tako smo veliko več zvedeli o delovanju jutranjega programa, hardware-ski konfiguraciji SROP-a, sistemskem in aplikativnem software-ju, ki ga uporabljajo delavci SROP-a, osebnem računalniku v oddelku RUDS (RIR) podružnice Ljubljana, kot o novem APS-u.

Spoštovani gospod XY, stari nemški pregovor pravi: »Preveč lepila slabo drži«.

Če pa je to vse, kaj se o APS-u ARGUS lahko pove v tem trenutku (in to ni nič posebnega, ker že dolgo obstajajo transakcije s podobnimi funkcijami), potem »Projekt ARGUS« dejansko lahko imenujemo »Projekt POLIFEM«.

Sedaj smo ponovno pri mitološkem enookem velikanu!


November 1990

Kritično o neki obdelavi

Ko sem prelistal številko ugledne slovenske gospodarske revije, se mi je vzbudila asociacija na šolske naloge iz slovenskega in tujih jezikov v gimnaziji pred mnogimi šolskimi reformami. Tedaj smo pisali dve vrsti poprav šolske naloge: tisti z nalogami, kjer je bilo manj rdečih popravkov, so jo napisali kar na rob, ostali, pri katerih je bil profesor z rdečo barvo bolj radodaren, pa so nalogo napisali ponovno, tokrat pravilno. Od tistih časov mi je ostala navada, da si med branjem zapišem kako krajšo opazko kar na rob berila.

V omenjeni številki je kot že več let doslej izšel seznam 200 največjih delovnih organizacij, povečan še za nadaljnjih sto, v naši republiki v letu 1984. Revija se je potrudila in k seznamu objavila komentar, resda nekoliko skromen glede na priliko, ob kateri je objavljen, ampak dober namen je treba ceniti. Komentarju je dodan tudi diagram, najbrž v skladu z rekom, da slika pove več kot tisoč besed. Zdi se, da ta slika ne pove toliko, ker je »za lažje razumevanje« dodanih še »nekaj pojasnil«, kar kaže na to, da nemara diagram ni pravi, ali pa na to, da tudi slika ne pomaga, kjer ni kaj povedati. Z drugimi besedami rečeno, kjer ni, še vojska ne vzame.

Sam seznam je mogočen in prav lepo ga je prelistati. Človeku vzbudi dober občutek, da Slovenija v nekaterih pogledih le ni tako majhna in da ima kaj pokazati. Vendar pa je dovolj majhna, da vsakdo od nas bliže pozna katerega od teh 300 največjih ali pa vsaj koga, ki združuje delo v kateri od teh delovnih organizacij. To seveda da voljo in moč, da nekdo prelista dolgi seznam bolj počasi in pazljivo. Ob takem listanju pa si pazljivi bralec hočeš nočeš napravi na rob kako oznako, kak klicaj, pa tudi kak vprašaj.

Prvo presenečenje so delovne organizacije, ki ne spadajo med gospodarske organizacije. Med 300 največjimi se tako prikažejo ugledna zdravstvena ustanova, znan univerzitetni inštitut in nemara še kaj podobnega. Na prvi pogled ti namreč ne bi sodili v to druščine, vendar se po premisleku človek potolaži, če so veliki, so veliki, pa tudi če niso iz gospodarstva. Vpraša pa se, koliko je še velikih, ki tudi niso s tega področja, pa jih ni na seznamu.

Drugo bolj neprijetno presenečenje so delovne organizacije, ki so notorični viri problemov zaradi negativnih rezultatov poslovanja, pa se vseeno znajdejo v družbi uglednih. Na seznamu je dolenjski velikan avtomobilske industrije, gorenjska tovarna elektronskih izdelkov in bogve koliko takih še, ki nam prav tako niso v čast in ponos. Potem človek neha listati po seznamu in pogleda, od kod taki podatki. In zagleda na vrhu tabele dokaj skrit napis, s katerim se je ugledna revija, ki je podatke objavila, zavarovala: podatke za seznam 300 največjih so pripravili in obdelali pri SDK - centrala za Slovenijo. Na tem mestu interes za tabelo neha biti neoseben in zaskrbi me za ugled organizacije in delovne skupnosti, kjer združujem delo, saj mi ne more biti vseeno, kakšne podatke posredujemo za objavo. Potem se pozanimam, kako je mogoče, da izdelamo tak seznam in izvem (kakor že večkrat doslej), da je seznam izdelan popolnoma tako, kakor je bilo zahtevano.

Tedaj sem se (kakor že večkrat doslej), spomnil na članek, ki je pred več kot desetimi leti izšel v neki ameriški znanstveni reviji, govori pa o kandidatu, ki bi bil za svoje sicer izkazano odlično znanje fizike kmalu padel na izpitu samo zato, ker profesor ni dovolj točno izrazil vprašanja. Ker je zgodba poučna tudi za naše prilike, zasluži, da jo preberemo tudi mi.

Takole je:

Pred nekaj časa me je poklical kolega in me vprašal, ali bi hotel biti razsodnik za oceno izpitnega vprašanja. Nekega študenta se je bil pravkar namenil oceniti negativno za njegov odgovor na vprašanje iz fizike, študent pa je vztrajal, da bi moral dobiti najboljšo oceno in da bi jo bil tudi dobil, če bi se ne zarotil proti njemu cel sistem. Profesor in študent sta se strinjala, naj zadevo presodi nepristranska oseba, in sta izbrala mene.

Šel sem v kabinet svojega kolega in prebral izpitno vprašanje: »Pokaži kako je mogoče določiti višino stolpnice s pomočjo barometra.«

Študent je odgovoril: »Nesi barometer na vrh zgradbe, priveži nanj dolgo vrv, spusti barometer do ulice, potem ga dvigni k sebi in meri dolžino vrvi. Dolžina vrvi je enaka višini stolpnice.«

Poudaril sem, da ima študent trden argument v svoje dobro, ker je odgovoril na vprašanje popolno in pravilno. Po drugi strani pa, če bi se mu to priznalo, bi lahko dobil visoko oceno iz fizike. Visoka ocena naj bi potrjevala obvladanje fizike, na kar pa odgovor ni kazal. Predlagal sem, naj študent še enkrat poskusi odgovoriti na to vprašanje. Ni me presenetilo, da se je moj kolega strinjal, pač me je presenetilo, da se je strinjal tudi kandidat. Dal sem mu šest minut časa, da odgovori na vprašanje, obenem z opozorilom, da mora biti iz odgovora razvidno določeno znanje fizike. Po petih minutah ni napisal še ničesar. Vprašal sem ga, ali želi odstopiti, vendar je odvrnil, da ne. Imel je mnogo rešitev tega problema; pravkar je razmišljal o najboljši. Opravičil sem se mu, ker ga motim, in dejal, naj prosim kar nadaljuje. V naslednji minuti je izročil odgovor, ki je bil tak:

Nesi barometer na vrh zgradbe in se nagni čez rob strehe. Spusti barometer in meri čas padanje s štoparico. Potem izračunaj višino stolpnice po formuli

Tedaj sem vprašal kolega, ali želi on odstopiti. Pristal je in dal sem študentu zelo visoko oceno. Ko sem zapuščal kabinet svojega kolega, sem se spomnil študenta reči, da ima še druge odgovore na to vprašanje, zato sem ga vprašal, kateri so ti odgovori. »Hm, ja,« je dejal študent. »Mnogo načinov je za določitev višine visoke zgradbe s pomočjo barometra. Na primer, lahko bi vzeli barometer, ko sije sonce in izmerili njegovo višino, dolžino njegove sence in dolžino sence stolpnice in s pomočjo enostavnega razmerja določili višino zgradbe.« »Lepo,« sem rekel, »kaj pa drugi?«

»Da« je rekel študent. »Je še zelo osnovna metoda, ki vam bo ugajala. Pri tem načinu vzamete barometer in začnete hoditi po stopnicah. Ko se vzpenjate, označujete dolžino barometra vzdolž stene. Potem preštejete število oznak, kar vam da višino stolpnice v barometrskih enotah. Zelo direktna metoda.

Seveda, če želite bolj zapleten način, lahko privežete barometer na konec vrvice, ga zanihate kot nihalo in določite "g" na ulici in na vrhu stavbe. Iz razlike med obema vrednostma za "g" lahko načelno izračunate višino stavbe.

Končno je zaključil, »je še mnogo drugih načinov za rešitev tega problema. Verjetno najboljši,« je dejal, »je ta, da vzamemo barometer v klet in potrkamo pri hišniku. Ko se oglasi, mu rečemo takole: »Gospod hišnik, tule imam dober barometer. Če mi poveste višino te stolpnice, vam dam ta barometer!«

Tedaj sem vprašal študenta, ali res ne pozna konvencionalnega odgovora na to vprašanje.

Zgodba se tu zaključi z razmišljanjem študenta o razmerah in poučevanju na njegovi univerzi. Mi pa se lahko iz te zgodbe naučimo nečesa drugega: ne smemo pričakovati, da bomo na osnovi površno definirane naloge dobili izdelek, ki bo ustrezal vsem našim skritim željam. Če smo nad izdelkom razočarani ali če ni to, kar smo pričakovali, najprej premislimo, kaj smo storili, da bi dobili to, kar smo želeli.

Čim bolj grobo je izražena naloga, temveč je rešitev, ki ji ustrezajo. Da bi se v prihodnje izognili robnim ali celo popolnim popravam, bi bilo prav, da zahtevo specificiramo, kolikor najbolj točno moremo.


September 1985

Problem predstave o računalniških strokovnjakih

Januar 1985

Pri opravljanju svojega dela smo z njim običajno tako okupirani, da ne pomislimo, kaj o našem delu in nas samih mislijo drugi. Da bi se vživeli v svoje sodelavce in vsaj poskusili nase pregledati z njihovimi očmi, je še redkeje. Praktično izključeno pa je, da bi se vživeli v kožo uporabnikov in ugotovili, kakšna je njihova predstava o računalniških strokovnjakih. Največ, kar v tem pogledu navadno naredimo, je to, da jih razumemo, če nas ne razumejo. Živi in pusti živeti. V zadnji številki revije Datamation je izšel članek, ki je v tem pogledu prav razveseljujoč, ker daje priliko, da pogledamo, kako nas vidijo drugi, daje tudi možnost, da se spremenimo, če menimo, da nismo taki, kakršni se jim zdimo. Zato je zanimiv tudi za nas.

Eksperti ocenjujejo, da je programiranje računalnikov eden od najperspektivnejših segmentov za poslovanje. Do konca desetletja bo v ZDA programerjem na voljo več kot 25.000 delovnih mest. Kaj točno programer dela? Kaže, da ima o tem vsak drugačno predstavo. Tukaj je nekaj raznih vtisov, odvisno od tega, kje kdo sedi.

Programer - kakor se vidi sam

Je križanec med dr. Spockom in Clintom Eastwoodom - inteligenten, logičen, vendar hladen in preračunljiv, ne eden od tistih, ki izgubljajo čas z ničevimi čustvi. Še kot študenta so te iskali po študentskem domu, da si pomagal razvozlati pomen gumbov na mikrovalovni pečici, prenosnem telefonu, video kasetnem rekorderju, digitalnih budilkah in bančnih avtomatih. Pri slednjih si skušal razvozlati fine programske napake s tem, da si odštel 1.024 USD od bančnega računa, ki je imel saldo manj kot 256 USD.

V službi popravljaš programe, ki dopuščajo odštevanje 1.024 USD od bančnih računov, ki imajo saldo manj kot z 256 USD. Tvojim naporom gre neposredna zasluge za rešitev podjetja, ki je na robu finančne katastrofe.

Ker si učinkovit, vendar tankovesten, te po krivem obsojajo. Uporabniki mislijo, da je tvoja edina skrb, kako bi jim zagrenil življenje. Vodstvo te venomer kara, da zapravljaš dragocen računalniški čas, ko si izmišljaš ekrana, ki jih uporabnik razume. Sanjaš o tem, da boš zapustil to podjetje, ki je ladja norcev, brž ko boš dokončal svoj razvpiti program in prodal milijon izvodov.

Programer - kakor ga vidi uporabnik

Nima razumevanja za človeško krhkost ali spodobno oblačenja. Ko ga opomnijo na športna oblačila, ki jih sestavljajo kavbojke in majica, odgovori, da kravata in obleka ovirata dotok krvi v možgane in s tem onemogočata kreativnost. Komuniciranje s programerjem je naporno, ker govori tuj jezik, ki vsebuje obilje izrazov kot so k, abend in no-op (osebni zaimek, ki označuje vodstvo podjetja). Če nam uspe prebiti ta jezikovni zid in mu dopovedati, daje v programu napaka, izjavi, da je to »napaka operaterja« in predlagaj naj se ponovno generirajo. Zagotavlja vam, da je razumljivost uporabniku na vrhu prioritet pri razvoju programov, vam ponosno pokaže tabelo, ki je izpisana decimalno in ne heksadecimalno. Najpogostejši odgovor na vprašanje: PTPN (preberi tisto prekleto navodilo).

Programer - kakor ga vidi šef

Je marljiv in lojalen vse dokler je lahko član badminton kluba v podjetju in če dobi popust v svoji trgovini z računalniškimi komponentami ter ima rezerviran parkirni prostor za svojega BMW. Prekanjeni šef prepoznava kot normalne naslednje značilnosti obnašanja programerja: a) enkrat tedensko odloži vse, kar dela, da bi popravil zadnjo napako v prejšnjem programu, b) vedno zamudi sestanek kljub svoji fenomenalno točni elegantni kvarčni zapestni uri, c) pušča na mizi prijave za zaposlitve, zlasti ob času ocenjevanja. Ocenjevanje časa, ki je potreben za programiranje, je ena najbolj zahtevnih šefovih nalog, ker programer verjame, da ima projekt devet življenj in daje le deveto tisto, ki ga je treba upoštevati. Najpogostejši odgovor na vprašanje: »Napaka uporabnika«.

Programer - kakor ga vidi tehnik

Sam sebi pravi programski tehnik, toda prav kakor smetar, ki se skriva za nazivom »sanitarni tehnik«, nima pojma, za kaj pri tehniki pravzaprav gre. Če bi resnično imel talent, bi programiral v strojnem jeziku, ampak tega v večerni šoli za programiranje niso naučili. Namesto tega žali grobo lepoto procesorja s tem, da vse računalnike otovori s cobolom ne glede na njihovo interno arhitekturo. Ko se sestane delovna skupina, krivi za to, da ni opravil dela do roka, omejitve zaradi velikosti pomnilnika in hitrosti izvajanja programov. Problem je seveda OPO (oprema pametnejše od operaterja). Najpogostejši odgovor na vprašanje: »Hardverska napaka«.

Programer - kakor ga vidi glavni direktor

Je znatna debetna postavka v plačilnem stolpcu finančnega poročila. Žene ga neustavljiv nagon po dokupovanju »zastarele« opreme (oprema, ki je stara več kot šest mesecev). Hrepeni po najnovejših video igrah, ki se nezmotljivo pojavijo na vsakem ekranu, ki je priključen na naš računalnik. Ima navade testirati nove programe v času, ko je računalnik najbolj obremenjen, tako da mreža razpade. Kritična pot vsakega pomembnega projekta visi na programerjevih prepozno opravljenih nalogah. Glede na to, kako se oblači, kakšno grimaso dela in kakšen delovni čas spoštuje, bi ga lahko zamenjali s hišnikom, le plačo ima petkratno hišnikovo. Njegovi napori so direktno krivi za to, da je podjetje na robu finančne katastrofe. Najpogostejši odgovor na vprašanje: »Sem dobro oblečen?«

Slika govori sama zase. Kar bi se človek nemara lahko vprašal, je: ali so v tej hiši samo programerji tisti, ki so na očeh?

O ekonomiji in organiziranju informacijskih sistemov

Zveza ekonomistov Jugoslavije je skupaj s Svetom za družbeni sistem informiranja SFRJ priredila jugoslovansko posvetovanje o ekonomiji in organiziranju informacijskih sistemov. Organizator je bila Zveza ekonomistov Slovenije, posvetovanje pa je bilo na Bledu od 9. do 11. oktobra 1985.

V uvodnem delu je bilo podanih nekaj preglednih referatov s področja družbenega sistema informiranja in poslovnega informacijskega sistema. Najprej je bilo posvetovanje razdeljeno v tri tematska področja. Vsakemu od njih je bil namenjen en dan, s tem daje bila drugega dne popoldne organizirana okrogla miza na temo standardizacija v informacijskih sistemih. Tematska področja so bila ekonomija in organiziranje poslovnih informacijskih sistemov, ekonomija in organiziranje v informacijskih službah družbenega informiranja in kot tret'e varstvo informacijskih sistemov in podatkov.

Zgornja faktografija je potrebna zaradi splošnega orisa ozadja. To, da sem se imel priliko udeležiti posvetovanja, mi daje priložnost, da zapišemo nekatera svoja razmišljanja in opažanja, ki se nanašajo nanj.

V prispevku nimam namena biti recenzent referatov ali celo ocenjevalec tega pomembnega dogodka, ne morem pa si kaj, da ne bi vsaj poizkusil pripomoči k razumevanju tega, kar so napisali in povedali nekateri referenti in drugi, ki so se oglasili kot razpravljavci v zvezi s posameznimi temami.

Naj se najprej dotaknem ključnega izraza tega posvetovanja, informacijski sistem. Iz poročil in razprave je bilo videti, kot da je le malo komu jasno, o čem govori, čeprav je eden od uvodnih poročevalcev že dlje časa tega podal jasno in sprejemljivo definicijo informacijskega sistema. Zgornja domneva je videti kar tendenciozna, vendar ni utemeljena. Iz razprav na tem in na prejšnjih posvetovanjih na to temo, ki jih prireja zveza ekonomistov Slovenije vsako leto v Portorožu, se da ugotoviti, da se izraz informacijski sistem uporablja za

1. računalniški sistem
2. računalniško obdelavo (aplikacijski programski sistem)
3. računalniški program
4. računalniški izpis.

Tu in tam se izraz uporablja celo korektno. Najočitneje nerazumevanje. je pred nekaj meseci pokazal nekdo na ljubljanskem radiu, ki je dejal približno takole: »Vedeti moramo, da je osebni računalnik že sam po sebi informacijski sistem.« Splošna uporaba izraza izhaja najbrž od tod, da vsi mislimo, da razumemo, kaj je informacija in kaj je sistem in da zato razumemo tudi kombinacijo obeh besed. Vendar se moramo zavedati, da je informacijski sistem predvsem sistem. To pomeni, da ima določene strukturne elemente, funkcionalne elemente, povezave, hierarhijo, način delovanja in da opravlja določene funkcije. Skratka, o informacijskem sistemu moramo razmišljati z vidika teorije sistemov, tega vtisa pa večina razpravljavcev ni pustila.

Mnogo je bilo tudi govora o razvijanja in formacijskih sistemov v določenih organizacijah. Čeprav članek ni predavanje o informacijskih sistemih, je nekako treba komentirati-tudi ta pogled. Delujočo organizacijo si lahko zamislimo kot povezavo dveh sistemov, produkcijskega in informacijskega (ki ju še naprej lahko delimo na podsisteme). Produkcijski sistem je tisti, ki je materialna osnova za proizvodnjo ali delovanje, informacijski sistem pa omogoči, da organizacija res deluje ali proizvaja. Vsaka delujoče: organizacija torej mora vsebovati tudi delujoč informacijski sistem ali pa je preprosto ne bi bilo. Tam, kjer »vzpostavljajo«, »razvijajo«, »gradijo« in drugače izdelujejo svoj informacijski sistem, nemara preprosto še niso opazili, da njihov informacijski sistem obstaja.

Dragi izraz, ki je bil na tem posvetovanju zelo priljubljen in v splošni uporabi, je bil izraz baza podatkov. Zanj je očitno, da se je iz informatike preselil v druge stroke in se v njih trdno ukoreninil. Težko bi dejal, da sem razumel, na kaj seje v splošnem z bazo podatkov mislilo, vendar tako, kakor jo pojmujemo v informatiki največkrat ne. Pogosto izražena ideja je bila, da bi se, če bi imeli »dobro«, popolno« ipd. bazo podatkov pravilno odločali. To razmišljanje je v osnovi sicer pravilno, ne upošteva pa nivoja (hierarhijo) odločanja. Čim višji je namreč nivo odločanja, tem manj podatkov je potrebnih za (pravilne) odločitve in tem manj podatkov pride iz sistema, v katerem se odloča, tem več pa iz okolice. Nazoren dokaz za to trditev je gradnja rafinerije pri nas po tem, ko je okolica energetsko krizo že prebolevala: na osnovi podatkov znotraj sistema se je dalo najbrž sklepati, da je taka odločitev pravilna, pogled zunaj meja sistema pa bi verjetno pokazal nasprotno.

Posebna pozornost je bila posvečena standardizaciji v informatiki. Že prej je bilo večkrat ugotovljeno (in obžalovano), da na tem področju za razvitimi tako zelo zaostajamo, kar je na prvi pogled nerazumljivo, saj je videti, kot da se ne bi zavedali ekonomskega pomena standardizacijo. Tega se sicer zavedamo, vendar na področjih, kjer ima standardizacija tradicijo in kjer brez standardov preprosto ne gre več. Kaj pa v informatiki? Tu tradicije še ni in ekonomske koristi (merljive v dinarjih) so premajhno, da bi bile v razmerah visoke inflacije opazne ali celo prevladujoče. standardi v informatiki me spominjajo na resničen primer, ko je bil neki delovni organizaciji ponujen program za optimiranje nekega njenega proizvoda. Ocenjeno je bilo, da je s pomočjo optimizacije mogoče prihraniti do 3 % pri stroških proizvodnje. Po desetdnevnem premisleku je delovna organizacija nakup programa zavrnila z zanimivo obrazložitvijo. Povedali so, da so skupaj z drugimi proizvajalci iz svoje panoge dosegli pri zvezni administraciji (ki je tedaj imela to pristojnost) 75 odstotno podražitev izdelka, katerega proizvodnjo naj bi optimizirali. Nakup progama, ki bi jim omogočil za red velikosti manjšo korist, bi bil v takih okoliščinah golo zapravljanje. Standardi torej še naprej ostanejo ekonomska kategorija tudi v informatiki, vendar se spričo razmer ne smemo čuditi, če ne bo pretirane vneme za to, da bi jih razvijali in uveljavljali.

Naj se za konec dotaknem še organizacije posvetovanja. Prirejeno je bilo nekako »forumsko«. Avtorji, ki so svoje prispevke sicer objavili v zborniku referatov, so le-te na kratko predstavili, v nadaljevanju pa so udeleženci posvetovanja kako njihovo misel ali pa vprašanje za razpravo, ki so bila posredovana posebej, uporabili kot iztočnico za svojo diskusijo. Posledica take tehnike je bila, da smo vsi poslušali vse diskutante. Ker interesi niso tako univerzalni, bi se mi zdelo primerneje, da bi referenti svoje prispevke predstavili bolj temeljito in z uporabo vizualnih pripomočkov (npr. grafoskopa). Poleg tega bi organizatorji lahko priredili več okroglih miz, ki bi potekale istočasno. S tem bi dosegli, da bi se udeleženci bolj posvetili temam, ki jih predvsem zanimajo. Okrogla miza bi s tem postala res to, kar naj bi bila, namreč izmenjava mnenj, s čimer bi pridobili tako udeleženci kot tudi prireditelj.

Če bi posvetovanje organizirali na tak način, bi to zahtevalo nekaj več organizacijskega napora, vendar verjamem, da bi bilo vredno poizkusiti, saj bi bilo srečanje bolje izkoriščeno, kar je v vzajemnem interesu vseh sodelujočih.

CASE + CAST = APS

November 1991

Temeljite spremembe pri poslovanju so v preteklih letih doletele prenekatero firmo, predvsem z uporabo računalniško podprtih aplikativnih sistemov. Spoznanje, da računalnik ne omogoča v najboljšem primeru le podporo operativnemu delu, kot moderen knjigovodski stroj, je danes prisotno v mnogih podjetjih, ki se borijo za svoj tržni delež. Poudarek je na sprotnih (online) aplikativnih programskih sistemov (APS).

APS in ustrezna računalniška podpora postajata vse bolj zahtevni in kompleksni nalogi ter občasno presegata trenutne zmogljivosti, tako človeške kakor tudi strojne. Dodatna komplikacija in nevarnost je tudi hitrost, ki jo morajo dosegati ljudje, APS in strojna oprema s ciljem spremljanja tekočega dogajanja in konkurenčnosti.

To je čas, ko se je pojavil CASE (Computer Aided Software Engineering) kot ključ, nekateri so ga imenovali kar čudežni, ki bo rešil vse ali skoraj vse probleme in težave pri razvoju in vzdrževanju APS. Lahko se je našlo celo ekonomsko opravičilo, saj so reklame in oglasi za CASE orodja obljubljali mnogo, predvsem za majhen denar.

Jasno je, da od celotne in vsestranske rešitve CASE v praksi pokriva le zgodnje načrtovanje in razvoj APS v njenem celotnem življenjskem ciklusu. Za postopke testiranja, ki so izjemno pomembni za izdelavo čiste in zaupanja vredne programske kode pred samo uporabo v rednem delu, je CASE naredil bolj malo. CASE sam po sebi in kot tak ne more izdelati kvalitetnega in zanesljivega APS.

Ali je morda CAST (Computer Aided Software Testing) manjkajoči člen za normalno pot pri razvoju, testiranju in uvajanju orodij za celovite (integralne) pakete? Vsekakor sta CASE in CAST izdelana približno hkrati. Toda poznavanje in razumevanje obeh je bistveno različno.

CASE je način - metodologija za avtomatično in kompleksno testiranje vseh funkcij pri razvoju novega ali spreminjanju obstoječega APS. S pojavom CASE tehnologije se bistveno povečala hitrost izdelave novih in predvsem zahtevnost APS. To pa je tudi povečalo problemi testiranja, ki je bil potisnjen na rob razvoja in uporabe APS.

Nujno zlo med izdelavo APS je testiranje, čeprav proizvajalci CASE opreme o nepogrešljivosti ravno njihovega produkta vedo povedati vse najboljše. Tragično je, ko se slabo testirani programi prenesejo v produkcijo. Lep primer je firma American Airlines, ki je zaradi programske napake v sistemu rezervacij (booking) v pičlih 3 (treh) mesecih imela ca. 50 mio USS izgube! Prav zato, da se prepreči podobne napake, so mnogi pripravljeni investirati v programsko opremo za testiranje.

In kje je rešitev? Odgovor je treba iskati tudi v boljšem vzdrževanju APS. Znani so podatki, da se tudi do 50% vseh stroškov neke APS porabi za njeno vzdrževanje. To ni le nesmiselno in absurdno temveč tudi neuspeh za organizacijo in izdelavo samega APS. Redki so uporabniki, ki realno ocenijo, da je testiranje APS zelo pomemben korak pri razvoju APS. Vsak napor in strošek se kasneje obrestujeta.

Trditev, da je testiranje med razvojem nepotrebno (podaljšuje čas izdelave, viša stroške), ni resna. Če se testira sproti in med razvijanjem, se vse odkrite napake popravi takoj in ne šele pri prekinitvah med rednim delom.

CAST naredi testiranje bolj vodljivo, uspešno in omogoča uporabniku izdelavo načrta testiranja v vsakem trenutku razvoja ali uporabe APS. CAST vsebuje štiri tehnike testiranja: (1) diagnostiko napak, (2) interaktivno popravljanje, (3) avtomatizirano testiranje in (4) uporaba podatkov - datotek. V CAST okolici so na razpolago orodja, ki skupaj s CASE omogočajo dobro in kvalitetno izdelavo APS.

Razvoj aplikacijskih programskih sistemov z uporabo CASE in podobni orodij se ocenjuje in meri z meseci in leti oziroma  kako hitro se izdela APS v primerjavi z običajnimi metodami. Nasprotno, pri CAST uporabljamo minute in kvečjemu še ure kot mero uspešnosti pri odkrivanju napak. Nekatere APS lahko obsegajo nekaj deset ali celo sto sprotnih, on-line, interaktivnih programov, ki jih je treba testirati. Kar nekaj pripomočkov je na razpolago, ki olajšajo to mukotrpno delo.

Običajno lahko celotno testiranje opredelimo z naslednjimi štirimi metodami:

1. diagnostika napak,
2. interaktivno popravljanje,
3. avtomatizirano testiranje,
4. uporaba podatkov - datotek.

Bistveni postopki obsegajo naslednjih pet korakov:

1. testiranje posameznega programa,
2. združevanje več že preizkušenih programov v zaokroženo celoto,
3. spreminjanje programov, da se prepričamo v predvidene (napačne ali pravilne) rezultate,
4. vzporedno delovanje dveh ali več programov in dveh ali več uporabnikov istega programa ter opazovanje vseh negativnih efektov, pa čeprav takšen način dela morda nikakor ni možen pri rednem delu,
5. obremenitev SW in HW kot v normalnem delovanju.

Eden med pomembnimi in bistvenimi faktorji aplikativnega testiranja je tudi delovanje v ekstremnih pogojih. Tako kot avtomobilska industrija testira in preobremenjuje nove izdelke pred redno proizvodnjo in prodajo, tako je treba tudi APS »obremeniti« - intenzivna uporaba, maksimalno število uporabnikov, velike količine podatkov in podobno.

Celovito testiranje pa ni prisotno le med razvojem programov in APS. Upoštevati je treba tudi hiter razvoj strojne opreme. Res je, da je kompatibilnost od starega na novo zagotovljena že s strani proizvajalca strojne opreme. Vprašanje pa je, če neki stari APS res dobro izkorišča novo strojno opremo. Ko pride do odločitve, da se mora APS prilagoditi novim značilnostim strojne opreme, potem to ne sme na noben način vplivati na delo uporabnikov - spremembe ne smejo niti zaznati, kaj šele, da so pri tem moteni.

Tako zanesljiv in gladek prehod na spremenjeni APS lahko olajša tudi uporaba CAST pripomočkov. Tehnično gledano, uporaba CAST ni težka ali problematična. Največji problem je v tem, da se vsi, ponudniki in uporabniki CASE, ne zavedajo dovolj kaj je učinkovito testiranje. Načrt testiranja in testni podatki morajo biti določeni v vsaki fazi razvoja APS. Kot rečeno, hierarhija testiranja se prične pri posameznem programu in se zaključi kot vsestranski test celotnega APS v resnični okolici delovanja.

Prednosti pripomočkov CAST so nesporne: bistveno skrajšajo čas izdelave APS, odkrijejo napake, vse skupaj pa poceni celoten »proračun« določenega APS. Vsekakor ni razlogov za tekmovanje med CASE in CAST. CAST je dopolnilo CASE, oba skupaj nudita čist dizajn in razvojne prednosti ter zmanjšujeta morebitne možnosti napak - rezultat je boljši APS. Poudarek mora biti na celotnem področju uspešnosti: hiter razvoj, dobro testiranje, zadovoljstvo končnega uporabnika ter natančnost, točnost in ažurnost podatkov.

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

Prihodnost v informatiki

Vsaka obletnica, bodisi osebna ali obletnica delovanja organizacije, nas nekako sili k temu, da vsaj pri sebi napravimo neke vrste obračun uspešnosti za to obdobje. To še toliko bolj, če je obletnica okrogla in visoka. O svojem delu in delovanju organizacije sicer letno poročamo, vendar so ta poročila pripravljena za drugačen namen in tudi za drugo publiko kakor razmišljanja o dosežkih in uspehih v času, ki ga označuje jubilej. Zato so primerno suhoparna in ni slučajno, da izhajajo kot uradna priloga Obvestil. Prav jubilej pa je priložnost, da predstavimo svoje delo in rezultate javnosti, obenem pa tudi razmislimo, kakšne cilje naj določimo kot usmeritev za delovanje v prihodnje. Iz dneva v dan se sproti niti ne zavemo, da se imamo s čim pohvaliti, ker smo zaradi nalog, ki jih vidimo pred seboj, veseli, da je vsaj ena opravljena, zato je jubilej dobrodošla prilika tudi za to, da prikažemo dosežke na bolj prijazen način.

Ko pregledujemo in seštevamo dosežke minulih tridesetih let, se nehote spomnimo, da smo - vsaj zazdi se nam tako - še ne tako dolgo tega, ob petindvajsetletnici službe družbenega knjigovodstva, napravili prav nekaj podobnega. Odveč bi bilo zato ponavljati vse, kar je bilo rečenega in napisanega za tisto priložnost. Raje se bomo ozrli na pet let, ki so minila od tedaj, in pogledali, ali so dosežki v tem času vredni omembe ob jubileju. Navzven morda najbolj vidna sprememba, ki zadeva organiziranost informatike v službi, je v tem, da sta se združila centrala in skupni elektronski računski center centrale in podružnice Ljubljana, ki je tako postal sektor za računalniško obdelavo podatkov.

Informacija je postala že samostojna stroka, ki je vse kaj več kot zgolj uporabljanje računalnikov. Ker se je razvila iz uporabe računalnikov, torej pač zaradi tradicije in pa zato, ker je to tako rekoč najbolj otipljivi del informatike. Poglejmo najprej, kaj smo dosegli pri opremljanju službe z računalniškimi napravami. V preteklih petih letih je bilo zamenjanih deset računalniških sistemov v podružnicah druge in tretje velikosti z novimi, tehnološko sodobnimi in bistveno bolj zmogljivimi. O tem priča tudi dejstvo, da so imele podružnice Koper, Novo mesto, Nova Gorica in Murska Sobota po dva računalnika, večje število obdelav pa se sedaj izvaja na enem računalniškem sistemu. Z zmogljivejšimi so bili zamenjani računalniki velikih podružnic in centrale, poleg tega pa so bile vsako leto nabavljene različne periferne enote računalniških sistemov, ki so zamenjala izrabljene ali je bila z njimi povečana zmogljivost celotnega sistema.

Eno od smeri razvoja računalniških naprav, osebne računalnike, uspešno uvajamo tudi pri nas. Od prvih nekaj modelov, ki so bili nabavljeni v glavnem za potrebe razvijanja programov, smo prišli že do široke uporabe v vseh delih in funkcijah službe. Za sedaj se osebni računalniki uporabljajo kot samostojne naprave. Pričakujemo lahko, da se bo tudi v prihodnje uporaba širila tako po številu uporabnikov in naprav kakor po področjih in namenih uporabe in da bo vse več možnosti za prenos podatkov med njimi in velikimi sistemi. Uspešni poizkusi nas v tem potrjujejo.

Na področju komunikacij je služba ena od prvih organizacij, ki je poleg tega, da je bila soinvestitor javne mreže za prenos podatkov, začela to mrežo tudi redno uporabljati za prenos podatkov in interaktivno delo z oddaljenih lokacij v dveh podružnicah. Vozlišče v Ljubljani je bilo ena od prvih treh aktivnih vozlišč računalniške mreže Službe družbenega knjigovodstva. Nedavno tega je bil opravljen uspešen preizkus prenosa podatkov med računalnikoma Unisys in IBM, kar bo omogočilo nadaljnje povečanje števila slovenskih podružnic, ki se bodo lahko povezale v računalniško mrežo. Računalniška mreža bo tudi omogočila neposreden vpogled v zbirke podatkov, ki jih služba zbira in jih bo lahko ponudila, ko bo to omogočeno tudi z navodili.

Projektiranje aplikacijskih programskih sistemov in programiranje sta vedno aktualni področji informatike. Smer razvoja v razvitih državah na tem področju je delo z bazami za upravljanje s podatki in uporaba programskih jezikov četrte generacije.

V zgornjem pregledu dosežkov smo podali le tiste, ki se nanašajo na zadnjih pet let ali manj in ki so pomembni za razvoj in delo vnaprej. Videti je, kakor da se hvalimo, in dejansko se. Rečemo lahko, da je informatika v naši službi na strokovnem nivoju, kakršnega dosegata morebiti le še dva druga računska centra v službi, pa tudi v bližnji okolici jih ni prav dosti, ki bi nas v tem pogledu presegali. Uspehi seveda obvezujejo, do njih pa ne prihaja slučajno. Na to kaj smo dosegli, vplivajo različni faktorji na različne načine. Faktor, ki vpliva pozitivno, je izobraževanje in neprestano strokovno usposabljanje. To področje je zadovoljivo urejeno in prizadevati si moramo, da v prihodnosti ne bi prišlo do poslabšanja. Manj smo zadovoljni s tehničnimi in prostorskimi pogoji.

Ker so strokovni uspehi zelo močna motivacija, lahko rečemo, da bomo uspešni tudi v prihodnje, kolikor bo to odvisno od nas samih. Ob tem pa morajo biti izpolnjeni še objektivni pogoji, ki morajo ta osnovni pogoj dopolniti. Pri tem mislim na dolgoročne razvojne usmeritve za področje informatike, ki jih je služba sprejela, a jim zaradi različnih vzrokov, med katerimi finančni niso na zadnjem mestu, v celoti ne sledimo. Če naj bomo kot sektor in služba na področju informatike uspešni tudi v prihodnje, mora biti to omogočeno tudi tehnično, prostorsko in kadrovsko.



Oktober 1989

Mašinerija brez ljudi je staro železo

Za kratek razgovor smo prosili pomočnika generalnega direktorja za področje računalniške obdelave podatkov.

Podružnica Ljubljana je z novo organizacijsko shemo AOP formalno izgubila projektantsko in programsko ekipo, ki je opravljala svoje delo za vse podružnice v Sloveniji z IBM opremo. Boste po tej shemi na centrali organizirali tudi programiranje za podružnice z Borroughs računalniškimi sistemi?

Težko bi rekli, da je podružnica Ljubljana izgubila programsko in projektantsko ekipo, ki je pokrivala njene potrebe in potrebe drugih podružnic SDK v Sloveniji, kjer so instalirali računalniški sistemi IBM, z novo organizacijsko shemo sektorja za obdelavo podatkov centrale. Če uporabim vaš izraz, se je to formalno zgodilo že z ustanovitvijo skupnega elektronskega računskega centra centrale in podružnice Ljubljana, kar pa ni pomenilo, da podružnica Ljubljana ni imela na voljo strokovnjakov za računalništvo in seveda tudi ne pomeni, da jih ne bo imela v prihodnje. Vse storitve, ki jih je za podružnice Ljubljana opravljal SERC, bo v prihodnje opravljal sektor za obdelavo podatkov centrale. Z novimi računalniškimi napravami, ki so bile instalirane prav te dni, bo mogoče opravljati te storitve vsaj tako kvalitetno kot prej.«

Računalniške sisteme ima v tem trenutku vsaka podružnica v Sloveniji ne glede na morebitno nerentabilnost take organizacije. Predvidevate na tem področju kakšne spremembe?

Računalniški sistem v vsaki podružnici v Sloveniji je bil v času, ko je bil inštaliran, gotovo upravičen, saj moramo upoštevati tudi druge razloge, ne le ekonomskih. Najprej je treba verjetno izpolniti zahtevo, da morajo biti podatki plačilnega prometa obdelani dnevno ažurno. Vemo, da je računalnik sredstvo, ki to omogoča. Dejstvo pa je, da so danes na voljo tehnike in naprave, ki jih v času, ko se je obdelava podatkov v službi načrtovala, še ni bilo ali pa jih še nismo obvladovali. V tem smislu je treba ugotoviti, da je mini računalnik v SDK svoje poslanstvo opravil in da bo treba izdelati načrt za čas, ko bodo računalniki v podružnicah odslužili. Ob tem moram povedati še to, da nadomestitev računalnikov v podružnicah ne pomeni obenem kar avtomatične odprave delavcev, ki delajo na tem področju, predvsem organizatorjev in programerjev.«

Za organizacijski del analiz v SDK ste postali nepogrešljiv partner pri opravljanju njihove osnovne dejavnosti. Kontrola je ostala do sedaj še brez kakšne večje računalniške podpore. Mislite, da bi bilo tudi za kontrolo mogoče kaj več narediti in kaj?

Najbrž bi se dalo kaj več narediti, vendar se na to področje še najmanj spoznamo, ker smo s kontrolo bolj malo delali. Lani so izrazili željo, da instaliramo programe, ki bi jih uporabljali inšpektorji. Šlo je namreč za to, da bi dobili magnetni trak od uporabnikov družbenih sredstev, nato pa bi jih inšpektorji preko svojega programa analizirali. Nekaj poskusov je bilo, dlje od tod pa nismo prišli. Menim pa, da bi to lahko naprej razvijali in bi bilo še posebej koristno pri ocenjevanju periodičnih obračunov in ocenjevanju zaključnih računov. Najbrž bi se dalo narediti programski paket in izdvojiti preciznejše detajle, da ne bi bilo treba človeku premlevati vseh podatkov, od tu naprej pa bi jih analiziral inšpektor. Mi bi takšen program znali narediti, samo uporabniki družbenih sredstev bi morali specializirati svoje zahteve in tudi pobuda mora priti od njih.«

Obrazci plačilnega prometa so že nekaj časa v prometu v taki obliki, kot ga zahteva prihodnji TK prenos v SDK. Kako sodelujete pri realizaciji TK prenosa v SDK in kako bomo to izpeljali v Sloveniji?

Pri sami izvedbi TK prenosa ne sodelujemo, sodelovali pa smo v delovni skupini pri SDK Jugoslavije. Nadaljnje sodelovanje je namreč presegle naše kadrovske zmogljivosti. Precej smo se namreč angažirali pri razvoju programskih aplikacij sistema za spremljanje investicij. Če bi poslali eno ekipo še za realizacijo TK prenosa, bi se dnevno delo začelo zatikati, ne sicer pri plačilnem prometu, pri statističnih poročilih pa zagotovo. Sodelovali smo tudi pri prenosu na TK pri seriji 1. V eksperimentalni prenos nismo vključeni, mislim, da ob tem ne bo posebne škode, ker ne gre za obdelavo, ampak vnos in prenos podatkov, kar že dobro obvladamo. TK prenos naj bi 1. oktobra stekel, s 1. februarjem leta 1986 pa naj bi to uspelo tudi vsem podružnicam v državi.«

V SDK ste znani kot uspešen direktor skupnega računalniškega centra centrale in podružnice Ljubljana. Kako vam je uspelo vzdrževati stalno motiviranost zaposlenih, disciplino in obenem podporo sodelavcev?

Trudim se. Karkoli delam, nimam nikoli osebnih interesov. Vedno sem poskušal poiskati tiste rešitve, ki so za službo najboljše. Pozna pa se, da že dolgo delamo skupaj, da me delavci poznajo in da vedo, da nimam osebnih interesov. Ljudje sledijo tistemu, ki ve, kaj hoče. Pri motiviranosti pa smo vedno gledali na to, da smo delavce za dobro delo dobro nagradili. Predvsem se mi zdi pomembno, da nikoli nikogar ne podcenjuješ. Vedno smo bili širokogrudni za razne vrste nagrajevanja, nadurno delo smo vedno priznali in kompenzacija je bila vedno možna. Treba je imeti pošten odnos do delavcev in jim omogočiti tudi strokovno izpopolnjevanje, udeležbo na strokovnem seminarju ali razstavi in upam, da bodo te možnosti ostale tudi v prihodnje.«

Znano je, da redno spremljate razvoj računalništva v svetu. Kakšen trend je trenutno prisoten in kaj od tega bi bilo zanimivega za našo službo?

Zadnje čase spremljam razvoj računalništva na žalost bolj pasivno. Ogledal sem si Hannovrski sejem računalništva, kjer sem sicer veliko videl, saj je sejem prava paša za oči, bolj pa bi mi koristilo, če bi se udeležili kakšnega seminarja, kar pa je strahovito drago. Vendar če smo nekaj deset starih milijard dinarjev investirali v računalniško opremo, bi morali najti še nekaj sredstev za izobraževanje, kajti mašinerija brez ljudi je staro železo. V Beogradu sem se tudi pogovarjal z nekaterimi, ki so bili na SICOB v Parizu, in tudi oni so mi potrdili, da IBM kot vodilni ne razstavlja več računalniških sistemov. V začetku leta je IBM objavil sistem 3090, to je računalnik, katerega centralni polnilnik se začne pri 16 MB. Ta računalnik bi bilo zanimivo videti, pa ravno tega niso razstavili. Prikazali pa so, kako računalnik pri delu lahko pomaga človeku pri konstruiranju, načrtovanju, statistiki, vnosu podatkov pa tudi pri banalnih stvareh. Za SDK je zanimiva predvsem uporaba mikroračunalnikov. Pri nas se na tem področju stvari že premikajo. Za določene enote je bil namreč naknadno objavljen popust, zato smo kupili nekaj več ekranov in mikroračunalnik IBM PC za potrebe centrale. Omenjeni računalnik bo imel poleg standardnega programiranja še možnost priključitve na velik računalnik, obdelave teksta, grafični prikaz podatkov in drugo.

Kako gledate na poskuse uveljavljanja mikroračunalnikov v združenem delu in posebej v SDK?

To je edina možna pot naprej. Mikroračunalnike bi morali čim bolj uveljaviti in tako zmanjšati zaostanek za razvitim svetom. V službi družbenega knjigovodstva smo bili do sedaj že korak zadaj in zato smo veseli, da ima centrala SDKJ mikroračunalnike in da je naš generalni direktor pokazal izredno razumevanje za to področje.


oktober 1985

Reforma visokošolski programov

Januar 1985

Letos je pred nami preobrazba visokošolskega študija. Visoke šole morajo prilagoditi svoje programe začetemu usmerjanja iz srednje šole in pa seveda potrebam združenega dela. Dobili smo osnutek vzgojno-izobraževalnega programa za višješolski in visokošolski študij organizacije dela - smer informatika. Na preizkušnji je področje dela, ki nima kakšne posebne tradicije in katerega razvoj je zaradi hitrega napredka tehnike in tehnologije, težko napovedovati. Šola je lik diplomanta opisala takole:

Diplomirani organizator - informatik je poklic VII. stopnje po klasifikacijski lestvici zahtevnosti del in nalog. Le-ta obvlada analizo delovnih procesov v informacijskih sistemih z namenom izboljšanja organiziranosti dela na tem področju. To vključuje:

 Organiziranje informacijskih dejavnosti v organizacijskih sistemih

• členjenje in analiza delovnih procesov (nalog) v informacijskih sistemih z namenom izboljšanja organiziranosti dela na tem področju
• izdelovanje predlogov rešitev delitve dela in odgovornosti v zvezi z informacijskimi sistemi med organizacijskimi enotami za informacijski sistem (za obravnavanje podatkov) in organizacijskimi enotami uporabnikov rezultatov informacijskega sistema
• izdelovanje predlogov v zvezi z organizacijsko strukturo enot za informacijski sistem (enot za obravnavanje podatkov)
• izdelovanje predlogov organiziranosti uporabnikov rezultatov informacijskega sistema za potrebe razvoja in delovanja informacijskega sistema
• izdelovanje predlogov v zvezi z organiziranostjo standardiziranja in standardizacijo v informacijskem sistemu
• izdelovanje predlogov konkretnih organizacijskih standardov v informacijskem sistemu (standardi delovnih nalog, delovnih postopkov, dokumentacije, sestavin informacijskega sistema)
• organiziranje revizije v informacijskih sistemih

 Vzpostavljanje sodobnih informacijskih sistemov

• izdelovanje predlogov zasnove in načrta razvoja celotnega informacijskega sistema organizacije ob upoštevanju sodobne tehnologije informacijskih sistemov in ob sodelovanju poslovodnih in strokovnih delavcev - uporabnikov ter zadevnih specialistov
• vzpostavljanje povezav med delnimi računalniško zasnovanimi informacijskimi sistemi
• organiziranje projektov razvoja računalniško zasnovanega informacijskega sistema
• strokovno usposabljanje uporabnikov za potrebe razvoja, uporabe in vzdrževanja računalniško zasnovanega informacijskega sistema
• analiziranje potreb po informacijah v upravljalnem in izvajalnem sistemu ter v okolju organizacije
• vrednotenje predlaganih in delujočih rešitev računalniško zasnovanih informacijskih sistemov z vsebinskih, organizacijskih in gospodarskih vidikov
• ocenjevanje tržnih aplikativnih programskih podatkov glede njihove uporabnosti in gospodarnosti.

V službi družbenega knjigovodstva je za potrebe združenega dela in družbenopolitičnih skupnosti zgrajen računalniško podprt informacijski sistem, ki je še vedno v fazi dopolnjevanja in modernizacije. S prevzemom računalniške tehnike, kot osnovne infrastrukture za delovanje učinkovitega informacijskega sistema, se je tudi pri nas takoj pojavil kadrovski problem na področju organizacije dela, projektiranja aplikacijskih programskih sistemov in vodenja tako imenovanih računalniških centrov v organizacijskih enotah službe.

Organizator dela, torej vmesni člen med kadri, ki se ukvarjajo z zakonsko definiranimi funkcijami službe (inšpekcija, revizija, informiranje, analize, plačilni promet, družbeno računovodstvo, statistika) in kadri, ki poganjajo računalniško obdelavo podatkov (projektiranje programskih aplikacijskih sistemov, programiranje na računalniškem sistemu, programiranje sistemskega programja, operiranje z računalniškim sistemom) se je izoblikoval samoniklo, pač iz vrst najstrokovnejših delavcev, ki imajo potrebno afiniteto do računalništva.

Delo organizatorja je raznoliko in naporno. Področje dela se neprenehoma menjava. Delo, ki se ponavlja je zanj nezanimivo. Organizator se spopada skoraj vsak dan z novim problemom, saj uporabniki računalniških storitev zahtevajo vedno nove aplikacije. Pa tudi že utečene programske rešitve zaposlujejo organizatorja, saj se pogosto menjajo predpisi, stopnje prispevkov ali drugi pogoji. Menjajo se izvajalci, ki so že osvojili delovni proces v ERC, ponagaja tehnika, slabi programi itd. Narava dela je izbrusila našega organizatorja, to je enega izmed tistih delavcev, ki se ne ustrašijo ne popoldanskega ali nočnega dela, ne v nedeljah in praznikih. Praksa, šolanje, pa tudi nagnjenost k takim opravilom so izoblikovali tak profil novega delavca.

Kljub že večletnim izkušnjam in dopolnilnemu izobraževanju pa še vedno opažamo prav pri tem profilu kadra največjo potrebo po kompleksnejšem in tudi zelo specifičnem znanju.

Isti primer opažamo pri projektantskem in programerskem kadru, ki smo ga rekrutirali iz strokovnjakov na področju elektrotehnike, kemije, ekonomije itd., kjer se nivoja razpoznavanja problema pri njih in naročniku običajno močno razhajata in je potrebno več časa in napora, da pride do enotno oblikovanega izhodišča za izdelavo novega projekta.

Osnutek vzgojno-izobraževalnega programa visoke šole daje dovolj garancije, da se bo po takem sistemu šolanja oblikoval ustrezen kader za potrebe organiziranja informacijskih sistemov in njihovega vzdrževanja, prav tako pa tudi kader za projektiranje in zelo zahtevno programiranje.

Novosti na področju poslovne informatike

Okrogla miza o izobraževanju računalniškega kadra je vzbudila največ zanimanja

Društvo ekonomistov Ljubljana je organiziralo 18. do 20. aprila 1984 v Portorožu že 13. posvetovanje o ekonomiki in organizaciji v združenega dela.

Beseda je tekla o problemih organiziranja računalniško zasnovanih informacijskih sistemov. Seveda pa to posvetovanje ni bilo prvo, ki bi odpiralo tako aktualno temo. Prizadevno društvo ljubljanskih ekonomistov je že nekajkrat obravnavalo računalništvo na svojih sestankih ali posvetovanjih. To pot je bilo posvetovanje razdeljeno na sledeče dele:

• organizacija dela v računalniško zasnovanem informacijskem sistemu,
• varnost podatkov in informacij v računalniško zasnovanem informacijskem sistemu,
• usklajevanje podatkov in informacij v družbenem sistemu informiranja
• kontrola in revizija poslovanja v pogojih računalniško zasnovanega informacijskega sistema.

Organizirana je bila tudi okrogla miza na temo izobraževanja računalniškega kadra in je vzbudila še največ zanimanja. Prisotnih je bilo precej univerzitetnih profesorjev, ki so opisali razvoj in problematiko informatike ter istočasno obravnavali razvoj kadrov ter osnovna izhodišča in smer nadaljnjega izobraževanja. Na temo usklajevanje podatkov in informacij je pripravila referat tudi delavka iz Centrale v Ljubljani in to o Informacijskem sistemu službe družbenega knjigovodstva v družbenem sistemu informiranja. S tem referatom je služba nekako zaokrožila celoletno prizadevanje obveščanja najširše javnosti o funkciji in nalogah SDK v družbenem sistemu informiranja.

Društvo je že drugič pripravilo tudi pregled inovacij in izdelanih projektov na področju poslovne informatike. SDK je sodelovala s projektom ELKA, ki je bil izdelan v SDK SERC.

Posvetovanja se je udeležilo okrog 500 ekonomistov in med njimi tudi večina vodij AOP naših podružnic.

Maj 1984

1 + 1 = 2

Strokovna eleganca

Bolj za šalo kot zares, toda, kaj pa če je vse skupaj res?


Vsakemu tehničnemu izobražencu, torej inženirju, je splošno znano seštevanje dveh realnih števil:

To pravilo je napisano v neverjetno enostavni obliki, razumljivo celo učencem 2. razreda osnovne šole. Brez dvoma pa zgoraj napisani enačbi manjka domišljije, da o stilu ne izgubljamo besed.

Iz osnov matematike je znano

oziroma

Vsem je tudi znan zapis

Iz vsega povedanega sledi, da enostavno enačbo

lahko zapišemo bolj strokovno takole
 

Gornja oblika enačbe se zelo približuje znanstvenemu zapisu.

Splošno znano je

ter da je

iz česar izhaja

To enostavno enačbo pa lahko zapišemo v mnogo bolj pregledni obliki

Če upoštevamo, da je

in dejstvo, da je inverzna matrika transformirane matrike enaka transformirani matriki inverzne matrike, vse seveda ob predpostavki enodimenzionalnega prostora, potem dobimo naslednjo poenostavitev v vektorski obliki  

Če sedaj poenostavljeno odvisnosti seštejemo

in

dobimo

Ko uporabimo poenostavitve iz enačbe

končno dobimo zelo pregledno, elegantno in vsem razumljivo enačbo

Vsak dvom odpade, saj je gornja enačba absolutno bolj profesionalna in strokovna od prvotne »kmečke« oblike 

Za pravilno razumevanje:

Zgornji prikaz je narejen za naše prijatelje in diplomante Univerze v Kumrovcu in FSNP oziroma naslednice FDV v Ljubljani, odvetnike, tudi za ekonomiste, filozofe, ključavničarje, šivilje, bolniške bratce itd., v upanju, da spoznajo, da lahko tudi tehnični izobraženci zakomplicirajo vsako še tako enostavno zadevo.