Software Project

Management
Specific Instructional Objectives
At the end of this lesson the student would be able to:

 Identify the job responsibilities of a software project manager.

 Identify the necessary skills required in order to perform software
project management.
 Identify the essential activities of project planning.
 Determine the different project related estimates performed by a project
manager and suitably order those estimates.
 Explain what is meant by Sliding Window Planning.
 Explain what is Software Project Management Plan (SPMP).
 Identify and explain two metrics for software project size estimation.
 Identify the shortcomings of function point (FP) metric.
 Explain the necessity of feature point metric in the context of project
size estimation.
 Identify the types of project-parameter estimation technique.
 Identify why careful planning of staffing pattern for a project is so
important.

 Determine numerically how change of project duration affects the

overall effort and cost.

 Identify five necessary tasks taken by a project manager in order to

perform project scheduling.

 Explain the usefulness of work breakdown structure.

 Explain activity networks and critical path method.

 Develop the Gantt chart for a project.

 Develop PERT chart for a project.

 Explain the necessity of a suitable organization structure.

 Differentiate between functional format and project format in the

context of organization structure.

 Explain why the functional format is not suitable for small organizations
handling just one or two projects.
 Identify the important types of team structures of an organization.
 Explain what is meant by egoless programming technique.
 Identify the characteristics of a good software engineer.
 Identify the main categories of risks which can affect a software
project.
 Explain how to assess a project risk.
 Identify the main strategies to plan for risk containment.
 Explain what risk leverage is.
 Explain how to handle the risk of schedule slippage.
 Explain what is meant by configuration of a software product.
 Differentiate among release, version and revision of a software product.
 Explain the necessity of software configuration management.
 Identify the principal activities of software configuration management.
 Identify the activities carried out during configuration identification.
 Identify the activities carried out during configuration control.
 Identify the popular configuration management tools.
The main goal of software project management is to
enable a group of software engineers to work
efficiently towards successful completion of a project.

The Main Objectives of SPM

► To discuss the responsibilities and some desirable

attributes of software project managers.

► To discuss different issues relevant to project

planning and the latest techniques available for
project planning.
 Responsibility of Software Project Managers
► Writing project proposals.
► Estimating project cost.
► Project scheduling and staffing.
► Software process tailoring.
► Project monitoring and control.
► Software configuration management.
► Risk management.
► Interfacing with clients.
► Managerial report writing and presentations.

The above responsibilities can be broadly classified into project

planning, project monitoring and control activities
 Project Planning
The project planning consists of the following important
activities:

► Effort, cost, resource and project duration estimation.

► Risk identification, analysis and abatement procedures.
► Project scheduling.
► Staff organization and staffing plans
► Miscellaneous plans such as quality assurance plan,
configuration management plan, etc.
► Selection of suitable development process model.
The results of the planning phase is documented in a SPMP
document. The general structure of a SPMP document is as
follows:
1. Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraint
2. Project Estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost and Project Duration Estimates
Contd…
3. Risk Management Plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
4. Schedule
(a) Work breakdown structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation

Contd…
5. Project Resources
(a) People
(b) Hardware and Software
(c) Special Resources
6. Staff Organization
(a) Team Structure
(b) Management Reporting
7. Project Tracking and Control Plan
8. Miscellaneous Plans
(a) Process Tailoring (b) Configuration Management
(c) Quality Assurance (d) Validation and Verification
(e) System Testing (e) Delivery, Installation & Maintenance
 Project Size Estimation Metrics
The size of a program is an indicator of the effort and time
required to develop the program. In other words, the size of a
program indicates the development complexity.
Estimating the problem size is fundamental to estimating the
effort, time and cost of a planned software project.
There are several metrics to measure problem size. Each of
these metrics has its own advantages and disadvantages.
The two important metrics to estimate size are:
• Lines of Code (LOC)
• Function Point (FP)
Estimating SLOC
This metric measures the number of source instructions required to solve a
problem. A SLOC estimate of a software system can be obtained from
experience, the size of previous systems, the size of a competitor’s system,
and breaking down the system into smaller pieces and estimating the SLOC
of each piece. Putnam suggests that for each piece, three distinct estimates
should be made:
LOC as a measure of problem size has several shortcomings:
1. LOC gives a numerical value of problem that varies with
coding style.
2. LOC does not take into consideration the relative complexity
of design, coding, etc.
3. LOC measure correlates poorly with the quality and efficiency
of the code.
4. LOC penalizes the use of high-level programming languages,
code reuse etc.
5. LOC metric measures lexical/textual complexity and does not
address the more important but subtle issues of logical or
structural complexities.
6. It is very difficult to arrive at an accurate LOC estimation from
a problem specification. Therefore, the LOC metric is of little
use to project managers, at the beginning of a project.

Function Point (FP) Metric

 A vehicle to estimate cost and resources required for
software development, enhancements and/or maintenance.
 A tool to quantify performance levels and to monitor
progress made from software process improvement
initiatives.
 A tool to determine the benefit of an application to an
organization by counting functions that specifically match
requirements.
 A tool to size or evaluate purchased application packages.
 A better way to generate effort estimations and duration
estimations from the product is to estimate the functionality
rather than the physical size.
 Function Points are one of the major technique to the major
