CH3: SOFTWARE PROJECT MANAGEMENT

In past several projects have failure not for want of competent technical
professionals, neither for lack of resources, but due to the use of faulty project
management practices. It is important to carefully

The main goal of software project management is to enable a group of developers

to work effectively towards the successful completion of a project.

Software Project

A Software Project is the complete procedure of software development from

requirement gathering to testing and maintenance, carried out according to the
execution methodologies, in a specified period of time to achieve intended
software product.

Software Project Management Complexities

Project Management Complexities refer to the various difficulties to manage a

software project. It recognizes in many different ways. The main goal of software
project management is to enable a group of developers to work effectively towards
the successful completion of a project in a given time. But software project
management is a very difficult task. Earlier many projects have failed due to faulty
project management practices. Management of software projects is much more
complex than management of many other types of projects.
Types of Complexity

Time Management Complexity: Complexities to estimate the duration of the

project. It also includes the complexities to make the schedule for different
activities and timely completion of the project.

Cost Management Complexity: Estimating the total cost of the project is a very
difficult task and another thing is to keep an eye that the project does not overrun
the budget.

Quality Management Complexity: The quality of the project must satisfy the
customer requirements. It must assure that the requirements of the customer are
fulfilled.

Risk Management Complexity: Risks are the unanticipated things that may occur
during any phases of the project. Various difficulties may occur to identify these
risks and make amendment plans to reduce the effects of these risks.

Human Resources Management Complexity: It includes all the difficulties

regarding organizing, managing and leading the project team.

Communication Management Complexity: All the members must interact with

all the other members and there must be a good communication with the customer.

Procurement Management Complexity: Projects need many services from third

party to complete the task. These may increase the complexity of the project to
acquire the services.

Integration Management Complexity: The difficulties regarding to coordinate

processes and develop a proper project plan. Many changes may occur during the
project development and it may hamper the project completion, which increases
the complexity.

Main factors in Software project management complexity

Invisibility: Until the development of a software project is complete, Software

remains invisible. Anything that is invisible is difficult to manage and control.
Software project manager cannot view the progress of the project due to the
invisibility of the software until it is completely developed. The project manager
can monitor the modules of the software that have been completed by the
development team and the documents that have been prepared, which are a rough
indicator of the progress achieved. Thus the invisibility causes a major problem to
the complexity of managing a software project.

Changeability: Requirements of a software product are undergone various

changes. Most of these change requirements come from the customer during the
software development. Sometimes these change requests resulted in redo some
work, which may cause various risks and increases the expenses. Thus frequent
changes to the requirements play a major role to make software project
management complexity.

Interaction: Even moderate-sized software has millions of parts (functions) that

interact with each other in many ways such as data coupling, serial and concurrent
runs, state transitions, control dependency, file sharing, etc. Due to the inherent
complexity of the functioning of a software product in terms of the basic parts
making up the software, many types of risks are associated with its development.
This makes managing software projects much more difficult as compared to many
other kinds of project.

Uniqueness: Every software project is usually associated with many unique

features or situations. This makes every software product much different from the
other software projects. This is unlike the projects in other domains such as
building construction, bridge construction, etc. where the projects are more
predictable. Due to this uniqueness of the software projects, during the software
development, a project manager faces many unknown problems that are quite
dissimilar to other software projects that he had encountered in the past. As a
result, a software project manager has to confront many unanticipated issues in
almost every project that he manages.

Exactness of the Solution: A small error can create a huge problem in a software
project. The solution must be exact according to its design. The parameters of a
function call in a program are required to be correct with the function definition.
This requirement of exact conformity of the parameters of a function introduces
additional risks and increases the complexity of managing software projects.
Team-oriented and Intellect-intensive work: Software development projects are
team-oriented and intellect-intensive work. Software cannot be developed without
the interaction between developers. In a software development project, the life
cycle activities not only intellect-intensive, but each member has to typically
interact, review the work done by other members and interface with several other
team members creates various complexity to manage software projects.

Huge task regarding Estimation: One of the most important aspects of software
project management is Estimation. During project planning, a project manager has
to estimate the cost of the project, probable duration to complete the project and
how much effort needed to complete the project based on size estimation. This
estimation is a very complex task, which increases the complexity of software
project management.

Responsibilities of a Software Project Manager

