Learning Resource

On

Software Engineering

Chapter-3
Software Project Management

Prepared By:
Kunal Anand, Asst. Professor
SoCE, KIIT, DU, Bhubaneswar-24
•1
Chapter Outcomes:
After completing this chapter successfully, the students will be able
to:
– Define the goal of Software Project Management (SPM).
– Identify the responsibilities of project manager.
– List the content of Software Project Management Plan
(SPMP) document.
– Illustrate several project estimation and scheduling
techniques in SPM.
– Apply project estimation and scheduling techniques to
software project scenarios.
– Explain risk managment in SPM.
– Identify different organization structure and team
organization.

2
Organization of the Chapter:
• Introduction to Software Project Management
• Responsibilities of a Project Manager
– Project Planning
– Software Estimation
• Software Size Metrics
• Cost Estimation Models (COCOMO)
• Empirical, Heuristics, and Analytical Estimation
• Halstead’s software science
• Staffing Level Estimation
– Project Scheduling
• Risk Management
• Organization structure and Team organization

3
Introduction to Software Project Management
• Many software projects fail not because the development
team is not capable enough but due to the faulty project
management practices.

• Therefore, it is important to learn different aspects of

Software Project Management.

• Goal of Software Project Management is to enable a group

of engineers to work efficiently towards successful
completion of a software project.

4
Responsibility of Project Managers
• Project proposal writing,
• Project cost estimation,
• Scheduling,
• Project staffing,
• Project monitoring and control,
• Software configuration management,
• Risk management,
• Managerial report writing and presentations, etc.

5
(contd..)
• A project manager’s activities can be broadly classified into:
– Project Planning
– Project Monitoring and Control
• Once a project is found to be feasible, the project managers
undertake project planning. It consists of the following essential
activities:
• Estimating the following attributes of the project:
– Project size: What will be the problem complexity in terms of
• Cost: How much cost to develop the project?
• Duration: How much time to complete development?
• Effort: How much effort would be required.
• The effectiveness of the subsequent planning activities like
scheduling, staffing, risk management, and miscellaneous plans,
depends on the accuracy of these estimations.
6
Sliding Window Planning
• Planning a project over a number of stages protects managers
from making big commitments too early. This technique of
staggered planning is known as Sliding Window Planning.

• In this technique, starting with an initial plan, the project is

planned more accurately in successive development stages.

• At the start of a project, project managers have incomplete

knowledge about the details of the project. Their information
base gradually improves as the project progresses through
different phases.

• After the completion of every phase, the project managers can

plan each subsequent phase more accurately and with increasing
levels of confidence.
7
Organization of SPMP Document
• After planning is complete, the manager documents the plans in a
Software Project Management Plan (SPMP) document.
• Introduction (Objectives, Major Functions, Performance
issues, Management and Technical Constraints)
• Project Estimates (Historical Data, Estimation Techniques,
Effort, Cost, and Project Duration Estimates)
• Project Resource Plans (People, Hardware and Software,
Special Resources)
• Schedules (Work Breakdown Structure, Task Network,
Gantt Chart Representation, PERT Chart Representation)
• Risk Management Plan (Risk Analysis, Risk Identification,
Risk Estimation, Abatement Procedures)
• Project Tracking and Control Plan
• Miscellaneous Plans (Process Tailoring, Quality Assurance)

8
Software 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.
• Two metrics widely used to estimate the project size:
– Lines of Code (LOC)
– Function Point (FP)

9
Software Project Size Metrics: LOC
• Simplest among all metrics available to estimate project size.
• Using this metric, the project size is estimated by counting the
number of source instructions in the developed program.
• While counting the number of source instructions, comment
lines and the header lines should be ignored.
• To estimate, the project managers usually divide the problem
into modules, submodules until the size of the different
leaf-level modules can be approximately predicted.
• By using the estimation of the lowest level modules, project
managers arrive at the total size estimation.
• Accurate estimation of the LOC count at the beginning of a
project is very difficult.
• Past experience in developing similar products is helpful.
10
Disadvantages of using LOC metric
• Size can vary with coding style.
• Focuses on coding activity alone.
• Correlates poorly with quality and efficiency of code.
• Penalizes higher level programming languages, code reuse, etc.
• Difficult to estimate LOC from problem description.
– So not useful for project planning

