Software Engineering

Chapter Five – Part Two

(Process and Project Metrics)

5.3.2 Function-Oriented Metrics

Function-oriented software metrics are used as a measure of the functionality
I
delivered by the application like a normalization value. Since ‘functionality’ cannot be
measured directly, it must be derived indirectly using other direct measures.
Function-oriented metrics suggested a measure called the function point. Function
points are derived using an empirical relationship based on countable (direct)
measures of software's information domain and assessments of software complexity.
Function points are computed by completing the table shown in Figure 5.3.

Figure 5.3
Computing
function points

Five information domain characteristics are determined and counts are provided in the
appropriate table location. Information domain values are defined in the following
manner:
Number of user inputs. Each user input that provides distinct application-oriented
data to the software is counted. Inputs should be distinguished from inquiries, which
are counted separately.
Number of user outputs. Each user output that provides application-oriented
information to the user is counted. In this context output refers to reports, screens,
error messages, etc. Individual data items within a report are not counted separately.
Number of user inquiries. An inquiry is defined as an on-line input that results in the
generation of some immediate software response in the form of an on-line output.
Each distinct inquiry is counted.
Number of files. Each logical master file (i.e., a logical grouping of data that may be
one part of a large database or a separate file) is counted.
Number of external interfaces. All machine readable interfaces (e.g., data files on
storage media) that are used to transmit information to another system are counted.

1
Once these data have been collected, a complexity value is associated with each count.
Organizations that use function point methods develop criteria for determining
whether a particular entry is simple, average, or complex. Nonetheless, the
determination of complexity is somewhat subjective.
To compute function points (FP), the following relationship is used:

FP = count total _ [0.65 + 0.01 _ Σ(Fi)] (5.1)

where count total is the sum of all FP entries obtained from Figure 5.3.

The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the

following questions:

1. Does the system require reliable backup and recovery?

2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry requires the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not important
or applicable) to 5 (absolutely essential). The constant values in Equation (5.1) and
the weighting factors that are applied to information domain counts are determined
empirically.
Once function points have been calculated, they are used in a manner analogous to
LOC as a way to normalize measures for software productivity, quality, and other
attributes:
• Errors per FP.
• Defects per FP.
• $ per FP.
• Pages of documentation per FP.
• FP per person-month.

2
5.3.3 Object-Oriented Project Metrics
Conventional Software Project Metrics such as LOC and FP Metrics can be used to
estimate OO Projects. However, Conventional metrics do not provide enough aid for
the Project Schedule and Effort Adjustments that are required as we iterate through
evolutionary incremental process method.

Object-Oriented Project Metrics Set:

- No. of scenario scripts
- No. of key classes
- No. of support classes
- Average no. of support class / key class
- No. of sub-systems

1. Number of Scenario Scripts

A Scenario Script is a detailed sequence of steps that describes the interaction
between the user and the application.
The number of scenario scripts directly correlated to the size of the application and
to the number of test cases that must be developed to exercise the system once it is
constructed.

2. Number of Key Classes (Foundation Classes)

Key classes are highly independent components that are defined in object-oriented
analysis.
Because key classes are central to the problem domain, the number of such classes is
an indication of the amount of effort required to develop the software and also
indication of the potential amount of reuse to be applied during the development.

3. Number of Support Classes

Support classes are required to implement the system but are not immediately related
to the problem domain. (e.g. user interface classes, database access and manipulation
classes, computation classes).
In addition, a support class can be developed for each of the key classes. Thus, the
number of support classes is an indication of the amount of effort to develop the
software and an indication of potential amount of reuse to be applied during system
development.

4. Average Number of Support Class per Key Class

Key classes are usually known early in the project. Support classes are defined during
the development. If the Average number is known for a given problem domain,
estimating would be much simpler. Some suggestions indicate:

 Applications with a GUI have between two and three times the
number of support classes as key classes.

 Applications with non-GUI have between one and two times the
number of support classes as key classes.

3
5. Number of Subsystems
A Sub-system is an aggregation of classes that support a function which is visible to
the end-user of a system.
Once subsystems are identified, it is easier to lay out a reasonable schedule in which
work on subsystems is partitioned among project staff.

5.3.4 Web Engineering Project Metrics

Measures and metrics used for traditional software engineering project are difficult to
translate directly to Web-Apps. Yet a web engineering organization will have to
collect measurers and build a database that allow it to assess its internal productivity
and quality over a number of projects.

Among the Measurers that can be collected for WEB Engineering Projects are:
 No. of Static Web Pages
 No. of Dynamic Web Pages
 No. of Internal Page Links
 No. of External System interfaces
 No. of Persistent Data Objects
 No. of Static Content Objects
 No. of Dynamic Content Objects
 No. of Executable Functions

1. No. of Static Web Pages

Web pages with static content are the most common of all Web–Applications. These
pages represent ‘’Low relative complexity’’ and generally require less effort to
construct than dynamic pages.
This measure provides the overall size of the application and the effort required
developing it.

