IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE … · IV IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE PROJEKTE Z UPORABO UML 2.0 Ključne besede: tehnična dokumentacija programske

Peter Pogladič

IZDELAVA TEHNIČNE DOKUMENTACIJE ZA

ODPRTOKODNE PROJEKTE Z UPORABO

UML 2.0

Diplomsko delo

Maribor, avgust 2011

I

Diplomsko delo univerzitetnega študijskega programa

IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE

PROJEKTE Z UPORABO UML 2.0

Študent: Peter Pogladič

Študijski program: UN – Informatika in tehnologije komuniciranja

Smer: Informacijski sistemi

Mentor: doc. dr. Aleš Ţivkovič

Somentor: asist. Kristjan Košič

Maribor, avgust 2011

II

III

ZAHVALA

Maji za vzpodbudo in čas, ki ga nisem mogel

posvetiti njej.

Zahvaljujem se mentorju Ţivkovič Alešu in

somentorju Košič Kristjanu za pomoč in vodenje

pri opravljanju diplomskega dela.

Posebna zahvala velja staršem za odlično

vzgojo, potrpeţljivost in za vse priloţnosti, ki so

mi jih omogočili, tudi študij.

IV

IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE

PROJEKTE Z UPORABO UML 2.0

Ključne besede: tehnična dokumentacija programske opreme, odprta koda,

informacijski sistemi, UML, poslovni procesi, povratno inţenirstvo, RUP, MSF.

UDK: 004.439(043.2)

Povzetek

Odprtokodna programska oprema je za podjetja in splošne uporabnike zelo mamljiva,

vendar malo uporabljena. Problem se med drugim nahaja v pomanjkljivi dokumentaciji

in posledično zamujenimi možnostmi uporabe in prilagajanja odprtokodne programske

opreme potrebam organizacije. V diplomski nalogi je predstavljen prilagojen proces

izdelave tehnične dokumentacije odprtokodne programske opreme na osnovi procesnih

modelov RUP in Microsoft MSF4ASD. Namen diplomske naloge je izdelava splošnega

procesa za izdelavo tehnične dokumentacije, ki omogoča nadaljnji razvoj oziroma

prilagoditev odprtokodne programske opreme potrebam organizacije.

V

DEVELOPMENT OF TECHNICAL DOCUMENTATION FOR

OPEN SOURCE PROJECTS USING UML 2.0

Key words: technical software documentation, open source, information systems,

UML, business processes, reverse engineering, RUP, MSF.

UDK: 004.439(043.2)

Abstract

Open source software is very tempting for businesses and general users, however it is

not frequently used. The problem is in poor software documentation, which

consequently leads to missed opportunities to use or adapt open source software for the

needs of organization. The diploma thesis presents an adapted process of technical

documentation for open source software based on process models IBM RUP and

Microsoft MSF4ASD. The main purpose of the diploma thesis is to produce an overall

documentation process, which enables further development and customization of

software for the needs of the organization.

VI

VSEBINA

1 UVOD ...................................................................................................................... 1

2 ODPRTA KODA .................................................................................................... 3

2.1 PRIMERJAVA ODPRTOKODNIH LICENC ................................................................ 4

2.2 ODPRTOKODNI PROJEKTI ................................................................................... 5

2.3 ORANGE HRM .................................................................................................. 5

2.3.1 Statistika Orange Human Resource Management........................................ 6

3 METODOLOGIJE RAZVOJA PROGRAMSKE OPREME ............................ 8

4 PRIMERJAVA MICROSOFT SOLUTIONS FRAMEWORK FOR AGILE

SOFTWARE DEVELOPMENT IN IBM RATIONAL UNIFIED PROCESS ....... 10

4.1 IBM ZAČETNA FAZA/MSF FAZA PREDVIDEVANJA ........................................... 12

4.2 IBM ZBIRANJE INFORMACIJ/MSF FAZA NAČRTOVANJA ................................... 14

4.3 IBM FAZA KONSTRUKCIJE/MSF FAZA RAZVOJA IN STABILIZACIJE .................. 15

4.4 IBM FAZA PREVZEMA/MSF FAZA NAMESTITVE IN SPREMLJANJA .................... 16

5 TEHNIČNA DOKUMENTACIJA ODPRTOKODNEGA PROJEKTA S

POMOČJO UML 2.0 ................................................................................................... 18

5.1 PREGLED OBSTOJEČE DOKUMENTACIJE............................................................ 21

5.2 DOKUMENTACIJA PROGRAMSKE OPREME Z UPORABO DIAGRAMSKIH TEHNIK .. 22

5.2.1 Analiza funkcionalnosti sistema ................................................................. 22

5.2.2 Izdelava diagrama aktivnosti...................................................................... 22

5.2.3 Generiranje razrednega diagrama ............................................................. 23

5.2.4 Generiranje paketnega diagrama ............................................................... 23

5.2.5 Podatkovni model ....................................................................................... 24

5.2.6 Diagram zaporedja ..................................................................................... 24

5.2.7 Diagram namestitve .................................................................................... 24

5.2.8 Zemljevid strani .......................................................................................... 25

5.3 ZAKLJUČNA FAZA ............................................................................................ 25

5.3.1 Dopolnitev dokumentacije .......................................................................... 25

5.3.2 Ugotovitve ................................................................................................... 25

6 SKLEP ................................................................................................................... 26

VII

7 VIRI ....................................................................................................................... 27

8 PRILOGE .............................................................................................................. 29

8.1 KAZALO SLIK ................................................................................................... 29

8.2 KAZALO GRAFOV ............................................................................................. 29

8.3 SEZNAM PREGLEDNIC ...................................................................................... 30

VIII

UPORABLJENE KRATICE

RUP – Rational Unified Process

MSF4ASD – Microsoft Solutions Framework for Agile Software Development

GPL – General Public License

GNU GPL – GNU's Not Unix General Public License

OSI – Open Source Initiative

Orange HRM – Orange Human Resource Management

