Software Project Planning

SEN-269 : Software EngineeringEngr. Tazeen Muzammil

Project Planning

The overall goal of project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule.

Why?So the end result gets done on time, under budget and with quality!

2

Project Planning TaskEstablish project scopeDetermine feasibilityAnalyze risks (Done in previous lecture)Define required resources

Determine require human resourcesDefine reusable software resourcesIdentify environmental resources

Estimate cost and effortDecompose the problemDevelop two or more estimates using size, function points, process tasks or use-casesReconcile the estimates

Develop a project schedule (Done in previous lecture)

3

Software Sope

4

What is Scope?Software scope describes

the functions and features that are to be delivered to end-usersthe data that are input and outputthe “content” that is presented to users as a consequence of using the softwarethe performance, constraints, interfaces, and reliability that bound the system.

Scope is defined using one of two techniques:A narrative description of software scope is developed after communication with all stakeholders.A set of use-cases is developed by end-users.

5

Obtaining Information Necessary for Scope

Understand the customers needsUnderstand the business contextUnderstand the project boundariesUnderstand the customer’s motivationUnderstand the likely paths for changeUnderstand that ...

Even when you understand, nothing is guaranteed!

6

Feasibility

Once the scope has been identified, then we ask the following questions:

Technology: Do we have the requisite technology.Finance: Do we have the requisite finances/budget.Resources: Do we have the requisite skilled resources.

7

Resources

8

Resources

9

Estimation

10

EstimationEstimation of resources, cost, effort and schedule requires

experienceaccess to good historical information (metrics)the courage to commit to quantitative predictions when qualitative information is all that exists

Project scope must be understoodElaboration (decomposition) is necessaryAt least two different techniques should be usedUncertainty is inherent in the processEstimation should define

Best case scenarioWorst case scenario

11

Why Estimate Software?

30% of project never complete 100-200% cost overruns not uncommon Average project exceeds cost by 90%; schedule by 120% 15% of large project never deliver anything Only 16.2% of projects are successful

12

What are the consequences?

EconomicLoss of contracts Company failure

TechnicalDependency on software growing

ManagerialChange of personnel

13

Estimation Techniques

Expert JudgmentEstimation by AnalogyPricing to winDecomposition Techniques (e.g. LOC, FP Based )Empirical models (e.g. COCOMO)Automated EstimationTools

14

Expert JudgementOne or more experts in both software development and the application domain use their experience to predict software costs.Process iterates until some consensus is reached.Pros:

Little or no historical data needed. Suitable for new or unique projects.Relatively cheap method; Accurate if experts have direct experience of similar systems

Cons:Very subjective.Experts may introduce bias.

Larger number of experts will help to reduce biasQualification of experts may be questioned.

15

• Gather a group of experts together,• Describe overall program in enough detail so experts can

provide an estimate.• Each member of the expert group then does an

independent of the resources needed.• Estimates are gathered anonymously and compared,• If there exists significant divergence among the

estimates, the estimates will be returned to the expert group,

• The expert group then discusses the estimates and the divergence and works to resolve differences, and

• The expert group once again submits anonymous, independent estimates which continues until a stable estimate results.

16

Expert Judgement-Steps

Expert Judgement-Example

Three software engineers are renown in the ERP software development.

You hold interviews with each explaining the requirements, sizing level, and development process for your new system. Each member of the group submits their opinion of the final cost and the estimate converges to $50M.

17

Estimation by Analogy

Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available.

Actual costs of similar existing system are adjusted for complexity, technical, or physical differences to derive new cost estimatesAnalogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approachCompares similarities and differences

Focus is on main cost drivers.

18

Estimation by AnalogyPros:

InexpensiveEasily changedBased on actual experience (of the analogous system)

Cons:Very SubjectiveLarge amount of uncertaintyTruly similar projects must exist and can be hard to findMust have detailed technical knowledge of program and analogous systemNeeds systematically maintained cost database

19

Estimation by Analogy-Steps

Determine estimate needs/ground rules,Define new system,Breakout new system into subcomponents for analogy estimating,Assess data availability of historical similar systems,Collect historical system component technical and cost data,Process/normalize data into constant year dollars (e.g., constant FY2003$), Develop factors based on prior system,

Example: Program Management is 10% of total development cost

Develop new system component costs.Obtain complexity (and other translation) factorsExample: Historical database is for 4 million records and new database will need to house 24 million records => complexity factor of 6 (4*6 = 24) times the historical database costApply factors to historical costs to obtain new system costs

20

Estimation by Analogy- Example

Your company is developing a new IT payroll system serving 5,000 people and containing 100,000 lines of C++ code. Another company developed a similar 100,000 lines of code system for $20M for only 2,000 people. Your software engineers tell you that the new system is 25% more complicated than the other system. Other system development cost was $20M.