11
Function Point Metric
• Proposed by Albrecht in 1983.
• It overcomes some of the shortcomings of the LOC metric
• It estimates the size of a software product directly from the
problem specification.
• Size of a software product is directly dependent on the number
of different functions or features it supports.
• Albrecht postulated that in addition to the number of basic
functions that a software performs, the size is also dependent
on the number of files, number of inquiries, and the number
of interfaces.

12
 • FP metrics computes the size of a software product using three
other characteristics as below:
– UFP=(no. of inputs)*4 + (no. of outputs)*5 + (no. of
inquiries)*4 + (no. of files)*10 + (no. of interfaces)*7
where,
UFP: Unadjuisted Function Point
Number of inputs: Each data item input by the user
Number of outputs: The outputs considered refer to reports
printed, screen outputs, error messages.
Number of inquiries: user commands which require specific
action by the system.
Number of files: Each logical file is counted.
Number of interfaces: Used to exchange information with
other systems. Examples of such interfaces are data files on
tapes, disks, communication links with other systems etc.

13
• UFP, Unadjusted Function Point, is a gross indicator of the
problem size as it assumes that each parameter is of average
complexity, that is rarely true. Hence, UFP is refined by considering
the complexity of these parameters.
• The complexities are broadly classified into simple, average and
complex. Please refer Table 3.1, pp. 105; Fundamentals of SE;
5th edition by Rajib Mall.
• Once UFP is calculated, Technical Complexity Factor, TCF, is
calculated next. It refines the UFP measure by considering 14 other
factors; Table 3.2, assigned a value from 0 (No Influence) to 6
(Strong influence).
• The resulting numbers are summed, yielding the total Degree of
Influence, DI.
– TCF= 0.65 + 0.01*DI; where, 0<=DI<=84
– TCF usually varies from 0.65 to 1.49.
• Finally, FP=UFP*TCF 14
Sample Problem
Consider a project with the following functional units:
• Number of user inputs = 100 (30 simple inputs and 20 average
inputs, rest complex)
• Number of user outputs = 80
• Number of user inquiries = 60 (20 simple inquiries and 15
average inquiries, rest complex)
• Number of user files = 06
• Number of external interfaces = 04 (1 simple and 3 average)

Assuming all complexity adjustment factors as average. Calculate

the function points for the project.

15
Solution
Considering the complexities and given data, Function Point can be
calculated as below:
Step-1: UFP = (30*3 + 20*4 + 50*6) + 80*5 + (20*3 + 15*4
+ 25*6) + 6*10 + (1*5 + 3*7)
= 470 + 400 + 270 + 60 + 26 = 1226
Step-2: Considering the complexity adjustment factors of average
complexity, TCF can be computed as below:
TCF = 0.65 + (0.01*DI); where, 0<= DI<= 84
= 0.65 + (0.01*56) = 1.21
Step-3: Finally, the adjusted function point, FP = 1226 * 1.21 =
1483.46

Note: Please refer to Solved Problem 3.1; pp. 106; to get a better
understanding of a real life project scenario for FP metric estimation.
16
Function Point Metric (contd..)
• FP metric suffers from a major drawback as here the size of a
function is independent of its complexity.
• Extended FP metric considers an extra parameter named as
Algorithm Complexity.
– It says that greater is the effort required to develop it and
therefore its size should be larger compared to simpler
functions.
• Proponents claim that FP is language independent. Hence,
size can be easily derived from problem description
• Opponents claim that it is subjective which means that
different people can produce different estimates for the same
problem.

17
Software Project Size/Cost Estimation
• Empirical techniques:
– an educated guess based on past experience.

• Heuristic techniques:
– assume that the characteristics to be estimated can be
expressed in terms of some mathematical expression.

• Analytical techniques:
– derive the required results starting from certain simple
assumptions.

18
Empirical Size Estimation Techniques
• Based on making an educated guess of the project parameters.
• Prior experience with development of similar products is helpful.
• Two popular empirical estimation techniques are:
– Expert judgment technique
– Delphi cost estimation

• Expert Judgement
– Here, an expert makes an educated guess of problem size
after analyzing the problem thoroughly.
– The expert estimates the cost of different component and
combines them to arrive at the overall estimate.
– Suffers from human errors and biasness.
– Additionally, prior experience is required. Absence of the
same may lead to inadequate or wrong estimations.
19
Delphi Cost Estimation
• Overcomes some of the problems of expert judgement
• Team of Experts and a coordinator.
– Experts carry out estimation independently. They mention
the unusual characteristic of the product which has
influenced his estimation.
– The co-ordinator notes down any extraordinary rationale
and circulates among experts.
• Experts re-estimate.
• Experts never meet each other to discuss their viewpoints as
many estimators may easily get Influenced.
• After several rounds of iterations, the coordinator compiles all
the results and prepare the final estimates.

