Unit

3 SOFTWARE PLANNING
3.1 INTRODUCTION
Planning is one of the most important management activity and it is an going
effort through out the life of the project. The objective of software project planning is
to provide a framework that enables the manager to make reasonable
estimate of
resource ,cost and schedule. These estimate are made with in a limited time frame at
the beginning of software project and should be update regularly as the project
progreSs.

3.1.1 Project Planning

Before doing the planning of any project, the feasibility study of project is done.
If the project is found to be feasible, then only software project manager will
undertake project planning. Various activities that are done during project planning
are discussed here.
Estimation of effort, cost and project duration
This is an important activity involved in project planning. However various
heuristic and mathematical techniques are available for estimating these
parameters but the project managers generally uses empirical techniques.
Estimation of resources for aproject includes - estimation about the number of
peoples required and typ of skill level required; and in addition amount of
computing and other resources required. However it is very difficult to guess about
the exact number of peoples required in development process because it depends on
basically two parameters -one is the difficulty level of task to be performed and
second is the productivity level of each individual engineer. The number of engin
to be hired for any project depends on the skill, intelligence and productivity of
engineers and the size and complexity of project.
Risks identification and abatement
During this activity various risks that may occur to the proper development of
project are identified and then these risks are removed using some proper abatement
methods.
 ISHAN'S Software Engineertrq

model
Seleeting Development process mpropor development process model s
ptedBased
In addition
on the totype
theofchoice problem a process model, here may be chang,
in development
project
process. Depending on the type of project,
nthe hfe cycle phases of development some may be ignorable. So based o
sme of the phases may be very importan while
phases might be added o
OmetvpeeNisting
the phases
of proect, sometophases
be used omitted and some new
are may be modified. Generally for the simple
waterfall model is opted while for some challenging
and
deelopment process simple prototyping development model.
wmpleN projects we may Tequire evolutionary or
Project Scheduling
must be settled properly, otherwise it may cause
Time schedule for the project customer dissatisfaction. Also time
late in the delivery of project which results in
settled properly so that it is neither too large, nor too small. When tima
should be
settled is very small it may affect the team moral which can lead project failure To
generally uses a particular type of
OverOme thìs type of problems project managers
planning technique called Sliding Window Planning. beginning In this technique, project
of project. But
managers only do some preliminary planning at the
the various
detailed planning of project is done in stages as we proceed through beginning of
the
phases of development process. The reason behind this is that, at
the project &
project, project managers usually not have complete knowledge of
hence cannot plan completely. However as project successes through various
development phases the project managers obtain more and more knowledge about
the detail of project. Due to this improved information the system, the confidence
level of project manager improved which helps him to properly plan the project.
Project Complexity
Project - Complexity of any project defines the difficulty level of that particular
project. While planning a project, the complexity of that project must also be checked
which helps in planning about the resources of project. However the complexity of
project is a relative term which depends on the person-to-person. A project which is
complex for a particular project manager may not be complex for other. This also
depends on the experience of project managers. A project may be complex for a
project manager because the field in which the project lies may be new to that
particular project manager and this particular project then will be simple for
another particular project manager which is having large experience in that
particular field. For example, a simple data processing application might be taken as
complex by a project manager which is having experience in process control
applications.
SoftwarePlanning 57

Stafing Plan
After the project complexity, efforts, cost and other parameters of project have
beplanned.
hired
Based on these parameters, staffing level and number of persons in staff
to be is decided. Working level of the staff to be selected is chosen based on the
omplexity of project.
Quality Assurance and configuration management plan
During this plan, decision about the required quality and configuration of
projectis done. When the project planning is complete, the results of the planning
nhase is documented in the form of Software Project Management Plan (SPMP)
document by the project manager.

3.2 RESPONSIBILITIES OF SOFTWARE PROJECT MANAGER

A project manager is a professional in field of project management, Project
managers can have the responsibility of planning execution and closing of any
project.
Aproject manager is person responsible for accomplishing the started project
objective, key project management responsibilities includes creating clear and attain
able project, objectives, building the project requirements and managing the
constraints of the project management triangl, which are cost, time, scope, quality.
A project manager is often a client representative and has to determine and
implement the exact needs of the client, based on knowledge of the firm they are
representing. A project manager is bridging gap between Production team and
Client.
Project managers ensure that the clients requirement are met, the project is
completed on time and within budget and than every one else is doing their jobs
properly
Typical responsibilities include
agreeing project objectives
representing the client's interest
providing independent advice on the management of projects
organizing the various professional people working on the project
risk assessment
making sure that allthe aims of the project are meet
making sure that quality standard are met
using the latest approach to keep track of people and progress
recruiting specialists and subcontractors
 measveethe
