57261818 Project Estimation

8/13/2019 57261818 Project Estimation

1/112

Project Estimation and

scheduling

Outline:Estimation overview

Cocomo: concepts, process and tool.

Detailed schedule/planning terminology and processesPlanning Tools (MS Project)


2/112

Estimation

The single most important task of aproject: setting realistic expectations.

Unrealistic expectations based oninaccurate estimates are the single largest

cause of software failure.Futrell, Shafer and Shafer, Quality Software Project Management


3/112

Why its important to you!

Program development of large software

systems normally experience 200-300%

cost overruns and a 100% schedule slip

15% of large projects deliverNOTHING!

Key reasonspoor management and

inaccurate estimations of development cost

and schedule

If not meeting schedules, developers often

pay the price!


4/112

The Problems

Predicting software cost

Predicting software schedule

Controlling software risk

Managing/tracking project as it progresses


5/112

Fundamental estimation questions How much effort is required to complete an

activity?

How much calendar time is needed to complete anactivity?

What is the total cost of an activity?

Project estimation and scheduling are interleavedmanagement activities.


6/112

Software cost components

Hardware and software costs. Travel and training costs.

Effort costs (the dominant factor in most

projects) The salaries of engineers involved in the project;

Social and insurance costs.

Effort costs must take overheads into account

Costs of building, heating, lighting.

Costs of networking and communications.

Costs of shared facilities (e.g library, staff restaurant, etc.).


7/112

Costing and pricing

Estimates are made to discover the cost, to thedeveloper, of producing a software system.

There is not a simple relationship between the

development cost and the price charged to thecustomer.

Broader organisational, economic, political and

business considerations influence the pricecharged.


8/112

Software pricing factors

Market

opportunity

A development organisation may quote a low price because it

wishes to move into a new segment of the software market.

Accepting a low profit on one project may give the opportunity

of more profit later. T he experience gained may allow new

products to be developed.

Cost est imate

uncertainty

If an organisation is unsure of its cost estimate, it may increase

its price by some contingency over and above its normal profit .

Contractual terms A c ust omer may be willing to allow the developer to retain

ownership of the source code and reuse it in ot her projects. T he

price charged may then be less than if the software source code

is handed over to the customer.

Requirements

volatility

If the requirements are likely to change, an organisation may

lower its price to win a contract. After the contract is awarded,high prices can be charged for changes to the requirements.

Financial health Developers in financial difficulty may lower their price to gain

a c ontract. It is bet ter to make a smaller than normal profit or

break even than to go out of business.


9/112

Nature of Estimates

Man Months (or Person Months), defined as 152man-hours of direct-charged labor

Schedule in months (requirements complete to

acceptance) Well-managed program


10/112

4 Common (subjective)

estimation models

Expert Judgment

Analogy

Parkinsons law

Price to win


11/112

Expert judgment

One or more experts in both softwaredevelopment and the application domain use their

experience to predict software costs. Processiterates until some consensus is reached.

Advantages: Relatively cheap estimation method.Can be accurate if experts have direct experience

of similar systems Disadvantages: Very inaccurate if there are no

experts!


12/112

Estimation by analogy

The cost of a project is computed by comparing

the project to a similar project in the same

application domain Advantages: May be accurate if project data

available and people/tools the same

Disadvantages: Impossible if no comparableproject has been tackled. Needs systematically

maintained cost database


13/112

Parkinson's Law

The project costs whatever resources are

available

Advantages: No overspend

Disadvantages: System is usually unfinished


14/112


15/112

Top-down and bottom-up estimation

Any of these approaches may be used top-downor bottom-up.

Top-down

Start at the system level and assess the overallsystem functionality and how this is deliveredthrough sub-systems.

Bottom-up

Start at the component level and estimate the effortrequired for each component. Add these efforts toreach a final estimate.


16/112

Top-down estimation

Usable without knowledge of the systemarchitecture and the components that might be

part of the system.

Takes into account costs such as integration,configuration management and documentation.

Can underestimate the cost of solving difficult

low-level technical problems.


17/112

Bottom-up estimation

Usable when the architecture of the system isknown and components identified.

This can be an accurate method if the system has

been designed in detail. It may underestimate the costs of system level

activities such as integration and documentation.