20
Heuristic Estimation Techniques
• Single Variable Model: provides a means to estimate the desired
characteristics of a problem, using some previously estimated
basic (independent) characteristic of the software product such
as its size, staff etc.
Estimated Parameter = C1 * e d1
Where,

e = Characteristics that has already been estimated.

–
Estimated parameter is the dependent parameter, to be estimated
–
C1 and d1 are constants.
–
• Multivariable Model: assumes that the parameter to be
estimated depends on more than one characteristic.
● Estimated Parameter = C1*(e1)^d1+ C2*(e2)^d2+…
● Usually more accurate than single variable models. 21
 COCOMO Model
• COCOMO (COnstructive COst MOdel) is a Constructive Cost
Estimation Model proposed by Boehm.
• COCOMO Product classes correspond to the application, utility
and system programs, respectively.
• Data processing and scientific programs are application
programs.
• Compilers, linkers, editors, etc., are utility programs.
• Operating systems and real-time system programs, etc. are
system programs.
• Divides software product developments into 3 categories:
– Organic: Relatively small groups working to develop
well-understood small sized applications.
– Semi-detached: Project team consists of a mixture of
experienced and inexperienced staff.
– Embedded: The software is strongly coupled to complex
hardware, or real-time systems. 22
COCOMO Model (contd..)
• For each of the three product categories:
– From size estimation (in KLOC), Boehm provides equations
to predict:
• project duration in months
• effort in programmer-months (PM)
• Average staff size
• Productivity of the team
• Development cost

• Boehm obtained these equations:

– examined historical data collected from a large number of
actual projects.

23
COCOMO Model (contd..)
• Software cost estimation is done through three stages:
– Basic COCOMO:
• Gives only an approximate estimation
• Effort = a1*(KLOC)^a2 PM
• Tdev = b1*(Effort)^b2 months
• SS = E/D persons
• P = KLOC/E KLOC/PM
Where,
– KLOC, Size, is the estimated kilo lines of source
code
– a1,a2,b1,b2 are constants for different categories of
software products,
– Tdev is the estimated time to develop the software in
months,
– SS is staff size and P is productivity. 24
Development Effort Estimation
• Organic :
– Effort = 2.4*(KLOC)^1.05 PM
• Semi-detached:
– Effort = 3.0*(KLOC)^1.12 PM
• Embedded:
– Effort = 3.6*(KLOC)^1.20PM
Development Time Estimation
• Organic:
– Tdev = 2.5*(Effort)^0.38 Months
• Semi-detached:
– Tdev = 2.5*(Effort)^0.35 Months
• Embedded:
– Tdev = 2.5*(Effort)^0.32 Months 25
Basic COCOMO Model (contd..)
• Effort is somewhat super-linear of problem size i.e., the
effort increases with increase in project size.

26
Basic COCOMO Model (contd..)
• Development time is a sublinear function of product size.
• When product size increases two times, development time
does not get double. i.e., Time taken is almost same for all the
three product categories.

27
Basic COCOMO Model (contd..)
• The effort estimation and duration estimation done by basic
COCOMO is known as nominal effort and nominal duration
estimate.

• The term “Nominal” implies that if one tries to complete the

project in a time shorter than the estimated duration, the cost
will increase drastically.

• However, if the project is completed over a longer duration

than the estimate, there is almost no decrease in the estimated
cost.

28
Example-1
• The size of an organic software product has been estimated
to be 32,000 lines of source code. Assume that the average
salary of software engineers be Rs. 50,000/- per month.
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
• Cost required to develop the product = Effort x Avg. salary
= 91 х 50,000
= Rs. 45,50,000/-

