International Journal of EmergingTrends & Technology in Computer Science(IJETTCS)

Web Site: www.ijettcs.org Email: [email protected], [email protected]

Volume 3, Issue 2, March April 2014 ISSN 2278-6856


Volume 3, Issue 2 March April 2014 Page 299


Abstract This paper define the artifacts representing
different dimensions and to become in consistent over the
year. It is a survey paper on selection of artifacts and their
maintenance. In this paper we define the selection of artifacts
which are developed during testing so the selected artifacts
are more feasible. The Software Testing is time consuming
activity. The overall time spent on testing depends, in many
factors including, human factors, and process issues, testing
techniques, tool used. This paper evaluates empirical
relationship between a new metric Qi and testability of classes
in object oriented systems. The Qi metric captures the
distribution of the control flow in a system.

Keyword Quality Assurance Indicator, Software
Testability, Artifacts. Constraints Management.

1. INTRODUCTION
Software Testing is an activity to evaluate an attribute and
the capability of a program, or system and determines the
required result. Software testing plays an important role
to improve the product in software quality. It is a primary
technique that used to gain consumers confidence in the
software industry. Software testing is a time and cost
consuming task [8]. The purpose of Testing can be quality
assurance, verification and validation or reliability
estimation. The objective of software testing is to design
minimum number of test cases so that they identify as
many faults as possible [8]. To posses the testing effort of
classes, we used different metrics; these were classified in
two categories low and high based on the testing effort
[2]. Software testing is one of the major and primary
techniques for achieving high quality software. Software
testing is done to detect presence of faults, which cause
software failure [3]. Verification is done to ensure that the
software meets specification and is close to structural
testing whereas validation is close to the functional
testing and is done by executing software under test
(SUT).
Metrics can be used to predict the testability and manage
the testing effort. It can help the software managers and
testers to monitor testing activities and determine the
critical path of the code on which they have to focus to
ensure the quality of the software [2]. We define a metric,
called Qi capturing in an integrated way with attributes of
object oriented software system such as complexity and
coupling. Software testing plays an important role on the
total quality of the final product [2].The metric captures
the distribution of control flow in a system. The objective
is to identify relative values that may be used for
identifying before the testing process begins and the
critical classes that will require a high testing effort
during the testing process. The class on which more
testing effort is required is used to ensure the software
quality. Testing is a critical component of a mature
software development process [7]. It is very challenging
and costly activity, and it provides the strongest support
for development of high quality software [7]. Testing is
used in its broadest sense to encompass all Software
quality related activities. For improve the quality of the
software we consider the Testing Maturity Model, for
increasing the quality of the software this maturity model
will have a very positive impact on software quality.

2. SOFTWARE TESTABILITY
Software testability is an important software quality
attribute. Different definition of software testability as
IEEE defines this is a degree to which a system facilitates
establishment of the test criteria. ISO defines testability as
characteristics of maintainability. Having quantitative
data on the testability of software can be used for the
software development managers the strong decision
making to develop a high quality product [2]. Testability
measured by the test code lines and number of assert
statement in the test code.
According to Fenton and Pfleeger software testability is
an external attribute [9]. It is related to the testing effort
reduction and software quality. Testability give impact on
the test costs and making the design decisions based on
test costs. Software testability is affected by different
factors such as controllable, observable and the global test
cost. It is consider as a probability predicting whether test
will detect a fault. The component testability is based on
five factors these are understandability, observable,
controllability, traceability and testing support capability
[2].

3. QUALITY ASSURANCE INDICATOR
The Quality Assurance Indicator (Qi) is based on the
concept of control call graph. These control call graphs
are reduced form of the traditional control flow graphs
[2]. Software testing remains the primary technique used
to gain consumers confidence indicator of a class. This
indicator is based on different intrinsic characteristics of
the class. A control call graph is a control flow graph,
where the nodes representing instructions.
Selection and maintenance of software artifacts
during testing to improve the quality of
software

Ankita Dwivedi
1
and Navneet Kumar Verma
2


1
Research Scholoar, Apaji Institute of Mathematics & Applied computer technology, Banasthali Vidyapith
2
School of Computer and Systems Sciences, J aipur National University
International Journal of EmergingTrends & Technology in Computer Science(IJETTCS)
Web Site: www.ijettcs.org Email: [email protected], [email protected]
Volume 3, Issue 2, March April 2014 ISSN 2278-6856


