24 Elsevier Publications, 2013

Proceedings of International Conference on Computing Sciences

WILKES100 ICCS 2013
ISBN: 978-93-5107-172-3
Software quality assessment of components based on input
modeling technique
Puneet Goswami
*
0F
Associate Professor, Department of Computer Science and Engineering, Galaxy Group of Instittions, HR, India
Abstract
The Component Based development approach is widely accepted in software industry. The success of the systems designed
on these approaches depends on the models used to analyze the quality of the systems. Numerous models are present which
mainly focus on analyzing the systems based on some system parameters/metrics. These system parameters have an
undeviating impact on the entire system as they are the means through which the models deduce the system. All the system
parameters or metrics may not be of prime importance. Hence, there is a necessity to identify only those metrics, which have
higher priorities over the other. The present work provides an input modeling approach to analyze the metrics used by the
available models. A reliable metric when used to design models provides reliable models and hence a reliable system as a
whole.
2013 Elsevier Science. All rights reserved.
Kevwords. component, Input Modelling Technique, Inspection Rate , Inspection hours
1. Introduction
Accurately predicting software development effort is a critical concern of many organizations even today.
Software effort estimation has been the focus of much research mostly over the last couple of decades. [18].[1]
provides us better understanding of cost and schedule estimation approaches for CBSD. CBSD (Component
Based Software Development) has become an important alternative for building complex and distributed
applications. Low cost and efforts, faster delivery and quality are the main benefits of this approach [8]. The
quantitative approach to evaluation consists of defining, collecting and analyzing objective quantitative metrics
that can be combined into quality model. [3] These quality models can in that case be used for quality analysis of
the system designed using CBSE approach.
Quality models in contrast depend on the system parameters. These models use specific parameters for the
investigation of the system quality. These metrics measure principle structures that if improperly designed may
negatively affect the design and code quality attributes. Subsequently these metrics have to be selected with extra
care. [2] provides several reasons for the inadequacy in measuring the object oriented metrics themselves and
also proposes some new metrics for CBSD.
Metrics further can be evaluated to known whether or if it is reliable to be considered as the base groundwork
of the entire system design process. If this can be done, then we can undeniably choose the model for our system
design and analysis.
2. Literature Review
Component based software engineering (CBSE) is a branch of software engineering the priority of which is
the separation of concerns in respect of the wide ranging functionality available throughout a given software
system. CBSE emphasizes on building system by reusing high quality configurable software components. This
*
Corresponding author: Puneet Goswami
25 Elsevier Publications, 2013
Puneet Goswami
reduces its development cost as well as time to market and ensures higher reliability, better maintainability and
quality by exploiting reusability [1].
But there are several problems with the CBSE approach such as component trustworthiness, component
certification, emergent property prediction and requirements tradeoffs [6]. Hence, we always have
the prerequisite of a means through which we can analyze the software components i.e. the quality, quantity
and efforts predictions. Underestimating these can have a detrimental impact on both the functionality and
quality of software products and therefore the developers reputation and competitiveness [1].
3. Objective
Input models provide the driving force for a simulation of any system. In simulation of a queuing system,
typical input models are the distributions of time between arrivals and of service times. For the simulation of a
reliability system, the distribution of time to failure of any component is an example for input model [5].
For a system designed using the CBSE approach, we need to consider the distributions of few of
the parameters of the system. As the components or component modules constitute the input set of such a system,
we need to consider the effort estimators of the components for modeling the simulation of the CBSE system.
As we have already seen that inspection rate, error density etc are important and reliable metrics, these can be
considered as the system parameters for the input model.
A system designed using CBSE approach is thoroughly analyzed before its design using the system
parameters. Here in this paper, we have analyzed such system parameters to be reliable or unreliable based on
the input modeling results. If system parameter is found out to be unreliable then the systems designed based on
them are highly probable to failure.
4. Research Methodologies
Input modeling technique uses the 4 step approach in development of useful model for input data [5]. They are
in brieI -

Data collection
Identification of probability distribution
A Comparative Study of Hard and Fuzzy Data Clustering Algorithms with Cluster Validity Indice
Choosing Distribution Parameters & Estimators

Evaluation of your choice using goodness of fit.

