Click here to load reader

ANALIZA IN PRENOVA SISTEMA UPRAVLJANJA Z …eprints.fri.uni-lj.si/841/1/Pahor_A._VS.pdf · Teoreti čno lahko imamo tudi samo en modul in v njem navadne mape, je pa bolj prakti čno

  • View
    215

  • Download
    0

Embed Size (px)

Text of ANALIZA IN PRENOVA SISTEMA UPRAVLJANJA Z …eprints.fri.uni-lj.si/841/1/Pahor_A._VS.pdf · Teoreti...

UNIVERZA V LJUBLJANI FAKULTETA ZA RAUNALNITVO IN INFORMATIKO

Aleksander Pahor

ANALIZA IN PRENOVA SISTEMA UPRAVLJANJA Z DOKUMENTACIJO V

PODJETJU

Diplomsko delo na visokoolskem strokovnem tudiju

Mentor: dr. Mojca Ciglari

Ljubljana, 2009

I Z J A V A O A V T O R S T V U

diplomskega dela Spodaj podpisani/-a ____________________________________, z vpisno tevilko ____________________________________, sem avtor/-ica diplomskega dela z naslovom: _________________________________________________________________________ _________________________________________________________________________ S svojim podpisom zagotavljam, da: sem diplomsko delo izdelal/-a samostojno pod mentorstvom (naziv, ime in priimek) ___________________________________________________________________ in somentorstvom (naziv, ime in priimek) ___________________________________________________________________ so elektronska oblika diplomskega dela, naslov (slov., angl.), povzetek (slov., angl.) ter kljune besede (slov., angl.) identini s tiskano obliko diplomskega dela soglaam z javno objavo elektronske oblike diplomskega dela v zbirki Dela FRI. V Ljubljani, dne ______________ Podpis avtorja/-ice:______________________

Zahvala V prvi vrsti se zahvaljujem svoji mentorici dr. Mojci Ciglari za potrpljenje, ki ga je izkazala z menoj. Predvsem cenim to, da je bila pripravljena z nekaterimi izdelki poakati, kar je bilo pogojeno z mojim delom, ki velikokrat ne dopua, da bi se svojim ostalim obveznostim posvetil toliko, kolikor bi si zasluile. Zahvaljujem se vsem v podjetju Hermes Softlab d.d., ki so mi vedno stali ob strani in mi pomagali odrasti strokovno, poslovno in osebno. Davorju Hvali, ki me je vzel v slubo in vsem mojim nadrejenim: Aleu Pestotniku, Primou Svetku, Mihi Urbaniji in Aleu Koirju, ki so mi zaupali vedno bolj odgovorne naloge, ki so mi omogoile videti svet in delati na mnogih projektih in podjetjih. To mi je dalo samozavest, da lahko suvereno nastopim pred komerkoli. Zahvala gre tudi vsem sodelavcem podjetij SEZ Ag. in NLB d.d., s katerimi sem strokovno izredno napredoval. Zahvaljujem se svojim soolcem na fakulteti, ki so mi pomagali, da sem vedno dobil vse zapiske in bil seznanjen z vsem, kar se je na fakulteti dogajalo, posebno Gaperju Petrau in Primou Furlanu, s katerima sem se uil za izpite in brez katerih bi mi bilo veliko teje pri opravljanju le-teh. Nazadnje, ampak najbolj toplo, se zahvaljujem svoji druini, ki nikoli ni obupala nad tem, da bom zakljuil tudij. Za vsa priganjanja in opominjanja moji najveji zaveznici, prijateljici, punci in sedaj eni Vesni. Mojim starem Boji in Zdravku, ki sta me vzgojila z vso ljubeznijo in neumorno prenaala vsa zavlaevanja pri tudiju. Babi in edu za vedno toplo besedo in brezpogojno podporo pri vsem, kar sem in bom poel. Mojemu mlajemu bratu Klemnu in moji herki ivi pa za vseprisoten opomin, da je potrebno biti vasih komu tudi v zgled.

Vesni

Kazalo POVZETEK ...................................................................................................................................................... 1

1 POSLOVNO OKOLJE IN OPIS SISTEMA PRED PRENOVO ....................................................... 3

1.1 NAMEN IN IZHODIA ...................................................................................................................... 3 1.2 PREDSTAVITEV POSLOVNEGA OKOLJA IN TRENUTNEGA NAINA VERZIONIRANJA ............................ 4 1.3 RAZLINA ORGANIZACIJSKA OKOLJA ............................................................................................... 5

1.3.1 Poslovno okolje Globus in NBO .............................................................................................. 5 1.3.1.1 Vloge lanov projekta ............................................................................................................................. 5 1.3.1.2 ivljenjski cikel projektov ...................................................................................................................... 7

1.3.2 IT okolje NLB d.d........................................................................................................................ 7 1.3.2.1 Sektor za razvoj ....................................................................................................................................... 8 1.3.2.2 Sektor za infrastrukturo ........................................................................................................................... 8 1.3.2.3 Sektor za podporne funkcije ................................................................................................................... 8

1.4 OPIS STAREGA NAINA IZDELAVE DOKUMENTACIJE PRI OBEH CILJNIH PROJEKTIH ........................... 9 1.4.1 Teave s poimenovanjem datotek .............................................................................................. 10 1.4.2 Teave z dostopanjem in spreminjanjem istega dokumenta s strani ve razlinih uporabnikov11 1.4.3 Teava pri nadzoru dela na projektu ........................................................................................ 12 1.4.4 Teava poasnosti obnovitve izgubljenih ali izbrisanih podatkov ............................................ 12 1.4.5 Teava varovanja podatkov in doloanja dostopov .................................................................. 12 1.4.6 Teave s pregledovanjem razlik med dvema razliicama istega dokumenta ............................ 13 1.4.7 Teava z doloanjem natannega asa nastanka datoteke ....................................................... 13 1.4.8 Teava z doloanjem tega, kdo je opravil popravek v datoteki................................................. 14 1.4.9 Teava z doloanjem vzroka za nastanek nove revizije ............................................................ 14

2 IZPOPOLNJEN SISTEM HRANJENJA DOKUMENTACIJE ...................................................... 15

2.1 DOLOANJE KRITERIJEV IZBIRE ...................................................................................................... 16 2.2 OCENA RAZLINIH ORODIJ ............................................................................................................. 22

2.2.1 Kriteriji za izbiro orodja ........................................................................................................... 23 2.2.1.1 Pomanjkanje dostopnih podatkov ........................................................................................................ 23 2.2.1.2 Model skladia ..................................................................................................................................... 25 2.2.1.3 Stopnja zrelosti izdelka ......................................................................................................................... 25 2.2.1.4 Vejezina podpora orodja ................................................................................................................... 25 2.2.1.5 Ostale tipine teave in interni mehanizmi sistema za nadzor razliic .............................................. 26 2.2.1.6 Cena ........................................................................................................................................................ 27

2.2.2 Konna primerjava in izbira med ustreznima orodjima CVSNT in SubVersion ....................... 29 2.3 IZBRANO ORODJE IN NAIN POVEZAVE ........................................................................................... 31

2.3.1 Namestitev strenika ................................................................................................................. 32 2.3.2 Namestitev odjemalcev ............................................................................................................. 34

2.4 IZDELAVA SPREMNE DOKUMENTACIJE ........................................................................................... 35 2.4.1 Administratorska dokumentacija .............................................................................................. 36 2.4.2 Uporabnika dokumentacija ..................................................................................................... 36 2.4.3 Dokumentacija za delavnice ..................................................................................................... 37

2.5 DELAVNICE ZA UPORABNIKE .......................................................................................................... 38 2.5.1 Scenarij, ki se uporablja za dokumentacijo projekta Globus: .................................................. 39 2.5.2 Scenarij, ki se uporablja za dokumentacijo projekta NBO: ...................................................... 40 2.5.3 Napredni uporabniki ................................................................................................................. 40

2.6 POTREBE IN FUNKCIJE VODSTVA PROJEKTA .................................................................................... 40 2.7 IZKUNJE IN SUBJEKTIVNA OCENA UVAJANJA NOVE REITVE ......................................................... 42

3 SKLEPNE UGOTOVITVE ................................................................................................................. 44

Prevodi in razlage kratic in tujk ACL Access Control List Seznam nadzora dostopov API Application

Programming Interface Vmesnik za programiranje aplikacij

ASCII American Standard Code for Information Interchange

Amerike standarne kode za izmenjavo informacij

CAU Centralna Administracija Uporabnikov Changeset Mnoica sprememb je nedeljiv paket spremenjenih datotek CM Configuration

managment Upravljanje z nastavitvami

CMS Content Management Systems

Sistem za upravljanje z vsebinami

CVS Concurrent Version Control System

Sistem za nadzor hkratnih razliic omogoa vejemu tevilu uporabnikom istoasno nadzorovan in beleen dostop do datotek v skupni rabi

Datamining Podatkovno rudarjenje. Opisuje dejavnost iskanja podatkov po bazah podatkov ali drugih oblikah zbirk in zapisov podatkov

EOL End of line ASCII koda znaka za konec vrstice EVS Naslednik CVSNT strenika EXT EXTender file system Tip datotenega sistema Floating licence Konkurenna licenca omogoa delo z eno licenco ve

razlinim uporabnikom, vendar samo enemu od njih naenkrat

Globus Aplikacija za transakcijsko poslovanje s pravnimi osebami GNU/GPL GNU General Public

Licence Tip licenciranja, ki omogoa odprtokodne reitve

GSSAPI Generic Security Service API

Sploni vmesnik za varnostne storitve

GUI Graphic User Interface Grafini uporabniki vmesnik High-end Navadno opisuje nekaj, kar je objektivno najbolje v svoji

skupini ali podroju IDE Integrated Development

Enviroment Integrirano razvojno okolje

IIS Internet Information Server

Strenik spletnih strani

IT Information Technology Informacijske Tehnologije KIT Katalog Informacijske

Tehnologije Zbirka obrazcev in predpisov informacijske tehnologije podjetja NLB d.d.

Memory leak Dogodek, ki se zgodi, ko se v aplikaciji neka podatkovna struktura ne sproa dovolj skrbno in ostanejo deli pomnilnika zasedeni, kljub neuporabi, skozi as pa se velikost tako zasedenega pomnilnika vea

MSI Microsoft Installer

Aplikacija za nameanje, odstranjevanje in spreminjanje aplikacij v operacijskih sistemih Windows (.msi datoteka)

Multisite Opisuje geografsko razprene sisteme, storitve ipd. Mvfs MultiVersion

FileSystem Tip datotenega sistema, ki omogoa shranjevanje razliic

NBO Novo Banno Okence. Aplikacija za uporabnike po poslovalnicah, ki zdruuje razline zaledne sisteme.

NDCS Sistem za nadzor razliic elementov sistema Globus NLB d.d. Nova Ljubljanska Banka delnika druba NTFS New Technology File

System Standardni datoteni sistem Windows NT druine operacijskih sistemov Microsoft

OS Operating System Operacijski Sistem PC Team Skupina znotraj UCIT, ki skrbi za namestitve osebnih

raunalnikov PSERVER Avtentikacijski protokol Product Izdelek ali veinoma pogovorno produkt opisuje navadno

aplikacijo v irem pomenu besede RC Revision Control Nadzor razliic RCS Revision Control

System Sistem za nadzor razliic

Revizija Verzija Razliica root Koren SCCS Source Code Control

System Sistem za nadzor izvorne kode

SCM Source Code Management

Sistem za nadzor razliic izvorne kode

SMS Microsoft Systems Management Server

Sistem za upravljanje sistemov Microsoft

SSH Secure SHell Varna lupina SSP Security Service

Provider Ponudnik storitve varnosti

SSPI Security Support Provider Interface

Vmesnik storitve podpore varnosti

SVN SubVersion Kratica za aplikacijo SubVersion UCIT Upravljalski center informacijske tehnologije UNIX Druina operacijskih sitemov UTF Unicode

Transformation Format Format zapisa nabora znakov

VCS Version Control System Sistem za nadzor razliic VPN Virtual Private Network Navidezno zasebno omreje VSS Visual Source Safe Kratica za aplikacijo Visual Source Safe Wrapper Opisuje dejavnost programske opreme, da deluje kot

adapter med programskimi reitvami