18/112

Estimation methods

Each method has strengths and weaknesses. Estimation should be based on several methods.

If these do not return approximately the same

result, then you have insufficient informationavailable to make an estimate.

Some action should be taken to find out more in

order to make more accurate estimates.

Pricing to win is sometimes the only applicable

method.


19/112

Pricing to win

This approach may seem unethical and un-businesslike.

However, when detailed information is lacking it

may be the only appropriate strategy. The project cost is agreed on the basis of an

outline proposal and the development isconstrained by that cost.

A detailed specification may be negotiated or anevolutionary approach used for systemdevelopment.


20/112

Algorithmic cost modeling

Cost is estimated as a mathematical function ofproduct, project and process attributes whose

values are estimated by project managers

The function is derived from a study of historicalcosting data

Most commonly used product attribute for cost

estimation is LOC (code size) Most models are basically similar but with

different attribute values


21/112

Criteria for a Good Model

Definedclear what is estimated Accurate

Objectiveavoids subjective factors

Results understandable

Detailed

Stablesecond order relationships

Right Scope

Easy to Use Causalfuture data not required

Parsimoniouseverything present is important


22/112

A measure of the rate at which individualengineers involved in software development

produce software and associated

documentation. Not quality-oriented although quality assurance is

a factor in productivity assessment.

Essentially, we want to measure usefulfunctionality produced per time unit.

Software productivity


23/112

Size related measuresbased on some output fromthe software process. This may be lines of

delivered source code, object code instructions,

etc. Function-related measuresbased on an estimate of

the functionality of the delivered software.

Function-points are the best known of this type ofmeasure.

Productivity measures


24/112

Estimating the size of the measure (e.g. how manyfunction points).

Estimating the total number of programmer

months that have elapsed. Estimating contractor productivity (e.g.

documentation team) and incorporating this

estimate in overall estimate.

Measurement problems


25/112

What's a line of code? The measure was first proposed when programs were typed

on cards with one line per card;

How does this correspond to statements as in Java which can

span several lines or where there can be several statementson one line.

What programs should be counted as part of the system?

This model assumes that there is a linear relationship

between system size and volume of documentation. A key thing to understand about early estimates is that

the uncertainty is more important than the initial linedont see one estimate, seek justifiable bounds.

Lines of code


26/112

The lower level the language, the moreproductive the programmer

The same functionality takes more code toimplement in a lower-level language than in a high-

level language.

The more verbose the programmer, the higherthe productivity

Measures of productivity based on lines of codesuggest that programmers who write verbose codeare more productive than programmers who writecompact code.

Productivity comparisons


27/112

System development times

Analysis Design Coding Testing Documentation

Assembly code

High-level language

3 weeks

3 weeks

5 weeks

5 weeks

8 weeks

4 weeks

10

weeks6 weeks

2 weeks

2 weeks

Size Effort Productivity

Assembly code

High-level language

5000 lines

1500 lines

28 weeks

20 weeks

714 lines/month

300 lines/month


28/112

Empirical Model (COCOMO)

Provide computational means for deriving S/W costestimates as functions of variables (major cost drivers)

Functions used contain constants derived from

statistical analysis of data from past projects:

can only be used if data from past projects is available

must becalibratedto reflect local environment

relies on initial size and cost factor estimates which

themselves are questionable


29/112

COCOMO

COCOMO (CONSTRUCTIVE COST MODEL)

-First published by Dr. Barry Boehm, 1981

Interactive cost estimation software package thatmodels the cost, effort and schedule for a new

software development activity. Can be used on new systems or upgrades

Derived from statistical regression of data from a

base of 63 past projects (2000 - 512,000 DSIs)


30/112

Where to Find CoCoMo

http://sunset.usc.ede Or do a Google search on Barry Boehm.


31/112

Productivity Levels

Tends to be constant for a given programmingshop developing a specific product.

~100 SLOC/MM for life-critical code

~320 SLOC/MM for US Government quality code

~1000 SLOC/MM for commercial code


32/112

Nominal Project Profiles

Size 2000

SLOC

8000

SLOC

32000

SLOC

128000

SLOC

MM 5 21 91 392

Schedule

Months

5 8 14 24

Staff 1.1 2.7 6.5 16

