Software Project

Management
(Continued…)
Staffing
● Project Managers usually
take responsibility for
choosing their team:
●need to identify and select
good software engineers for
the success of the project.

2
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.

3
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

4
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.

5
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.

6
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.
7
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.

8
Work Breakdown
Structure
Compiler Project

Requirements Design Code Test Write Manual

Lexer Parser Code Generator

9
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.

10
Activity Network
Code Lexer

Design Code Parser

Requirements Code Code Generator Test

Write Manual

11
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.

12
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.
13
Gantt Chart
Requirements

Design
Code Lexer

Code Parser

Code Code Generator

Test

Write Manual

14
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.

15
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

16
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.

17
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.
18
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. 19
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.

20
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.

21
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?

22
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

23
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

24
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.
25
Task Table
● Task Duration Dependents
a 10
b 20
c 20 a,g
d 5 b
e 10 b
f 5 d,e
g 5

26
CPM Graph
c:20

a:10

star finish
g:5
t
b:20 f:5
d:10

e:10

27
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

28
Start and finish times for
tasks.
● Latest start time (LS) of a task = LF - duration
of the task
Task MT ES EF LF LS

a 10 0 10 15 5

b 20 0 20 25 0

c 20 10 30 35 15

d 10 20 30 30 25

e 10 20 30 30 20

f 5 30 5 15 10
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.

30
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.

31
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.
32
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

33
Project Risks
● Project risks associated
with:
●budget,
●schedule,
●personnel,
●resource, and
●customer problems.
34
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.

35
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.
36
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.

37
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.

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

39
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.

40
Containing Schedule
Slippage
●A milestone is reached,
●when documentation
produced has
successfully been
reviewed.

41
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.
42
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.

43
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.

44
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.
45
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)

46
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.
47
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.

48
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.

49
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).

50
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. 51
Software Configuration Management
Activities
● Configuration management is
carried out through three
principal activities:
● configuration identification,
● configuration control,
● configuration accounting and
reporting.

52
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.

53
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.

54
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.
55
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

56
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).

57
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.
58
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.

59
Configuration Control
Baseline New Baseline

A B A B

C D C’ D

Reserve
Replace

Cancel Reservation

C
Private Copy

60
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
61
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.

62
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.

63
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.
64
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.

65
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.

66
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.
67
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
68
Summary
●Configuration
management.
●the set of activities by
which a large number of
objects are managed and
maintained.

69