View
215
Download
1
Category
Preview:
Citation preview
1 / 23
CS 425/625 Software Engineering
Project Management
Based on Chapter 4 of the textbook [Somm00] Based on Chapter 4 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6th Ed., Addison-Wesley, 2000
and on Ch4 PowerPoint presentation from the book’s web-site:www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html
September 8, 2003September 8, 2003
2 / 23
OutlineOutline
IntroductionIntroduction Project PlanningProject Planning Project SchedulingProject Scheduling Risk ManagementRisk Management
3 / 23
Introduction.Introduction.
Software project managementSoftware project management is aimed to ensure that is aimed to ensure that the software is delivered on time, within budget and the software is delivered on time, within budget and schedule constraints, and satisfies the requirements of schedule constraints, and satisfies the requirements of the clientthe client
Management of software projects is different from other Management of software projects is different from other types of management because:types of management because:● Software is not tangibleSoftware is not tangible● Software processes are relatively new and still “under trial”Software processes are relatively new and still “under trial”● Larger software projects are usually “one-off” projectsLarger software projects are usually “one-off” projects● Computer technology evolves very rapidlyComputer technology evolves very rapidly
4 / 23
.Introduction.Introduction
Management activities:Management activities:● Writing proposalsWriting proposals
● Planning the projectPlanning the project
● Scheduling the projectScheduling the project
● Estimating the cost of the projectEstimating the cost of the project
● Monitoring and reviewing the project’s progressMonitoring and reviewing the project’s progress
● Selecting, hiring, and evaluating personnelSelecting, hiring, and evaluating personnel
● Writing reports and giving presentationsWriting reports and giving presentations
5 / 23
Project Planning…Project Planning…
A project plan should be drawn at the start of the A project plan should be drawn at the start of the project. This plan project. This plan drives the project and needs to be drives the project and needs to be continuously adjustedcontinuously adjusted
The role of the project manager is to anticipate The role of the project manager is to anticipate possible problems and be prepared with solutions for possible problems and be prepared with solutions for these problemsthese problems
Other plans that need be developed:Other plans that need be developed:● Quality planQuality plan● Validation and verification planValidation and verification plan● Configuration management planConfiguration management plan● Maintenance planMaintenance plan● Staff development planStaff development plan
6 / 23
.Project Planning...Project Planning.. The planning process [Fig 4.2, Somm00]The planning process [Fig 4.2, Somm00]
Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverableswhile project has not been completed or cancelled loop
Draw up project scheduleInitiate 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 ifend loop
7 / 23
..Project Planning...Project Planning.
The structure of the project plan:The structure of the project plan:● Introduction (objectives, constraints)Introduction (objectives, constraints)
● Project organization (team structure, personnel involved, roles)Project organization (team structure, personnel involved, roles)
● Risk analysis (types of risk, probabilities, solutions to prevent or Risk analysis (types of risk, probabilities, solutions to prevent or reduce the risk)reduce the risk)
● Hardware and software resources needed (prices, delivery schedule)Hardware and software resources needed (prices, delivery schedule)
● Work breakdown (activities, milestones, deliverables)Work breakdown (activities, milestones, deliverables)
● Project schedule (dependencies between activities/tasks, work Project schedule (dependencies between activities/tasks, work assignments, time allocated per task)assignments, time allocated per task)
● Monitoring and reporting mechanisms (reports, dates) Monitoring and reporting mechanisms (reports, dates)
8 / 23
……Project PlanningProject Planning MilestoneMilestone = end-point of a specific, distinct software process = end-point of a specific, distinct software process
activity or task (for each milestone a report should be presented activity or task (for each milestone a report should be presented to the management)to the management)
DeliverableDeliverable = project result delivered to the client = project result delivered to the client In order to establish milestones the phases of the software In order to establish milestones the phases of the software
process phases need be divided in basic activities/tasks. process phases need be divided in basic activities/tasks. Example for requirements engineering [Fig. 4.3, Somm00]Example for requirements engineering [Fig. 4.3, Somm00]
Evaluationreport
Prototypedevelopment
Requirementsdefinition
Requirementsanalysis
Feasibilityreport
Feasibilitystudy
Architecturaldesign
Designstudy
Requirementsspecification
Requirementsspecification
ACTIVITIES
MILESTONES
9 / 23
Project Scheduling……Project Scheduling……
Software managers:Software managers:● Divide the project in activities/tasksDivide the project in activities/tasks
● Estimate time and resources needed to finish the projectEstimate time and resources needed to finish the project
● Allocate resources to tasksAllocate resources to tasks
● Try to employ efficiently all the project personnelTry to employ efficiently all the project personnel
● Minimize dependencies between tasks and teamsMinimize dependencies between tasks and teams
● Prepare contingency plans Prepare contingency plans
● Rely on experience and intuitionRely on experience and intuition
10 / 23
.Project Scheduling…...Project Scheduling…..
The scheduling process [Fig. 4.4 Somm00]The scheduling process [Fig. 4.4 Somm00]
Estimate resourcesfor activities
Identify activitydependencies
Identifyactivities
Allocate peopleto activities
Create projectcharts
Softwarerequirements
Activity chartsand bar charts
11 / 23
..Project Scheduling…...Project Scheduling….
Graphical notations used in software Graphical notations used in software project scheduling:project scheduling:● Tables: summary description of tasks Tables: summary description of tasks
● Bar chartsBar charts: show schedule against the time: show schedule against the time
● Activity chartsActivity charts: graphs that depict dependencies : graphs that depict dependencies between tasks and indicate the between tasks and indicate the critical pathcritical path (the (the longest path in the activity graph)longest path in the activity graph)
12 / 23
……Project Scheduling…Project Scheduling…
Example of tabular description [Fig. 4.5 Somm00]:Example of tabular description [Fig. 4.5 Somm00]:
Task Duration (days) DependenciesT1 8T2 15T3 15 T1 (M1)T4 10T5 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 / 23
…….Project Scheduling...Project Scheduling..
Example of activity chart [Fig. 4.6, Somm00]Example of activity chart [Fig. 4.6, Somm00]
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99
15 days
11/8/99
25 days
10 days
20 days
5 days25/7/99
15 days
25/7/99
18/7/99
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
14 / 23
……..Project Scheduling...Project Scheduling.
Example of bar chart [Fig. 4.8, Somm00]Example of bar chart [Fig. 4.8, Somm00]
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5T8
M3
M2T6
T5M4
T9
M7T10
M6
T11M8
T12
Start
Finish
15 / 23
…………Project SchedulingProject Scheduling
Staff allocation chart [Fig. 4.9, Somm00]Staff allocation chart [Fig. 4.9, Somm00]
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
16 / 23
Risk Management…….Risk Management…….
RiskRisk = some adverse circumstance that may = some adverse circumstance that may happen and affect negatively the project, the happen and affect negatively the project, the product, and/or the businessproduct, and/or the business
Categories of risk:Categories of risk:● Project risksProject risks● Product risksProduct risks● Business risksBusiness risks
Risk managementRisk management means anticipating risks and means anticipating risks and preparing plans to reduce their effectpreparing plans to reduce their effect
17 / 23
.Risk Management…….Risk Management…… Examples of risks in the software process [Fig. 4.10, Somm00]Examples of risks in the software process [Fig. 4.10, Somm00]
Risk Risk type DescriptionStaff turnover Project Experienced staff will leave the
project before it is finished.Management change Project There will be a change of
organisational management withdifferent priorities.
Hardware unavailability Project Hardware which is essential for theproject will not be delivered onschedule.
Requirements change Project andproduct
There will be a larger number ofchanges to the requirements thananticipated.
Specification delays Project andproduct
Specifications of essential interfacesare not available on schedule
Size underestimate Project andproduct
The size of the system has beenunderestimated.
CASE tool under-performance
Product CASE tools which support theproject do not perform as anticipated
Technology change Business The underlying technology on whichthe system is built is superseded bynew technology.
Product competition Business A competitive product is marketedbefore the system is completed.
18 / 23
..Risk Management…....Risk Management…..
The risk management activities [Fig. 11, Somm00]The risk management activities [Fig. 11, Somm00]
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
19 / 23
……Risk Management….Risk Management…. Types of risk in Types of risk in risk identificationrisk identification [Fig. 4.12, Somm00] [Fig. 4.12, Somm00]
Risk type Possible risksTechnology The database used in the system cannot process as many
transactions per second as expected.Software components which should be reused contain defectswhich limit their functionality.
People 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.
Organisational The organisation is restructured so that different managementare responsible for the project.Organisational financial problems force reductions in the projectbudget.
Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework areproposed.Customers fail to understand the impact of requirementschanges.
Estimation The time required to develop the software is underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.
20 / 23
…….Risk Management….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 / 23
……..Risk Management....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
22 / 23
…………Risk Management.Risk Management. Examples of risk management strategies [Fig. 4.14, Somm00]Examples of risk management strategies [Fig. 4.14, Somm00]
Risk StrategyOrganisationalfinancial problems
Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.
Recruitmentproblems
Alert customer of potential difficulties and the possibility ofdelays, investigate buying-in components.
Staff illness Reorganise team so that there is more overlap of work andpeople therefore understand each other’s jobs.
Defectivecomponents
Replace potentially defective components with bought-incomponents of known reliability.
Requirementschanges
Derive traceability information to assess requirements changeimpact, maximise information hiding in the design.
Organisationalrestructuring
Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.
Databaseperformance
Investigate the possibility of buying a higher-performancedatabase.
Underestimateddevelopment time
Investigate buying in components, investigate use of a programgenerator.
23 / 23
…….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
Recommended