CS 425/625 Software Engineering

Project Management
Based on Chapter 5 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006 and on Ch5 PPT presentation from http://www.software-engin.com/
September 17, 2007

Outline

Introduction Project Planning Project Scheduling Risk Management

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 Software processes are relatively new and still under trial Larger software projects are usually one-off projects Computer technology evolves very rapidly

.Introduction

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

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

.Project Planning..

The planning process [Fig 5.2, SE-8]

Esta bl ish the proj ect co nstrai nts Make in iti al a ssessme nts of the p ro je ct p arameters De fi ne proj ect mi le ston es an d del i verab le s w hile proj ect has not b een compl eted o r ca ncel led loop Draw up p ro je ct sch edu le Ini ti ate acti vi tie s accordi ng to sche dul e Wai t ( fo r a whi l e ) Re vi ew proj ect progress Re vi se estima te s of p ro je ct p arameters Up date th e proj ect sched ul e Re -n egoti ate proj ect co nstrai nts and d el iverabl es if ( prob le ms arise )then Ini ti ate tech ni cal re vi ew an d possi bl e revi sion end if end loop

..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)

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 study

Requir ements analysis

Prototype development

Design study

Requir ements specification

Feasibility report

Requir ements definition

Evaluation report MILESTONES

Architectural design

Requir ements specification

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

.Project Scheduling..

The scheduling process [Fig. 5.4, SE-8]

Identify activities

Identify activity dependencies

Estimate resources for activities

Allocate people to activities

Create project charts

Software requirements

Activity charts and bar charts

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

Project Scheduling

Example of tabular description [Fig. 5.5, SE-8]:

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)

Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

12

.Project Scheduling..

Example of activity chart [Fig. 5.6, SE-8]

1 4/ 7 / 03 8 d ays T1 2 5/ 7 / 03 M1 15 d a ys T3 5 d ays M3 15 d ays T2 10 d a ys T4 1 8/ 7 / 03 M5 2 5 d ays 25/ 7 / 03 M2 T6 2 0 d ays T7 11/ 8 /0 3 M7 15 d a ys T1 0 4/ 8 /0 3 M4 15 d a ys T9 2 5/ 8 /0 3 M6 7 d ays T1 1 5/ 9 /0 3 M8 10da ys T12

4/ 7 / 03 s tart

10 d ays T5

13

T8 19/ 9 /0 3

Fi n is h

..Project Scheduling.

Example of bar chart [Fig. 5.7, SE-8]

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

4/ 7 T4 T1 T2

M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T1 0 M6 T1 1 M8

14

T1 2 Fi n is h

Project Scheduling

Staff allocation chart [Fig. 5.8, SE-8]

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 Mary
15

T7 T5

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

16

.Risk Management

Examples of risks in the software process [Fig. 5.9, SE-8]

Affects Project Project Project Project and product Project and product Project and product Product Business Business Description Experienced staff will leave the project before it is finished. There will be a change of organisational management with different priorities. Hardware that is essential for the project will not be delivered on schedule. There will be a larger number of changes to the requirements than anticipated. Specifications of essential interfaces are not available on schedule The size of the system has been underestimated. CASE tools which support the project do not perform as anticipated The underlying technology on which the system is built is superseded by new technology. A competitive product is marketed before the system is completed.

Risk Staff turnover Management change Hardware unavailability Requirements change Specification delays Size underestimate CASE tool underperformance T echnology change Product competition

17

..Risk Management..

The risk management activities [Fig. 5.10, SE-8]

Risk identification

Risk analysis

Risk planning

Risk monitoring

List of potential risks

Prioritised risk list

Risk avoidance and contingency plans

Risk assessment

18

Risk Management.

Types of risk in risk identification [Fig. 5.11, SE-8]

Potential indicators Late delivery of hardw are or support softw are, 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 w orkstations Many requirements change requests, customer complaints Failure to meet agreed schedule, failure to clear reported defects

Risk type Technology People Organisational Tools Requirements Estimation

19

.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

20

..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

21

Risk Management.

Examples of risk management strategies [Fig. 5.13, SE-8]

Risk Organisational financial problems Recruitment problems Staff illness Defective components
Risk Requirements changes Organisational restructuring Database performance Underestimated development time

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 boughtin components of known reliabilit y.
Strategy Derive traceabili ty 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 possibilit y of buying a higherperformance database. Investigate buying in components, investigate use of a program generator

22

.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

23