29
Example-2: Suppose that a project was to be estimated at
400KLOC. Calculate the development effort and time for
each of the three modes.
Solution:
Estimated size of the project = 400 KLOC
1. Organic:
E = 2.4 (400)^1.05 = 1295.31 PM
D = 2.5 (1295.31)^0.38 = 38.07 M
2. Semi detached:
E = 3.0 (400)^1.12 = 2462.79 PM
D = 2.5 (2462.79)^0.35 = 38.45 M
3. Embedded:
E = 3.6 (400)^1.20 = 4772.81 PM
D = 2.5 (4772.81)^0.32 = 37.59 M
30
Intermediate COCOMO
• Basic COCOMO model assumes that the effort and
development time depend on product size alone.
• However, several other parameters affect effort and
development time:
• Reliability requirements
• Availability of CASE tools and modern facilities to the
developers
• Size of data to be handled
• For accurate estimation,
– the effect of all relevant parameters must be considered.
– Intermediate COCOMO model recognizes this fact and
refines the initial estimate obtained by the basic COCOMO
by using a set of 15 cost drivers (multipliers).
31
Intermediate COCOMO (contd..)
• If modern programming practices are used, initial estimates are
scaled downwards.

• If there are stringent reliability requirements on the product,

initial estimate is scaled upwards.

• Rate different parameters on a scale of very low, low, nominal,

high, very high and extra high.

• Depending on these ratings, multiply cost driver values with

the estimate obtained using the intermediate COCOMO.

32
Intermediate COCOMO (CONT.)
• Cost driver classes:
– Product: characteristics of the product that affects the
estimates are reliability (RELY), databse size (DATA) and
complexity (CPLX).
– Computer: Execution time (TIME), storage requirements
(STOR), virtual machine volatility (VIRT) and computer
turnaround time (TURN).
– Personnel: programming language experience (LEXP),
virtual machine experience (VEXP), programming
capability (PCAP), analysis capability (ACAP), and
application experience (AEXP) etc.
– Development Environment: modern programming
practices (MODP), software tools (TOOL) and required
development schedule (SCED)
33
Shortcoming of basic and intermediate
COCOMO models
• Both models:
– consider a software product as a single homogeneous entity
– However, most large systems are made up of several
smaller sub-systems.
• Some sub-systems may be considered as organic type,
some may be considered embedded, etc.
• for some the reliability requirements may be high, and so
on.

34
Complete COCOMO
• Cost of each sub-system is estimated separately.
• Costs of the sub-systems are added to obtain total cost.
• Reduces the margin of error in the final estimate.

• Example: A Management Information System (MIS) for an

organization having offices at several places across the country:
– Database part (semi-detached)
– Graphical User Interface (GUI) part (organic)
– Communication part (embedded)

• Costs of the components are estimated separately and then

summed up to give the overall cost of the system.

35
Analytical Estimation Techniques
• Analytical estimation techniques derive the required results
starting with basic assumptions regarding the project.

• Analytical techniques do have scientific basis.

• Halstead’s software science is an example of an analytical

technique.
– Can be used to derive some interesting results starting with
a few simple assumptions.
– Useful for estimating software maintenance efforts.
– In fact, it outperforms both empirical and heuristic
techniques when used for predicting software maintenance
efforts.
36
Halstead's Software Science
• An analytical technique to estimate:
– size,
– development effort,
– development time.

• Halstead used a few primitive program parameters like number

of operators and operands
• Derived expressions for:
– program length: N=n1 + n2; n1 and n2 are total number of
operators and operands, respectively.
– program vocabulary: Total number of unique operators
and operands. i.e., U=u1 + u2; u1 and u2 are total number
of unique operators and operands.

37
Halstead Software Science (contd..)
– program volume: The program size, V, can be considered
as: V=Nlog2U; where, N is program length and U is
program vocabulary.
– Potential Minimum Volume: V*= (2+u2)log2(2+u2); It is
defined as the minimum source code using which the
problem can be coded. e.g. say a function call.
– Program level: L= V*/V; where, V* is potential minimum
volume and V is program volume.
– effort: V/L; where, V is program volume and L is program
level.
– development time: E/S; where, E is effort and S is speed
of mental discrimination.
– Halstead provided following two expressions to calculate
length and volume
• Estimated length= u1*log u1 + u2*log u2
• Volume= Length* log (u1+u2) 38
Staffing Level Estimation
• Once the effort required to develop a software has been
determined, it is necessary to determine the staffing
requirement for the project.
• Very small number of engineers are needed at the beginning of
a project to carry out planning and specification.
• As the project progresses:
– more detailed work is required,
– number of engineers slowly increases and reaches a peak
• Putnam observed that:
– the time at which the Rayleigh curve reaches its
maximum value corresponds to system testing and
product release.
– After system testing, the number of project staff falls till
product installation and delivery.
39
Rayleigh Curve
• Rayleigh curve is specified by two parameters:
– td the time at which the curve reaches its maximum
– K the total area under the curve.
• L=f(K, td)