Pojmi CVSNT Razliica ali revizija ali verzija (Revision, Version) je stanje neke datoteke ob tono doloenem asu. Razliica ima neko interno tevilko, ki je odvisna od zaporednega tevila in morebitnega razvejanja. tevilka razliice je interna in se je ne da prirejati. Vse razliice so vrste 1.n ali 1.n.m, vrednost ne bo nikoli dosegla 2.0. Vsaka razliica ima lahko prilepljeno eno ali ve oznak, s katerimi bolje nadzorujemo, kaj je vsebina razliice, in seveda komentar avtorja in as objave. Skladie (Repository) je osnovno skladie kjer so shranjene datoteke pod nadzorom hkratnih razliic. Skladie se nahaja na streniki strani. Uporabnik mora poznati samo ime njegovega korena (root). Navadno (tudi priporoeno) potrebujemo samo eno skladie, saj lahko v njem ustvarjamo ve modulov. Veja (Branch). Zaradi laje predstave razliice organiziramo tako, da so bolj pregledne. Veja navadno pomeni, da bo neka skupina ali uporabnik dalj asa spreminjal datoteko in zato ne eli motiti ostalega razvoja, ki se nadaljuje na glavni veji. Po konanem razvoju na veji je potrebno spojiti razvojno vejo v glavno vejo. Oznaka (Tag) Na razliico lahko nalepimo napis ali oznako, s katerim bomo kasneje lahko operirali. Ob prevzemu lahko podamo oznako in tako pridobimo vse razliice datotek, ki imajo to oznako na sebi. Oznako uporabljamo za bolj mone in ire opombe, ki zadevajo veje tevilo datotek pa tudi za nadzor na izdajami. Izdaja (Release) je skupek datotek, ki so oznaene s skupno oznako, za katero smo se odloili, da bo oznaka izdaje. Izdaja je navadno nek cilj v funkcionalnostih ali asovnem obdobju, pri kateri se ustavimo z razvojem in pogledamo celotno sliko stanja datotek naega izdelka. Predvsem je uporabno, da se lahko (e smo pravilno in celotno oznaili vse datoteke) kadarkoli vrnemo na doloeno izdajo tako, da podamo oznako izdaje ob prevzemu datotek. Modul (Module) je ena od osnovnih map skladia. Navadno predstavlja zakljueno skupino datotek. Teoretino lahko imamo tudi samo en modul in v njem navadne mape, je pa bolj praktino (e je mono) natanno razmejiti datoteke po skupinah, ki jih bodo uporabljale oz. po namenu shranjenih datotek. Ob prevzemu je potrebno izbrati tudi modul in tako ustvariti lokalno kopijo modula v svojem peskovniku. Peskovnik (Sandbox) je prostor na lokalnem disku, kjer se nahajajo prevzete datoteke iz skladia. Iz peskovnika datoteke poljemo na strenik tako, da jih objavimo. Datoteka, ki se nahaja v peskovniku in e ni objavljena, e ni dostopna ostalim uporabnikom ampak samo nam. Prevzem (Checkout) sproi kopiranje datotek iz doloenega modula skladia pod nadzorom strenika CVSNT na lokalni disk. Datoteke se s strenika prenesejo v peskovnik, kjer so nam na razpolago za popravljanje. Imamo monost izbire po datumu, reviziji ali oznaki. To nam omogoa, da imamo lokalne datoteke iz modula na izbrani dan ali vse datoteke, ki so oznaene z doloeno oznako. Vsak prevzem sproi kopiranje samo ene razliice datoteke. Brez povezave s strenikom ni mogoe pregledovati zgodovine, grafa

revizij, razlik med razliicami datoteke itd. Lahko pa nemoteno urejamo prevzeto razliico datoteke. Objavi (Commit) je funkcija, s katero se sprememba na datoteki shrani na CVSNT strenik. Samodejno se ji dodeli nova tevilka razliice. Sedaj je ta razliica dostopna tudi vsem ostalim uporabnikom, e sproijo posodobitev svojega peskovnika. Objavimo lahko ve datotek hkrati ali celotno mapo. Ne moremo pa objaviti razliice, ki je enaka predhodni. e je datoteka binarna (.doc, .avi, .xls, ...), se shrani celotna datoteka e enkrat; e je datoteka tekstovna pa samo razlika med prejnjo razliico. Metoda s shranjevanjem samo razlik (t.i. delta) binarne datoteke v CVSNT ne deluje vedno v redu in e v eksperimentalni fazi. Izdaj (Release) pobrie izbrane datoteke/mape iz peskovnika. Vse ostaja e vedno shranjeno na streniki strani. Lahko izbiramo med tremi naini izdaje. - Brisanje celotnega peskovnika brez spremenjenih datotek in datotek, ki niso pod nadzorom CVSNT. - Brisanje popolnoma vseh datotek. - Brisanje kontrolnih datotek CVSNT (rekurzivno). Zadnji nain je uporaben za spremembo peskovnika v navadno mapo. Taka mapa ni ve povezana s CVSNT. Odstrani (Remove) izbrie datoteko/mapo na streniki strani. Datoteka ali mapa se pri tem z zgodovino vred izgubita za vedno. Uporaba tega ukaza je odsvetovana, saj dejansko ni potrebe po trajni odstranitvi datoteke in njene celotne zgodovine. Administrator lahko, preko zaporedja ukazov za oivitev, ponovno povrne tudi izbrisano datoteko. Posodobi (Update) posodobi peskovnik z zadnjimi spremembami, ki so e na streniku (kopirajo se samo nove datoteke datoteke, ki so trenutno urejane ali spreminjane ostanejo nedotaknjene). Posodobitev je sproena z istimi kriteriji, kot je bilo sproeno prevzemanje (datum, razliica ali oznaka). S posebno posodobitvijo lahko spremenimo tudi te kriterije. Dodaj (Add) doda izbrane datoteke/mape na CVSNT strenik. Sedaj je ta datoteka dostopna tudi vsem, e sproijo posodobitev svojega peskovnika. Ta datoteka je sedaj v skladiu. Po dodajanju moramo vedno tudi objaviti datoteko ali mapo. Dodaj torej le rezervira ime za prvo objavo. Prezri (Ignore) izbrane datoteke/mape oznai za ignoriranje. Take datoteke ne bodo objavljene v skladiu, e sproimo objavljanje nad mapo. Prezrte datoteke/mape so dostopne samo v lastnem peskovniku. Sledi (Watch) nad izbrano datoteko/mapo je nain, s katerim vsak uporabnik zaklene datoteko tako, da bo vedno obveen preko elektronske pote, ko jo bo nekdo popravljal. Katerikoli uporabnik lahko sproi Uredi in jo popravi. Ukaz se lahko sproi samo iz ukazne vrstice. Z istim ukazom tudi umaknemo sledenje z datoteke. Uredi (Edit) je ukaz, s katerim nam je dovoljeno popravljati datoteko, ki je sledena. Po tem ukazu je datoteka pisljiva. Kdor sledi datoteko, bo po elektronski poti obveen, da smo odstranili zaklep na datoteki.

Razveljavi urejanje (Unedit) je ukaz, s katerim prekliemo popravljanje datoteke, ki je sledena. Po tem ukazu je datoteka znova nepisljiva. Uporabnik, ki je datoteko sledil, bo obveen po elektronski poti, da je bilo urejanje datoteke razveljavljeno. Razlikuj (Diff) prikae razlike do delovne razliice. e drimo CTRL tipko med izbiranjem, lahko podrobneje doloimo izbiro razliice. Razloi (Annotate) je ukaz, s katerim lahko v tekstovnih datotekah za vsako vrstico vidimo, kdo in v kateri razliici jo je dodal. Osvei stanje map (Refresh folder status) ponovno prebere celotno mapo in ponovno izrie ikone nad datotekami. Priroen ukaz, s katerim preverimo stanje datotek, e domnevamo, da ikone niso pravilne oz. aurne. Pomembno je razlikovati med tem ukazom in ukazom posodobi. Osveevanje stanja map ne prenaa datotek in posodablja peskovnika, ampak samo preveri ikone nad datotekami. Graf revizij (Revision graph) nam slikovno prikae drevo zgodovine razliic datoteke. V takem pogledu natanno vidimo vse komentarje ob objavi, vse veje, oznake in spajanja. Zelo uporabna funkcionalnost, s katero lahko s klikom na desni gumb doloamo tudi, katero razliico elimo (lepljiva razliica). Razliica, ki jo imamo trenutno v svojem peskovniku, je prikazana odebeljeno in jo tako laje opazimo. Zgodovina (History) je dostopna v veih podrojih TortoiseCVS. Zgodovina je bistvo sistema nadzora razliic. Zgodovina dostopna na desnem kliku, je tabelarni izpis dogodkov nad datoteko. Prikazuje enake podatke kot graf revizij, vendar je druganega videza in je zato morda laji nain za pregledovanje komentarjev (teje vidna pa so spajanja in oznake). HEAD veja (HEAD branch) je glavna veja v grafu revizij. Navadno spajamo vse veje v HEAD vejo. Privzeto prevzamemo vedno zadnjo razliico v HEAD veji. Razvejaj (Branch) je ukaz, s katerim iz trenutne delovne razliice ustvarimo vejo, ki jo poljubno poimenujemo. Spoji (Merge) je ukaz, s katerim spremembe med navedenimi razliicami/oznakami/vejami spojimo v trenutne delovne vire. Skladie ostane nespremenjeno do naslednje objave. CVSNT nima nedeljivega ukaza za spajanje. Lepljiva (Sticky) pove, da elimo izbrano (na grafu revizij) razliico datoteke od sedaj naprej imeti v svojem peskovniku. Prikazana datoteka v mapi bo od sedaj naprej (do naslednje posodobitve/prevzema) stareja od zadnje razliice. To lahko povzroi, da ne moremo objaviti niesar kar spremenimo na tako pridobljeni datoteki, saj naslednja razliica e obstaja. Za spreminjanje vsebine in kasneje objavljanje na taki datoteki, moramo nujno ustvariti vejo iz nje in jo kasneje spojiti z zadnjo razliico v HEAD veji. Uvozi (Import) je funkcionalnost, s pomojo katere lahko naenkrat dodamo in objavimo veje tevilo datotek. Datotekam se takoj dodeli oznako in tevilko razliice.

1

POVZETEK

Namen diplomske naloge je predstaviti prenovo nastajanja tehnine in poslovne dokumentacije pri dveh projektih v podjetju NLB d.d. in podati reitev za bolj uinkovito spremljanje dela na tem podroju razvoja in nabiranju poslovnega znanja. Cilj diplomske naloge je dokazati, da sistem za nadzor razliic lahko kvalitetno pripomore k veji preglednosti, nadzoru in spremljanju nastajanja spremne dokumentacije pri projektih. Domnevamo, da bo izbrana odprtokodna reitev, ki omogoa preprosto nadgradljivost, kasneje dodajanje novih funkcionalnosti po lastni presoji in transparentnost ter ne predstavlja velikega stroka v obliki licenc in zunanjih svetovalcev. Diplomska naloga analizira trenutno stanje in potrebe znotraj dveh razlinih projektov podjetja NLB d.d.. Razloeni so poslovni in informacijski vidiki okolja, kjer bo vzpostavljen nov sistem za nadzor razliic. Opisan je star nain izdelave in hranjenja dokumentacije pri obeh izbranih projektih. Na podlagi potreb in teav analizira, s katerimi kriteriji je mogoe izbrati in vzpostaviti bolji sistem. Na podlagi teh kriterijev so ovrednotene razline izbire skupin ali posaminih orodij . Iz celotnega nabora aplikacij in orodij, ki so na voljo, se sistematino izbere zelo ozek krog kandidatov, ki se jih nato e bolj podrobno primerja med seboj. V skladu z domnevami se v zakljuku postopka izbire odloamo med orodjama SubVersion in CVSNT. Po doloitvi izbrane aplikacije CVSNT in posledino spremnih orodij, je opisan natanen postopek in doloen obseg spremne dokumentacije, ki je potrebna za odobritev s strani vodilnih v podjetju, da se sistem lahko uvede v obstojee informacijsko okolje. Na koncu je opisan potek prenove sistema z izbrano aplikacijo za nadzor razliic in nain uvajanja zaposlenih. V sklepu je opisano zadovoljstvo zaposlenih, uporabnikov in vodilnih z novim sistemom za nadzor razliic in podano osebno mnenje za nadaljnje delo na tem podroju znotraj celotnega informacijskega sistema podjetja NLB d.d.. Kljune besede:

