IS 556 Project Management

IS 556 Fall 2003 1

IS 556 Project Management

Week 5 - Project EstimatingReadings: On Time Within Budget Ch.12

Case: Vandelay Industries

David Lash

2David LashCS 556 - Winter

Project PlanWork Breakdown StructurePert ChartGannt ChartDealing with Human Resources

Last Week Objectives


Stepwise EstimationPrototyping – Engineering orientationConstructive Cost ModelsEstimate project in 5 levels

1. Level of Personnel2. Level of complexity3. Project size4. Development Environment5. Reliability level

Range of Estimates (normal distrbution)Hardware estimates - CPU, Memory, disk, resp

time

Objectives - Estimation


Some things needing estimationWe estimate things we don’t know for sure: Project Development Cost

Estimate in dollarsDevelopment Schedule : timeDevelopment Team

Number of people Type of people

Amount of Software LOC Kilobytes Better measures

Hardware Resources Time needed in test Lab CPU Usage Disk, memory


Estimation Is Inherently Hard

Critical to success of schedule but hard to do:

R&D projects may be solving “new” problemNew technology may use new, “unknown” productivity enhancements

What is the productivity of each developer? (What is an average worker?)

If 1 portion of project slips, coordination of resources may throw schedule off (e.g., equipment shows up and not ready for it.)


Estimating Techniques

Experience: What worked before Works if we keep data

Metrics and measures for successCOCOMO: COnstructive COst MOdel

Estimation model of the new era Continuous model improvement Quantitative Software life cycle costs


Stepwise Estimation: 4 Categories

Often well evaluated and tested. E.g., open source modules, math library.

Applications with lots of experience.Area of specialty (e.g., Internet Ap or DB module). Confident can repeat past success. Risk of miscalculation.

Components similar to others. (e.g., develp cellular billing w/ experence in telephone billing.) Can you identify whats new and familiar w/i component? Evolutionary steps.

No significant experience. No reliable basis for estimation.

•Decompose Problem into small units (modules) and Classify them


Decompose and Classify


Development Estimating Methods Prototyping – Engineering orientation

Reduced functionality May be able to Refine and reuse prototype The better the prototype the most it costs to develop

You typically prototype to “learn” something. It might be requirements, or how to implement something or to estimateoverall complexity of the module.

Usefulness of prototype (to reuse it) often depends upon reason it was built. If implementing a portion of system to get better estimate might very well be useful later. If learning how to work with hardware…


Development Estimating Methods Statistical – Scientific orientation

The idea is to categorize modules, build a % of them and extrapolate

Some steps1. Identify all new development software components. 2. Initial design of each component: ID software modules that implement them3. Divide the modules into similar categories, according to:

complexity (degree of difficulty) function (such as communications, data base, human interface, etc.) type (screen, operating system, library utility, service task, etc.)

4. From each category, select one module that is representative of the others. 5. Implement the selected modules. 6. Based on this experience estimate the resources required for each category. 7. Combine the estimates for each category

The more “samples” the more estimation accuracy but more samples increases costs of estimation!


Constructive Cost Models Any development estimate is difficult

Skill - Are all programmers skill equal? (Consider small case at chapter start)

Complexity - How determine complexity of task? Size - Estimating the size by LOC, number of objects?, type of work? Reliability – Highly reliable software much more difficult Environment – Lots of process, meetings overhead?

Using Estimation Models Most basic is to gather relevant data.

Compare estimate of task and date to actual completion There are several different estimation models

CoCoMO is the oldest


Constructive Cost Models COCOMO – Dr. Barry Boehm - USC

1981 - original COCOMO introduced in Software Engineering Economics. • Uses previous 5 factors, and estimates

costs, schedule and staff size 1981-1996 – incremental developments 1997 - calibration of COCOMO II is released by

Boehm.• More OO approach using obect points and function points

to determine software size. From informit.com - Barry Boehm is among the most respected names in the software world. A TRW professor of software engineering and director of the USC Center for Software Engineering, he earlier served as director of the DARPA Information Science and Technology Office and as a chief scientist at TRW. His contributions to the field include the Constructive Cost Model (COCOMO), the Spiral Model of the software process, the Theory W (win-win) approach to software management and requirements determination, and his classic book, Software Engineering Economics (Prentice Hall, 1982).


COCOMO Overall IdeaEstimate project in 5 levels


Need to gather data and “calibrate” model over time.

