borut hauptman na rtovanje in izdelava aplikacij v ... · primer uporabe – na’rtovanje,...

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO

Borut Hauptman

NAČRTOVANJE IN IZDELAVA

APLIKACIJ V PROGRAMSKEM OKOLJU

FLEXGEN

Diplomska naloga

Žalec, januar 2008

I

UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17

Diplomska naloga visokošolskega strokovnega študijskega programa


APLIKACIJ V PROGRAMSKEM OKOLJU FLEXGEN

Študent: Borut HAUPTMAN

Študijski program: visokošolski strokovni, Računalništvo in informatika

Smer: Informatika

Mentor: viš. pred. mag. Davor BONAČIĆ

Žalec, januar 2008

III

ZAHVALA

Zahvaljujem se mentorju viš. pred. mag. Davorju

BONAČIĆU za pomoč in vodenje pri pripravi

diplomske naloge.

Zahvala gre tudi podjetju Agrina

iNFORMATIKA d.o.o. Žalec, za vso podporo in

razumevanje pri pisanju diplomskega dela.

Posebna zahvala gre staršem, ki so mi omogočili

študij.

IV


APLIKACIJ V PROGRAMSKEM OKOLJU

FLEXGEN

Ključne besede: informacijski sistemi, programska oprema, življenjski cikel razvoja

programske opreme, hiter razvoj aplikacij, generatorji aplikacij, integrirana razvojna

okolja, analiza in načrtovanje, testiranje.

UDK: 004.43(043.2)

Povzetek

Podjetja se morajo vse hitreje prilagajati spremembam in zahtevam, ki jih prinaša trg in

sodobno poslovanje. Temu ritmu mora slediti tudi informacijska podpora. Veliko razvojnih

projektov programske opreme se kljub uporabi sodobnih razvojnih orodij in metodologij

ne konča v predvidenih časovnih, stroškovnih in kakovostnih okvirih. Za to obstaja več

razlogov. Eden od njih so težave zaradi spreminjanja uporabniških zahtev med projektom,

kar pri starejših razvojnih pristopih zelo povečuje stroške projekta.

Običajno razvoj aplikacij poteka skozi več faz. V pričujoči diplomski nalogi je prikazan

postopni razvoj aplikacije za materialno poslovanje z generatorjem FlexGen. Prvi del

diplomske naloge zajema splošen opis same sestave generatorja FlexGen, drugi del

diplomske naloge pa je sestavljen iz več faz in se začne z analizo problema, sledi druga

faza, ki zajema načrtovanje, nato sledi implementacija, zadnja faza pa zajema testiranje

aplikacije.

V

PLANNING AND MAKING APPLICATIONS

IN APPLICTION DEVELOPMENT TOOL

FLEXGEN

Key Word: information systems, software, software development life cycle, rapid

application development, application generators, integrated development environments,

analysis and design, testing.

UDK: 004.43(043.2)

Abstract

Modern business demands constant adaptation to changes and the information

technology has to cope with that. A lot of software projects fail or end challenged, despite

of using modern tools and methodologies. One of the reasons are also problems with

constant changing of user requirements during project. Changes quickly rise the costs of

project, especially when using older software developement models.

In this thesis is outlined the gradual progress of the material application with FlexGen

generator. First part of this thesis contain rough description of FlexGen generator. Second

part starts with analysis problem, then follow planning, implantation and finish with testing

of the material application.

VI

VSEBINA

1. UVOD 1

2. OPIS GENARATORJA FLEXGEN 2

2.1 Kaj je generator FlexGen? 2

2.2 FlexGen dictionary 3

2.2.1 Kaj FlexGen dictionary vsebuje 4

2.2.2 Česa FlexGen dictionary ne vsebuje 4

2.3 Gradnja programov 5

2.3.1 Potek gradnje programov 6

2.4 Terminologija 7

3. PRIMER UPORABE – NAČRTOVANJE, IZDELAVA IN TESTIRANJE

APLIKACIJE ZA MATERIALNO POSLOVANJE 8

3.1 Analiza z uporabo dokumenta SZPO 8

3.1.1 Uvod 8

3.1.2 Ime projekta 8

3.1.3 Pregled vsebine SZPO 9

3.1.4 Perspektive produkta 9

3.1.5 Funkcije produkta 9

3.1.6 Značilnosti uporabnikov 10

3.1.7 Splošne omejitve 10

3.1.8 Funkcionalne zahteve 11

3.1.9 Zahteve glede vmesnikov 11

3.1.10 Zahteve glede zmogljivosti 12

3.1.11 Omejitve načrtovnja 12

3.1.12 Lastnosti 12

3.1.13 Vzdrževanje 12

3.2 Entitetno relacijski podatkovni model aplikacije 13

3.2.1 Entitete 13

3.2.2 Relacije 14

3.3 Implementacija 17

3.3.1 Firma 17

VII

3.3.2 Partner 18

3.3.3 Artikel 20

3.3.4 Dokument 25

3.3.4.1 Nabava blaga 25

3.3.4.2 Prodaja blaga 30

3.3.5 Šifranti 32

3.4 Testiranje 34

3.4.1 Splošno o testiranju 34

3.4.2 Testiranje aplikacije 35

4. SKLEP 42

5. LITERATURA 44

6. VIRI 45

VIII

KAZALO SLIK

Slika 2.2 : Prikaz zgradbe FlexGen-a (vir: FlexGen for Windows, Ver. 6.2, Getting Started Manual)................. 3

Slika 2.3.1 : Prikaz poteka gradnje programov (vir: FlexGen for Windows, Ver. 6.2, Getting Started Manual) .. 6

Slika 2.4 : File, Record in Field (vir: FlexGen for Windows, Ver. 6.2, Getting Started Manual) ......................... 7

Slika 3.2: E-R model materialnega poslovanja ................................................................... 16

Slika 3.3.1: Prikaz izdelane vnosne maske za vnos podatkov o firmi................................. 17

Slika 3.3.2: Prikaz izdelane vnosne maske za vnos partnerjev ........................................... 18

Slika 3.3.3: Prikaz izdelane forme za vnos artiklov ............................................................ 20

Slika 3.3.4.1.1: Vnos naročila.............................................................................................. 26

Slika 3.3.4.1.2: Potrditev blaga v skladišču......................................................................... 27

Slika 3.3.4.1.3: Kalkulacija blaga........................................................................................ 28

Slika 3.3.4.2: Uporabniški vmesnik – Prodaja blaga........................................................... 31

Slika 3.3.5.1: Opisnik primarnega šifranta .......................................................................... 32

Slika 3.3.5.2: Lastnosti podšifranta ..................................................................................... 33

Slika 3.3.5.2: Opisnik podšifranta ....................................................................................... 33

IX

UPORABLJENE KRATICE

SCL – The System Control Language

RPC – Remote Procedure Call

TCP/IP – Transmision Control Protocol / Internet Protocol

EAN – The European Article Numbering ali evropska izdelčna koda

GTIN – Global Trade Identification Number ali globalna trgovinska identifikacijska

številka

SSKJ – Slovar slovenskega knjižnega jezika

ZDDV – Zakon o davku na dodano vrednost

DDV – Davek na dodano vrednost

MTTR – Mean Time To Repair

Borut Hauptman: Načrtovanje in izdelava aplikacij v programskem okolju FlexGen

1

1. UVOD

Na vsak projekt razvoja programske opreme prežijo številna tveganja, zaradi katerih se

ta kljub uporabi modernih razvojnih orodij in metodologij lahko ne konča v predvidenih

časovnih, stroškovnih in kakovostnih okvirih. Za to obstaja več razlogov. Eden od njih so

težave zaradi spreminjanja uporabniških zahtev med projektom, kar pri klasičnih razvojnih

pristopih zelo povečuje stroške projekta. Ta težava je posebej očitna pri linearnih razvojnih

pristopih. Pri teh je najbolj znan predstavnik zaporedni ali slapovni razvojni model, kjer si

faze razvoja sledijo zaporedno ena za drugo, vsaka faza razvoja pa se lahko prične šele

takrat, ko se predhodna faza zaključi. V praksi so se kmalu začeli iskati drugačni razvojni

pristopi, katerih skupna značilnost je ta, da razvoj poteka v več korakih ali iteracijah.

Vzporedno s tem se je razvijal in spreminjal tudi proces testiranja.

V konkretnem primeru smo se razvoja lotili z uporabo iterativnega razvojnega pristopa.

Eden od načinov prehoda na iterativni razvojni model je uporaba načela deli in vladaj.