2. No. of Dynamic Web Pages

Are essential for e-commerce applications and search engines, financial applications
and may other WebApps. These pages represent ‘’Higher relative complexity’’ and
thus, require more effort to construct than static pages.
This measure also provides the overall size of the application and the effort required
to develop it.

3. No. of Internal Page Links

Are pointers that provide a hyperlink to some other Web pages within the WebApp.
This measure provides an indication of the degree of architectural coupling within the
WebApp. As the link pages increases, the effort expended on designing and
constructing navigations.

4. No. of External System interfaces

WebApps must often interface with ‘’Backroom Business Applications’’.
As the requirements for external interfacing grow, system complexity and
development effort increases.

4
5. NO. of Persistent Data Objects
One or more database files may be accessed by a WebApp. As the number of required
files grows, the complexity of WebApp also grows and effort to implement it
increases proportionally.

6. NO. of Static Content Objects

A static content objects may contain text, graphic, video, animation and audio
information. Multiple content objects may appear on a single web page increasing the
complexity.

7. NO. of Dynamic Content Objects

Dynamic content objects are generated based on user actions and encompasses
internally generated text, graphic, video, animation and audio information that are
incorporated within WebApp. Multiple content Objects may appear on a single web
page.

8. NO. of Executable Functions

An executable function (also called Script or Applet) provides some conceptual
service to the end-user. As the number of functions increases, modeling and
construction effort also increases.
Each of the above measures can be determined at a relatively early stage of the web
engineering process. Web application metrics can be computed and correlated with
project measures such as:
- Effort expanded
- Errors and defects uncovered
- Models or document pages produced.
Web-App measures and project measures provide metrics that can aid in project
estimation.

5.4 Reconciling Different Metrics Approaches

The relationship between lines of code and function points depends upon the
programming language that is used to implement the software and the quality of the
design. A number of studies have attempted to relate FP and LOC measures.
The following table provides rough estimates of the average number of lines of code
required to build one function point in various programming languages:

5
A review of these data indicates that one LOC of C++ provides approximately 1.6
times the "functionality" (on average) as one LOC of FORTRAN. Furthermore, one
LOC of a Visual Basic provides more than three times the functionality of a LOC for a
conventional programming language.

5.5 Metrics for Software Quality

The overriding goal of software engineering is to produce a high-quality application
system within a time-frame that satisfies a market need.

HOW TO ACHIEVE THIS GOAL,

 By applying effective methods coupled with modern development tools within
the context of a mature software process.

 Taking measures continuously to ensure high quality.

The primary source of quality measurers at the project-level is ‘Errors and Defects’.
Metrics derived from Errors and Defects provide an indication of the effectiveness of
software quality assurance and control activities.

Quality Metrics that are derived from Errors / Defects

- Product errors per function point
- Errors uncovered per review hours
- Errors uncovered per testing hour

6
5.6 Measuring Quality
There are many measures of software quality; but the following four metrics provide
useful indicators for the project team.
- Software correctness
- Software maintainability
- Software integrity
- Software usability

1. SOFTWARE CORRECTNESS
Correctness is the degree to which the software performs its required function.
Most common measures for correctness are DEFECTS / KLOC.
Defects are these problems that are reported by Users after the Software has been
released for general use.
For quality assessment, defects are counted over a standard period of time, typically
for one year.

2. SOFTWARE MAINTAINABILITY
 Maintainability is the ease with which a program can be corrected when
an error is encountered, adapted if its environmental changes, or
enhanced if the customer desires a change in requirements.
There is no way to measure maintainability directly so we must use
indirect measurements.
 Mean Time To Change Time-(MTTC), which is a simple time- oriented
metrics that can be used to analyze the changes required, design the
appropriate modification, test, implement and distribute the changes to all
users.

 Programs that are maintainable have a lower MTTC than the programs
that are not maintainable.

3. SOFTWARE INTEGRITY
This attribute measures a system ability to withstand both accidental and intentional
attacks to its security.
Attacks can be made on all three components of software (i.e. programs, data and
documents).
Integrity has become extremely important in the age of ‘’Hackers and Firewalls’’

To measure Integrity, two other attributes need to be defined:

 Threat probability - that an attack of a specific type will occur within a given
time.
 Security probability - that the attack of a specific type will be repelled.

INTEGRITY = ∑ [(1 - (THREAT)) * (1 - (SECURITY))]

Where Threat and Security are summed over each type of attack.

7
4. SOFTWARE USABILITY
Usability is an attempt to quantify user-friendliness and can be measured in terms of
the following four characteristics.

USABILITY CHARACTERISTICS
1. The physical and / or intellectual skill required to learn the system.

2. The time required to become moderately efficient in the use of the

system.

3. The net increase in productivity measured when the system is used by

someone who is moderately efficient.

4. A subjective assessment of users’ attitudes towards the system.

If a program is not user-friendly, then it is doomed to failure even its functions are
valuable.