nadzor razliic, upravljanje z dokumentacijo podjetja, uvajanje sistema v podjetje razliica, skladie, peskovnik, oznaka, veja CVSNT TortoiseCVS

2

The purpose of this thesis is to present the renewal of the technical and business documentation creation on two projects in the company NLB d.d. and to provide solutions for more effective monitoring of the work and progress of the development and archiving of business knowledge in this segment. The goal is to demonstrate that the system for version control may contribute to greater transparency, control and monitoring of the creation of supporting documentation on projects. We are assuming the choice of an open-source solution which will allow easier upgrading, adding new functionalities later-on with great transparency and will not represent a large cost in the form of licensing and external consulting. In this thesis the current situation is analysed trough the needs of two chosen projects in the company NLB d.d.. Business and IT aspects of the environment where the new version control system will be installed are explained. The old method of creation and storage of documentation on the two selected projects is described, too. Based on the needs and problems it is analysed which criteria is needed to select and establish a better system for version control. Different choices of groups or individual tools are based on those criteria. From the full set of applications and tools that are available on the market a very narrow circle of candidates is than systematically compared in grater detail. As assumed it ends in deciding between applications Subversion and CVSNT. After the selected application, CVSNT, and consequently the supporting tools are defined the detailed process of installation and the volume of supporting documentation is described. The system can be added to the existing IT environment only if the process and documentation comply to the companys standard. Finally, the course of the renovation of the documentation system is described and the method how to teach the employees the new system. Employees, users and managers satisfaction with such new system is described and the personal opinion for further work in this area across the entire company information system is expressed at the end of this thesis. Keywords:

version control, enterprise documentation management, introduction of a new system in a company

version, repository, label, branch CVSNT TortoiseCVS

3

1 POSLOVNO OKOLJE IN OPIS SISTEMA PRED PRENOVO

1.1 Namen in izhodia

V podjetju NLB d.d. sem bil zadolen za vpeljavo sistema za verzioniranje dokumentacije. Sistem za nadzor izvorne kode in na splono za upravljanje vseh datotek je nujen za nadzor nad spremembami, do katerih prihaja med razvojem programskih projektov ali dokumentacije. Razvijalci (v irem pomenu besede tako tehnologi kot programerji) potrebujejo popolno zgodovino sprememb, da se lahko v primeru kakrnihkoli teav vrnejo k prejnjim razliicam. Novi lani projekta zgodovino lahko pregledujejo kot zbirko znanja in vidijo, kakna je tipina pot do konnega izdelka. Ker pisanje programov in dokumentacije zahteva veliko asa in denarja, je zelo pomembno porabiti vsaj nekaj asa in denarja tudi za varovanje delnih izdelkov ali izdelkov, ki jih trenutno ne obravnavamo kot uporabne. Dananja podjetja so vedno bolj odvisna od usklajenosti posameznih lanov na razlinih projektih. Obseno znanje, ki ga znamo upravljati in pravilno uporabiti, ustvarja veliko konkurenno prednost podjetij in posameznikov. V dodatno pomo pa so nam lahko razne programske reitve [1]. Jasne smernice in pravila, kako lani projektov dodajajo novo znanje in kako naj ga potem iejo, niso vedno plod izkljuno tehnine reitve. V primeru NLB in podobnih podjetij, ki so na trgu e ve desetletij, je upravljanje z nastavitvami, produkt krianja nekega starega, zgodovinskega naina shranjevanja in zadnjih reitev ter orodij, ki so na voljo. Najbolje reitve so tiste, ki dobro analizirajo staro stanje, preverijo dodatne zahteve uporabnikov in na podlagi tega ponudijo novo reitev. S tem doseejo, da bodo uporabniki sprejeli novo reitev s kar najmanj odpora. Sodobni zaposleni dobro vedo, da je raunalnikih reitev ogromno in ne sprejmejo ve esarkoli. Mnogi prihajajo iz razlinih podjetjih in projektov, kjer je morda v uporabi e kaken podoben sistem. Idealno je, da so uporabniki vkljueni e v asu izbire in implementacije novega sistema. Sprememba okolja in sistema se mora za uporabnike zgoditi neopazno. Sodoben nain vodenja projektov skorajda ne dopua prehodnih obdobij, pri katerih zaposleni delujejo z zmanjano uinkovitostjo ali z omejenim naborom orodij, aplikacij in pripomokov. Sistem mora biti robusten in nadgradljiv, predvsem pa transparenten pri svojem delovanju. Po konani vpeljavi morajo ostale spremne slube imeti monost nadzorovanja podroja sistema, ki jih zadeva. To pomeni, da je potrebno izdelati jasna navodila za vsako od teh slub in morebiti nov sistem tudi integrirati v kateri drugi zaledni sistem. V diplomski nalogi se elim osredotoiti tako na tehnine kot socioloke vidike vpeljave novega sistema v poslovno okolje. Zael bom z analizo starega sistema, ki je bil opravljen preko pogovorov in sestankov z razlinimi lani projekta Globus in NBO. Po analizi trenutnega stanja se bom osredotoil na izbiro novega sistema verzioniranja in izbiro orodij, ki bodo nudile celovito reitev. Na kratko bom opisal nain vpeljave v NLB d.d. in oddelke, s katerimi se je potrebno povezati za vzpostavitev sistema v zelo varovanem in doreenem bannem okolju.

4

1.2 Predstavitev poslovnega okolja in trenutnega naina verzioniranja

Bannitvo je stara brana, ki je v drugi polovici 20-ega stoletja izjemno napredovala ravno s pomojo informacijske tehnologije. Raunalniki so v uporabi e od poznih 50-ih let in precej aplikacij, ki so e danes v uporabi, je bilo razvitih e v tistih asih [22]. Nadgradnje, kompatibilnost za nazaj in integracije so v takem okolju dobro poznani pojmi. Obvladovanje tveganj v povezavi z njimi pa strategija, ki jo je ta brana izdelala skozi leta praktinega dela. Ravno zaradi zrelosti in zavedanja vseh posledic slehernih sprememb je tako okolje teavno za vpeljavo novih sistemov. Vsako novo aplikacijo je potrebno dobro preuiti z ve vidikov:

dodana vrednost v obliki pohitritve ali lajega dela uporabnikov uporabnost teavnost uporabljanja/intuitivnost stabilnost vzdrevanje na kratki, srednji in dolgi rok monost nadgrajevanja monost integriranja varnostni vidiki (belo in rno hackanje) cena licenciranja spremna dokumentacija skupna cena na asovno obdobje

Za kvalitetno oceno zgornjih kriterijev je potrebno dobro poznavanje tako informacijskega kot poslovnega okolja. Ti so kljunega pomena za uspeno vpeljavo dodatnega sistema in s tem novega principa delovanja v poslovno okolje. Selektivnost pri tem poznavanju pa vsekakor ni ni manj pomembna, saj je pogoj za zadovoljivo hitro vpeljavo. Veinoma se raunalniarji osredotoamo na tehnine prepreke problemov. Vendar je za dosego cilja neizbeno poznavanje vsaj okvirnega delovanja projektnega vodenja v podjetju, poznavanje sistema organiziranosti podjetja v podrojih potrebnih za dosego tega cilja in poslovni delovni okviri uporabnikov - zaposlenih. Prvotno reujemo teavo ali lajamo delo poslovnim uporabnikom in to nam mora biti vodilo pri vsakem preprievanju in argumentiranju. Dobro poznavanje IT sistema je v tem primeru drugotnega pomena za ljudi, ki jim nov sistem predstavljamo. al pa je veina dela ravno na tem podroju in je zato ostalim soudeleencem take vpeljave nevidna oz. samoumevna. Iskanje kompromisa med tehninimi monostmi v e zgoraj natetih kriterijih in poslovnimi zahtevami je sr uspeha zastavljene naloge. Na tem mestu je potrebna e kraja razlaga delovnega razmerja, v katerem sem bil prisoten v NLB d.d., saj je pomembna za razumevanje samoomejitve raziskovanja. V podjetju NLB d.d. sem bil prisoten kot delavec podjetja Hermes Softlab d.d.. Podjetje NLB je od nas odjemalo nekatere tehnine storitve, zaradi katerih je bila na njihovi lokaciji poleg mene potrebna nenehna prisotnost e dveh inenirjev. Banka je od nas priakovala, da opravljamo izkljuno tiste storitve, zaradi katerih smo bili najeti. Za opravljanje le-teh dejansko ni bilo potrebno natanno poznavanje niesar drugega kot tehnine reitve, ki smo jo ponujali banki. Vendar je bilo zaradi razlogov, ki sem jih opisal e na zaetku tega poglavja, vseeno potrebno raziskati tako informacijsko, kot poslovno okolje, kjer sem deloval. V podjetju

5

NLB d.d. sem bil torej gost. Ob nastopu dela sem podpisal izjavo o varovanju podatkov, ki me tudi v bodoe zavezuje k varovanju le-teh. Tudi pisanje tega diplomskega dela je moralo biti odobreno s strani odgovornih v podjetju. Moje dostopne pravice, geslo in nasploh dostop do prostorov so bili ponovno dodeljeni vsake tri mesece. Do zasebnih podatkov nisem imel dostopa. Raziskal sem le najbolj nujne stvari, ki so mi omogoile, da sem svojo nalogo dobro opravil.

1.3 Razlina organizacijska okolja

1.3.1 Poslovno okolje Globus in NBO

Najbolje je prieti z grobo razdelitvijo poslovnega okolja banke. al je ureditev in razdelitev pristojnosti od oddelka do oddelka in od projekta do projekta razlina, vendar obstaja rdea nit pri vseh tistih okoljih, ki so se me zadevala med to nalogo. Za sam sistem verzioniranja dokumentacije je najbolj pomembno to, kako se izdelki razvijajo, testirajo in migrirajo med okolji ter kako so razdeljene naloge razlinih lanov projekta. Oba projekta, pri katerih je bila izvedena prenova sistema dokumentacije, sta razvojna projekta. Globus je razvijal aplikacijo za transakcijsko poslovanje pravnih oseb. NBO pa je Novo banno okence in integrira razline zaledne sisteme, ki jih v poslovalnicah uporabljajo blagajniki, vodje poslovalnic in ostali zaposleni. Gre torej za dve aplikaciji. Vsaka od njiju je razvita v druganem programskem jeziku. Verzioniranje izvorne kode poteka v ClearCase za NBO in v lastni aplikaciji za projekt in aplikacijo Globus. Ta nima izvorne kode v pravem pomenu besede loene v datotekah, zato potrebuje namensko verzioniranje - aplikacijo NDCS, ki verzionira elemente aplikacije Globus. Ti elementi so postavljeni v bazi, preko katere aplikacija deluje. Elementi se v realnem asu prevajajo in prikazujejo uporabnikom v obliki aplikacije.

1.3.1.1 Vloge lanov projekta

lani projektov opravljajo razline funkcije znotraj projekta. Te so: projektni vodja migrator tester uporabnik razvijalec tehnolog poslovni sekretar / tajnica prevajalec

6

Projektni vodja

Tester

Migrator

Razvijalec

Tehnolog

Poslovni sekretar

Uporabnik

Prevajalec

Razvijalec inTester

Migrator in Razvijalec

Razvijalec

Tehnolog

Tehnolog

Tehnolog