A software project manager is the most important person inside a team who takes
the overall responsibilities to manage the software projects and play an important
role in the successful completion of the projects. A project manager has to face
many difficult situations to accomplish these works. In fact, the job responsibilities
of a project manager range from invisible activities like building up team morale to
highly visible customer presentations. Most of the managers take responsibility for
writing the project proposal, project cost estimation, scheduling, project staffing,
software process tailoring, project monitoring and control, software configuration
management, risk management, managerial report writing and presentation and
interfacing with clients. The task of a project manager is classified into two major
types:

 Project planning
 Project monitoring and control
Project planning

Project planning is undertaken immediately after the feasibility study phase and
before the starting of the requirement analysis and specification phase. Once a
project has been found to be feasible, Software project managers started project
planning. Project planning is completed before any development phase starts.
Project planning involves estimating several characteristics of a project and
then plan the project activities based on these estimations. Project planning is
done with most care and attention. A wrong estimation can result in schedule
slippage. Schedule delay can cause customer dissatisfaction, which may lead to
a project failure. For effective project planning, in addition to a very good
knowledge of various estimation techniques, past experience is also very
important.

Project monitoring and control

Project monitoring and control activities are undertaken once the development
activities start. The main focus of project monitoring and control activities is to
ensure that the software development proceeds as per plan. This includes
checking whether the project is going on as per plan or not if any problem
created then the project manager must take necessary action to solve the
problem.

Skills Necessary for Managing Software Projects

Three skills that are most critical to successful project management are the
following

 Knowledge of project management techniques

 Decision taking capabilities
 Previous experience in managing similar projects

Other additional skills includes Communication, Leadership, Team management,

Negotiation, Personal organization, Risk management
PROJECT PLANNING

Project planning is undertaken and completed before any development activity

starts. During project planning, the project manager performs the following
activities.
Estimation: The following project attributes are estimated.
• Cost: How much is it going to cost to develop the software product?
• Duration: How long is it going to take to develop the product?
• Effort: How much effort would be necessary to develop the product?
The effectiveness of all later planning activities such as scheduling and
Staffing is dependent on the accuracy with which these three estimations have been
made.
Scheduling: After the entire necessary project parameters have been estimated, the
schedules for manpower and other resources are developed.
Staffing: Staff organisation and staffing plans are made.
Risk management: This includes risk identification, analysis, and abatement
planning.
Miscellaneous plans: This includes making several other plans such as quality
assurance plan, and configuration management plan, etc.

Size is the most fundamental parameter based on which all other estimations and
project plans is made. Based on the size estimation, the effort required to complete
a project and the duration over which the development is to be carried out are
estimated. Based on the effort estimation, the cost of the project is computed. The
estimated cost forms the basis on which price negotiations with the customer is
carried out. Other planning activities such as staffing, scheduling etc. are
undertaken based on the effort and duration estimates made.
Figure : Precedence ordering among planning activities
Planning a project over a number of stages protects managers from making big
commitments at the start of the project. This technique of staggered planning is
known as sliding window planning.
In the sliding window planning technique, starting with an initial plan, the project
is planned more accurately over a number of stages.

The SPMP Document of Project Planning

Once project planning is complete, project managers document their plans in a
software project management plan (SPMP) document. Listed below are the
different items that the SPMP document should discuss. This list can be used as a
possible organisation of the SPMP document.
Organisation of the software project management plan
(SPMP) document
1. Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraints
2. Project estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates
3. Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation
4. Project resources
(a) People
(b) Hardware and Software
(c) Special Resources
5. Staff organisation
(a) Team Structure
(b) Management Reporting
6. Risk management plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
7. Project tracking and control plan
(a) Metrics to be tracked
(b) Tracking plan
(c) Control plan
8. Miscellaneous plans
(a) Process Tailoring
(b) Quality Assurance Plan
(c) Configuration Management Plan
(d) Validation and Verification
(e) System Testing Plan
(f ) Delivery, Installation, and Maintenance Plan

METRICS FOR PROJECT SIZE ESTIMATION

The project size is a measure of the problem complexity in terms of the effort and
time required to develop the product. Currently, two metrics are popularly being
used to measure size—lines of code (LOC) and function point (FP). Each of these
metrics has its own advantages and disadvantages.

1. Lines of Code (LOC)

