Beruflich Dokumente
Kultur Dokumente
Project Management
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide1
Project management
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide2
Objectives
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide3
Topics covered
Management activities
Project planning
Project scheduling
Risk management
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide4
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide5
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide6
Management activities
Proposal writing
Project planning and scheduling
Project costing
Project monitoring and reviews
Personnel selection and evaluation
Report writing and presentations
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide7
Management commonalities
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide8
Project staffing
Project budget may not allow for the use of highly-paid staff
Staff with the appropriate experience may not be available
An organisation may wish to develop employee skills on a
software project
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide9
Project planning
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide10
IanSommerville2000
Description
Describesthequality
proceduresand
standardsthatwillbeusedinaproject.
Describes theapproach,resourcesand
scheduleusedforsystemvalidation.
Describes theconfigurationmanagement
proceduresandstructurestobeused.
Predictsthe maintenancerequirementsof
thesystem,maintenancecostsand
effort
required.
Describeshowtheskillsand experienceof
theprojectteam
memberswillbe
developed.
SoftwareEngineering,6thedition.Chapter4
Slide11
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide12
Introduction
Project organisation
Risk analysis
Hardware and software resource requirements
Work breakdown
Project schedule
Estimated Cost
Actual Cost
Monitoring and reporting mechanisms
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide13
Activity organization
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide14
Requir ements
analysis
Prototype
development
Design
study
Requir ements
specification
Feasibility
report
Requir ements
definition
Evaluation
report
Architectural
design
Requir ements
specification
MILESTONES
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide15
Project scheduling
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide16
Identify
activities
Identifyactivity
dependencies
Estimateresources
foractivities
Allocatepeople
toactivities
Software
requirements
IanSommerville2000
Createproject
charts
Activitycharts
andbarcharts
SoftwareEngineering,6thedition.Chapter4
Slide17
Scheduling problems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide18
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide19
Duration(days)
8
15
15
10
10
5
20
25
15
15
7
10
Dependencies
T1(M1)
T2,T4(M2)
T1,T2(M3)
T1(M1)
T4(M5)
T3,T6(M4)
T5,T7(M7)
T9(M6)
T11(M8)
SoftwareEngineering,6thedition.Chapter4
Slide20
Activity network
8days
15days
M1
T3
15days
T9
T1
25/7/99
4/7/99
start
14/7/99
M3
5days
4/8/99
25/8/99
T6
M4
M6
7days
20days
15days
T7
T2
25/7/99
10days
M2
T4
T11
10days
M7
T5
5/9/99
11/8/99
T10
18/7/99
M8
15days
10days
T12
M5
25days
T8
Finish
19/9/99
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide21
Activity timeline
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
Finish
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide22
Staff allocation
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
12/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne T2
T6
Jim
Mary
IanSommerville2000
T10
T7
T5
SoftwareEngineering,6thedition.Chapter4
Slide23
19/9
Risk management
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide24
Software risks
Risk
Staffturnover
Risktype
Project
Managementchange
Project
Hardwareunavailability
Project
Requirementschange
Projectand
product
Specificationdelays
Projectand
product
Projectand
product
Product
Sizeunderestimate
CASEtoolunder
performance
Technologychange
Productcompetition
IanSommerville2000
Business
Business
Description
Experiencedstaffwillleavethe
projectbeforeitisfinished.
Therewillbeachangeof
organisationalmanagementwith
differentpriorities.
Hardwarewhichisessentialforthe
projectwillnotbedeliveredon
schedule.
Therewillbealargernumberof
changestotherequirementsthan
anticipated.
Specificationsofessentialinterfaces
arenotavailableonschedule
Thesizeofthesystemhasbeen
underestimated.
CASEtoolswhichsupportthe
projectdonotperformasanticipated
Theunderlyingtechnologyonwhich
thesystemisbuiltissupersededby
newtechnology.
Acompetitiveproductismarketed
beforethesystemiscompleted.
SoftwareEngineering,6thedition.Chapter4
Slide25
Risk identification
Risk analysis
Risk planning
Risk monitoring
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide26
Risk
identification
Riskanalysis
Riskplanning
Risk
monitoring
Listofpotential
risks
Prioritisedrisk
list
Riskavoidance
andcontingency
plans
Risk
assessment
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide27
Risk identification
Technology risks
People risks
Organisational risks
Requirements risks
Estimation risks
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide28
People
Organisational
Tools
Requirements
Estimation
IanSommerville2000
Possible risks
The database used in the system cannot process as
many transactions per second as expected.
Software components which should be reused contain
defects which limit their functionality.
It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
The organisation is restructured so that different
management are responsible for the project.
Organisational financial problems force reductions in the
project budget.
The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Changes to requirements which require major design
rework are proposed.
Customers fail to understand the impact of requirements
changes.
The time required to develop the software is
underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
SoftwareEngineering,6thedition.Chapter4
Slide29
Risk analysis
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide30
Risk analysis
Risk
Organisational
financial
problems
force
reductions in the project budget.
It is impossible to recruit staff with the skills
required for the project.
Key staff are ill at critical times in the project.
Software components which should be reused
contain defects which limit their functionality.
Changes to requirements which require major
design rework are proposed.
The organisation is restructured so that different
management are responsible for the project.
The database used in the system cannot process
as many transactions per second as expected.
The time required to develop the software is
underestimated.
CASE tools cannot be integrated.
Customers fail to understand the impact of
requirements changes.
Required training for staff is not available.
The rate of defect repair is underestimated.
The size of the software is underestimated.
The code generated by CASE tools is inefficient.
IanSommerville2000
Probability
Low
Effects
Catastrophic
High
Catastrophic
Moderate
Moderate
Serious
Serious
Moderate
Serious
High
Serious
Moderate
Serious
High
Serious
High
Moderate
Tolerable
Tolerable
Moderate
Moderate
High
Moderate
Tolerable
Tolerable
Tolerable
Insignificant
SoftwareEngineering,6thedition.Chapter4
Slide31
Risk planning
Minimisation strategies
Contingency plans
If the risk arises, contingency plans are plans to deal with that
risk
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide32
IanSommerville2000
Strategy
Prepare a briefing document for senior management showing how the project is
making a very important contribution to the goals of the business.
Alert customer of potential difficulties and the possibility of delays, investigate
buying-in components.
Reorganise team so that there is more overlap of work and people therefore
understand each others jobs.
Replace potentially defective components with bought-in components of known
reliability.
Derive traceability information to assess requirements change impact, maximise
information hiding in the design.
Prepare a briefing document for senior management showing how the project is
making a very important contribution to the goals of the business.
Investigate the possibility of buying a higher-performance database.
Investigate buying in components, investigate use of a program generator.
SoftwareEngineering,6thedition.Chapter4
Slide33
Risk monitoring
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide34
Risk factors
Risk type
Technology
People
Organisational
Tools
Requirements
Estimation
IanSommerville2000
Potential indicators
Late delivery of hardware or support software, many reported
technology problems
Poor staff morale, poor relationships amongst team member,
job availability
organisational gossip, lack of action by senior management
reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
many requirements change requests, customer complaints
failure to meet agreed schedule, failure to clear reported
defects
SoftwareEngineering,6thedition.Chapter4
Slide35
Key points
IanSommerville2000
SoftwareEngineering,6thedition.Chapter4
Slide36
Key points
SoftwareEngineering,6thedition.Chapter4
Slide37