Celotni sistem smo najprej razbili na več delov ali inkrementov, nato pa smo vsakega

posebej razvili z uporabo slapovnega razvojnega cikla. Tako smo z vsako iteracijo razvili

del funkcionalnosti celotnega sistema, pri čemer smo se v začetnih iteracijah lotili najbolj

tveganih delov sistema. S tem smo kritične pomanjkljivosti odkrili in odpravili dovolj

zgodaj ter s tem zmanjšali tveganje prekoračitve predvidenih stroškov projekta.


2

2. OPIS GENARATORJA FLEXGEN

Namen opisa je osnovni pregled generatorja FlexGen.

To poglavje obsega sledeče:

• Kaj je FlexGen?

• FlexGen dictionary

• Gradnja programov v FlexGen-u

• Terminologija, ki je uporabljena

2.1 Kaj je generator FlexGen?

Aplikacije so ponavadi sestavljene iz sledečih elementov:

• Podatki;

• Programi za vnos (insert) in posodabljanje (update) podatkov;

• Programi za poizvedovanje (query);

• Menu za »povezovanje« različnih programov v uporabniku prijazen način.

FlexGen je prav takšna aplikacija, saj združuje vse zgoraj naštete elemente v neko

celoto. Napisana je na Cobol-ski osnovi, ki generira Cobol-ske programe.

Celotno razvojno okolje (integracija) je shranjeno v repozitorij (Central Repository)

oziroma v urejeno sistemsko knjižnico (System Dictionary).


3

2.2 FlexGen dictionary

DataDefinitions

UserPrograms

CommonRoutines

FlexGenMacros

UserMenus

FlexGenMenus

SystemParameters

ProgramExecution

Commands

Dictionary

Slika 2.2 : Prikaz zgradbe FlexGen-a (vir: FlexGen for Windows, Ver. 6.2, Getting Started Manual)


4

2.2.1 Kaj FlexGen dictionary vsebuje

Dictionary se uporablja za shranjevanje in obnavljanje (indeksiranje) vseh aspektov

aplikacije:

• Data definitions – Definicije podatkov

Pod definicijo podatkov štejemo datoteke (Files), zapise (Records, Fields) in relacije

med njimi.

• Query and Form Programs – Poizvedovalni programi in forme

Gre za programe za vnos podatkov in poizvedovanje shranjenih podatkov, ki so

shranjeni v FlexGen formatu in ne v izvirnem Cobol-skem formatu.

• Copy Elements

Ponavadi so to rutine, ki jih lahko uporabimo v večih programih.

• Program Execution Scripts

Gre za zbirko rutin, neodvisnih od operacijskega sistema, ki jih je potrebno prevesti

(SCL, JDL, JCL, itd.).

• FlexGen Functions – Funkcije

To so parametrizirane Cobol-ske izvorne rutine, ki si jih generator FlexGen prilagodi in

jih lahko kličemo iz programov s parametri. Veliko funkcij je sicer že vgrajenih, lahko

pa ustvarimo tudi svoje in jih kličemo s pomočjo parametrov.

2.2.2 Česa FlexGen dictionary ne vsebuje

• Data files – Podatkovne datoteke

Čeprav FlexGen dictionary vsebuje informacije o tem kako naj izgledajo podatki,

samih podatkov ne vsebuje.

• Error and Help Messages – Poročila o napakah in pomoč

FlexGen dovoljuje možnost pisanja poročil o napakah in pomoči, kar povečuje

čitljivost aplikacije. Ti podatki so shranjeni izven dictionary-a.


5

• Object Programs – izvršljivi programi

Ko generiramo program v generatorju FlexGen in Cobol-u, le-ta program kompilira.

Koda tako generiranega programa (objekt ali izvršljiv del) se shrani ločeno za vsak

preveden program posebej.

• The Terminal Definition File

Ta datoteka vsebuje informacije o terminalu (osebnem računalniku) na katerem teče

aplikacija, vključno z opisom različnih ključev in njihovih funkcij.

2.3 Gradnja programov

Z uporabo programskega paketa FlexGen je mogoče doseči visoko produktivnost pri

gradnji aplikacij in sicer tako pri poizvedovalnih programih, ki jih uporabljamo za izdelavo

izpisov, izvoz in uvoz podatkov in posodabljanje podatkov, kot tudi pri formah, ki so

grafični vmesniki in se uporabljajo za interaktivni vnos podatkov v bazo podatkov.

Z uporabo enostavnih poizvedb generator FlexGen omogoča enostavno in hitro

izgradnjo aplikacije. Osnovni Cobol-ski ukazi včasih ne zadostujejo zahtevam

programiranja, zato ima generator FlexGen dodatne funkcije (te lahko napišemo tudi

sami), ki zadostijo tem zahtevam. Napisano nato prevedemo s Cobol-skim Compiler-om,

ki je že integriran v FlexGen-u v izvršljiv (executeble) objekt. Objekt, ki nastane,

zaganjamo z SCL (The System Control Language) Scrip-tom. Menu za končne uporabnike

oblikujemo tako, de vanj vežemo SCL Scrip-te, katere zaganja uporabnik.


6

2.3.1 Potek gradnje programov

Easy Query

Query Forms

Generator

InterimSource

Constructor

IDDivision

DataDivision

ProcedureDivision

ServiceRoutines

Combine

CobolSource

Compilation

CobolObject

Conversions

ExternalSource

Slika 2.3.1 : Prikaz poteka gradnje programov (vir: FlexGen for Windows, Ver. 6.2, Getting Started Manual)


7

2.4 Terminologija

• Aplikacija

Aplikacija ima v generatorju FlexGen-u dva pomena. Lahko je zbirka elementov v

Dictionary-u ali pa program, narejen za končnega uporabnika.

• Compiler

Compailer prevede izvorno kodo progama v računalniško izvršljiv program.

• Constructor

Constructor prevede interno FlexGen kodo v izvorno kodo, ki jo uporabi Compiler.

• Error

Napako sestavlja koda in obvestilo o napaki. Uporablja se tako pri poizvedovalnih

programih, kot tudi pri formah.

• Field

Field je skupina znakov, ki se obnašajo kot celota. Drug izraz za Field je lahko tudi

stolpec.

• File

File je fizični zapis, ki zajema stolpce (Field) in zapise (Record), ki se obnašajo kot

celota.

Primer:

# Name Address100 Mary Smith 101 Main St101 Pete Joans 9 East St102 Dave Lane 55 West St

RECORD

FIELD

FILE

Slika 2.4 : File, Record in Field (vir: FlexGen for Windows, Ver. 6.2, Getting Started Manual)


8

3. PRIMER UPORABE – NAČRTOVANJE, IZDELAVA IN TESTIRANJE APLIKACIJE ZA MATERIALNO POSLOVANJE

3.1 Analiza z uporabo dokumenta SZPO

3.1.1 Uvod

Namen dokumenta SZPO

Namen dokumenta je strukturiran in discipliniran pristop k implementaciji

aplikacije za materialno poslovanje. Tu so opisane različne storitve sistema, ki jih lahko

izvaja uporabnik. Dostop do centralizirane baze podatkov je omejen glede na naravo

uporabnika. Dokument je namenjen tako naročniku kot izvajalcem projekta, med katere

spadajo programerji, informatiki, načrtovalci sistema in baze podatkov ter

demonstratorji produkta z znanjem gradnje informacijskih sistemov.

3.1.2 Ime projekta

Polno ime projekta se glasi:

Načrtovanje in izdelava aplikacije za materialno poslovanje.

Projekt bo zajemal:

• enostaven vnos osnovnih podatkov o podjetju;

• enostaven vnos osnovnih podatkov o partnerjih;

• enostaven vnos osnovnih podatkov o artiklih;

• vnos prejema blaga na osnovi dobave;

• izstavitev dobavnice / računa ob prodaji blaga;

• spremljanje zaloge, izpisa in izvoz v Excel;

o možnost različnih izpisov osnovnih podatkov in izvoz v Excel;

o možnost različnih izpisov prometa blaga in izvoz v Excel;


9

Projekt ne bo zajemal:

• analize prodaje;

• spletnih rešitev aplikacije;

• navezave na finančno poslovanje.

3.1.3 Pregled vsebine SZPO

Dokument je organiziran po standardu ANSI/IEEE 830-1984 (Software Requirements

Specifications).

3.1.4 Perspektive produkta

Aplikacija bo delovala samostojno v lokalni mreži.

Do baze podatkov bo dostop omejen.

3.1.5 Funkcije produkta

