SOFTWARE

PROJECT MANAGEMENT (II)

Prof. S. K. Swain
Software Estimation
Effort Estimation Cost
Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

2
 Scheduling
• Scheduling the project tasks is an
important project planning activity.
• Scheduling involves deciding which
tasks would be taken up when.
 In what sequence a set of activities will be performed.
 When they should start and be completed.

3
 Scheduling
To schedule a project, the project manager
needs to do:
• Identify all 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.
• Allocate resources to 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 duration of the project.
4
Work Breakdown Structure
Decomposing a given task set recursively into small
activities. The root is named with problem name. The
children nodes are the broken down activities. They are
decomposed to leaf-level activities so that it requires two
weeks to get completed.
Advantages:
• Small activities can be distributed to number of
engineers.
• Activity ordering permits, the solution to come
independently.
• Possible to develop the product faster.
• Able to complete a project faster.
• Breaking the jobs into small ones, parallelism is
possible.
5
 MIS application

Requirement Design Code Test Document

specification

Database Graphical user Database Graphical user

part interface part part interface part

Work breakdown structure of an MIS problem

6
 ACTIVITY NETWORK DIAGRAM

• A project management tool used to schedule,

organize, and coordinate tasks within a
project.
• Two approaches to Project management:
• PERT
• CPM

7
 PERT Vs. CPM
PERT was devised to support the
development of the Polaris missile in the
late 1950’s. PERT is an activity-on-node
notation – the ‘nodes’ are the boxes
which represent activities
CPM was developed by Du Pont
Chemical Company who published the
method in 1958. CPM uses an activity-
on-arrow notation where the arrows are
the activities.
8
 PERT & CPM
• PERT and CPM are similar in their basic approach, they
do differ in the way activity times are estimated.

• PERT (Program Evaluation Review Technique)

• PERT handles probabilistic activity times
• The stress is on the probability of completing a
project in a given time.

• CPM (Critical Path Method)

• CPM handles deterministic activity times
• The stress is on sensitivity of project completion
time on resources

9
 Probabilistic Time Estimates
• PERT-type approach uses 3 time estimates for
each activity
• Most likely time (tm)
– subjective estimate of most frequent time
• Optimistic time (to)
– shortest possible time (ideally)
• Pessimistic time (tp)
– longest time possible if everything went wrong

10
 PERT vs CPM
Do B
PERT

Do A Do D
Do C
CPM
Do B
Do A

Do D
Do C

11
 Both PERT and CPM
• Graphically display the precedence relationships
& sequence of activities
• Estimate the project’s duration
• Identify critical activities:
– Activitiesthat cannot be delayed without delaying
the project
• Estimate the amount of slack associated with
non-critical activities
12
 Comparison Between CPM and PERT
CPM PERT
1 Uses network, calculate float or slack, identify
critical path and activities, guides to monitor Same as CPM
and controlling project

2 Uses one value of activity time Requires 3 estimates of activity time

Calculates mean and variance of time

3 Used where times can be estimated with Used where times cannot be estimated with
confidence, familiar activities confidence.
Unfamiliar or new activities

4 Minimizing cost is more important Meeting time target or estimating percent

completion is more important

5 Example: construction projects, building one Example: Involving new activities or products,
off machines, ships, etc research and development etc

13
 CPM/PERT
• Over time, CPM and PERT merged into one
technique:
– referred to as "CPM/PERT".
• Visually easier to see precedence
relationships
• Ideal for large projects with many activities
– Consist of a network of branches and nodes

14
 Sample Usage of PERT & CPM
• Completion date?

• On schedule? Within budget?

• Probability of completing by ...?

• Critical activities?

• Enough resources available?

• How can the project be finished early at the least

cost?
15
 PERT & CPM Steps
• Identify activities
• Determine sequence
• Create network
• Determine activity times
• Find critical path:
• Earliest & latest start times
• Earliest & latest finish times
• Slack

16
 PERT Charts