functionality of the system.
 Function Points were originally introduced by Allan Albrecht
over 20 years ago.

The conceptual idea behind the FP metric is that the size of the
software product is directly dependent on the number and type
of different functions it performs. It computes the size of a
software product using five different characteristics of the
product. The FP of a given software is the weighted sum of
these five items. The weights of these five items have been
derived empirically and validated by observations over many
projects.
• External Inputs (EI)
• External Outputs (EO)
• External Inquiries (EQ)
• Internal Files (IF)
• External Files (EF)

After EI, EO, EF, IF, EQ is weighted, the unadjusted function

point count can be calculated by summing the all individual
counts. After that adjustment factor can be calculated from the
15 cost drivers based on technical and quality requirements.

External Input (EI) : An EI process data or control information

that comes from the outside the application boundary. EI means
where data flows from an actor to the system.
External Output (EO) : An EO is an elementary process that
generates data or control information sent outside the
application’s boundary. EO means data can flow from system to
actor.

External Inquiry (EQ) : An EQ is an elementary process made

up of an input-output combination that results in data

Internal File (IF) : Internal File means originator.

External File (EF) : External File means destination.

Size of a problem in FPs = (Number of inputs) * 4 +

(Number of outputs) * 5 +
(Number of inquiries) * 4 +
(Number of files) * 10 +
(Number of interfaces) * 10
 Table 1: Function Count Weighting Factors

Calculating the Adjusted Function Points

It is important to consider the environment variables to determine
accurately the effort required to program a system. Albrecht
recognized this when developing the FP model and created a list of
fourteen “general system characteristics that are rated on a scale
from 0 to 5 in terms of their likely effect for the system being
counted.” These characteristics are as follows:
1. Data communications
2. Distributed functions
3. Performance
4. Heavily used configuration
5. Transaction rate
6. Online data entry
7. End user efficiency
8. Online update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13. Multiple sites
14. Facilitates change
The ratings given to each of the characteristics above are then
entered into the following formula to get the Value Adjustment Factor
(VAF):

where ci is the value of general system characteristic i, for 0 ≤ ci ≤ 5.

Finally, the UFP and VAF values are multiplied to produce the
adjusted FP (AFP) count:

In practice, the final AFP number of the proposed system is compared

against the AFP count and cost of systems that have been measured
in the past. The more historical data that can be compared the better
the chances of accurately estimating the cost of the proposed software
system.
One of the important advantages of the FP metric is that it can
be used to estimate the size of software directly from the
problem specification.
An important shortcoming of the FP measure is that it does not
take into account the algorithmic complexity of a software.
To overcome this shortcoming, an extension of the FP metric
called Feature Point metric has been proposed.
 LOC v/s FP
 Relationship between lines of code and function points depends upon the
programming language that is used to implement the software and the
quality of the design
 Empirical studies show an approximate relationship between LOC and FP

LOC/FP (Average)
Assembly language 320
COBOL, FORTRAN 128
C language 106
C++ language 64
Visual Basic 32
Smalltalk 22
SQL 12
Graphical languages (icons) 4
 Project Estimation Techniques

During project planning, project managers usually estimate the

following parameters: project size, effort required to develop
the software, project duration and cost. These estimates not
only help in quoting project cost to the customer, but also in
resource planning and scheduling. There are three main
techniques of estimating project parameters:

• Empirical estimation techniques

• Heuristic techniques
• Analytical estimation techniques
Empirical Estimation Techniques
Empirical estimation techniques are based on making an
educated guess of the project parameters. Although empirical
estimation techniques are based on common sense, different
activities involved in estimation have been formalized over the
years. The two most widely used empirical estimation
techniques are

• Expert Judgement
• Delphi Technique

Heuristic Techniques
Heuristic techniques assume that the project parameters can be
modeled using mathematical expression. Various heuristic
estimation techniques can be divided into the following three
classes:
 • Static single variable models
• Static multivariable models
• Dynamic multivariable models

Static single variable estimation provide a means to estimate

different characteristics of a problem using some previously
estimated characteristics of the software product such as its
size. The basic static single variable cost estimation model takes
the form
Resource  c * e 1
d1

Where e is a characteristic of the software which has already

been estimated and the resource to be predicted could be the
effort, project duration, staff size, etc. Constants c1 and d1 can
be determined using the data collected from the past projects.
The basic COCOMO model is an example of a static single
variable cost estimation model.
A static multivariable cost estimation model is of the form

Resource  c1 * e  c2 * e  ...
d1
1
d2
2

Where e1, e2, … are some characteristics of the software

already estimated and c1, c2, d1, d2, … are constants. Static
multivariable estimation models give more accurate estimate
than that provided by static single variable models, since
software cost is usually determined by several factors.
Dynamic multivariable models project resource requirements as
a function of time.

COCOMO – A Heuristic Estimation Technique

COCOMO (COst Constructive estimation MOdel) was proposed
by Boehm [1981]. Boehm postulated that there are essentially
three important classes of software products organic,
semidetached and embedded.
These three product classes correspond to application utility,
and system programs.
Brooks [1975] states that utility programs are three times as
difficult to write as application programs and system programs
are three time as difficult as utility programs. Thus according to
Brooks the relative levels of product complexity for the three
categories of products are in the ratio 1:3:9 for application,
utility and system programs.