Slika 1.1: Razlini lani projekta Posamezni kljuni lani opravljajo tudi do tri razline funkcije (slika 1.1). Oba projekta imata zelo podobno razdeljene vloge lanov. Poslovni sekretarji skrbijo za spremne dejavnosti projekta. Beleijo odsotnosti, sprejemajo korespondenco, rezervirajo sejne sobe in posebno opremo ter posledino dostopajo do podroja dokumentacije, ki je potrebna za vodenje zgoraj natetega (npr. tabele rezervacij, odsotnosti ...). Doloene dokumente pa tudi skenirajo in shranjujejo na omrene vire. Prevajalci prevajajo dokumentacijo, ki je potrebna neslovenskim lanom pri projektu. To so zunanji svetovalci in programerji specialisti. Njihove dokumente ravno tako prevajajo v slovenino za ostale lane projekta. Navadno dostopajo do dokumentacije vodstva projekta. Testerji in uporabniki v praktinem smislu opravljajo isto funkcijo. Razlike med njimi so, da so testerji prisotni na lokaciji vodstva projekta, medtem ko so uporabniki v poslovalnicah, in da testerji preizkuajo aplikacijo v ivljenjskem ciklu razvoja takoj za razvijalci, uporabniki pa za njimi v vmesni veji izdaji aplikacije. Z vidika dokumentacije testerji dostopajo do veje koliine dokumentacije in izdelujejo plane testiranj, do katerih imajo kasneje dostop e ostali lani projekta, tudi uporabniki. Tehnologi ustvarijo najve dokumentacije, saj specificirajo poslovne zahteve, na podlagi katerih razvijalci kasneje razvijajo aplikacijo. Tehnologi preteno ustvarjajo dokumente, do katerih kasneje dostopajo e ostali lani projekta (razvijalci, testerji, prevajalci, projektni vodje) Projektni vodje pregledujejo dokumentacijo, ki nastaja pri vseh ostalih. Sami ne ustvarijo veliko dokumentacije, morajo pa imeti dostop do vsega in do metod, s katerimi lahko pregledujejo, kdo in kdaj je ustvaril nov dokument. Projektni vodje odobrijo tehnino dokumentacijo, ki jo proizvedejo tehnologi in nadzirajo napredek in narte testiranja preko zapisov in planov testiranja.

7

Razvijalci veinoma ne ustvarjajo dokumentacije. Najpogosteje pregledujejo zahtevke funkcionalnosti, ki jih ustvarijo tehnologi. Izjemoma lahko v primeru napak pregledujejo zapise testnih scenarijev, s katerimi laje reproducirajo hroe. Migratorji z vidika dokumentacije nimajo posebne vloge. Njihovo delo je migriranje zadnjih razvojnih popravkov v okolja za testiranje ali produkcijsko okolje. Potrebujejo pa dostope do migracijskih form, ki so samodejno ustvarjene z orodji za doloanje migriranja izvorne kode.

1.3.1.2 ivljenjski cikel projektov

Dokumentacija skozi ivljenjski cikel projekta nastaja razlino. Obstaja tudi ve razlinih ivljenjskih ciklov glede na razline vrste zahtevkov, ki so predmet projekta. Razlini tipi zahtevkov so:

poslovne zahteve zahteve po spremembah napake zahtevki za operacije

V primeru poslovnih zahtevkov je prvi dokument, ki nastane tehnina specifikacija. Na njegovi podlagi poteka razvoj, ki ob svojem koncu zahteva zapis o testiranju. Ob prehodu te funkcionalnosti v naslednje okolje je potrebno sproiti nastanek migracijske forme. Zahteve po spremembah so v sri podobne novemu poslovnemu zahtevku. Vse je enako, le da ustvarimo novo tehnino specifikacijo in po konanem razvoju dobimo nov zapis o testiranju ter sproimo nastanek nove migracijske forme. Zahtevki za operacije so zahtevki, ki razen primerno izpolnjenega obrazca za IT slube, ki zahtevek izvedejo, ne proizvedejo nobene druge dokumentacije. Napake in opisi napak se beleijo v posebnem sistemu za vodenje zahtevkov. V primeru napake tehnologa ali nedoreenosti, se popravi dokument tehnina specifikacija in se po odpravi teave ustvari nov zapis o testiranju in nova migracijska forma.

1.3.2 IT okolje NLB d.d.

Podjetje NLB d.d. ima zelo dobro razdelano informacijsko okolje. Vzpostavljeni so centri, ki skrbijo za tono doloeno podroje okolja. Pristojnosti se ne prekrivajo in vsak poseg v okolje je v celotnem ivljenjskem ciklu dobro dokumentiran. Krovni center, ki skrbi za vso informacijsko tehnologijo, je UCIT. Center skrbi za vso raunalniko podporo poslovnih ciljev banne skupine. Njegova primarna skrb je obvladovanje produkcije in zahtev razlinih podroij znotraj banke po informacijski tehnologiji. UCIT sestoji iz treh sektorjev: za obvladovanje produkcije in infrastrukturo, za razvoj in za podporne dejavnosti. V sektor za razvoj spadajo med drugim programski vodje, IT projektni vodje, analitiki, nartovalci programske opreme in programerji. V sektorju za infrastrukturo je PC Team, v sektorju za podporne dejavnosti pa so CAU, projektna pisarna, trenerji za izobraevanje uporabnikov ter finanni kontroling.

8

Na kratko bom razdelal, kakna je funkcija vsakega od sektorjev:

1.3.2.1 Sektor za razvoj

Sektor sestoji iz ve podroij - programov, ki jih vodijo programski oz. linijski vodje. Programi so namenjeni za podporo naslednjim podrojem:

Elektronski kanali Upravljalski sistemi Fizine osebe Pravne osebe Plailni sistemi Finanni trgi

V okviru le-teh se sprejemajo vse velike odloitve o raunalnikih prenovah in se sledi rokom izdelav in potroenim virom. Tu se vodijo vsi razvojni projekti in se vzdruje obstojee produkcijske kode.

1.3.2.2 Sektor za infrastrukturo

Ta sektor skrbi za nemoteno delovanje produkcije in za vse operativne stvari okoli informacijskih tehnologij. Zaposluje sistemske administratorje in specialiste iz razlinih podroij raunalnitva. Veji del specialistov je certificiranih od razlinih proizvajalcev strojne ali programske opreme (MSCE, Cisco, Oracle ...). Podroja delovanja pokrivajo:

namestitev, razvoj, nadzor in vzdrevanje delovnih postaj namestitev, razvoj, nadzor in vzdrevanje strenikov (spletnih, podatkovnih in aplikacijskih) namestitev, razvoj, nadzor in vzdrevanje skupnih baz podatkov namestitev, razvoj, nadzor in vzdrevanje diskovnih polj namestitev, razvoj, nadzor in vzdrevanje varnostnih kopij namestitev, razvoj, nadzor in razvoj lokalnih, regionalnih in mednarodnih omreij testiranje novih izdelkov pred namestitvijo v okolje namestitev, razvoj, nadzor in vzdrevanje sistema za zagotavljanje kontrole dostopov (security policy) namestitev, razvoj, nadzor in vzdrevanje sistema za samodejno nameanje novih izdelkov v okolje izdelava paketov za samodejno nameanje novih izdelkov v okolje

Celotno operativno delo za namestitev novega strenika in odjemalcev v banno okolje je potrebno usklajevati s tem sektorjem. Vse delo se izvaja na podlagi delovnih nalogov in preko obrazcev, ki jih je predhodno potrebno potrditi pri poslovnih skrbnikih. Ti lahko zahtevajo storitve, ki jih PC Team iz tega sektorja nudi. Navadno prihaja veji del zahtevkov s strani CAU oddelka, ki ima logini pregled nad vsebino, ki je dostopna..

1.3.2.3 Sektor za podporne funkcije

UCIT sprejema tudi proraun za nadaljnja obdobja na podlagi skupnega prorauna, ki ga banka nameni za notranji razvoj in s tem doloa, katera podroja, orodja in aplikacije se bodo vpeljali in razvijali. Prav tako ima organizirano projektno pisarno za razvojne projekte in skupino trenerjev, ki so odgovorni za izobraevanje uporabnikov ob instalacijah novih

9

verzij programske opreme. V tem sektorju se vodi tudi finanni del za vse investicije in stroke v informacijsko tehnologijo in razvojne ter vzdrevalne projekte. V tem sektorju je tudi skupina, ki skrbi za centralno administracijo uporabnikov CAU (doloanje pravic in mesta dostopov uporabnikom, uporabnika imena, podroje delovanja, pripadnost omrenim skupinam, doloa omrene vire, omrenim virom doloa, katere skupine jih smejo uporabljati in na kaken nain, doloa elektronski potni naslov in nain uporabe elektronske pote). Vsak poseg glede doloanja ali spreminjanja dostopov uporabnika do novih ali starih mrenih virov je primarno naslovljen na CAU. Vsi obrazci so dostopni na intranetni strani (KIT). Obrazci se izpolnijo in glede na obrazec se zberejo razlini podpisi odgovornih. Tako izpolnjen obrazec se preda CAU, ki lahko ta zahtevek prenaslovi na PC Team. Navadni uporabniki vse svoje zahteve podajo CAU, le posebej doloeni IT skrbniki lahko neposredno dostopajo do PC Team-a in s tem zmanjajo odzivni as.

Slika 1.2: Umestitev IT okolja v poslovno okolje

1.4 Opis starega naina izdelave dokumentacije pri obeh ciljnih projektih

Kot dokumentacijo obravnavamo vse oblike zapisov. Navadno ti zapisi nastajajo v programskem paketu Microsoft Office, bolj natanno v oblikah Word in Excel. Statistino skupaj predstavljajo preko 92%, ostalih 8% pa predstavljajo Powerpoint predstavitve, iste ASCII tekstovne datoteke in skenirani dokumenti. Datoteke ustvarjamo na novo, jih shranjujemo, si jih izmenjujemo, ali jih elimo poiskati. Po raunalniki definiciji je dokumentacija organiziranana zbirka evidenc, ki opisuje strukturo, namen, delovanje,

10

vzdrevanje in zahtevo po podatkih za raunalniki program, operacijski sistem, strojno opremo ali napravo [28]. Dokumentacija v podjetju NLB d.d. opisuje preteno:

tehnine specifikacije analize sistema statistike razlinih zalednih sistemov (npr. Sistem za spremljanje zahtevkov) poroila zalednih sistemov in aplikacij (rona in samodejna) zapisi o testiranju zapisniki sestankov razne razpredelnice in preglednice skenirani dokumenti in faksi korespondenca z elektronsko poto navodila prironiki certifikati slike itd.

Oba projekta sta e pred mojim prihodom imela skupni omreni vir, kjer so zaposleni shranjevali svoje dokumente. Omreni vir je bil razdeljen priblino logino in je v razlinih podmapah po skupinah doloal, kateri uporabniki lahko do njega dostopajo za branje ali pisanje. Razlini osnutki dokumentacije so leali v teh mapah in v imenih je bilo doloeno, katero verzijo gledamo.

1.4.1 Teave s poimenovanjem datotek

Nateli bomo le najbolj tipine oblike imen datotek, s katerimi so uporabniki eleli doloiti razliico dokumenta. Na kratko bomo opisali slabosti takih oblik na primeru najbolj pogostega scenarija, to je iskanja zadnje razliice datoteke. Primer je datoteka, ki se osnovno imenuje datoteka.txt in je bila spremenjena dvajsetega avgusta dvatisoega leta od uporabnika Milica. Tipina poimenovanja so:

20-5-2008_datoteka.txt 08-5-20_dateka.txt 20080520_datoteka.txt datoteka-20-5-2008.txt datoteka_08-5-20.txt datoteka_20080520.txt datoteka-Milica.txt datoteka-rev0.1.txt datoteka_Milica_rev0.1.txt datoteka_20080427_rev0.1.txt

Vsi naini poimenovanja, ki se zanejo z datumom, imajo kot glavno slabost to, da je v mapi skoraj nemogoe brskati po imenu datoteke. Ureditev po imenu vedno postavi enake datume skupaj. Iskanje zadnje razliice je tako zelo teko, saj je potrebno zaeti na koncu

11

