software project management (continued…) lecture 10
DESCRIPTION
Software Project Management (Continued…) Lecture 10. Dr. R. Mall. Organization of this Lecture. Overview of Last Lecture Staffing Scheduling Risk Management Configuration Management Summary. Overview of Last Lecture. - PowerPoint PPT PresentationTRANSCRIPT
1
Software Project Management (Continued…) Lecture 10
Dr. R. Mall
2
Organization of this LectureOverview of Last LectureStaffingSchedulingRisk ManagementConfiguration ManagementSummary
3
Overview of Last LectureLast 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.
4
Overview of Last LectureTo estimate software cost:
Determine size of the product.
Using size estimation, determine effort needed.
From the effort estimation,determine project duration, and cost.
5
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
6
Overview of Last Lecture (CONT.)
Heuristic techniques: assume that different product
parameters are related through a simple mathematical expression:
COCOMOAnalytical techniques:
derive the estimates starting with some basic assumptions
Halstead's Software Science
7
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.
8
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.
9
StaffingProject Managers usually take responsibility for choosing their team: need to identify and select good software engineers for the success of the project.
10
StaffingA 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.
11
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
12
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.
13
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.
14
SchedulingScheduling 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.
15
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.
16
Work Breakdown Structure
Compiler Project
Lexer
DesignRequirements Code Test Write Manual
Parser Code Generator
17
Activity NetworksWBS 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.
18
Activity NetworkCode Lexer
Requirements Test
Write Manual
Code Parser
Code Code Generator
Design
19
Gantt ChartsNamed 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.
20
Gantt ChartsGantt 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.
21
Gantt ChartRequirements
Design
Code Lexer
Code Parser
Code Code Generator
Test
Write Manual
22
SchedulingMany 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.
23
SchedulingA 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
24
Critical PathTask 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.
25
Critical PathsA 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.
26
Critical PathsOther 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.
27
CPM and PERT ChartsWhile 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.
28
Critical Path ManagementCritical 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.
29
Critical Path ManagementCPM 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?
30
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?
startb
a cfinish5
48
31
ExampleClearly, 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.start
b
a cfinish5
48
32
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.
33
Task Table Task Duration
Dependents a 10b 20c 20 a,gd 5 be 10 bf 5 h
34
CPM Graph
start finisha:10
c:20
f:5d:10
e:10
b:20
g:5
35
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
36
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 0c 20 10 30 35 15d 5 20 25 30 25e 10 20 30 30 20f 5 0 5 15 10
37
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.
38
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.
39
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.
40
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
41
Project RisksProject risks associated with: budget, schedule, personnel, resource, and customer problems.
42
Technical RisksTechnical 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.
43
Business RisksBusiness 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 “company disaster list”, 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.
44
Risk assessmentObjective 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.
45
Risk HandlingThree 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.
46
Risk HandlingTo decide about risk handling options, we must take into account: cost of reducing risk resulting cost saving from risk reduction.
47
Risk ContainmentLet 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.
48
Containing Schedule SlippageA milestone is reached, when documentation produced has successfully been reviewed.
49
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.
50
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.
51
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.
52
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.
53
VersionsAs a software is released and used by
the customers: errors are discovered, enhancements to the functionalities might be
needed.A new releasenew 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)
54
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.
55
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.
56
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.
57
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).
58
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.
59
Software Configuration Management ActivitiesConfiguration management
is carried out through three principal activities: configuration identification, configuration control, configuration accounting and
reporting.
60
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.
61
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.
62
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.
63
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
64
Configuration ControlConfiguration 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).
65
Configuration ControlThe 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.
66
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.
67
Configuration Control
A
C
B
D
A B
C’ D
C
Baseline
Private Copy
New Baseline
Reserve Replace
Cancel Reservation
68
Configuration ControlThis 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
69
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.
70
SCCSSuppose 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.
71
SCCS FeaturesAccess 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.
72
SCCS FeaturesRevisions 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.
73
SummaryProject 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.
74
SummarySeveral 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.
75
SummaryIt 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
76
SummaryConfiguration management. the set of activities by which a large number of objects are managed and maintained.