4.1. Data Collection
We have used the data given in table 1, taken from [7]. Five parameters namely the inspection hours,
code lines, inspection rate, defects and error density can be considered for the study.
Out oI various metrics Ior soItware, the inspection hours, inspection rate and error density are the most important
metrics Ior industrial applications according to |16|. Ebenau was the Iirst who employed inspection metrics to
identiIy modules that are likely to be error prone |4|. SoItware inspection is considered as an essential practice to
develop high quality soItware. II it is possible to identiIy potentially error prone modules with relatively high
degree oI accuracy at little or no extra cost by analyzing the present inspection data, project managers can use
such Iindings to optimize soItware development productivity. They may test potentially erroneous modules more
extensively than other |16|. Sun Sup So |7| proposed in his paper a Iuzzy logic based approach to predict error
prone modules. In |16| there is re-evaluation oI this approach; based on triangular Iuzzy numbers.
But how can one predict the system parameters (metrics) to be reliable? When large systems are being designed
using the CBSE approaches, analysis oI the system is done beIore the design phase based on several system
parameters. A wrong choice oI parameter cannot be identiIied until the design phase. Correcting or changing the
parameter at this stage gives unproductive and undesirable results.
26 Elsevier Publications, 2013
Software quality asessment of components bases on input modelling technique
Table 1. Particulars of 25 software modules under study
1 2 3 4 5 6 7 8
Fig. 1. Histogram for inspection hours
1 DISP function I 1.25 280 224 03 10.7
2 Trans type 1 I 2.00 280 140 04 14.3
3 Trans type 1 R 1.50 280 187 02 07.1
4 Prog Keys I 2.00 414 207 14 33.8
5 Status Disp I 2.25 520 231 10 19.2
6 Trans type 2 I 2.25 1200 533 04 03.3
7 OPS I 1.50 240 160 01 04.2
8 LCD-Service I 0.50 80 160 00 00.0
9 Status bus I 2.00 440 220 10 22.7
10 LCD-Team I 0.75 85 113 02 23.5
11 OPS I 1.00 81 81 01 12.3
12 Status DMA I 2.50 330 132 08 24.2
13 LCD-User I 1.00 250 250 01 04.0
14 Status Bus R 1.00 440 440 03 06.8
15 Wait Display I 1.50 350 233 00 00.0
16 Active Display I 1.00 240 240 04 16.7
17 Status Disk I 2.50 570 228 02 03.5
18 Trans type 4 I 3.00 400 133 04 10.0
19 Audible Alert I 0.50 80 160 00 00.0
20 Chan handler I 1.80 200 111 08 40.0
21 Dial_0 and LDN I 0.50 36 75 02 55.6
22 Directed Recal I 2.00 370 185 05 13.5
23 DMA handler I 0.30 40 133 02 50.0
24 Aler /CON I 1.00 120 120 03 25.0
25 Do not disturb I 0.80 140 175 05 35.7
1. module no 2. component name
3. inspection meetings 4. inspection hours
5. code lines 6. inspection rate(lines/h)
7. defects 8. errors per KLoC
I- initial inspection R- replicated inspection
4.2. Identification of probability distributions
In order to identify distribution, we need to estimate all the available parameters. We are using a
frequency distribution or Histogram [5] to identify the shape of the distribution.
According to the steps given in [5], five different histograms are designed for the five parameters collected
respectively and are shown below.
27 Elsevier Publications, 2013
Puneet Goswami
FIG 2 .HISTOGRAM FOR CODE LINES
Fig. 2. Histogram for code lines
Fig. 3. Histogram for inspection rates
FIG5: HISTOGRAM FOR ERRORDENSITY
Fig. 4. Histogram for defects
28 Elsevier Publications, 2013
Software quality asessment of components bases on input modelling technique
Fig. 5. Histogram for error density
The main purpose of preparing a histogram is to find the shape of the distributions and compare them with
well-known existing distributions. The shape of the distribution in Fig.1 is a normal distribution. To go in deep
we can consider it as a lognormal distribution since the bell is heavier towards left. Those in Fig.2 3 4 & 5 are
exponential distributions. To know more about probability distribution identification, you can look up [5].
4.3. Choosing distribution parameters & estimators
The distribution parameters for lognormal distribution are &o^2 and that oI exponential distribution is . To
estimate the distribution parameters, the preliminary statistics is to find the sample mean and sample variance.
From [5] sample mean (X

) is defined by

X=
_ X
n
i=1
n
............................................................. (1)
and the sample variance S
2
is defined by
x
2
-nX

