software engineering processes - ii 2.1 unit 2: project cost estimation software engineering...

Software Engineering Processes - II 2.1

Unit 2:

Project Cost Estimation

Software Engineering Processes - II


What are your expectations from this unit?

Before You Begin…


Unit Objectives

Identify the methods for preparing initial estimates.

Describe software estimation problems.

Count function points for simple projects using function point analysis.

Estimate the cost of a project using COCOMO II.

Define the factors affecting total project cost.

Explain detailed costing and scheduling.

Describe project performance monitoring.


Project Cost Estimation

Estimation involves identifying the following factors:

Effort required to complete each activity

Calendar time required to complete each activity

Total cost of each activity


Project Cost Estimation (cont.)


Initial Project Estimates

Initial estimates, though not very accurate, serve the following objectives:

They define the project scope and associated risks.

They help the organization decide whether the project should be undertaken or not.

They serve as the basis for detailed estimates when the requirements are clearer.


Calculating Initial Project Estimates

Initial estimates can be calculated using the following methods:

Analogy: Actual cost and schedule of a similar project

Rules of thumb: Organizational guidelines based on past project database

Parametric models: Product properties such as LOC to predict cost and schedule


Class Activity -1

Make a list of questions that a project manager should answer to help him select the appropriate past projects that can be used as a basis for estimating cost of a new project.


Initial Estimation Problems

The following problems might occur while calculating the initial estimates:

Uncertain requirements: Requirements must be known with some degree of certainty to get accurate estimates.

Diseconomy of scale: A slight increase in the size of the product may require more than equal amount of increase in effort and time.

Brooks Law: Increase in the number of people does not necessarily reduce the time taken to complete a project.


Initial Estimation Problems (cont.)

Staff skills and experience: The necessary staff skills may not be available for the project, which may affect the schedule or cost.

Optimal staffing level: Staffing may not be uniform over the course of the project.

Risk allowance: Evaluation of the risks of the project, for which a 20 % margin is considered to be reasonable, may not be accurate.


Parametric Estimation Models

Parametric models have been developed by performing statistical analysis of many earlier projects.

They use various forms of input such as:

The expected size of product

Nature of the product

Organization capabilities

Project properties


COCOMO II

COCOMO II can be used to model a broader variety of project circumstances:

Early design : Can be applied to calculate the initial estimates when the design phase has not started. The requirements are known only from the agreement.

Post architecture: Can be applied when the requirements and early design phase are complete.


Early Design

The estimates produced at this stage are based on the standard formula for algorithmic models:

Effort = A*Sizeb*M

Based on his own large data set, Boehm proposes that A should be 2.94.

Size of the system is given in KSLOC, which is the number of thousands of lines of source code. Calculate function points and then use standard tables that relate software size to function points for different programming languages.

Exponent b varies from 1.1 to 1.24.


Early Design (cont.)

Multiplier M is based on a set of seven project characteristics that influence the estimate:

Product reliability and complexity (RCPX)

Reuse required (RUSE)

Support facilities (FCIL)

Personnel capability (PERS)

Platform difficulty (PDIF)

Personnel experience (PREX)

Schedule (SCED)

M = PERS* RCPX*RUSE*PDIF*PREX*FCIL*SCED


Post-Architecture

Post-architecture is based on the same formula (Effort = A*Sizeb*M) as early design, but the size estimates are now more accurate.

M is more accurate. More extensive set of 17 attributes instead of 7 are used to refine the effort computation, because more information is available about the software and the development process.


Function Point Analysis

A function point (FP) is a measure of the functionality of the software product, independent of the technology used.

The steps involved in calculating the FPs for a software application are:

1. Define the application boundary.

2. List all the external input values, output values, inquiries, internal logical files (ILFs) and external interface files (EIFs).

3. Group the listed items based on their complexity factor as low, medium, and high.

4. Consolidate the counts and apply the standard FPA weights.


Function Point Analysis (cont.)

Consider the following application. The following table lists the weights and counts for the five categories of external and internal data based on their complexity.

Functions Low Medium High

Count Weight Total Count Weight Total Count Weight Total UFC

Input Values 4 3 12 8 4 32 1 6 6 50

Output Values 11 4 44 25 5 125 17 7 119 288

Inquiries 0 3 0 2 4 8 1 6 6 14

Interfaces 16 5 80 42 7 294 0 10 0 374

Internal Logical Files 28 7 196 7 10 70 7 15 105 371

Totals 59 332 84 529 26 236 1097


Function Point Analysis (cont.)

