 Project Planning

 Project Scheduling
 Risk Management

1
 Introduction.
 Software project management is aimed to ensure that the software is
delivered on time, within budget and schedule constraints, and satisfies
the requirements of the client
 Management of software projects is different from other types of
management because:
● Software is not tangible
● Frequently problems too complex or expensive to solve in the electronics are
passed off to the developers
 E,g- position of a satellite relative to a star.
● Computer technology evolves very rapidly
 there may be frequent changes in the requirements description
 User are geographically distributed , so tk time to complete project
 Lack of domian knowledge therefore difficult to plan for managers

2
 .Introduction

 Management activities:
● Writing proposals
● Planning the project
● Scheduling the project
● Estimating the cost of the project
● Monitoring and reviewing the project’s progress
● Selecting, hiring, and evaluating personnel
● Writing reports and giving presentations

3
 Project Planning…

 A project plan should be drawn at the start of the project. This plan
drives the project and needs to be continuously adjusted
 The role of the project manager is to anticipate possible problems
and be prepared with solutions for these problems
 Other plans that need be developed:
● Quality plan
● Validation and verification plan
● Configuration management plan
● Maintenance plan
● Staff development plan

4
 .Project Planning..
 The planning process
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelledloop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise )then
Initiate technical review and possible revision
end if
end loop

5
 ..Project Planning.
 The structure of the project plan:
● Introduction (objectives, constraints)
● Project organization (team structure, personnel involved, roles)
● Risk analysis (types of risk, probabilities, solutions to prevent or
reduce the risk)
● Hardware and software resources needed (prices, delivery schedule)
● Work breakdown (activities, milestones, deliverables)
● Project schedule (dependencies between activities/tasks, work
assignments, time allocated per task)
● Monitoring and reporting mechanisms (reports, dates)

6
 …Project Planning
 Milestone = end-point of a specific, distinct software process
activity or task (for each milestone a report should be presented
to the management)
 Deliverable = project result delivered to the client
 In order to establish milestones the phases of the software
process need be divided in basic activities/tasks. Example for
requirements engineering [Fig. 5.3, SE-8]
ACT IVITIES

Feasibility Requir ements Prototype Design Requir ements

study analysis development study specification

Feasibility Requir ements Evaluation Architectural Requir ements

report definition report design specification

MILESTONES
7
 Project Scheduling……

 Software managers:
● Divide the project in activities/tasks
● Estimate time and resources needed to finish the project
● Allocate resources to tasks
● Try to employ efficiently all the project personnel
● Minimize dependencies between tasks and teams
● Prepare contingency plans
● Rely on experience and intuition

8
 .Project Scheduling…..
 The scheduling process

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts

Software Activity charts

requirements and bar charts

9
Scheduling problems

Estimating the difficulty of problems and hence
the cost of developing a solution is hard

Productivity is not proportional to the number of
people working on a task

Adding people to a late project makes it later
because of communication overheads

The unexpected always happens. Always allow
contingency in planning

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 10

 ..Project Scheduling….
 Graphical notations used in software
project scheduling:
● Tables: summary description of tasks
● Bar charts: show schedule against the time
● Activity charts: graphs that depict dependencies
between tasks and indicate the critical path (the
longest path in the activity graph)

11
Bar charts and activity
networks

Graphical notations used to illustrate the project
schedule

Show project breakdown into tasks. Tasks should
not be too small. They should take about a week
or two

Activity charts show task dependencies and the
the critical path

Bar charts show schedule against calendar time

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 12

 …Project Scheduling…
 Example of tabular description

Task Duration (days) Dependencies

T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)

13
 ….Project Scheduling..
 Example of activity chart
14/7/03 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/03 25/8/03
25/7/03
4/7/03 T6 M4 M6
M3
start 20 days 7 days
15 days
T7 T11
T2
25/7/03 11/8/03 5/9/03
10 days 10 days
M2 M7 M8
T4 T5 15 days
T10 10 da
ys
18/7/03
T12
M5
25 days
T8 Finish
14
19/9/03
 …..Project Scheduling.
 Example of bar chart

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
15 Finish
 ……Project Scheduling
 Staff allocation chart

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5

16
 Risk Management…….
 Risk = some adverse circumstance that may
happen and affect negatively the project, the
product, and/or the business
 Categories of risk:
● Project risks
● Product risks
● Business risks
 Risk management means anticipating risks and
preparing plans to reduce their effect

17
 .Risk Management……
 Examples of risks in the software process

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be
delivered on schedule.
Requirements change Project and There will be a larger number of changes to the
product requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not available on
product schedule
Size underestimate Project and The size of the system has been underestimated.
product
CASE tool under- Product CASE tools which support the project do not perform as
performance anticipated
Technology change Business The underlying technology on which the system is built is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is
completed.
18
The risk management process

Risk identification
• Identify project, product and business risks

Risk analysis
• Assess the likelihood and consequences of these risks

Risk planning
• Draw up plans to avoid or minimise the effects of the risk

Risk monitoring
• Monitor the risks throughout the project

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 19

 …Risk Management….
 Types of risk in risk identification

Risk type Potential indicators

Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects

20
 ….Risk Management…
 Risk analysis:
● Estimate risk probability:
 Very low (< 10%)
 Low (10-25%)

 Moderate (25-50%)

 High (50-75%)

 Very high (> 75%)

● Establish risk seriousness:

 Insignificant

 Tolerable

 Serious
 Catastrophic

21
Risk analysis
Risk Probability Effects
Organisational financial problems force Low Catastrophic
reductions in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
required for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
design rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
The database used in the system cannot process Moderate Serious
as many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 22

 …..Risk Management..

 Risk planning means preparing a strategy

to deal with each of the risks identified
 Classes of strategies:
● Avoidance strategies: the probability of the risk
will be diminished
● Minimization strategies: the effect of the risk will
be reduced
● Contingency strategies: plans for the worst case
scenarios

23
 ……Risk Management.
 Examples of risk management strategies
Risk Strategy
Organisational Prepare a briefing document for senior management
financial problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-
components in components of known reliability.

Risk Strategy
Requirements Derive traceability information to assess requirements
changes change impact, maximise information hiding in the
design.
Organisational Prepare a briefing document for senior management
restructuring showing how the project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate buying in components, investigate use of a
development time program generator
24
 …….Risk Management
 Risk monitoring:
● Frequently re-assess the risks
 Changes in risk probability?
 Changes in risk gravity?

● Take into consideration risk factors

● Discuss key risks at each management project
progress meeting

25
Risk factors

Risk type Potential indicators

Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational organisational gossip, lack of action by senior management
Tools reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements many requirements change requests, customer complaints
Estimation failure to meet agreed schedule, failure to clear reported
defects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 26