Software Project Planning

Observations on Estimating Estimation of Resources, Cost and Schedules Factors affecting estimation Project Complexity Project Size Degree of Structural uncertainty

March 2004

Chapter 5 Software Project Planning 1

Software Project Planning
Steps to Software Planning Define Software Scope Determine Resources Create Project Estimates Make or buy decision

March 2004

Chapter 5 Software Project Planning 2

What scope means: Functions Literally refers to all functions performed by a system Performance Refers to processing and response time requirements Constraints Limits placed on the software by external hardware, available memory or existing systems Interfaces Reliability
March 2004 Chapter 5 Software Project Planning 3

Obtaining the information Communication, communication, communication!!! Meet with customer as often as needed. Have free form discussion Try to understand his/her goals/constraints, not just what she/he thinks they want. Government procurement often provides detailed written specifications on what they want. The problem is that those writing them probably didn¶t fully understand, and they will change. Government is trying for a more enlightened approach.
March 2004 Chapter 5 Software Project Planning 4

Scope Information
Some typical questions Overall Goals Who¶s request; What benefit; Who else has solution Understanding The Problem What output; What Problem; What Issues; What Constraints Effectiveness of Meeting Are answers official; Are my questions relevant; Other sources of Info.

March 2004

Chapter 5 Software Project Planning 5

Scoping - Subsequent Meetings
Begin high level planning Know the capabilities of existing software and staff Joint teams of customer and developers/analysts Checklist of items to cover Organization of Information Get everything down with diagrams Create and save transcripts of Meetings Possibly use Web.

March 2004

Chapter 5 Software Project Planning 6

Scoping Example
Conveyor Line Motion ID No. ID No. ID No. ID No. Bin 2 Bin 3 Bin 4
Control connection
March 2004 Chapter 5 Software Project Planning 7

Bin 1

Bar Code

Sorting Station

Bin 5

Project Decomposition
For our example: Read bar code input Read pulse tachometer Decode part code data Do database lookup Determine bin location Produce control signal for shunt Maintain record of box destinations

March 2004

Chapter 5 Software Project Planning 8


March 2004

Chapter 5 Software Project Planning 9

For each type of resources, 4 characteristics are examined: Description of resource Availability Time resource needed Duration of time for which the resource is needed

March 2004

Chapter 5 Software Project Planning 10

Human Resources
Scope and skills required Organizational position and specialty must both be considered As estimate of development effort is essential to determine the number of people required for the project.

March 2004

Chapter 5 Software Project Planning 11

Reusable Software Resources
Off-the-shelf components Existing s/w acquired from 3rd party, fully validated Full experience components Existing specs, code or test data developed for past projects Partial experience components New validation will have to be performed New Components

March 2004

Chapter 5 Software Project Planning 12

Environmental Resources
Software Engineering Environment Compilers Editors Design tools Configuration management tools Management tracking tools Problem Reporting And Corrective Action (PRACA) tools Documentation tools Hardware resources Network support
March 2004 Chapter 5 Software Project Planning 13

Software Project Estimation
Estimation critical -- software costs usually dominate project. Categories of estimation techniques Delay estimation until late in the project Base estimates on similar projects already completed Use simple decomposition (possibly in combination with other methods). Use one or more empirical models, i.e., d = f(vi) where d ± no of estimated values; vi ± LOC or FP etc. For example, # of people = LOC ÷(Duration*(LOC/PM))
March 2004 Chapter 5 Software Project Planning 14

Decomposition Techniques
Software Sizing The degree of the size of product estimated Ability to translate size estimate into human effort, calendar time, dollars The degree to which project plan reflects abilities of s/w team The stability of product reqs. and the environment that supports the se effort Using Direct approach, size can be measured in LOC Using Indirect approach, size is represented as FP

March 2004

Chapter 5 Software Project Planning 15

Software Sizing
4 approaches to Software Sizing problem ³Fuzzy Logic´ Sizing Function Point Sizing Standard Component Sizing Change Sizing These methods can be combined statistically to create a ThreePoint or expected value estimate Done by developing Optimistic(low), most likely, and pessimistic(high) values for size and combining them in equation

March 2004

Chapter 5 Software Project Planning 16

