Software Project

Management
(Continued…) Lecture 10

Dr. R. Mall

1
Organization of this
Lecture
 Overview of Last Lecture
 Staffing
 Scheduling
 Risk Management
 Configuration Management
 Summary

2
Overview of Last Lecture
 Last lecture we discussed the
broad responsibilities of the
project manager:
 Project planning
 Project Monitoring and Control
 Cost estimation is an important
part of project planning.

3
Overview of Last Lecture
 To estimate software cost:
 Determine size of the product.
 Using size estimation,
 determine effort needed.
 From the effort estimation,
 determine project duration, and
cost.

4
Overview of Last Lecture
(CONT.)

 Cost estimation techniques:

 Empirical Techniques
 Heuristic Techniques
 Analytical Techniques
 Empirical techniques are based on
systematic guesses made by experts:
 Expert Judgement
 Delphi Estimation

5
Overview of Last Lecture
(CONT.)

 Heuristic techniques:
 assume that different product
parameters are related through a
simple mathematical expression:
 COCOMO
 Analytical techniques:
 derive the estimates starting with
some basic assumptions
 Halstead's Software Science

6
Overview of Last Lecture
(CONT.)

 Staffing level during the life cycle of

a software product:
 follows the Rayleigh curve:
 Maximum number of engineers required
during testing.
 Number of engineers at any phase depends
on the number of parallel activities possible.
 The relationship between schedule
change and effort is highly nonlinear.

7
Overview of Last Lecture
(CONT.)

 Team organization:
 Chief programmer: Suitable for
routine development work.
 Democratic: Suitable for small
teams doing R&D type work.
 Mixed: Suitable for large
organizations.

8
Staffing
 Project Managers usually
take responsibility for
choosing their team:
 need to identify and select
good software engineers for
the success of the project.

9
Staffing
 A common misconception:
 one software engineer is as productive as
another:
 Experiments reveal:
 a large variation in productivity between
the worst and best in a scale of 1 to 10.
 Worst engineers even help reduce the
overall productivity of the team
 in effect exhibit negative productivity.

10
Who is a Good Software
Engineer?
 Good programming abilities
 Good knowledge of the project areas (Domain)
 Exposure to Systematic Techniques
 Fundamental Knowledge of Computer Science
 Ability to work in a team
 Intelligence
 Good communication skills:
 Oral
 Written
 Interpersonal
 High Motivation

11
Who is a Good Software
Engineer? (cont.)

 Studies show:
 these attributes vary as much as
1:30 for poor and bright candidates.
 Technical knowledge in the area of
the project (domain knowledge) is
an important factor, determines:
 productivity of an individual
 quality of the product he develops.

12
Who is a Good Software
Engineer? (cont.)

 A programmer having
thorough knowledge of
database applications (e.g
MIS):
 may turn out to be a poor data
communication engineer.

13
Scheduling
 Scheduling is an important activity for the
project managers.
 To determine project schedule:
 Identify tasks needed to complete the project.
 Determine the dependency among different
tasks.
 Determine the most likely estimates for the
duration of the identified tasks.
 Plan the starting and ending dates for various
tasks.

14
Work Breakdown
Structure
 Work Breakdown Structure (WBS) provides a
notation for representing task structure:
 Activities are represented as nodes of a tree.
 The root of the tree is labelled by the problem name.
 Each task is broken down into smaller tasks and
represented as children nodes.
 It is not useful to subdivide tasks into units
which take less than a week or two to execute.
 Finer subdivisions mean that a large amount of time
must be spent on estimating and chart revision.

15
Work Breakdown
Structure
Compiler Project

Requirements Design Code Test Write Manual

Lexer Parser Code Generator

16
Activity Networks
 WBS structure can be refined into an
activity network representation:
 Network of boxes and arrows
 shows different tasks making up a project,
 represents the ordering among the tasks.
 It is important to realize that
developing WBS and activity network
 requires a thorough understanding of the
tasks involved.

17
Activity Network
Code Lexer

Design Code Parser

Requirements Code Code Generator Test

Write Manual

18
Gantt Charts
 Named after its developer
Henry Gantt.
 a form of bar chart:
 each bar represents an activity,
 bars are drawn against a time line,
 length of each bar is proportional
to the length of time planned for
the activity.

19
Gantt Charts
 Gantt charts are not specific to software
engineering.
 Gantt charts used in software project