SLOC/

MM

400 376 352 327


33/112

Input Data

Delivered K source lines of code(KSLOC) Various scale factors:

Experience

Process maturity

Required reliability

Complexity

Developmental constraints


34/112

COCOMO

Uses Basic Effort Equation Effort=A(size)exponent

Effort=EAF*A(size)

exponent

Estimate man-months (MM) of effort to complete S/W project

1 MM = 152 hours of development

Size estimation defined in terms of Source lines of codedelivered in the final product

15 cost drivers (personal, computer, and project attributes)


35/112

COCOMO Mode & Model

Three development environments (modes)Organic Mode

Semidetached Mode

Embedded Mode

Three increasingly complex models

Basic ModelIntermediate Model

Detailed Model


36/112

COCOMO Modes

Organic Mode

Developed in familiar, stable environment

Product similar to previously developed product


37/112

COCOMO Models

Basic Model Used for early rough, estimates of project cost,

performance, and schedule

Accuracy: within a factor of 2 of actuals 60% of time

Intermediate Model Uses Effort Adjustment Factor (EAF) fm 15 cost

drivers

Doesnt account for 10 - 20 % of cost (trng, maint,

TAD, etc) Accuracy: within 20% of actuals 68% of time

Detailed Model Uses different Effort Multipliers for each phase of

project (everybody uses intermediate model)

B i M d l


38/112

Basic Model

Effort Equation(COCOMO 81)

Effort=A(size)exponent

A is a constant based on the developmental mode

organic = 2.4

semi = 3.0

embedded = 3.6

Size = 1000s Source Lines of Code (KSLOC)

Exponent is constant given mode

organic = 1.05

semi = 1.12

embedded = 1.20

B i M d l


39/112

Basic Model

Schedule Equation (COCOMO 81)

MTDEV (Minimum time to develop) =2.5*(Effort)exponent

2.5 is constant for all modes

Exponent based on modeorganic = 0.38

semi = 0.35

embedded = 0.32

Note that MTDEV does not depend on number of

people assigned.


40/112

CountingKSLOC


41/112

Still how to estimate KSLOC

Get 2 experts to provide estimates. Better if estimates are based on software requirements

Even better if estimates are based on design doc

Good to get best estimate as well as +- size.

Make sure they address integration/glue code/logic. Take average of experts.

If using Work Breakdown Structure (WBS) inscheduling, estimate KSLOC per task. Note not all

tasks have KSLOC. Remember COCOMO is strict development effort not management,

reporting or user support.

COCOMO Does NOT include defining the Requirements/Specification!


42/112

Some beginners guidelines

A good estimate is defendable if the size of the product is identified inreasonable terms that make sense for the application. Without seriousexperience, estimating Lines of Code for a substantial application can

be meaningless, so stick to what makes sense. Bottom up is better forbeginners.

An estimate is defendable if it is clear how it was achieved. If the

estimate simply came from SWAG, or whatever sugar-coated term youwould like to give for an undefendable number), that information itselfgives us an understanding of the legitimacy we can apply to thenumbers, and we should expect a large uncertainty.

If it was achieved by taking the business targets and simply suggestingwe can fit all the work into the available time, we can send the

estimator back to the drawing board. A good estimate allows all the stakeholders to understand what went

into the estimate, and agree on the uncertainty associated with thatestimate. With that, realistic decisions can be made. If there is any

black magic along the way, or if there is a suggestion that you canaccurately predict, you are in for trouble.


43/112

Basic COCOMO assumptions

Implicit productivity estimate Organic mode = 16 LOC/day

Embedded mode = 4 LOC/day

Time required is a function of total effort NOT

team size

Not clear how to adapt model to personnel

availability


44/112

Intermediate COCOMO

Takes basic COCOMO as starting point Identifies personnel, product, computer and

project attributes which affect cost and

development time. Multiplies basic cost by attribute multipliers

which may increase or decrease costs


45/112

Attributes

Personnel attributes Analyst capability

Virtual machine experience

Programmer capability

Programming language experience

Application experience

Product attributes Reliability requirement

Database size

Product complexity


46/112

More Attributes

Computer attributes Execution time constraints

Storage constraints

Virtual machine volatility

Computer turnaround time

Project attributes