Estimated cost for new system = 1.25 * $20M = $25M

Plus 5,000/2,000, or 2.5 * $25M = $62.5M total cost

21

Pricing to winThe project costs whatever the customer has to spend on it.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 is constrained by that cost.A detailed specification may be negotiated or an evolutionary approach used for system developmentAdvantages:

You get the contract.Disadvantages:

The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required.

22

Decomposition Techniques

23

Decomposition TechniquesTo obtain an estimation, we can decompose the problem to be solved, or decompose the process.Decomposition should be done in such a way that

1. size can be properly estimated,2. cost or effort required for each component

can be accurately estimated,3. the team's ability to handle the

components is well known, and

24

Problem-Based Estimation1. Based on the software scope, decompose the

software into problem functions that can be estimated individually.

2. Estimate LOC or FP of each function.3. Make optimistic (sopt), most likely (sm), and

pessimistic (spess) estimates for each item. Then compute the expected value:

EV (Expected Value) = (sopt + 4 sm + spess)/6

4. Apply baseline productivity metrics to compute estimated cost or effort.

25

ExampleProblem Statement: Take the Library management system case. Software developed for library will accept data from operator for issuing and returning books. Issuing and returning will require some validity checks. For issue it is required to check if the member has already issued the maximum books allowed. In case for return, if the member is returning the book after the due date then fine has to be calculated. All the interactions will be through user interface. Other operations include maintaining database and generating reports at regular intervals.

26

ExampleMajor software functions identified.

User interfaceDatabase managementReport generation

For user interfaceSopt : 1800Sm : 2000Spess : 4000

For database managementSopt : 4600Sm : 6900Spess : 8600

For report generationSopt : 1200Sm : 1600Spess : 3200

27

EV for user interfaceEV = (1800 + 4*2000 + 4000) / 6EV = 2300

EV for database managementEV = (4600 + 4*6900 + 8600) / 6EV = 6800

EV for report generationEV = (1200 + 4*1600 + 3200) / 6EV = 1800

Lines of code (LOC)

Given:LOC Estimate = 33200 LOCProductivity = 620 LOC/P-M(Person-Month)Labor Rate = $ 8000 P-M

Effort = LOC/ProductivityCost per LOC = Labor Rate/ProductivityProject Cost= LOC estimate * Cost per LOC

28

Effort = 54 P-MCost per LOC = $ 13 P-MProject Cost= $ 431600

LOC-Example

29

Functions

UICF

2DGA

3DGA

DSM

CGDF

PCF

DAM

Totals

estimated LOC $/LOC Cost Effort (months)LOC/pm

2340

5380

6800

3350

4950

2140

8400

33,360

14

20

20

18

22

28

18

315

220

220

240

200

140

300

32,000

107,000

136,000

60,000

109,000

60,000

151,000

655,000

7.4

24.4

30.9

13.9

24.7

15.2

28.0

145.0

Function PointFive information domain characteristics are determined and counts for each are provided and recorded in a table.

Number of user inputsNumber of user outputsNumber of user inquiresNumber of filesNumber of external interfaces

Once the data have been collected, a complexity value is associated with each count. Each entry can be simple, average or complex. Depending upon these complexity values is calculated.

30

Function PointFunction Point Formula:

FP = Count Total * [0.65+0.01*Sum(Fi)]

Fi are complexity adjustment values based on response to questions(1-14) given below. The constant values in the equation and the weighing factors that are applied to information domain are determined empirically.

Rate each factor on a scale of 0 to 5

0 - No influence1 - Incidental2 - Moderate3 - Average4 - Significant5 - Essential

Count-total is sum of all FP entries.

31

Fi1. Does the system require reliable backup and recovery?2. Are data communications required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational environment?6. Does the system require on-line entry?7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?8. Are the inputs, outputs, files, or inquiries complex9. Is the internal processing complex?10. Is the code designed to be reusable?11. Are master files updated on-line?12. Are conversion and installations included in the design?13. Is the system designed for multiple installations in different organizations?14. Is the application designed to facilitate change and ease of use by the user?

32

Function PointOnce function points have been calculated, productivity, quality, cost and documentation can be evaluated.

Productivity = FP / person-monthQuality = defects / FPDocumentation = pages of documentation / FPEffort = FP Estimate/ProductivityCost per FP = Labor rate/ProductivityProject Cost Estimate = FP * Cost per FP

33

Computing function-point metrics

34

Example (Same as LOC)

35

Information Domain Values

Optlikely

Pessest Account

wt FP Account

Number of Inputs 4 10 16 10 4 40

Number of Outputs 4 7 16 8 5 40

Number of Inquiries 5 12 19 12 4 48

Number of Files 3 6 9 6 10 60