The Basic COCOMO Model

The basic COCOMO model provides an approximate estimation
of software costs and is given by the following expressions:

Effort  a1 * (KLOC) a2

Tdev  b1 * (Effort) b2
Where
• KLOC is the estimated kilo lines of code
• a1, a2, b1, b2 are constants for different categories of
software products
• Tdev is the estimated time to develop the software in months
• Effort is the total development effort required to produce the
software product in programmer-months (PMs)

The values of a1, a2, b1, b2 for different categories of products

as given by Boehm [1981] are summarized below.
Estimation of Development Effort
Organic : Effort  2.4 * (KLOC)1.05PM
Semidetach ed : Effort  3.0 * (KLOC)1.12PM
Embedded : Effort  3.6 * (KLOC)1.20PM
Estimation of Development Time

Organic : Tdev  2.5 * (Effort)0.38Months

Semidetach ed : Tdev  2.5 * (Effort)0.35Months
Embedded : Tdev  2.5 * (Effort)0.32Months

Fig. 1 shows a plot of estimated effort versus size for various

product sizes. From Fig. 1, we can observe that the effort is
almost linearly proportional to the size of the software product.
Fig. 2 shows a plot of development time versus product size.
From Fig. 2, we can observe that the development time is
sublinear function of the size of the product. This can be
explained by the fact that for larger products several parallel
activities can be identified which can be carried out
simultaneously by a number of engineers.
Estimated Effort

Embedded

Semidetache
d
Organic

Size

Fig. 1 Effort vs. Size

Normal development time

Embedded

Semidetache
d
Organic

Size

Fig. 2 Development time vs. Size

Example: Assume that the size of an organic software product
has been estimated to be 32,000 lines of source code. Let us
determine the effort required to develop the software product
and the nominal development time.

Effort  2.4 * (32)1.05  91 PM

Nominal Development Time  2.5 * (91)0.38  14 Months

The Intermediate COCOMO Model

The basic COCOMO model assumes that effort and
development time are functions of the product size alone.
However, it is intuitively obvious that a host of other project
parameters besides product size affect the effort and
development time. Therefore, in order to obtain an accurate
estimation of the effort and project duration, the effect of these
parameters must be taken into account.
The intermediate COCOMO model recognizes this fact and
refines the initial estimate obtained by the basic COCOMO
model by using a set of 15 cost drivers. Cost drivers can be
classified as being attributes of the following items:

Product: Inherent complexity of the product, reliability

requirements of the product, etc.
Computer: Execution time, storage requirements, etc.
Personnel: Experience of personnel, etc.
Development Environment: Sophistication of the tools used for
software development.

The Complete COCOMO Model

An important shortcoming of the basic and the intermediate
COCOMO model is that they consider a software product as a
single homogeneous entity.
For example, a distributed Management Information System
(MIS) product for an organization having offices at several
places across the country can have the following
sub-components:

• Database part
• GUI part
• Communication part

Of these, the communication part can be considered as an

embedded software, the database part as a semidetached
software and the GUI as an organic software. The costs of
these three components can be estimated separately and
summed up to give the overall cost of the system.
 Rating
Cost Driver Description Very
Very Low Low Nominal High Extra High
High

Product

RELY Required software reliability 0.75 0.88 1.00 1.15 1.40 -

DATA Database size - 0.94 1.00 1.08 1.16 -
CPLX Product complexity 0.70 0.85 1.00 1.15 1.30 1.65

Computer

TIME Execution time constraint - - 1.00 1.11 1.30 1.66

STOR Main storage constraint - - 1.00 1.06 1.21 1.56
VIRT Virtual machine volatility - 0.87 1.00 1.15 1.30 -
TURN Computer turnaround time - 0.87 1.00 1.07 1.15 -

Personnel

ACAP Analyst capability 1.46 1.19 1.00 0.86 0.71 -

AEXP Applications experience 1.29 1.13 1.00 0.91 0.82 -
PCAP Programmer capability 1.42 1.17 1.00 0.86 0.70 -
VEXP Virtual machine experience 1.21 1.10 1.00 0.90 - -
LEXP Language experience 1.14 1.07 1.00 0.95 - -

Project

MODP Modern programming practices 1.24 1.10 1.00 0.91 0.82 -

TOOL Software Tools 1.24 1.10 1.00 0.91 0.83 -
SCED Development Schedule 1.23 1.08 1.00 1.04 1.10 -
Halstead’s Software Science – An Analytical Technique
Halstead’s software science is an analytical technique to measure the size,
development effort and development cost of a software product. Halstead
used a few primitive program parameters to develop expressions for the
overall program length, the potential minimum volume for an algorithm, the
actual volume, the language level, effort and development time.
For a given program, let:
• n1 be the number of unique operators used in the program,
• n2 be the number of unique operands used in the program,
• N1 be the total number of operators used in the program,
• N2 be the total number of operands used in the program.
With the above parameters, Halstead define the length of a program as the
total usage of all operators and operands in the program.
Thus, length N = N1 + N2.
The program vocabulary is the number of unique operators and operands
used in the program. Thus, the program vocabulary n = n1 + n2
 Operators and Operands for the ANSI C Language