Vnos podatkov v bazo:

• vnos osnovnih podatkov o podjetju;

• vnos osnovnih podatkov o partnerjih;

• vnos osnovnih podatkov o artiklih;

• vnos prejema blaga;

• vnos izdaje blaga (dobavnice).

Funkcije, povezane z vnosom v bazo:

• ažuriranje osnovnih podatkov o podjetju;

• ažuriranje osnovnih podatkov o partnerjih;

• ažuriranje osnovnih podatkov o artiklih;

• ažuriranje zalog;

• rezervacija zalog.


10

Funkcije, povezane z branjem iz baze:

• prikaz podatkov o podjetju;

• prikaz podatkov o partnerjih;

• prikaz podatkov o artiklih;

• izračun nove zaloge pri nabavi in prodaji blaga;

• izračun rezervirane zaloge pri nedokončani prodaji.

3.1.6 Značilnosti uporabnikov

Ciljni uporabnik naj ima osnovno znanje iz računalništva in materialnega

poslovanja ter naj bo seznanjen z enim izmed informacijskih sistemov:

• Microsoft Windows 2000;

• Microsoft Windows XP;

• Microsoft Windows Vista.

3.1.7 Splošne omejitve

Omejitve glede strojne opreme:

• delujoč računalnik z enim izmed zgoraj naštetih operacijskih sistemov;

• mrežna povezava s strežnikom.

Omejitve glede programske opreme:

Na računalniku, ki dostopa do baze podatkov, mora biti pravilno instaliran in

delujoč eden izmed spodnjih sistemov:


• Microsoft Windows XP;

• Microsoft Windows Vista.


11

Na računalniku, kjer imamo shranjeno podatkovno bazo, mora biti pravilno

instaliran in delujoč eden izmed spodnjih sistemov:

• Microsoft WinNT 4.0;



3.1.8 Funkcionalne zahteve

Prijava v aplikacijo za materialno poslovanje določi dostopnost in lastnost posameznih

funkcij glede na tip uporabnika. Opravi se verifikacija vnesenih podatkov in se določi

dostopnost do funkcij aplikacije za materialno poslovanje.

• Če je bila prijava neuspešna, se pojavi sporočilo.

• Omogočeno je ažuriranje podatkov.

• Obstaja možnost dodajanja v bazo.

3.1.9 Zahteve glede vmesnikov

Uporabniški vmesnik je namenjen Microsoft Windows okolju. Delovanje aplikacije je

podprto v vseh Microsoftovih operacijskih sistemih od Windows 98 naprej. Komunikacija

je izvedena s pomočjo COBOL-RPC (Remote Procedure Call) protokola.

Vmesniki za strojno opremo, s pomočjo katerih se povezujemo z bazo, preko omrežja

morajo biti podprti s strani operacijskega sistema. Mrežna podpora bo omogočena preko

standardnih protokolov za Intranet/Internet (TCP/IP).

Za delovanje komunikacijskih vmesnikov je med drugim potrebno imeti pravilno

instalirano mrežno kartico, s pomočjo katere se vežemo na server, ki nam omogoči dostop

do podatkovne baze.


12

3.1.10 Zahteve glede zmogljivosti

Aplikacija, preko katere dostopamo do podatkovne baze, je namenjena enemu samemu

uporabniku, vendar pa lahko server sprejme večje število prijav. V končnem delovanju

sistema bo število prijav omejeno s 50 hkratnimi prijavami.

3.1.11 Omejitve načrtovnja

Aplikacija bo zadovoljevala Windows standarde.

Omejitve strojne opreme: Za računalnik, ki je predviden kot server za podatkovno bazo, je

predviden naslednji procesor: Pentium III 5OOMHz ali več) z 512 MB primarnega

pomnilnika in vsaj 50 GB trdega diska in vsaj 100M bitno mrežno karto (priporočljivo

več). Računalnik, na katerem bo postavljena aplikacija za dostop do baze je za minimalno

delovanje predviden Pll računalnik z 256MB primarnega pomnilnika z vsaj 100 MB

prostega sekundarnega pomnilnika. Pravilno mora biti nameščena tudi mrežna kartica, s

pomočjo katere se sistem veže v omrežje.

3.1.12 Lastnosti

Sistem zadovoljuje in močno presega trenutne potrebe materialnega poslovanja. Ob

prekinitvi delovanja se ohrani vsebina baze, ob porušitvi serverja in ponovni vzpostavitvi

iz rezervne kopije baze pa se lahko pričakujejo minimalne izgube podatkov.

3.1.13 Vzdrževanje

Modularna zgradba omogoča hitro nadgradnjo sistema in sledenje novim zahtevam in

standardom. Program skrbi, da se varnostna kopija podatkovne baze opravi vsak dan. Za

vzdrževanje in obnovo baze v primeru padca baze skrbi administrator podatkovne baze.


13

3.2 Entitetno relacijski podatkovni model aplikacije

3.2.1 Entitete

Firma

To je osnovna entiteta. V to entiteto zapišemo osnovne podatke o podjetju.

Poslovni partnerji

Potrebno je voditi osnovne podatke o poslovnih partnerjih kot so naziv podjetja, sedež

in naslov podjetja, davčna številka, matična številka in ostale podatke kot so telefonska

številka, telefaks številka, e-mail naslov, internet naslov, informacija o sklenjeni pogodbi

in tako dalje. Te podatke je potrebno voditi tako o dobaviteljih, kot o kupcih.

Artikel in Zaloga

Potrebujemo tudi entiteto artiklov in zalog, kjer so vpisani vsi podatki, ki so potrebni za

nabavo, prodajo in kasnejšo analizo prodaje in nabave.

Dokument

Dokument je sestavljen iz glave dokumenta in pozicij dokumenta. Uporablja se za

nabavo, prodajo, prevrednotenje zalog, predračune, konsignacijo, inventuro (viške in

manjke) in drugo.

Šifrant

Je entiteta, v katero vpisujemo različne vrste šifrantov, ki so potrebni za nemoteno

delovanje aplikacije.

Oddelki

Podjetje ima lahko več oddelkov (poslovnih enot), katere želi voditi ločeno. V oddelku

se nahajajo tudi različni indikatorji. Oddelki se lahko vodijo po naslednjih indikatorjih:

• indikator količinskega ali vrednostnega vodenja zaloge

• cena (nabavna, veleprodajna, malopredajna, cena z DDV)


14

• ostali podatki (kdo je vodja oddelka, kateremu stroškovnemu mestu pripada

oddelek, številčenje dokumentov in ostalo).

3.2.2 Relacije

Firma – Partner (1:n)

Vsaka firma ima več poslovnih partnerjev, to je kupcev in dobaviteljev. Hkrati se v

šifrantu partnerjev nahaja »partner«, ki ima podatke o tej firmi.

Firma – Dokument (1:n)

Vsaka firma ima več dokumentov kot tudi tipov dokumentov. Vsak dokument pripada

natanko eni firmi, na katero se navezuje.

Artikel – Zaloga (1:n)

Ker artikel ni vezan na oddelek in ker ima lahko firma več oddelkov, zaloga pa je

vezana na oddelek, je lahko artikel na več zalogah, zaloga pa lahko vsebuje samo en

artikel.

Oddelek – Zaloga (1:n)

Ker je zaloga vezana na oddelek, se oddelek pojavi na več različnih zalogah, zaloga pa

ima natanko en oddelek.

Oddelek – Glava (dokumenta) (1:n)

Na oddelek je vezanih več dokumentov kot tudi tipov dokumentov. Glava dokumenta

lahko vsebuje oddelek ali pa tudi ne.

Oddelek – Pozicija (dokumenta) (1:n)

Kot je bilo omenjeno že pri predhodni relaciji, je na oddelek vezanih več dokumentov.

Za razliko od predhodne relacije je pozicija dokumenta obvezno vezana na oddelek.


15

Glava – Pozicija (1:n) v okviru Dokumenta

Glava dokumenta ima lahko eno ali več pozicij dokumenta. Pozicija pripada natanko

eni glavi dokumenta, ki skupaj tvorita dokument.

Partner – Dokument (1:n)

Za vsakega partnerja je lahko narejenih več dokumentov. Dokument je izdan za točno

določenega partnerja.

Zaloga – Pozicija (1:n)

Zaloga se pojavi na večih pozicijah dokumenta. Pozicija dokumenta ima podatek samo

iz ene zaloge.


16

Slika 3.2: E-R model materialnega poslovanja


17

3.3 Implementacija