•PERT = Project Evaluation and Review Technique
•PERT chart = graphical representation of the scheduling of events in a project
•Sample PERT Chart:
6
3 E
10
B 3 13
2 6
0 A 4 13
1 4 2 F
0 4 C 7 10
D 3
3 4 5
7 3 10
•A PERT chart is a graph
– Edges are tasks/activities that need to be done
– Nodes are the events or milestones
•Task edge T from event node E1 to event node E2 signifies:
– Until event E1 happens, task T cannot be started
– Until task T finishes, event E2 cannot happen
•Events often simply represent completion of tasks associated with arrows entering
it 17
 PERT Chart Event Nodes

Event Number:
Sequence number assigned Earliest Completion Time
(ECT) or ES (Earliest Start):
Only task edges indicate
9 Earliest time this event can be
dependencies 5 achieved, given durations and
19 dependencies

Latest Completion Time (LCT) or LF(Latest Finish):

Latest time that this event could be safely achieved
Slack = (Latest Start) - (Earliest Start), or = (Latest Finish) - (Earliest Finish).
A critical path is a path of activities, from the Start node to the Finish
node, with 0 slack times. 18
 Calculating ECTs or ES
• ECT = earliest time event can be completed, To calculate:
– For an event not depending on others: ECT = 0
• Usually this is the first event
– For an event E depending on one or more others:
• Calculate ECTs of event(s) that E depends on
• Add duration(s) of task(s) leading to E
• If E depends on more than one event, take MAX
• Proceed left to right (  ) through the chart

19
 Calculating LCT or LF
• LCT = latest time event can be completed, while still finishing last task at indicated
time, To calculate:
– For an event which no other events depend on: LCT = ECT
• Generally there will only be one such event
– For an event E which one or more others depend on:
• Calculate LCTs of event(s) that depend on E
• Subtract duration(s) of task(s) leading from E
• If more than one event depends on E, take MINIMUM
• Proceed right to left (  ) through PERT chart

20
 Critical Path

Red line is the critical path A critical path for the network is a
path consisting of activities with zero slack.
What does it represent? And it is always the longest path in the
project network.

21
Critical Path Method
• WBS representation of a project is transformed into an
Activity network along with their interdependencies.
• An activity network shows the different activities making
up a project, their estimated durations,
interdependencies.

Ex-Consider a software project of 8 jobs Analysis-module-1 and

system requirement study(SRS)-1, Analysis-module-2,
System requirement Study(SRS)-2, GUI Design, GUI Coding
& Unit Testing-1, Data Base(DB) Design, DB Coding & Unit
Testing, and Integration & System Testing. Two groups of
professionals are deployed to develop the system. The
required time of each activities and precedence of activities
are given in the next slide.

22
Job Job Description Predecessor Normal Time (days)
A Analysis-1 & SRS-1 - 10
B Analysis-2 - 5
C SRS-2 B 3
D GUI Design A, C 4
E DB Design A, C 5
F GUI Coding & Unit Testing D 6
G DB Coding & Unit Testing E 5
H Integration & System Testing F, G 5

23
 Job Job Description Predecessor Normal Time (days)
A Analysis-1 & SRS-1 - 10
B Analysis-2 - 5
C SRS-2 B 3
D GUI Design A, C 4
E DB Design A, C 5
F GUI Coding & Unit Testing D 6
G DB Coding & Unit Testing E 5
H Integration & System Testing F, G 5
ES=14
LF=14
4
D F
ES=0 ES=10 ES=20
LF=0 LF=10 4 6 LF=20
A 5 ES=25
1 3 6 7 LF=25
10 5 H
B 5 3
C E 5
2 G
5
ES2=5
LF=7 ES=15
LF=15

24
 ES=14
LF=14
ES=0 ES=10 4 F ES=20
D
LF=0 LF=10 6 LF=20
A 4 5 ES=25
1 10 3 6 H 7
5 3 5 LF=25
B C E 5
2 G
5
ES2=5 ES=15
LF=7 LF=15
Job Expected Earliest Latest Slack Time Remarks
Duration Start-ES Finish-LF (Max.delay)

