Software Engineering: Lecture_2

MARWARI COLLEGE, RANCHI

(AN AUTONOMOUS UNIT OF RANCHI UNIVERSITY FROM 2009)

- Prakash Kumar, Dept. of CA

-Archana Kumari, Dept. of CA
-Raju Manjhi, Dept. of CA

__________________________________________________________________________________ 

Software metrics:

Software metric is a characteristic of a software system, system documentation, or development process that can be objectively measured. Examples of metrics include the size of a product in lines of code; the Fog index (Gunning, 1962), which is a measure of the readability of a passage of written text; the number of reported faults in a delivered software product; and the number of person-days required to develop a system component.

Some software metrics:

·         Size Metrics - Lines of Code (LOC) (), mostly calculated in thousands of delivered source code lines, denoted as KLOC.

·         Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of the software.

·         Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph.

·         Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications define the quality of the product.

·         The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of the product.

·         Process Metrics - In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.

·         Resource Metrics - Effort, time, and various resources used, represents metrics for resource measurement.

In brief Software metrics may be either control metrics or predictor metrics. As the names imply, control metrics support process management, and predictor metrics help you predict characteristics of the software. Control metrics are usually associated with software processes.

Examples of control or process metrics are the average effort and the time required to repair reported defects. Predictor metrics are associated with the software itself and are sometimes known as ‘product metrics’.

Both control and predictor metrics may influence management decision making. Managers use process measurements to decide if process changes should be made, and predictor metrics to help estimate the effort required to make software changes.

There are two ways in which measurements of a software system may be used:

1. To assign a value to system quality attributes By measuring the characteristics of system components, such as their cyclomatic complexity, and then aggregating these measurements, you can assess system quality attributes, such as maintainability.

2. To identify the system components whose quality is substandard Measurements can identify individual components with characteristics that deviate from the norm. For example, you can measure components to discover those with the highest complexity. These are most likely to contain bugs because the complexity makes them harder to understand.

Product metrics: Product metrics are predictor metrics that are used to measure internal attributes of a

software system. Examples of product metrics include the system size, measured in lines of code, or the number of methods associated with each object class.

Product metrics fall into two classes:

1. Dynamic metrics, which are collected by measurements made of a program in execution. These metrics can be collected during system testing or after the system has gone into use. An example might be the number of bug reports or the time taken to complete a computation.

2. Static metrics, which are collected by measurements made of representations of the system, such as the design, program, or documentation. Examples of static metrics are the code size and the average length of identifiers used.

Software component analysis: A measurement process that may be part of a software quality assessment process is as follows:

The key stages in this component measurement process are:

1. Choose measurements to be made: The questions that the measurement is intended to answer should be formulated and the measurements required to answer these questions defined.

2. Select components to be assessed: you may not need to assess metric values for all of the components in a software system. Sometimes, you can select a representative selection of components for measurement, allowing you to make an overall assessment of system quality.

3. Measure component characteristics: the selected components are measured and the associated metric values computed. This normally involves processing the component representation (design, code, etc.) using an automated data collection tool.

4. Identify anomalous measurements: after the component measurements have been made, you then compare them with each other and to previous measurements that have been recorded in a measurement database.

5. Analyze anomalous components: when you have identified components that have anomalous values for your chosen metrics, you should examine them to decide whether or not these anomalous metric values mean that the quality of the component is compromised.

Types of Measures

• Direct Measures (internal attributes)

– Cost, effort, LOC, speed, memory

• Indirect Measures (external attributes)

– Functionality, quality, complexity, efficiency, reliability, maintainability

Size oriented metrics:    Size oriented metrics are derived by normalization   Quality, or productivity measure of considering the size of the software that has been produced. To develop Metrics that can be a simulated with similar metrics from other project which use LOC as our normalization value.

 A simple size oriented metric can be developed each project.

o   Error per KLOC

o   Defect per KLOC

o   Dollar per KLOC

o   Pages of documentation per KLOC

o   Error per person month

o   KLOC per person month

o   Dollar per page documentation

LOC Metrics

• Easy to use

• Easy to compute

• Can compute LOC of existing systems but cost and requirements traceability may be lost

• Language & programmer dependent

Function Oriented Metrics

The function point was proposed by Albrecht is used for measuring the functionality delivered by a system function can be used to- 