( { { . , -> * + - ~ ! ++ -- / % << >> <> <= >= != == &
^ | && || = *= /= %= += -= <<= >>= &= ^= |= : ? ; CASE
DEFAULT IF ELSE SWITCH WHILE DO FOR GOTO CONTINUE
BREAK RETURN and function name in a function call.

Example 1: In the expression a = &b;

{a, b} are treated as operands and {=, &} as operators

Example 2: The function name in a function definition is not counted as an

operator.
int function-name ( int a, int b)
{
…..
}
For the above example code, the operators are: { }, ( )
Example 3: In the function call statement: function-name (a, b);
function-name and ; are considered as operators and variables a,
b are treated as operands.

Program Volume
The program volume V = N log2 n is the minimum number of bits needed to
encode the program. Therefore, to represent n different identifiers, we need
at least log2n bits (where n is the program vocabulary). However, the volume
V varies with the programming language used.

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most
succinct program in which the program can be coded. The minimum volume
is obtained when the program can be expressed using a single source code
instruction, say a function call like f( ).
Thus, if the algorithm operates on input and output data d1, d2, d3, … ,dn, the
most succinct program is f(d1, d2, d3, … ,dn); for which n1=2, n2=n.
Therefore, V* = (2 + n2) log2 (2 + n2).
This result agrees with the intuitive notion that it takes more effort to
develop a program in assembly language than to develop a program in a high
level language to solve a problem.
The program level L is given by L = V* / V. The L is an attempt to measure
the level of abstraction provided by the programming language. Using this
definition, languages can be ranked into levels that also appear intuitively
correct.

Effort and Time

Effort E = V / L, where E is the number of mental discriminations required to
implement the program and also the effort required to read and understand
the program. Thus, the programming effort E = V2 / V* varies as the square
of the volume.
The programmer’s time T = E / S, where S is the speed of mental
discriminations developed from psychological reasoning due to Stroud and
the recommended value for software is 18.
Length Estimation
Halstead suggests a way to determine the length of a program using the
number of unique operators and operands used in the program. Following is
the equation to estimate the program length in terms of unique operators
and operands:

N = n1 log2 n1 + n2 log2 n2
Experimental evidence gathered from analysis of a large number of programs
suggests that computed and actual lengths match very closely.
Example: Let us consider the following C program:
main ( )
{
int a, b, c, avg;
scanf (“%d %d %d”, &a, &b, &c);
avg = (a + b + c) / 3;
printf (“Average = %d”, avg);
}
The total number of unique operators ( n1 ) are : 12
The total number of unique operands ( n2 ) are : 11

Estimated Length = (12 * log 12 + 11 * log 11)

= (12 * 3.58 + 11 * 3.45)
= (43 + 38)
= 81

Volume = Length * log (23)

= 81 * 4.52
= 366
Staffing Level Estimation

Norden studied the staffing patterns of several R & D projects and found that
for most R & D projects, the staffing pattern can be approximated by the
Rayleigh distribution curve. The Rayleigh curve is represented by the
following equation:

K  t2 
E  2 * t * exp  
2 
td  2 * td 

Where E is the effort required at time t. Thus, E is an indication of the

number of engineers (Staffing level) at any particular time during the
duration of the project. K is the area under the curve, td is the time at which
the curve attains its maximum value.
Effort

td
Time

Rayleigh Curve
Effect of Schedule Change on Cost
By analyzing a large number of army projects, Putnam [1978] found that the
Rayleigh curve can be used to relate the number of delivered lines of code to
the effort and the development time and derived the followed relation:

L  Ck K1/3t d4/3
The various terms of this relation is interpreted as follows:

1. K is the effort expended and L is the size in KLOC.

2. td corresponds to the time of system integration and testing and can be
approximately considered as the time to develop the software.
3. Ck is the state of technology constant and reflects constraints that impede
the progress of the programmer. Its typical values are: Ck=2 for poor
development environment. Ck=8 for good software development
environment. Ck=11 for an excellent environment. The exact value of Ck
can be derived from historical data.
Experience shows that a very rapid build-up of staff correlates with schedule
slippage.
Now, using the relation derived for L, we get

3
L
K 34 or K  C1 / t 4
d
Ck t d
3
L
For the same product size, C1  3 is a constant.
Ck
From this relation, it can be observed that a relatively
small compression in delivery schedule can result in
or substantial penalty on human effort. For example, if
the estimated development time is one year, then in
order to develop the product in six months, the total
effort and the cost increases 16 times.
Jensen Model
Jensen [1984] proposed a model, very similar to Putnam model, to study the
effect of schedule compression on effort. The proposed model is applicable to
smaller and medium sized projects unlike Putnam model, which is suitable
only for large systems. The equation proposed by Jensen is as follows:

L  Cte * td * K 1/ 2

Where Cte is the effective technology constant, td is the time to develop the
software and K is the effort needed to develop the software.

Scheduling
Scheduling is an important activity of project managers. In order to schedule
a project, a software project manager needs to do the following:
1. Identify the tasks needed to complete the project.
2. Determine the dependency among different tasks.
3. Establish the most likely estimates for the duration of the identified tasks.
4. Plan the starting and ending dates for various tasks.
5. Determine the critical path (The chain of tasks that determine the duration
of the project).

Several tools are currently available which can help us to figure out the
critical path in an un restricted schedule, but figuring out an optimal schedule
with resource limitations and with large number of parallel tasks is an
exponentially hard problem. Several commercial products are available for
automating the scheduling techniques, e.g. Macproject on Apple Macintosh
computers and MS-Project on personal computers.

Work Breakdown Structure

Work Breakdown Structures (WBS) provides a notation for representing the
major tasks needed to be carried out in order to solve a problem. In this
technique, the major activities needed to solve the problem are represented
as nodes of a tree. The root node of the tree is labelled by the problem
name. Each node of the tree is broken down into smaller components that
are designated as the children of the node. The following figure represents
the WBS of an MIS software.
 MIS Application

Requirements Design Code Test Document

Specification

Database Graphical User Database Graphical User

Part Interface Part Part Interface Part

Fig. 4 Work breakdown structure of an MIS problem

Precedence ordering among planning activities
Activity network representation of the MIS problem
 Gantt and PERT Charts
Gantt and PERT charts are visualization tools commonly used by project
managers to control and administer the tasks required to complete a
project.

The Gantt chart, developed by Charles Gantt in 1917, focuses on the

sequence of tasks necessary for completion of the project at hand. Each task
on a Gantt chart is represented as a single horizontal bar on an X-Y
chart. The horizontal axis (X-axis) is the time scale over which the project
will endure. Therefore, the length of each task bar corresponds to the
duration of the task, or the time necessary for completion. Arrows
connecting independent tasks reflect the relationships between the tasks it
connects. The relationship usually shows dependency where one task cannot
begin until another is completed. The resources necessary for completion are
also identified next to the chart. The Gantt chart is an excellent tool for
quickly assessing the status of a project. The following Gantt chart was
developed using MS Project for developing a proposal.
Gannt Chart representation of the MIS problem
Complex projects require a series of activities, some of which must be
performed sequentially and others that can be performed in parallel with
other activities. This collection of series and parallel tasks can be modeled as
a network.
In 1957 the Critical Path Method (CPM) was developed as a network model
for project management. CPM is a deterministic method that uses a fixed
time estimate for each activity. While CPM is easy to understand and use, it
does not consider the time variations that can have a great impact on the
completion time of a complex project.
The Program Evaluation and Review Technique (PERT) is a network model
that allows for randomness in activity completion times. PERT was developed
in the late 1950's for the U.S. Navy's Polaris project having thousands of
contractors. It has the potential to reduce both the time and cost required to
complete a project.
PERT charts are a more sophisticated form of activity chart, where instead of
making a single estimate for each task, pessimistic, likely and optimistic
estimates are made. The boxes of PERT charts are usually annotated with the
pessimistic, likely and optimistic estimates for each task. There is thus not
one but many critical paths, depending on the permutation of the estimates
for each task.
 Jan15 – Apr 1 Apr 1 – July 15 July 15 – Nov 15

Design Code Integrate

Database Database and
Part Part Test

Jan1 – Jan 15

Specification Nov 15 Finish

Design Code Write

GUI GUI Users
Part Part Manual

Jan 15 – Mar 15 Mar 15 – Apr 1 Apr 1 – July 15

PERT Chart representation of the MIS problem

 Steps in the PERT Planning Process
PERT planning involves the following steps:
• Identify the specific activities and milestones.
• Determine the proper sequence of the activities.
• Construct a network diagram.
• Estimate the time required for each activity.
• Determine the critical path.
• Update the PERT chart as the project progresses.

A distinguishing feature of PERT is its ability to deal with uncertainty in

activity completion times. For each activity, the model usually includes three
time estimates:
Optimistic time - generally the shortest time in which the activity can be
completed.
Most likely time - the completion time having the highest probability.
Pessimistic time - the longest time that an activity might require.
PERT assumes a beta probability distribution for the time estimates. For a
beta distribution, the expected time for each activity can be approximated
using the following weighted average:

Expected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6

Benefits of PERT
PERT is useful because it provides the following information:
• Expected project completion time.
• Probability of completion before a specified date.
• The critical path activities that directly impact the completion time.
• The activities that have slack time and that can lend resources to critical
path activities.
• Activity start and end dates.
 Organization and Team Structures
Every software organization handles several projects. Software organizations
assign a team of engineers to handle a software project. There are a few
standard ways in which software organizations and teams are structured.

Organization Structure
There are essentially two broad ways in which a software development
organization is structured:

• Functional format
• Project format

Team Structure
Problems of different complexities and sizes require different team structures.
For effective solution, usually every organization has a standard formal team
structure. The three common formal team structures followed by most
organizations are:
• Democratic Team Structure
• Chief Programmer Team Structure
• Mixed Team Structure

Democratic Team Structure

• It does not enforce any formal team hierarchy.
• A manager provides the administrative leadership.
• Different members of the group provide technical leadership at different
times.
• It leads to higher morale and job satisfaction but less turnover.
• It is more appropriate for less understood problems.
• It encourages egoless programming environment.

However, a democratic team structure has one disadvantage as team

members may waste a lot of time arguing about trivial points due to the
absence of any authority in the team.
Fig. 5 Democratic Team Structure
Chief Programmer Team Structure
• A senior engineer provides the technical leadership.
• The leader of a team verifies and integrates the products developed by
different team members.
• It is more suitable for well understood and is within the intellectual grasp
of a single individual
• It is susceptible to single point failure since too much responsibility and
authority is assigned to the chief programmer.

Project manager

Software Engineers
Mixed Control Team Organization
• It incorporates the ideas from both democratic and chief programmer
team organization.
• In this structure, communication is limited to within a small group that is
most likely to benefit from it.
• It is suitable for very large projects.

Project manager

Senior Software Engineers

Software Engineers
Responsibilities of a Project Manager

 First point of escalation of project issues.

 Obtain project resource commitments.
 Complete project estimates, as required.
 Establish and execute a project plan.
 Define project milestones.
 Create and maintain a project issues log.
 Schedule and conduct project status meetings.
 Complete project status meeting minutes.
 Compete project status reports.
 Monitor and manage financial status of project.
 Participate in the post-implementation review meeting.
 Communicate with the other end-to-end project managers.
 Close the project.
Responsibilities of a Technical Lead

 Review and approve change requests.

 Create systems project plan.
 Participate in weekly project status meetings.
 Conduct system training, as needed.
 Conduct system status meetings.
 Assist in user acceptance testing.
 Ensure system testing is completed.
 Complete the technical design and review.
 Review and approve the project plan.
 Develop the systems support plan.
 Develop system conversion programs, as needed.
 Complete system development and unit testing.
 Update system documentation.
 Complete production support plan.
 Ensure technical activities are included in the project timeline.
 Ensure technical resources are available to complete technical activities.
Responsibilities of a Test Coordination
 Identification of testing participants, organization of test team, and
definition of responsibilities.
 Coordinate cross-project testing dependencies with other testing project
leads.
 Identification of business and operations end users that may need to
validate.
 Confirm testing environment provided will meet needs.
 Schedule testing with dependencies based on design, training, and
conversion schedule.
 Completion of test plan and approval.
 Completion of test scripts and approval.
 Establish and communicate testing schedule.
 Communicate testing status with project team.
 Monitoring of test cycles.
 Ensure validation complete.
 Track testing issues for fixes to be made and ensure appropriate
resolution.
 Obtain testing signoffs.
Staffing

• Software project managers take the responsibility of choosing their team,

they need to identify good software engineers for the success of the
project.
• A common misconception held by managers is the assumption that one
software engineer is as productive as another.
• Experiments have revealed that there exists a large variability of
productivity between the worst and the best software engineers in a scale
of 1 to 30.
• The worst engineer may sometimes even reduce the overall productivity
of the team and thus in effect exhibit negative productivity.

Attributes of a Good Software Engineer

In the past, several studies concerning the qualities of a good software
engineer have been carried out. All these studies roughly agree on the
following attributes that good software engineers usually possess:
• Exposure to systematic techniques
• Good technical knowledge of the project areas (Domain Knowledge)
• Good programming abilities
• Good communication skills
- Oral
- Written
- Interpersonal
• High motivation
• Sound knowledge of fundamentals of computer science
• Intelligence
• Ability to work in a team
• Discipline
Studies show that these attributes vary as much as 1:30 for poor and bright
candidates. An experiment conducted by Sackman [1968] shows that the
ratio of coding hours for the worst to the best programmer is 25:1 and the
ratio of debugging hours is 28:1. Also the ability of a software engineer to
arrive at the design of the software from a problem description varies greatly
with respect to the parameters of quality and time.
Risk Management
A risk is any unfavorable event or circumstances that can occur while a
project is underway. Risk management aims at dealing with all kinds of risks
that might affect a project. Risk management consists of three essential
activities: Risk Identification, Risk assessment, Risk containment

Risk Identification
A project can be affected by a variety of risks. The three main categories of
risks which can affect a software project are:

• Project risks
Budgetary, schedule, personnel, resource, customer-related problems etc.
• Technical risks
Potential design, implementation, interfacing, testing and maintenance
problems. In addition, ambiguous specification, incomplete specification,
changing specification, technical uncertainty and technical obsolescence.
• Business risks
These risks include building an excellent product that no one wants, not
fulfilling budgetary or personnel commitments etc.
In order to successfully foresee and identify different risks that might affect a
software project, it is a good idea to have a company disaster list. This could
contain all the bad events that have happened to software projects over the
years. This list can be read by the software project managers in order to be
aware of the risks that could arise in a project and therefore such a disaster
list often helps to analyze typical areas of risk in a better way.

Risk Assessment
The objective of risk management is to rate each risk in two ways:

• The likelihood of a risk coming true.

• The consequence of the problems associated with that risk.

Based on these two factors, we can prioritize different risks in the following
way:

p  r *s
Where p is the priority of a risk, r is the probability of the risk becoming true
and s is the severity of damage due to the risk.
If risks are prioritized in this way, then the most likely and damaging risks
can be handled first and much more comprehensive risk abatement
procedures can be designed for these risks.

Risk Containment
After the different risks of a project are assessed, steps are first initiated to
avoid or at least control the most damaging and the most likely risks.
Different risks require different containment procedures.

There are three main strategies to plan for risk containment:

Avoid the risk: This may take several forms such as discussing with the
customer to change the requirements to reduce the scope of the work, giving
incentives to the engineers to avoid the risk of manpower turnover, etc.
Transfer the risk: This strategy involves getting the risky component
developed by a third party, buying insurance cover, etc.
Risk reduction: This involves planning ways to contain the damage due to
a risk. For example, if there is risk that some key personnel might leave, new
recruitment may be planned.
Risk leverage
To choose between the different strategies of handling a risk, the project
manager must consider the cost of handling the risk and the corresponding
reduction of risk. For this the risk leverage of the different risks can be
computed. Risk leverage is the difference in risk exposure divided by the
cost of reducing the risk. More formally,
Risk leverage = (risk exposure before reduction – risk exposure after
reduction) / (cost of reduction)

Modern process approaches for solving conventional problems

Conventional Process: Impact Modern Process: Inherent Risk
Top 10 Risks Resolution Features
Late breakage and Quality, Architecture-first approach
excessive scrap/rework Cost, Iterative development
Schedule Automated change management
Risk-confronting process
Attrition of key Quality, Successful, early iterations
personnel Cost, Trustworthy management and
Schedule planning
Conventional Process: Impact Modern Process: Inherent Risk Resolution
Top 10 Risks Features

Inadequate development Cost, Environments as first-class artifacts of the

resources Schedule process.
Industrial-strength, integrated
environments.
Model-based engineering artifacts.
Round-trip engineering.

Adversarial stakeholders Cost, Demonstration-based review.

Schedule Use-case oriented requirements/testing.

Necessary technology Cost, Architecture-first approach.

insertion Schedule Component-based development.

Requirements creep Cost, Iterative development.

Schedule Use-case modeling.
Demonstration-based review.
Conventional Process: Impact Modern Process: Inherent Risk Resolution
Top 10 Risks Features

Analysis paralysis Cost, Demonstration-based review.

Schedule Use-case oriented requirements/testing.

Inadequate performance Quality Demonstration-based performance

assessment.
Early architecture performance feedback.

Overemphasis on artifacts Schedule Demonstration-based assessment.

Objective quality control.

Inadequate function Quality Iterative development.

Early prototypes, incremental releases.
Software Configuration Management
The results of a large software development effort typically consists of a large
number of objects, e.g. source code, design documents, SRS document, test
cases, etc. These objects are usually referred to and modified by a number of
software engineers during the development phase of the software. The state
of any of these objects changes at any point of time is called configuration.
The state of an object changes as development progresses and also as bugs
are detected and fixed.

Configuration management is the art of identifying, organizing and controlling

modifications to the software being built by a programming team. The goal is
to maximize productivity by minimizing mistakes.

Software Configuration Management (SCM) is a set of activities designed to

control change by identifying the work products that are likely to change,
establishing relationships among them, defining mechanisms for managing
different versions of these work products, controlling the changes imposed
and auditing and reporting on these changes made.
It is important to control the change during software development process. If
we don’t control change, it controls us that’s never good. It is very easy for a
stream of uncontrolled changes to turn a well-run software project into
chaos. For that reason, SCM is an essential part of good project management
and solid software engineering practice.

Necessity of Software Configuration Management

There are several reasons for putting an object under configuration

management. Unless strict discipline is enforced regarding updation and
storage of these documents through some automated tool, several problems
appear soon and chaos may follow.

• Inconsistency problem when the object is replicated.

• Problems associated with concurrent access.
• Providing stable development environment.
• System accounting and maintaining status.
Configuration Management Activities
Configuration management is implemented through two principal activities:

• Configuration Identification decides the part of the system which needs to

be kept track of.

• Configuration Control ensures that changes to a system are implemented

smoothly.

Configuration Identification
Any object associated with software development activity can be classified
into three main categories: controlled, precontrolled and uncontrolled.
Controlled objects are under configuration control and some formal
procedures must be followed to change them. Precontrolled objects are not
yet under configuration control but will be eventually under configuration
control. Uncontrolled objects are not and will not be subject to configuration
control. Controllable objects include both controlled and precontrolled
objects. Typical controllable objects include
• Requirements specification document.
• Design documents.
• Tools used to build the system such as compilers, linkers, parsers, etc.
• Source code for each module
• Test cases
• Problem reports

Configuration management plan written during the project planning phase

lists all controlled objects.

Configuration Control
Configuration control is the process of managing changes to controlled
objects. It is that part of a configuration management system that directly
affects the day-to-day operations of developers. In order to change a
module, a developer can get a copy of the module by a reserve operation.
Configuration management tool allow any one person to reserve this module
until the reserved module is restored. Thus the problems associated with
concurrent access are solved.
 A B

C D
Restore
Modules

Reserve
Private Copy of C

Reserve and Restore operation in configuration control.

The engineer needing to change a module must first obtain a private copy of
the module. Then he/she carries out all the necessary changes on his/her
copy. However, restoring the changed module requires the permission of a
change control board (CCB). The CCB is usually constituted from among the
development team members. For every change that needs to be carried out,
the CCB reviews the changes made and certifies several things about the
change:

• Change is well motivated

• The developer has considered and documented the effects of the change.
• Changes interact well with the changes made by other developers.
• Appropriate people have validated the change.
The objective of providing a stable development environment is achieved
through CCB. At any given time, a programmer may pay attention to two
versions of a configuration:
• Current base line configuration.
• Programmer’s private version.
CR ID
About the change request

• Items to be changed
• Description of change
• Reasons for change
• Priority of change
• Originator

CCB comments

• CR approved / rejected
• Actions needed
• Comments

Implementation information

• Status of change information

• Comments
FR ID
Fault information

• Description of the fault

• Severity of fault
• Items suspected of being faulty
• Effect of the fault
• Circumstances and environment
data that caused the fault to
manifest itself
• Possible fixes
• Originator

CCB comments Fault fixing information

• CR approved / rejected • Items changed

• Priority • Comments
• Comments
Change Management Process
Integrated Build Process
Content of an Archive
Release Identification
Baseline
A specification or product that has been formally reviewed an
agreed upon, that thereafter serves as the basis for further
development, and that can be changed only through formal
change control procedures.

Version
An initial release or re-release of a computer software
configuration item, associated with a complete compilation
or recompilation of the computer software configuration item.
IEEE Standard Glossary of Software Engineering Terminology

Release
The formal notification and distribution of an approved version.
Example: Configurations
Product Version Tree
Most Important Software Processes
Primitive Components of Software Change Order
Metrics: The metrics collected for each SCO are important for planning, for
scheduling and for assessing quality improvement. Change categories are of
type 0 (critical bug), type 1 (bug), type 2 (enhancement), type 3 (new feature)
and type 4 (other).

Breakage- Quantifies the volume of change.

Rework- Quantifies the complexity of change.

Analysis- Identifies the number of staff hours expended in understanding the

required change.

Implement – Identifies the staff hours necessary to design and implement the
resolution.

Test – Identifies the hours expended in testing the resolution.

Document- Identifies all effort expended in updating other artifacts such as

the user manual or release description.
Source Code Control System (SCCS)
SCCS is a configuration management tool available on most Unix systems.
SCCS can be used for controlling and managing different versions of text
files. SCCS provides an efficient way of storing versions that minimizes the
amount of occupied disk space. Suppose a module MOD is present in three
versions: MOD1.1, MOD1.2 and MOD1.3. Then SCCS stores original module
MOD1.1 together with the changes needed to transform into MOD1.2 and
MOD1.2 to MOD 1.3. These changes are stored to transform each base lined
file to the next version are called deltas.

The access control facilities provided by SCCS include restrictions on the set
of individuals who can create new versions and facilities for checking
components in and out. Individual developers check out components and
modify them. After they have changed a module as required and the module
has been successfully tested, they check in the changed module into SCCS.
 Assignments - 2
1. What you understand by software project management and why is it
necessary?
2. Discuss the major responsibilities of a software project managers.
3. Why is improving software product visibility important during software
development?
4. Mention five important general skills and traits of a good software
engineer.
5. What are the different categories of software according to the COCOMO
estimation model? Give examples of software products belonging to each
of these categories.
6. For the same number of lines of code and the same size of the
development team, rank the following software projects in order of their
estimated development time. Briefly mention the reason for your answer.
(i) A text editor (ii) An employee payroll system
(iii) An operating system for a new computer.
7. Assume that you have estimated the nominal development time of a
moderate-sized software product to be 5 months. You have also
estimated that it will cost Rs. 50,000 to develop the software product.
Now, the customer comes and tells you that he wants to accelerate the
delivery time by 10%. How much additional cost would you charge him
for this accelerated delivery?
8. Suppose you are developing a software product in the organic mode. You
have estimated the size of the product to be about 100,000 lines of code.
Compute the nominal effort and the development time.
9. Is it true that a software product can always be developed faster by
having a larger development team of competent software engineers?
Justify your answer.
10. What are the relative advantages of using either PERT charts or Gantt
charts in scheduling and monitoring software projects?
11. Discuss why the number of engineers required for a project cannot be
calculated as a simple division of the effort estimate (in PMs) by the
nominal time estimate (in months).
12. Indicate the important items that a software project management plan
(SPMP) document should discuss.
13. What is meant by software configuration management? Why is SCM is
crucial to the success of large software product development projects.
14. What is the relationship between software configuration management
and software maintenance?
15. List three major types of risks in a software project. Suppose you are the
project manager of a large software development project. Enumerate the
main steps you would follow to manage risks in your project.

*****
12. For the following C program estimate the Halstead’s length and volume
measures. Compare the Halstead’s length and volume measures of size
with the LOC measure.

/* Program to calculate GCD of two numbers */

int compute_GCD ( int x, int y )

{
while ( x != y)
if ( x > y ) then
x = x – y;
else
y = y – x;
return ( x );
}
12. The following table indicates the various tasks involved in completing a
software project, the corresponding activities and the estimated effort for
each task in programmer-months.
Effort in
Notation Activity
programmer-months
T1 Requirements specification 1
T2 Design 2
T3 Code actuator interface module 2
T4 Code sensor interface module 5
T5 Code user interface part 3
T6 Code control processing part 1
T7 Integrate and test 6
T8 Write user manual 3

The precedence relation Ti<={Tj, Tk} implies that the task Ti must be
completed before either task Tj or task Tk can start. The following precedence
relation is known to hold among different tasks:
T1<=T2<={ T3, T4, T5, T6} <= T7.
Draw the Gantt chart and the PERT chart representations for the project.