Na osnovi analize in načrtovanja smo se najprej lotili implementacije osnovnih entitet

in sicer firme, partnerjev in artiklov.

3.3.1 Firma

Odločili smo se, da za ključ uporabimo dvomestno numerično polje.

Polje partner je šifra partnerja in se navezuje na šifrant partnerjev. V to polje se vpiše šifra

osnovne firme, kar nam kasneje koristi pri internih dokumentih, ki se nanašajo na osnovno

firmo. Taki dokumenti so na primer interni premiki blaga, sprememba cene, prenos blaga

med oddelki in drugi.

V firmi pa ni vpisana samo šifra firme, ampak tudi drugi podatki, ki se navezujejo na

firmo. Med drugim so to kraj izstavitve računa, različne zapore, kontrole in indikatorji.

Slika 3.3.1: Prikaz izdelane vnosne maske za vnos podatkov o firmi


18

3.3.2 Partner

Šifrant poslovnih parterjev je za vodenje poslovanja eden od najpomembnejših

šifrantov, zato moramo v ta šifrant vnašati podatke točno, ker se iz njega zapisujejo podatki

na vse dokumente, ki jih uporabljamo pri poslovanju. V nadaljevanju bo podrobneje

predstavljena vnosna maska za vnos podatkov o partnerjih in opisana polja na maski.

• Šifro partnerja, ki je hkrati tudi ključ, smo razdelili na dve polji. Prvo polje je

numerično in dolgo šest mest, drugo je prav tako numerično in dolgo tri mesta.

Odločitev je bila sprejeta zgolj na podlagi dejstva, da je potrebno na prodajni strani

zagotoviti prodajo na način prejemnik-plačnik. To pomeni, da ima lahko plačnik

več prejemnikov. V našem primeru (pri zgoraj opisani delitvi) ima lahko en plačnik

največ devetstodevetindevetdeset (999) prejemnikov.

Slika 3.3.2: Prikaz izdelane vnosne maske za vnos partnerjev

• Naziv: vpišemo glavni naziv firme, ki mora biti enak kot je na registraciji firme

oziroma kot je na izdanih dokumentih, ki jih ta poslovni parter izdaja.

• Dod. naziv: vpišemo dodatni naziv partnerja, če seveda obstaja.

• Država: vpišemo šifro države v kateri ima partner sedež firme. Če šifre ne

poznamo, jo lahko poiščemo v pregledu šifranta držav.


19

• Pošta: vpišemo poštno številko kraja sedeža poslovnega partnerja. Številka je lahko

petmestna, kar pomeni, da lahko vnesemo poštno številko za tujino.

• Kraj: vpišemo kraj v katerem je sedež poslovnega partnerja.

• Naslov: vpišemo naslov sedeža poslovnega partnerja.

• Davčni zavezanec: vpišemo šifro oznake davčnega zavezanca. Pomen posameznih

šifer vidimo v pripadajočem šifrantu.

• Davčna številka: vpišemo davčno številko poslovnega partnerja.

• Matična številka: vpišemo matično številko poslovnega partnerja.

• Račun: vpišemo transakcijski račun poslovnega partnerja.

• Swift tuj. Banka: vpišemo oznako tuje banke, če je poslovni partner iz tujine.

• Direktor: vpišemo priimek in ime direktorja firme poslovnega partnerja.

• Kontaktna oseba: vpišemo kontaktno osebo, katero lahko v primeru potrebe

pokličemo ali ji posredujemo pisno sporočilo.

• Telefon: vpišemo telefonske številke poslovnega partnerja.

• Telefaks: vpišemo telefaks številko poslovnega partnerja.

• Davčni urad: vpišemo šifro davčnega urada pod katerega spada poslovni partner.

Šifro davčnega urada izberemo iz šifranta davčnih uradov.

• Valuta dni: za kupce vnesemo informativni podatek, koliko dni je valuta za plačilo

računa.

• Valuta dobavitelja: za dobavitelja vnesemo informativni podatek, koliko dni je

valuta za plačilo računa za posameznega dobavitelja.

• Partner: v to polje vpišemo šifro partnerja glede na vrsto poslovanja (dobavitelj,

kupec, konsignator, ali drugo). Šifro lahko vidimo v šifrantu.


20

3.3.3 Artikel

V šifrant artiklov smo vključili vse pomembnejše podatke, ki pripadajo oziroma

opisujejo blago. Vnosno masko smo gradili postopoma, glede na želje strank. Ker ima

vsaka stranka tudi specifične oziroma svoje želje, smo bili primorani narediti tudi več

različnih vnosnih mask za vnos podatkov o artiklu. Glede na želje oziroma zahteve strank

jim v menu vežemo tisto vnosno masko (formo), katera jim najbolj ugaja in vsebuje

možnost vnosa vseh podatkov, katere potrebujejo za poslovanje. Slika 3.3.3 prikazuje eno

od takih vnosnih mask. Prikazana vnosna maska ima možnost vnosa sledečih postavk.

• Koda artikla (je primarni ključ tabele).

Slika 3.3.3: Prikaz izdelane forme za vnos artiklov

• Naziv artikla: vpišemo osnovni naziv artikla.

• Tuji naziv: vpišemo tuji naziv artikla.

• Ean šifra: je trinajst (13) mestno numerično polje in se lahko uporablja kot vnosno

polje sistema GTIN-8 ali GTIN-13. Primer izračuna GTIN-13 kontrolne šifre

opisno in programsko sledi v nadaljevanju.


21

• Klasifikacija: SSKJ pravi da pomeni klasifikacija razvrstitev, razporeditev česa

glede na enake ali podobne lastnosti. Prav tako je tudi pri blagu (artiklih). Na

podlagi klasificiranja blaga lahko poizvedujemo in izpisujemo blago s podobnimi

ali enakimi lastnostmi, seveda v odvisnosti od same organiziranosti pri vnosu.

• Enota mere: označimo s kakšno enoto mere blaga operiramo pri poslovanju z

blagom.

• Šifra davka: označimo stopnjo davka, ki pripada artiklu in ga določa ZDDV.

• Proizvajalec: iz šifranta partnerjev izberemo proizvajalca blaga, ki pa ni nujno, da

je tudi dobavitelj blaga. Na podlagi proizvajalca blaga lahko poizvedujemo in

izpisujemo prodajo in nabavo blaga po proizvajalcih blaga.

Posebnost predstavljene maske je možnost vnosa kalkulacijskih pogojev že pri samem

vnosu artikla. Navedeno pomeni, da pri vnosu artikla vnesemo odstotek carine, internih in

eksternih stroškov (stroški prevoza, pakiranja, skladiščenja,…), marže in tri nivojski vnos

trgovskih cen. Ti našteti podatki se upoštevajo pri prevzemu oziroma kalkulaciji blaga ob

nabavi le-tega. Izjema so le trgovske cene, ki se upoštevajo pri prodaji blaga. Kateri nivo

cene se upošteva, pa je odvisno od vrste kupca, ki jo označimo pri vnosu partnerjev.


22

Primer izračuna GTIN-13 kontrolne šifre opisno in programsko

Opisno:

Izračun kontrolne cifre - C za GTIN 383202020212C.

Oštevilčimo mesta od desne proti levi. Skrajno desno na mestu 1 je C, ostala mesta pa

opredelimo kot liha in soda od 2 do 13:

13 12 11 10 9 8 7 6 5 4 3 2 1

3 8 3 2 0 2 0 2 0 2 1 2 C

Prvi korak

Seštejemo vse vrednosti na sodih mestih:

8 + 2 + 2 + 2 + 2 + 2 = 18

Drugi korak

Vsoto pomnožimo s tri:

18 x 3 = 54

Tretji korak

Seštejemo vse vrednosti na lihih mestih:

3 + 3 + 0 + 0 + 0 + 1= 7

Četrti korak

Seštejemo rezultat 2. in 3. koraka:

54 + 7= 61

Peti korak

Pogledamo, koliko od dobljenega seštevka v 4. koraku manjka do naslednje cele desetice:

61< 70; 70 - 61= 9

Vrednost za C je enaka razultatu v 5. koraku, torej 9. Celotna identifikacijska številka

GTIN-13 je 3832020202129!


23

Programsko:

.DATA

01 SUM-P PIC 9(9).

01 I-MART PIC 99.

01 PP PIC 9.

01 KONT PIC 9.

01 S PIC 9(9).

.PROC

MOVE 0 TO SUM-P

* v zanki seštevamo števila na sodih mestih PERFORM VARYING I-MART FROM 2 BY 2 UNTIL I-MART > 12

