Software engineering Olli Alm Lecture 5: project management & workload estimation.

Software engineering

Olli Alm

Lecture 5: project management & workload estimation

Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

© Ian Sommerville 2004, Software Engineering 7, ch 5 slides

Software project management


Management activities

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

Probably the most time-consuming project management activity.

Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.

Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.


Project planning


Types of project plan

Plan Description

Quality plan Describes the quality procedures and standards that will be used in a project. See Chapter 27.

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

Configuration management plan

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

Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. See Chapter 21.

Staff development plan.

Describes how the skills and experience of the project team members will be developed. See Chapter 25.


Activity organization

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. The waterfall process allows for the straightforward

definition of progress milestones.

Activity organization

Milestones example

Deliverables example


Milestones in requirements engineering

Evaluationreport

Prototypedevelopment

Userrequirements

Requirementsanalysis

Feasibilityreport

Feasibilitystudy

Architecturaldesign

Designstudy

Systemrequirements

Requirementsspecification

ACTIVITIES

MILESTONES


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.


Project scheduling process

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Softwarerequirements

Activity chartsand bar charts

Create projectcharts


Bar charts and activity network

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.


Bar charts and activity network

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.

Critical path: (a chain of) tasks that may block the starting of following tasks

Critical path (Pressman): ”Tasks that must be completedon schedule if the project as a whole is to be completedon schedule”


Task durations and dependenciesActivity Duration (days) Dependencies

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 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/03

8 days

14/7/03 15 days

4/8/03

15 days

25/8/03

7 days

5/9/03

10 days

19/9/03

15 days

11/8/03

25 days

10 days

20 days

5 days25/7/03

15 days

25/7/03

18/7/03

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4


Activity timeline (Gantt chart)

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

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11M8

T12

Start

Finish

Workload estimation

A set of techniques to estimate cost and effort required for software production

How much effort (hours?) is required to complete each activity?

How much calendar time is needed (when a task should be finished?)

What is the total cost of each activity?

Workload estimation: productivity

Productivity: How many ”units” are there to be produced? How many ”units” can be produced by a man in an hour? Complete cost: <no of units> / <units per hour (per person)>

total time taken


Productivity: How many ”units” are there to be produced? How many ”units” can be produced by a man in an hour? Complete cost: <no of units> / <units per hour (per person)>

total time takenBUT: software is always ”unique product”, cost estimation is hard and difficult (and often fails)


Productivity: Complete cost: <no of units> / <units per hour (per person)>

total time taken / total cost Productivity example, size-oriented metrics:

Unit measure: lines of code No of units: Software size will be 10’000 lines Unit per hour: Developer codes 50 lines in hour Total cost: 10’000 / 50: 200 hoursTo code the software in a week (~40 hours), we need200 / 40: 5 persons

Workload estimation: cost metrics

Metrics: a measurable / quantifiable factor of the (software) product to be developed

Cost estimation: Size-related metrics

Lines-of-code (LOC) Size of documentation (no of pages)

Function-related metrics Based on overall functionality of the software Function points Object points

Workload estimation: size-related example

Lines-of-code (LOC) Pros:

simple, explicit measurement unit One measure to whole project: LOC includes all other

activities: requirements, design… (in other words, other activities are simplified / reduced to LOC)

Cons: Quantity vs. Quality? Good code less lines Language dependent measurement (e.g. in Java, it usually

takes lots of lines to code anything) Difficult to estimate

Workload estimation: function-related metrics

Measuring the functionality of the code More independent from implementation language than

size-oriented metrics Function-Point count (FP)

No of function points implemented per person-month Function-Points:

External inputs and outputs User interactions External interfaces Files used by the system

Each function point has a complexity-weight E.g. external input:

simple: weight 3 complex: weight 15

Workload estimation: function-point (continued)

Unadjusted Function-point Count (UFC) Overall measure (one value) for the productivity UFC = ∑(no of elements of given type)*(weight)

Function-Point count Result value depends (heavily) on the estimator Suitable for data-processing system, not so good for

event-driven (=where no of inputs and outputs are hard to calculate)

Workload estimation: object-points

Another function-related metrics Not related to object-oriented programming Object points is weighted estimation of

Number of separate screens displayed Number of reports produced Number of modules that supplement / use database

Object points Easier to estimate high-level software specification More related to user interaction than data processing Utilized in (the famous) COCOMO II estimation model with

the name application points

Workload estimation

Combinations of function and size related metrics is possible

To estimate workload correctly: You should know your team You should know the problem You should understand what is the best (combination of)

estimation techniques in the specific situation Previous, similar projects are the best source of

information! (=experience matters)

Workload estimation – real world example

Software company, located in Finland

1. Project group + senior expert in the meeting room2. Go through the project goals3. Project activities on the wall, every one on its own paper,

size A04. Write down those activities + people who do them + their

experience5. Divide the group into three sub groups independent

workload estimations6. Walk through those estimations and try to think reasons for

the differences7. Final target: List of works that need to done

List of workload

Workload estimation – real world example

Software company, located in Finland

7. Final target: List of works that need to done

List of workload

Most commonly used figures:pessimistic approximation ( p )probable approximation ( a )optimistic approximation ( o )

Maximumlikelihood = p + 4a +o 6

Project economics

A person who has no experience with project / software work can’t understand where all those huge costs are coming from.

Most of the costs are coming from labor costs = 50 .. 70 % of all costs = monthly salary, overtime salary, bonus, necessary indirect employee costs ( 50 ... 60 % of salary ) and optional indirect employee costs ( car, food, health care, refreshments)

Others: overhead cost (work premises rents, phone, post ... ), hardware+software costs, education, literature, traveling costs, project group support ( no active project work ), capital costs and contribution margin ( need to make some money ).

If a new person is hired means about 6 - 10 months salary.

Adapted from Haikala-Märijärvi: Ohjelmistotuotanto

Project economics (continued)

Rough estimate for software work: Calculate basic hour rate price = sum ( cost items ) / sum

( hours billing from customer) Billing hours = (all working hours) – (working hours that are

“not“ directly customer work)Example: normal number of working days = 225 days = 1700 hours /

person management and secretaries can normally use only 25 % their work directly in project.

Working cost = project hours * basic hour rate

Project price = sum ( working cost + other costs ( external services+ equipments ..... ))



Rough estimate for software work:Example: A small company, manager + 9 programmers. Programmers do

effective work in projects, 75 % of their working time, last part is for education + old project maintenance work

One person per year leaves the company and new one will come in.

Salaries and indirect employee costs are = 10 * ( 1.6 * 2200 eur *12 moths) = 422 400 eur

Overheads, etc multiply by 1.5 633 600 eur..



Rough estimate for software work: 9 programmers, but only 8 work effectively in projects

8 * 1700 * 0.75 = about 10000 hours that customer will pay.

Hour rate = about 63 euros ( 633600 / 10000 ) --> day rate = 506 euros

If programmer does 10 ... 30 lines of program code / day one line of code = 15 ... 50 eur

Our Java program that has 15000 code lines costs a couple of millions.

COCOMO / intermediate model= 47 mm * 22 days/mm * 8 hours/day) * 63 euros /h = about 521 000 euros

Software engineering Olli Alm Lecture 5: project management & workload estimation.

Documents

Transcript of Software engineering Olli Alm Lecture 5: project management & workload estimation.