The Lawrence Putnam model describes the time and effort requires finishing a software project of a specified size. Putnam makes a use of a so-called The Norden/Rayleigh Curve to estimate project effort, schedule & defect rate as shown in fig:
Putnam noticed that software staffing profiles followed the well known Rayleigh distribution. Putnam used his observation about productivity levels to derive the software equation:
The various terms of this expression are as follows:
K is the total effort expended (in PM) in product development, and L is the product estimate in KLOC .
td correlate to the time of system and integration testing. Therefore, td can be relatively considered as the time required for developing the product.
Ck Is the state of technology constant and reflects requirements that impede the development of the program.
Typical values of Ck = 2 for poor development environment
Ck= 8 for good software development environment
Ck = 11 for an excellent environment (in addition to following software engineering principles, automated tools and techniques are used).
The exact value of Ck for a specific task can be computed from the historical data of the organization developing it.
Putnam proposed that optimal staff develop on a project should follow the Rayleigh curve. Only a small number of engineers are required at the beginning of a plan to carry out planning and specification tasks. As the project progresses and more detailed work are necessary, the number of engineers reaches a peak. After implementation and unit testing, the number of project staff falls.
Effect of a Schedule change on Cost
Putnam derived the following expression:
Where, K is the total effort expended (in PM) in the product development
L is the product size in KLOC
td corresponds to the time of system and integration testing
Ck Is the state of technology constant and reflects constraints that impede the progress of the program
Now by using the above expression, it is obtained that,
For the same product size, C =L3 / Ck3 is a constant.
(As project development effort is equally proportional to project development cost)
From the above expression, it can be easily observed that when the schedule of a project is compressed, the required development effort as well as project development cost increases in proportion to the fourth power of the degree of compression. It means that a relatively small compression in delivery schedule can result in a substantial penalty of human effort as well as development cost.
For example, if the estimated development time is 1 year, then to develop the product in 6 months, the total effort required to develop the product (and hence the project cost) increases 16 times.
Before beginning new software projects, it is essential to understand the time and cost involved in software development today. The “Constructive Cost Model (COCOMO)” is one effective cost-estimating method widely used in several software projects.
In 1981, Barry W. Boehm introduced the COCOMO model, a procedural approach to software cost assessment. The Effort, average team size, development time, and Effort needed to construct a software project are all predicted using this cost-estimating model. This adds transparency to the model, which helps software managers understand why the model delivers the estimations it does. Furthermore, a waterfall model lifetime was initially based on the basic COCOMO.
This tutorial will cover an overview of the COCOMO model, its generic types, the fundamental computation of the COCOMO-based cost estimating approach, its extension, and its relative advantages and disadvantages.
The necessary steps in this model are:
Get an initial estimate of the development effort from evaluation of thousands of delivered lines of source code (KDLOC).
Determine a set of 15 multiplying factors from various attributes of the project.
Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e., multiply the values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single variable models, using KDLOC as the measure of the size. To determine the initial effort Ei in person-months the equation used is of the type is shown below
Ei=a*(KDLOC)b
The value of the constant a and b are depends on the project type.
In COCOMO, projects are categorized into three types:
Organic
Semidetached
Embedded
1.Organic: A development project can be treated of the organic type, if the project deals with developing a well-understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar methods of projects. Examples of this type of projects are simple business systems, simple inventory management systems, and data processing systems.
2. Semidetached: A development project can be treated with semidetached type if the development consists of a mixture of experienced and inexperienced staff. Team members may have finite experience in related systems but may be unfamiliar with some aspects of the order being developed. Example of Semidetached system includes developing a new operating system (OS), a Database Management System (DBMS), and complex inventory management system.
3. Embedded: A development project is treated to be of an embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For Example: ATM, Air Traffic control.
For three product categories, Bohem provides a different set of expression to predict effort (in a unit of person month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks, etc.
Top Techniques for Applying the COCOMO Model
By following the methods listed below, any software developer who uses the COCOMO model may guarantee a proper workflow and arrive at the most accurate and efficient cost estimation.
utilizing precise historical data
modifying the model to meet precise project requirements
to routinely update the estimations
to incorporate tools for project management
use additional estimating methods in conjunction with the present model to improve judgment
by using practical measures to validate the outcomes
Teach the group how to use the model
Not all assumptions and modifications
Hold review meetings on a regular basis
Assure ongoing participation from stakeholders
According to Boehm, software cost estimation should be done through three stages:
Basic Model
Intermediate Model
Detailed Model
1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters. The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on the code size are shown below:
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
Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe that the effort is somewhat superliner in the size of the software product. Thus, the effort required to develop a product increases very rapidly with project size.
The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that the development time is a sub linear function of the size of the product, i.e. when the size of the product increases by two times, the time to develop the product does not double but rises moderately. This can be explained by the fact that for larger products, a larger number of activities which can be carried out concurrently can be identified. The parallel activities can be carried out simultaneously by the engineers. This reduces the time to complete the project. Further, from fig, it can be observed that the development time is roughly the same for all three categories of products. For example, a 60 KLOC program can be developed in approximately 18 months, regardless of whether it is of organic, semidetached, or embedded type.
From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost per month. But, implicit in this project cost computation is the assumption that the entire project cost is incurred on account of the manpower cost alone. In addition to manpower cost, a project would incur costs due to hardware and software required for the project and the company overheads for administration, office space, etc.
It is important to note that the effort and the duration estimations obtained using the COCOMO model are called a nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries to complete the project in a time shorter than the estimated duration, then the cost will increase drastically. But, if anyone completes the project over a longer period of time than the estimated, then there is almost no decrease in the estimated cost value.
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:
E = 2.4 * (400)1.05 = 1295.31 PM D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12=2462.79 PM D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM D = 2.5 * (4772.8)0.32 = 38 PM
Example2: A project size of 200 KLOC is to be developed. Software development team has average experience on similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff size, and productivity of the project.
Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience of development time.
2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of the number of lines of code and some constants calculated according to the various software systems. The intermediate COCOMO model recognizes these facts and refines the initial estimates obtained through the basic COCOMO model by using a set of 15 cost drivers based on various attributes of software engineering.
Classification of Cost Drivers and their attributes:
(i) Product attributes –
Required software reliability extent
Size of the application database
The complexity of the product
Hardware attributes –
Run-time performance constraints
Memory constraints
The volatility of the virtual machine environment
Required turnabout time
Personnel attributes –
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience
Project attributes –
Use of software tools
Application of software engineering methods
Required development schedule
The cost drivers are divided into four categories:
Intermediate COCOMO equation:
E=ai (KLOC) bi*EAF D=ci (E)di
Coefficients for intermediate COCOMO
Project
ai
bi
ci
di
Organic
2.4
1.05
2.5
0.38
Semidetached
3.0
1.12
2.5
0.35
Embedded
3.6
1.20
2.5
0.32
3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version with an assessment of the cost driver?s effect on each method of the software engineering process. The detailed model uses various effort multipliers for each cost driver property. In detailed cocomo, the whole software is differentiated into multiple modules, and then we apply COCOMO in various modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
Planning and requirements
System structure
Complete structure
Module code and test
Integration and test
Cost Constructive model
The effort is determined as a function of program estimate, and a set of cost drivers are given according to every phase of the software lifecycle.
COCOMO Extension
It is worthwhile for you to conduct more studies on the extension of this successful COCOMO model, even if this page just discusses the COCOMO I model (1981). The expansion of COCOMO I, which is utilized in different software development process categories, including Agile, Iterative, and spiral waterfall models, is a clear illustration of COCOMO II (1995).
In addition to the COCOMO I and COCOMO II models, a number of cost-estimating models are also being created, such as the Constructive Phased Schedule & Effort Model (COPSEMO) and the Constructive Rapid Application Development schedule estimate model (CORADMO).
Pros of the COCOMO Model
Unlike other models like SLIM, COCOMO is straightforward to understand how it operates.
The estimator may better grasp the effects of many elements influencing project costs by using drivers.
COCOMO offers suggestions for historical initiatives.
It is simple to estimate the project’s overall cost using the COCOMO model.
Understanding the effects of the many elements that influence project crises is made much easier by the drivers.
Cons of the COCOMO Model
When most effort estimates are needed early in the project, it is challenging to estimate KDSI.
In actuality, KDSI is a length measurement rather than a size one.
extremely susceptible to the development mode being incorrectly classified.
A key factor in success is adapting the model to the organization’s requirements utilizing past data, which isn’t always accessible.
It restricts the software expenses’ accuracy.
COCOMO disregards consumer knowledge, abilities, and collaboration.
Additionally, agile is centered on quick feedback cycles and taking advantage of fresh ideas, whereas COCOMO is based on designing the design in advance.
Examples Based on Case Studies and Real-World Applications
NASA Projects: NASA has estimated costs and timelines for several space exploration software projects using the COCOMO model.
Defence Systems: The U.S. Department of Defense primarily uses defense systems to guarantee precise budgeting and prompt fulfillment of software project needs.
Telecommunications: Telecom corporations use COCOMO to calculate the time and expenses involved in creating sophisticated network management software.
IBM: IBM used COCOMO to efficiently manage project timetables, optimize resources, and create extensive enterprise software systems.
Healthcare: In healthcare IT projects, electronic health record systems and other vital applications are planned and developed using COCOMO.
For any new software project, it is necessary to know how much it will cost to develop and how much development time will it take. These estimates are needed before development is initiated, but how is this done? Several estimation procedures have been developed and are having the following attributes in common.
Project scope must be established in advanced.
Software metrics are used as a support from which evaluation is made.
The project is broken into small PCs which are estimated individually. To achieve true cost & schedule estimate, several option arise.
Delay estimation
Used symbol decomposition techniques to generate project cost and schedule estimates.
Acquire one or more automated estimation tools.
Uses of Cost Estimation
During the planning stage, one needs to choose how many engineers are required for the project and to develop a schedule.
In monitoring the project’s progress, one needs to access whether the project is progressing according to the procedure and takes corrective action, if necessary.
Cost Estimation Models
A model may be static or dynamic. In a static model, a single variable is taken as a key element for calculating cost and time. In a dynamic model, all variable are interdependent, and there is no basic variable.
Static, Single Variable Models: When a model makes use of single variables to calculate desired values such as cost, time, efforts, etc. is said to be a single variable model. The most common equation is:
C=aLb
Where C = Costs L= size a and b are constants
The Software Engineering Laboratory established a model called SEL model, for estimating its software production. This model is an example of the static, single variable model.
E=1.4L0.93 DOC=30.4L0.90 D=4.6L0.26
Where E= Efforts (Person Per Month) DOC=Documentation (Number of Pages) D = Duration (D, in months) L = Number of Lines per code
Static, Multivariable Models: These models are based on method (1), they depend on several variables describing various aspects of the software development environment. In some model, several variables are needed to describe the software development process, and selected equation combined these variables to give the estimate of time & cost. These models are called multivariable models.
WALSTON and FELIX develop the models at IBM provide the following equation gives a relationship between lines of source code and effort:
E=5.2L0.91In the same manner duration of development is given by
D=4.1L0.36
The productivity index uses 29 variables which are found to be highly correlated productivity as follows:
Where Wi is the weight factor for the ithvariable and Xi={-1,0,+1} the estimator gives Xione of the values -1, 0 or +1 depending on the variable decreases, has no effect or increases the productivity.
Example: Compare the Walston-Felix Model with the SEL model on a software development expected to involve 8 person-years of effort.
Calculate the number of lines of source code that can be produced.
Calculate the duration of the development.
Calculate the productivity in LOC/PY
Calculate the average manning
Solution:
The amount of manpower involved = 8PY=96persons-months
(a)Number of lines of source code can be obtained by reversing equation to give:
Then
L (SEL) = (96/1.4)1⁄0.93=94264 LOC L (SEL) = (96/5.2)1⁄0.91=24632 LOC
(b)Duration in months can be calculated by means of equation
A Software Project is the complete methodology of programming advancement from requirement gathering to testing and support, completed by the execution procedures, in a specified period to achieve intended software product.
Need of Software Project Management
Software development is a sort of all new streams in world business, and there’s next to no involvement in structure programming items. Most programming items are customized to accommodate customer’s necessities. The most significant is that the underlying technology changes and advances so generally and rapidly that experience of one element may not be connected to the other one. All such business and ecological imperatives bring risk in software development; hence, it is fundamental to manage software projects efficiently.
Software Project Manager
Software manager is responsible for planning and scheduling project development. They manage the work to ensure that it is completed to the required standard. They monitor the progress to check that the event is on time and within budget. The project planning must incorporate the major issues like size & cost estimation scheduling, project monitoring, personnel selection evaluation & risk management. To plan a successful software project, we must understand:
Scope of work to be completed
Risk analysis
The resources mandatory
The project to be accomplished
Record of being followed
Software Project planning starts before technical work start. The various steps of planning activities are:
The size is the crucial parameter for the estimation of other activities. Resources requirement are required based on cost and development time. Project schedule may prove to be very useful for controlling and monitoring the progress of the project. This is dependent on resources & development time.
Cyclomatic complexity is a software metric used to measure the complexity of a program. Thomas J. McCabe developed this metric in 1976.McCabe interprets a computer program as a set of a strongly connected directed graph. Nodes represent parts of the source code having no branches and arcs represent possible control flow transfers during program execution. The notion of program graph has been used for this measure, and it is used to measure and control the number of paths through a program. The complexity of a computer program can be correlated with the topological complexity of a graph.
How to Calculate Cyclomatic Complexity?
McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity. The cyclomatic number is equal to the number of linearly independent paths through a program in its graphs representation. For a program control graph G, cyclomatic number, V (G), is given as:
V (G) = E – N + 2 * P
E = The number of edges in graphs G
N = The number of nodes in graphs G
P = The number of connected components in graph G.
Example:
Properties of Cyclomatic complexity:
Following are the properties of Cyclomatic complexity:
V (G) is the maximum number of independent paths in the graph
The other set of metrics we would live to consider are known as Information Flow Metrics. The basis of information flow metrics is found upon the following concept the simplest system consists of the component, and it is the work that these components do and how they are fitted together that identify the complexity of the system. The following are the working definitions that are used in Information flow:
Component: Any element identified by decomposing a (software) system into it’s constituent’s parts.
Cohesion: The degree to which a component performs a single function.
Coupling: The term used to describe the degree of linkage between one component to others in the same system.
Information Flow metrics deal with this type of complexity by observing the flow of information among system components or modules. This metrics is given by Henry and Kafura. So it is also known as Henry and Kafura’s Metric.
This metrics is based on the measurement of the information flow among system modules. It is sensitive to the complexity due to interconnection among system component. This measure includes the complexity of a software module is defined to be the sum of complexities of the procedures included in the module. A process contributes complexity due to the following two factors.
The complexity of the procedure code itself.
The complexity due to the procedure’s connections to its environment. The effect of the first factor has been included through LOC (Line Of Code) measure. For the quantification of the second factor, Henry and Kafura have defined two terms, namely FAN-IN and FAN-OUT.
FAN-IN: FAN-IN of a procedure is the number of local flows into that procedure plus the number of data structures from which this procedure retrieve information.
FAN -OUT: FAN-OUT is the number of local flows from that procedure plus the number of data structures which that procedure updates.
Essentially the need for software development and other activities are to process data. Some data is input to a system, program or module; some data may be used internally, and some data is the output from a system, program, or module.
Example:
Program
Data Input
Internal Data
Data Output
Payroll
Name/Social Security No./Pay rate/Number of hours worked
That’s why an important set of metrics which capture in the amount of data input, processed in an output form software. A count of this data structure is called Data Structured Metrics. In these concentrations is on variables (and given constant) within each module & ignores the input-output dependencies.
There are some Data Structure metrics to compute the effort and time required to complete the project. There metrics are:
The Amount of Data.
The Usage of data within a Module.
Program weakness.
The sharing of Data among Modules.
1. The Amount of Data: To measure the amount of Data, there are further many different metrics, and these are:
Number of variable (VARS): In this metric, the Number of variables used in the program is counted.
Number of Operands (η2): In this metric, the Number of operands used in the program is counted. η2 = VARS + Constants + Labels
Total number of occurrence of the variable (N2): In this metric, the total number of occurrence of the variables are computed
2. The Usage of data within a Module: The measure this metric, the average numbers of live variables are computed. A variable is live from its first to its last references within the procedure.
For Example: If we want to characterize the average number of live variables for a program having modules, we can use this equation.
Where (LV) is the average live variable metric computed from the ith module. This equation could compute the average span size (SP) for a program of n spans.
3. Program weakness: Program weakness depends on its Modules weakness. If Modules are weak(less Cohesive), then it increases the effort and time metrics required to complete the project.
Module Weakness (WM) = LV* γ
A program is normally a combination of various modules; hence, program weakness can be a useful measure and is defined as:
Where
WMi: Weakness of the ith module
WP: Weakness of the program
m: No of modules in the program
4.There Sharing of Data among Module: As the data sharing between the Modules increases (higher Coupling), no parameter passing between Modules also increased, As a result, more effort and time are required to complete the project. So Sharing Data among Module is an important metrics to calculate effort and time.
Feature point is the superset of function point measure that can be applied to systems and engineering software applications.
The feature points are used in those applications in which the algorithmic complexity is high like real-time systems where time constraints are there, embedded systems, etc.
Feature points are computed by counting the information domain values and are weighed by only single weight.
Feature point includes another measurement parameter-ALGORITHM.
The table for the computation of feature point is as follows:
Feature Point Calculations
Measurement Parameter
Count
Weighing factor
1. Number of external inputs (EI)
–
*
4
–
2. Number of external outputs (EO)
–
*
5
–
3. Number of external inquiries (EQ)
–
*
4
–
4. Number of internal files (ILF)
–
*
7
–
5. Number of external interfaces (EIF)
–
*
7
–
6.Algorithms used Count total →
–
*
3
–
The feature point is thus calculated with the following formula:
where count-total is obtained from the above table.
CAF = [0.65 + 0.01 * ∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of ∑(fi) .
6. Function point and feature point both represent systems functionality only.
7. For real-time applications that are very complex, the feature point is between 20 and 35% higher than the count determined using function point above.
3D function points
Three dimensions may be used to represent 3D function points?data dimension, functional dimension, and control dimension.
2. The data dimension is evaluated as FPs are calculated. Herein, counts are made for inputs, outputs, inquiries, external interfaces, and files.
3. The functional dimension adds another feature-Transformation, that is, the sequence of steps which transforms input to output.
4. The control dimension that adds another feature-Transition that is defined as the total number of transitions between states. A state represents some externally observable mode
Now fi for average case = 3. So sum of all fi (i ←1 to 14) = 14 * 3 = 42 FP = Count-total * [0.65 + 0.01 *∑(fi ) ] = 618 * [0.65 + 0.01 * 42] = 618 * [0.65 + 0.42] = 618 * 1.07 = 661.26
Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further modified by the International Function Point Users Group (IFPUG). FPA is used to make estimate of the software project, including its testing in terms of functionality or function size of the software product. However, functional point analysis may be used for the test estimation of the product. The functional size of the product is measured in terms of the function point, which is a standard of measurement to measure the software application.
Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the software application functional size to the client, customer, and the stakeholder on their request. Further, it is used to measure the software project development along with its maintenance, consistently throughout the project irrespective of the tools and the technologies.
Following are the points regarding FPs
1. FPs of an application is found out by counting the number and types of functions used in the applications. Various functions used in an application can be put under five types, as shown in Table:
Types of FP Attributes
Measurements Parameters
Examples
1.Number of External Inputs(EI)
Input screen and tables
2. Number of External Output (EO)
Output screens and reports
3. Number of external inquiries (EQ)
Prompts and interrupts.
4. Number of internal files (ILF)
Databases and directories
5. Number of external interfaces (EIF)
Shared databases and shared routines.
All these parameters are then individually assessed for complexity.
The FPA functional units are shown in Fig:
2. FP characterizes the complexity of the software system and hence can be used to depict the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information systems.
6. The five parameters mentioned above are also known as information domain characteristics.
7. All the parameters mentioned above are assigned some weights that have been experimentally determined and are shown in Table
Weights of 5-FP Attributes
Measurement Parameter
Low
Average
High
1. Number of external inputs (EI)
7
10
15
2. Number of external outputs (EO)
5
7
10
3. Number of external inquiries (EQ)
3
4
6
4. Number of internal files (ILF)
4
5
7
5. Number of external interfaces (EIF)
3
4
6
The functional complexities are multiplied with the corresponding weights against each function, and the values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement parameter type.
The Function Point (FP) is thus calculated with the following formula.
where Count-total is obtained from the above Table.
CAF = [0.65 + 0.01 *∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of ∑(fi)
Also note that ∑(fi) ranges from 0 to 70, i.e.,
0 <= ∑(fi) <=70
and CAF ranges from 0.65 to 1.35 because
When ∑(fi) = 0 then CAF = 0.65
When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
Based on the FP measure of software many other metrics can be computed:
Errors/FP
$/FP.
Defects/FP
Pages of documentation/FP
Errors/PM.
Productivity = FP/PM (effort is measured in person-months).
$/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.
9. FP metrics is used mostly for measuring the size of Management Information System (MIS) software.
10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs) of a subsystem are further adjusted by considering some more General System Characteristics (GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows:
Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its weight is 5.
The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF = (TDI * 0.01) + 0.65
Remember that the value of VAF lies within 0.65 to 1.35 because
When TDI = 0, VAF = 0.65
When TDI = 70, VAF = 1.35
VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Example: Compute the function point, productivity, documentation, cost per function for the following data:
According to Halstead’s “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operand.”
Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be classified as either operators or operands. All software science metrics can be defined in terms of these basic symbols. These symbols are called as a token.
The basic measures are
n1 = count of unique operators. n2 = count of unique operands. N1 = count of total occurrences of operators. N2 = count of total occurrence of operands.
In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.
Halstead metrics are:
Program Volume (V)
The unit of measurement of volume is the standard unit for size “bits.” It is the actual size of a program if a uniform binary encoding for the vocabulary is used.
V=N*log2n
Program Level (L)
The value of L ranges between zero and one, with L=1 representing a program written at the highest possible level (i.e., with minimum size).
L=V*/V
Program Difficulty
The difficulty level or error-proneness (D) of the program is proportional to the number of the unique operator in the program.
D= (n1/2) * (N2/n2)
Programming Effort (E)
The unit of measurement of E is elementary mental discriminations.
E=V/L=D*V
Estimated Program Length
According to Halstead, The first Hypothesis of software science is that the length of a well-structured program is a function only of the number of unique operators and operands.
N=N1+N2
And estimated program length is denoted by N^
N^ = n1log2n1 + n2log2n2
The following alternate expressions have been published to estimate program length:
NJ = log2 (n1!) + log2 (n2!)
NB = n1 * log2n2 + n2 * log2n1
NC = n1 * sqrt(n1) + n2 * sqrt(n2)
NS = (n * log2n) / 2
Potential Minimum Volume
The potential minimum volume V* is defined as the volume of the most short program in which a problem can be coded.
V* = (2 + n2*) * log2 (2 + n2*)
Here, n2* is the count of unique input and output parameters
Size of Vocabulary (n)
The size of the vocabulary of a program, which consists of the number of unique tokens used to build a program, is defined as:
n=n1+n2
where
n=vocabulary of a program n1=number of unique operators n2=number of unique operands
Language Level – Shows the algorithm implementation program language level. The same algorithm demands additional effort if it is written in a low-level program language. For example, it is easier to program in Pascal than in Assembler. L’ = V / D / D lambda = L * V* = L2 * V
Language levels
Language
Language level λ
Variance σ
PL/1
1.53
0.92
ALGOL
1.21
0.74
FORTRAN
1.14
0.81
CDC Assembly
0.88
0.42
PASCAL
2.54
–
APL
2.42
–
C
0.857
0.445
Counting rules for C language
Comments are not considered.
The identifier and function declarations are not considered
All the variables and constants are considered operands.
Global variables used in different modules of the same program are counted as multiple occurrences of the same variable.
Local variables with the same name in different functions are counted as unique operands.
Functions calls are considered as operators.
All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
In control construct switch ( ) {case:…}, switch as well as all the case statements are considered as operators.
The reserve words like return, default, continue, break, sizeof, etc., are considered as operators.
All the brackets, commas, and terminators are considered as operators.
GOTO is counted as an operator, and the label is counted as an operand.
The unary and binary occurrence of “+” and “-” are dealt with separately. Similarly “*” (multiplication operator) are dealt separately.
In the array variables such as “array-name [index]” “array-name” and “index” are considered as operands and [ ] is considered an operator.
In the structure variables such as “struct-name, member-name” or “struct-name -> member-name,” struct-name, member-name are considered as operands and ‘.’, ‘->’ are taken as operators. Some names of member elements in different structure variables are counted as unique operands.
All the hash directive is ignored.
Example: Consider the sorting program as shown in fig: List out the operators and operands and also calculate the value of software science measure like n, N, V, E, λ ,etc.
Solution: The list of operators and operands is given in the table
Operators
Occurrences
Operands
Occurrences
int
4
SORT
1
()
5
x
7
,
4
n
3
[]
7
i
8
if
2
j
7
<
2
save
3
;
11
im1
3
for
2
2
2
=
6
1
3
–
1
0
1
<=
2
–
–
++
2
–
–
return
2
–
–
{}
3
–
–
n1=14
N1=53
n2=10
N2=38
Here N1=53 and N2=38. The program length N=N1+N2=53+38=91