MOVE MART-ARTI(I-MART:1) TO PP

ADD PP TO SUM-P

END-PERFORM

* vsoto pomnožimo s tri COMPUTE SUM-P = SUM-P * 3

* v zanki seštevamo števila na lihih mestih PERFORM VARYING I-MART FROM 1 BY 2 UNTIL I-MART > 12

MOVE MART-ARTI(I-MART:1) TO PP

ADD PP TO SUM-P

END-PERFORM

* iskanje kontrolne cifre COMPUTE S = SUM-P / 10

ADD 1 TO S

COMPUTE KONT = (S * 10) - SUM-P

* razliko pripišemo na zadnje mesto MOVE KONT TO MART-ARTI(13:1)


24

Po končanem načrtovanju in implementaciji osnovnih entitet smo začeli z

načrtovanjem in implementacijo ostalih entitet, ki za osnovo uporabljajo osnovne entitete.

Ostale entitete smo implementirali neodvisno drugo od druge. Kar pomeni, da smo jih

lahko razvijali vzporedno oziroma iterativno.

Pri tem načinu razvoja aplikacije smo osredotočeni na konkretne, vidne izdelke

oziroma programske izdaje (angl. software release), ki so pogoj za zaključitev vsake

iteracije. Za uspeh na projektu je med drugim zelo pomembna povratna informacija s strani

naročnika ali uporabnikov po vsaki zaključeni iteraciji. Končno je uspešnost takšnega

pristopa odvisna od težav pri integraciji oziroma združevanju posameznih sklopov v

celovit sistem.

Ne glede na izbrani razvojni pristop je eden izmed »trših orehov« pri razvoju

programske opreme zajemanje uporabniških zahtev. Večina uporabnikov si težko

predstavlja končno aplikacijo na podlagi tekstovnih opisov ali diagramov v začetnih fazah

projekta. Ena od možnosti iterativnega razvoja in sredstvo za lažjo komunikacijo med

uporabniki in razvijalci izdelka je uporaba prototipov. Z njimi uporabniki lažje dobijo

predstavo o bodočem izdelku, razvijalci pa povratno informacijo, če so na pravi poti.

Prototipi so lahko samo sredstvo za zajemanje uporabniških zahtev in se lahko kasneje

zavržejo, lahko pa se skozi več iteracij oblikujejo v končni izdelek.


25

3.3.4 Dokument

Dokument je sestavljen iz osnovnih entitet glave in pozicije.

Osnovna dokumenta materialnega poslovanja sta nabava in prodaja blaga. Ta dva

dokumenta bomo tudi podrobneje obdelali, ker so ostali dokumenti bolj ali manj izpeljanke

iz teh dveh osnovnih dokumentov.

3.3.4.1 Nabava blaga

Nabavo blaga smo razčlenili na več faz in sicer tako, kot si v praksi tudi sledijo:

• naročilo blaga;

• potrditev blaga v skladišču (količinski prevzem);

• kalkulacija blaga.

Naročilo blaga

Z naročilom blaga se soočimo, ko želimo blago kupiti. Pri nakupu lahko gre za

material, ki ga do sedaj še nismo imeli, lahko pa gre za material, ki nam je pošel, oziroma

je dosegel minimalno zalogo in ga je zato potrebno naročit pri dobavitelju.

V vnosno masko naročilo blaga vnesemo šifro dobavitelja, pri katerem naročamo

blago. V primeru, da gre za novega dobavitelja, obstaja povezava na šifrant partnerjev in

tako vnesemo novega dobavitelja brez da bi zapustili vnosno masko naročila blaga.

Podobno je pri samem vnosu pozicij naročila. V primeru, da želimo naročiti blago, ki ga do

sedaj še nismo imeli, imamo možnost odpiranja novega artikla v šifrantu artiklov, brez da

bi pri tem morali zapustiti naročilo blaga. Samoumevno pa je, da v takem primeru, ko smo

vnesli nov artikel v naročilo blaga, program ne nudi dobaviteljeve cene, ampak jo mora

vnesti uporabnik. Po končanem vnosu uporabnik potrdi naročilo in ga pošlje dobavitelju.


26

Slika 3.3.4.1.1: Vnos naročila

Potrditev blaga v skladišču (količinski prevzem)

Na podlagi naročila blaga dobavitelj dobavi naročeno blago, ki ga skladiščnik

količinsko prevzame. Skladiščnik pokliče dokument naročila, na podlagi katerega je bilo

blago dobavljeno, in preveri naročene količine z dobavljenimi količinami ter jih popravi,

če se količina dobave ne ujema s količino naročila. Nima pa možnosti dodajanja blaga na

dokument, če je dobavljeno blago, ki ga ni na naročilu. Ta blokada je bila narejena na željo

oziroma zahtevo naročnika aplikacije. Če bi naročnik želel drugače, bi bilo aplikacijo

mogoče izvesti tudi drugače. Skladiščnik nima možnosti popravljana dobavitelja, saj lahko

v glavo dokumenta vnese le številko in datum prejetega (dobaviteljevega) dokumenta.


27

Slika 3.3.4.1.2: Potrditev blaga v skladišču

Okoliščino, ki pove v kateri fazi je dokument, smo enostavno rešili s statusom

dokumenta. Če je dokument v statusu nič, to pomeni, da se kreira kot naročilo in da se na

takšen dokument lahko dodajajo in brišejo pozicije ali pa se spreminja vsebina pozicij. Ko

dokument kot naročilo potrdimo, preide v status ena, kar pomeni, da se ga kot naročilo

lahko samo pregleduje in izpisuje in da spreminjanje dokumenta ni več mogoče. Dokument

s statusom ena se uporablja tudi kot količinski prevzem v skladišču, kjer se samo

količinsko potrdi in preveri ali se količina dobavljenega blaga ujema s količino naročila. S

potrditvijo dokumenta v statusu ena preide dokument v status dve. Dokument v statusu dve

ni več viden v modulu naročanja blaga, je pa še vedno viden skladiščniku, ki lahko takšen

dokument samo pregleduje in izpisuje. V modulu količinskega prevzema namreč popravek

dokumenta ni več mogoč. Dokument v tej fazi se nato pojavi še v zadnji fazi, in sicer v

kalkulaciji blaga, kjer blagu, ki smo ga dobili na zalogo »zgradimo« ceno.


28

Kalkulacija blaga

Kalkulacija blaga ali »gradnja« pomeni, da na osnovi dobaviteljeve cene in

dobaviteljevega rabata izračunamo neto ceno. Na neto ceno dodamo različne stroške, kot

na primer stroške prevoza, stroške skladiščenja ali stroške carine. S tem dobimo nabavno

ceno, ki je osnova za nadaljnji izračun. Na nabavno ceno dodamo veleprodajno ali

maloprodajno maržo in s tem dobimo prodajno ceno, kateri je potrebno prišteti še davek na

dodano vrednost. S tem dobimo prodajno ceno z davkom na dodano vrednost. Povsod, kjer

je možnost vnesti procent, je možno vnesti tudi absolutni znesek. Rešitev je sledeča. Če

vnesemo procent se absolutna vrednost izračuna na podlagi procenta, vnosno polje

absolutne vrednosti pa postane pregledno. Pri vnosu absolutne vrednosti moramo polje za

vnos procenta pustiti prazno oziroma vnesemo nič procentov, s tem pa postane polje

absolutne vrednosti vnosno in vanj vnesemo absolutno vrednost, procent pa se izračuna na

podlagi vnesenega podatka.

Slika 3.3.4.1.3: Kalkulacija blaga

Na vsaki kalkulaciji blaga imamo tudi pomožna polja, ki nam pomagajo pri »izgradnji«

cene. To je lepo razvidno na skrajni desni strani Slike 3.3.4.1.3.


29

Privzeti pogoji pomenijo, da lahko že pri samem vnosu artikla nastavimo privzeto

maržo (razvidno s Slike 3.3.3) in si s tem olajšamo delo pri kalkulaciji pozicije dokumenta.

Zadnji pogoji so razvidni z zadnje nabave blaga, kar nam koristi pri sami kontroli

nabave blaga in spremljanju dobavitelja, ali nam le-ta daje vedno enake prodajne pogoje.

Povprečni pogoji so pogoji, izračunani z vseh nabav blaga.

Ko naredimo celotno kalkulacijo blaga do konca, le-to potrdimo in takšen dokument

dobi status tri, kar pomeni, da ni več viden v količinskem prevzemu v skladišču in da

