1 of 19

METRICS FOR PROJECT SIZE ESTIMATION

Speaker: Sirveer Dhaliwal

2 of 19

WHY ESTIMATE ?

  • The accuracy of project estimates can have a dramatic impact on profitability.
  • Software development projects are characterized by regularly over running their budgets and rarely meeting deadlines.
  • Effective software estimation is one of the most important software development activities however it is also one of the most difficult.
  • Under estimating a project will lead to under staffing it, under scoping the quality assurance effort and setting too short a schedule. That in turn can lead to staff burnout , low quality , loss of credibility, deadlines being missed and ultimately to inefficient development effort that takes longer than normal.
  • Overestimating a project can be almost as bad , work expands until available time comes into play. Which means that the project will take as long as estimated .
  • An accurate estimate is a critical part of the foundation of efficient software development.

3 of 19

What is Measurement ?

4 of 19

Metrics

5 of 19

METRIC

  • Definition : “a quantative measure of the degree to which a system,component,or process possesses a given attribute”

6 of 19

PROJECT METRICS

  • Software project metrics are used for strategic purposes.

  • Software project measures are tactical. That is, project metrics and the indicators derived from them are used by a project manager and a software team to adapt project work flow and technical activities.

7 of 19

Applications of project metrics

1. The first application of project metrics on most software projects occurs during estimation.

Metrics collected from past projects are used as a basis from which effort and time estimates are made for current software work.

As a project proceeds, measures of effort and calendar time expended are compared to original estimates .

The project manager uses these data to monitor and control progress.

8 of 19

Cotd.

2. As technical work commences, other project metrics begin to have significance.

Production rates represented in terms of pages of documentation, review hours, function points, and delivered source lines are measured.

In addition, errors uncovered during each software engineering task are tracked. As the software evolves from specification into design, technical metrics are collected to assess design quality .

9 of 19

Cotd.

  • The intent of project metrics is twofold :
  • First, these metrics are used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks.
  • Second, project metrics are used to assess product quality on an on going basis and, when necessary, modify the technical approach to improve quality.
  • As quality improves, defects are minimized, and as the defect count goes down,
  • the amount of rework required during the project is also reduced.
  • This leads to a reduction in overall project cost.

10 of 19

Basic Model

  • Every project should measure :
  • Inputs-measures of the resources (e.g., people, environment) required to do the work.
  • Outputs-measures of the deliverables or work products created during the software engineering process.
  • Results-measures that indicate the effectiveness of the deliverables.

11 of 19

Software measurement

  • Measurements in the physical world can be categorized in two ways:
  • direct measures(e.g., the length of a bolt)
  • indirect measures (e.g., the "quality" of bolts produced)

12 of 19

Software metrics

  • Software metrics can be categorized similarly:
  • Direct measures of the software engineering process include cost and effort applied.
  • Direct measures of the product include lines of code (LOC) produced, execution speed,memory size, and defects reported over some set period of time. (easy to collect)
  • Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability .(relatively difficult)

13 of 19

Size oriented metrics

  • Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced.
  • If a soft-ware organization maintains simple records, a table of size-oriented measures, such as the one shown in Figure , can be created.
  • The table lists each software development project that has been completed over the past few years and corresponding measures for that project. Referring to the table entry for project alpha:
  • 12,100 lines of code were developed with 24 person-months of effort at a cost of
  • $168,000. It should be noted that the effort and cost recorded in the table represent
  • all software engineering activities (analysis, design, code, and test), not just coding.
  • Further information for project alpha indicates that 365 pages of documentation were developed, 134 errors were recorded before the software was released, and 29 defects

14 of 19

PROJECT

LOC

EFFORT

$(000)

Pp.DOC.

ERRORS

DEFECTS

PEOPLE

Alpha

12,100

24

168

365

134

29

3

beta

27,200

62

440

1224

321

86

6

gamma

20,200

43

314

1050

256

64

5

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15 of 19

Function-Oriented Metrics

  • Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value.

`functionality' cannot be measured directly, it must be derived indirectly using other direct measures.

  • Function-oriented metrics use a measure called the function point.

16 of 19

  • Function points are computed [IFP94] by completing the table shown in Figure .

17 of 19

Measurement parameter

Count

Weighting factor

Simple Average Complex

No: of user inputs

No: of user outputs

No: of user Inquiries

No: of files

No: of external interfaces

× 3 4 6 =

Count total

18 of 19

  • Number of user inputs. Each user input that provides distinct application-oriented data to the software is counted. Inputs should be distinguished from inquiries, which are counted separately.

  • Number of user outputs. Each user output that provides application-oriented information to the user is counted. In this context output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.

  • Number of user inquiries. An inquiry is defined as an online input that results in the generation of some immediate software response in the form of an online output. Each distinct inquiry is counted.

  • Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file) is counted.

  • Number of external interfaces. All machine readable interfaces (e.g., datafiles on storage media) that are used to transmit information to another system are counted.

19 of 19

  • To calculate fp the relation used is:
  • FP = count total *[0.65 + 0.01 *summation(Fi)]
  • where count total is the sum of all FP entries obtained from Figure