A 10 0 10 0 Critical
B 5 0 7 2 Non-critical
C 3 5 10 3 Non-critical
D 4 10 14 0 Critical
E 5 10 15 0 Critical
F 6 14 20 0 Critical
G 5 15 20 0 Critical
H 5 20 25 0 Critical
If all the jobs are done at their normal times, the project duration
(length of the longest path) is 25 days.

Critical path A D F H = 25 days 25

or A E G H = 25 days
 Example: ABC Associates
• Consider the following project:
Immediate
Activity Predecessor time (days)
A -- 6
B -- 4
C A 3
D A 5
E A 1
F B,C 4
G B,C 2
H E,F 6
I E,F 5
J D,H 3
K G,I 5

26
 Example: network
Backward LF
Forward
ES
6 20

6 19
D
2 5 5
J
1 6
0 A
6 E H 3 23
13
1 C 3
4 7
0 4 F 5
13 5
B 4 I 23
K
2
3 6
G
9 18

9 18
27
 Example: ABC Associates
• Earliest/Latest Times
Activity time ES EF LS LF Slack
A 6 0 6 0 6 0 *critical
B 4 0 4 5 9 5
C 3 6 9 6 9 0 * EF = ES + t
D 5 6 11 15 20 9 LS = LF – t
E 1 6 7 12 13 6 Where t is the
F 4 9 13 9 13 0*
G 2 9 11 16 18 7 Activity time
H 6 13 19 14 20 1
I 5 13 18 13 18 0* Slack = LF – EF
J 3 19 22 20 23 1 = LS - ES
K 5 18 23 18 23 0*
– The estimated project completion time is the Max EF at node 7 = 23.

28
PERT Chart (Program Evaluation Review Technique)
Ex: Consider a project consisting of 9 jobs (A, B, …I) with
the following relations and time estimates.
Job Predecessor Optimistic Most probable Pessimistic
Time(to) Time(tm) Time (tp)
A -- 2 5 8
B A 6 9 12
C A 6 7 8
D B,C 1 4 7
E A 8 8 8
F D,E 5 13 17
G C 3 12 21
H F, G 3 6 9
I H 5 8 11

29
 t o  4t m  t p
Expected Time = te =
6

Variance = Ve = {(tp – to) / 6 }2

Standard deviation = sqrt(Variance)

Where, to = Optimistic time

tm = Most likely time
tp = Pessimistic time

NB: tm is 4 times more likely to occur than either of the other

two. Weightage is applied to the three time estimates.
This helps to bias time estimates away from the
unrealistically short time-scales normally assumed.
30
Job Average time Standard Variance
deviation
A 5
B 9
C 7
D 4
E 8
F 13
G 12
H 6
I 8

31
 Job Average time Standard Variance
deviation
A 5 1 1
B 9 1 1
C 7 1/3 1/9
D 4 1 1
E 8 0 0
F 13 2 4
G 12 3 9
H 6 1 1
I 8 1 1

First we compute the average time from the three times given in
previous table and the variance for each one of the jobs. They are
tabulated in above table. Figure in the next slide gives the project
network, where the numbers on the arcs indicate the average job times.
Using the average job times, the earliest and latest times of each event
are calculated.
32
 (12, 14)
3
G
C
7 12

A B D F H I
1 2 4 5 6 7 8
9 4 G 13 8
5 6
(0, 0) (5, 5) (14, 14) (18, 18) (31, 31) (37, 37) (45, 45)
E
8

Network Events with Earliest and Latest Time

The critical path is found as 1245678.

Let T denotes the project duration. Then the expected

length of the project is

E(T) = sum of the expected times of jobs A,B,D,F,H and I

= 5 + 9 + 4 + 13 + 6 + 8 = 45 days.
33
Total project duration = 45 days
Total project variance = 1 + 1 + 1 + 4 + 1 + 1 = 9
The standard deviation of the project = √(9) = 3

With 1 SD there is 68% chance that the project will be completed

between 45 + 3 = 42 days to 48 days.
With 2 SD there is 95% chance that the project will be completed
between 45 + 2(3) = 39 days to 51 days.
With 3 SD there is 99.7% chance that the project will be completed
between 45 + 3 = 36 days to 54 days.