takšnega dokumenta ni mogoče spremeniti, lahko pa se ga pregleduje in izpisuje.

Prav tako se ob potrditvi takega dokumenta vsi kalkulativni elementi zapišejo v entiteto

(tabelo) zaloge, kjer so vpisani zadnji in povprečni pogoji za blago, ki smo ga prevzeli. Če

v tabeli zaloge blaga, ki smo ga prevzeli, še ni, ga dodamo v tabelo. V nasprotnem primeru

se zadnji pogoji prepišejo čez zadnje že vpisane pogoje, povprečni pogoji pa se

preračunajo na nove povprečne pogoje.


30

3.3.4.2 Prodaja blaga

Za tem, ko blago prevzamemo in potrdimo prevzem je možna prodaja blaga. Tako pri

prodaji, kot pri nabavi blaga se navezujemo na tabelo zaloge, vendar pri nabavi blaga v

tabelo zapisujemo podatke, pri prodaji blaga pa črpamo podatke iz tabele in v tabelo

zapisujemo le podatek o datumu prodaje in novo količino na zalogi, ki je zmanjšana za

količino prodaje. Količina blaga v tabeli zaloge je zapisana dvonivojsko, in sicer imamo

količino zaloge in rezervirano količino. Na pregledih količine blaga na zalogi je tako

prikazana prosta zaloga, ki predstavlja razliko med količino zaloge in rezervirano količino.

Zakaj smo se odločili za dvonivojsko zapisovanje količine blaga v tabeli zaloge?

Razlogi za takšno odločitev izhajajo iz izkušenj v praksi, saj je narava prodaje takšna,

da imamo dobavnico odprto določeno časovno obdobje ( teden, mesec, itd), ne glede na

odprte dokumente pa želimo imeti v vsakem trenutku točno evidenco količine blaga v

skladišču. Tako se ob izpisu dobavnice status dokumenta spremeni, in sicer preide iz

statusa nič v status ena. Zaloga blaga, ki je na prodajnem dokumentu, se v tabeli zaloge ne

spremeni, spremeni se le rezervirana količina, ki se poveča za količino prodaje, s tem pa se

zmanjša prosta zaloga. Ob potrditvi dokumenta oziroma ko je dokument zaključen in

želimo narediti izpis računa, dokument preide iz statusa ena v status tri. S tem se dokument

zaključi. Navedeno pomeni, da dokumenta ni več mogoče popravljati oziroma ga

spreminjati, možno pa ga je pregledovati in izpisovati. Ob sami potrditvi dokumenta se v

tabeli zaloge zmanjša količina rezervacije za količino prodaje, prav tako pa se za enako

količino zmanjša tudi količina zaloge, ob tem pa ostane prosta zaloga nespremenjena.

V glavo prodajnega dokumenta vnesemo šifro kupca. Tako kot pri nabavi blaga imamo

tudi tukaj možnost vnosa novega prejemnika, če prejemnik še ni vpisan v šifrantu

partnerjev. Ostali podatki, ki se še vnašajo v glavo dokumenta so vezni dokument. Tukaj je

možno vpisati številko naročila blaga (če vršimo prodajo na podlagi naročila stranke),

datum odpreme blaga in šifro potnika, ki jo potrebujemo za kasnejše prodajne evidence.

Šifra potnika je praktična zlasti v primeru, če želimo voditi prodajo in spremljati promet po

posameznih potnikih.


31

V pozicije prodaje imamo možnost vnosa le šifre artikla in količine. Glede na navedeno

je prodaja zelo zaprta in tako komerciala nima vpliva na ostale prodajne pogoje kot so

rabati in popusti.

Slika 3.3.4.2: Uporabniški vmesnik – Prodaja blaga


32

3.3.5 Šifranti

Pri šifrantih smo se odločili za prav poseben sistem zapisa, ki ga nudi prav FlexGen

generator.

Zadeve smo se lotili tako, da smo najprej opisali osnovni zapis dolžine 128 in ga

razdelili na ključ dolžine 20 in ostali del dolžine 108. Ključ smo nato v tretjem nivoju

razdelili na 2 + 18, kje je 2 alfa numerično polje, 18 pa numerično polje. S tem smo dobili

osnovni record.

Slika 3.3.5.1: Opisnik primarnega šifranta

Izpeljane recorde pa smo naredili tako, da smo prvi dve mesti ključa uporabili za

primarni ključ podšifrantov, za katerega program sam skrbi in ga sam avtomatsko zapisuje

pri zapisovanju v tabelo (iz Slike 3.3.5.2 je razvidno, da se avtomatsko zapisuje vrednost

»DO«). Pri pregledu podatkov program sam skrbi, da dostopa samo do podatkov, ki

pripadajo podšifrantu, nad katerim je narejena forma.


33

Slika 3.3.5.2: Lastnosti podšifranta

Slika 3.3.5.2: Opisnik podšifranta

V danem primeru gre za šifrant vrst dokumentov. Tu smo za primarni ključ uporabili

SIFR-DO-SIFR in mu dodali relacijo na vrednost »DO«, kar pomeni, da ta forma dostopa

do podatkov v tabeli šifrantov, ki imajo zapis v prvem delu primarnega ključa »DO«. Prav

tako ta forma tudi zapisuje v tabelo šifrantov in avtomatsko dodeli v prvi del (SIFR-DO-

SIFR) primarnega ključa vrednost »DO«. Drugi del (SIFR-DO-KLJU) smo uporabili za

ključ v vnosni formi.


34

To tehniko smo uporabili za vse šifrante. Glede na to, da šifrantov ni ravno malo, smo s

tem prihranili veliko časa za načrtovanje, izdelavo in testiranje tabel, ki bi jih sicer morali

izdelati za vsak šifrant posebej.

3.4 Testiranje

3.4.1 Splošno o testiranju

Pri testiranju programske opreme želimo le-tej dodati vrednost. Dodajanje vrednosti

skozi testiranje pomeni izboljšanje kvalitete in zanesljivosti aplikacije. Izboljšanje

zanesljivosti pomeni iskanje in odpravljanje napak oz. »bugov«. Ko se lotimo testiranja,

moramo predpostavljati, da programska oprema ali sistem vsebuje napake (veljavna

predpostavka za skoraj vsako aplikacijo). Skozi proces testiranja poskušamo najti napake v

čim večjem številu. Definicija testiranja programske opreme bi se lahko glasila takole

(Myers, 2004):

»Testiranje je proces izvajanja programa z namenom iskanja napak.«

Eden izmed primarnih vzrokov za slabo testiranje programske opreme je to, da večina

programerjev napačno razume testiranje. Z njihove strani je velikokrat slišati (Myers,

2004):

• »Testiranje je proces dokazovanja, da napake niso prisotne.«

• »Namen testiranja je pokazati, da program pravilno izvaja pričakovane funkcije.«

• »Testiranje je proces vzpostavljanja zaupanja, da program dela, kar naj bi počel.«

Takšno razmišljanje se posledično prenese na izvajalce testiranja, kar se pozna na

rezultatih testa. Osnovni koncept testiranja sestavljata dve metodi, in sicer metoda črne in

bele skrinjice. Pri metodi črne skrinjice ali funkcionalni analizi preverjamo izhodne

podatke aplikacije pri danih vhodnih podatkih, ki morajo biti v skladu s funkcionalno


35

specifikacijo aplikacije. Pri metodi bele skrinjice ali strukturni analizi preverjamo izhodne

podatke aplikacije pri danih vhodnih podatkih, ki morajo biti v skladu s strukturalno

specifikacijo aplikacije.

Zakaj ni mogoče izvesti popolnega testa?

Mnogi menijo, da je potrebno testirati vse kombinacije, da bi lahko dokazali, da

programska oprema deluje. To seveda ni mogoče, saj ni možno preveriti vseh vhodnih

podatkov, časovnih usklajevanj in možnih poti.

3.4.2 Testiranje aplikacije

V konkretnem primeru smo aplikacijo za materialno poslovanje testirali tako, da smo

najprej izvedli testiranje enot, nato integracijsko testiranje, nazadnje pa še sistemsko

testiranje.

Testiranje enot

Testiranje enot smo izvedli posamezno na vsaki stopnji modula sistema. To

testiranje smo izvedli sami razvijalci in to še preden smo enote integrirali v

integracijski test z ostalimi enotami. Za testiranje na tej stopnji smo uporabili metodo

bele skrinjice. Testiranju enot lahko rečemo tudi testiranje modulov, saj predstavlja

najnižjo možno komponento za testiranje.

