aplikacija na osnovi konceptualnoga modela · 2017. 1. 12. · application effort estimation...
TRANSCRIPT
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
Denis Čeke
PROCJENA TEŽINE RAZVOJA WEB
APLIKACIJA NA OSNOVI
KONCEPTUALNOGA MODELA
DOKTORSKI RAD
Zagreb, 2016.
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
Denis Čeke
PROCJENA TEŽINE RAZVOJA WEB
APLIKACIJA NA OSNOVI
KONCEPTUALNOGA MODELA
DOKTORSKI RAD
Mentor:
doc. dr. sc. Boris Milašinović
Zagreb, 2016.
FACULTY OF ELECTRICAL ENGINEERING AND COMPUTING
Denis Čeke
ESTIMATION OF WEB APPLICATION
DEVELOPMENT EFFORT BASED ON A
CONCEPTUAL MODEL
DOCTORAL THESIS
Supervisor:
Assistant Professor Boris Milašinović, Ph.D.
Zagreb, 2016
Doktorski rad izraĎen je na Sveučilištu u Zagrebu Fakultetu elektrotehnike i računarstva, na
Zavodu za primijenjeno računarstvo.
Mentor: doc. dr. sc. Boris Milašinović
Doktorski rad ima: 147 stranica
Doktorski rad br.:__________
O mentoru
Boris Milašinović roĎen je u Metkoviću 1976. godine. Diplomirao je 2001. godine na
Matematičkom odjelu Prirodoslovno matematičkog fakulteta u Zagrebu (dipl.ing. matematike
– smjer računarstvo) te magistrirao 2006. i doktorirao 2010. godine na Sveučilištu u Zagrebu
Fakultetu elektrotehnike i računarstva (FER).
Od listopada 2002. godine zaposlen je na Zavodu za primijenjeno računarstvo FER-a.
Prethodno je bio zaposlen kao znanstveni novak na Matematičkom odjelu PMF-a (2001.-
2002.) te kao programer u tvrtki MultimediaLab d.o.o. (2000.-2001.). U prosincu 2013.
godine izabran je u zvanje docenta te je bio mentor više od 20 završnih i diplomskih radova.
U okviru vanjske suradnje Zavoda radio je na projektiranju i izradi baza podataka i
programske podrške te kao konzultant u projektima informatizacije za gospodarstvo i drţavnu
upravu. Objavio je više od 20 radova u časopisima i zbornicima konferencija u području
informacijskih sustava i programskog inţenjerstva.
Doc. Boris Milašinović član je stručne udruge IEEE i programskih odbora nekoliko
meĎunarodnih konferencija.
About the Supervisor
Boris Milašinović was born in Metković in 1976. He graduated at the Department of
Mathematics of the Faculty of Science, University of Zagreb in July 2001. He defended his
Master Thesis in 2006 and defended PhD thesis in 2010 at the Faculty of Electrical
Engineering and Computing, University of Zagreb.
Since October 2002 he has been employed at the Department of Applied Computing of the
Faculty of Electrical Engineering and Computing, University of Zagreb as a research
assistant. From September 2001 to October 2002 he was employed at the Department of
Mathematics of the Faculty of Science, University of Zagreb as a research and teaching
assistant. From June 2000 to September 2001 he had worked as a Software Developer at
Multimedia Lab. He has held the position of Assistant Professor at the Faculty of Electrical
Engineering and Computing since December 2013. He was supervisor for more than 20
bachelor and master thesis. He is author or co-author of more than 20 scientific, professional
and educational publications in the area of information systems and software engineering.
Assistant Prof. Boris Milašinović is a member of IEEE and a member of several
conference international programme committees.
SAŢETAK
Današnji razvoj društva i informacijskih sustava nameće potrebu za razvojem web
aplikacija u što kraćem vremenskom periodu u skladu s postavljenim zahtjevima u pogledu
efikasnije iskorištenosti sustava. Voditelji projekata su prilikom planiranja web projekata
većinom usmjereni na vremensku varijablu. Razvoj web aplikacija na osnovi konceptualnog
modela pruţa bolju procjenu teţine razvoja i umanjuje mogućnost pojave grešaka u razvoju.
Do danas, predloţen je značajan broj metoda za razvoj web aplikacija na osnovi
konceptualnog modela, ali samo nekolicina od njih omogućava provoĎenje procesa procjene
teţine razvoja web aplikacija. Većina predloţenih metoda koristi prethodno definirane
teţinske faktore na osnovu kojih vrše procjenu za novi model i izračun teţine razvoja, što
zahtijeva velike količine podataka o prethodnim projektima.
U posljednje vrijeme u području procjene teţine razvoja softverskih projekata, sve više
paţnje se posvećuje izračunu funkcionalne veličine projekata, jer: (1) su bazirani na
funkcionalnosti koja će biti isporučena krajnjem korisniku, a ne na artefaktima koji su nastali
kao produkt završene aplikacije (na primjer broj web stranica, multimedijalnih datoteka itd.);
(2) funkcionalnosti aplikacije mogu biti mjerene u ranoj fazi procesa razvoja web aplikacije;
(3) su bazirani na standardima koji definiraju koncept veličine i zahtjeva za potrebe procjene
veličine aplikacija; i (4) imaju široku prihvaćenost u industriji.
Postoji nekoliko metoda za izračun funkcionalne veličine softvera koje su standardizirane,
ali metoda koja je u posljednje vrijeme doţivjela ogromnu prihvaćenost od strane istraţivača i
razvojnih inţenjera je metoda COSMIC (Common Software Measurement International
Consortium). Njena česta zastupljenost se moţe objasniti time da je vrlo jednostavna za
korištenje i implementaciju, kao i vrlo jednostavna za učenje. Kombiniranih pristupa za
procjenu teţine razvoja web aplikacija, na bazi konceptualnih modela i funkcionalne veličine
je jako malo u literaturi.
Disertacijom je definirana procedura za kreiranje konceptualnih modela kao i metoda za
izračun funkcionalne veličine web aplikacija na osnovi konceptualnih modela u svrhu
kreiranja modela za izračun teţine razvoja web aplikacija. Kao rezultat istraţivanja u okviru
ove disertacije nastao je matematički model pomoću kojeg je moguće na osnovi
konceptualnog modela koristeći izračunatu funkcionalnu veličinu web aplikacije procijeniti
teţinu razvoja same web aplikacije izraţenu u formi vremenske varijable. TakoĎer, u okviru
disertacije razvijen je i sustav za automatsku procjenu teţine razvoja web aplikacija, a koji
podatke potrebne za izračun modela aktivno preuzima iz podatkovnog repozitorija prethodno
razvijenih web aplikacija po predloţenom modelu. Sustav je nazvan WADEES (Web
Application Effort Estimation System) i omogućava da se na bazi konceptualnog modela izvrši
automatski izračun CFP-a (engl. COSMIC Function Point, CFP) i procjeni napor za razvoj
neke nove web aplikacije.
Verifikacija modela za procjenu teţine razvoja web aplikacija je provedena na osnovu
predloţenog modela i baze podataka razvijenih web aplikacija. Kao rezultat verifikacije
istraţivanja nastao je prototip sustava za procjenu teţine razvoja web aplikacija razvijenih na
osnovi konceptualnog modela.
KLJUČNE RIJEČI
Web aplikacija
Konceptualni model
Funkcionalna veličina
Procjena teţine razvoja
COSMIC
Funkcijske točke
ABSTRACT
ESTIMATION OF WEB APPLICATION DEVELOPMENT EFFORT BASED ON A
CONCEPTUAL MODEL
Development of society and information systems nowadays imposes the need for
developing web applications in a short period of time in accordance with the set requirements
concerning efficient utilization of the system. During web project planning, project managers
are primarily focused on the time variable in terms of estimating time needed for project
completion. Due to the discrepancies between the time required for development and the
demands set, projects reports often comment on overrunning project budget and deadlines for
development, which results in creating a software that ultimately contains a number of errors.
In terms of the estimation of web application development effort, the need has arisen to find a
solution which would define how to estimate the time required for software development, as
early as possible, even before the start of development. The earliest stage in the software
development process is a phase which defines the requirements to be met by the software
which is being developed. This issue is very complex due to a number of parameters that
affect the very development of web applications, development environment in which they are
being created and programming languages used to develop web applications. Sometimes
some of these parameters are neither measurable in the desired time nor can they be displayed
in an acceptable form necessary to conduct the analysis. In the context of the existing issues
relating to the estimation of the web application development effort, there have been many
attempts to solve this issue in different ways and with different methods which mostly
represented adaptations of the existing software development effort estimation methods.
However, most of these methods could not meet the demands of the software development
effort estimation since the development of a typical software and is somewhat different from
web application development. One of the possible directions of research that has provided
satisfactory results is development effort estimation based on the calculation of the functional
size of a web application, which then needs to be linked with the efforts necessary for their
development.
Calculating a functional size of a web application can be performed by using some of
the standardized methods for calculating the functional size of software for this purpose.
However, the use of calculation implies the existence or completion of a web application with
a complete source code or a conceptual model, whose functional size can be calculated. Since
there is a need to perform the calculation of the functional size of software in the earliest stage
of its development, that is, in the phase of defining requirements, it seems fitting to use
conceptual models of web applications to calculate their functional size.
Recently, web application development is generally focused on creating different models
of web applications before the implementation of the process of application coding.
Conceptual models of web applications are considered to be the most appropriate models to
undergo top quality processes of analysis and calculation of functional size of a web
application. In order to calculate the functional size of web applications based on this type of
model, it is necessary that conceptual models are quite descriptive in order to be able to make
a detailed description of all the elements to be implemented in the web application. The very
development of web applications based on a conceptual model provides an opportunity for a
better estimation of the development effort and reduces the possibility of occurrence of errors
in development since their models need to be defined prior to application source code is
created. To date, several methods for web application development based on the conceptual
model have been proposed. However, there are very few methods of estimating web
application development effort that use conceptual models of web applications as an input
parameter in their systems for development effort estimation. Even those methods that use
some kind of conceptual models are not always applicable because they are developed by
certain tools for modeling web applications that are not publicly available nor can be
integrated into overall process to estimate the web application development effort.
This paper proposes a model to estimate the web application development estimation
that combines the method of creating conceptual models of web applications and the method
of calculating the functional size of web applications based on previously created conceptual
model. Combining these two methods proved to be a good solution as it is possible to
estimate web application development effort in the phase of defining requirements.
Calculation of the functional size of web applications based on the conceptual model
represents a task which is not resistant to the occurrence of errors in the calculation, if
performed manually. Therefore, the automation of these tasks needs to be implemented as an
integral part of the system for web application development effort estimation. One such
system for automation of the process of calculating the web application development effort
based on the conceptual model was developed and implemented within this paper.
One of the main shortcomings of the existing methods for estimating web application
development efforts is that the mostly used methods are the ones which cannot estimate
development effort in the early stages of software development. Methods developed so far to
estimate software development effort, which used methods of calculating the functional size
of software, were mostly first-generation methods that were not applicable to web
applications since web application development technology is constantly progressing.
There are several standardized methods of calculating the functional size of software,
but the method that has recently experienced tremendous acceptance by researchers and
development engineers is the COSMIC (Common Software Measurement International
Consortium) method. Its frequent application in practice can be contributed to the fact that it
is very simple to use and implement, and very easy to learn. Combined approaches to estimate
web application development effort on the basis of the conceptual models and functional size
are rather hard to find in literature.
COSMIC method is widely applicable and provides fairly accurate results to estimate
software development efforts, especially when it comes to multi-layer software architecture.
In addition, this method is very well accepted among the staff dealing with software
development effort estimation, since it offers a possibility to easily create rules for mapping
between COSMIC method and software requirements of modern software architecture.
In recent years, the focus of the attention in the field of estimation of software project
development effort has shifted to calculating the functional size of the project using specific
methods for these purposes, since they are based on functionality that will be delivered to end
user and not on the artifacts created as a product of finished applications (eg. number of web
sites, multimedia files, etc.). In addition, these methods can measure functional size of web
applications in the early phases of development of web applications and are widely applicable
in the industry.
The second chapter of this paper provides an overview of the general measurement
methods and methods based on function points used to estimate software development effort.
This chapter also presents some of the most commonly represented measures to calculate the
accuracy of the models created to estimate software development effort. Web application
development assumes faster application development, with fewer team members, where cost
estimates include improvisation as an option for the estimation. In addition, similarities and
differences between the development of web applications and development of a typical
software are presented in the chapter, as well as problems related to the estimation of efforts
arising from these differences.
In the field of estimating software development effort a number of methods have been
developed, while such methods are significantly fewer in the development of web
applications. The third chapter of the paper provides an overview of research in this area. The
chapter provides examples of studies that use different methods to estimate web application
development effort. A very limited number of methods of estimating web application
development effort has met with wide applicability in research and industrial sector. A
standard method for this type of estimation has not yet been created, as is the case with
estimation of software development effort, where method COCOMO II has been widely used
for many years, both by researchers and by the industry. A possible reason for the lack of a
universal method for the estimation of the application development effort is the fact that the
web development is very dynamic and is based on the development technologies that are
advancing day by day, with new programming languages and methods of developing this kind
of software appearing on the market.
The fourth chapter provides an overview of the measurement procedures for
estimation of web application development effort. The overview deals with twelve methods
mostly represented in the literature, although a number of these methods are no longer used in
practice. The reason for exclusion of some of the methods is their obsolescence and non-
compliance with the new technology of development of web applications. Most of these
methods use indicators unique to the observed method of estimating web application
development effort, based on which the conclusions and results of the research were defined.
Several of the analyzed methods were created as extensions of the existing methods used to
estimate a typical software development effort and customized for web application use.
Lately, more importance is being given to methods based on the principles which calculate the
required values without taking into account technology of development of web applications,
such as the programming language used for development, and different variations of the
method of analysis of function points.
Nowadays, web application development uses methods which create conceptual
models to web applications prior to the development. The development of such models has
multiple purpose, some of which include creating and visualizing the web project and
development of web applications with as few errors, thus speeding up the development and
documentation of web projects. The fifth chapter deals with methods commonly used to
develop conceptual models of web applications.
The process of creating UWE model and the application of COSMIC method is provided
in chapter six. Measuring the functional size of web applications can be performed by several
methods, which calculate the size. However, the analysis of the existing studies and analysis
of the simplicity of use and application of specific measure of functional size on a web
application, showed that the best method for application is COSMIC measurement method.
Applying the COSMIC method requires models of web applications presented in an
appropriate manner in order to create and implement the rules for the preferred method.
Therefore, the models of web applications and measures of functional size should be
harmonized for the purposes of calculating functional size.
The paper proposed a new method of estimating web application development effort that
consists of calculating functional size of web applications based on conceptual models as well
as the procedure for creating conceptual models of web applications, as shown in the sixth
and seventh chapter.
The design of the measurement procedure for calculating COSMIC function points is
performed through several steps which are described in chapter seven. Defining the objectives
of the measurement, specifying the concepts to be measured, selecting the metamodel and
defining numerical rules represent some of the basic phases when designing a measurement
procedure. Each of these steps needs to be carried out carefully and in accordance with the
COSMIC rules so that UWE models and COSMIC measurement rules would be harmonized
and uniformly defined.
The procedure for creating models to predict the web application development effort is
shown in the eighth chapter. The procedure covers several stages, such as the empirical
evaluation of the proposed model, a method for validating the accuracy of the prediction, the
model creation and evaluation of the quality of the model created. The chapter further
presents data on web applications used for creation of estimation model. The selection of
variables was made to create a model based on the analysis of their impact on the effort
needed to develop web applications by using statistical data analysis. Statistical data analysis
obtained data on variables used to create estimation model. After the statistical analysis of the
data related to projects, a regression method was used to create a model to estimate web
application development effort. Evaluation of the quality of model for predicting effort was
carried out by cross-validation. After the analysis, the conclusions were provided regarding
the constraints of the models created relating to the limitations of web projects used in the
data groups for model development.
The paper has also developed a system for automation of the calculation of functional
size of web applications and automation of the calculation of the web application
development effort based on a method developed in the paper. Chapter nine provides an
overview of the basic features of a developed system for automation of measurements, the
platform on which it developed and the way it operates. The automation of these processes is
one of the most important segments of the process for calculating web application
development effort based on the conceptual model, since, in this manner, the process of
calculation is accelerated, the occurrence of prospective errors is reduced and the entire
system is systematically automated. The system developed to automate the process of
calculating the functional size of a web application based on a conceptual model provides
quite good results, as shown in the comparative table of automatic and manual calculation of
functional size shown in this chapter.
The thesis defines a procedure to create conceptual models and methods of calculating
functional size of web applications on the basis of conceptual models for the purposes of
designing a model for calculation of web application development effort. The research
resulted in a mathematical model, based on a conceptual model, which uses the calculated
funcional size of a web application to estimate the level of web application development
effort represented as a time varialble. In addition, within the thesis, a system for automatic
web application development effort estimation was developed. The system actively collects
the data necessary for model calculation from a data repository of the previously developed
web applications by the proposed model. The system is called WADEES (Web Application
Effort Estimation System) and it enables automatic calculation of the CFP (COSMIC Function
Point) based on conceptual model and estimation of a new web application development
effort.
Verification of the model of development effort estimation for web applications was
carried out on the basis of the proposed model and a database of previously developed web
applications. As a result of the verification of the research, a prototype system to estimate web
applications development effort based on the conceptual model was created. The model
created provides good results with reasonable accuracy taking into account the issues treated,
availability of test data sets and development of the issues discussed.
KEYWORDS
Web application
Conceptual model
Functional size
Development effort estimation
COSMIC
Function points
SADRŢAJ
1. UVOD .................................................................................................................................... 1
1.1. Motivacija ....................................................................................................................... 1
1.2. Znanstveni doprinosi ...................................................................................................... 2
1.3. Struktura disertacije ........................................................................................................ 3
2. TEHNIKE PROCJENE TEŢINE RAZVOJA SOFTVERA ................................................. 5
2.1. Funkcijske točke ............................................................................................................. 5
2.2. Mjerne metode ................................................................................................................ 5
2.2.1. IFPUG ..................................................................................................................... 5
2.2.2. COSMIC .................................................................................................................. 8
2.2.1. MK II ..................................................................................................................... 10
2.2.2. NESMA ................................................................................................................. 12
2.3. Općenita podjela tehnika za procjene teţine razvoja softvera ...................................... 12
2.3.1. Procjena stručnjaka ................................................................................................ 13
2.3.2. Algoritamski modeli .............................................................................................. 13
2.3.3. Strojno učenje ........................................................................................................ 15
2.4. Mjere točnosti za kreirane modele za procjenu teţine razvoja softvera ....................... 17
2.5. Sličnosti i razlike klasičnog softvera i web aplikacija .................................................. 18
3. VEZANA ISTRAŢIVANJA ............................................................................................... 22
3.1. Pregled najzastupljenijih tehnika procjena teţine razvoja web aplikacija ................... 24
3.1.1. Zaključivanje temeljeno na slučaju (Case based reasoning, CBR) ..................... 25
3.1.2. Postupna regresija (Stepwise regression, SWR) ................................................... 25
3.1.3. Linearna regresija (Linear regression) .................................................................. 26
3.1.4. Metoda vektora potpore regresije (Support-vector regression, SVR) .................. 26
3.1.5. Web-COBRA ........................................................................................................ 26
3.1.6. CWADEE (Chilean Web Application Development Effort Estimation) .............. 27
3.1.7. WEBMO ................................................................................................................ 27
3.2. Primjeri studija s metodama za procjenu teţine razvoja web aplikacija ...................... 29
4. MJERNE PROCEDURE ZA PROCJENU TEŢINE RAZVOJA WEB APLIKACIJA ..... 33
4.1. IFPUG-ove smjernice za web aplikacije ...................................................................... 33
4.2. Web objekti .................................................................................................................. 33
4.3. Web točke ..................................................................................................................... 34
4.4. Internetske točke ........................................................................................................... 35
4.5. Podatkovne web točke .................................................................................................. 36
4.6. OOmFPWeb ................................................................................................................. 36
4.7. Cândido i Sanches ........................................................................................................ 38
4.8. Costagliola i suradnici .................................................................................................. 38
4.9. Fraternali i suradnici ..................................................................................................... 39
4.10.Procedura OO-HFP ...................................................................................................... 40
4.11.Metoda OO-H COSMIC Function Points (OO-HCFP) ............................................... 40
4.12.Metoda OO-Method COSMIC Function Points (OOmCFP) ....................................... 41
5. KREIRANJE KONCEPTUALNIH MODELA WEB APLIKACIJA ................................ 43
5.1. OOHDM ....................................................................................................................... 43
5.2. WebML......................................................................................................................... 45
5.3. Object-Oriented-Hypermedia metoda (OO-H)............................................................. 46
5.4. W2000 .......................................................................................................................... 47
5.5. UML za web inţenjering (UWE) ................................................................................. 48
6. KREIRANJE UWE MODELA I PRIMJENA MJERNE METODE COSMIC .................. 52
6.1. Mjerenje funkcionalne veličine web aplikacija na bazi COSMIC metode .................. 53
6.2. Kreiranje UWE modela za potrebu procjene teţine razvoja web aplikacija ................ 54
7. DIZAJN MJERNE PROCEDURE ZA IZRAČUN COSMIC‐OVIH FUNKCIJSKIH
TOČAKA ................................................................................................................................. 61
7.1. Definiranje ciljeva ........................................................................................................ 65
7.2. Karakterizacije koncepta koji će se mjeriti .................................................................. 68
7.3. Odabir metamodela ...................................................................................................... 68
7.3.1. Pravila za funkcionalne procese, podatkovne grupe i podatkovne atribute .......... 78
7.4. Definiranje numeričkih pravila..................................................................................... 88
7.4.1. Primjer primjene pravila mjerenja izračuna kretanja podataka ............................. 89
8. MODEL ZA PROCJENU TEŢINE RAZVOJA WEB APLIKACIJA ............................... 94
8.1. Empirijska evaluacija predloţenog modela .................................................................. 94
8.2. Metoda za validaciju točnosti predviĎanja ................................................................. 100
8.3. Kreiranje modela ........................................................................................................ 101
8.4. Evaluacija kvalitete modela za predviĎanje uloţenog napora .................................... 110
9. AUTOMATIZACIJA PROCJENE NAPORA .................................................................. 113
9.1. Primjena COSMIC pravila brojanja na UWE modele ............................................... 113
9.2. Arhitektura i implementacija sustava za automatizaciju CFP mjerenja ..................... 120
9.3. Pregled WADEES sustava ......................................................................................... 121
9.3.1. WADEES arhitektura .......................................................................................... 123
9.3.2. Primjer obrade podataka ...................................................................................... 123
9.3.3. Izračun CFP-a za svaki od korištenih modela ..................................................... 126
9.4. Automatizacija izračuna napora pomoću WADEES sustava ..................................... 127
ZAKLJUČAK ........................................................................................................................ 130
REFERENCE ......................................................................................................................... 132
POPIS KRATICA .................................................................................................................. 141
PRILOG ................................................................................................................................. 143
ŢIVOTOPIS ........................................................................................................................... 144
BIOGRAPHY ......................................................................................................................... 145
POPIS OBJAVLJENIH RADOVA ....................................................................................... 146
1
1. UVOD
1.1. Motivacija
Razvoj web aplikacija se kreće u smjeru razvoja zasnovanog na konceptualnom modelu
čiji je krajnji cilj razvoj web aplikacija na visokoj razini apstrakcije bazirano na modelima i
transformacijama modela u izvršna aplikativna rješenja [1]. Modeli mogu predstavljati
različite razine apstrakcije web aplikacije, počevši od platformski-neovisnih (engl. Platform
Independed Models, PIM) do platformski-orijentiranih modela (engl. Platform Specific
Models, PSM). Ovakav način razvoja web aplikacija donosi prednosti i mogućnosti
voditeljima projekata da na osnovi konceptualnih modela naprave rane procjene veličine
buduće aplikacije i procjene napora koji će biti potreban za implementaciju.
U posljednjih nekoliko godina, provedeno je nekoliko studija koje su se bavile procjenom
veličine web aplikacija i trajanjem razvoja na osnovi konceptualnog modela [2]. Priroda
projekata unutar kojih se razvijaju web aplikacije prisiljava voditelje projekata da se primarno
usmjere na vremensku varijablu u cilju dostizanja zahtijevanih kratkih vremenskih intervala
za razvoj ove vrste softvera. Uslijed disbalansa potrebnog vremena za razvoj i zahtjeva koji se
postavljaju, u izvješćima projekata često je navedeno probijanje budţeta projekata i vremena
za razvoj što rezultira proizvodnjom softvera koji u konačnici ima puno pogrešaka [3]. S
obzirom da se razvoj web aplikacija moţe promatrati kao proces transformacija modela u one
uspješne za izvršavanje na ciljanoj platformi, pristup razvoju zasnovan na modelu pruţa
mogućnost da se prebrode prethodno navedeni problemi.
U proteklih nekoliko godina, značajan broj metoda za razvoj web aplikacija koje prate
razvoj zasnovan na modelu je predloţen, meĎu kojima se mogu izdvojiti metoda objektno-
orijentiranog hipermedijskog dizajna (engl. Object-Oriented Hypermedia Design Method,
OOHDM) [4], WebML jezik za modeliranje web aplikacija (engl. Web Modeling Language,
WebML) [5], objektno-orijentirana hipermedija (engl. Object-Oriented Hypermedia, OOH)
[6], W2000 [7] i UML za web inţenjering (engl. UML-based Web Engineering, UWE) [8].
Usvajanje takvih metoda postavlja nove izazove voditeljima web projekata, posebno u smislu
procjene resursa i planiranja projekata. Osnovni problem u ovom kontekstu je procjena
veličine budućih web aplikacija i potrebnog napora za njihov razvoj na bazi konceptualnog
modela.
Jedna vaţna činjenica je ta da ne postoji univerzalna metoda za razvoj modela za
predviĎanje napora za razvoj web aplikacija. Do danas, jedan od glavnih izazova u ovom
2
području ostaje odgovor na pitanje kako izvršiti procjenu veličine web aplikacije ili napora
potrebnog za razvoj prije nego je sama aplikacija uopće razvijena.
Mogući odgovor na ovo pitanje leţi u pretpostavci da je napor potreban za razvoj web
aplikacija, izmeĎu ostalog, ovisan od funkcionalne veličine same aplikacije. Ova hipoteza je
već testirana od strane nekih istraţivača i kroz neke primjere je pokazano da ova ovisnost
postoji [2][9], što je logično ako se uzme u obzir da što je aplikacija kompleksnija to je
potreban veći napor za njen razvoj.
Funkcionalna veličina softvera je definirana kao „veličina softvera izvedena
kvantificiranjem funkcionalnih zahtjeva― [10]. Funkcionalni zahtjevi korisnika opisuju što bi
korisnik morao moći obaviti korištenjem softvera. Neki od primjera funkcionalnih zahtjeva
korisnika bi mogli biti slanje podataka od strane korisnika putem on-line forme ka sustavu za
obradu podataka, obrada zaprimljenih podataka poslanih od strane korisnika prema sustavu,
skladištenje podataka koje korisnik ţeli trajno sačuvati ili pak dobavljanje podataka za
potrebe korisnika iz spremišta podataka. Funkcionalna veličina je nezavisna od programskog
jezika i razvojnih metoda. Da bi se mjerila funkcionalna veličina softverskih aplikacija, četiri
mjerne metode su prepoznate kao standard: IFPUG (International Function Point Users
Group) [11], MK II [12], NESMA (Netherlands Software Metrics Association) [13] i
COSMIC (Common Software Measurement International Consortium) [10] analize
funkcijskih točaka (engl. Function Point Analysis, FPA).
Ove metode su u većini do sada analiziranih radova korištene prilikom mjerenja
funkcionalne veličine završenih aplikacija. Budući da voditelji projekata imaju potrebu za
indikatorima u ranoj fazi razvoja softverskih rješenja, za bolje upravljanje projektima
baziranim na modelu, potrebno je definirati način na koji će mjerni standardi biti primijenjeni
na konceptualne modele.
1.2. Znanstveni doprinosi
Jedan od ciljeva doktorske disertacije bio je da se kreira procedura za dizajniranje modela
podataka, navigacije i procesa web aplikacija kako bi se na osnovi konceptualnih modela
mogao izračunati potreban vremenski okvir za razvoj web aplikacija prije nego je aplikacija
uopće razvijena. Pored toga, bilo je potrebno kreirati pravila pomoću kojih bi bilo moguće
izvršiti preslikavanje izmeĎu konceptualnih modela web aplikacija i COSMIC mjerne metode
za izračun funkcionalne veličine web aplikacija.
3
Kao rezultat istraţivanja nastao je matematički model pomoću kojeg je moguće na osnovi
konceptualnog modela koristeći izračunatu funkcionalnu veličinu web aplikacije predvidjeti
teţinu razvoja same web aplikacije, pri čemu se teţina razvoja izraţava vremenski. Dodatno,
u sklopu disertacije razvijen je i sustav za automatizaciju izračuna teţine razvoja web
aplikacija na osnovi konceptualnog modela. Konceptualni model na osnovu kojeg se provodi
daljnja procedura za izračun potrebnog napora za razvoj web aplikacija razvija se u
odgovarajućem alatu za modeliranje web aplikacija i pohranjuje se u XMI (XML Metadata
Interchange) formatu.
U okviru disertacije predstavljeni su sljedeći znanstveni doprinosi:
Definirana je procedura za kreiranje konceptualnih modela pomoću kojih je moguće
izračunati funkcionalnu veličinu web aplikacija.
Kreirana je mjerna procedura za procjenu funkcionalne veličine web aplikacija na
temelju konceptualnih modela web aplikacija.
Kreiran je matematički model za procjenu teţine razvoja web aplikacija na osnovi
funkcionalne veličine web aplikacija.
Kreiran je prototip alata za automatizaciju procesa računanja funkcionalne veličine
web aplikacija.
Kreiran je prototip alata za automatizaciju procesa izračuna vremena potrebnog za
razvoj web aplikacija.
Mjerna procedura za predviĎanje napora potrebnog za razvoj web aplikacija testirana
je na prethodno dovršenim stvarnim projektima
1.3. Struktura disertacije
Doktorska disertacija je strukturirana kroz devet poglavlja, sa zaključkom i referencama.
Prvo poglavlje čini uvodni dio disertacije, s prezentacijom motivacije i znanstvenog
doprinosa. U drugom poglavlju dat je pregled općih mjernih metoda i metoda baziranih na
funkcijskim točkama za procjenu teţine razvoja softvera, sličnosti i razlike razvoja web
aplikacija i klasičnog softvera, kao i problemi vezani za procjenu napora koji proističu iz tih
razlika. Pregled dosadašnjih istraţivanja iz ovog područja dat je u trećem poglavlju, dok
četvrto poglavlje donosi pregled mjernih procedura za procjenu teţine razvoja web aplikacija.
U petom poglavlju su obraĎene metode koje se koriste za razvoj konceptualnih modela web
aplikacija.
4
Disertacijom je predloţena nova metoda za procjenu teţine razvoja web aplikacija koja se
sastoji od izračuna funkcionalne veličine i procedure za kreiranje konceptualnih modela web
aplikacija, što je prikazano u šestom i sedmom poglavlju.
Osmo poglavlje prikazuje način razvoja modela za procjenu teţine razvoja web aplikacija
na osnovi konceptualnog modela, identifikaciju svih potrebnih elemenata, načine
kombiniranja baznih metoda u svrhu dobivanja ţeljenog modela, kao i prikaz kreiranog
modela, njegovu validaciju i evaluaciju.
U devetom poglavlju prikazan je sustav za automatizaciju izračuna funkcionalne veličine
web aplikacija i automatizaciju izračuna potrebnog napora za razvoj web aplikacija temeljen
na metodi razvijenoj u ovoj disertaciji.
Disertacija završava zaključkom i pregledom citirane literature. Kroz zaključak je dat
rezime disertacije kao i planirana buduća istraţivanja.
5
2. TEHNIKE PROCJENE TEŢINE RAZVOJA SOFTVERA
U ovom poglavlju dat je kratki opis što su to funkcijske točke, kako se one koriste u
području mjerenja softvera kao i pregled nekoliko osnovnih mjernih metoda baziranih na
funkcijskim točkama.
2.1. Funkcijske točke
Za mjerenje veličine softvera postoje dva pristupa [14]: pristup baziran na retcima kôda
(engl. Lines of Code, LOC) i pristup baziran na funkcionalnoj veličini (engl. Functional Size,
FS). Metodu mjerenja veličine softvera, a time i procjenu napora pomoću funkcijskih točaka
(engl. Function Points, FP), razvio je Allan Albrecht u IBM-u 1979. godine [15]. Ova metoda
je bila kreirana kao alternativna mjera u odnosu na brojanje linija koda i više se bavila
funkcionalnošću sustava kao mjerom za odreĎivanje veličine softverskog proizvoda, a samim
time i napora i cijene razvoja proizvoda [16]. Albrechtove funkcijske točke se izračunavaju
brojanjem sljedećih softverskih karakteristika:
1) vanjski ulazi i izlazi (engl. External inputs, External outputs),
2) interakcije korisnika (engl. User interactions),
3) vanjska sučelja (engl. External interfaces) i
4) datoteke koje sustav koristi.
Svaka od ovih karakteristika se pojedinačno procjenjuje zbog sloţenosti te se svakoj od
njih onda dodjeljuje teţišna vrijednost koja moţe varirati od 3 (jednostavna) do 15
(kompleksna). Tijekom vremena uočene su slabosti u Albrechtovoj metodi te su predloţene
nadogradnje odnosnosno modifikacije kao što su IFPUG, COSMIC i MK II.
S obzirom da je IFPUG verzija funkcijskih točaka najbliţa originalnoj verziji i direktni
nasljednik originalnih Albrechtovih funkcijskih točaka, na ovoj metodi se moţe
najjednostavnije opisati suština funkcijskih točaka.
2.2. Mjerne metode
2.2.1. IFPUG
Izračunavanje funkcijskih točaka provodi se kroz nekoliko koraka [11].
6
Prvi korak je identifikacija granice izmeĎu softvera koji se mjeri i korisnika koji je u
interakciji sa softverom koji se mjeri. Ova granica praktično odreĎuje koje su to funkcije koje
će biti uključene u proces brojanja.
Sljedeći korak je brojanje tipova podatkovnih funkcija (engl. Data Function Types, DFT).
Oni predstavljaju funkcionalnost koja je omogućena korisniku da bi se ispunili unutarnji i
vanjski zahtjevi u smislu potrebnih podataka. DFT su klasificirani u sljedeća dva tipa:
unutarnja logička datoteka (engl. Internal Logical File, ILF) i vanjska datoteka sučelja (engl.
External Interface File, EIF). ILF predstavljaju logički povezanu datoteku koju korisnik moţe
identificirati, a koja se u cijelosti nalazi unutar granica softvera koji se mjeri i koji se odrţava
kroz vanjske ulaze. EIF predstavlja logički povezanu datoteku koju korisnik moţe
identificirati a koristi se isključivo za referenciranje. Podaci se nalaze u cijelosti izvan
softvera koji se mjeri i oni se odrţavaju putem drugog softvera. Vanjske datoteke sučelja su
unutarnje logičke datoteke za neku drugu aplikaciju. Ovdje se termin „datoteka― odnosi na
logički povezanu grupu podataka, a ne na fizičku implementaciju tih grupa podataka.
Nakon toga, svakom ILF ili EIF se dodjeljuje funkcionalna kompleksnost na osnovu broja
podatkovnih tipova elemenata (engl. Data Element Type, DET) i tipova zapisa elemenata
(engl. Record Element Type, RET) povezanih sa ILF ili EIF pomoću RET/DET matrice
kompleksnosti (Tablica 2.1).
Tablica 2.1. RET / DET matrica kompleksnosti [11].
RET \ DET 1-9 20-50 >50
1 Nisko Nisko Prosječno
2-5 Nisko Prosječno Visoko
>5 Prosječno Visoko Visoko
Podatkovni tip elementa (DET) je jednoznačno prepoznatljiv od strane korisnika
(podatkovna ili kontrolna informacija) i neponavljajuće je polje. Na primjer, broj nekog
bankovnog računa koji moţe biti smješten u više polja se broji samo kao jedan DET. Tip
zapisa elementa (RET) predstavlja podgrupu podatkovnih elemenata unutar ILF ili EIF a koja
je prepoznatljiva od strane korisnika (podatkovna ili kontrolna informacija).
7
U narednom koraku potrebno je provesti brojanje transakcijskih funkcijskih tipova (engl.
Transactional function types, TFT). Oni predstavljaju funkcionalnost pruţenu korisniku za
obradu podataka od strane aplikacije.
TFT su definirani kao sljedeća tri tipa:
vanjski ulazi (engl. External Inputs, EI),
vanjski izlazi (engl. External Outputs, EO), i
vanjski upiti (engl. External Inquiry, EQ).
Vanjski ulaz (EI) procesira podatke ili kontrolira informaciju koja dolazi izvan granice
sustava koji se mjeri prema unutrašnjosti sustava. Vanjski izlaz (EO) je elementarni proces
koji generira podatkovnu ili kontrolnu informaciju koja je poslana izvan granica sustava koji
se mjeri. Vanjski upit (EQ) je elementarni proces koji je sastavljen od ulazno-izlazne
kombinacije koja kao rezultat generira ili dohvaća podatke. Izlazna strana ne stvara izvedene
podatke. Izvedeni podaci su podaci koji zahtijevaju obradu koja je drugačija od direktnog
dobavljanja ili izmjene informacija od unutarnjih logičkih datoteka (ILF) i/ili vanjskih
datoteka sučelja (EIF). U ovom slučaju se ne odrţava (nema kontinuirano postojanje unutar
nekog perioda vremena tijekom procesiranja) niti jedna unutarnja logička datoteka tijekom
procesiranja niti je izmjenjeno ponašanje sustava.
Nakon toga, svakom EI ili EO potrebno je dodijeliti funkcionalnu kompleksnost bazirano
na broju referenciranih tipova datoteka (engl. File Types Referenced, FTR) i podatkovnih
tipova elemenata (DET). TakoĎer, potrebno je svakom EQ dodijeliti funkcionalnu
kompleksnost na osnovu FTR i DET za svaku ulaznu i izlaznu komponentu. Za svaki EI, EO i
EQ postoji FTR/DET matrica kompleksnosti. Tablica 2.2 prikazuje FTR/DET matricu
kompleksnosti za EI.
Tablica 2.2. FTR/DET matrica kompleksnosti za EI [11].
FTR \ DET 1-4 5-15 >15
0-1 Nisko Nisko Prosječno
2 Nisko Prosječno Visoko
>2 Prosječno Visoko Visoko
Nakon brojanja tipova podatkovnih funkcija (DFT) i brojanja tipova transakcijskih
funkcija (TFT), suma za svaki funkcijski tip se klasificira prema kompleksnosti i teţini
8
korištenjem matrice kompleksnosti. Ukupna suma svih funkcijskih tipova je neprilagoĎeni
broj funkcijskih točaka (engl. Unadjusted Function Count, UFC).
Ukupna suma funkcijskih točaka jednaka je proizvodu UFC s tehničkim faktorom
sloţenosti (engl. Technical Complexity Factor, TCF) koji se sastoji od različitih tehničkih
faktora projekta (kao na primjer faktor koji ima odreĎenu teţinu ako je u pitanju distribuirani
sustav, efikasnost krajnjeg korisnika, ponovna iskoristivost kôda softvera, konkurentnost,
sigurnosne značajke, jednostavnost instalacije, jednostavnost uporabe itd.). Rezultat je
prilagoĎeni broj funkcijskih točaka (engl. Adjusted Function Point Count, AFC) ili
jednostavno nazvano funkcijska veličina. Velika prednost FP-a u odnosu na LOC je da je
dostupan prije početka razvoja.
2.2.2. COSMIC
Mjerna metoda COSMIC se često koristi u različitim procjenama vezanim za softver
(napor i cijena razvoja, procjena veličine aplikacije izraţena u KB, procjena veličine UML
modela itd.) te je odobrena kao ISO standard (ISO/IEC 19761) od oţujka 2003. godine [10].
Ova metoda je originalno bila dizajnirana za potrebe procjene veličine poslovnih sustava i
sustava realnog vremena, ali je takoĎer primjenjiva u bilo kojem drugom kontekstu gdje u
nekom softverskom rješenju dominira veliki broj kretanja podataka, pri čemu se pojam
kretanja odnosi na razmjenu podataka unutar sustava koji se mjeri ili razmjenu podataka
izmeĎu sustava koji se mjeri i njegovog okruţenja [10] [17]. Metoda COSMIC mjeri kretanje
podataka izmeĎu funkcionalnog korisnika i softverskog procesa (aplikacije) ili obratno.
Granica aplikacije je definirana kao konceptualno sučelje (zamišljena linija ili razgraničenje)
izmeĎu softvera (unutarnje aplikacije) koji se mjeri i njegovog funkcionalnog korisnika
(vanjskog korisničkog svijeta). Za primjenu metode COSMIC, potrebno je odvojiti aplikaciju
koja se mjeri od njenog operativnog okruţenja. Potencijal metode COSMIC u fazi definiranja
softverskih zahtjeva u usporedbi s drugim FSM metodama je demonstriran u [18]. COSMIC
se ne oslanja na subjektivne odluke mjeritelja funkcionalne veličine tijekom mjernog procesa.
Stoga različiti mjeritelji uporabom ove metode postiţu iste ili vrlo slične rezultate mjerenja na
osnovu dobro specificiranih zahtjeva [19].
Mjerenje korištenjem metode COSMIC je bazirano na principu da su funkcionalni zahtjevi
korisnika formirani od kolekcije ili skupa funkcionalnih procesa. COSMIC FP naziva
transakciju funkcionalnim procesom, koja je definirana kao „elementarna komponenta koja
predstavlja skup funkcionalnih zahtjeva korisnika koji sadrţi jedinstven, kohezivan i neovisan
9
skup kretanja podataka. Ova transakcija se pokreće aktiviranjem jednog ili više dogaĎaja i
smatra se završenom kada je izvršena do kraja― [10]. Svaki funkcionalni proces je aktiviran
(engl. triggered) od strane korisnika ili iniciran od strane korisnika procesa (engl. actor)
(moţe biti funkcionalni korisnik ili vanjska komponenta) koji se pojavljuju izvan granica
softvera koji se mjeri. Tako inicirani zahtjev uzrokuje kretanje grupe podataka (engl. data
group) koja se moţe sastojati od jednog ili više atributa koji pripadaju toj grupi. Proces je
završen kada je softver obavio sve zadatke koji su bili potrebni u cilju da se odgovori na
zahtijevani dogaĎaj [10].
Metoda COSMIC prepoznaje četiri tipa kretanja podataka: Ulaz (Entry), Izlaz (Exit),
Čitanje (Read) i Pisanje (Write):
Entry - kretanje podataka od funkcionalnih korisnika, preko granice ka funkcionalnom
procesu;
Exit - kretanje podataka od funkcionalnog procesa, preko granice ka funkcionalnom
korisniku;
Read - kretanje podataka od stalnog skladišta podataka ka funkcionalnom procesu;
Write - kretanje podataka od funkcionalnog procesa ka stalnom skladištu podataka;
Svako od ovih kretanja se promatra kao jedna COSMIC-ova funkcionalna točka (engl.
COSMIC Function Point, CFP). Nakon što su svi funkcionalni procesi završeni, mjeritelj
mora sumirati sve CFP-ove u svim funkcionalnim procesima. Ukupna suma predstavlja
veličinu softverske aplikacije izraţena pomoću CFP-ova. Na slici 2.1, prikazan je način
kretanja podataka za sve osnovne elemente metode COSMIC.
10
Slika 2.1. Četiri tipa kretanja podataka i njihove veze s funkcionalnim procesima i
korisnicima [10].
Da bi se primijenila mjerna metoda COSMIC, potrebno je proći kroz tri faze: definiranje
mjerne strategije, preslikavanje i mjerenje [10]. Nakon toga, moguće je izračunati
funkcionalnu veličinu softvera i izračunati broj CFP-ova za projekt. Za funkcionalni proces i,
ukupna funkcionalna veličina je izračunata kao suma svih kretanja podataka koji se pojavljuju
u tom procesu:
Size (FPi) = numberOf(Entriesi)+ numberOf(Exitsi)+ numberOf(Readsi)+
numberOf(Writesi) (2.1)
Veličina kompletne softverske aplikacije u obliku COMSIC funkcionalne veličine je suma
svih funkcionalnih procesa koji se pojavljuju u mjerenoj softverskoj aplikaciji:
Size(software) = Size(FPi) (2.2)
2.2.1. MK II
Metodu MK II FPA je razvio Charles Symons 1988. godine da bi riješio nedostatke
osnovne metode FPA [18] [20]. Korisnički zahtjevi softvera se identificiraju i svaki od njih je
11
kategoriziran u jednu od sljedećih skupina: ulazi (engl. inputs), izlazi (engl. exits) i objekti
(engl. objects). Da bi se izmjerila funkcionalna veličina sustava, broje se prethodno navedeni
funkcionalni zahtjevi.
Procedura brojanja sadrţi nekoliko koraka:
UtvrĎivanje točke gledišta (engl. View Point), namjene i tipa brojanja,
Definiranje granice unutar koje se vrši brojanje; Granica sustava predstavlja logičku
liniju koja odvaja korisnike od sustava. Koristi se kako bi se utvrdile logičke
transakcije kao što su ulazi i izlazi koji prelaze granicu sustava tijekom interakcije
izmeĎu korisnika i sustava;
Identifikacija logičkih transakcija; Svaka transakcija se broji samo jednom iako se
ona moţe izvršavati na više od jednog mjesta unutar aplikacije koja se mjeri;
Identifikacija i kategorizacija tipova podatkovnih entiteta (engl. Data Entity Types);
Tipovi podatkovnih entiteta su logičke podatkovne strukture koje sadrţe
informacije koje su značajne za korisnika. U metodi MK II FPA postoji samo jedan
tip podatkovnih entiteta, a to su objekti. Objekti moraju biti točno identificirani
kako bi mogli biti brojani.
Brojanje tipova elemenata ulaznih podataka (engl. Input Data Element Types),
brojanje referenciranih tipova podatkovnih entiteta (engl. Data Entity Types
Referenced) i brojanje izlaznih tipova podatkovnih elemenata (engl. Output Data
Element Types).
Izračun funkcionalne veličine: Jednom kada su transakcije i objekti u sustavu
identificirani, oni se mogu brojati u cilju izračunavanja funkcionalne veličine
sustava. Funkcionalna veličina sustava predstavljena je kao teţinski odreĎene
ulazno/izlazne transakcije i objekti unutar granice sustava.
Veličina se moţe izraziti kao [12]:
Size = Wi Ni + We Ne +Wo No (2.3)
Sume predstavljene u prethodnoj jednadţbi su ukupni broj jedinstvenih ulaza, izlaza i
objekata mjerenog sustava. Trenutno preporučene vrijednosti su Wi=0,58, We=1,66 i Wo=0,26
[12].
Ova metoda je takoĎer dizajnirana za potrebe mjerenja informacijskih sustava. Metoda
moţe biti primijenjena i u drugim područjima kao što su znanstveni i softveri stvarnog
12
vremena (engl. real-time) s nekim modifikacijama. MK II FPA je odobrena kao zvanična
metoda obzirom da je usuglašena s ISO/IEC 14143 i postala je meĎunarodni ISO standard
2002. godine [12].
2.2.2. NESMA
Holandska asocijacija korisnika metrike softvera (Netherlands Software Metrics Users
Association, NESMA) objavila je prvu verziju Definicija i Pravila brojanja za uporabu i
primjenu kod analize funkcijskih točaka 1990.godine [18]. Ova metoda je takoĎer bazirana na
principu rada metode IFPUG FPA. Razlika je u tome da ova metoda daje konkretnija pravila
za uporabu, natuknice i primjere [21]. NESMA FPA je odobrena od strane ISO i postala je
meĎunarodni standard 2005.godine [22].
2.3. Općenita podjela tehnika za procjene teţine razvoja softvera
U literaturi postoji velik broj različitih tehnika za procjenu teţine razvoja softvera koje su
predloţene od strane istraţivača u posljednjih 30 godina u području softverskog inţenjerstva
[23] [24].
Na osnovi analize ovih tehnika, mogu se razlučiti tri osnovne kategorije [25]:
1. Procjena stručnjaka (engl. Expert Judgement) je tehnika koja koristi znanje eksperta,
njegovo mišljenje i iskustvo da bi generirala procjenu za neki softverski proizvod. Ove
metode nemaju točno utvrĎenu proceduru za provoĎenje postupka procjene teţine
razvoja te stoga i nisu ponovljive [23].
2. Algoritamski modeli (engl. Algorithmic Models) su prema [23] jedna od
najpopularnijih metoda kojima se uspostavlja veza izmeĎu potrebnog napora za razvoj
softverskog proizvoda i jedne ili više karakteristika projekta, kao što su primjerice broj
linija izvornog koda, broj stranica, broj poveznica i slično. Primjeri algoritamskih
modela su COCOMO, SLIM i Function Points (FP) [23].
3. Strojno učenje (engl. Machine Learning) je tehnika bazirana na umjetnoj inteligenciji
(engl. Artificial Intelligence) koja se koristi kao alternativa tehnikama procjene
stručnjaka i algoritamskim modelima. Neizrazita logika (engl. fuzzy logic), neuronske
mreţe (engl. neural networks), regresijska stabla (engl. regression trees) i
zaključivanje temeljeno na slučaju (engl. case-based reasoning, CBR) su primjeri
strojnog učenja [23].
13
2.3.1. Procjena stručnjaka
Procjena na bazi ocjene stručnjaka uključuje izradu predviĎanja temeljeno na vještini i
iskustvu jednog ili više stručnjaka. Ova metoda nije visoko cijenjena u istraţivačkoj zajednici
zato što se smatra da je predmet predrasuda i jako ovisi o kvalifikaciji i iskustvu stručnjaka.
Hannond i suradnici [26] tvrde da se pokazalo da iskustvo nije povezano s empirijskom
točnosti stručne prosudbe nego je takoĎer opisano i kao nagaĎanje [27]. Ruhe i suradnici [28]
su predloţili pristup za procjenu troškova web aplikacija istraţivanjem primjene metode
COBRA (engl. Cost Estimation, Benchmarking, and Risk Assessment) [29].
Metoda COBRA je hibridna metoda koja kombinira dva pristupa: pristup baziran na
postojećim podacima i pristup baziran na procjeni stručnjaka. Kod ove metode, faktori troška
(engl. cost drives) su identificirani i kvantificirani unutar sistematičnog procesa korištenjem
procjene stručnjaka, dok je informacija o osnovnoj produktivnosti dobivena od malog skupa
postojećih projekata. Ova metoda omogućava iskorištenje prednosti pristupa baziranih na
podacima (sustavno, transparentni modeli procjene troška) dok je potrebna jako mala količina
podataka o projektima i stoga je primjenjiva u većini industrijskih okruţenja. COBRA je
uspješno primijenjena nekoliko puta u različitim razvojnim okruţenjima [29][30][31].
U ranijim verzijama, COBRA je kao mjeru veličine koristila broj linija koda (engl. Lines of
Code, LOC), što nije bilo primjereno za procjenu web razvoja, jer je podatak o linijama koda
dostupan tek na kraju projekta te je vrlo teško predvidjeti broj linija koda za web aplikacije na
početku razvoja. Nadalje, web aplikacije obično u svom razvoju uključuju i po nekoliko
različitih programskih jezika i aplikacija koje mogu dodatno oteţati procjenu troškova na bazi
broja linija koda.
2.3.2. Algoritamski modeli
Algoritamski modeli predviĎaju tj. procjenjuju potrebni napor uz pomoć parametarskih
jednadţbi. Korišteni modeli su obično nastali iz analize statističkih podataka. Primjeri
ovakvih modela su regresija običnom metodom najmanjih kvadrata (engl. Ordinary Least
Square, OLS) [32], konstruktivni model troška (engl. Constructive Cost Model, COCOMO) i
klasifikacijska i regresijska stabla (engl. Classification and Regression Trees, CART) [17].
Najpopularniji algoritamski model je COCOMO, predstavljen od strane Barry Boehma
1981. godine [33]. Ovaj model uzima u obzir tri vrste projekata: organske (engl. organic),
dvojne (engl. semi-detached) i ugraĎene (engl. embedded). Organski sustavi su u osnovi
sustavi za procesiranje podataka, dok ugraĎeni sustavi odgovaraju sustavima stvarnog
14
vremena. Dvojni sustavi kombiniraju elemente oba prethodna sustava. Ovakav model je
takoĎer poznat kao osnovni COCOMO model. Osnovni problem s ovim modelom je taj da je
voĎen varijantama metode s brojanjem redaka koda (LOC). S obzirom da je podatak o broju
linija koda dostupan samo na kraju projekta, a voditelji projekta trebaju napraviti procjenu
projekta na njegovom samom početku, uporaba ovog modela oteţava cjelokupni proces
procjene potrebnog napora za razvoj softverskog produkta. Ova slabost je uklonjena
predstavljanjem modela COCOMO II 1990. godine, koji procjenjuje veličinu projekta na
osnovi specifikacije projekta [34]. Obje ove tehnike vrše procjenu uloţenog napora
korištenjem statističkih tehnika baziranih na eksponencijalnim formulama prilagoĎenim uz
pomoć regresijskih tehnika [35].
Donald J. Reifer je uveo mjernu metriku za web aplikacije pod nazivom Web objekti (engl.
Web Objects), što je proširenje tehnike brojanja funkcijskih točaka [36], [37]. Web objekti se
sastoje od istih elemenata kao i funkcijske točke zajedno s još četiri webu srodne komponente,
kao što su (I) multimedijske datoteke; (II) web gradivni blokovi; (III) skripte; i (IV) veze.
Svaku komponentu Web objekata treba računati i kategorizirati kao komponentu niske,
prosječne ili visoke sloţenosti. Rezultati usporedbe izmeĎu funkcijskih točaka i Web objekata
za dimenzioniranje mjere pokazuju da se točnija procjena napora dobiva korištenjem Web
objekata. Web objekti se detaljnije obraĎuju u poglavlju 4.2.
Reifer je razvio radni list pod nazivom „Web Objects Calculation Worksheet― u kojem je
naveo Web objekte prema sloţenosti teţine (niska, prosječna ili visoka). Radni list i metrike
za procjenu veličine za mjerenja postale su prvi korak u razvoju modela koji točno procjenjuje
troškove i optimalan raspored za izradu web aplikacija. Reifer je takoĎer razvio i model
WebMo [37] pomoću stručnih prosudbi i na osnovu podataka iz 46 projekata gdje je koristio
regresijsku analizu. Analiza Web objekata pokazuje da mjerenja kojima se utvrĎuje teţina
razvoja svakog od identificiranih Web objekata imaju mnoge prednosti kod procjene troškova
razvoja web aplikacija u odnosu na tradicionalno mjerenje broja linija izvornog koda i u
odnosu na brojanje funkcijskih točaka. Reifer je razvio konvencije za računanje i potvrdio da
Web objekti imaju bolju točnost predviĎanja od tradicionalnih funkcijskih točaka.
Ruhe i suradnici [24] su nastavili ovo istraţivanje i usredotočili se na korištenje Web
objekata pri procjeni napora za razvoj web aplikacija. U svom radu su istraţivali primjenjivost
Web objekata kao mjerne veličine u usporedbi s tradicionalnim funkcijskim točkama. Njihovi
rezultati, temeljeni na web aplikacijama u kontekstu industrijskog skupa podataka, pokazuju
da je procjena izvedena korištenjem Web objekata značajno nadmašila modele koji koriste
funkcijske točke [38].
15
Rollo [39] je uveo različite mjere poznate kao potpune funkcijske točke (engl. Full
Function Points, FFP), ali te mjere nisu bile podvrgnute punoj empirijskoj evaluaciji. FFP je
funkcijska mjera temeljena na standardnim FP tehnikama. FFP tipovi transakcijskih funkcija
su identificirani na podrazini procesa, umjesto na razini procesa kao što je učinjeno s
tradicionalnim FP.
Novi model za procjenu troškova web aplikacija uveli su Mangia i Paiano, poznat kao
metrički model za web aplikacije (engl. Metric Model for Web Application, MMWA) [40].
MMWA mjerenje predstavlja rješenje problema za procjenu troškova razvoja i veličinu
projekta uzimanjem u obzir svih čimbenika sloţenosti u razvoju web aplikacija.
Prednost ovog modela, za razliku od rane verzije modela COCOMO, a ujedno i modela
COCOMO II jest da je neovisan od broja linija izvornog koda softvera i ujedno ne zavisi od
logike programera.
2.3.3. Strojno učenje
Strojno učenje se temelji na tehnikama računalne inteligencije poput umjetnih neuronskih
mreţa, genetičkih algoritama i analognih pristupa poput zaključivanja baziranih na slučaju
(engl. Case Based Reasoning, CBR). Oni su razvijeni kako bi se izbjegli nedostaci prethodno
prikazanih tehnika (Web objekti, COCOMO II, FP i druge). Glavni fokus strojnog učenja je
automatski naučiti kako prepoznati sloţene obrasce koji postoje i napraviti pametne odluke na
temelju podataka.
Genetički algoritmi (GA) su vrsta tehnike evolucijskog računanja. Ova tehnika daje opću
strukturu za rješavanje problema, koja oponaša biološku paradigmu „opstanka najjačih― [41].
Istraţivanje provedeno od strane Dolado [42] pokazalo je obećavajuće rezultate za GA na
temelju sustava procjene s jednom ulaznom varijablom.
Neuronska mreţa (eng. Neural Network, NN) je računalni sustav koji simulira proces
učenja ljudskog mozga. NN su masivni paralelni sustavi inspirirani na bazi arhitekture
biološke neuronske mreţe, koje sadrţe jednostavne meĎusobno povezane cjeline (umjetnih
neurona). Neuroni izračunavaju teţinski zbroj njihovih unosa i generiraju izlaz. Ako je zbroj
veći od odreĎene vrijednosti tolerancije, ovaj izlaz tada postaje jedan uzbudljivi (pozitivan) ili
inhibitorni (negativan) ulaz drugih neurona u mreţi. Proces se nastavlja sve dok se ne generira
jedan ili više izlaza [43]. NN se naširoko koristi u mnogim industrijskim područjima,
uključujući procjenu napora za razvoj softvera. Primjenjivost NN u području procjene napora
za razvoj softvera su opseţno proučavani u radovima [43], [44]. Srinivasan i Fisher [45]
16
istaknuli su da je pristup s izvedbom neuralnih mreţa bio vrlo osjetljiv na konfiguraciju
izbora, kao što je broj skrivenih umjetnih jedinica-neurona (engl. artificial hidden units-
neurons), zaustavni kriterij i početne postavke teţine. Odgovarajuće postavke ovih izbora
mogu se odrediti samo empirijski.
Neizrazita logika (engl. Fuzzy Logic, FL) je čvrsto utemeljena u smislu njenih teorijskih
temelja i aplikacija u raznim područjima u kojima se koristi, kao što su robotika, medicina i
obrada slike. FL sustavi korišteni su u samo nekoliko radova za razvoj modela za procjenu
teţine razvoja softvera [46]. FL sustav polazi od toga da se prilikom opisa činjenica i
zaključivanja sluţi jezikom koji je neprecizan, kao na primjer „dobro plaćeni stručnjak―,
„tvrtka srednje veličine―, „vrlo mala snaga―, itd. Ulaz u FL sustav moţe biti numerička ili
jezična vrijednost, s istom primjenom na izlaz iz sustava. Najočitija snaga FL sustava je ta da
se pomoću jezičnih preslikavanja moţe kreirati vrlo intuitivan model koji moţe razumjeti bilo
tko, čak i bez treninga. Negativna strana FL sustava je da pate od nekih ograničenja,
uključujući poteškoće specificiranja sustava s vrlo visokom točnošću pri tome zadrţavajući
visok stupanj smislenosti. „Općenito više točnosti zahtijeva više pravila, a veći broj pravila
vodi do veće kompleksnosti i manje mogućnosti za interpretaciju sustava― [47].
Metoda analogije uključuje usporedbu jednog ili više završenih projekata s detaljima
novog projekta u cilju predviĎanja troškova i trajanja realizacije. Glavni problem s ovom
tehnikom je što zahtijeva skup podataka o već završenim projektima s kojima se usporeĎuje
novi projekt. Metoda bazirana na pristupu analogijom koja je najviše istraţena u svezi s
problemima troškova predviĎanja jest zaključivanje bazirano na slučaju (engl. Case Based
Reasoning, CBR). CBR se zbog ideja formaliziranja procesa predviĎanja analogijom smatra
atraktivnim [48]. Studija na gotovo 600 organizacija je pokazala da je analogija najraširenija
metoda procjene u softverskoj industriji [49]. Procjena napora temeljena na analogiji takoĎer
je opseţno istraţena i primijenjena, zbog svoje jednostavnosti i konceptualno empirijske
konkurentnosti. U stvarnosti ne postoji niti jedan najbolji model za procjenu troškova razvoja
softvera, ali CBR je ocijenjena meĎu najboljim metodama u različitim okolnostima [24].
CBR je pristup baziran na umjetnoj inteligenciji čija je osnovna ideja da rasuĎivanje o
novom projektu moţe biti učinjeno na osnovi iskustva ili ideja prethodnih projekata radije
nego da se kreće od samog početka, jer se uvidom u korištenje podataka o prethodnim
projektima i njihovom rješavanju mogu umanjiti i izbjeći poznate greške te se moţe doći do
rješenja na usmjeren način [50].
17
2.4. Mjere točnosti za kreirane modele za procjenu teţine razvoja softvera
Korištenjem tehnika za kreiranje modela u svrhu predviĎanja uloţenog napora za razvoj
web aplikacija javljaju se i neki problemi naročito kada je u pitanju validacija dobivenih
rezultata. Naime, prema [51] ako se za izračun točnosti koristi isti skup podataka kao i za
kreiranje modela za predviĎanje, procjena točnosti će biti optimistična. Da bi se izbjegao ovaj
problem, razvijen je veliki broj tehnika unakrsne validacije (engl. cross-validation) koji je
primijenjen od strane različitih autora u literaturi. Unakrsna validacija je uobičajeni način za
validaciju modela za procjenu cijene i napora potrebnog za razvoj web aplikacija. Osnovna
ideja ovog pristupa je da se skup podataka za kreiranje modela (skup podataka za učenje) i
skup podataka za evaluaciju modela (skup podataka za testiranje) razlikuju [24]. Za ocjenu
prihvatljivosti i točnosti predikcije modela, razvijen je veliki broj statističkih tehnika.
Neke od najpopularnijih tehnika, navedenih u [52] su:
Magnituda relativne pogreške (engl. Magnitude of Relative Error, MRE) [53].
Srednja magnituda relativne pogreške (engl. Mean Magnitude of Relative Error,
MMRE) [25].
Medijan magnitude relativne pogreške (engl. Median Magnitude of Relative Error,
MdMRE) [54].
Predikcija na razini n (engl. Prediction at level n, Pred(n)) [55] (Postotak predviĎene
vrijednosti koji je unutar 25% stvarne vrijednosti).
U nekim studijama, korišteni su i dijagrami pravokutnika apsolutnih ostataka (engl.
boxplots of absolute residuals) (stvarni napor – procijenjeni napor, engl. actual effort-
estimate) i dijagrami pravokutnika od z (procijenjeni napor / stvarni napor) kao mjere za
validaciju kreiranih modela. Kitchenham i suradnici [56] su kritizirali MMRE na osnovu
konstatacije da je ona u suštini mjera raširenosti (disperzije) od z (z = procijenjeno/stvarno)
prije nego što je mjera točnosti i predloţili su da dijagrami pravokutnika ostataka i dijagrami
pravokutnika od z predstavljaju bolju alternativu ili dopunu za sumarnu statistiku. Kao
rezultat njihove konstatacije, sada dosta istraţivača uključuje dijagrame pravokutnika u svoje
rezultate istraţivanja.
18
2.5. Sličnosti i razlike klasičnog softvera i web aplikacija
Reifer je kroz svoj članak [36] ukazao na neke različitosti izmeĎu klasičnog softvera i web
aplikacija kada je u pitanju područje procjene teţine razvoja softvera. Prema Reiferu, ako se
ţeli klasične metode prilagoĎavati novim metrikama onda onaj tko razvija nove metrike
vezane za web procjenu troška izrade web aplikacija, treba imati na umu neke različitosti
izmeĎu web aplikacija i klasičnih softverskih aplikacija. Neke od karakteristika tradicionalnih
u odnosu na web aplikacije kao i sam razvoj su prikazani u tablici 2.3 dok tablica 2.4
prikazuje neke posebne izazove s kojima se suočavaju procjenitelji web aplikacija [36], [37].
Iz tablice 2.3 i 2.4 moţe se izvesti zaključak da je glavni izazov izmeĎu procjena klasičnog
softvera i web aplikacija vrijeme potrebno za njihov razvoj. Iako je moguće da trenutni
trendovi u razvoju softvera mogu uzrokovati drugačije vrijednosti, tablica 2.3 je prenesena iz
Reifer [36] bez intervencija. Kod razvoja web aplikacija se obično postavlja zahtjev za kraćim
vremenom potrebnim za razvoj, implementaciju i isporuku na trţište gotovog proizvoda u
odnosu na klasični softver. Stoga, mnogo je više izazova koje je potrebno uspješno savladati
da bi se u konačnici proizveo kvalitetan softver. Mjere veličine softvera, koje su bile većinom
korištene kod klasičnog razvoja, nisu više primjenjive za web razvoj jer sam web razvoj
zahtijeva predloške i neke specifične elemente web aplikacija (slike, audio zapisi, ActiveX
kontrole, Java skripte, animacije, apleti, skripte za povezivanje html/xml podataka itd.).
Funkcionalnost, pouzdanost pa čak i portabilnost su relevantni kako za web sustave tako i za
tradicionalne softverske sustave.
Tablica 2.3. Karakteristike tradicionalnog u odnosu na web razvoj [36], [37].
Karakteristike Tradicionalni razvoj Web razvoj
Primarni cilj Izrada kvalitetnog
softverskog proizvoda s
minimalnim troškom
Izrada kvalitetnih proizvoda i
njihov plasman na trţište što je
prije moguće
Tipična veličina
projekta
Srednji do veliki (stotine
članova tima)
Mali (3-5 članova tima)
Tipično vremensko
ograničenje
12-18 mjeseci 3-6 mjeseci
Korišteni razvojni
pristup
Klasičan, baziran na
zahtjevima, isporuka po
Brzi razvoj aplikacija (RAD),
sklapanje više završenih objekata u
19
fazama ili inkrementalno,
slučajevi korištenja, baziran
na dokumentaciji
jednu cjelinu, prototipiranje,
Rational Unified Process, MBASE
Primarno korištene
inţenjerske tehnologije
Objektno orijentirana
metode, generatori, moderni
programski jezici (C++),
CASE alati, itd.
Komponentno-bazirane metode,
četvrte i pete generacije
programskih jezika (HTML, Java,
itd.), vizualizacija (pokreti,
animacije), itd.
Korišteni proces CMM-baziran Ad-hoc
Razvijeni proizvodi Sustav baziran na kodu,
većinom novi, neki ponovno
iskorišteni, mnogo vanjskih
sučelja, često kompleksni
Objektno bazirani sustavi, mnogo
ponovo iskoristivih komponenti
(dijelovi sustava za on-line
kupovinu, itd.), nekoliko vanjskih
sučelja, relativno jednostavni
Uključeni ljudi Profesionalni softverski
inţenjeri s velikim
iskustvom
Grafički dizajneri, manje iskusni
softverski inţenjeri1
Korištena tehnologija
estimacije
SLOC ili modeli bazirani na
funkcionalnim točkama,
WBS pristup za male
projekte
„Wing it― - Improvizacija
Tablica 2.4. Izazovi procjene web projekata [36], [37].
Tradicionalni pristup Izazovi web-a
Proces procjene Većina koristi analogiju
dopunjenu prethodnim
iskustvima
Trošak posla je većinom procijenjen
ad-hoc na osnovu podataka
dobivenih od programera (obično
previše optimistično)
Procjena veličine Sustavi su izgraĎeni na
osnovi zahtjeva, SLOC ili
Aplikacije su napravljene
korištenjem predloţaka i uz pomoć
1 Tvrdnja je prenesena bez intervencija iako je moguće da se uslijed trendova promijeni.
20
funkcijske točke su
korištene
varijacija web-baziranih objekata
(HTML, apleti, komponente,
gradivni blokovi). Ne postoji
dogovor vezano za to koju mjeru
veličine za Web aplikacije koristiti u
istraţivačkoj zajednici
Procjena napora Potrebni napor je
procijenjen uz pomoć
regresijskih formula
modificiranih s faktorima
troškova (iscrtavanje
podataka od projekata na
dijagramima i utvrĎivanje
veza izmeĎu varijabli)
Procjena napora je uraĎena podjelom
posla u zadatke i identifikacijom što
je potrebno uraditi da se posao
obavi. Malo povijesnih informacija o
projektima je dostupno.
Procjena potrebnog
vremena za izvršenje
aktivnosti
Procjena potrebnog vremena
je dobivena kao treći korijen
potrebnog napora.
Modeli obično procjenjuju potrebno
vrijeme kao visoko jer u ovom
slučaju treći korijen potrebnog
napora nije dosljedan2 (ne drţi
vezu).
Procjena kvaliteta Kvaliteta je mjerljiva iz
unutarnjih mjerenih
podataka sustava kao što su
podaci o defektima i
svojstvima sustava.
Kvalitetu je teško mjeriti. Nove
metrike su potrebne da bi se
ocijenila kvaliteta multimedijalnih
elemenata.
Kalibracija modela Mjerenja iz prethodno
završenih projekata se
koriste za kalibraciju
modela za procjenu
potrebnog napora i
poboljšavanje točnosti.
Mjerenja iz prošlih projekata se
koriste za identifikaciju znanja i
činjenica (jako mali broj postojećih
da bi bili korisni)
2 Prema tvrdnjama autora iz [36], [37] testovi nad WEBMO modelu procjene su pokazali da formula korištena u
tom modelu nije primjenjiva za veće web aplikacije.
21
„Što ako“ analiza Procjena modela se koristi
za izvoĎenje kvantitativne
„što ako (what if)― i analize
rizika.
Većina „što ako― i analiza rizika je
kvalitativna zato što modeli ne
postoje. ROI (Return On Investment)
i odnos trošak/prednosti za e-
poslovne aplikacije ostaju otvoreni
izazov.
Procjena cijene se često poistovjećuje s procjenom napora potrebnog za razvoj nekog
softverskog proizvoda. Ipak, ova dva termina nisu sinonimi. Cijena projekta uključuje trošak
ljudi uključenih u razvoj projekta i uloţeni napor je obično dominantni trošak, ali cijena
razvoja projekta moţe uključivati i druge faktore koji nisu direktno vezani za sam proizvod,
kao što su primjerice licenciranje, putovanja, obuka korisnika, posluţitelji za smještanje
aplikacije itd. Napor uloţen u razvoj neke aplikacije moţe se dobiti ili izračunati
parametarskim jednadţbama (linearne, kvadratne, regresijske itd.), prethodnim iskustvom ili
procjenom eksperta.
22
3. VEZANA ISTRAŢIVANJA
U proteklih nekoliko godina predloţeno je nekoliko mjera za procjenu veličine web
aplikacija, budţeta i cijene projekata [23], [40], [57]–[59]. Unatoč tome, ne postoje široko
prihvaćene mjerne metode u praktičnoj primjeni za procjenu veličine web aplikacija. Vjeruje
se da mjere bazirane na funkcionalnoj veličini mogu pruţiti dobro rješenje u domeni problema
procjene veličine web aplikacija iz sljedećih razloga [2]:
bazirane su na funkcionalnosti koja će biti pruţena krajnjem korisniku, a ne na
artefaktima (produktima završene aplikacije) kao što su primjerice broj web stranica,
broj multimedijalnih datoteka itd,
neovisne su od primijenjene tehnologije ili programskog jezika [60],
mogu biti mjerene u ranoj fazi procesa razvoja web aplikacije dok broj linija kôda
zavisi od programskog jezika kojim se razvija aplikacija i obično je broj dostupan tek
na kraju razvoja,
bazirane su na standardima koji definiraju koncept veličine i zahtjeve za potrebe
procjene veličine aplikacija,
imaju široku prihvaćenost u praksi.
Prvi pokušaj da se primijene mjere funkcionalne veličine na web aplikacije bile su
smjernice predloţene od strane IFPUG-a. MeĎutim, istraţivači tvrtke Total Metrics [61] su
izjavili da ove smjernice nisu riješile mnoge probleme vezane za brojanje funkcijskih točaka
kada se primjenjuju na web aplikacije. Osim toga, istraţivači u radu [62] su predloţili
interpretaciju za IFPUG-ove smjernice i objasnili kako se metoda analize funkcijskih točaka
(engl. Function Point Analysis, FPA) moţe primijeniti na web aplikacije. Rollo [63] je
takoĎer ukazao na neke od problema kada se mjerenje web aplikacija vrši koristeći FPA, kao
što je problem u identificiranju granica sustava i njegovih logičkih zapisa. Rollo [63] je tvrdio
da je metoda COSMIC pogodnija za brojanje funkcijskih točaka zbog jednostavnosti primjene
mjernih pravila COSMIC-a u slučaju web aplikacija. Široko prihvaćene mjere funkcionalne
veličine (engl. Functional Size Measures, FSM) kao što su IFPUG, FPA i COSMIC imaju
neka bitna ograničenja. Prvi problem je taj što primjena mjernih pravila zahtijeva ljudsku
interpretaciju klasificiranja i brojanja funkcionalnih točaka (na primjer, nije uvijek jasno kako
svaki element funkcionalnih zahtjeva treba biti klasificiran i brojan), pa je potreban ekspert za
primjenu metode. Drugi problem je što niti jedna od ISO standardiziranih FSM metoda nije
dizajnirana tako da uzima u obzir posebne osobine web aplikacija. Da bi se riješila ova
23
ograničenja, deset mjernih procedura za web aplikacije je predloţeno u posljednjih nekoliko
godina. Od ovih mjernih procedura, četiri su predloţene od strane profesionalaca: IFPUG-ove
smjernice za web aplikacije [2], Web-points [64], Web objects [36], Internet points [65].
Ostalih šest je predloţeno od strane istraţivača: OOmFPWeb (OO-Method Function Points
for the Web) [62], Data Web Points [66], Cândido and Sanchez [14], Costagliola i suradnici
[9], Fraternali i suradnici [67] i OO-HFP (Object-Oriented Hypermedia Function Points)
[68]. Većina prethodno navedenih mjernih procedura baziranih na metodi COSMIC koristila
je starije verzije priručnika za izračun COSMIC-ovih funkcijskih točaka (engl. Cosmic
Function Points, CFP). TakoĎer, ove metode nisu imale dizajnirane mjerne procedure što je
jedan od vaţnijih elemenata kada se kreira sama mjerna metoda. Većina ovih metoda nema
kreirane alate za automatizaciju procesa izračunavanja CFP-ova već se proces obavlja
isključivo uz pomoć stručnjaka iz ovog područja. Automatizacija procesa izračunavanja CFP-
ova je jedna od glavnih pretpostavki da se izbjegne mogućnost pogrešaka u procesu
izračunavanja CFP-ova kao i da se subjektivnost ili iskustvo mjeritelja odbaci kao potencijalni
uzrok pogreške u cjelokupnom procesu.
Za potrebe modeliranja web aplikacija do sada je razvijeno više metoda od kojih se mogu
izdvojiti sljedeće: OOHDM [69], WebML [5], OO-H [6], W2000 [70] i UWE [71].
Svaka od ovih metoda ima svoje prednosti i nedostatke. MeĎutim, glavni cilj metoda za
modeliranje web aplikacija u kontekstu procjene teţine njihovog razvoja treba biti
jednostavnost primjene, dostupnost literature, egzaktni primjeri upotrebe i područje primjene.
Svaka od metoda ima svoje odreĎeno područje primjene, a veći broj je razvijen u okviru
raznih projekata tako da su testne skupine korisnika koje su testirale upotrebljivost ovih
metoda veoma ograničene. Većina predloţenih metoda koristi notacije, simbole i elemente za
modeliranje koji nisu u standardnoj upotrebi kod većine programera softvera. Jedna od
metoda čija je notacija i elementi koji se koriste u razvoju bazirani na jeziku za modeliranje
UML je UWE metoda. Zbog ove činjenice, ova metoda ima komparativnu prednost nad
ostalim metodama.
Usprkos tome, u kontekstu procjene teţine razvoja web aplikacija u vezi s razvojem
zasnovanom na modelu, problem procjene teţine razvoja web aplikacija na osnovi
konceptualnog modela [2] i dalje ostaje neriješen.
U radu prezentiranom od strane Azhar i suradnika [72], autori su istraţili veliki broj studija
u području procjene potrebnih resursa za web aplikacije. Prema trenutno dostupnoj literaturi,
ovi autori su napravili jednu od najvećih studija kada je u pitanju procjena potrebnih resursa
za razvoj web aplikacija. Interesantna činjenica koja je proizašla iz ove studije je ta da ni
24
jedna od analiziranih studija nije dala prijedloge ili upute kada primijeniti neki scenario za
procjenu teţine razvoja web aplikacija u odreĎenim slučajevima. TakoĎer, izveden je
zaključak da ne postoji univerzalna i jedinstvena metoda kada je u pitanju procjena teţine
razvoja web aplikacija. U dostupnoj literaturi postoji relativno mali broj članaka koji istraţuju
procjenu teţine razvoja web aplikacija na bazi konceptualnih modela u ranoj fazi razvoja web
aplikacija [72]. Studije većinom istraţuju ovu tematiku po segmentima, primjerice samo
procjena veličine softverskih aplikacija bez direktne ili indirektne uključenosti procjene teţine
razvoja. S druge strane, postoje članci koji istraţuju samo veličinu softverskih aplikacija na
osnovi funkcionalne veličine modela (npr. IFPUG, COSMIC) [2], [73]. U radu Marín i
suradnika [73] dat je pregled postojećih mjernih procedura baziranih na COSMIC metodi za
izračun funkcionalne veličine softverskih aplikacija. MeĎutim, veći broj analiziranih metoda u
tom članku je koristio stara COSMIC-ova mjerna pravila koja nisu bila u cijelosti usklaĎena s
novim trendovima razvoja softvera i web aplikacija. U studijama Costagliola i suradnika [9],
Abrahão i suradnika [2], Marín i suradnika [73] i Čeke i suradnika [17], autori su kreirali i
predloţili neke dobre smjernice kako provesti mjerenje veličine web aplikacija, a samim time
i indirektno omogućiti jednostavniju i točniju procjenu teţine razvoja web aplikacija.
U studiji Abrahão i suradnika [2] autori su napravili kratak pregled studija koje se bave
procjenom teţine razvoja web aplikacija. Na osnovi te studije moguće je zaključiti da je
područje procjene teţine razvoja web aplikacija jako raširena kroz različite procedure,
identifikaciju različitih objekata, različitih skupova testnih podataka koji dolaze iz različitih
izvora i različitih grupa razvojnih inţenjera s različitim iskustvom, od studenata do
profesionalnih programera. Na osnovu ovih činjenica zaključuje se da je teško definirati
operatore usporedbe za egzaktnu komparaciju izmeĎu dostupnih procedura i mjernih metoda
jer je svaka od njih kreirana za odreĎenu vrstu web aplikacija.
3.1. Pregled najzastupljenijih tehnika procjena teţine razvoja web aplikacija
Na osnovu analize literature i dostupnih studija u kojima je napravljena kompletna analiza
dosadašnjih istraţivanja u području procjene teţine razvoja web aplikacija [72], [74] nameće
se zaključak da trenutno postoji jako veliki broj web metrika i skupova podataka na osnovu
kojih su metrike proizašle, kao i tehnika modeliranja koje su nastale na bazi tradicionalnih
metoda za procjenu teţine razvoja web aplikacija. Neke od najčešće zastupljenih tehnika na
osnovi kojih su nastale nove metode su: zaključivanje bazirano na slučaju (engl. Case based
reasoning, CBR), postupna regresija (engl. Stepwise regression), linearna regresija (engl.
25
Linear regression), Bayesova mreţa (engl. Bayesian networks), klasifikacijska i regresijska
stabla (engl. Classification and regression trees, CART), metoda vektora potpore regresije
(engl. Support vector regression, SVR), procjena stručnjaka (engl. Expert judgment), Web-
COBRA, posebno kreirana rješenja (Chilean Web Application Development Effort
Estimation-CWADEE, Content Management System Effort Estimation Model-CMSEEM,
modificarne verzije od WEBMO – WEBMO+ i Vector Prediction Model – VPM+, Web
component model), srednja vrijednost procjene (engl. Mean estimation), medijan procjene
(engl. Median estimation) te još neka druga rješenja, kao što su nelinearna regresija (engl.
Non-linear regression), broj funkcijskih točaka (engl. Function point counts), WEBMO, tabu
pretraga (engl. Tabu search) i hibridni modeli.
U nastavku, ukratko će biti opisane najzastupljenije metode kao i one koje su nastale kao
prilagoĎena rješenja za potrebe procjene teţine razvoja web aplikacija.
3.1.1. Zaključivanje temeljeno na slučaju (Case based reasoning, CBR)
CBR metoda je tehnika za predikciju koja je jako često u upotrebi. U [75] ukazano je na
opravdanost uporabe CBR-a korištenjem povijesnih informacija završenih projekata. Za te
projekte je bio poznat podatak o uloţenom naporu koji je bio potreban da se razvije neka web
aplikacija. Metoda uključuje karakteristike novog projekta za koje je potrebno procijeniti
uloţeni napor, koji ima neke zajedničke osobine s prethodno završenim projektima sačuvanim
u bazi slučajeva (baza završenih projekata). Osobine projekata za koje je potrebno izvršiti
procjenu se koriste kao osnova za pronalazak sličnih (analognih) završenih projekata, za koje
je uloţeni napor već poznat. Ova procjena napora za novu aplikaciju se postiţe mjerenjem
euklidske udaljenosti izmeĎu dva projekta, bazirano na vrijednostima osobina za ove projekte.
Jedan od glavnih problema prilikom korištenja CBR-a je ovisnost o dostupnosti podataka o
završenim projektima koji su slični ili bi trebali biti slični po karakteristikama kao projekt za
koji se procjenjuje teţina razvoja tj. uloţeni napor.
Autori u [75] su sugerirali da CBR metoda moţe biti jako korisna gdje je područje razvoja
kompleksno i teško za modeliranje.
3.1.2. Postupna regresija (Stepwise regression, SWR)
Postupna regresija [76] je statistička tehnika gdje se model za predviĎanje, tj. jednadţba
modela, kreira tako da predstavlja vezu izmeĎu neovisnih i ovisnih varijabli. Ova tehnika u
26
svakoj iteraciji kreira model dodavanjem neovisne varijable s najvećom vrijednošću (snagom)
veze s ovisnom varijablom, uzimajući u obzir sve varijable koje se trenutno nalaze unutar
modela. Njen cilj je pronaći skup neovisnih varijabli (prediktora) koji na najbolji mogući
način opisuju varijacije unutar ovisne varijable (odgovor). Prije kreiranja modela, vaţno je
osigurati da sve pretpostavke vezane za korištenje takve tehnike nisu narušene [77].
3.1.3. Linearna regresija (Linear regression)
Linearna regresijska analiza je jedna od najčešće korištenih statističkih tehnika za
istraţivanje veze izmeĎu ovisne varijable i jedne ili više neovisnih varijabli. Većina
analiziranih studija je za potrebe kreiranja modela za procjenu teţine razvoja web aplikacija
koristila upravo ovu statističku metodu vjerojatno zato što se vjeruje da postoji snaţna
linearna veza izmeĎu ovisne i neovisne varijable [74].
3.1.4. Metoda vektora potpore regresije (Support-vector regression, SVR)
SVR [68] predstavlja novu generaciju algoritama za strojno učenje koji su prikladni za
probleme modeliranja predviĎanja. Primjena SVR-a u području procjene teţine razvoja web
aplikacija je veoma oskudna, ali postoji. Nekoliko studija [72] analiziralo je primjenu ove
metode u tu svrhu te su dobili zadovoljavajuće rezultate.
Glavni problem ove metode je način odabira odgovarajućih parametara za SVR da bi se
ona mogla efikasno koristiti za procjenu teţine razvoja web aplikacija [78].
3.1.5. Web-COBRA
Web-COBRA predstavlja adaptaciju metode COBRA (COst estimation, Benchmarking
and Risk Analysis) [29]. COBRA je tipična kompozitna metoda predloţena sa ţeljom da
ujedini sve dobre osobine estimacija baziranih na podacima pomoću kojih se kreiraju
matematički modeli (modelske metode) i onih baziranih na iskustvu stručnjaka (ne-modelske
metode). Metoda COBRA ovo postiţe korištenjem iskustva eksperata i njihovog rasuĎivanja
na kontroliran način u kombinaciji s drugim faktorima za definiranje teţine (nositelji
troškova). Ovo sve zajedno se koristi s algoritamskim pristupima. Ne-modelske metode su
uglavnom bazirane na pogaĎanjima ili predviĎanjima eksperata. Modelske metode bazirane su
ili se oslanjaju na više formalne pristupe, uključujući primjenu nekih algoritama s nekoliko
ulaznih parametara (tj. faktora koji imaju utjecaja na cijenu razvoja aplikacija) kako bi u
27
konačnici kreirale procjenu teţine razvoja softvera. Kao teţinski faktor najčešće se uzima
veličina aplikacije.
Web-COBRA [31] je predloţena u cilju procjene teţine razvoja web aplikacija uzimajući u
obzir potrebe koje se postavljaju kao zahtjevi od tvrtki koje se bave razvojem web aplikacija.
Osnovna razlika izmeĎu metoda COBRA i Web-COBRA odnosi se na način kako se
odreĎuje teţina faktora troška. COBRA dopušta da se izvrši dodjela teţine za svakog eksperta
u cilju da se prilikom procjene teţine razvoja aplikacije uzme u obzir i stupanj iskustva
eksperta [29] dok su faktori troška Web-COBRA metode prilagoĎeni za web aplikacije tako
da je isključena mogućnost interakcije izmeĎu pojedinih faktora troška.
3.1.6. CWADEE (Chilean Web Application Development Effort Estimation)
Ochoa i suradnici [66] su za potrebe procjene teţine razvoja web aplikacija razvili metodu
koju su nazvali Chilean Web Application Development Effort Estimation (CWADEE) u cilju
brze procjene teţine razvoja u kratkom periodu unutar 24-72 sata. Oni su tvrdili da je ova
metoda jednostavna i specifično prilagoĎena za procjenu teţine razvoja Web baziranih
informacijskih sustava srednje veličine. Ochoa i suradnici su predstavili novu metriku za
procjenu veličine web aplikacija nazvanu Data Web Points (DWP) za koju su tvrdili da je
indirektna metrika veličine koja uzima u obzir karakteristike čileanskih eksperata, raspoloţivo
vrijeme procjene, i nedostatak velike količine povijesnih informacija korištenih za potrebe
procjene. Autori ove metode su naglasili da su studenti računarstva tijekom tečaja softverskog
inţenjerstva koristili CWADEE za potrebe izračuna teţine razvoja razvijanih web projekata.
Nadalje su naglasili da i studenti s malo iskustva mogu dobiti zadovoljavajuće procjene
korištenjem CWADEE.
3.1.7. WEBMO
WEBMO [37] metoda predstavlja modifikaciju tj. nadogradnju već postojeće metode Web
objekata koju je prezentirao Reifer [36].
Ovaj model je nadogradnja modela COCOMO II [34]. Model je nastao kao spoj metode
procjene na bazi eksperta i stvarnih podataka od 64 projekta korištenjem tehnike linearne
regresije. Metoda omogućava korisniku da uzme u obzir karakteristike web projekata u skladu
s prilagoĎavanjima prema utjecajima koje oni imaju prema teţinskim faktorima cijene.
WEBMO matematička formulacija izgraĎena je na modelima COCOMO II tj. njihovim
28
iscrpnim podacima na analizi podataka više od 161 projekta koji upućuju na rješavanje
problema vezanih za web.
Trenutna verzija modela WEBMO razlikuje se od originalnog modela COCOMO II tako
što ima devet umjesto sedam nositelja troškova. Prikaz nositelja troškova WEBMO i
COCOMO II modela dati su u tablici 3.1.
Tablica 3.1. Prikaz nositelja troškova WEBMO i COCOMO II modela.
WEBMO Oznaka Opis
CPLX Product Reliability and Complexity – Pouzdanost i kompleksnost
proizvoda
PDIF Platform Difficulty – Teškoće razvojne platforme
PERS Personnel Capabilities – Sposobnosti osoblja
PREX Personnel Experience –Iskustvo osoblja
FCIL Facilities – Sredstva ili oprema
SCED Schedule Constraints – Ograničenja zbog rasporeda
RUSE Degree of Planned Reuse –Stupanj planirane ponovne uporabe
TEAM Teamwork – Timski rad
PEFF Process Efficiency –Proces učinkovitosti
COCOMO II Oznaka Opis
RCPX Product Reliability and Complexity – Pouzdanost i kompleksnost
proizvoda
RUSE Required Reuse – Potrebna ponovna iskoristivost
PDIF Platform Difficulty – Teškoće razvojne platforme
PERS Personnel Capabilities – Sposobnosti osoblja
PREX Personnel Experience –Iskustvo osoblja
FCIL Facilities – Sredstva ili oprema
SCED Required Development Schedule – Potreban raspored razvoja
Prezentirani model kroz rad Reifera [37] ukazuje da su rezultati analize i kreiranja modela
značajni zato što ukazuju na činjenicu da Web objekti i model WEBMO moţe pomoći u
rješavanju nedostataka u oblasti estimacije. U tablici 3.2 prikazana je matematička
formulacija WEBMO modela.
29
Tablica 3.2. Matematička formulacija WEBMO modela [36].
Jednadţba za potrebni napor Jednadţba za vremensko trajanje
2PDuration B Effort
Gdje su: A i B = konstante iz parametarske tablice modela na osnovu završenih projekata; P1 i P2 =
eksponencijalni zakoni jačine (power laws); cdi = nositelji troška; Size = # SLOC.
Obzirom da je WEBMO nadogradnja modela COCOMO II a model COCOMO II koristi
SLOC za procjenu uloţenog napora, da bi se ovaj model mogao odmah koristiti (engl. Out of
the box), potrebno je izvršiti konverziju elemenata modela WEBMO u SLOC i stoga
jednadţba modela prikazana u tablici 3.2 i sadrţi SLOC kao jedan od parametara.
3.2. Primjeri studija s metodama za procjenu teţine razvoja web aplikacija
U literaturi je opisan veliki broj tehnika za procjenu teţine razvoja web aplikacija baziranih
na jednoj ili više osnovnih tehnika.
U [24] su koristili metodu COBRA za procjenu teţine razvoja web aplikacija. U svom radu
autori su na bazi ove metode razvili model za izračun teţine i cijene razvoja web aplikacija.
Autori su takoĎer sugerirali da se ova metoda treba koristiti kada postoji nedostatak ili kada
postoji manji broj podataka o prošlim projektima. Nadalje su naglasili da COBRA sama po
sebi koristi znanje eksperta i ograničen broj podataka o prošlim projektima za predviĎanje ili
estimaciju napora potrebnog za razvoj aplikacija. U svojoj studiji autori su uvjereni da
standardni softverski inţenjerski principi i tehnike ne mogu u cijelosti odgovoriti na zahtjeve i
izazove procjene teţine razvoja web aplikacija kao što je to naveo i Reifer [37] u svojoj
studiji.
U [28] je po prvi puta provedena studija i primijenjena mjera Web objekata i izvršena
validacija. Model za procjenu teţine razvoja web aplikacija koji je bio baziran na Web
objektima je usporeĎen s FPA pomoću statističke metode regresije s običnom metodom
najmanjih kvadrata (engl. Ordinary Least Square, OLS). Autori studije su nakon analize
utvrdili da su performanse Web objekata tj. modela baziranom na ovoj metodi bile bolje u
odnosu na standardnu FPA metodu.
19
1
P
i
i
Effort A cd Size
30
U [2] i [79] korištena je metoda CBR, linearna i postepena regresijska tehnika za procjenu
napora potrebnog za razvoj web aplikacija. U [23] je primijenjeno nekoliko različitih
konfiguracija CBR-a u njihovoj studiji za procjenu cijene i teţine razvoja web aplikacija.
U [80] provedena je druga replicirana studija da bi se istraţila točnost korištenja podataka
iz različitih tvrtki naspram podataka iz jedne tvrtke za kreiranje modela. U svojoj studiji autori
su koristili 83 web projekta iz baze podataka projekta Tukutuku [81]. Projekt Tukutuku
prikuplja podatke o web projektima iz cijelog svijeta i koristi ove podatke za kreiranje modela
za predviĎanje cijene i teţine razvoja web aplikacija i za označavanje i evidenciju
produktivnosti. Mjere veličine web aplikacija korištenih u toj studiji dobivene su
prikupljanjem podataka putem web portala na kojem su se pomoću web formi prikupili
podaci za 133 web projekta koji su implementirani u svijetu. Davanje ovih podataka u svrhu
skupljanja informacija i kreiranja Tukutuku baze podataka bilo je na dobrovoljnoj osnovi
[82]. Procjena bazirana na modelu kreiranom s podacima podataka iz jedne tvrtke bila je
značajno točnija od onih modela koji su kreirani na osnovi podataka dobivenih iz različitih
tvrtki.
U [14] provedena je studija nad podacima koji su dobiveni od strane manje tvrtke iz
Brazila s 25 zaposlenih koja se bavi razvojem web aplikacija. Cilj ove studije je bio da se
dobije pojednostavljena metoda za procjenu teţine razvoja web aplikacija. Ova tvrtka je za
razvoj svojih aplikativnih rješenja koristila tehnologije kao što su PHP, HTML, Java i
MySQL. Pojednostavljena verzija IFPUG (International Function Point Users Group)
funkcijskih točaka (engl. Function Points, FP) je korištena za dobivanje veličine web
aplikacija. Podaci za kreiranje modela za procjenu teţine razvoja web aplikacija su bili
dobiveni od dvadeset tvrtki koje su se bavile razvojem web aplikacija. Rezultati procjene
korištenjem ove pojednostavljene metode bili su jako blizu rezultatima dobivenim
korištenjem IFPUG potpune metode. Na osnovu rezultata mjerenja, bilo je moguće
uspostaviti pojednostavljenu metodu za procjenu veličine web aplikacija sukladno razvojnim
karakteristikama analizirane tvrtke.
U drugoj studiji [9] autori su proveli empirijsku analizu o efikasnosti metode COSMIC za
procjenu teţine razvoja web aplikacija. U svojoj studiji, korišteni su podaci od 44 web
aplikacije razvijene od strane studenata. Rezultat studije je ukazao na činjenicu da mjerenje
kretanja podataka moţe biti korisno za procjenu napora potrebnog za razvoj dinamičkih web
aplikacija.
31
U [83] provedena je nova studija na bazi studije [84] korištenjem različitih
eksperimentalnih procedura gdje su korišteni podaci od strane više tvrtki preuzeti iz
repozitorija podataka International Software Benchmarking Standards Group (ISBSG).
Autori su uzeli uzorak od 98 web aplikacija uključujući 9 projekata iz jedne tvrtke i 89
podataka iz drugih različitih tvrtki nad kojim su primijenili metodu funkcijskih točaka, pri
čemu su ulazni parametri bili korišteni programski jezik, tip razvoja i platforma na kojoj je
razvijena aplikacija kao osnovni elementi na bazi kojih je vršena procjena teţine razvoja web
aplikacija. Glavni cilj ove studije bio je da se predvidi da li modeli za predviĎanje teţine
razvoja web aplikacija bazirani na podacima iz različitih tvrtki proizvode bolju procjenu za
napor i cijenu u odnosu na modele bazirane na podacima iz tvrtke za koju je namijenjen
model. Autori su došli do zaključka da za jednu kompaniju korištenje podataka za kreiranje
modela na osnovu podataka iz više drugih kompanija daje manje točne podatke u odnosu na
to ako se koristi model koji je testiran i napravljen na podacima tvrtke za koju se radi procjena
teţine razvoja.
U [85] provedena je studija na 15 web aplikacija koje je razvila talijanska softverska tvrtka
srednje veličine koja je uglavnom razvijala poslovne informacijske sustave za drţavne
institucije. Web projekti korišteni u ovoj studiji su bili klasificirani uglavnom kao e-vlada, e-
bankarstvo, web portali i intranet aplikacije i razvijene su uglavnom uz pomoć J2EE, ASP,
ASP.NET, ORACLE i drugih tehnologija. UsporeĎena je efikasnost tri mjere veličine web
aplikacija za predviĎanje napora potrebnog za razvoj web aplikacija: model procjene kreiran
pomoću varijabli iz baze podataka Tukutuku [86], Web objekti, model procjene kreiran
pomoću varijabli karakterističnih elemenata web stranica (broj web stranica, broj
multimedijalnih elemenata, broj novih multimedijalnih elemenata, broj klijentskih skripti i
aplikacija, broj programskih datoteka posluţitelja i aplikacija, broj unutarnjih poveznica i broj
vanjskih referenciranja poveznicama) s funkcijskim mjerama (devet komponenti Web
objekata). Rezultat studije, korištenjem 15 web projekata razvijenih od strane softverske
tvrtke, pokazao je da su sve mjere pokazale zadovoljavajuće rezultate u pogledu procjene
teţine razvoja web aplikacija.
U drugoj studiji [87] autori su usporedili COSMIC i Web objekte u cilju verifikacije
njihove efikasnosti kao indikatora potrebnog napora za razvoj web aplikacija. Rezultati
studije koji su uključili 15 web aplikacija otkrili su da su Web objekti kao i metoda COSMIC
dobri indikatori za procjenu napora potrebnog za razvoj web aplikacija.
32
U [2] autori su u svojoj studiji primijenili i izvršili validaciju pristupa Object-Oriented
Hypermedia Function Points (OO-HFP) za procjenu teţine razvoja web aplikacija na
podacima dobivenim od španjolske tvrtke koja se bavi razvojem web aplikacija, koja je u
svoj razvoju aplikacija koristila pristup baziran na modelu uz korištenje Object-Oriented
Hypermedia (OO-H) metode i funkcionalnih točaka. Ova studija je takoĎer pokazala
zadovoljavajuće rezultate u pogledu točnosti procjene teţine razvoja web aplikacija.
U [72] autori su izvršili analizu velikog broja studija u području procjene resursa web
aplikacija. Na osnovu obraĎene studije, moţe se uočiti da je do sada predloţen jako veliki broj
pristupa i tehnika za različite kategorije web aplikacija. Interesantna činjenica je da ni jedan
pristup nije predloţio smjernice kada je moguće primijeniti neku metodu u nekom odreĎenom
scenariju. Studija [88] zaključuje da ne postoji univerzalna metoda kad je u pitanju procjena
teţine razvoja web aplikacija. Nadalje, analizom studija iz [72], uočljivo je da postoji jako
mali broj radova koji istraţuje procjenu teţine razvoja web aplikacija bazirano na
konceptualnim modelima u ranoj fazi razvoja web aplikacija. Studije su većinom istraţivale
ovu tematiku po segmentima, na primjer, samo procjena veličine aplikacija bez direktnog
upućivanja da li se radi o web aplikacijama, ili kroz neke metode kao na primjer analogija
(engl. Analogy), CBR, tabu pretraţivanje, vektor potpore regresije itd. Osim navedenih
postoje i radovi koji obično istraţuju veličinu softverskih aplikacija bazirano na funkcijskim
točkama (npr. IFPUG, COSMIC itd.).
U ovom poglavlju napravljen je uvod u područje procjene teţine razvoja softverskih
proizvoda i dat je pregled postojećih metoda za procjenu teţine razvoja web aplikacija. Svaka
od predstavljenih metoda za procjenu teţine razvoja web aplikacija ima svoju primjenu u
ovisnosti od načina na koji su se razvijale aplikacije koje su bile uzorni elementi za kreiranje
modela procjene. MeĎutim, ove metode većinom nisu bazirane na konceptu rane procjene
teţine razvoja web aplikacija, što je uglavnom primjenjivo pomoću metoda koje na osnovu
nekih parametara pokušavaju izgraditi model procjene teţine razvoja web aplikacija ali u fazi
definiranja zahtjeva web aplikacija. U narednim poglavljima bit će prikazani i objašnjeni
osnovni gradivni elementi za kreiranje modela procjene teţine razvoja web aplikacija u fazi
definiranja zahtjeva korisnika kao što su metode za procjenu funkcionalne veličine web
aplikacija, metode za kreiranje konceptualnih modela web aplikacija i metode za procjenu
teţine razvoja web aplikacija bazirane na funkcionalnim veličinama web aplikacija.
33
4. MJERNE PROCEDURE ZA PROCJENU TEŢINE RAZVOJA WEB APLIKACIJA
Unutar ovog poglavlja, predstavljene su neke od vaţnijih i više zastupljenih metoda za
izračun funkcionalne veličine web aplikacija.
4.1. IFPUG-ove smjernice za web aplikacije
Godine 1998, IFPUG (International Function Point Users Group) je objavila smjernice na
koji način je potrebno izvršiti mjerenje veličine web aplikacija korištenjem analize funkcijskih
točaka (engl. Function Point Analysis, FPA) korištenjem pravila za brojanje funkcijskih
točaka [89]. Nakon analize ovih smjernica od više istraţivača i institucija, uslijedile su kritike
da predloţene smjernice nisu prihvatljive za korištenje u praktičnom radu.
Rollo [63] je ukazao na neke od mogućih problema i poteškoća prilikom primjene ovih
smjernica za mjerenje veličine web aplikacija, kao što su poteškoće prilikom identifikacije
granica sustava i njegovih logičkih zapisa. Na kraju, on je zaključio da je mjerenje veličine
poslovnih aplikacija jako teško uz uporabu IFPUG FPA. Iako je Rollo predloţio uporabu
metode COSMIC-FFP za mjerenje veličine web aplikacija, nikada nije prezentirao rezultate
usporedbe izmeĎu ove dvije metode koje bi potkrijepile njegovu tvrdnju. Nakon toga, tvrtka
Total Metrics [90] je uvidjela da IFPUG-ove smjernice nisu riješile mnoge od problema
vezanih za pravila brojanja prilikom mjerenja veličine web aplikacija.
4.2. Web objekti
Metoda Web objekata (engl. Web objects) prezentirana od strane Reifera [37] predstavlja
jednu formu proširenja metode FPA za potrebe procjene veličine web aplikacija. Uz pomoć
ove metode, funkcijska veličina web aplikacije se utvrĎuje uzimajući u obzir komponente od
kojih je sačinjena web aplikacija.
Reifer je dodao četiri nove komponente prikladne/srodne za web aplikacije pored pet
funkcijskih tipova definiranih u FPA (Internal Logical Files- ILF, External Interface Files-
EIF, External Input-EI, External Output-EO, External Inquiry-EQ), a to su: multimedijalne
datoteke, web gradivni elementi (npr. ActiveX, DCOM, OLE, Applets, itd.), skripte (za
povezivanje html/xml podataka) i poveznice (npr. xml, html i linije koda upitnog jezika SQL-
a kao poveznice prema podatkovnim atributima).
Kao i kod metode IFPUG FPA, načinjen je skup pravila za brojanje i tablica raspona
kompleksnosti s teţinama.
34
Web objekti su nastali kao kombinacija procjene stručnjaka i podataka koji su dobiveni iz
46 web projekata korištenjem regresijske analize. Na slici 4.1 prikazano je pet tipova funkcija
kao i dodatni webu srodni gradivni elementi [28].
Slika 4.1. Komponente Web objekata [28].
Veličina web aplikacije se utvrĎuje evaluacijom devet komponenti web sustava bazirano
na zahtjevima korisnika i dizajnu stranica. Svaka od komponenti mora se brojati i
kategorizirati u skladu sa svojom kompleksnošću, koja moţe biti niska, srednja ili visoka.
Odgovarajuća vrijednost za svaku pobrojanu instancu komponente Web objekata dodijeljuje
se na osnovi unaprijed definirane tablice teţina. Teţinska suma predstavlja funkcionalnu
veličinu web aplikacija izraţenu kroz Web objekte.
Ruhe [28] je prvi primijenio Web objekte u svojoj studiji i ujedno izvršio validaciju
metode. U njegovom radu, model za procjenu teţine razvoja web aplikacija baziran na Web
objektima je usporeĎen s metodom FPA korištenjem statističke metode regresije s običnom
metodom najmanjih kvadrata (engl. Ordinary Least Square, OLS). Autori studije su potvrdili
da su performanse Web objekata kao korištene metode bolje nego kod standardne metode
FPA.
4.3. Web točke
Cleary je u svom radu [64] predloţio novu metodu nazvanu Web točke (engl. Web points).
Pomoću ove metode mjeri se veličina statičkih web stranica. Kompleksnost HTML stranica je
osnovni mjerni element za izračun veličine web stranica. Broj web točaka dodijeljenih stranici
je funkcija veličine stranice u riječima, broju postojećih poveznica, i broju ne-tekstualnih
35
elemenata web stranice. Pomoću ove metode, Cleary uz pomoć podataka o produktivnosti
utvrĎuje napor koji je potrebno uloţiti za razvoj ili unaprjeĎenje statične web stranice. S
obzirom da je ova metoda usmjerena na analizu statičkih web stranica, ona ne analizira niti
uzima u obzir ponašanje i navigacijske osobine web aplikacija.
4.4. Internetske točke
Metoda tvrtke Cost Xpert nazvana internetske točke (engl. Internet points) [65] je
proširenje FPA metode kojom bi se eksplicitno podrţala procjena web projekata. Veličina
web aplikacije se mjeri pomoću sedam tipova funkcija: vanjski zapisi sučelja (engl. External
Interface Files, EIFs), unutarnje logičke tablice (engl. Logical Internal Tables),
poruke/vanjski upiti prema sustavu (engl. Messages/External Queries), izvještaji (engl.
Reports-hard copy), statičke HTML stranice (engl. Static screens), dinamičke HTML stranice
(engl. Dynamic screens) i interaktivne stranice (engl. Interactive screens). Prva dva tipa
funkcija ove metode odgovaraju istim tipovima funkcija vanjskih datoteka sučelja (engl.
External Interface Files, EIFs) i unutarnjih logičkih zapisa (engl. Internal Logical Files, ILFs)
metode IFPUG FPA dok su ostali tipovi funkcija definirani kako slijedi [62]:
Poruke poslane od strane sustava koji se mjeri odnosno upiti poslani do strane
vanjskog sustava (engl. Messages/External Queries): funkcije koje su napravljene za
interakciju s korisnicima izvan sustava koji se mjeri (kao na primjer API funkcije
nekog sustava) ili poruke koje su kreirane za uporabu izvan sustava koji se mjeri ili
funkcije/poruke koje su podrţane/generirane od strane aplikacija izvan sustava koji
se mjeri.
Izvještaji: izvještaji i prikazi mogući samo za čitanje bez mogućnosti interakcije.
Statičke HTML stranice.
Dinamičke HTML stranice: stranice generirane pomoću tehnologija kao što su
DHTML (Dynamic HTML), ASP (Active Server Pages) ili alata za izvještavanje
(engl. report engines) itd.
Interaktivne stranice: uključuju značajnu poslovnu logiku i omogućavaju interakciju
s korisnikom ili provjeru pogreške.
Proces mjerenja započinje identifikacijom sedam tipova funkcija na osnovu specifikacije
zahtjeva web aplikacije. Nakon toga, svaki tip funkcije se mnoţi s teţinskim faktorom koji je
različit za različite tipove funkcija te se na kraju zbroje veličine svakog od tipova funkcija i
36
dobiva se konačna veličina web aplikacije. Ova metoda je automatizirana uz pomoć alata
nazvanog Cost Xpert.
4.5. Podatkovne web točke
Metoda nazvana Podatkovne web točke (engl. Data Web Points) [66] kao svoj glavni
oslonac koristi podatkovni model za predstavljanje funkcionalnosti web aplikacija. Tipovi
entiteta i veza koji se pojavljuju i koriste u ovoj metodi su sljedeći:
Regularni entiteti: oni koji ne sadrţe strani ključ i kod kojih njihov primarni ključ sluţi
za njihovu identifikaciju.
Ovisni entiteti: oni koji su stranim ključem povezani s regularnim entitetom i čiji
primarni ključ je formiran od primarnog ključa regularnog entiteta i vlastitog ključa.
Vezni entiteti: oni koji razdvajaju N ka M vezu izmeĎu dva druga entiteta. Ključ veze
formiran je pomoću primarnih ključeva entiteta koji sudjeluju u vezi.
Veza 1 prema N: ova veza je uspostavljena izmeĎu relacijskog entiteta i drugog
entiteta, gdje je jedna ili više instanci relacijskog entiteta pridruţeno instanci drugog
entiteta.
Veza 1 prema 1: ova veza je uspostavljena izmeĎu relacijskog i drugog entiteta, gdje
je jedna i samo jedna instanca relacijskog entiteta pridruţena instanci drugog entiteta.
Osnovna ideja ovog prijedloga je da svaki od ovih entiteta predstavlja predloţak koji ima
tipične funkcionalnosti koje su mu dodijeljene. Sam proces primjene ove metode započinje
brojanjem svakog tipa entiteta iz podatkovnog modela. Broj svakog od tipova entiteta se onda
mnoţi s teţinskim faktorom. Predloţeni teţinski faktori za svaki od tipova entiteta i veza su
sljedeći: 9 za regularne i ovisne entitete, 3 za relacijske entitete i veze 1 prema 1, 6 za veze 1
prema N. Autori metode su spomenuli da su teţinski faktori definirani na osnovu iskustva
procjenitelja koji je stručnjak u danom području.
4.6. OOmFPWeb
OOWS (Object-Oriented Web Solutions) [91] je proširenje metode OO (Object Oriented)
nazvane OO-Method [92]. OO-Method je objektno orijentirana metodologija koja sjedinjuje
korištenje formalne specifikacije sustava s tradicionalnim objektno orijentiranim
metodologijama bazirano na praktičnom radu. OOWS omogućava uporabu grafičkih modela,
pa za razliku od ostalih pristupa u ovom području, ova metodologija omogućava analitičarima
da uvedu relevantne informacije o sustavu kako bi se mogao kreirati konceptualni model
37
unutar faze prikupljanja zahtjeva Na osnovi konceptualnih modela moguće je generirati
formalnu specifikaciju sustava koja sluţi kao repozitorij sustava na visokoj razini. OOWS
proširuje OO-Method na način da dodaje elemente pomoću kojih je moguće identificirati
navigacijske i prezentacijske osobine web aplikacija. Kao proširenje metode OO-Method,
osnovni cilj OOWS-a je utvrditi preciznu specifikaciju sustava koji će biti transformiran u
odgovarajući softverski proizvod. Kod razvojnog procesa metodom OOWS, razlikuju se dva
modela: konceptualni model i izvršni model. Konceptualni model je baziran na specifikaciji
pet komplementarnih pogleda konceptualnih modela (Object, Dynamic, Functional,
Navigational i Presentation), koji opisuju funkcionalnost web aplikacije unutar dobro
definiranog razvojnog okruţenja metode OO-Method.
Metoda za mjerenje funkcionalne veličine web aplikacija OOmFPWeb [62] predloţena je
kako bi se omogućilo mjerenje funkcionalne veličine web aplikacija koje su kreirane
korištenjem OOWS-a. Prema ovom modelu, mjerenje funkcionalne veličine zahtijeva dva
koraka apstrakcije: identifikacijski i mjerni korak. Identifikacijski korak započinje
definiranjem specifikacije zahtjeva korisnika (engl. User Requirements Specification) što vodi
do OOWS-ove konceptualne sheme, koja uključuje sljedeće elemente web aplikacije [62]:
Podaci (engl. Data): podaci s kojima radi ili koje aplikacija obraĎuje. Podaci su
definirani pomoću Objektnog Modela (engl. Object Model).
Proces (engl. Process): operacije koje aplikacija obavlja su definirane unutar
objektnog modela s jasno definiranim promjenama stanja objekta kod OOWS-ovog
funkcionalnog modela (engl. Functional Model).
Ponašanje (engl. Behavior): dinamičko ponašanje aplikacije u toku valjanog ţivotnog
vijeka objekta i interakcije unutar objekta, definirano u dinamičkom modelu (engl.
Dynamic Model).
Navigacija (engl. Navigation): navigacijska struktura aplikacije definirana unutar
navigacijskog modela (engl. Navigation Model).
Prezentacija (engl. Presentation): interakcija korisnika s aplikacijskim web sučeljem,
definirana unutar prezentacijskog modela (engl. Presentation Model).
OOmFPWeb pretpostavlja da svih pet modela OOWS-ove konceptualne sheme sadrţi sve
elemente koji mogu doprinijeti funkcionalnoj veličini web aplikacije. Stoga je konceptualna
shema OOWS-a osnovni element koji sluţi za identifikaciju ovih elemenata.
Tip elemenata koji su relevantni za mjerenje funkcionalne veličine web aplikacija su
opisani u OOmFPWeb-ovom apstraktnom mjernom modelu (engl. Measurement Abstract
38
Model). Ovi tipovi elemenata su uglavnom definirani kao osnovne funkcionalne kompomente
(engl. Basic Functional Component, BFC), kao što je definirano i u standardu ISO/IEC [93]
za mjerenje funkcionalne veličine.
Mjerni proces započinje elementima modela iz OOWS-ove konceptualne sheme. Kao
posljedica toga, funkcionalna veličina web aplikacija je izračunata u prostoru problema (engl.
problem space) [94] i stoga je neovisna od tehnologije koja se koristi za implementaciju web
aplikacije.
4.7. Cândido i Sanches
Metoda predloţena od strane istraţivača Cândido i Sanches [14] predstavlja
pojednostavljenu izvedbu metode IFPGU zajedno s izračunom funkcionalnih točaka baziranih
na idejama predloţenim od strane NESMA (Netherlands Software Metrics Association) [21]
za procjenu veličine informacijskih sustava za upravljanje projektom. Na osnovu izloţenih
rezultata u ovoj studiji, autori su predloţili moguću metodu za pojednostavljeni izračun
veličine web aplikacija u skladu s karakteristikama analiziranih web aplikacija.
Autori su prvo izvršili izračun funkcionalne veličine web aplikacija korištenjem metode
IFPUG. Nakon toga, primijenili su metodu NESMA za izračun broja funkcionalnih točaka.
Treći korak je bila usporedba rezultata mjerenja dobivenih u prva dva koraka. Nakon
usporedbe rezultata ova dva mjerenja, pokazalo se da metoda NESMA nije primjenjiva za
točno ili pribliţno točno odreĎivanje funkcionalnih točaka web aplikacija. MeĎutim, na
osnovu ovih mjerenja, pokazalo se da najveći broj funkcija ima nisku kompleksnost. Ova
činjenica je bila motivacija za kreiranje pojednostavljene metode za mjerenje funkcionalne
veličine web aplikacija.
Pojednostavljena metoda je koncipirana tako da uzima u obzir sve funkcije s niskom
kompleksnošću. Osim navedenog, autori su kreirali i alat za podršku mjerenju funkcionalnih
točaka te koji bi bio u mogućnosti utvrditi produktivnost zaposlenika i vrijeme potrebno za
razvoj svake od aplikacija (u satima).
4.8. Costagliola i suradnici
Analizirajući trenutnu situaciju u području web tehnologija, Costagliola i suradnici [9] su
zaključili da trenutne metode mjerenja funkcionalne veličine web aplikacija ne zadovoljavaju
napredne potrebe trţišta u ovom segmentu. S obzirom na evoluciju internetskih tehnologija i
stalni prelazak s klasičnih sustava za objavu web sadrţaja na web aplikacije, bilo je potrebno
39
adaptirati postojeće metode u skladu s potrebama. Da bi istraţili ovu oblast, Costagliola i
suradnici su predloţili metodu pomoću koje bi se mogla procijeniti funkcionalna veličina
dinamičkih web aplikacija. Predloţili su dva moguća pravca za primjenu metode: faza analize
i faza dizajna. Sukladno tome, na osnovu skupa podataka o razvijenim web aplikacijama,
analizirali su ova dva slučaja da bi utvrdili u kojoj fazi se mogu dobiti točniji rezultati. Za
kreiranje modela web aplikacija za fazu analize, koristili su pristup koji je predstavila Jenner
[95], [96]. Za fazu dizajna koristili su prijedloge Rollo [63] i Mendes i suradnika [23]
definirajući pravila koja im omogućavaju da mjere funkcionalnu veličinu web aplikacija
korištenjem dijagrama klasa. Dijagrami su bili prilagoĎeni UML (Unified Modeling
Language) notaciji za web predloţenim od strane Conallena [97], koji koristi stereotipove
(engl. stereotypes), označene vrijednosti (engl. tagged values) i ograničenja (engl.
constraints) da na odgovarajući način predstave komponente koje su specifične za web.
Procjena efikasnosti ova dva načina mjerenja funkcionalne veličine web aplikacija
provedena je uz pomoć empirijske studije na skupu od 44 web aplikacije razvijene od strane
studenata završne godine studija. Za kreiranje modela za predviĎanje napora, korištena je
statistička metoda regresijske analize s običnom metodom najmanjih kvadrata (engl. Ordinary
Least Square, OLS).
Nakon provedene analize utvrĎeno je da bolje rezultate daje model koji je kreiran na
osnovu Conallenovog dijagrama klasa uz primjenu definiranih pravila posebno kreiranih za
dinamičke web aplikacije. Na osnovu prethodno navedenog nameće se zaključak da je bolje
kreirati model u fazi dizajna web aplikacije. Ova pravila predstavljaju nadogradnju pravila
koje su za web hipermedijske sustave predloţili Mendes i suradnici [23].
4.9. Fraternali i suradnici
Tehnike za automatizaciju procjene veličine softverskih proizvoda postaju sve popularnije
i traţenije zbog brzine rada i točnosti izvršenja postavljenih zadataka. Fraternali i suradnici
[67] su razvili tehniku za automatizirano mjerenje funkcionalne veličine softverskog
proizvoda na bazi konceptualnog modela. Evaluacija modela je izvršena na stvarnim
projektima. Jedna od prednosti ovog alata i metode je da razvojni programeri mogu koristiti
neko integrirano razvojno okruţenje za specifikaciju zahtjeva i dizajniranje njihovih sustava,
generirati kompletan kostur izvršnog kôda aplikacije i na kraju izvršiti analizu funkcionalnih
točaka.
40
Osnovni element predloţene metode je formalni jezik za modeliranje notacijom pogodan
za generiranje koda aplikacije i procjenu funkcionalne veličine. U svom radu, ovi autori su
prilagodili jezik za modeliranje web sadrţaja (engl. Web Modeling Language, WebML) [5],
UML profil za prezentiranje interaktivnih sustava, posebno prilagoĎen za opis web aplikacija
kao i za podršku web servisa [98]. WebML koristi osnovni UML dijagram klasa za
predstavljanje poslovnih objekata razvijane aplikacije i notaciju specifičnu za odreĎenu
domenu, nazvanu hipertekstualni dijagrami (engl. Hypertext diagrams), za prikazivanje i
predstavljanje strukture sučelja aplikacije. Mjerna procedura je u potpunosti implementirana
kao dodatak unutar razvojnog okruţenja WebRatio [99].
4.10. Procedura OO-HFP
Object-Oriented Hypermedia Function Points (OO-HFP) je mjerna procedura za
odreĎivanje funkcionalne veličine web aplikacija koje su kreirane pomoću metode Object-
Oriented Hypermedia (OO-H) [6]. Modeli web aplikacija kreirani pomoću ove metode mogu
se transformirati u izvršnu web aplikaciju pomoću softverske aplikacije VisualWADE [100]
za modeliranje. Metoda OO-HFP kao ulaznu veličinu uzima konceptualni model web
aplikacije. Analiza valjanosti odnosno točnosti modela mjerenja metode OO-HFP je izvedena
usporedbom s drugim skupom web mjera (Tukutuku mjerenja [101]) koje su prethodno u
prošlosti već potvrĎena kao dobar procjenitelj točnosti.
Metoda OO-HFP uključuje četiri aktivnosti za svoju uspješnu realizaciju: definiranje
ciljeva, karakterizacija koncepata koji će se mjeriti, definiranje ili odabir metamodela i
definiranje numeričkih vrijednosti pravila. Entitet koji se mjeri je sastavljen od konceptualnog
modela dobivenog metodom OO-H. Model se sastoji od UML dijagrama klasa i navigacijskih
dijagrama (engl. Navigation Access Diagram, NAD) kojima se identificiraju struktura i
navigacijska pravila web aplikacije. Automatizacija metode je podrţana alatom VisualWADE
[100] unutar kojeg se takoĎer obavlja i modeliranje web aplikacije tako da se izračun
funkcionalne veličine nakon dizajna aplikacije moţe dobiti automatski.
4.11. Metoda OO-H COSMIC Function Points (OO-HCFP)
Abrahão i suradnici predloţili su još jednu metodu za procjenu veličine web aplikacija
baziranu na metodi OO-H [6], [100]. Za razliku od prethodne, ova metoda za izračun koristi
mjernu metodu COSMIC umjesto metode IFPUG. Autori su definirali pravila za COSMIC-
41
ovu mjernu proceduru uz primjenu OO-H konceptualnih modela. Ova metoda koristi metodu
OO-H koja ima dva konceptualna modela: UML dijagram klasa za prikaz zahtjeva za
sadrţajem i ponašanjem aplikacije te navigacijski dijagram za predstavljanje navigacijskih
zahtjeva. Za metodu nije uraĎena validacija rezultata mjerenja, nego je paţnja bila posvećena
za dvije aktivnosti: dizajn i primjena COSMIC-ove mjerne procedure uz uporabu procesnog
modela za mjerenje softvera. Budući razvoj ove metode predviĎa validaciju metode za
procjenu napora za razvoj web aplikacija i usporedbu s drugim metodama. Osim toga, autori
su najavili da će ova metoda, kao i prethodna, biti automatizirana pomoću alata
VisualWADE.
4.12. Metoda OO-Method COSMIC Function Points (OOmCFP)
OOmCFP [102] je mjerna procedura koja je dizajnirana za mjerenje funkcionalne veličine
objektno-orijentiranih aplikacija generiranih na bazi konceptualnih modela.
OO-Method [14] koja se koristi u ovom pristupu omogućava automatsko generiranje
aplikacija na bazi konceptualnih modela. Metoda ima formalnu definiciju podrţanu od strane
OASIS [103], koja je objektno-orijentirana, formalna specifikacija jezika za informacijske
sustave.
OO-Method prevodilac modela (engl. compiler) generira aplikaciju u skladu s troslojnom
arhitekturom i sastoji se od: klijentske komponente koja sadrţi grafičko korisničko sučelje,
posluţiteljske komponente koja sadrţi poslovna pravila i sloj za pristup bazi podataka, koji
sadrţi metode za smještanje i dohvat podataka iz baze podataka.
Softverski proizvodni proces OO-Method je prezentiran kroz tri modela:
Model zahtjeva: specificira zahtjeve sustava.
Konceptualni model: prikazuje statične i dinamične osobine funkcionalnih zahtjeva
sustava u odnosu na objektni, dinamički i funkcionalni model. Ovakav konceptualni
model posjeduje sve neophodne informacije potrebne za automatsko generiranje
softverske aplikacije.
Izvršni model: omogućava prelazak iz prostora problema (prikazano konceptualnim
modelom) prema prostoru rješenja (odgovarajući softverski proizvod).
Za metodu OOmCFP koristi se samo konceptualni model na osnovu kojeg se mjeri
funkcionalna veličina kroz odgovarajući mjerni proces. Osim toga, mjerna procedura ima alat
kojim je omogućeno automatizirano mjerenje funkcionalne veličine softverske aplikacije.
Ključna prednost ove metode uz korištenje COSMIC metode za mjerenje funkcionalne
42
veličine u odnosu na druge metode kao što su IFPUG FPA, NESMA FPA ili MK II FPA je ta
što COMSIC omogućava mjerenje funkcionalne veličine višeslojnih arhitektura s različitih
točaka gledišta.
U studiji De Marco i suradnika [104] autori su analizirali studije koje su koristile FSM
metode prve generacije za procjenu veličine web aplikacija i naglasili su neke od nedostataka
primjene ovih metoda. TakoĎer, predloţili su da se za mjerenje veličine web aplikacija koriste
neke druge metode, kao što je metoda COSMIC.
Nakon provedenih analiza u ovom i prethodnom polgavlju izvodi se zaključak da se
kombiniranjem metoda za procjenu funkcionalne veličine web aplikacija i metoda za kreiranje
konceptualnih modela ostvaruju preduvjeti za kreiranje modela procjene teţine razvoja web
aplikacija u fazi definiranja zahtjeva korisnika. Studije De Marco i suradnika [104] i studija
[105] ukazuju na činjenicu da primjena COSMIC mjerne metode za procjenu funkcionalne
veličine i teţine razvoja web aplikacija daje najtočnije rezultate kada je ova procjena u
pitanju. Stoga se kombiniranjem mjerne metode COSMIC za izračun funkcionalne veličine
web aplikacija zajedno s konceptualnim modelima web aplikacija stvaraju preduvjeti za
kreiranje modela procjene teţine razvoja web aplikacija u ranoj fazi razvoja web aplikacija, tj.
fazi definiranja zahtjeva web aplikacija.
43
5. KREIRANJE KONCEPTUALNIH MODELA WEB APLIKACIJA
U ovom poglavlju opisane su neke od aktualnih metoda za modeliranje web aplikacija kao
i one koje su najviše u primjeni u današnjem razvoju web aplikacija.
5.1. OOHDM
Hipermedijske aplikacije uključuju kompleksne informacije i omogućavaju sofisticirano
navigacijsko ponašanje. Metoda Object-Oriented Hypermedia Design Method (OOHDM)
[69], [106] je pristup za razvoj web aplikacija baziran na hipermedijskom modelu. Metoda
omogućava dizajneru da specificira web aplikaciju kao instancu hipermedijskog modela uz
korištenje nekoliko dodatnih specijaliziranih metamodela. Modeli se razvijaju na osnovi
objektno orijentiranih principa i elemenata, kao što su klase i objekti. Za razvoj se ujedno
koriste i objektno orijentirani apstrakcijski mehanizmi, kao što su agregacija i nasljeĎivanje
kako bi se opisali i razvili elementi svakog od modela. Svaki od modela je usmjeren na
drugačiji aspekt razvijane aplikacije. Jednom kada su ovi modeli specificirani za ţeljenu
aplikaciju, moguće je generirati izvršni kod aplikacije koja se razvija [107].
U tablici 5.1, prikazan je pregled OOHDM metodologije sa koracima odnosno slijedom
izvršavanja aktivnosti.
44
Tablica 5.1. Kratak pregled OOHDM metodologije [107].
Koraci (slijed) Produkti Mehanizmi Dizajn
Klase, pod-sustavi,
veze, atributi.
Klasifikacija,
kompozicija,
generalizacija i
poboljšanje.
Modeliranje
semantike domene
primjene aplikacije.
Čvorovi, poveznice,
pristupne strukture,
navigacijski
kontekst,
navigacijske
transformacije (s
jedne stranice na
drugu stranicu).
Preslikavanje
izmeĎu
konceptualnih i
navigacijskih
objekata.
Razmatranje profila
i zadataka korisnika.
Naglasak na
kognitivne aspekte.
Kostur aplikacijskog
sučelja, odgovori na
vanjske dogaĎaje,
transformacija
sučelja.
Preslikavanje
izmeĎu
navigacijskih i
vidljivih objekata.
Modeliranje
vidljivih objekata,
implementacija
odabranih metafora
sučelja. Opis sučelja
za navigacijske
objekte.
Pokretanje konačne
aplikacije.
Omogućeni
(podrţani) od strane
okruţenja u kojem
se implementira
aplikacija.
Performanse,
potpunost.
1. Analiza područja primjene (engl. Domain Analysis). U ovom koraku se kreira
konceptualni model aplikacije u odreĎenoj domeni korištenjem opće poznatog
objektno orijentiranog principa za modeliranje [108]. Posebna briga posvećuje se
samo semantici područja primjene aplikacije, a ne i tipovima korisnika i zadacima.
Konačni proizvod u ovom koraku je konceptualna shema sastavljena od podsustava,
klasa i veza (engl. relationships).
45
2. Navigacijski dizajn. Ovdje je opisana navigacijska struktura hipermedijskih aplikacija
pomoću navigacijskih klasa kao što su čvorovi (engl. Nodes), poveznice (engl. Links),
indeksi (engl. Indices) i voĎene smjernice (engl. Guided Tours). Navigacijski kontekst
i klase uzimaju u obzir tipove korisnika i skupove zadataka koje korisnici sustava
mogu izvršiti. Čvorovi u OOHDM-u predstavljaju logičke poglede (engl. views) na
konceptualne klase definirane tijekom analize domene (područja primjene). Za istu
konceptualnu shemu mogu biti napravljeni različiti navigacijski modeli kako bi
prikazali različite poglede za istu domenu. Poveznice su izvedene iz konceptualnih
veza definiranih u koraku 1. Definiranjem navigacijske semantike u smislu čvorova i
poveznica moţemo dobiti sliku navigacijskog prostora (npr. skup čvorova s kojima
korisnici mogu biti u interakciji) neovisno o konceptualnom modelu.
3. Dizajn apstraktnog sučelja. Model apstraktnog sučelja je napravljen definiranjem
vidljivih objekata u smislu klasa korisničkog sučelja. Klase su definirane kao
agregacija primitivnih (kao što su tekstualna polja, dugmad itd.) ili drugih klasa
sučelja. Ponašanje sučelja je definirano specifikacijom vanjskih i korisnički
generiranih dogaĎaja kojima se opisuje kako se odvija komunikacija izmeĎu objekata
sučelja i navigacije.
4. Implementacija. Nakon što je specificirano apstraktno sučelje, hipermedijska
aplikacija moţe biti implementirana. Apstraktno sučelje se preslikava u stvarne
objekte pomoću kojih se kreira aplikacija.
5.2. WebML
Web jezik za modeliranje (engl. Web Modeling Language, WebML) [5] predstavlja
notaciju za specificiranje kompleksnih web stranica na razini konceptualnog modela. Ova
metoda omogućava opis web stranica na visokoj razini promatrano iz različitih perspektiva.
Svi koncepti WebML-a su prikazani grafičkom notacijom i tekstualnom XML (EXtensible
Markup Language) datotekom. Specifikacija WebML-a je nezavisna od programskog jezika
upotrjebljenog za implementaciju aplikacije. WebML koncept je uparen s intuitivnim
grafičkim prikazom, koji moţe vrlo lako biti podrţana nekim CASE (engl. Computer-aided
software engineering) alatom, što je i uraĎeno kroz alat WebRatio [99] koji podrţava grafičko
modeliranje web aplikacija uz uporabu WebML-a. Alat takoĎer podrţava i automatizaciju
mjerenja uz odgovarajući dodatak [67].
WebML se sastoji od četiri modela:
46
1. Strukturalni model (engl. Structural Model), koji predstavlja podatkovni dio stranice,
u smislu relevantnih entiteta i njihovih veza. WebML ne predlaţe novi jezik za
modeliranje podataka, nego je kompatibilan sa standardnim notacijama kao što su E/R
model [109], ODMG (Object Data Managemet Group) objektno orijentirani model
[110] i UML dijagram klasa [111].
2. Hipertekstualni model (engl. Hypertext Model), opisuje jedan ili više hipertekstova
koji mogu biti publicirani na stranici. Svaki različiti hipertekst definira drugačiji izgled
stranice (engl. site view). Svaka stranica se sastoji od dva pod modela: kompozitni
(engl. Composition Model) i navigacijski model (engl. Navigational Model).
Kompozitni model specificira od kojih stranica je sastavljen hipertekst, a koje
modularne jedinice čini stranicu. Postoji šest tipova modularnih jedinica od koji se
moţe sastojati stranica: podaci, višestruki podaci, indeks, filtar, klizač (engl. scroller)
tj. navigacijska kontrola koja se u WebML-u naziva klizač, i poveznice izmeĎu dva
semantički povezana objekta (engl. direct units). Navigacijski model prikazuje na koji
način su stranice i modularne jedinice povezane tako da formiraju hipertekst.
3. Prezentacijski model (engl. Presentation Model) prikazuje strukturni izgled i grafički
prikaz stranica neovisno od programskog jezika uz pomoć kojeg se vrši renderiranje
(generiranje) prikaza stranice uz pomoć apstraktne XML sintakse.
4. Personalizacijski model (engl. Personalization Model), modelira eksplicitno korisnike
i korisničke grupe u strukturalnoj shemi u formi predefiniranih entiteta nazvanih
Korisnik (engl. User) i Grupa (engl. Group). Osobine ovih entiteta mogu se koristiti za
smještanje podataka specificiranih za neku grupu ili individualne korisnike, kao na
primjer preporuke za on-line kupovinu nekih proizvoda, skup najdraţih web sjedišta
itd.
5.3. Object-Oriented-Hypermedia metoda (OO-H)
Prateći trendove prezentirane u radovima Manolla [112] i Conallen [113], metoda OO-H
[6] promatra web sustave kao jedinstvene softverske cjeline gdje su struktura, ponašanje i
prezentacija osnovni dijelovi koji moraju biti kombinirani na odgovarajući način za dobivanje
ispravnog softverskog proizvoda. Glavni doprinos metode OO-H je pruţanje klasičnog
okruţenja za identifikaciju svih relevantnih osobina uključenih u modeliranje i
implementaciju sučelja web aplikacija i njihovo povezivanje s postojećim logičkim modulima
47
aplikacije. Za postizanje ovog cilja, metoda OO-H je bazirana na metodi OO-Method [92],
[114].
Metoda OO-H proširuje poglede (engl. views) metode OO-Method s dva nova
komplementarna dijagrama: navigacijskim i prezentacijskim dijagramima. Navigacijski
dijagram (engl. Navigational Access Diagram, NAD) definira navigacijske poglede, a
apstraktni prezentacijski dijagram (engl. Abstract Presentation Diagram, APD) okuplja
koncepte vezane za prezentacijski dio modela. Oba dijagrama identificiraju informacije
vezane za dizajn sučelja pomoću skupa predloţaka. Prateći filozofiju metode OO-Method,
metoda OO-H posjeduje CASE alat [6] za dizajniranje aplikacija koji sadrţi i prevodilac
(engl. compiler) modela koji generira prezentacijsko sučelje internetske aplikacije za ţeljenu
platformu i/ili programski jezik (HTML, XML, Wireless Markup Language, ili WML).
Metoda OO-H uključuje sljedeći skup notacija, tehnika i alata pomoću kojih je moguće
pristupiti fazi modeliranja web proizvoda: proces dizajna (engl. design process), katalog
predloţaka (engl. pattern catalog), NAD, APD i CASE alat koji omogućava automatizaciju
razvoja web aplikacija modeliranih pomoću metode OO-H.
Shematski prikaz metode OO-H, dat je na slici 5.1.
Slika 5.1. Pregled OO-H metode [6].
5.4. W2000
Modeliranje kompleksnih web aplikacija moţe se postići korištenjem metode W2000 [70],
[7]. Ova metoda je bazirana na preciznom metamodelu koju karakteriziraju različiti elementi
za notaciju kao i veze izmeĎu njih. W2000 potječe od HDM (engl. Hypertext Design Model)
[115], ali takoĎer u sebi sadrţi i principe UML-a [116] za podršku ideje o poslovnim
48
procesima. W2000 omogućava dizajneru aplikacija da modelira sve aspekte web aplikacija,
od web stranica do poslovnih transakcija, na dosljedan i cjelovit način. TakoĎer, adaptira
pristup voĎen modelom (engl. Model-driven development, MDD) tako da omogući
dizajnerima da inkrementalno obogate svoje modele i da bez problema izvrše prijelaz sa
specifikacija na dizajn aplikacija.
W2000 potiče odvajanje koncepata i prilagoĎava se obrascu MVC (engl. Model-View-
Controller, MVC). Cjelokupni W2000 model je organiziran kroz četiri modela: informacije
(engl. information), navigacija (engl. navigation), servisi (engl. services) i prezentacija (engl.
presentation). Informacija definira podatke korištene od strane aplikacije i percipirane od
strane korisnika. Model navigacije i model servisa specificiraju kontrolu, tj. kako se korisnik
moţe kretati kroz informacijske elemente i izmijeniti ih kroz uporabu odgovarajućih
poslovnih procesa.
Prezentacijski model prikazuje kako su podaci i servisi prikazani korisniku, tj. specificira
stranice i aktivacijske točke za poslovne servise.
5.5. UML za web inţenjering (UWE)
UML za web inţenjering (engl. UML-based Web Engineering, UWE) [71] se pojavio
krajem 1990-tih [117], [118] s osnovnom idejom da se pronaĎe standardni način za kreiranje
modela za analizu i dizajn web sustava bazirano na metodama OOHDM [4], RMM [119] i
WSDM [120]. Osnovi cilj je bio da se za modeliranje aplikacija koristi neki standardni jezik
ili da se barem definira metamodel za preslikavanje izmeĎu postojećih pristupa [118].
Prihvaćenost UML-a kao standarda u razvoju softverskih sustava i mogućnost proširenja
dodacima (engl. plugins) su osnovni razlog zašto je UML kao jezik odabran umjesto
korištenja neke druge tehnike modeliranja. Za razmjenu kreiranih modela, UWE koristi XMI
(engl. XML Metadata Interchange) format zapisa modela, a za meta-modeliranje koristi MOF
(engl. Meta-Object Facility).
UWE je objektno orijentiran, iterativan i inkrementalan. Baziran je na procesu za razvoj
softvera (engl. Unified Software Development Process ili Unified Process) [121] i pokriva
cjelokupni ţivotni ciklus web aplikacija usmjeravajući se ka dizajnu i automatskom
generiranju elemenata [122]. UWE notacija koja se koristi za analizu i dizajn je dodatak
UML-u koja omogućava uključivanje novih stereotipova potrebnih za opis elemenata modela
web aplikacija [123]. Ovi elementi za modeliranje se koriste za vizualnu prezentaciju
49
korisničkih zahtjeva u fazi dizajna konceptualnog modela, navigacijske strukture, poslovne
logike i prezentacijskih aspekata web aplikacije.
Nadogradnja (engl. extension) UML metamodela sastoji se od dodavanja jednog glavnog
paketa UWE koji je sačinjen od tri UML pod-paketa. Ovaj UWE paket sadrţi sve elemente
UWE modela, koji su podijeljeni u podpakete (slika 5.2a). Struktura paketa unutar UWE
paketa je analogna strukturi UML-ovog glavnog paketa. Paket Foundation sadrţi sve osnovne
statične elemente modela. Paket BehavioralElements ovisi od paketa Foundation i sadrţi sve
elemente potrebne za modeliranje ponašanja aplikacije. Paket ModelManagement takoĎer
ovisi od paketa Foundation i sadrţi sve elemente potrebne za opis modela specifičnih za
UWE. Navedeni UWE paketi ovise o odgovarajućim UML-ovim glavnim paketima. Slika
5.2b prikazuje dio metamodela UWE-ovih klasa u paketu Foundation [124].
(a) UWE metamodel ugraĎen u UML metamodel.
50
(b) Dio UWE metamodel klasa.
Slika 5.2. UWE metamodel.
UWE je podrţan kroz CASE alat ArgoUWE [125] (sada postoji i MagicUWE [8] kao
dodataka MagicDraw alatu [126]).
ArgoUWE omogućava sljedeće procese dizajna: konceptualni, navigacijski i prezentacijski
dizajn. U skorije vrijeme, UWE je evoluirao prema razvoju baziranom na modelu (engl.
Model-Driven Development, MDD) pristupu [127].
Sljedeći metamodeli su zastupljeni u slučaju UWE:
Model zahtjeva (engl. Requirements model): identificiran je sa slučajevima korištenja
(engl. Use cases), opisan pomoću case dijagrama i uz mogućnost dodavanja više
detaljnijeg tekstualnog opisa.
Konceptualni model (engl. Conceptual model): kreira se pomoću dijagrama klasa koji
opisuju entitete modela (objekti koji se odnose na područje rada aplikacije). Ovaj model
je osloboĎen od elemenata koji se odnose na navigaciju, prezentaciju ili interakciju.
Navigacijski model (engl. Navigation model): namijenjen prikazu osnovne navigacijske
strukture aplikacije.
Prezentacijski model (engl. Presentation model): namijenjen opisu „gdje i kako će
navigacijski objekti i osnovne operacije pristupa (engl. access primitives) kao što su
primjerice izbornici ili upiti koji generiraju neki sadrţaj koji korisnik moţe odabrati za
pregled) biti prezentirane krajnjem korisniku―. Sastoji se od stereotipa klasa
kompozicijskog dijagrama, koji pokazuje koja instanca kojeg tipa dodataka je prikazana
unutar koje prezentacijske klase.
51
Model zadatka (engl. Task model): formuliran je kroz ili dijagrame stroja stanja ili
dijagrame aktivnosti. Njegova svrha je da pruţi detalje vezano za navigacijsku strukturu
tako što će pruţiti dogaĎaje koji će pokrenuti tranzicije, definirajući ograničenja i
uključujući akcije koje se trebaju izvesti.
Razvojni model (engl. Deployment model): fizička struktura sustava je specificirana
kroz razvojni dijagram pokazujući koji će „čvorovi― biti razvijeni (čvorovi su računalno
aktivni resursi, obično implementirani kroz procese operativnog sustava) i njihove veze.
Detaljnije i dobro objašnjeno korištenje UWE elemenata i transformacija moţe se naći u
[128] i na web stranici projekta [8].
U modelu za procjenu teţine razvoja web aplikacija na osnovi konceptualnog modela
predloţenom u okviru ove disertacije, primijenjena je mjerna metoda COSMIC na UWE
model poslovnog procesa web aplikacije. Nakon analize svih alternativnih modela, došlo se
do zaključka da UWE model poslovnog procesa predstavlja najprikladniji model za brojanje
kretanja podataka [88].
52
6. KREIRANJE UWE MODELA I PRIMJENA MJERNE METODE COSMIC
U poglavlju 6.1 predstavljen je opis nekih od postojećih metoda kao i njihove moguće
nadogradnje ili adaptacije za izgradnju novog modela za procjenu teţine razvoja web
aplikacija. Poglavlje 6.2 predstavlja početak prikaza izvedbe novog modela za procjenu teţine
razvoja web aplikacija, a ujedno i početak prikaza znanstvenog doprinosa ove disertacije.
Osnovna svrha konceptualnih modela web aplikacija je pomoć u procesima dizajna i
implementacije te da posluţe kao smjernice za verifikaciju zahtjeva koje buduća aplikacija
treba ispuniti. Modeli web aplikacija moraju biti dovoljno detaljni tako da se identificiraju sve
karakteristike zahtjeva koji trebaju biti implementirani u web aplikaciji. Ovako postavljeni
uvjeti u procesu razvoja web aplikacija baziranom na konceptualnim modelima zahtijevaju
korištenje alata za modeliranje koji dovoljno detaljno mogu prikazati ono što je potrebno
razviti u web aplikaciji [88]. Jedan od takvih alata je MagicUWE [8] koji pri modeliranju web
aplikacija koristi metodu UWE [71], [127]. Metoda UWE se zasniva na principu razdvajanja
modela web aplikacije na više sastavnih dijelova (sadrţaj, navigacija, procesi itd.), od kojih
svaki ima svoju ulogu u cjelokupnom sustavu (modelu). Ovaj princip omogućava da se model
web aplikacije podijeli u podmodele, od analize zahtjeva do strukture procesa [71], [88]. U
modelu za procjenu teţine razvoja web aplikacija razvijenom u okviru ove disertacije,
korišteni su sljedeći podmodeli: model slučaja korištenja (engl. Use Case Model), model
sadrţaja (engl. Content Model), model navigacije (engl. Navigation Model) i model procesa
(eng. Process Model). Svaki od ovih podmodela ima svoj zadatak u svrhu kompletiranja
cjelokupnog procesa koji se tiče implementacije korisničkih zahtjeva u obliku završnog
modela web aplikacija na osnovu kojeg se kreira finalna web aplikacija.
Uz pomoć metoda baziranih na funkcionalnoj veličini moţe se već na početku razvojnog
procesa izvršiti procjena veličine softverskog proizvoda i indirektno izračunati ili procijeniti
napor potreban za razvoj softvera, što nije slučaj s većinom drugih metoda [88].
Kombiniranjem konceptualnih modela za modeliranje zahtjeva korisnika i mjera funkcijske
veličine za izračun veličine softvera, dobiva se snaţan alat za procjenu teţine razvoja softvera
u najranijoj mogućoj fazi, a to je faza analize zahtjeva [88].
U [104] autori su analizirali studije koje su koristile FSM metode prve generacije.
Primjenjivost ove metode u oblasti procjene teţine razvoja web aplikacija i njena prednost u
odnosu na FPA metode je potvrĎena ponovo u drugoj studiji De Marco i suradnika [105].
Metoda COSMIC ima snaţnu primjenjivost kod procjene veličine višeslojnih softverskih
53
arhitektura. S obzirom da su web aplikacije većinom bazirane na višeslojnim arhitekturama,
primjena metode COSMIC je više nego opravdana. Metoda COSMIC se lako uči, stabilna je,
relativno jeftina za implementaciju [88] i dobro prihvaćena od strane osoblja uključenog u
proces procjene veličine softvera zbog svoje prilično jednostavne mogućnosti za kreiranje
pravila za mjerenje veličine softvera sukladno zahtjevima modernih softverskih arhitektura.
Ovom metodom moguće je napraviti napredak u točnosti procjene veličine softvera, posebno
kada su u pitanju veliki projekti. TakoĎer, COSMIC omogućava mjerenje softvera na osnovi
postavljenih zahtjeva pomoću CASE alata [129], [130] što vodi ka kreiranju alata za
automatizaciju procesa procjene teţine razvoja web aplikacija i smanjivanju mogućnosti
pogreške prilikom svih potrebnih izračuna [88]. Metoda COSMIC je bazirana na brojanju
kretanja podataka koji su većinom zastupljeni u poslovnim aplikacijama i obično je najveći
napor uloţen za razvoj i implementaciju takvih funkcionalnosti web aplikacija [9], [10].
6.1. Mjerenje funkcionalne veličine web aplikacija na bazi COSMIC metode
Jedna od osnovnih osobina dinamičkih web aplikacija je velika količina kretanja podataka
(od strane korisnika ka skladištu podataka i obratno). Zbog ove činjenice, ovakve aplikacije su
pogodne za mjerenje pomoću metode COSMIC [63]. Da bi se primijenio mjerni proces,
softverski kontekstni model metode COSMIC se moţe prilagoditi kao što je prikazano u radu
[9] sukladno UWE pristupu. UWE je bio jedan od prvih projekata namjenski kreiran za
potrebe modeliranja web aplikacija koji koristi čisti UML profil proširen sa stereotipovima za
web aplikacije [71]. Osnovni tipovi artefakata UWE metode su: model zahtjeva (engl.
requirements model), model sadrţaja (engl. content model), navigacijski model (engl.
navigation model), prezentacijski model (engl. presentation) i model procesa (engl. process
model). Alat koji podrţava UWE pristup je MagicUWE [8], implementiran kao dodatak
MagicDraw alata [126]. Dodatna i detaljna objašnjenja vezana za korištenje UWE elemenata
kao i mogućih transformacija, mogu se pronaći u [128] kao i na web stranici projekta [8].
Softverski kontekstni model prilagoĎen za uporabu s metodom COSMIC za mjerenje
hipermedijskih sustava korišten u [131], prikazan je na slici 6.1. U ovom modelu, web
posluţitelj se smatra kao element za stalno smještanje podataka.
54
Slika 6.1. Funkcionalni protok podatkovnih atributa putem web aplikacije korišten u [131].
U ovoj disertaciji, korišten je pristup baziran na generičkom softverskom modelu
prezentiranom u radu [9] osim što su umjesto dijagrama slučaja (engl. use case) i dijagrama
toka procesa (engl. process flow) korišteni dijagrami slučaja i dijagrami aktivnosti (engl.
activity diagrams) za potrebe analize zahtjeva sa posebnim stereotipovima za web aplikacije.
6.2. Kreiranje UWE modela za potrebu procjene teţine razvoja web aplikacija
UWE je objektno orijentirana inţenjerska metoda bazirana na UML-u koja se koristi za
specifikaciju web aplikacija. U ovoj disertaciji, u svrhu kreiranja modela za procjenu teţine
razvoja web aplikacija, korištena su četiri glavna modela3: model zahtjeva (engl. requirements
model), model sadrţaja (engl. content model), model navigacije (engl. navigation model) i
model procesa (engl. process model).
Osnovni funkcionalni zahtjevi korisnika prikazuju se modelom zahtjeva koji izgleda kao
klasični UML dijagram slučaja korištenja. Mjerenje korištenjem metode COSMIC bazirano
na funkcionalnim zahtjevima korisnika tako da je ovaj model startna točka za modeliranje
cjelokupne web aplikacije. Primjer jednog modela zahtjeva kreiranog uz pomoć UWE alata
MagicUWE, prikazan je na slici 6.2.
3 Prezentacijski model se ne koristi jer nije neophodan za izračunavanje CFP i kreiranje modela procjene.
55
Slika 6.2. Model zahtjeva kreiran uz pomoć UWE alata MagicUWE.
Model sadrţaja se kreira za potrebe identifikacije svih podatkovnih grupa koje će biti
korištene u planiranoj web aplikaciji. Ove podatkovne grupe imaju bitnu ulogu u cijelom
procesu modeliranja web aplikacija zato što suštinski predstavljaju elemente kretanja
podataka koji se identificiraju u svrhu izračuna CFP. Primjer modela sadrţaja dat je na slici
6.3. Model sadrţaja je sačinjen od dijagrama klasa gdje svaka klasa sadrţi sve informacije
vezane za jednu podatkovnu grupu, atribute korištene u tim podatkovnim grupama i podatke
koji su od značaja za korisnike ili za identifikaciju trenutno kreiranih (nemaju karakter stalno
kreirane grupe podataka jer se kreiraju po potrebi) tranzijentnih grupa podataka koje će biti
korištene unutar funkcionalnih procesa.
56
Slika 6.3. Model sadrţaja UWE metode.
Nakon kreiranja modela zahtjeva i modela sadrţaja, kreira se model navigacije. Ovaj
model predstavlja shemu web aplikacije, s pozicioniranjem klasa koje opisuju procese i
navigaciju, izbornike (engl. menues), čvorove (engl. nodes), koji mogu biti navigacijski ili
procesni, zatim liste indeks elemenata (lista opcija koje ima neka klasa), navigacijske (engl.
navigational links) i procesne poveznice (engl. process links). Navigacijske poveznice
prikazuju mogućnost navigacije izmeĎu dva procesa, bez provoĎenja neke akcije, dakle samo
prelazak s jednog na drugi element. Procesne poveznice omogućavaju aktivaciju klase
procesa na koju upućuje procesna poveznica. Model navigacije omogućava shematski prikaz
povezivanja klasa procesa i navigacije u planiranoj web aplikaciji. Primjer modela navigacije,
dat je na slici 6.4.
57
Slika 6.4. Model navigacije UWE metode (dio dijagrama).
Na kraju, kreira se jedan od najvaţnijih modela a to je model procesa. Ovaj model je
podijeljen na dva podmodela: model strukture procesa (engl. process structure model) i model
toka procesa (engl. process flow model). Model strukture procesa prikazuje sve potencijalne
funkcionalne procese opisane uz pomoć klasa procesa koji se mogu pojaviti u web aplikaciji
(slika 6.5). Neki od primjera klasa procesa u nekoj klasičnoj web aplikaciji bi bili: login user,
logout user, change password, update article info itd.
Slika 6.5. Model strukture procesa UWE metode (dio dijagrama).
58
Za svaku klasu procesa u modelu strukture procesa kreiran je model tijeka procesa. Model
tijeka procesa se kreira kao klasični UML dijagram aktivnosti s UWE elementima koji mogu
imati poseban dodatak. Ovi dodaci omogućavaju identifikaciju korisnika procesa, elemenata
sustava, elemenata za smještanje podataka, njihovu poziciju i implementaciju dodatnih
specijalnih oznaka unutar elemenata korisničkih stereotipova, kao što su liveValidation,
autoCompletion, autoSuggestion, submitChange ili neki od posebno definiranih tagova kao
što su tekst, slike, medijalne datoteke ili datoteke za sustav ili za elemente za smještanje
podataka koji se mogu koristiti za identifikaciju kretanja podataka po metodi COSMIC, kao
što su Entry ili Exit.
Model toka procesa posjeduje dva glavna UWE elementa označena kao UML stereotip:
<<userAction>> i <<systemAction>>. Kod ovog modela, početak procesa je prikazan
elementom <<initialNode>> koji je na slici 8.6 označen ispunjenim crnim krugom dok je
kraj procesa prikazan elementom <<ActivityFinalNode>> koji je na slici 6.6 označen s dva
koncentrična kruga od kojih je unutarnji ispunjen crnom bojom. Model toka procesa je
značajan dio sustava zato što omogućava identifikaciju toka podataka (engl. data flow), toka
izvršavanja procesa (engl. process flow) ili inicijalizaciju nekog dogaĎaja izmeĎu korisnika i
sustava (slika 6.6). Smjer toka podataka ili toka izvršavanja komandi izmeĎu ova dva UWE
elementa je definiran pomoću strelica koje označavaju procesne ili strelice toka podataka. Ove
strelice se unutar XMI zapisa identificiraju kao object flow za tok podataka i control flow za
tok izvršavanja procesa. Primjer modela procesa, i to modela toka procesa dat je na slici 6.6.
59
Slika 6.6. Model toka procesa.
Nakon kreiranja prethodnih modela, ostvareni su preduvjeti za brojanje i sumiranje svih
kretanja podataka za web aplikaciju koja se mjeri. Da bi mjerenje bilo ispravno i uspješno,
potrebno je izvršiti brojanje svih kretanja podataka za svaki funkcionalni proces koji je
identificiran uz pomoć modela toka procesa nakon čega se moţe izračunati veličina web
aplikacije izraţena u obliku COSMIC-ovih funkcionalnih točaka.
Na slici 6.7, prikazan je tijek procedure kreiranja UWE modela u svrhu korištenja ovih
modela za procjenu teţine razvoja web aplikacija.
60
Slika 6.7. Slijed koraka za kreiranje UWE modela za potrebe procjene teţine razvoja web
aplikacija [88].
61
7. DIZAJN MJERNE PROCEDURE ZA IZRAČUN COSMIC‐OVIH FUNKCIJSKIH
TOČAKA
Slika 7.1 predstavlja generalni model kako se uopće provodi cjelokupni mjerni proces (od
dizajna metode do korištenja rezultata), tj. što je potrebno uraditi kako bi se dizajnirala,
primijenila i koristila bilo koja mjerna procedura ili neki mjerni proces, dok slika 7.2
predstavlja faze i aktivnosti mjerne metode COSMIC.
Slika 7.1. Općeniti mjerni model procesa – slijed izvršavanja radnji [132]. (Mjerni proces –
model na visokoj razini)
U skladu s mjernim modelom procesa (slika 7.1), potrebno je proći nekoliko koraka [132]:
Korak 1: Prije samog mjerenja, potrebno je dizajnirati mjernu metodu.
Korak 2: Pravila mjerne metode se primjenjuju na softver ili dio softvera.
Korak 3: Provodi se analiza mjernih rezultata.
Korak 4: Mjerni rezultat se koristi u kvantitativnom ili kvalitativnom modelu.
Faze i aktivnosti mjerne metode COSMIC shematski prikazano izgledaju kao na slici 7.2.
62
Slika 7.2. Faze i aktivnosti COSMIC mjerne metode [133].
Mjerni model procesa prethodno spomenut i prikazan na slici 7.1, u koraku 1 predviĎa
provoĎenje četiri aktivnosti za dizajn mjerne metode:
1.1. definiranje ciljeva,
1.2. karakterizacija koncepta koji će se mjeriti,
1.3. odabir metamodela, i
1.4. definicija pravila za označavanje ili dodjelu numeriranja.
Ove četiri aktivnosti za mjerni model procesa (koraci 1-4) sa svojim pod aktivnostima se
preklapaju sa fazama i aktivnostima COSMIC mjerne metode. To znači da se COSMIC faze i
aktivnosti (slika 7.2) nalaze u više podaktivnosti dizajna mjerne metode (slika 7.1, korak 1).
U nastavku rada biti će prikazani i objašnjeni koraci za dizajn mjerne procedure, a koji
predstavljaju korake 1-4 mjernog modela procesa. Na slici 7.3 prikazan je proces dizajna
mjerne procedure na kojem se moţe vidjeti na koji se način preklapaju COSMIC faze i
aktivnosti i koraci procesa dizajna mjerne procedure.
Modeliranje koraka vezanih za mjernu metodu prikazano na slici 7.3 temelji se na logičkoj
perspektivi i na spoznaji da su iterativna i uzastopna poboljšanja potrebna za unaprjeĎenje
63
prijedloga inicijalnog prijedloga dizajna metode mjerenja. TakoĎer se temelji na pretpostavci
da metoda mjerenja treba biti izgraĎena počevši od definiranja ciljeva, a da završava s
numeričkom karakterizacijom softverskih atributa.
Slika 7.3. Proces dizajna mjerne procedure [133], [134].
Mjerni proces po metodi COSMIC se sastoji od tri osnovne faze:
faza mjerne strategije unutar koje se COSMIC kontekstni model softvera (engl.
COSMIC Software Context Model) primjenjuje na softver koji se treba mjeriti;
faza preslikavanja u kojoj se COSMIC generički softverski model (engl. COSMIC
Generic Software Model) preslikava na softver koji je potrebno mjeriti;
faza mjerenja unutar koje se mjeri i dobiva stvarna veličina softvera.
Primjenom mjernog procesa na dio softverskog proizvoda nastaje mjera funkcionalne
veličine na osnovu funkcionalnih zahtjeva korisnika (engl. Functional User Requirements,
FUR) izraţena kao COSMIC Function Points (CFP) [10].
64
Da bi se provela procedura mjerenja konceptualnih modela, u okviru ove disertacije
definirana su pravila za potrebe identifikacije funkcionalnih korisnika i granica, funkcionalnih
procesa i grupa podataka, pravila za identifikaciju kretanja grupa podataka i pravila za
sumiranje funkcionalne veličine funkcionalnih procesa, i to:
3 pravila za identifikaciju funkcionalnih korisnika i granica,
1 pravilo za funkcionalne procese,
2 pravila za podatkovne grupe,
1 pravilo za atribute podataka,
9 pravila za identifikaciju kretanja podataka, i
2 pravila za sumiranje funkcionalne veličine funkcionalnih procesa.
Primjena metode zahtijeva identifikaciju dva modela: COSMIC kontekstnog softverskog
modela softvera i COSMIC generičkog softverskog modela.
Pomoću COSMIC kontekstnog softverskog modela uspostavlja se granica izmeĎu
aplikacije i operativnog okruţenja te se prikazuje generički funkcionalni tok podatkovnih
atributa (grupa podataka) iz funkcionalne perspektive. Tok podatkovnih atributa je
karakteriziran u dva smjera, pozadinski (engl. back-end) i frontalni (engl. front-end), s četiri
različita tipa kretanja: Entries i Exits, koji omogućavaju razmjenu podataka s korisnicima, i
Reads i Writes, koji omogućavaju razmjenu podataka s elementima za trajno smještanje
podataka.
COSMIC generički softverski model pretpostavlja da postoje generalno dva koncepta za
softver koji će se preslikavati i mjeriti:
1. softver uzima ulaz i proizvodi korisni izlaz za korisnika, i
2. softver upravlja dijelovima informacija odreĎenim kao podatkovne grupe koje se
sastoje od podatkovnih atributa.
COSMIC generički softverski model omogućava promatranje funkcionalnih zahtjeva
korisnika razgraĎenih na skup funkcionalnih procesa, gdje svaki funkcionalni proces izvodi ili
uzrokuje razmjenu podataka ili upravljanje podacima.
Za definiranje COSMIC mjerne procedure prilagoĎene za web aplikacije razvijene na bazi
konceptualnih modela uz pomoć metode UWE, uzima se u obzir procesni model za mjerenje
softvera prikazan na slici 7.1 a koji je predloţen od Jacquet i Abran [100], [132], [132].
65
7.1. Definiranje ciljeva
Za ispravno definiranje ciljeva, veoma je vaţno utvrditi ulazne artefakte za izvedbu
mjerenja i razinu detaljnosti koju moraju imati ovi artefakti da bi se izvelo mjerenje. Stoga,
korak definiranja ciljeva ima takoĎer veze s odreĎivanjem područja mjerenja (gdje je ulazni
artefakt specificiran uključujući njegove slojeve i dijelove softvera) i s odreĎivanjem razine
detaljnosti u fazi strategije COSMIC metode. Prvi korak prilikom kreiranja mjerne procedure
prema COSMIC-u je identificiranje vrste softvera, atributa koji se uzimaju u obzir, itd., te je
potrebno odrediti hoće li se mjerenje izvoditi s točke gledišta programera (koja sadrţi sve
funkcionalnosti koje je potrebno razviti) ili s točke gledišta korisnika (koja sadrţi skup
funkcija koje se razvijaju koje su potrebne korisniku) [132].
Namjena mjerenja
Namjenom mjerenja definira se zašto je mjerenje potrebno i za što će se rezultati koristiti
[10]. Namjena mora biti jasno definirana jer se na osnovu nje utvrĎuje koji su to najbolji ili
odgovarajući artefakti koje ćemo koristi za mjerenje. U ovoj disertaciji namjena mjerenja je
definirana kao potreba za odreĎivanje funkcionalne veličine web aplikacija na osnovi
konceptualnih modela u svrhu uporabe funkcionalne veličine za kreiranje modela za procjenu
teţine razvoja web aplikacija. Mjerni rezultati treba da uključuju izračun funkcionalne
veličine za sve funkcionalnosti s točke gledišta programera.
Područje mjerenja
Područje mjerenja definira skup funkcionalnih zahtjeva korisnika (FUR) koji će biti
uključeni u mjerni proces. Funkcionalni zahtjevi korisnika su definirani u ISO 14143-1 kao
podskup korisničkih zahtjeva [93]. Funkcionalni zahtjevi korisnika predstavljaju korisničku
praksu i procedure koje softver mora moći obaviti kako bi ispunio potrebe korisnika. Ovi
zahtjevi opisuju što softver treba da radi, u smislu zadataka i servisa. Ovo isključuje zahtjeve
za kvalitetom i bilo koje tehničke zahtjeve. Funkcionalni zahtjevi korisnika se odnose ali nisu
ograničeni na sljedeće stavke:
prijenos podataka (na primjer, unos podataka o kupcu u sustav, slanje kontrolnog
signala),
transformacija podataka (na primjer, izračun kamatne stope na bankovni kredit,
izračunavanje prosječne temperature),
66
smještanje podataka (na primjer, smještanje podataka o kupcu u sustav, biljeţenje
temperature okruţenja tijekom vremena),
čitanje podataka (na primjer, prikaz liste trenutnih uposlenika neke tvrtke,
dobavljanje informacije o posljednjoj poziciji aviona).
Primjeri zahtjeva korisnika koji nisu funkcionalni zahtjevi korisnika uključuju ali nisu
ograničeni na sljedeće:
ograničenja kvaliteta (na primjer, iskoristivost, pouzdanost, učinkovitost i
prenosivost),
ograničenja u smislu organizacije (na primjer, lokacije za operacije izvršavanja
zadataka, ciljane hardverske komponente, usklaĎenost sa standardima),
ograničenja u smislu operativnog okruţenja (na primjer, interoperabilnost,
osiguranje, privatnost i sigurnost),
ograničenja u smislu implementacije (na primjer, programski jezik korišten za
razvoj, raspored isporuke).
UWE mjerni proces koristi UWE konceptualne modele kao ulazni artefakt za mjerenje
funkcionalne veličine web aplikacija. Ovi konceptualni modeli formalno specificiraju
funkcionalne zahtjeve web aplikacije nezavisno od tehničkih karakteristika koje će imati
kreirana aplikacija. Područje mjerenja u ovom slučaju predstavlja UWE konceptualni model
koji se sastoji od četiri modela koji su prethodno opisani u poglavlju 5.5 i poglavlju 6. Model
procesa, a koji se sastoji od dva podmodela, i to modela strukture procesa (engl. process
structure model) i modela toka procesa (engl. process flow model), je najvaţniji model s
obzirom da se na osnovu njega definiraju sva pravila vezano za izračun funkcionalne veličine.
Svaki od ova dva podmodela moţe imati više dijagrama tipa dijagrama strukture procesa i
dijagram toka procesa pomoću kojih su prikazana ţeljena stanja sustava. Svaki od ovih četiri
modela, ima svoju ulogu u cjelokupnom sustavu i sadrţe sve potrebne informacije potrebne za
provoĎenje procesa mjerenja funkcionalne veličine web aplikacija. Nakon što je definirano
područje mjerenja (FUR), potrebno je definirati tj. utvrditi slojeve, dijelove softvera i vanjske
komponente (engl. peer components) koje čine cjelokupnu aplikaciju pri čemu su sloj i dio
softvera definirani prema COSMIC-ovom mjernom priručniku [10]:
Sloj (engl. layer): Sloj je particija koja je nastala kao rezultat funkcionalne
podijeljenosti softverske arhitekture koja zajedno s hardverom tvori cjelokupni
računalni sustav. Slojevi su organizirani u hijerarhiju te postoji samo jedan sloj na
67
svakoj razini u hijerarhiji. Postoji hijerarhijska ovisnost izmeĎu funkcionalnih servisa
omogućenih od strane softvera unutar slojeva.
Dio softvera (engl. pieces of software): Predstavlja programski kôd pojedinog dijela
softvera implementiran na svakom sloju.
Troslojna arhitektura s prezentacijskim aplikacijskim (poslovnim) i podatkovnim slojem je
način na koji su podijeljeni UWE konceptualni modeli, pa tako i model procesa na bazi kojeg
se obavlja mjerenje. Svaki dio ove strukture je hijerarhijski povezan s drugim slojevima.
Organizacija web aplikacije unutar UWE konceptualnog modela predstavljena je na
dijagramu aktivnosti vizualno podijeljenom u tri plivajuće staze: prezentacijski sloj koji je
prikazan pomoću korisničke plivajuće staze (engl. user swimlane), sloj poslovne logike koji je
prikazan pomoću sustavne plivajuće staze (engl. system swimlane) i podatkovni sloj koji je
prikazan pomoći podatkovne plivajuće staze (engl. storage swimlane).
Prezentacijski sloj koristi servise (usluge) poslovnog sloja jer je poslovni sloj direktno
ispod prezentacijskog sloja unutar hijerarhije. Na sličan način, poslovni sloj koristi servise
(usluge) podatkovnog sloja zato što je podatkovni sloj ispod poslovnog sloja u hijerarhiji. Ovi
slojevi odgovaraju definiciji slojeva COSMIC-ovog mjernog priručnika [10]. Na osnovi toga,
kod UWE pristupa razlikujemo tri sloja: klijentski sloj, koji sadrţi korisničko grafičko sučelje,
posluţiteljski sloj, koji sadrţi poslovnu logiku aplikacije i podatkovni sloj, koji predstavlja
stalno spremište podataka tj. bazu podataka ili neki drugi oblik sustava za pohranu podataka.
U svakom sloju UWE pristupa, postoji dio softvera koji izmjenjuje podatke s dijelovima
softvera drugih slojeva. Na slici 7.4 shematski su prikazani slojevi i dijelovi softvera UWE
modela web aplikacije koji je osnova za provoĎenje procesa mjerenja.
Slika 7.4. Dijelovi softvera i slojevi za primjenu procesa mjerenja.
68
Razina detaljnosti softvera
Kod UWE pristupa, s obzirom da se mjerenje obavlja na osnovi konceptualnih modela koji
imaju definirane svoje strukture procesa, metode i atribute uključene u ovaj proces, moţe se
smatrati da je razina zrnatosti (granularnosti) predstavljena upravo ovim konceptualnim
modelima.
7.2. Karakterizacije koncepta koji će se mjeriti
Karakterizacija koncepta koji će se mjeriti nije u svezi s bilo kojom fazom mjerne metode
COSMIC s obzirom da je mjerna metoda COSMIC dizajnirana za mjerenje funkcionalne
veličine softverskih aplikacija bez potrebe da karakterizira ili opisuje što funkcionalna
veličina znači u njenom mjernom procesu. Ovo je bitno spomenuti s obzirom da je na početku
poglavlja rečeno da se COSMIC faze i aktivnosti i koraci procesa dizajna mjerne procedure
preklapaju.
Elementi koji će se mjeriti su prikazani pomoću UWE konceptualnih modela. Ovi modeli
se sastoje od UML dijagrama klasa, UML dijagrama aktivnosti, i strukture procesa web
aplikacija. Mjerni elementi sadrţe sve potrebne sadrţaje na osnovu kojih je moguće izračunati
funkcionalnu veličinu web aplikacija.
7.3. Odabir metamodela
Na slici 7.5 prikazan je COSMIC metamodel koji je neophodan obzirom da se UWE treba
prilagoditi COSMIC metodi u svrhu kreiranja pravila za preslikavanje izmeĎu ova dva
koncepta i dizajniranja mjerne procedure.
Slika 7.5. Metamodel za COSMIC metodu [100], [135].
69
Metamodel sluţi za opis apstraktne sintakse jezika za modeliranje: strukturalne definicije
uključenih konceptualnih elemenata s njihovim osobinama, definicijama veza izmeĎu
različitih elemenata, i definicijama skupa pravila za kontrolu interakcije izmeĎu specificiranih
različitih elemenata[136].
Kod EMOF-a (engl. Essential Meta-Object Facility), metamodel je predstavljen pomoću
dijagrama klasa, gdje svaka klasa u dijagramu odgovara jednom elementu uključenog jezika
za modeliranje. Metamodel za FSM pruţa osnovu za dizajniranje mjernih pravila koji
identificiraju i mjere elemente sadrţane u metamodelu. Iako ne postoji sluţbeni metamodel
metode COSMIC na slici 7.5 je prikazan metamodel koji je u skladu sa metodom COSMIC i
mjernim priručnikom 3.0.1. Ovaj metamodel je odabran za dizajniranje mjerne procedure
zbog jednostavnosti izračuna funkcionalne veličine bez ograničenja na maksimalnu
vrijednost. Ovo nije slučaj s metodom IFPUG FPA kod koje postoji ograničenje maksimalne
moguće funkcionalne veličine.
Svaka podatkovna grupa ima skup atributa (engl. attributes) i objekte koji se promatraju
(engl. objects of interest). Svaki mjeritelj je usmjeren na skup objekata koji se promatraju.
Primjer objekata od interesa moţe biti grupa podataka s jedinstvenim skupom atributa koji
opisuju jedan objekt od interesa. Kod poslovnih aplikacija, objekt od interesa se identificira za
svaki tip entiteta koji se nalazi u normaliziranom podatkovnom modelu mjerenog softvera.
Svaka podatkovna grupa učestvuje u jednom ili više kretanja podataka (engl. data
movements), koji mogu biti kretanje podataka tipa Ulaz (Entry, E), Izlaz (Exit, X), Čitanje
(Read, R) ili Pisanje (Write, W).
Podaci su dio funkcionalnog procesa. Svaki funkcionalni proces koji je dio softvera je
iniciran (engl. triggered) nekim okidačem (engl. triggering events) od strane funkcionalnog
korisnika (engl. functional user). Prema ISO standardu korisnik je bilo koja osoba koja
specificira funkcionalne zahtjeve korisnika i/ili bilo koja osoba ili stvar koja komunicira ili je
u interakciji sa softverom u bilo koje vrijeme. Korisnik je odvojen od dijela softvera koji se
mjeri pomoću granice (engl. boundary). Svaki sloj dijela softvera je pridruţen jednom
okruţenju operativnog softvera (engl. operative software environment). Na kraju, područje i
namjena mjerenja odreĎuju razinu detaljnosti modela. Na osnovu slike 7.3 moţe se vidjeti da
se u koraku odabira metamodela provodi dio COSMIC faze preslikavanja. COSMIC fazom
preslikavanja vrši se identifikacija funkcionalnih procesa, podatkovnih grupa i atributa u
specifikaciji konceptualnog modela softvera zavisno od parametara definiranih u fazi
strategije. Na kraju, u ovom koraku, provodi se identifikacija kretanja podataka što pripada
COSMIC fazi mjerenja.
70
Identifikacija funkcionalnih korisnika i granica
Funkcionalni korisnici su korisnici koji su u interakciji sa sustavom koji se mjeri. Ovo su
korisnici koji izmjenjuju (šalju ili primaju) podatke s funkcionalnim procesima sustava.
Granica predstavlja konceptualno sučelje izmeĎu funkcionalnih korisnika i dijela softvera koji
se mjeri [10].
Kod primjene UWE pristupa, moguća je identifikacija sljedećih funkcionalnih korisnika za
UWE modelirane aplikacije: ljudski korisnici (engl. human users, klijentski dio softvera) i
vanjski sustavi (stare aplikacije ili aplikacije izvan softvera koji se mjeri) specificirani u
konceptualnom modelu. Ovi funkcionalni korisnici su odvojeni uz pomoć granice od dijela
aplikacije koja se mjeri (slika 7.6).
Slika 7.6. Prikaz granice izmeĎu funkcionalnih korisnika i softvera koji se mjeri, i smjera
kretanja grupa podataka [130].
Korisnici su kod UWE pristupa u dijagramu aktivnosti modela procesa predstavljeni
stereotipovima oblika <<userAction>>. Ovi korisnici su uglavnom ljudski korisnici koji šalju
ili primaju podatke od posluţiteljskog sloja i nazivaju se „ljudski funkcionalni korisnici― i
odvojeni su granicom od klijentskog sloja softvera. Na slici 7.7 prikazana je podjela korisnika
71
softvera na plivajuće staze kako bi se moglo vršiti mjerenje na osnovu dijagrama aktivnosti
UWE modela.
Slika 7.7. Podjela sustava koji se mjeri na segmente kod UWE modela korištenjem plivajućih
staza.
Da bi se identificirali funkcionalni korisnici i odgovarajuća granica, potrebno je definirati
sljedeća pravila:
Pravilo 1: Identificirati funkcionalnog korisnika za svaki stereotip <<userAction>>.
Pravilo 2: Identificirati funkcionalnog korisnika za svaki stereotip <<initialNode>>
za pokretanje ili iniciranje funkcionalnog procesa.
Pravilo 3: Identificirati granicu izmeĎu funkcionalnog korisnika (plivajuća staza user
swimlane) i posluţiteljskog sloja (koji se nalazi unutar plivajuće staze system
swimlane).
72
Identifikacija funkcionalnih procesa
Funkcionalni procesi su procesi koji su aktivirani nekim dogaĎajem na osnovu zahtjeva
kojeg inicira korisnik sustava [137].
Za podršku preslikavanja funkcionalnih procesa unutar UWE modela, potrebno je
uspostaviti pravila za točnu identifikaciju UWE elemenata koji se mogu upotrijebiti u procesu
mjerenja pomoću COSMIC metode.
Potrebe korisnika sustava mogu se identificirati pomoću dijagrama slučaja, iako postoji
vjerojatnost da pomoću ovih dijagrama nije uvijek moguće izvršiti preslikavanje sukladno
funkcionalnim procesima i njihovim zahtjevima. Stoga dijagrami slučaja se primjenjuju samo
u osnovnoj fazi identifikacije zahtjeva, a kasnije se koristi model procesa za detaljniju analizu
i kreiranje funkcionalnih procesa [88].
Na slici 7.8 prikazan je primjer dijagrama slučaja za web aplikaciju koji je korišten u svrhu
identificiranja funkcionalnih zahtjeva korisnika.
Slika 7.8. Primjer dijagrama slučaja korištenja sustava za registar kurikuluma, korišten za
identifikaciju funkcionalnih zahtjeva korisnika.
73
Funkcionalnosti koje treba osigurati krajnjem korisniku su prikazane pomoću modela
strukture procesa (engl. process structure model). Ovaj model se sastoji od klasa procesa
(slika 7.9) s metodama koje podrţavaju funkcionalnosti u skladu s potrebama korisnika
sustava.
Dvije vrste klasa procesa UWE konceptualnih modela se koriste za kreiranje navigacijskih
i procesnih modela, a to su: navigacijska klasa ( <<navigationClass>>) i klasa procesa
(<<processClass>>) (slika 7.10). Navigacijska klasa se koristi u modelu navigacije koji se
ne koristi direktno za preslikavanje prema dijagramima toka procesa, pa stoga ova klasa nema
direktnog utjecaja na izračun COSMIC funkcijskih točaka u dijagramu toka procesa.
MeĎutim, klasa procesa (slika 7.11) se koristi za preslikavanje prema dijagramu toka procesa
(engl. process flow diagram) modela toka procesa koji izvodi ţeljene akcije sukladno
potrebama korisnika sustava (slika 7.11).
Slika 7.9. Model strukture procesa sa klasama procesa u registru kurikuluma primjernoj web
aplikaciji.
74
Slika 7.10. Prikaz modela navigacije UWE konceptualnog modela u registru kurikuluma
primjernoj web aplikaciji.
Pored ostalog, klasa <<navigationClass>> daje informacije vezane za tok aktivnosti
korisnika i omogućava prikaz grananja klasa procesa unutar modela strukture procesa.
Na slici 7.11, prikazan je primjer vizualnog preslikavanja klase tipa <<processClass>>
naziva Login prema dijagramu toka procesa naziva takoĎer Login koji prikazuje tok podataka
i kontrole izvršavanja procesa za prijavu korisnika na sustav.
75
Slika 7.11. Preslikavanje klase tipa <<processClass>> naziva Login prema dijagramu toka
procesa naziva Login.
Identifikacija podatkovnih grupa i atributa
U slučaju dijagrama toka procesa (slika 7.12) mjerenje funkcionalne veličine je ostvareno
na osnovu identifikacije kretanja podatkovnih grupa izmeĎu <<userAction>> na korisničkoj
plivajućoj stazi i <<systemAction>> na sistemskoj plivajućoj stazi i
<<CentralBufferNode>> na plivajućoj stazi spremišta podataka.
76
Slika 7.12. Primjer dijagrama toka procesa UWE modela toka procesa.
Stereotip <<userAction>> predstavlja akcije inicijalizirane od strane korisnika (slika
7.12). Ove akcije, identificirane su tokom podataka tipa Entry, mogu biti, na primjer, unos
podataka kroz aplikacijsku formu, registracijska forma ako šaljemo podatke ka sustavu ili
samo prijava na sustav gdje korisnik unosi svoje korisničko ime i zaporku za pristup sustavu.
Ako su podaci koje treba prikazati korisniku u dinamičkoj formi (podrţano čitanje podataka iz
sustava ili baze podataka) onda treba identificirati tok podataka tipa Exit za prikaz izlaznih
podataka korisniku. Ako korisnik zahtijeva podatke koji ne moraju uključivati dinamičko
generiranje istih, onda ne postoji identifikacija kretanja podatka u skladu sa COSMIC
mjernim pravilima. Ovo znači da ako su podaci koje treba prikazati korisniku (npr. uz pomoć
padajuće liste) tvrdo kodirani, onda ne postoji identifikacija Exit kretanja podataka i ovo je
moguće identificirati samo kao dogaĎaj kod pokretanja neke akcije (engl. triggering event). U
ovom slučaju postoji tip kretanja podataka Entry koji predstavlja inicijalizacijsku komandu za
prikaz podataka korisniku sustava.
Stereotip <<systemAction>> predstavlja akcije koje se izvršavaju na strani posluţitelja
kao procesi (slika 7.12), npr. CheckUserPass, WriteLogForUser. Ove akcije uključuju
upravljanje podacima, provjeru integriteta podataka, slanje ili primanje podataka. U web
77
aplikacijama, stereotip <<systemAction>> predstavlja neke od standardnih funkcija koje se
izvršavaju na strani posluţitelja web aplikacija.
Stereotip <<displayAction>> predstavlja poruke koje se šalju od strane sustava ka
korisniku. Primjer bi bila poruka o postojećoj pogrešci, koja se generira kao odgovor na neki
dogaĎaj, npr. na osnovu pretrage. Ovim stereotipom ne vrši se identifikacija ili evidentiranje
Read ili Write kretanja podataka već samo Exit tip COSMIC kretanja podataka.
Stereotip <<CentralBufferNode>> predstavlja element za trajnu pohranu podataka (npr.
baza podataka). Ovaj stereotip je primjer elementa za smještanje podataka (slika 7.12). Svaka
izvorna ili odredišna točka toka podataka izmeĎu UWE stereotipova (na primjer,
<<userAction>>, <<systemAction>> i <<CentralBufferNode>>) predstavlja se
pravokutnikom na stereotipu (engl. pin element) i moţe biti tipa Read/Write što ovisi od toga
da li element šalje ili prima podatke (slika 7.12).
Podatkovne grupe predstavljaju grupe podataka koje se šalju ili primaju ka ili od stalnog
spremišta podataka, zatim grupe podataka koje se unose u sustav, ili neke tranzijentne
podatkovne grupe koje nisu stalno smještene unutar sustava za pohranu podataka (npr. poruke
koje su poslane ka <<userAction>> od strane <<systemAction>>). One se prikazuju
dijagramima sadrţaja kod UWE modela sadrţaja unutar konceptualne sheme web aplikacije.
Podatkovne grupe kod dijagrama sadrţaja su prikazane s njihovim pripadajućim atributima,
tipom i vrijednošću. Slika 7.13 prikazuje primjer UWE dijagrama sadrţaja s definiranim
podatkovnim grupama (Faculty, Subjects, User, StudyProgram i Curriculum).
Slika 7.13. Identifikacija podatkovnih grupa unutar UWE modela sadrţaja na primjeru
registra kurikuluma.
78
Podatkovni atributi predstavljaju elemente podatkovnih grupa i zajedno s njima čine jednu
integralnu cjelinu podataka koja se identificira unutar dijagrama sadrţaja kako bi se koristila u
procesu računanja kretanja podataka izmeĎu korisnika softvera, softvera koji se mjeri i
spremišta podataka.
U tablici 7.1 prikazano je na koji je način u okviru ove disertacije izvršeno preslikavanje
izmeĎu COSMIC elemenata i UWE dijagrama toka procesa.
Tablica 7.1. Preslikavanje izmeĎu COSMIC i UWE dijagrama toka procesa.
COSMIC UWE dijagram tijeka procesa
Korisnik softvera userAction stereotip
Granica softvera System i Storage segmenti dijagrama
aktivnosti
Funkcionalni proces Dijagram tijeka procesa
Podatkovna grupa Objekt dijagrama sadrţaja
DogaĎaj okidač initialNode, userAction
kretanje podataka Entry Podaci poslani od userAction ka
systemAction
kretanje podataka Exit Podaci poslani od systemAction ka
userAction, displayAction ili
ActivityFinalNode
kretanje podataka Read Podaci poslani od CentralBufferNode
ka systemAction
kretanje podataka Write Podaci poslani od systemAction ka
CentralBufferNode
7.3.1. Pravila za funkcionalne procese, podatkovne grupe i podatkovne atribute
Pravila za funkcionalne procese
Funkcionalni procesi odgovaraju skupu funkcionalnih zahtjeva korisnika gdje funkcionalni
procesi sadrţe jedinstven, kohezivan i nezavisan skup kretanja podataka [10]. Funkcionalni
proces je pokrenut (engl. triggered) inicijalnom ulaznom porukom (engl. initiate Entry) ili
kretanjem podataka (Entry) od strane funkcionalnog korisnika kao odgovor na neki inicijalni
79
dogaĎaj. Funkcionalni proces završava kada su sva kretanja podataka koja su bila potrebna da
bi se generirao odgovor na traţeni dogaĎaj izvršena. U skladu s time, funkcionalni proces u
pravilu ima najmanje dva tipa kretanja podataka koja se izvršavaju u toku jednog
funkcionalnog procesa (1 Entry/Read tip kretanja podataka + 1 Exit/Write tip kretanja
podataka). Funkcionalni korisnici kod UWE pristupa započinju funkcionalni proces. Model
strukture procesa predstavlja kompoziciju klasa procesa od kojih svaka od njih predstavlja
jedan funkcionalni proces.
Dakle, pravilo za identifikaciju funkcionalnih procesa bi bilo sljedećeg oblika:
Pravilo 4: Za svaku klasu procesa prikazanu u modelu strukture procesa, potrebno je
identificirati po jedan funkcionalni proces.
Funkcionalni procesi započeti od strane funkcionalnih korisnika
Funkcionalni korisnik započinje funkcionalni proces na osnovu aktivacijskog dogaĎaja što
je prikazano stereotipom <<userAction>> koji se nalazi u korisničkom segmentu dijagrama
aktivnosti za odgovarajuću klasu funkcionalnog procesa za koju je potrebno izvršiti mjerenje.
Reakcija sustava na taj dogaĎaj prikazana je stereotipom <<systemAction>> . Ovaj dogaĎaj
moţe proizvesti neku vrstu unosa podataka prema sustavu, zahtjev za obradom podataka koju
obavlja stereotip <<systemAction>> ili dogaĎaj kojim se uzrokuje da stereotip
<<systemAction>> dobavi neke podatke iz spremišta podataka. Stereotip <<systemAction>>
moţe predstavljati funkcije zaduţene za obavljanje aktivnosti koje su nastale kao direktan
zahtjev od strane stereotipa <<userAction>> ili mogu biti aktivnosti koje su nastale kao
indirektna posljedica dogaĎaja koje je inicirao stereotip <<userAction>>. To znači, da se
unutar stereotipa <<systemAction>> mogu pojaviti i akcije koje je potrebno obaviti prije
nego se pošalje konačni odgovor prema korisniku prikazanom pomoću stereotipa
<<userAction>> u korisničkom segmentu dijagrama aktivnosti. Ove akcije mogu biti
dodatne provjere konzistentnosti podataka koje je korisnik poslao prema sustavu, a za potrebe
pohranjivanja podataka u stalno spremište podataka. Ove akcije su predstavljene u klasama
procesa unutar modela strukture procesa kao klasične metode za obradu i izvršanje nekih
akcija nad podacima. Stoga je model strukture procesa kreiran u duhu objektno orijentiranog
programiranja gdje su zastupljene klasične metodologije poput nasljeĎivanja i druge
aktivnosti kako bi se izbjeglo dupliciranje izračunavanja funkcionalne veličine za više istih
metoda.
80
Vaţno pravilo koje je potrebno definirati vezano za mjerenje funkcionalne veličine na bazi
UWE modela je pravilo za izbjegavanje duplog brojanja funkcionalne veličine funkcionalnih
procesa koji se nalaze unutar nekog novog procesa, a već su jednom brojani. Ovo je već
definirano pomoću modela procesa gdje je jasno potrebno prikazati sve funkcionalne procese,
pojedinačno i cjelokupno kako bi se točno i vizualno moglo utvrditi gdje se i koliko puta koji
funkcionalni procesi pojavljuju unutar modela.
Pravila za podatkovne grupe
Podatkovne grupe odgovaraju skupu različitih atributa koji opisuju objekt od interesa.
Objekt od interesa je bilo „što― što je identificirano s točke gledišta zahtjeva funkcionalnih
korisnika. Moţe biti bilo koja fizička stvar, kao i bilo koji konceptualni objekt ili dio
konceptualnog objekta u svijetu funkcionalnog korisnika, a za koji se od softvera zahtijeva da
obradi i/ili sačuva podatke. Primjer objekta od interesa moţe biti sam funkcionalni korisnik ili
grupa podataka s jedinstvenim skupom atributa koji opisuju jedan objekt od interesa. U
metodi COSMIC termin „objekt od interesa― se koristi kako bi se izbjeglo povezivanje ili
ostvarivanje sličnosti s terminima iz metoda softverskog inţenjerstva. Ovaj termin ne upućuje
na „objekt― u smislu objektno orijentiranih metoda.
UWE pristup koristi UWE konceptualni model odnosno klase procesa iz modela strukture
procesa za mjerenje funkcionalne veličine web aplikacija. Na osnovu klasa procesa generiraju
se dijagrami aktivnosti koji predstavljaju funkcionalne procese. Podatkovne grupe koje se
koriste u dijagramima aktivnosti su realizirane kroz dijagrame sadrţaja. Dijagrami aktivnosti
koriste dijagrame sadrţaja za prikaz podatkovnih grupa koje sudjeluju u funkcionalnom
procesu. Kada je klasa procesa dio hijerarhije nasljeĎivanja, klasa roditelj odgovara
podatkovnoj grupi, a kada dijete klasa procesa ima različite atribute od roditelj klase, to
odgovara drugoj podatkovnoj grupi.
Na osnovi prethodno iznesenog, mogu se kreirati sljedeća pravila za ispravnu identifikaciju
podatkovnih grupa:
Pravilo 5: Identificirati podatkovnu grupu za svaku klasu koja nije korijen u stablu
nasljeĎivanja koja ima različite atribute od svoje nadreĎene (roditelj) klase u modelu
strukture procesa koja sudjeluje u funkcionalnom procesu.
Pravilo 6: Identificirati podatkovnu grupu za svaku korijen klasu (roditelj) u stablu
nasljeĎivanja unutar modela strukture procesa, a koja sudjeluje u funkcionalnom
procesu.
81
Pravila za atribute podataka
Atributi podataka odgovaraju najmanjem dijelu informacija grupe podataka. Kod UWE
pristupa, atributi grupe podataka odgovaraju atributima klasa koje su definirane unutar
dijagrama sadrţaja identificirani kao grupe podataka. Sukladno tome, definira se sljedeće
pravilo za identifikaciju atributa:
Pravilo 7: Identificirati atribute podataka za svaki atribut klasa unutar dijagrama
sadrţaja koje su identificirane kao grupe podataka.
Identificiranje kretanja podataka
U skladu sa COSMIC mjernim uputama za svaki funkcionalni proces potrebno je utvrditi
broj kretanja podataka [10].
Slika 7.14. Prikaz mogućih kretanja podataka ovisno o tipu korisnika i stereotipu.
Na slici 7.14 prikazane su moguće varijante kretanja podataka koje se mogu pojaviti u
dijagramu aktivnosti UWE modela. Na osnovu ove slike moguće je primijetiti da funkcionalni
korisnik (stereotipovi <<userAction>> i <<displayAction>>) unosi ili prima podatke od
82
strane softvera ili dijela softvera koji se mjeri a koji se kod UWE pristupa predstavlja pomoću
stereotipa <<systemAction>> u plivajućoj stazi sustava prikazano na dijagramu aktivnosti.
Samo element <<systemAction>> ima mogućnost čitanja i pisanja podataka u spremišta
podataka prikazano stereotipom <<CentralBufferNode>>.
Za identifikaciju kretanja podataka, u okviru ove disertacije definirano je 9 pravila za
potrebe brojanja kretanja podataka koja se mogu pojaviti kod UWE konceptualnih modela
kao i dodatna 2 pravila koja se odnose na sumiranje svih kretanja koja se mogu pojaviti unutar
funkcionalnih procesa. Sva ova pravila brojanja su strukturirana u skladu s konceptom mjerne
metode COSMIC i UWE pristupom, a što je osmišljeno i implementirano u okviru ove
disertacije.
Pregled mogućih kretanja podataka, prikazan je u tablici 7.2.
Tablica 7.2. Pregled kretanja podataka ovisno od stereotipova uključenih u izmjenu grupa
podataka.
Kretanje Izvor Odredište Opisno
K1 initalNode systemAction Stereotip <<initialNode>> inicira neku aktivnosti
odnosno aktivaciju funkcionalnog procesa (djeluje kao
okidač, engl. initial Entry) unutar ili prema stereotipu
<<systemAction>>. Identificiramo jedan Entry (E) tip
kretanja podataka (slika 7.14, kretanje (1)).
K2 userAction systemAction Stereotip <<userAction>> šalje podatke prema
stereotipu <<systemAction>> koji se trebaju obraditi
unutar sustava ili proslijediti daljnje prema stereotipu
<<CentralBufferNode>>. Identificiramo jedan Entry
(E) tip kretanja podataka (slika 7.14, kretanje (1)).
K3 systemAction displayAction Stereotip <<systemAction>> šalje poruku prema
stereotipu <<displayAction>> koja je nastala kao
produkt upravljanja podacima unutar stereotipa
<<systemAction>>. Identificiramo jedan Exit (X) tip
kretanja podataka (slika 7.14, kretanje (2)).
K4 systemAction userAction Stereotip <<systemAction>> šalje podatke prema
stereotipu <<userAction>> koji su nastali kao rezultat
dobavljanja podataka od stereotipa
<<CentralBufferNode>> ili su nastali kao produkt
83
upravljanja podacima unutar stereotipa
<<systemAction>> koje <<systemAction>>onda
prosljeĎuje prema <<userAction>>. Identificiramo
jedan Exit (X) tip kretanja podataka (slika 7.14, kretanje
(2)).
K5 CentralBuffer
Node
systemAction Stereotip <<systemAction>> prima podatke od
stereotipa <<CentralBufferNode>>. Identificiramo
jedan Read (R) tip kretanja podataka (slika 7.14,
kretanje (3)).
K6 systemAction CentralBufferN
ode
Stereotip <<systemAction>> šalje podatke stereotipu
<<CentralBufferNode>>. Identificiramo jedan Write
(W) tip kretanja podataka (slika 7.14, kretanje (4)).
K7 CentralBuffer
Node
systemAction Na osnovu inicijalizacije od strane stereotipa
<<systemAction>>, stereotip <<CentralBufferNode>>
šalje podatke prema <<systemAction>> stereotipu za
svaki atribut grupe 1 referenciran prema grupama
2,3,…,n. Identificiramo jedan Read (R) tip kretanja
podataka za svaku grupu podataka (slika 7.14, kretanje
(3)).
K8 decisionNode
(system
swimlane)
systemAction
(system
swimlane) i
userAction
(user swimlane)
ili
displayAction
(user swimlane)
ili
ActivityFinalNo
de (user
swimlane)
Čvorište odluke (engl. decision node) šalje izlazne
podatke iz plivajuće staze system swimlane prema dva
stereotipa, jednom u istoj plivajućoj stazi system
swimlane a drugom u plivajućoj stazi user swimlane.
Identificiramo samo jedan Exit (X) tip kretanja podataka
(slika 7.14, kretanje (2)).
K9 decisionNode
(user
swimlane)
systemAction
(system
swimlane) i
userAction
(user swimlane)
Čvorište odluke šalje ulazne podatke prema softveru
koji se mjeri i to iz plivajuće staze user swimlane prema
dva stereotipa, jednom u user swimlane plivajućoj stazi
i drugom u system swimlane plivajućoj stazi.
Identificiramo jedan Entry (E) tip kretanja podataka
84
ili
displayAction
(user swimlane)
ili
ActivityFinalNo
de (user
swimlane)
(slika 7.14, kretanje (1)).
K10 decisionNode
(system
swimlane)
userAction
(user
swimlane) ili
displayAction
(user
swimlane) i
CentralBuffer
Node (storage
swimlane)
Čvorište odluke šalje izlazne podatke istovremeno i
izvan softvera koji se mjeri i prema spremištu podataka.
Identificiramo jedan Exit (X) i jedan Write (R) tip
kretanja podataka (slika 7.14, kretanje (2) i kretanje (4)).
S obzirom da se svi tipovi kretanja podataka mogu identificirati uz odgovarajuće
pozicioniranje stereotipova unutar dijagrama aktivnosti UWE klasa procesa, na taj način
grupiraju se i prikazuju svi mogući tipovi kretanja podataka. Kod UWE pristupa postoji
nekoliko stereotipova koji označavaju vrstu korisnika sustava, način prikazivanja podataka,
način obrade i upravljanja podacima i način za smještanje podataka koji se mogu nalaziti u
nekom od tri segmenta UWE dijagrama aktivnosti, ali ne u svima. Tih nekoliko osnovnih
stereotipova su sljedeći: <<userAction>>, <<displayAction>>, <<systemAction>> i
<<CentralBufferNode>>.
Stereotip <<userAction>> predstavlja element kojim se prikazuje interakcija
funkcionalnog korisnika sa softverom koji se mjeri pa je samim time i jedan je od glavnih
elemenata za iniciranje dogaĎaja koji će se obavljati od strane softvera koji se mjeri.
Stereotip <<displayAction>> predstavlja informacije koje sustav šalje prema korisniku
sustava od strane funkcionalnog procesa. Te informacije mogu biti različitog tipa, kao na
primjer poruke koje informiraju o uspješno obavljenoj aktivnosti, zatim poruke o pogrešci ili
pak poruke u obliku podataka koje se šalju korisniku sustava, a koje mogu dolaziti od trajno
skladištenih podataka. Ovaj stereotip nema mogućnost za iniciranje funkcionalnog procesa ili
85
za slanje ulaznih podataka. Ovaj stereotip sluţi isključivo za prikaz izlaznih podataka iz
funkcionalnog procesa u vidu poruka od sustava ili neke druge vrste poruka za prikaz.
Stereotip <<systemAction>> predstavlja jedan od osnovnih elemenata sustava koji se mjeri
i osnovni je element putem kojeg se vrši izmjena podataka izmeĎu funkcionalnih korisnika i
softver koji se mjeri. Na osnovu ove činjenice, tok podataka izmeĎu softvera koji se mjeri i
funkcionalnih korisnika moguće je definirati promatranjem ulaza i izlaza ovog stereotipa i to
prema <<userAction>> i <<displayAction>> stereotipovima sa strane funkcionalnih
korisnika i prema <<CentralBufferNode>> stereotipu sa strane elementa za trajno smještanje
podataka.
Stereotip <<CentralBufferNode>> je element koji predstavlja sustav za pohranu podataka.
Ovaj stereotip ima samo mogućnost razmjene podataka sa stereotipom <<systemAction>>.
Da bi se definirala ova pravila, potrebno je promatrati i tokove podataka koji se izvršavaju
unutar, na primjer, jednog cjelokupnog procesa od traţenja podataka na ulazu u sustav do
njihovog dobavljanja iz spremišta podataka i na kraju do prosljeĎivanja podataka na izlaz iz
sustava koji se mjeri.
Na osnovu prethodnog, u nastavku će biti dat pregled kretanja podataka i na kraju pregled
svih pravila za kretanje podataka.
Prvo kretanje podataka odnosi se na ulazne ili inicirajuće podatke (Entry, (E)) prema
<<systemAction>> stereotipu. Za ovu situaciju, imamo moguće dvije vrste kretanja K1 i K2
prikazane u tablici 7.2.
Na osnovu prethodnih moguće definiranih kretanja, moţemo definirati sljedeća pravila:
Pravilo P8: identificira se po jedan tip kretanja Entry (E) iniciranja funkcionalnog
procesa tipa initial Entry (E) kada stereotip <<userAction>> inicira dogaĎaj koji se
onda obraĎuje sa <<systemAction>>. U tom procesu ne šalju se atributi klasa nego se
vrši inicijalizacija nekog dogaĎaja koji se obraĎuje pomoću <<systemAction>>
stereotipa. Pored toga, za isti tip kretanja podataka Entry (E), ali s grupom podataka
identificira se po jedan tip kretanja podataka Entry za slanje podataka od
<<userAction>> prema <<systemAction>> koje je potrebno obraditi. Podaci koji se
šalju se sastoje od jednog ili više atributa klasa prikazanih dijagramom sadrţaja koji
sudjeluju u funkcionalnom procesu (kretanje K1 i K2, tablica 7.2).
86
Vaţno je napomenuti da se bilo koja komunikacija izmeĎu stereotipova <<userAction>> i
<<CentralBufferNode>> moţe odvijati samo korištenjem stereotipa <<systemAction>>4.
Sljedeća grupa kretanja podataka odnosi se na kretanje izlaznih podataka Exit (X) opisanih
sa K3 i K4 elementima u tablici 7.2.
Kretanja K3 i K4 predstavljaju opisno različite uzročno/posljedične veze za kretanje
podataka prema izlazu iz softvera koji se mjeri, ali suštinski predstavljaju isti tip kretanja
podatka tj. Exit (X) tip kretanja podataka (tablica 7.2).
Na osnovu ovoga, moţemo definirati sljedeća pravila za kretanje podataka:
Pravilo P9: identificirati po jedan tip kretanja podataka Exit (X) za svaku poruku koja
se šalje od strane <<systemAction>> prema <<displayAction>> stereotipu.
Pravilo P10: identificirati po jedan tip kretanja podataka Exit (X) za svaku grupu
podataka koja se šalje od strane <<systemAction>> prema <<userAction>>
stereotipu.
Kretanje podataka izmeĎu stereotipova <<CentralBufferNode>> i <<systemAction>>
moţe se prikazati kroz nekoliko koraka, a koji su definirani kao koraci K5 i K6 prikazani u
tablici 7.2.
Na osnovu prethodno identificiranih mogućih kretanja podataka (tablica 7.2, kretanja
podataka K5 i K6) mogu se kreirati sljedeća pravila:
Pravilo P11: identificirati po jedan tip kretanja podataka Read (R) za svaku grupu
podataka koja se šalje od strane <<CentralBufferNode>> prema stereotipu
<<systemAction>>.
Pravilo P12: identificirati po jedan tip kretanja podataka Write (W) za svaku grupu
podataka koja se šalje od strane <<systemAction>> prema <<CentralBufferNode>>
stereotipu.
Kod UWE metode postoji potreba i mogućnost za višestruko čitanje podataka (tip kretanja
podataka Read) od stereotipa <<CentralBufferNode>> prema stereotipu <<systemAction>>
inicirano na osnovu činjenice da grupa podataka 1 moţe imati atribute koji se referenciraju na
grupe podataka 2,3,…,n i u tom slučaju uspješno dobavljanje podataka grupe 1 ovisi od
4 Direktna komunikacija izmeĎu stereotipova <<userAction>> i <<CentralBufferNode>> kod UWE pristupa
nije moguća, jer je veliki dio poslovne logike sustava koji se mjeri smješten odnosno prikazan pomoću stereotipa
<<systemAction>>.
87
dobavljanja podataka grupa 2,3,…,n. Ovaj slučaj referenciranja podataka je potrebno
identificirati jer je on u skladu sa COSMIC mjernom metodom.
Stoga je u ovom slučaju moguće definirati kretanje podataka K7 prikazano u tablici 7.2.
Za ovu vrstu kretanja, moguće je definirati sljedeća pravila:
Pravilo P13: identificiramo 1 Read (R) za dobavljanje grupe podataka inicirane pomoću
<<systemAction>> od <<CentralBufferNode>> za svaki atribut grupe podataka 1
koji se referencira na grupe podataka 2,3,…,n. Kretanje podataka izmeĎu
stereotipova <<displayAction>> i <<userAction>>, <<systemAction>> i čvorišta
odluke (engl. decision node) moţe se prikazati kroz nekoliki koraka, a koji su
definirani kao koraci K8 i K9 prikazani u tablici 7.2.
Ako se čvorište odluke, koje se nalazi u jednoj plivajućoj stazi, grana tako da pri tome
dolazi do prelaska strelica toka podataka od čvorišta odluke iz jedne plivajuće staze u drugu
plivajuću stazu prema istim ili različitim stereotipovima (na primjer, prilikom grananja
prelazak se dešava od čvorišta odluke koje se nalazi u user plivajućoj stazi prema stereotipu
<<systemAction>> unutar system plivajuće staze ili prilikom grananja prelazak se dešava od
čvorišta odluke koje se nalazi u system plivajućoj stazi prema stereotipu <<userAction>> ili
<<displayAction>> unutar user plivajuće staze), onda u tom slučaju moţemo smatrati da
postoji samo jedan Entry (ako se radi o kretanju podataka iz smjera user prema system
plivajućoj stazi) ili jedan Exit (ako se radi o kretanju iz smjera system prema user plivajućoj
stazi) tip kretanja podataka. U ovom slučaju se radi o kretanju iste grupe podataka s različitim
mogućim sadrţajnim informacijama koje se šalju prema ulazu, odnosno izlazu iz softvera ili
dijela softvera koji se mjeri s dvije opcije od kojih samo jedna trenutno moţe biti aktivna. Ne
identificira se kretanje podataka ako je tok procesa usmjeren od jednog do drugog stereotipa
istog tipa. U ovom slučaju se smatra da je ovo kretanje u biti aktiviranje akcije tipa toka
procesa tj. tipa „tok izvršavanja komandi― (npr. <<systemAction>> ka <<systemAction>>).
Ako čvorište odluke ima dva izlaza, od kojih je jedan prema elementu u istoj plivajućoj
stazi, a drugi prema elementu u drugoj plivajućoj stazi, onda identificiramo samo jedan Entry
tip kretanja podataka ako se radi o čvorištu odluke koje se nalazi u user plivajućoj stazi,
odnosno identificiramo jedan Exit tip kretanja podataka ako se radi o čvorištu odluke koje se
nalazi u system plivajućoj stazi.
Ako čvorište odluke koje se nalazi u system plivajućoj stazi ima dva izlaza, od kojih je
jedan usmjeren prema elementu u user plivajućoj stazi a drugi usmjeren prema elementu u
88
storage plivajućoj stazi, onda identificiramo dva moguća tipa kretanja podataka, i to jedan
Exit tip kretanja podataka i jedan Write tip kretanja podataka.
Na osnovu prethodno identificiranih mogućih kretanja podataka (tablica 7.2, kretanja
podataka K8, K9, i K10) mogu se kreirati sljedeća pravila:
Pravilo P14: Identificiramo 1 Entry (E) tip kretanja podataka ako postoji kretanje
podataka od čvorišta odluke koje se nalazi u user plivajućoj stazi prema dva elementa
od kojih se jedan nalazi u istoj plivajućoj stazi kao i čvorište odluke dok se drugi
element nalazi u system plivajućoj stazi.
Pravilo P15: Identificiramo 1 Exit (X) tip kretanja podataka ako postoji kretanje
podataka od čvorišta odluke koje se nalazi u system plivajućoj stazi prema dva
elementa od kojih se jedan nalazi u istoj plivajućoj stazi kao i čvorište odluke dok se
drugi element nalazi u user plivajućoj stazi.
Pravilo P16: Identificiramo 1 Exit (X) i 1 Write (W) tip kretanja podataka ako postoji
kretanje podataka od čvorišta odluke koje se nalazi u system plivajućoj stazi a koje
ima dva moguća izlaza prema dva elementa od kojih se jedan nalazi u user plivajućoj
stazi a drugi u storage plivajućoj stazi.
7.4. Definiranje numeričkih pravila
Numerička pravila su pravila pomoću kojih se dodjeljuju numeričke vrijednost procesu
kretanja podataka koji se odvija izmeĎu funkcionalnih korisnika i dijela softvera koji se mjeri.
Ove numeričke vrijednosti predstavljaju funkcionalnu veličinu softverske aplikacije na bazi
UWE konceptualnog modela. Ovaj korak podrazumijeva definiranje funkcija mjerenja i
agregaciju rezultata mjerenja što je ujedno i posljednja faza COSMIC mjernog procesa.
Primjena mjerne funkcije
U skladu s metodom COSMIC, svakom kretanju podataka će se dodijeliti jedna jedinica
veličine nazvana 1 CFP (COSMIC Function Point).
Kod UWE pristupa, svakom pojedinačnom kretanju podataka se dodjeljuje 1 CFP.
Agregracija mjernih rezultata
Funkcionalna veličina funkcionalnog procesa prema COSMIC mjernom priručniku
predstavlja sumu svih kretanja podataka koji se odvijaju unutar funkcionalnog procesa.
Matematički formulirano, to predstavljamo sljedećom jednadţbom:
89
Size (FPi) = numberOf(Entriesi)+ numberOf(Exitsi)+ numberOf(Readsi)+
numberOf(Writesi) (7.1)
Na osnovu toga, moţemo definirati sljedeća pravila za sumiranje kretanja podataka za
svaki funkcionalni proces:
Pravilo P17: Sumirati kretanja podataka unutar funkcionalnog procesa koji se
pojavljuje u dijelu softvera koji se mjeri da bi se dobila funkcionalna veličina
funkcionalnog procesa.
Kada su svi funkcionalni procesi izmjereni, potrebno je izvršiti sumiranje vrijednosti
kretanja podataka za sve funkcionalne procese kako bi se dobila funkcionalna veličina
softvera koji se mjeri. Dakle, sljedeće pravilo bi bilo:
Pravilo P18: Sumirati funkcionalne veličine svih funkcionalnih procesa kako bi se
dobila ukupna funkcionalna veličina softvera koji se mjeri.
Size(software) = Size(FPi) (7.2)
S ovako definiranim pravilima mjerenja, moguće je izmjeriti funkcionalnu veličinu
softvera kreiranog na osnovu UWE konceptualnog modela. Ova mjerna pravila sumiraju sva
kretanja podataka koja se pojavljuju u softveru za njegovu ispravno izvršavanje, tako da na
osnovu ovoga moţe se reći da mjerni rezultati uključuju sve funkcionalnosti s točke gledišta
programera.
7.4.1. Primjer primjene pravila mjerenja izračuna kretanja podataka
Ova faza uključuje identifikaciju kretanja podataka i sumiranje rezultata mjerenja.
Identifikacija kretanja podataka se obavlja za svaki funkcionalni proces koji je identificiran
na osnovu FUR (slika 7.9) i uz podršku strelica koje predstavljaju tok podataka unutar
dijagrama aktivnosti (slika 7.12). Strelica toka podataka izmeĎu stereotipa <<userAction>> i
<<systemAction>>, ili <<systemAction>> i <<CentralBufferNode>> predstavlja, kretanja
podataka, a strelica toka procesa izmeĎu dva stereotipa u istim plivajućim stazama
predstavljaju sekvencu izvršenja komandi unutar funkcionalnog procesa. Kod UWE pristupa,
vrsta kretanja podataka se identificira na osnovu FUR uz pomoć izvorišnih i odredišnih
90
elemenata unutar UWE dijagrama aktivnosti (slika 7.12), kao što je to predstavljeno u tablici
7.3.
Identifikacija i brojanje kretanja podatkovnih grupa (Entries, Exits, Reads i Writes) u
dijagramu toka procesa se obavlja pomoću strelica toka podataka (engl. data flow arrow).
Smjer toka podataka od i prema pin čvorovima kao izvorišnih i odredišnih točaka u dijagramu
toka procesa prikazan je u tablici 7.3.
Tablica 7.3. Vrsta kretanja ovisno o smjeru toka podataka od pin čvorova s izvorišnih
elementa odnosno ka pin čvorovima odredišnih elementa unutar dijagrama toka procesa.
Izvor Odredište Vrsta kretanja podataka
userAction systemAction Entry.
initialNode systemAction Entry.
CentralBufferNode systemAction Read.
systemAction userAction Exit.
systemAction systemAction Nije kretanje podataka.
userAction userAction Nije kretanje podataka.
systemAction CentralBufferNode Write.
systemAction displayAction Exit.
systemAction ActivityFinalNode Exit.
displayAction userAction Nije kretanje podataka (nije ni moguće).
displayAction systemAction Nije kretanje podataka (nije ni moguće).
userAction displayAction Nije kretanje podataka.
userAction CentralBufferNode Ne postoji direktna komunikacija izmeĎu ova
dva stereotipa. Komunikacija izmeĎu
userAction i CentralBufferNode je uvijek
ostvarena putem systemAction stereotipa.
Dijagram toka procesa je podijeljen u nekoliko plivajućih staza. Plivajuća staza označena
kao korisnik (engl. user), zatim stereotipovi <<userAction>> i <<displayAction>>
pozicionirani su u korisnikovoj plivajućoj stazi i koriste se za prezentaciju interakcije
korisnika sa sustavom. Stereotip <<systemAction>> pozicionira se u plivajućoj stazi
označenoj kao sustav (engl. system). Ovaj stereotip je zaduţen za prikaz procesiranja
91
podataka unutar sustava, komunikaciju sa stereotipovima <<userAction>>,
<<displayAction>> i <<CentralBufferNode>>.
Posljednji stereotip je <<CentralBufferNode>> i on je pozicioniran u plivajućoj stazi
označenoj kao element za pohranu podataka (engl. storage). Ovaj stereotip predstavlja
elemente za pohranu podataka ili bilo koji drugi element koji omogućava preuzimanje
podataka smještenih negdje drugdje ili za slanje podataka ka nekom elementu za spremanje
podataka.
Slika 7.15. Primjer dijagrama toka procesa za slučaj prijave korisnika na sustav sa
pozicioniranim elementima, prikazima podatkovnih i tokom procesa (Entry, Exit, Read,
Write).
Kroz pravila za identifikaciju kretanja podataka već je prikazano u kojim slučajevima se
moţe smatrati da imamo kretanja podataka i kada je to potrebno brojati, a kada ne. Smatra se
da kretanje podataka postoji samo u slučajevima kao što je to prikazano u tablici 7.3.
U kontekstu tipa komandi za izvršavanje, mogu se pojaviti dva slučaja: izvršavanje na
strani klijenta i na strani posluţitelja. Izvršavanje na strani klijenta ne mora nuţno uključivati
kretanje podataka koji se smještaju i dobavljaju od strane elemenata za spremište podataka
92
putem stereotipa <<systemAction>>5. U području programiranja, ovo znači da stereotip
<<userAction>> moţe imati neke elemente JavaScript funkcionalnosti ili neke druge tipove
objekata koji se trebaju izvršiti samo na strani klijenta bez interakcije sa sustavom. U ovom
slučaju ne postoji identifikacija kretanja podataka tipa Read/Write nego samo moţe postojati
kretanje podataka tipa Entry/Exit. Kod UWE modela, ovakav tip slučaja se prezentira na
strani klijenta ulazno/izlaznim pinovima objekata koji su identificirani sa stereotipom
<<userAction>> unutar dijagrama aktivnosti. U smislu izvršavanja komandi na strani
klijenta, jedini tip kretanja podataka koji se moţe identificirati je onaj koji je namijenjen za
unos ili dohvat podataka od strane sustava (npr. <userAction>> ka <<systemAction>> i
obratno) bez interakcije sa spremištem podataka. U ovom slučaju, moţe postojati samo Entry
ili Exit tip toka podataka.
Izvršavanje komandi na strani posluţitelja je uglavnom orijentirano manipulaciji ili
kretanju podataka izmeĎu stereotipova <<systemAction>> i <<CentralBufferNode>> . Ovi
tipovi toka podataka se prepoznaju kao Read ili Write ovisno o smjeru toka podataka.
Da bi se identificirali COSMIC tokovi podataka Entry ili Exit, potrebno je identificirati kada
(pod kojim uvjetima) korisnik šalje podatke ili inicira neku akciju koja predstavlja vanjski
dogaĎaj za sustav, a ujedno je potrebno biti u mogućnosti identificirati pod kojim uvjetima ili
na koji način sustav zaprima ove vrste dogaĎaja. Ovakve situacije se mogu identificirati kada
postoje različiti tipovi web formi za prikupljanje podataka i njihovo slanje sustavu (slika 7.15,
a) (na primjer, web forme s podacima, inicijalizacijski dogaĎaji na osnovu kojih se traţe neki
podaci) ili ako postoje situacije gdje korisnik prima informaciju od strane sustava (slika 7.15,
b i slika 7.15, g) (na primjer, lista aktivnih korisnika, neke informacije o objavljenim
radovima i autorima, poruke koje informiraju korisnika vezano za uspješno smještanje
podataka unutar sustava, poruke vezano za greške u sustavu itd.).
Drugi aspekt implementacije COSMIC mjerenja je taj da se mora znati kada sustav šalje
podatke ka spremištu podataka te kada sustav prima podatke od spremišta podataka
(COSMIC kretanje podataka: Write i Read). U ovom koraku, moguće je pratiti i izračunati
kretanje podataka tj. izmjenu podataka izmeĎu sustava i spremišta podataka uz pomoć
dijagrama sadrţaja kreiranih unutar konceptualne sheme web aplikacije.
5 Iako ne dolazi do fizičkog kretanja podataka od klijenta ka posluţitelju, u slučaju kompleksnije interakcije
(validacija na strani klijenta) moguće je brojati interakaciju kretanja podataka pomoću tagova predviĎenih za tu
situaciju.
93
Identifikacija kretanja podataka izmeĎu sustava i spremišta podataka (slika 7.15, c) se
obavlja uz pomoć pin elemenata kod stereotipa <<systemAction>> koji pomoću strelice
pokazuje tok podataka od stereotipa <<systemAction>>, koji se nalazi u plivajućoj stazi
system dijagrama aktivnosti, ka <<CentralBufferNode>> u plivajućoj stazi za spremanje
podataka.
Stereotip <<CentralBufferNode>> u UWE dijagramu toka procesa je prikazan kao
element za spremanje podataka (slika 7.15, User class). U tom slučaju, pin element je tipa
result koji označava da on obavlja radnju slanja podataka ka spremištu podataka.
Identificiranje kretanja podataka izmeĎu elemenata za spremanje podataka koji se nalaze u
plivajućoj stazi storage i elemenata koji se nalaze u plivajućoj stazi system (slika 7.15, d) je
takoĎer definirano uz pomoć pin elemenata sa strelicama koje označavaju tok podataka
pokazujući ka pin elementu na strani stereotipa <<systemAction>> u plivajućoj stazi system
usmjereno od strane stereotipa <<CentralBufferNode>> u plivajućoj stazi storage. U ovom
slučaju, pin element je tipa argument vrijednosti što znači da ovaj pin označava element koji
prima vrijednosti, tj. stereotip <<systemAction>> prima podatke od strane spremišta
podataka.
Agregacija mjernih rezultata.
U ovom koraku sumirani su rezultati svih kretanja podataka u svim funkcionalnim
procesima. Funkcionalna veličina svakog identificiranog objekta je jednaka sumi svih kretanja
podataka identificiranih unutar tog istog objekta.
94
8. MODEL ZA PROCJENU TEŢINE RAZVOJA WEB APLIKACIJA
8.1. Empirijska evaluacija predloţenog modela
U [88] provedena je empirijska analiza kako bi se utvrdilo moţe li se predloţena metoda
efektivno koristiti za predviĎanje uloţenog napora za razvoj web aplikacija na osnovi
konceptualnih modela web aplikacija i COSMIC funkcionalnih točaka. Rezultati su obraĎeni
pomoću statističkog softvera SPSS 17.0 za Windows operativni sustav.
Studija slučaja je provedena nad 19 web aplikacija koje su bile razvijene od strane dvije
različite grupe programera u vremenskom periodu od 2009. do 2013. godine. Podaci vezani za
web projekte i COSMIC funkcijske točke su prikupljeni nakon dizajna i analize zahtjeva
korisnika i na osnovu konceptualnih modela aplikacija. Razvojni programeri su bili
profesionalni programeri s minimalno 2 godine iskustva rada u programskim jezicima koji su
korišteni za razvoj aplikacija. Prva grupa je bila sastavljena od dva profesionalna programera
s iskustvom u radu u rasponu od 4 do 6 godina. Druga grupa je bila sastavljena od četiri
programera s iskustvom u radu u rasponu od 2 do 8 godina rada u području razvoja web
aplikacija. Sve aplikacije su razvijene uz pomoć programskog jezika PHP i baze podataka
MySQL. Za potrebe razvoja jednog dijela projekata korišteno je neko razvojno okruţenje kao
potpora brţem razvoju aplikacija. Voditelj projekata je bio zaduţen za COSMIC FP mjerenja
uz pomoć COSMIC-ovog priručnika za mjerenje [10], [102], pri čemu je kao pomoć za
mjerenje koristio COSMIC-ov mjerni etalon: C - registration system. Tipovi razvijenih
aplikacija su bili većinom aplikacije za upravljanje podacima bez većeg broja grafičkih
elemenata ili animacija, primjerice aplikacije za upravljanje podacima o studentima,
upravljanje nastavnim planovima, ispitima i rasporedom nastave i predavanja, sustavi za
upravljanje sadrţajima, portali za on-line kupovinu itd. Sve aplikacije su bile napravljene prvi
put.
Osim toga, aplikacije su bile tipične aplikacije za upravljanje podacima, bez kompleksnih
algoritamskih izračuna, bez kompleksnog dizajna, većinom posvećene za spremanje i dohvat
podataka iz baze podataka. Ovaj tip aplikacija je bio izabran za modeliranje sustava za
procjenu napora kako bi se generalizirali tipovi razvijenih aplikacija dobiveni od strane
različitih razvojnih timova s različitim sposobnostima.
Za sve analizirane projekte, prikupljene su informacije o razvojnim timovima, iskustvu
programera u razvoju web aplikacija, broju sati provedenih u razvoju aplikacija, tipovima
razvijenih aplikacija, korištenim programskim jezicima, web razvojnim okruţenjima i
95
korištenim bazama podataka.
Detaljni podaci o studijama slučaja koji su obuhvatili analizu 19 web projekata:
Projekti su dobavljeni iz dva različita izvora: 9 (47,3%) od strane akademske zajednice
i 10 (52,7%) od strane softverske tvrtke.
Svi projekti su bili novi razvoj (nije bila u pitanju dogradnja ili dorada postojećeg).
Za razvoj je korištena dinamička tehnologija PHP (100%).
Za smještaj podataka korištena je baza podataka MySQL(100%).
Korišteno je razvojno okruţenje kod 10 projekata (52,7%).
Nije korišteno pomoćno razvojno okruţenje kod 9 projekata (47,3%).
Odabir varijabli za kreiranje modela
Analiza globalnih faktora koji mogu imati utjecaj na procjenu uloţenog napora, kao što su
dijeljeni resursi, nedostatak sigurnosti, smanjen interes za razvoj kao i utjecaj razine točnosti
na razvoj analizirani su u ovom poglavlju.
Svi profesionalci koji su radili na razvoju web aplikacija su imali dovoljno znanja za
izvedbu posla koji im je povjeren u zadanom vremenskom periodu (dizajn aplikacije,
konfiguracija razvojnog okruţenja, kreiranje strukture baze podataka, kreiranje osnovnog
grafičkog izgleda aplikacije, administriranje baze podataka, testiranje aplikacije, kreiranje
dokumentacije i razvoj finalne verzije aplikacije). Svi projekti su bili kompletno razvijani
unutar tvrtke ili akademske zajednice tako da niti jedan od članova razvojnog tima nije bio
odvojen od ostatka tima nekom granicom (kontekstualno, organizacijsko, kulturalno,
vremenski, geografsko ili politički). Razvojno okruţenje nije bilo prostorno globalno
distribuirano tako da taj faktor koji bi mogao utjecati na uloţeni napor za razvoj nije bio
razmatran. Nije bilo identificiranih nedostataka u smislu nedostatka povjerenja izmeĎu
članova razvojnog tima, tako da ni ovo nije bilo razmatrano kao utjecajni faktor na razvoj
projekta.
Nedostatak posvećenosti ka radu i postavljenim zadacima nije identificiran s obzirom da su
svi programeri bili profesionalno angaţirani i u cijelosti posvećeni poslu koji im je bio zadan.
Faktori kao što su vremenska zona, različite kulture, kašnjenje u odgovoru na postavljena
pitanja, povjerenje, svjesnost klijenata, dijeljeni resursi, komunikacija, organizacija ili
struktura tima nisu utjecali na razvoj projekta. U nastavku se radilo na analizi i odabiru
varijabli za kreiranje modela za procjenu. Utjecaj prethodno spomenutih faktora je neznatan
zbog strukture ljudi koji su radili na projektima, njihovog iskustva i posvećenosti poslu.
96
Evaluacija točnosti procjene modela je provedena uz pomoć statističkih metoda, kao što su
MRE, MMRE i PRED(l). Pored globalnih faktora utjecaja na razvoj web aplikacija, analizirani
su i neki drugi faktori koji bi mogli imati utjecaja na uloţeni napor za razvoj web aplikacija,
kao što su funkcionalna veličina, veličina razvojnog tima, iskustvo programera i korištenje
nekog pomoćnog razvojnog okruţenja. Kao što je navedeno u [72], [138], [139], postoje neki
faktori koji mogu imati utjecaja na procjenu napora potrebnog za razvoj softvera, kao što su:
Veličina projekta.
Veličina razvojnog tima.
Korišteni razvojni programski jezik.
CASE alat.
Brzi razvoj aplikacija (engl. Rapid Application Development, RAD).
Računarska platforma za koju se razvija aplikacija (PC ili web posluţitelj).
Tip razvoja (novi razvoj ili odrţavanje postojećeg, nadogradnja postojećeg softvera).
Iskustvo razvojnog programera.
Na osnovu navedenih faktora, provedena je analiza web projekata da se utvrdi koji od
faktora moţe imati utjecaja na analizu i zaključke:
1. Veličina projekta izraţena u obliku COSMIC funkcionalnih točaka (CFP) moţe imati
utjecaja na procjenu napora. Stoga je ovaj faktor uključen u daljnju analizu.
2. Veličina razvojnog tima takoĎer moţe se smatrati kao faktor koji moţe imati utjecaja
na procjenu napora.
3. Programski jezik korišten za razvoj. S obzirom da je isti programski jezik korišten u
svim projektima, ovaj faktor nije smatran utjecajnim.
4. CASE alat. Programeri nisu koristili CASE alat za razvoj aplikacija tako da ovaj
faktor nije uzet u razmatranje.
5. Brzi razvoj aplikacija. S obzirom da je više od pola projekata od ukupnog broja
analiziranih koristilo pomoćno razvojno okruţenje za razvoj aplikacija, ovaj faktor je
uzet u razmatranje.
6. Programska platforma. Sve razvijene aplikacije su bile web aplikacije pa stoga ovo
nije smatrano kao utjecajni faktor.
7. Tip razvoja. S obzirom da su sve razvijene aplikacije bile novi razvoj, ovaj faktor nije
uzet u razmatranje.
97
8. Iskustvo razvojnog programera. S obzirom da su razvojni programeri uključeni u
razvoj aplikacija imali različita radna iskustva po pitanju programiranja, ovo se moţe
smatrati mogućim utjecajnim faktorom.
Varijable, kao što su TeamSize, CFP i DeveloperExperience se promatraju kao omjeri
njihovih logaritamskih vrijednosti u odnosu na logaritamsku vrijednost varijable ActualEffort
za potrebe kreiranja dijagram rasipanja (engl. scatter plot) izmeĎu varijabli, dok je korištenje
razvojnog okruţenja mjereno s Da ili Ne. Razvijene aplikacije koje su korištene u ovoj studiji
su bile mali projekti s relativno malim razvojnim timovima.
Broj programera koji su razvijali aplikacije je najčešće bio 1 (47,4%), označeno parametrom
TeamSize, dok je najrjeĎe broj programera koji su razvijali aplikacije bio 3 (5,3%). Najviše
zastupljeno iskustvo programera (DeveloperExperience) je bilo 4 godine (36,8%) dok je
najmanje zastupljeno bilo sa 2 godine (5,3%). Analizom podataka zaključeno je da je
najzastupljenija veličina tima bila relativno mala i da je većinom bilo zastupljeno kratko
razvojno vrijeme što dalje indicira da se radilo o malim web projektima.
Kao prvi korak analize, načinjena je komparacija izmeĎu aplikacija koje su prilikom svog
razvoja koristile neko pomoćno radno okruţenje i onih koje to nisu. Testirana je sljedeće
hipoteza:
H0: Ne postoji razlika u uloženom naporu ako se koristi pomoćno razvojno okruženje.
H1: Postoji razlika u uloženom naporu ako se koristi pomoćno razvojno okruženje.
Za usporedbu srednje vrijednosti dva različita skupa podataka, korišten je nezavisni t-test.
Nakon primjene testa ovisnosti, dobiveni su sljedeći rezultati. S nezavisnim t-testom,
primijenjen je Levene test da se provjere pretpostavke jednakih varijanci. Obzirom da je p-
vrijednost Levene testa bila 0,092 (p>0,05), pretpostavka je da je varijanca obje grupe bila
ista. Nakon analize nezavisnog t-testa s pretpostavkom jednakih varijanci, p-vrijednost za ovaj
test je bila 0,165 (p>0,05), što je veće od 0,05. Ovo navodi na zaključak da nije moguće
odbaciti nultu hipotezu i da nije bilo razlike izmeĎu srednje vrijednosti dvije grupe podataka.
U ovom slučaju, došlo se do zaključka da uporaba pomoćnog razvojnog okruţenja nije imala
utjecaja na uloţeni napor za razvoj web aplikacija koje su analizirane u ovoj studiji.
S praktične točke gledišta, uporaba pomoćnog razvojnog okruţenja bi trebala smanjiti
vrijeme razvoja i smanjiti potrebni napor, ali ovo nije bio slučaj u provedenoj studiji. Moguće
objašnjenje za ovakve rezultate moţe se naći u tome da funkcionalnosti koje pomoćno
razvojno okruţenje postavlja dostupno kao gotovo rješenje nije bilo dovoljno da osigura
funkcionalnosti za kojima je programer imao potrebu. Sve ovo navodi na zaključak da je
prilikom razvoja aplikacija potrebno voditi računa u funkcionalnostima koje se trebaju razviti
98
te je sukladno tome potrebno da razvojno okruţenje ima mogućnosti da pruţi te
funkcionalnosti kao gotove elemente kako se ne bi morale ponovo razvijati. Na ovaj način bi
se potrebni napor što značajnije umanjio, a mogućnosti pomoćnog razvojnog okruţenja bi bile
još više iskorištene. Naravno, tip web aplikacija koje je potrebno razviti takoĎer ima značajnu
ulogu u odabiru pomoćnog razvojnog okruţenja.
U drugom koraku analize, s obzirom da su varijable mjerene kao omjer veličina
(ActualEffort, CFP, DeveloperExperience i TeamSize) te su značajno varirale jedna u odnosu
na drugu, primijenjene su log-transformacije varijabli za stabilizaciju ovih varijacija. Nakon
primijenjene transformacije, kreiran je dijagram rasipanja (engl. scatter plot) ovih varijabli
kako bi se utvrdila veza izmeĎu ActualEffort (zavisna varijabla) i ostalih varijabli (nezavisne
varijable).
Slika 8.1.a. Dijagram rasipanja izmeĎu varijabli ActualEffort i CFP.
99
Slika 8.1.b. Dijagram rasipanja izmeĎu varijabli ActualEffort i TeamSize.
Slika 8.1.c. Dijagram rasipanja izmeĎu varijabli ActualEffort i DeveloperExperience.
100
Nakon kreiranja dijagrama rasipanja za različite parametre, moţe se uočiti činjenica da
samo u slučaju ActualEffort i CFP varijabli postoji snaţna linearna veza izmeĎu istih.
TeamSize i DeveloperExperience, barem u skupu podataka ove studije, nemaju značajan
utjecaj na uloţeni napor. Samo je CFP varijabla značajno u korelaciji sa ActualEffort
varijablom. Iz ovog razloga, u nastavku kreiranja modela uključene su bile samo ove dvije
varijable.
Na slikama TeamSize (Slika 8.1.b) i DeveloperExperience (Slika 8.1.c) prikazane su
ovisnosti prethodno navedenih varijabli u odnosu na ActualEffort. S obzirom na slabu vezu
izmeĎu ovih varijabli, one nisu dalje ni korištene za kreiranje modela za procjenu uloţenog
napora.
Za CFP varijablu moţemo reći da je veličina projekta u pozitivnoj vezi sa potrebnim
naporom za njihov razvoj (Slika 8.1.a).
8.2. Metoda za validaciju točnosti predviĎanja
Validacija točnosti predviĎanja predloţene metode je provedena na sljedeći način [2]:
CFP mjera veličine korištena u ovoj studiji je uzeta kao nezavisna varijabla za potrebe
kreiranje modela za procjenu uloţenog napora za razvoj web aplikacija uz pomoć
metode jednostavne linearne regresije (engl. Simple Linear Regression, SLR) [140]. U
oblasti procjene teţine razvoja web aplikacija ova metoda je najčešće zastupljena zato
što pruţa prilično točne rezultate ([9], [28], [82], [85], [141], [142] ). U ovoj studiji,
predviĎanje napora za razvoj web aplikacija je napravljeno samo uz pomoć jedne
varijable, a to je veličina web aplikacija izraţena kao CFP. Stoga je CFP korištena
kao nezavisna varijabla a ActualEffort kao zavisna varijabla.
Stabilnost modela je testirana procedurom predloţenom od strane Mendes [142]. Ova
procedura je već korištena u nekoliko drugih studija za potrebe procjene napora web
projekata.
Evaluacija modela predviĎanja potrebnog napora je provedena uz pomoć standardnih
mjera kao što su Mean Magnitude of Relative Error (MMRE), Median of MRE
(MdMRE), i Pred(25). Ovo su neke od uobičajeno korištenih mjera za potrebe
evaluacije modela procjene ([2], [143]). One su bazirane na evaluaciji Magnitude of
Relative Error (MRE) [143] koja je definirana kao:
101
EFFreal EFFpredMRE
EFFreal
(8.1)
, gdje EFFreal i EFFpred predstavljaju stvarnu i predviĎenu vrijednost napora.
PredviĎanje na razini l (Pred(l), [143]) je definirano na sljedeći način:
Pred(l) = k/n (8.2)
, gdje je k broj mjerenja kod koji je MRE manje ili jednako l, a n je ukupan broj mjerenja u
validacijskom skupu podataka.
Generalno, vrijednost od 25 se obično koristi za razinu l. Pred(25) je odreĎivanje
predviĎanja kod kojih je greška manja od 25%. Sukladno [144], dobar model za predviĎanje
treba da ima MMRE≤0,25 i Pred(25)≥0,75, što znači da najmanje 75% predviĎenih
vrijednosti treba da se naĎe unutar 25% njihovih stvarnih vrijednosti ([2], [9], [143]).
8.3. Kreiranje modela
Model za procjenu teţine razvoja web aplikacija je kreiran uz pomoć dvije varijable:
ActualEffort (stvarno uloţeni napor za razvoj web aplikacija), izraţen u vrijednosti osoba-sati
(engl. person-hours, p-h), i COSMIC Function Point (CFP), izraţeno u CFP.
102
U tablici 8.1, prikazani su podaci od 19 projekata koji su korišteni za kreiranje modela za
procjenu uloţenog napora.
Tablica 8.1. Podaci od 19 razvijenih web projekata.
Projekt CFP ActualEffort
P1 77 136
P2 65 115
P3 60 107
P4 77 89
P5 69 97
P6 72 90
P7 38 50
P8 187 365
P9 87 215
P10 59 190
P11 65 130
P12 66 120
P13 38 25
P14 110 110
P15 42 90
P16 54 110
P17 28 16
P18 28 32
P19 57 85
U tablici 8.2, prikazana je deskriptivna statistika za varijable koje su korištene u ovoj studiji.
103
Tablica 8.2. Deskriptivna statistika za 19 web projekata.
Varijabla Opis N Nedostaje Srednja
vrijednost
Medijan Stdandardna
devijacija
Min. Maks.
CFP Veličina web
aplikacija
mjerena
COSMIC
mjernom
metodom
19 0 67,32 65 35,45 28 187
ActualEffort Stvarni napor
uloţen u razvoj
izraţen u mjeri
čovjek-sati
(engl. person-
hours)
19 0 114,32 107 78,56 16 365
Nakon toga, testirana je pretpostavka koja se odnosi na linearnu regresiju da se utvrdi da li
su podaci, koji su prikupljeni za ovu studiju, primjenjivi za kreiranje modela ovom metodom.
Prema [142], da bi model bio stabilan, on mora biti u skladu sa pretpostavkama koje su
testirane i provjerene nad skupom testnih podataka što je prikazano u nastavku.
U prvom koraku analize, cijeli skup varijabli je provjeren da se utvrdi da li ovi skupovi
podataka za odreĎene varijable sadrţe značajnu količinu nedostajućih vrijednosti (>60%). Iz
tablica 8.2 se jasno vidi da u analiziranom skupu varijabli ne postoje one koje imaju
nedostajuće vrijednosti.
Sljedeći korak je traţenje simptoma asimetrije (engl. skewness) i netipičnih vrijednosti
(engl. outliers). Postojanje ovih elemenata moţe biti indikator da je varijable potrebno
normalizirati kako bi one mogle biti prikazane u obliku normalne distribucije. Slike 8.2.a i
8.2.b prikazuju vrijednosti varijabli korištenih u ovoj studiji i njihovu distribuciju.
104
Slika 8.2.a. Histogram za CFP varijablu.
Slika 8.2.b. Histogram za ActualEffort varijablu.
Histogram za numeričke varijable (slika 8.2.a i slika 8.2.b) pokazuje da vrijednosti nisu u
cijelosti simetrične oko centralne vrijednosti. S obzirom na ovu činjenicu, ove vrijednosti
onda nisu u skladu s pretpostavkom za normalnu distribuciju. Dijagrami s pravokutnikom
(engl. Box-Plot, BP) su korišteni u svrhu provjere postojanja netipičnih vrijednosti.
105
Slika 8.3. Dijagram s pravokutnikom za CFP i ActualEffort varijable.
Dijagrami s pravokutnika (slika 8.3) pokazuju postojanje netipičnih vrijednosti. U slučaju
da netipične vrijednosti postoje, one trebaju biti predmet daljnjih provjera.
Zbog postojanja simptoma asimetrije i postojanja netipičnih vrijednosti prikazanih na
dijagramima s pravokutnikom i histogramima, analizirane podatke je potrebno normalizirati.
Transformacija koja je primijenjena za ovu potrebu je prirodni logaritam log(n). Iako su
histogrami i dijagrami s pravokutnikom pokazali postojanje asimetrije i netipičnih vrijednosti,
primijenjena je dodatna statistička analiza kako bi se potvrdile ove pretpostavke. Najčešće
primijenjeni statistički testovi za ovu potrebu su Kolmogorov-Smirnov (K-S) i Shapiro-Wilk
testovi. Ovi testovi usporeĎuju promatrane vrijednosti s teorijskim. Vrijednosti koje su
jednake ili manje od 0,05 (p<0,05), ukazuju da se promatrana distribucija razlikuje od
teorijske.
Tablica 8.3. Rezultati testiranja normalizacije, Kolmogorov-Smirnov i Shapiro-Wilk testovi.
K-Sa sa Lillefors testom korekcije Shapiro-Wilk test
Varijable Statistika Ssa p-vrijednost Statistika Ss
a p-vrijednost
CFP 0.234 19 0.007 0.785 19 0.001
ActualEffort 0.233 19 0.008 0.824 19 0.003
a Skraćenice: Ss, Stupnjevi slobode; K-S, Kolmogorov-Smirnov;
106
K-S i Shapiro-Wilk testovi (tablica 8.3) su pokazali da niti jedna od varijabli nije imala
distribuciju koja je odgovarala normalnoj distribuciji (p<0,05). Stoga je sve varijable bilo
potrebno transformirati. Transformacija koja je korištena u ovom slučaju i primijenjena na sve
numeričke varijable je prirodni logaritam [142].
Kreirane su nove transformirane varijable, lCFP i lActualEffort, za normalizirane CFP i
normalizirane ActualEffort, respektivno (tablica 8.4).
Tablica 8.4. Normalizirani podaci za CFP i ActualEffort.
Projekat ID lCFP lActualEffort
P1 4.36 4.92
P2 4.19 4.75
P3 4.11 4.68
P4 4.36 4.50
P5 4.25 4.58
P6 4.29 4.51
P7 3.66 3.93
P8 5.24 5.90
P9 4.48 5.38
P10 4.09 5.25
P11 4.19 4.88
P12 4.20 4.80
P13 3.66 3.26
P14 4.71 4.71
P15 3.76 4.51
P16 4.01 4.71
P17 3.37 2.83
P18 3.37 3.50
P19 4.06 4.45
107
Za konstrukciju potpunog regresijskog modela, provedena je verifikacija stabilnosti
modela. Da bi se provela verifikacija, potrebno je izvršiti identifikaciju rezidualnih odstupanja
(engl. residuals) i jako utjecajnih podatkovnih točaka. TakoĎer je potrebno izvršiti provjeru
da li su rezidualna odstupanja homoskedastična (engl. homoscedastic) tj. da li postoji
varijanca, kao i da li su u skladu s normalnom distribucijom [142].
U analizi su korišteni sljedeći dijagrami:
Dijagram rezidualnih odstupanja u odnosu na prikladne vrijednosti (engl. Residuals
versus fitted values plot). Ovaj dijagram omogućava vizualnu analizu pretpostavke da
li su rezidualna odstupanja slučajno ili normalno distribuirana.
Dijagram normalne vjerojatnosti (P-P dijagram) rezidualnih odstupanja (engl. The
normal probability plot (P-P plot) of the residuals). P-P dijagram normalnih
odstupanja se koristi za utvrĎivanje da li je podatkovni skup aproksimativno normalno
distribuiran ili ne. Podaci iscrtani na dijagramu u odnosu na teoretsku normalnu
distribuciju bi trebali aproksimativno formirati pravu liniju. Ako je ovo slučaj, onda
imamo slučaj normalne distribucije.
Cook-ova udaljenost (engl. Cook’s distance; Cook’s D) za identifikaciju utjecajnih
projekata. Bilo koja opservacija sa Cook-ovom udaljenosti većom od 4/n, gdje n
predstavlja ukupan broj projekata, se smatra da ima značajan utjecaj na rezultate.
Cook-ova udaljenost identificira projekte koji imaju značajne utjecaje i velika
rezidualna odstupanja.
Dijagram rezidualnih odstupanja za analizirane varijable prikazan je na slici 8.4.
108
Slika 8.4. Dijagram rezidualnih odstupanja za model.
Dijagram vjerojatnosti rezidualnih odstupanja (P-P dijagram) je prikazan na slici 8.5.
Slika 8.5. P-P dijagram modela.
P-P dijagram prikazan na slici 8.5 sugerira da su rezidualna odstupanja dosljedna sa
normalnom distribucijom. Dijagram rezidualnih odstupanja (slika 8.5) pokazuje da od 19
projekata, za dva projekta postoji vjerojatnost da imaju velika rezidualna odstupanja.
109
Da bi se potvrdila ova pretpostavka, Cook-ova udaljenost je izračunata za sve projekte.
Ako je Cookova udaljenost veća od 4/n za projekt, onda je potrebno dodatno izvršiti analizu
podataka. Ove utjecajne točke su testirane da se vidi kako one utiču na konstruiranje modela.
Utjecajne točke su bile isključene iz analize i parametri modela su bili ponovo izračunati.
Nakon analize, parametri modela se nisu značajno promijenili i R2 je imala bolju vrijednost.
Odlučeno je, u skladu sa prethodnom konstatacijom, da se ove utjecajne točke ipak zadrţe u
narednim koracima konstruiranja modela. Nakon što su rezidualna odstupanja i stabilnost
regresijskog modela provjereni, izvršeno je kreiranje jednadţbe modela za predviĎanje
uloţenog napora. Tablica 8.5 prikazuje koeficijente modela baziranog na regresijskoj analizi.
Tablica 8.5. Rezultati parametara modela baziranog na regresijskoj analizi korištenjem lCFP.
Varijable Vrijednost Sga Beta t Sg
a R
2 Sg
a r F Sf
a F
(konstanta) -1.179 0.864 -1.365 0.190 0.722 0.394 44.126 0.000
lCFP 1.384 0.208 0.850 6.643 0.000
a Skraćenice: Sg, standardna greška; Sf, signifikantnost;
Regresijska jednadţba ima sljedeći oblik:
lActualEffort = -1.179 + 1.384lCFP (8.3)
Ova jednadţba koristi dvije varijable koje su prethodno transformirane (lActualEffort i
lCFP). Sukladno tome, ove varijable trebaju biti transformirane natrag u njihovo originalno
stanje. Rezultat takve transformacije je sljedeća jednadţba:
ActualEffort = 0.307CFP1.384
(8.4)
Prosti linearni regresijski model je izračunat na osnovu slučajnih uzoraka podataka
mjerenja varijabli. Ako bi se koristio drugi skup podataka, vjerojatnoća je da bi prilikom
izračuna dobili vjerojatno malo drugačije vrijednosti za parametre regresijskog modela. Iz
ovog razloga potrebno je izračunati interval pouzdanosti (engl. Confidence Interval, CI) za
predviĎene y vrijednosti za neovisnu varijablu x. Interval pouzdanosti za predviĎenu
vrijednost varijable y za vrijednost neovisne varijable x se računa na sljedeći način:
110
2
/2, 2 2 2
( )1
(x)
in yx
x xy t S
n x n
(8.5)
, gdje ŷ predstavlja predviĎenu vrijednost od y, tα/2 predstavlja kritičnu t statistiku iz t-tabele
za odreĎenu razinu pouzdanosti (95%), n-2 predstavlja stupnjeve slobode, Syx je standardna
greška procjene, xi je data vrijednost za x, x je prosjek od vrijednosti x i n je broj mjerenja
korišten u regresijskoj analizi.
Uobičajeno je da se interval pouzdanosti izračunava za opseg od 95%, što znači da postoji
vjerojatnost od 95% da će stvarna linija linearne regresije populacije da se nalazi unutar
intervala pouzdanosti regresijske linije izračunate na osnovi podataka iz promatranog uzorka.
Za podatke iz provedene analize, interval pouzdanosti za predviĎenu varijablu za razinu
značajnosti od 95% ima sljedeće vrijednosti: 95% CI je od 0,944 do 1,824.
8.4. Evaluacija kvalitete modela za predviĎanje uloţenog napora
Za evaluaciju kreiranog modela korištena je procedure izostavljanja jedne vrijednosti
putem unakrsne validacije (engl. leave-one-out cross-validation, LOOCV). Procedura
unakrsne validacije je primijenjena kako bi se skup podataka podijelio na dva druga skupa
podataka, jedan za treniranje, a jedan za validaciju podataka. Skup podataka za treniranje je
korišten za kreiranje modela dok je validacijski skup podataka korišten za validaciju modela.
Ova studija je u svojoj analizi imala 19 projekata, stoga je primjenjena unakrsna validacija
19 puta. Ovo znači da je ukupno kreirano 19 skupova podataka za treniranje i validaciju da bi
se dobila statistika točnosti za model. U svakoj iteraciji, 18 projekata se koristi kao skup za
treniranje i 1 projekt kao validacijski skup. Za mjerenje točnosti predviĎanja, Mean MRE
(MMRE), Median MRE (MdMRE), i Pred(25) statističke metode su korištene. Rezultati
mjerenja za ove parametre, prikazani su u tablici 8.6.
111
Tablica 8.6. Rezultati validacije za podatke sa procedurom izostavljanja jedne vrijednosti
putem unakrsne validacije.
Podatkovni
skup
Projekt lCFP lActualEffort Procjenjeni
napor
MRE
Skup 1 P1 4,36 4,92 4,85 0,015
Skup 2 P2 4,19 4,75 4,61 0,029
Skup 3 P3 4,11 4,68 4,50 0,038
Skup 4 P4 4,36 4,5 4,88 0,085
Skup 5 P5 4,25 4,58 4,71 0,029
Skup 6 P6 4,29 4,51 4,78 0,059
Skup 7 P7 3,66 3,93 3,88 0,012
Skup 8 P8 5,24 5,9 6,18 0,048
Skup 9 P9 4,48 5,38 4,99 0,073
Skup 10 P10 4,09 5,25 4,44 0,154
Skup 11 P11 4,19 4,88 4,61 0,056
Skup 12 P12 4,2 4,8 4,63 0,036
Skup 13 P13 3,66 3,26 3,97 0,217
Skup 14 P14 4,71 4,71 5,45 0,157
Skup 15 P15 3,76 4,51 3,98 0,118
Skup 16 P16 4,01 4,71 4,35 0,076
Skup 17 P17 3,37 2,83 3,66 0,293
Skup 18 P18 3,37 3,5 3,48 0,005
Skup 19 P19 4,06 4,45 4,44 0,003
MMRE: 0,079
MdMRE: 0,056
Pred(25): 94,7%
Podaci u tablici 8.6 pokazuju da razvijeni model ima MMRE vrijednosti koji su manje od
0,25 što ukazuje na to da je postignuta dobra razina predviĎanja. MdMRE predstavlja srednju
vrijednost cjelokupnog MRE za sve podatkovne skupine. U provedenoj analizi, vrijednost za
MdMRE=0,056 pokazuje da pola projekata bi trebalo da bude jednako ili iznad dok druga
polovina treba da bude jednaka ili ispod vrijednosti 0,056. Generalno gledajući, ovo znači da
je postignuta zadovoljavajuća točnost predviĎanja za kreirani model.
Samo jedan projekt je imao MRE koje je veće od 0,25. U skladu sa Pred(25), moţe se
zaključiti da su rezultati pokazali da je 94,7% projekata u validacijskom skupu podataka
predstavlja procijenjeni napor unutar 25% stvarnog napora, što je takoĎer dobar rezultat.
Ovo znači da kreirani model ima 94,7% šansu za predviĎanje napora koje se nalazi unutar
25% stvarnog napora.
112
Ovaj zaključak ide zajedno sa nekim od ograničenjima web projekata koji su korišteni u
podatkovnim skupinama za kreiranje modela. Neka od ograničenja su: mali broj web
projekata koji je korišten za kreiranje modela (mali podatkovni skupovi, samo 19 web
projekata), vrsta ili tip razvijenih aplikacija (uglavnom aplikacije za upravljanje podacima),
web projekti s malim brojem animacija ili bez animacija i korišten je samo jedan programski
jezik za razvoj web aplikacija (PHP).
113
9. AUTOMATIZACIJA PROCJENE NAPORA
9.1. Primjena COSMIC pravila brojanja na UWE modele
Pri kreiranju pravila za brojanje funkcionalnih točaka web aplikacija, UWE modeli su
korišteni za identifikaciju zahtjeva funkcionalnih korisnika (engl. Functional User
Requirements, FUR) i za modeliranje funkcionalnih procesa. Svaka klasa procesa je opisana
vlastitim modelom procesa prikazanim dijagramom aktivnosti. Primjena metode COSMIC se
provodi kroz tri faze: faza mjerne strategije, faza preslikavanja i faza mjerenja.
U fazi mjerne strategije vrši se utvrĎivanje namjene i područja mjerenja, identifikacija
funkcionalnih korisnika i odreĎivanje razine detaljnosti.
U fazi preslikavanja, vrši se identifikacija funkcionalnih procesa i podatkovnih grupa.
Funkcionalnosti koje sustav treba pruţiti krajnjem korisniku su prikazane pomoću modela
strukture procesa. Model strukture procesa je kolekcija ili skup klasa procesa gdje svaka klasa
procesa ima metode koje podrţavaju funkcionalnosti u skladu s funkcionalnim zahtjevima
korisnika.
Ove klase procesa su preslikane u dijagrame toka procesa koji predstavljaju funkcionalne
pocese. Kod UWE pristupa, koriste se dva tipa klasa procesa: <<navigationalClass>> i
<<processClass>>. Stereotip <<navigationalClass>> ilustrira tok aktivnosti korisnika i
moguća grananja klasa procesa koje se nalaze unutar modela strukture procesa. Stereotip
<<processClass>> je klasa koja preslikava funkcionalne zahtjeve korisnika (FUR) u
dijagram toka procesa. Identifikacija kretanja podatkovnih grupa unutar dijagrama toka
procesa je postignuta pomoću <<userAction>> (u korisničkoj plivajućoj stazi),
<<displayAction>> (u korisničkoj plivajućoj stazi), <<systemAction>> (u plivajućoj stazi
sustava) i <<CentralBufferNode>> (u plivajućoj stazi spremišta podataka) UWE elemenata
(slika 9.1, (1))6.
Komunikacija izmeĎu ovih elemenata moţe biti tipa toka podataka (XMI oznaka object
flow) ili toka izvršavanja aktivnosti (XMI oznaka control flow). Ako je komunikacija izmeĎu
prethodno navedenih UWE stereotipova tipa object flow, onda se mogu identificirati kretanja
grupa podatka i stoga postoji mogućnost identifikacije CFP elementa (Entry, Exit, Read, ili
Write). Ako je komunikacija izmeĎu ovih elemenata tipa control flow, onda se ne moţe
6 Podatkovne grupe i njihovi atributi mogu se izmjenjivati izmeĎu stereotipova <<userAction>>,
<<systemAction>>, <<displayAction>> ili <<CentralBufferNode>> unutar dijagrama toka procesa.
114
identificirati CFP element izuzev u slučaju kada se radi o inicijalizaciji procesa što je na
dijagramu aktivnosti prikazano takoĎer pomoću stereotipa <<userAction>> ali sa strelicom
tipa toka izvršavanja aktivnosti (control flow). Ovaj poseban slučaj koji predstavlja
inicijalizirajući ulaz (engl. initial Entry) se identificira kao CFP Entry (E) tip kretanja
podataka.
Slika 9.1 predstavlja preslikavanje izmeĎu generičkog softverskog modela (engl. Generic
Software Model) COSMIC-a i UWE dijagrama toka procesa (slika 9.1,(5)).
Identifikacija UWE dijagrama toka procesa u XMI (XML Metadata Interchange) datoteci je
prikazan na istoj slici (slika 9.1, (6)).
Faza mjerenja je posljednja faza implementacije COSMIC mjernih pravila. Ova faza je
najznačajnija zato što se unutar nje vrši stvarno brojanje kretanja podataka i na kraju te faze
dobiva se ukupni CFP za cijeli mjereni softver. U ovoj fazi, vrši se identifikacija kretanja
podataka i agregacija mjernih rezultata. Prvo, za svaki funkcionalni proces, identificira se
podatkovna grupa. Tok podataka podatkovnih grupa je identificiran kroz dijagrame toka
procesa uz podršku podatkovnih strelica koje pokazuju smjer kretanja podataka izmeĎu UWE
stereotipova <<userAction>> i <<systemAction>>, ili <<systemAction>> i
<<CentralBufferNode>> (slika. 9.1, (4)). Strelice koje su tipa toka procesa, a nalaze se
izmeĎu dva UWE stereotipa predstavljaju sekvencu izvršavanja komandi unutar
funkcionalnog procesa i stoga se ne bi trebali smatrati kao kretanje podatkovnih grupa, pa
prema tome one nisu uključene u CFP mjerni proces. Smjer kretanja podataka izmeĎu UWE
stereotipova koji definiraju da li postoji tip kretanja podataka Entry, Exit, i Read ili Write se
postiţe uz pomoć izvornih i odredišnih elemenata kod UWE dijagrama toka procesa (slika
9.1, (2)). Ovi izvorni i odredišni elementi se identificiraju pomoću UWE čvorova na
dijagramima aktivnosti označenih pin elementom koji su pozicionirani na UWE
stereotipovima (userAction, systemAction, displayAction ili CentralBufferNode; slika 9.1,
(3)). Strelice za tok podataka unutar dijagrama toka procesa predstavljaju kretanje podatkovne
grupe, koje moţe biti prema pin elementu kao odredište i od pin elementa kao izvorište prema
ili od UWE stereotipova. Tablica 7.3 iz poglavlja 7 prikazuje smjer toka podataka od pin
elemenata ili prema pin elementima kao izvornim ili odredišnim elementima unutar dijagrama
toka procesa.
115
Slika 9.1. Mapiranje izmeĎu generičkog softverskog modela COSMIC metode i UWE
dijagrama tijeka procesa (5); Identifikacija UWE elemenata dijagrama tijeka procesa (6).
Algoritam za identificiranje XMI elemenata koji se koristiti u izračunu kretanja podataka,
prikazan je pseudo kodom u tablici 9.1. Za svaki funkcionalni proces označen sa fpi opisan
XMI oznakama tgi unutar XMI datoteke prikazano u tablici 9.1 izračunava se kretanje
podataka. Obzirom da kretanje podataka moţe biti tipa Entry, Exit, Read ili Write, potrebno je
za svaki stereotip kod kojeg postoji mogućnost da šalje ili prima poruke ili podatke
identificirati XMI elemente koji opisuju njegova stanja (da li šalje ili prima podatke) i
poziciju unutar dijagrama aktivnosti (u kojoj plivajućoj stazi se nalazi). Ovi elementi su
označeni kao <node> tagovi i svaki do njih ima dodatne atribute koji ih detaljnije opisuju.
Atributi koji su bitni za algoritam unutar <node> taga su:
xmi:type, koji označava tip elementa koji moţe biti uml:CentralBufferNode
(predstavlja storage stereotip), uml:InitialNode (predstavlja početak dijagrama
aktivnosti), uml:ActivityFinalNode (predstavlja kraj dijagrama aktivnosti),
uml:CallBehaviorAction (predstavlja user ili system stereotip), uml:DecisionNode
(predstavlja čvorište odluke) i uml:ActivityPartition (predstavlja plivajuću stazu).
116
dodatni tagovi unutar <node> taga označeni kao <incoming> (predstavljaju dolazne
poruke ili podatke u stereotip), <outgoing> (predstavljaju odlazne poruke ili podatke
van stereotipa), <inPartition>(označava plivajuću stazu).
Primjer za identifikaciju elemenata XMI datoteke sukladno algoritmu iz tablice 9.1 bi bio
sljedeći. U tablici 9.1 TG predstavlja skup XMI oznaka tgi pri čemu se za svakog od njih
unutar čvora (<node>) od interesa u njegovim svojstvima (engl. properties) identificiraju
izvorni i odredišni elementi tj. da li je taj element (tgi) izvor ili odredište (<outgoing> ili
<incoming>), u kojoj se plivajućoj stazi nalazi (<inPartition>) i da li je slijed izvršavanja
aktivnosti tipa toka podataka (object flow) ili toka izvršavanja aktivnosti (control flow).
Primjer bi bio sljedeći. Element tipa xmi:type='uml:CentralBufferNode' je elemenat tgi i on
ima XMI oznaku <node> i predstavlja storage element. On se nalazi unutar plivajuće staze
označene unutarnjom XMI oznakom <inPartition>, pri čemu plivajuća staza <inPartition>
moţe biti tipa user, system ili storage, a xmi_type_source (<outgoing>) ili xmi_type_target
(<incoming>) su oznake elemenata ovisno od toga da li se podaci primaju ili šalju odnosno
da li je pin element input ili output tipa. Na ovaj način je izvršeno označavanje varijabli
tip_izvora, segment_izvora, tip_odredišta, segment_odredišta i is_control_flow u algoritmu
prikazanom u tablici 9.1.
Na ovaj način postoji mogućnost da se svaki stereotip koji se koristi u dijagramu
aktivnosti, a poslije predstavljen kroz XMI datoteku, identificira, utvrdi njegova pozicija
unutar dijagrama aktivnosti (u kojoj plivajućoj stazi se nalazi) i da se odredi da li šalje ili
prima podatke. Na ovaj način moguće je dijagram aktivnosti, pomoću kojeg je opisan
funkcionalni proces, predstaviti i na tekstualan način i na taj način omogućiti izvršavanje
njegove analize.
Tablica 9.1. Algoritam za identificiranje elemenata XMI datoteke i izračun sumarne
vrijednosti za kretanja podataka.
algoritam identifikacija_elemenata(project_id_xmi_file)
ulaz: XMI zapis UWE konceptualnog modela
izlaz: data_movement_fp sumarna vrijednost CFP za funkcionalni proces izraţena kao cjelobrojna
vrijednost
begin
Neka je FP={fp1, fp2, …, fpn} skup funkcionalnih procesa identificiranih unutar XMI zapisa.
Neka je TG={tg1, tg2, …., tgn} skup XMI oznaka unutar funkcionalnog procesa.
117
for each fpi ∈ FP do
for each tgi ∈ TG do
tip_izvorai:=tgi.xmi_type_source
segment_izvorai:=tgi.partition_source
tip_odredištai:=tgi.xmi_type_target
segment_odredištai:=tgi.partition_target
is_control_flowi:=tgi.object_control_flow
data_movement:= AlgoritamZaIdentifikacijuVrsteKretanjaPodataka (tip
_izvorai, segment_izvorai, tip_odredištai, segment_odredištai,
is_control_flowi)
if(data_movement==Entry)
data_movement_entry++
else if (data_movement==Exit)
data_movement_exit++
else if (data_movement==Read)
data_movement_read++
else if(data_movement==Write)
data_movement_write++
end if
data_movement_tags:= data_movement_entry+ data_movement_exit+
data_movement_read+ data_movement_write
end for
data_movement_fp:= data_movement_fp+ data_movement_tags
end for
return data_movement_fp
end identifikacija_elemenata
Tablica 9.1 prikazuje algoritam pomoću kojeg se vrši identifikacija svakog od tagova XMI
zapisa koji su potrebni za proces izračuna kretanja podataka. Za svaki od ţeljenih elemenata
se uzimaju podaci kao što su tip XMI elementa izvornog i odredišnog kretanja, segment
unutar kojeg se ti elementi nalaze unutar dijagrama aktivnosti UWE konceptualnog modela
kao i podatak da li se radi o kretanju podataka (engl. ObjectFlow) ili se radi o izvršavanju
naredbi kontrole tijeka izvršavanja procesa (engl. ControlFlow). Ovaj algoritam za potrebe
izračunavanja kretanja podataka poziva funkciju
AlgoritamZaIdentifikacijuVrsteKretanjaPodataka() kojoj prosljeĎuje identificirane ţeljene
elemente XMI zapisa a kao povratnu informaciju dobiva podatak o identificiranom tipu
118
kretanja podataka. Algoritam za identifikaciju elemenata iz tablice 9.1 prilikom svakog poziva
algoritma za identifikaciju vrste kretanja podataka iz tablice 9.2 uvećava brojač pronaĎenih
ţeljenih elemenata (Entry, Exit, Read ili Write kretanja podataka) za vrijednost jedan ukoliko
pronaĎe odgovarajući element. Algoritam suštinski broji postojanje kretanja podataka (Entry,
Exit, Read ili Write) koji moraju već biti prikazani u UWE modelu procesa. Model procesa je
onaj kod kojeg je jako vaţno da su ispravno prikazana kretanja podataka, bilo da je jedan ili
više kretanja podataka istog ili različitog tipa, npr. više Exit ili više Read tipova kretanje
podataka. Nakon što su oni ispravno prikazani u UWE modelu procesa, oni su tako
pozicionirani i u samom XMI zapisu (u odgovarajućoj plivajućoj stazi i sa ispravno
postavljenim smjerom kretanja). Nakon što je to uraĎeno, algoritmu više nije bitno da li se
radi o jednom Entry (Exit, Read ili Write) ili više njih unutar XMI zapisa odnosno UWE
modela procesa. Algoritam tada samo izbroji njihovo postojanje i u konačnici prikaţe sumu
vrijednosti kretanja podataka.
Algoritam za identifikaciju vrste kretanja podataka, a koji se poziva iz algoritma za
identificiranje elemenata XMI datoteke (tablica 9.1), prikazan je u tablici 9.2.
Tablica 9.2. Algoritam za identifikaciju vrste kretanja podataka.
algoritam AlgoritamZaIdentifikacijuVrsteKretanjaPodataka(tip_izvora, segmen_izvora, tip_
odredišta, segment_ odredišta, is_control_flow)
ulaz: elementi XMI oznaka potrebni za identifikaciju kretanja podataka
izlaz: vrsta CFP kretanja podataka za tagove funkcionalnih procesa
begin
if(is_control_flow)
if tip_izvora = uml_InitialNode and segment_izvora = User and (tip_odredišta =uml_
CallBehavioralAction or tip_odredišta =uml_ DecisionNode) and segment_ odredišta =
System then
return Entry
end if
else
if tip_izvora = uml_ CallBehavioralAction and segment_izvora = User and (tip_odredišta
=uml_ DecisionNode or tip_odredišta =uml_ CallBehavioralAction) and segment_ odredišta
= System then
return Entry
end if
if tip_izvora = uml_ DecisionNode and segment_izvora = User and tip_odredišta =uml_
119
CallBehavioralAction and segment_ odredišta = System then
return Entry
end if
if tip_izvora = uml_ DecisionNode and segment_izvora = System and tip_odredišta =uml_
CallBehavioralAction and segment_ odredišta = User then
return Exit
end if
if tip_izvora = uml_ DecisionNode and segment_izvora = System and tip_odredišta =
uml_CentralBufferNode and segment_ odredišta = Storage then
return Write
end if
if tip_izvora = uml_ CallBehavioralAction and segment_izvora = System and (tip_odredišta
=uml_ CallBehavioralAction or tip_odredišta = uml_ActivityFinalNode) and segment_
odredišta = User then
return Exit
end if
if tip_izvora = uml_CallBehavioralAction and segment_izvora = System and tip_odredišta =
uml_CentralBufferNode and segment_odredišta = Storage then
return Write
end if
if tip_izvora = uml_CentralBufferNode and segment_izvora = Storage and tip_odredišta =
uml_CallBehavioralAction and segment_odredišta = System then
return Read
end if
end if
end
return null
Algoritam za izračun kretanja podataka prikazan u tablici 9.2 moţe se prikazati i dijagramom
toka na slici 9.2.
120
Slika 9.2. Prikaz algoritma za izračun kretanja podataka pomoću dijagrama toka.
9.2. Arhitektura i implementacija sustava za automatizaciju CFP mjerenja
Za COSMIC FSM mjernu metodu predstavljenu u [88], razvijena je web aplikacija koja
kao ulazni parametar uzima UWE model, a kao rezultat omogućava automatizirano mjerenje
funkcionalne veličine sustava i daje cjelokupan izvještaj o mjerenom sustavu. Ovaj izvještaj
uključuje naziv klase procesa koja je obraĎena, zatim ručno i automatizirano dobiveni CFP.
Ručno izračunati CFP se dobiva pregledom modela i primjenom COSMIC mjernih pravila na
modele web aplikacija koje su korištene u projektnom zadatku. Pojedinačne i sumarna
vrijednost CFP za svaki funkcionalni proces se unosi putem web forme u WADEES sustavu i
to na istom mjestu na kojem WADEES generira izvještajnu formu vezanu za prikaz izračuna
CFP-a automatiziranim putem. Nakon toga, korisnik ima mogućnost da izvrši snimanje ovih
podataka u WADEES sustavu. Razvijena web aplikacija nazvana je WADEES (Web
Application Development Effort Estimation System) [145] i implementiran je u programskom
jeziku Java. S obzirom da WADEES trajno pohranjuje podatke, kao sustav za trajnu pohranu
podataka korišten je MySQL server verzije 5.1. Kao aplikativni server za izvršavanje
aplikacija korišten je Apache Tomcat server 7.0.41. WADEES sustav koristi XMI (XML
Metadata Interchange) format datoteke koji predstavlja UWE model web aplikacije za koji je
121
potrebno izračunati veličinu u obliku funkcionalnih točaka. WADEES koristi SAX (Simple
API for XML) parser za obradu XMI datoteke pomoću koje je opisan UWE model.
Osnovne funkcije WADEES sustava su:
uvoz UWE modela web aplikacije,
parsiranje XMI datoteke kako bi se izdvojili samo bitni dijelovi podataka kôda
modela,
pohrana izdvojenih podataka u bazu podataka,
izračun CFP na osnovu izdvojenih elemenata, i prikaz rezultata izračuna CFP-a.
9.3. Pregled WADEES sustava
Uporaba WADEES sustava podrazumijeva postojanje UWE modela web aplikacije. UWE
model web aplikacije se kreira pomoću alata MagicUWE koji predstavlja nadogradnju
MagicDraw alata namjenjenog za modeliranje softvera s tom razlikom što je MagicUWE
kreiran isključivo za modeliranje web aplikacija. Korisnik prvo kreira model sa dijagramima
slučaja korištenja, zatim kreira model sadrţaja, pa potom model navigacije i na kraju model
procesa. Model procesa sadrţi dijagrame aktivnosti a koji su potrebni za izračun CFP-a za
model web aplikacije. Na kraju, model procesa se izvozi u datoteku tipa XMI formata koja je
onda spremna za učitavanje u WADEES sustav.
WADEES se sastoji od nekoliko modula:
modul za unos detaljnih podataka o projektu,
modul za slanje XMI datoteke na posluţitelj koja predstavlja konceptualni model web
aplikacije,
SAX parser za obradu XMI datoteke i izdvajanje potrebnih elemenata,
modul za smještanje podataka u bazu podataka,
modul sa pravilima za analizu i brojanje elemenata i modul za prikaz rezultata
mjerenja.
Shematski prikaz aktivnosti unutar WADEES-a predstavljen je na slici 9.2. Korisnik
modelira aplikaciju i generira XMI datoteku na osnovu UWE modela. Ova datoteka se onda
šalje u sustav WADEES zajedno sa sljedećim informacijama o projektu: naziv projekta, tip
aplikacije (podatkovna aplikacija, sustav za upravljanje sadrţajima, sustav za upravljanje
dokumentima itd.), korišteni programski jezik za razvoj web aplikacije (PHP, Java, C# itd.),
broj programera koji je bio uključen u razvoj aplikacije, iskustvo programera (izraţeno u
broju godina), izvor projekta (odakle se dobio projekt, industrija/softverska tvrtka, obrazovne
122
institucije itd.), razvojno okruţenje koje je korišteno (ako je korišteno), sustav za pohranu
podataka koji je korišten (slika 9.3.). Nakon što je datoteka poslana u sustav WADEES, ona je
prikazana na sustavu kao dostupna za obradu. Korisnik sustava inicira procesiranje nakon
čega XMI parser obraĎuje XMI datoteku i vrši izdvajanje relevantnih informacija potrebnih
za CFP mjerni proces. Kada je završen prvi dio obrade XMI zapisa, korisnik iz izdvojenih
relevantnih informacija odabire UWE elemente toka procesa koji će se daljnje obraditi. Ovi
elementi su UWE dijagrami aktivnosti koji predstavljaju funkcionalne procese (slika 9.1.).
Zatim, korisnik aktivira komandu za procesiranje XMI datoteke da bi se izvršilo preslikavanje
elemenata UWE modela prema COSMIC mjernim pravilima pomoću stroja za generiranje
pravila. Kada stroj za generiranje pravila završi procesiranje, CFP brojač broji kretanja
podataka i generira rezultat u obliku CFP veličine za obraĎeni element toka procesa. ObraĎeni
elementi se spremaju u bazu podataka. Vaţno je napomenuti da se unutar ovog procesa, svaki
element toka procesa UWE konceptualnog modela obraĎuje zasebno. Stoga, da bi se dobila
ukupna CFP veličina za cijelu web aplikaciju, potrebno je ponoviti ove korake za svaki
element toka procesa UWE konceptualnog modela.
Slika 9.2. Shema postupka procjene funkcionalne veličine web aplikacije [88].
123
Slika 9.3. Forma za prikaz detalja vezanih za projekt i lista zapisa koji trebaju biti obraĎeni
unutar projekta.
9.3.1. WADEES arhitektura
WADEES sustav je implementiran korištenjem višeslojne arhitekture. Prezentacijski sloj je
kreiran uz pomoć tehnologije Primefaces JSF, dok je poslovna logika kreirana korištenjem
tehnologije Java beans. Kao spremište podataka korištena je baza podataka MySQL. U
poslovnom sloju se nalaze funkcije za izdvajanje potrebnih podataka koje obraĎuju XMI
datoteke, zatim funkcije sa pravilima za implementaciju COSMIC mjerenja, i funkcije za
mapiranje elemenata izmeĎu COSMIC FSM i UWE modela.
9.3.2. Primjer obrade podataka
Evaluacija sustava WADEES provedena je na skupu od 19 web aplikacija. Konceptualni
modeli web aplikacija su izvezeni kao XMI datoteka i onda uvezeni u WADEES sustav.
Namjena evaluacije je bila demonstracija mogućeg izračuna funkcionalne veličine web
124
aplikacija na osnovi konceptualnog model koji je opisan pomoću XMI datoteke. TakoĎer,
potrebno je bilo i demonstrirati da UWE konceptualni modeli mogu opisati sve relevantne i
potrebne informacije za potrebe COSMIC FP mjerenja, i da je WADEES sustav sposoban
izvršiti uvoz i obradu informacija koje su modelirane pomoću UWE pristupa.
Ilustracija procesa je prikazana na primjeru jedne UWE klase toka procesa,
EditSubjectName. Ova klasa se prikazuje dijagramom aktivnosti s uključenim UWE
stereotipovima [88]. Svaki UWE konceptualni model je obraĎen na isti način kao što je to
prikazano na slici 9.2. Nakon obrade, WADEES prikazuje informaciju vezanu za obraĎene
elemente (na primjer, ime elementa, ukupnu sumu izračunatih kretanja podataka ručno i
automatski). WADEES je identificirao ukupno CFP=7 kretanja podataka za EditSubjectName
element toka procesa (koji je takoĎer prethodno prikazan u dijagramu toka procesa na slici
9.1), i on je identificirao Entry=2, Exit=2, Read=2 i Write=1 (slika 9.4).
Slika 9.4. Primjerni prikaz obraĎenih elemenata iz UWE konceptualnog modela unutar
WADEES sustava.
Nakon dobivenih rezultata, moţe se izvesti zaključak da automatizirano mjerenje radi na
zadovoljavajućem nivou, što je moguće vidjeti i kroz usporedbu rezultata ručnog i
automatskog izračuna rezultata. Naravno, kako niti jedan sustav nije savršen, trenutno i ovaj
sustav ima svojih nedostataka što se moţe uočiti na izračunu elemenata modela prikazano na
slici 9.5.
125
Slika 9.5. Prikaz usporedbe ručnog i automatiziranog mjerenja za slučaj odstupanja u
mjerenjima.
Kako vidimo, u ovom slučaju WADEES nije imao apsolutnu točnost u slučaju
automatiziranog mjerenja u odnosu na ručno mjerenje. ObraĎeni rezultati prikazani na slici
10.4.1 pokazuju podudarnost izmeĎu ručnog i automatiziranog mjerenja od 88,31%.
Prethodna slika kod većine funkcionalnih procesa pokazuje skoro sto procentnu podudarnost
izmeĎu ručnog i automatiziranog mjerenja kod prikaza ukupnog CFP-a za jedan funkcionalni
proces. MeĎutim, iako postoji velika podudarnost u ukupnom CFP-u za jedan funkcionalni
proces (na primjer CreateOrganizationUnit) kada se pogledaju pojedinačna kretanja podataka
(Entry, Exit, Read ili Write) izračuni za ručno i automatizirano mjerenje se razlikuju
(CreateOrganizationUnit, ručno CFP: ukupno=4, E=1, X=1, R=1, W=1; automatizirano CFP:
ukupno=4, E=0, X=2, R=1, W=1). Dakle, WADEES sustav zahtijeva dodatnu doradu i
testiranje kako bi vremenom postao još precizniji sustav za obradu ove vrste podataka.
Uvaţavajući prethodnu činjenicu i dalje se moţe reći da razvijeni model sa XMI parserom i
stroj za generiranje pravila prilično korektno i veoma precizno obraĎuju elemente u skladu s
pravilima preslikavanja izmeĎu UWE pristupa i COSMIC mjerenja. Rezultati su takoĎer u
skladu s prethodno izvedenom studijom u radu [88]. Isti proces obrade zapisa primijenjen je
na svaki element toka procesa u UWE konceptualnom modelu.
126
9.3.3. Izračun CFP-a za svaki od korištenih modela
Nakon učitavanja svih modela u WADEES, svaki od njih je prošao proces izračuna CFP
elemenata za svaki postojeći funkcionalni proces koji je prikazan kroz UWE konceptualni
model.
Tablica 9.3 prikazuje izračun CFP-a za svaki od 19 web projekata koji su korišteni u
procesu izrade modela za procjenu uloţenog napora. Iz tabele moţe se vidjeti da je WADEES
uspio izvršiti identifikaciju CFP elemenata s točnošću od 81,55%. Ovaj rezultat je
obećavajući iako je poţeljno nastaviti proces kalibracije modela kako bi mogao dostići što
veću razinu točnosti.
Ovaj podatak ukazuje na činjenicu da XMI parser i alat za procesiranje pravila mjerenja s
velikom točnošću obavljaju proces preslikavanja sukladno pravilima koja su definirana za ovu
potrebu, a koja se provode pomoću stroja za preslikavanja izmeĎu UWE elemenata i
COSMIC mjerenja kao i za izračun CFP elemenata.
Tablica 9.3. Izračun CFP vrijednosti za svih 19 web projekata.
R.B. Projekt CFP ručno CFP automatski %
1 P1 77 77 100,00
2 P2 65 45 69,23
3 P3 60 40 66,67
4 P4 77 68 88,31
5 P5 69 54 78,26
6 P6 72 43 59,72
7 P7 38 28 73,68
8 P8 187 133 71,12
9 P9 87 76 87,36
10 P10 59 59 100,00
11 P11 65 55 84,62
12 P12 66 55 83,33
13 P13 38 33 86,84
14 P14 110 96 87,27
15 P15 42 37 88,10
16 P16 54 48 88,89
127
17 P17 28 24 85,71
18 P18 28 24 85,71
19 P19 57 48 84,21
Ukupno 1279 1043 81,55
9.4. Automatizacija izračuna napora pomoću WADEES sustava
Pored svih već analiziranih elemenata sustava WADEES, on posjeduje i modul koji na
osnovu ukupno izračunate vrijednosti CFP-a za neku novu web aplikaciju procjenjuje
potrebni napor za njen razvoj. Vrijednost CFP-a je izračunata na osnovi konceptualnog
modela web aplikacije. Ovaj modul, pored procjene potrebnog napora, omogućava izračun
vrijednosti R2 za elemente u bazi podataka na osnovu kojih je generirana linearna regresijska
jednadţba, zatim vrijednosti koeficijenata regresijske jednadţbe, kao i na kraju grafikon na
kojem je prikazana regresijska jednadţba zajedno s pravcem koji pokazuje najbolje
poklapanje za izračunatu regresiju.
Na slici 9.6, prikazan je primjer izračuna napora i generiranje svih izračunatih i grafičkih
elemenata kada su unesene vrijednost CFP-a za neku web aplikaciju.
Ovaj modul sustava koristi ugraĎene funkcije za izračun vrijednosti parametara jednadţbe
koje su već programirane tako da kao ulazni parametar prihvaćaju podatke za CFP i Effort iz
baze podataka za sve projekte i na osnovu tih podataka generiraju jednadţbu za model
procjene napora. Za grafički prikaz regresijskog pravca na osnovu parametara iz obraĎenih
projekata, korištena je besplatna biblioteka JFreeChart7 koja izmeĎu ostalog ima i mogućnost
za generiranje ovakvih prikaza u razvojnom okruţenju koje koristi Java programski jezik.
7 JFreeChart, besplatna Java biblioteka za kreiranje grafikona,
http://www.jfree.org/jfreechart/
128
Slika 9.6. Prikaz izračuna elemenata WADEES modula za procjenu potrebnog napora nove
aplikacije.
Modul za izračun i prikaz elemenata modela za procjenu uloţenog napora ima tri
segmenta. Prvi segment prikazuje izračun koeficijenata regresije za jednadţbu modela kao i
R2 vrijednost za podatke iz projekata.
Drugi segment osim prikaza jednadţbe modela za procjenu napora omogućava da i
korisnik unese vrijednosti za CFP i Effort novog projekta, a da mu sustav generira procjenu
129
napora za razvoj nove web aplikacije na osnovu funkcionalne veličine web aplikacije. Na ovaj
način korisnik moţe provjeriti razliku izmeĎu stvarnog uloţenoga napora i onog koji je sustav
procijenio ali samo ako je web aplikacije već bila razvijena. Parametar za Effort nije obavezan
za nove projekte koji samo imaju CFP vrijednost na osnovu kreiranog konceptualnog modela
web aplikacije.
Treći segment vrši prikaz regresijske jednadţbe na osnovu kojeg je moguće i vizualno
prikazati koliko dobro jednadţba kreiranog modela prati vrijednosti ostalih projekata na
osnovu kojih je i kreirana sama jednadţba.
130
ZAKLJUČAK
Procjena napora potrebnog za razvoj web aplikacija predstavlja problem koji nema
trivijalno rješenje niti ga je moguće jednoznačno definirati. Trenutno postoji veliki broj
metoda i procedura pomoću kojih je moguće pribliţno procijeniti potreban napor za razvoj
klasičnih softverskih aplikacija. S obzirom da se razvoj web aplikacija razlikuje od razvoja
klasičnog softvera, kako u pogledu korištenih programskih jezika tako i u domeni korištenih
tehnologija unutar jednog web projekta to nije moguće direktno primijeniti metode i
procedure za procjenu napora klasičnih softverskih aplikacija na web aplikacije. Činjenica je
da niti jedan do sada analizirani pristup za procjenu teţine razvoja web aplikacija nije utvrdio
i predloţio smjernice kada je moguće primijeniti neku metodu u nekom odreĎenom scenariju.
TakoĎer, utvrĎeno je da ne postoji univerzalna metoda kad je u pitanju procjena teţine razvoja
Web aplikacija. Za procjenu teţine razvoja web aplikacija bazirano na modelima u ranoj fazi
razvoja postoji jako mali broj radova koji istraţuje ovu materiju. Većinom razvoj web
aplikacija počinje skiciranjem potencijalnog aplikativnog rješenja. Obzirom na tu činjenicu i
da razvoj obično kreće od konceptualnih modela, iste je moguće primijeniti u oblasti procjene
uloţenog napora za aplikacije koje tek treba napraviti. Konceptualni modeli sadrţe
informacije o potencijalnoj web aplikaciji koja se razvija, ali je ovaj prikaz baziran na
apstraktnoj razini.
Cilj ove disertacije je bio da se identificiraju elementi web aplikacija i primijene moguće
mjerne metode na te elemente kako bi se veličina web aplikacija na neki način izmjerila i
kako bi se utvrdilo postojanje veze izmeĎu veličine web aplikacije i uloţenog napora.
Obzirom da web aplikacije većinom upravljaju podacima, a podaci se prenose od korisnika
ka sustavu i obratno, kao adekvatna mjerna metoda za mjerenje veličine web aplikacija je
korištena mjerna metoda COSMIC za izračun funkcionalne veličine samih aplikacija.
Mjerenje funkcionalne veličine je izvršeno nad modelima funkcionalnih procesa koji su u
konceptualnim modelima predstavljeni pomoću dijagrama aktivnosti.
Modeli web aplikacija su kreirani pomoću metode UML-baziranog web inţenjeringa
(UWE). Za potrebe preslikavanja izmeĎu UWE modela i COSMIC mjerne metode, kreirana
su pravila koja predstavljaju jedan od osnovnih elemenata potrebnih za uspješno provoĎenje
procesa mjerenja funkcionalne veličine web aplikacija.
Model procjene veličine web aplikacije je kreiran pomoću metode linearne regresije s
jednom varijablom, CFP, za koju je analizom modela web aplikacija utvrĎeno da je
131
najmjerodavnija kao veličina koja u velikoj mjeri ima utjecaja i veze s uloţenim naporom.
Sama varijabla je mjera funkcionalne razvijenosti i razvoja web aplikacija.
Za potrebe demonstracije praktične uporabe predloţenog modela, razvijen je sustav
WADEES koji sadrţi sve potrebne module za procjenu potrebnog napora na osnovu
konceptualnog modela. Ulazni podatak u sustav WADEES je konceptualni model web
aplikacije kreiran pomoću UWE alata MagicUWE. Sustav WADEES na osnovi
konceptualnog modela generira funkcionalnu veličinu web aplikacije. Sustav je u mogućnosti
da na osnovu izračunate funkcionalne veličine web aplikacije izračuna (procjeni) potrebni
napor za kreiranje web aplikacije za koju je poznat konceptualni model. Parametri
matematičkog modela na osnovu kojeg se vrši izračun potrebnog napora za razvoj web
aplikacija se mogu nanovo izračunati za svaki novi model dodan u repozitorij završenih
projekata. Matematički model sustava WADEES se moţe kalibrirati na osnovi novih
podataka o završenim projektima. Na ovaj način je postignuto da sustav WADEES bude
adaptabilan, odnosno, da ga je moguće kontinuirano nadograĎivati. Za potrebe izrade sustava,
inicijalno su korišteni podaci od 19 završenih web projekata.
U ovoj disertaciji osmišljen je i implementiran mehanizam za identifikaciju i preslikavanje
parametara UWE konceptualnog modela prema mjernoj metodi COSMIC, definirani su
mogući problemi i predloţena su potencijalna rješenja u pogledu vrsta web aplikacija nad
kojima je moguće primijeniti razvijeni model.
Kreirani model je otvorio nekoliko novih pravaca istraţivanja koji se ogledaju u primjeni
nekih drugim metoda za kreiranje modela procjene napora, zatim korištenja novih ili dodatnih
parametara kao ulaznih veličina u model kao i mogućnost korištenja nekih drugih metoda za
izračun veličine web aplikacija.
Na temelju ove disertacije bit će provedena daljnja istraţivanja i proširenje sustava
WADEES uporabom novih metoda za izračun veličine web aplikacija na osnovu
konceptualnih modela, dopunjavanje baze podataka s podacima o novim projektima. Na
osnovi podataka iz novih projekata izvršit će se analiza mogućnosti primjene neke druge
metode za kreiranje modela procjene uloţenog napora.
132
REFERENCE
[1] B. Marín, N. Condori-Fernández, O. Pastor, and A. Abran, ―Measuring the Functional
Size of Conceptual Models in an MDA Environment.,‖ in In proceeding of:
Proceedings of the Forum at the CAiSE’08 Conference, Montpellier, France, 2008, pp.
33–36.
[2] S. Abrahão, J. Gómez, and E. Insfran, ―Validating a size measure for effort estimation
in model-driven Web development,‖ Inf. Sci., vol. 180, no. 20, pp. 3932–3954, Oct.
2010.
[3] ―Standish Group 2010. CHAOS Summary 2010,‖ 2010. [Online]. Available:
https://cours.etsmtl.ca/mti515/Notes/Cours01/CHAOS%20Summary%202010.pdf.
[4] G. Rossi and D. Schwabe, ―Modeling and Implementing Web Applications with
Oohdm,‖ in Web Engineering: Modelling and Implementing Web Applications, G.
Rossi, O. Pastor, D. Schwabe, and L. Olsina, Eds. London: Springer London, 2008, pp.
109–155.
[5] S. Ceri, P. Fraternali, and A. Bongio, ―Web Modeling Language (WebML): a modeling
language for designing Web sites,‖ Comput. Netw., vol. 33, no. 1–6, pp. 137–157, Jun.
2000.
[6] J. Gómez, C. Cachero, and O. Pastor, ―Conceptual Modeling of Device-Independent
Web Applications,‖ IEEE Multimed., vol. 8, no. 2, pp. 26–39, Apr. 2001.
[7] R. Paiano and A. Pandurino, ―From the Design to the Development: a W2000 Based
Framework, Issues and Guidelines,‖ in Proceedings of Information Resources
Management Association (IRMA) International Conference, Philadelphia, PA, 2003.
[8] ―MagicUWE,‖ UWE – UML-based Web Engineering. [Online]. Available:
http://uwe.pst.ifi.lmu.de/toolMagicUWE.html. [Accessed: 13-Dec-2012].
[9] G. Costagliola, S. Di Martino, F. Ferrucci, C. Gravino, G. Tortora, and G. Vitiello, ―A
COSMIC-FFP approach to predict web application development effort,‖ J Web Eng,
vol. 5, no. 2, pp. 93–120, Jun. 2006.
[10] ―The COSMIC Functional Size Measurement Method Version 3.0.1 Measurement
Manual,‖ COSMICON, 2009. [Online]. Available:
www.cosmicon.com/dl_goto.asp?id=73. [Accessed: 13-Dec-2012].
[11] ―ISO, ISO/IEC 20926: Software engineering — IFPUG 4.2 unadjusted functional size
measurement method — counting practices manual,‖ Westerville, Ohio, 2004.
[12] ―MkII Function Point Analysis Counting Practices Manual, v 1.3.1,‖ Sep-1998.
[13] ―The application of function point analysis in the early phases of the application life
cycle a practical manual: Theory and case study, Version 2.0,‖ 2005.
[14] E. J. D. Candido and R. Sanches, ―Estimating the Size of Web Applications by Using a
Simplified Function Point Method,‖ in Proceedings of the WebMedia & LA-Web 2004
Joint Conference 10th Brazilian Symposium on Multimedia and the Web 2nd Latin
American Web Congress, Washington, DC, USA, 2004, pp. 98–105.
[15] A. J. Albrecht, ―Measuring Application Development Productivity,‖ in Proc. of IBM
Application Development Symp., 1979, pp. 83–92.
[16] L. C. Briand, K. E. Emam, D. Surmann, I. Wieczorek, and K. D. Maxwell, ―An
assessment and comparison of common software cost estimation modeling techniques,‖
presented at the Software Engineering, 1999. Proceedings of the 1999 International
Conference on, 1999, pp. 313–323.
[17] D. Čeke, M. Đurek, and S. Kasapović, ―Web application functional size estimation
based on COSMIC method and UWE approach,‖ in 2013 36th International
133
Convention on Information Communication Technology Electronics Microelectronics
(MIPRO), 2013, pp. 396–403.
[18] C. Gencel, O. Demirors, and E. Yüceer, ―Utilizing Functional Size Measurement
Methods for Real Time Software Systems,‖ in 11th IEEE International Software
Metrics Symposium (METRICS 2005), Como, Italy, 2005.
[19] I. Hussain, L. Kosseim, and O. Ormandjieva, ―Approximation of COSMIC functional
size to support early effort estimation in Agile,‖ Data Knowl. Eng., vol. 85, pp. 2–14,
May 2013.
[20] C. R. Symons, ―Function point analysis: difficulties and improvements,‖ IEEE Trans.
Softw. Eng., vol. 14, no. 1, pp. 2–11, Jan. 1988.
[21] ―NESMA. Netherlands software metrics association.‖ [Online]. Available:
http://nesma.org. [Accessed: 11-May-2015].
[22] ―ISO, ISO/IEC 24570: Software engineering — NESMA functional size measurement
method version 2.1 — definitions and counting guidelines for the application of
function points analysis,‖ 2005.
[23] E. Mendes, N. Mosley, and S. Counsell, ―A Comparison of Length, Complexity and
Functionality as Size Measures for Predicting Web Design and Authoring Effort,‖ in
Proceedings of Empirical Assessment in Software Engineering, Keele University,
Staffordshire, 2001.
[24] M. Ruhe, R. Jeffery, and I. Wieczorek, ―Cost estimation for web applications,‖ in 25th
International Conference on Software Engineering, 2003. Proceedings, 2003, pp. 285–
294.
[25] M. Shepperd, C. Schofield, and B. Kitchenham, ―Effort Estimation Using Analogy,‖ in
Proceedings of the 18th International Conference on Software Engineering,
Washington, DC, USA, 1996, pp. 170–178.
[26] K. R. Hannond, R. M. Hamm, J. Grassia, and T. Pearson, ―Direct comparison of the
efficacy of intuitive and analytical cognition in expert judgment,‖ IEEE Trans. Syst.
Man Cybern., vol. 17, no. 5, pp. 753–770, Sep. 1987.
[27] B. Kitchenham, ―Making process predictions,‖ in Software Metrics: A Rigorous
Approach, Chapman & Hall, Ltd. London, UK, UK, 1991, p. 320.
[28] M. Ruhe, R. Jeffery, and I. Wieczorek, ―Using Web objects for estimating software
development effort for Web applications,‖ in Software Metrics Symposium, 2003.
Proceedings. Ninth International, 2003, pp. 30–37.
[29] L. C. Briand, K. El Emam, and F. Bomarius, ―COBRA: a hybrid method for software
cost estimation, benchmarking, and risk assessment,‖ in Proceedings of the 1998
International Conference on Software Engineering, 1998, 1998, pp. 390–399.
[30] A. Trendowicz, J. Heidrich, J. Münch, Y. Ishigai, K. Yokoyama, and N. Kikuchi,
―Development of a hybrid cost estimation model in an iterative manner,‖ 2006, p. 331.
[31] F. Ferrucci, C. Gravino, and S. D. Martino, ―Estimating Web Application Development
Effort Using Web-COBRA and COSMIC: An Empirical Study,‖ in Proceedings of the
2009 35th Euromicro Conference on Software Engineering and Advanced
Applications, Washington, DC, USA, 2009, pp. 306–312.
[32] L. C. Briand and I. Wieczorek, ―Resource Estimation in Software Engineering,‖ in
Encyclopedia of Software Engineering, John Wiley & Sons, Inc., 2002.
[33] B. W. Boehm, Software Engineering Economics. Prentice Hall PTR, 1981.
[34] B. W. Boehm, C. Abts, W. Brown, S. Chulani, C. Bradford K., E. Horowitz, R.
Madachy, D. Reifer, and B. Steece, Software Cost Estimation with Cocomo II. Prentice
Hall; HAR/CDR edition, 2000.
[35] J. J. Amor, G. Robles, and J. M. Gonzalez-Barahona, ―Effort estimation by
characterizing developer activity,‖ presented at the Proceedings of the 2006
134
international workshop on Economics driven software engineering research, 2006, pp.
3–6.
[36] D. J. Reifer, ―Web Development: Estimating Quick-to-Market Software,‖ IEEE Softw,
vol. 17, no. 6, pp. 57–64, Nov. 2000.
[37] D. Reifer, ―Estimating Web Development Costs: There Are Differences,‖ in CrossTalk,
2002.
[38] M. Morisio, I. Stamelos, V. Spahos, and D. Romano, ―Measuring functionality and
productivity in Web-based applications: a case study,‖ presented at the Software
Metrics Symposium, 1999. Proceedings. Sixth International, 1999, pp. 111–118.
[39] T. Rollo, ―Functional size measurement and COCOMO—a synergistic approach,‖ in
Proc. Software Measurement European Forum ’06, Rome, Italy, 2006, pp. 259–267.
[40] L. Mangia and R. Paiano, ―MMWA: A Software Sizing Model for Web Applications,‖
in Web Information Systems Engineering, International Conference on, Los Alamitos,
CA, USA, 2003, vol. 0, p. 53.
[41] T. Bäck, U. Hammel, and H.-P. Schwefel, ―Evolutionary computation: comments on
the history and current state,‖ Evol. Comput. IEEE Trans. On, vol. 1, no. 1, pp. 3–17,
Apr. 1997.
[42] J. J. Dolado, ―On the problem of the software cost function,‖ Inf. Softw. Technol., vol.
43, no. 1, pp. 61–72, Jan. 2001.
[43] C. Mair, G. Kadoda, M. Lefley, K. Phalp, C. Schofield, M. Shepperd, and S. Webster,
―An investigation of machine learning based prediction systems,‖ J. Syst. Softw., vol.
53, no. 1, pp. 23–29, Jul. 2000.
[44] K. K. Aggarwal, Y. Singh, P. Chandra, and M. Puri, ―Bayesian Regularization in a
Neural Network Model to Estimate Lines of Code Using Function Points,‖ J. Comput.
Sci., vol. 1, no. 4, pp. 505–509, Dec. 2005.
[45] K. Srinivasan and D. Fisher, ―Machine learning approaches to estimating software
development effort,‖ IEEE Trans. Softw. Eng., vol. 21, no. 2, pp. 126–137, Feb. 1995.
[46] S. Kumar, B. A. Krishna, and P. S. Satsangi, ―Fuzzy systems and neural networks in
software engineering project management,‖ Appl. Intell., vol. 4, no. 1, pp. 31–52, Mar.
1994.
[47] A. R. Gray and S. G. MacDonell, ―A comparison of techniques for developing
predictive models of software metrics,‖ Inf. Softw. Technol., vol. 39, no. 6, pp. 425–
437, 1997.
[48] M. Shepperd, ―Software project economics: a roadmap,‖ in Future of Software
Engineering, 2007. FOSE ’07, 2007, pp. 304–315.
[49] F. J. Heemstra, ―Software cost estimation,‖ Inf. Softw. Technol., vol. 34, no. 10, pp.
627–639, Oct. 1992.
[50] C. Tsatsoulis, ―Case-based Design and Learning in Telecommunications,‖ in
Proceedings of the 2Nd International Conference on Industrial and Engineering
Applications of Artificial Intelligence and Expert Systems - Volume 1, New York, NY,
USA, 1989, pp. 509–518.
[51] F. Walkerden and R. Jeffery, ―An Empirical Study of Analogy-based Software Effort
Estimation,‖ Empir. Softw Engg, vol. 4, no. 2, pp. 135–158, Jun. 1999.
[52] E. Mendes, N. Mosley, and I. Watson, ―A Comparison of Case-Based Reasoning
Approaches to Web Hypermedia project Cost Estimation,‖ 2002.
[53] C. F. Kemerer, ―An Empirical Validation of Software Cost Estimation Models,‖
Commun ACM, vol. 30, no. 5, pp. 416–429, May 1987.
[54] I. Myrtveit and E. Stensrud, ―A controlled experiment to assess the benefits of
estimating with analogy and regression models,‖ IEEE Trans. Softw. Eng., vol. 25, no.
4, pp. 510–525, Jul. 1999.
135
[55] M. Shepperd and C. Schofield, ―Estimating software project effort using analogies,‖
IEEE Trans. Softw. Eng., vol. 23, no. 11, pp. 736–743, Nov. 1997.
[56] B. A. Kitchenham, L. M. Pickard, S. G. Macdonell, and M. J. Shepperd, ―What
accuracy statistics really measure [software estimation],‖ Softw. IEE Proc. -, vol. 148,
no. 3, pp. 81–85, Jun. 2001.
[57] E. Mendes, N. Mosley, and S. Counsell, ―Web metrics - estimating design and
authoring effort,‖ IEEE Multimed., vol. 8, no. 1, pp. 50–57, Mar. 2001.
[58] S. D. Martino and C. Gravino, ―Estimating Web Application Development Effort using
COSMIC-FFP method,‖ Int. J. Comput. Appl., vol. 31, no. 3, pp. 153–158, Jan. 2009.
[59] L. Baresi and S. Morasca, ―Three empirical studies on estimating the design effort of
Web applications,‖ ACM Trans Softw Eng Methodol, vol. 16, no. 4, Sep. 2007.
[60] A. Trendowicz and R. Jeffery, ―Appendix A: Measuring Software Size,‖ in Software
Project Effort Estimation, Springer International Publishing, 2014, pp. 433–449.
[61] ―Total Metrics.‖ [Online]. Available: http://www.totalmetrics.com/function-point-
resources/function-point-FAQ/web-based-applications. [Accessed: 12-Jan-2016].
[62] S. Abrahao, G. Poels, and O. Pastor, ―Evaluating a Functional Size Measurement
Method for Web Applications: An Empirical Analysis,‖ in Proceedings of the Software
Metrics, 10th International Symposium, Washington, DC, USA, 2004, pp. 358–369.
[63] T. Rollo, ―Sizing e-commerce,‖ in Proceedings of the Australian Conference on
Software, Sydney, 2000.
[64] D. Cleary, ―Web-Based Development and Functional Size Measurement,‖ in
Proceedings of IFPUG Annual Conference, San Diego, USA, 2000.
[65] ―Estimating Internet development, 2001,‖ Cost Xpert, Cost Xpert Group Inc. [Online].
Available: http://www.costxpert.com/Reviews_Articles/SoftDev/. [Accessed: 15-Mar-
2009].
[66] S. F. Ochoa, M. C. Bastarrica, and G. Parra, ―Estimating the development effort of
Web projects in Chile,‖ in Web Congress, 2003. Proceedings. First Latin American,
2003, pp. 114–122.
[67] P. Fraternali, M. Tisi, and A. Bongio, ―Automating function point analysis with model
driven development,‖ in Proceedings of the 2006 conference of the Center for
Advanced Studies on Collaborative research, Riverton, NJ, USA, 2006.
[68] L. De Marco, F. Ferrucci, C. Gravino, F. Sarro, S. Abrahao, and J. Gomez, ―Functional
versus design measures for model-driven Web applications: A case study in the context
of Web effort estimation,‖ in 2012 3rd International Workshop on Emerging Trends in
Software Metrics (WETSoM), 2012, pp. 21–27.
[69] D. Schwabe and G. Rossi, ―The object-oriented hypermedia design model,‖ Commun
ACM, vol. 38, no. 8, pp. 45–46, Aug. 1995.
[70] L. Baresi, F. Garzotto, and P. Paolini, ―From Web Sites to Web Applications: New
Issues for Conceptual Modeling,‖ in Conceptual Modeling for E-Business and the Web,
S. W. Liddle, H. C. Mayr, and B. Thalheim, Eds. Springer Berlin Heidelberg, 2000, pp.
89–100.
[71] N. Koch, A. Knapp, G. Zhang, and H. Baumeister, ―Uml-Based Web Engineering,‖ in
Web Engineering: Modelling and Implementing Web Applications, G. Rossi, O. Pastor,
D. Schwabe, and L. Olsina, Eds. Springer London, 2008, pp. 157–191.
[72] D. Azhar, E. Mendes, and P. Riddle, ―A Systematic Review of Web Resource
Estimation,‖ in Proceedings of the 8th International Conference on Predictive Models
in Software Engineering, New York, NY, USA, 2012, pp. 49–58.
[73] B. Marín, G. Giachetti, and O. Pastor, ―Measurement of Functional Size in Conceptual
Models: A Survey of Measurement Procedures Based on COSMIC,‖ in Proceedings of
136
the International Conferences on Software Process and Product Measurement, Berlin,
Heidelberg, 2008, pp. 170–183.
[74] L. Singh, ―Where are we? A Review of Effort and Cost Estimation Techniques used for
Web Applications,‖ in Georgian Electronic Scientific Journal, 2009, vol. No.3 (20).
[75] E. Mendes, I. Watson, C. Triggs, N. Mosley, and S. Counsell, ―A Comparative Study
of Cost Estimation Models for Web Hypermedia Applications,‖ Empir. Softw Engg,
vol. 8, no. 2, pp. 163–196, Jun. 2003.
[76] E. Mendes, ―A Comparison of Techniques for Web Effort Estimation,‖ in First
International Symposium on Empirical Software Engineering and Measurement, 2007.
ESEM 2007, Sept., pp. 334–343.
[77] B. A. Kitchenham and E. Mendes, ―A Comparison of Crosscompany and Within-
company Effort Estimation Models for Web Applications,‖ in Proceedings Metrics’04,
Chicago, Illinois, 2004.
[78] A. Corazza, S. Di Martino, F. Ferrucci, C. Gravino, F. Sarro, and E. Mendes, ―How
Effective is Tabu Search to Configure Support Vector Regression for Effort
Estimation?,‖ in Proceedings of the 6th International Conference on Predictive Models
in Software Engineering, New York, NY, USA, 2010, p. 4:1–4:10.
[79] E. Mendes, S. Counsell, and N. Mosley, ―Measurement and effort prediction of web
applications,‖ in Procs of the 2nd ICSE Workshop on Web Engineering, Limerick,
Ireland, 2000.
[80] E. Mendes, S. Di Martino, F. Ferrucci, and C. Gravino, ―Effort Estimation: How
Valuable is it for a Web Company to Use a Cross-company Data Set, Compared to
Using Its Own Single-company Data Set?,‖ presented at the WWW 2007, Banff,
Alberta, Canada, 2007.
[81] A. Corazza, S. Di Martino, F. Ferrucci, C. Gravino, and E. Mendes, ―Applying support
vector regression for web effort estimation using a cross-company dataset,‖ in 3rd
International Symposium on Empirical Software Engineering and Measurement, 2009.
ESEM 2009, 2009, pp. 191–202.
[82] E. Mendes, N. Mosley, and S. Counsell, ―Investigating early web size measures for
web cost estimation,‖ in Proceedings of the Seventh Conference on Evaluation and
Assessment in Software Engineering (EASE’03), Keele, UK, 2003, pp. 1–22.
[83] C. Lokan and E. Mendes, ―Cross-company and single-company effort models using the
ISBSG database: a further replicated study,‖ presented at the 2006 International
Symposium on Empirical Software Engineering (ISESE 2006), Rio de Janeiro, Brazil,
2006.
[84] R. Jeffery, M. Ruhe, and I. Wieczorek, ―Using public domain metrics to estimate
software development effort,‖ in Software Metrics Symposium, 2001. METRICS 2001.
Proceedings. Seventh International, 2001, pp. 16–27.
[85] S. Di Martino, F. Ferrucci, C. Gravino, and E. Mendes, ―Comparing Size Measures for
Predicting Web Application Development Effort: A Case Study,‖ in First International
Symposium on Empirical Software Engineering and Measurement, 2007. ESEM 2007,
2007, pp. 324–333.
[86] E. Mendes, N. Mosley, and S. Counsell, ―Investigating Web size metrics for early Web
cost estimation,‖ J. Syst. Softw., vol. 77, no. 2, pp. 157–172, Aug. 2005.
[87] F. Ferrucci, C. Gravino, and S. D. Martino, ―A Case Study Using Web Objects and
COSMIC for Effort Estimation of Web Applications,‖ in Proceedings of the 2008 34th
Euromicro Conference Software Engineering and Advanced Applications, Washington,
DC, USA, 2008, pp. 441–448.
[88] D. Čeke and B. Milašinović, ―Early effort estimation in web application development,‖
J. Syst. Softw., vol. 103, pp. 219–237, May 2015.
137
[89] ―‗Hints to Counting Web Sites‘: IFPUG White Paper.‖ IFPUG, 1998.
[90] ―Web Based Applications: How is FPA applied to sizing Web Based applications?,‖
Total Metrics, 2001. [Online]. Available: http://www.totalmetrics.com/function-point-
resources/function-point-FAQ/web-based-applications. [Accessed: 27-Oct-2015].
[91] O. Pastor, S. Abrahao, and J. Fons, ―An Object-Oriented Approach to Automate Web
Applications Development,‖ in Electronic Commerce and Web Technologies, K.
Bauknecht, S. K. Madria, and G. Pernul, Eds. Springer Berlin Heidelberg, 2001, pp.
16–28.
[92] O. Pastor, J. Gomez, E. Insfran, and V. Pelechano, ―The OO-Method Approach for
Information Systems Modelling: From Object-Oriented Conceptual Modeling to
Automated Programming,‖ Inf. Syst., vol. 26, no. 7, pp. 507–534, 2001.
[93] ―ISO/IEC 14143-1:2007, Information technology -- Software measurement --
Functional size measurement -- Part 1: Definition of concepts,‖ 2007.
[94] K. Czarnecki and U. W. Eisenecker, Generative Programming: Methods, Tools, and
Applications. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co.,
2000.
[95] M. S. Jenner, ―COSMIC-FFP and UML: estimation of the size of a system specified in
UML - problems of granularity,‖ presented at the 4th European Conference on
Software Measurement and ICT Control, Heidelberg, Germany, 2001, pp. 173–184.
[96] M. S. Jenner, ―Automation of Counting of Functional Size Using COSMIC-FFP in
UML,‖ presented at the 12th International Workshop Software Measurement, 2002, pp.
43–51.
[97] J. Conallen, Building Web Applications with Uml, 2nd ed. Boston, MA, USA: Addison-
Wesley Longman Publishing Co., Inc., 2002.
[98] N. Moreno, P. Fraternalli, and A. Vallecillo, ―UML 2.0 Profile for WebML Modeling,‖
presented at the 2nd ModelDriven Web Engineering Workshop, ICWE‘06, Palo Alto,
CA, 2006.
[99] ―Web Models: WebRatio.‖ [Online]. Available: http://www.webratio.com. [Accessed:
27-Oct-2015].
[100] S. Abrahão, L. De Marco, F. Ferrucci, C. Gravino, and F. Sarro, ―A COSMIC
Measurement Procedure for Sizing Web Applications Developed Using the OO-H
Method,‖ in Proceedings of the Workshop on Advances in Functional Size
Measurement and Effort Estimation, New York, NY, USA, 2010, p. 2:1–2:8.
[101] S. Abrahão, E. Mendes, J. Gomez, and E. Insfran, ―A Model-driven Measurement
Procedure for Sizing Web Applications: Design, Automation and Validation,‖ in
Proceedings of the 10th International Conference on Model Driven Engineering
Languages and Systems, Berlin, Heidelberg, 2007, pp. 467–481.
[102] B. Marín, O. Pastor, and G. Giachetti, ―Automating the Measurement of Functional
Size of Conceptual Models in an MDA Environment,‖ in Proceedings of the 9th
international conference on Product-Focused Software Process Improvement, Berlin,
Heidelberg, 2008, pp. 215–229.
[103] O. P. Lopez, F. Hayes, and S. Bear, ―Oasis: An object-oriented specification language,‖
in Advanced Information Systems Engineering, P. Loucopoulos, Ed. Springer Berlin
Heidelberg, 1992, pp. 348–363.
[104] L. De Marco, F. Ferrucci, and C. Gravino, ―Approximate COSMIC Size to Early
Estimate Web Application Development Effort,‖ in 2013 39th EUROMICRO
Conference on Software Engineering and Advanced Applications (SEAA), 2013, pp.
349–356.
[105] S. Di Martino, F. Ferrucci, C. Gravino, and F. Sarro, ―Web Effort Estimation: Function
Point Analysis vs. COSMIC,‖ Inf. Softw. Technol., vol. 72, pp. 90–109, Apr. 2016.
138
[106] D. Schwabe and G. Rossi, ―Building hypermedia applications as navigational views of
information models,‖ in Proceedings of the Twenty-Eighth Hawaii International
Conference on System Sciences, 1995, 1995, vol. 3, pp. 231–240 vol.3.
[107] E. Mendes and N. Mosley, Eds., Web Engineering. Berlin, Heidelberg: Springer Berlin
Heidelberg, 2006.
[108] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-oriented
Modeling and Design. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1991.
[109] P. P.-S. Chen, ―The Entity-relationship Model—Toward a Unified View of Data,‖
ACM Trans Database Syst, vol. 1, no. 1, pp. 9–36, Mar. 1976.
[110] Object Database Standard ODMG 2 0. San Francisco, Calif: Morgan Kaufmann
Publishers, 1997.
[111] G. Booch, J. Rumbaugh, and I. Jacobson, Unified Modeling Language User Guide, The
(2Nd Edition) (Addison-Wesley Object Technology Series). Addison-Wesley
Professional, 2005.
[112] F. Manola, ―Technologies for a Web object model,‖ IEEE Internet Comput., vol. 3, no.
1, pp. 38–47, Jan. 1999.
[113] J. Li, P. Chen, and P. Chen, ―Modeling Web application architecture with UML,‖ in
36th International Conference on Technology of Object-Oriented Languages and
Systems, 2000. TOOLS - Asia 2000. Proceedings, 2000, pp. 265–274.
[114] J. Gómez, C. Cachero, and O. Pastor, ―Extending a Conceptual Modelling Approach to
Web Application Design,‖ in Proceedings of the 12th International Conference on
Advanced Information Systems Engineering, London, UK, UK, 2000, pp. 79–93.
[115] F. Garzotto, P. Paolini, and D. Schwabe, ―HDM—a Model-based Approach to
Hypertext Application Design,‖ ACM Trans Inf Syst, vol. 11, no. 1, pp. 1–26, Jan.
1993.
[116] M. Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language,
Second Edition. Addison-Wesley Professional, 2000.
[117] H. Baumeister, N. Koch, and L. Mandel, ―Towards a UML Extension for Hypermedia
Design,‖ in «UML»’99 — The Unified Modeling Language, R. France and B. Rumpe,
Eds. Springer Berlin Heidelberg, 1999, pp. 614–629.
[118] G. Rossi, O. Pastor, D. Schwabe, and L. Olsina, Eds., Web Engineering: Modelling and
Implementing Web Applications, 1st Edition. Springer, 2008.
[119] T. Isakowitz, E. A. Stohr, and P. Balasubramanian, ―RMM: A Methodology for
Structured Hypermedia Design,‖ Commun ACM, vol. 38, no. 8, pp. 34–44, Aug. 1995.
[120] O. M. F. De Troyer and C. J. Leune, ―WSDM: A User Centered Design Method for
Web Sites,‖ in Proceedings of the Seventh International Conference on World Wide
Web 7, Amsterdam, The Netherlands, The Netherlands, 1998, pp. 85–94.
[121] I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process.
Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999.
[122] N. Koch and A. Kraus, ―Towards a Common Metamodel for the Development of Web
Applications,‖ in Proceedings of the 2003 International Conference on Web
Engineering, Berlin, Heidelberg, 2003, pp. 497–506.
[123] ―Object Management Group. Unified Modeling Language Specification, Version 2.5.
Specification,‖ Jun-2015.
[124] A. Knapp, N. Koch, G. Zhang, and H.-M. Hassler, ―Modeling Business Processes in
Web Applications with ArgoUWE,‖ in < <UML> > 2004 - The Unified Modeling
Language. Modelling Languages and Applications, T. Baar, A. Strohmeier, A. Moreira,
and S. J. Mellor, Eds. Springer Berlin Heidelberg, 2004, pp. 69–83.
[125] ―ArgoUWE,‖ UWE – UML-based Web Engineering. [Online]. Available:
http://uwe.pst.ifi.lmu.de/toolargoUWE.html. [Accessed: 13-Dec-2012].
139
[126] ―MagicDraw,‖ No Magic. [Online]. Available:
http://www.nomagic.com/products/magicdraw.html. [Accessed: 13-Dec-2012].
[127] N. Koch and A. Kraus, ―The Expressive Power of UML-based Web Engineering,‖
presented at the Proceedings of the 2nd International Workshop on Web-Oriented
Software Technology (IWWOST 2002), 2002, pp. 105–119.
[128] N. Koch and S. Kozuruba, ―Requirements Models as First Class Entities in Model-
Driven Web Engineering,‖ in Current Trends in Web Engineering, M. Grossniklaus
and M. Wimmer, Eds. Springer Berlin Heidelberg, 2012, pp. 158–169.
[129] ―Advantages of the COSMIC method,‖ COSMIC, 12-Aug-2014. [Online]. Available:
http://www.cosmicon.com/advantagesV3.asp.
[130] ―The COSMIC Functional Size Measurement Method Version 4.0, Introduction to the
COSMIC method of measuring software,‖ May-2014. [Online]. Available:
www.cosmicon.com/dl_goto.asp?id=471. [Accessed: 08-Dec-2014].
[131] E. Mendes, N. Mosley, and S. Counsell, ―Comparison of Web size measures for
predicting Web design and authoring effort,‖ IEE Proc. - Softw., vol. 149, no. 3, pp.
86–92, Jun. 2002.
[132] J.-P. Jacquet and A. Abran, ―From software metrics to software measurement methods:
a process model,‖ in Software Engineering Standards Symposium and Forum, 1997.
Emerging International Standards. ISESS 97., Third IEEE International, 1997, pp.
128–135.
[133] B. Marín Campusano, ―Functional Size Measurement and Model Verification for
Software Model-Driven Developments: A COSMIC-based Approach,‖ PHD
dissertation, Universitat Politèctnica de València, Valencia, Spain, 2011.
[134] B. Selic, ―A Systematic Approach to Domain-Specific Language Design Using UML,‖
in 10th IEEE International Symposium on Object and Component-Oriented Real-Time
Distributed Computing, 2007. ISORC ’07, 2007, pp. 2–9.
[135] N. Condori-Fernández, S. Abrahão, and O. Pastor, ―On the estimation of the functional
size of software from requirements specifications,‖ J Comput Sci Technol, vol. 22, no.
3, pp. 358–370, May 2007.
[136] M. Campusano and B. Mariela, ―Functional Size Measurement and Model Verification
for Software Model-Driven Developments: A COSMIC-based Approach,‖ Riunet, Jul.
2011.
[137] X. Gu, G. Song, and Q. Li, ―An Improved FSM Method for Web-based Applications,‖
in International Conference on Computational Intelligence for Modelling, Control and
Automation, 2006 and International Conference on Intelligent Agents, Web
Technologies and Internet Commerce, 2006, p. 21.
[138] E. Mendes, ―Introduction to Web Resource Estimation,‖ in Practitioner’s Knowledge
Representation, Springer Berlin Heidelberg, 2014, pp. 55–60.
[139] Zhizhong Jiang and Peter Naudé, ―An Examination of the Factors Influencing Software
Development Effort,‖ Int. J. Comput. Inf. Syst. Control Eng., vol. 1, no. 4, pp. 909–919,
May 2007.
[140] S. Weisberg, Applied Linear Regression. John Wiley & Sons, 2005.
[141] S. D. Martino, F. Ferrucci, C. Gravino, and F. Sarro, ―Using Web Objects for
Development Effort Estimation of Web Applications: A Replicated Study,‖ in Product-
Focused Software Process Improvement, D. Caivano, M. Oivo, M. T. Baldassarre, and
G. Visaggio, Eds. Springer Berlin Heidelberg, 2011, pp. 186–201.
[142] E. Mendes, Cost Estimation Techniques for Web Projects. IGI Global, 2007.
[143] F. Ferrucci, C. Gravino, R. Oliveto, F. Sarro, and E. Mendes, ―Investigating Tabu
Search for Web Effort Estimation,‖ in 2010 36th EUROMICRO Conference on
Software Engineering and Advanced Applications (SEAA), 2010, pp. 350–357.
140
[144] S. D. Conte, H. E. Dunsmore, and V. Y. Shen, Software Engineering Metrics and
Models. Redwood City, CA, USA: Benjamin-Cummings Publishing Co., Inc., 1986.
[145] D. Čeke and B. Milašinović, ―Automated web application functional size estimation
based on a conceptual model,‖ presented at the 23rd International Conference on
Software, Telecommunications and Computer Networks, SoftCOM 2015, Bol, Croatia,
2015.
141
POPIS KRATICA
AFC - Adjusted Function Point Count
APD - Abstract Presentation Diagram
BFC - Basic Functional Component
CART - Classification and Regression Trees
CASE - Computer-aided software engineering
CBR - Case-based reasoning
CFP - COSMIC Function Point
COBRA - Cost Estimation, Benchmarking, and Risk Assessment
COCOMO - Constructive Cost Model
COSMIC - Common Software Measurement International Consortium
CWADEE - Chilean Web Application Development Effort Estimation
DET - Data element type
DFT - Data Function Types
DHTML - Dynamic HTML
EMOF - Essential Meta-Object Facility
FFP - Full Function Points
FL - Fuzzy Logic
FP - Function Points
FPA - Function Point Analysis
FS - Functional Size
FTR - File Types Referenced
FUR - Functional User Requirements
GA - Genetski algoritmi
HDM - Hypertext Design Model
HTML - Hyper Text Markup Language
IFPUG - International Function Point Users Group
ISBSG - International Software Benchmarking Standards Group
LOC - Lines of Code
MDD - Model-Driven Development
MdMRE - Median Magnitude of Relative Error
MMRE - Mean Magnitude of Relative Error
MMWA - Metric Model for Web Application
142
MOF - Meta-Object Facility
MRE - Magnitude of Relative Error
MVC - Model-View-Control
NAD - Navigation Access Diagram
NESMA - Netherlands Software Metrics Association
NN - Neural network
ODMG - Object Data Managemet Group
OLS - Ordinary Least Square
OO-H - Object-Oriented Hypermedia
OOHDM - Object-Oriented Hypermedia Design Method
OO-HFP - Object-Oriented Hypermedia Function Points
OOmFPWeb - OO-Method Function Points for the Web
OOWS - Object-Oriented Web Solutions
PHP - Hypertext Preprocessor
PIM - Independed Models
Pred(n) - Prediction at level n
PSM - Platform Specific Models
RET - Record element type
ROI - Return On Investment
SVR - Support vector regression
SWR - Stepwise regression
TCF - Technical Complexity Factor
TFT - Transactional function types
UFC - Unadjusted Function Count
UML - Unified Modeling Language
UWE - UML-based Web Engineering
WADEES - Web Application Effort Estimation System
WebML - Web Modeling Language
WebML - Web Modeling Language
XMI - XML Metadata Interchange
143
PRILOG
Dodatak koji se nalazi na pratećem CD-u ima sljedeći sadrţaj:
Softver za kreiranje UWE konceptualnog modela (MagicDraw s dodatkom
MagicUWE).
UWE modeli svih web aplikacija korištenih u disertaciji.
Web aplikacija za procjenu uloţenog napora, sustav WADEES, s pratećom bazom
podataka.
Podaci o vrijednostima CFP-a korištenih web aplikacija u disertaciji.
144
ŢIVOTOPIS
Denis Čeke roĎen je 06. listopada 1978. godine u Tuzli, Bosna i Hercegovina. Godine
1997 upisao je studij na Fakultetu elektrotehnike, Univerziteta u Tuzli, odsjek Tehnička
informatika. Diplomirao je odličnim uspjehom 29. listopada 2003. godine. Za postignute
uspjehe tijekom studija nagraĎen je Srebrenom plaketom Univerziteta u Tuzli.
Poslijediplomski studij na Fakultetu elektrotehnike u Tuzli, odsjek Tehnička informatika
upisao je 2003. godine i magistrirao 23. oţujka 2007. godine
Od listopada 2003. do listopada 2009. godine bio je zaposlen kao stručni suradnika za
multimedijalnu produkciju u Univerzitetskom centru za razvoj daljinskog obrazovanja
Univerziteta u Tuzli. Poslije toga, do danas je zaposlenik Centra za osiguranje kvaliteta i
internu evaluaciju kao sistem inţenjer za kvalitetu gdje radi na poslovima razvoja i odrţavanja
informacionog sustava Univerziteta u Tuzli.
Područje njegovoga istraţivanja uglavnom uključuje softverski inţenjering, razvoj
zasnovan na modelu i inţenjering na osnovu korisničkih zahtjeva u području razvoja web
aplikacija. Kao autor i koautor objavio je 1 znanstveni rad u CC časopisu, 3 rada u drugim
časopisima, 4 rada u zbornicima skupova s meĎunarodnom recenzijom te jedno poglavlje u
knjizi.
145
BIOGRAPHY
Denis Čeke was born on October 6th, 1978, in Tuzla, Bosnia and Herzegovina. In 1997 he
enrolled at the Faculty of Electrical Engineering, University of Tuzla, department for
technical informatics. He graduated on October 29th, 2003. For the results achieved during
the study he was awarded with Silver plaque of the University of Tuzla. In 2003 he enrolled
in the Postgraduate Study at the Faculty of Electrical Engineering, University of Tuzla and
defended his Master Thesis on March 23th, 2007.
Since October 2009 he is a system engineer in charged for quality assurance, development
and maintain of the University information system at the Center for quality assurance and self
evaluation at the University of Tuzla.
His research mainly includes software engineering, model-driven development and
requirements engineering in web application development.
As an author and co-author he published 1 paper in Current Contents journal, 3 papers in
other journals, 4 papers in conference proceedings with international peer review, and a
chapter in the book.
146
POPIS OBJAVLJENIH RADOVA
Poglavlja u knjizi
1. Denis Čeke, Matjaz Debevc, Denis Helic, Nermin Hodzic, Djordje Kadijevic, Filip Maric,
Samra Mujacic, Walther Neuper, Dusan Pagon.
Roadmap to Advance Web-based E-Learning in South Eastern Europe // Roadmap to
Advance Web-based E-Learning in South Eastern Europe / Denis Helic (ur.).
Graz, Austria : Verlag der Technischen Universität Graz, 2008. Str. 6-48.
Izvorni znanstveni i pregledni radovi u CC časopisima
1. Čeke, Denis; Milašinović, Boris.
Early effort estimation in web application development. // Journal of systems and software.
103 (2015) ; 219-237 (članak, znanstveni).
Znanstveni radovi u drugim časopisima
1. Kunosić, Suad; Čeke, Denis; Beganović, Adnan; Bašić, Begzada.
Effects of dispersed radiation on the thyroid and the gonads during mammography. //
HealthMED. 5 (2011) , 6; 1774-1781 (članak, znanstveni).
2. Kunosić, Suad; Čeke, Denis; Koprić, Mustafa; Lincender, Lidija.
Determination of mean glandular dose from routine mammography for two age groups of
patients. // HealthHMED. 4 (2010) , 1; 125-131 (članak, znanstveni).
3. Čeke, Denis; Kunosić, Suad; Koprić, Mustafa; Lincender, Lidija.
Using Neural Network Algorithms in Prediction of Mean Glandular Dose Based on the
Measurable Parameters in Mammography. // Acta Informatica Medica. 17 (2009) , 4; 194-197
(članak, znanstveni).
Znanstveni radovi u zbornicima skupova s meĎunarodnom recenzijom
1. Čeke, Denis; Milašinović, Boris.
Automated web application functional size estimation based on a conceptual model //
SoftCOM 2015, The 23rd International Conference on Software, Telecommunications and
Computer Networks / Roţić, Nikola ; Begušić, Dinko ; Šarić, Matko ; Šolić, Petar (ur.).
147
Split, Croatia, 2015. 234-241 (predavanje, meĎunarodna recenzija, objavljeni rad,
znanstveni).
2. Čeke, Denis; Đurek, Marijan; Kasapović, Suad.
Web application functional size estimation based on COSMIC method and UWE approach //
MIPRO 2013 Conference Proceedings.
Opatija, 2013. 396-403 (predavanje, meĎunarodna recenzija, objavljeni rad, znanstveni).
3. Suad Kasapović, Samra Mujačić, Denis Čeke, Amir Hadţimehmedović.
Comparison ways of assignment of codes in UMTS networks // MIPRO, 2012 Proceedings of
the 35th International Convention.
2012. 552-556 (predavanje, meĎunarodna recenzija, objavljeni rad, znanstveni).
4. Denis Čeke, Marijan Đurek, Nermin Sarajlić.
A practical introduction to computer-adaptive tests // XXI International Symposium on
Information, Communication and Automation Technologies.
Sarajevo, 2007. 334-337 (predavanje, meĎunarodna recenzija, objavljeni rad, znanstveni).
Magistarski rad:
1. Čeke, Denis.
Primjenjivost računarsko-adaptibilnih testova / magistarski rad.
Tuzla: Fakultet elektrotehnike, 23.03.2007, 87 stranica str. Voditelj: Đurek, Marijan.