management are:
 enhanced version of standard Gantt charts.
 colored part of a bar shows the length of
time a task is estimated to take.
 white part shows the slack time,
 the latest time by which a task must be finished.

20
Gantt Chart
Requirements

Design
Code Lexer

Code Parser

Code Code Generator

Test

Write Manual

21
Scheduling
 Many managers believe
 an aggressive schedule motivates
the engineers to do a better and
faster job.
 However, careful experiments show:
 unrealistic aggressive schedules cause
engineers to compromise on intangible
quality aspects,
• also cause schedule delays.

22
Scheduling
 A good way to achieve accuracy:
 let people set their own schedules.
 Schedule for a large-sized task may take
too long:
 Managers need to break large tasks into
smaller ones to find more parallelism
 can lead to shorter development time.
 Small-sized tasks help in better tracking

23
Critical Path
 Task dependencies define a partial
ordering among tasks, i.e.
 Completion of some tasks must precede the
starting time of some other tasks.
 A critical path:
 along which every milestone is critical to
meeting the project deadline.
 A Critical Path is a chain of tasks that
determine the duration of the project.

24
Critical Paths
 A critical paths is sequence of tasks such
that
 a delay in any of the tasks will cause a delay to
the entire project.
 There can be more than one critical path in a
project.
 It is important for the project manager to be
aware of the critical paths in a project:
 can ensure that tasks on these paths are
completed on time.

25
Critical Paths
 Other tasks may have some room for delay
without affecting the entire project.
 If necessary, the manager may switch
resources from a noncritical task to a critical
task.
 Several software packages are available
for automating the scheduling process:
 MacProject on Apple Macintosh computer
 MS-Project on Microsoft Windows Operating
System.

26
CPM and PERT Charts
 While Gantt charts show the
different tasks and their
durations clearly:
 they do not show intertask
dependencies explicitly.
 this shortcoming of Gantt charts
is overcome by PERT charts.

27
Critical Path Management
 Critical Path Management(CPM) is
a technique for:
 Identifying critical paths
 Managing project.
 The CPM technique is not specific
to software engineering
 has a much wider use.

28
Critical Path Management
 CPM can assist in answering
questions like:
 What are the critical paths in the
project?
 What is the shortest time in which the
project can be completed?
 What is the earliest (or latest) time a
task can be started (or finished) without
delaying the project?

29
Example
 A project involves three tasks:
 task a takes 4 hours,
 task b takes 5 hours
 task c takes 8 hours.
 task c cannot commence until task a is completed.
 What is the shortest time in which the project
can be completed?
b
start 5 finish

4 a c
8

30
Example
 Clearly, the project continues until task
a and then task c complete:
 which is 12 hours.
 Task b takes only 5 hours.
 Task b can have 7 hours of leeway to start
and finish.
b
start 5 finish

4 a c
8

31
What data do we need to construct a
CPM graph?
 To construct a CPM graph,
 a list of tasks and their durations are
required.
 Also, for each task a list of tasks upon
which it depends is required.
 A task may depend on more than one
task.
 Project task details can be given in the
form of a table.

32
Task Table
 Task Duration Dependents
a 10
b 20
c 20 a,g
d 5 b
e 10 b
f 5 h

33
CPM Graph
c:20

a:10

start finish
g:5
b:20 f:5
d:10

e:10

34
How do we work out the various start and
finish times for tasks?
 Minimum time to complete project (MT) =
Maximum of all paths from start to finish
 Earliest start time (ES) of a task = Maximum of
all paths from start to this task
 Earliest finish time (EF) of a task = ES +
duration of the task
 Latest finish time (LF) of a task = MT -
Maximum of all paths from this task to finish
 Slack time = LS - ES = LF - EF

35
Start and finish times for
tasks.
 Latest start time (LS) of a task = LF - duration
of the task
Task MT EF ES LF LS
a 10 0 10 15 5
b 20 0 20 25 0
c 20 10 30 35 15
d 5 20 25 30 25
e 10 20 30 30 20
f 5 0 5 15 10

36
What are the float time (or slack time)
of tasks?
 Float time (or slack time) is the total
time that a task may be delayed
 before it will affect the end time of the
project.
 The float times indicate the "flexibility"
in starting and completion of tasks:
 A critical activity is an activity with zero
(0) slack or float time.

37
What is PERT and how
does it work?
 PERT (Program Evaluation and Review
Technique) is a variation of CPM:
 incorporates uncertainty about duration of tasks.
 Gantt charts can be derived automatically from