seznama datotek v mapi in se prebiti proti zaetku tako, da iemo ime datoteke nekje na sredini imena datoteke. Ugotavljamo torej, da je najbolje, e oznabo o reviziji postavimo na konec datoteke. V tem primeru je oblika dan-mesec-leto slaba, saj sortiranje po imenu premea vrstni red datotek. Res, da je nabor takih datotek majhen, a obstaja monost, da uporabnik spregleda resnino zadnjo razliico. Seveda ob predpostavki, da so se vsi predhodni uporabniki, ki so delali na datoteki drali dogovora, da je datum na koncu imena datoteke. V primeru, da je razliic na isti dan ve, so uporabniki to reevali z dodajanjem za datumom: -1, rev0.1, lastnim imenom ipd. Taka uporaba verzioniranja ni slaba, ima pa e vedno precej pomanjkljivosti, ki jih sistemi za nadzor razliic nimajo in jih elegantno reujejo. Nekateri uporabniki so datoteke poimenovali veinoma brez datuma, samo z revizijo na koncu, saj trdijo, da je datoteko naknadno mogoe poiskati z ureditvijo datotek v raziskovalcu po datumu. Argument proti temu je primer, ko nek uporabnik ponovno shrani datoteko in ji s tem popravi atribut datuma v datotenem sistemu. Vsi zgoraj nateti naini shranjevanja revizij imajo vsekakor to slabost, da mapa hitro vsebuje veliko tevilo datotek. Tako je iskanje natanko enega stanja datoteke zelo oteeno in zahteva, da uporabnik pregleda praktino vse datoteke v mapi, preden izve, katera je zadnja razliica, na kateri lahko dela dalje, ali pa jo mora spreminjati. Delna reitev je uvedba mape arhiv kot pod-mape glavne mape. Tam se premikajo vse datoteke, ki so stareje od te, na kateri trenutno delamo. Oba projekta sta v mapah, ki so bile najbolj obsene po tevilu datotek, izbrala to reitev. al ponovno brez enotne izbire imena takega arhiva, kar bi naknadno oteilo avtomatizacijo prenosa na nov sistem verzioniranja.

1.4.2 Teave z dostopanjem in spreminjanjem istega dokumenta s strani ve razlinih uporabnikov

Pri projektih, na katerih je sprva delalo le nekaj tono doloenih uporabnikov se rado zgodi, da uporabniki ne elijo oddati od sebe dokumenta, ki ni zadnja razliica. Take dokumente shranjujejo lokalno pri sebi. V primeru, da jo poljejo v revizijo kateremu od drugih lanov projekta in elijo dodatke ali popravke, imajo odgovore navadno shranjene kar v potnem predalu elektronske pote. lani projekta nimajo jasno doloenih strategij za razvranje pote po mapah, ki logino razmejujejo projekte in zadeve. Velikokrat se dogodi, da je neka elektronska pota preprosto spregledana ali izbrisana preden so spremembe vkljuene v dokument, ki ga lan upravlja. Poleg tega je monost izgube takih dokumentov velika, saj ni celotnih varnostnih kopij. V primeru bolezni ali dopusta pa je sodelavcem izjemno teko, e ne nemogoe, nadaljevati delo. eprav so na razpolago skupni omreni viri, jih veina zaposlenih ne eli uporabljati, saj se ravno tam bojijo izgube podatkov in tega, da datoteke ne bodo ve nali. Poimenovanje brez jasne strategije je povzroalo dodatno delo tistim uporabnikom, ki so morali datoteko poiskati. Obenem so se pojavile napake, ker uporabnik ni nael prave datoteke in je tako preprosto izgubil vse, kar je bilo medtem narejenega na datoteki. Enotna strategija, ki je jasna vsem uporabnikom, ki na dokumentaciji delajo ali jo uporabljajo, je tako kljunega pomena za odpravo nepotrebnih napak.

12

1.4.3 Teava pri nadzoru dela na projektu

Zaradi prejnje teave imajo projektni vodje in vodje skupin zelo oteen pregled nad tem, kako in na katerih podrojih delo napreduje. Razlini zaposleni imajo razlino dinamiko shranjevanja in odlaganja na skupne omrene vire, kar povzroa ogromno dela vsem, ki poskuajo nadzorovati in spremljati tako delo. Nekateri zaposleni ele po ve tednih dajo svoje dokumente na voljo tudi ostalim lanom . Za vodjo projekta je, e mu ni omogoeno sprotno spremljanje in normiranje opravljenega dela zaposlenih, koliko asa bo doloen korak v projektu trajal, ocena izjemno oteena . Zahtevati od zaposlenih, da uporabljajo to strategijo discipliniranega odlaganja svojih dokumentov je teavno s psiholokega vidika. Vodja projekta prav tako porabi veliko asa, da sproti preverja, ali so zaposleni datoteke spreminjali.

1.4.4 Teava poasnosti obnovitve izgubljenih ali izbrisanih podatkov

Operacijski sistem Windows je nekoliko neroden, saj z izjemno lahkoto omogoa, da uporabnik z miko pomotoma odnese celo mapo datotek na neko drugo mesto. Ravno tako uporabniki vekrat pomotoma briejo svoje stare datoteke, saj ne vedo, da jih tudi drugi e potrebujejo, ali da jih bodo potrebovali tudi sami. V takem primeru obstaja tono doloen predpis, ki doloa na kaken nain uporabniki zaprosijo za obnovitev (ang. restore) takih datotek ali map. Uporabnik na intranetnih straneh CAU najde obrazec za obnovitev in ga izpolni po naslednjem postopku:

kdo zahteva kje je stara lokacija dokumenta ali mape (omreni vir ali uporabnika mapa na

lokalni delov kdaj je okvirni as izbrisa pridobi podpise vseh odgovornih nadrejenih (linijski vodja, projektni vodja, vodja

skupine). Pravilno izpolnjen obrazec se osebno odda CAU, ki ga dodeli tistemu administratorju znotraj PcTeam-a, ki je odgovoren za varnostne kopije strenika, s katerega je datoteka ali mapa izginila. Ta ga glede na as izginotja lahko ie med dnevnimi, tedenskimi ali mesenimi varnostnimi kopijami. Vsaka od teh varnostnih kopij je lahko na razlini obliki medija (diskovno polje, CD, trak,...). Kratkorone varnostne kopije so kumulativne in e zaradi tega je obnova zelo poasna. Povpreen as od oddaje uporabnikove vloge za obnovo in dejansko obnovo je navadno 2 do 3 dni. e datoteka nima prave vsebine, se celoten postopek ponovi. Uporabniki obnovo zaradi tega dolgotrajnega postopka uporabljajo le kot skrajno reitev in e to neradi.

1.4.5 Teava varovanja podatkov in doloanja dostopov

Banka je velik sistem, v katerem v razlinih vlogah deluje veliko ljudi. Vsi podatki niso namenjeni vsem zaposlenim. Nekateri morajo podatke le brati, drugi jih lahko tudi spreminjajo, tretji pa o njihovem obstoju sploh ne smejo vedeti. Doloanje uporabnikih dostopov do omrenih virov poteka preko posebnega obrazca CAU, ki vsebuje podatke:

kdo zahteva spremembo dostopa zakaj zahteva spremembo dostopa

13

na katero uporabniko skupino in omreni vir je vezan dostop katere so zahtevane pravice dostopa pridobi podpise vseh odgovornih nadrejenih (linijski vodja, projektni vodja, vodja

skupine).

V primeru, da je omreni vir e vzpostavljen in uporabnika skupina e ustvarjena, izpolnjevanje zahtevka traja en dan. V nasprotnem primeru je zahtevkov ve in as sorazmerno dalji. Sama tehnina izvedba je preprosta, vendar trajanje dogovora o dostopnih pravicah z odgovornimi dolgotrajno, saj je vsaka sprememba dobro preuena.

1.4.6 Teave s pregledovanjem razlik med dvema razliicama istega dokumenta

Pri vkljuevanju razlinih popravkov v osnovni dokument je najprej potrebno ugotoviti, kaj je v prejeti razliici druganega v primerjavi z osnovnim dokumentom. Microsoft Word vsebuje nekaj sistemov za pregledovanje razliic. Dva najbolj poznana sta funkcionalnosti Track Changes in Diff Two Documents. Funkcionalnost spremljaj razlike je potrebno omogoiti takoj na zaetku ustvarjanja dokumenta in nihe od naslednjih uporabnikov, ki delajo na tem dokumentu, je ne sme izklopiti. Funkcionalnost je dovolj dobra, dokler si dokument podajata dva uporabnika. V primeru, ko eden izmed uporabnikov prejme popravke iz ve virov naenkrat, pa le-ta v praksi odpove. V tem primeru si uporabniki navadno dokumente v celoti natisnejo in pretipkajo popravke v osnovni dokument. Enako storijo tudi v primeru, ko te funkcionalnosti ne poznajo. Funkcionalnost razlikuj med dvema dokumentoma je zelo redko poznana uporabnikom. Omogoa, da iz osnovnega dokumenta izberemo e enega in ta nam (oblikovno podobno funkcionalnosti spremljaj razlike) pokae razlike. Funkcionalnost je primerna za uporabo, e spremljaj razlike ni omogoena na dokumentu. Kljub obema monostma za Wordove datoteke je to zelo pere problem pri uporabnikih, poleg tega pa v okviru programskega paketa Microsoft Office ni reitev za datoteke Excel in prezentacije Powerpoint. Enako velja za ostale tipino uporabljane oblike datotek.

1.4.7 Teava z doloanjem natannega asa nastanka datoteke

Velikokrat elimo vedeti, kdaj natanno je nek dokument nastal. Teave s potvorjenim datumom so na skupnih omrenih virih precej pogost pojav. Do spremembe datuma pride velikokrat zaradi tega, ker nekdo ob prebiranju dokumenta popravi kakno manjo slovnino ali vsebinsko napako. Ko tako popravljen dokument ie nekdo drugi, mu novi datum pomeni teavo pri ugotavljanju dejanskega asa nastanka dokumenta. Datoteke Excel so glede spremembe datuma e posebej teavne. Ob vsakem odpiranju datoteke Excel aplikacija spremeni datum Date modified v datotenem sistemu na trenutni as. e datoteke nismo shranili, aplikacija vrne datum in as na prejnji zapis, v nasprotnem primeru ostane as spremembe, as zadnjega shranjevanja. Teava nastane, e

14

je kateri od uporabnikov na skupnem omrenem viru imel odprto datoteko in se mu porui raunalnik, ali se aplikacija sesuje. V tem primeru (poleg tega, da zelo pogosto datoteka ostane celo zaklenjena za pisanje s strani drugih uporabnikov) ostane v datotenem sistemu zabeleen as zadnje spremembe - trenutek odpiranja datoteke. Najpomembneje datoteke ravno zaradi tega vsebujejo glave, ki vsebujejo datum spremembe, ki se mora rono posodobiti na dejanski as. Ravno tako imajo (al le zares pomembni dokumenti) na zaetku tabelo, v kateri je vpisan as spremembe, avtor in namen spremembe.

1.4.8 Teava z doloanjem tega, kdo je opravil popravek v datoteki

Vsebine datotek so obutljivo podroje. Ne elimo, da jih lahko kdorkoli spreminja, ne da bi vedeli, kdo je to bil. V navadnem datotenem sistemu lahko vemo le, kdo je bil zadnji, ki je dokument popravljal. Lahko se nam zgodi, da nekdo izbrie ali priredi cele odlomke besedil. e bo za njim e kdorkoli to datoteko ponovno shranil, nikoli ne bomo vedeli, kdo je bil tisti, ki je nek odlomek spremenil ali izbrisal. Funkcionalnost Spremljaj spremembe je na voljo le za datoteke Word. al z njo ne moremo pokriti vseh varnostnih vidikov, ki so potrebni za resen nadzor nad avtorstvom sprememb, saj je funkcionalnost namenjena dobronamerni uporabi. Zlonameren uporabnik jo lahko mimogrede zaobide, ali e huje potvori.

1.4.9 Teava z doloanjem vzroka za nastanek nove revizije

Najpomembneje datoteke imajo v svojem zaetku tabele, ki sluijo kot dnevnik zapisov. Vsebujejo edinstveno oznako revizije, datum, avtor in namen spremembe. Pomembno je, da obstaja jasen dogovor, da uporabniki beleijo svoje spremembe v take tabele. Velikokrat so spremembe manje in jih zato uporabniki ne elijo vpisati v to tabelo. Opis namena je seveda zelo pomembno polje, al pa je tudi edino polje, ki se le redkokdaj izpolni. e je e izpolnjeno, je opis zelo skop ali kriptien (razumljiv samo avtorju).

15

2 IZPOPOLNJEN SISTEM HRANJENJA DOKUMENTACIJE

Po temeljiti opredelitvi teav starega sistema shranjevanja dokumentov in ostalih vrst datotek na skupne omrene vire, je naravna reitev vejega dela teav uvedba sistema za nadzor razliic na nivoju celotnih projektov. Najprej je potrebno opredeliti kriterije, po katerih bomo izbirali orodja, nato bomo med vsemi orodji izbrali tista, ki bodo kriterijem izbire najbolje ustrezala, na koncu pa bomo izbrali e metodologijo in opredelili jasna pravila, kako sistem uvesti na projekte in ga pribliati uporabnikom. Sistem za nadzor razliic je v IT okolju dobro poznano orodje, ki slui za shranjevanje zgodovine razvoja. Najdlje se uporablja v programskem inenirstvu, najpogosteje za shranjevanje izvorne kode in konfiguracijskih datotek. Razvijalec mora imeti monost potegniti iz arhiva staro razliico in jo popravljati. Teave, ki se pojavljajo pri shranjevanju programske kode in konfiguracijskih datotek, so zelo podobne tem, ki jih sreamo pri shranjevanju dokumentacije. Sistem za nadzor razliic je upravljanje vejega tevila revizij iste enote informacije. Najpogosteje se uporablja pri ineniringu in razvoju programske opreme za vodenje, razvoj na digitalnih dokumentih, kot je izvorna koda aplikacij, umetnostnih virih, kot so narti ali elektronski modeli in za ostale projekte, pri katerih istoasno dela skupina ljudi. Spremembe teh dokumentov so navadno identificirane z inkrementiranjem nekega tevila ali kode znakov. To imenujemo tevilka revizije, stopnja revizije ali najpreprosteje revizija. Zgodovinsko jo poveemo z osebo, ki je naredila spremembo. Najosnovneji nain spremljanja revizij je, da pri nastanku nekega dokumenta temu damo revizijsko tevilko 1. Ko je narejena prva sprememba, se revizija povea na dva in tako dalje (slika 2.1). [7]

Slika 2.1: Preprost nain verzioniranja dokumenta Primer.txt Sistem za nadzor razliic je najpogosteje samostojna aplikacija, vendar je nadzor revizij tudi e vkljuen v razline tipe programske opreme kot so urejevalniki besedil (npr. Microsoft Word, OpenOffice.org Writer, Koffice, Pages, Google Docs), preglednice (npr.

16

OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel) in razlini CMS. Integrirana kontrola revizije je kljuna funkcionalnost pri vseh teh skupinah, saj najpogosteje omogoa vraanje vsebine na prejnje stanje, kar je kljuno za urejevalce, da lahko spremljajo spremembe drug-drugega, popravljajo napake in prepreujejo namerne vandalizme zlonamernih popravljavcev. [7] Razlini avtorji, ki analizirajo razvojne brane, vedno bolj priznavajo pomembnost in nujnost sistemov nadzora razliic pri organizaciji projektov z ve razvijalci [18].

2.1 Doloanje kriterijev izbire

e elimo objektivno izbrati, moramo pri vsakem odloanju, doloiti jasne kriterije izbire in jim doloiti primerno pomembnost. Glede na e opisano okolje in teave sem izbral tiste kriterije, za katere sem ocenil, da bodo doprinesli koristen prispevek k napredovanju splonega dela na projektih. Nateti so vsi kriteriji, ki lahko vplivajo na odloitev, ni pa nujno, da bo potrebno vse upotevati. Kriteriji izbire orodja: a) Model skladia Poznamo tri razline oblike skladi, ki jih taki sistemi premorejo.