5. Determine the Degree of Influence (DI) on a scale of 0-5 for each of the complexity factors given in the following table. Compute the sum as TDI.

Complexity Adjustment factors DI

1 Data communication 5

2 Distributed functions 0

3 Performance 4

4 Heavily utilized operational environment 2

5 Transaction rate 3

6 On-line data entry 2

7 Design for end-user efficiency 2

8 On-line master updates 2

9 Complex processing 4

10 Code reusability 4

11 Installation ease 4

12 Operational ease 2

13 Multiple sites 2

14 Ease of change 4

40


FPA – Best Practices

For large projects where the effort is more than 15-20 person years, FPA estimates should be done by two persons independently. A discussion should follow to reconcile the differences.

A large application can be divided into several modules. Function point estimates should be calculated for each module separately and then compiled.


FPA – Best Practices (cont.)

Inter-module input values, output values and interfaces should be counted only once.

An organization wide common understanding of criteria, which define the input, output, inquiries, ILFs, and EIFs should exist.


Class Activity - 2

Compute the unadjusted function point count for a project that has the following functions:

User input values – 20 low, 12 medium complexity

Output values – 12 low, 12 medium and 6 high

Inquiries – 4 medium, 4 high

Files – 10 low, 12 medium

Interfaces – 0


Phase Wise Effort Distribution

Recommended effort distribution across the definition, analysis, and development phases is referred to as 40-20-40 rule. (traditional methods)

For object-oriented analysis, it is approximately 10-15-15-40-10-10 for: Analysis High-level design Low-level design Construction Module/integration testing System testing


Detailed Costing and Scheduling

Detailed costing and scheduling involves the following activities:

Reviewing the contract or SOW to determine overall project objectives and other nontechnical requirements, such as a visit to customer site for reviews is a nontechnical requirement.

Identifying dependencies on external data or events, such as data or reports from a legacy system.

Identifying all project deliverables other than the software application, such as operations manual, user training, and post-delivery on-site support.


Detailed Costing and Scheduling (cont.)

Partitioning the requirements, deliverables, and activities into work packages.

Identifying dependencies among work packages and sequencing them in serial or in parallel.

Estimating the resources and schedule needed to deliver each package.

Estimating the budgets required by including labor, capital, and expenses.

Evaluating and refining the estimates and budget.


Work Packages

A work package is a discrete task, performed to achieve the project objectives.

A work package specification should consist of:

Description of the task

Preconditions, such as SRS or architectural design

Postconditions, such as approved SRS

Related project objectives

Time, effort, and resources required to complete the work package


Example of a Work Package Specification

Work Package SpecificationActivity number: 3.3.2

Activity name: ARCH-SS-XYZActivity description: Specify the architectural structure of subsystem XYZProject requirement: Deliverable prime software, WBS 5.6Estimated duration: 5 weeksEarned value status method: Incremental in 6 steps. See attached status plan

Resources needed:Personnel: 2 senior telecom designersSkill: Designers familiar with S2 protocolTools: 1 Sun workstation with IDE; 1 VT100/DEC 785Travel: One 3-day design review in San Diego

Work/product/postconditions: Architectural specification of SS-XYZTest plan for subsystem XYZBaselined? Yes for bothRisks: Availability of senior designersPreconditions: An approved architectural concept of the total systemCompletion criteria: PDR sign-off for subsystem XY


Monitoring Project Performance

Weekly status report should contain:

Hours spent on the work package

Informal assessment of work package

Issues that can impact schedule, cost, and quality

Reasons for occurrence of these issues and strategies to counter the impact of these issues


Monitoring Project Performance (cont.)

To deal with schedule and cost variances, you can :

Scale back the requirements of one or more work packages

Break packages into parallel efforts

Apply more staff, if feasible

Evaluate change in tools and technology


Earned Value

The earned value system is based on three metrics:

Budgeted cost of work scheduled (BCWS): Effort planned to be spent by a given date

Actual cost of work performed (ACWP): Effort actually spent as of the that date

Budgeted cost of work performed (BCWP): The planned effort needed to achieve the present level of work completion as of that date


Just a Minute

If for a project, BCWP = ACWP and BCWS = BCWP, what can you conclude?


Variances

Cost Variance: CV = BCWP – ACWP

Schedule Variance: SV = BCWP – BCWS

Cost Performance Index: CPI = BCWP/ACWP

Schedule Performance Index: SPI = BCWP/BCWS


Class Activity - 3

Can you identify the strengths and limitations of the earned value system?


Summary

What was your key learning from the unit?

software engineering processes - ii 2.1 unit 2: project cost estimation software engineering...

Documents