Modern programming practices Software tools

Required development schedule

I t di t M d l


47/112

Intermediate Model

Effort Equation(COCOMO 81)

Effort=EAF*A(size)exponent

EAF (effort adjustment factor) is the product of effortmultipliers corresponding to each cost driver rating

A is a constant based on the developmental mode organic = 3.2

semi = 3.0

embedded = 2.8

Size = 1000s Delivered Source Instruction (KDSI)

Exponent is constant given mode


48/112

COCOMO COST DRIVERSRatings range: VL, L, N, H, VH, XH

RELY Reliability PCAP Programmer Capability

DATA Database Size AEXP Applications Experience

CPLX Complexity PEXP Platform Experience

RUSE Required Reusability LTEX Language and Tool Experience

DOCU Documentation PCON Personnel Continuity

TIME Execution Time Constant TOOL Use of Software Tools

STOR Main Storage Constraint SITE Multisite Development

PVOL Platform Volatility SCED Required Schedule

ACAP Analyst Capability

Gone:VIRT,TURN,MDDP,VEXP New: RUSE, DOCU, PVOL, PCON

E l COCOMO


49/112

Example COCOMOTURN and TOOL Adjustments

COCOMO 81 Rating L N H VH

COCOMO Multiplier:

CPLX 1.00 1.15 1.23 1.3

COCOM Multiplier:

TOOL 1.24 1.10 1.00


50/112

Intermediate Model Example

Highly complex intermediate organic projectwith high tool use:

Estimate 3000 DSIs

CPLX = 1.3 (VH)TOOL = 1.10 (L)

EAF = 1.3*1.10 = 1.43

Effort = 1.43 * 3.2 * 31.05 = 14.5 man monthsMTDEV = 2.5 * 14.50.38= 6.9 months

Staff required = 14.5/6.9 = 2.1 people

Effort=EAF*A(KDSI)exp1

MTDEV= 2.5*(Effort)exp2


51/112

Example with options

Embedded software system on microcomputer hardware. Basic COCOMO predicts a 45 person-month effort

requirement

Attributes = RELY (1.15), STOR (1.21), TIME (1.10),

TOOL (1.10)

Intermediate COCOMO predicts

45 * 1.15 * 1.21 * 1.10 *1.10 = 76 person-months.

Assume total cost of person month = $7000.

Total cost = 76 * $7000 = $532, 000


52/112

Option: Hardware Investment

Processor capacity and store doubled TIME and STOR multipliers = 1

Extra investment of $30, 000 required Fewer tools available

TOOL = 1.15

Total cost = 45 * 1.24 * 1.15 * $7000 = $449, 190

Cost saving = $83, 000


53/112

Cocomo in practice (89 projects) Canned Language Multipliers were accuratecan

be tuned/calibrated for a company.

Modeling personnel factors, and creatingoptions/scenarios can be a valuable tool.

Assumptions and Risks should be factored into the

model

Tool Demonstration


54/112

Tool Demonstration(web based version)

http://sunset.usc.edu/research/COCOMOII/expert_cocomo/expert_cocomo2000.html

http://sunset.usc.edu/research/COCOMOII/expert_cocomo/expert_cocomo2000.html

Its Free and easy to use. So Use it!

You can also get a standalone win32 version
http://sunset.usc.edu/research/COCOMOII/expert_cocomo/expert_cocomo2000.htmlhttp://sunset.usc.edu/research/COCOMOII/expert_cocomo/expert_cocomo2000.html


55/112

Free CoCoMo Tools

COCOMO II -This program is an implementation of the 1981 COCOMO IntermediateModel. It predicts software development effort, schedule and effort distribution. It is availablefor SunOS or MS Windows and can be downloaded for free. The COCOMO II model is anupdate of COCOMO 1981 to address software development practice's in the 1990's and 2000's.

Revised Intermediate COCOMO(REVIC) is available for downloading from the USAir Force Cost Analysis Agency (AFCAA).

TAMU COCOMOis an on-line version of COCOMO from Texas A&M University.

Agile COCOMO -The Center continues to do research on Agile COCOMO II a costestimation tool that is based on COCOMO II. It uses analogy based estimation to generateaccurate results while being very simple to use and easy to learn.