Ločimo tri tipe enot (Dogša, 1993, str. 46):

• navadna enota oz. enota;

• krmilna enota – ima nalogo, da prenese izbrane testne vzorce v enoto, ki jo

testiramo, in nato izpiše izhodne podatke;

• nadomestna enota, ki simulira delovanje originalne enote – sprejme in vrne

podatke, ki jih zahteva klicna enota.

Pri izvedbi testiranja enot se lahko odločimo za dva pristopa (Dogša, 1993, str. 49-50):

• izolirano testiranje enot – namen je ločeno preizkusiti posamezne enote, preden jih

integriramo v kompletni program;


36

• inkrementalno (postopno) testiranje enot – najprej testiramo enoto in nato temu

dodamo novo, še ne testirano enoto.

V našem primeru smo se odločili za izolirano testiranje enot in smo tako vsako enoto

testirali ločeno še preden smo jo integrirali v neko celoto.

Integracijsko testiranje

Integracijsko testiranje je vmesna faza med testiranjem modulov in sistemskim

testiranjem, s katerim smo testirali medsebojno delovanje in skladnost sestavljenega

podsistema. Integracijsko testiranje smo izvajali postopoma, med sestavljanjem

posameznih modulov v podsistem. Podsistem lahko sestavimo na več načinov:

• od spodaj navzgor – najprej podsistem sestavimo z moduli iz najnižje stopnje, ki jih

potem zamenjamo z moduli višje stopnje;

• od zgoraj navzdol – podsistem sestavimo z moduli najvišje stopnje, ki jih potem

zamenjujemo z moduli nižje stopnje;

• mešanica pristopa od spodaj navzgor in pristopa od zgoraj navzdol.

Z integracijskim testiranjem smo opravili delni test sistema, pri katerem nismo

čakali na dokončanje vseh komponent, ampak smo testirali sproti. Integracijsko

testiranje smo opravili, ko smo imeli dokončane in testirane posamezne enote, ki

tvorijo neko celoto (integracijo).

Tako smo odpravljali napake, ne da bi vplivali na proces razvoja ostalih komponent.

Pri testiranju na tej stopnji smo uporabljali mešanico metod črne in bele skrinjice.

Sistemsko testiranje

Sistemsko testiranje je najtežavnejši proces testiranja in je velikokrat tudi napačno

razumljen. Sistemsko testiranje še ne pomeni testiranja delovanja celotnega sistema, saj

bi bilo potem funkcionalno testiranje odveč. Osnovna naloga tega testiranja je dokazati,

da program v popolnosti ne ustreza vsem postavljenim kriterijem (Myers, 2004):


37

1. Sistemsko testiranje ni omejeno na sistem. Če je produkt aplikacija, testiranje

sistema poskuša prikazati, kako aplikacija kot celota ne ustreza zahtevam.

2. Sistemsko testiranje ni možno, če ni zapisanih in merljivih zahtev produkta.

Testne primere za sistemsko testiranje načrtujemo s pomočjo analize zahtev,

izoblikujemo pa jih z analizo uporabniške dokumentacije. Zaradi odsotnosti metod za

sistemsko testiranje ta proces zahteva dodatno mero ustvarjalnosti. V nadaljevanju smo

navedene različne kategorije, ki jih lahko uporabimo pri oblikovanju testnih scenarijev

(nekatere izmed njih smo uporabili v planu testiranja aplikacije za materialno

poslovanje):

• testiranje obsega podatkov;

• testiranje stabilnosti;

• testiranje uporabnosti;

• testiranje delovanja;

• testiranje konfiguracije;

• testiranje kompatibilnosti;

• testiranje nameščanja;

• testiranje zanesljivosti;

• testiranje obnovitve delovanja;

• testiranje dokumentacije;

• testiranje postopkov.

Testiranje obsega podatkov

Pri tem procesu smo aplikacijo za materialno poslovanje izpostavili velikim

količinam podatkov. Cilj tega testa je dokazati, da aplikacija ne prenese obsega

podatkov, navedenih v njenih zmožnostih.

Testiranje stabilnosti

Pri testiranju stabilnosti smo aplikacijo za materialno poslovanje izpostavili

velikemu »bremenu« oziroma »naporu«. Tega testiranja ne smemo zamenjati s

testiranjem obsega podatkov. Največja možna količina podatkov ali aktivnosti v

kratkem časovnem razponu predstavlja velik napor.


38

Testiranje uporabnosti

Naslednja pomembna kategorija pri sistemskem testu je iskanje problemov pri

uporabi programa. Velik del testiranja uporabnosti zajema testiranje uporabniškega

vmesnika (UI), preko katerega uporabnik komunicira z aplikacijo. Vsaka aplikacija ima

neke vrste UI. Sodobni računalniški programi pa imajo grafični uporabniški vmesnik

(GUI). Dober uporabniški vmesnik naj bi imel naslednje lastnosti:

• sledi standardom in trendom;

• intuitiven;

• skladen;

• prilagodljiv;

• udoben;

• pravilen;

• uporaben.

Pri testu uporabnosti se je treba posvetiti sledečim vprašanjem:

• Ali je bilo vsako uporabniško okno narejeno v skladu z inteligenco, stopnjo

izobrazbe in dejavniki okolja končnega uporabnika?

• Ali so izhodni podatki sistema vsebinsko ustrezni in primerni za nadaljnjo

uporabo?

• Ali so sporočila napak v sistemu razumljiva, tako da jih razumemo brez posebnega

računalniškega znanja?

V današnjih sistemih, ki so namenjeni masovni uporabi, še vedno zasledimo

sporočila kot so: »Prišlo je do nepričakovane napake.« ali »Prišlo je do napake, zato

morate zapreti program.«.

• Ali uporabniški vmesniki odražajo pomembno pojmovno celoto, složnost, enotnost

sintakse, formata, sloga in kratic?

• V sistemih kot so npr. bančni sistemi, kjer se preverjajo različni vhodni podatki, je

točnost ključnega pomena. Te vrste bančni sistem bi moral zahtevati številko

računa, ime lastnika in osebno identifikacijsko kodo (PIN4) kot zagotovilo, da do

računa dostopa prava oseba.


39

• Ali sistem vsebuje prekomerno število možnosti ali opcij, ki se bodo uporabljale

zelo redko? Eden od trendov v moderni programski opremi je ta, da uporabniku

ponudimo samo tiste možnosti, ki jih najpogosteje uporablja.

• Ali se sistem na vse vhodne akcije odziva na enak način? Na primer z miško

kliknemo na polje in posledica je takoj vidna. V drugem primeru, ko gre za akcijo,

ki zahteva več časa za izvedbo, se mora pokazati sporočilo, ki uporabnika obvesti,

kaj se dogaja.

• Ali je sistem enostaven za uporabo? Na primer ali je geslo za vstop občutljivo na

velike in male črke brez vednosti uporabnika? Ali je jasno prikazano, kako se vrniti

na osnovni meni, če je na razpolago cela vrsta menijev?

Testiranje delovanja

Mnogi sistemi imajo specifično določene zmogljivosti, kot so odzivni čas, čas

obdelave in nastavitvene možnosti. S tem testom smo želeli dokazati, da aplikacija ni

narejena tako, da zadovolji te specifične zahteve.

Testiranje konfiguracije

Kompleksni operacijski sistemi ali komunikacijska programska oprema podpirajo

zelo široko paleto strojne opreme, veliko vhodnih in izhodnih naprav ter

komunikacijskih poti. Pogosto je število možnih konfiguracij preveliko, da bi testirali

vse kombinacije. Zato je dobro, da sistem testiramo vsaj s strojno opremo, kjer

uporabimo minimalno in maksimalno število teh naprav. Današnje aplikacije so

narejene tako, da delujejo na več operacijskih sistemih, zato morajo biti v test vključeni

vsi podprti sistemi.

Testiranje kompatibilnosti

Večina programske opreme, ki se razvija, ni povsem nova. Običajno gre za

zamenjavo nezadostne opreme. Takšne aplikacije imajo specifične zahteve, ki se

nanašajo na kompatibilnost in migracije iz obstoječih sistemov. Pri tej vrsti testiranja

skušamo dokazati, da zahteve glede kompatibilnosti in migracije ne držijo in tako na

primer naredimo prenos podatkov iz ene baze v drugo.


40

Testiranje nameščanja

Nekatera programska oprema ima zapleten namestitveni proces. Test

instalacijskega procesa je pomemben del testiranja sistema. To še posebej velja, če je ta

