-

Transkripcija

1 Informatika v organizaciji in managementu PROGRAMSKA REŠITEV ZA SLEDENJE MATERIALA Mentor: doc. dr. Borut Werber Kandidat: Stojan Erker Kranj, junij 2016

2 ZAHVALA Zahvaljujem se mentorju doc. dr. Borutu Werberju za nasvete in pomoč pri izbiri vsebin in sestavljanju moje diplomske naloge. Hvala vsem sodelavcem iz razvojne skupine, ki ne želijo biti imenovani na straneh mojega diplomskega dela, a so bili nepogrešljiv člen v razvojnem ciklu projekta. Posebna zahvala velja moji družini, ki me je ves čas študija podpirala in spodbujala.

3 POVZETEK Programsko rešitev za sledenje materiala smo razvili zaradi funkcionalne neustreznosti obstoječih aplikacij. Uvedli smo jo v proces izdelave aluminijastih folij in s tem informacijsko podprli operacije od prevzema materiala do pakiranja. Razvoj smo začeli s skrbno izbiro članov razvojne skupine in po sestavi takoj začeli intervjuvati uporabnike. Na ta način smo podrobno spoznali delovni proces in se seznanili z njihovimi željami in pričakovanji. Na osnovi zbranih informacij smo določili glavne usmeritve in omejitve ter izdelali osnovne analitske opise. Istočasno smo gradili tudi podatkovni model. Za izmenjavo podatkov s stroji smo izdelali spletne storitve (web servise), za zapisovanje podatkov v podatkovno bazo pa smo izdelali shranjene procedure. Poslovno logiko in spletne strani smo izdelali z razvojnim orodjem IBM EGL, ki temelji na programskem jeziku Java. Programsko rešitev smo gradili po etapah in delovanje vsake verzije preverili v testnem okolju. Po uspešnem testiranju smo verzijo namestili na produkcijski aplikativni in bazni strežnik, kjer je na razpolago vsem uporabnikom z ustrezno avtorizacijo. KLJUČNE BESEDE: informacijski sistem, metodologija, entiteta, podatkovni model, transportna enota.

4 ABSTRACT Software solution for material tracking we have developed as a result of functional inadequacy of existing applications. We have implemented it in the process of making aluminum foil and with this information to support the operation of the acquisition of the material to the package. We started development with a careful selection of the members of the development team and after composition immediately began with interviews of users. In this way we get to know in detail the working process and learn about their wishes and expectations. On the basis of the collected information, we set the main guidelines and limitations and produce the basic analytical descriptions. At the same time, we also built a data model. For data exchange with the machines we have Web services for the recording of data in the database we created stored procedures. The business logic and the website we made with development tool IBM EGL, which is based on the Java programming language. Software solution we built by stages and operation of each of the versions checked in the test environment. After successful testing, we have a version installed on a production application server and database server, where it is available to all users with appropriate authorization.. KEYWORDS: information system, metodology, entity, data model, transport unit.

5 KAZALO 1. UVOD PREDSTAVITEV PROBLEMA PREDSTAVITEV OKOLJA PREDPOSTAVKE IN OMEJITVE METODE DELA TEORETIČNE OSNOVE PODATKOVNA BAZA APLIKACIJSKI STREŽNIK TRI SLOJNA AHITEKTURA PODATKOVNO MODELIRANJE METODOLOGIJA RAZVOJA IS OBSTOJEČE STANJE POSNETEK STANJA KRITIČNA ANALIZA PRENOVA ANALIZA NAČRTOVANJE IZVEDBA VPELJAVA ZAKLJUČEK OCENA UČINKOV POGOJI ZA UVEDBO MOŽNOSTI ZA NADLJNJI RAZVOJ LITERATURA IN VIRI ELEKTRONSKI VIRI: KNJIGE: KAZALO SLIK KRATICE IN AKRONIMI... 58

6 1. UVOD 1.1. PREDSTAVITEV PROBLEMA Zaposlen sem v podjetju, ki se ukvarja z razvojem informacijskih rešitev. Zadolžen sem za administracijo podatkovnih baz. Aplikacijske rešitve in svetovanja nudimo kupcem na slovenskem trgu, predvsem podjetjem, ki uporabljajo strojno in programsko opremo enega največjih proizvajalcev tovrstne opreme na svetu. Za svojega največjega naročnika, iz katerega smo se tudi razvili, pa nudimo celovito IT storitev. V dolgoletnem sodelovanju je nastalo veliko aplikativnih rešitev, ki delno ali pa v celoti podpirajo praktično vsa področja delovanja tega podjetja. Razvoj delovnih procesov v celotnem podjetju in potrebe posameznih oddelkov so narekovali nastajanje vedno novih ter posodabljanje obstoječih aplikacij. V nekaterih primerih pa temu razvoju in spremembam posodobitve aplikativnih rešitev niso sledile. Najpogostejša težava, ki se je pri tem pojavljala, je, da s takšnimi aplikacijami ni bilo možno zajeti novih vrst podatkov. Okolje, kjer smo naleteli na takšno težavo, je bila tudi proizvodnja aluminijastih folij. Čeprav je obstoječi IS (informacijski sistem) na nek način podpiral vse operacije obdelave materiala v delovnem procesu, pa posodobitve niso sledile spremembam ključnih operacij, zato ni bilo možno zajeti vseh potrebnih podatkov. Ni omogočal ustreznega zapisa podatkov za postopek zdvajanja, kjer iz dveh enoplastnih kolobarjev folije dobimo dva dvoplastna. Uporabniki so si za zagotavljanje ustreznih podatkov v IS uvedli interno pravilo, da za zapis dvoplastnih navitij uporabijo oznako zgornje plasti. Vse ostale podatke so zapisovali v fizične mape, ki jih imenujejo knjige dela. Informacijsko pa se je podatek o spodnji plasti izgubil. Velik problem je bila tudi komunikacija z obdelovalnimi stroji in napravami, ki je IS ni omogočal. Na stroj ni bilo možno prenašati nastavitvenih parametrov, hkrati pa iz stroja ni bilo možno prenesti rezultatov obdelave. Podatke za nastavitev strojev so operaterji ročno vnašali v določena vpisna mesta na strojih, kar je bil pogosto vzrok za napačne nastavitve in posledično za neustrezno obdelavo. Zaradi nepopolnih podatkov je bilo onemogočeno izvajanje ustreznih analiz in statistik, ki bi morale biti osnova za sprejemanje kvalitetnih odločitev. Vse to se je odražalo v višjih stroških, v višji ceni končnega izdelka, zmanjšanju konkurenčnosti na tržišču in na koncu bi lahko privedlo do izgube posla. Stojan Erker: Programska rešitev za sledenje materiala stran 1

7 1.2. PREDSTAVITEV OKOLJA Podjetje, za katerega smo razvili programsko rešitev za sledenje materiala, se uvršča v kovinsko predelovano industrijo. Zaposluje več kot 280 ljudi, proizvodnja v letu 2015 pa je presegla ton valjanih izdelkov. Svoje izdelke prodajo predvsem na tujih trgih, večinoma evropskih, nekaj pa tudi na trgih Severne in Južne Amerike ter Azije. Program trakov, pločevin in rebrastih pločevin je namenjen za uporabo v avtomobilski industriji, gradbeništvu, transportu, elektroindustriji, strojegradnji in gospodinjstvu. Program folij pa je namenjen uporabi v živilski industriji, farmaciji, za različno tehnično uporabo in v gospodinjstvu. Podjetje je organizacijsko razdeljeno na več procesov, ki so shematsko prikazani na sliki 1. Vodstvo podjetja Prodaja Procesni inženiring Proces planiranja in logistike valjanih izdelkov Proizvodni proces RRT Proizvodni proces FTT Vzdrževanje Proces vzdrževanja v PP FTT Proces vzdrževanja v PP RRT Slika 1: Organizacijska shema podjetja V diplomskem delu smo se omejili predvsem na proizvodni proces folije in tanki trakovi (PP FTT). Vse delovne operacije, ki smo jih z aplikacijo za sledenje materiala podprli, so se nahajale v tem proizvodnem procesu. Stojan Erker: Programska rešitev za sledenje materiala stran 2

8 1.3. PREDPOSTAVKE IN OMEJITVE Cilj, ki smo ga s programsko rešitvijo za sledenje materiala želeli doseči, je bil izdelati delujočo spletno aplikacijo. Predpostavljalo se je, da bo z novo aplikacijo možno v podatkovno bazo zapisati vse podatke, ki so se že do tedaj zapisovali v obstoječi IS in vse tiste, ki so jih ročno vodili v knjigah dela. Vzpostaviti je bilo treba obojestransko komunikacijo med IS in računalniško vodenimi obdelovalnimi stroji. V smeri od IS k strojem je bilo treba pošiljati nastavitvene podatke in podatke za povezljivost, v smeri od strojev k IS pa je bilo treba podatke za povezljivost dopolniti s pripadajočimi rezultati obdelav. Komunikacija med sistemi je bila izvedena z mrežnimi storitvami. Upoštevati je bilo treba, da se delujoči IS ni ukinjal in da se zaradi uvajanja novih aplikativnih rešitev tudi ni smel dopolnjevati ali posodabljati. Ohraniti je bilo treba popolno operativnost vseh obstoječih programskih rešitev METODE DELA Da bi lahko izdelali tako kompleksno programsko rešitev, je bilo treba k razvoju pristopiti zelo sistematično in premišljeno. Upoštevati je bilo treba: zahteve naročnika, tehnične omejitve strojev in naprav, omejenost posodobitev obstoječega IS, velikost in izkušenost razvojne skupine, časovno omejitev. Najprej smo sestavili razvojno skupino, v kateri je poleg zaposlenih iz našega podjetja sodeloval še razvijalec za avtomatizacijo in procesni inženir valjanih izdelkov, kot predstavnik naročnika. Določili smo metodologijo za izgradnjo informacijskega sistema. Sprva smo izbrali zaporedno metodo model slapa. Po tej metodi si faze razvoja sledijo zaporedno; ko je prva zaključena, se lahko začne druga. Po tej metodologiji je bilo sorazmerno enostavno določiti posamezne faze in njihovo okvirno trajanje. Tako smo se lahko približali končnemu terminu, kar je bilo za skupino tudi velika spodbuda in motivacija. Sledila je faza analize, v kateri smo izvajali intervjuje s procesnim inženirjem. Pridobiti smo morali vse potrebne informacije o posameznih operacijah in delovnem procesu v celoti. Nato se je začela faza načrtovanja, ko smo na osnovi zbranih informacij in analiz, začeli načrtovati osnovne gradnike novega IS. Večkrat smo spoznali, da nimamo dovolj natančnih podatkov za izgradnjo določenega gradnika. Postopke intervjujev smo morali ponoviti, velikokrat pa smo morali na intervju povabiti odgovorne s področij, kamor so gradniki organizacijsko spadali. S tem smo pridobili nove informacije, ki so pogosto vodile k spremembi že zaključene analitike. To je seveda pomenilo obdelavo že zaključene faze izbrane metodologije. Zaradi tega se nam je podaljševal čas izgradnje posamezne faze. Posledično bi se zamaknil tudi končni rok, ki je bil ocenjen na osnovi metodologije. Lastnost zaporednosti metodologije je bila za naročnike zelo moteča. Ugotovili smo, da smo se zaradi razpršenega poznavanja delovnega procesa, morali prevečkrat vračati v predhodne faze. Stojan Erker: Programska rešitev za sledenje materiala stran 3

