chapter(4:(measuring(the(eﬀort for(so6ware(project · pdf...

Chapter 4: Measuring the Effort for So6ware Project

Complied by Heng Sovannarith [email protected]

IntroducFon •  EsFmaFon of resources, cost and schedule of so6ware

development are very important. •  To make a good esFmate requires experience and

experFze to convert qualitaFve measures to quanFtaFve form.

•  Factors like Project size, Amount of risk involved etc. are affecFng the accuracy and efficacy of esFmates.

•  The following are the different techniques for esFmaFon –  Source Lines of Code (SLOC) –  FuncFon Point (FP) –  ConstrucFve Cost Model (COCOMO) –  Delphi

SLOC Technique

•  Source lines of code (SLOC) is a so2ware metric used to measure the size of a so2ware program by counFng the number of lines in the text of the program's source code.

•  SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to esFmate programming produc;vity or maintainability once the so6ware is produced.

SLOC Technique (cont.) •  So6ware projects can vary between 1 to 100,000,000 or

more lines of code. •  Using lines of code to compare a 10,000 line project to a

100,000 line project is far more useful than when comparing a 20,000 line project with a 21,000 line project.

•  There are two major types of SLOC measures: physical SLOC (LOC) and logical SLOC (LLOC).

•  Physical SLOC –  SLOC is a count of lines in the text of the program's source code including comment lines.

–  Blank lines are also included unless the lines of code in a secFon consists of more than 25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of code.

SLOC Technique (cont.)

•  Logical SLOC – Logical SLOC a]empts to measure the number of executable "statements", but their specific definiFons are Fed to specific computer languages (one simple logical SLOC measure for C-‐like programming languages is the number of statement-‐terminaFng semicolons).

•  logical SLOC can o6en be significantly different from physical SLOC.

SLOC Technique (cont.)

•  Example

Usage of SLOC measures •  Experiments have repeatedly confirmed that effort is highly correlated with SLOC that is, programs with larger SLOC values take more Fme to develop.

•  Thus, SLOC can be very effecFve in esFmaFng effort.

•  However, funcFonality is less well correlated with SLOC: skilled developers may be able to develop the same funcFonality with far less code, so one program with less SLOC may exhibit more funcFonality than another similar program.

Usage of SLOC measures (cont.)

•  In parFcular, SLOC is a poor producFvity measure of individuals, since a developer can develop only a few lines and yet be far more producFve in terms of funcFonality than a developer who ends up creaFng more lines (and generally spending more effort).

•  Inexperienced developers o6en resort to code duplicaFon, which is highly discouraged as it is more bug-‐prone and costly to maintain, but it results in higher SLOC.

Usage of SLOC measures (cont.) •  SLOC is parFcularly ineffecFve at comparing programs

wri]en in different languages unless adjustment factors are applied to normalize languages.

Usage of SLOC measures (cont.) •  Modern so6ware tools o6en have the capability to auto-‐

generate enormous amounts of code with a few clicks of a mouse.

•  For instance, GUI builders automaFcally generate all the source code for a GUI object simply by dragging an icon onto a workspace.

•  The work involved in creaFng this code cannot reasonably be compared to the work necessary to write a device driver, for instance.

•  There are several cost, schedule, and effort esFmaFon models which use SLOC as an input parameter, including the widely-‐used ConstrucFve Cost Model (COCOMO) series of models by Barry Boehm et al.

Example of SLOC

•  Example:

Example of SLOC (cont.) •  David A. Wheeler studied the Red Hat distribuFon of

the Linux operaFng system, and reported that Red Hat Linux version 7.1 (released April 2001) – Over 30 million physical SLOC. –  Required about 8,000 man-‐years of development effort

– Would have cost over $1 billion (in year 2000 U.S. dollars).

– Note: Man-‐Year is a method of describing the amount of work done by an individual throughout the enFre year. The man-‐year takes the amount of hours worked by an individual during the week and mulFplies it by 52 (or the number of weeks worked in a year)

Example of SLOC (cont.)

Lines of Code – Advantages & Disadvantages

•  Advantages: – Scope for Automa;on of Coun;ng

•  Line of Code is a physical enFty. •  Small uFliFes may be developed for counFng the LOC in a program.

•  However, a code counFng uFlity developed for a specific language cannot be used for other languages

– An Intui;ve Metric: •  Line of Code serves as an intuiFve metric for measuring the size of so6ware due to the fact that it can be seen and the effect of it can be visualized.

Lines of Code – Advantages & Disadvantages (cont.)

•  Disadvantage – Lack of Accountability:

•  Lines of code measure suffers from some fundamental problems. First and fore most, It is completely inaccurate and unfortunate to have to measure the producFvity of a development project with the outcome of one of the phases (coding phase) which usually accounts for only 30% to 35% of the overall effort.

Lines of Code – Advantages & Disadvantages (cont.)

– Lack of Cohesion with Func;onality: •  Though experiments have repeatedly confirmed that effort is highly correlated with LOC, funcFonality is less well correlated with LOC. That is, skilled developers may be able to develop the same funcFonality with far less code, so one program with less LOC may exhibit more funcFonality than another similar program.

FuncFon Point Technique

•  Func;on Point Analysis is an objecFve and structured technique to measure so6ware size by quanFfying its funcFonality provided to the user, based on the requirements and logical design.

•  This technique breaks the system into smaller components so they can be be]er understood and analyzed.

•  For detail, please read Chapter 3: Metrics for So2ware Project Management

SEG3300 A&B W2004 R.L. Probert 18

Example on FuncFon Point


Example (.)

COCOMO Technique

•  The COnstruc;ve COst Model (COCOMO) is the most widely used so6ware esFmaFon model in the world.

•  The COCOMO model predicts the effort and dura;on of a project based on inputs relaFng to the size of the resulFng systems and a number of "cost drives" that affect producFvity.

•  The ConstrucFve Cost Model (COCOMO) is an algorithmic so6ware cost esFmaFon model developed by Barry W. Boehm in 1981.

COCOMO Technique (cont.)

•  It is also know as COCOMO 81 •  Second Version: ADA Cocomo (ADA 87) •  Current Version: COCOMO II (circa 2000)


•  The model uses a basic regression formula with parameters that are derived from historical project data and current project characteris;cs.

•  It drew on a study of 63 projects at TRW Aerospace where Boehm was Director of So6ware Research and Technology.


•  COCOMO is defined in terms of three different models: –  the Basic model, –  the Intermediate model, and –  the Detailed/Advanced model.

•  The more complex models account for more factors that influence so6ware projects, and make more accurate esFmates.

Cost EsFmaFon Process " "

Errors

Effort

Development Time

Size Table

Lines of Code

Number of Use Case

Function Point

Estimation Process Number of Personnel

Project Size -‐ Metrics 1.   Number of func;onal requirements 2.   Cumula;ve number of func;onal and non-‐func;onal requirements 3.   Number of Customer Test Cases 4.   Number of ‘typical sized’ use cases 5.   Number of inquiries 6.   Number of files accessed (external, internal, master) 7.   Total number of components (subsystems, modules, procedures, rou;nes, classes,

methods) 8.   Total number of interfaces 9.   Number of System Integra;on Test Cases 10.   Number of input and output parameters (summed over each interface) 11.   Number of Designer Unit Test Cases 12.   Number of decisions (if, case statements) summed over each rou;ne or method 13.  Lines of Code, summed over each routine or method

Project Size – Metrics(.) Availability of Size Estimation Metrics:"

"

Development Phase"

Available "Metrics" a"

Requirements Gathering"

1, 2, 3"

b"

Requirements Analysis"

4, 5"

d"

High Level Design"

6, 7, 8, 9"

e"

Detailed Design"

10, 11, 12"

f"

Implementation"

12, 13"

"


RelaFon between LOC and FP

•  RelaFonship:

– LOC = Language Factor * FP !

– where •  LOC (Lines of Code) •  FP (FuncFon Points)


RelaFon between LOC and FP(.)

Assuming LOC’s per FP for: Java = 53, C++ = 64

KLOC = FP * LOC_per_FP / 1000

It means for the SpellChekcer Example: (Java)

LOC=52.25*53=2769.25 LOC or 2.76 KLOC

Basic COCOMO Model •  The Basic COCOMO model computes effort as a funcFon of

program size. The Basic COCOMO equaFon is: – Effort Applied (E) = aKLOC^b (man-‐month) – Development Time (D) = c(E)^d (months) – People required (P) = E / D (count)

•  Effort for three modes of Basic COCOMO.

Mode a b c d

Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Basic COCOMO Model (cont.)

•  Basic COCOMO is good for quick, early, rough order of magnitude esFmates of so6ware cots.

•  It does not account for differences in hardware constraints, personnel quality and experiences, use of modern tools and techniques, and other project a]ributes known to have a significaFon influence on so6ware costs, which limits its accuracy.


•  Organic – The project deals with developing a well understood applica;on program.

–  In organic type, the size of the development team is reasonably small, and the team members are experienced in developing similar types of projects.

– Data processing programs can be considered as Organic type.


•  Semidetached –  the development consists of a mixture of experienced and inexperienced staff.

– Team members may have limited experience on related systems being developed.

– UFlity programs like compilers, linkers etc are the examples of semidetached type.


•  Embedded – The so6ware being developed is strongly coupled to hardware.

– System programs like operaFng systems, real-‐Fme systems etc can be considered as embedded type.


Example

Example

(FSP) means Full-‐;me-‐equivalent So2ware Personnel


Intermediate COCOMO Model •  The intermediate COCOMO model computes effort as a

funcFon of program size and a set of cost drivers. The Intermediate COCOMO equaFon is: – E = aKLOC^b*EAF

•  Effort for three modes of intermediate COCOMO.

Mode a b

Organic 3.2 1.05

Semi-detached

3.0 1.12

Embedded 2.8 1.20

Intermediate COCOMO Model (cont.)

•  The Intermediate Model esFmates the so6ware development effort by using fi2een cost driver variables besides the size variable used in Basic COCOMO

•  Four areas for drivers – Product itself – Computer – Personnel – Project itself

Example

DistribuFon of Effort

•  A development process typically consists of the following stages: – Requirements Analysis – Design (High Level + Detailed) – Implementation & Coding – Testing (Unit + Integration)

DistribuFon of Effort The following table gives the recommended percentage distribution

of Effort (APM) and TDEV for these stages: Percentage Distribution of Effort and Time Table:

Req Analysis

Design, HLD + DD

Implementation

Testing

Effort

28%

29%

22%

21%

100%

TDEV

39%

25%

15%

21%

100%

Advanced/Detailed COCOMO Model

•  The detailed model differs from the Intermediate model in only one major aspect: the Detailed model uses different Effort MulFpliers for each phase of a project. These phase dependent Effort MulFpliers yield be]er esFmates than the Intermediate model. the six phases COCOMO defines are:

Abbrevia;on Phase RQ Requirements PD Product Design DD Detailed Design CT Code & Unit Test IT Integrate & Test MN Maintenance

Advanced/Detailed COCOMO Model (cont.)

•  The Programmer Capability cost driver is a good example of a phase dependent cost driver.

•  The Very High raFng for the Programmer Capability Cost Driver corresponds to an Effort Mul;plier of 1.00 (no influence) for the Product Design phase of a project, but an Effort Mul;plier of 0.65 is used for the Detailed Design phase.

•  These raFngs indicate that good programmers can save ;me and money on the later phases of the project, but they don't have an impact on the Product Design phase because they aren't involved.

Delphi Technique •  Delphi is a place in Greece, which was supposed to confer predicFve powers to the person. A temple was built there and virgin girls were appointed there to answer quesFons about the future – these were called Oracles.

•  Oracle’s prophecies were considered propheFc or at least wise counsel.

•  This technique, taking cue from the above legend, is drawing wise counsel (Oracle) from senior and experienced so2ware developers for preparing esFmates for so6ware development projects.

Delphi Technique (cont.)

•  Developed by Rand Corpora;on •  Under this method of so6ware esFmaFon, the project specificaFons would be given to a few experts and their opinion taken.

•  The actual number of experts chosen would depend on their availability.

•  A minimum of three is normally selected to have a range of values.


•  Now this method has the following steps – 1.  SelecFon of experts 2.  Briefing to the experts 3.  CollaFon of esFmates from experts 4.  Convergence of esFmates and finalizaFon


•  SelecFon of experts – Now the experts are selected who have these a]ributes, namely, 1. They have so6ware development experience 2. They have worked and possess knowledge in the applicaFon domain at hand 3. They may be from within the organizaFon or from without the organizaFon