Bog tne efpot ¢ t1me
a

hsoblem Conploty in tms ef deuelop tae odu

58
eg w -l to ISHAN'S Software Engineering

Anonitoring subcontractors to ensure guidelines are maintained

/accounting, costing and billing
all aspects from design state
pendng on the project, responsibilities can cover
through to completion and handover to the client.
softWare pro)ect
Skill Necessary for software proiect management for effective judgment
managenment, The Software Projects Manager have a good qualitative
and
skills
declsion making capabilities. The project managers need good communication
and ability get work done for the latest software project management tehniques
Sueh as cost estimatiom, risk management and configuration management etc. SOme
bKll such as tracking, controlling the progress of project, customer interaction,
managerial, presentation and team building are largely acquired through
experience.

3.3 PROJECT SIZE ESTIMATION

Project Size Estimation is an activity in software engineering that is used to
estimate the size of a software application or component in order to be able to
implement other software project management activities such as estimating or
tracking.

3.3.1 By Using the Size Oriented Metrics

By using this size of the software produced, we collect the following data for
each project and then using the collected data a set of size-oriented metric is
developed.
1. Lines of code (LOC) [generally measured in Kilo Lines of Code (KLOC)
which means thousand lines of code].
2. Effort - It is measured in number of persons - months.
3. Cost - Measured in currency measurement like dollars or rupees etc.
4 Pages of documentation - Measured by number of pages.
5. Errors Measured by counting the numbers of errors found before the
softwareis released.
6. Defects -Measured by counting the number of defects found after the
software has been delivered to the customer and is used by the customer for
a limited number of years.
7. Peoples - Number of peoples working in the development of software
project. Gountn
Lve
the numbe govrce (mtouchons in the devesh
popam. sed to eshmade te Si2e Sluw
SoftwarePlanning 59

For example, the data collected for the various proiccts in an organization can
belikethis: Sw devloþm eut mauterance
Cost Pages of Errors Defects People
Project LOC Effort
(in lacs) documentation
Project X 130000 35 170. 1200 - 136 19 4

Project Y 25000 65 280 2500 250 26 7

Project Z 17000 45 190 1400 170 20 5

Table 3.1: Size Oriented Metrics Data Collected

So here project Xis having 13000 lines of codes or 13 KLOC which is developed
hy an effort of 35 person-months. The cost occurred on project is 170 lacs. The
documentation made for the illustration is having 1200 pages. Errors detected before
the project release is 136 and defects found when provided one year service to
customer is 19. Four persons were working on the project for development. It should
be noted here that the cost and effort considered here is for all the software
development and maintenance activities from Requirement analysts, through
implementation to maintenance.
3.3.2 Line of Code (LOC)
LOC is the simplest among all metric available to estimate project size. This
metric measures the size of a project by counting the number of source instruction in
the developed program. While counting the number of source instruction, lines used
for commenting the code and header lines are ignored.
Determine the LOC count at end of project is very simple. However, accurate
estimation of the LOC count at the beginning of a project is very difficult.

3.3.2.1 Advantages of Using LOC as Key Measure

There are following favoring point of using LOC as key measure :
1. LOC is very simple to use, because it provide a exact numeric entity.
2 Lines of code can be easily counted and hence LOC is easy to measure.
3. Alarge body of literature and data is already available on concept of LOC.
3.3.2.2 Short-comings of Using LOC as Key Measure
There are following negative points of using LOC as key measure :
60
ISHAN'S Soltware Engneer
1. When LOC is required in planning plhase of the development,
tricky for the planner to estimate LOC at beginning of project.
2.
that time no physical code is available. Beecause
LOC measures are programming language dependent. Por a same actu.
using different programming languages can produce the different
codes. o lines
3. LOC varies with the coding
style of different programmers. As
programmers may write each instructions of the program in some
while some programmers may write multiple instructions in single dif erent liSone
in the first case LOC will be larger, which gives the wrong idea line.
code written in first case is having more s1Ze. that the
4. LO only focuses on the coding part of whole development. A
ideal
should focus on the whole complexity of the problem. But LOCmeasure
1gnores the other phases like design or testing etc. It may be the case tha. clearly
designing of project be very complex but coding is straight forward, In th
case, as LOC only counts the number of source lines in fnal program, will
only consider the coding part of development. The coding-effort is only th.
small part of whole efforts devoted in development life cycle, so the effot.
calculated using LOC which only focuses on coding phase cannot be
proportional to the total effort of project.
5. Using library routines generally decreases the Lines of Code. So if a ney
programmer, not having proper knowledge of the required programming
language may not use the library routines and hence may increase the LOC
value adversely.
6. From the L0C measure, one cannot guess about the quality
and efficiency
of project. Some programmers by using their p00r coding skills may produce
lengthy programs and complicated code structure. This poorly written code
will have more LOC than a piece of efficient code if written. So if effort be
measured based upon LOC, then it will give wrong conclusion by showing
more effort for p00r qualhty program.
7 The program with complex logic but small number of source code lines
require more effort to develop than a program with simple logic and large
number of lines of code.
 61
Software Planning

3.3.3i Function-Oriented Metrics

as key
In the size-oriented metrics, LOC (lines of code) is generally used
measure of
measure ofnormalized value. Function-oriented metrics are Uses a
functionally delivered by the application as a normalization value.
The idea behind this approach is that the size of soft ware product is directly
dependent on the number and types of different functions it performs. But ag the
functionality of a software product cannot be measured directly, so it must be
derived by using the method of indirect measurement using other direct
measures. The measure used for deriving the functionality is called Function
Points (FP). Function points are derived using some direct measures of the
software product which considers the software's information domain as well as
software complexity.
Following five different characteristics are used to compute the Function Points
of the software product:
1. Number of user inputs : Each distinct user input to the software is
counted. However input should be distinguished from user inquiries which are
counted separately.
2. Number of outputs : Each of the output shown to the user, which provide
information to the user is counted. Output generally refers to the screens, error messages,
reports etc. However within a report, individual items are not counted separately.
3. Number of Files : Each logical file is counted.
4. Number of user inquiries : Inquiries here means the interactive queries
made by the user i.e. an online input given by the user to the software and in
response of that input, an immediate response output caused by the system is called
inquiry. All such inquiries are counted.
5. Number of external Interfaces : All interfaces that are used to transmit
information to the another system is counted here-Example includes various storage
medias like tape, disks etc.
However these five parameters collected are not having the equal weightage in
determining the Function Point (FP) of the problem. Each of the parameter is
assigned a particular weightage value based upon the study done by the
organization. For each of the parameter, the organization firstly decide, if the
parameter given is Simple, Average or Complex. For example, for the parameter
Number of user inputs, it is checked that if the user inputs are simple, average or
Complex. Then based upon that, weight is assigned to them as shown in figure 3.1.
 weçley facts
62 JSHAN'S Soltware Engineedog
Simple Average Complex
Parameter i 4 6
Number of user inputs 3
5
Number of user outputs 4
10 15
Number of Files 7
4 6
Number of inquiries 10
7
Number of external interfaces 5

Table 3.2 :Weighting Factor

parameters is
Then based upon the weighting factor. total count of all the
parameters are of
calculated. For example, for a software product, for which all the
average category. The total count will be:
TotalCount = 4 * Number of user inputs
+ 5* Number of user outputs
+ 10 * Number of files
+ 4 * Number of inquiries
+ 7* Number of external interfaces
Then by using the above calculated total count, the function point of software
product is calculated by using following relation :
FP = Total count * [0. 65 + 0.01 (sum of complexity Adjustment values)]

3.3.3.1Advantages of Using FP as Key Measure

() It overcomes all the problems that we are facing while using LOC as key
measure.

() Using function point metric, the size of software can be directly measured
from the initial problem specification. Because the 5 parameters which we
require for calculating function points can be easily guessed from the initial
detailed problem specification.
(Cn) The function point metric is language-independent because the parameters
used for calculating it like number of inputs, number of outputs, number of
inquiries, number of interfaces, number of files are same for a software
product independent of the language which we are using for programming.

3.3.3.2 Disadvantage of Using Function Point as Key Measure

1. Function point metric does not take into account the algorithmic complexity
of a software. Two software products might be having same count and
weightage of five parameters for calculating the function points, but the
algorithm for these two software may be of different complexity. So function
Software Planning
63
points calculated for these two
software will be same even though
2.
algorithmic complexity will be different.
Function point metric is dependent on the engineers working on
Diferent engineers may reach to different results for the project.
software product or number of output screen number of files in
To overcome the problems in shown.
noint metric called Feature point Function point metric, an extension of
metric has been proposed. Thisfunction metric
successtully handle the algorith mic complexity but the
dependence on engineers occurs in this metric also. second problem of
Due to the above mentioned
disadvantages. of Function Point measure, it is
mainly applied for business information
applications like systems and engineering softwaresystem applications. For complex
extension Feature point is employed generally. Feature applications, the function point
used for the applications in which point measure is mainly
algorithmic complexity is high. Because of this
reason, Real-time, embedded and process
the Feature Point measure. To control software systems are handled by
compute the
used for function point i.e. Number of user feature point, same parameters as we
of files, Number of user inquiries and inputs, Number of user outputs, Number
number of external interfaces are used. In
addition to these parameter values, a new
considered for computing the Feature Point. parameter called Algorithm is also
3.3.4 EXAMPLE
Till now we have discussed the two type of
function oriented metrics. These approaches are basedmetrics-size oriented metrics,
on LOC and Function Points
respectively. Now we will discuss an example of each approach
3.3.4.1 An Example of LOC Based Technique
Let us consider a software package to be developed for a
computer-aided design
(CAD) application for mechanical components. A simple review will show that this
software system require interfacing with various graphics peripherals like mouse,
laser printer, high resolution coloured monitor etc. So a general specification for the
software will be as:
CAD Software will get 2 or 3 dimensional geometric data from the engineer.
Auser-interface has to be provided so that engineer can interact with this
system. User interface should exhibit characteristics of good
human/machine interface design.
 64 ISHAN'S Software Engineering
All geonetric data input by the user will be maintained in the database of
CAD software.
A SOttware module for desieping vill be developed which will produce the
required output.
Software will interact with various peripheral devices to get the user input
as wellas todisplav the reauied output. Peripheral devices include mouse
laser printer. plotter, high resolution graphics display, digitizer.
In the real practical working, the specification for the software project will be
very large. Each of the point mentioned above have to be clearly analyzed. Then
based on the analysis, the complete CAD software can be divided into
software functions
() User Interface
fol owing
(ii) GeometricAnalysis
(üi) Database Management
(iv) Peripheral Control
(v) Computer Graphics Display
Function
(vi) Software Module for Design
Analysis
Now for each of the function, the lines of code is
estimated as shown in figure 2.3
Name of Function
User Interface
Estimated Lines of Code
2500
Geometric Analysis 13000
Database Management 3300
Peripheral Control
2000
Computer Graphics Display Function 5000
Software Module for Design Analysis
Total lines Of Code 8400
34200
Table 3.3: Estimation of LOC for
As shown in the table 3.3 various functions.
the estimated LOC for
Lines of Code (LOC). the CAD software is 34200
Now based on the data
metrics can be obtained. It collected for effort or cost
has been seen that for occurring on project, various
productivity of
organization is
Rs. 4 lac per month then cost 600
software of this type, average
LOCIPerson-month
per lines of code is about and if labour rate be
Rs. 800. Then based taken as
on these
Software Planning
65
estimation the total cost of developing software project can be calculated. So for
above discussed CAD system, The estimated cost of
development will be
Total cost = cost per lines of code * Total lines of
code
= Rs. 800 * 34200 = Rs.
2536000
Total cost of developing CAD software systemn would be
Rs. 2536000
(estimated).
Similarly the total effort in person-month for developing CAD system
would be
Total effort = Total lines of code 34200 lines of code (LOC)
Lines of code/person-month 600 LOClperson-month
= 57 person-month
So total effort of developing CAD software system
would be 57 person-month.
3.3.4.2 An Example of Function-Point Based Technique
Let us now find the effort & cost for the same software
system CAD using
Function-Point approach. Now in the Function-Point approach, instead of
decomposing the overall functioning of CAD system into groups and estimating LOC
for each, the Function Point calculation is done by using
various parameters of CAD
system. The system specification will be the.samne as we done in last topic and then
based upon the system specification the project planner estimates the
inputs,
number of outputs, number of inquiries, number of files and number of external
interfaces for the CAD system as shown in table 3.4. The weightage factor for each
parameter of CAD system is assumed to be average.
Software Estimated Function Point
Parameters Count Weight Count
Number of inputs 24 4 96
Number of outputs 16 5 80
Number of inquiries 24 5 120
Number of files 5 10 50
Number of interfaces 2 7 14
Total count 360
Table 3.4 : Software Parameter Count
Now the complexity adjustment value according to the questions discussed in
topic 2.3 (Function oriented metrics) is calculated as shown in table 3.4.
 ISHAN'S Software Engineering
Complexity Adjustment Value
Sr. No. Factor
1. DataCommunication required
2. Distributed pro ssing
4
3. Reusability of code designed
5
4. Internal processing complexity
4
5. Performance is critical
6. Online updation of master files
4
7. Back up method required
4
8. Application changeable
9. System run in existing environment
4
10. Input, output be complex
3
11. Installation in design
4
12. Multiple Installations supported
4
13. Online data entry
5
14. Input transaction
Total Complexity Adjustment Factor 49

Fig. 3.5 : Calculating Complexity Adjustment Factor.

Finally the estimated value of FP for the project will be
FP = Total count * [0.65 + 0.01 * complexity Adjustment Factor]
= 360 * [0.65 + 0.01 * 49]
=360 * [0.65 + 0.49]
=360 *[1.14]
=410410.40
Now using the data collected for effort or cost occurring on project, various
metrics can be obtained. It has been seen that for the software of this type average
productivity of organization is 6.5 FP/Person month and if labour rate be taken Rs. 4
lac per month then cost per FP is approximately Rs. 61000. Then based on these
estimates the total cost of developing software project can be calculated as.
So for above discussed CAD system the estimated cost of development will be -
Total cost = Cost per FP *Total FP
= Rs. 61000 * 410
= Rs 2501000
Total cost of developing CAD system would be Rs. 2501000 (estimated).
 SoftwarePlanning 67

Similarlythe total effort in person-month for developing CAD system would be-
Total Effort = 63x07
s 63 person-month.
So total effort of developing CAD software system would be approximately b3
person-month.

4 PROJECT ESTIMATION TECHNIQUE

Software development estimation is process of predicting the most realistic use
af effort, size, cost, duration require to developer maintain software. These
parameters are used by project manager to deal with customer about the project
development cost and planning the resources schedule for project development.
Eollowing thre techniques are used for estimating project parameter.
Empirical estimation :This technique is based on making a guess of project
parameter using the part working experience. These type of techniques are based on
the common and experience project manager expert judgment.
Heuristic Technique : In this technique the project parameters are estimated
using some mathematical expressiÍn eg. cocomo models.
Analytical Estimation technique : These type of technique are based on
concept of making assumption. Analytical estimation technique calculate the various
project parameters using certain basis assumption regarding the project. So the
analytical technique have the scientific basis, One of the example of analytical
estimation technique is Halstead's Software Science.
3.4.1 COCOMO-A Cost Estimating Model
COCOMO (Constructive Cost Estimation Model) : COCOM0 Model uses
the Heuristic technique. It was proposed by Boehm in 1981. It is an algorithmic cost
estimation technique and uses bottom-up approach. Boehm in this model not only
consider the characteristics of the product but also those of the development team
and development environment. According to Boehm, software cost estimation should
be done through three stages
Basic C0COMO
Intermediate COCOMO
Complete COCOMO
According to Boehm software development projects can be classified into three
categories based on their complexity organic, semidetached 'and embedded. We can
call these categories as application, utility and system programs respectively.
Normally, simple data processing programs dre considered to be applications.
68 ISHAN'S Software Engineering

Compilers, linkers, DBMS are utility programs. Operating system and real-time
with the
$ystem programs are System programs, System programs drectly interacts
Brooks states
hardware and involve timing constraints and concurrent processing.
apPplication program%
that utility programs are three times as difficult as to write utility
difhcult to wite as
ahd system programs are roughly three times as
programs.
Boehm's definition of organic. semidetached and embedded programs are as
follow
Organic:If the project being developed is a well understood application. The
SiZe of the development team is small and the team members are less experienced or
experienced in the developing similar type of projects.
Semidetached : If the team is a mixture of experienced and non-experienced
peoples. The members have experience but unfamiliar with the aspect of the system
being developed. Semidetached falls between organic &embedded categories.
Embedded : Projects are considered to be of embedded type if organization has
little experience and have very tight constraints from the hardware, software and
personal and also the project require hardware interaction.
Boehm provide different expressions to predict the effort and development time
from the size estimation. This model also consider the loss in productivity due to
some lost of time from holidays, weekly offs, coffee breaks etc. The unit for
measuring effort isconsidered in PM (Person-Month).
Now we will discuss the three categories of COCOMO model proposed by
Boehm.

3.4.1.1 Basic COCOMO Model

This is the most common approach for estimating effort. The single variable
approach in algorithmic cost model is the basic for COCOMO model. The single
variable used is the project size. The metric used for size can be either LOC (Line
of Code) or I (Function point). This model gives the approximate estimation of
project parameters. The basic COCOMO estimation model is given by the following
equations :
E=a* (size) PM
Or E=a* (KLOC) PM
where E is the Effort estimated
a, b are the constant for each category of software and the development time is
calculated using the following formula
Tdey = C *(E)d months
SoftwarePlanning 69

where Tey.= estimated time to develop the software

dare the constants for each category of
software
The effort estimation is expressed in term of person-Month (PM). Figure 3.2
hows the number of persons required or working on the project at different time
during development.

of
No.
Persons

Time
Fig. 3.1 : Person-Month Curve
The effort in PM (Person-Month) is denoted by the area under the
curve (Figure 3.1). person-month
The value of constants a, b, c, d used in equation is different for different
categories of products. The value of the constants are derived by examining the
historical data collected from a large number of actual projects. The value of the
constants is shown in following tables.
For development Effort
b
Organic 2.4 1.05 E=a* (KDLOC) PM
Semidetached 3.0 1.12
Embedded 3.6 1.10
Table. 3.6
For development time

Organic 2.4 1.05 Tdey =C * (E)d months

Semidetached 3.0 1.12
Embedded 3.6 1.10
Table. 3.7
70
(SHANG oftwareEnggreate
Using the value of the constanta according to the category of
easily calçulate the value of estimated development effort proj
andect,
development time for various types of projects.
If we plot the estimated effort for different product size, we observe
eatimate
required 18 rapidly increasing with the product size. Figure 3.2 shows
thethat ellon
effort estimated against size of product for various categories of project. graph
Semidetached

Bmbeded
ded

Efforts
Estimated
E

Organic

Size

Fig. 3.2: Effort Vs Size

Now if we observe the development time against the size of the
size of product increases, time to develop the product also increases.
product; when
development time is roughly the same for all types of products. Figure 3.3 shows the
However., The
relationship between development time against size.
Embedded

Development
Time
Semidetached

Organic

Size
Fig. 3.3 : Development Time Vs Size
software Planning 71

From the graph, it can be easily find out that larger the product, larger will be
the development time. But some activities can be performed simultaneously called
parallel activities, reduce some time of the development. The estimated values for
effort and development time are the nominal values. By nominal, we means that if
project development time is reduced than this nominal time, than effort and cost will
be increased from nominal. Similarly if project completes in longer time that the
nominal time, then there is almost no decrease in the cost of the project from
nominal cost.

24.1.2 Intermediate COCOMO Model

It is observed that the estimation based on single factors such as size 1s not
much accurate. Hence another approach is used which uses number of factors for
estimation. This model is explained previously in Algorithmic cost model section.
This model find the initial estimates using the basic COCOMO model. Then
Adjustment factor is calculated using number of factors (these factors are multiplied
together to find the Adjustnent factor). This adjustment factor is then multiplied to
initial effort calculated to give the final estimated effort. The cost factors can be
classified into following items :
Product : It includes the complexity of product, reliability requirement of
the product etc.
Computer : It includes the execution speed required, storage space
required etc.
Personnel : It include factors such as experience level of personnel,
programming capability, analysis capability etc.
Development Environment : The factors are such as development
facility, software tools used etc.

3.4.1.3 Complete COCOMO Model

The main problem with the previous models were that they consider a software
as a single homogeneous entity. Most of large systems are made up of several
Smaller subsystems. These subsystems may have different characteristics. For
example some subsystems may be of organic type, some semidetached and some may
be of embedded type. These subsystems may have different complexities and the
reliability requirements. This model says that rather than calculating effort for a
whole software product, it is beneficial to find estimation for individual subsystems.
The estimation is calculated for each sub system separately. Let us consider any
72
ISHAN'S Software Engineering
system being developed in an organization. This system have following
subsystems such as : dif erent
Interface part
Communication component
Database handling omponent
The interface part can be considered as simple organic component, bus
communication part is considered as embedded software. The database part is
semidetached. The cost of three components is calculated separately and then
summed-up to give overall cost of the system.
3.4.2 Halstead 's Software Science
Halstead complexity metrics were developed by lave Maurice Halstead as mean
of determining a quantitative measure of complexity directly from operators and
operand in the module to measures aprogram modules complexity directly from
source code. They are strong indicators of code complexity. Halstead science is an
estimation technique to find out size, item and effort of a software number of
operator and operands.
Halstead use the some of parameters of the project like operator and operand to
estimate the following characteristics of project.
1. Overall program length
2. Vocabulary size
3. Program volume
4. Difficulty level
5. Program level
6. Effort to implement (E)
7. Estimated program length
8. Potential volume
9. Estimated program level
10. Effort
11. Time to implement (T)
Let usconsider the following notations
n, =Number of unique operators used in program
SoftwarePlanning 73

n, =Number of unique operands used in program

N.=Total number of operator used in program
N,=Total number of operands used in program
2. Recognizing operator and operands : Some of guidelines regarding
operatorsand operands are given below
1 Arithmetic, logic, assignment operator are consider as
operators
9. ()isconsiders asoperator
3. {
is consider as single operator
4. Go toconsider as single operator
5. 1 (Terminator) is consider as operator
6 Complete block of if -..-else---end if or while-. do is counted as single
operators.
7 A function name in function call statement is consider as operator.
8. The parameter transferred in function call statements are counted in
operands.
9 Subroutine declarations and variable declarations consist of operands.

3.4.3.1 Program Length (N)

It is sum of the total number of operators and operands in the program
N=N, +N,
3.4.3.2 Vocabulary Size (n)
The vocabulary size (n) is the sum of number of unique operators and
operands
n = n tny

3.4.3.3 Program volume (V)

The program volume () is information contents of the program, measured
in mathematical bits. it is calculated as program length times the 2 base logarithm
ofvocabulary size (r)
V=N* log 2(n)
 ISHAN'S Software Engineering

74 Halstead's volume() describe the size of theimplementation of an algorithm

The computation of Vis based on the number of operations performed and operands

handles in the algorithm.

3.4.3.4 Difficult Level (D)
proportional to the unique operators
program is in
The difficult level (d) of the
the program
Dis also proportional to ratio between the total number of operands and

number of unique operands. is more

used many times in the program, it prone to errors
i.e. if same operand
D= (4/n, )* (N, Ing)
3.4.3.5 Program Level (L)
error pronenesS of the program m
The program level (L) is the inverse of the
abstraction a language provide f
level of program define the amount of
programming a particular program
L=/D

3.4.3.6 Efforts Implement (E)

The effort to implement (E) or understand a program is proportional to volume
and to the difficult level of the program
E =V* D

3.4.3.7 Estimated Program Length (N)

According to Halstead, The first hypothesis of software science is that the length
of a well structured program structured program is a function only of the number of
unique operator and operands
The estimated length is denoted by N^
N +n, log,"2

3.4.3.8 PotentialVolume
Amongst all the program, the one that has minimal size is said to have the
potential volume V*, The implementation of algorithm for minimal size would
SoftwarePlanning 75

require
more than invoking he procedure and supplying operands for inputs and
outputparameters

V* = (2+ n, *) log (2+ng)

3.4.3.9Estimated Program Level
Halsteadoffered an alternate formula that estimates the program level.
L^ =
2na/ ,N, or L^ = 2n,
D =/
3.4.3.10Effort
The effort required to implement aprogram increase as the size of the program
increase,

E =
L
It takes more effort to implement a program at low level than the higher level.

34.3.11Time to Implement
Bfort uses elementary discriminations its unit of measure, the programming
time would be
T=ElB
Bis normallyset to18 since this seemed togive best result inHalstead earlier
experiment.

SUMMARY

The objective of software project planning is to provide a frame work that

enables the manager to make reasonable estimate of resource, cost and
schedule.
Aproject manager is a professional in field of project management, Project
managers can have the responsibility of planning execution and closing of
any project.