9 Sprejeli smo odločitev o izboru ustreznejše metodologije. Morala je biti vsaj tako poznana kot prva in brez omenjenih pomanjkljivosti. Tem pogojem je ustrezala metodologija postopnega naraščajočega razvoja IS, oz. kot je navedeno v Fowler in Scott (2000), inkrementalni model razvoja IS. Na osnovi zbranih informacij smo oblikovali vodilno usmeritev celotne izvedbe, ki se do zaključka ni spreminjala. Po analiziranju smo natančno definirali izhodišča in izdelali programske specifikacije procesov. Na osnovi teh specifikacij smo izdelali podatkovni model, ta pa je bil osnova za izgradnjo poslovne logike. V tej fazi so se začele vzporedno izvajati tudi aktivnosti za izgradnjo grafičnega vmesnika. V fazi konstrukcije smo za vsako iteracijo izdelali vmesne postopke analize, načrta in izvedbe določenega gradnika. Pomembne so bile tudi informacije o željah in pričakovanjih naročnika, ki so bile vodilo za izbiro sloga izgleda vizualnega dela programske rešitve. Gradili smo modularno, za posamezne operacije v delovnem procesu smo izdelali delujoč modul in ga vključili v testiranje. Manjše pomanjkljivosti smo odpravljali sproti, v nekaterih primerih pa so se pojavile tudi konceptualne napake. V takšnih primerih smo se morali vrniti do zapisov v analitiki ter preveriti skladnost med specifikacijo procesa in delovanjem programa. Večinoma se je izkazalo, da v intervjujih ni bilo podanih dovolj natančnih pojasnil o funkcionalnosti delovne operacije. Iz faze testiranja je bil za celotno programsko rešitev izveden prehod v produkcijsko uporabo. Tudi po prehodu je bilo izvedenih še veliko sprememb in dodatkov, vendar se ni bilo treba vračati na konceptualni nivo. Stojan Erker: Programska rešitev za sledenje materiala stran 4

10 2. TEORETIČNE OSNOVE 2.1. PODATKOVNA BAZA Eden izmed poglavitnih elementov v razvoju in implementaciji informacijskih sistemov je tudi podatkovna baza. Za naše potrebe uporabljamo podatkovno bazo DB2 proizvajalca IBM. Kot je navedeno v Alcad platforma (2016), je trenutno v operativni uporabi verzija DB2 Enterprise Server Edition version 10.1 for Linux, Unix, Windows, naložena na operacijskem sistemu Linux on IBM System Z, strojna oprema je IBM System Z. DB2 v bistvu združuje celoten sistem za upravljanje relacijske podatkovne baze RDBMS (Relational Database Management System) namenjen shranjevanju, analizi in učinkovitemu dostopu do podatkov. Kot je navedeno v (DB2 Spoznavanje, 2016), je zasnovan na medsebojni povezavi več gradnikov, nekateri med njimi so prikazani na sliki 2. Ob instalaciji DB2 se za vse nastavitvene parametre prenesejo privzete vrednosti. Lahko pa jih, odvisno od načina uporabe in izkušenj, ločeno nastavljamo. Slika 2: Shema arhitekture podatkovne baze DB2 (Vir: DB2 podatkovna baza, 2016) Za pristop do upravljanja s podatkovno bazo je treba znotraj RDBMS najprej kreirati instanco. V skladu z (DB2 Database Manger) je instanca logično okolje za DB2 DBM. Stojan Erker: Programska rešitev za sledenje materiala stran 5

11 V odvisnosti od uporabniških zahtev je lahko na enem fizičnem strežniku kreiranih več instanc, znotraj vsake instance pa je lahko definiranih več podatkovnih baz. Na sliki 3 je grafični prikaz organiziranosti instanc. Slika 3: Shematski prikaz zgradbe instanc v DB2 (Vir: DB2 Instanca, 2016) Podatkovne baze morajo biti poimenovane z edinstvenimi imeni. Vsaki bazi pripada še lasten nabor nastavitvenih datotek, nabor kataloških datotek, lastne avtorizacije in privilegiji. Istočasno je lahko aktivirana povezava samo z eno instanco (DB2 Instanca, 2016). Pridobivanje in zapisovanje podatkov na disk je izvedeno z uporabo medpomnilnika. Enota medpomnilnika (bufferpool) je del glavnega delovnega pomnilnika, ki ga definiramo in opredelimo s pomočjo baznega menedžerja. Podatki se v enoto medpomnilnika prenašajo po straneh (pages). Kot je navedeno v (DB2 bufferpool, 2016), je privzeta velikost strani 4 kb, v odvisnosti od aplikativnih zahtev pa lahko definiramo več različnih enot z različno velikimi stranmi (8 kb, 12 kb, 32 kb). Na vsako enoto je lahko vezan tabelni prostor (tablespace), to je shranjevalna struktura, ki vsebuje tabele, indekse, velike objekte in dolge podatkovne strukture. Sestavljen je iz enega ali več kontejnerjev, ki so definirani na fizični ravni. Kot je navedeno v (DB2 table spaces, 2016), so to lahko enota, imenik ali datoteka. Logična struktura podatkov, shranjenih v stolpcih in vrsticah, se v podatkovni bazi imenuje tabela. Vsak stolpec mora biti definiran vsaj z imenom in podatkovnim tipom, kot je navedeno v (DB2 tabele, 2016), pa obstaja še veliko drugih funkcijskih opredelitev (referenčna skladnost, različne omejitvene funkcije, privzete vrednosti...). Stojan Erker: Programska rešitev za sledenje materiala stran 6

12 2.2. APLIKACIJSKI STREŽNIK Enoto, kjer tečejo aplikacije, v skladu z Bagwell (2009) imenujemo aplikacijski strežnik. Deluje kot skupna infrastruktura, s pomočjo katere imajo delujoče aplikacije omogočen nadzorovan dostop do podatkov, zaščito in varovanje, komunikacijski dostop in transakcijsko integriteto. Koncept delovanja aplikacijskega strežnika, ki je prikazan na sliki 4, je bil v IBM zasnovan že v letu 1960, implementirali so ga v aplikacijskem strežniku CICS. Slika 4: Shema arhitekture aplikacijskega strežnika (Vir: Bagwell, 2009) Poglavitna prednost novejšega strežnika (WebSphere Application Server WAS) je v podpori odprtim standardom. Kot je navedeno v (Bagwell, 2009), so standardi dogovorjena pravila in predpisi, ki jih sprejmejo vsi ali pa velika večina različnih ponudnikov strežniških storitev, z namenom lažje integracije in boljšega skupnega delovanja. Na sliki 5 je shematski prikaz nekaterih standardov, ki so uporabljeni v lokalnem omrežju. Slika 5: Prikaz nekaterih standardov za uporabo lokalnega omrežja in interneta (Vir: Bagwell, 2009) Stojan Erker: Programska rešitev za sledenje materiala stran 7

13 Standardi, prikazani v rumenem okvirju, so implementirani v aplikacijskem strežniku. Vseh standardov je še veliko več, saj IBM sodeluje v večini delovnih skupin, ki razvijajo in potrjujejo te standarde. Drugi ključni segment WAS je Java nevtralna platforma. Java je v osnovi objektno orientiran programski jezik, ki ga je razvil Sun Microsystems. Za delovanje programov, razvitih s tem programskim jezikom, WAS uporablja okolje imenovano javanski navidezni stroj (Java Virtual Machine JVM). Slika 6 prikazuje JVM, ki je v bistvu programska implementacija računalnika ali strojne opreme. Področje, kjer tečejo Java aplikacije. Vsi JVM morajo proizvajati enak API. S tem je dosežena univerzalnost. Področje, kjer se izvajajo prevodi ukazov med Javo in OS. Slika 6: Javanski navidezni stroj JVM (Vir: Bagwell, 2009) Java teče znotraj javanskega navideznega stroja, navidezni stroj pa teče na katerikoli trenutno uporabljeni strojni opremi. Takšno neodvisnost mu omogoča sistemski kontrolni program (System Control Program SCP), ki je naložen skupaj z JVM in ukaze javanskih programov prevede v ukaze primarnega operacijskega sistema. Najvidnejši so trije tipi Java aplikacij, ki tečejo znotraj WAS: mrežne aplikacije Web Application so aplikacije, ki jih lahko odpiramo z brskalniki. Najpogosteje so to Java programi imenovani servleti in Java strežniške strani Java Server Page ali JSP. EJB aplikacije Enterprise Java Bean namenjeni so za bolj robustno in kompleksnejšo poslovno logiko. Sami nimajo neposredne interakcije z brskalniki, za to vlogo uporabljajo servlete. Najpogostejši obliki EJB aplikacij sta sejno zrno Session Bean in entitetno zrno Entity Bean. POJO Plain Old Java Object so preprostejše javanske strukture, nezahtevne za kreiranje, in kot je navedeno v Bagwell (2009), so med novejšimi elementi, implementiranimi v WAS. Pomembna naloga aplikacijskega strežnika je tudi pridobivanje podatkov. Za to funkcionalnost so prav tako uporabljeni odprti standardi, ki nam kompleksnost specifičnih postopkov prikrivajo za standardiziranimi vmesniki. Stojan Erker: Programska rešitev za sledenje materiala stran 8

14 Programsko kodo vmesnikov izdelajo proizvajalci podatkovnih baz sami. Na sliki 7 je shematski prikaz pristopa do različnih vrst podatkov znotraj JVM. Slika 7: JVM dostop do podatkov (Vir: Bagwell, 2009) Kot je navedeno v Bagwell (2009), je pridobivanje podatkov iz relacijskih baz (DB2, Oracle, Informix...), omogočeno preko standardnega vmesnika JDBC (Java Data Base Connection). Za pridobivanje podatkov iz nerelacijskih sistemov kot so CICS, IMS, SAP in podobni, se v WAS uporablja vmesnik JCA (Java Connector Ahitecture). Omeniti je potrebno še standardizirani vmesnik JMS (Java Messaging Service), ki se uporablja kot prenosni mehanizem za sporočila. Za generiranje sporočil je možno uporabiti MQ (Message Queue), WAS pa je privzeto opremljen s kreatorjem sporočil, ki temelji na Javi. Stojan Erker: Programska rešitev za sledenje materiala stran 9

15 2.3. TRISLOJNA ARHITEKTURA Aplikacijski strežnik in strežnik podatkovne baze sta temeljna gradnika implementacije trislojne arhitekture pri izgradnji aplikativnih rešitev. Koncept temelji na ločeni obdelavi treh ključnih plasti: predstavitvena plast, plast poslovne logike, podatkovna plast. Slika 8 nam prikazuje razporeditev plasti, tipične aplikacije po plasteh in smer podatkovnega toka. Slika 8: Implementacija trislojne arhitekture (Vir: Bagwell, 2009) Kot je navedeno v gradivu 3S arhitektura IBM (2016), je prva plast, imenujemo jo predstavitvena plast, namenjena vizualni podobi aplikacije in uporabniški interakciji. Na tej plasti se nahajajo vse forme za prikaz in vnos večine podatkov. Stopnja uporabnosti posameznega grafičnega vmesnika je odvisna od ergonomije specifičnih gradnikov vmesnika na spletni strani, zato na tej plasti ocenjujemo, ali je aplikacija uporabniku prijazna ali ne. Naloga aplikacijskega strežnika je, da se zahteve iz prve plasti prenesejo na naslednjo plast. To je plast poslovne logike. Tukaj se s pomočjo ustreznih aplikativnih komponent odvija večina procesov poslovne logike, ter se na nadzorovan in dovoljen način dostopa do storitev tretje plasti. Do te plasti lahko hkrati pride več zahtev po storitvah tretje plasti, zato mora biti vzpostavljeno ustrezno upravljanje s transakcijami. Tretjo plast imenujemo podatkovna plast. Iz te plasti se v plast poslovne logike posredujejo zahtevani podatki. Z drugo plastjo je zaščitena pred neposrednim dostopom različnih uporabniških komponent, tudi takšnim, ki temeljijo znotraj varovanega omrežja. Zahteve po podatkih lahko posreduje samo druga plast. Vse tri plasti med sabo komunicirajo po protokolih, ki jih podpirajo odprti standardi. Z ločitvijo teh plasti je omogočena večja učinkovitost in fleksibilnost aplikacij. Vsaka od treh plasti lahko teče na drugi strojni opremi, ni pa pogoj. Stojan Erker: Programska rešitev za sledenje materiala stran 10