Volume 3, Issue 2 March April 2014 Page 300


Software quality assurance is relevant for software
engineer, to reduction the costs and improve quality
assurance activities, which are performed on every
software project. Quality assurance systems are defined as
the organizational structure, responsibility procedures
process and resources for implementing quality
management. Software quality assurance activities play
an important role in producing high quality software.
Software quality assurance is the vital component of
software project development [8][2].
The quality assurance indicator Qi metric is in the
normalized form and gives the values in the interval. A
low value of the Qi of a class indicates that the class is at
high-risk and needs a high testing effort and activity to
increase its quality. And the high value of the Qi metric
of a class provides information about class that this class
is at low-risk so there is no need to give best effort of
testing. The quality assurance indicator of a method is the
estimation that is measured as the probability that the
control flow of the method go through out the method
without any defect or failure. It can be considered as an
indicator which is associated with the risk of the [2]. We
assume that the quality of a method also depends on the
quality of the he methods. . There are many different
definitions of quality. Some are based on the capability of
the products and others can be based on the customer
values for identifying the level of the defect.
The first definition of quality is given by Shewhart in the
beginning of 20th century:
1. The quality is defined in two categories; one is consider
quality as the objective which is independent from the
existence of man. The second category shows the
objective reality in the sense, feel and thin of the
product it is consider as the subjective side of the
quality.
2. The problem inherent is attempted to define the quality
of a product. The quality is defined as the satisfaction
of the user with considerable characteristics; the project
must be designed to give the satisfaction to the
customer which pays for it. This is not easy task
because once give the deliverable successfully he finds
that the needs of the consumer have changed.
3. Quality consider only as customer determination, it is
not an engineer, marketing or a general management
determination. Quality is based on the requirement of
the customer to the product and also based on the
competitive market.
4. The quality has multiple meanings. Quality consists of
those product features which meet the need of
customers and thereby provide product satisfaction. The
goal of quality is to provide management with the data
necessary to be informed about product quality. Quality
consists of freedom from deficiencies.

4. ARTIFACTS
Artifacts define in the software engineering as a generic
term as deliverable which could be produced by any role
in the software development life cycle. These are taken in
the form of deliverable from a project plan, test plan,
source code file etc. An artifact is one of many kind of
tangible by product produced during development of
software. Some artifacts are used to describe the
functions, architecture and the design of software. Other
artifacts are relevant to the development process such as
project plans, risk assessments. Artifacts describe
automated behavior or control sequences. In the earliest
stage of development, some artifacts may be created by
the designing team to show the role of project sponsor
how serious the contractor is ready about meeting for the
projects needs.
Artifacts vary in their maintainability. Maintainability is
affected by the fulfillment of the artifacts. The role can be
either practical or symbolic. The symbolic artifacts
convey the information in improper way, but the way of
expression is very impressive[3][4]. Symbolic artifacts are
sometimes referred as Illuminated Scrolls because the
decorations do not enhance the understanding in the
information industry. The illuminated scrolls are
considered as un-maintainable because it requires the
diligence to preserve the symbolic quality. Because of this
reason, when the project sponsor approved the
Illuminated Scrolls they are replaced by artifacts for
serving a practical role. Practical artifacts must be highly
maintainable they have to be maintained throughout the
lifecycle of the project.
Moreover the objective is to identifying the values before
the testing process start, not to evaluate a design. The
critical classes that will require high testing effort and
during the testing is required to ensure software quality.
4.1 Maintenance of Software Artifacts
Software can be described as multidimensional. There is
multiple varieties of artifacts for the software systems.
These artifacts are design documents, source code, test
cases, and documentation .Each of these dimensions
describes limited part of the software the actual system
[6]. As code is written, developers gradually ignore the
initial stages of development, the specifications and the
system design, documentation, component specifications,
and test cases.
It is necessary to ensure that all the artifacts remain
consistent with one another. Programmers have the
freedom to develop the software in the best way. Some
changes are best done at source code level for the
performance enhancement. Test case can be written first
and documentation is done when the coding is complete.
The work is based on the concept to ensure that the
consistency can be done by the programmer.
This is necessary because if any inconsistency identified
between the different software artifacts which identified
by the constraints. For this, define the meta constraints.
These met constraints define the information about the
artifacts that how information associated with one artifact
should be match with the information associated with the
second type of artifact for different set of artifacts. These
meta constraints are based on the information of various
artifacts which is extracted.
International Journal of EmergingTrends & Technology in Computer Science(IJETTCS)
Web Site: www.ijettcs.org Email: [email protected], [email protected]
Volume 3, Issue 2, March April 2014 ISSN 2278-6856