2 n
S
2
=
_
i=1
n-1
.................................................... (2)
Table 2: Sample Mean and Sample Variance of the Parameters
Sl.no Parameters Sample mean Sample variance
1. Inspection Hours 0.95 0.49
2. Code lines 5.00 10.50
3. Inspection Rate 6.25 8.25
4. Defects 6.25 30.90
5. Error Density 4.16 10.16
29 Elsevier Publications, 2013
Puneet Goswami
Table 3. Estimator values of the system parameters
Sl.no Parameter Distribution Estimators
1. Inspection hours lognormal = 0.95
2. Code lines exponential
`
= 0.2
3. Inspection Rate exponential
`
= 0.16
4. Defects exponential
`
= 0.16
5. Error Density exponential
`
z
z
z
z= 0.24
Numerical estimates [5] of the distribution parameters are needed to reduce the family of distributions to a
specific distribution and to test the resulting hypothesis. According to Table 3 we have considered our numerical
estimates.
We have to keep in mind that a distribution parameter is an unknown constraint whereas the estimator is a
statistic which depends on the sample values.
4.4. Evaluations
Goodness of fit test is used to test the hypothesis. We test the hypothesis obtained from the above three steps.
If hypothesis is accepted then we can consider the corresponding parameter as reliable.
Two well known goodness of fit test are the Chi-Square test and the Kolmogorov-Smirnov test. Choosing one,
let us conduct the Chi-Square test on our data.
The histogram of the inspection rate shown in Fig. 3 appeared to follow an exponential distribution, so the
parameter z
`
= 0.16 was computed. Thus, the following hypothesis are formed-
H
0
: the inspection rates are exponentially distributed
H
1
: the inspection rates are not exponentially distributed
2
The critical value _
u,k-s-1
can be found in any statistical tables. Refer [5]. The hypothesis H
0
is rejected if
_
0
2
>
_
u,k-s-1
2
, where
_
0
2
= tcststotistic = _
(0
i-
L
i
)
2
L
i
...... (3)
k= number of intervals = 4
n= sample size= 25
p= expected probability= 1/k= 0.25
E
i
= expected frequencies= n*p= 6.25
O
i
= observed frequencies
s = number of parameters estimated from the data (z
`
) which is 1
Degree of freedom= k-s-1 = 4-1-1 = 2
u level oI signiIicance 0.05
TABLE 4:CALCULATIONOF X
0
2
Class interval Observed freq
(O
|-
F
|
)
2
F
|
(70-140] 8 0.49
(140- 210] 8 0.49
(210-280] 7 0.09
>= 280 2 2.89
Total 25 3.96
_
0
2
= tcststotistic = _
(0
i-
L
i
)
2
L
i
=3.96
30 Elsevier Publications, 2013
Software quality asessment of components bases on input modelling technique
_
0
2
.05,2=
5.99
Since 3.96 is less than 5.99 the hypothesis H
0
can be accepted and hence inspection rate can be considered as a
reliable metric while designing the system.
The chi square test can be conducted for different level of significance. In the above test for inspection rate,
we have occupied the level of significance as 0.05. The test results for different system parameters and for
different level of significances can be calculated similarly and the results are listed below in the Table 5.
Table 5: Test results of chi-square test
System parameter
2

Percentage points from table