16 2.4. PODATKOVNO MODELIRANJE Izgradnja aplikacij, združenih v različne informacijske sisteme, zahteva specifičen pristop v razvoju posameznih gradnikov teh aplikacij. Eden izmed poglavitnih gradnikov, ki se nahaja v podatkovni plasti trislojne arhitekture, je podatkovni model. Kot je navedeno v (Reingruber in Gregory, 1994), je podatkovni model abstrakcija stvari, s katerimi se v določenem poslovnem okolju vsak dan srečujemo. Koncept je postavil C. Finkelstein že leta Temelji na dejstvu, da je za izgradnjo kakovostnega podatkovnega modela potrebno poznavanje in razumevanje poslovne politike, poslovne strategije in poslovnih planov podjetja. Koncept vključuje teorijo relacijskih modelov, ki jo je objavil E. F. Codd leta 1990 in entitetno-relacijski model, ki gaje objavil P. Chen leta Po zbiranju podatkov se glede na vsebino poslovnih procesov začne faza prepoznavanja entitet. Poznanih je več definicij entitet, ki so jih napisali pionirji s področja podatkovnega modeliranja, med njimi C. J. Date, C. Finkelstein, J. Martin. Kot je navedeno v (Reingruber in Gregory, 1994), je entiteta definirana kot zbirka atributov, ki zadosti določenemu naboru pravil, vzpostavljenih za relacijsko modeliranje. V podatkovni bazi ima entiteta vlogo tabele. Naslednji korak je prepoznava atributov. Pomensko so povezani v entiteto in jo s tem opredeljujejo. Glede na karakteristike in vlogo v entiteti so atributi kategorizirani v dva tipa: ključ ali identifikator služijo kot primarni ključi (njihova vrednost je v entiteti unikatna), ali tuji ključi (opredeljujejo relacije z drugimi entitetami in njihova vrednost v entiteti ni nujno unikatna); opisni vsebujejo dodatne informacije in njihova vrednost v entiteti ni unikatna. Posamezni opisni atribut se lahko pojavi samo v eni entiteti v podatkovnem modelu. Entitete so preko atributov med sabo povezane. Povezujejo se atributi primarnega ključa neodvisne entitete z atributi tujega ključa odvisne entitete. Ta povezava se imenuje relacija. Brez prehoda primarnega ključa v odvisno entiteto relacija ne more obstajati. V skladu z Reingruber in Gregory (1994), je to hkrati tudi osnovno načelo referencialne skladnosti in eno izmed glavnih vodil podatkovnega modeliranja. Ključnega pomena pri opisu relacije in karakteristike povezave med dvema entitetama je kardinalnost. S tem je opisana stopnja ali števnost relacije, prikazana pa je s simboli na vsakem koncu povezave. Kardinalnost nam pove, koliko instanc enega objekta je povezanih oz. je v relaciji s koliko instancami drugega objekta. Slika 9 prikazuje relacije med objekti. Slika 9: Prikaz relacije več na več Stojan Erker: Programska rešitev za sledenje materiala stran 11

17 Da lahko entitete, atribute in relacije grafično prikažemo, je bilo razvitih več vrst notacij. Najpogosteje uporabljeni sta: crow's feet (Slika 10) Slika 10: Prikaz notacije crow's feet (Vir: IBM-notacija, 2016) IDEF1X (Slika 11) Slika 11: Prikaz notacije IDEF1X (Vir: IBM-notacija, 2016) Po postopku prepoznave entitet in atributov se izvede metoda klasifikacije in agregacije. S klasifikacijo se glede na skupne lastnosti, atributi razvrstijo v tipe (razrede), z agregacijo pa se na osnovi skupine klasifikacijskih tipov definira nov, skupni tip. Sledi metoda generalizacije, s katero se dvema tipoma (razredoma) določi nadtip (nadrazred). Pri uvajanju nadtipov se morajo upoštevati diskriminatorji, ki določajo, kakšne vrste podtipov združujejo. Kot je navedeno v Reingruber in Gregory (1994), so diskriminatorji najpogosteje tuji ključi. Stojan Erker: Programska rešitev za sledenje materiala stran 12

18 Definicija entitete temelji na pravilih za relacijsko modeliranje, ki jim morajo zadostiti atributi znotraj te entitete. Ta pravila nosijo tudi skupni naziv, imenujejo se normalne forme. Normalna forma in normalizacija je v svojem elementarnem smislu postopek preverjanja organiziranosti atributov, združenih v entiteti. Temelji na določenih vrstah odvisnosti med atributi in osnovni koncept normalizacije je funkcionalna odvisnost. V skladu z Reingruber in Gregory (1994, stran 262) je v relaciji R atribut Y funkcionalno odvisen od atributa X takrat, in samo takrat, ko vsaki vrednosti atributa X pripada natanko ena vrednost atributa Y. Atributa X in Y sta lahko sestavljena kompozitna. Poznamo več vrst funkcionalnih odvisnosti: delna funkcionalna odvisnost atribut relacije je odvisen od dela ključa relacije (možno pri sestavljenih ključih), polna funkcionalna odvisnost atribut relacije je odvisen od celotnega ključa relacije in hkrati ni odvisen od nobene podskupine katerega koli dela ključa tranzitivna funkcionalna odvisnost atribut relacije je tranzitivno ali posredno odvisen od ključa relacije. Če je atribut B funkcionalno odvisen od atributa A in je atribut C funkcionalno odvisen od atributa B, potem je atribut C posredno funkcionalno odvisen od atributa A. Pravila določajo organiziranost petih (5) normalnih form (NF) in Boyce Codd NF, ki je umeščena med 3NF in 4NF. Kot je navedeno v Reingruber in Gregory (1994), je izhodišče tabela, v kateri se ponavlja ena ali več skupin podatkov. Govorimo o ne normalizirani tabeli. Z različnimi metodami transformacij in razstavljanj, takšno tabelo prestrukturiramo v drugačno, vendar ekvivalentno obliko. Pri tem postopku se nobena informacija ne sme izgubiti. Tabela je v 1NF, ko so vse vrednosti atributov atomarne nerazstavljive in ni več ponavljajočih skupin podatkov. Tabela je v 2NF, če je v 1NF in je vsak opisni atribut, ki ni ključ, popolno funkcionalno odvisen od primarnega ključa. Tabela je v 3NF, če je v 2NF in za vsak opisni atribut, ki ni ključ, velja, da ni tranzitivno odvisen od primarnega ključa. Identificirati in odstraniti v drugo entiteto je potrebno vse tiste atribute, ki so kakorkoli odvisni od atributa ali atributov, ki niso primarni ključ. Normalizacija prinaša v podatkovno modeliranje več koristnih in pozitivnih učinkov. Nekatere poglavitne prednosti so: odprava ali minimiziranje redundance (podvajanje podatkov), zaščita pred izgubo informacij in nepredvidenimi rezultati poizvedb, minimiziranje številčnosti praznih (null) vrednosti, ki povzročajo težave pri dostopu do podatkov in uporabi nekaterih kolonskih funkcij npr. SUM, deljenje, odprava anomalij ob zapisu, popravljanju ali brisanju podatkov iz tabel. Postopek normalizacije je pri večjih relacijskih modelih lahko precej zapleten. V veliko pomoč pri tem so strokovnjaki iz področja, za katerega se bo izdeloval informacijski sistem. Zaradi detajlnega poznavanja svojega področja lahko ti strokovnjaki natančno definirajo prave funkcionalne odvisnosti med posameznimi atributi v entitetah. Kot je navedeno v Reingruber in Gregory (1994), je sodelovanje vzajemno, saj jim s sistematičnim pristopom in s poznavanjem različnih metod in tehnik normalizacije, omogočamo odkrivanje dodatnih zahtev in pravil za izboljšanje postopkov pri doseganju poslovnih ciljev. Stojan Erker: Programska rešitev za sledenje materiala stran 13

19 2.5. METODOLOGIJA RAZVOJA IS Razvoj informacijskih sistemov že dolgo časa velja za inženirsko vedo, ki je s strukturnim pristopom v razvoj IS vpeljala dosledno izvajanje analize in načrtovanja. Kot je navedeno v gradivu Strukturni pristop (2016), se je strukturni pristop oblikoval že v sedemdesetih letih in se skozi leta izpopolnjeval, dokler se v devetdesetih letih ni pojavil nov pristop, ki je temeljil na objektih in objektnih metodologijah. Razvoj IS sledi določenemu življenjskemu ciklu, ki ga sestavlja zaporedje določenih faz. Aktivnosti, ki so združene v teh fazah, lahko pojmujemo tudi kot metodologijo razvoja IS. Kot je navedeno v gradivu Metodologija (2016), nam sama definicija metodologije pove, da je metodologija pravzaprav vse, kar redno počnemo, da bi dosegli želen rezultat, torej izdelek ali storitev, ki je cilj našega dela. Strukturni razvojni modeli so največkrat sestavljeni iz analize, načrtovanja, izvedbe in vpeljave. Med sabo se razlikujejo po podrobnejši delitvi faz in v zaporedju ter načinu izvajanja. Razvojni modeli, ki so značilni za strukturni pristop razvoja IS, so: zaporedni, iterativni prototipni, inkrementalni oz. naraščajoči. Metodologija zaporednega razvojnega modela, ki jo prikazuje slika 12, se je razvila že v sedemdesetih letih. Kot je navedeno v gradivu Zaporedni model (2016), je ena od najstarejših metodologij strukturnega pristopa. Slika 12: Zaporedni razvojni model model slapa (Vir: Zaporedni model, 2016) Stojan Erker: Programska rešitev za sledenje materiala stran 14

20 Značilnost te metodologije je, da se faze ne prekrivajo in se naslednja začne, ko se predhodna konča. V začetnem obdobju uporabe, je z natančno definiranimi aktivnostmi posameznih faz in prehodov med njimi, predstavljal osnovo za izgradnjo kompleksnih aplikacij. V današnjem času pa je ta lastnost, njegova največja slabost. Nikoli namreč ne velja, da bi popolnoma zaključili eno fazo in nato prešli na naslednjo, ampak je pogosteje potrebno med fazami prehajati iz naslednje v predhodno. Po zaporedni metodologiji pa prehod nazaj, v zaključeno fazo, ni mogoč. Kot je navedeno v Zaporedni model (2016), je to pri sedanjem razvoju zelo moteče, saj se je potrebno velikokrat iz faze izgradnje, vrniti tudi do analize, da bi lahko v razvoj vključili še zadnja pridobljena spoznanja. Metodologija iterativnega razvojnega modela se je razvila kot posledica uporabe osebnih računalnikov v osemdesetih letih, ko so pri hitrem razvoju aplikacij na novih tehnologijah, vse bolj sodelovali tudi uporabniki. Kot je navedeno v Prototipni model (2016), so se to metodologijo prvič pojavili tudi prototipi, ki so tej metodologiji prinesli dodatno prednost. Danes se prototipi uporabljajo domala v vsakem razvojnem modelu, na tej osnovi pa se je razvil tudi prototipni razvojni model, prikazan na sliki 13. Slika 13: Prototipni razvojni model (Vir: Prototipni model, 2016) Stojan Erker: Programska rešitev za sledenje materiala stran 15