Will overview at a high level some major factors in model.


1. Level of Personnel

Productivity of developers varies widely (can be 400%). Performance varies by many factors

As project size increases Effect of individual performance decreases

PL < 1 is good PL while > 1 is not good …

),,( KSLOCNEPfPL

Personnel level

Expected Performance (assigned betw 1-4) for N engineers using KLOC as project size


Personnel Level Cost Multipliers

(ΣEP)/N KSLOC <5 25<KSLOC <300300

<KSLOC4 0.33 0.5 0.75

3.5 0.45 0.65 0.813 0.66 0.85 0.9

2.5 1 1 12 2.2 1.8 1.5

1.5 3.5 2.5 2.21 4 4 4

A B CKSLOC 10 100 500N 3 35 190ΣEP 9 71 435(ΣEP )/N 3 2 2.3PL 0.66 1.8 1

PL = f(ΣEP, N, KSLOC)

Table 12.2: PL Cost Factors Calculated for Three Projects

Table 12.1: Cost Multipliers for the Level of Personnel

PL estimates

AverExpectedperformance

Predicted costs of A 1/3 of B

100 KLOC, 35 people, 9@lvl 1 1@lvl 2, 6@lvl3, 2@lvl4

10 KLOC, 3 people, 1@lvl 2 1@lvl 3, 1@lvl4

500 KLOC, 500 people, 20@lvl 1 100@lvl 2, 65@lvl3, 5@lvl4


2. Levels of Software Complexity:

1. System - operating, comm., etc.• SEM = 3.6 X (KSLOC)

1.20

2. Algorithmic – logic, scientific, sort• SEM = 3.2 X (KSLOC)

1.15

3. Service – utilities, graphics• SEM = 2.8 X (KSLOC)

1.10

4. Data Processing – DB, inventory, spreadsheet, etc.

• SEM = 2.4 X (KSLOC)1.05

Consider 4 classes of software complexity:

Estimated Software Engineering Months (SEM).

These formula suggest that as size gets > 100 KLOC classification becomes more important. > 300KLOC can be > 200%.


3. Reliability Levels

Must formulate based on experience

Levels based on effects of system failure Slight inconvenience Losses easily recovered Moderately difficult to

recover losses High financial loss Risk to human life

LEVEL OF RELIABILITY

RELIABILITY MULTIPLIERS

5. Full fault tolerance 2

3. Data integrity preserved 1.17

4. High reliability required 1.5

1. No effort required 0.75

2. Low 0.93

Table 12.4: Reliability Multipliers for Five Reliability Levels

Reliability is not a cheap requirement

A reliability function is calibrated for your environment and generate reliability multiplier


4. Development Environment

OS Programming language Computer Aided Software Engineering (CASE)

Multipliers can be developed for these levels also

Productivity is impacted by DE factors such as:


5. SubsystemsSubsystems are components that can be

viewed as systems in their own right. Decomposition can result in subsystemsAlternatives

Can use model to calculate subsystem effortDivide into subsystems and calculate

effort separately.


Some Basic CoCoMo Steps

Decompose software into subsystems and into modules

Use size estimation to estimate module sizeDetermine effort multipliers

(personnel, size, reliability, development environ, module complex)

Apply multipliers to modules and rollup into module and susbsystem effort

Review costs missed and any missed factors

Have another independent estimate made


Function Point Analysis There is some controversy about using KLOC as a

size/complexity measure. (C++ VS Perl VS VB code). FPA is a measure of complexity based on problem size

(functionality amount) There exists Intl Function Point Users Group (IFPUG) =>

promote FPA and software measurement FPA can be used to compare

Project complexity Effort to complete Generate other measures such as KLOC

Used as a component in COCOMO, There are also several software packages that calculate


Function Point Analysis

FPA based on UFP -> unadjusted function point -> Complexity of I/O

component CAF -> Complexity adjustment factor -> overall complexity

of project.

AFP => Adjusted function point

xUFPCAFAFP


Function Point Analysis - UFP UFP -> measure of I/O Dependent-ness Identify the number of functions that are Input/output

dependent E.g., User inputs/inquires, external data output, control files/data,

external shared files/data/control info Classify these functions and rate them as

Simple (minimal i/O, minimal user involvement) Average – Complex – (many file accesses, many different data types,

extensive user involvement) Weighted values – Assigned to each function type, calibrated

for your environment.

)__( valuesweightedAllUFP

Remember: CFP= CAF x UFP


Function Point Analysis - CAF CAF – Calculated Adjustment Factor - Attributes of

Processing complexity Look at overall problem and estimate attributes of

processing complexity: Data communication, performance, transaction rate, online

data entry, reusability, Operational ease, installation ease and many more)