COCOTS -The USC Center is actively conducting research in the area of off-the-shelfsoftware integration cost modelling. Our new cost model COCOTS (COnstructive COTS),

focuses on estimating the cost, effort, and schedule associated with using commercial off-the-shelf (COTS) components in a software development project. Though still experimental,COCOTS is a model complementary to COCOMO II, capturing costs that traditionally havebeen outside the scope of COCOMO. Ideally, once fully formulated and validated, COCOTSwill be used in concert with COCOMO to provide a complete software development cost

estimation solution.


56/112

Resources

Software Cost Estimating With COCOMO IIBoehm,Abts, Brown, Chulani, Clark, Horowitz, Madachy, Reifer, Steece ISBN:0-13-026692-2

COCOMO II- http://sunset.usc.edu/research/COCOMOII/

NASA Cost Estimating Web Site-http://www1.jsc.nasa.gov/bu2/COCOMO.html

Longstreet Consulting -http://www.ifpug.com/freemanual.htm

Barry Boehm Bio -http://sunset.usc.edu/Research_Group/barry.html
http://sunset.usc.edu/research/COCOMOII/http://sunset.usc.edu/Research_Group/barry.htmlhttp://sunset.usc.edu/Research_Group/barry.htmlhttp://sunset.usc.edu/research/COCOMOII/


57/112

Conclusions

Experience shows that seat-of-the-pants estimates of costand schedule are 50%- 75% of the actual time/cost. Thisamount of error is enough to get a manager fired in manycompanies.

Lack of hands-on experience is associated with massivecost overruns.

Technical risks are associated with massive costoverruns.

Do your estimates carefully! Keep them up-to-date!

Manage to them!


58/112

Project Scheduling/Planning

COCOMO his high-level resource estimation. Toactually do project need more refined plan.


59/112

Work breakdown structures (WBS)

Types: Process, product, hybrid Formats: Outline or graphical org chart

High-level WBS does not show dependencies or

durations

What hurts most is whats missing

Becomes input to many things, esp. schedule


60/112

Estimation

History is your best allyEspecially when using LOC, function points, etc.

Use multiple methods if possible

This reduces your risk If using experts, use two

Get buy-in

Remember: its an iterative process! Know your presentation techniques


61/112

Estimation

Bottom-up More work to create but more accurate

Often with Expert Judgment at the task level

Top-down Used in the earliest phases

Usually with/as Analogy or Expert Judgment

Analogy Comparison with previous project: formal or informal

Expert Judgment Via staff members who will do the work

Most common technique along w/analogy

Best if multiple experts consulted


62/112

Estimation

Parametric Methods Know the trade-offs of: LOC & Function Points

Function Points Benefit: relatively independent of the technology used to

develop the system We will re-visit this briefly later in semester (when discussing

software metrics)

Variants: WEBMO(no need to know this for exam)

Re-Use Estimation See QSPM outline

U Calgary

l h
http://c/Users/amir%20joshi/AppData/Local/Temp/FPEx.dochttp://www.stsc.hill.af.mil/crosstalk/2002/jun/reifer.asphttp://c/Users/amir%20joshi/AppData/Local/Temp/Misc/QSPM/Chapter_10.ppthttp://pages.cpsc.ucalgary.ca/~hongd/SENG/621/report2.htmlhttp://pages.cpsc.ucalgary.ca/~hongd/SENG/621/report2.htmlhttp://c/Users/amir%20joshi/AppData/Local/Temp/Misc/QSPM/Chapter_10.ppthttp://www.stsc.hill.af.mil/crosstalk/2002/jun/reifer.asphttp://c/Users/amir%20joshi/AppData/Local/Temp/FPEx.dochttp://c/Users/amir%20joshi/AppData/Local/Temp/FPEx.dochttp://c/Users/amir%20joshi/AppData/Local/Temp/FPEx.doc


63/112

Your Early Phase Processes

Initial Planning: Why

SOW, Charter

What/How (partial/1stpass)

WBS

Other planning documents Software Development Plan, Risk Mgmt., Cfg. Mgmt.

Estimating Size (quantity/complexity) and Effort (duration)

Iterates

Scheduling Begins along with 1stestimates

Iterates

S h d li


64/112

Scheduling