21 Prototipi so navadno nepopolne in poenostavljene verzije sistema ali aplikacije. Razvita so tudi namenska orodja za hiter razvoj prototipov, pri katerem tesno sodelujeta analitik in uporabnik. Po uskladitvi aplikativnih zahtev, analitik izdela prototip in ga preda v testiranje uporabniku. Povratna informacija analitiku služi za pripravo nove verzije prototipa. Kot je navedeno v Prototipni model (2016), se postopek ponavlja do ustreznosti delovanja prototipa oz. verifikacije ustreznosti delovanja. Po metodologiji prototipnega razvojnega modela so prototipi vmesna faza in se na koncu zavržejo. Obstajajo pa že metode, ki takšne prototipe izkoristijo za sestavo produkcijskega sistema (Rapid Aplication Development RAD). Metodologija inkrementalnega ali postopnega razvojnega modela, prikazana je na sliki 14, v skladu z gradivom Inkrementalni model (2016), razdeli celoten sistem na module, ki jih nato samostojno razvijamo, neodvisno od ostalih. Slika 14: Inkrementalni razvojni model (Vir: Fowler, Scott, 2000) Moduli so kot del funkcionalnosti celotnega sistema dovolj samostojni, da se jih po zaključeni fazi konstrukcije vključi v produkcijo. Z njimi na koncu pokrijemo celotno funkcionalnost aplikacije in zaključimo razvoj. Vsak modul je lahko samostojni podprojekt, kar prikazuje slika 15. Slika 15: Modul kot podprojekt (Vir: Inkrementalni model, 2016) Stojan Erker: Programska rešitev za sledenje materiala stran 16

22 Kot je navedeno v gradivu Inkrementalni model (2016), je delitev na module odvisna od pomembnosti posamezne funkcionalnosti, lahko pa tudi en modul pokriva eno funkcionalno področje. Prednost takšnega razvoja je, da lahko posamezne module sorazmerno hitro predamo v uporabo. Na ta način se morebitne pomanjkljivosti hitreje odkrijejo in tudi odpravijo. Poznamo prednosti in slabosti omenjenih formalnih metodologij, vendar pa veliko računalniških podjetij razvija informacijske sisteme po neformalno opredeljenih metodologijah. Da bi poiskali ravnovesje med formalno in neformalno metodologijo, skušajo doseči ustrezno prilagodljivost, ki bo najprimernejša za konkreten primer. Prilagodljivost in učinkovitost pa sta osnovni lastnosti novim agilnim metodologijam. Kot je navedeno v (Agilne metodologije, 2016), so temelje agilnih metodologij postavili v letu 2001, ko je skupina sedemnajstih vodilnih na področju metodologij (Adaptive Software Development, XP Extreme Programming, Feature-Driven Development, Crystal, Scrum, Dynamic System Development Method idr.) postavila nove trende razvoja agilnih metodologij. Določili so osnovna načela agilnih tehnologij: posamezniki in njihova komunikacija so pomembnejši kot sam proces in orodja, delujoča programska oprema je pomembnejša kot popolna dokumentacija, vključevanje (sodelovanje) uporabnika je pomembnejše kot pogajanje na osnovi pogodb, upoštevanje sprememb je pomembnejše od sledenja planu. Iz naštetih načel je izpeljanih veliko priporočil, ki jih upoštevajo vse agilne metodologije in so v pomoč pri izgradnji ter vrednotenju metodologije. Našteli bomo samo nekaj delov teh priporočil: zadovoljstvo naročnika je najvišja prioriteta, projekti naj vključujejo motivirane posameznike, enostavnost procesa je ključ do uspeha, kakovost programske kode in arhitekture je treba nenehno preverjati in izboljševati. Razvojne skupine imajo na razpolago širok nabor različnih metodologij, zato lahko ocenijo in izberejo takšno, oziroma prilagodijo obstoječo, ki najbolj ustreza značilnostim projekta in razvojne skupine. Stojan Erker: Programska rešitev za sledenje materiala stran 17

23 3. OBSTOJEČE STANJE Poslovno informacijski sistem, ki podpira procese v proizvodnji folij, deluje na strojni opremi IBM System z in na operacijskem sistemu z/vse v.5. Aplikacije so razvite z razvojnim orodjem IBM VisualAge Generator, tečejo pa na aplikacijskem strežniku IBM CICS. Podatkovna baza (opisana v poglavju 2.1.) ima samo eno instanco in je skupna vsem delujočim produkcijskim programom in strežnikom. Uporabljena je klasična klient-strežnik arhitektura, ki izvira še iz 80. let, le da so terminale IBM 3270 nadomestili osebni računalniki in prenosniki, za emulacijo terminala pa je uporabljen program Personal Communication različica 5.8 za Windows. Omenjena infrastruktura je robustna in ima določene omejitve glede razvoja in posodobitev, njeno delovanje pa je odzivno, hitro in stabilno. Obstoječi PIS se je razvil pred več kot desetimi leti in se je od takrat nenehno dopolnjeval. Uporabniki so navajeni green-screen 1 aplikacij, ki so tipične menijske aplikacije. Vhodni meni v eno od področij PIS je prikazan na sliki 16. Slika 16: Prikaz vhodnega menija Uporabniki morajo za dostop do posamezne funkcije iz menija pridobiti dovoljenje, ki ga potrdi njihov nadrejeni ali druga odgovorna oseba v podjetju. 1 Tipična slika terminala IBM 3270, zelena pisava na črni podlagi. Stojan Erker: Programska rešitev za sledenje materiala stran 18

24 3.1. POSNETEK STANJA Proizvodnja aluminijastih folij poteka po predpisanih proizvodnih postopkih. V odvisnosti od naročil kupcev tehnologi izdelajo navodila za izdelavo naročenih izdelkov. Ta navodila se imenujejo tehnologija izdelave. Izdelki, ki so v PIS oštevilčeni in poimenovani identi, se med seboj razlikujejo po specifičnih lastnostih: obdelavi npr. hladno valjano, toplo valjano, nazivu npr. folija 20 50,99 ali folija 6 8,99 (6 8,99 je debelina v µm), zlitini, dimenzijskem razredu npr. trakovi, folije, pločevine, stanje materiala npr. trdo, pol trdo, mehko, stanje površine npr. z ene strani svetla, z druge strani mat. Vseh lastnosti, s katerimi so izdelki opisani, je še veliko več, vendar pa sprememba najmanj ene od zgoraj naštetih povzroči nastanek novega izdelka. Več različnih izdelkov, ki so si glede na določene lastnosti sorodni, je lahko izdelanih po enaki tehnologiji. Tehnologija izdelave je po svoji vsebini vrstni red operacij na strojih in napravah, na katerih se mora vhodni material obdelati, da bo iz surovine nastal naročen izdelek. Na sliki 17 je prikazan del tehnologije, za izdelek FOLIJA 6 8,99, kjer so prikazane operacije s pripadajočimi parametri posameznih obdelav. Parametri obdelav so določeni glede na specifične lastnosti vhodne surovine. Slika 17: Prikaz ekranske maske z delom tehnologije za izdelek Stojan Erker: Programska rešitev za sledenje materiala stran 19

25 Za enak izdelek, ki bi ga izdelali iz surovine z drugačnimi dimenzijami, je sestavljena druga tehnologija. Na sliki 18 so prikazani parametri obdelave na prvi operaciji, ki se zaradi različne vhodne surovine razlikujejo od parametrov prve operacije iz slike 17. Slika 18: Prikaz dela tehnologije za enak izdelek z drugačno surovino Poznamo več vrst tehnologij: matična tehnologija, operativna tehnologija, tehnologija za delovni nalog. Matična tehnologija vsebuje glavno zaporedje delovnih operacij in je osnova za vse ostale tehnologije. Operativna tehnologija je izpeljana iz matične tehnologije in je povezana z naročilom ter postavko naročila. Ta tehnologija nima vpliva na postopke pri sledljivosti materiala. Tudi tehnologija delovnega naloga je izpeljana iz matične tehnologije, vendar pa je tukaj možno izvajati spremembe operacij in njihovega zaporedja. Spremembe so potrebne bodisi zaradi zasedenosti ali ne operativnosti strojev bodisi zaradi združevanja delovnih nalogov ali pa kakšnega drugega vzroka (vzorci, testiranja). Združevanje delovnih nalogov je postopek, ko se kolobar folije na določeni operaciji prenese na drug delovni nalog, zaradi ustreznejše tehnologije glede na izdelek. Surovina za izdelavo folije je aluminijasti trak, navit na jekleni tulec. Masa takšnega navitja ali kolobarja je lahko od 1 t do 12 t in dimenzijsko ustreza zahtevam obdelovalnih strojev. V proizvodnem procesu ga poimenujemo transportna enota (TRE). Pred začetkom obdelave se vsi kolobarji nahajajo v surovinskem skladišču. Sem prispejo po običajnih nabavnih postopkih in so opremljeni s proizvajalčevimi specifikacijami kemijskih, mehanskih in dimenzijskih lastnosti. Postopek prevzema je dvofazen, najprej se izvede količinski ali kvantitativni prevzem. V tej fazi se preveri ustreznost surovine po dokumentaciji in najpomembnejše za to fazo, če dobavljena količina ustreza naročeni količini. Druga faza prevzema je kakovostni prevzem. V tej fazi se ugotavljajo kakovostne karakteristike dobavljene surovine. Če surovina ustreza vsem zahtevanim kriterijem, skladiščniki izvedejo prevzem v skladišče. V nasprotnem primeru se izdela reklamacija. S prevzemom se TRE določi tudi štirimestna zaporedna številka in se zapiše v podatkovno bazo. Stojan Erker: Programska rešitev za sledenje materiala stran 20

26 Poslovna logika v PIS poskrbi, da se v proizvodnem procesu hkrati ne nahajata dve TRE z enako številko. Na sliki 19 so prikazane podrobnosti kolobarja pred kakovostnim prevzemom. Štirimestna številka še ni prikazana, ker se poišče in dodeli šele v trenutku zapisa v PB. Prevzem in s tem zapis podatkov v PB se izvede s pritiskom na tipko F4. Slika 19: Ekranska maska za prevzem surovine v skladišče surovine S tem postopkom je TRE informacijsko dostopna tudi v proizvodnem delu informacijskega sistema. Planerji, ki sestavljajo delovne naloge, lahko od tega trenutka naprej, TRE povežejo z delovnim nalogom. Iz informacijskega stališča je delovni nalog 4 do 5 mestno število, na nivoju tabele v PB določeno kot del primarnega ključa, ki združuje količino povsem enakih izdelkov iz ene ali do treh postavk iz istega ali do treh različnih naročil. Slika 20 prikazuje sestavljen kompozitni primarni ključ tabele DELNALOG, ki je sestavljen iz treh atributov, vsi ostali atributi v tabeli pa so od njega funkcijsko odvisni. Slika 20: Primarni ključ tabele DELNALOG Stojan Erker: Programska rešitev za sledenje materiala stran 21