•  It is necessary to select at least three experts so that there is a range. The actual number of experts selected can depend on the – 1.  Complexity of the project – more complex more

experts 2.  Availability of experts who have the domain

knowledge 3.  The compeFFon and the necessity of winning over

compeFFon – if we perceive sFff compeFFon and expecFng the margins to be low, we need to get more expert advice


•  Briefing the experts – The experts need to be briefed about the project. This may happen independently or in a meeFng.

– The following aspects need to be briefed – 1.  ObjecFves of the esFmaFon 2.  ExplanaFon of the project scope 3.  CompeFFon and its nature in the project bidding 4.  Timelines for compleFng the esFmate and

deliverables expected from the experts 5.  Any clarificaFons asked by the experts


•  Now the experts would be ready for coming out with the esFmates.

•  How much Fme should we allow experts to come out with esFmates? It depends on the requirements of the project and the willingness of the experts.

•  We would advocate a minimum on one calendar so that the experts do have Fme to mull over the project and come out with esFmates.


•  CollaFon of esFmates received from the experts – The experts are expected only to give just to give one figure for so6ware development effort and opFonally so6ware size.

– This is their best guess or hunch.


•  Each of these Oracles (experts) would give their opinion. Then these opinions were tabulated as shown in the below table.


•  Convergence of es;mates and finaliza;on


•  Merits of Delphi technique – Very useful when the organizaFon does not have any in-‐house experts with the domain knowledge or the development platorm experience to come out with a quick esFmate

– Very quick to derive an esFmate – Simple to administer and use –  If appropriate experts are chosen carefully, the results can be surprisingly accurate


•  Demerits of Delphi technique –  This is too simplisFc –  It may be difficult to locate right experts –  It may also be difficult to locate adequate number of experts willing to parFcipate in the esFmaFon

–  The derived esFmate is not auditable –  It is not possible to determine the causes of variance between the esFmated value and the actual values

– Only size and effort and esFmaFon are possible – schedule would not be available.

chapter(4:(measuring(the(eﬀort for(so6ware(project · pdf...

Documents