MsSQL – Microsoft Structured Query Language

http – Hypertext Transfer Protocol

CMMI – Capability Maturity Model Integration

XP – Extreme Programming

BPMN – Business Process Modeling Notation

Izdelava tehnične dokumentacije za odprtokodne projekte z uporabo UML 2.0 Stran 1

1 UVOD

Odprtokodna programska oprema je na razpolago brezplačno z moţnostmi prilagajanja le-

te, saj je na voljo njena izvorna programska koda (odvisno od licence). Pri prilagajanju

programske opreme potrebam organizacije, se pojavi problem poznavanja izvorne

programske kode in funkcionalnosti sistema, ki jo posameznik ali organizacija ţeli

prilagoditi. Diplomsko delo je nastalo na osnovi problematike dokumentiranja odprtokodne

programske opreme, ki v splošnem ni ali pa je zelo slabo dokumentirana. Odprtokodni

razvoj programske opreme je zelo razširjen, dobro podprt s strani skupnosti in predvsem

perspektiven. Veliko organizacij in splošnih uporabnikov se odloča za razvoj ali uporabo

odprtokodne programske opreme, pri čemer pa zaradi svobode razvoja programske opreme

ni poudarka na njeni dokumentaciji. Dokumentacija je pomembna predvsem zaradi

prilagajanja in nadgradenj odprtokodne programske opreme, ki jo le-ta omogoča.

Diplomsko delo je nastalo v okviru zgoraj omenjene problematike dokumentiranja

programske opreme in temelji na ogrodjih, ki omogočajo agilen razvoj programske opreme

IBM RUP (ang. IBM Rational Unified Process) in Microsoft MSF4ASD (ang. Microsoft

Solutions Framework for Agile Software Development). Ogrodji podajata dobre prakse pri

razvoju programske opreme, ki omogočajo hiter in učinkovit razvoj. Na osnovi ogrodij so

nastali določeni dokumenti, ki so sestavni del nastalega procesa tehnične dokumentacije

odprtokodne programske opreme v posamezni fazi. Dokumenti, ki opisujejo

dokumentacijo odprtokodne programske opreme so nastali na osnovi primerjave med

omenjenima ogrodjema.

Praktični del diplomske naloge je potekal s pomočjo izbranih orodij, ki omogočajo

povratno inţenirstvo. Za izdelavo UML diagramov se je uporabljal Visual Paradigm for

UML 8.0 Standard Edition, medtem ko se je za izdelavo podatkovnega modela uporabljal

MySQL Workbench 5.2 CE. Večino diagramov, ki sestavljajo dokumentacijo je bilo


mogoče pridobiti s pomočjo povratnega inţenirstva, nekatere pa je bilo potrebno izdelati

samostojno.

Pri izdelavi procesa dokumentacije programske opreme je bil uporabljen IBM WebSphere

Business Modeler Advanced 6.2. Proces opredeljuje faze dokumentacije programske

opreme in dokumente, ki so vhodi oziroma izhodi iz posamezne faze procesa.

Proces je predstavljen tudi s pomočjo spletnega vmesnika, ki opredeljuje vse vhodno –

izhodne dokumente, dodatno pa je podkrepljen tudi s predlogami, ki opisujejo dokumente

kot rezultate posamezne faze. Spletni vmesnik je izdelan s pomočjo IBM Method

Composer.

V nadaljevanju bomo spoznali osnove odprte kode in pregledali odprtokodne licence, ki jih

bomo navezali z moţnostmi prilaganja odprtokodne programske opreme.


2 ODPRTA KODA

Odprtokodna programska oprema je programska oprema, katere izvorna koda je na voljo

širši javnosti za brezplačno, prosto uporabo in/ali modifikacijo originalne različice izvorne

kode. Kljub temu, da lahko z odprtokodno programsko opremo njeni uporabniki počno

karkoli, zanjo veljajo posebna pravila, ki so opisana v licencah za odprtokodno programsko

opremo. Vsem licencam je skupnih nekaj pravil, kot so [8]:

1. Odprtokodno programsko opremo je mogoče svobodno redistribuirati. Lahko jo

redistribuira kdorkoli, brezplačno ali proti plačilu.

2. Izvorna programska koda je dostopna uporabniku. Licenca mora dovoljevati

distribucijo v predvideni in izvorni obliki.

3. Licenca mora dovoljevati spremembe osnovne kode in izvedene oblike nove

kode.

4. Kljub temu, da mora biti izvorna koda dostopna, lahko izvorni avtorji

zahtevajo, da se morebitne spremembe jasno ločijo od originalne kode in tako

ohranijo ločnico med prvotno in modificirano kodo (npr. v obliki popravkov ali

različnih verzij).

5. Licenca ne sme omejevati katerekoli osebe ali skupine.

6. Licenca ne sme biti omejevalna glede na področje dela, v okviru katerega se

programska koda uporablja.

7. Distribucija licenc mora biti enakovredna za vse uporabnike, brez dodatnih

omejitev.

8. Licenca za isto programsko kodo se ne sme razlikovati, če se jo uporablja v

kombinaciji z drugo programsko opremo.

9. Licenca ne sme omejevati uporabe druge programske opreme.

10. Licenca mora biti tehnološko nevtralna.


Vsa odprtokodna programska oprema ni distribuirana pod enako licenco. Nekatera

programska oprema uporablja prosto programsko licenco (ang. Free software license),

copyleft licenco ali GPL (ang. General Public License) licenco. GPL licenca je prosta,

copyleft licenca, medtem ko »GNU Lesser General Public License« zajema prosto

programsko licenco brez »copyleft« licence. Danes obstaja pribliţno petdeset licenc, ki so

izdane pod okriljem OSI (ang. Open Source Initiative).

2.1 Primerjava odprtokodnih licenc

Spodnja slika (Slika 2.1) tabelarično prikazuje primerjavo med različnimi odprtokodnimi

licencami. Vsaka licenca ima določene specifike, po katerih se razlikuje od drugih licenc.