27 V kolono LETODN se zapisuje leto nastanka delovnega naloga. Kolona DELNAL zavzema vrednosti od 1000 do in se v obdobju do treh let ponovijo. Kolona VARDELN pomeni varianto ali verzijo delovnega naloga, vrednosti v koloni so velike tiskane črke. Tabelo DELNALOG vključno s primarnim ključem sestavlja 105 kolon. Združuje podatke o naročenih količinah, izdelanih količinah, različnih karakteristikah izdelka, dimenzijah, posebnih zahtevah, začetnih in končnih terminskih enotah ter ostalo. Na sliki 21 je prikazana ekranska maska s podatki o delovnem nalogu (DN). Namenjena je predvsem spremljanju različnih skupnih količin, vezanih na DN (izdelano, odpadek, stanje ). Slika 21: Prikaz podatkov iz tabele DELNALOG Vse podatke o delovnem nalogu v PIS vpisujejo planerji. Ko so vsi zahtevani podatki vpisani, se izvede povezava delovnega naloga s transportno enoto in operacijo tehnologije. V primeru, da je to začetna operacija, zaporedna številka operacije je 0 ali 1, potem se ta postopek imenuje lansiranje delovnega naloga. V okviru enega DN je lahko na eno operacijo vezanih več TRE. Število TRE je odvisno od naročene količine ali pa od postopka izdelave, po katerem je za več naročil del tehnologije enak. Ko planerji DN lansirajo v proizvodni proces, ga najprej pregledajo terminerji, ki preračunajo, kdaj morajo začeti z obdelavo, da bo proizvodni proces pravočasno zaključen. Načeloma se ti procesi odvijajo nekaj dni, zato je zelo pomembno, kdaj operaterji na strojih prejmejo zahteve za začetek proizvodnje. Terminerji izpišejo delovno dokumentacijo in jo predajo delovodjem, ti pa sezname dnevnih zahtev in delovnih nalogov razdelijo operaterjem na strojih. Stojan Erker: Programska rešitev za sledenje materiala stran 22

28 Na sliki 22 je prikazan DN 95714, varianta A, na katerega so vezane 4 TRE. Vse TRE se nahajajo na operaciji z zaporedno številko 0 in na stroju s šifro 0000 in nazivom START. Slika 22: Prikaz DN in pridruženih TRE na operaciji 0 Na ekranskih maskah so prikazani podatki, ki so zapisani v različnih tabelah v PB. Tabele, prikazane na sliki 23, so le del celotnega podatkovnega modela. V tem izseku so prikazane ključne tabele za obstoječi sistem sledenja materiala po proizvodnem procesu. Slika 23: Del podatkovnega modela za DN in TRE na operaciji Stojan Erker: Programska rešitev za sledenje materiala stran 23

29 Vsebina in namen tabel (razen tabele DELNALOG, ki je že bila omenjena): DNTEHNGL in DNTEHNOP glava in postavka vsebujeta podatke o tehnologiji delovnega naloga, nista namenjeni za trajno shranjevanju podatkov; TT_STROJI šifrant strojev, namenjena trajnemu shranjevanju podatkov; KTPROIZV in KT_TRANSE kontrolna točka proizvodnje in TRE na kontrolni točki (KT), nista namenjeni za trajno shranjevanju podatkov; KT_KNJIGE nekakšno zlitje osnovnih podatkov tabel KTPROIZV, KT_TRANSE in DELNALOG namenjena trajnemu shranjevanju podatkov. Tehnologija delovnega naloga ne vsebuje operacije z zaporedno številko 0 in strojem s šifro 0000 START, kar je razvidno iz slike 24. Slika 24: Prikaz začetnih operacij tehnologije za DN (Vri: lasten) DN in TRE, ki se nahajajo na operaciji 0, čakajo na sprostitev strojev na 1. operaciji. Na isti stroj lahko čaka več TRE iz več DN in z različnimi zaporednimi številkami operacij. Na prosti stroj se bo pomaknila tista TRE in celoten DN, ki ima glede na naročila višjo prioriteto. V primeru, da ni izrazite prioritete, se na stroj prestavi tista TRE, za katero je treba minimalno spreminjati nastavitve obdelave. Prenos TRE na operacijo z zaporedno številko 1 opravi terminer ali delovodja, vse nadaljnje prenose pa izvršijo operaterji na strojih. Na nivoju PB se s prenosom TRE iz ene operacije na drugo izvedejo programi, ki v tabele zapišejo nove in spremenijo obstoječe podatke. Celotna operacija prenašanja za dodajanje in spreminjanje prvenstveno vključuje 3 tabele: KTPROIZV, KT_TRANSE, KT_KNJIGE. Iz tabel DNTEHNGL in DNTEHNOP poiščemo podatke za naslednjo operacijo. V tabelo KT_KNJIGE zapišemo podatke o trenutni operaciji. Za tabelo KTPROIZV v prvi fazi izvršimo pregled, ki pove, ali zapis z zaporedno številko naslednje operacije za DN, že obstaja. Če obstaja, povečamo količino skupnega materiala in komadov na tej operaciji. V nasprotnem primeru izvedemo zapis novih podatkov. V KT_TRANSE pa zapišemo podatke za naslednjo operacijo in izbrišemo podatke za sedanjo operacijo. V pogojih delnih prenosov količine za eno TRE je akcija prenosa za tabelo KT_TRENSE podobna akciji prenosa za tabelo KTPROIZV. Po prenosu vseh TRE na naslednjo operacijo se podatki za predhodno operacijo v tabeli KTPROIZV izbrišejo. Stojan Erker: Programska rešitev za sledenje materiala stran 24

30 Slika 25 prikazuje ekransko masko za prenos TRE iz ene operacije na drugo. Številko trenutne operacije (podatek ob napisu Operacija_1) je poleg delovnega naloga in variante treba vpisati ročno. Te vrednosti so vhodni podatki poizvedbe za prikaz TRE na trenutni operaciji in po tehnologiji predvidene naslednje operacije. Slika 25: Ekranska maska za prenos TRE med operacijami Po vpisu indikatorja P, mase in komadov se s tipko F2 sproži predhodno opisan postopek prenosa TRE. Na sliki 26 je prikazana TRE, ki je bila prenesena in se nahaja na operaciji 1, na stroju 3103 B3 BISTRAL 3. Slika 26: Prikaz TRE prenesene iz operacije 0 na operacijo 1 Celoten delovni proces izdelave aluminijastih folij sestavlja veliko število strojev in naprav. Na določenih strojih se obdelovalni postopki tudi večkrat ponovijo ali pa se TRE, po obdelavi na drugi napravi, vrne nazaj na predhodni stroj. Stojan Erker: Programska rešitev za sledenje materiala stran 25

31 Slika 27 prikazuje zaporedje obdelav od vhoda do skladiščenja. Slika 27: Proizvodni proces izdelave folij Za različne izdelke so potrebne različne tehnološke poti. Opisane so z zaporedjem operacij v tehnologiji. Stojan Erker: Programska rešitev za sledenje materiala stran 26

32 Po zaključeni obdelavi na določenem stroju se TRE po opisanem postopku prenese na naslednji stroj. Enak postopek velja za vse stroje in naprave v proizvodnem procesu, do zadnje operacije v tehnologiji. Po zadnji operaciji, najpogosteje je to pakiranje, v tabelah KTPROIZV in KT_TRANSE za TRE in DN ni več nobenega zapisa. Za sledljivost ostajajo zapisi le v tabeli KT_KNJIGE. Vendar pa tudi v to tabelo ne gredo vsi želeni podatki, zato si zaposleni na vsakem stroju vodijo fizično knjigo dela. Te knjige, primer za stroj B3 je prikazan na sliki 28, so prirejene za beleženje dogovorjenih podatkov za vsak stroj posebej. Slika 28: Knjiga dela za stroj B3 To so tiskani prazni obrazci, speti s spiralnim trakom, ki jih zaposleni v proizvodnji izpolnjujejo, poslovna sekretarka pa arhivira. V knjige dela zapisujejo vmesne in končne rezultate obdelav ter sprotna opažanja na obdelovanem materialu. Treba je poudariti, da je zapisovanje v knjige dela dokaj zamudno opravilo in se največkrat ne izpolnjuje sproti. Knjige dela so edina povezava z dogajanji na operacijah, ko se iščejo in analizirajo vzroki reklamacij. Takšne analize so zelo zamudne, saj je treba pregledati več knjig, da si analitik lahko ustvari sliko o poteku materiala skozi proizvodni proces. Stojan Erker: Programska rešitev za sledenje materiala stran 27

33 3.2. KRITIČNA ANALIZA Obstoječi IS je nastal pred več kot desetimi leti. Kljub nenehnim popravkom in dopolnitvam je pri informacijski podpori proizvodnje aluminijastih (Al) folij, zaznanih več slabosti in pomanjkljivosti. Vsaka od njih ima določen vpliv na kvaliteto informacijskega sistema kot celoto. Med poglavitne pomanjkljivosti sodi dejstvo, da z obstoječimi aplikacijami ne moremo zajeti podatkov, ki nastajajo v proizvodnem procesu. Tukaj sta v ospredju dve operaciji: valjanje, zdvajanje. Namen valjanja Al folije je, da se ji s to operacijo postopno zmanjšuje debelina (posledično se mu povečuje dolžina). Končno dimenzijo dosežemo z večkratnim prehodom TRE skozi obdelavo. Pri vsakem prehodu nastane veliko pomembnih podatkov, ki jih pa PIS ne beleži. Zaposleni si za zagotavljanje minimalne sledljivosti, vodijo knjige dela, kar je naslednja slabost. Zdvajanje je postopek, s katerim iz dveh enoplastnih navitij dobimo dve dvoplastni navitji. V dve plasti zdvojimo polovico ene TRE, s polovico druge TRE. Enako velja za drugi dve polovici. V PIS lahko vpišemo atribute samo ene TRE, zato se podatki o drugi plasti povsem izgubijo. Sledljivost je ponovno zapisana v knjigah dela. Naslednja velika slabost se kaže pri prenašanju TRE iz enega delovnega nalog na drugi delovni nalog. Pri tem postopku se zaradi strukture tabel izgubi unikatna povezava do postopkov, ki so bili do prehoda na drugi delovni nalog že opravljeni. Enaka slabost se pokaže, ko je treba TRE začasno odstraniti iz proizvodnega procesa zaradi delne neustreznosti. Informacijsko se iz tabel za prenos po kontrolnih točkah (KT_TRANSE, KTPROIZV) vsi podatki o konkretni TRE izbrišejo in se zapišejo v IS za motnje. Ko se takšna TRE ponovno vrne v proizvodni proces, ni nobenih podatkov o predhodnih operacijah. Velik problem za terminerje predstavlja tudi iskanje za delovni proces ustreznih TRE v IS za motnje. V času vse večje povezljivosti je zelo moteče tudi dejstvo, da na tej platformi brez dodatnih produktov, ni možno izvesti komunikacije z računalniško vodenimi stroji s pomočjo mrežnih storitev. Pri ročnem prepisovanju podatkov prihaja do velikega števila nenamernih napak, ki so navadno prepozno odkrite. Zaradi nepopolnih podatkov so zelo otežene tudi statistike in analize, rezultati pa imajo nizko stopnjo zaupanja. Reševanje reklamacij poteka z veliko ročnega iskanja podatkov po knjigah dela, kar je zelo naporno in zamudno. Našteli smo samo nekaj najopaznejših slabosti in pomanjkljivosti, vseh je verjetno veliko več. Vse omenjene lastnosti so zgolj posledica enega generalnega problema. Prišli smo do zaključka, da se PIS v predhodnem obdobju ni posodobil sistematično, ampak se je posodabljal in dopolnjeval parcialno in nepovezano. Tudi podatkovni model se ni posodabljal. Določeni deli so še iz osemdesetih let, ko so se razvili prvi zametki PIS. Takrat je zasedenost delovnega pomnilnika predstavljala nekaj drugega kot danes. Enako velja za procesorsko moč in diskovni prostor. Dopolnitve, ki so bile izvedene, so navadno reševale lokalni problem, brez upoštevanja vplivov na celoto. Načeloma so to bili projekti brez kakršnekoli klasične metodologije. V tabele so se dodajali stolpci po potrebi, kar je pač bilo implementirano na ekranski maski. Manjka tudi veliko kontrol, zato je v tabelah veliko nekonsistentnih in redundantnih podatkov. S programsko rešitvijo za sledenje materiala smo s sistematičnim pristopom in ustrezno metodologijo, postavili temelje in izhodišča za posodobitve tudi na ostalih področjih poslovanja podjetja. Stojan Erker: Programska rešitev za sledenje materiala stran 28