Once tasks (from the WBS) and size/effort (fromestimation) are known: then schedule

Primary objectives

Best time Least cost

Least risk

Secondary objectives Evaluation of schedule alternatives

Effective use of resources

Communications

T i l


65/112

Terminology

Precedence: A task that must occur before another is said to have

precedence of the other

Concurrence: Concurrent tasks are those that can occur at the same time

(in parallel)

Leads & Lag Time

Delays between activities Time required before or after a given task

T i l


66/112

Terminology

MilestonesHave a duration of zero

Identify critical points in your schedule

Shown as inverted triangle or a diamond Often used at review or delivery times

Or at end or beginning of phases

Ex: Software Requirements Review (SRR)

Ex: User Sign-off

Can be tied to contract terms

T i l


67/112

Terminology

ExampleMilestones

T i l


68/112

Terminology

Slack & FloatFloat & Slack: synonymous terms

Free Slack Slack an activity has before it delays next task

Total Slack Slack an activity has before delaying whole project

Slack Time TS= TLTE

TE= earliest time an event can take place TL= latest date it can occur w/o extending projects

completion date

S h d li T h i


69/112

Scheduling Techniques

Mathematical Analysis Network Diagrams

PERT

CPM

GERTBar Charts

Milestone Chart

Gantt Chart

N t k Di


70/112

Network Diagrams

Developed in the 1950s A graphical representation of the tasks necessary

to complete a project

Visualizes the flow of tasks & relationships

M th ti l A l i


71/112

Mathematical Analysis

PERTProgram Evaluation and Review Technique

CPM

Critical Path Method Sometimes treated synonymously

All are models using network diagrams

MS P j t E l


72/112

MS-Project Example

N t k Di


73/112

Network Diagrams

Two classic formatsAOA: Activity on Arrow

AON: Activity on Node

Each task labeled with Identifier (usually a letter/code)

Duration (in std. unit like days)

There are other variations of labeling There is 1 start & 1 end event

Time goes from left to right

N d F t


74/112

Node Formats

N t k Di


75/112

Network Diagrams

AOA consists of

Circles representing Events Such as start or end of a given task

Lines representing Tasks Thing being done Build UI

a.k.a. Arrow Diagramming Method (ADM)

AON Tasks on Nodes

Nodes can be circles or rectangles (usually latter) Task information written on node

Arrows are dependencies between tasks

a.k.a. Precedence Diagramming Method (PDM)

Critical Path


76/112

Critical Path

The specific set of sequential tasks upon whichthe project completion date depends

or the longest full path

All projects have a Critical Path Accelerating non-critical tasks do not directly

shorten the schedule

Critical Path Example


77/112

Critical Path Example

CPM


78/112

CPM

Critical Path MethodThe process for determining and optimizing the

critical path

Non-CP tasks can start earlier or later w/oimpacting completion date

Note: Critical Path may change to another as you

shorten the current Should be done in conjunction with the you & the

functional manager

4 Task Dependency Types


79/112


MandatoryDependencies Hard logic dependencies

Nature of the work dictates an ordering

Ex: Coding has to precede testing

Ex: UI design precedes UI implementation

DiscretionaryDependencies Soft logic dependencies

Determined by the project management team Process-driven

Ex: Discretionary order of creating certain modules



80/112


ExternalDependencies Outside of the project itself

Ex: Release of 3rdparty product; contract signoff

Ex: stakeholders, suppliers, Y2K, year end

ResourceDependencies Two task rely on the same resource

Ex: You have only one DBA but multiple DB tasks

Task Dependency Relationships


81/112

Task Dependency Relationships

Finish-to-Start (FS) B cannot start till A finishes

A: Construct fence; B: Paint Fence

Start-to-Start (SS) B cannot start till A starts

A: Pour foundation; B: Level concrete

Finish-to-Finish (FF) B cannot finish till A finishes

A: Add wiring; B: Inspect electrical

Start-to-Finish (SF) B cannot finish till A starts (rare)

Example Step 1


82/112

Example Step 1

Milestone Chart


83/112

Milestone Chart

Sometimes called a bar charts Simple Gantt chart

Either showing just highest summary bars

Or milestones only

Bar Chart


84/112

Bar Chart

Gantt Chart


85/112

Gantt Chart