Problem-Based Estimation
Projects should be grouped by team size, application area, complexity, other parameters. Local domain averages should be computed. When new project is estimated, first allocate it to a domain, and them determine domain average to generate the estimate LOC use decomposition invariably, function wise. FP uses info domain characteristics ± inputs, outputs, data files, inquiries, external interfaces ± as well as the 14 complexity adjustment values

March 2004

Chapter 5 Software Project Planning 17

Software Project Estimation
Precise estimation is difficult. So, make three estimates: optimistic, most likely, and pessimistic. Then combine as: Expected value of size EV=(Sopt + 4Sm + Spess)/6 An example ± CAD application s/w for mechanical unit user interface and control facilities 2-D geometric analysis 3-D opt = 4600 LOC 3-D geometirc analysis 3-D m. likely = 6900 LOC database management 3-D pess. = 8600 LOC computer graphics display => (4600+4*6900+8600)/6 peripheral control = 6800 design analysis models
March 2004 Chapter 5 Software Project Planning 18

Estimation Table

‡ Suppose 620 LOC/PM, and $8,000/PM, based upon historical data. Then, Est. Cost = 33,200*$8,000/620 = $431,000 & Est. effort = 54 person months
March 2004 Chapter 5 Software Project Planning 19

Function Point Based Estimation
Function Point Complexity Weighting Factors backup and recovery 4 Data communications 2 Distributed processing 0 Performance critical 4 Existing operating environment 3 On-line data entry 4 « Application designed for change 5 Total 52
March 2004 Chapter 5 Software Project Planning 20

Function Point Based Estimation

Complexity factor = [0.65  0.01v § Fi ] = 0.65+0.01×52 = 1.17 FP estimate = count-total× [0.65  0.01v § Fi ] = 318 × 1.17 = 372 Then, if 6.5 FP/PM, cost = 372 × $8,000 ÷ 6.5 = $457,000 and 58 person months Chapter 5 Software Project Planning March 2004

Process Based Estimation
Decompose the process into a set of activities or tasks Estimate effort or cost to perform each task Estimate cost of each function May be done using LOC and FP estimation or separately If estimated separately, then there are two or three distinct cost estimates. Reconcile differences If radically different, perhaps problem is not well understood, or productivity data is obsolete, or the models have not been used correctly.
March 2004 Chapter 5 Software Project Planning 22

Process Based Estimation -- Example
Customer Activity Communication Planning Risk Analysis

Analysis Design

Customer Evaluation Construction Release
Code Test

Function UICF 2DGA 3DGA DSM CGDF PCF DAM Total % effort 0.25 1% 0.25 1% 0.25 1% 0.50 0.75 0.50 0.50 0.50 0.25 0.50 3.50 8% 2.50 4.00 4.00 3.00 3.00 2.00 2.00 20.50 45% 0.40 0.60 1.00 1.00 0.75 0.50 0.50 4.75 10% 5.00 2.00 3.00 1.50 1.50 1.50 2.00 16.50 36% n/a n/a n/a n/a n/a n/a n/a

‡ If labor rate is $8,000/PM, then Est. cost = $368,000
March 2004 Chapter 5 Software Project Planning 23

Empirical Estimation Models
Based on limited number of sample projects Typical form E = A + B×(ev)C Some examples E = 5.2×(KLOC)0.91 Walston-Felix Model E = 5.5 + 0.73×(KLOC)1.16 Bailey-Basili Model E = 3.2×(KLOC)1.05 Boehm simple model E = 5.288×(KLOC)1.047 Doty model for KLOC > 9 E = -13.39 + 0.0545×FP Albrecht & Gaffney E = 60.62 + 7.728×10-8FP3 Kemerer Model E = 585.7 + 15.12×FP Albrecht & Gaffney Must calibrate for local conditions
March 2004 Chapter 5 Software Project Planning 24

‡Application Composition model --Used during early stages of design ‡Early Design Stage model --When basic s/w archie. has been established ‡Post-Architecture stage model --During construction of s/w ‡3 sizing options ± object points, function points & LOC
March 2004 Chapter 5 Software Project Planning 25

Object point is computed using count of 1. Screen 2. Report & 3. Components required to build the application Object Type Simple Screen Report 3GL comonent 1 2 Complexity Weight Medium 2 5

Difficult 3 8 10

NOP = (object points) * [(100 - %reuse)/100]; NOP -> new object points Productivity rate = NOP/person-month
March 2004 Chapter 5 Software Project Planning 26