Volume 3, Issue 2 March April 2014 Page 301


4.2 Requirement of consistent software evaluation
The objective is to provide a framework for the
maintenance of consistency for many dimensions of
software. There must be some requirements for the
consistency for the software artifacts. These requirements
are meet so that consistency maintained, some
requirements are
1. Using existing methods The tool must be able to use
the existing method and also bound the programmers to
work with different style.
2. Work with existing tool one is not required to re-
implement the existing tool. It is necessary that these
codes support the legacy code and external component.
3. Enable to locate the points for inconsistency
Identified the inconsistency in the software code and it
provide the programmer the exact information that
where the inconsistency arise.
4. Handle a wide range of software dimensions All the
dimensions must be handle a wide range which are not
included in the existing tool.
5. Bidirectional The mechanism must handle the
changes at any time in different aspect, it is important.
A developer who changes the design must know that
which code is affected by the change.
6. Handle low overhead This mechanism does not
interfere with existing tool and it must be automatic so
that no excessive amount of time is taken to find the
inconsistency.
Previous approaches for the consistent software evolution
depend on development of a single comprehensive
language or a single common semantic representation.
Such approaches cannot reach a desire goal for different
reasons. Firstly, they cannot attract the goods of
dimensions which inherent to software. Second, they fail
to handle the new dimensions implied to new types of
software and its development. Third, it will make it
difficult to incorporate existing components into a system.
Fourth, developers uses variety of different tools,
languages in a single system and methods, this is fail to
deal with the software exist today [5].
4.3 Constraints are the basis for the evaluation
The integration method that is developed for the
maintenance of the consistency of different software
artifacts is based on constraints [4]. The Palladio model-
driven approach supports prediction of Quality of Service
(QoS) properties of component-based SW architectures,
providing a meta model for specification of performance-
relevant information and a simulator for derivation of
performance, reliability maintainability, and cost metrics.
It is implemented in a well established tool which enables
integration within a component based development
process [9].
The constraint based approach to maintenance is flexible.
Constraints can also be used for checking the style of a
program, designing, coding, patterns and design rules.
These constraints are relationship between types of
artifacts. The artifact relationship is the first point of the
model of evaluation.
In order to make such a model, one must be attentive in
specifying the basis for the constraints. These constraints
are provided for the accountability. When a constraint is
not met to determine that what part of the source or other
software artifact are in conflict these constraints are used.
These constraints are easy to specify and check. The latter
is required to ensure the consistency maintenance which
is tractable in the face of thousands of constraints.
Finally, the basis for specifying the constraints should
flexible enough to fit in the wide variety of the different
dimensions of software.

Figure 1: Constraint based model for the artifact
consistency maintenance

For the development of the framework first understand
the artifacts of software. This can done by the abstracting
the information from the different software artifacts.
Provide the information for the different artifacts types
allows the common name space for the different artifacts
and ensures that information needed by the constraints is
available information. It is also possible to abstract the
information from the multiple sources. Each item
abstracted from the artifacts identifies the location of
consistency.
As shown in the figure1 information box is used to obtain
the data from the artifacts and also captures the meaning
of the artifacts. This box contains all the information that
is particularly of the artifacts and the global information
such as file name. The constraints between the individual
artifacts which are defined in model that mapped to the
constraints between the information associated with those
artifacts. The goal for the implementation of this model is
to use a relational database for storing the information
which abstracted from each artifact. Each artifact type
defines its own set of relation and uses a common set of
relations. The database relations which are associated
with the corresponding artifact types are updated when
the artifacts changes. An individual constraint indicates
as constraints between tuples in the relations associated
with the various artifacts [7]. There is no limit for
checking such constraints as both the predicates and the
International Journal of EmergingTrends & Technology in Computer Science(IJETTCS)
Web Site: www.ijettcs.org Email: [email protected], [email protected]
Volume 3, Issue 2, March April 2014 ISSN 2278-6856


Volume 3, Issue 2 March April 2014 Page 302


set of objects that can be enhanced to accommodate the
wide variety of software dimensions.
4.4 Analysis for the ensure of consistency
To analyses the consistency and to detect the
inconsistency between the software design,
documentation, source code, test cases and other artifacts
develop a tool that is software development tool, CLIME.
This is designed for the demonstration of power and
potential. This tool is developed to tell the programmers
that artifacts are unsynchronized and there is need to
change and update to achieve system wide consistency.
The tool is a prototype [2]. It handles java system and a
limited set of artifacts.