PERT charts.
 Gantt chart representation of schedule is
helpful in planning the utilization of resources,
 while PERT chart is more useful for monitoring the
timely progress of activities.

38
Risk Management
 A risk is any unfavourable event or
circumstance:
 which might hamper successful or timely
completion of a project.
 Risk management:
 concerned with the reduction of the impact of
risks.
 Risk management consists of three activities:
 risk identification,
 risk assessment, and
 risk containment.

39
Risk identification
 To be able to identify various risks:
 we must categorize risks into different
classes.
 Three main categories of risks can
affect a software project:
 project risks
 technical risks
 business risks

40
Project Risks
 Project risks associated with:
 budget,
 schedule,
 personnel,
 resource, and
 customer problems.

41
Technical Risks
 Technical risks concern:
 requirements specification
 (e.g ambiguous, incomplete, changing
specifications)
 design problems,
 implementation problems,
 interfacing problems,
 testing, and maintenance problems.
 technical uncertainty, and technical
obsolescence are technical risk factors too.

42
Business Risks
 Business Risks include:
 building an excellent product that no one
wants,
 losing budgetary or personnel commitments, etc.
 It is a good idea to have a “company
disaster list”,
 a list of all bad things that have happened in the
past
 project managers can jog their mind to see which
items their project is vulnerable to.

43
Risk assessment
 Objective of risk assessment is to
prioritize the risks:
 Likelihood of a risk being real.
 Consequence of the problems
associated with that risk.
 Prioritization helps in handling the most
damaging risks first.
 Priority of a risk is the product of the
likelihood of the risk and the consequences of
the problems associated with that risk.

44
Risk Handling
 Three main strategies for risk handling:
 Avoid the risk: e.g. change the requirements
for performance or functionality.
 Transfer the risk: allocate risks to third
party
 or buy insurance to cover any financial loss
should the risk become a reality.
 Contingency planning: Prepare contingency
pans to minimize the impact of the risk.

45
Risk Handling
 To decide about risk
handling options, we
must take into account:
 cost of reducing risk
 resulting cost saving from
risk reduction.

46
Risk Containment
 Let us see how we can contain an
important type of risk:
 schedule slippage
 can be dealt with by increasing the visibility
of the project.
 Milestones are placed at regular
intervals
 provide a manager with regular
indication of progress.

47
Containing Schedule
Slippage
 A milestone is reached,
 when documentation
produced has
successfully been
reviewed.

48
Software Configuration
Management
 The results (aka deliverables) of any
large software development effort
consists of a large number of objects:
 source code,
 design document,
 SRS document,
 test document,
 project plan (SPMP) document, etc.

49
Software Configuration
Management (CONT.)
 A configuration is a collection of
deliverables:
 being developed for some customer.
 As development proceeds,
 the components comprising a
configuration undergo changes:
 Even during maintenance, the
components comprising a configuration
keep changing.

50
What is configuration
management?
 The set of activities through
which the configuration
items are managed and
maintained
 as the product undergoes its
life cycle phases.

51
Versions
 A configuration for a particular
system is called a version:
 The initial delivery might consist of
several versions,
 more versions might be added later on.
 For example, one version of a
mathematical package might run on a
Unix machine,
 another on Windows NT, and
 another on Solaris.

52
Versions
 As a software is released and used by the
customers:
 errors are discovered,
 enhancements to the functionalities might be
needed.
 A new release of the software is an
improved system intended to replace an old
one.
 Usually a product is described as version m
and release n (or as version m.n)

53
Software Configuration
Management
 Existence of variants of a
software product causes several
problems.
 Suppose you have several
versions of the same module, and
 find a bug in one of them.
 it has to be fixed in all versions.

54
Software Configuration
Management
 Different objects are accessed and
modified by a number of
engineers.
 Unless strict discipline is enforced:
 regarding updation and storage of
the objects through some automated
tool,
 several problems appear.

55
Software Configuration
Management
 For example, an engineer might update
the module that he has designed ---
 without informing the engineers who need
to interface with this module.
 Or, two engineers may simultaneously
carry out changes to different portions
of a module:
 while saving overwrite each other.

56
Why Configuration
Management?
 To be able to identify the exact state of different
deliverables at any time.
 To avoid the problems associated with having replicated
