Adapted from Ian Sommerville 2006, Software Engineering ...mysite.du.edu/~lbarne28/SE/Slides/Ch5.pdf · Projjgect management Adapted from Ian Sommerville 2006, Software Engineering,

Project managementj g

Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 5 1

ObjectivesObjectives

To explain the main tasks undertaken by project To explain the main tasks undertaken by projectmanagers

To introduce software project management and top j gdescribe its distinctive characteristics

To discuss project planning and the planningprocess

To show how graphical schedule representations areused by project managementused by project management

To discuss the notion of risks and the riskmanagement process


management process

Topics coveredTopics covered

Management activities Management activities Project planning

Project scheduling Project scheduling Risk management


Software project management

Concerned with activities involved in ensuring

Software project management

Concerned with activities involved in ensuringthat software is delivered on time and onschedule and in accordance with therequirements of the organisations developingand procuring the software.

Project management is needed becausesoftware development is always subject tob d t d h d l t i t th t t bbudget and schedule constraints that are set bythe organisation developing the software.


Software management distinctions

The product is intangible

Software management distinctions

The product is intangible. The product is uniquely flexible.

Software engineering is not recognized as an Software engineering is not recognized as anengineering discipline with the same status asmechanical, electrical engineering, etc.mechanical, electrical engineering, etc.

The software development process is notstandardised.

Many software projects are 'one-off' projects.


Management activities

Proposal writing

Management activities

Proposal writing. Project planning and scheduling.

Project costing Project costing. Project monitoring and reviews.

P l l ti d l ti Personnel selection and evaluation. Report writing and presentations.


Management commonalities

These activities are not peculiar to software

Management commonalities

These activities are not peculiar to softwaremanagement.

Many techniques of engineering project Many techniques of engineering projectmanagement are equally applicable to softwareproject management.p j g

Technically complex engineering systems tendto suffer from the same problems as softwaresystems.


Project staffingProject staffing

May not be possible to appoint the ideal people to May not be possible to appoint the ideal people towork on a project• Project budget may not allow for the use of highly-paid

staff;• Staff with the appropriate experience may not be

available;available;• An organisation may wish to develop employee skills

on a software project. Managers have to work within these constraints

especially when there are shortages of trained staff.


Project planningProject planning

Probably the most time consuming project Probably the most time-consuming projectmanagement activity.

Continuous activity from initial concept through Continuous activity from initial concept throughto system delivery. Plans must be regularlyrevised as new information becomes available.

Various different types of plan may be developedto support the main software project plan that isconcerned with schedule and budget.


Types of project planTypes of project plan

Plan Description

Quality p lan Describes the quality proce dures and standards that will beused in a p rojec t See Chapter 27used in a p rojec t. See Chapter 27.

Validation plan Describes the approach , resources and schedule used forsystem validation. See Chapter 22.

Configuration Describes the configuration management procedures andConfigurationmanage me nt plan

Describes the configuration management procedures andstructures to be used. See Chapter 29.

Maintenance plan Predicts the maintenance requirements of the sys tem,maintenance costs and effort required. S ee Chapter 21.

Staff developmentplan.

Describes how the skills and experience of the projec t teammembers will be developed. S ee Chapter 25.


Project planning processProject planning process

Establish the project constraints p jMake initial assessments of the project parameters Define project milestones and deliverableswhile project has not been completed or cancelled loop

D j t h d lDraw up project scheduleInitiate activities according to scheduleWait ( for a while )Review project progressReview project progressRevise estimates of project parametersUpdate the project scheduleRe-negotiate project constraints and deliverablesif ( problems arise ) then

Initiate technical review and possible revisionend if

end loop


end loop

The project planp j p

The project plan sets out: The project plan sets out:• The resources available to the project;• The work breakdown;The work breakdown;• A schedule for the work.


Project plan structureProject plan structure

Introduction Introduction. Project organization.

Risk analysis Risk analysis. Hardware and software resource requirements.

W k b kd Work breakdown. Project schedule.

M it i d ti h i Monitoring and reporting mechanisms.


Activity organizationActivity organization

Activities in a project should be organised to Activities in a project should be organised toproduce tangible outputs for management tojudge progress.

Milestones are the end-point of a processactivity.D li bl j t lt d li d t Deliverables are project results delivered tocustomers.

The waterfall process allows for the The waterfall process allows for thestraightforward definition of progress milestones.


Milestones in the RE processMilestones in the RE process


Project schedulingProject scheduling

Split project into tasks and estimate time and Split project into tasks and estimate time andresources required to complete each task.

Organize tasks concurrently to make optimal Organize tasks concurrently to make optimaluse of workforce.