34 4. PRENOVA Danes si praktično ne moremo predstavljati, da bi neko podjetje, ki zaposluje nekaj manj kot 300 delavcev, delovalo brez informacijskega sistema. Postopkov in opravil, ki jih je treba opraviti, je preveč, da bi jih opravljali ročno ter bili kljub temu konkurenčni na zahtevnem tržišču. Povsem enako je pri našem naročniku. Razširjenost uporabe računalniških aplikacij, ki so danes posredno ali neposredno prisotne praktično na vsakem področju delovanja, je že zdavnaj prešla iz uporabe zgolj za evidenco v pravo odvisnost. Sistemi so vedno bolj povezani in med seboj odvisni. Če v IS ni zabeležene zaloge za surovino, ni možno izdati delovnega naloga, čeprav je veliko naročil. Če v sistemu ni kupčevega naročila, ni možno izpisati fakture. To so le grobe odvisnosti, ki so zelo markantne in neposredno vplivajo na delovanje podjetja. Vsaka pomanjkljivost je hitro opazna, saj se razmere trgovanja hitro spreminjajo in je potrebno temu primerno posodabljati in prenavljati tudi IS. Precej drugačna je situacija v proizvodnem procesu. Obstoječi IS, ki je bil in je v veliki meri še v uporabi, je bil za proizvodnjo velika pridobitev. Čeprav je to bilo že pred več kot desetimi leti, je z nekaterimi popravki in manjšimi dopolnitvami vzdržal do današnjih dni. Zaposleni so ga sprejeli takšnega, kakršen je, in s stereotipnim prepričanjem, da se tako ali tako ne da kaj veliko spremeniti. Iz tega izhaja tudi dejstvo, da so si svoj delovni proces prilagodili tako, da je v kar največji meri ustrezal zahtevam IS. Tudi prve zahteve za dopolnitve iz tega okolja, niso bile neposredno povezane s sledenjem materiala po proizvodnem procesu kot celoti, ampak samo za določeno operacijo. Veliko težav so namreč imeli z označevanjem TRE v procesu žarenja. Postopek se odvija v žarilnih pečeh, kjer so TRE izpostavljene temperaturi nad 300 ºC, dlje kot 100 ur. Želja je bila, da bi na vsako takšno TRE, nalepili etiketo s črtno kodo, ki bi na nek način združevala identiteto in lokacijo TRE ter omogočala ustrezno prepoznavanje tudi po žarenju. Do sedaj so zaradi razmer v pečeh, uporabljali posebna pisala in ročno napisane oznake, ki niso bile računalniško berljive. To je povzročalo precejšnje težave pri identifikaciji in iskanju ustreznih TRE za nadaljnjo obdelavo. Vključili smo se v reševanje omenjene problematike in v prvi fazi izvedli analizo stanja. Izbrali smo metodologijo zaporednega razvojnega modela in poskušali zaključiti prvo fazo in čim prej preiti na načrtovanje. Vendar pa je analiza pridobljenih podatkov in informacij pokazala, da je skoraj nemogoče izdelati rešitev, ki bi podpirala samo to operacijo v delovnem procesu. Vzrok so bili neustrezni podatki, ki so prišli iz predhodnih operacij. Ponovno smo izvedli zbiranje podatkov, sedaj v širšem obsegu in ugotovili, da je neskladje med IS in dejanskim procesom preveliko, da bi nastalo situacijo lahko reševali z majhnimi, nepovezanimi rešitvami. Predlagali smo prenovo dela informacijskega sistema, ki zajema sledenje TRE po proizvodnem procesu. Uporabniki so se s predlaganim strinjali in začeli smo z izgradnjo programske rešitve za sledenje materiala. Formalne postopke in dokumente za začetek projekta so zagotovili v managementih vseh vključenih strani, razvojna skupina pa je dobila na razpolago čas in ljudi za razvoj aplikacije. Stojan Erker: Programska rešitev za sledenje materiala stran 29

35 4.1. ANALIZA Na prvih sestankih smo se kot formalna razvojna skupina najprej seznanili s problematiko, ki je bila prisotna na področju sledenja materiala. Določili smo metodologijo, po kateri bomo razvijali IS in se odločili za zaporedni razvojni model. Začeli smo s fazo analize in najprej pregledali, do kolikšne mere so bili zbrani podatki iz analiz predhodnih projektov. Analize so se nanašale predvsem na posamezne operacije, zato za sedanje stanje niso bile najprimernejše. Podatke in informacije smo pridobivali z intervjuji in prihajali smo do vedno novih spoznanj o samem poteku dela v proizvodnem procesu. Konkretni tehnološki parametri posameznih obdelav nas seveda niso zanimali, pomembno pa je bilo dejstvo, da se želena debelina ne doseže v enem prehodu, ampak na več prehodih. Dobljene podatke smo sproti pregledovali in sestavljali delne zaključke. Na začetku smo se širše usmerili v vrednost oz. število, ki predstavlja transportno enoto. Vsi smo že do sedaj vedeli, da je oznaka TRE v bistvu štirimestno število med 1000 in Prav tako je bilo znano, da se v nekem časovnem obdobju ponovijo, prikaz ponavljanja TRE, je prikazan na sliki 29. Slika 29: Ponavljanje TRE 4661 po letih Prišli smo do zaključka, da je TRE kot število lahko samo atribut neke entitete in mora biti popolnoma odvisen od primarnega ključa te entitete. Ta primarni ključ oz. meta atribut, smo poimenovali DOSJE. Glede na dogovore in interna pravila našega podjetja pa morajo imeti vse novejše tabele za primarni ključ kolono, ki je vrednostno določena z avtomatskim številčenjem ob zapisu podatkov. Takšno vlogo bo v tabeli dobil tudi dosje. Sledila so nadaljnja razmišljanja o dosjeju, ki so nas vodila na točko, ko se TRE prvič vpiše v obstoječi IS. Določitev vrednosti TRE in zapis v IS se izvede pri kakovostnem prevzemu materiala na proizvodno skladišče. Postopek prevzema je opisan v poglavju 3.1. POSNETEK STANJA. Prišli smo do zaključka, da se mora v tej operaciji tvoriti tudi novi dosje. Na razpolago smo imeli dve možnosti: dopolnitev obstoječega programa ali avtomatski zapis s prožilcem na podatkovni bazi. Tukaj smo se morali držati zapisanih omejitev projekta, da se v obstoječi IS ne bo posegalo in zanj ne sme biti predvidenih nikakršnih popravkov, posodobitev ali dopolnitev. Zato je za nastanek dosjeja ostala samo možnost zapisa s prožilcem na PB. V tej fazi pozornosti nismo usmerjali na kasnejši podatkovni model, skušali smo zbrati kar največ različnih atributov, ki opisujejo dogajanje v delovnem procesu. Stojan Erker: Programska rešitev za sledenje materiala stran 30

36 Ob tem smo prišli še do enega pomembnega spoznanja. Analizirali smo postopke za razvoj dosjeja, ki je v tej fazi ekvivalenten TRE. Začela se je pojavljati tendenca, da bi prešli na zbiranje informacij o tehnologiji, ker se dosje po proizvodnem procesu pomika po navodilih iz tehnologije. Spoznali smo, da tehnologija ne spada v sistem sledljivosti, ampak v sistem, ki je namenjen določanju in obdelavi tehnoloških postopkov. Sprejeli smo zaključek, da je za ta projekt edini pravi predmet opazovanja samo TRE oz. dosje in ne tehnologija, delovni nalog ali kakršenkoli drug atribut. Nadaljevali smo s pridobivanjem informacij in na osnovi zbranega izdelali več shematskih prikazov operacij v delovnem procesu. Slika 30 prikazuje proces obdelave z vmesnim zdvajanjem dveh kolobarjev. Slika 30: Prikaz delovnega procesa z zdvajanjem dveh kolobarjev Stojan Erker: Programska rešitev za sledenje materiala stran 31

37 Na sliki 31 je prikaz celotnega delovnega procesa s posebnostjo zdvajanja, ko je kolobar zdvojen sam s sabo. Slika 31: Prikaz delovnega procesa z zdvajanjem enega kolobarja Stojan Erker: Programska rešitev za sledenje materiala stran 32

38 Opazili smo, da je bil vrstni red operacij v obeh primerih zelo podoben. Kljub temu pa se je iz intervjujev dalo razbrati, da je na določenih operacijah potrebna povečana pazljivost pri zapisovanju dogajanja v knjige dela. Analiza posameznih operacij je pokazala, da se lahko obdelava na eni operaciji izvede na več načinov. Na sliki 32 so s skicami in opisi prikazani vsi možni načini prehodov materiala skozi različne stroje. Slika 32: Načini prehodov in smeri materiala skozi obdelovalne stroje Stojan Erker: Programska rešitev za sledenje materiala stran 33

39 Pazljivost je bila namenjena ustreznemu opisu pravilnega načina obdelave na stroju. Ta je pomemben za kasnejše odkrivanje vzrokov reklamacij, ker iz IS ni možno dobiti ustreznih podatkov. Za reševanje reklamacij je zelo pomembno, na kateri plasti se je nahajala katera TRE, kdo je proizvajalec, kdaj je bila dobavljena ipd., saj lahko na neustrezne lastnosti materiala vplivajo zelo različni vzroki. Kvaliteta materiala vpliva tudi sam delovni proces. Na nekaterih operacijah se mora en kolobar oz. ena TRE razdeliti na dva kolobarja. Po delitvi se obdelava lahko nadaljuje, ker tako zahteva tehnologija izdelave. V tem primeru nastaneta tudi dve TRE. Prišli smo do zaključka, da mora za vsak nastali novi kolobar nastati tudi novi dosje. Ob vsem dogajanju na operacijah smo hkrati iskali načine za označevanje kolobarjev, saj smo videli, da operaterji porabijo precej časa, da najdejo kolobar s TRE, ki je za obdelavo predvidena v delovnem nalogu. Odločili smo se, da bomo uporabili obstoječe, ročno pisanje na kolobarje. Na sliki 33 je prikazan izgled zapisa TRE na kolobarju. Za zapis v IS pa bomo uporabili rekurzivni način zapisovanje. Slika 33: Ročno označevanje kolobarjev Stojan Erker: Programska rešitev za sledenje materiala stran 34

40 Digitalizacija označevanja in prepoznave kolobarjev ni bila vključena v naš projekt. Na sliki 34 je shematski prikaz označevanja kolobarjev po zdvajanju. Slika 34: Shematski prikaz označevanja pri zdvajanju Pri razdvajanju, razrezih in pretrgih smo ohranili ročni zapis označevanja. Način je prikazan na sliki 35, in sicer z dodatkom za TRE, oznako za zaporednost navitja, oznako osi pri razdvajalcu in oznako zaporednosti širine. Slika 35: Način označevanja za razdvajanje in razrez Zelo pogosto se na operacijah pojavijo tudi pretrgi materiala. Ti dogodki v tehnologiji niso predvideni, jih pa ne smemo prezreti, saj ni nujno, da je s tem material uničen. Proces se nadaljuje po enakem postopku z vsemi ustreznimi pretrganimi kolobarji. Po analizi možnih dogodkov ob pretrgih smo zaključili, da za vsako delitev kolobarja nastane novi dosje. Pri zapisovanju je treba zagotoviti, da se bodo k novemu dosjeju zapisali tudi podatki o izvornem dosjeju. Naslednja pozornost je bila namenjena dogajanju na obdelovalnih strojih. Poznano nam je bilo, da so nekateri stroji računalniško vodeni in so sposobni komunicirati z drugimi IS. Že v osnovi je bilo predvideno, da bo komunikacija tekla s pomočjo spletnih storitev. Izmenjava podatkov bo potekala v obe smeri. Sprejeli smo nekaj osnovnih zaključkov. Med pomembnejšimi je ta, da morajo stroji obratovati ne glede na delovanje računalniškega omrežja. Stojan Erker: Programska rešitev za sledenje materiala stran 35