LOC is possibly the simplest among all metrics available to measure project size.
Consequently, this metric is extremely popular. This metric measures the size of a
project by counting the number of source instructions in the developed program.
Obviously, while counting the number of source instructions, comment lines, and
header lines are ignored.
In systematic guessing of LOC project manager divides the problem into modules
and each module into sub-modules and so on, until the LOC of the leaf-level
modules are small enough to be predicted. By adding the estimates for all leaf level
modules together, project managers arrive at the total size estimation. In spite of its
conceptual simplicity, LOC metric has several shortcomings when used to measure
problem size.
A good problem size measure should consider the total effort needed to carry out
various life cycle activities (i.e. specification, design, code, test, etc.) and not just
the coding effort. LOC, however, focuses on the coding activity alone—it merely
computes the number of source lines in the final program.

The implicit assumption made by the LOC metric is that the overall product
development effort is solely determined from the coding effort alone is flawed.
Even when the design or testing issues are very complex, the code size might be
small and vice versa. Thus, the design and testing efforts can be grossly
disproportional to the coding effort. Code size, therefore, is obviously an improper
indicator of the problem size.
 LOC count depends on the choice of specific instructions
 LOC measure correlates poorly with the quality and efficiency of the code
 LOC metric penalises use of higher-level programming languages and code
reuse
 LOC metric measures the lexical complexity of a program and does not address
the more important issues of logical and structural complexities
 It is very difficult to accurately estimate LOC of the final program from
problem specification

2. Function Point (FP) Metric

The size of a software product is directly dependent on the number of different
high-level functions or features it supports. This assumption is reasonable, since
each feature would take additional effort to implement.
Function point metric is based on the idea that a software product supporting
many features would certainly be of larger size than a product with less number
of features.
Function point metric has several advantages over LOC metric. One of the
important advantages of the function point metric over the LOC metric is that it
can easily be computed from the problem specification itself. Using the LOC
metric, on the other hand, the size can accurately be determined only after the
product has fully been developed.
Though each feature takes some effort to develop, different features may take
very different amounts of efforts to develop. For example, in banking software, a
function to display a help message may be much easier to develop compared to
say the function that carries out the actual banking transactions. This has been
considered by the function point metric by counting the number of input and
output data items and the number of files accessed by the function.

Figure: System function as a mapping of input data to output

data
Albrecht postulated that in addition to the number of basic functions that
software performs, size also depends on the number of files and the number of
interfaces that are associated with the software. Here, interfaces refer to the
different mechanisms for data transfer with external systems including the
interfaces with the user, interfaces with external computers, etc..

Function point (FP) metric computation

The size of a software product (in units of function points or FPs) is computed
using different characteristics of the product identified in its requirements
specification. It is computed using the following three steps:
Step 1: Compute the unadjusted function point (UFP) using a heuristic
expression.
Step 2: Refine UFP to reflect the actual complexities of the different parameters
used in UFP computation.
Step 3: Compute FP by further refining UFP to account for the specific
characteristics of the project that can influence the entire development
effort.

Step 1: UFP computation

The unadjusted function points (UFP) is computed as the weighted sum of five
characteristics of a product as shown in the following expression. The weights
associated with the five characteristics were determined empirically by Albrecht
through data gathered from many projects.
UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of
inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10
where,
Number of inputs: Each data item input by the user is counted.
Number of outputs: The outputs considered include reports printed, screen
outputs, error messages produced, etc.
Number of inquiries: An inquiry is a user command (without any data input)
and only requires some actions to be performed by the system.
Number of files: The files referred to here are logical files. A logical file
represents a group of logically related data. Logical files include data structures
as well as physical files.
Number of interfaces: Here the interfaces denote the different mechanisms that
are used to exchange information with other systems. Examples of such
interfaces are data files on tapes, disks, communication links with other systems,
etc
Step 2: Refine parameters
UFP computed at the end of step 1 is a gross indicator of the problem size. This
UFP needs to be refined. This is possible, since each parameter (input, output,
etc.) has been implicitly assumed to be of average complexity.
However, this is rarely true. For example, some input values may be extremely
complex, some very simple, etc. In order to take this issue into account, UFP is
refined by taking into account the complexities of the parameters of UFP
computation. The complexity of each parameter is graded into three broad
categories—simple, average, or complex. The weights for the different
parameters are determined based on the numerical values shown in Table.
Step 3: Refine UFP based on complexity of the overall project
In the final step, several factors that can impact the overall project size are
considered to refine the UFP computed in step 2. Examples of such project
parameters that can influence the project sizes include high transaction rates,
response time requirements, scope for reuse, etc. Albrecht identified 14
parameters that can influence the development effort. The list of these
parameters has been shown in Table below. Each of these 14 parameters is
assigned a value from 0 (not present or no influence) to 6 (strong influence). The
resulting numbers are summed, yielding the total degree of influence (DI). A
technical complexity factor (TCF) for the project is computed and the TCF is
multiplied with UFP to yield FP. The TCF expresses the overall impact of the
corresponding project parameters on the development effort. TCF is computed
as (0.65+0.01*DI). As DI can vary from 0 to 84, TCF can vary from 0.65 to
1.49. Finally, FP is given as the product of UFP and TCF. That is,
FP=UFP*TCF.
Example