34
Example

35
 Example

Task appeared on the calculated critical path are marked out with red color. This way any person is able
to see at once tasks which require special attention.

36
Gantt Chart
This technique of using special type of bars representing
activities has been developed by Henry Gantt and named as
Gantt chart.
The Gantt chart is also known as Time-line chart.
It is a useful used to allocate resources to various activities.
Each bar, an activity, is drawn against a time line.

The shaded part of the bar is the estimated time and the white
part of the bar is called the slack time by which the activity
has to finish. Therefore the shaded part can be shifted, if
necessary, to any part to extent of the white bar limitation.

This allows the project manager to allocate resources suitably by

shifting the activity on the timeline without affecting other
activities. Many activities can start concurrently.
37
 Gantt Charts
• Visual scheduling tool
• Graphical representation of information
• Named after Henry Gantt who invented them in 1917
• Show dependencies between tasks, personnel, and other
resources allocations
• Track progress towards completion
• Depicts some of the same information as on a PERT chart
• Also depicts new information

38
Acitivity Code Description Duration (Wk) Preceedence
A Requirement analysis 1 -
B Design database 2 A
C Interface design 1.5 A
D Write SQL code for DB 2 B, C
E Write code for interface 1.5 C
F Integration and testing 5 D, E
G Documentation 1.5 A

39
 Requirement analysis
A
Design Database
C
T Interface Design
I
V Write SQL Code for Database
I
T Write Code for Interface
I Integration and Testing
E
S
Documentation

1 2 3 4 5 6 7 8 9 10 11 weeks

Gantt Chart for Software Development

40
 Gantt Charts
 Establish a time-phased network
 Can be used as a tracking tool

Benefits of Gantt charts

1. Easy to create and comprehend
2. Identify the schedule baseline network
3. Allow for updating and control
4. Identify resource needs
41
 RISK MANAGEMENT
A risk is any anticipated unfavorable
event or circumstance that can occur
while a project is underway.
•It may adversely affect the project to complete in
time
•The project manager to anticipate and identify
•Contingence plans need to be prepared to reduce
the impact of risk
Three essential Activities: Risk Identification, Risk
Assessment, Risk Mitigation

42
Risk Identification
Early Risk identification is important. The project
manager can examine the diff. classes of risks.
•Project risks
concerns about budgets, schedule, personnel,
resource, customer related problems
•Technical risks
potential design, implementation, interfacing, testing,
and maintenance, ambiguous specification,
changing specification, technical uncertainty, technical
obsolescence
•Business risk
building an excellent product that no one wants,
losing budgetary commitments
43
Risk Assessment
Rank the risks in terms of their damage causing potential
r = likelihood of a risk becoming real (probability)
s = sequence of problems associated (severity of
damage caused due the risk becoming real)
p = priority of risk = r * s

If all the identified risks are priortised, then most likely the
damaging risks can be handled and risk abatement
procedure can be designed to handle the risks.

44
Risk Mitigation
•Avoid the risk
Process related risks (work schedule, budget, resource
utilization)
•Transfer risk
(development by third party, insurance cover)
•Risk reduction
(consider the cost handling risk and the corresponding
reduction of risk, compute risk coverage)

Risk leverage = (risk exposure before reduction – risk

exposure after reduction) / cost of reduction

45
 Software Change Management
• refers to the process of managing changes in software
applications and systems.
• It ensures that changes are introduced in a controlled and
coordinated manner, minimizing disruptions and maintaining
system integrity.
• This process is crucial for maintaining software quality and
reliability, especially in complex and large-scale systems.
• helps organizations adapt to new requirements, fix bugs, and
improve system functionality while minimizing risks and
ensuring system stability.
• It is a crucial part of software development and IT operations,
particularly in environments that require high reliability and
security.
 Key aspects of Software Change