lokalno skladie distribuirano skladie sistem odjemalec-strenik

Sistem odjemalec-strenik je sistem, pri katerem uporabniki, razvijalci, delijo skupno centralno skladie. Lokalno skladie pomeni, da je skladie postavljeno na lokalni datoteni sistem. Priklop z drugih delovnih postaj ni moen. Distribuirano skladie je sistem, pri katerem navadno uporabniki delajo na svojem lokalnem skladiu in v posebnem koraku svoje delo in spremembe delijo z ostalimi lokalnimi skladii. Prednost bomo dali sistemu odjemalec-strenik, saj bi kateri od drugih sistemov zahteval ve vzdrevanja, vejo discipliniranost uporabnikov, bistveno vejo potronjo prostora in predvsem vejo teavnost namestitve. Poleg tega sta preostala sistema bolj primerna za nepovezane uporabnike, ki si obasno izmenjujejo informacije. Ta kriterij je pri nai odloitvi zelo pomemben. b) Vkljuenost v okolje Bodoi uporabniki ne smejo utiti ostrega prehoda med starim in novim sistemom. Novi sistem mora biti na videz dobro integriran v ostale e obstojee sisteme, ki so jih uporabniki e vajeni. c) Preprostost uporabe tudi za najbolj neuke uporabnike Za vsako novo orodje, sistem ali aplikacijo je idealno, da je njegovo delovanje mogoe razloiti v nekaj preprostih stavkih z razlago nove terminologije vred. Orodje, ki je uporabljeno za izvajanje novega sistema mora biti intuitivno. Onemogoati mora nepravilno delovanje in uporabnika opozoriti pred nezaelenimi ali potencialno nevarnimi akcijami. Pod ta kriterij bom umestil tudi podporo poslovenjenju uporabnikega vmesnika, saj bo s tem orodje laje dostopno vsem vrstam uporabnikov in bo prehod nanj preprosteji.

17

d) Stabilnost aplikacije elimo si, da nobena aplikacija ne bi delovala slabo, se ruila, povzroala memory leak-ov, vplivala na druge aplikacije in zaledne sisteme ali ogroala delovanje operacijskega sistema, na katerem deluje. Pod ta kriterij bom uvrstil tudi promet, ki ga na omreju povzroa aplikacija/orodje pri velikem tevilu uporabnikov in velikem tevilu aplikacij, ki jih le-ti uporabljajo. Vsak dodaten promet predstavlja infrastrukturno tveganje. e) Cena Cena novega sistema je veplastno sestavljen kriterij. Na ceno vpliva cena morebitnih licenc samega orodja, njegovih dodatkov in opreme, s pomojo katere tee. To pa je le prvi najbolj oiten stroek. Poleg tega kot stroek nastopa tudi tevilo inenirskih ur, ki so potrebne za namestitev novega sistema, kar pomeni, kako hitro je mogoe sistem namestiti in nastaviti. Nenazadnje je v ceno potrebno uvrstiti tudi stroek truda, asa in delavnic, ki so potrebne za usposobljenost uporabnikov za delo z novim sistemom. Velja nenapisano pravilo: Draja je licenca, hitreja je namestitev in ceneji je strokovnjak - ceneja je licenca, poasneja je namestitev in draji je strokovnjak. e je sistem sestavljen iz odprtokodnih reitev, to navadno pomeni, da bomo toliko ve denarja in asa morali investirati v samo namestitev, nastavljanje in ustvarjanje uporabnike dokumentacije. f) Licenciranje in pravice uporabe orodij V okvir cene bi lahko uvrstili tudi licenciranje. Ker pa ne vemo, koliko uporabnikov bo orodje v resnici uporabljalo, je nedvoumno bolj prav, e opredelimo ta kriterij kot posebno kategorijo in jo posebej uravnoteimo. V primeru, da bo uporabnikov orodja malo, je cena irelevantna napram razliki v asu, ki je potrebnen za namestitev komercialne celostne reitve (all-in-one). V nasprotnem primeru se podaljanje asa, ki ga potrebujemo za namestitev odprtokodnega orodja pod licenco GNU/GPL, ali katero od razliic izplaa pri vejemu tevilu uporabnikov. g) Varnost Banno okolje e po pravilu potrebuje vijo stopnjo varnosti omreja, aplikacij in operacijskega sistema. Gre za denar in osebne podatke komitentov. Poleg tega izpad ali vdor v katerega od sistemov lahko predstavlja najmanj naslednje posledice: izgubo licence Banke Slovenije, visoke denarne kazni drave, visoke denarne tobe komitentov in ali drugih fizinih ali pravnih oseb, izgubo komitentov ali izgubo zaupanja komitentov [24]. Izbrani sistem bo, preden bo prejel uspeen Zapis o testiranju s strani UCIT , seveda naprej dobro testiran s strani banke. Varnost mora biti zagotovljena z neprekinjenim preverjanjem identitete uporabnika na domenskem krmilniku. Kanali, preko katerih se prenaajo datoteke in identifikacija uporabnika, morajo biti varni. h) Operacijski sistem (heterogena okolja) Operacijski sistemi znotraj podjetja NLB d.d. so preteno homogeni na enaki ravni. To pomeni, da so delovne postaje preteno poenotene glede operacijskega sistema in nameenih aplikacij. Veina uporabnikov bo torej uporabljala orodje nameeno na operacijskem sistemu Windows 2000. Nekaj uporabnikov dela s pomojo operacijskega sistema Windows XP Professional in nekaj administratorjev potrebuje ta sistem pri operacijskem sistemu Windows 2003 Server. Upotevati moramo tudi najbolji moen scenarij in predvideti uporabo tudi na ostalih strenikih, kjer bi lahko administratorji potrebovali sistem za nadzor razliic za verzioniranje konfiguracijskih datotek, brali navodila ali odlagali poroila. Vse slednje se lahko izvaja rono ali avtomatizira preko

18

skript. Velikostni red teh namestitev je preko 1500 Windows 2000, 200 Windows XP, 300 Windows Serverjev, in 40 razlinih operacijskih sistemov iz druine UNIX (AIX, DEC ...) [15] (slika 2.1).

t.

0

200

400

600

800

1000

1200

1400

1600

Windows 2000 Windows XP Windows Server UNIX

t.

Slika 2.2: tevilo razlinih operacijskih sistemov v bannem okolju Iz zgoraj navedenega je razvidno, da iemo programsko reitev, ki bo nudila najboljo podporo za odjemalce na sistemu Windows. Za strenik je tudi najbolje, da deluje na operacijskem sistemu Windows. V NLB d.d. je najve administratorjev z dobrim poznavanje tega strenika, pa tudi strenikov, ki e delujejo in na katerih bi bilo mogoe namestiti streniko aplikacijo, je veliko. Vendar izbira operacijskega sistema za strenik ni nujno omejena na Windows Server, torej je mona konna izbira tudi za kateri drugi operacijski sistem. i) Masovno nameanje, nastavljanje in nadgrajevanje e iz zgornjega kriterija je razvidno, da je tevilo raunalnikov, na katere je potrebno namestiti orodje za nadzor razliic, veliko. Glede na to, da je to samo eno izmed orodij, ki so potrebna za delo uporabnikov, je nerealno priakovati, da bi zaposleni PCTeam-a porabili nekaj tednov za namestitev tega orodja na razlinih geografskih lokacijah. Gre torej za nujno zahtevo, brez katere ne moremo priakovati, da bo UCIT karkoli sprejeto. Banni sistem je e pripravljen za tako mnoino nameanje, nastavljanje in nadgrajevanje. Za operacijske sisteme Microsoft obstaja reitev v obliki SMS System Management Server proizvajalca Microsoft. Izdelek upravlja velike skupine raunalnikov z nameenim operacijskim sistemom Windows. Upravljanje s konfiguracijo nudi oddaljen nadzor, nameanje popravkov, distribucijo programske opreme, nameanje operacijskega sistema in samodejno ustvarja seznam strojne in programske opreme na nivoju celotnega podjetja. [4]. V banki se s podmnoico zgoraj natetih funkcionalnosti SMS dopolnjuje z aplikacijo

19