Figure 2: The architecture for CLIME tool

The tool is divided in two parts the first part is for
extracting the necessary information from the artifacts
and the second part is used to find and update the
information about the constraints.
The Project Manager keeps track of the artifacts that are
able to detect, using the Activity Monitor, which have
changed since the previous update. The Information
abstractor gathers as much information as possible from
each of the artifacts that have changed and format this
information in terms of relational tables, with each
abstractor generating its own set of tables.
Most of these are in two parts. The first part takes the
artifact, isolates the information relevant to a particular
dimension, and then generates an XML file with that
information. The second part reads this XML file and
then generates a second XML file consisting of
commands describing what should be removed, inserted,
or updated.
The Database Manager is then responsible for
incrementally updating the artifact information,
attempting to minimize the changes to the database, and
maintaining identifying information across updates. In
addition to updating the database, it generates an XML
file describing what has changed in the database. The
Constraint Manager is in charge of finding and updating
constraints and storing the resultant constraint
information in another database. It does this using a set of
meta constraints that define generic relationships, using
these to find specific constraints, and then checking the
constraints as the underlying data is changed. The
Presentation Manager provides the user interface.
Information is extracted from the various software
artifacts using an array of tools, each oriented to a
particular type of artifact. Each type of artifact is treated
independently, with its own scanners and its own set of
stored information. Artifact changes are detected and
updated at the file level.
The user interface that CLIME provides is useful but
could be improved. Future work here would include
letting users define their own hierarchies of constraints
rather than or in addition to the built-in ones, letting
users assign priorities to the constraints, letting users
choose sets of constraints to ignore, storing and reloading
selected sets of constraints, and being able to show
changes to constraints over time rather than just the
current state of all constraints.

5. CONCLUSION
The problem of software quality analysis and estimation
is important during software development. The
automation of test case generation has been a long-
standing problem in software engineering. Artifacts
describe automated behavior or control sequences. In the
earliest stage of development of software the artifacts may
be developed by the design team to sever a symbolic role
to show the project sponsor the seriousness of the
contractor for the meeting the projects needs. We must
have to estimate the quality of the software so that we
analyses the need of testing and can select the artifacts
during testing to become it viable and easy. We used the
proposed approach for the priority of the documents
which produced during the software testing activity.

References
[1] Yasutaka kamei, Emad Shihab, Bram Adams Anand
Sinha and Naoyasu Ubayashi, A Large-Scale
Empirical Study of Just-in-Time Quality Assurance
IEEE Transactions on Software Engineering, vol.
39,June 2013.
[2] Mourad Badri and Fadel Toure, Evaluating the
Effect of Control Flow on the Unit Testing Effort of
Classes: An Empirical Analysis Software
Engineering Research Laboratory, Department of
Mathematics and Computer Science, University of
Quebec, Canada, March 2012.
[3] Audris Mockus, Nachiappan Nagappan and Trung
T.Dinh-Throng, Test Coverage and Post-
Verification Defects: Amultiple Case Study.
[4] James A.Whittaker, The 10 Minute Test Plan,
IEEE Software, November /December 2012.
[5] Andreia Rodrigues da Silva, Fermando Rodrigues de
Almedia Junior, Applying a Goal Programming
Model to Support the Selection of Artifacts from
Testing Process University of Fortaleza, 2012.
International Journal of EmergingTrends & Technology in Computer Science(IJETTCS)
Web Site: www.ijettcs.org Email: [email protected], [email protected]
Volume 3, Issue 2, March April 2014 ISSN 2278-6856


Volume 3, Issue 2 March April 2014 Page 303


[6] Steven P. Reiss, Incremental Maintenance of
Software Artifacts IEEE Transaction on Software
Engineering, Vol. 32, September 2006.
[7] Ilene Burnstein, Taratip Suwanassart, and Robert
Carlson, Developing A Testing Maturity Model for
Software Test Process Evaluation and Improvement
IEEE Computer Society, 1996.
[8] Aditya P mathur, Foundation of Software Testing,
1st edition Pearson Education 2008.
[9] N. Fenton and S.L. Pfleeger, Software Metrics: A
Rigorous and Practical Approach, PWS publishing
company, 1997.