Determine the function point measure of the size of the following supermarket
software. A supermarket needs to develop the following software to encourage
regular customers. For this, the customer needs to supply his/her residence
address, telephone number, and the driving license number. Each customer who
registers for this scheme is assigned a unique customer number (CN) by the
computer. Based on the generated CN, a clerk manually prepares a customer
identity card after getting the market manager’s signature on it. A customer can
present his customer identity card to the check out staff when he makes any
purchase. In this case, the value of his purchase is credited against his CN. At
the end of each year, the supermarket intends to award surprise gifts to 10
customers who make the highest total purchase over the year. Also, it intends to
award a 22 carat gold coin to every customer whose purchase exceeded Rs.
10,000. The entries against the CN are reset on the last day of every year after
the prize winners’ lists are generated. Assume that various project characteristics
determining the complexity of software development to be average.
Answer:

Step 1:
From an examination of the problem description, we find that there are two
inputs, three outputs, two files, and no interfaces. Two files would be required,
one for storing the customer details and another for storing the daily purchase
records. Now, using equation 3.1, we get:

UFP = 2 × 4 + 3 × 5 + 1 × 4 + 10 × 2 + 0 × 10 = 47

Step 2:
All the parameters are of moderate complexity, except the output parameter of
customer registration, in which the only output is the CN value. Consequently,
the complexity of the output parameter of the customer registration function can
be categorized as simple. By consulting Table 3.1, we find that the value for
simple output is given to be 4. The UFP can be refined as follows:

UFP = 3 × 4 + 2 × 5 + 1 × 4 + 10 × 2 + 0 × 10 = 46
Therefore, the UFP will be 46.

Step 3:
Since the complexity adjustment factors have average values, therefore the total
degrees of influence would be: DI = 14 × 4 = 56

TCF = 0.65 + 0.01 + 56 = 1.21

Therefore, the adjusted FP = 46*1.21 = 55.66

Feature point metric shortcomings: A major shortcoming of the function point

measure is that it does not take into account the algorithmic complexity of a
function. That is, the function point metric implicitly assumes that the effort
required to design and develop any two different functionalities of the system is
the same. But, we know that this is highly unlikely to be true. The effort
required to develop any two functionalities may vary widely. For example, in a
library automation software, the create-member feature would be much simpler
compared to the loan-from-remote-library feature. FP only considers the number
of functions that the system supports, without distinguishing the difficulty levels
of developing the various functionalities. To overcome this problem, an
extension to the function point metric called feature point metric has been
proposed.
Feature point metric incorporates algorithm complexity as an extra parameter.
This parameter ensures that the computed size using the feature point metric
reflects the fact that higher the complexity of a function, the greater the effort
required to develop it—therefore, it should have larger size compared to a
simpler function.

PROJECT ESTIMATION TECHNIQUES

Estimation of various project parameters is an important project planning

activity. The different parameters of a project that need to be estimated include
—project size, effort required to complete the project, project duration, and cost.
Accurate estimation of these parameters is important, since these not only help
in quoting an appropriate project cost to the customer, but also form the basis for
resource planning and scheduling. A large number of estimation techniques have
been proposed by researchers. These can broadly be classified into three main
categories:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques

Empirical estimation techniques are essentially based on making an educated guess

of the project parameters. While using this technique, prior experience with
development of similar products is helpful. Although empirical estimation
techniques are based on common sense and subjective decisions, over the years,
the different activities involved in estimation have been formalised to a large
extent.

Heuristic techniques assume that the relationships that exist among the different
project parameters can be satisfactorily modelled using suitable mathematical
expressions. Once the basic (independent) parameters are known, the other
(dependent) parameters can be easily determined by substituting the values of the
independent parameters in the corresponding mathematical expression. Different
heuristic estimation models can be divided into the following two broad categories
—single variable and multivariable models.

Analytical Estimation Techniques

Analytical estimation techniques derive the required results starting with certain
basic assumptions regarding a project. Unlike empirical and heuristic techniques,
analytical techniques do have certain scientific basis. As an example of an
analytical technique, we shall discuss the Halstead’s software science Halstead’s
software science is especially useful for estimating software maintenance efforts.
In fact, it outperforms both empirical and heuristic techniques as far as estimating
software maintenance efforts is concerned.