0.005 O 0.05 O 0.1 O
Inspection hours 7.31 16.70 A 11.10 A 9.20 A
Code lines 8.40 12.84 A 7.81 R 6.25 R
Inspection rate 3.96 10.60 A 5.99 A 4.61 A
Defects 9.64 10.60 A 5.99 R 4.61 R
Error density 12.2 14.96 A 9.49 R 7.38 R
O- Output R- Reject A-Accept
_
0
2
- calculated from data
A 0.1 level of significance is considered as accurate value for the test. Accordingly we have inspection hours
and inspection rate as the most reliable metrics. Defects, error density and code lines are reliable metrics only to a
certain extent. This is because they are accepted with a 0.005 level of significance. If any of the system
parameters is rejected even at a 0.005 level of significance then it is detrimental to suggest such a metric for the
CBSE system design and analysis. On other hand we highly recommend the system parameters like inspection
hours and inspection rate to be well thought-out with great importance during system design and analysis.
5. Conclusion
CBSE is a discipline leading software engineering into a new generation. CBSE offers a promising way to
promote software reuse, decrease the complexity and time of the development process, via proper information
encapsulation and separation of concerns at various levels. CBSE enhances the modularity of a software system
at much higher level [15]. If done in a right manner CBSE provides tremendous results.
In order to develop an accurate system, analyze the system in particular using reliable models. The reliability
of models can be tested depending on the parameters/metrics used by the models. Models which use unreliable
parameters are liable to fall short during their implementations. The present work has provided a means to check
reliability of the metrics used in CBSE models by means of input modeling technique. If a metric is unreliable
then so is the model using it as well as the entire system designed on its base.
References
[1] T. Wijayasiriwardhane, R. Lai, K.C Kang- Effort estimation of component-based software development- a survey IET software, Feb
2010.
[2] Eun Sook Cho, Min Sun Kim, Soo Dong Kim Component Metrics to Measure Component Quality. Seoul, Korea 2001 IEEE.
[3] Miguel Goulao, Fernando Brito e Abreu- Software Components Evaluation: an Overview, Portugal.
[4] R.G Ebenau, Predictive quality control with software inspection, in software inspection: an industrial best practice, IEEE computer
Society Press, Silver Spring, MD,1996,pp.147-156.
[5] Jerry Banks, John S Carson, Barry l. Nelson, David M Nicol, P Shahabudeen Discrete Event System Simulation fourth edition,
pearson education 2008, 269-331.
31 Elsevier Publications, 2013
Puneet Goswami
[6] SommervilleSoftware Engineering eight edition. Pearson Education, 463-484, 2009.
[7] Sun Sup So, Sun Deok Cha, Yong Rae Kwon- Emperical Evalaution of a fuzzy logic based software quality prediction model,
Elsevier, Fuzzy Sets and systems 127, 199-208, 2002.
[8] Sharma Arun, Kumar Rajesh, Grover P.S Estimation of Quality for Software Components- an Empirical Approach SIGSOFT, Nov
2008.
[9] Cote, M.A. Suryn, W.Georgiadou, E, Software Quality Model Requirements for software Quality Engineering. 14
th
International
Conference on Software Quality Management, 2006, 31-50.
[10] Maryoly, O., M. A. Perez and T.Rojas, A systematic Quality Model for Evaluating Software products , 2002.
[11] Zouaoui, F. & Wilson, J.R. (2001 2). Accounting for input model and parameter uncertainty in simulation. In B.A. Peters, J.S. Smith,
D.J. Medeiros, and M.W. Rohrer (Eds.), Proceedings of the 2001 Winter Simulation Conference (pp. 290-299). Washington, DC: IEEE
Computer Society
[12] Mahmood, S., Lai, R., Kim, Y.S, : Survey of Component Based Software Development. , IET softw, 2007, 1, pp 57-66.
[13] Gupta, A. & Parzen, E. (2004). Input modeling using quantile statistical methods. In R.G. Ingalls, M.D. Rossetti, J.S. Smith, and B.A.
Peters (Eds.), Proceedings of the 2004 Winter Simulation Conference. (pp. 716-724). Winter Simulation Conference.
[14] Leemis, L. (2003). Input modeling. In S. Chick, P.J. Snchez, D. Ferrin, and D.J. Morrice (Eds.), Proceedings of the 2003 Winter
Simulation Conference. (pp. 14-24). Winter Simulation Conference.
[15] Nasib Singh Gill and Pradeep Tomar- Modified development process of component based software engineering march 2010.
[16] Mittal Harish, Bhatia Pradeep, Goswami Puneet - software quality assessment based on fuzzy logic, international journal of software
computing applications, 2008.
[17] Perry D & Wolf, A., 1992, Foundations for the study of Software Architecture, ACM Software Engineering Notes 17(4), 40-52.
[18] Shepperd, M: Software Project Economics: a roadmap , Proc,Int.Conf. on Software Engineering- Futute of Software Engineering, may
2007, pp, 304-315.
[19] Brooks F.P.J (1995), the Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, MA.
Index

C
Chi square test, 30
Component, 25
Component based software engineering (CBSE), 2425

I
Input modeling technique
chi square test, 30
data collection, 25
distribution parameters and estimators, 2829
evaluations, 2930
probability distributions, identification of, 2628
Inspection hours, 25, 30
Inspection rate, 25, 2930

P
Probability distributions, identification
histograms, 2628