Rate complex influence from 0->none, 5->strong complex influence

Calculate the CAF. Text suggests one formula might be:

)__(5

)__(

categoriesofnumberx

ratingscomplexAllCAF

xUFPCAFAFP


Range of EstimatesIdea is to ask several engineers to

estimate effort. Estimations will form normal distribution (if

‘N’ is large enough. (Shaper of distribution important)

Idea is to approximate a normal distribution so you have some statistical basis for determining an estimation range. Can calculate expected valueStandard deviation:

• 1 sd = 66% of data• 2 sd = 95% of data• 3 SD = 99% of data

Idea- 95% confidence of estimate from 4-9 days


Using Normal Distribution Steps would be:

1. Get a solid estimate of best and worst case 2. Get several estimates of expected time

- Probability of best case = .2 - Probability of worst case = .2 - Probability of most likely = .6 - Expected value = summary of probabilities.

- Can approximate std dev = P(word)*worst -

P(best)*best and therefore can calc 3*SD


How does that work? Assume estimates as:

Best case – 4 weeks Worst case – 12 weeks Expected case estimate – 7 Weeks

Approximate Std Dev

Therefore you could say66% confident effort is between 5.8-9 days95% confident effort is between 4.2-10.6

4.7)2(.12)6(.7)2(.4 Expected

Remember assign probabilities .2 and probability .6

8.4)3(6.1)(3

2.3)2(6.1)(2

6.1)2(.4)2(.12

Sdev

Sdev

Sdev Remember has 66% confidence95% confidence and 99% confidence


Hardware ResourcesSometimes application targets a specific

hardware with limited CPU E.g., Palm pilot, some network switches, real-

time softwareSometime must design software to work

with hardw limitations Will consider CPU, Data storage and response

time


Hardware Resources – CPU LoadCPU Load - difficult with multi-processors so

often use percentage Choose specific time frame.

Why? E.g., Many systems on aver10-20% busy. Concerned about the critical time the AP is running.

Usually Real-Time systems For example, a communication system, needs

• A main loop with to read 2 data inputs every 400 Ms and require 60 ms each

– Therefore within 400 ms consume 120 ms• A fast loop that reads 2 inputs every 40 Ms and require 10ms.

That is, consumes 20 ms every 40 ms.– Would consume 200 ms within 400

• So within 400 ms– (120+200)/400 or 80% consumed


Hardware Resources - Data Storage Sometimes early estimates need based on user input Estimate worst case memory needs

Decompose system & estimate memory needs ID indirect memory needs (work areas, etc.) ID largest set of modules resident at any one time ID system level needs (buffers, stack, resident tables) Total OS memory utilization Combine all

Disk usage still comes up from time to time E.g., disk needs for DB application

Establish an estimated number of tables and variables within each Estimate number of records.


Hardware Resources - response time

System feedback – user perception

Response time interval

Estimate response times Average Worst case system usage 95th percentile

RESPONSE TIME (SECONDS)

PERCENTAGE

0-3 20%3-6 60%6-9 39%

9-15 1%

Table 12.7: Example Response Time Distribution Table

Event Process Response

Response time


Nondevelopment Overhead Update estimates and report

continuously

At end of design phase At milestones Before IntegrationBefore

Testing Update when requirements

change Use a safety factor or fudge

factor (%) Project Overhead doesn’t

include Senior management, sales

OVERHEADManagement 0.1Configuration control 0.02Software quality assurance 0.03

Table 12.8: Overhead of Nondevelopment Activities

It is better to withstand the assault on a schedule at the beginning of a project and be applauded when it is completed on time, than to be applauded at the beginning of a project for accepting an impossible schedule and being rebuked at the end for failing to deliver it on time.


Stepwise EstimationPrototyping – Engineering orientationConstructive Cost ModelsEstimate project in 5 levels


Range of Estimates (normal distrbution)Hardware estimates - CPU, Memory, disk, resp

time

Summary

Date post:	01-Feb-2016
Category:	Documents
Upload:	awen
View:	29 times
Download:	0 times

IS 556 Project Management

Documents