Management
• Change Request: originate from various sources, such as
customers, developers, or stakeholders. It typically describes the
desired change, its purpose, and any expected benefits.
• Change Evaluation: Before implementation, changes are
evaluated based on their impact, feasibility, and risks. This step often
involves a review by a change control board (CCB)
• Prioritization and Scheduling: Approved changes are
prioritized and scheduled based on factors like urgency, impact, and
available resources. This helps in efficient resource allocation and
planning.
• Implementation: The actual implementation of changes
involves modifying the software code, configuration, or infrastructure.
• Testing and Validation: Changes are thoroughly tested to
ensure they work as intended
 Key aspects of Software Change
Management
• Documentation: Proper documentation is crucial for
understanding the changes made, including the reason for the change,
and the expected outcome. This helps in future maintenance and audits.
• Monitoring and Review: After deployment, the changes are
monitored to ensure they operate as expected. Any issues that arise are
addressed promptly.
• Rollback and Contingency Planning: In case a change
causes issues, a rollback plan should be in place.
• Communication and Training: Stakeholders, including end-
users, developers, and support teams, should be informed about the
changes. Clear communication ensures everyone is aware of new
features, or new procedures.
 Software Configuration Management (SCM)
• SCM is a discipline within software engineering that
focuses on controlling and managing changes to
software products throughout their lifecycle.

• It ensures the integrity, traceability, and

reproducibility of software configurations.

• SCM is crucial in maintaining consistency, preventing

conflicts, and enabling efficient collaboration among
development teams.
 Software Configuration Management (SCM)
• SCM is an essential practice, especially in
environments that require frequent updates,
multiple developers, and complex software
systems.
• It supports effective project management,
reduces risks, and improves the overall quality
and reliability of software products.
• SCM is the process of controlling the evolution of
a software system
• SCM can be viewed as a quality assurance activity
 Why Software Config Mgmt?
SCM
• Simplifies sharing code and other documents
• The ability to revert to an older version (“undo”)
• Coherently integrate contributions from team members
(“merge”)
• Notify interested parties about new modifications (“reporting”)
• Track software issues (e.g., bugs)
• Create an auditing trail (“archiving”)
• SCM system allows us to answer questions:
– When was this software module last changed?
– Who made changes in this line of code?
– What is the difference between the current version and last versions?
– How many lines of code did we change in this release?
– Which files are changed most frequently?
 SCM Process
• SCM process defines a series of tasks having 4
primary objectives
– To identify all items that collectively define the s/w
configuration.
– To manage changes to one or more of these items.
– To facilitate construction of different versions of an
application.
– To ensure that s/w quality is maintained as configuration
evolves over time.
 Key Components of SCM

1. Configuration Identification
– Definition: Identifying configurations, cofiguration items and baselines.
This includes source code files, libraries, documentation, and
configuration files.
– Configuration – A collection of all the elements of a baseline and a
description of how they fit together
– Configuration item (CI) refers to the fundamental structural unit of a
configuration management system. A collection of software elements
treated as a unit for the purposes of SCM.
– Baselines: It is an agreed description of the attributes of a product, at a
point in time, which serves as a basis for defining change. A change is a
movement from this baseline state to a next state. The identification of
significant changes from the baseline state is the central purpose of
baseline identification. A baseline is a reference point.
 Configuration Identification
It involves deciding which parts of the system should be
kept track of it
•Requirement specification document
•Design document
•Tools used to build the system (compilers, linkers, lexical
analysers, parsers)
•Source code for each module
•Test cases
•Problem reports
Configuration management plan is written during the
project planning phase. It lists all control objects.
 Key Components of SCM
2. Configuration Control
– Definition: The process of managing changes to the software configuration, ensuring
that only approved changes are made. This involves:
• Change Request: Proposals for changes are submitted, documented, and
reviewed.
• Change Control Board (CCB): A group or commitee of stakeholders responsible
for approving or rejecting change requests (based on their impact, necessity, and
feasibility) that are sent against any baseline.
Restoring the changed module to the system configuration requires the permission of
a Change control board (CCB). CCB reviews the changes and certifies
1. Changes is well-motivated
2. Developer has considered and documented
3. Changes interact well with other developers
4. Appropriate people (CCB) have validated change