1)      Estimate the cost or effort required to design code and test the software.

2)      Predict the number of errors that will be encountered during testing.

3)      For the cost the no of component or source line the implement system. Function point is delivered using empirical formula based on countable measured or software information.

 Information domain value is:

1)      No of external Input(EI)

2)      No of external Output(EO)

3)      No of external Enquiry(EQ)

4)      No of Internal logical files(ILF)

5)      N o of external Interface files(EIF)

Compute Function Points

FP = Total Count * [0.65 + .01*Sum(Fi)]

Where,

Count total=sum of all function point entries

Fi= Value adjustment factor (may be assume)

Cyclomatic Complexity

• Set of independent paths through the graph (basis set)

• V(G) = E – N + 2

– E is the number of flow graph edges

– N is the number of nodes

• V(G) = P + 1

– P is the number of predicate nodes

Metrics and Software Quality

FURPS

• Functionality - features of system

• Usability – aesthesis, documentation

• Reliability – frequency of failure, security

• Performance – speed, throughput

• Supportability – maintainability

COCOMO MODEL

COCOMO stands for Constructive Cost Model. The COCOMO model is commonly used to estimate the total effort required to develop a software project. It is based on the study of already developed software projects.

         Boehm’s refers to a group of model. The basic model was built around the equation.

Effort =C*(Size)^k

Where,

C= constant

K=constant

Effort is measured in per person per month and size is measured in thousand of delivered source of code instruction.

NOTE:-C and K depend into and classified into organic, semi-detach or embedded.

The technical nature of the system

1)      Organic mode: -In organic mode small teams developed software in a highly familiar in house environment.

2)      Embedded: - In this mode the product being developed had to operate within every tight environment constraint and changes very costly.

3)      Semidetached:-It is a combination of organic and embedded.

ADVANTAGE	DISADVANTAGE
Use to calculate effort.	It ignores requirement and all documentation.
Easy to interpret.	It ignores customer skill and knowledge.
Easy to understand.	It ignores hardware issue.
Can be easily adjusted to environment.	Depend on the amount of time spent in each phase

Project              C           k
Organic	2.4	1.05
Semi-detached	3.0	1.12
Embedded	3.6	1.20

Organic: Effort = 2.4(KLOC)^1.05 PM

Semi-detached: Effort = 3.0(KLOC)^1.12 PM

Embedded: Effort = 3.6(KLOC)^1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development time based on the effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

                Effort=C*(KLOC) ^k PM
                Tdev=b₁*(efforts)b₂ Months                 Estimated Size of project= 400 KLOC
                D = 2.5 * (1295.31)0.38=38.07 PM
                D = 2.5 * (2462.79)0.35=38.45 PM
                D = 2.5 * (4772.8)0.32 = 38 PM

(i)Organic Mode

                E = 2.4 * (400)1.05 = 1295.31 PM

(ii)Semidetached Mode

                E = 3.0 * (400)1.12=2462.79 PM

(iii) Embedded Mode

                E = 3.6 * (400)1.20 = 4772.81 PM

COCOMO II model

The COCOMO II model is a COCOMO 81 update to address software development practices in the 1990's and 2000's. The model is by now invigorative software engineering artifact that has, from customer perspective, the following features:

•        The model is simple and well tested

•        Provides about 20% cost and 70% time estimate accuracy

In general, COCOMO II estimates project cost, derived directly from person-months effort, by assuming the cost is basically dependent on total physical size of all project files, expressed in thousands single lines of code (KSLOC). The estimation formulas have the form:

The COCOMO II model makes its estimates of required effort (measured in Person-Months – PM) based primarily on your estimate of the software project's size (as measured in thousands of SLOC - KSLOC) :

Effort = 2.94 * EAF * (KSLOC)^E

Where:

    EAF   Is the Effort Adjustment Factor derived from       the Cost Drivers

    E        Is an exponent derived from the five Scale         Drivers

As an example, a project with all Nominal Cost Drivers and Scale Drivers would have an EAF of 1.00 and exponent, E, of 1.0997. Assuming that the project is projected to consist of 8,000 source lines of code, COCOMO II estimates that 28.9 Person-Months of effort is required to complete it:

Effort = 2.94 * (1.0) * (8)^1.0997 = 28.9 Person-Months

--------xxxx------