40
Project Scheduling
• It involves deciding which tasks will be taken up and when.
• To schedule the project activities, a software project manager
needs to do the following tasks:
– Identify all the tasks needed to complete the project.
– Break down large tasks into small activities.
– Determine the dependency among different activities.
– Establish the most likely estimates for the time durations
necessary to complete the activities.
– Plan the starting and ending dates for various activities.
– Determine the critical path.
– A critical path is the chain of activities that determines the
project’s duration.

41
Work Breakdown Structure (WBS)
• Decompose a given task set
recursively into small
activities.
• Root of the tree is labelled
by the problem name.
• Each node of the tree is
broken down into smaller
activities that are made the
children of the node.
• Each activity is recursively
decomposed into smaller
sub-activities until at the
leaf level.

42
Activity networks
• Activity network shows the different activities making up a
project, their estimated durations, and interdependencies.
• Each activity is represented by a rectangular node and the
duration of the activity is shown alongside each task.
• An example of activity network is as shown below:

43
Critical Path Method (CPM)
• The Critical Path Method (CPM), a project modeling
technique developed by Morgan R. Walker and James E.
Kelly in late 1950s.
• Critical path is the sequence of activities from start to end,
and it has the longest duration among all paths in a network
diagram.
• The activities under critical path are known as critical
activities.
– An activity is critical if it can't be delayed else the entire
project will be delayed. Hence, slack for critical activities
is 0.
• In ideal conditions, an activity network diagram, and therefore,
the project, should have only one critical path.

44
Critical Path Method (CPM)
• The CPM has four key elements...
– Critical Path Analysis
– Early Start & Early Finish; Late Start & Late Finish
– Float/Slack Determination
• The following is the procedure to find the critical path on a network
diagram:
– Draw the activity network diagram.
– Identify all possible paths in the network diagram.
– Find the duration of each path.
– The path with the longest duration is the critical path.
• Float (slack time) is the amount of time an activity can slip before it
causes your project to be delayed.
• Example: Based on the below network diagram, identify the total
paths, critical path, and float for each path.

45
Example

• The above network diagram has five paths; the paths and their
duration are as follows:
– Start -> A -> B -> C-> End, duration: 31 days.
– Start ->D -> E ->F -> End, duration: 18 days.
– Start -> D -> B -> C -> End, duration: 26 days.
– Start -> G ->H ->I -> End, duration: 13 days.
– Start -> G -> E ->F -> End, duration: 16 days.
46
contd..
• Since the duration of the first path i.e., A->B->C is the
longest, it is the critical path. The float/slack on the critical
path is zero.
• The float/slack for the second path “D -> E ->F” = duration
of the critical path – duration of the path “D -> E ->F” = 31 –
18 = 13. Hence, the float/slack for the second path is 13 days.
• Using the same process, we can calculate the float/slack for
other paths as well.
– Float/slack for the third path = 31 – 26 = 5 days.
– Float/slack for the fourth path = 31 – 13 = 18 days.
– Float/slack for the fifth path = 31 – 16 = 15 days.

47
Early Start (ES) & Early Finish (EF)
• Early Start (ES) for the first activity on any path will be 1
because no activity can be started before the first day.
– ES of the activity = EF of predecessor activity + 1
– EF of the activity = Activity duration + ES of activity – 1
• Late Start (LS) and Late Finish (LF)
– Late Finish (LF) of the last activity in any path will be the
same as the Last Finish of the last activity on the critical
path, because you cannot continue any activity once the
project is completed.
– Late Start (LS) of Activity = Late Finish of activity –
activity duration + 1
– Late Finish (LF) of Activity = Late Start of successor
activity – 1
48
contd..
• Early Start & Early Finish for the path A -> B -> C
– ES of activity, A = 1
– EF of activity, A = ES of activity A + activity duration – 1
= 1 + 10 – 1 = 10
• ES of activity, B = EF of predecessor activity + 1
= 10 +1 = 11
• EF of activity, B = ES of activity B + activity duration – 1
= 11 + 12 – 1 = 22
• ES of activity C=EF of predecessor activity+1=22+1 = 23
• EF of activity C = ES of activity C + activity duration – 1
= 23 + 9 – 1 = 31

