Project Planning

Instructor: Dr. Jerry Gao

Project Planning

Jerry Gao, Ph.D. Jan. 1999

- Software Scope- Obtaining Information Necessary for Scope- A Scoping Example

- Resources- Software Project Estimation- Decomposition Techniques

- Software Sizing- Problem-based Estimation- Process-Based Estimation

- Empirical Estimation Models- The Structure of Estimation Models- The COCOMO Model- The Software Equation

- The Make-Buy Decision

Project Planning

Project planning is one of the first activity in a software process.The quality and accuracy of a software project

---> affect the process, product quality, and schedule.

Objectives: reasonable estimation on resources, cost, and schedule

Major problem in project planning is the uncertainty of a project plan.The risks caused by:

- Project complexity- Project size- The degree of structural uncertainty- Understanding of the project and system- Changes of requirements

Note: a project manager should not become obsessive about estimation.Modern software engineering approaches take an iterative view of development.

Revisit the estimation and revise it when the customer makes changes to requirements.

Software Scope

The first activity in software project planning --> determination of software scope.

Goal: To define a unambiguous and understandable project scope at management and technical levels.

Software scope:function, performance, constraints, interfaces, and reliability.

delivery deadlines, budgetary restrictions, personnel availabilitytechnical interfaces, and so on.

Without these information, it is impossible- To define reasonable estimates of the cost- To conduct an effective assessment of risk- To do realistic breakdown of project tasks- To come out a manageable project schedule

Obtaining Information

To define a project scope, we need a lot of information through a communication process.

A preliminary meeting or interview is a common technique to bridge thecommunication gap between engineers and the customer.

Analysts must ask context free questions to lead a basic understanding ofthe problem and the desired solutions.

Communication with the customer --> - definition of the data, functions, and behavior,- the performance and constraints.

Questions focus on the customer, goals, and the benefits:

- Who is behind the request for this work?- Who will use the solution?- What will be the economic benefit of a successful solution?- Is there another source for the solution?

Obtaining Information

Questions focus on solutions (from the customer’s perceptions):

- How would you characterize “good” output that would be generated by a successful solution?- What problem(s) will this solution address?- Can you show me (or describe) the environment where the solution will be used?- Are there special performance issues (or constraints)?

The final set of questions: (meta-questions)

- Are you the right person to answer these questions? Are your answers “official”?- Are my questions relevant to the problem that you have?- Am I asking too many questions?- Is there anyone else who can provide additional information?- Is there anything else that I should be asking you?

The Q&A session should be used for the first encounter only.

Resources

People

Reusable Software Components

Hardware/Software Tools

Reusable Software Resources:

Bennatan [Ben92] suggests four software resource categories:

- Off-the-shelf components: third-party software, ready for use and validated.

- Full-experience components: existing specification, design, code or test data from past projects.---> small changes and low risk.

- Partial-experience components: existing specification, design, code, or test data from past projects.---> needs a lot of changes, a fair degree of risk.

- New components: new software components must be built by the software team .

Resources

People

Reusable Software Components

Hardware/Software Tools

Reusable Software Resources:

Bennatan [Ben92] suggests four software resource categories:

- Off-the-shelf components: third-party software, ready for use and validated.

- Full-experience components: existing specification, design, code or test data from past projects.---> small changes and low risk.

- Partial-experience components: existing specification, design, code, or test data from past projects.---> needs a lot of changes, a fair degree of risk.

- New components: new software components must be built by the software team .

Resources

Guidelines used by software planner when reusable components are specified as a resource:

- If off-the-shelf components meet project requirements, acquire them.Because: cost is low, risk is small.

- If full-experience components are available, the risks associated with modification and integration are generally acceptable. The project plan should reflect this.

- If partial-experience components are available, their use for the current project should beanalyzed in detail.

Software Project Estimation

Software cost and effort estimation will never be an exact science. Too many variables can affectthe ultimate cost of software and effort.