ScriptLogic proizvajalca QuestSoftware. Ta je uporabljan za administracijo omreij na osnovi operacijskih sistemov Microsoft Windows. Dovoljuje administratorjem omreja oddaljeno upravljanje na mreo priklopljenih osebnih raunalnikov in strenikov in s tem zagotavlja uniformnost omrenih konfiguracij in uveljavljanje varnostne politike[5]. Seveda pa je lasten sistem nameanja ravno tako dober kot e izbrana reitev, vendar mora pokrivati vse kljune funkcionalnosti e obstojeega bannega sistema. Osredotoili se bomo na oceno avtomatizirane namestitve v operacijskih sistemih Windows, ker je tevilo ostalih dovolj majhno, da je tamkajnja rona namestitev dovolj hitra (priprava avtomatizacije traja dlje kot namestitev na vse potrebne sisteme). Dodatno lahko h konni oceni tega kriterija doprinese morebitna monost samodejne integracije v Microsoft Office, IDE, Windows Explorer ipd. j) Ciljni uporabniki So iz obeh skupin bannih uporabnikov. To so poslovni in razvojni uporabniki. Prvi bodo nov sistem uporabljali za verzioniranje, ustvarjanje in pregledovanje dokumentacije. Njihovo poznavanje informacijskih tehnologij je omejeno. Ne moremo priakovati velikih prilagoditev glede metodologij dela. Razvojni uporabniki bodo dokumentacijo ustvarjali in pregledovali ter dodatno uporabljali za verzioniranje konfiguracij. Projektni vodje pa potrebujejo poglobljeno znanje sistema in bodo funkcionalnosti primerne njihovemu delu in potrebam ocenjevali z drugim kriterijem (monost poroanja). k) Administracija Mora biti lahka in transparentna. Krivulja uenja mora biti imbolj strma in kratka. Za najzahtevneje posege in potrebe banka navadno uporablja zunanje svetovalce, s katerimi si pomaga in s tem ceni administracijo, saj njihovim administratorjem poglobljeno poznavanje sistema ni potrebno . l) Razreevanje teav prejnjega sistema shranjevanja in verzioniranja Oceniti moramo, v kolikni meri novi sistem verzioniranja odpravlja teave starega sistema. Pod ta kriterij za skupno oceno pri izbiri orodja bomo uvrstil tudi parcialno monost avtomatizacije zaetnega stanja skladia, s katerim bomo poskusili odpraviti pomanjkljivost starega sistema urejanja dokumentacije. Obenem bomo na ta nain uporabnike poskusili nauiti novega sistema, saj njihove datoteke ne bodo ve poimenovane enako kot prej in ne bodo na istih lokacijah. m) Obveanje Za nekatere datoteke je dobro, da je doloen krog uporabnikov, e pride do sprememb, obveen v naprej . Navadno so to datoteke s podatki o tem, kdaj bo zaposleni na letnem dopustu, zbirna poroila, pravila in navodila pri razvoju ipd.. V vsakem primeru pa je potrebno v okviru skupin uporabnikov o spremembah obvestiti vodjo, saj na ta nain lahko uspeno spremlja in normira delo. n) Statistike in poroila Orodje v idealnih okoliinah nudi nain za poroanje vodstvu projekta na najvijem nivoju. e je dokumentacija pravilno razvrena po podrojih poslovanja, izdelkih, modulih izdelkov, skupinah uporabnikov (vlogah) in logini fazi razvoja, je s statistikami in poroili mogoe na najvijem nivoju dobro videti napredek na razlinih projektih. S tem kriterijem poskuamo oceniti, ali ima orodje e nek samodejni nain in ali je potrebno morda

20

osnovnemu orodju dodati e izdelano reitev ali morda do-programirati aplikacijo oziroma sistem, da je sposoben takih poroil. o) Pregledovanje razlik najvejega monega tevila oblik datotek Idealno je, da sistem e zna delati z najvejim monim tevilom oblik datotek. Za oblike datotek, ki niso podprte, mora obstajati preprost mehanizem, s katerim lahko dodajamo programe, s katerimi bo mono te razlike pregledovati. Najbolj potrebujemo sistem, ki bo imel podprte oblike datotek Microsoft Office, zato bo sistem, ki bo imel boljo podporo za te oblike najbolje ocenjen. p) Kader, ki dobro pozna in ima izkunje z integracijo doloenega orodja Pri vsaki integraciji in nasploh vsakem delu, ki se ga lotevamo smo vedno omejeni s kadri, ki jih imamo na voljo za izvedbo. Pomembno je, da imamo za izbrani sistem na voljo kader, ki sistem pozna in ima z njim izkunje. e kadra nimamo, moramo vsaj vedeti, kje tak kader lahko pridobimo za trajno, obasno ali enkratno sodelovanje. r) Reene ostale tipine teave in interni mehanizmi sistema za nadzor razliic Sistemi za nadzor razliic so zrela skupina izdelkov. Zaradi tega obstaja precej kriterijev, ki uporabniku niso najbolj oitni. Ni pomembno, da ima nek izdelek realizirane vse funkcionalnosti, da bi bil bolji. Gre bolj za uravnoteenost funkcionalnosti in seveda monost, da pomanjkanje le-teh ne zavira nemotenega dela. Na grobo delimo te kriterije [6]:

Operacije nad skladiem Tehnina dovrenost Uporabniki vmesniki

Operacije nad skladiem, ki so pomembne so: Nedeljivo objavljanje

Podpora nedeljivemu objavljanju pomeni, da skladie ne bo ostalo v nekonsistentnem stanju, e je bila operacija nad skladiem prekinjena med izvajanjem,.

Preimenovanje in premikanje datotek in map

Sistem mora premikanje ali preimenovanje mape ali datoteke beleiti v zgodovini in ohraniti staro zgodovino mape.

Pametno zlivanje po preimenovanju in premikanju

Sistem mora spremljati in beleiti preimenovanja in zlivati zgodovine in vsebine datotek. Zaznavanje kopij datotek in map

Ali zna sistem hraniti zgodovino na enem mestu v primeru, da je ena datoteka na ve mestih v skladiu?

Podvojitev oddaljenega skladia

Ali sistem podpira kloniranje oddaljenega skladia tako, da pridobi funkcionalno ekvivalentno kopijo na lokalnem sistemu in ali je to mono storiti brez posebnih pravic dostopa do oddaljenega skladia.

21

Prenaanje sprememb na krovno oddaljeno skladie Ali sistem omogoa irjenje sprememb iz enega skladia na drugega?

Pravice nad skladiem

Ali je mogoe doloiti pravice dostopa do dela skladia in ali je dostop odprt za vse? Podpora mnoice sprememb

Ali skladie podpira veje tevilo hkratnih sprememb? [6,3] Spremljanje zgodovine na nivoju datoteke

Ali ima sistem za nadzor razliic monost spremljanja zgodovine na nivoju datoteke vrstico-po-vrstico? Ali lahko na primer za vsako vrstico v datoteki na preprost nain pokae, v kateri reviziji je bila nazadnje spreminjana in od koga?

Praktini dodatki Monost dela na le eni mapi v skladiu

Ali lahko sistem prevzame le eno mapo skladia in omeji objave le na eno mapo? Spremljanje neobjavljenih sprememb

Ali lahko programska oprema pregleduje razlike, ki e niso objavljene v skladiu? Opomba ob objavi na nivoju datoteke

Ali sistem omogoa zapis opombe v zgodovino datoteke ob objavi mnoice sprememb in dodatno e k zgodovini mnoice sprememb.

Tehnina dovrenost Dokumentacija

Kako dobro je sistem dokumentiran in ali ga je lahko zaeti uporabljati? Preprostost namestitve

Kako preprosta je namestitev, kakni so predpogoji in soodvisnosti in kako teko jih je urediti?

Nabor ukazov

Kako obiren je nabor ukazov in kako je kompatibilen z naborom ukazov CVS (defakto odprtokodni standard)?

Podpora omrejem

Kako dobra in s kolikno stopnjo je mona integracija v obstojee sisteme omreij (protokoli in infrastrukturo)?

Prenosljivost

Kako prenosljiv je sistem na druge operacijske sisteme, raunalnike arhitekture in druge tipe sistemov?

Uporabniki vmesniki Vmesniki za brskalnik

Ali so na voljo vmesniki primerni za brskalnike, s katerimi je mogoe pregledovati drevo revizij, zgodovino, izvajati preglede razlik ipd.?

22

Koliko grafinih vmesnikov je na voljo

Koliko razlinih grafinih vmesnikov je na voljo za izbirani sistem za nadzor razliic?

2.2 Ocena razlinih orodij

Ponudba razlinih orodij je velika, saj so sistemi za nadzor razliic nastali v 70-ih letih prejnjega stoletja. Prvi tak sistem je bil SCCS, nasledil ga je sistem RCS, tega pa CVS. Razvijalci CVS so kasneje eleli popraviti nekatere najveje pomanjkljivosti tega sistema in so ustvarili CVSNT. V zadnjih dveh letih poskuajo odpraviti tudi nekatere pomanjkljivosti CVSNT in ponovno se je del razvijalcev odloil, da bo ustvaril nov izdelek EVS, ki pa e ni na voljo niti v alfa razliici. To je nekako glavna veja razvoja te skupine sistemov. Na vsaki toki razvoja pa je peica razvijalcev zaela razvijati svoje orodje za svoje potrebe. Ti so navadno odpravljali najbolj peree probleme, ki so se tisti trenutek pojavljali zaradi nezrelosti teh sistemov. Zaradi take mnoice orodij bomo s pomojo v prejnjem poglavju opisanih kriterijev poskuali izbiro orodja postopoma zmanjevati. S tem si bomo prihranili raziskovanje vsakega od orodij, ki e v najbolj pomembnih kriterijih ne dosegajo standardov, ki jih zahtevamo. Po temeljiti raziskavi te skupine programske opreme je na voljo 49 programskih reitev, ki nam omogoajo kvaliteten nadzor razliic:

AccuRev Aegis Aldon Alienbrain AllChange AllFusion Harvest Change Manager Arch AVS Bazaar BitKeeper ClearCase CM+ CMSynergy Code Co-op Co-Op CVS CVSNT Darcs DesignSync Git GNU arch LibreSource Synchronizer Mercurial Monotone OpenCM Perforce

23

Plastic SCM PureCM Razor SourceAnywhere SourceHaven StarTeam Subversion Superversion Surround SCM svk Synergy Team Foundation Server Vault Vesta Visual SourceSafe

2.2.1 Kriteriji za izbiro orodja

Da bi si olajali monost filtriranja in hitreje prili do ojega izbora monih programskih reitev za nae zahteve, smo ustvarili tabelo [priloga 1]. Tabela vsebuje zbrane podatke, ki smo jih dobili pri referennih primerjalnih ocenah na straneh Wikipedije[3] in better scm-ja[6]. Ne vsebuje vseh kriterijev, ki smo jih doloili v prejnjem poglavju, vendar bomo videli, da je ob primerni izbiri, glede na to, s pomojo katerih kriterijev elimo to razpredelnico filtrirati, mono najti optimalno reitev zelo hitro in brez celotnega poznavanja vseh ponujenih programskih reitev. Ti kriteriji so: vzdrevalec, stopnja zrelosti, model skladia, model konkurennosti, licenca, podprte platforme, cena, programski jezik, model zgodovine, identifikacija revizij, velikost skladia, podprti mreni protokoli, nedeljiva objava, preimenovanje datotek, zlivanje preimenovanja datotek, simbolini linki, monost proenja zank ob dogodkih, oznaene revizije, sledenje zlivanja, konverzija EOL, oznake, vejezinost, zgodovina, pomembni uporabniki, obstoj vmesnikov za brskalnike, obstoj samostojnih uporabnikih vmesnikov in integracija ali vtiniki za IDE.

2.2.1.1 Pomanjkanje dostopnih podatkov

V prvem koraku bomo takoj izloili tiste programske reitve, o katerih ne moremo zbrati dovolj podatkov. Pri izbiri programskih reitev je e to dovolj dober pokazatelj kakovosti in zrelosti izdelka. e orodja veina avtorjev sploh ne obravnava pri vrednostih primerjavah in ga ne navaja v testih, lahko sklepamo, da je razlog za to slaba kakovost ali nezrelost izdelka. elimo torej priznan izdelek, ki je dobro podprt in o katerem bomo nali dovolj uporabnike dokumentacije. Za tako programsko reitev z vejo verjetnostjo obstaja obirna skupnost uporabnikov ali plaljiva strokovna tehnina podpora, ki nam lahko pomaga v primeru zastojev ali teav. Iz seznama v prilogi 1 bomo izloili vse tiste programske reitve, za katere nismo mogli najti odgovorov na ve kot polovico opazovanih kriterijev in podatkov, ki smo jih zbrali. Na podlagi tega kriterija smo izloili orodja: Aegis, Arch, AVS, BitKeeper, CM+, CMSynergy, Codeville, Co-Op, Endevor, FileHamster, MKS, Mogware, OpenCM, Revision Control System, Source Code Control System, Superversion, Synergy in Vesta.

24

Ustrezni kandidati Izloeni kandidati

tevilo podatkov / Ime tevilo podatkov / Ime

27 12

AllFusion Harvest Change Manager AVS

Bazaar 9