49
Late Start (LS) and Late Finish (LF)
• Late Start and Late Finish Dates for the path A -> B -> C
– On a critical path, Early Start, and Early Finish dates will
be the same as Late Start and Late Finish dates.
• Late Start and Late Finish for the path D -> E -> F
– LF of activity F = 31 (because you cannot allow any
activity to cross the project completion date)
– LS of activity F = LF of activity F – activity duration + 1
= 31 – 6 +1 = 26
– LF of activity E = LS of successor activity – 1
= LS of activity F – 1 = 26 – 1 = 25
– LS of Activity E = LF of activity E – activity duration+ 1
= 25 – 7 + 1 = 19

50
contd..
• Late Finish of activity D = LS of successor activity – 1
– If you look at the network diagram, you will notice that
activity D has two successor activities, B and E. So, which
activity will you select?
– You will select the activity with the earlier(least) Late Start
date. Here, Late Start of activity B is 11, and Late Start of
activity E is 19.
– Therefore, you will select activity B which has the earlier
Late Start date.

• LF of activity D = LS of activity B – 1 = 11 – 1 = 10
• LS of Activity D = LF of activity D – activity duration + 1
= 10 – 5 + 1 = 6

51
CPM using Box Representation Method
• In box representation, each activity is represented using a box
as shown below:

52
Forward Pass

53
Backward Pass

54
Advantages & Disadvantage of CPM
Advantages: Disadvantages:
– It shows the graphical • Because the critical path
view of the project. method is an optimal planning
– It discovers and makes tool, it always assumes that all
dependencies visible. resources are always available
– It helps in project for the project.
planning, scheduling, and • It does not consider resource
controlling. dependencies.
• There are chances of misusing
– It shows the critical path
float or slack.
and identifies critical
• Less attention on non-critical
activities requiring
activities, though sometimes
special attention.
they may also become critical.
– It shows you where you • Projects based on the critical
need to take action to path often fail to be completed
bring project back on within the approved time
track. duration. 55
Gantt Chart
• Gantt charts are mainly used
to allocate resources to
activities.
• The resources allocated to
activities include staff,
hardware, and software.
• A special type of bar chart
where each bar represents
an activity.
• The bars are drawn along a
time line. The length of
each bar is proportional to
the duration of time
planned for the
corresponding activity.
56
PERT chart
• PERT (Project Evaluation and Review Technique) charts
consist of a network of boxes and arrows. The boxes represent
activities and the arrows represent task dependencies.

• PERT chart represents the statistical variations in the project

estimates assuming a normal distribution. Thus, in a PERT chart
instead of making a single estimate for each task, pessimistic,
likely, and optimistic estimates are made.

• A critical path in a PERT chart is shown by using thicker

arrows.

• Gantt chart representation of a project schedule is helpful in

planning the utilization of resources, while PERT chart is useful
for monitoring the timely progress of activities. 57
A Sample Example

58
Sample Problem-1
A small consultancy project consists of
the following activities given below.
• Calculate the expected time (te)
values, standard deviation, and
variance for each activity.
• Draw a network diagram and mark
the expected time (te)
• Calculate EST and LFT and mark
them on the diagram.
• Calculate the total slack for each
activity.
• Calculate the variance of the critical
path.
• Calculate the probability that the job
on the critical path will be finished
by the due date of 38 days. (omit)
59
Solution
(a) We know that te = (to + 4*tm + tp ) / 6

Standard deviation

Variance = (Standard deviation)2

60
Contd..

61
Contd..
• Critical path is 1 – 2 – 3 – 5 – 8, Length is 6 + 13 + 11+ 3 = 33
days
• There are three critical paths:
1 – 2 – 3 – 5- 8 (33).
1 – 6 – 7 – 8 (31) Next most critical path.
1 – 2 – 4 – 5 – 8 (19) Next most critical path.
• Slack time for each activity is as below:
1-2 (a1): 6 – 6 = 0; 3-5 (a5): 30 – 30 = 0
1-6 (a2): 7 – 5 = 2; 4-5 (a6): 30 – 30 = 0
2-3 (a3): 19 – 19 = 0; 6-7 (a7): 18 – 16 = 2
2-4 (a4): 24 – 10 = 14; 5-8 (a8): 33 – 33 = 0
7-8 (a9): 33 – 33 = 0
62
contd..
• The variance of critical path 1 – 2 – 3 – 5 – 8 is 4 + 16 + 4 + 1
= 25.
• The probability that the project will meet the due date I
calculated by the formula.