Minimize task dependencies to avoid delays Minimize task dependencies to avoid delayscaused by one task waiting for another tocomplete.

Dependent on project managers intuition andexperience.


The project scheduling processp j g p


Scheduling problemsScheduling problems

Estimating the difficulty of problems and hence Estimating the difficulty of problems and hencethe cost of developing a solution is hard.

Productivity is not proportional to the number of Productivity is not proportional to the number ofpeople working on a task.

Adding people to a late project makes it later Adding people to a late project makes it laterbecause of communication overheads.

The unexpected always happens. Always allowp y pp ycontingency in planning.


Bar charts and activity networksBar charts and activity networks

Graphical notations used to illustrate the project Graphical notations used to illustrate the projectschedule.

Show project breakdown into tasks Tasks Show project breakdown into tasks. Tasksshould not be too small. They should take abouta week or two.

Activity charts show task dependencies and thethe critical path.

Bar charts show schedule against calendar time.


Task durations and dependenciesTask durations and dependencies

Activity Duration (days) DependenciesActivity Duration (days) DependenciesT1 8T2 15T3 15 T1 (M1)T3 15 T1 (M1)T4 10T5 10 T2, T 4 (M2)T6 5 T1, T 2 (M3)T7 20 T1 (M1)T8 25 T4 (M5)T9 15 T3, T 6 (M4)

T10 15 T5, T 7 (M7)T11 7 T9 (M6)


T12 10 T11 (M8)

Activity networkActivity network


Activity timelineActivity timeline


Staff allocationStaff allocation


Risk managementg

Risk management is concerned with identifying Risk management is concerned with identifyingrisks and drawing up plans to minimise theireffect on a project.

A risk is a probability that some adversecircumstance will occur

Project risks affect schedule or resources;• Project risks affect schedule or resources;• Product risks affect the quality or performance of the

software being developed;• Business risks affect the organization developing or

procuring the software.


Software risksRisk Affects Description

Staff turnover Project Experienced staff w ill leave the project before it is f inished.

Management change Project There will be a c hange of organisational management withdifferent priorities.

Hardw are unavailability Project Hardw are that is essential for the projec t w ill not bedelivered on schedule.

Requirements change Project andproduct

There will be a larger numb er of changes to therequirements than anticipate d.

Specification delays Project andd t

Specifications of essential interfaces are not available onh d lproduct schedule

Size underestimate Project andproduct

The size of the system has been underestimate d.

CASE t ool under-performance

Product CASE t ools w hich support the project do not perform asanticipate dperformance anticipate d

Tec hnology change Business The u nderlying technology on which the sys tem is b uilt issuperseded by new t echnology.

Product co mp etition Business A competitive product is marketed before the system iscom pleted


com pleted.

The risk management processg p

Risk identification Risk identification• Identify project, product and business risks;

Risk analysisy• Assess the likelihood and consequences of these

risks;Risk planning Risk planning• Draw up plans to avoid or minimise the effects of the

risk; Risk monitoring

• Monitor the risks throughout the project;


The risk management processg p


Risk identification

Technology risks Technology risks. People risks.

Organisational risks Organisational risks. Requirements risks.

E ti ti i k Estimation risks.


Risks and risk typesyp

Risk type Poss ible risks

Techno logy The da tabase used in the system canno t proce ss as many transactions per secondas exp ected.Software co mponen ts that shou ld b e reus ed con tain defects that limit theirfunc tiona lity.

l i i ibl i ff i h h kill i dPeop le It is im pos sible to recruit staff with the skills required .Key staff are ill and unava ilable at criti cal times.Requi red training for staff is not av ailable.

Organ isationa l The o rgan isation is restructured so that different manag ement are respons ible forthe pro jectthe pro ject.Organ isationa l f inancial problems force reduc tions in the pro ject budge t.

Tool s The cod e gen erated by CASE tools is inefficient.CA SE tools canno t be integrated.

Requi rements Changes to requ irements that requ ire m ajor design rewo rk are p roposedRequi rements Changes to requ irements that requ ire m ajor design rewo rk are p roposed .Customers fail to unde rstand the impact o f requ irements change s.

Estimation The time requ ired to deve lop the software is unde restimated.The rate of defect repa ir is und erestim ated.The size o f the software is unde restimated.


Risk analysisy

Assess probability and seriousness of each risk Assess probability and seriousness of each risk. Probability may be very low, low, moderate, high

or very highor very high. Risk effects might be catastrophic, serious,

tolerable or insignificant.tolerable or insignificant.


Risk analysis (i)y ( )

Risk Probability Effects

Organ isationa l f inancial problems force reduc tions inthe pro ject budge t.

Low Catastroph icp j g