Glede na primerjalne kriterije je najbolj odprta oziroma najmanj omejena licenca MIT

(ang. Massachusetts Institute of Technology license).

Slika 2.1: Primerjava odprtokodnih licenc [4]

http://en.wikipedia.org/wiki/Massachusetts_Institute_of_Technology


2.2 Odprtokodni projekti

Odprtokodno programsko opremo lahko definiramo kot programsko opremo, za katero je

izvorna koda izdana pod zaščitno licenco, ki zadostuje osnovnim pravilom odprte kode.

Licenca dovoljuje uporabo in spreminjanje programske opreme ter njeno razširjanje v

spremenjeni ali nespremenjeni obliki.

Ena izmed najbolj razširjenih skupnosti, kjer spodbujajo razvoj programske opreme, je

SourceForge (http://sourceforge.net/). Na spletnem mestu je zbranih okoli 295.000

odprtokodnih projektov. Med najbolj znanimi projekti so:

eMule,

Azureus / Vuze,

VLC media player,

Ares Galaxy,

7 – Zip,

FileZila,

Orange HRM (http://www.orangehrm.com/).

Orange HRM (ang. Orange Human Resource Management) smo uporabili kot osnovo pri

izdelavi procesa tehnične dokumentacije odprtokodne programske opreme in je tudi

dokumentiran v skladu z izdelanim procesom.

2.3 Orange HRM

Orange HRM je eden izmed vodilnih odprtokodnih informacijskih sistemov, ki ponuja

rešitve za manjša in srednje velika podjetja na področju vodenja človeških virov. Podjetju

oziroma organizaciji omogoča vodenje ključnega faktorja vsake organizacije – ljudi, z

moduli za upravljanje zaposlenih, z vodenjem prisotnosti, z upravljanjem zaposlovanja v

organizaciji in z drugimi.

Orange HRM je odprtokodni informacijski sistem, ki so ga začeli razvijati konec leta 2005.

Prva delujoča različica je bila razvita ţe januarja leta 2006. Danes ima Orange HRM

http://sourceforge.net/

http://www.orangehrm.com/


številne uporabnike po celem svetu, katerim zagotavlja stabilno, tehnološko dovršeno in

brezplačno aplikacijo za vodenje človeških virov. Zahvaljujoč licenci pod katero je izdan

(GPL), se nenehno dograjuje in izpopolnjuje.

Projekt je bil nagrajen z nagrado SourceForge: ˝Projekt meseca decembra 2008˝. Razvit je

v programskem jeziku PHP, uporablja podatkovni streţnik Microsoft SQL in http (ang.

Hypertext Transfer Protocol) streţnik Apache. Izdan je pod GPL in je v skladu z licenco

brezplačen. Trenutno je na voljo v stabilni verziji 2.6.4.

2.3.1 Statistika Orange Human Resource Management

V poglavju je zbranih nekaj zanimivih grafov, ki prikazujejo statistiko projekta s spletne

strani SourceForge.

Na spodnjem grafu (Graf 2.1) je prikazana statistika prenosov datotek na projektu Orange

HRM od začetka projekta do danes. Iz grafa je razvidno število prenosov projekta in

potreba po večanju pasovne širine, rezervirane za projekt na spletni strani SourceForge.net.

Graf 2.1: Statistika prenosov Orange HRM [6]


Spodnji graf (Graf 2.2) prikazuje spletni promet projekta na domači strani projekta. Iz

grafa je razviden razvoj projekta in njegova popularnost med uporabniki. Projekt je doţivel

svoj razcvet ob koncu leta 2008 in ga uţiva še danes.

Graf 2.2: Spletni promet projekta na domači strani [7]

Odprtokodni sistem za upravljanje s človeškimi viri ima zavidljiv milijon uporabnikov po

vsem svetu in več kot 500.000 prenosov projekta z uradne strani

http://www.orangehrm.com/#.

Skupnost, ki razvija projekt, se lahko pohvali tudi s sistemsko podporo uporabnikom

oziroma naročnikom, ki je plačljiva.

http://www.orangehrm.com/


3 METODOLOGIJE RAZVOJA PROGRAMSKE OPREME

Razvoj programske opreme med drugim ločimo tudi po metodologijah razvoja programske

opreme. Najbolj poznane med njimi so:

agilne metode razvoja (MSF, SCRUM, XP),

iterativne metode (RUP, Iterativni razvoj, Spiralna metoda),

metode, ki temeljijo na modelu slap (Slap, CMMI),

ad-hoc metode (proste metode, ki ne poznajo vodenega oziroma procesnega

razvoja programske opreme).

Agilne metode razvoja programske opreme temeljijo na iterativnem in inkrementalnem

razvoju programske opreme. Metode podajajo skupke dobrih praks in priporočil za razvoj

ţelenega projekta, ter pripomorejo k učinkovitem izvajanju nalog in vodenju projekta.

Agilne metode temeljijo na procesnem vodenju razvoja programske opreme, ki:

podajajo napotke glede zaporedja in sosledja aktivnosti razvojne skupine,

določajo kateri izdelki bodo razviti, ter kdaj bodo razviti,

usmerjajo naloge posameznikov in razvojne skupine kot celote,

nudijo kriterije za spremljanje in vrednotenje projektnih izdelkov in aktivnosti.

Spodnji graf (Slika 3.1) prikazuje uporabo metodologij razvoja programske opreme v

organizacijah. Razvidno je, da agilne metode prednjačijo pred ostalimi metodologijami

razvoja programske opreme. Zaskrbljujoče je predvsem dejstvo, da pribliţno 30 odstotkov

organizacij ne uporablja nobene od procesno vodenih metodologij, temveč temeljijo na

tako imenovanih ad-hoc metodah.


Slika 3.1: Uporaba metodologij razvoja v organizacijah [10]


4 PRIMERJAVA MICROSOFT SOLUTIONS FRAMEWORK FOR

AGILE SOFTWARE DEVELOPMENT IN IBM RATIONAL

UNIFIED PROCESS

Pri izdelavi procesa tehnične dokumentacije odprtokodne programske opreme smo kot

osnovo uporabili agilni metodologiji razvoja programske opreme IBM RUP in MSF4ASD.

Metodologiji razvoja programske opreme povzemata skupke dobrih praks in načel pri

razvoju programske opreme, ki natančno opredeljujejo vloge in opravila v posamezni fazi

razvoja.

IBM RUP (Slika 4.1) je razdeljen v štiri faze razvoja in podaja šest dobrih praks pri

razvoju programske opreme (iterativni razvoj, upravljanje zahtev, uporaba komponentnih

arhitektur, vizualno modeliranje, preverjanje kakovosti in nadzor nad spremembami [5]).

Slika 4.1: Proces razvoja programske opreme po IBM RUP [5, 11, 12]


MSF4ASD (Slika 4.2) pri razvoju programske opreme kombira spiralni model in model

slap. Cikel razvoja se zaključi z jasno definiranim mejnikom, če mejnik ni doseţen, se

cikel ponovi (Slika 4.3). MSF4ASD pri razvoju programske opreme ne pozna hierarhične

ureditve vlog na projektu, kar vse člane razvojne skupine postavi v enakovreden poloţaj.

Slika 4.2: MSF Procesni model [1]

Slika 4.3: Disciplina upravljanje [3]


Pri primerjavi ogrodij (Slika 4.4) najdemo podobnosti pri razvoju programske, ki so

podrobneje opisane v naslednjih podpoglavjih.

Slika 4.4: Primerjava po fazah [11]

4.1 IBM začetna faza/MSF faza predvidevanja

Na začetku vsakega projekta se sestane projektna skupina in naročnik, kjer naročnik

seznani projektno skupino s problemom. Naročnik natančno doreče katere stvari ga na

projektu zanimajo. Te informacije morajo biti dokumentirane, da projektna skupina in

naročnik ustvarijo skupno in popolno vizijo problema [11].

Tako po RUP kot po MSF se ustvari vizija, da se zagotovi enaka ideja poslovnega

problema z obeh strani (naročnik – izvajalec). Prav tako se po RUP in MSF določijo meje

projekta in njegov obseg. Pri določanju obsega projekta je RUP bolj temeljit, zaradi česar

laţje določa fiksne meje projekta, medtem ko MSF daje obsegu projekta in njegovim

mejam več svobode, kar ugaja strankinim ţeljam [11].

Ko naročnik spozna poslovni primer projekta je naloga projektne skupine predvideti in

identificirati ključne elemente za ustrezno rešitev poslovnega problema. Naročnik, končni

uporabniki in ostale zainteresirane skupine obvestijo projektno skupino o njihovih ţeljah,

potrebah in pričakovanjih glede sistema [11].


Skladno z ogrodjem RUP je pridobitev čim več informacij, ki pripomorejo k splošnemu

planiranju in razumevanju problema s katerim se sooča. V začetni fazi se formulirajo vse

zahteve, okvirni stroški, potencialna tveganja in arhitektura sistema.

MSF je agilne miselnosti, kar pomeni, da MSF skupina misli, da ni potrebno imeti vseh

informacij v naprej. Agilna skupnost meni, da sprememba ni samo verjetna, ampak da je

neizogibna. MSF skupina uporablja »just-in-time« pristop, kjer se določena stvar naredi,

ko se potrebuje [11].

Obe metodi uporabljata ta razvojni cikel programske opreme za preučitev strankinega

poslovanja, problemov in potreb za razvoj skupnega pogleda na projekt. RUP je v tej fazi

bolj strikten in formalen glede obsega projekta kot MSF, ki je bolj fleksibilen in odprt do

sprememb [11].

Tabela 4.1: Dokumenti začetne faze (RUP) in faze predvidevanja (MSF) [2, 11]

RUP - Začetna faza MSF - Faza predvidevanja

Vizija Vizija in obseg

Poslovni primer Poslovne zahteve

Načrt razvoja programske opreme - Struktura projekta

- Poročilo o napredku razvojne skupine na

projektu

- Predlogi funkcionalnosti

- Poročilo o napredku posameznega člana

razvojne skupine

- Finančni načrt

Iteracijski načrt Poročilo o doseganju mejnika faze razvoja

Razvojna infrastruktura Poročilo trenutne infrastrukture

Slovar (ang. Glossary)

Model primerov uporabe

Seznam začetnih tveganj na projektu


4.2 IBM zbiranje informacij/MSF faza načrtovanja

V obdobju planiranja se pripravi ideja prihodnosti projekta, ocenijo se stroški in čas

projekta ter se določijo sredstva. Oba procesa uporabljata vizijo kot osnovo za ustvarjanje

sistemske arhitekture, identifikacijo nefunkcionalnih in funkcionalnih zahtev ter omejitev

[11].

RUP ţeli pridobiti čim več informacij, kolikor je mogoče, da bi lahko projekt ocenili in

načrtovali kot celoto ali po iteracijah. V fazi zbiranja informacij projektna skupina zasnuje

arhitekturo in vizijo ter napravi podroben plan tveganj za celotno fazo konstrukcije ter za

upravljanje in nadzor preostalih procesov. Na koncu faze zbiranja informacij so

identificirane vse funkcionalne in nefunkcionalne zahteve [11].

MSF se v ciklu načrtovanja bolj osredotoča na načrtovanje iteracij kot na načrtovanje

celotnega projekta, ker je načrtovanje projekta kot celote po MSF nesmiselno, saj je

predvideno, da se bodo pojavile spremembe na projektu. Kjer se RUP osredotoča na

načrtovanje tveganj na projektu, se MSF osredotoča na kvalitetno planiranje naslednje

iteracije [11].

Tabela 4.2: Dokumenti faze zbiranja informacij (RUP) in načrtovanja (MSF) [2, 11]

RUP - Zbiranje informacij MSF - Načrtovanje

Načrtovalni model Logično načrtovanje

Model implementacije Fizični model

Načrt razvoja programske opreme Načrt razvoja programske opreme

Model primerov uporabe (80%) - Uporabniške zahteve

- Scenarij uporabe

Dodatne specifikacije - Funkcionalne specifikacije

- Sistemske zahteve

- Zahteve obratovanja

Smoke test Testni plan

Prototip

Dopolnjen seznam tveganj na projektu

Proces razvoja

Dokument arhitekture programske opreme


4.3 IBM faza konstrukcije/MSF faza razvoja in stabilizacije

Obdobje izgradnje programske opreme ima pri obeh procesih enak namen, zgraditi

programsko opremo v skladu s pričakovanji in potrebami, ki so bile določene v prvem

obdobju razvoja programske opreme. V tej fazi se kaţe iterativni in inkrementalni razvoj

programske opreme, ki ga oba procesa spodbujata. Razvoj produkta je izdelan korak za

korakom, zagotovljena pa je visoka kvaliteta produkta.

Po RUP je bilo narejeno planiranje celotnega projekta in iteracij v prejšnjih fazah, zato se v

tej fazi osredotoča zgolj na implementacijo produkta po iteracijah. Razvijalci programske

opreme prejmejo potrebne primere uporabe (ang. Use case), funkcionalne opise in

arhitekturo za implementacijo funkcionalnih zahtev sistema. Vsaka iteracija se konča z

verzijo sistema, ki se predstavi naročniku, od katerega pridobimo povratno informacijo o

sistemu. Projektna skupina organizira iteracijo, v kateri zagotovi sebi in naročniku

informacije o napredku in statusu sistema, podatke dokumentira in preveri ali je projekt

konsistenten s predhodnimi dogovori [11].

Po MSF poteka izgradnja programske opreme na tako imenovan »ad-hoc« način. Za

razliko od RUP, MSF ne načrtuje celotnega projekta ampak samo naslednjo iteracijo.

Delovni dan po MSF se začne s kratkim sestankom razvijalcev o statusu projekta,

napredku in o delu, ki še mora biti opravljeno. Iteracija se zaključi z pregledom

zastavljenih ciljev in napredka projekta.


Tabela 4.3: Dokumenti faze konstrukcije (RUP) in Konstrukcije (MSF) [2, 11]

RUP - Konstrukcija MSF – Konstrukcija (Razvoj in stabilizacija)

Načrt namestitve

Model implementacije

Iteracijski načrt

Proces razvoja

Infrastruktura razvoja

Podatkovni model

Dodatne specifikacije

Model primerov uporabe (dokončan)

Poročilo testiranja in razhroščevanja

Revizija sledljivosti

Testne specifikacije

4.4 IBM faza prevzema/MSF faza namestitve in spremljanja

Ko je produkt dovolj razvit in ima pričakovan nivo kakovosti, je pripravljen na predajo

stranki. Pred predajo sistema stranki je potrebno storiti naslednje: beta testiranje, da

validiramo nov sistem glede na strankina pričakovanja, paralelno izvajanje sistema s

prejšnjim, preureditev testne podatkovne baze, izobraževanje uporabnikov, dodatna

dokumentacija (navodila za uporabo, namestitev) in podobno [11].

Po predaji projekta uporabniku se projektni cikel RUP zaključi, medtem ko ima MSF

dodatno periodo cikel spremljanja produkta, katerega namen je pregled celotnega projekta,

identifikacija novih tveganj, hroščev in podobno.

Tabela 4.4: Dokumenti faz prevzema (RUP), Namestitve in spremljanja (MSF) [ 2, 11]

RUP - Prevzema MSF - Namestitve, Spremljanja

Delujoča aplikacija

Pomoč uporabnikom

Analiza »preteklega« projekta

Dokončanje projekta


Pri izdelavi procesa tehnične dokumentacije odprtokodne programske opreme z uporabo

UML 2.0 sta kot osnova sluţila prav Microsoft Solutions Framework in IBM Rational

unified process. Na osnovi omenjenih ogrodij so definirani izhodni produkti posameznega

opravila (ang. task), ki jih določa proces. Proces je podobno kot primerljivi ogrodji

procesno voden in podrobno opredeljuje posamezne korake procesa. Definirane ima vloge,

dokumente in opravila, ki pripomorejo k učinkoviti dokumentaciji izbrane programske

opreme. Rezultat procesa je tehnična dokumentacija, ki omogoča učinkovit, hiter in

kontroliran razvoj oziroma prilagoditev programske opreme potrebam organizacije. V

primeru modifikacij programske opreme se lahko pri ponovni dokumentaciji preurejene

programske opreme upremo na proces, ki je podrobneje predstavljen v nadaljevanju.


5 TEHNIČNA DOKUMENTACIJA ODPRTOKODNEGA

PROJEKTA S POMOČJO UML 2.0

Proces dokumentacije odprtokodne programske opreme je razdeljen v tri zaporedne faze,

ki so podrobneje opisane s pomočjo opravil, ki posamezno fazo sestavljajo. Rezultati

posameznega procesa znotraj faze so dokumenti, ki zaključujejo celoten proces tehnične

dokumentacije programske opreme. Proces je izdelan na osnovi praktične izdelave

tehnične dokumentacije odprtokodnega projekta Orange HRM.

Proces smo razvili s pomočjo orodja IBM WebSphere Business Modeler Advanced 6.2,

kjer je celoten BPMN proces (ang. Business Process Modeling Notation) predstavljen

grafično (Slika 5.1). Poslovni proces, izdelan s pomočjo omenjenega orodja definira

procese, ter njihove vhodno – izhodne dokumente. Razdeljen je na tri segmente:

pregled obstoječe dokumentacije,

dokumentacija programske opreme z uporabo diagramskih tehnik,

zaključna faza.

Spletni vmesnik vključuje poslovni proces in je nastal s pomočjo orodja IBM Method

Composer, ki je namenjen spletni predstavitvi procesa. Spletni vmesnik je namenjen

laţjemu sledenju, opisu opravil in dokumentov pri izdelavi tehnične dokumentacije

programske opreme. Spremljanje razvoja dokumentacije je organizirano v tri skupine:

vloge,

dokumente,

segmente.


Slika 5.1: Proces dokumentacije


Pri izdelavi praktičnega dela se je s pomočjo orodja Visual Paradigm for UML 8.0

Standard Edition generiral razredni, paketni diagram, medtem ko je bilo potrebno diagram

primerov uporabe, diagram aktivnosti, diagram namestitve, zemljevid strani izdelati ročno.

Izdelava entitetno relacijskega diagrama je potekala s pomočjo MySQL Workbench 5.2

CE.

Spletni vmesnik procesa dokumentacije (Slika 5.2) je namenjen vodenju dokumentacije, ki

jo je potrebno izdelati za določen produkt.

Slika 5.2: Spletni vmesnik procesa tehnične dokumentacije odprtokodne programske opreme

Proces dokumentacije opisuje vloge, aktivnosti, opravila in dokumente, ki jih je potrebno

izpeljati v posamezni fazi procesa. Rezultat posamezne faze je eden ali več dokumentov, ki

opisujejo dokumentiran produkt. Vsako opravilo v fazi je vodeno s koraki, ki jih je

potrebno izpeljati, določa vloge, ki so odgovorne za izpeljavo opravila ter opredeljuje

dokumente, ki sluţijo kot vhodni oziroma izhodni produkti. Iz procesa je natančno

razvidno katera vloga je odgovorna za posamezni dokument ter v kateri fazi dokumentacije

se dokument uporablja.

Proces opredeljuje štiri vloge, ki jih v praksi lahko dodelimo več ljudem. Vsaka vloga ima

vnaprej predviden profil osebe, ki naj bi ji ustrezal. Posamezni vlogi so dodeljena različna


opravila in odgovornosti, ki jih mora posameznik upoštevati za dosego ţelenega cilja,

dokumentacije produkta.

Vloge procesa:

projektni vodja,

analitik,

administrator podatkovne baze,

vodja razvojne skupine.

Proces dokumentacije programske opreme izdelan s pomočjo IBM RMC je priloţen k

diplomski nalogi na zgoščenki na kateri najdemo s praktičnimi primeri opisan proces

dokumentacije odprtokodnega projekta Orange HRM po korakih, ki jih proces predvideva.

V nadaljevanju so opisani koraki procesa izdelave tehnične dokumentacije.

5.1 Pregled obstoječe dokumentacije

V tem koraku se zbere vsa dostopna dokumentacija projekta, ki ga ţelimo dokumentirati za

nadaljnji razvoj oziroma prilagoditi potrebam organizacije. Vsi nadaljnji koraki procesa

izdelave dokumentacije so odvisni prav od tega koraka. Če zbrana dokumentacija ustreza

našim potrebam za nadaljnji razvoj oziroma prilagoditev projekta se proces dokumentacije

zaključi ţe v prvem segmentu procesa, v nasprotnem primeru sledimo nadaljnjim korakom

dokumentacije projekta, da dobimo ţeljen rezultat dokumentacije.

Tabela 5.1: Vhodni in izhodni dokumenti

Vhodi Izhod

- Obstoječa dokumentacija Dokument obstoječe dokumentacije

- Izvorna koda


5.2 Dokumentacija programske opreme z uporabo diagramskih tehnik

Faza dokumentacije programske opreme z uporabo diagramskih tehnik je najpomembnejša

in najobširnejša faza procesa dokumentacije, v kateri definiramo vse potrebne dokumente,

ki jih faza določa za uspešen zaključek le-te. Pri dokumentaciji produkta si pomagamo z

najrazličnejšimi orodji za povratno inţenirstvo, katera skrbno izberemo v skladu s

produktom, ki ga dokumentiramo, saj nam ob pravilni izbiri orodja olajšajo delo, v

nasprotnem primeru pa oteţijo.

Faza je razdeljena v osem opravil, med katerimi se opravila »generiranje razrednega

diagrama«, »generiranje paketnega diagrama« in »generiranje ER modela« izvajajo

paralelno, medtem ko se ostali procesi izvajajo zaporedno.

5.2.1 Analiza funkcionalnosti sistema

Diagramov primerov uporabe ne moremo pridobiti s pomočjo povratnega inţenirstva, zato

jih moramo izdelati ročno. Diagram primerov uporabe pomaga dokumentirati

funkcionalnosti sistema, ter omogoči enostavnejši pogled na funkcionalnosti projekta, ki ga

dokumentiramo.


Vhodi Izhodi

- Dokument obstoječe dokumentacije

- Pregled delovanja sistema (demo

različica sistema, aktualna različica

sistema).

- Dokument funkcionalnosti sistema, ki zajema

diagram primerov uporabe ter opis

pomembnejših primerov uporabe iz diagrama

primerov uporabe.

5.2.2 Izdelava diagrama aktivnosti

Diagrame aktivnosti tako kot diagrame primerov uporabe, rišemo ročno, saj jih s pomočjo

povratnega inţenirstva ne moremo generirati. Diagrame aktivnosti rišemo na osnovi

posameznih primerov uporabe iz DPU. Diagram aktivnosti predstavlja interakcijo med


sistemom in uporabniki sistema. Diagrame aktivnosti uporabimo namesto vezanega

besedila, ki smo ga uporabili za opis primerov uporabe v prejšnji točki.


Vhodi Izhod

- Diagram primerov uporabe Diagram aktivnosti

- Opis primerov uporabe

5.2.3 Generiranje razrednega diagrama

S pomočjo orodja generiramo razredni diagram iz izvorne kode projekta, ki ga

dokumentiramo. Na trţišču je na voljo več orodij za generiranje razrednih diagramov,

izberemo pa tistega, ki omogoča generiranje razrednega diagrama iz izvorne kode projekta,

ki ga dokumentiramo. Kvaliteta generiranega razrednega diagrama je odvisna od znanja

razvijalcev, ki so aplikacijo razvili in od programskega jezika v kateri je aplikacija

implementirana.


Vhod Izhodi

- Izvorna koda - Razredni diagram

- Generirano poročilo o razredih v razrednem diagramu

5.2.4 Generiranje paketnega diagrama

Paketni diagram lahko prav tako generiramo s pomočjo orodja za povratno inţenirstvo. V

vsak paket lahko dodamo predhodno generirane diagrame. Paketni diagram je posebno

uporaben, kadar gre za obseţno aplikacijo in ko postane razredni diagram nepregleden.


Vhodi Izhod

- Razredni diagram - Paketni diagram

- Izvorna koda


5.2.5 Podatkovni model

Podatkovni model generiramo s pomočjo orodja, ki ga izberemo na osnovi podatkovne

baze, ki se uporablja na izbranem projektu, ki ga dokumentiramo. Podatkovni model nam

omogoča celovit vpogled na podatkovno bazo sistema, ki jo sestavlja skupek entitet in

odvisnosti med njimi.


Vhod Izhod

Podatkovna baza sistema Entitetno relacijski model

5.2.6 Diagram zaporedja

Diagrame zaporedja lahko prav tako generiramo s pomočjo orodja za povratno inţenirstvo.

Orodja za povratno inţenirstvo so omejena na programski jezik v katerem je aplikacija

napisana, zato je v določenih primerih diagrame zaporedja teţko ali celo nemogoče

generirati. Diagrami zaporedja prikazujejo interakcijo v obliki mnoţice sporočil, ki si jih

izmenjujejo objekti v času izvajanja funkcionalnosti sistema.


Vhod Izhod

Izvorna koda Diagram zaporedja

5.2.7 Diagram namestitve

Diagram namestitve pomaga pri razumevanju arhitekturne namestitve sistema. Prikazuje

relacije med posameznimi segmenti programske opreme, ter nam daje vpogled v

arhitekturo. Diagrama namestitve ne moremo generirati s pomočjo orodij za povratno

inţenirstvo, temveč ga je potrebno narisati ročno.


5.2.8 Zemljevid strani

Zemljevid strani koristi pri pregledu preglednosti spletne strani oziroma uporabniškega

vmesnika aplikacije, ki jo dokumentiramo. Zemljevid strani nam prikaţe strukturo

uporabniškega vmesnika. Pri izdelavi zemljevida strani moramo biti pozorni tudi na več

vrst oziroma tipov uporabnikov, ki sistem uporabljajo.


Vhod Izhod

Uporabniški vmesnik Zemljevid strani

5.3 Zaključna faza

Zaključna faza procesa dokumentacije je namenjena pregledu dokumentov, ki so nastali v

predhodnih fazah, katere pregledamo, dopolnimo in povzamemo ugotovitve oziroma

izkušnje, ki smo jih skozi proces dokumentacije pridobili.

5.3.1 Dopolnitev dokumentacije

Pridobljeno dokumentacijo dopolnimo s splošnimi informacijami o projektu ter z

informacijami, ki dopolnjujejo vse nastale dokumente skozi proces. Dopolnitev

dokumentacije sluţi za boljše razumevanje predhodno izdelane dokumentacije ter

dokumentiranega projekta kot takšnega.

5.3.2 Ugotovitve

Glede na pridobljeno dokumentacijo zapišemo vse ugotovitve in izkustva, ki smo jih

pridobili pri dokumentaciji projekta skozi proces dokumentacije. V tem razdelku zapišemo

tudi ideje o nadgradnji oziroma prilagoditvi sistema, ki smo ga dokumentirali.


6 SKLEP

Proces izdelave tehnične dokumentacije odprtokodne programske opreme je, za razliko od

ogrodij na katerih temelji, namenjen izdelavi tehnične dokumentacije ţe razvite

programske opreme. Sluţi kot osnova za nadaljnji razvoj oziroma prilagoditev

odprtokodne programske opreme potrebam organizacije. Proces podaja smernice in dobre

prakse pri izdelavi tehnične dokumentacije odprtokodne programske opreme ter omogoča

celovit pogled na delovanje sistema in njegove funkcionalnosti.

Proces izdelave tehnične dokumentacije je nastal na osnovi dokumentacije odprtokodnega

projekta. Bazira na uporabi diagramov UML, ki grafično prikazujejo lastnosti

dokumentirane programske opreme na vsakem segmentu tako nastalega procesa. Notacija,

z uporabo tehnik jezika UML, omogoča enostaven pregled delovanja sistema in

identifikacijo funkcionalnosti sistema. Prednost procesa je predvsem v celovitem vpogledu

na delujoč sistem, ki ga dobimo na osnovi dokumentacije sistema. Nastala dokumentacija

omogoča laţje razumevanje ter hitro vpeljavo novih razvijalcev v poznavanje

funkcionalnosti odprtokodnega sistema. Pomembno je, da razvijalci razumejo notacijo

UML.

Proces se lahko v prihodnje uporablja pri dokumentaciji nastajajoče kot tudi za

dokumentacijo ţe obstoječe programske opreme. Z dosledno dokumentacijo programske

opreme bi odprtokodna programska oprema pridobila na vrednosti in kvaliteti izdelave le-

te ter omogočala laţjo nadgradnjo in modifikacije programske opreme.

Zasnova procesa ponuja še mnogo moţnosti nadgrajevanja, osnovne smernice pa so:

proces dokumentacije komercialne programske opreme,

procesno vodena dokumentacija programske opreme v razvoju,

prilagajanje procesa in njegovo nadgrajevanje potrebam organizacije.


7 VIRI

1. “Bb497038.ump0103_big(en-us,TechNet.10).gif (GIF Image, 400x253 pixels)”,

http://technet.microsoft.com/en-us/library/Bb497038.ump0103_big(en-

us,TechNet.10).gif, Zadnjič obiskano 22.08.2011.

2. “Chapter 1 - Introduction to the Microsoft Solutions Framework”,

http://technet.microsoft.com/en-us/library/bb497060.aspx, Zadnjič obiskano

22.08.2011.

3. “Module 1: The Total Solution Life Cycle”, http://msdn.microsoft.com/en-

us/library/bb756611.aspx, Zadnjič obiskano 22.08.2011.

4. “Shafqat Ahmed’s .NET Blog: Comparison of Different Open Source Licenses -

With Comparison Chart!”, http://www.shafqatahmed.com/2008/10/comparison-of-

d.html, Zadnjič obiskano 22.08.2011.

5. “Rational Unified Process- Best practices for software development teams”,

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/12

51_bestpractices_TP026B.pdf, Zadnjič obiskano 22.08.2011.

6. “SourceForge.net: Project Statistics for OrangeHRM - Human Resource

Management”,

http://sourceforge.net/project/stats/detail.php?group_id=156477&ugn=orangehrm&

type=prdownload&mode=alltime&file_id=0, Zadnjič obiskano 12.05.2011.

7. “SourceForge.net: Project Statistics for OrangeHRM - Human Resource

Management”,

http://sourceforge.net/project/stats/detail.php?group_id=156477&ugn=orangehrm&

type=sfweb&mode=alltime, Zadnjič obiskano 12.05.2011.

8. “Vse o Odprti kodi - COKS - Center odprte kode Slovenije",

http://www.coks.si/index.php5/Vse_o_Odprti_kodi, Zadnjič obiskano 22.08.2011.

9. A Comparison between Agile and Traditional Software Development

Methodologies, M.A.Awad, 2005, http://www.scribd.com/doc/55475190/A-ion-

Between-Agile-and-Traditional-SW-Development-Methodologies, Zadnjič

obiskano 22.08.2011.

http://technet.microsoft.com/en-us/library/Bb497038.ump0103_big(en-us,TechNet.10).gif

http://technet.microsoft.com/en-us/library/Bb497038.ump0103_big(en-us,TechNet.10).gif

http://technet.microsoft.com/en-us/library/bb497060.aspx

http://msdn.microsoft.com/en-us/library/bb756611.aspx

http://msdn.microsoft.com/en-us/library/bb756611.aspx

http://www.shafqatahmed.com/2008/10/comparison-of-d.html

http://www.shafqatahmed.com/2008/10/comparison-of-d.html

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

http://sourceforge.net/project/stats/detail.php?group_id=156477&ugn=orangehrm&type=prdownload&mode=alltime&file_id=0

http://sourceforge.net/project/stats/detail.php?group_id=156477&ugn=orangehrm&type=prdownload&mode=alltime&file_id=0

http://sourceforge.net/project/stats/detail.php?group_id=156477&ugn=orangehrm&type=sfweb&mode=alltime

http://sourceforge.net/project/stats/detail.php?group_id=156477&ugn=orangehrm&type=sfweb&mode=alltime

http://www.scribd.com/doc/55475190/A-ion-Between-Agile-and-Traditional-SW-Development-Methodologies

http://www.scribd.com/doc/55475190/A-ion-Between-Agile-and-Traditional-SW-Development-Methodologies


10. Agile development: Mainstream adoption has changed agility; Dave West and To

Grant, Ph.D. for application development & program management professional,

http://www.osp.ru/netcat_files/18/10/h_d8eddd303b6cf0c38c23601c4363bee4,

Zadnjič obiskano 22.08.2011.

11. Comparative study MSF vs. RUP4ASD: Rational unified process vs. Microsoft

solutions framework for agile software development by Johan W.A. Traa: Erasus

University Rotterdam, The Nederland

12. IBM Rational Unified Process for small projects, http://www-

01.ibm.com/software/awdtools/rup/, Zadnjič obiskano 22.08.2011.

http://www.osp.ru/netcat_files/18/10/h_d8eddd303b6cf0c38c23601c4363bee4

http://www-01.ibm.com/software/awdtools/rup/

http://www-01.ibm.com/software/awdtools/rup/


8 PRILOGE

8.1 Kazalo slik

Slika 2.1: Primerjava odprtokodnih licenc [4]....................................................................... 4

Slika 3.1: Uporaba metodologij razvoja v organizacijah [10] ............................................... 9

Slika 4.1: Proces razvoja programske opreme po IBM RUP [5, 11, 12]............................. 10

Slika 4.2: MSF Procesni model [1] ..................................................................................... 11

Slika 4.3: Disciplina upravljanje [3] .................................................................................... 11

Slika 4.4: Primerjava po fazah [11] ..................................................................................... 12

Slika 5.1: Proces dokumentacije .......................................................................................... 19

Slika 5.2: Spletni vmesnik procesa tehnične dokumentacije odprtokodne programske

opreme ......................................................................................................................... 20

8.2 Kazalo grafov

Graf 2.1: Statistika prenosov Orange HRM [6] ..................................................................... 6

Graf 2.2: Spletni promet projekta na domači strani [7] ......................................................... 7


8.3 Seznam preglednic

Tabela 4.1: Dokumenti začetne faze (RUP) in faze predvidevanja (MSF) [2, 11] ............. 13

Tabela 4.2: Dokumenti faze zbiranja informacij (RUP) in načrtovanja (MSF) [2, 11] ...... 14

Tabela 4.3: Dokumenti faze konstrukcije (RUP) in Konstrukcije (MSF) [2, 11] ............... 16

Tabela 4.4: Dokumenti faz prevzema (RUP), Namestitve in spremljanja (MSF) [ 2, 11] .. 16

Tabela 5.1: Vhodni in izhodni dokumenti ........................................................................... 21











Documents

IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE … · IV IZDELAVA TEHNIČNE DOKUMENTACIJE ZA ODPRTOKODNE PROJEKTE Z UPORABO UML 2.0 Ključne besede: tehnična dokumentacija programske