• For the value of Z = 1 the corresponding standard normal

distribution table is 0.841 i.e, 84.1%

63
Risk management
Three main categories of risks:
• Project risks: risks concern varies forms of budgetary, schedule,
personnel, resource, and customer-related problems. An important
project risk is schedule slippage.
• Technical risks: risks concern potential design, implementation,
interfacing, testing, and maintenance problems. Most technical risks
occur due to the development team’s insufficient knowledge about the
project.
• Business risks: risks that are driven by the business needs. For
example: building an excellent product that no one wants.
• Risk assessment: to rank the risks in terms of their damage causing
potential. p = r * s ; where
p is the priority with which the risk must be handled,
r is the probability of the risk becoming true,
s is the severity of damage caused due to the risk becoming true.
64
Risk containment
● Risks of a project are assessed, plans must be made to contain
the most damaging and the most likely risks.
● Different risks require different containment procedures.
Three main strategies to plan for risk containment:
● Avoid the risk: 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: Involves getting the risky component
developed by a third party, buying insurance cover, etc.
● Risk reduction: 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.

65
Risk Reduction Leverage (RRL)
– Risk Reduction Leverage (RRL) can be defined as the
variation in risk exposure divided by the amount of reducing
the risk.
– Mathematically, Risk Reduction Leverage can be represented
as below:
• RRL = (risk exposure before reduction – risk exposure
after reduction) / (cost of reduction)
– Risk exposure (RE) = (potential damage) x (probability of
occurrence)
– If the RRL < 1, it means that the cost of the risk reduction
activity outweighs the probable gain from implementing the
action i.e., one should opt for a risk reduction solution only
when the RRL > 1.
66
Sample Example
• After doing risk analysis, a team estimated that a 1% chance of fire
could cause damage of Rs. 100000/- to the company. However, the
team found that if they install a fire alarm system to resolve the risk,
the chances of damage will be reduced to 0.5%. The fire alarm
system installation will cost Rs.1000/- to the company. As a team
leader, will you go ahead with the installation of a fire alarm
system?
Ans: According to the given scenario:
REbefore = r * s = 0.01 * 100000 = 1000
REafter = r * s = 0.005 * 100000 = 500
Cost of reduction = 1000
Hence, RRL = (1000 – 500) / 1000 = 0.5
i.e., RRL<1 which means that the cost of the fire system installation
outweighs the probable gain from implementing the action. Therefore,
being a team leader, I will not opt for the installation of fire alarm
system. 67
 Organization Structure
• Functional Format:
– Engineers are organized into functional groups, e.g.
• specification, design, coding, testing, maintenance, etc.
– Engineers from functional groups get assigned to different
projects
– Requires considerable communication between different
teams to provide efficient development.
– It also requires good documentation to be produced after each
activity.
– Advantages: Ease of staffing, Job specialization.
– Disadvantages: No knowledge about the other aspects of
software development.

68
contd..
• Project Format:
– Team of engineers are assigned at the beginning of the
project, and they remain till the end of the project.
– Same team carries out all the life cycle activities.
– Provides job rotation to team members which gives them
exposure to different activities.
– Advantages: Good exposure towards other aspects of
software development, ease of staffing, Good
documentation.
– Disadvantages:
• Poor utilization of the resource as the team size is fixed.
• No job expertise or specialization.
69
contd..

70
Team Organization: Chief Programmer Team
• A senior engineer provides technical leadership:
– partitions the task among the team members.
– verifies and integrates the products developed by the
members.
• Works well when
– the task is well understood
• also within the intellectual grasp of a single individual,
– importance of early completion outweighs other factors
• team morale, personal development, etc.
• Chief programmer team is subject to single point failure:
– too much responsibility and authority is assigned to the
chief programmer.

71
Democratic Teams
• Suitable for:
– small projects requiring less than five or six engineers
– research-oriented projects
• One of the team member provides administrative leadership:
– at different times different members of the group provide
technical leadership.
• Democratic organization provides
– higher morale and job satisfaction to the engineers
– therefore leads to less employee turnover.
• Disadvantage:
– team members may waste a lot time arguing about trivial
points due to the absence of any authority in the team.
72
Mixed Control Team Organization

• Draws upon ideas from both:

– democratic organization and
– chief-programmer team organization.
• Communication is limited
– to a small group that is most likely to benefit from
it.
• Suitable for large organizations.

73