It is im pos sible to recruit staff with the skills requiredfor the p roject.

High Catastroph ic

Key staff are ill at c rit ical times in the project. Mod erate Serious

Software co mponen ts that shou ld b e reus ed con taindefects wh ich limit their func tion ality.

Mod erate Serious

Changes to requ irements that requ ire m ajor de sign Mod erate Seriousrewo rk a re propo sed.

The o rgan isation is restructured so that differentmanage ment are respons ible for the project.

High Serious


Risk analysis (ii)y ( )

Risk Probability Effects

The da tabase used in the system canno t proce ss asmany transactions per second as expec ted.

Mod erate Serious

The time requ ired to deve lop the software isunde restimated.

High Serious

CASE tools canno t be integrated. High Tolerab le

C f il d d h i f M d T l b lCustomers fail to unde rstand the impact o frequ irements change s.

Mod erate Tolerab le

Requi red training for staff is not av ailable. Mod erate Tolerab le

The rate of defect repa ir is underestim ated. Mod erate Tolerab leThe rate of defect repa ir is underestim ated. Mod erate Tolerab le

The size o f the software is unde restimated. High Tolerab le

The cod e gen erated by CASE tools is inefficient. Mod erate Insignificant


Risk planningp g

Consider each risk and develop a strategy to Consider each risk and develop a strategy tomanage that risk.

Avoidance strategiesg• The probability that the risk will arise is reduced;

Minimisation strategies• The impact of the risk on the project or product will

be reduced; Contingency plans Contingency plans

• If the risk arises, contingency plans are plans to dealwith that risk;


Risk management strategies (i)g g ( )

Risk Strategy

Organ isationa lfi i l bl

Prepar e a b riefing docu ment for senior manage menth i h th j t i ki i t tfinanc ial problems sho wing how th e project is making a v ery impor tant

con tribution to the goa ls of the bus iness.

Recru itmentbl

Alert cu stomer of po tential difficulties and theibili f d l i i b i iproblems pos sibility of de lays, inves tigate buy ing- in

componen ts.

Staff illness Reorgan ise team so that there is more ove rlap o f workd l h f d d h h ’ j band peop le therefore und erstand e ach other’s jobs .

Defectivecomponen ts

Replace pot entially defective componen ts with bough t-in compon ents of known reliability.


Risk management strategies (ii)g g ( )

Risk Strategy

Requi rementschang es

Derive traceability info rmation to assess requ irementschang e impac t, maximise information hid ing in thed idesign.

Organ isationa lrestructuring

Prepar e a b riefing docu ment for senior manage mentsho wing how th e project is making a v ery impor tantcon tribution to the goa ls of the bus inesscon tribution to the goa ls of the bus iness.

Da tabaseperformanc e

Inves tigate the po ssibility o f buy ing a high er-performanc e da tabase.

Unde restimateddeve lopment time

Inves tigate buy ing in componen ts, inve stigate u se of aprogra m gene rator


Risk monitoringg

Assess each identified risks regularly to decide Assess each identified risks regularly to decidewhether or not it is becoming less or moreprobable.p

Also assess whether the effects of the risk havechanged.g

Each key risk should be discussed atmanagement progress meetings.


Risk indicators

Risk type Pote ntial indi cato rs

Techno logy Late d elivery of hardwa re o r suppo rt software, many repo rtedtechno logy prob lems

Peop le Poor staff morale, poo r relationsh ips among st team m ember,job availability

Organ isationa l Organ isationa l gos sip, lack o f action by sen ior ma nage ment

Tool s Reluctance by team m embers to use tools, comp laints abou tCA SE tools, demands for high er-powe red work stations

Requi rements Many requ irements change reques ts, cus tomer comp laints

Estimation Failure to meet ag reed schedu le, failure to c lear repor teddefects


Key pointsKey points

Good project management is essential for project Good project management is essential for projectsuccess.

The intangible nature of software causes problemsg pfor management.

Managers have diverse roles but their mostsignificant activities are planning, estimating andscheduling.Planning and estimating are iterative processes Planning and estimating are iterative processeswhich continue throughout the course of aproject.


p j

Key points

A project milestone is a predictable state where a

Key points

A project milestone is a predictable state where aformal report of progress is presented tomanagement.

Project scheduling involves preparing variousgraphical representations showing projectactivities their durations and staffingactivities, their durations and staffing.

Risk management is concerned with identifyingrisks which may affect the project and planningy p j p gto ensure that these risks do not develop intomajor threats.


Documents

Adapted from Ian Sommerville 2006, Software Engineering ...mysite.du.edu/~lbarne28/SE/Slides/Ch5.pdf · Projjgect management Adapted from Ian Sommerville 2006, Software Engineering,