1. EMPIRICAL ESTIMATION TECHNIQUES

Empirical estimation techniques are easy to use and give reasonably accurate
estimates. Two popular empirical estimation techniques are—Expert judgement
and Delphi estimation techniques.

Expert Judgement

Expert judgement is a widely used size estimation technique. In this technique, an

expert makes an educated guess about the problem size after analysing the problem
thoroughly. Usually, the expert estimates the cost of the different components (i.e.
modules or subsystems) that would make up the system and then combines the
estimates for the individual modules to arrive at the overall estimate. However, this
technique suffers from several shortcomings. The outcome of the expert judgement
technique is subject to human errors and individual bias. Also, it is possible that an
expert may overlook some factors inadvertently. Further, an expert making an
estimate may not have relevant experience and knowledge of all aspects of a
project. For example, he may be conversant with the database and user interface
parts, but may not be very knowledgeable about the computer communication part.
Due to these factors, the size estimation arrived at by the judgement of a single
expert may be far from being accurate.
A more refined form of expert judgement is the estimation made by a group of
experts. Chances of errors arising out of issues such as individual oversight, lack of
familiarity with a particular aspect of a project, personal bias, and the desire to win
contract through overly optimistic estimates is minimised when the estimation is
done by a group of experts. However, the estimate made by a group of experts may
still exhibit bias. For example, on certain issues the entire group of experts may be
biased due to reasons such as those arising out of political or social considerations.
Another important shortcoming of the expert judgement technique is that the
decision made by a group may be dominated by overly assertive members.
2. Delphi Cost Estimation

Delphi cost estimation technique tries to overcome some of the shortcomings of

the expert judgement approach. Delphi estimation is carried out by a team
comprising a group of experts and a co-ordinator. In this approach, the co-
ordinator provides each estimator with a copy of the software requirements
specification (SRS) document and a form for recording his cost estimate.
Estimators complete their individual estimates anonymously and submit them to
the co-ordinator. In their estimates, the estimators mention any unusual
characteristic of the product which has influence d their estimations. The co-
ordinator prepares the summary of the responses of all the estimators, and also
includes any unusual rationale noted by any of the estimators. The prepared
summary information is distributed to the estimators. Based on this summary, the
estimators re-estimate. This process is iterated for several rounds. However, no
discussions among the estimators are allowed during the entire estimation process.
The purpose behind this restriction is that if any discussion is allowed among the
estimators, then many estimators may easily get influenced by the rationale of an
estimator who may be more experienced or senior. After the completion of several
iterations of estimations, the co-ordinator takes the responsibility of compiling the
results and preparing the final estimate. The Delphi estimation, though consumes
more time and effort, overcomes an important shortcoming of the expert
judgement technique in that the results cannot unjustly be influenced by overly
assertive and senior members.

Heuristic Techniques

Heuristic estimation models can be divided into two broad categories—single

variable and multivariable models.

Single variable estimation models assume that various project characteristic can be
predicted based on a single previously estimated basic (independent) characteristic
of the software such as its size. A single variable estimation model assumes that
the relationship between a parameter to be estimated and the corresponding
independent parameter can be characterised by an expression of the following
form:
Estimated Parameter = c1* ed1
In the above expression, e represents a characteristic of the software that has
already been estimated (independent variable). Estimated Parameter is the
dependent parameter (to be estimated). The dependent parameter to be estimated
could be effort, project duration, staff size, etc., c1 and d1 are constants. The
values of the constants c1 and d1 are usually determined using data collected from
past projects (historical data). The COCOMO model discussed later is an example
of a single variable cost estimation model.

A multivariable cost estimation model assumes that a parameter can be predicted

based on the values of more than one independent parameter. It takes the following
form:
Estimated Resource = c1 * p1d1 + c2 * p2d2 + ...

Where, p1, p2, ... are the basic (independent) characteristics of the software already
estimated, and c1, c2, d1, d2, .... are constants. Multivariable estimation models are
expected to give more accurate estimates compared to the single variable models,
since a project parameter is typically influenced by several independent
parameters. The independent parameters influence the dependent parameter to
different extents. This is modelled by the different sets of constants c1, d1 , c2 ,
d2 , .... Values of these constants are usually determined from an analysis of
historical data. The intermediate COCOMO model discussed later can be
considered to be an example of a multivariable estimation model.