Increasingly, object-oriented measurements are being used to
evaluate and predict the quality of software . A growing body of empirical
results supports the theoretical validity of these metrics. The validation of
these metrics requires convincingly demonstrating that
(1) the metric measures what it purports to measure (for
example, a coupling metric really measures coupling) and
(2) the metric is associated with an important external metric,
such as reliability, maintainability and fault-proneness. Often these metrics
have been used as an early indicator of these externally visible attributes,
because the externally visible attributes could not be measures until too late
in the software development process.
CLASS ORIENTED MATRICES
Lines of code and functional point metrics can be used for
estimating object-oriented software projects. However, these metrics are not
appropriate in the case of incremental software development as they do not provide
adequate details for effort and schedule estimation. Thus, for object-oriented
projects, different sets of metrics have been proposed. These are listed below.
Number of scenario scripts: Scenario scripts are a
sequence of steps, which depict the interaction between the user and the
application. A number of scenarios is directly related to application size and
number of test cases that are developed to test the software, once it is
developed. Note that scenario scripts are analogous to use-cases.
Number of key classes: Key classes are
independent components, which are defined in object -oriented analysis. As key
classes form the core of the problem domain, they indicate the effort required
to develop software and the amount of 'reuse' feature to be applied during the development
process.
Number of support
classes: Classes, which are required to implement the system but are
indirectly related to the problem domain, are known as support classes. For
example, user interface classes and computation class are support classes. It
is possible to develop a support class for each key class. Like key classes,
support classes indicate the effort required to develop software and the amount
of 'reuse' feature to be applied during the development process.
Average number of support
classes per key class: Key classes are defined early in the software project while
support classes are defined throughout the project. The estimation process is
simplified if the average number of support classes per key class is already
known.
Number of subsystems: A collection of classes
that supports a function visible to the user is known as a subsystem.
Identifying subsystems makes it easier to prepare a reasonable schedule in
which work on subsystems is divided among project members.
The afore-mentioned metrics are collected along with other
project metrics like effort used, errors and defects detected, and so on. After
an organization completes a number of projects, a database is developed, which
shows the relationship between object-oriented measure and project measure.
This relationship provides metrics that help in project estimation.
No comments:
Post a Comment