CSC 480 Software Engineering Project Planning. Proposal writing Project planning and scheduling...

CSC 480Software Engineering

Project Planning

Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel selection and evaluation Report writing and presentations

Management Activities

Project Scheduling Dependent on project managers intuition and

experience 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

The Project Scheduling Process

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Create projectcharts

Softwarerequirements

Activity chartsand bar charts

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

Task Durations & DependenciesTask 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)

Activity network

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

Activity Timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4T1T2

M1

T7T3M5

T8M3M2

T6T5

M4T9

M7T10

M6T11

M8

T12

Start

Finish

Staff Allocation4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4T8 T11

T12T1

T3T9

T2T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Risk Management

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

The Four Risk Activities

Identification

Mindset: try to continually identify risks

Retirement planning

Prioritization

Retirement or mitigation

Risk Identification

Technology risks People risks Organisational risks Requirements risks Estimation risks

Risks and Risk TypesRisk 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.

Risk Analysis

Assess probability and seriousness of each risk

Probability may be very low, low, moderate, high or very high

Risk effects might be catastrophic, serious, tolerable or insignificant

Projectfinish

Risk Management MindsetProject

start

Identification Retirement

2. “Java skills not high enough.”

1. “May not be possible to superimpose images adequately.”

1. Retirement by conquest: Demonstrate image super- imposition

Risk 1

Risk 2

Risk 1

Projectfinish

Risk 2

2. Retirement by avoidance: Use C++

Projectstart

Likelihood1-10

 1 = least

likely

Impact1-10

 1 = least impact

Retire-ment cost

1-101 = lowest retirement

cost

Priority computation

Resulting priority

 Lowest number handled

first

The highest priority

risk

10(most likely)

10 (most

impact)

1 (lowest

retirement cost)

(11-10)*(11-10)

*11

The lowest

priority risk

1 (least likely)

1 (least

impact)

10(highest

retirement cost)

(11-1)*(11-1)

*101000

Compute Risk Priorities

Constructive Cost Model (COCOMO)

Can we use the estimated KLOC as an effort estimation?KLOC / (KLOC/(man*hr)) = man * hr

The answer is NOThe communication, documentation, and

integration efforts increase faster than the product size grows

Effort (in man-month) is exponential in sizebKLOCaEffort

COCOMO

Once we know the effort estimation in man-month, can we just divide it by the number of developers to get the duration?Duration = Effort / (# developers)

The answer is NO, again It takes one chef five hours to cook a turkey. Can we

then expect five chefs get one ready in one hour?

dEffortcDuration

COCOMO Formulas (Boehm)

Applies to design through integration & test.*“Effort” = total person-months required.

(2) Duration for increasing Effort* ( y 2.5x 0.35 )

(1) Effort* for increasing LOC( y 3x 1.12 )

exponent: < 1> 1

Basic COCOMO FormulaeEffort in Person-months

= aKLOC b

Duration = cEffort d

Software Project a b c d Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32Empirical factors due to Boehm [Bo]