objects accessible by multiple engineers.
 Controlling concurrent work on a module by different
engineers. (Overwriting one engineer’s work by another)
 Letting different engineers work on related modules at
the same time.
 Keeping track of variants (versions) and helping fix bugs
in them.
 Storing versions and revisions efficiently.
 Maintaining revision history (accounting).

57
Software Configuration
Management
 Configuration management helps to:
 quickly determine the current state of the
product
 change the various components
(modifications, revisions, variations etc.)
in a controlled manner.
 maintaining the current up-to-date status
of various versions of the software,
 control and account changes to the
product.

58
Software Configuration Management
Activities
 Configuration management is
carried out through three
principal activities:
 configuration identification,
 configuration control,
 configuration accounting and
reporting.

59
Software Configuration
Management Activities
 Configuration identification
 which parts of the system must be
kept track of?
 Configuration control
 ensures that changes to a component
happen smoothly.
 Configuration accounting
 keeps track of what has been
changed, when, and why.

60
Configuration
Identification
 Deliverable objects can be classified
into three main categories:
 controlled,
 precontrolled,
 uncontrolled.
 Controlled objects are under
configuration control:
 you must follow some formal procedures to
change them.

61
Configuration
Identification
 Precontrolled objects are not
yet under configuration control,
 but may eventually be under
configuration control.
 Uncontrolled objects are not
and will not be subject to
configuration control.

62
Configuration
Identification
 Typical controllable objects include:
 Design documents
 Tools used to build the system, such as
compilers, linkers, lexical analyzers,
parsers, etc.
 Source code for each module
 Test cases
 Problem reports

63
Configuration Control
 Configuration control is the process of
managing changes.
 It is the part of configuration
management that most directly affects
day-to-day operations of the developers.
 Once an object goes under
configuration control,
 any further changes requires approval
from a change control board (CCB).

64
Configuration Control
 The CCB is constituted from among
the development team members.
 For every change carried out,
 CCB certifies several things about the
change:
 Change is well-motivated.
 Developer has considered and documented
the effects of change.
 Appropriate people have validated the
change.

65
Configuration Control
 An important reason for configuration control:
 people need a stable environment to develop a
software product.
 Suppose you are trying to integrate module A,
with the modules B and C,
 you cannot make progress if developer of module C
keeps changing it;
 this is especially frustrating if a change to module C
forces you to recompile A.
 As soon as a document under configuration
control is updated,
 the updated version is frozen and is called a baseline.

66
Configuration Control
Baseline New Baseline

A B A B

C D C’ D

Reserve
Replace

Cancel Reservation

C
Private Copy

67
Configuration Control
 This establishes a baseline for others to use.

 Freezing a configuration may involve

archiving everything needed to rebuild it.
 Archiving means copying to a safe place such as
a magnetic tape.
 At any given time, a programmer may pay
attention to:
 Current baseline configuration
 Programmer's private version

68
SCCS (Source Code Control
System)
 SCCS is a configuration
management tool:
 available on Unix systems:
 helps control and manage text files.
 also implements an efficient way of
storing versions:
 minimizes the amount of occupied disk
space.

69
SCCS
 Suppose a module is present in 3
versions:
 MOD1.1, MOD1.2, and MOD1.3.
 SCCS stores the original module
MOD1.1
 together with changes needed to
transform it into MOD1.2 and MOD1.3.
 the modifications are called deltas.

70
SCCS Features
 Access control facilities provided by SCCS
include:
 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.

71
SCCS Features
 Revisions are denoted by numbers
in ascending order,
 e.g, 1.1, 1.2, 1.3 etc.
 It is also possible to create
variants of a component
 by creating a fork in the development
history.

72
Summary
 Project staffing requires careful
understanding of the attributes of good
software engineers.
 Project scheduling:
 break down large tasks into smaller logical
units,
 determine dependencies among tasks,
 determine expected duration of tasks,
 assign resources, and
 assign times.

73
Summary
 Several techniques are available to
help in scheduling:
 Work breakdown structure
 Activity networks
 Gantt charts
 PERT and CPM
 Commercial software tools are
available to assist in developing these.

74
Summary
 It is necessary to determine the
critical paths in a project:
 to meet the timing for critical activities.
 An important project planning
activity is risk management:
 Risk identification
 Risk assessment
 Risk containment

75
Summary
 Configuration
management.
 the set of activities by
which a large number of
objects are managed and
maintained.

76