SWE 205 - Introduction to Software Engineering

Lecture 7 - Software Project Management

Lecture Objectives

To discuss project planning and planning process.

To show how graphical schedule representations are used by project management To discuss the notion of risks and the risk management process

Project Management process

Project Schedule Negotiate deliverables Start activities according to schedule Review Project progress

Update the project schedule

3

The Project Plan

The project plan sets out:

The resources available to the project; The work breakdown; A schedule for the work.

The Project Plan

Quality Plan Validation Plan Configuration Plan Maintenance Plan Quality Procedures and Standards Approach, Resources, Schedule Configuration Management Process Maintenance Process, cost, required effort How skills and experience of the Project team will be developed
5

Staff Development Plan

Project Plan Structure

Introduction. Project organisation. Risk analysis. Hardware and software resource requirements. Work breakdown. Project schedule. Monitoring and reporting mechanisms.
6

Milestones & Deliverables

Activities in a project should be organised to produce tangible outputs for management to judge progress. Milestones are the end-point of a process activity. Deliverables are project results delivered to customers.
7

Project Scheduling

Split project into tasks and estimate time and resources required to complete each task. Organize tasks concurrently to make optimal use of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete.

Dependent on project managers intuition and experience.

8

Scheduling Challenges

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

The unexpected always happens. Always allow contingency in planning.

Bar charts & Activity Networks

Graphical notations used to illustrate the project schedule. Show project breakdown into tasks.

Tasks should not be too small. For example, 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.
10

Task Durations & Dependencies

Task
T1 T2 T3

Duration (days)
8 15 10

Dependencies

T1

Component-A Design
Component-A Implementation
11

Progress from one Milestone to another.

Activity Network
1 4/ 7 / 03 8 d ays T1 2 5/ 7 / 03 4/ 7 / 03 s tart 15 d ays T2 10 d a ys T4 1 8/ 7 / 03 M5 2 5 d ays T8 19/ 9 /0 3 Fi n is h 25/ 7 / 03 M2 M3 T6 2 0 d ays T7 11/ 8 /0 3 M7 15 d a ys T1 0 M1 15 d a ys T3 5 d ays 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

10 d ays T5

12

Minimum time required to finish the project. (critical path)

Activity Network
1 4/ 7 / 03 8 d ays T1 2 5/ 7 / 03 4/ 7 / 03 s tart 15 d ays T2 10 d a ys T4 1 8/ 7 / 03 M5 2 5 d ays T8 19/ 9 /0 3 Fi n is h 25/ 7 / 03 M2 M3 T6 2 0 d ays T7 11/ 8 /0 3 M7 15 d a ys T1 0 M1 15 d a ys T3 5 d ays 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

10 d ays T5

13

Less chances of causing delay in project schedule.

Activity Network
1 4/ 7 / 03 8 d ays T1 2 5/ 7 / 03 4/ 7 / 03 s tart 15 d ays T2 10 d a ys T4 1 8/ 7 / 03 M5 2 5 d ays T8 19/ 9 /0 3 Fi n is h 25/ 7 / 03 M2 M3 T6 2 0 d ays T7 11/ 8 /0 3 M7 15 d a ys T1 0 M1 15 d a ys T3 5 d ays 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

10 d ays T5

14

Grantt Charts
4/ 7 11/ 7 St art T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 18/ 7 2 5/ 7 1/ 8 8/ 8

Flexibility in completion Date

1 5/ 8 22/ 8 2 9/ 8 5/ 9 12/ 9 1 9/ 9

M6 T11 M8 T12 Fi n is h

15

Staff Allocation
4/7 Fred T4 T8 1 1/7 18/7 2 5/7 1/8 8/8

Specialists e.g Security Analyst

2 2/8 2 9/8 5/9 1 2/9 19/9

15/8

T11 T1 2

Jane

T1 T3 T9

An ne

T2 T6 T10

Jim Mary

T7 T5
16

Risk Management

Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur

Project risks affect schedule or resources; Product risks affect the quality or performance of the software being developed; Business risks affect the organisation developing or procuring the software.
17

Risk Management - Example

An experience Programmer leaves a project.

Project risk - possible delay in system delivery. Product risk - Replacement may be less experienced and more chances of errors. Business risk - Programmers experience is not available for future products.
18

Risk Management Process

19

Risk Indicators
Risk type Technology People Organisational Tools Requirements Estimation 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
20

Key Points

Planning and estimating are iterative processes which continue through out the course of a project. Project scheduling involves preparing various graphical representations showing project activities, their durations and staffing. Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats.
21