Computer Modelling
46 Computer Modelling and New Technologies, 2011, Vol.15, No.4, 46–51 Transport and Telecommunication Institute, Lomonosov 1, LV-1019, Riga, Latvia
EARLY ESTIMATION METHOD OF SOFTWARE
DEVELOPMENT
R. I. Muhamedyev, A. I. Kupensheyeva
International IT University, IT department, Almaty, Kazakhstan Manas/Jandosov Str., 34A/8A
E-mails: [email protected]; [email protected]
In order to estimate the effort put into software development various models are used, which are basically based on some form of analysis specification of customer requirements or technical project. In particular, FP metrics that allow to estimate the effort based on the numbers of the function points is widely known [1, 2].
In our opinion, adaptive evaluation system based on formalized specifications of a customer can be used in established system of development (elaboration). This evaluation system can be named as “early”, since it does not include the in-depth analysis methods of the projected system. This system of effort estimation should be based on some important parameters of formalized specifications and additional parameters, which include, for example, qualification of software developer, type of module, etc. For an assessment of basic applicability of formalized specification the analysis based on actual data was performed. The quantity of words and characters were used as the metrics of formalized specification (LFC).
The results of the technique based on the LFC metrics show that error of evaluation results compared with the actual data is relatively small (at least for one module). The maximum error value is 20%, the average is around 9% as compared to the actual data.
Keywords: software engineering, labour effort estimation, formal specification, labour input estimation metrics, estimation
methods
1. Estimation of Labour Input of Software Development
Estimation of labour input of software development is one of the difficult tasks in software engineering. It is solved by different methods [1–5]:
1. Expert estimation; 2. Estimation using models.
1. Expert estimation. The method is designed for project estimation with an emphasis on the expert’s knowledge and experience. The estimation is conducted for the whole project or its separate parts by the experts.
2. Estimation using models. This technique is designed for project estimation with the help of specific models.
“Estimation using models” technique has the following types: 2.1. Estimation by analogy;
2.2. Use Case Points (UCP); 2.3. Function points (FP); 2.4. Fast Function Points (FFP); 2.5. Early Function Points (EFP).
2.1. Estimation by analogy. Project estimation on the basis of historical data. In fact, it is an automated version of expert estimation method. Project estimation based on its “measurement” of forms, reports, subsystems, essence, etc. Conversion of measurement results to labour effort according to accumulated statistics.
2.2. Use Case Points (UCP). The method is designed to evaluate the projects, for which requirements definition is applied with the help of use cases (or precedents). The main point of this technique is to determine “actors” and use cases (precedents) and to estimate (evaluate) its complexity.
2.3. Function Points (FP). The method is designed to evaluate the project on the base of a concept called “function point”. Its essence is as follows:
- Identification of all information objects and all operations on data exchange between the system and “actors” (users, other systems) and estimation of its complexity;
- Correction of the results – account of non-functional requirements;
- Using the result (in FP) in a COCOMO (Constructive Cost Model) calculator (conversion to labour effort with the partition according to project phases and processes) or conversion to code size, and further to labour efforts.
Computer Modelling
47
2.4. Early Function Points (EFP). Variety of a Function Points method allowing application in the absence of detailed requirements. The main point of this technique is:
- Identification of all information objects and all operations on data exchange between the system and “actors”;
- Correction of the results – account of non functional requirements.
2.5. Fast Function Points (FFP). Variety of a Function Points method allowing application in the absence of detailed requirements. The essence is as follows:
- Identification of all information objects and all operations on data exchange between the system and “actors” (users, other systems) without estimation of their complexity (an average value is used).
In the case of the established software development process estimation of labour input can be conducted using the statistics based on the results of the previous tasks. Particularly, in this regard, size-oriented metrics has worked well. The given approach described in [1] is based on LOC (lines of code) estimation by analogy with COCOMO.
2. Software Development Input Estimation on the Basis of Formal Specification
The techniques considered above are not easy to implement, and in some cases, for example, when modifying system modules, their application can be redundant.
Here comes the question: is it possible to move away from the given techniques for input estimation and replace them with the simplified method that allows performing immediate estimation of software development input at an early stage, the stage of task formulation?
We assume that, in some cases, in the well-organized development process, in “conservative” environment, where specific statistics of software development is given and the groups of developers are stable, it is possible to use formal specification of software development (FC – formal specification) for calculation of labour input (WD – work days) in man-days.
FC = > WD.
In other words, it can be assumed that formal specification can be sufficient for relatively accurate labour input calculations of software development.
In this case, the task is to find a function
WD = fwc (FC, P), (1)
where P is a vector of additional parameters, including, for example, a developer’s qualification, a type of the designed module , etc. It is supposed that in some instances it is possible to perform convolution of P vector to the correction factor that depends on the specified parameters. The general model of a customisable (adaptive) system of input estimation is shown in Fig. 1.
Figure 1. The generalized model of adjusted (adaptive) system of an assessment of labour input
According to Figure 1, block 1 is a block for definition of significant parameters of formal specification, block 2 is a block for definition of a vector of additional parameters, block 3 is a module for definition of fwc function, block 4 is used for calculation of predicted input, block 5 performs a comparison of actual indicators of labour input with the calculated ones, Kfc, Kp, Kfwc are corresponding correctors that ensures the system configuration to improve an accuracy of input calculations. The factor
FC 1. Definition of meaningful parameters FC 3. Generation module fwc() 4. Calculation WDp 2 . Definition of additional . parameters P 5. Compare WD Fact with WD Calc Kfwc Kp K FC WD
Computer Modelling
48
analysis, clustering and pattern recognition algorithms, and also algorithms for semantic analysis can be applied in order to construct the correctors.
The experiments with an actual data were conducted in order to verify the possibility of using formal specification for software development input calculations.
At the same time, the number of words and symbols (which, in this case, plays the role of significant parameters) is used as a simple metrics of formal specification. In this instance, the expression (1) can be converted to the following form:
WD = LFC(w,c) * p, (2)
where LFC is a function depending on the number of words (w) and symbols (c) in formal specification, p is a correction factor. In this case, a correction factor is a convolution of P vector.
At first glance, the described approach looks very formal, independent of the semantic content of specification to a software product. However, it can be recalled that the structure of formal specification developed by an expert gives necessary substantial sense to the whole technique.
3. An Example of LFC Metrics and Formal Specifications Application for Estimation of Software Development Labour Input
The applicability analysis of LFC metrics and formal specifications was conducted based on the data accumulated in an organization with an “HB” label. In this organization software development and modification is done as follows (Fig. 2).
Figure 2. The development and modification of software in the organization of “HB”
At first, an application form written by a customer in a free form and related to the specific module of a system comes to an analyst.
Based on this application the analyst writes formal specification and passes it to the developer. At this point, on the basis of the given specification the developer in the “HB” organization estimates his/her labour input. The calculation of labour effort is not formalized and based on expert estimation. But, as shown on Figure 2, it is proposed to calculate efforts at an analysis stage, without bringing up an application to the developer. To formalize the process of effort calculation empirically dependence LFC = f(w,c) was found in the following form
Computer Modelling
49
LFC = w1 + c1 + w2 + c2, (3)
where w1 and w2 are the number of words in the application of the customer and analyst, respectively; c1 and c2 are the number of symbols in the application of the customer and analyst, respectively.
As a result formula (2) has the following form
WD = LFC * p. (4)
In order to get the p factor, data about WD accumulated in the development process can be used. In other words, for each application Рi = WDi/ LFCi, where WDi is the developer’s labour effort for i-th application, LFCi is LFC calculation using formula (3) for i-th application.
The generalized factor P is calculated as an average for all Pi.
Let’s consider an application of the given technique in the “HB” organization when modifying modules in one system.
Formal specification for software development (modification) was designed for the use of the technique. Formal specification is based on GOST34 [8] (Fig. 3).
Application for revision of software
Customer: ______________________________________________________ Type of application: ______________________________________________________ Name of system: ______________________________________________________ Name of module: ______________________________________________________ Name of task: ______________________________________________________ Access level: _______________________________________________________________________________________________
Purpose, objectives, expected results from the introduction: _______________________________________________________
Reason for work: ________________________________________________________________________________________
Basic requirements: ________________________________________________________________________________________
__________________________________________________________________________________________________________ __________________________________________________________________________________________________________ Interaction with other subsystems
A list of all the classifiers (directories)
The list of legal acts and regulations (including internal), regulating the order of execution of works –
Requirements for the ways and means of communication for information exchange between users of the subsystem: in
accordance with the specifications.
The requirement to conduct the event log: Yes.
Number of users of the subsystem: ________________
Availability of information included in the list of information to be protected:_________________
The owner created an information resource______________________________________________
Aspirational deadlines –
Customer's representative_____________________________________________________________
Authorized representative of the analysis ________________________________________________
Head of Analysis
______________________ ________________ _________ 2012г
(signature of the head)
Figure 3. Example, formal specification (the application) to refine the software
Table 1 contains the source data for calculation (w1, c1, w2, c2)
Table 1. Quantitative characteristics of applications for the module “Credits”
S/n Name of application WDi fact.
Customer application Analyst application
Number of words, (w1) Number of characters, (c1) Number of words, (w2) Number of characters, (c2) 1 Unblock 11 612 6685 568 4917 2 Stepped rate 15 853 7657 1058 7208
3 Calculation of the duration 5 240 1715 292 2564 4 Cancellation of deposit 13 688 6518 764 6087
5 Changes mortgage 4 234 1981 319 2722
6 Delivery of documents 4 127 1114 418 3372 7 Calculation of the homogeneity 9 130 1146 812 8205
Computer Modelling
50
According to the data given in Table 1, the following results are derived: Based on the first application “Unblock” LFC = 612+6685+568+4917 = 12782
Рi = WDi/ LFCi = 11*60*8/12782 = 0.41,
where 11 is a runtime of the application in man-days. For accuracy improvement, calculations are done in minutes with account of 8-hour workday.
An average value of a correction factor for the module “Credits” calculated according to 7 applications is P = 0.44.
Using the values of p and data from Table 1, the developer’s labour effort (WDi) is calculated according to 7 applications (Table 2).
Table 2. The results of calculations of labour input required for application processing by the developer according to the module “Credits”
S/n Name of application LFC Pi P (per.-min.) (per.-day) WDi WDi
1 Unblock 12782 0,38 0,44 5624,08 11,72
2 Stepped rate 16776 0,43 0,44 7381,44 15,38 3 Calculation of the duration 4811 0,6 0,44 2116,84 4,41 4 Cancellation of deposit 14057 0,68 0,44 6185,08 12,89 5 Changes mortgage 5256 0,27 0,44 2312,64 4,82 6 Delivery of documents 5031 0,48 0,44 2213,64 4,61 7 Calculation of the homogeneity 10293 0,23 0,44 4528,92 9,44
Table 3 presents the data that allows comparing the results of actual input required for application processing with the calculated data.
The absolute error of labour input required for application processing is calculated by the formula:
Δ WDi = | WDi actual. – WDi calc.|
The relative error of labour input: ε (WDi) = Δ WDi / WDi actual.
The error between actual WDi and calculated WDi is insignificant as shown in Table 3.
Table 3. The comparison of actual and calculated data of labour input required for applications processing by the developer
S/n Name of application Module
WDi WDi Δ WDi
(per.-day)
ε (WDi)
(%)
(per.-day)
fact. (per.-day) calc.
1 Unblock Credits 11 11,72 0,72 6,55
2 Stepped rate Credits 15 15,38 0,38 2,53
3 Calculation of the duration Credits 5 4,41 -0,59 11,8 4 Cancellation of deposit Credits 13 12,89 -0,11 0,85
5 Changes mortgage Credits 4 4,82 0,82 20,5
6 Delivery of documents Credits 4 4,61 0,61 15,25 7 Calculation of the homogeneity Credits 9 9,44 0,44 4,89
The results of using the technique based on LFC metrics show that the error of the results of input estimation compared to actual data is relatively small (at least for one module).
Let’s note that the attempts of using the specified approach for labour input estimation required for applications processing that affect multiple modules have not been successful. Therefore, the described technique can be applied only in case of severe restrictions on the subject area and in the presence of reliable data about actual labour input of software development.
4. Conclusions
To estimate the labour input of software development, an adaptive system of input estimation based on formalized specification, a model of which includes corresponding correctors that ensures system configuration for improvement of calculation accuracy, was proposed.
The analysis based on the actual data was conducted in order to evaluate principal applicability of formal specification. At the same time, the quantity of words and symbols were used as the metrics of formal specification (LFC).
Computer Modelling
51
The results of using the method based on LFC metrics show that the error of results of labour input estimation compared to the actual data is relatively small (at least for one module). The maximum value of the error is 20%; the medium is about 9%.
The attempts of using the specified approach for labour input estimation required for applications processing that affect multiple modules have not been successful. Therefore, the described technique can be applied only in case of severe restrictions on the subject area and in the presence of reliable data about actual labour input of software development.
Let’s note that although the proposed metrics is formal, it can be recalled that the structure of formal specification developed by an expert gives necessary substantial sense to the whole technique.
Further development of the approach can be a system that computes the correction factor p by the actual results of design and self-defining type of function fwc. The possible approaches can be the factor analysis, clustering and pattern recognition algorithms, and also algorithms for semantic analysis.
References
1. Lipaev, V. V. (2006). Software Engineering. Methodological Foundations. M.: TEIS. 2. Orlov, S. A. (2004). Technologies of development of the software. St. Petersburg: Piter.
3. Lipaev, V. V. (1993). Debugging complex software: Methods, tools, technology. M: Energoatomizdat. 4. Boehm, B. W. (1985). Software Engineering. Moscow: Radio and Communications.
5. Boehm, B., Turner, R. (2003). Using Risk to Balance Agile and Plan-Driven Methods. Computer, June 2003, 57–66.
6. Abran, A., Robillard, P. N. (1996). Function Points Analysis: An Empirical Study of its Measurement Processes. IEEE Transactions on Software Engineering, 22, 895–909.
7. Arkhipenkov, S. (2009). Lecture № 6. Evaluation complexity and timing of software development. Retrieved December 20, 2011, from http://citforum.ru/SE/project/arkhipenkov_lectures/11.shtml 8. Development of documentation in accordance with GOST. Retrieved December 20, 2011, from
http://www.rugost.com/index.php?option=com_content&task=category§ionid=7&id=25&Itemid=62 Received on the 21st of December 2011