proces avtomatiziran in je del programskega paketa. Napaka v instalacijskem procesu

lahko povzroči negativno mnenje o celotni aplikaciji.

Testiranje zanesljivosti

Cilj vseh vrst testiranja je izboljšanje zanesljivosti programske opreme. Če

aplikacija vsebuje specifične zahteve glede zanesljivosti, se specifični testi zanesljivosti

lahko izmislijo. Testiranje zahtev zanesljivosti je lahko težavno. Pri on-line sistemu,

kot je na primer WAN6, je lahko zahteva po dostopnosti 99,97 % celotnega časa

delovanja sistema. Z nobeno znano metodo ne moremo testirati te zahteve v testnem

obdobju več mesecev ali celo let. Aplikacije ali sisteme s skromnimi časovnimi razponi

med pojavljanjem napak je možno testirati.

Testiranje obnovitve delovanja

Operacijski sistemi, podatkovne baze in komunikacijske aplikacije imajo

mnogokrat zahtevo po samodejni ponovni vzpostavitvi delovanja, če pri tem pride do

prekinitve. Eden izmed ciljev takšnih sistemov je minimiziranje povprečnega časa

ponovne vzpostavitve delovanja. Čas nedelovanja sistema povzroči izpad prihodkov

podjetja, ker sistem ne deluje. Eden izmed namenov testa je dokazati, da sistem ne

ustreza zahtevam MTTR. Običajno imajo vrednosti MTTR zgornjo in spodnjo

vrednost, kar moramo v testu tudi upoštevati.

Testiranje dokumentacije

Testiranje uporabniške dokumentacije je prav tako področje, s katerim se ukvarja

sistemsko testiranje. Osnovni princip izvedbe testa dokumentacije je uporaba

dokumentacije pri oblikovanju testov. Uporabniška dokumentacija naj bi bila tudi

predmet inšpekcije, ki preverja točnost in jasnost le-te. Vsi navedeni primeri v

dokumentaciji morajo biti vključeni v testne scenarije in testirani.


41

Testiranje postopkov

Mnoge aplikacije so sestavni deli večjih, ne v celoti avtomatiziranih sistemov.

Vsaka ročno napisana procedura za sistemske operaterje, administratorje podatkovnih

baz in končne uporabnike mora biti testirana v sklopu testa sistema. Administrator

podatkovnih baz mora opisati postopek za arhiviranje in restavriranje podatkovne baze

programske opreme ali sistema.


42

4. SKLEP

Pomena kakovosti storitve se zelo dobro zavedamo storitvena podjetja z daljšo

tradicijo. Zavedamo se, da je naš položaj na trgu odvisen predvsem od celovite kakovosti

produktov in storitev, ki jih ponujamo. Podjetja, ki se ukvarjamo z razvojem programskih

rešitev, pa moramo skrbeti, da aplikacije delujejo čimbolj brezhibno in da izpolnjujemo

specifikacije, ki smo jih upoštevali pri razvoju.

Glede na kompleksnost in velikost današnje programske opreme je pisanje programske

kode, ki ne vsebuje napak, zelo težko izvedljivo tudi za najbolj izkušene programerje. Zato

testiranje programske opreme spada med kritične naloge pri razvoju programske opreme,

ki se mora izvesti profesionalno in učinkovito. Z nenehnim povečevanjem in širjenjem

zaupanja v programsko opremo pri vsakodnevnih opravilih in s prodornostjo le-te v

medicino, telekomunikacije, proizvodno in finančno industrijo lahko programska napaka

povzroči katastrofo. Kakovostne programske opreme ne moremo narediti z ad–hoc ali z

delno narejenim projektom., pač pa je potreben načrten in discipliniran pristop k vsaki fazi

projekta.

Diplomska naloga je razdeljena na dva sklopa. V prvem sklopu je v grobem

predstavljen generator FlexGen, nato je opisano kaj ta generator nudi, v nadaljevanju pa so

predstavljene še splošne karakteristike obravnavanega generatorja. V drugem sklopu

diplomske naloge je opisana gradnja končnega produkta in sicer aplikacije za materialno

poslovanje, vse od načrtovanja in implementacije vse do samega testiranja aplikacije.

V diplomski nalogi je opisan in predstavljen samo osnovni koncept materialnega

poslovanja, to je nabava in prodaja. Razlog za odločitev o tem, da se obravnava samo

osnovni koncept materialnega poslovanja, je izključno v veliki obsežnosti materialnega

poslovanja. Večji sklopi, ki še spadajo v okvir materialnega poslovanja in niso zajeti v tej

diplomski nalogi so inventura, proizvodnja, dana konsignacija, prejeta konsignacija in

drugo.


43

Vizija za prihodnost je vključitev vseh prej naštetih sklopov v materialno poslovanje in

seveda tudi razvoj finančnega poslovanja ter navezava materialnega poslovanja na

finančno poslovanje. Navedeno pomeni izdelavo likvidacijskega modula za prenos nabave

blaga, izdelava programov za prenos prodajnih podatkov iz materialnega poslovanja v

finančno in programov za vknjižbo teh podatkov v finančne evidence (glavna knjiga,

saldakonti in DDV).


44

5. LITERATURA

[1] Liant retooling Enterprise Systems 1999, RM/COBOL Version 7.0 User's Guide, Liant

Software Corporation, USA 1999;

[2] Liant retooling Enterprise Systems 1999, RM/COBOL Version 7.0 Language

Reference Manual, Liant Software Corporation, USA 1999;

[3] Informacijski sistemi I, Procesni modeli, življenjski cikel programske opreme, SZPO,

Doc. Dr. Matjaž B. Jurič;

[4] ANSI/IEEE Std. 830 -1984;

[5] Franc Solina (1997), Projektno vodenje razvoja programske opreme, Fakulteta za

računalništvo in informatiko, Ljubljana, 1997;

[6] Myers G. J., The art of software testing, New Jersey John Wiley & Sons, Inc., 2004;

[7] Tomaž Dogša, Verifikacija in validacija programske opreme: V&V, Fakulteta za

elektrotehniko, računalništvo in informatiko, Maribor 1993.


45

6. VIRI

[1] LIANT, [URL: http://www.liant.com/];

[2] EasiRun Europa, [URL: http://www.easirun.de/];

[3] Agile Alliance, [URL: http://www.agilealliance.org];

[4] Agile Manifesto, [URL: http://www.agilemanifesto.org];

[5] Dogša T.: Verifikacija in validacija programske opreme,

[URL: www.kal.si/4gb_gkr/rso/vsebina/TESTIRANJE.doc];

[6] Načrt testiranja programske opreme,

[URL: http://lisa.uni-mb.si/%7Ebregar/Vaje/Nacrt%20testiranja%20PO.pdf ];

[7] Agrina iNFORMATIKA d.o.o., Interna gradiva.


46

IZJAVA O ISTOVETNOSTI TISKANE IN ELEKTRONSKE VERZIJE DIPLOMSKE NALOGE

Ime in priimek študenta: _BORUT HAUPTMAN_____________________________ Številka indeksa: _93415364________________________________________ Študijski program: _RAČUNALNIŠTVO IN INFORMATIKA______________ Naslov diplomskega dela: _NAČRTOVANJE IN IZDELAVA APLIKACIJ V PROGRAMSKEM OKOLJU FLEXGEN___

Mentor: _viš. pred. mag. Davor BONAČIĆ_____________________ Somentor: _________________________________________________ Podpisani _BORUT HAUPTMAN_se strinjam, da se moja diplomska naloga objavi na portalu Digitalne knjižnice Univerze v Mariboru. Izjavljam, da sem diplomsko nalogo izdelal sam ob pomoči mentorja in nisem kršil avtorskih pravic in intelektualne lastnine drugih. Tiskana verzija diplomske naloge je istovetna elektronski verziji, ki sem jo oddal v Digitalno knjižnico Univerze v Mariboru.

Podpis študenta: _________________________

V nadaljevanju izpolnite samo, če diplomska naloga ne sme biti javno dostopna.

Diplomsko delo ni javno dostopno, zaradi zagotavljanja konkurenčneprednosti, varstva industrijske lastnine ali tajnosti podatkov naročnika.

Naročnik izdelave začasno nedostopne diplomske naloge je:

Naloga ne sme biti javno dostopna do ________________________. Podpis mentorja: _________________________

Podpis odgovorne osebe naročnika in žig: _________________________________

borut hauptman na rtovanje in izdelava aplikacij v ... · primer uporabe – na’rtovanje,...

Documents