For example, human, technical, environmental, political,….

To achieve reliable cost and effort estimation, a number of options arise:

- Delay estimation until late in the project.--> not practical.

- Base estimation on similar completed projects--> work reasonability well if the current project is quit similar to the past projects.However, past experience has not always been a good indicator.

- Use relatively simple “decomposition techniques” to generate project cost and effort estimation--> a viable approach to software project estimation.

- Use one or more empirical models for software cost and effort estimation.--> can be used to complement decomposition techniques and offer a potentiallyvaluable estimation approach. --> based on the past experience in a specific environment for application projects.

Decomposition Techniques

--> Problem decomposition and process decompositionBefore an estimate can be made, the project planner must understand the scopeof the software to be built and generate an estimate of its “size”.

Software Sizing:

The accuracy of a software project estimate is predicated on a number things:- The degree to which the planner has properly estimated the size of the product to be built.- The ability to translate the size estimate into human effort in time and cost.- The degree to which the project plan reflects the abilities of the software team- The stability of product requirements and the environment that supports the software engineering effort.

Putnam and Myers [PUT92] suggest four different approaches to the sizing problem:a) Fuzzy-logic sizing b) Function point sizingc) Standard component sizing d) Change sizing

Problem-Based Estimation

Line of code (LOC) and function points (FP) are basic metrics to measure productivity.

LOC and FP data are used in two ways during software project estimation.- As an estimation variable that is used to “size” each element of the software.- As baseline metrics collected from past projects and used in conjunction withestimation variables to predict project cost and effort.

As a project planner, he/she first decompose software into problem functionsuntil each of them can be estimated individually.

Next, Baseline productivity metrics (LOC/pm or FP/pm) are then applied tothe appropriate estimation variable and cost (or effort) for each function.

Alternatively, the planner may choose another component for sizing such as classes (or objects), changes, or business processes.

For FP estimation, decomposition works differently.--> Focus on each of the information domain characteristics, such as

inputs, outputs, data files, inquires, and external interfaces, and so on.

Problem-Based Estimation

A three-point or expected value:

EV = (Sopt + 4Sm + Spess)/6 (one typical example)

- EV - Expected value for the estimation variable (size).- the optimistic (Sopt) estimate.- the most likely (Sm).- the pessimistic (Spess) estimate.

This assumes that there is a very small probability that the actual size result willfall outside the optimistic or pessimistic values.

Once the expected value for the estimation variable has been determined,historical LOC or FP productivity data are applied. Are the estimates correct?

The only answer to this question is: “We can’t be sure.”

An Example of LOC-based Estimation

A preliminary statement of software scope can be developed:The CAD software will accept two- and three- dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human-machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design and analysis modules will be developed to produce required output which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, and laser printer.

User interface and control facilities (UICF)2,300Two-dimensional geometric analysis (2DGA) 5,300Three-dimensional geometric analysis (3DGA) 6,800Database management (DBM) 3,350Computer graphics display facilities (CGDF) 4,950Peripheral control (PC) 2,100Design analysis modules (DAM) 8,400---------------------------------------------------------------------------estimated lines of code 33,200

The range of LOC estimates for the 3D geometric analysis function is:Sopt = 4600, Sm = 6900 Spess = 8600

An Example of FP-based Estimation

Information Domain Value opt. Likely pess. Est. count weight FP-count---------------------------------------------------------------------------------------------------no. of inputs 20 24 30 24 4 96no. of outputs 12 16 22 16 5 80no. of inquires 16 22 28 22 4 88no. of files 4 4 5 4 10 40no. of external interfaces 2 2 3 2 7 14---------------------------------------------------------------------------------------------------count-total 318---------------------------------------------------------------------------------------------------Factor Value Factor ValueBackup and recover 4 Data communications 2Distributed processing 0 Performance critical 4Existing op env. 3 On-line data entry 4Input transaction 5 Master files updated 3over multiple screens Information domain value complex.5Internal processing complex 5 Code designed for reuse 4Conversion/installation in design 3 Multiple installations 5Application designed for change 5 Complexity adj. Factor 1.17