Gantt Chart


86/112

Gantt Chart

Disadvantages Does not show interdependencies well

Does not uncertainty of a given activity (as does PERT)

Advantages

Easily understood

Easily created and maintained

Note: Software now shows dependencies among tasks in

Gantt charts In the old days Gantt charts did not show these dependencies,

bar charts typically do not. Modern Gantt charts do show them.

Reducing Project Duration


87/112

Reducing Project Duration

How can you shorten the schedule? Via

Reducing scope (or quality)

Adding resourcesConcurrency (perform tasks in parallel)

Substitution of activities

Compression Techniques


88/112

Compression Techniques

Shorten the overall duration of the project

Crashing Looks at cost and schedule tradeoffs

Gain greatest compression with least cost

Add resources to critical path tasks Limit or reduce requirements (scope)

Changing the sequence of tasks

Fast Tracking

Overlapping of phases, activities or tasks that would otherwise besequential

Involves some risk

May cause rework

Mythical Man-Month


89/112

Mythical Man-Month

Book: The Mythical Man-MonthAuthor: Fred Brooks

Theclassic book on the human elements of

software engineering First two chapters are full of terrific insight (and

quotes)

Mythical Man-Month
http://www.amazon.com/exec/obidos/ASIN/0201835959/qid%3D1022856693/sr%3D1-1/ref%3Dsr_1_1/103-4280067-9687806http://www.amazon.com/exec/obidos/ASIN/0201835959/qid%3D1022856693/sr%3D1-1/ref%3Dsr_1_1/103-4280067-9687806http://www.amazon.com/exec/obidos/ASIN/0201835959/qid%3D1022856693/sr%3D1-1/ref%3Dsr_1_1/103-4280067-9687806http://www.amazon.com/exec/obidos/ASIN/0201835959/qid%3D1022856693/sr%3D1-1/ref%3Dsr_1_1/103-4280067-9687806


90/112

Mythical Man-Month

Cost varies as product of men and months,progress does not.

Hence the man-month as a unit for measuring the

size of job is a dangerous and deceptive myth Reliance on hunches and guesses

What is gutless estimating?

The myth of additional manpowerBrooks Law

Adding manpower to a late project makes it later

Mythical Man-Month


91/112

Mythical Man-Month

Optimism All programmers are optimists

1stfalse assumption: all will go well or each task takes only

as long as it ought to take

The Fix: Consider the larger probabilities Cost (overhead) of communication (and training)

His formula: n(n-1)/2

How long does a 12 month project take?

1 person: 1 month

2 persons = 7 months (2 man-months extra)

3 persons = 5 months (e man-months extra)

Fix: dont assume adding people will solve the problem

Mythical Man-Month


92/112

Mythical Man-Month

Sequential nature of the process The bearing of a child takes nine months, no matter

how many women are assigned

What is the most mis-scheduled part of process? Testing (the most linear process)

Why is this particularly bad? Occurs late in process and w/o warning

Higher costs: primary and secondary

Fix: Allocate more test time Understand task dependencies

Mythical Man-Month


93/112

Mythical Man-Month

Q: How does a project get to be a year late? A: One day at a time

Studies

Each task: twice as long as estimatedOnly 50% of work week was programming

Fixes

No fuzzy milestones (get the true status)Reduce the role of conflict

Identify the true status

Planning and Scheduling Tools


94/112

Planning and Scheduling Tools

Big variety of products, from simple/single project toenterprise resource management

See for instance: http://www.columbia.edu/~jm2217/#OtherSoftware

http://www.startwright.com/project1.htm Some free tools to play with:

Ganttproject (java based)

Some tools on linux

Free evaluation Intellysis project desktop

FastTrack Schedule

MS-Project
http://www.columbia.edu/~jm2217/http://www.startwright.com/project1.htmhttp://www.startwright.com/project1.htmhttp://www.columbia.edu/~jm2217/


95/112

MS Project

Mid-market leader

Has approx. 50% overall market share

70-80% MS-Project users never used automated project

tracking prior (a first tool)

Not a mid/high-end tool for EPM (Enterprise Project

Mgmt.)

While in this class you can get a free copy though MS

Academic Allianceemail me if interested.

Project Pros


96/112

Project Pros