Developers experience/capability Environment maturity/capability PROD Estimated effort = NOP/PROD Very low Very low 4 Low Low 7 Nominal Nominal 13 High High 25 Very High Very High 50

March 2004

Chapter 5 Software Project Planning 27

³The Software Equation´
The software equation -- E=[LOC * B0.333/P]3 * (1/t4), where E = effort in person months t = project duration in months B = ³special skills factor´ For KLOC (5, 15) use 0.16, for KLOC > 70, use B = 0.39 P = ³productivity parameter´ reflecting overall process maturity and management practices extent to which good software engineering used state of software environment skill and experience of team complexity of application
March 2004 Chapter 5 Software Project Planning 28

Software Equation Example
Typical productivity values P e.g., 2,000 for real-time, 10,000 for tele-comm, 28,000 for business applications. Simplified model suggested for tmin, E: tmin = 8.14(LOC/P)0.43 in months for tmin > 6 months E = 180Bt3 for E >= 20 person months For P = 12,000 (typical scientific computation) tmin = 8.14(33,200/12,000)0.43 = 12.6 months E = 180(0.28)(1.05)3 = 58 person months Study implications of these equations. Trying to get done too fast requires much more effort.
March 2004 Chapter 5 Software Project Planning 29

Resources - Make-Buy Decision
Acquire or develop? Make/buy? Acquisition options: S/w may be purchased off-the-shelf ³Full-experience or partial-experience components may be acquired and then modified an integrated to meet specific needs S/w can be custom built by an outside contractor to meet purchaser¶s specifications. For expensive s/w, some guidelines are to be followed:

March 2004

Chapter 5 Software Project Planning 30

Resources - Make-Buy Decision
Develop specification for desired software Estimate cost to develop internally and estimate delivery date Select candidate applications that come closest to meeting specifications. Select reusable components that could assist constructing the required application Develop comparison matrix that compares key functions and costs. Possibly conduct benchmark tests Evaluate each s/w package or component based on past product quality, vendor support,. Product direction, reputation and the like Contact other users of the s/w and ask for opinions
March 2004 Chapter 5 Software Project Planning 31

Resources - Make-Buy Decision
Make/Buy decision is made based on following: Will the delivery date of s/w product be sooner than that for internally developed s/w? Will the cost of acquisition plus the cost of customization be less than the cost of developing the s/w internally Will the cost of outside support (e.g. maintenance contract) be less than the cost of internal support?

March 2004

Chapter 5 Software Project Planning 32

Decision Tree Support
EC = §(path prob)i * (est. path cost)
simple (.30) Build reuse major changes (.60) buy difficult (.70) minor changes (.40) simple (.20) complex (.80) minor changes (.70) $380,000 $450,000 $275,000 $310,000 $490,000 $210,000 $400,000 $350,000

System X Expected cost = ™ (path probablity)I x (estimated path cost)I
March 2004

major changes (.30) contract without changes (.60)

with changes (.40) Chapter 5 Software Project Planning



Make/Buy Decision
1. 2. 3. 4. Build system X from scratch Reuse partial-experience components to construct the system Buy an available s/w product and modify to meet local needs Contract the s/w development to an outside vendor The ev for cost computed along any branch is Expected cost = § (Path probability)i x (estimated path cost) I where i = decision tree path. For the ³build´ path EC(build) = 0.30 ($380K) + 0.70 ($450K) = $429K EC(reuse) = 0.40 ($275K) + 0.60 (0.20 ($310K) + 0.80 ($490K) = $382 K
March 2004 Chapter 5 Software Project Planning 34

Make/Buy Decision
EC(buy) = 0.70 ($210K) + 0.30 ($400K) = $267K EC(contract) = 0.60 ($350K) + 0.40 ($500K) = $410K Based on above figures, the lowest expected option is ³buy´ option. Availability, experience of developer/vendor/contractor, conformance to requirements, local ³politics´ and likelihood of change are also the criteria that may affect the decision to build, reuse, buy or contract.

March 2004

Chapter 5 Software Project Planning 35

Project planner must estimate three things: how long project will take how much effort will be required how many people will be required Must use decomposition and empirical modeling Most empirical techniques need to be calibrated to individual situations. Use multiple techniques to gain confidence in result

March 2004

Chapter 5 Software Project Planning 36