Empirical Estimation Models

An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP.

The empirical data that support most estimation models is derived from a limited sample of projects. ---> The results from such models must be used judiciously.

The Structure of Estimation Models:

A typical estimation model is derived using regression analysis on data collectedfrom past software projects. The overall structure of such models takes the form:

CE = A + B X (ev)

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

The COCOMO Model

Barry Boehm [BOE81]’s COCOMO stands for COnstructuve COst Model.

COCOMO model is a comprehensive empirical model for software estimation.

Three forms:Model 1: The Basic COCOMO model

- computes the cost as a function of program size expressed in estimated lines of code.

Model 2: The Intermediate COCOMO model- computes the cost as function of program size and a set of “cost drivers”, such as hardware, personnel, project attributes,.. product attribute.

Model 3: The Advanced COCOMO model- incorporates all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step of the softwareprocess.

The COCOMO Model

Basic COCOMO model:

bb

E = ab KLOC

db

D = cb E E- the effort applied in person-months.D - the development time in chronological months.

Software project ab bb cb dborganic 2.4 1.05 2.5 0.38semi-detached 3.0 1.12 2.5 0.35embedded 3.6 1.20 2.5 0.32

1.05 1.05 Example: E = 2.4 (KLOC) = 2.4(33.3) = 95 person-months

0.35 0.35D = 2.5 E = 2.5 (95) = 12.3 months, N=E/D=95/12.3= ~8 people.

The COCOMO Model

Intermidiate COCOMO model:

bi

E = ai KLOC X EAF

E- the effort applied in person-months.EAF - An effort adjustment factor (EAF)

typical values range from 0.9 to 1.4.

Software project ai biorganic 3.2 1.05semi-detached 3.0 1.12embedded 2.8 1.20

The Software Equation

The software equation [PUT92] - a multivariable model.--> assume a specific distribution of effort over the life of a software development project. (based on data from 4000 projects)

0.333 3 4E = [LOC X B / P ] X (1 / t )

E - effort in person-months or person-years.t - project duration in months or years B - special skill factor.

For small programs (KLOC = 5 - 15), B = 0.16.For programs greater than 70 KLOC, B = 0.39.

P - “productivity parameter” that reflects:- overall process maturity and management practices- the extent to which good software engineering practices are used- the level of programming languages used- the state of the software environment- the skill and experience of the software team- the complexity if the application

P = 2000 for real-time embedded softwareP = 10,000 for telecommunication systems, P = 28,000 for business application systems

The Make-Buy Decision

In many cases, it is often more cost effective to acquire, rather than develop, computer software.

Mangers are faced with a make-buy decision based on three acquisition options:- software may be purchased (or licensed) off-the-shelf- “full-experience” or “partial-experience” software components- customer-built software

For more expensive software products, the following guidelines can be applied:

- 1) Develop a specification for the desirable function and performance.- 2) Estimate the internal cost to develop and delivery date.- 3a) Select 3 or 4 candidate applications that best meet your specification.- 3b) Select reusable software components for applications.- 4) Develop a comparison matrix for key functions.- 5) Evaluate each software package or component.- 6) Contact other users for opinions.

The Make-Buy Decision- Creating a Decision Tree

In the final analysis, checking the following questions:- Will the delivery date of the software product be sooner than for internally developed software?- Will the cost of acquisition plus the cost of customization be less than the costof developing the software internally?- Will the cost of outside support be less than the cost of internal support?

$500,000

$400,000

$380,000$450,000

$275,000

$310,000

$490,000

$210,000

Without changes (0.60)

With changes (0.40)

minor changes (0.70)

major changes (0.30)

simple (0.30)

difficult (0.70)

minor changes (0.40)

simple (0.20)

complex (0.80)Major changes (0.60)

System X

build

contract

reuse

buy