Easy outlining of tasks including support for hierarchicalWork breakdown structures (WBS)

Resource management

Accuracy: baseline vs. actual; various calculations

Easy charting and graphics

Cost management

Capture historical data

Project Cons


97/112

Project Cons

Illusion of control

Workgroup/sharing features ok, still in-progress

Scaling

No estimation features Remember:

Being a MS-Project expert does not make you an

expert project manager!No more so than knowing MS-Word makes you a

good writer.

P j UI


98/112

Project UI

Indicators

Task Sheet

View Bar

Enter Tasks

Here

Gantt Chart

Timescale

Task Bars

Milestone

Split Bar

Outline

Buttons

(Un)Link Buttons Toolbars

The MS-Project Process


99/112

The MS Project Process

Move WBS into a Project outline (in Task Sheet)

Add resources (team members or roles)

Add costs for resources

Assign resources to tasks Establish dependencies

Refine and optimize

Create baseline

Track progress (enter actuals, etc.)

Create Your Project


100/112

Create Your Project

File/New Setup start date

Setup calendar

Menu: Project/Project Information

Often left with default settings

Hours, holidays

Enter WBS


101/112

Enter WBS

Outlining

Sub-tasks and summary tasks

Do not enter start/end dates for each

Just start with Task Name and Duration for each Use Indent/Outdent buttons to define summary

tasks and subtasks

You can enter specific Start/End dates but dontmost of the time

Establish Durations


102/112

Establish Durations

Know the abbreviations h/d/w/m

D is default

Can use partial

.5d is a half-day task

Elapsed durations

Estimated durations

Put a ? after duration

DURATION != WORK (but initial default is that it is)

Add Resources


103/112

dd esou ces

Work Resources People

(can be % of a person. All resources split equally on task.

Tboult[25%], Eng1 means task gets 25% of tboults time, 100% of Eng1 thus

it gets 1.25MM per month).

Material Resources

Things

Can be used to track costs

Ex: amount of equipment purchased

Not used as often in typical software project

Resource Sheet


104/112

Can add new resources here Or directly in the task entry sheet

Beware of mis-spellings (Project will create near-duplicates)

Setup costs

Such as annual salary (put yr after Std. Rate)

Effort-Driven Scheduling


105/112

g

MS-Project default Duration * Units = Work

Duration = Work / Units (D = W/U)

Work = Duration * Units (W = D*U)

Units = Work / Duration (U = W/D) Adding more resources to a task shortens duration

Can be changed on a per-task basis In the advanced tab of Task Information dialog box

Task Type setting

Beware the Mythical Man-month Good for laying bricks, not always so for software development

Link Tasks


106/112

On toolbar: Link & Unlink buttons Good for many at once

Or via Gantt chart

Drag from one task to another

Milestones


107/112

Zero duration tasks Insert task normally but put 0 in duration

Common for reports, Functional module/test

completions, etc.

Good SE practice says milestones MUST be

measurable and well spread through the project.

Make Assignments


108/112

g

Approach 1. Using Task Sheet Using Resource Names column

You can create new ones by just typing-in here

2. Using Assign Resources dialog box

Good for multiple resources Highlight task, Tools/Resources or toolbar button

3. Using Task Information dialog Resources tab

4. Task Entry view View/More Views/Task Entry

Or Task Entry view on Resource Mgmt. toolbar

Save Baseline


109/112

Saves all current information about your project Dates, resource assignments, durations, costs

Fine Tune


110/112

Then is used later as basis for comparing againstactuals

Menu: Tools/Tracking/Save Baseline

Project 2002


111/112

j

3 Editions: Standard, Professional, Server MS Project Server 2002

(TBs never used server 2002 or newer) Based on docs.

Upgrade of old Project Central

Includes Project Web Access, web-based UI (partial) Workgroup and resource notification features

Requires SQL-Server and IIS

Portfolio Analyzer

Drill-down into projects via pivot tables & charts

Portfolio Modeler

Create models and what-if scenarios

SharePoint Team Services integration

Newer versions of Project


112/112

j

MS-Project Professional Build Team feature Skills-based resource matching

Resource Pools: with skill set tracking

Resource Substitution Wizard Project Guide feature

Customizable process component

Documents

57261818 Project Estimation