CCB constitutes the project manager and other senior people in the team.
Configuration control
Configuration control is the process of managing
changes to controlled objects. It allows only authorised
changes to the controlled objects to occur and prevents
authorised changes.

New baseline Baseline

A B A B

C D C D

Cancel
reservation Reserve
Restore
Private copy of
C

Reserve and restore operation in configuration control

 Key Components of SCM
3. Configuration Status Accounting
– Definition: The process of recording and reporting the status of
configuration items (CIs) throughout the lifecycle. This includes
tracking changes, versions, and baselines.
– Reporting: Provides information on what changes have been made,
by whom, when, and why, helping in audits and compliance.
4. Version Control
– Definition: Version control systems (VCS) track and manage changes
to software code and associated documentation.
– Types: There are two main types of version control systems:
• Centralized Version Control Systems (CVCS), which have a single, central
repository.
• Distributed Version Control Systems (DVCS): full copy of the repository,
including its entire history.
(C) Version Control
• Object 1.0 undergoes revision

– Object 1.0 -> Object 1.1

• If minor changes/corrections introduced to Object
1.1

– Object 1.1.1 & 1.1.2 (variants)

• Functional changes, new modules added to Object
1.1 can lead to

– Object 1.1 ->Object 1.2

• Major Technical Change

– Object 1.0 ->Object 2.0

 Key Components of SCM
5. Configuration Audits
– Definition: The process of verifying that the software configuration items are
consistent with their documentation and meet specified requirements.
– Types:
• Functional Configuration Audit (FCA): Ensures that the software performs the
functions described in its specifications.
• Physical Configuration Audit (PCA): Verifies that the software and its
documentation are complete and accurate.
6. Build Management
– Definition: The process of compiling and linking source code into executable
software. This involves automating the build process, managing build scripts, and
ensuring that the correct versions of source code and dependencies are used.
– Continuous Integration (CI): An SCM practice where developers frequently integrate
their code changes into a shared repository, followed by automated builds and
tests. This helps in detecting issues early in the development process.
 Key Components of SCM
7. Release Management
– Definition: The process of managing, planning, and scheduling the deployment of
software releases. It includes preparing release notes, packaging the software, and
deploying it to the production environment.
– Versioning: Assigning version numbers to releases to identify different stages of the
software's evolution (e.g., alpha, beta, release candidates, final releases).
8. Environment Management
– Definition: The management of different environments (development, testing,
production) in which the software operates.
9. Backup and Recovery
– Definition: Implementing strategies for backing up software configurations and
ensuring that they can be recovered in case of data loss or corruption.
 Benefits of SCM
• Consistency: Ensures that all developers are working with the
same versions of software components.
• Traceability: Provides the ability to trace changes back to their
origins, understanding who made changes and why.
• Collaboration: Facilitates collaboration among multiple
developers and teams, reducing the chances of conflicts.
• Quality Assurance: Helps maintain the quality of the software
by ensuring that changes are properly reviewed and tested before
being integrated.
• Compliance: Assists in meeting regulatory and compliance
requirements by maintaining accurate records of software
configurations and changes.
 Key Differences of Software Change Management
and cofiguration management
• Scope: SCM has a broader scope, covering all aspects of managing
software artifacts, while Software Change Management focuses
specifically on changes to the software.

• Activities: SCM includes configuration identification, control, status

accounting, and audit. Software Change Management deals specifically
with the process of handling change requests, impact analysis,
approval, implementation, and verification.

• Goal: The goal of SCM is to maintain the integrity and traceability of

the software throughout its lifecycle. The goal of Software Change
Management is to ensure that changes are introduced smoothly, with
minimal disruption and maximum benefit.
 Key Differences of Software Change Management
and cofiguration management
• In summary, Software Change Management is a component of the
broader Software Configuration Management process. Software
Change Management is a subset of Software Configuration
Management.

• Software Change Management focused specifically on managing the

process of making changes to software systems. It deals with the
identification, assessment, and implementation of changes to the
software. Change Management focuses on the controlled introduction
of changes to those artifacts. While SCM ensures overall consistency
and integrity of software artifacts,