ClearCase BitKeeper

DesignSync 7

Git Codeville

Perforce FileHamster

Subversion (SVN) MKS

Surround SCM Mogware

Team Foundation Server 6

26 Endevor

AccuRev Synergy

AllChange 3

CVS Arch

CVSNT Revision Control System

Mercurial Source Code Control System

PureCM 1

Razor Aegis

StarTeam 0

25 CM+

Code Co-op CMSynergy

LibreSource Synchronizer Co-Op

Monotone OpenCM

PlasticSCM Superversion

Vault Vesta

Visual SourceSafe

24

darcs

SourceAnywhere Hosted

23

GNU arch

22

Aldon

21

Alienbrain

SVK

19

Telelogic Synergy

18

SourceHaven

Tabela 2.1: Seznam vseh programskih reitev zdruenih po tevilu podatkov, ki smo jih zbrali Po pregledu izloenih programskih reitev je razvidno, da so izloene reitve veinoma zastarele in se redko uporabljajo. Obenem je model skladia ravno pri izloenih kandidatih veinoma neprimeren za nae potrebe.

25

2.2.1.2 Model skladia

Model skladia je naslednji in je izjemno pomemben kriterij, s katerim bomo izloili naslednje mone programske reitve. elimo si take, ki omogoajo model odjemalec-strenik. Uporabniki bodo veinoma popravljali le nekaj dokumentov na leto. Lokalna in porazdeljena skladia tako nikakor ne pridejo v potev.

Odjemalec-strenik; 21

Odjemalec-strenik/ Porazdeljeno; 2

Porazdeljeno; 8

Slika 2.3: Graf tevila preostalih kandidatov, ki zadostujejo pogoju izbire modela skladia S pomojo tega kriterija izbire smo izloili dodatnih 8 programskih reitev in sicer: Bazaar, Code Co-op, darcs, Git, GNU arch, Mercurial, Monotone in SVK. Pregled programskih reitev, ki so nam preostale nam pokae, da vsa orodja podpirajo strenike na operacijskem sistemu Windows (vsaj preko Jave) in da vsa nudijo odjemalce na vseh operacijskih sistemih, za katere je mogoe, da se bodo na banki uporabljali. Zato tega kriterija ne moremo uporabiti za zmanjanje tevila kandidatov.

2.2.1.3 Stopnja zrelosti izdelka

Tretji kriterij, po katerem bomo poskuali izloiti e nekaj dodatnih neprimernih orodij, je stopnja zrelosti izdelka. Kriterij je implicitno podoben prvemu kriteriju izloanja, vendar smo takrat eleli izloiti tiste programske reitve, ki niso uspele na triu, sedaj pa elimo, da nam ostane tak izdelek, ki je podprt in pri kateremu se dodajajo nove funkcionalnosti. Na podlagi tega kriterija smo dodatno izloili e CVS in Visual Source Safe. Oba izdelka sta v opuanju in na primeru VSS je mogoe rei, da ni nikoli dejansko zaivel, saj ga za razvoj ni uporabljal niti Microsoft. CVS je e dalj asa v opuanju in veina njegovih uporabnikov je e prela na CVSNT ali Subversion. Obstajajo tudi konverterji, ki CVS skladie lahko spremenijo v CVSNT ali Subversion obliko skladia.

2.2.1.4 Vejezina podpora orodja

etrti kriterij je na prvi pogled manj pomemben, a je kot e omenjeno pri poglavju o kriterijih izbire, glede na vrsto uporabnikov kritien. Velika veina uporabnikov na banki ne pozna angleine oz. jo pozna na zelo osnovni ravni. Strategija glede poimenovanja datotek ne predvideva opuanja umnikov in podobno. Pomembno je torej, da programska reitev podpira vejezinost v vsebini, odjemalcih, poimenovanju datotek ipd. Izloili bomo vsa orodja razen tistih, za katera vemo, da imajo vejezino podporo.

26

Da; 12

Ne; 2

(blank); 7

Slika 2.4: Razmerje med preostalimi kandidati, ki izrecno podpirajo vejezino podporo in ostalimi S pomojo tega kriterija smo izloili e neprimernih 9 programskih reitev: AccuRev, Aldon, AllChange, DesignSync, LibreSource Synchronizer, PlasticSCM, Razor, SourceHaven in Vault.

2.2.1.5 Ostale tipine teave in interni mehanizmi sistema za nadzor razliic

Peti kriterij izbire naj bo kriterij, s pomojo katerega so reene ostale tipine teave in interni mehanizmi sistema za nadzor razliic. V nai razpredelnici smo zabeleil 10 od 17-ih kriterijev opisanih v prejnjem poglavju pod to toko. V razpredelnici so nekateri aspekti in kriteriji zdrueni, saj so soodvisni ali izkljuujoi. Te kriterije smo nastavili tako, da je odgovor Da vedno pozitiven in predstavlja potrebno prednost. Izloili bomo vse tiste kandidate, ki ne ustrezajo dvema tretjinama te skupine kriterijev. Gre namre za kriterije, ki se v veini primerov lahko zaobidejo z drugano strategijo uporabe. Je pa potrebno poudariti, da tiste programske reitve z manj realiziranimi mehanizmi zahtevajo ve asa za integracijo v druge mehanizme, bolj stabilne strenike in delovne postaje, ve truda pri uporabi in celo potrebo po do-programiranju take funkcionalnosti preko katerega od skriptnih jezikov.

27

tevilo pozitivnih odgovorov / Ime

5

AllFusion Harvest Change Manager

6

Alienbrain

SourceAnywhere Hosted izloeni

7 ustrezni

StarTeam

Subversion (SVN)

Telelogic Synergy

CVSNT

Surround SCM

9

ClearCase

Perforce

PureCM

10

Team Foundation Server

Tabela 2. 2: Seznam vseh programskih reitev grupiranih po tevilu pozitivno reenih 10-ih tipinih teev in internih mehanizmov Pri teh destih kriterijih bomo preteli torej vsa polja, ki vsebujejo Da, zahtevamo pa, da ustrezajo vsaj sedmim (tabela 2.2). Na ta nain smo dodatno izloili e 3 kandidate: Alienbrain, AllFusion Harvest Change Manager in SourceAnywhere Hosted. Pri pregledu njihovih lastnosti vidimo, da nobeden nima referenc katerega od velikih podjetij in da je primerov uporabe teh izdelkov malo.

2.2.1.6 Cena

Zadnji kriterij, s katerim bomo zoili krog najboljih kandidatov je seveda cena. Potencialnih uporabnikov te programske reitve je 1500. V prvem koraku bo novo metodologijo verzioniranja dokumentacije takoj zaelo uporabljati okoli 300 uporabnikov. Izvleek iz tabele zbranih podatkov [priloga 1] vsebuje vse podatke [tabela 2.4], ki jih potrebujemo za odloitev. Cena je pri tej skupini izdelkov precej visoka. Najnija cena med preostalimi reitvami je 200 amerikih dolarjev na uporabnika. Obstaja monost nakupa konkurennih licenc, vendar je licenca zasedena e (navadno) 30 minut po vsaki operaciji na skladiu (tudi pregledu atributov datoteke). Projekcije normalne uporabe bi torej omogoale najve 7 uporabnikov na tako licenco, ki pa stane najmanj 4380 amerikih dolarjev. Tako visoke cene bi onemogoale irjenje te metodologije na druge projekte, saj bi se projektni vodje teko odloili za reitve, ki jim krnijo proraun projekta. Glede na prisotnost velikega tevila strokovnjakov iz podroja informatike v NLB d.d. in zelo spretnih sistemskih administratorjev, je potreba po plaani reitvi nelogina. Tako plaana reitev, kot neplaana, zahtevata veliko truda za vzdrevanje in praktino enak obseg dela, ki je potreben za namestitev, nastavljanje, vpeljavo sistema in vzdrevanje. Izloili bomo torej vse reitve, ki ne omogoajo brezplane uporabe programskih reitev. Plaana podpora je celo zaelena, saj nam dovoljuje, da se v primeru teav posluimo poklicnih

28

svetovalcev. Ker imamo e na voljo strokovnjake, ki imajo as administrirati sistem, ne elimo plaevati dodatnih strokov licenc.

Cena / Ime

ClearCase $4380 za konkureno licenco + davek (vkljuuje 12 mesecev podpore)

CVSNT Zastonj ali plaljivo s podporo

Perforce Zastonj do 2 uporabnika, in za OSS razvoj; obiajna cena $900 na sede s popusti na koliino

PureCM Zastonj za 2 uporabnika. $1,000 za 5 uporabnikov

StarTeam $7500 za konkureno, $2500 za poimensko licenco. Monost popusta z direkten kontaktom s podjetjem Borland

Subversion (SVN) Zastonj (Plaljiva podpora in storitve so na voljo)

Surround SCM Plaljivo

Team Foundation Server Licencirano preko MSDN naronine ali neposrednega nakupa (individualna ponudba)

Telelogic Synergy Ponudba na individualni ravni: kontakt Telelogic

Tabela 2.3: Podatek o monostih pridobitve programske reitve (cena) Na ta nain smo izloili naslednje programske reitve: ClearCase, Perforce, PureCM, StarTeam, Surround SCM, Team Foundation Server in Telelogic Synergy. Gre za skupino izjemno priznanih aplikacij, ki predstavljajo hrbtenico razvoja veine aplikacij, ki jih piejo velike multinacionalke. Predvsem ClearCase je zaradi svoje robustnosti in mnogih spremnih orodij uporabljan pri razvoju na podjetjih HP, IBM, Cisco, Motorola, Siemens, Ericsson, Nokia in e mnogih drugih. ClearCase ima razvit lastni datoteni sistem mvfs, ki je ga odlikuje hitrost in uporabnost pri avtomatizaciji pakirnih skript izdelkov na operacijskih sistemih UNIX [3,25]. TeamFundationSystem uporablja Microsoft za svoj razvoj. Perforce je poznan vsem tistim, ki so se kadarkoli ukvarjali s Perlom in FreeBSDjem[3]. Vendar ravno te reference kaejo na to, da so orodja, ki so izpadla, neprimerna za nao ciljno uporabo. Veina izpadlih orodij se uporablja za razvoj in spremljanje izvorne kode. Najveja prednost teh programskih reitev je multisite razvojni model z zrcaljenjem skladi. Orodja, ki so priloena, veinoma sluijo za datamining in za pomo pri doslednem oznaevanju, ki slui za oznaevanje vejih izdaj programske opreme. Ta skupina orodij ne pozna niesar

29

monejega kot so ClearCaseovi config-speci. Ti natanno opredeljujejo naine prevzemanja in lahko samodejno vejajo pri prevzemu datoteke in podobne funkcije s pomojo preproste sintakse.

2.2.2 Konna primerjava in izbira med ustreznima orodjima CVSNT in SubVersion

V tem trenutku sta nam ostali le e dve programski reitvi, ki jih nadalje lahko obravnavamo. To sta CVSNT in SubVersion. Spremnih orodij, ki podpirajo eno ali drugo reitev je priblino enako. Obe reitvi sta brezplani in imata monost plaljive strokovne podpore. Glede referenc je nemogoe rei, katera se je skozi as izkazala za bolj trpeno. SubVersion se pod svojo referenno listo ponaa s ASF, SourceForge, Google Code, KDE, GNOME, GCC, Ruby, Python, Mono, PuTTY, Zope, Xiph, GnuPG, CUPS, Wireshark, TWiki, Django in mnogo drugih, predvsem programskih podjetij. CVSNT je prav tako prisoten pri skoraj vseh podjetjih, ki se uvrajo v lestvico Fortune 500. Pri slednjem torej lahko reemo, da ima bolj heterogeno oz. raznovrstno paleto podjetjih, ki ga uporabljajo. Najverjetneje zaradi tega, ker vsa literatura aplikaciji CVSNT priznava, da je defakto novi standard sistemov za nadzor razliic. Poleg tega bolj natanen pregled ugotavlja nekatere tehnoloke dovrenosti, ki jih ima CVSNT pred SVN. Poglejmo zgolj razlike med obema aplikacijama in sicer najprej glede na to, kaj ima CVSNT esar SVN nima. CVSNT ima glede nivoja zrelosti strenika nekaj prednosti, ki e lahko zadostujejo, da na