www.ietdl.org Published in IET Software Received on 30th November 2009 Revised on 18th May 2010 doi: 10.1049/iet-sen.2010.0027
ISSN 1751-8806
Software cost estimation for componentbased fourth-generation-language software applications Z. Zia1 A. Rashid1 K. uz Zaman2 1
ICIT, Gomal University, D.I.Khan, Pakistan Department of Economics, Gomal University, D.I.Khan, Pakistan E-mail:
[email protected] 2
Abstract: Software cost estimation is important for budgeting, risk analysis, project planning and software improvement analysis. There are numerous estimation techniques. During the past three decades there had been some significant developments in effort estimation, size of software and cost estimation methodology. Current software cost estimation models have been experiencing increasing difficulties in estimating the costs of software, as new software development methodologies and technologies are emerging very rapidly. Most of the software cost models generally rely on such inputs as estimates of lines of source code, delivered sets of instructions, function points and processing complexity or experience levels to produce cost estimates. These models generally produce inaccurate results when used to estimate the cost of software development in current development environments such as those that use component-based software development environments like visual languages. The authors present in this study a new technique for software cost estimation that can be used for software projects developed using component-based fourth-generationlanguage environment. The model was calibrated using the empirical data collected from 19 software systems. Efficiency of the model was also compared with an existing model used for such environment. The proposed model achieved better predictive accuracy.
1
Introduction
Software cost estimating has been an important but difficult task since the beginning of the computer era in the 1940s. As software applications have grown in size and importance, the need for accuracy in software cost estimating has grown, too. In early days of computing, programs were relatively much simpler and the entire software development cost were often less than $5000. Today, software exceeds 25 million source code statements. Software development organisations require technical staff of more than 1000 personnel. Development cost of such software may be in millions. Therefore errors in software cost estimation can be very serious indeed [1]. Software is now the driving force of modern business, government and military operations. Different organisations IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
may produce hundreds of new applications and modify hundreds of existing applications every year. As a result of the host of software projects in the modern world, software cost estimating is now a mainstream activity for every company that builds software. Today, software development is widely seen to be inefficient. One cause of inefficiency is the inadequacy of economic information available to support decision making. In the absence of reasonable cost estimates, projects are at risk. Improving our basic understanding of software economics and the abilities of organisations to model and analyse economic aspects can help to make them significantly more productive [2]. Since the early 1950s, software development practitioners and researchers have been trying to develop methods to 103
& The Institution of Engineering and Technology 2011
www.ietdl.org estimate software costs and schedules [3]. Software cost estimation models have appeared in the literature over the past three decades [4]. However, the field of software cost estimation is still in its infancy [5]. In recent years, software has become the most expensive component of computer system projects. The bulk of the cost of software development is due to the human effort, and most cost estimation methods focus on this aspect and give estimates in terms of person months (PMs). Accurate software cost estimates are critical to both developers and customers [1]. Accurate cost estimation is important because of the following reasons [6]: † It can help to classify and prioritise development projects with respect to an overall business plan. † It can be used to determine what resources to commit to the project and how well these resources will be used. † It can be used to assess the impact of changes and support re-planning. † Projects can be easier to manage and control when resources are better matched to real needs. † Customers expect actual development costs to be in line with estimated costs. Practitioners have struggled with three fundamental issues [6]: 1. Which software cost estimation model to use? 2. Which software size measurement to use – lines of code (LOC), function points (FP) or feature point?
developed for data-centre applications using database. Smith [9] developed a model to identify parameters for effort estimation in component-based software systems. COCOMO is a well-studied and accepted effort estimation model. By augmenting the COCOMO model with the proposed metrics, a new model has been built upon the experience inherent in the COCOMO technique. This model can be used for all types of software applications developed in any component-based 4GL environment.
2 Overview of the existing models The most interesting difference between estimation models is between models that use source lines of code (SLOC) as the primary input against models that do not [10].
2.1 SLOC-based models SLOC is the oldest metric for calculating project effort. SLOC is the primary input for these types of cost estimation models. SLIM and COCOMO models are based on SLOC. Although numerous deficiencies of these models have been reported but many organisations still use SLOC-based models. The main reason for the popularity of these models is because no other measure is well understood or as easy to collect as LOC. Major drawback in SLOC-based model is that estimating the SLOC early in the software development lifecycle can be difficult. A SLOC estimate of a software system can be obtained from experience, the size of previous systems, the size of a competitor’s system and breaking down the system into smaller pieces and estimating the SLOC of each piece. For each piece, three distinct estimates are made: 1. Smallest possible SLOC – a 2. Most likely SLOC – m
3. What is a good estimate? 3. Largest possible SLOC – b As new tools and technologies are emerging for the development of software, these issues have become even more important. The diversity of software development tools observed today has resulted in a situation where existing effort prediction models’ applicability appears to be limited. Component-based fourth-generation-language (4GL) software development provides one such difficulty. These languages are based on reusable components which are neither suitable to be calculated by FP analysis technique nor classical effort estimation methods can be applied that are specifically developed for procedural languages. The limitations of traditional models are problematic for effort estimation in component-based 4GL environment.
Then the expected SLOC for piece E can be estimated by adding the smallest estimate, largest estimate and four times the most likely estimate and dividing the sum by 6. This calculation is represented by the following formula E=
a + 4m + b 6
The expected SLOC for the entire software system E is simply the sum of the expected SLOC of each piece E=
n
Ei
i=0
There exist some software effort estimation models for 4GL environment like van Koten [7, 8], but these are 104 & The Institution of Engineering and Technology 2011
where n is the total number of pieces. IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
www.ietdl.org Generally to obtain a cost estimate for a software system, three variables are required in addition to the SLOC estimate: alpha, a, the marginal cost per thousand LOC (KLOC); beta, b, an exponent of the KLOC and gamma, g, the additional fixed cost of the project. The cost estimate calculation is represented by the following formula Cost estimate = a × KLOCb + g
2.2 FP models Fortunately for those who do not believe SLOC is an appropriate input for cost estimation, there is an alternative approach that is relatively new. In 1979, IBM’s Allan Albrecht published the FP model which involves ‘a measure of the amount of function provided by the software system’ [11]. This model offers several advantages over traditional SLOC-based models. The FP metric was originally developed as an alternative to SLOC to measure productivity in the later stages of software development. However, Albrecht argued that the FP model could also be a powerful tool to estimate software cost in the early stages of the software development lifecycle. For an FP metric Albrecht provides fives categories of functions to count: external inputs, external outputs, external inquiries, external interfaces and internal files. When a function is identified for a given category, the function’s complexity must also be rated as low, average or high as shown in Table 1. Each function count is multiplied by the weight associated with its complexity and all of the function counts are summed to obtain the count for the entire system, known as the unadjusted function points (UFP) [11]. This calculation is summarised by the following equation 3 5
Wij Xij
i=1 j=1
where Wij is the weight for row i, column j, and Xij is the function count in cell i, j [10]. Table 1 Function count weighting factors Low
Average
High
external input
__ × 3
__ × 4
__ × 6
external output
__ × 4
__ × 5
__ × 7
internal file
__ × 7 __ × 10 __ × 15
external interface __ × 5
__ × 7
__ × 10
__ × 3
__ × 4
__ × 6
external inquiry
IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
AFP = UFP × VAF where VAF is value adjustment factor calculated as VAF = 0.65 + 0.01 ×
This is a very basic method for estimating software cost using SLOC.
UFP =
UFP are then used to calculate adjusted function point (AFP). It is calculated as
14
ci
i=1
where ci is list of 14 general system characteristics. The final AFP number of the proposed system is compared against the AFP count and cost of systems that have been measured in the past. The more historical data that can be compared the better the chances of accurately estimating the cost of the proposed software system.
3 Component-based 4GL applications Although it may be somewhat controversial, but modern software development environments are better understood as aggregates of forms, reports, tables and screens, rather than LOC. Fourth-generation languages are componentbased languages which provide a rich set of components. Complexity of usage of these components may vary. But there are languages like Visual Basic, VB.Net and Visual C#, where user can develop an application without writing single line of code. When there is no line of code, SLOCbased models cannot be used for cost estimation of these applications. FP metrics can be used but the function categories defined for FP metrics do not exactly apply on 4GL applications. Smith [9] identified some parameter for effort estimation in component-based software system. It is not a well-established model. van Koten and Grey [8] presented an effort prediction model for data centred 4GL. According to this model 1. The minimal set of specifications completed for a software system is the entity relationship diagram (ERD) and functional hierarchy diagram (FHD). The FHD defines functional specifications of the system’s user-interface components. 2. The system’s database is automatically generated from the ERD. This implies that differences in the complexity of ERDs, such as the differences of the number of different types of relationships, would have, in general, only a negligible effect on development effort because implementation of the data model does not require any manual coding. 3. A system consists of some or all of three types of userinterface components – forms, reports and graphs. Once the related table(s) in the database is defined, the tool 105
& The Institution of Engineering and Technology 2011
www.ietdl.org automatically generates code that ensures the connectivity between them. This implies that developers’ effort would be primarily spent performing the two tasks: creating each component by using various readymade graphical userinterface items such as text boxes and combo boxes and adding code to the items [8]. This model was developed to predict the software effort only for that software where data is accessed from database to forms, reports and graphs. For non-database application, this model is not suitable. Fourth-generation languages are not used only to develop data-centred applications. These systems can be used to develop every type of software, including database applications, scientific applications, generic software, computer games, mobile applications – the list is endless. van Koten [7] also developed Bayesian statistical software effort prediction models for database-oriented software systems, which are developed using a specific 4GL tool suite. It is actually an extension of the previous model using statistical approach. Riquelme et al. [12] compared different effort estimation methods and presented a model for 4GL applications that analyses the relationship between a set of metrics for 4GL programs and the maintenance time for such programs which uses SQL statements. This model is based on the following parameters: NS ¼ total number of Select instructions in the considered program. NI ¼ total number of Insert instructions in the considered program. ND ¼ total number of Delete instructions in the considered program. NU ¼ total number of Update instructions in the considered program. NT ¼ total number of used Tables in the considered program.
develop a software application project p; a is the y intercept; b1 is the number of person days for one form F; b2 is the number of person days for one report R; b3 is the number of person days for one table T; b4 is the number of person days for one module M. Unfortunately, these calculations seem very illusive because complexity of development of each and every component has been taken as equal. In practice, the LOE required to develop one form will not be equal to another one as the complexity of development will vary. Same is true for reports, tables and modules.
4
Proposed method
As it has been discussed earlier that none of the existing models can be used properly for software cost estimation of 4GL applications, we suggest a new method for the size estimation of 4GL applications. The calculated size will be used to determine nominal person per month in COCOMO II model. In order to adjust the nominal effort, same effort multipliers will be used as described in COCOMO II model definition. According to COCOMO II, the nominal effort for a given size project and expressed as PM is given by PMnominal = A × (Size)B ‘The inputs are the Size of software development, a constant A and a scale factor B. The size is in units of thousands of source lines of code (KSLOC). This is derived from estimating the size of software modules that will constitute the application program. It can also be estimated from UFPs, converted to SLOC then divided by one thousand’ [13]. We will use the same equation. All the scale factors and pertinent COCOMO II model drivers will still be applicable. Modern software development environments are aggregates of forms, reports, tables and modules, where
NN ¼ total number of Nestings in the considered program. Where ¼ total number of Where clauses in the considered program. This model is also suitable only for database applications. Morgan Peeples developed a model [13], where he calculates level of effort of a project as LOEp = a + b1 × forms + b2 × reports + b3 × tables + b4 × modules where LOEp is the number of person days of effort it takes to 106 & The Institution of Engineering and Technology 2011
1. Forms are objects created by a developer for interaction or navigation by the user. The 4GL tool provides templates for the developer to use. The form templates can be used as menus that move the user through the application, or for use as data entry, querying screens or other forms required for the application. A form is actually a collection of different components. 2. Reports are objects that a developer uses to retrieve data from tables, to format and present that data to the user. The 4GL tool provides an easy way to use interface and readymade products for the developer to tailor and create specialised reports. Some reports may be simple but some may be more complicated as they need extensive coding as IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
www.ietdl.org well as higher level complicated database queries and stored procedures. 3. Tables are objects created to store data. The 4GL tool provides features for the developer to define and generate data definition language and create tables automatically from design models. The level of complexity also varies as some table may require only a few fields, whereas other will require hundreds of fields with integrity constraints.
where SizeF is the sum of sizes of all forms. It will be calculated as SizeF =
n
SFi
i=1
where SF is the size of form. The size of form will be calculated as sum of size of its components. It will be calculated as
4. Modules represent that portion of a software development application that cannot otherwise be delivered, except to be created. These might be computational algorithms, transaction handling, processes and code written for different events.
SF =
n
(SFCi )
i=1
where SFC is the size of component used in the form. For 4GL application, the Size of the software will be calculated as Size = SizeC + Sizem where SizeC is size of components (forms, reports and tables) converted into KLOC. SizeC will be calculated as SizeC = SizeF + SizeR + SizeT
In order to determine the nominal PMs, these components have to be converted to SLOC. In COCOMO II model definition [13], a table for converting FPs, written in different languages, to SLOC has been provided. But unfortunately there is no such conversion available anywhere to convert 4GL components to equivalent LOC. The recommended method for converting these components to their equivalent LOC will
Table 2 Effort calculation of the selected projects P#
Tool
SizeF (KLOC)
SizeT (KLOC)
SizeR (KLOC)
Sizem (KLOC)
Size (KLOC)
Predicted effort (PM)
1
Visual Basic
2.709728
1.146423
0.781652
0.573
5.211
18.11
2
Visual Basic
2.905829
1.310472
0.854655
0.627
5.698
19.89
3
Visual Basic
2.447205
1.248574
0.749144
0.549
4.994
17.32
4
Visual Basic
4.213685
1.782713
1.215486
0.891
8.103
28.79
5
Visual Basic
2.366648
0.96419
0.569749
0.482
4.383
15.1
6
Visual Basic
3.025194
1.27989
0.872652
0.640
5.818
20.33
7
Visual Basic
2.653443
1.167515
0.796033
0.690
5.307
18.46
8
Visual Basic
2.880465
1.218658
0.830903
0.609
5.539
19.31
9
VB.Net
3.780425
1.599411
1.090507
0.800
7.270
25.69
10
VB.Net
3.165335
1.460924
0.791334
0.670
6.087
21.32
11
VB.Net
3.015101
1.474049
1.474049
0.737
6.700
23.58
12
VB.Net
3.779023
1.598818
1.090103
0.800
7.267
25.68
13
VB.Net
3.152264
1.386996
0.945679
0.820
6.305
22.12
14
VB.Net
4.180985
1.735503
1.104411
0.868
7.889
27.99
15
VB.Net
3.805647
1.610082
1.097783
0.805
7.319
25.87
16
Visual C#
4.558684
1.928674
1.315005
0.964
8.767
31.27
17
Visual C#
5.123552
2.348294
2.028072
1.174
10.675
38.45
18
Visual C#
3.773694
1.660425
1.283056
0.830
7.548
26.72
19
Visual C#
3.465821
1.466309
0.999756
0.733
6.666
23.45
IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
107
& The Institution of Engineering and Technology 2011
www.ietdl.org be expertise based. As there are thousands of components available in different 4GL languages, hence it will be almost impossible to summarize them. Only VB.Net provides more than 3000 components. The developer can easily estimate effort of these components. Some components are very simple, like buttons, which can be easily converted, but some components are more complicated, like data sets, which require an effort equivalent to 150 –300 LOC. Therefore it is suggested that the developer should maintain a conversion table for these components, developed on the basis of their own experience. SizeR is the sum of size of all reports, used in the project. It will be calculated as
SizeR =
n
5 Empirical validation of the proposed method GomalSoft is a private software house, located in D.I.Khan. It is providing effective computing solutions within public and private sector. Major development tools used in this software house are Visual Basic, VB.Net and Visual C#. This software house was facing problems in software cost estimation. FP metrics were used to estimate the cost but the result were always unsatisfactory. We applied the proposed method on 19 projects. All of these projects were
Table 3 Empirical validation results P#
Tool
Actual effort (PM)
Predicted effort (PM)
MRE, %
1
Visual Basic
16.34
18.11
10.83
2
Visual Basic
18.21
19.89
9.23
(SR i )
i=1
where SR is the size of report. As the nature of every report is not the same, therefore the size of each report also depends on its complexity. Some reports may be very simple and can be prepared using report generator wizards, like Crystal Report. But there will be many reports that will require complicated cross-tab queries, stored procedure, selection formulae, run-time parameters and even some coding. Same is the suggestion for report conversion to LOC as for components. It is still difficult to predict the size of each report but the developer can easily develop a table for report conversion.
3
Visual Basic
15.34
17.32
12.91
4
Visual Basic
31.4
28.79
8.31
5
Visual Basic
13.27
15.10
13.79
6
Visual Basic
18.92
20.33
7.45
SizeT is the sum of size of all tables in database, used with the project. It can be calculated as
7
Visual Basic
16.57
18.46
11.06
8
Visual Basic
17.45
19.31
10.66
9
VB.Net
23.52
25.69
9.23
10
VB.Net
24.48
21.32
12.91
11
VB.Net
20.71
23.58
13.86
12
VB.Net
23.53
25.68
9.14
13
VB.Net
19.82
22.12
11.60
14
VB.Net
25.68
27.99
8.99
15
VB.Net
23.64
25.87
9.43
16 Visual C#
28.34
31.27
10.34
17 Visual C#
32.79
38.45
17.26
18 Visual C#
22.66
26.72
17.91
19 Visual C#
20.34
23.45
15.29
SizeT =
n
(STi )
i=1
where ST is the size of table. The table size can be easily converted to LOC. The size of table is directly related to number of fields in the table. Different GUI-based database environments provide database designers like SQL Server. According to our own experience, one simple field designing counts for three LOC, whereas one integrity constraint implementation counts for two LOC. Depending on the complexity of tables, the tables will be converted to LOC. And finally, Sizem will be calculated as Sizem = Size of Modules in KSLOC Sizem is the total number of statements, written for different computational algorithms, transaction handling, processes and events. 108
& The Institution of Engineering and Technology 2011
MMRE MMRE MMRE MMRE
of all 19 projects ¼ 11.61% for Visual Basic projects ¼ 10.57% for VB.Net projects ¼ 10.74% for Visual C# projects ¼ 15.29% IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
www.ietdl.org Table 4 Results of van Koten’s model P#
Tool
Actual effort (PM)
Predicted effort (PM)
MRE, %
1
Visual Basic
16.34
19.34
18.36
2
Visual Basic
18.21
20.23
11.09
3
Visual Basic
15.34
18.45
20.27
4
Visual Basic
31.4
32.4
5
Visual Basic
13.27
18.32
38.06
6
Visual Basic
18.92
22.31
17.92
7
Visual Basic
16.57
19.21
15.93
8
Visual Basic
17.45
18.4
5.44
9
VB.Net
23.52
27.34
16.24
10
VB.Net
24.48
24.89
1.67
11
VB.Net
20.71
27.4
32.30
12
VB.Net
23.53
24.58
4.46
13
VB.Net
19.82
20.45
3.17
14
VB.Net
25.68
27.06
5.37
15
VB.Net
23.64
26.39
11.63
16 Visual C#
28.34
37.56
32.53
17 Visual C#
32.79
45.82
39.74
18 Visual C#
22.66
28.45
25.55
19 Visual C#
20.34
27.56
35.50
MMRE MMRE MMRE MMRE
3.185
of all 19 projects ¼ 17.81% for Visual Basic projects ¼ 16.28% for VB.Net projects ¼ 10.70% for Visual C# projects ¼ 33.33%
database projects, where SQL Server was used as backend and Crystal Report as report development tool. However, different tools were used as frontend. Nominal effort for the selected projects was calculated by calculating the equivalent size of forms, reports, tables and modules. To determine the nominal PMs, all forms, tables and reports were converted to SLOC. In order to translate them into equivalent SLOC, different equivalence tables are constructed for different categories of components. The SLOC value assigned to different categories of component was set on the basis of experience of the developers. As it IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
has been discussed earlier that these conversion tables can be maintained by developers themselves, therefore these tables are not going to be included here. These calculations are presented in Table 2. Table 3 presents empirical validation results. Fortunately all of the projects are database-oriented projects. We applied van Koten [7] model to these projects. There were considerable difficulties in applying this model as these applications also had many non-database controls. However, their relative costs were calculated in best possible manner. The results of van Koten’s model are presented in Table 4. We also applied FP metrics on these projects but mean magnitude of relative error (MMRE) was very high (26%). Best MRE in FP metrics was 19%, whereas worst was 34%. Although the personnel, who did the estimation work were competent enough in applying FP metrics, the major problem was the nature of 4GL application as it is not suitable for FP metrics.
6 Conclusion and recommendations We applied this approach for cost estimation of 19 projects, developed in Visual Basic 6.0 (8), VB.Net 2005 (7) and C# (4). The approach tested on these 19 cases proved robust and stable through cross-validation and verification trials on software development applications. It gave a significant level of accuracy. The level of accuracy was measured in terms of MRE and MMRE. Best MRE among these 19 cases was 7.45% for Visual Basic 6.0 projects, whereas worst was 17.91% for C# projects. We also compared it with van Koten’s model [8] which resulted in very high MMRE. Although MMRE for VB.Net projects was slightly better than our approach, it was far worse for C# and Visual Basic projects. All of these 19 projects were intermediate-level projects. Further research with larger projects is still required. It is also required to identify more components as only four structural components, that is, forms, reports, tables and modules, have been identified that contribute to modern software development using 4GL software tools and their associated structural components. Calibration is likely to be essential in order to improve the level of accuracy. Finally, this research will be a new direction for estimating cost of software application using component-based 4GL.
7
References
[1] JONES C.: ‘Estimating software cost’ (McGraw-Hill, New York, 1979) [2] BOEHM B., SULLIVAN K.: ‘Software economics: status and prospects’, Inf. Softw. Technol., 1999, 41, pp. 937– 946 109
& The Institution of Engineering and Technology 2011
www.ietdl.org [3] ABDEL-HAMID T., MADNICK S.: ‘Software project dynamics’ (Prentice-Hall, 1991)
of Information Science, University of Otago, Dunedin, New Zealand
[4] ABEDALLAH Z., SELAMAT M.H., GHANI A.B.A., ATAN R., TIENG W.K.: ‘Issues in software cost estimation’, IJCSNS Int. J. Comput. Sci. Netw. Secur., 2008, 8, (11), pp. 350 – 356
[9] SMITH R.K.: ‘Effort estimation in component-based software development: identifying parameters’. The Twenty-ninth ACM SIGCSE Technical Symp., Atlanta, GA, 25 February 1998
[5] KITCHENHAM B.: ‘Empirical studies of assumptions that underlie software cost estimation models’, Inf. Softw. Technol., 1992, 31, (1), pp. 211 – 218 [6] LEUNG H., ZHANG F. : ‘Software cost estimation’ in ‘Handbook of software engineering and knowledge engineering’ (World Scientific Pub. Co, River Edge, NJ, 2001)
[10] KEMERER C.F.: ‘An empirical validation of software cost estimation models’, Commun. ACM, 1987, 30, (5), pp. 416– 429 [11] ALBRECHT A. : ‘Measuring application development productivity’. Proc. Joint SHARE/GUIDE/IBM Application Development Symp., October 1979, pp. 83– 92
[7] VAN KOTEN C. : ‘An effort prediction model for data-centred fourth-generation-language software development’, Discussion Paper 2003/2004, Department of Information Science, University of Otago, Dunedin, New Zealand
‘A comparison of effort estimation methods for 4GL programs: experiences with statistics and data mining’, IJSEKE, 2006, 16, (1), pp. 127 – 140
[8] VAN KOTEN C., GREY A.: ‘Bayesian statistical effort prediction models for data-centred 4GL software development’. Discussion Paper 2005/2009, Department
[13] MORGAN PEEPLES J.N.: ‘ : ‘A software development cost estimation model for higher level language environments’, 2006, Cyber Kebumen, http://blogger.kebumen.info/docs
110 & The Institution of Engineering and Technology 2011
[12]
RIQUELME J.C., POLO M., AGUILAR-RUIZ J.S., PIATTINI M., FERRER-
TROYANO F.J. , RUIZ F. :
IET Softw., 2011, Vol. 5, Iss. 1, pp. 103– 110 doi: 10.1049/iet-sen.2010.0027