41 Funkcionalnost stroja se z uvedbo komunikacije ne sme zmanjšati. Akcije za klice spletnih storitev smo določili v fazi načrtovanja. Za vse operacije smo še enkrat preverili, ali so zbrani vsi potrebni podatki in ugotovili, da se je zbiranje informacij in podatkov o operacijah lahko zaključilo. V fazo analize smo postavili tudi izdelavo podatkovnega modela. Najprej smo iz opravljenih analiz izluščili poteke različnih procesov (prikazano na sliki 30 in sliki 31) in na osnovi tega začeli določati specifične atribute. Na vsaki operaciji delovnega procesa so se pojavljale enake skupine atributov. To so atributi za povezljivost, skupina atributov o dimenzijah, skupina atributov o stanju glede na delovni proces in skupina atributov o času in osebi, ki je podatke obdelovala. Na sliki 36 je prikaz zbranih atributov v orodju za podatkovno modeliranje, kjer so že opredeljeni s podatkovnimi tipi. Slika 36: Seznam atributov na operacijah Pri poimenovanju entitet in atributov smo se opirali na interne dogovore in pravila. Na sliki 37 je prikazan primer poimenovanja za šifrant vrst dogodkov glede na interna pravila. Slika 37: Poimenovanje entitete in atributov v entiteti Stojan Erker: Programska rešitev za sledenje materiala stran 36

42 Pri imenu entitete so prvi trije znaki namenjeni področju, za katerega se izvaja projekt. V tem primeru gre za programsko rešitev na področje izdelave folij, zato FOL. Četrti znak je namenjen za vrsto entitete, ali je šifrant, prometna, arhivska, števec. Omenjena entiteta je šifrant, zato na četrtem mestu črka S (šumnikov se izogibamo). Na naslednjih mestih se nahaja skupno ime za skupino atributov ali poimenovanje relacije, na osnovi katere so entitete nastale. Pravila so določena tudi za vsebino entitete, ki ima lastnosti šifranta. Vsi šifranti morajo vsebovati dogovorjene atribute, ki so enako poimenovani in imajo enake osnovne podatkovne tipe, ki pa so lahko različnih dolžin. Pravila smo uvedli, da analitiki lažje prepoznajo in uporabijo dele podatkovnega modela, ki jih niso izdelali sami ali sodelovali pri izdelavi. Zbrane atribute smo združevali v entitete in sproti izvajali postopke normalizacije. Cilj postopkov normalizacije je bila 3NF, ki pa ni najstrožje določena. Velikokrat je treba v podatkovni model vključiti entitete iz obstoječega modela, ki pa že ob nastanku ni bil pravilno normaliziran. Predvsem to velja za najstarejše dele podatkovnega model. Nekoliko okrnjen ERM prikazuje slika 39. Slika 39: Entitetno relacijski model Stojan Erker: Programska rešitev za sledenje materiala stran 37

43 Novi podatkovni model se v dveh točkah stika z obstoječim podatkovnim modelom. Prvi stik modelov je pri povezavi TRE z dosjejem ob prevzemu, ko se podatki skladišča surovin prenesejo v proizvodno skladišče. Na sliki 40 je prikazana entiteta TT_ODLOZISCE_POZ, ki je del starejšega modela in tabela FOLP_DOSJE_TRE, ki je del novega podatkovnega modela. Povezuje ju entiteta FOLP_ODLOZISCE_DOSJE_TRE. Slika 40: Povezava med obstoječimi in novimi entitetami Entiteti TT_ODLOZISCE_POZ in FOLP_DOSJE_TRE, ki ju povezuje vmesna entiteta FOLP_ODLOZISCE_DOSJE_TRE, ne moreta biti med sabo direktno povezani. Pri analizi smo prišli do zaključka, da vsaka delitev kolobarja povzroči nastanek novega dosjeja, ki se odraža kot nova vrednost primarnega ključa v entiteti FOLP_DOSJE_TRE. Tuji ključ, ki je iz entitete TT_ODLOZISCE_POZ, ne bi bil več neposredno funkcijsko odvisen od primarnega ključa in začela bi se pojavljati redundanca. Pojavilo bi se stanje, ko ne bi bilo možno dati odgovora na vprašanje, kateremu ZAPSTEV in POZ dejansko pripada in kateri ID_FOLP_DOSJE_TRE, saj bi se za isti prevzem pojavilo več dosjejev. Vsak prevzem ima natančno en dosje in natančno en dosje pripada samo enemu prevzemu. V vsaki osnovni entiteti so dosjeji, ki niso pogojeni s prevzemi in nastajajo tudi prevzemi, ki niso odvisni od dosjejev. Drugi stik obstoječega in novega modela je pri entitetah, vezanih na entiteto FT_STROJI_OM. Entiteta združuje atribute, ki opisujejo tehnične lastnosti posameznega stroja. Šifra stroja je primarni ključ, nastala pa sta še dva tuja ključa. Eden je ID_FOLS_VRSTA_PRNOSA, ki je primarni ključ v šifrantu FOLS_VRSTA_PRENOSA in opisuje, ali stroj podpira avtomatski ali ročni način prenosa podatkov. Stojan Erker: Programska rešitev za sledenje materiala stran 38

44 Drugi tuji ključ opisuje, kakšna ekranska maska se uporablja za določen stroj. Atribut STEVSTRO je kot tuji ključ v tabeli FOLP_DELNAL_STROJ_OPERACIJA. Na sliki 41 je del ERM, kjer so prikazane omenjene entitete. Slika 41: Povezava entitete iz obstoječega ERM Z izgradnjo podatkovnega modela, smo postavili temelje za razvoj naslednjih gradnikov izdelave programske rešitve. Na tej točki smo zaključili prvo fazo metodologije in se začeli ukvarjati z logičnimi in fizičnimi modeli procesov. To je pomenil, da začenjamo z drugo fazo metodologije: načrtovanjem. Stojan Erker: Programska rešitev za sledenje materiala stran 39

45 4.2. NAČRTOVANJE Faza načrtovanja je za projekt v razvojnem smislu pomenila postavitev tistih gradnikov, ki bodo implementirali uporabo podatkovnega modela. Izvajati smo začeli razna preverjanja ustreznosti podatkovnega modela. Preverili smo, ali obstaja kakšna kombinacija dogodkov, ki bi za svoj opis zahtevala takšne atribute, ki jih do sedaj še nismo upoštevali. Opirali smo se na izsledke analiz iz predhodne faze in na nova spoznanja, ki smo jih pridobili pri izdelavi podatkovnega modela. Pri preverjanju nismo našli pomembnejših odstopanj, zato smo lahko nadaljevali z izgradnjo logičnega podatkovnega modela. V našem primeru smo v tej fazi s pomočjo razvojnega orodja določili podatkovne tipe, primarne ključe, avtomatsko številčenje in indekse na entitetah. Primer določanja primarnega ključa in avtomatskega številčenja je prikazan na sliki 42. Slika 42: Določitev primarnega ključa in samoštevilčenja ob zapisu Na vseh entitetah smo uporabili negovoreče primarne ključe. Vrednost se jim določa z avtomatskim številčenjem ob vsakem zapisu v podatkovno bazo. Stojan Erker: Programska rešitev za sledenje materiala stran 40

46 Na sliki 43 je prikazana entiteta z atributi in z določenim primarnim ključem ter kandidatnim ključem, ki ima definirano unikatno vrednost. Slika 43: Prikaz že določenega primarnega in kandidatnega ključa Tako smo obdelali vse entitete in na ta način definirali logični podatkovni model. Na osnovi logičnega podatkovnega modela, smo lahko začeli načrtovati programske module. Najprej smo definirali modul, ki se bo priključil, z avtorizacijami nadzorovanemu osnovnemu meniju. Osnovni meni je že definiran in izdelan. Za vstop ga uporabljajo tudi druge spletne aplikacije. Naslednji modul je namenjen izboru načina podrobnega pregleda za operacijo. Iz dokumentacije, ki spremlja proizvodni proces, smo za izbor določili delovni nalog in šifro stroja. Pomembno je, da se po prvem izboru prikažejo vse aktivne operacije s TRE samo izbranega delovnega naloga, po drugem izboru pa vsi delovni nalogi na tej operaciji. Iz podrobnega pregleda se izvede prehod na obdelavo. Programski modul bo na osnovi izbranih podatkih pokazal informacijski pogled na dogajanje na tej operaciji. Načrtovanje naslednjih programskih modulov se je tukaj razdelilo, ker so specifičnosti posameznih operacij preveč različne, da bi lahko načrtovali skupen modul. Nastali so moduli, ki podpirajo procese na valjanju in žarenju. Naslednji modul je namenjen spremljanju zdvajanja. Izdelali smo še zadnji modul, ki je namenjen podpori na razdvajanju in razrezih. Stojan Erker: Programska rešitev za sledenje materiala stran 41

47 Programski moduli so shematsko prikazani na sliki 44. Slika 44: Shematski prikaz programskih modulov V tej fazi smo izdelali načrte tudi za večino prožilcev, ki ob določenih dogodkih na izbrani tabeli pokličejo shranjene procedure in izvedejo predvideno obdelavo. Na ta način smo se izognili posegom v obstoječe aplikacije in zagotovili, da lahko hkrati delujeta oba sistema. Fazo nčrtovanja smo po končanih omenjenih aktivnostih tudi zaključili. Izdelali smo svojo različico dokumentacije, lastnoverzijo primerov uporabe z navodili za programiranje, ki bo osnovno vodilo in opora v naslednji fazi metodologije. Stojan Erker: Programska rešitev za sledenje materiala stran 42

48 4.3. IZVEDBA Prva naloga v tej fazi je bila, da se na osnovi navodil in logičnega podatkovnega modela, izdelajo ukazi za kreiranje objektov v podatkovni bazi (PB). Datoteko z ukazi za kreiranje objektov nam izdela razvojno orodje. Na sliki 45 je prikazan del generirane datoteke z ukazi za kreiranje tabel. Slika 45: Ukazi za kreiranje objektov na DB2 Nekatere ukaze je treba zaradi višje verzije baze, ki uporablja nekoliko drugačen strukturiran ukazni jezik (SQL), minimalno dopolniti ali spremeniti. Ko so bili objekti v PB zgrajeni, smo začeli z izvedbo prožilcev. Prožilci so uporabniški programi, pridruženi tabelam, ki jih aktivira DBM (database manager), ko pride do spremembe podatkov v podatkovni bazi. Kot je navedeno v (Bedoya, Cruz, Lema, in Singkorapoom, 2006), je njihov osnovni namen opazovanje podatkovnih sprememb in ob zaznani spremembi izvesti notranjo programsko logiko. Aktivirajo se neodvisno od vmesnikov, ki generirajo podatkovne spremembe. Glede na zaključke iz analize je bilo najprej treba izdelati avtomatski zapis dosjeja, ki se izvede ob kakovostnem prevzemu TRE. Pri kakovostnem prevzemu se v tabeli TT_ODLOZISCE_POZ, spremeni vrednost podatka v koloni PREVZETO. V primeru, da se spremeni na vrednost D, se mora izvesti zapis dosjeja. Zapis dosjeja poteka v treh delih: zapis v tabelo FOLP_DOSJE_TRE, zapis v tabelo FOLP_DOSJE_TRE_RAZVOJ, zapis v tabelo TT_ODLOZISCE_DOSJE_TRE. Dosje je v bistvu primarni ključ tabele FOLP_DOSJE_TRE, njegova vrednost pa se tvori avtomatsko. Programski jezik za pisanje prožilcev in shranjenih procedur je PL/SQL. Programska logika znotraj prožilca poskrbi, da se pravilno izvedejo tudi ostali zapisi ali pa se v primeru napake izvede preklic vseh zapisov. Stojan Erker: Programska rešitev za sledenje materiala stran 43