Number of external interfaces

2 2 3 2 7 14

Count Total 202

ExampleComplexity weighing factors are determined and the following results are obtained.

36

Factor Value

Backup Recovery 4

Data Communication 1

Distributed processing 0

Perfomance Critical 3

Existing Operating Environment 2

On-line data entry 5

Input transaction over multiple screens

5

Master file updated online 3

Information domain values complex 3

Internal processing complex 2

Code design for reuse 0

Conversion/Installation in design 1

Multiple installations 3

Application designed for change 5

Sum ( Fi ) 37

ExampleEstimated number of FP :FPestimated = count-total * [0.65 + .01 * sum(Fi) ]FPestimated = 206From historical data, productivity is 55.5 FP/person-month and development cost is $8000 per month.Productivity = FP/ person-monthperson-month = FP/Productivity= 202/55.5 = 3.64 person-monthTotal Cost = Development cost * person-month= 8000 * 3.64=$29100Cost per FP = Cost/FP= 29100/202= $144.2per FP

37

Function Point-Example

38

number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces algorithms

measurement parameter

4 5 4 7 7 3

count

x x x x x x

count-total

= = = = = =

weight

complexity multiplier

feature points

0.25 p-m / FP = 120 p-m

40 25 12 4 4 60

160 125 48 28 28 180

569

.84

478

Given Productivity = 6.5 FP/P-MLabor Rate = $8000/P-M

Process-based estimationMost commonly-used technique for project estimationProject is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimatedBegins with a delineation of software functions obtained from the project scope

Process-based estimationA series of framework activities must be performed for each functionRepresentative framework activities:

Customer communicationPlanning / risk analysisEngineeringConstruction / release

Functions and activities may be shown together as a table:

Process-based estimation table

Activity CC PlanningRisk

analysisEngineering Release CE Totals

Function Anal. Design Code Test

UICF 0.75 2.50 0.40 5.00 n/a 8.65

2DGA 0.75 4.00 0.60 2.00 n/a 7.35

3DGA 0.50 4.00 0.60 2.00 n/a 7.10

CGDF 0.50 4.00 1.00 3.00 n/a 8.50

DBM 0.50 3.00 1.00 1.50 n/a 6.00

PCF 0.25 2.00 0.75 1.50 n/a 4.50

DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals .25 .25 .25 3.50 17.50 4.25 15.00 34.80

% effort 1% 1% 1% 7% 45% 12% 40%

Process-based estimationOnce functions and activities are melded, the planner estimates the effort (person-months) required to accomplish each activity per functionAverage labor rates are then applied to the estimated efforts (may vary per task)Cost and effort for each function and activity (row and column totals) are computed as the last step

Empirical Estimation Models

An estimation model provides empirically derived formulas to predict effort as a function of LOC or FP.The data used to support these models are derived from a limited sample. Thus no model is appropriate for all classes of software.

43

Empirical models

Examples of Commercially Available ModelsCOCOMOThe Software EquationCOSTXPERTSLIMSEERCostar, REVIC, etc.

44

Structure of Estimation Model

E = A + B XC

where A, B, and C are empirically derived constants, E is the effort in person months, and X is the estimation variable, either in LOC or FP.

45

COCOMO

COCOMO, COnstructive COst MOdel is static single-variable model. Barry Boehm introduced COCOMO models. There is a hierarchy of these models. Model 1:

Basic COCOMO model is static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code.

Model 2:Intermediate COCOMO model computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes.

Model 3:Advanced COCOMO model incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step, like analysis, design, etc.COCOMO can be applied to the following software project's categories.

46

Three Software Project's Categories

Organic -- a relatively small simple project in which small teams with good application experience work to a set of less than rigid requirements.

Semi-detached -- an intermediate project in which teams with mixed experience must meet a mix of rigid and less than rigid requirements.

Embedded -- a project that must meet tight hardware, software, and operational constraints.

47

COCOMOThe COnstructive COst MOdel

It is LOC-based.Formula:

E = a(KLOC)bT = cEd

where E is the effort required in person-months, T is the required development time in chronological months, KLOC is the estimated size of software in thousand lines of delivered source code. The constants a, b, c, and d are listed below:

48

The Software Equation

A dynamic multivariable modelE = [LOC x B0.333/P]3 x (1/t4)

whereE = effort in person-months or person-yearst = project duration in months or yearsB = “special skills factor”P = “productivity parameter”

49

Automated Estimation Tools

The automated estimation tools allow the planner to estimate cost and effort and to perform what if analysis for important project variables such as delivery date or staffing.Six generic functions:1. Sizing of project deliverables2. Selecting project activities3. Predicting staffing levels4. Predicting software effort5. Predicting software cost6. Predicting software schedules

50