49 Prožilci lahko opazujejo spremembe podatkov v vseh ali samo v posameznih kolonah. Slika 46 prikazuje ukaza za kreiranje prožilca, ki izvede napisan nabor ukazov, po spremembi kolone PREVZETO. Slika 46: Ukaz za kreiranje prožilca Prožilci se lahko izvajajo pred spremembo ali po spremembi vrednosti v tabeli, lahko pa tudi pred ali po zapisu nove vrednosti v tabelo. Paziti je treba, da s prožilci ne povzročimo neskončne zanke, ker baza sama tega ne preverja. Naslednja stopnja v fazi izvedbe so shranjene procedure. Shranjene procedure so prav tako uporabniški programi, shranjeni v PB, ki jih lahko aplikacije pokličejo z ukazom CALL. Kot je navedeno v Bedoya et al. (2006), so klici lahko izvedeni lokalno ali iz oddaljenih strežnikov. Prednosti uporabe shranjenih procedur: zmanjšanje podatkovnega prometa po mreži, delitev aplikacijske logike, uporaba statičnih poizvedb (v večini primerov hitrejše kot dinamične). Z uvajanjem shranjenih procedur v plast poslovne logike trislojne arhitekture smo zvišali stopnjo odzivnosti, predvsem pri reševanju ter odpravi napak in pomanjkljivosti v fazi razvoja in testiranja. Procedure vračajo dogovorjen nabor atributov, ki jih sprejme poslovna logika aplikacije, ki je proceduro poklicala. V primeru, da je treba iz kakršnega koli vzroka spremeniti podatkovni model ali pa samo poizvedbo, ni treba spreminjati aplikacije s poslovno logiko, ampak le shranjeno proceduro. Spreminjanje shranjenih procedur je lažje, njihova implementacija pa enostavnejša od sprememb aplikacij na aplikacijskem strežniku. Stojan Erker: Programska rešitev za sledenje materiala stran 44

50 Na sliki 47 je prikaz kreiranja shranjene procedure, s tipično uporabo optimističnega zaklepanja spremenjene vrstice na PB. Slika 47: Kreiranje shranjene procedure Shranjene procedure smo implementirali praktično za vse transakcije s PB. Poslovna logika, ki je implementirana na aplikacijskem strežniku, je samo del celotne poslovne logike. Za medsebojno razumevanje smo za poslovno logiko na aplikacijskem strežniku uporabili termin aplikacijska logika, za shranjene procedure pa podatkovna logika. Naloga aplikacijske logike v smislu transakcij s PB je, da pripravi ustrezne atribute, izvede klic shranjene procedure in sprejme predvidene rezultate. Celotna obdelava podatkov se izvede na PB, aplikacijska logika poskrbi za prenos na predstavitveno plast in sprejem zahtev iz te plasti. Za razvoj aplikacijske logike uporabljamo orodje Rational Application Developer (RAD) za WebSphere Software. Kot je navedeno v (RAD za WAS, 2016), je namenjen hitrejšemu in kvalitetnejšemu razvoju javanskih in drugih aplikacij ter optimiziran za namestitve na WebSphere Application Server. To orodje je uporabljeno tudi za razvoj aplikacij na predstavitvenem nivoju ali na klientu. Za opis celotnega poteka se je treba postaviti na predstavitveno plast, natančneje na klientov brskalnik. Tukaj se vrednostno nastavijo vhodni parametri za klic shranjene procedure, ki je na PB. Zahteva za klic se iz brskalnika pošlje na strežnik. Stojan Erker: Programska rešitev za sledenje materiala stran 45

51 Na sliki 48 je prikazan del kode za nastavitev parametrov in klic procedure. Slika 48: Nastavitev parametrov in klic procedure Na brskalniku se bo opisana akcija izvedla po kliku na gumb Pregled. Na sliki 49 vidimo vhodni parameter z vrednostjo 51042, ki se nahaja v vnosnem polju, ob napisu Vpiši DN. Slika 49: Izgled aplikacije na predstavitveni plasti V aplikacijski logiki se izvede sprejem klica iz klienta, prevzame vhodne parametre procedure in pripravi klicne parametre za klic procedure, ki je shranjena v PB. Stojan Erker: Programska rešitev za sledenje materiala stran 46

52 Na sliki 50 je prikazan del programa, ki pripravi parametre in pokliče shranjeno proceduro (ukaz: call sledljivost...). Slika 50: Klic procedure iz WAS V aplikaciji je ukaz sestavljen iz notranjih spremenljivk, na podatkovno bazo pa se pošlje v obliki, ki ga prikazuje slika 51 v drugi vrsti. Slika 51: Prikaz strežnikovih sporočil o klicu shranjene procedure Klic procedure se prenese na PB. Ker je aplikacija nameščena na aplikacijskem strežniku, ni potrebno, da bi se predhodno izvedla prijava v PB. Za to funkcionalnost skrbi aplikacijski strežnik. Ena od prednosti aplikacijskega strežnika je tudi ta, da se prijave na PB izvajajo iz zbiralnika povezav. Zbiralnik povezav je nabor povezav, ki jih strežnik uporablja za prijavo na PB in eksplicitno je nastavljena ena odprta povezava. To pomeni, da se v trenutku zagona aplikacijskega strežnika do PB takoj odpre najmanj ena povezava. Ko se zaradi hkratnega dela uporabnikov, ta povezava zasede, se iz prvega zbiralnika odpre nova povezava. Iz zbiralnika se lahko odpre do 20 povezav, ki pa se zapirajo takoj, ko aplikaciji povezava ni več potrebna. Definiranih je 20 takšnih zbiralnikov, nekatere aplikacije permanentno uporabljajo samo izbran zbiralnik povezav. Po klicu shranjene procedure PB obdela podatke po navodilih podatkovne logike in vrne rezultat. Podatki iz rezultata se prenesejo nazaj v aplikacijski strežnik. Aplikativna integriteta aplikacijskega strežnika zagotavlja, da se rezultati s podatki vrnejo natanko tisti aplikaciji, ki jih je tudi klicala. Aplikacijski strežnik sprejme rezultat, ga pretvori v JSON-format in ga pošlje klientu. Ta format je precej podoben XML-formatu, le da je nekoliko krajši, hitrejši in podpira uporabo zbirk. Stojan Erker: Programska rešitev za sledenje materiala stran 47

53 Na sliki 52 je prikazan način transformacije rezultata v JSON-format. Slika 52: Pretvorba v JSON-format Aplikacija na klientu sprejme rezultat, ga obdela in prikaže na oknu v brskalniku. Slika 53 prikazuje rezultat in izgled rezultata po kliku na gumb Pregled. Slika 53: Prikaz rezultata za DN Na enak način funkcionirajo vsi moduli programske rešitve za sledenje materiala. Uporaba aplikacije je enostavna, saj so okna pregledna in zasnovana po navodilih uporabnikov. Naslednje okno se pokaže ob kliku na vrstico z ustreznimi podatki. Prikazi ustrezajo fizičnim izpisom delovnih nalogov v proizvodnji, zato operater ne izbira na slepo. Stojan Erker: Programska rešitev za sledenje materiala stran 48

54 Slika 54 prikazuje okno obdelave, kjer se prikažejo podatki o vhodih in izhodih iz procesa na operaciji. Slika 54: Vhodne TRE in izhodne TRE Zeleni krožci, vidni levo spodaj, pomenijo, da je podatek bil poslan na obdelovalni stroj in da je sprejem potrjen. Zeleni krožec v sredini spodaj pove, da je stroj vrnil rezultate obdelave in je sprejem potrjen. Rdeči krožec ponazarja, da stroj za TRE še ni vrnil rezultatov. Po kliku na vrstico med zelenima gumboma se odpre okno, prikazano na sliki 55, ki pokaže operacije obdelava in rezultate prehodov. Slika 55: Faza prehodov skozi obdelovalni stroj Na desni strani slike vidimo zelene in rdečo kljukico. S tem se izvede kakovostni prevzem prehoda. V poljih z belo podlago lahko spreminjamo vrednosti. Zelena kljukica pomeni, da ni opaznih posebnosti, rdeča pa pomeni, da je operater opazil anomalije na kolobarju in mora to tudi kratko opisati. Ta funkcionalnost aplikacije v popolnosti nadomešča knjige dela, ki smo jih omenjali pri posnetku stanja in kritični analizi. V ločeni spodnji vrstici so podatki o ostanku. Ostanek je del vhodnega kolobarja, ki je ostal neporabljen na vhodu v obdelovalni stroj. Ta ostanek se prenese v sistem motenj, ki pa niso del sledljivosti. S klikom na gumb Zapis obdelave, nahaja se desno spodaj, se podatki obdelajo in zapišejo v podatkovno bazo. Kljukice in bela polja postanejo sive barve. Stojan Erker: Programska rešitev za sledenje materiala stran 49

55 Po kakovostnem prevzemu se vrnemo na okno obdelave. Ko so kakovostno prevzeti vsi prehodi, lahko izvedemo ali zaključek ali zapis motnje. Motnjo moramo okarakterizirati, zato se pokaže dodatno okno za izbor vrste motnje in opis. Slika 56 prikazuje okno za vpis motnje. Slika 56: Izbor vrste motnje, opis in zapis Po zapisu motnje vrstica izgine iz pregleda. Tiste TRE, ki ustrezajo pogojem za prenos na naslednjo operacijo delovnega procesa, pa zaključimo z zeleno kljukico v stolpcu OK. Slika 57 prikazuje dve TRE, od katerih želimo eno zaključiti na tem procesu in jo prenesti na naslednjega. Slika 57: Zaključevanje procesa za TRE V obdelavi, ki jo sprožimo s klikom na gumb Zaključi, se izvede tudi klic spletne storitve za zapis podatkov na obdelovalni stroj naslednje operacije. Krožci na levi strani okna se s tem avtomatsko obarvajo v zeleno barvo. Na sliki 58 so prikazane uspešno zaključene TRE na naslednji operaciji. Slika 58: Prikaz TRE na naslednji operaciji Stojan Erker: Programska rešitev za sledenje materiala stran 50

56 To so bili prikazi za vrsto strojev, ki imajo predviden en izhod. V proizvodnem procesu pa so stroji, ki proizvedejo več izhodnih kolobarjev. Na sliki 59 je prikazana maska za kakovostni prevzem na operaciji razdvajanja, kjer je na izhodu več manjših kolobarjev na zgornji in spodnji osi. Slika 59: Prikaz razreza vhodnega kolobarja na dve širini Izgled posameznega okna je samo predstavitvena plast. Za pravilno delovanje smo morali izvesti vse faze metodologije, da smo lahko izdelali aplikacijo, ki podpira povsem drugačen delovni proces. Takšnih iteracij je bilo več, pomembna je še operacija zdvajana, ki sicer uporablja enako okno kot valjanje, vendar pa povsem drugačno poslovno logiko. Metodologija postopnega razvojnega modela nam je omogočala, da smo iteracije izvajali znotraj konstrukcijske faze. Izkazalo se je, da je pila predhodna faza analize izdelana korektno in je ni bilo treba dopolnjevati. Tudi osnovnih gradnikov, npr. ERM, ni bilo treba spreminjati, včasih je bilo treba dodati le kak atribut, ki pa ni vplival na postavljene relacije. S tem smo zaključili fazo izvedbe in prešli na naslednjo fazo. Stojan Erker: Programska rešitev za sledenje materiala stran 51